2011-03-24

<hcarty> I'll see if it's something I can fit in
<hcarty> thelema: Ok, thank you for your time
<hcarty> Printed twice
<hcarty> Yes
<hcarty> thelema: Yes - "Installed package is not available to the system"
<thelema> hcarty: hmm, and it's saying that camomile isn't installed?
<hcarty> thelema: 0.8.1
<thelema> hcarty: ^^^
<hcarty> And "ocamlfind remove camomile -destdir ~/.odb/lib" works
<thelema> hcarty: hmm, odd.
<hcarty> thelema: Yes, both variables are set
<hcarty> "Problem with installed package:..."
<hcarty> And now it's not finding camomile after it's installed - another instance of the same versioning issue maybe?
<hcarty> thelema: line 101 - "as x" is unused
<hcarty> Probably the Calendar library to start out.
<hcarty> You're welcome. I'll see if I can put together a package or two.
<hcarty> thelema: Thank you!
<hcarty> thelema: This looks more promising. Camomile is building now.
<hcarty> thelema:
<thelema> hcarty: try the newly pushed version
<thelema> hcarty: back to odb now...
<hcarty> thelema: Any suggestions for tracking down why odb.ml is missing dependencies?
<thelema> hcarty: ah, not so good at reading ubuntu version numbers. ok.
<hcarty> thelema: If the version is 1:3.0.1-5build2, that looks like upstream 3.x
<hcarty> chewbranca: You have a newer verison (3.x) than what the code expects, from what it sounds like
<hcarty> thelema: Closer. It grabbed batteries, but didn't automatically download and install camomile
<thelema> hcarty: I just pushed a fix for that maybe 10 minutes ago
<hcarty> Any suggestions on where to start looking for the cause?
<hcarty> thelema: "ocamlfind list" only lists the stock packages, no Batteries, Camomile, etc.
<hcarty> thelema: I just tried odb.ml with a fresh OCaml 3.12.0 and findlib 1.2.6 install. "ocaml odb.ml batteries" says that it is already installed.
<hcarty> orbitz: Interesting ... I tried to search on Google for LiML and didn't find anything, but the first link was to Links, which is apparently web programming language written in OCaml
<thelema> hcarty: it does reward benchmark writers, though, as it compiles damn efficiently
<thelema> hcarty: it's such a pain to program anything significant in
<hcarty> thelema: OCaml saved me from diving in to Ada. I may give it a shot eventually, but it seems extremely verbose.
<hcarty> orbitz: It's nice that OCaml allows that :-)
<hcarty> orbitz: They can be helpful in reducing code duplication
<orbitz> hcarty: yeah i'm slowly gettign there. I spent the first year of ocaml dabbling writing it like Python
<hcarty> orbitz: I found functors baffling when I started with OCaml... and at some point they clicked.
<joelr> hcarty: i haven't used mpi but zeromq has excellent documentation
<hcarty> joelr: If you've tried both - how does (OCaml) ZeroMQ compare with (OCaml) MPI?

2011-03-23

<joelr> rproust: docs show examples with 1 type that's a module, though. do i (as hcarty said) need to wrap classes in modules then?
<hcarty> Functions are parameterized over all of these, as of 3.12.0
<hcarty> Classes are parameterized over values (and maybe classes?)
<hcarty> Functors are parameterized over modules
<hcarty> I think Jason Hickey's book has a decent chapter on OO vs modules
<joelr> hcarty: i'm stuck with classes as these are generated from thrift-ocaml
<hcarty> In that case you probably want to use functions and/or some OO pieces
<hcarty> joelr: If you want to use functors, the classes would have to be wrapped in modules (and their names would have to start with lower case letters)

2011-03-17

<adrien> hcarty: I need to take some time to remember the EFL guys to have a nice machine-parseable interface (for bindings generation)
<adrien> hcarty: ;-)
<hcarty> adrien: I wish I had time to do so :-)
<adrien> hcarty: yeah, definitely, you feel like checking the guts to see how it manages memory? :P
<hcarty> adrien: I was looking through the EFL 1.0 docs. It looks nice and worth binding.

2011-03-13

<hcarty> With some test/demo/comparison code
<hcarty> It's possible that the speed could be addressed. Again, if I have time later I will write up a proper response for the list.
<hcarty> I don't know how much slower in real code, but I tested the two a while ago and found that there is a difference in microbenchmark-like code.
<hcarty> Regarding the current mailing list thread on a possible replacement for Enum - in my experience, Seq works very nicely as an enum replacement, but it is slower than the Enum module.
<hcarty> thelema: Thank you as well. I'm glad to have contributed something :-)
<hcarty> thelema: There is. I have to leave now, but if I have time later this evening I'll try to get a test patch together.
<thelema> hcarty: is there an interface from an arbitrary arrat, or can it only read from argv
<hcarty> thelema: I'm not sure how to go about writing test cases for this module.
<hcarty> thelema: http://pastebin.com/PQ4KUvf3 -- This fixes a (very) small documentation typo in the same file which I noticed while editing. It may not be worth bothering with the patch in this case...
<hcarty> thelema: http://pastebin.com/LwFn5L5w -- This adds the function and docs, no test
<hcarty> thelema: Ok. Definitely a proper git'd patch. I'll likely pastebin it, unless something comes up and I can't finish it now
<hcarty> thelema: Ok, I'll put a patch together. Should I email it to you?
<thelema> hcarty: a quick patch (maybe even with test) or moving the issue to the wishlist on the wiki
<hcarty> The docs are about bytecode primarily, but they may still be useful - http://cadmium.x9c.fr/downloads.html
<hcarty> If yezariaely comes back, I the OCaml Java compiler/project has some documentation on OCaml's internals
<hcarty> thelema: I can - what follow up would you like?

2011-03-10

<hcarty> Maybe namespace support can help with this
<hcarty> I'm wondering about this outside of Batteries as well - extending any submodule becomes messy.
<hcarty> Adding a map function to Bigarray.Array1 requires reproducing the entire contents of the Bigarray module as BatBigarray, for example
<hcarty> thelema: If the submodules were stripped, then each one could be handled separately. So there would be no need (or significantly less need) to copy and paste code
<hcarty> thelema: But in order to extend a module like Bigarray.Array1, you need to copy and paste all of the signature and contents of the Bigarray module
<thelema> hcarty: ? stripping submodules? we do our best to only add to stdlib
<hcarty> Once Batteries moves to requiring OCaml >=3.12.0, this kind of stripping of submodules could make updating Batteries to match new stdlib changes a bit easier.
<hcarty> Is there a simpler way than this to strip modules from a module? http://pastebin.com/AjMSWfDQ
<hcarty> EM03: Doesn't seem to build here (Ubuntu 10.04 64bit), but I haven't put much time in to it
<hcarty> Oh cool - I didn't know that
<EM03> sitll works though hcarty :)
<hcarty> EM03: A very cool project none the less
<hcarty> EM03: Yes, unfortunately (a) I think it's written in C++ and (b) I don't think it's maintained
<hcarty> thelema: Definitely
<EM03> hcarty: this is an app that is similar
<hcarty> EM03: OCaml needs a (working) DrOCaml... then maybe it will be as cool as scheme
<hcarty> thelema: Agreed
<thelema> hcarty: this is the data I'm interested in, now to make it nicer...
<hcarty> EM03: Regarding "scripting" OCaml - there is also ocamlscript which allows you to run an OCaml program like a script, but it automatically compiles the program to native code on execution.
<hcarty> thelema: I think Gerd has a searchable, rather large suite of OCaml documentation grouped together

2011-03-09

<hcarty> I guess if there is a run-time exception defined for it then it may be an accepted possibility.
<hcarty> kaustuv: That looks like it may be a bug
<hcarty> When trying to call M.f
<hcarty> kaustuv: Very weird. "Exception: Undefined_recursive_module ("", 1, 42)."
<hcarty> kaustuv: I hope it is more Perl-like in its results - A Net.* hierarchy, a Map.* hierarchy...
<hcarty> First-class modules allow this too
<hcarty> Catch any missed code changes before they introduce a bug or security hole
<hcarty> EM03: Frequent type changes would be an argument for static type checks I would think
<hcarty> EM03: If the whole framework is typesafe then I don't think it would make anything more time consuming - but I haven't tested this theory :-)
<thelema> hcarty: maybe because browsers are loose about what input they'll accept (so one's output doesn't have to be 100% correct)
<hcarty> I'm not sure I see why static typing would be any worse for web development than it is for any other domain.
<hcarty> EM03: Ah. In that case it will just be fast and fun :-)
<hcarty> OCaml should be fast and fun to learn in that case. And you have two to four levels of fast available, depending on how you count them... ~interpreted toplevel code; bytecode; native code as a sort-of script; and native code.
<hcarty> Or the significant computational work was done by C or Fortran (GSL or LAPACK)
<hcarty> Ah. I found standard float arrays in OCaml to be plenty fast - but most of the float-heavy processing I've done has also been I/O heavy.
<thelema> hcarty: whole program optimization, better float arrays (bigarray has some implementation deficiencies, notably too many indirections)
<hcarty> thelema: Why scheme over OCaml in that case?
<hcarty> EM03: So it's up to something
<hcarty> EM03: OCaml's performance is nicely predictable
<hcarty> thelema: Hopefully that either gets worked out, or ends up being a non-issue in practice
<hcarty> I like "open Foo as Bar" too
<thelema> hcarty: yes, "in Foo.Bar" definitely seems better
<hcarty> thelema: Possibly so. The "in Foo.Bar" syntax (or something similar) may become more standard
<hcarty> The README looks quite promising
<hcarty> adrien: Using syntax like "in Foo.Bar" in x.ml would give you a module Foo.Bar.X
<hcarty> adrien: It also looks like you can define a namespace/module space in a file
<hcarty> adrien: I'm looking through it a bit now. It looks, at this point, like file x.ml in directory A gives you module A.X
<hcarty> That could be promising
<hcarty> There is a recently created namespaces branch in OCaml's Subversion tree.
<hcarty> There is an example in pa-do to optimize it away
<thelema> hcarty: no, native code
<hcarty> thelema: But I vaguely remember someone stating a lack of optimization as an argument against |> and friends
<hcarty> thelema: Is this from "ocaml foo.ml", bytecode or native code?

2011-03-08

<gildor> hcarty, thelema: don't go to fast, speak with upstream first, I think they have specific stuff they want to keep in their install
<hcarty> lablgtk2's move to the forge may open up the opportunity for full findlib support
<hcarty> It works here too
<thelema> hcarty: ah, great!
<hcarty> I think lablgtk2 does now... but I could be wrong.
<hcarty> thelema: You could compare the foo.info version number with the version number from findlib
<gildor> hcarty: you always update everything to be in sync with the server
<hcarty> gildor: How would you know to update the client side libraries when an upstream library version changes?
<hcarty> Ok, thanks
<hcarty> thelema: Ok, so it will verify that (for example) Camomile is >=0.7.0, but it won't recompile Batteries if you install a new version of Camomile?
<hcarty> thelema: What is the current state of odb.ml's handling of dependencies + version requirements?
<hcarty> I enjoyed them immensely, and started looking for something with more static checks
<hcarty> thelema: I did the same, more or less. I started using Perl's functional features thanks to the Perl 6/Pugs noise.
<thelema> hcarty: odd - I transitioned right from perl to ocaml, mostly because I was enjoying perl's functional features.
<hcarty> robertosucks: It also offers a different way of thinking about problems.
<hcarty> robertosucks: That gives you some opportunities to try a concept in a language you know and the new language, as a point of comparison.
<hcarty> robertosucks: It would probably also help to learn and use some of Python's functional components. I know that helped me in the transition from Perl to OCaml.
<hcarty> robertosucks: Based on comments others have made
<hcarty> robertosucks: Either would be good to learn. OCaml is probably a bit easier to transition to.
<robertosucks> hcarty, what OCaml has different from Haskell?
<hcarty> robertosucks: OCaml is good for many kinds of applications. It is a reasonably general-purpose programming language.
<gildor> hcarty, thelema: is this possible that someone with good knowledge of Batteries gives a talk about it at this year OCaml Meeting ?

2011-03-07

<hcarty> thelema: That's what I was thinking, since odb.ml does that as it is
<thelema> hcarty: you mean have odb.ml download everything needed to run a full oasis-db? most of the problems in the full version can come up in the bootstrap code
<hcarty> thelema: Would it be reasonable to use odb.ml-current as a bootstrap to grab batteries, oasis, whatever else is required to make handling everything else more easy?
<hcarty> thelema: . is the only other character I see on my system's "ocamlfind list" and I think that's only used for sub-packages
<hcarty> gildor: That's a good point. Binary rebuilding could be on-demand for odb's 80% solution.
<gildor> thelema, hcarty: I know the solution
<gildor> thelema, hcarty: binary deps ?
<hcarty> And it requires root, which is a downside on machines maintained by others.
<hcarty> thelema: Probably a good idea. findlib does a lot on its own.
<thelema> hcarty: that might not be a bad solution - having *everything* findlib-enabled
<hcarty> thelema: Then the binaries would be caught along with libraries.
<hcarty> thelema: You could require META files for binaries...
<hcarty> thelema: findlib can do that
<hcarty> thelema: The other option is scan every findlib package to see if it depends on the package being updated
<thelema> hcarty: blah
<hcarty> thelema: No, binaries wouldn't be covered by findlib. I think GODI handles this by downloading all available package metadata and basing checks on that.
<hcarty> thelema: findlib's libraries probably
<thelema> hcarty: how to find that out?
<hcarty> redownload AND rebuild
<hcarty> thelema: A relatively simple hack would be to redownload rebuild all packages which depend on the upgraded package
<gildor> hcarty: you can submit a bug to oasis, if you want
<hcarty> thelema: Fair enough
<thelema> hcarty: so that's a request for findlib, then
<hcarty> thelema: Without version support in findlib, I'm not sure how else to have testing + "real" versions available.
<thelema> hcarty: the build system (oasis, make, omake) would have to support it
<thelema> hcarty: custom findlib names seems like a bad idea for dependencies
<hcarty> Before I submit the request - do you think that would be more appropriate for odb or oasis?
<hcarty> Another feature request, possibly for oasis over odb/oasis-db -- It would be nice to be able to specify a custom findlib name. This would allow batteries and batteries-head to be installed simultaneously.
<thelema> hcarty: oops
<hcarty> thelema: That was me - don't assign my mistakes to gildor :-)
<hcarty> Maybe s/I think/I agree/ is a better way to put that.
<hcarty> thelema: Which is why I think odb and oasis+oasis-db and Batteries are so important :-)
<thelema> hcarty: without a cpan-like system to bring the community together, everyone can have their own standard
<hcarty> On the other hand, trying to create your own system can be healthy - either it fails and they transition to the standard (ex. findlib) or they succeed and create the new standard system.
<hcarty> gildor: I do, and I think that's very unfortunate.
<gildor> hcarty: you know that they are still people around thinking hard that findlib is a bad thing (TM)
<hcarty> gildor: Given what I've seen of oasis and from what thelema has said, I expect that to be what happens enventually :-)
<hcarty> gildor: I agree, and I think that's probably the right mid to long term plan. But odb is REALLY simple as it is, and it works now. That's good because it makes it easier to try oasis for someone using GODI (for example).
<gildor> hcarty, thelema: and if we work together around 1 format file, we will hopefully make it converges faster
<gildor> hcarty: and the difference is that if you set an _oasis, upstream author can use it for its own build system
<hcarty> If oasis becomes an informal standard like findlib has, then the two will converge.
<gildor> hcarty: my problem is that, I don't want yet another packaging system
<hcarty> Creating a package for odb for any one of ~80% of the OCaml packages out there would probably take 1-5 minutes. Converting that package to _oasis may take longer and require some upstream interaction.
<gildor> hcarty: I am just trying to convince thelema to base its system on _oasis to enhance the cooperation
<gildor> hcarty: this exactly that
<hcarty> The two can continue to develop and experiment with different approaches.
<hcarty> odb gives a lightweight CPAN-like tool Right Now
<hcarty> oasis gives a build system to test Right Now
<hcarty> gildor, thelema: As an outsider, I think both projects and approaches are very important
<thelema> hcarty: well, gildor suggests that binary distribution solves the oasis-db distribution problem
<hcarty> thelema: Or oasis the toolchain?
<hcarty> thelema: But can the same be said for oasis-db?
<hcarty> I do think the two can coexist quite nicely though, and converge if needed.
<thelema> hcarty: oasis is well designed to not need bootstrapping - the setup.ml files it creates are independent of the oasis binary
<hcarty> It's probably a little frustrating to see an independent project pop up which is, at least on the surface, so similar
<hcarty> gildor: _oasis and odb address a similar problem, but from different points in the toolchain. odb is something which could be used to bootstrap an oasis install, for example.
<hcarty> gildor: I suppose META files could be used when a package isn't using oasis
<hcarty> gildor: Where do the deps come from?
<gildor> hcarty: I have smthg like 5 Debian packages almost auto-generated using _oasis and its deps
<gildor> hcarty: oasis use findlib name and it works pretty well
<thelema> hcarty: ocaml doesn't even have a way to put magic comments (or require/use declarations) to make this happen
<hcarty> Go is the only language I've read about which has something like that.
<hcarty> gildor: Isn't that required for any system like this though? OCaml doesn't have a good automated "here is the source, what dependencies do I need?"
<gildor> hcarty: and it uses MakeMaker + .yaml file
<hcarty> It wouldn't be too outlandish to require something similar for odb/oasis-db/etc.
<gildor> hcarty: that what I call a standard path
<hcarty> Doesn't CPAN require a standard "configure && make && make test && make install"-like process from its packages?
<hcarty> gildor: Unless oasis-db eventually provides a replacement for GODI (with the exception of building OCaml itself) I think GODI will continue to be an important part of the OCaml community
<gildor> hcarty: yep, I agree
<hcarty> gildor: Yes, although odb's packaging is much simpler. GODI is nice, but the process for creating packages is rather involved.
<gildor> hcarty: to have oasis in GODI
<gildor> hcarty: a better plan would be to have it in GODI, if you use GODI ?
<hcarty> s/mimicing/mimicking/
<hcarty> gildor: odb is an easy way to get access to oasis in the near-term
<hcarty> gildor: Probably mimicing the existing packages which are available for odb at first, but then yes - I hope/plan to get some packages oasis-ified
<gildor> hcarty, thelema: I hope that creating package for odb will mostly be a matter of writing an _oasis file (and compiling it with "oasis setup")
<hcarty> If I start making packages I'll submit them too
<hcarty> I certainly will
<hcarty> thelema: Ok, that's all good to know. I want to make sure I have an idea of what to expect before I start trying it out.
<thelema> hcarty: the issue of where things get installed depends on the package itself. If not installing as root, (which is currently always the case), "--prefix $odb_home" is added to the configure command
<hcarty> thelema: Are binaries, documentation, etc. installed in ~/.odb?
<hcarty> I'm hoping to get a chance to test it later... which also makes it easier to test oasis, since oasis isn't packaged for GODI yet.
<thelema> hcarty: I think so.
<hcarty> thelema: I should be able to use odb with a hand-compiled OCaml, ocamlfind and nothing else from OCaml-land, correct?

2011-03-05

<surikator> hcarty: yes, i'm aware of ocamlnet for general network stuff. i was looking for something more specific. thanks a lot!

2011-03-04

<hcarty> surikator: ocamlnet is probably your best bet. I don't know if it has modules specifically for P2P networking, but it likely has the components required to build one.
<hcarty> mrvn: I've wondered the same. Maybe a compiler switch to turn it on/off.
<hcarty> virtuoussin13: That seems to be the most common route

2011-03-03

<thelema> hcarty: well, they don't need customization to work on a pretty vanilla linux system
<hcarty> And I suppose that logic could be removed if custom configure/build/install commands are added
<hcarty> It's quite nice that there are already a dozen packages which don't require customization beyond detecting the build system
<hcarty> Are any of the packages you put up on your site customized, or are they the upstream tarballs?
<hcarty> It looks that way
<thelema> hcarty: that's one of my two todo items - 1) command line args, 2) configuration file
<hcarty> thelema: A feature requests - a user-configuration $ODB_DIR (= ~/.odb by default)
<thelema> hcarty: thank you
<hcarty> In all seriousness though, it looks like a nice stop-gap until oasis-db is up and running
<hcarty> The 137 lines seemed like they would never end!
<hcarty> Ah... if I'd read the bottom of the file I would have seen that...
<hcarty> In the install function in odb.ml
<hcarty> thelema: Where are packages built? Is the "install-*" directory created in pwd or elsewhere?
<hcarty> thelema: Do odb package names map to findlib names?
<hcarty> thelema: Ulib from the Caml Bazaar may be worth stealing from as well
<hcarty> It's all very pleasantly surprising
<hcarty> thelema: I was under the same impression until searching and finding that link just now...
<thelema> hcarty: really? whoa. it has a new website, and its version number has jumped. I guess I was wrong about thta.
<hcarty> thelema: I think it is maintained, but it seems to be moving rapidly from location to location...
<hcarty> mrvn: http://gallium.inria.fr/camlimages/ may have what you need

2011-03-02

<hcarty> adrien: Thanks for sharing
<hcarty> Those bugs (or at least some of them) are fixed in 3.12-dev thanks to xclerc
<hcarty> I haven't switched over to -use-ocamlfind because there are still some threads-related bugs
<hcarty> Ah, this was using a findlib'd myocamlbuild.ml
<hcarty> adrien: I've used OCaml 3.12 + ocamlbuild + findlib + lablgtk2 with threads compiled in (Batteries rather than Batteries_uni), but no real thread use taking place.
<hcarty> adrien: Maybe? :-)
<thelema> hcarty: that was the answer I was looking for. Wow, it's been forever since I've used an array literal
<mrvn> hcarty: that is actually even better than Obj.magic.
<thelema> hcarty: hmm, I forgot about array literals...
<hcarty> mrvn: I'm not sure I understand... why doesn't { foo = [||]; bar = [||] } work?
<thelema> hcarty: need an empty node with no children or decisions
<mrvn> hcarty: how would you create the decisions array?
<hcarty> thelema: Why doesn't a normal, non-magic'd array work there?
<thelema> hcarty: Obj.magic would be better
<hcarty> thelema: This is a guess ... would wrapping it in an option help?
<gildor> hcarty: like how to setup/what is needed/who can do it at the conference
<gildor> hcarty: you can create a wiki page with links from the main OCamlMeeting2011 page to organize yourself
<gildor> hcarty: I understand, if you are able to convince someone to help in live, that would be perfect
<hcarty> gildor: I may be able to help, depending on what help is required. I can't make it in person, but I would love to see the talks.
<gildor> hcarty: I think so, but we will probably setup 2 webcams, one for the screen and one for the speaker
<hcarty> gildor: As in live slides + video/audio
<hcarty> gildor: Can webex provide a mix of computer display + webcam video?
<gildor> hcarty: though, I have a webcam and can afford for a webex session -- if someone volunteer to help
<gildor> hcarty: if someone volunteer to do it, yes
<hcarty> ustream or something along those lines
<hcarty> Would some sort of live streaming of the talks be possible?

2011-03-01

<hcarty> adrien: Sleep is so often overlooked as a debugging tool :-)
<hcarty> examachine_: Not that I know of
<examachine_> @hcarty: yeah i should first run some memory debuggers on them, i wondered if ocaml had any specific memory debugger facilities that i've forgotten
<hcarty> kaustuv: http://camlosg.sourceforge.net/ -- would this work for you?
<hcarty> examachine_: Lots of calls to Gc.full_major, Gc.compact, flushed printf calls and running under gdb and valgrind.
<hcarty> I haven't used it
<hcarty> This was posted to the list recently: http://ygrek.org.ua/p/code/cxx_wrapped/
<hcarty> kaustuv: The only game-related bindings I know of are SDL, ODE and Chipmunk
<hcarty> sgnb: My understanding is that it is. I haven't had trouble with in my personal use.
<sgnb> hcarty: is the git master reliable?
<hcarty> http://cgit.freedesktop.org/cairo-ocaml/ -- This is the most up-to-date home for cairo-ocaml
<hcarty> I think that there are a few folks who have put effort in to the Cairo bindings, Olivier Andrieu has done most of the work from what I understand
<hcarty> sgnb: I wish I had time to work on the Cairo bindings
<hcarty> sgnb: No no - the PLplot OCaml bindings
<sgnb> hcarty: you are the author/maintainer of cairo-ocaml?
<hcarty> It has the benefit of few dependencies