2011-05-31

<hcarty> The same operators could then be used in List.Infix, Array.Infix, Seq.Infix, etc.
<hcarty> Regarding the Enum operators - I'm of the opinion that most, if not all, of them should be moved from Batteries to Enum.Infix (and maybe Enum)
<hcarty> bluestorm: Hello
<rixed> hcarty: well, probably related since it works at home and one of the difference is that my home machine do not support dynlink. I replaced ocamlfind+makefile by custom compile.sh and now it works :)
<hcarty> rixed: Maybe it's not linking dynlink.cma? Just a guess though.

2011-05-30

<hcarty> And going with n = 500000000 puts Seq slightly ahead of Enum in speed
<hcarty> For a large n of 100000000 or so
<hcarty> thelema: http://vpaste.net/BSpWK? -- the speed difference between Seq and Enum may be negligible. s/Seq/Enum/ in that paste and the runtime doesn't really change on my system
<hcarty> Seq makes more sense/acts in a more expected manner when programming in a functional way
<hcarty> I do think Enum should remain - it's a useful module
<hcarty> Can that actually be done?
<hcarty> The memory used would be the source list + a bit of Seq overhead
<hcarty> Only the element currently being used is kept around
<hcarty> I don't think the whole list would be kept in Seq
<hcarty> I don't know how significant the speed differences are between Seq and Enum. I think I tested with something trivial like summing a large sequence of integers.
<hcarty> File.lines_of could either be surprising in a good or bad way with Seq
<hcarty> Seq was slower (I don't remember how much) last time I checked
<hcarty> If Seq.( -- ) were defined like the Enum equivalent
<hcarty> An imaginary let a = Seq.(1 -- 10) in Seq.iter print_int a; Seq.iter print_int a would print 1 through 10 twice
<hcarty> Correct
<hcarty> From the start of the sequence
<hcarty> You can't backtrack with marching through the sequence to the desired element
<hcarty> The large_list example is probably better.
<hcarty> I'm not sure it really makes sense with that example...
<hcarty> So (I think?) you could do File.lines_of "large_file.txt" |> Seq.reduce ( ... ) with a Seq-based implementation
<hcarty> Seq isn't consumable, but any used elements can be GC'd
<hcarty> That's my understanding of the implementation at least
<hcarty> thelema: I think Seq acts like Enum as far as GC-ability goes

2011-05-27

<hcarty> _habnabit: I think ( & ) can be used for the reverse order. I think ocamlbuild defines it that way by default (let ( & ) f x = f x)
<hcarty> _habnabit: I defined that in all of my code (and then in my mini extend stdlib) before moving to Batteries
<hcarty> let ( |> ) x f = f x
<_habnabit> hcarty, yeah, I don't have batteries, though.
<hcarty> _habnabit: List.map ... |> List.sort ... |> Array.of_list
<hcarty> You could go all out and build a mail reader in OCaml, using the SQLite bindings + SQLite's full text search support :-)
<hcarty> My main complaint with the alternatives is that you trade imperfect seach for no (or very slow) search
<hcarty> I would love to find a mail server, supporting IMAP or similar, with reasonable support for server-side search. Something to dump everything in to and still have Gmail-like search available
<hcarty> Though those all have their potential troubles
<hcarty> I'm thinking more from a phone, family member's home or work :-)
<hcarty> I've wanted to try sup, but that would require me to give up easy access to my email from anywhere
<hcarty> And/or copy the mail to be read locally using offlineimap or similar
<hcarty> adrien: You can use mutt to connect to Google's IMAP server(s) directly
<adrien> hcarty: I'm probably going to use mutt, but what I need some time to get a nice setup (plus I need to download all my emails, which will take some time...)
<hcarty> Assuming mutt offers some method to wrap long lines
<hcarty> adrien: If you're feeling keyboardy, you could use mutt to connect to gmail through IMAP
<hcarty> It seems rather complex for what it's doing. I haven't looked beyond the documentation intro yet though.
<hcarty> The automated man-ification is an interesting touch.
<hcarty> Cmdliner looks like a potentially interesting addition to the OCaml world -- http://erratique.ch/software/cmdliner

2011-05-26

<hcarty> It's too bad OCaml's build system doesn't support parallel make calls
<hcarty> I'm going to start fully fresh
<hcarty> Let me try a fresh odb.ml download
<hcarty> About 2 minutes ago
<hcarty> It looks like there is a stale dependency somewhere
<hcarty> thelema: This is against 2.0beta
<hcarty> thelema: I just tried a bare OCaml 3.12 + ocamlfind + odb.ml install of Batteries, and I get "ocamlfind: Package `camomile' not found"
<hcarty> oasis-db/odb++ could be extended to a full-blown ocamlbrew
<thelema> hcarty: maybe yes.
<hcarty> thelema: Does CAML_LD_LIBRARY_PATH get around the need to edit ld.conf?
<hcarty> But if you want otherwise, you could specify it somehow
<hcarty> The default would be .odb
<hcarty> odb could potentially allow a user to specify the target path
<hcarty> It's the way perlbrew works, and I have yet to see a tool which handles this kind of thing better
<hcarty> Otherwise the user has to learn the variables to set, or learn to build OCaml and findlib themselves
<hcarty> If odb creates a script or spits out the variables to be set then it's not really an issue.
<hcarty> The result is a very simple way to get the latest version of Some OCaml Library
<hcarty> Set a few ocamlfind environment variables
<hcarty> CAML_LD_LIBRARY_PATH
<hcarty> f[x]: I don't see where the hoops are
<hcarty> I think the default should be user-local (~/.odb/) not system-wide ($(ocamlc -where))
<hcarty> That makes odb unusable by non-root users if you're using a system ocaml
<hcarty> Tied how?
<hcarty> f[x]: Changing the .odb to/ .odb/a/ is a simple enough task
<hcarty> It does if you force the libraries to install to the same local-to-ocaml path
<hcarty> OCaml 3.12.0 with Batteries 1.0, 1.2 and 2.0
<hcarty> What if you want to use the same ocaml for each?
<hcarty> For example, a stable, testing and development suite
<hcarty> f[x]: What if you want several sets of libraries?
<hcarty> f[x]: Why?
<hcarty> I still think that it is worth leaving odb's install location in place
<hcarty> Drat, I misread
<hcarty> It looks like that's not true, with a bit of environment variable setup
<thelema> hcarty: at least once, someone with permissions to that file (root/staff) will have to add an entry in that file
<hcarty> odb seems very much like a cpanminus/perlbrew-light
<thelema> hcarty: to install a C stub library, the file `ocamlc -where`/ld.conf has to point to the install dir
<hcarty> Why else would findlib allow a user to specify multiple library locations?
<hcarty> thelema: I insist that f[x]'s opinion is flawed :-)
<thelema> hcarty: binaries have to go there. f[x] insists that if you don't have permissions to the configured findlib repo, you shouldn't be installing packages.
<hcarty> That's one of the nicer things about it
<hcarty> thelema: I hope odb.ml isn't going to stop putting things under ~/.odb ...

2011-05-25

<hcarty> rwmjones: #use for .ml, #load for .cmo or .cma
<hcarty> chegibari: I'm glad you found the issue!
<chegibari> hcarty, and that caused the mismatch
<chegibari> hcarty, as a consequence, a default .mli file was being generated
<chegibari> hcarty, my build system was not copying a handwritten .mli file to the working directory
<vivanov> hcarty: great -- thx -- ill try that :)
<chegibari> hcarty, thanks
<hcarty> chegibari: So Z may have been updated and compiled, but X and/or Y have not been recompiled against the new Z
<hcarty> chegibari: It usually (always?) happens when something hasn't been recompiled properly
<hcarty> vivanov: It has very nice time and date handling
<hcarty> vivanov: There is the Calendar module

2011-05-24

<hcarty> zsparks: For programs made up of only a file or two, ocamlscript can be a nice option as well
<hcarty> zsparks: The most popular options are probably ocamlbuild, OCamlMakefile, omake, oasis or autoconf
<hcarty> gildor: fileutils gets my vote
<hcarty> gildor: I was able to build and install fileutils with odb and fileutils-0.4.2-oasis6 as thelema_ said
<thelema_> hcarty: I don't think that's it, otherwise I'd be getting warnings on the admin panel
<gildor> hcarty: fileutils needs love esp regarding oasis, it is a shame that I didn't find the time to do it myself
<hcarty> odn calls for ounit, but odb expects oUnit
<hcarty> Ah, I see part of the problem
<gildor> hcarty: concerning odn, the bundle I released is just the result of a partial test (i.e. part of the ounit test suite of oasis-db), I'll upload odn 0.0.4 in my test suite to get it in the bundle
<thelema_> hcarty: thank you
<hcarty> odb does look like it is cleaning up nicely
<hcarty> thelema_: odn depends on ounit, but odb doesn't know this. Packaging/_oasis error I presume.
<thelema_> hcarty: the command line has -d for dependents, but it returns the package itself as a dependent. I'm now just cheating and filtering anything that starts with the package name from the list.
<hcarty> thelema_: I think you can find dependent modules with the findlib API, but I don't know if you can from the command line interface
<hcarty> Reaganomicon, zorun: There is a syntax extension. I don't know if it's maintained.
<hcarty> thelema_: fileutils fails during build, but that looks like a packaging issue
<hcarty> thelema_: Thanks, I'll give it a try
<thelema_> hcarty: fix pushed. i'll be back in 15
<hcarty> thelema_: I tried to install odn with odb, but I get a version parsing error: Exception: Failure "Could not parse version 1.5.0".
<hcarty> gildor: The oasis bundle doesn't work under a GODI 3.12 install as odn is not available
<hcarty> gildor: Thank you, and no apology needed! I'm looking forward to getting a chance to try out oasis with a few of my own projects.
<gildor> hcarty: sorry for the delay, I don't have enough time to work on everything at once, but stay tuned, I will do it (except if someone do it before me -- which would be great)
<hcarty> gildor: Understood - thank you for all of your effort
<gildor> hcarty: esp. regarding type-conv and ocaml-data-notation
<gildor> hcarty: I need to fix a bunch of deps before pushing oasis to 3.12
<hcarty> gildor: Could you push the oasis package to the 3.12 section in GODI?
<thelema> hcarty: since odb is working on local information, there's a chance it'll do extra work. if the deps are just A -> B -> C, then recompiling A will recompile B and then C If there's triangles, some duplicate recompilation is possible with the current strategy

2011-05-23

<hcarty> In this case, I guess C would need to depend on B and A.
<hcarty> For example - update package A. Package B depends on A, and C depends on B. Will B be updated/reinstalled before C, or is this undefined?
<hcarty> thelema: I haven't had a chance to try it yet - but does the odb update recompile packages in a dependency-respecting order?
<hcarty> thelema: Thank you - I certainly will
<thelema> hcarty: initial version committed. It may be a while before we can really test this, but if you see any obvious bugs, fix them or let me know.
<hcarty> thelema: If I get the time to, I certainly will :-)
<hcarty> How much work would it be to support multiple package repositories? For example, official and local repositories.
<hcarty> That's reasonable for now
<hcarty> print_endline "Some dependent packages are not available through odb: localfoo localbar localbaz"
<hcarty> thelema: Bonus points if it points out packages which depend on the package "foo" but which are not installed/installable with odb
<hcarty> That plus an auto-upgrade flag would be excellent
<hcarty> thelema: Something like, "To upgrade dependent packages, please run: ocaml odb.ml ..."
<hcarty> thelema: That would be a good start
<thelema> hcarty: would it be sufficient if, after upgrading camomile, odb gave the command line to update everything that depends on camomile?
<thelema> hcarty: working on the dep issue - maybe easily solvable
<hcarty> Since compilation will break with "foo and bar make inconsistent assumptions..." errors
<hcarty> Until it can handle that, I don't know how usable it is beyond an initial install
<hcarty> thelema: Possibly so. Can it do updates? (ex. Camomile 0.7 -> 0.8 upgrade also upgrades Batteries)
<thelema> hcarty: I worry that the only missing critical part of odb is the database of installable packages
<hcarty> I think that oasis-db/odb is the right idea. It just isn't complete yet.
<hcarty> thelema: I agree, but until something CPAN-like comes along, where anyone can develop and add packages, oasis-db/odb won't be enough.
<hcarty> ocp: github vs gitorious vs sf vs other hosts have the same visibility issues though
<hcarty> ocp: The Hump is something along those lines
<hcarty> It's a bit of a trade off between discoverability for people who don't use OCaml and people who do
<hcarty> ocp: That's a fair point
<thelema> hcarty: I don't think gildor can do that even with 48 hours in a day.
<hcarty> github certainly provides a cleaner and prettier interface than the forge. Possibly even cleaner than gitorious.
<hcarty> If the forge needs to be improved for that to happen, then it will hopefully be improved to the point where it is polished enough.
<hcarty> I think that, for a project which wants to be an important part of the OCaml community, it would be ideal if it were hosted on the forge.
<hcarty> thelema: You hear a voice in the back of your head. It calls out, "Use the Forge, Edgar!"
<hcarty> If it is then a better competitor to github, so much the better.
<hcarty> Also, providing a better services on the forge is, in general, a good thing
<hcarty> Those are pretty signifcant parts of a project
<thelema> hcarty: migration path away? i.e. we're locked into using github?
<hcarty> thelema: github does not, as far as I understand
<hcarty> thelema: gitorious provides a migration path away from a host
<thelema> hcarty, gildor: What's the problem with github? Its not being open source seems to be the best argument against it, and even that is a pretty weak argument
<hcarty> gildor: An instance of gitorious on the forge would be very nice. It provides a clean interface, and would hopefully entice more projects to move over from github.

2011-05-20

<hcarty> preludeml has a short OCaml program which converts the prelude.ml source from CamelCase to underscore_separated. It may be usable with Batteries as well.
<hcarty> thelema: I understand - I'll either put a patch together soon or suck it up and deal with the consequences
<hcarty> Nativeint, Printexc, Bigarray are all unfortunately named, I agree :-)
<hcarty> They would probably be used as aliased replacements for the matching unlabeled module
<hcarty> Again, though - I'd argue that the *Labels modules are not going to be used directly all that often.
<hcarty> I wouldn't expect the Bat* modules to be used directly all that often, given that they are often incomplete
<hcarty> No, but I like Multi_map more than MultiMap
<hcarty> I'm not terribly concerned though... individual module names tend to be short
<hcarty> But less efficient to read!
<hcarty> thelema: Cool, I'll take a look. I'm sad to see that CamelCase won out :-)
<thelema> hcarty: new v2 pushed for testing
<hcarty> It is quite a nice language and compiler
<nantralien> hcarty the best tool to use to focus on programming, and get efficient binaries :)
<nantralien> hcarty and i thank them for the wonderful compiler
<hcarty> nantralien: The OCaml team does provide means to provide financial support for OCaml's development
<nantralien> hcarty i agree
<hcarty> nantralien: In an ideal case, the university would be focused on research rather than bringing in money
<nantralien> hcarty i agree, i was speaking about general behaviour of universities
<hcarty> nantralien: I'm not sure I follow - a community OCaml bundle would, presumably, be distributed without charge
<nantralien> hcarty yes it's a pity that all the good things that universities create, they let other develop it and get the money....
<thelema> hcarty: new v2 pushed
<hcarty> A community bundle can address stdlib limitations
<hcarty> nantralien: That may be, but given how little full-time paid time OCaml gets, it's probably better that it stays small
<nantralien> hcarty i know but my opinion about small is 'not so small' !
<hcarty> nantralien: The OCaml authors want to keep the bundled stdlib small to make it easier to maintain
<hcarty> And _oasis
<hcarty> And META
<hcarty> thelema: It's probably not a big deal yet, but Camomile can be removed from README's list of requirements
<hcarty> nantralien: It's worth knowing about!
<thelema> hcarty: no, I guess I should do one more merge from master
<hcarty> thelema: What is the state of the v2 branch? Is it up to date with the development in master?
<hcarty> That too, but I was thinking about all of the resource files Camomile needs at run time
<thelema> hcarty: Hopefully yoriyuki is amenable to having his ulib folded into batteries.
<hcarty> thelema: Primarily because it would (I think?) remove any dependencies on outside files
<hcarty> thelema: A Camomile-less Batteries would be wonderful in my opinion

2011-05-19

<hcarty> IDA?
<hcarty> _y_: https://forge.ocamlcore.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=ocaml-hdf/ocaml-hdf.git;a=blob;f=hdf_impl.c;h=9862caaf711dd8ec14ee4b2d4b280d22a56356a9;hb=HEAD -- lines 16 to 40 for reference
<hcarty> I've used it in a few library bindings
<hcarty> Maybe not with typedefs. I'm not certain.
<hcarty> _y_: It's an ugly hack, but it is needed sometimes.
<hcarty> _y_: You can wrap some #define's around the conflicting headers to avoid C name conflicts

2011-05-18

<hcarty> I don't think that it is possible to compile that, but I may be wrong.
<hcarty> NaCl: I haven't used recursive modules before, but I think they need to be defined in a single .ml file

2011-05-17

<hcarty> A web development perspective, that is
<hcarty> sheets1: From a web perspective, yes
<sheets1> hcarty: yes, that limits its usefulness as a teaching tool as you can't as easily hook it into js libs or the dom
<hcarty> sheets1: It's based on a JVM-based OCaml bytecode runtime
<hcarty> sheets1: Another toplevel option which is heavier (Java vs Javascript) but similarly feature-full - http://ocamljava.x9c.fr/toplevel/toplevel.html
<hcarty> Competition go home!
<flux> hcarty, not really. because it is useful for any language! there'll be competition!
<hcarty> I wonder if we can get OCaml up and running in this, to provide yet another Try OCaml From Your Browser option: http://bellard.org/jslinux/
<hcarty> _habnabit: Or if you want to get fancy and use syntax extensions: (Print.printf p"%{int list}" [1;2;4]) also prints "[1;2;3]"

2011-05-03

<hcarty> adrien: The biggest downside to GODI is that its packages are rather heavy. godiva helps, but there is still a fair amount of effort involved.
<hcarty> adrien: That said, I haven't taken the time to learn the command line syntax for GODI's tools. My guess is that doing everything through godi_console slows me down.
<hcarty> adrien: I agree. It's just a little heavy to get setup initially.
<hcarty> It's probably not a pressing issue at this point in odb's development
<hcarty> thelema: For example, "ocaml odb.ml --replay" could print "ocaml odb.ml batteries camomile ..."
<hcarty> thelema: A 60% solution could be to provide a way to have odb dump a command line which would replicate the currently installed packages
<hcarty> thelema: I've added three examples using ocamlscript - one with vanilla Batteries, one with a syntax extension and one with threaded Batteries (but no thread use)
<hcarty> I've started a lot of projects with ocamlscript, then transitions to ocamlbuild once the initial idea was properly tested
<hcarty> ocamlscript is more an ocamlbuild replacement for smaller projects (maybe up to a few files) than it is something you would us in addition to ocamlbuild
<hcarty> I'll add the ocamlscript example to the wiki
<thelema> hcarty: the ocamlscript example is useful, and maybe it should go here: https://github.com/ocaml-batteries-team/batteries-included/wiki/Getting-started\
<hcarty> thelema: Unless I misunderstood and you meant bluestorm's ideas rather than those from the blog post
<hcarty> thelema: http://codepad.org/NIhnOkyi -- A brief ocamlscript + Batteries + camlp4 example
<hcarty> But I'm not familiar enough with the details of either camlp4 or what they are proposing to properly judge their merits.
<hcarty> I like the idea of <:foo< >>-style delimited extensions without camlp4
<hcarty> On a side note - the syntax Yaron Minsky shows in the comment bluestorm linked to from the Batteries list is rather nifty looking
<hcarty> I've used ocamlscript with the syntax extensions from Batteries, for example
<hcarty> thelema: It works well. I believe it enables camlp4 by default
<thelema> hcarty: its support of findlib does produce a 90% solution. I wonder how/if it works with camlp4
<hcarty> thelema: ocamlscript could potentially be used as a basis for that kind of operation
<thelema> hcarty: one way to deal with compilation troubles is to unify dependency handling between the toplevel and compiled programs
<hcarty> Having a four or five line "Hello world!" which uses Batteries and requires no explicit compilation step could remove a few hurdles.
<hcarty> On a tangent - ocamlscript would be a wonderful thing to use in OCaml tutorials. It avoids many of the compilation troubles many OCaml beginners can have.
<hcarty> But it's just a suggestion - it really may not be worth it
<hcarty> I'm thinking three or four Not_found's in to the future :-)
<hcarty> thelema: You could use it for odb development, then fall back to bare ocaml once everything is done
<hcarty> thelema: I highly recommend it. It's a very nice tool.
<thelema> hcarty: thanks. I guess I should look into ocamlscript
<hcarty> thelema: Someone did release a patch to allow backtraces in the toplevel
<hcarty> thelema: It is when using ocamlscript, but I don't think it is (without patching OCaml) when using the ocaml binary
<gildor> hcarty: thx
<hcarty> gildor: Congratulations :-)
<hcarty> gildor: Ok, thanks - that makes sense
<gildor> hcarty, thelema: I think the current batteris tarball don't include an _oasis, that is the reason of the problem
<hcarty> thelema: Ok, thanks
<hcarty> thelema: I get a 404 on the admin page
<hcarty> Is it possible to upload new packages?
<hcarty> thelema: Was that in one of the links gildor gave ~a few weeks ago? I don't have them handy at the moment.
<hcarty> thelema: The _oasis file in the archive, or something else?
<thelema> hcarty: you're right.. huh.
<hcarty> gildor: ping
<hcarty> For batteries or, as far as I can tell, anything else
<hcarty> oasis-db only provides the source archive in the info file
<hcarty> thelema: Yes
<thelema> hcarty: what server doesn't provide dependency information? oasis-db?

2011-05-02

<hcarty> s/it/is/
<hcarty> The help both in gnuplot and on the website it good
<hcarty> DOUK: I'm not sure - I haven't used gnuplot in a while
<douknoukem> hey hcarty how can i use names on the x axis instead of numbers
<hcarty> douknoukem: http://gnuplot.sourceforge.net/demo/histograms.html has simple bars in the second example
<hcarty> douknoukem: There is a wide range of examples here - http://gnuplot.sourceforge.net/demo/
<hcarty> thelema: Ah... nevermind, it looks like the server doesn't provide dependency information
<hcarty> thelema: This is with a fresh OCaml 3.12.0 + ocamlfind install from source, Ubuntu 10.04 64bit.
<hcarty> thelema: No luck here with odb.ml + batteries. odb doesn't try to fetch Camomile.
<hcarty> Fedora may have its own methods, although IIRC most of the Fedora packages are modeled after Debian
<hcarty> Hopefully these kinds of differences will go away once the various upstream projects are properly ocamlfind-ified
<hcarty> kaustuv: I have no evidence to back that up, beyond GODI acting like it does one thing and Debian acting like it does another.
<hcarty> kaustuv: GODI and Debian may have each added their own, different linking steps to the build process
<thelema_> hcarty: iirc, there's no META from garrigue
<kaustuv_> hcarty: there are some META files in the debian/ directory in lablgtk2. Not sure if they are the same as upstream or not
<hcarty> kaustuv: Do either GODI or Debian use an upstream META file and build system, or do they provide their own?
<hcarty> Or something close to that
<hcarty> kaustuv: $GODI/build/godi/godi-lablgtk2/patches/
<hcarty> I'm on an older Ubuntu (10.04), so not at the moment
<hcarty> Using GODI + 3.12.0 + GODI's lablgtk2 + native code your program works here
<hcarty> kaustuv: I believe so. I checked the distribution files directory and the lablgtk2 source package there is 2.14.2
<hcarty> kaustuv: GODI package version that is
<hcarty> kaustuv: I think that GODI version is equivalent to 2.14.2

2011-05-01

<thelema_> hcarty: the one on github is the latest.

2011-04-30

<hcarty> thelema_: Is odb on github the right one to use/start with, or is there a different home now?
<thelema_> hcarty: what it needs is .tar.bz2 support and... maybe just more love.
<thelema_> hcarty: other than that, I don't really know what works and what doesn't. I think maybe batteries is installable at the moment. Dunno about anything else.
<thelema_> hcarty: I've not worked on odb significantly since the default repo became oasis. I spent a bunch of time trying to get the repo set up, and got distracted
<hcarty> It isn't intended for general use as it pokes directly into the program's internals
<hcarty> redfire: The Obj module is somewhat intentionally left undocumented
<redfire> hcarty: unfortunately, I have already looked at this web sites, but there are not enough information :-(
<hcarty> thelema_: What is the current state of odb?
<hcarty> redfire: I don't know if anyone has done what you're trying to do, but you can look at the OCaml Java project for some bytecode documentation.