<hcarty>
_habnabit: What version of Batteries are you using?
<hcarty>
That's odd
<hcarty>
flux: Ah, I suppose that could be a problem :-)
<flux>
hcarty, heh, found out the reason why the build failed: /tmp is full :-)
<hcarty>
flux: It looks like Sid has an older PLplot version as well. I don't remember what has changed since then.
<thelema>
hcarty: great
<hcarty>
flux: Hopefully so
<hcarty>
thelema: I wrote up a quick _oasis file for React. I won't be able to test it until later this evening at the earliest, but in theory that will open up the possibility of an installable utop from odb.
<flux>
hcarty, apt-get build-dep should take care of that
<hcarty>
And I think most of those are enabled for the Debian build
<hcarty>
A minimal PLplot build doesn't require a ton of external items, but the dependency list grows quickly once bindings and other optional pieces come into play.
<hcarty>
flux: That sucks - do you have all of the (very very large number of) build dependencies?
<flux>
hcarty, bah, not even the debian source package dpkg-buildpackage's for me
<hcarty>
I've been contemplating creating a ocaml-plplot-minimal stand alone distribution. It would make the build process simpler, but it is also potentially a lot of work.
<hcarty>
flux: And contributions are welcome, of course :-)
<hcarty>
flux: I emailed him to ask. There are no other OCaml folks among the PLplot developers, so I'm not sure how much will get done.
<hcarty>
flux: Not in its current state. The whole thing (core library plus all language bindings) builds at once.
<hcarty>
One of the other PLplot developers has offered to package the OCaml bindings, but they have not had time
<hcarty>
And Debian packaging looks like deep, dark magic to my untrained eyes.
<hcarty>
flux: No, sadly not. No one has made a package for them.
<flux>
hcarty, hmm, apparently the plplot bindings aren't in debian unstable?-(
<mfp>
hcarty: AFAIK not
<hcarty>
mfp: Is the first valid OCaml?
<hcarty>
The problem seems to be that you can't leave out any pieces. So the string would need to include the minutes and seconds as well.
<hcarty>
Creating the same date using Calendar.lmake, printing it with the format string, then parsing the result with the same format string fails.
<hcarty>
flux: Yes
<hcarty>
CalendarLib.Printer.Calendar.from_fstring "%Y%m%d%H" "1984090100";; -- This raises Invalid_argument and I don't understand why
<hcarty>
Does anyone here with the Calendar library installed mind running a quick test?
2011-07-28
<hcarty>
React shouldn't be too hard to oasis-ify, but I don't think I'll have time for a while
<hcarty>
thelema: The other packages involved (zed and lambda-term and utop) already use oasis
<hcarty>
Or, oasis-db technically I suppose
<hcarty>
I think React is the only major missing piece from odb
<hcarty>
Maybe not yet
<hcarty>
And Lwt... and React
<hcarty>
There are three required, aside from Camomile
<hcarty>
I was going to try and upload the packages
<thelema>
hcarty: I just saw the posting - maybe we can get it installable via odb?
<hcarty>
All that said - once it is setup, utop is quite nice! Probably even a bit better than lwt-toplevel.
<hcarty>
thelema: Never mind - we had this conversation before. The option doesn't exist yet to install packages with more than an OCaml library outside of ~/.odb without using sudo.
<hcarty>
thelema: Is it possible to install Camomile with odb, placing the data files somewhere other than /usr?
2011-07-26
<hcarty>
pdhborges: Ok. Thank you for the bindings and the information.
<pdhborges>
hcarty: no, I created a new one
<hcarty>
pdhborges: Will the zeromq 3 bindings be in the same github repository?
<pdhborges>
hcarty: in about 5 days I'll release the bindings for zmq 3
<hcarty>
pdhborges: Ah! In that case, perhaps I'll wait for version 3.
<hcarty>
pdhborges: I haven't used your bindings yet, but I'm hoping to get a chance to try them out soon
<pdhborges>
hcarty: but I'm writting new ones for ocaml zmq 3
<pdhborges>
hcarty: I'll fix the bugs zmq 2 bindings
<hcarty>
pdhborges: When you have time - what is the state of your zeromq bindings?
2011-07-21
<hcarty>
_habnabit: Each new OSX and GODI release seems to bring up trouble.
<hcarty>
_habnabit: The GODI mailing list may have something in its archive (if it has one?)
2011-07-20
<hcarty>
thelema: I'm not sure - it's been a while so I'd have to think on it
<hcarty>
thelema: Yes
<thelema>
hcarty: did you follow my usage pattern - converting an optional value into an optional function to apply?
<hcarty>
thelema: Option.apply seems like a reasonable name. I've had a use for something like that in the past.
<hcarty>
Nevermind
<hcarty>
Oh.
<hcarty>
thelema: Why ('a -> 'a)?
<hcarty>
Core has probably received more thorough testing since (as I understand it) Core is used pervasively at Jane St.
<hcarty>
Batteries has the benefit of being openly developed, so you can track the progress of bug fixes and new feature development
<hcarty>
They are both worth trying
<hcarty>
As is the *.print structure
<hcarty>
NaCl: The IO system in Batteries is quite nice
<hcarty>
NaCl: Core is probably more consistent in its design than Batteries (although that is improving in Batteries)
<hcarty>
NaCl: Yes, but internally developed rather than community developed
<hcarty>
Batteries and Core have tail-rec List.map functions. Jane St. has posted a number of quick, tail-rec List.map implementations on their OCaml blog.
<hcarty>
eikke: I think it came down to faster for short lists vs tail-recursive for long lists
<hcarty>
eikke: There was some discussion about this on the mailing list at some point.
<hcarty>
bobry: Somewhere around 3.10.0 or 3.11.0 the revised syntax was changed somewhat. The infix operator syntax was one thing to change to match the original syntax.
2011-07-19
<hcarty>
adrien: Then symlink godi_console to the .opt version
<hcarty>
adrien: Ah. I run it manually and copy the native godi_console to godi_console.opt, moving the original to godi_console.byte
<adrien>
hcarty: iirc, yes, but I was trying to make it conditional
<hcarty>
adrien: It's pretty easy ... "make opt" from the correct directory IIRC
<hcarty>
NaCl: That's true. But it does have some nice command line tools if you want to avoid godi_console
<adrien>
hcarty: exactly
<hcarty>
adrien: There are so many optional parameters that it's difficult to find your way around lablgtk.
<hcarty>
adrien: A gross simplification of my experience with lablgtk is that it would make a wonderful base for a usable GUI library.
<adrien>
hcarty: I'd like completion for use with lablgtk
<hcarty>
ocaide may have some kind of context sensitive completion
<hcarty>
Something context sensitive would be cool
<hcarty>
adrien: I've been relying on vim's general completion
<hcarty>
adrien: Agreed
<adrien>
hcarty: would be a good starting point
<hcarty>
adrien: But last I saw they were provided as more of a starting example than a proper implementation.
<hcarty>
adrien: ocamlspotter or a similar project has vim support files for that
<hcarty>
I think that self-consistency is more important when it is known that incompatible changes will be made when the major version changes.
<hcarty>
thelema_: Is it more important for Batteries to be self-consistent, or easy to upgrade between major versions?
<hcarty>
It would be a cool thing to have
<hcarty>
thelema_: That will at least keep both functions consistent within a major release
<hcarty>
thelema_: Fix both in v2 sounds like a good plan
<hcarty>
My preference is global_replace ~str ~by xxx, as it reads somewhat correctly out loud
<hcarty>
The only names a user will see are ~from and ~to (whatever they end up being). No one will ever see the name str unless they read the implementation.
<hcarty>
Its name isn't exposed in the API
<hcarty>
Why not rename the main argument?
<hcarty>
dst kind of implies that's where the result is stored
<hcarty>
You could rename the main argument original or src
<hcarty>
I think ~sub and ~by are a bit confusing together
<hcarty>
or ~str ~by
<hcarty>
Maybe ~orig and ~by?
<hcarty>
thelema_: Is there an regexp support here, or only verbatim strings?
<hcarty__>
gildor: Can you update the #ocaml topic to point to the 3.12.1 release?
<hcarty__>
Or something elsefrom the Constructors section of the Enum documentation.
<hcarty__>
_habnabit: You would probably use something like Enum.I it
<hcarty__>
_habnabit: Your best reference is probably the other modules in Batteries
<hcarty>
thelema: Not yet, but it's on my list
<hcarty>
thelema: Cool. I ran into a similar issue using ( ^^ ) in a logging function.
<thelema>
hcarty: ^^
<hcarty>
thelema: Or ksprintf (tap exit |- ignore) ...
<hcarty>
thelema: I'm not sure I completely follow what you are doing - but would something like "ksprintf ignore ..." work?
<gildor>
hcarty: thx
<hcarty>
gildor: Submitted. #1010
<gildor>
hcarty: that is the same BTS
<hcarty>
gildor: Should oasis and oasis-db bugs/requests go to the same tracker? Or do you have separate tools for each project?
<hcarty>
gildor: That sounds like a good idea. Sort of a light-weight version of the conf-* packages in GODI.
<gildor>
hcarty: e.g. pkg-config libraries, where we will be able to attach various data, like a homepage and a Debian package
<gildor>
hcarty: i.e. package that won't be available/listed on oasis-db but used to gives hint to people
<gildor>
hcarty: I think you could state that it should be coupled with the ability to define "virtual package"
<gildor>
hcarty: good idea, fill a bug report
<hcarty>
Or perhaps s/the//...
<hcarty>
s/the gcc/gcc/
<hcarty>
thelema: That's what I was thinking when I added it :-) h4cc is a wrapper script around the gcc or whichever compiler is used to build the HDF4 library.
<thelema>
hcarty: good idea - I don't think I even know what h4cc is
<hcarty>
gildor: Something as simple as "This is provided with the core OCaml distribution" or "This is provided by omake"
<hcarty>
gildor: I think it may be useful to have a description or origin field for external programs and external libraries on the oasis-db/odb admin panel
<hcarty>
thelema: Oh, that's cool. I'm sorry I didn't do a proper release sooner then :-) Let me know if you have a use for the library and if you have any questions/suggestions.
<thelema>
hcarty: yes, hdf4 is what I was talking about - used by scientists and not many others
<hcarty>
Not likely to be broadly used in the OCaml community that is
<hcarty>
thelema: It's used frequently for satellite data, among other things. Not likely to be broadly used... but I put a lot of time into the bindings as I learned OCaml, so I'd rather they are available for use rather than rotting away somewhere
<hcarty>
thelema: I think that's something different - HDF4 = Hierarchical Data Format v4
<thelema>
hcarty: nice. I've heard of HPF4, and imagine this may make ocaml a bit more convenient for High performance computing
2011-07-10
<hcarty>
thelema: xstrp4 is. The other (bindings for HDF4) will be as soon as I finish a bit of cleaning up and testing.
<thelema>
hcarty: yay - are the libraries available on oasis-db?
<hcarty>
gildor: And in each case the result has been a much simpler and easier to maintain build system.
<hcarty>
gildor: Thank you for your help. I think that I have now successfully ported two libraries to use oasis :-)
<gildor>
hcarty: yes
<hcarty>
gildor: BaseEnvLight.var_get will return values from setup.data, correct?
<hcarty>
gildor: Ah cool, thanks for the pointer
<gildor>
hcarty: I use a combination of oasis generated dispatch and customize dispatch
<hcarty>
gildor: I have this working in my hand-written myocamlbuild.ml, but I would like to move to oasis
<hcarty>
gildor: The only way to automatically get the proper flags is to call a script that comes with the upstream library with a specific option (h4cc -show) and pull the -l and -L arguments from the output.
<hcarty>
gildor: I need to specify some linking options for bindings I'm trying to package with oasis
<hcarty>
gildor: Do you know if you can call Ocamlbuild_plugin.dispatch multiple times in myocamlbuild.ml to accumulate rules, flags, etc.?
<gildor>
hcarty: thx
<hcarty>
gildor: Submitted. #1008.
<hcarty>
gildor: Ok, will do. Thank you!
<gildor>
hcarty: ByteOpt and NativeOpt don't apply to .c file compilation apparently -> this is probably a bug, fill a bug report about that, I'll try to fix it in 0.2.1
<hcarty>
gildor: The -ccopt part may be doable through _oasis... but the '-cc h4cc' is not from what I can tell
<hcarty>
gildor: The only solution I've found so far is to manually modify setup.data to add/change the ocamlbuildflags line : ocamlbuildflags = "-ocamlc 'ocamlfind ocamlc -cc h4cc -ccopt -fPIC'"
<hcarty>
gildor: And "CCOpt: -cc foo" translates to "-ccopt -cc -ccopt foo" on the command line
<hcarty>
gildor: ByteOpt and NativeOpt don't apply to .c file compilation apparently
<hcarty>
gildor: None of CCOpt, ByteOpt, NativeOpt work
<gildor>
hcarty: you can also use ByteOpt: -cc foo and NativeOpt: -cc foo
<gildor>
hcarty: you can use CCOpt, but I wasn't aware of -cc foo
<gildor>
hcarty: Jane St sent me the patch, it will be applied in 0.3
<hcarty>
gildor: I haven't been able to find a way to pass "-cc foo" to the compiler, through an _oasis file, when compiling C
<hcarty>
gildor: On another front, does oasis currently provide a method to override the compiler used with C stubs?
<hcarty>
gildor: It looks like Jane St. is using some form of packed module support in their Core library, but if I recall correctly it was based on something they had worked out locally.
<hcarty>
gildor: Do you have any immediate plans to add packed module support to oasis?
2011-07-08
<hcarty>
Interesting tidbit - add .patch to the end of a github commit URL to get a raw patch for that commit
<hcarty>
thelema: Thank you for the quick fix!
<hcarty>
thelema: Yes, that patch does appear to fix my issue, both using master and the patch applied against 1.3.0
<hcarty>
thelema: Does this mean that the printf format strings in Batteries are not checked (or not fully checked) at compile time?
<hcarty>
thelema: I'm off for a bit, but I'll check later this evening or tomorrow
<thelema>
hcarty: does commit e09c469 fix your problem?
<hcarty>
thelema: #158
<hcarty>
thelema: Issue submitted
<hcarty>
thelema: For some reason, ( ^^ ) seems to be adding a ,
<hcarty>
The same thing works with the stdlib, no batteries
<hcarty>
s/composition/concatenation/ perhaps
<hcarty>
thelema: But that's on my TODO list
<hcarty>
thelema: I need the printf format composition in a few other places as well
<thelema>
hcarty: try using v1.4's Future.Log for that.
<hcarty>
log "foo" -> raises Invalid_argument "printf: bad conversion %,, at char number 4 in format string ``%s %,Hello%,%!''".
<hcarty>
let log format = let header = "LOG" in Printf.printf ("%s " ^^ format ^^ "%!") header
<hcarty>
thelema: I'm getting a strange stdlib/Batteries mismatch using printf format strings
2011-07-07
<hcarty>
_habnabit: Sorry - have to run!
<hcarty>
_habnabit: Do you have pkg_str as one of the tags for your program in _tags?
<hcarty>
thelema: Yes, sorry for the typo
<hcarty>
If it's only an alias then I think the --have-perms-* options would be sufficient, along with a not somewhere on their GODI-relevance
<hcarty>
A user with a self-installed OCaml + findlib in ~/ may still want binaries like oasis in /usr/local/bin/ rather than ~/path/to/ocaml/bin/
<hcarty>
Having both is probably a good idea
<hcarty>
--godi could turn on both, if it's worth having each separately.
<hcarty>
--have-perms-lib --have-perms-bin maybe?
<hcarty>
Or a "--local-godi" option which does both :-)
<hcarty>
thelema: Two options seems like a good idea
<hcarty>
That was fixable with a environment variable IIRC, but it was package-specific.
<hcarty>
The only real gotcha I ran into was "make install" for programs would try to install to somewhere like /usr/local/bin/
<hcarty>
thelema: Thank you for implementing it :-)
<thelema>
hcarty: ah, thanks.
<hcarty>
_habnabit: odb has a --have-perms option which works well with a locally-installed GODI
2011-06-30
<hcarty>
thelema_: It's not pure OCaml, but GSL (via ocamlgsl) provides OCaml with large number of random number distributions
2011-06-29
<hcarty>
s/or/vs/
<hcarty>
thelema_: It would be largely a matter of interpolation everywhere or interpolation only with say/warn
<thelema_>
hcarty: I was, but you're right - that's not necessary
<hcarty>
thelema_: Ah, so are you thinking 'say "Hello $foo"' would be replaced by the extension, not just the '"Hello $foo"' part?
<hcarty>
And use xstrp4.syntax.batteries when compiling
<hcarty>
let say = print_endline
<hcarty>
flux: Nah
<hcarty>
Otherwise it's printf-like say and warn
<hcarty>
thelema_: That's doable with xstrp4 :-)
<hcarty>
warn could be for the logger, but I was thinking more for inclusion in the pervasive section of Batteries
<hcarty>
thelema_: They would be printf and eprintf wrapped up with the automatic addition of a newline character.
<thelema_>
hcarty: warn for the logger?
<hcarty>
thelema_: Would you be interested in a printf-like, Perl-y "say" and "warn" for Batteries?
2011-06-28
<hcarty>
I've considered splitting out the OCaml bindings to make the packaging process easier. That, unfortunately, makes binding upkeep more difficult.
<hcarty>
vivanov: Unfortunately, I'm the only OCaml PLplot developer and I don't have enough time + experience to setup a Debian package
<vivanov>
hcarty: ic
<hcarty>
Maybe unique is the wrong word... I'm sure other libraries exist which do the same. But it's not common.
<hcarty>
vivanov: PLplot is somewhat unique in that the core library + bindings + Debian packaging are all in the same repository
<hcarty>
vivanov: One of the PLplot authors talked about it, but I haven't heard anything since
2011-06-27
<hcarty>
thelema_: Is there a print_maybe function anywhere in Batteries?
2011-06-26
<hcarty>
zorun: Indeed. It's not terribly difficult, but it's not terribly readable either :-)
<zorun>
hcarty: interesting, how do you build a map2 function from mapi?
<hcarty>
zorun, pixelou: My guess is that the stdlib lacks Array.map2 because Array.mapi provides a reasonable, if slightly less pretty, replacement for Array.mapN
<hcarty>
pixelou: You could compute the values from list2 on the fly, if that is simpler
<hcarty>
pixelou: For reference, Arrays can be quite natural in OCaml too. With Batteries you get an equivalent Array.map2 function
2011-06-22
<hcarty>
If I can find a way to fake it with flags then that would be cool. But I don't see an equivalent to the 'env "%.ml"' function rule definitions get
<thelema_>
hcarty: ah, ok.
<hcarty>
thelema_: I've only written one ocamldoc rule before, and I found the process tricky and fraught with peril
<hcarty>
thelema_: Not write a program - copy over the ocamldoc comments manually
<thelema_>
hcarty: you're willing to write a program to transfer comments from .ml to .mli, but not willing to write a new ocamldoc rule?
<hcarty>
thelema_: Likely so. I'm not sure I'm willing to go that far yet.
<thelema_>
hcarty: you'll probably have to make your own rule
<hcarty>
I don't know that there is a way to pass both the .ml and .mli
<hcarty>
mfp: The problem seems to be that ocamlbuild only passes the .mli if one exists
<hcarty>
But they are being passed to ocamlfind ocamldoc, so I'm likely getting something wrong in the invocation
<hcarty>
mfp: "-m A" and "-inv-merge-ml-mli" do not seem to work as I expect them to
<hcarty>
mfp: It looks like it does - I'm adding the flags now to test
<hcarty>
mfp: Is it possible to do that through ocamlbuild?
<mfp>
hcarty: you can even specify which parts/tags are to be merged (and which is preferred) with the -m option (in order to merge everything, -mA should do)
<mfp>
hcarty: actually, ocamldoc *can* merge the docs from the .mli and the .ml
<hcarty>
thelema_: Thanks
<thelema_>
hcarty: I'm pretty sure there's no workaround
<hcarty>
Copying comments from .ml to .mli it is then
<hcarty>
rproust: Ok, thanks. The documentation says that .ml comments are ignored if a .mli is present. I wasn't sure if there was a work-around available.
<rproust>
hcarty: I've never seen it done
<hcarty>
Is it possible to merge documentation comments from foo.ml and foo.mli when building documentation with ocamlbuild?
<hcarty>
I feel special. I just created item #1000 for oasis...
2011-06-21
<hcarty>
thelema_: Thanks for updating the oasis-db package
<thelema_>
hcarty: thanks for testing
<hcarty>
thelema_: Batteries builds here from odb. I'll have to wait a bit for more in depth tests.
<hcarty>
gildor: Nevermind - it looks like "prefix=$SOME_DIR ocaml odb.ml ..." works
<hcarty>
gildor: Particularly where binaries are installed
<hcarty>
gildor: Does the oasis-generated build system support any sort of environment variables for $fooprefix values?
<thelema_>
hcarty: because it has an oasis file that doesn't explicitly list modules it provides. I fixed this in the 2.0, I guess I've not backpatched 1.x
<hcarty>
The info entries aren't there
<hcarty>
thelema_: Odd - "ocaml odb.ml" doesn't list batteries
<hcarty>
thelema_: What are the changes from 1.3.0?
<thelema_>
hcarty: please test 1.4.0pre1
<thelema_>
hcarty: gildor pulled that for me. I'm uploading a 1.4.0pre1 onw
<hcarty>
According to the oasis-db site, the 2.0beta .tar.gz is still the live version
<hcarty>
thelema_: Maybe not? The last time I checked the .tar.gz was still from 2.0beta
<thelema_>
hcarty: yes. it fails to install?
<hcarty>
thelema_: Any chance Batteries could be made installable again from odb?
<hcarty>
thelema_: Cool, thank you
<thelema_>
hcarty: yes, it's like --sudo, except it doesn't run sudo
<hcarty>
thelema_: ocaml odb.ml --have-perms ... will perform the package installation to the default findlib location, correct?
<hcarty>
gildor: Thank you!
<hcarty>
gildor: Ok - once I have a solution I'll submit something
<gildor>
hcarty: don't hesitate to submit a feature request describing your scenario (and maybe the solution you find), so that I will add it for oasis 0.3
<hcarty>
gildor: Thank you! I'll give it a try.
<gildor>
hcarty: i.e. "foo.ml": syntax_camlp4o, dep_of_the_syntax, use_myown_syntax_extension
<hcarty>
gildor: Do you have an example of such a trick or or a suggestion on where to start?
<gildor>
hcarty: you have to apply some extra trick to get it working
<gildor>
hcarty: that is not yet possible, I am afraid
<hcarty>
gildor: Yes, that is correct
<hcarty>
gildor, thelema: I'm still enjoying oasis overall, and being able to upload a .tar.gz to oasis-db and have it "just work" with odb is quite nice
<gildor>
hcarty: hum, you want to use a generated syntax extension from within the build
<hcarty>
gildor: If I understand this myocamlbuild.ml correctly, use_foo tags are only used for compilation and linking.