2008-10-13

<hcarty> let ertai = ertai + 1
<hcarty> camlp4 seems to work well in the toplevel again!
<hcarty> ertai: The fix for bug #4495 seems to work properly under CVS HEAD and 3.10.2 on my system
<hcarty> There was a mailing list post about this at some point, but I have been unable to find it
<hcarty> Does anyone here know how to apply an outside patch to a godi package?
<hcarty> ertai: A simple test worked here, but several libraries I'm using apparently have trouble with CVS HEAD, or their godi versions do at least. I'm going to try the patch against 3.10.2 and see how that works out.
<hcarty> labltk isn't building for me, and I'm wondering if there is a simple way to fix it
<hcarty> Has anyone here built OCaml CVS (3.11) from godi?
<hcarty> ertai: Thanks. Once I get the changes and test I will report back.
<ertai> hcarty: only camlp4/Camlp4Top/Top.ml
<hcarty> ertai: And, similarly, which files changed so I know what to watch for?
<hcarty> ertai: If you are around - do you have an idea of approximately how long it will take for the camlp4 changes to propagate to the public anonymous CVS?
<ertai> hcarty: It might take a while to propagate to the public annon CVS but it's commited
<hcarty> ertai: I'm off for a bit, but please leave a note when the code is ready to test and I will do so
<hcarty> ertai: Thank you for your time and effort on this
<hcarty> ertai: Wonderful! It will likely take me a few hours as I am meeting with a prospective student soon, but I will happily do the testing
<ertai> hcarty: I would like you to test the camlp4 toplevel a little bit
<hcarty> ertai: pong
<ertai> hcarty: ping

2008-10-12

<hcarty> ertai: Thanks. I agree that it would be nice to have it for 3.11 if at all possible.
<ertai> hcarty: I have to go and so pause this camlp4 fix don't hesitate to recall me about it
<hcarty> ertai: Thank you for working on this
<ertai> hcarty: I've made progress
<ertai> hcarty: not yet, it was not the right fix
<hcarty> ertai: Any luck with the wrap function update?
<hcarty> ertai: I am happy to test here as well, if it would help
<ertai> hcarty: I came to the same conclusion and have changed something to this wrap function
<hcarty> ertai: I don't know if this helps at all
<hcarty> ertai: As far as I can tell, the #4495 problem comes from the wrap function in camlp4/Camlp4Top/Top.ml. Something is generating a Sys_error exception and (I think?) gen_print in camlp4/Camlp4/ErrorHandler.ml is printing the error
<ertai> hcarty: But not sure to find it
<ertai> hcarty: I'm looking at camlp4/Camlp4Top/Top.ml and toplevel/toploop.ml
<hcarty> ertai: Any suggestions on where to look? I tried digging through the code myself a while ago, but didn't have any luck at the time.
<hcarty> #4495 is the one I'm more concerned about, personally
<ertai> hcarty: trying to identify the bug by looking at the code could help
<ertai> hcarty: thanks but too late :)
<hcarty> ertai: Is there anything someone relatively ignorant of the OCaml internals, such as myself, can do to help resolve OCaml bugs #4495 and/or #4593? (camlp4 + toplevel)
<hcarty> Yoric[DT]: I suppose it depends on the attention you are trying to attract
<Yoric[DT]> hcarty: or "Empowering OCaml"?
<hcarty> Batteries: Powered by OCaml

2008-10-10

<nyingen> hcarty: neat
<hcarty> calc/Makefile in particular
<hcarty> The examples here might be useful as well, since they are quite simple: http://www.ocaml.info/ocaml_sources/ocaml-make-6.28.1/
<hcarty> I can paste an example, and I think there are some examples online
<hcarty> Yes
<hcarty> 4 or 5 lines are often enough
<Camarade_Tux> hcarty, how do you use it ? you "include" it in your makefile and then can benefit from automatic rules ?
<hcarty> Camarade_Tux: It doesn't really make the binding generation itself easier, but the Makefile is greatly simplified
<Camarade_Tux> hcarty, I think we always start thinking "it will be easy, just compile and that'll be ok", but then...
<hcarty> Camarade_Tux and nyingen: I have found OCamlMakefile /very/ helpful when starting a C library binding. It has a nice set of features to handle most of the details.
<hcarty> guyzmo: You are welcome
<guyzmo> hcarty - thank
<hcarty> guyzmo: Someone worked on something along those lines this past summer
<hcarty> grirgz: ocamlbuild should be useable in production - what are you looking for specifically?

2008-10-07

<hcarty> Yoric[DT]: Is this why you were (talking about?) updating Camomile in godi?
<hcarty> Yoric[DT]: What flux said, without a doubt

2008-10-06

<hcarty> Yoric[DT]: Very true
<hcarty> Yoric[DT]: Which extensions are included?

2008-10-01

<hcarty> I'm off though. Yoric[DT], I would be interested to hear if you find a solution
<hcarty> I don't think so, as all of the sub-modules of Mylib are visible on my install
<hcarty> for each sub-module
<hcarty> It looks like ExtLib under godi also have the .cmi and .mli files installed
<hcarty> Yoric[DT]: That I don't know, and have not tried
<Yoric[DT]> hcarty: ok.
<hcarty> kombinator: uintlib may do what you want, but I have not used it -- http://forge.ocamlcore.org/projects/uint64lib/
<hcarty> And they are 64bit on a 64bit platform
<hcarty> olegfink: I don't think nativeint values are unsigned
<hcarty> Yoric[DT]: "everything" here being building and running other code which uses the modules included in Mylib
<hcarty> Yoric[DT]: I haven't used -pack directly, but for a library built with mylib.mlpack I installed the mylib.* files using findlib and everything seems to work properly
<hcarty> flux: Thanks!
<hcarty> flux: That is probably a good idea
<hcarty> CoffeeBuzz: It is a decent start. The OCaml manual introductory chapter is nice as well.

2008-09-26

<hcarty> :-)
<DRMacIver> hcarty: Thanks very much for your help. Hopefully I'll get this figured out. :)
<hcarty> DRMacIver: Best of luck
<hcarty> You could use "open Mylib" to expose all of those modules directly, open them individually, or just qualify their contents with Mylib.Foo.x
<hcarty> DRMacIver: They are submodules of Mylib. So there is Mylib.General, Mylib.MyArray, Mylib.Math, etc
<hcarty> With Mylib compiled in this way, I only have to install the mylib.{cma, cmxa, ...} files for the module to work properly
<hcarty> DRMacIver: You're welcome. The .mlpack and _tags files let ocamlbuild know what modules to pack together in to the module Mylib
<DRMacIver> hcarty: Thanks
<hcarty> Yoric[DT]: Thanks for the clarification
<hcarty> DRMacIver: http://ocaml.pastebin.com/d51dd573f is some of what I use
<hcarty> DRMacIver: If you are using ocamlbuild, you may need to create a mylib.mlpack and a _tags file. This may depend on how you are putting the modules together
<hcarty> DRMacIver: Then /I think/ only the resulting library needs to be installed
<hcarty> Would the individual modules be used separately, or will they all be treated as pieces of a whole, never used on their own?
<hcarty> DRMacIver: Will they all be packed in to one large module?
<hcarty> DRMacIver: I apologize for the convoluted explanation .. I hope it has helped
<hcarty> The object and library files should generally be installed, and the .mli files can be useful to provide for reference purposes
<hcarty> DRMacIver: Sorry, here is a wiki page with (hopefully) more readable information from the above mailing list thread - http://ocaml-tutorial.org/filenames
<hcarty> Richard Jones' post has more detail
<hcarty> DRMacIver: .mli is the interface to a module; .cmi is (I think) a compiled .mli; .cma is a byte code library package; .cmxa is a native code library package
<hcarty> DRMacIver: That mailing list post has some explanation
<hcarty> Generally, the .cmi, .cma, cmxa, .so and .a files are, I think, enough. The .cmo and .cmx files can also be useful for the compiler.
<hcarty> ocamlbuild could just as easily be used to handle the compilation. But the "install:" section of the Makefile should give help get an idea of which files to install
<hcarty> This Vec library is fairly simple, and installs cleanly with ocamlfind: http://luca.dealfaro.org/Vec-Extensible-Functional-Arrays-for-Ocaml
<hcarty> That may be rather opaque though, coming in without much experience
<hcarty> DRMacIver: There was a mail list post about this recently. http://groups.google.com/group/fa.caml/browse_thread/thread/cf74ffa8876aa578
<hcarty> They definitely are not stupid questions :-) A "holy crap where did all of these files come from" reaction is understandable.
<hcarty> If the module is pure OCaml (no C or other languages) then ocamlbuild + ocamlfind is probably easiest
<DRMacIver> hcarty: This seems to generate an arbitrarily large number of module files though (well, ok, not that large. But more than one. :) ). Am I able to bundle these together in some way?
<hcarty> ocamlfind install mymodule mymodule.cma mymodule.cmxa META ...
<DRMacIver> hcarty: My aim here is to have the main library compiled as some sort of binary which I can package and then write a small OCaml frontend which deals with the export to ruby
<hcarty> DRMacIver: For installing, ocamlfind is probably the easiest way to go
<DRMacIver> hcarty: Yes
<hcarty> DRMacIver: Do you want to install the OCaml library for use from OCaml? I don't have any experience with rocaml
<DRMacIver> hcarty: Right, that's what I'm using
<hcarty> DRMacIver: rocaml may be of some assistance - http://eigenclass.org/repos/rocaml/head/

2008-09-15

<hcarty> And that list of modules seems to be fixed
<hcarty> flux: I don't think you can do that... the plugin seems to only have access to the modules specifically provided by ocamlbuild
<Eridius> hcarty: is there any way to install an ocamlbuild plugin globally, or does it have to be put into every project that wants it?
<hcarty> flux: Though I imagine a "smart" enough ocamlbuild plugin could respond appropriately to external library changes
<hcarty> flux: ocamlbuild does not support what you are looking for out of the box. I have the same problem with my own code built with ocamlbuild + ocamlfind.

2008-09-07

<Palace_Chan> thelema, no it helps, as hcarty was telling me it just takes some time to get used to the types in functional programming
<Palace_Chan> hcarty, how do i access the documentation, through the website ?
<hcarty> Practice worked best for me - particularly reading through the OCaml standard library documentation, comparing the function types with the short descriptions the documentation provides
<hcarty> Palace_Chan: That sort of type may take some time to get used to, but like anything else once you do they make sense

2008-09-06

<hcarty> Eridius: http://alain.frisch.fr/soft.html#patches -- There is a compiler patch here which allows for shared record fields within one module, but it does not apply cleanly to 3.10.x
<hcarty> det: Ah, I see. That's unfortunate that the preprocessor chokes
<hcarty> det: I think you would generally wrap the OCaml callback so that the value pointer is checked and updated if needed on each call

2008-09-05

<hcarty> haskellian: Why should it complain?
<Palace_Chan> hcarty, yep i guess
<hcarty> Palace_Chan: You can download it from http://www-rocq.inria.fr/~acohen/tuareg/ and do the installation manually in your home directory. Instructions are in the download.
<hcarty> Palace_Chan: It looks like tuareg-mode, at least, has ocaml as a dependency
<hcarty> haskellian: Because it takes 4 arguments and you gave it 3?
<hcarty> You can try
<hcarty> Regarding emacs, I'm not sure - those packages may require OCaml
<hcarty> Without it or a similar tool, ocaml does not allow using the arrow keys or similar to move around or see previous commands
<hcarty> Palace_Chan: rlwrap allows you to edit things you type like you can at the bash prompt
<Palace_Chan> hcarty, my emacs still opens .ml files in BS mode (DOS mode)...can i safely get ocaml-mode from my package manager without conflicting with my build right now ?
<hcarty> Palace_Chan: You can also install rlwrap (sudo apt-get install rlwrap) and use it to make working with the ocaml toplevel much nicer
<Palace_Chan> hcarty, k let me give it a try
<hcarty> Palace_Chan: Yes
<Palace_Chan> hcarty, oh same thing just with export
<hcarty> export PATH=$PATH:/home/palace/ocaml/bin
<Palace_Chan> hcarty, i do ?
<hcarty> Actually... no, you likely still need to export PATH
<hcarty> Palace_Chan: If you want to have it set in an existing, pre-bashrc-update session then you would need the export command
<hcarty> Palace_Chan: For .bashrc that is correct
<Palace_Chan> hcarty, why the export ? i thought i would add to the .bashrc: "PATH=$PATH:/home/palace/ocaml/bin"
<hcarty> For persistence
<hcarty> Palace_Chan: And yes you would have to add it to your bashrc
<hcarty> Palace_Chan: If you are using bash for your shell, then "export PATH=/path/to/install/bin:$PATH"
<Palace_Chan> hcarty, so add the full bin directory to my path ?
<hcarty> Palace_Chan: Just add $prefix/bin to your path
<hcarty> Palace_Chan: Yes yes, chown sorry
<Palace_Chan> hcarty, i just realized that apparently i have to work off the bin directory and run things like ./ocaml for the toploop is that normal ?
<Palace_Chan> hcarty, would'nt i want to use chown maybe ?
<hcarty> Otherwise it would only affect the bin, lib and man directories but nothing underneath
<hcarty> "R"ecursive
<hcarty> Since the files are presently owned by root
<hcarty> Palace_Chan: Actually you would need "sudo chmod -R myuser.myuser *"
<hcarty> Palace_Chan: From the installation prefix
<hcarty> Palace_Chan: chmod -R myuser.myuser *
<hcarty> Palace_Chan: It shouldn't be a big problem no
<hcarty> Palace_Chan: Another option would be to change all of the installed files so that they are owned by your user
<Palace_Chan> hcarty, ugh, i guess ill just stick to as is
<hcarty> Palace_Chan: Then you would most likely have to run most, if not all, of the steps again
<hcarty> And you shouldn't have to worry about any umask settings
<hcarty> Palace_Chan: If not, then all you would have to re-run is "make install"
<hcarty> Palace_Chan: Or anything else in the OCaml source directory after running "make install"?
<hcarty> Palace_Chan: Did you run "make clean" yet?
<Palace_Chan> hcarty, so binaries, libs and that...hmm that might be a problem
<hcarty> Palace_Chan: Everything under /home/palace/ocaml installed by "make install" is likely now owned by root
<hcarty> Palace_Chan: You can either leave it as-is, or remove the installation prefix and run "make install" again as your user rather than as root
<hcarty> You now have files own by root in your home directory
<hcarty> It just makes it more difficult to work with later
<Palace_Chan> hcarty, but what is the 'problem' ?
<hcarty> Palace_Chan: It's not a huge problem
<hcarty> s/Thaose/Those/
<hcarty> Palace_Chan: Thaose two steps are the installation
<Palace_Chan> hcarty, yea i used root only for the umask two steps
<hcarty> Palace_Chan: You probably shouldn't do the installation as root if you are installing in your home directory
<hcarty> Palace_Chan: Then you don't need su or sudo
<hcarty> s/Where/What/
<hcarty> Where prefix are you installing under?
<hcarty> Though make clean isn't really needed
<hcarty> Palace_Chan: You should be able to
<hcarty> Palace_Chan: In this case, I don't think it would be
<Palace_Chan> hcarty, oops so running them with sudo isnt equivalent to switching to root ?
<hcarty> Palace_Chan: so "sudo su" followed by the commands
<hcarty> Palace_Chan: The instructions are telling you to switch to root, then run those two commands
<hcarty> Palace_Chan: GODI is a package manager for OCaml
<Palace_Chan> hcarty, right, thanks for the heads up as i will turn to GODI if this doesnt work, im just at the final step though
<hcarty> Palace_Chan: Either way will allow you to have a basic OCaml installation though
<hcarty> Palace_Chan: But GODI provides other advantages over building OCaml by hand
<hcarty> Palace_Chan: That is true
<hcarty> "you" being me or anyone else
<hcarty> yziquel: Though you could probably rebuild the source packages from Lenny or Sid easily enough
<yziquel> hcarty: ok...
<hcarty> yziquel: OCaml is, sadly, not very well maintained in Ubuntu at this point
<hcarty> Palace_Chan: Then I definitely would recommend using GODI. I am under Ubuntu, with everything installed under $HOME and it works very well
<Palace_Chan> hcarty, yes i am not using my distros packages because i am asked to use version 3.10.2
<hcarty> (Assuming you are on some form of Linux or perhaps OSX)
<hcarty> I highly recommend it if you aren't using your distribution's packages
* Yoric[DT] concurs with hcarty.
<hcarty> Palace_Chan: GODI is a very nice tool for building OCaml and several related tools and libraries
<Palace_Chan> hcarty, Not really, but this is the final step in the installation of this and is, i believe, all i need for now
<hcarty> Palace_Chan: Have you tried GODI?
<hcarty> Yoric[DT]: If it works even just enough for basic package creation then it is a good example to have
<Yoric[DT]> hcarty: well, I've made one and it was rather simple.
<hcarty> The last time I read the documentation on the web site it seemed like a large amount of work
<hcarty> Yoric[DT]: You have a trivial way to make godi packages? That's wonderful news.

2008-09-04

<hcarty> haskellian: The manual in general is quite useful and readable
<hcarty> haskellian: So, not particularly
<hcarty> haskellian: It catches potential bugs at compile time. float_of_int or int_of_float isn't that generally that much of a problem to type
<hcarty> Proteus: There are, at least, bug fixes listed for 3.10.2 for ARM

2008-09-03

<hcarty> rwmjones: I sent a brief reply to one of the thread messages and CCd you. If you need any more information please feel free to ask.
<hcarty> rwmjones: Ok, thanks
<rwmjones> hcarty, yup, a good 80-90% I should think
<hcarty> rwmjones: Is it safe and appropriate to say that you packaged most of the OCaml-related software in Fedora?
<hcarty> rwmjones: Ok, will do
<rwmjones> hcarty, can you CC me in on any relevant ones please? to rjones / redhat / com
<hcarty> The relevant messages are not in the SF archive yet, but I can paste/forward messages if they would be useful
<hcarty> rwmjones: Thanks. I'd be happy to (try to) make whatever changes will make life easier for the packagers. Right now, the default "make install" puts everything under $prefix, without using ocamlfind or anything of the sort
<rwmjones> hcarty, oh right, thanks I'll have a look
<hcarty> rwmjones: There is a discussion right now on the PLplot mailing list about packaging the OCaml bindings for Fedora
<rwmjones> hcarty, pong
<hcarty> rwmjones: ping

2008-08-30

<hcarty> bluestorm: I think pa-do may allow for some sort of units sugar, like the F# feature you mentioned earlier. I don't know the details of the F# feature though, so this may not be comparable.

2008-08-28

<hcarty> The groups seem to be large this year as well, which may or may not be helpful
<hcarty> I think they required students' advisers to be more heavily involved
<hcarty> Hopefully the changes in the OSP structure will help keep the projects maintained.
<hcarty> bluestorm: Yes, probably
<hcarty> flux: I haven't either. The author(s?) just setup an external web site with, IIRC, some amount of documentation
<bluestorm> hcarty: if think it's related to the topic
<hcarty> Yes, I think Reins was the closest any of the projects came to having a life post-OSP
<hcarty> The final meeting is some time in the next few weeks. Early September... not sure of the exact date
<Proteus> hcarty, do you know off hand when the OSP ends?
<hcarty> bluestorm: Once the OSP is over, I think I will likely switch to pa-do
<hcarty> bluestorm: I saw the pa_scope project - it was annouced the day after (or perhaps two days after?) we discussed the same thing here in #ocaml
<Proteus> hcarty, that's good news
<hcarty> Proteus: The qtcaml Jane St. OSP is supposed to be, partly, tools for easing interface generation between C++ libraries and OCaml

2008-08-27

<_y_> hcarty: thank you very much, that's excellent and is exactly what I am looking for
<hcarty> _y_: http://www.linux-nantes.org/~fmonnier/OCaml/ocaml-wrapping-c.php is useful as well. Fewer details, but sometimes easier to read.
<hcarty> bluestorm: Very interesting link
<Proteus_> hcarty, I'm aware of Batteries, I'm not sure where I was going with that statement actually.
<hcarty> mrvn: Sorry, the Extlib+Batteries were meant more for Proteus_ re: "or a library of modules, organizing things nicely"
<hcarty> No Math module yet, but the GSL bindings and/or LACAML provide nice math tools
<mrvn> hcarty: Extlib is way more than a few math constants if it even has them
<hcarty> mrvn and Proteus_: There is Extlib, and Yoric[DT] + others are working on extending that with other goodies in Batteries

2008-08-26

<hcarty> rwmjones: Thank you
<rwmjones> hcarty, yes, very important to avoid $ and also << and >>
<hcarty> The docs recommend against using ( $ ) as an OCaml operator because it is used by camlp4. Could anyone here comment on the applicability of this warning outside of a camlp4 extension?
<hcarty> gildor: I've been following the pa-do work for a while now - it has been interesting watching their progress and I've already made a few bug reports and feature requests. Thank you for the links though.
<gildor> hcarty: using bzr you can even fetch their source code
<gildor> hcarty: pa-do folks also have a nice home page (http://pa-do.forge.ocamlcore.org/) and have already release one version (http://forge.ocamlcore.org/frs/?group_id=40) (talking about yesterday remark about OSP)

2008-08-25

<hcarty> At least the qtcaml folks have their Subversion repository open for others to look through
<hcarty> bluestorm: The pa-do folks seem reasonably communicative. It is too bad that everyone else seems silent though.

2008-08-20

<hcarty> One of the plotting devices supported in PLplot is Cairo, and the C library allows you to provide a Cairo context to the plotting routines - this could allow for embedding in a Gtk+ app and is on my eventual TODO list for the bingings
<hcarty> I'm not sure if your "plotting points" blog post was simply venting some steam, but the PLplot bindings may be useful for a task like you mentioned
<rwmjones> hcarty, pong
<hcarty> rwmjones: ping

2008-08-18

<hcarty> Thanks
<hcarty> I'm heading off for the night, but thanks for the offer
<hcarty> jeddhaberstro: Very nice, what sort of game?
<hcarty> Glad to help :-)
<hcarty> or { v = Array.map (fun a -> a *. s) v.v }
<hcarty> So you probably want { v = Array.map (( *. ) s) v.v }
<hcarty> "(*.) s" has type (float -> float) but v has elements of float
<hcarty> jeddhaberstro: Your function isn't complete

2008-08-17

<hcarty> And the patch applies fairly easily to 3.10.2 as well. I don't know if it /works/, but it applies
<hcarty> 3.04 according to the page
<Toonto_del_alma> hcarty, what is the old version?
<hcarty> The patch is on http://alain.frisch.fr/soft.html
<hcarty> s
<hcarty> But it is against an old version of OCaml, so I have no idea if it would work against newer OCaml version
<hcarty> There is also a patch to allow different records to have fields with the same names
<hcarty> It also seems to be a pre-3.10.0 extension
<hcarty> pa_records at http://oandrieu.nerim.net/ocaml/ if that is the correct one
<hcarty> But it has a different purpose
<hcarty> Still likely useful in some cases
<hcarty> bluestorm: The "handy record notation" extension doesn't do what I want, if it's the extension I think it is
<hcarty> If the compiler does gain such optimizations then the result of the syntax translation could be simplified accordingly
<hcarty> Given that it isn't at this time, camlp4 translations seem like a reasonable fix for now
<hcarty> Adding OVERLOAD_OPENIN DEFAULT to a source file would enable openin for Foo.(...) but not Float.(...) for example. As I understand it at least.
<hcarty> Enabling openin as a default action for Foo.(...) only applies for modules with no overloading defined, and even then you have to specify that you want to enable this
<hcarty> mfp: Yes, pa-do currently supports it on a module-by-module basis by default
<hcarty> I just tried it with no luck
<hcarty> No, apparently not
<hcarty> Yes
<hcarty> If you use a naive openin-like extension
<hcarty> mfp: But that is how opening Foo in Foo.(...) would work
<mfp> hcarty: it's irrealistic in that you allocate a closure per iteration
<hcarty> As in the slow version takes ~50% longer to run than the fast version
<hcarty> For this overly simplified case, the difference on my system is a little less than 50% for native code
<hcarty> bluestorm: I had reimplemented the benchmark incorrectly. The "slow" version: http://ocaml.pastebin.com/m3905d7cf and the "fast" version: http://ocaml.pastebin.com/m2a0bc94d
<hcarty> The pa-do developers are wonderfully responsive
<hcarty> bluestorm: Enabling openin (among other options) as a default action with Module.(...) syntax using pa-do is now possible with the latest bzr revision
<hcarty> I may bring up the idea to the pa-do folks just to see what they think
<hcarty> mfp: Thank you for the clarification
<hcarty> The transformation can be done with pa-do, so if something like that is needed later it can be implemented
<hcarty> bluestorm: Very good point regarding just using openin. If a simple benchmark is giving such strange results, this probably counts as severe premature optimization
<mfp> bluestorm, hcarty: let module X = ... causes allocation unless it's a mere module alias
<bluestorm> hcarty: without further information, i think the saner idea is to use the open_in trick
<hcarty> I'm on a 64bit system now, while I was a on a 32bit system before. I don't know if that makes any difference.
<hcarty> bluestorm: I can't find the benchmark I used, and an attempt to recreate them gave the opposite result :-)
<hcarty> bluestorm: I'll suggest that
<hcarty> I wrote a simple benchmark for to test for this a while ago, I'm not sure if I still have it