2012-03-30

<hcarty> I tried uploading cmdliner 0.9.1 but oasis-db complains that the _oasis format isn't supported
<hcarty> gildor: Do you have a rough idea of when oasis-db's package upload will support the 0.3 _oasis format?
<hcarty> mrvn: valgrind/gdb? And/or lots of printf calls.

2012-03-27

<hcarty> The Lwt solution is very short and simple, but the syntax is horribly ugly unless Lwt's syntax extension is used.
<Lor> hcarty, just the fact that it doesn't integrate well with pre-existing code
<hcarty> Lor: What makes it a hack?
<hcarty> I keep looking for excuses to try Lwt for something other than a simple toy. Perhaps this will be that excuse.
<hcarty> avsm: :-)
<avsm> hcarty: Lwt, it's the only way to UNIX! :-)
<hcarty> d3z, chambart: Thank you both
<hcarty> chambart: That said, if it's easy enough to use and I can restrict its effect then I'm willing to give it a shot.
<hcarty> chambart: I knew Lwt provided something, but I'm not sure if I'm ready to Lwt-ize my code yet :-)
<chambart> hcarty: it depends on your notion of easy, but lwt provides what you need ( it is easy if you know lwt )
<hcarty> I'm just a little concerned that there may be a good reason the pid is not returned from those functions.
<hcarty> If open_process_full returned a pid along with the stdout/stdin/stderr I'd have everything I need.
<hcarty> stdlib/Batteries provide all but the last component in an easy-to-use form.
<hcarty> My needs are fairly simple. I want to start a process, capture its output (stdout and stderr), killing the process if it takes too long to complete.
<hcarty> d3z: Maybe a bit harsh, but also maybe a bit appropriate.
<hcarty> d3z: Thanks. I'll take a look at ocamlnet's Shell module. I forgot that exists...
<hcarty> Does anyone here know/have a guess about why the Unix.open_process* functions do not return the pid?
<hcarty> I'll dig into unix.ml
<hcarty> It looks that way, browsing through the code
<hcarty> thelema_: Ok, will do. I need to be able to kill the process - there doesn't seem to be a straightforward way to do that with the current implementation.
<thelema_> hcarty: probably not - you're welcome to make an improves open_process_full and send t to us for inclusion
<hcarty> thelema_: Or would I need to take the BatUnix/Unix code and create my own?
<hcarty> thelema_: Is there a way to get the pid of a child process created with BatUnix.open_process_full?
<hcarty> mrvn: You could try ocamlbrew for all your custom OCaml building needs. It won't add a prefix/suffix to the executables, but it will put everything under an isolated directory.

2012-03-22

<hcarty> That should be correct. findlib should handle the details.
<hcarty> _andre: Yes, assuming you're asking about another library that uses uint
<hcarty> That answers that question.
<hcarty> And the ZeroMQ bindings use uint
<hcarty> _andre: But I can use ZeroMQ directly, without referencing uint
<_andre> hcarty: i can use uint fine from the toplevel too
<hcarty> _andre: I run into this sometimes and I can never remember the specifics of how to fix it... but I can use ZeroMQ + bitbucket's branch of uint from the toplevel.
<hcarty> Lack of historic baggage can be a fun thing to have :-)
<hcarty> I'm finally trying out some of the ocamlbuild newness on a new project
<hcarty> pippijn: I have pkg_* all over :-)
<hcarty> It's what is/was commonly used before ocamlfind support was added to ocamlbuild
<hcarty> pippijn: I think that syntax requires a custom myocamlbuild.ml
<hcarty> pippijn: The package() pieces are for findlib packages, not modules being referenced directly
<hcarty> pippijn: The syntax I used requires the -use-ocamlfind flag, and possibly OCaml 3.12.1
<pippijn> hcarty: I found it
<pippijn> hcarty: how does that syntax() package() stuff work?
<hcarty> In _tags: syntax(camlp4o), package(some-syntax)
<hcarty> I could get away with a Makefile and no _tags if ocamlbuild supported findlib'd syntax extensions on the command line
<hcarty> pippijn: That's likely what I will do, along with a clean target
<hcarty> Given that, I would like to avoid the added (admittedly minor) complication oasis adds until it would offer a sifnificant benefit
<hcarty> pippijn: This project is simple enough that a one-line _tags file is otherwise sufficient
<pippijn> hcarty: try oasis
<hcarty> Oh well, I suppose a few extra typed characters isn't that bad. Or a few extra characters in a Makefile
<hcarty> pippijn: I was hoping to avoid a custom myocamlbuild.ml file. I can do everything else I need from _tags.
<hcarty> Is it possible to replace ocamlbuild's -use-ocamlfind flag with something in _tags?

2012-03-21

<thelema_> hcarty: this handles multiple things, 1) oasis setup from scratch (by simulating a fixed repo in a single file) and 2) fast install of many packages, such as for what the barbra people want
<hcarty> With the warning that 2.0 is not final, so things may change/break between now and release
<Drakken> hcarty yep.
<hcarty> Drakken: Does the same suggestion you gave thomasga work?
<hcarty> thelema_: Very nice. This is, I would guess, to support cases like installation of all dependencies for a project?
<hcarty> yezariaely: utop has the additional benefit, beyond arrow keys and improved editing, of providing context-appropriate tab completion.
<hcarty> Ptival: ocamlnet provides (Fast)CGI support

2012-03-20

<Drakken> hcarty I hope you're right, but I haven't figured it out yet. I checked out the expansion of EXTEND, but that's all expr nodes, inside a "do" expression. No str_item nodes, and no splicing.
<hcarty> Drakken: I haven't done anything with camlp4 in a while, but it seems like that should be fairly straightforward.

2012-03-19

<thelema_> hcarty: ah, yes. The loggers should flush when they log.
<hcarty> I'm thinking of it specifically for logging and being able to force flushing of the logging output. But I'm leaning toward that being better handled at the logging code level, rather than the output level.
<hcarty> thelema_: I'm not sure what the proper interface would be, or if there really is a good, general way to do this.
<thelema_> hcarty: not that I know of. How would you like that to be handled?
<hcarty> ospec looks like an interesting tool, but I haven't had an opportunity to build and try it out
<hcarty> _andre: You could package that with oasis and add it to oasis-db as well :-)
<hcarty> _andre: I don't have ospec, so the build fails
<hcarty> Let me see what I can do from the admin interface
<hcarty> _andre: Thank you! Unfortunately, I'm not sure how to force your version over the one I uploaded
<hcarty> thelema_: For example, forcing Batteries' stdout to be unbuffered
<_andre> hcarty: ok, uploaded version 1.0.2
<hcarty> thelema_: Is it possible to force unbuffered output for an arbitrary Batteries.IO.output?
<hcarty> _andre: I don't remember... I think it may default to bytecode
<hcarty> _andre: Also, be sure to include the build system oasis generates, otherwise the package will not be installable through odb
<hcarty> _andre: That will make both versions selectable through oasis-db
<hcarty> _andre: If the name in the _oasis file is the same but the version is newer then you can use the same upload interface you did previously
<_andre> hcarty: should i just upload as if it were a new package or is there a way to "edit" a previous upload to add a new version?
<hcarty> _andre: Cool, thank you
<_andre> hcarty: doing it right now
<hcarty> _andre: That sounds like a reasonable fix. Have you uploaded a newer version to oasis-db?

2012-03-16

<_andre> mrvn, hcarty: got it to work moving Str_conv to the parent module, Uint
<hcarty> _andre: Yes, 'uint' would need to be used, as opposed to 'uint.unit64', etc.
<hcarty> Ah. I think you would either need to pack the modules, or put everything into a Uint module, with other modules available under that.
<hcarty> Ah, ok
<hcarty> _andre: Does the failure happen when the library is used, or when the library is built?
<_andre> hcarty: zeromq only uses uint.uint64 it seems
<hcarty> _andre: With that version (bitbckt's oasis branch) I was able to build uint and zeromq with odb
<hcarty> _andre: I'm fairly certain it was from here - https://github.com/bitbckt/ocaml-uint/tree/oasis
<hcarty> _andre: But I need to find which fork I took that .tar.gz from...
<hcarty> _andre: It worked in the version I uploaded on oasis-db
<lorill> hcarty: thanks. I'll see what I can do with a module
<hcarty> In that case it's talking about allowing cross-library references in ocamldoc
<hcarty> lorill: It's not directly related, but it does involve modifying ocamldoc - http://caml.inria.fr/mantis/view.php?id=5533
<hcarty> lorill: There has been some discussion around ocamldoc on the bug tracker recently. Changes may be more readily accepted if you can present something in plugin form first.
<hcarty> lorill: That looks very nice
<hcarty> Excellent! Please let us (#ocaml) know how it goes.
<hcarty> mehdid: Good luck tweaking it to your needs - or tweaking your code to ocp-pack's requirements :-)
<mehdid> hcarty: it looks like what I want, thanks!
<hcarty> mehdid: Does ocp-pack do what you want? http://www.ocamlpro.com/blog/2011/08/10/ocaml-pack-functors.html

2012-03-15

<thelema> hcarty: ok, batLog.Easy now supports changeable output channels.

2012-03-14

<hcarty> Which is kind of unfortunate given all of the cool things they can do.
<hcarty> I have a few syntax extensions I still use in certain places but I've been trying to avoid them more and more.
<hcarty> That's a large part of why I didn't go with Bolt
<hcarty> thelema: Agreed
<hcarty> Yes, mine is very pretty for my intended use, and yours is very pretty for yours
<hcarty> :-)
<hcarty> The BatLog test that is
<hcarty> Similar to your test case
<hcarty> Yes
<hcarty> Or yes, being very careful with link order
<hcarty> I can, but that requires functorizing everything else over that module.
<hcarty> thelema: Yes, or command line argument or however else it would be customized.
<hcarty> Sorry - not re-init, but init the first time with some runtime-determined output
<hcarty> Or are you asking if that's what I'm looking to do?
<hcarty> Make_lev/Easy doesn't have a way to re-init
<hcarty> thelema: That is something that I would like to have, and part of why my implementation has an init function
<hcarty> thelema: Is it possible to, at run time, change the output for a logger generated with Make_lev?
<hcarty> In which case 20:12/21:02 is valid
<hcarty> thelema: Or 20:12/12:20 for that matter
<adrien> hcarty: I wanted to write it too but didn't since it wasn't a proper date (yet!)
<hcarty> thelema: 2012/1220 could as easily be 2012/12:20
<hcarty> adrien: 2012/2102! Not a real date, but it is a palindrome (dateindrome?)
<hcarty> I'd use CalendarLib for any printing/parsing of date formats, so that's not the end of the world. The current BatLog date format just doesn't seem as readily human-parsable as ISO 8601 (or whatever YYYY-MM-DD is...)
<hcarty> The two differences you pointed out are bothersome but minor. I think I'm getting a better picture of how to use BatLog.
<hcarty> I would like to use SomeLog.Easy.log everywhere in a program, enabling/disabling it from a some single point.
<hcarty> How would you disable BatLog.Easy?
<hcarty> thelema: I'm not sure if I would switch to BatLog from my implementation or not.
<thelema> hcarty: does the new interface added to BatLog satisfy your needs?
<thelema> hcarty: it's much more convenient for my common use
<hcarty> thelema: printf'ing the code sounds like a good idea
<thelema> hcarty: perl doesn't need printf because of its string interpolation, but here's the interface I'm providing:

2012-03-13

<hcarty> Sounds good to me
<hcarty> thelema_: You're more than welcome to use my code if it's helpful
<thelema_> hcarty: I updated batLog with a little more, but haven't had a chance to work on the leveled-functor
<hcarty> thelema_: gist updated. I'm curious to see what you end up with on your end.
<hcarty> I made the change locally and will update the gist later. Off for a bit now - we can pick this up later if you like.
<hcarty> thelema_: I like default_level more. Thanks for the suggestion :-)
<hcarty> Or at least is more flexible.
<hcarty> max_level because the default is meant to be the most restrictive. But default_level probably makes more sense.
<hcarty> thelema_: It could be default_level
<hcarty> Yes
<hcarty> thelema_: Yes, that's the issue I ran up against
<hcarty> Perhaps a combination approach - one way to disable everything less than n; another to disable specific levels
<hcarty> s/But if//
<hcarty> I don't know which approach is best
<hcarty> If each logger is defined independently then each one needs to be enabled/disabled on its own.
<hcarty> thelema_: I can see that. But if the effort required to maintain each additional level scales more gracefully with a linear set of levels
<hcarty> thelema_: I was away for a bit, but here is a functorized version of what I pasted earlier - https://gist.github.com/2031221
<hcarty> print/get_output/fatal seem like common enough names that they could cause confusion.
<hcarty> Or objects work too
<hcarty> Maybe the default implementation should be in a submodule
<hcarty> Is a user expected to "open (Bat)Log"?
<hcarty> thelema_: set_output?
<hcarty> thelema_: How do you enable/disable? I see creation, but no enable/disable.
<thelema_> hcarty: batLog has no need of "level". Just enable and disable ... hmm, I thought I had put in a nicer way to disable loggers... I guess the best way to do that is with setting the output to null_output (or whatever it is from BatIO)
<hcarty> thelema_: Perhaps the 'level' too? Although I think that could be solved with currying.
<thelema_> hcarty: unit -> string it is.
<hcarty> thelema_: unit -> string is fine by me
<hcarty> But then the prefix logic needs to be included in each debug.print call
<hcarty> So that they can be formatted differently or replaced entirely
<hcarty> Something in place of the date/time
<hcarty> Well, etc = filepos in this case
<hcarty> The full prefix, rather than just date/time/etc.
<hcarty> thelema_: Is it possible to have a custom prefix?
<thelema_> hcarty: batLog doesn't consider the different logging levels as primitive, but as created by generating different loggers for each level and then enabling/disabling them.
<hcarty> thelema_: This is what I had in mind for a simple logging module - https://gist.github.com/2031221
<hcarty> thelema_: What is the optional fp argument used for?
<thelema_> hcarty: it's simple but should be quite flexible
<thelema_> hcarty: try BatLog - worst case I'll spin it off to a odb-able package
<thomasga> hcarty: the only available "documentation" is the .ocp files in typerex. We use it internally a lot, but it is not yet ready to be used widely (ie. user doc is missing, the syntax of .ocp is still changing, etc). So if you are courageous and want to give it a try, I will be happy to help (otherwise you can wait for a proper release)
<hcarty> I'd rather avoid that if possible, but it may not be at this point.
<hcarty> thelema_: Ok, thanks. I'm trying to pick a logging library/module. I do'nt need much, so I may end up with something custom.
<thelema_> hcarty: I hope that BatLog will stick around longer, and would like to deprecate batLogger. That said, maybe they both belong in separate libraries
<hcarty> thelema_: What is the status of BatLog vs BatLogger? Is one better/more likely to stick around?
<Ptival> hcarty: I don't think so, there is a paper about it in French, and examples ocp files in typerex's sources, anyway thomasga will tell you the actual status
<hcarty> Ptival: Are there examples and documentation available? How does it compare with oasis?
<Ptival> hcarty: OCamlPro's build tool, which you can find included with typerex
<hcarty> thomasga: What is ocp-build?

2012-03-12

<hcarty> flux: You can, however, have multiple ocamlbew installs going at once, as long as they are pointing at different build and install directories.
<hcarty> flux: Although it could be possible in some cases to install some of the libraries in parallel.
<hcarty> flux: ocamlbrew only supports as much concurrent compilation as OCaml itself does. Which, unfortunately, means none.

2012-03-11

<flux> hcarty, does ocamlbrew support concurrent compilation?

2012-03-06

<hcarty> gasche: As one who writes (obviously minor!) pieces of software in OCaml, the updates on new material and reminders of older work are nice to have.
<gasche> hcarty, you're welcome; do not hesitate to post things yourself if you have interesting stuff and it lacks activity
<hcarty> gasche: From another lurker - thank you for the reddit posts, including the older articles.
<hcarty> What's OCaml? (outside of any French university)

2012-03-02

<hcarty> I don't either. It could be a helpful indicator of network/corruption issues... but that isn't ocamlbrew or odb's job.
<hcarty> I agree. I won't have a chance to work on it for a little while. If no one submits a patch before I get time for ocamlbrew then I'll at least implement that much.
<hcarty> And the check would only be on the OCaml archive, as that is the only thing installed by ocamlbrew which includes any kind of hash data.
<hcarty> Indeed. That, however, will definitely be left up to others to patch. I don't have (easy) access to non-GNU md5sum binaries.
<hcarty> Then check $?
<hcarty> grep ocaml-3.12.1.tar.gz MD5SUM | md5sum -c --status -
<hcarty> thelema: I think I may have something that works, but yes that may be the result.
<thelema> hcarty: well then push it back on those asking for it to write it for you.
<hcarty> thelema: I'd rather avoid hard-coding anything as the script is intended to work with more than one version of OCaml
<hcarty> That may be more shell trickery than I want to get into. If you're grabbing a .tar.gz, get MD5SUM, md5sum -c on only the relevant archive line, parse result
<hcarty> thelema: I'm a bit reluctant to do something similar for ocamlbrew. I could for the default packages I suppose...
<thelema> hcarty: odb now supports md5=<ms5 checksum> for tarballs. It's not any real security, but it was maybe 6 lines of code, so...
<hcarty> thelema: Any thoughts on the request for signature checks in odb.ml and ocamlbrew?
<hcarty> thelema: Ah! Thanks. I was missing the 'a t piece.
<thelema> hcarty: ^^^
<hcarty> Which isn't the most helpful error
<hcarty> val ( --> ) : 'a t -> key -> 'a is not included in val ( --> ) : 'a t -> key -> 'a
<hcarty> If I tweak it a bit -- include Map.Make(Int) include Infix -- then I get further, but still run into issues.
<hcarty> thelema: Yes
<hcarty> That's a bummer.
<hcarty> "include Map.Make(Int).Infix" does not work for me
<hcarty> thelema: Not bad. I don't know if there is a similar workaround for the BatMap.Infix case, where the Infix module does not have its own functor.
<thelema> hcarty: the previous can be simplified to this. := is making more sense to me now after having used it a bit.
<hcarty> Good point - that is the case for the Bigarray example I pasted earlier
<hcarty> It's strange that Foo := Module_like_foo removes Foo
<hcarty> thelema: I agree. It's strange that Foo
<hcarty> thelema: Thanks for sharing!
<hcarty> I don't see an obvious way to simplify that
<hcarty> thelema: A little convoluted, but it makes sense.
<thelema> hcarty: I think I solved my problem with this: https://gist.github.com/1960458
<hcarty> thelema: If you do find a solution I would be very interested in hearing it
<hcarty> From the result of BatMap.Make that is.
<hcarty> thelema: I'm not sure how possible it is to adapt that to, for example, remove Infix from BatMap.Make
<hcarty> thelema: http://vpaste.net/jbavq -- An example removing Array* from Bigarray
<thelema> hcarty: how to remove it entirely?
<hcarty> thelema: I don't see a way to rename/replace a module without removing it entirely.
<adrien> hcarty: tmux with C-a as a prefix ;-)
<hcarty> adrien: screen?
<thelema> hcarty: hmm, maybe you're right...
<hcarty> I'm not sure if you could do the same thing with a functor and still be able to access the original submodule
<hcarty> My work-around for extending Bigarray was along the lines of "include Biggary : module type of Bigarray with Array1 := Array1"
<hcarty> I ran into the same issue a while ago trying to extend the Bigarray submodules. With a functor it would be even more complicated I would think
<hcarty> thelema: It's not unreasonable, but I don't think it's very easy (or maybe not possible?) to do directly

2012-03-01

<rgrinberg> hcarty: ya I'll give odb a try as well. It has less stuff than godi but it does seem to have all of what i care about
<hcarty> thizanne: Beat me to it :-)
<hcarty> rgrinberg: You can take a look at odb as well
<hcarty> That or "let open Lexing in" as the first line in all three. It may make things easier to manage if you shift code around.
<hcarty> This syntax was added in 3.12.0, along with Module.(...) which limits the open to within the ( )
<hcarty> That limits the scope of the open module
<hcarty> If you only use it in a function or two then you can use "let open Lexing in" in those functions
<hcarty> What version of OCaml are you using?
<hcarty> pippijn: That's getting much more reasonable :-)
<hcarty> pippijn: That would be better, yes.
<pippijn> hcarty: is it good to "let iter = List.iter" if I just use 1 or 2 functions from a module?
<pippijn> hcarty: the ones I have open now are very frequently used
<hcarty> Or value
<hcarty> pippijn: For best practices - lots of globally open modules is generally frowned on. It makes it more difficult to track down the origin of a function.
<hcarty> pippijn: As far as formatting goes, the pasted code looks good initially.

2012-02-29

<hcarty> thelema: Or a --prefix flag for odb that does not affect the library installation step.
<hcarty> thelema: A brew flag could work. Or a change to the --have-perms flag so that --prefix is still used, pointing to the parent of bin/ocamlc
<hcarty> Drakken: Because it's spelled 'List.fold_left' :-) Or you can use BatSet.S.of_enum
<thelema> hcarty: Maybe a `brew` flag that works similarly to the godi flag to just disable DESTDIR
<hcarty> thelema: But if OCAMLFIND_DESTDIR is set then the packages install to that location rather than site-lib
<hcarty> thelema: Yes
<thelema> hcarty: don't you want the prefix and the ocamlfind dest to be the same for ocamlbrew - both in the brew dir?
<hcarty> thelema: It's needed in order to install modules to ocamlfind's default site-lib. Otherwise packages end up in another location.
<thelema> hcarty: okay, we can add that if it's what you need for ocamlbrew
<hcarty> thelema: But I don't think odb has the means to say "pass --prefix to configure but don't set any ocamlfind paths during installation"
<hcarty> thelema: Binary installation to a specific location works with (many?) packages in oasis-db
<hcarty> thelema: I was trying to minimize the size of the .mli to minimize the number of places I need to make changes when code is updated
<thelema> hcarty: binary install in a specific dir will require support from package installers - with oasis, --prefix does this, which is supported in odb. with others - it varies by package
<thelema> hcarty: just use ocamlc -i to produce batteries.mli, no?
<hcarty> batteries.mli that is
<hcarty> thelema: The issue came up in a local Batteries-based stdlib; Trying to create the equivalent of a batterie.mli has caused quite a bit of trouble
<hcarty> thelema: I don't have a minimal example, but the fix appears to be a generous helping of "with type t = Foo.t" in the .mli
<hcarty> thelema: On a different front - Do you have any ideas on how to best allow odb to work with ocamlbrew so that packages are installed in the default site-lib and programs/documentation/etc are install under ocamlbrew's root?
<hcarty> I'll try to come up with an minimal example
<hcarty> It comes from some combination of using 'module type of' and a .mli
<hcarty> thelema: Not intentionally, but I think that may be what is happening
<thelema> hcarty: that is odd.
<hcarty> This is an odd type constraint error: type 'a t = 'a String_map.t is not included in type 'a t = 'a String_map.t

2012-02-24

<hcarty> thelema: Thanks for testing. I'll respond to the announcement email on oasis-devel.
<thelema> hcarty: I'll test it on mine
<hcarty> thelema: I uploaded the 0.3.0~rc1 release to oasis-db/odb unstable, but it sadly does not work on my system.
<hcarty> thelema: Ok thanks. I'll take the conversation there.
<thelema> hcarty: you'll get better response by email
<hcarty> gildor: I'm unable to get oasis 0.3.0~rc1 to build on my system. It insists on looking under /usr for OCaml's tools and libraries, but there is no OCaml installation there.
<hcarty> _habnabit: If the third doesn't use xmlm then I think OCaml will skip linking it in.
<hcarty> Maybe y.*
<hcarty> _habnabit: Do you need to refer to more than just y.ml?
<flux> hcarty, well, it might actually even help, there is more information there to be extracted from the header files :)
<hcarty> It also doesn't help that Qt is not pure C++ which is not C
<hcarty> iZsh: Until someone wants the binding enough to make and support it themselves it's not likely to happen.
<hcarty> The stdlib was made (Batteries)
<hcarty> iZsh: Asking for it, but not making it :-)
<iZsh> hcarty: ppl has been asking for a qt binding for years. as much as a better std library ;)
<hcarty> But there has apparently not been enough demand to get over the challenge of mapping C++/Qt to OCaml.
<hcarty> iZsh: I think OCaml has a few partial Qt bindings
<hcarty> iZsh: C++ is likely part of the blocker there
<ulfdoz> hcarty: But it got better since java 5.
<ulfdoz> hcarty: Depends, there are some very old APIs, which really give that feeling (e.g. JDBC).
<hcarty> ulfdoz: My understanding is that Java is nothing but boilerplate :-D
<hcarty> Where does type-conv live now? I would like to fix it on oasis-db so that it builds against development versions of OCaml.
<hcarty> I use |> all the time - I find it makes the code more readable. And |- more rarely, but that's not as much of a readability aid.
<hcarty> thelema: But not adding... much :-)
<thelema> hcarty: except they keep modifying the stdlib
<hcarty> iZsh: The core INRIA folks have made it pretty clear that they want to leave library development to the community
<hcarty> iZsh: Well that's good to hear :-)
<iZsh> hcarty: everything relies on Batteries nowadays ;)
<hcarty> It's also nice to see that other people, even if only a few of them, are uploading packages to oasis-db
<thelema> hcarty: sure. This shouldn't be too hard, except for maybe the testsuite, and even that not too bad.
<hcarty> The next step is to have Batteries use a full-blown oasis build system. Then the cycle will be complete.