<hcarty>
That could certainly be used as well. I think it's generally used for quick prototyping.
<hcarty>
I'm the author/maintainer of the bindings - feedback is welcome!
<hcarty>
Yes, hopefully :-)
<hcarty>
vivanov: Yes
<hcarty>
vivanov: PLplot or you can use Cairo directly
2011-02-28
<hcarty>
It cuts out the Pcre dependency
<hcarty>
thelema: I don't know that it simplifies things at all, but you could the OCaml curl bindings in place of ocamlnet.
<hcarty>
thelema: Oh my. Good luck - I hope it's not anything serious.
<thelema>
hcarty: one sec while I push it to github
<hcarty>
thelema: Any progress on your odb-minus project?
2011-02-25
<alexyk>
hcarty: no way; I'm only using Batteries...
<hcarty>
alexyk: Is there any possibility that Not_found was re-defined somewhere?
<hcarty>
xstp4's <here:< >>
<hcarty>
I don't know if a quotation would fix that itself, make it easier to fix, or make no difference.
<hcarty>
I'm not sure why it's non-portable. Maybe Windows line endings vs Unix line endings?
<hcarty>
thelema: The warning description - "29 Unescaped end-of-line in a string constant (non-portable code)."
<hcarty>
thelema: Thanks
<hcarty>
The here quotation is definitely a lower priority item in my opinion
<hcarty>
They do, but a warning was added recently (IIRC) which complains when unescaped newlines are found in strings
<hcarty>
The <:here< ... >> quotations in xstrp4 are nice for anything multi-line
<hcarty>
pa_string already supports labeled arguments, but it would be nice to avoid writing a variable name twice
<hcarty>
thelema: Inline interpolation and possible "here" quotations
<hcarty>
thelema: I don't either, but I'd like to learn enough to fold some of xstrp4's features in to pa_string
<thelema>
hcarty: I was thinking about extending the Print module
<hcarty>
thelema: xstrp4 and/or the Print module from Batteries could provide something similar to Perl's formats/templates
<hcarty>
kaustuv: "custodian's moonlighted Xavier interlopers sobers Canterbury's" -- Deep insights from the OCaml toplevel, using your earlier pastebin
2011-02-24
<SoftTimur>
hcarty: thanks for the link, yes, I think precedence explains the thing
<hcarty>
SoftTimur: IIRC, ; has a lower precedence than if/then
<hcarty>
thelema: That still requires an understanding of dependencies on the server. It would be simpler to leave all of that to the client - in this case the upload client, as opposed to the end-user download client.
<hcarty>
thelema: The dependency tree would be created by the author then, before uploading to a remote server?
<thelema>
hcarty: yes, in multiple steps
<hcarty>
thelema: Perhaps I misunderstood. I thought you meant you wanted to be able to query the full dependency tree of a package from a remote server
<thelema>
hcarty: you call it API, I call it static files in preset locations
2011-02-23
<hcarty>
thelema: If the dependency calculation is done client-side then nothing special is required of the server
<hcarty>
thelema: Why require a server-side API? That prevents you from being able to allow "dumb" mirrors which only contain a bare file hierarchy.
<hcarty>
thelema: I tried out perlbrew and cpanminus recently. Very impressive tools.
<hcarty>
libcurl abstracts the protocol away rather nicely
<hcarty>
CPAN is good and old school :-)
<gildor_>
hcarty, thelema: there is already a graph of deps in oasis
<hcarty>
Reading about the history of CPAN, I believe that's how it started. Static FTP on the server side and some basic organizational assumptions by the client.
<hcarty>
Simplest Thing That Could Possibly Work... or is it s/That/Which/...
<hcarty>
thelema: Assuming "make" and "make install" do the right thing is probably reasonable for a STTCPW
<hcarty>
With a fixed directory hierarchy, findlib + OCaml's libcurl bindings should be enough for something which is static on the web side
<hcarty>
thelema: META files have all of the information required for dependency calculation between OCaml packages
<hcarty>
thelema: To do some oasis-db-like work?
<hcarty>
gildor_: Good night
<hcarty>
gildor_: Thank you for your work on all of this!
<gildor_>
thelema, hcarty: thx for the discussion, drop me an email/bugs/patches if you have other ideas
<hcarty>
thelema: Version to version breakage is a large part of why I would love to see version handling in ocamlfind.
<thelema>
hcarty: at least, that seems to be the accepted solution for CPAN and others
<gildor_>
SoftTimur: I am not sure hcarty, me and thelema knows a lot about alphaCaml
<hcarty>
thelema: But you can't test against an unknown user's code
<thelema>
hcarty: the solution to that is testing, lots
<hcarty>
thelema: I disagree somewhat. It makes it safer to put new version of libraries up, while being able to take stable snapshots along the way
<hcarty>
I would presume that, eventually -- val build : ocaml -> oasis-db-bundle -> binary
<hcarty>
If you don't have network oasis-db, it's harder to mix versions of libraries as they come out. If you don't have bundles, it's harder to get snapshots.
<hcarty>
thelema: Network oasis gives you the CPAN/hackage experience
<hcarty>
thelema: Bundles would be for specific cases - packaging to distribute a final application for example
<gildor_>
hcarty: well it can even be mirrored to your computer
<thelema>
hcarty: if we have successful bundles, noone will need network oasis
<hcarty>
If I understand correctly...
<hcarty>
thelema: Bundles - one shot, for one package; Mirroring - oasis.o.o vs oasis.janest.com
<gildor_>
hcarty: it is indeed almost orthogonal
<hcarty>
thelema: Bundles and mirroring sound orthogonal to me
<gildor_>
hcarty: excatly, the bundle will just get rid of oasis-db and allow a simple build/install cycle
<hcarty>
thelema: Avoid the need for an oasis-db client for end-users
<hcarty>
thelema: It could be very useful for deploying to a server, or distribution to users
<hcarty>
gildor_: From the sound of it, the oasis-db client doesn't require anything from the server other than a fixed set of files, correct?
<gildor_>
hcarty: we use the same directory structure
<hcarty>
gildor_: I suppose I should read up on hackage then :-)
<gildor_>
hcarty: oasis-db is inspired from hackage mostly
<hcarty>
I admit that I haven't read the oasis-db technical specification yet, but CPAN seems like a good thing to emulate at first
<hcarty>
thelema: ocsigen is a nice community vote of confidence. Not that the same can't be said for ocamlnet...
<hcarty>
thelema: The static file could be replaced with something dynamic later on if needed
<hcarty>
thelema: It's a web API, just not a dynamic one...
<thelema>
okay, so we have the repo structure, we have the dependency solving and package getting and we have the required contents of the tarball. I guess I have to ask hcarty's question: what's missing?
<hcarty>
gildor_: I agree - anything involving a build + install should be restricted to _oasis packages
<hcarty>
thelema: GODI configures a number of things with ocamlfind. For example, system packages and user packages install to different locations.
<hcarty>
thelema: But not in the general case
<thelema>
hcarty: requires root for me
<gildor_>
hcarty: but it won't be taken into account in deps et building
<hcarty>
thelema: ocamlfind install ...
<gildor_>
hcarty: indeed, we can upload w/o _oasis
<hcarty>
Any why would install require root? For example, GODI doesn't require (or even recommend) root
<thelema>
hcarty: oasis-db ecosystem can include things w/o _oasis
<hcarty>
Why would oasis-db support building/installing anything which is not part of the oasis-db ecosystem?
<gildor_>
hcarty: yes oasis provide install/uninstall/reinstall
<hcarty>
Does oasis provide install targets?
<hcarty>
gildor_: What complex components remain?
<gildor_>
hcarty: yes, that it is the reason why we can fill the findlib-db using debian/godi packages
<hcarty>
gildor_: It's probably safe to require, at least at first, that any dependencies which aren't using oasis be installed through some other means than oasis-db
<gildor_>
hcarty: indeed, it is written and will be updated to help people understand what is going on
<hcarty>
thelema_: Having a spec/plan, however specific or loose, could be handy for external contributions once oasis-db gets rolling
<hcarty>
thelema: Probably a bad link. I've been able to browse the darcs repo in the past.
<thelema>
hcarty: n/p
<hcarty>
flux, thelema: Sorry about the noise
<thelema>
hcarty: his second email has the patch
<flux>
hcarty, it should've been two posts, (git format-patch) cover letter and actual patch?
<hcarty>
flux: I didnt see the patch in your mailing list post. But from looking at your MapSet code before, I think it is a worthwhile addition.
<hcarty>
thelema: I didn't know that. That's good to know.
<hcarty>
thelema: Assuming that "open Batteries" is allowed for getting the most recent version
<hcarty>
thelema: I like it, but I'm not sure how it would work when you have both Batteries1 and Batteries2 installed. Would the two batteries.cm(x)a files conflict?
<thelema>
hcarty: maybe batteries could have different (sub)packages for 1.x and 2.x etc
<hcarty>
It would also be nice to have version support in findlib/ocamlfind. Being able to specify "ocamlfind opt -package batteries:1.x ..." vs "batteries:2.x" would be nice
<hcarty>
philtor: A rvm or perlbrew for OCaml would be pretty nifty.
<hcarty>
philtor: There is no automated tool for automatically switching between versions, but it is at least possible to do manually.
<hcarty>
philtor: You can have multiple OCaml versions available now with GODI - install multiple OCaml versions in different directories, then adjust your $PATH appropriately.
2011-02-22
<thelema>
hcarty: I expect it to do as little work as possible to get the one element
<thelema>
hcarty: yes, very
<hcarty>
thelema: Bat(Map|Set).pop does not seem to be ordered. Is that correct?
<hcarty>
thelema: Does a Gc.full_major affect memory use at all, once everything is loaded?
2011-02-20
<hcarty>
I've added suport for "${foo,print_foo}" which uses %a internally. But it would be nice to support expressions in place of "foo" and "print_foo"
<hcarty>
adrien: Oh yes, it definitely does. Thanks for the tip.
<hcarty>
adrien: Oh, that seems rather serious. Do you have a test case by any chance?
<hcarty>
I've been able to make it take a plain function as the printer, but it would be Very Cool to be able to embed proper OCaml expressions for evaluation in interpolated strings.
<hcarty>
I'm working on/playing with xstrp4
<hcarty>
Is there a simple, preferably pre-defined, OCaml expression match pattern in ocamllex?
2011-02-10
<thelema>
hcarty: to be honest, I'm not so sure about the difference between Seq and Lazylist
<hcarty>
thelema: Would Seq or LazyList be the proper analog to Enum if one were added in addition to Enum?
2011-02-08
<hcarty>
thelema: Thanks! The ocamlbuild wiki and perhaps a patch/snippet submitted to the ocamlviz project.
<hcarty>
thelema: Would you mind sharing the ocamlbuild hacks?
<hcarty>
thelema: Last commit was ~4 months ago, according to the forge
<thelema>
hcarty: interesting. Building it from source never caused me any problems
<hcarty>
thelema: I've been hoping to have a chance to try it out, but it had build issues in GODI last time I tried.
<thelema>
hcarty: nice. I've had a lot of success profiling with it. not that I use GODI...
<hcarty>
Cool! Ocamlviz is available in GODI now.
2011-02-07
<hcarty>
adrien: Sounds very exciting :-)
<hcarty>
adrien: I agree. A proper FRP GUI API seems tricky to implement properly, but allows for some very nice end-user code
2011-02-04
<thelema_>
hcarty: thanks
<hcarty>
thelema_: Happy 1.3.0 release :-)
2011-02-03
<hcarty>
But not in bytecode
<hcarty>
It was my understanding that the native code floating point handling in OCaml follows IEEE 754
<hcarty>
kaustuv_: I believe the t_printers are for the Print module functions
<hcarty>
kaustuv_: Also (hopefully) true
<kaustuv_>
hcarty: presumably thelema's quicktest harness would take care of things getting out of sync
<hcarty>
kaustuv_: But that also opens lots of room for bugs as print/read fall out of sync
<hcarty>
kaustuv_: True
<hcarty>
If it's for serialization then I'm not sure I see the benefit over sexplib
<hcarty>
thelema: If it's viewing then using the Format module and simple representations would be ideal, as it makes it easier to see what's going on.
<thelema>
hcarty: without de-serializers, they're only good for debugging
<hcarty>
thelema: Are the print and read functions meant to be for serialization or viewing/debugging?
<thelema>
hcarty: yes, except it wouldn't be string -> 'a, it'd be like *.print: (input -> 'a) -> input -> 'a list
<hcarty>
thelema: Would these read functions be in place of something like sexplib?
<hcarty>
kaustuv: I think BitC is doing something similar, though it may be one "let" and one "in" surrounding definitions
<hcarty>
f[x]: It looks like xclerc is/was on a camlp4 fixing spree today. Perhaps a few of these will be caught in that.
<hcarty>
adrien, gildor: That's quite nice - the forge feels even more official with both X. Leroy and Jacques Garrigues have projects hosted there :-)
<hcarty>
thelema, kaustuv: I'd like to see that change (enum becoming to_enum) as a consistency fix in 2.0
<gildor>
hcarty: Jacques told me he want to move back at ICFP 2010 (september), I think it is official
<adrien>
hcarty: Jacques Garrigues had told me he was planning a move and Maxence Guesdon is a long-time contributor to lablgtk, so I'm inclined to think it's a move
<hcarty>
adrien: Is this an official move to the forge for lablgtk, or a fork/mirror?
<hcarty>
Have *a* good day/afternoon/evening
<hcarty>
npouillard: Have good day/afternoon/evening
<hcarty>
npouillard: I saw :-) It was quite a happy revelation
<npouillard>
hcarty: xclerc implemented it!
<hcarty>
npouillard: It is the only one I've seen missing
2011-01-31
<hcarty>
spicey: Part of the reason for using ( |> ) over ( $ ) is that $ has a special meaning for camlp4
<hcarty>
spicey: You were. Just not the first inventor. Discovery on your own of something nifty which has already been discovered is Still Cool.
<spicey>
hcarty, ok, I'll know that now; yet for a moment I felt like the inventor of the greatest thing in the universe
<hcarty>
s/exaple/example/
<hcarty>
spicey: ( |> ) is commonly used for that. It's defined in Batteries, for exaple.
<hcarty>
dooode: Try it! :-)
<hcarty>
dooode: See the List module. List.map in particular
<hcarty>
thelema: If IO speed is a concern then staging the file(s) to be processed in /dev/shm (or some other ramdisk space) may help
<hcarty>
Which probably doesn't help much in this case
<hcarty>
thelema: Then it sounds like it could work the other way (Bigarray pointing to a string) but not a string pointing to a Bigarray.
<hcarty>
thelema: In that case, the process sounds more complex :-)
<thelema>
hcarty: the string value would have to have its header written right before the mmaped value in memory
<hcarty>
thelema: But an OCaml string value pointing to the data from a byte Bigarray may do the trick.
<hcarty>
thelema: If it did work, it would probably be fragile. The internal representations are different, so String.length would probably not work.
<hcarty>
thelema: I've been wondering the same. A C stub could probably be used to do something similar.
<hcarty>
adrien: Thanks, it looks that way
<hcarty>
thelema: I expect the IO overhead would drown out the extra allocations needed for the Buffer case.
<thelema>
hcarty: fair enough.
<hcarty>
thelema: Then I would think all-at-once would be faster, though I doubt there would be a huge difference either way
<adrien>
hcarty: I _think_ you don't need them for native cod
<thelema>
hcarty: since I'm processing it with bitstring, it has to be all in memory at once
<hcarty>
thelema: Is the input processed as a whole, or as it is read? Reading it all in at once should be faster from an IO perspective.
<hcarty>
From an experiment it looks like the dll*.so files are not used by native code binaries. But I'm not sure if that is a function of the library + compilation flags, or if that is generally true.
<hcarty>
Anarchos: It probably is. I think I'm just missing it, or misunderstanding the relevant portion.
<hcarty>
Are the dll*.so files generated for C bindings used at run time by native code binaries, or only for bytecode/toplevel?
2011-01-30
<mrvn>
hcarty: yes, if you want to apply it then
<hcarty>
mrvn: Wouldn't it be (#foo) a?
<hcarty>
mrvn: My guess is either (a) no one wanted to do it or (b) it introduces some abiguity
2011-01-29
<hcarty>
sav: Depends on the .idl file. camlidl can be used with specially-crafted .idl files to generate OCaml interfaces for C libraries.
<hcarty>
doodo: For what it's worth - if you go with the class, rather than fighting it the whole way, it will make the next few months much more enjoyable.
<hcarty>
thelema: let x = List.Exceptionless.find (fun i -> i > 5) lst |? 5 in ...
<hcarty>
thelema: I use ( |? ) for that
2011-01-28
<hcarty>
Neither of these are technical reasons of course, but the original goal isn't particularly technical.
<hcarty>
And 'a option does as well, because "foo ();" would give a warning
<hcarty>
s/hope/intent/
<hcarty>
mrvn: I think I'm going to stick with thelema's suggestion of two functions. The hope was for syntax convenience, so a functor defeats the purpose here.
<mrvn>
hcarty: or a functor.
<mrvn>
hcarty: ^^^
<hcarty>
thelema: True. The one can wrap around the other.
<thelema>
hcarty: I've wished for it myself
<hcarty>
thelema: That makes sense
<thelema>
hcarty: once you have a default, the type of that default becomes the type of that parameter
<hcarty>
thelema: I didn't think it was, but I was hoping I missed something. Thank you!
<Anarchos>
hcarty you can't have a true polymorphic output, only weak variable type
<hcarty>
Anarchos: I'm hoping for a polymorphic return value
<Anarchos>
hcarty let f = fun 0 -> 'a' | x -> 'y' ?
<thelema>
hcarty: nope
<hcarty>
Anarchos: "let return ?(x = ()) () = x" does not work for rather obvious reasons
<Anarchos>
hcarty can you precise your question ?
<hcarty>
Is it possible in OCaml to have a function like "val return : ?x:'a -> unit -> 'a" where x is some specific value by default? (for example ?(x = ()))
2011-01-27
<hcarty>
kaustuv_: On Google Video I think
<mrvn>
hcarty: easily. You just use an int and increment/decrement it without locking.
<hcarty>
thelema: Could Mutex and RMutex be replaced by dummy versions in the non-thread case?
2011-01-26
<hcarty>
flux: Lots of large changes. It sounds impressive.
<thelema>
hcarty: nope, I have used this trick, and I'm not up to 3.12 yet
<hcarty>
mrvn: Agreed. That would be really handy.
<hcarty>
thelema: Ah, cool. I thought that had been added in 3.12.
<thelema>
hcarty: that's been possible since before 3.12
<hcarty>
alexyk: 3.12 may offer the ability to do something like that ... create a module from a module type if the module type does not contain any values.
<hcarty>
alexyk: That's something of what a .ml and .mli separation provides
<hcarty>
alexyk: Someone posted a camlp5 syntax extension on the mailing list recently
<alexyk>
hcarty: arrgh... is there a way to somehow include .mli without duplication??
<hcarty>
alexyk: Types need to be duplicated between the .ml and .mli, with the exception that anything you want to be hidden from outside use shouldn't be exposed in the .mli
2011-01-25
<kaustuv_>
hcarty: I also like the grouping. With Arg I have to manually insert \ns in the description
<kaustuv_>
hcarty: I was being a bit facetious, but I do find the ~first argument to OptParser.parse kind of useful for implementing subcommands with their own options
<hcarty>
kaustuv_: Thanks for the pointer. What does OptParse offer that the old 'n busted Arg does not?
<hcarty>
jado: That is correct. You have to verify that required arguments have been provided.
2011-01-24
<hcarty>
In my experience at least. Sadly, it's not very well documented.
<hcarty>
thelema: The toplevel extension on its own makes keeping Lwt around worth while :-)
<hcarty>
jonafan: More awesome. Mosty of the changes I've seen are filling in missing features/functions.
<hcarty>
adrien: I'm glad someone else has found it useful :-)
<adrien>
hcarty: yeah, and quickplot is quite nice :-)
<hcarty>
adrien: It doesn't work for everything, but for the items it supports it's quite handy
<hcarty>
adrien: Not wanting to write code to make plots if part of why I wrote a Quick_plot module for PLplot - usually one line to display/save a plot.
<hcarty>
orbitz: You're welcome. A few warnings: 1) This is OCaml 3.12.0 or later only; 2) camlp4 doesn't play well with "module type of"
<orbitz>
thanks hcarty
<hcarty>
IIRC
<hcarty>
module Foo = sig include module type of Orbitz_foo end
<hcarty>
I think more recent OCaml versions support include in signatures...
<hcarty>
orbitz: That would require duplication, or "include Orbitz_foo"
<hcarty>
orbitz: Or "module Foo = Orbitz_foo" + orbitz_foo.ml
<hcarty>
orbitz: You can put "module Foo = Foo" in orbitz.ml, and the content of Foo in foo.ml
<hcarty>
The best approach depends on what the goal is - quick + dirty view of data or piece of a larger project
<hcarty>
That's true
<hcarty>
(Cairo and PLplot both support SVG output :-D)
<hcarty>
adrien: But it does remove the need for you to manage coordinates yourself.
<hcarty>
adrien: PLplot could be overkill if all you want to do is show lines
<hcarty>
adrien: It has some basic map support. But at the end of the day, it's lines in a coordinate system - Cairo and PLplot support that.
<hcarty>
adrien: If you're working from OCaml, Cairo or PLplot are probably your best bets. Cairo may be the simplest, depending on how the data are formatted.
<thelema>
hcarty: haven't used batarg - I've still got my own argument handling library that I use
<hcarty>
thelema: If not, I'll submit a bug report and (hopefully) a patch
<hcarty>
thelema: Do you know if there is a way to align the usage/help output from BatArg.handle? It doesn't look like there is, but I'm not certain.
<thelema>
hcarty: I've found the heap size to be most important, and when allocating large values, turning down the space_overhead parameter temporarily as well.
<hcarty>
thelema: I just (re)found elehack's posting on GC tuning. I've been waiting for a chance to try some of what's talked about there.
<thelema>
hcarty: that's quite worse, I expect. I understand why you're paining the GC
<hcarty>
thelema: Thanks, I'll look in to all of this. For better or worse, the BAs are converted to normal OCaml arrays to ease manipulation by other functions.
<thelema>
hcarty: there's a point where functional code without deforestation runs into physical bottlenecks, and I think your code is seeing that.
<thelema>
hcarty: hmmm, I imagine the functional-ness requires creating lots of new arrays... you're using BA, of course. I wonder how much benefit you'd get from mutating an accumulator
<hcarty>
thelema: I'm most concerned with making sure that this isn't indicative of a bug somewhere, since there is some C involved.
<hcarty>
thelema: Thanks for the GC suggestion. The program is manipulating a large number of large multi-dimensional float arrays, so keeping things functional results in lots of garbage to collect :-)
<thelema>
hcarty: you could try upping the size of your minor heap... what're you doing to allocate so much memory?
<hcarty>
Or does it mean I should tweak some GC parameters?
<hcarty>
Wildly different = 500-600 megabytes vs 5+ gigabytes
<hcarty>
Does wildly different memory use with and without calls to Gc.full_major in a loop indicate something buggy/bad?
2011-01-20
<thelema>
hcarty: It's not unreasonable to provide *.seq and *.of_seq for those situations where enum isn't appropriate
<hcarty>
thelema: Of course, the lack of consumption on Seq.t values could certainly be surprising as well