2009-09-02

<bluestorm> hcarty: I think userland stuff is a more reasonable target, at least for a beginning
<hcarty> That's getting a bit ahead of this though.
<hcarty> But, if not, they could be pushed in to Community OCaml or a similar project.
<hcarty> It would be particularly nice if the INRIA folks (xleroy, etc.) would agree to accept improvements from these events if they involve OCaml itself.
<hcarty> Camarade_Tux: user-suggested sprint!
<hcarty> Try to get some basic infrastructure to make it easy to, during the sprint, quickly share and push out changes for people to test.
<hcarty> GODI themed sprint, ocamlbuild themed sprint, library X themed sprint...
<hcarty> bluestorm: I think that's an excellent idea
<hcarty> And the pa_do author provides .godiva files for each release, which is nice as a GODI user.
<hcarty> bluestorm: Yes, user feedback can be a powerful motivator. I hope it has been helpful.
<hcarty> There may have been updates in the bzr repo since then though.
<hcarty> thelema: pa-do's last release was in July
<thelema> hcarty: it was last updated last november, no?
<hcarty> pa_do is also one of the (VERY) few Jane St. OSP projects still being maintained.
<hcarty> It's something I need to report to the authors, though they may know already.
<hcarty> mikmatch has similar problems - I'm not familiar enough with the internals to know exactly what is going on.
<hcarty> thelema: It's quite a nice piece of work. I use it often, and the only trouble I've had is that #use'ing a .ml file which uses pa_do from the toplevel gives some errors.
<thelema> hcarty: wow, I'm impressed
<hcarty> thelema: If the module/plugin says to. The included Float overloading does.
<hcarty> bluestorm: I definitely think both have their uses/places.
<bluestorm> hcarty: agreed, and moreover pa_do has specific features regarding numeric operators
<hcarty> bluestorm: Float.(1 + 2) is, I think, easier to read and comprehend (as a person reading code) than open Float in \n 1 + 2
<hcarty> Ah, ok. I think their scope is different though. And pa_do can, overall, make things a little clearer.
<hcarty> "Simple things" - such as?
<bluestorm> hcarty: I however feel that pa_openin, as it is much simpler, tends to be more reliable
<hcarty> Whereas pa_openin does incur a runtime penalty, though it can range from negligible to quite large.
<hcarty> Regarding pa_do vs pa_openin, pa_do has the benefit that it does not incur any runtime overhead, and in some cases brings about improvements in runtime.
<hcarty> Yes, a proper IDE or similar suite of tools would be quite nice. There are a lot of half-finished projects to help with this, but nothing that feels ready to go.
<hcarty> thelema: :-) And thank you for the information.
<hcarty> thelema: That's reassuring. I don't want to have to rip out all of the Batteries-dependent code I've written so far :-)
<thelema> hcarty: the fork will be merged once we get some good structure for pre-processing
<hcarty> The current state of Batteries seems to be getting a little depressing, with the semi-departure of David and pre-release forking.

2009-09-01

<Camarade_Tux> hcarty: no, it's ok, I have access to it thanks to ssh goodness :)
<hcarty> Camarade_Tux: I can email you the GODI camlp4 META file if it would help.
<hcarty> I wish for your speedy recovery :-)
<hcarty> Camarade_Tux: Best of luck then
<Camarade_Tux> hcarty: that's basically what I tried
<hcarty> The META file for camlp4 that ships with GODI is massive.
<hcarty> Or something similar to that
<hcarty> Camarade_Tux: Adding the line 'requires += "dynlink"' should do it
<Camarade_Tux> hcarty: order occured to me but I didn't try changing camlp4's META, gonna check/try
<hcarty> Camarade_Tux: Regarding the Windows problem - is dynlink.cma added too late in the command line? Maybe it needs to be added to camlp4's META file.
<hcarty> Interesting. I wonder if sup does that.
<hcarty> Interesting
<hcarty> Ah
<hcarty> Camarade_Tux: How so? (not disagreeing - curious)
<hcarty> If the IMAP service is up then it shouldn't, hopefully, lose any incoming mail.
<Camarade_Tux> hcarty: gmail's search is less powerful than google's however
<hcarty> Nothing here yet for the web interface.
<hcarty> And, thankfully, if you ask for a server-side search it's still very fast.
<hcarty> The IMAP interface seems to be working for Gmail. I can connect with mutt.
<hcarty> Or you can pull everything, get some possible duplicates, and maintain tags through the IMAP folders.
<hcarty> Camarade_Tux: I definitely recommend giving offlineimap a try. If you just pull the "All Mail" IMAP folder it will backup all of your mail. You won't have the tags, but the messages will be there.
<Camarade_Tux> hcarty: ok, good news :)
<hcarty> I don't do it as often as I should, but I've been using offlineimap to backup my Gmail account.
<hcarty> Camarade_Tux: They should all be available by IMAP at least. I can view my earliest (pre-IMAP) messages that way.
<hcarty> Sounds good
<hcarty> Yoric[DT]: Allowing for multiple ocamlfind targets? Or are you thinking of something different?
<hcarty> bluestorm: Fair point. I think Yoric[DT] is behind most, if not all, of the Batteries myocamlbuild.
<bluestorm> hcarty: the idea is certainly not mine, I reused the structure of Batteries myocamlbuild, wich I suppose is mostly from Yoric
<hcarty> bluestorm: On a different front, that is a very nicely put-together myocamlbuild.ml in macaque
<hcarty> They may not be able to (currently) avoid linking with camlp4.cma, but there is no need for preprocessing.
<hcarty> It is already up to the author of Batteries-using code if they want any camlp4 use in their project.
<hcarty> That doesn't alleviate the Batteries-compile-time requirement of sexplib, etc. But I would think that it is easier to change that in the Batteries code base than it is to maintain a separate branch of code.
<hcarty> (including Standard in Batteries)
<hcarty> That could be changed in Batteries as well.
<hcarty> If I add "open Batteries open Standard" to the start of foo.ml then it compiles without issue, because the library is linked but no camlp4 is applied to foo.ml
<hcarty> Or, with the full Batteries camlp4 suite.
<hcarty> It does apply, because with camlp4 the "open Batteries;; open Standard;;" is implicit.
<hcarty> But you would have to do that with aaa or any other non-camlp4-Batteries code.
<hcarty> "let f x = 1 |> print_int" in foo.ml, compiled with "ocamlfind ocamlopt -package batteries -linkpkg foo.ml" fails because none of the camlp4 is used in this case.
<hcarty> If you juse use pkg_batteries (or ocamlfind ocamlc -package batteries ...) no camlp4 is involved.
<hcarty> camlp4 is only enabled by default if you use the Batteries myocamlbuild.ml and use_batteries
<hcarty> The camlp4 requirement can already be avoided, correct?
<hcarty> Of course, I haven't used the sexplib support in Batteries, or how it is used throughout the code base, so I don't know if that is even remotely reasonable to attempt.
<hcarty> If that's the major hurdle for Windows.
<hcarty> Would it be enough to make sexplib, etc. optional compile-time dependencies for Batteries?
<hcarty> I just don't want Batteries to lose appeal before it ever gets started because there are multiple independently operated, divergent versions. The OCaml stdlib++ landscape is already rather difficult to take in :-)
<hcarty> s/a related/related/
<hcarty> thelema: That is certainly true. Properly modular myocamlbuild.ml support and a related ocamlfind support would be wonderful.
<hcarty> There are certainly Batteries-specific pieces in there, but a lot of it is making ocamlfind and camlp4 support easier.
<hcarty> Well, the Batteries myocamlbuild.ml is pretty generic overall.
<hcarty> bluestorm: Fair enough :-)
<bluestorm> hcarty: apparently thelema doesn't :]
<hcarty> I honestly think that batteries-specific tools for a transparent build environment would be suitable.
<hcarty> bluestorm: This is true. But for getting started, or a simple project, what's there is often "enough"
<bluestorm> hcarty: thelema wants a "transparent" build env.
<hcarty> Could the Batteries wrappers provide an automatic use of a myocamlbuild.ml, without needing to bring it in externally?
<bluestorm> hcarty: except getting some code included in Extlib is harder than hell
<thelema> hcarty: it doesn't extend well - myocamlbuild doesn't compose between requirements
<hcarty> orbitz: That is/was the goal of extlib.
<hcarty> thelema: Why is that?
<hcarty> Yes, the myocamlbuild.ml that comes with Batteries does most of the work for you, if not all of it.
<thelema> hcarty: true, I'm only considering it.
<hcarty> If you remove the IO system, it seems like it will be quite difficult to maintain upwards compatibility with full Batteries.
<hcarty> Are there unportable/platform-dependent pieces of Batteries now?
<hcarty> Does the IO system bring in external dependencies?
<hcarty> thelema: So more extlib than batteries?
<hcarty> orbitz: I don't know that a library should be based on what _might_ happen in the future for another library...
<hcarty> "little commitment" - such as?
<hcarty> thelema: That's my concern as well (no one uses the full Batteries). What are the issues with Batteries that aaa addresses?
<thelema> hcarty: the reason for "car" batteries is so that just plain "batteries" can refer to the project, and each of the two options has an easy name.
<hcarty> And suggestions for a better name are welcome.
<hcarty> You can't clone from that repo as I don't have the permissions setup properly yet. But you can download snapshots and browse the source.
<hcarty> If I continue to develop it and/or someone else wants to take part then I'll move it over to the forge.
<hcarty> In case there is an interest, I have a (temporary) location for the Gtk_light module here: http://0ok.org/cgit/cgit.cgi/gtk-light/
<orbitz> thanks hcarty
<hcarty> orbitz: http://caml.inria.fr/pub/docs/manual-ocaml/libref/index.html -- Each numeric type should have min/max values in either Pervasives or the appropriate module.
<orbitz> hcarty: i plan on it!
<hcarty> orbitz: pa_do is a wonderful tool, definitely worth checking out.
<hcarty> Without the extra goodies (syntax in particular), the library loses much of its flair.
<hcarty> I think the current "Car" Batteries should retain the title "Batteries"
<Yoric> hcarty: :)
<hcarty> Llama batteries to Camel batteries.
<thelema> hcarty: that's the plan.
<hcarty> thelema: Will any aaa-dependent code also work with Batteries?

2009-08-31

<Camarade_Tux> hcarty: :)
<hcarty> Camarade_Tux: And I updated the .tar.gz to include the proper _tags content -- thanks!
<hcarty> http://0ok.org/ocaml/gtk_light/basic_gui_test.ml is a simple test, with a basic demo of what is going on.
<hcarty> Alpounet: Thanks for the description :-)
<hcarty> Though I've been able to tie in the React library through callbacks.
<hcarty> The naming and general approach is taken more or less directly from Chris King's FrGui, minus the built-in "Fr"
<hcarty> http://0ok.org/ocaml/gtk_light/gtk_light.ml (and .mli) to browse the code
<Camarade_Tux> hcarty: I'm always spending hours in the lablgtk documentation, I'll check that :)
<Alpounet> hcarty, please keep the DSEL approach, it's so practical !
<hcarty> Camarade_Tux: I defined it, though it's not far from what is in lablgtk2
<Camarade_Tux> hcarty: you defined the 'hbox' function : 'a list -> unit or did it already exist in lablgtk?
<hcarty> Alpounet: The object stuff is hidden.
<hcarty> Alpounet: Yes. And, potentially, not so basic. With the hope that it will be simpler to compose the GUI than when using lablgtk2 directly.
<hcarty> Camarade_Tux: I hope to get it in GODI at some point, but that requires making GODI and cmake play nicely together.
<hcarty> Alpounet: It is a simple, very early/alpha, lablgtk2 wrapper.
<Camarade_Tux> hcarty: ok, that's what I thought :)
<hcarty> Camarade_Tux: No, they are part of PLplot. Not yet in GODI.
<hcarty> Camarade_Tux: Ah, wonderful, thanks
<Camarade_Tux> hcarty: but I don't have plot and plcairo, are they in godi?
<Alpounet> hcarty, what does gtk_light consist in ?
<hcarty> Camarade_Tux: Yes
<Camarade_Tux> hcarty: you're using godi, right?
<hcarty> Everything is just falling apart :-)
<hcarty> Wow
<hcarty> I wonder if that is a more recent addition to lablgtk2. What version do you have?
<hcarty> Nothing would be drawn in the window, but it should run then
<hcarty> You could comment out that section of the function - everything except the "true"
<hcarty> Camarade_Tux: Hmmm... odd
<Camarade_Tux> hcarty: Error: Unbound value Gdk.GC.create in basic_gui_test.ml
<Camarade_Tux> hcarty: yeah, irc backlogs are very useful :)
<Camarade_Tux> hcarty: was about to ask you how to compile ;)
<hcarty> Or .native if you prefer
<hcarty> Camarade_Tux: ocamlbuild basic_gui_test.byte should build a very simple demo
<hcarty> The conversation here generally swaps between a trickle and a flood.
<hcarty> Camarade_Tux: Not remembering conversations on #ocaml is why I am glad someone out there is silently logging this place...
<hcarty> It requires Batteries and lablgtk2
<hcarty> http://0ok.org/ocaml/gtk_light.tar.gz if you are interested
<hcarty> Camarade_Tux: I mentioned something about attempting it, and have talked about (but not followed up on) updating Chris King's FrGui
<Camarade_Tux> hcarty: did you already mention that here? it feels like I already said that...
<Camarade_Tux> hcarty: also, how did you do it?
<hcarty> Right now, windows, (v|h)boxes, sliders and drawing areas.
<hcarty> Any interest in a (very basic, alpha-level) Gtk_light module? It is a simplified wrapper around a bit of lablgtk2.
<hcarty> thelema, flux: Thanks. I'm using the Event module to signal the end of the thread (send a message when a window closes), so I don't think I have a need for the returned Thread.t at this time.
<thelema> hcarty: iirc, you can do some sorts of job control using the Thread.t
<hcarty> And it uses Batteries, of course.
<hcarty> Related to this, I now have a reasonably toplevel-friendly lablgtk2 + Cairo + PLplot setup. Now I just need to make the packaging nicer.
<hcarty> What use is a Thread.t? I'm new to threads in general, and OCaml threading in particular. Is there a reason to keep it around after creating a thread?
<Camarade_Tux> hcarty: \o/ for { x }
<hcarty> And nevermind regarding { Foo.x }. Apparently that works as well.
<hcarty> kaustuv: I'm not sure
<hcarty> I wonder what is does for { Foo.x }. I'm guessing it doesn't work.
<hcarty> OCaml is apparently getting a bit more sugar - { x } can now (CVS HEAD) be used in place of { x = x }
<hcarty> camlidl skips the CAMLparam/CAMLreturn/CAMLlocal macros, but I think it has its own library to safely work with OCaml values.

2009-08-29

<hcarty> sgnb: Yes, thanks. That's the other one.
<sgnb`> hcarty: froc?
<hcarty> And someone has a functional reactive web/javascript toolkit they posted to the mailing list some time ago.
<hcarty> There's React
<hcarty> The author is not able to maintain it at this time. It's mostly working, but not complete. I tried digging in to the code, but it was beyond what I was able to dedicate time to.
<hcarty> bluestorm: Yes, that is the one I mean
<bluestorm> hcarty: was there not a related Jane Street summer project ?
<hcarty> And I am working on a more friendly and OCaml-ish interface for PLplot.
<hcarty> Tux|Jedi: If you do, please let me know how it goes. PLplot is, at its core, a C library but I wrote the included OCaml bindings.
<hcarty> I've been playing with a simple-ish lablgtk wrapper, which is visually similar to what currently exists for FrGui, but minus the "Fr" and in general not as powerful.
<Tux|Jedi> hcarty: hehe :P
<Tux|Jedi> hcarty: will check that right after my vam-split visualization is done (which means after I've slept enough and stopped procrastinating...)
<hcarty> bluestorm: That would be nice
<hcarty> Tux|Jedi: They are not tied together yet, but I have written stand-alone GUIs with it. Threading is something I am currently unfamiliar with though, so I'll have to get a handle on that. Or someone else can :-)
<hcarty> Tux|Jedi: You can grab the latest PLplot svn to get most of the existing pieces :-)
<hcarty> orbitz: That would be wonderful (a cleaned up FrGui, which is looking less likely)
<Yoric[DT]> hcarty: that's great
<hcarty> With the idea being that the graphics window would run/update from a separate thread.
<orbitz> hcarty: as in how one would make a UI lib in a functional language, not just a weak wrapper?
<hcarty> Yoric[DT], flux: I'm (slowly) working toward making PLplot+Cairo+lablgtk a useful toplevel-friendly graphics combo

2009-08-24

<hcarty> You're welcome. Thank you for pointing out the bindings :-)
<hcarty> Binding a C library is often much simpler than binding a C++ library, at least with OCaml.
<hcarty> It says it requires the C interface as well (according to Google's translation...)
<hcarty> The author may prefer not to use the OO support in OCaml
<hcarty> I would guess that the bindings use the C interface. That is just a guess though.
<hcarty> Why is the lack of OO a problem? You could OOify it if you like.
<hcarty> The last update is quite recent
<hcarty> robocop1: I think the library has been mentioned here before. But I don't know of any OCaml bindings.

2009-08-19

<Camarade_Tux> hcarty: that's what I've written, I've just been surprised it wasn't there but I have to admit I'm readin online doc so it's maybe not completely up-to-date (or maybe too much)
<hcarty> I think it's there in Batteries as well, as I've used it in Batteries-based code.
<hcarty> Camarade_Tux: Filename.basename perhaps? That's where it is in the stdlib at least.

2009-08-18

<Camarade_Tux> hcarty: hehe :P
<hcarty> Wow... that really is faster.
<hcarty> Good night
<hcarty> Camarade_Tux: Thanks again! Looks like it works here.
<Camarade_Tux> hcarty: here, I have /ocaml/build/godi/godi-tools/work/godi-tools-2.0.10/console-src , go there and 'make opt', it will produce console/godi_console.opt
<hcarty> Camarade_Tux: Very nice, thanks.
<Camarade_Tux> hcarty: no, not at all, if you have godi, you can get one of the .tar.gz/.tgz (I'll find the good one in a second), extract it, cd, and make opt, that simple
<hcarty> Camarade_Tux: Interesting find. Is it difficult to build a native code version of godi_console?

2009-08-12

<hcarty> fun that is
<hcarty> Have fyb
<hcarty> Yes
<hcarty> Sorry about the mixup.
<hcarty> Ok, there is apparently a "float" function, but no "int" function.
<hcarty> That may be out of date then. It doesn't work on my 3.11.1 install.
<hcarty> Ah, ok sorry.
<hcarty> Those are constuctors. They create a value (Float f).
<hcarty> Those are not functions.
<hcarty> Oh sorry, I see what you are talking about.
<hcarty> Beelsebob: I don't see the example you are talking about.
<hcarty> Then yes, they are just functions with those names.
<hcarty> You have float_of_int and int_of_float.
<hcarty> Beelsebob: Do they?
<hcarty> Beelsebob: For example "string_of_int" is the int -> string conversion function in the standard library.
<hcarty> Beelsebob: If you use a type name like a function, it should be a function. Otherwise you'll get an error.
<Anarchos> hcarty to fix what if i can ask ?
<hcarty> yziquel: Not sure. I've run in to this before, and sprinkling "-fPIC" all over seemed to help fix it.
<yziquel> hcarty: http://caml.inria.fr/mantis/bug_view_advanced_page.php?bug_id=3924 is it this amd64/bsd specific bug?
<hcarty> yziquel: You probably need to add something like "-ccopt -fPIC"
<hcarty> Beelsebob: OCaml has classes, but no built-in type classes.

2009-08-03

<Camarade_Tux> hcarty: that'd be nice, thanks for the tip :)
<hcarty> Camarade_Tux: If you assume ocamlfind is available, I am fairly certain you can create a local findlib install target (in the build dir) and use that as a temporary installation/staging area for dependencies.

2009-07-25

<hcarty> raboof: There are a few options for parallel processing in OCaml. The most commonly used are probably jocaml, ocamlp3l and prelude.ml's parallel List and Array functions.

2009-07-15

<hcarty> julm: Good find.
<Camarade_Tux> hcarty: good to know
<hcarty> I don't know if/when it will be fixed though, as it has been around for quite a while.
<hcarty> Camarade_Tux: My understanding is that `foo is not supposed to be accepted, but is currently due to a bug somewhere in OCaml.
<hcarty> No, the Batteries license would not be changed a consortium membership. I certainly hope not anyway :-)
<hcarty> Modius: What do you mean by "casing convention"?
<hcarty> leondz: If other files are used, they need to be somehow explicitly referenced. They will not be picked up automatically by the toplevel.
<gildor_> thelema, erickt, hcarty: this kind of DNS problem can lead to some problem (but it should be something like no connectivity at all)
<gildor_> thelema, erickt, hcarty: maybe they are doing some work at night (in france) that make the server less responsive
<gildor_> thelema, erickt, hcarty: but ovh.net seems to have network trouble since a few day
<gildor_> thelema, erickt, hcarty: load average on the server is 0.00
<hcarty> I'm off for the night. Best of luck erickt, and thanks again for your reports and debugging.
<hcarty> Hooray for expanded testing!
<hcarty> Clearer and more consistent than the OCaml stdlib that is. And that is, of course, an opinion.
<hcarty> That said, the Batteries exceptions tend to be clearer and more consistent. Also, the Exceptionless modules are quite when you can use them.
<hcarty> erickt: Yes, the changes to raised exceptions are something of a barrier.
<hcarty> erickt: Ah, then don't let me stop you :-)
<hcarty> My guess is that it was an oversight. But it's possible that there is some other reason for this.
<hcarty> erickt: I havne't worked with the IO or Scanf modules, but if you post to the list and add a bug report it should be addressed.
<hcarty> erickt: Somewhat
<erickt> thelema or hcarty, either of you still around?
<hcarty> thelema: If you are able to continue on this please do. I have a few things to finish up this evening and likely won't be able to get back to this for a few days.
<hcarty> erickt: If this doesn't get resolved now, could you post the information and patch you have (with a note that it is not against the latest git) to this bug: https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=235&group_id=17&atid=151
<erickt> ping hcarty
<hcarty> We unfortunately don't have the equivalent of perltidy for OCaml.
<erickt> hcarty: mailed to batteries-devel
<hcarty> A safe first step should be GZip -> ExtGzip and InnerGZip -> InnerGzip. We can move file contents around after that, if there's reason to do so.
<thelema> hcarty: thanks for finding that. Ok, let's go ahead with renaming it
<hcarty> Commit ac7abc14658150f3065cbe03c54107dcd4996943 - according to the commit comment, it was a style choice. The module was originally called ExtGzip.
<hcarty> In that case, innerGzip.(ml|mli) is probably a reasonable name. Though that could break whatever code depends on it.
<hcarty> thelema: Ah, ok. That would make sense.
<thelema> hcarty: if that was reasonable, why would innergzip exist in the first place?
<hcarty> erickt: Not that you should do have to do all of that :-)
<hcarty> Though perhaps innerGZip.ml should be included as a module in extGzip.ml and hidden by extGzip.mli.
<hcarty> I was thinking innerGzip. I'm not sure which would be appropriate.
<hcarty> erickt: Sounds reasonable, as long as the build holds together.
<hcarty> erickt: Or, rather, "module Gzip = Gzip" in Legacy and "module Gzip = ExtGzip" in the main Batteries module.
<hcarty> erickt: extGzip.* and "module Gzip = ExtGzip" would probably be best. The other ExtFoo modules are named that way to match upstream.
<hcarty> erickt: Thank you very much for your detailed testing and reporting on this.
<erickt> hcarty: that seemed to work
<hcarty> I suppose this could be an issue on Windows as well.
<hcarty> erickt: The rename could be to extGzip.*, which would keep with the existing ExtFoo naming convention used in the rest of Batteries. Regardless, it would be wonderful if that would work.
<hcarty> erickt: Thanks for trying. It was something of a stab in the dark :-)
<erickt> and hcarty, that rename doesn't fix it
<hcarty> Or, ever I suppose.
<hcarty> thelema: It seems like this is either a build system bug (ocamlbuild or myocamlbuild.ml) or a bug in ocaml(c|opt). It really should not be looking for gzip.cmi in the build tree at that point.
<thelema> hcarty: no apologies necessary - that change shouldn't have broken anything.
<hcarty> And my apologies for commiting a compilation-breaking change.
<hcarty> Could you try changing the "module Gzip = Gzip" lines to "module Gzip_original = Gzip"?
<hcarty> Reported breakage is quite appreciated.
<hcarty> erickt: Care to try a little experiment? :-)
<hcarty> erickt: Wonderful!
<hcarty> The Batteries Gzip does not (or did not at the time of the commit) cover the full range of functionality in the parent module
<erickt> hcarty: that was me! :)
<hcarty> Without that alias, there is no way to reach the original Gzip module under default Batteries use.
<hcarty> thelema: That is rather confusing though, since the gZip.ml code has not been referenced at that point in the file. So it should not, as I understand, interfere.
<hcarty> thelema: It seems that another user tracked down the Batteries OSX problem to a specific commit. I added an Gzip module alias/entry to the Legacy module and that seems to be what kills it.

2009-07-14

<thelema> hcarty: pong
<hcarty> thelema: ping

2009-07-13

<hcarty> And free can be very appealing, whether justified or not.
<hcarty> julm: Of course, the alternative costs money :-)

2009-07-10

<hcarty> erickt: Those issues are much less likely to get lost that way.
<hcarty> erickt: Good finds on your last few posts to the Batteries mailing list. Could you add these to the bug tracker?

2009-07-08

<hcarty> With "type t = Foo of int * int" you need to do "match x with Foo (a, b) -> ..."
<hcarty> You can with "type t = Foo of (int * int)"
<hcarty> AxleLonghorn: One difference I'm aware of is that, without parens in the type definition, you can't do "match x with Foo t -> ..."

2009-07-02

<C_Tux> hcarty: he, ok, I would maybe have been to the doctor otherwise ;p