2011-08-09

<hcarty> bitbckt: I think most of the industry users have their own tools, and/or use GODI.
<hcarty> GODI is quite nice in a lot of ways, but the setup and interface are apparently troublesome on anything other than Linux.
<hcarty> Apparently curl doesn't follow redirects by default
<hcarty> technomancy: Yes, that's why I sent the other URL :-) I ran into the same thing a few days ago when running a test
<technomancy> hcarty: syntax error running odb.ml on line 1
<hcarty> technomancy: Good luck!
<hcarty> ygrek: odb pulls from testing by default
<hcarty> ygrek: By default, it ends up in the "unstable" tree of packages
<hcarty> ygrek: It looks like you uploaded a newer version of extlib to oasis-db
<hcarty> ygrek: Sorry ... I should have provided some context :-)
<technomancy> hcarty: taking a look; thanks
<ygrek> hcarty, what does that mean?
<hcarty> ygrek: Should extlib 1.5.2 be pushed from unstable to testing on oasis-db?
<hcarty> gildor: https://raw.github.com/thelema/odb/master/odb.ml is the correct URL. I'm not sure if this is due to a github change or something else.
<hcarty> gildor: Just a note - the odb download link on the oasis-db website it incorrect
<hcarty> technomancy: That will, assuming no early-development-related issues, allow you to build oasis in your home directory
<hcarty> You would want to curl -O https://raw.github.com/thelema/odb/master/odb.ml
<hcarty> technomancy: Although the download link there is wrong...
<hcarty> technomancy: If you want to start playing with oasis in the mean time, you can try odb
<hcarty> qdl_: You're welcome
<qdl_> @hcarty: Yepp, thanks.
<hcarty> Probably something like "-o my_exe"
<hcarty> qdl_: The ocamlc documentation covers the command line flags, I don't remember them off the top of my head
<hcarty> ocamlbuild, OCamlMakefile and oasis hide all of these things quite nicely.
<hcarty> I think the -custom flag is what you need, but it's been a while since I've used the compilers directly.
<hcarty> qdl_: You want a stand-alone bytecode executable?
<hcarty> qdl_: Ask away - if someone can help then you'll get an answer :-)
<hcarty> philtor: The upstream package had unintentionally changed
<hcarty> philtor: The GODI + PCRE problem is a known issue and apparently fixed now

2011-08-08

<hcarty> Good luck tracking down the problem, whatever it ends up being!
<hcarty> I'm not sure - I've used it on Fedora, Debian and Ubuntu
<hcarty> You can see them from godi_console and probably from somewhere else as well
<hcarty> kfx: There may be configuration options for the godi-ocamlgsl package
<kfx> hcarty: yes that's what I assumed
<hcarty> kfx: It looks like you need to configure ocamlgsl to look at the correct GSL include and lib directories. Or it could be some problem related to those static linking errors.
<hcarty> kfx: It should work? What error(s) are you getting?
<hcarty> kfx: What OS, version of OCaml and version of GSL are you using?
<hcarty> *client
<hcarty> odb provides a simple/proof-of-concept cleint which may eventually grow into more
<hcarty> oasis-db may eventually take care of some or all of them, but oasis-db doesnt't exist as anything other than a server right now.
<hcarty> oasis is just a build system
<hcarty> s/much more simple/much easier/
<hcarty> _habnabit: It's usually more up to date than anything other than possibly Debian Sid; It makes rebuilds of everything much more simple when you update OCaml or a core package; It provides a large number of packages in an easily managed form.
<hcarty> It's already a good portion of the way there
<hcarty> oasis + oasis-db/odb makes the release process simpler, so hopefully that will eventually translate into a simple way to get more timely updates
<hcarty> _habnabit: When the packagers update them. It varies from package to package.

2011-08-07

<hcarty> NaCl: But a few libraries provide dynamically growing arrays
<hcarty> NaCl: No
<hcarty> My hope is that most cases will require 1 - 3 arguments, with more available when further customization is wanted
<adrien> hcarty: otoh, if you have sane defaults unlike gtk, it's going to be easier and shorter
<adrien> hcarty: as long as your arguments fit on two lines or less usually... :P
<hcarty> adrien: Now... is that a good or a bad thing? :-)
<hcarty> Each has 20+ arguments in the C API, so I'm trying to consolidate and provide sane defaults where possible.
<hcarty> This is for the OCaml more OCaml-y, higher level bindings for PLplot's legend and colorbar functions
<hcarty> Thank you both!
<hcarty> Anarchos: That's a good point. Lots of optional parameters also make the available categories of options a bit more discoverable
<adrien> hcarty: I prefer optional arguments then
<hcarty> adrien: Probably not - they are more likely to be specified directly in the code
<Anarchos> hcarty cause grouping them in a list is not logical most of the time
<Anarchos> hcarty i had this problem and i prefer passing lots of optional options with named parameters
<adrien> hcarty: do you want to be able to copy the parameters? like storing them on disk and loading them, or using it in several places?
<hcarty> For example: foo ?color ?length ?width vs foo [`color `red; `length 1; `width 2]
<hcarty> Informal API opinion poll: Given a function with lots of optional configuration options, is it better to have a large number of optional parameters or one (or a few) lists of configuration options?

2011-08-06

<Associat0r> hcarty: I still have to watch the beginning
<hcarty> Associat0r: I'm about an hour into his talk. He's an interesting developer to follow.
<hcarty> s/packages/packaged/
<hcarty> Along with the problem of the OCaml bindings not being packages
<hcarty> It exists now, so when 5.9.8 (or 5.9.9) ends up in Debian the problem should be fixed
<hcarty> flux: I just grabbed the 5.9.5 source and it looks like the .mli install was missing at that time
<flux> hcarty, 5.9.5
<hcarty> It's quite possible that it's a more recent addition
<hcarty> flux: Which version had you tested with?
<flux> hcarty, maybe it's the new version then
<hcarty> flux: A slight diversion - PLplot does install its .mli on my system, next to the .cm? files
<hcarty> flux: Indeed
<hcarty> flux: I think that should be possible to build that on top of xstrp4
<flux> hcarty, hmph :)
<hcarty> flux: Next week! Assuming that you submit a patch by the middle of the week :-D
<flux> hcarty, so when is xstrp4 going to have string macro expansion (expanding multiple string fragments into a compile time string literal) for me to use with PGOCaml?-)
<hcarty> adrien: I hope it works well for you!
<adrien> flux: well, you might want to harass hcarty about that ;p
<adrien> hcarty: awesome, thanks!
<hcarty> adrien: xstrp4 2.0alpha5 is available and on oasis-db/odb. It fixes both the "You can't say file!" issue and error location reporting.

2011-08-05

<hcarty> _habnabit: You would have to define a class type, or used an already defined class type if one exists
<hcarty> _habnabit: You may need to do an explicit type cast
<hcarty> _habnabit: There may be something in the BatIO module
<NaCl> hcarty: yeah, it does, but I read some of it, and it said that the C matrix type was obsolete
<hcarty> NaCl: If you take the C++ route, cxx_wrapped may help: http://ygrek.org.ua/p/ocaml.html
<hcarty> NaCl: Does openCV provide a C interface? That may or may not be easier to wrap, depending on the approach you take
<hcarty> ( |> ) is used for ( >> ) in Batteries, and I think Core uses ( |! )
<hcarty> ( & ) can cause conflicts with JoCaml
<hcarty> ( >> ) can cause conflicts with camlp4
<hcarty> ( >> ) and ( & ) need a bit of care - ( >>
<hcarty> If not then it's probably a reasonable compromise. Those are the only two types OCaml supports natively anyway.
<hcarty> Do you lose any functionality (beyond support for other types) when you do that?
<hcarty> NaCl: Or restrict the initial bindings to only support one type (ex. OCaml floats <-> C/C++ doubles)
<hcarty> NaCl: You could use multiple modules or functors to support the variable data types in OpenCV
<hcarty> _habnabit: There are some signature tricks you can play with 3.12.x+ to make it work, but beyond that I don't think that there is any way to do that.

2011-08-04

<hcarty> adrien: Good luck with the testing!
<hcarty> adrien: Ok, I'll wait to push anything out until I either hear from you again or I get error location reporting to work properly.
<adrien> hcarty: I won't have time right now: I need to finish some code before it gets tested on cars this weekend (glups!) and before I leave for Berlin (desktopsummit.org)
<hcarty> adrien: I have a fix for the "file" problem in xstrp4. I can send you a patch now or push the changes out as another release some time later today or tomorrow.

2011-08-03

<hcarty> Functions can be passed around as values
<hcarty> Should work
<hcarty> let x = if y then ImplA.make else ImplB.make in Interface.perform x --> as long as ImplA.make and ImplB.make have the same type
<hcarty> _habnabit: The example you gave should work just fine
<sgnb> hcarty: well... I don't use either myself, but there are other packages in Debian that depend on these (mlpost, ocamlviz)
<hcarty> Christophe Troestler's bindings also seem to be more complete in their API coverage.
<hcarty> s/state/stated/
<hcarty> sgnb: It may not help with this specific bug, but Christophe Troestler wrote a separate Cairo binding. Part of the reason he state for doing this is the large number of memory management bugs in the existing binding.
<NaCl> hcarty: now *that* makes more sense
<hcarty> Oh, and bindings for OpenCV too!
<hcarty> adrien: I haven't used rsvg, but given how complex SVG appears to be that seems reasonable.
<adrien> hcarty: I found rsvg to be pretty bad actually
<hcarty> librsvg and Cairo would give you a start. The result may not perform well.
<adrien> hcarty: actually it might be through some other library that this would work: plplot <-> gtk <-> lablgtk <-> X <-> Graphics
<hcarty> s/complete/correct/
<hcarty> adrien: Cairo/Gtk is already supported, so clearly the next step should be using the Gtk <-> Graphics integration to complete this horrible oversight :-)
<adrien> hcarty: actually I think that cairo/gtk is more valuable ;-)
<hcarty> It may not be useful, but I'm sure it could be done!
<hcarty> I'm guessing that the two could be made to work together...
<hcarty> adrien: It has been known for a while that PLplot's biggest fault is its lack of support for the Graphics module
<hcarty> adrien: Everyone ... must ... use ... PLplot
<adrien> flux: run! hcarty is going to make sure you can't not use plplot this time :P
<hcarty> flux: I just got an email from Andrew Ross, one of the PLplot developers and the maintainer of the Debian packages. He is working on getting the 5.9.8 release ready for Debian, including the OCaml bindings.
<hcarty> kaustuv: As one who doesn't use BatLazyList, those seem like good ideas.
<hcarty> ttamttam: You're welcome, and good luck!
<ttamttam> hcarty: you already helped! Thanks. I will ask when I have more up-to-date versions.
<hcarty> Not 0.8.1 or later
<hcarty> ttamttam: Ah - it looks like you need Camomile 0.8.2 or later
<hcarty> ttamttam: But thelema should be able to provide you with some more information on how to accomplish this
<hcarty> ttamttam: I can't provide much more help - to be honest, I'm waiting for Batteries 2.0 which will remove the Camomile dependency :-)
<ttamttam> hcarty: oups. I mixed versions of two of my machines. I will try with the right one.
<ttamttam> hcarty: I set CAMOMILE_DIR in the env, but it is not taken into account.
<adrien> hcarty: yeah, afaiu, it's mostly a leftover from a previous version of the syntax
<hcarty> ttamttam: I think Batteries does by default if Camomile 0.8.1 or later is used.
<ttamttam> hcarty: Camomile version is checked during batterie installation (I use the very last version of camomile I could. But I do not know how to instruct Batterie to use CamomileLibraryDyn?
<hcarty> adrien: Patches are welcome :-D I haven't used that beyond some basic testing, but my guess is that changing line 45 of http://0ok.org/cgit/cgit.cgi/xstrp4/tree/src/xstrp4_here.ml to ... "interpolate_file" ... rather than ... "interpolate"; "file" ... would do the trick
<hcarty> ttamttam: thelema will be able to give a better answer. But Batteries may Just Work assuming you build against a new enough Camomile and set the appropriate environment variable(s).
<hcarty> ttamttam: I'm not sure of the specifics. Batteries 1.3.0 introduced some support for this, but I think you need to use Camomile 0.8.1 or later.
<adrien> hcarty: well, and using syntax_here? :P
<ttamttam> hcarty: did you see my question of this morning?
<hcarty> adrien: That's possible as long as you don't use xstrp4.syntax.compat or xstrp4.syntax.syntax_here :-)
<hcarty> The major things standing in the way of a proper beta release are: (a) fixing the reported location of errors (b) documentation (c) hearing back from Gerd
<hcarty> Plus, I'd like to keep it odb-installable
<hcarty> I'll continue to maintain my fork for now - I have found the changes to be quite useful in my code
<hcarty> I agree - I'd rather have one true xstrp4 rather than the confusion of multiple
<hcarty> adrien: He provided me with some help to get started in hacking on xstrp4, but I haven't heard from him since then. He's been quite busy from what I understand, so it may be a while before I hear back.
<hcarty> adrien: I have sent a few emails, both before I started to ask him for some advice on how to start with my experiments and once I had something working to let him know about the state of my work
<adrien> hcarty: is he already aware fo it?
<hcarty> s/more/my/
<hcarty> adrien: Yes, xstrp4 is more fork of Gerd's original xstrp4 1.8
<gildor> ttamttam: that is a question for thelema or hcarty
<adrien> hcarty: xstrp4 2 is your fork?
<hcarty> thelema: xstrp4 2.0a4 also has xstrp4.syntax.batteries_strings which allows for fun things like: let s = "Hello $name. The list is ${l, List.print Int.print}"
<hcarty> xstrp4 2.0alpha4 is up on oasis-db/odb now, including a module for compatibility with xstrp4 1.8

2011-08-02

<hcarty> I think later versions may have switched to (\ \1 < 5)
<hcarty> The original version let you use (\ _ < 5)
<hcarty> pa_holes I think
<hcarty> bluestorm wrote a syntax extension which would give you something close
<hcarty> Ah, as opposed to (( > ) 5) or (fun x -> x < 5)
<hcarty> thelema: You're welcome
<hcarty> In Haskell
<hcarty> _habnabit: What are sections?
<thelema> hcarty: thanks for looking that over
<hcarty> thelema: Also, (Option.map_default f def opt) vs (Result.default_map def f res)
<hcarty> thelema: s/make/match/
<hcarty> thelema: BatResult.default_map -> BatResult.map_default to make BatOption?
<adrien> hcarty: yeah, I saw that ;-)
<hcarty> vext01: Both are right in different contexts
<hcarty> adrien: Another plug - PLplot supports Qt as well....
<adrien> hcarty: yeah, probably, but C++ ='(
<hcarty> Even if having to work in C++ on Windows is sad :-)
<hcarty> I haven't used PLplot's C++ support beyond building and running the examples, but all of the same features should be supported there
<hcarty> adrien: That should still be possible :-)
<adrien> hcarty: well, what is going to hurt is that it will be on windows and might be with C++ ='(
<hcarty> adrien: There is no built-in panning support, but I've done something like this when mixing PLplot + Cairo + lablgtk2
<hcarty> adrien, flux: I'd like to write a few blog/wiki/documentation articles on using PLplot with OCaml. If you find information which is missing and would be useful for documentation it may give me something to start with
<adrien> hcarty: btw, I had one question: is there something to be able to "pan" the plot? and something to get the coordinates of the cursor in the plot? (haven't had time to check yet, I'm still on something else)
<adrien> hcarty: sure
<hcarty> adrien: My only request is that you provide feedback :-) But even if you don't - have fun with it!
<hcarty> flux: Ah, too bad! But going from pure Cairo to Cairo + PLplot requires very little if/when you decide to make the jump :-)
<hcarty> You can then use that surface as you see fit - the original Cairo bindings provide a way to get PNG contents as a string, for example.
<hcarty> The Plcairo module has functions to allow a user to supply their own Cairo surface to draw on.
<hcarty> flux: I don't this so. The SVG output device writes directly to disk IIRC.
<flux> hcarty, would it be simpler for svg?
<hcarty> flux: You can create a PNG in memory using the Plcairo library + the OCaml Cairo bindings
<hcarty> flux: The OCaml section of the documentation gives a quick overview of the OCaml interface and its components
<hcarty> flux: Some documentation at least :-) The core C API is well documented and available more or less in raw form from OCaml
<flux> hcarty, does it provide means to write into memory and then produce a png into an ocaml string?
<hcarty> Some are not, either due to poorly supported types or function callbacks
<hcarty> Yes, most of the bindings are generated with camlidl
<hcarty> flux: Thanks for the tip on the copyright
<flux> hcarty, so the bindings are generated from an idl file? (btw, the idl-file's copyright is 2007,2008)
<hcarty> let plug = "It does add nice legend support and some (very) experimental color bar support"
<hcarty> flux: Glad to hear it. 5.9.8 was just released, without too many OCaml changes.
<flux> hcarty, also I'm this -> <- close to trying plplot/ocaml once I figure ocsigen a bit further :)
<hcarty> But only until oasis-db/odb/etc are in full swing!

2011-08-01

<hcarty> thelema: I think BatList has a group_by or similar function to do the splitting
<hcarty> thelema: Split the list into AB C BA ...; sort each AB/BA list; join the resulting lists back together
<hcarty> NaCl: What bugs have you run up against?
<hcarty> thelema: It even provides a bit of minor syntax highlighting if you copy over one of the example rc files
<hcarty> thelema: It may be utop scanning through the available modules for its completion information
<hcarty> Editing that may work too
<hcarty> export CAML_LD_LIBRARY_PATH=/path/to/stublibs:$CAML_LD_LIBRARY_PATH
<hcarty> thelema: Ah - depending on where lwt was installed, you may need to set CAML_LD_LIBRARY_PATH
<hcarty> Yes
<hcarty> Oh, one more - the utils/ directory is included as well
<hcarty> thelema: You're welcome. GODI copies *.cmi, *.cmi, *.o and *.cmx
<hcarty> thelema: From typing/ and parsing/ in the source tree to wherever the compiler will find them by default
<hcarty> thelema: It looks like GODI installs the extra compiler libraries by copying them over manually.
<hcarty> thelema: I think GODI has a separate package for the compiler libraries... I'm not sure how you would do this from a raw source install
<thelema> hcarty: 3.12.1
<hcarty> thelema: What version of OCaml?
<hcarty> thelema: I think it's worth doing, now that React is in oasis-db
<hcarty> thelema: Cool. It won't be pulled in automatically as it is not listed as a dependency of Lwt
<hcarty> thelema: You need to install react first
<hcarty> thelema: Oops
<hcarty> thelema: I think that should do it
<hcarty> thelema: ocaml odb.ml --configure-flags --enable-react lwt && ocaml odb.ml utop
<thelema> hcarty: what's the command to install utop via odb?
<hcarty_> Testing and tweaking - it's easier to blow out and rebuild .odb than all of godi if something goes wrong
<hcarty_> Mostly for packages with binaries installed in bin I would think
<hcarty_> I'm not sure which is the best default, but I think it would be good to support both
<hcarty_> thelema: The flag would allow a godi user to keep odb packages in the .odb directory
<thelema> hcarty: is --godi needed - can't the existence of the godi environment variable trigger that behavior?
<hcarty> thelema: Each one is pretty trivial. If one or more of them gets cut later I won't be offended :-)
<hcarty> thelema: Let me know if it works and/or if I need to change anything!
<hcarty> thelema: This is my first time using github as anything other than a tool for working with someone else's project... I forked, pushed and submitted a pull request
<adrien> hcarty: ok, I know how to make godi packages now anyway ;-)
<hcarty> thelema: Fork and then send a request?
<hcarty> adrien: It, in theory, would make using odb with GODI a bit easier. But it would not ease creating a GODI package.
<adrien> hcarty: could be used from inside godi,
<hcarty> thelema: Ok. What's the process to perform a push request?
<hcarty> adrien: Not much - it adds a --godi flag which automatically sets "--prefix $GODI_LOCALBASE" for all packages
<thelema> hcarty: nope, deleting that still results in failure
<hcarty> thelema: Oh - maybe due to the commit hash at the top?
<adrien> hcarty: what does the godi-patch do?
<hcarty> thelema: If you are interested in those as well
<hcarty> thelema: I also have a --godi flag patch and a Arg.align patch which cleans up the --help output a bit
<thelema> hcarty: thanks, I'll apply this now
<hcarty> thelema: A patch for odb.ml that is
<hcarty> thelema: http://vpaste.net/HtsWi? -- A patch which should allow flags to be passed to both explicitly installed packages and/or to explicity installed packages + automatically installed packages

2011-07-29

<NaCl> hcarty: what deps did it pull in?
<hcarty> thelema: I now have an odb-installed utop running
<hcarty> thelema: A proof of concept change to odb worked. I'll try to get something more robust together as soon as possible.
<hcarty> thelema: If you don't get a chance, I will try to get a patch together for odb which allows you to pass configure flags
<hcarty> It's likely related to that
<hcarty> dsheets1: They are having some DNS issues
<hcarty> NaCl: :-)
<NaCl> hcarty: I've done this for more than 20 different libraries.
<hcarty> Although I imagine one could create an oasis plugin to generate .spec files
<hcarty> NaCl: OS-level packages are, understandably, more complicated
<hcarty> NaCl: I lucked out ... the upstream author, gildor and thelema did all the work for me - I just had to upload the package to oasis-db
<hcarty> thelema: Once that Lwt build issue is addressed, it looks like utop should be installable from odb
<hcarty> thelema: Does odb.ml provide a way to pass configure arguments to packages? It doesn't look like it does from browsing the code.
<hcarty> thelema: Small (?) snag - Lwt builds, but doesn't build with its React support
<hcarty> Given available time, of course.
<hcarty> thelema: In that case, test early, test often!
<hcarty> thelema: Fair point... if it works with Batteries and oasis there is no reason it wouldn't here...
<thelema> hcarty: no reason to suspect it won't cascade, but ok.
<hcarty> To ensure everything cascades along properly
<hcarty> thelema: Don't test until utop goes up of course :-)
<hcarty> thelema: Step 1 was trivial (zed). Now on to the others...
<thelema> hcarty: react installed trivially via odb - I hope utop goes as easily
<hcarty> thelema: I'll try uploading utop and its dependencies
<hcarty> thelema: React is available via odb now if you get a chance to test and confirm
<thelema> hcarty: I tried to find the source package for ocaml in godi and failed to discover it among the gazillion packages
<hcarty> thelema: In the future - GODI has a number of mirrors which have source packages available for OCaml and the libraries in GODI.
<hcarty> I'm just testing :-)
<hcarty> I think that's someone else. Michael Ekstrand maybe.
<hcarty> thelema: Cool, I'll give it a try here
<hcarty> thelema: Something about .cm? files causing ocamlbuild to fail
<thelema> hcarty: it seems fixed - I upgraded to 3.12.1 with no batteries build problems with batteries 1.4.1
<hcarty> thelema: I think it was an ocamlbuild issue
<thelema> hcarty: if so, it is included in 1.4.1
<thelema> hcarty: or was the -link thing on ocamlbuild the fix for the 3.12.1 problem?
<thelema> hcarty: what's the problem with 3.12.1 again? I thought it was this hashtbl problem, but that looks like it'll be in 3.13, not 3.12.1
<thelema> hcarty: that would have been a good thing to get in 1.4.1
<thelema> hcarty: not 3.12.1 yet, I still need to work on that.
<hcarty> flux: Feedback on the bindings are more than welcome. They were primarily developed somewhat on an as-needed basis - I tried to be consistent, but it may not be overall.
<hcarty> thelema: 1.4.1 fixes the Set bug and the 3.12.1 incompatibility?
<hcarty> flux: Thanks! I'll look into that and make the change.
<flux> hcarty, you've got it!
<hcarty> flux: hez 0ok org
<flux> hcarty, what's your email?
<hcarty> flux: I thought it did install the .mli - could you send me an email or post a bug about that?
<flux> hcarty, it would be nice if plplot for ocaml installed the .mli file as well, not just the binaries
<hcarty> _habnabit: I think the Set and Map modules were largely rewritten for 1.4.0
<hcarty> I should soon though, as there is a development release planned for this weekend.
<hcarty> flux: I haven't done a full, all bindings + all output devices build in a while.
<hcarty> flux: I'm not sure - if a full test suite is run then multiple gigabytes. If not... it could be as much as 100 megabytes or a few hundred possibly.
<flux> hcarty, btw, do you happen to have an idea space does how much plplot take to build?
<hcarty> _habnabit: That's probably the simplest way
<hcarty> _habnabit: ocamlfind list |grep batteries
<_habnabit> hcarty, how can I find out?
<hcarty> That's a rather unfortunate bug