<flux>
hcarty, however I still don't think they should be packaged with findlib
<flux>
hcarty, he didn't say the libraries that currently come with META cannot continue coming with META
<hcarty>
If they were included in findlib
<hcarty>
flux: Each new library would need a new findlib release to get the new META file.
<hcarty>
Putting all of the META files in findlib means that you need a new findlib release every time a new library release comes out.
<hcarty>
I disagree - particularly when many (most?) OCaml library authors are also findlib users themselves.
<hcarty>
Then it is up to the upstream author to accept or not accept the contribution.
<hcarty>
Leading to things like GODI and Debian having different findlib names for the camlzip library.
<hcarty>
blue_prawn: But if the effort doesn't go upstream, then everyones' individual efforts end up diverging
<thelema>
hcarty: ok, we're only going to solve one problem by going upstream, the other will have to be solved by godi. gotcha
<hcarty>
Compiling with findlib is certainly much simpler than compiling without.
<hcarty>
blue_prawn: One generally only has to write META files for new libraries. And the META file format is very simple.
<hcarty>
thelema: Even if the Makefile isn't patched at all, if Xavier Leroy includes a META file it will mean that downstream will be consistent.
<thelema>
hcarty: ok
<hcarty>
thelema: That part can be patched in on the GODI side
<hcarty>
blue_prawn: How so?
<hcarty>
ocamlgsl has findlib and non-findlib installation options, for example.
<hcarty>
thelema: He may still accept the patch though, if it leaves non-findlib installation in place
<hcarty>
flux: That is rather problematic :-)
<hcarty>
It has, from what I understand, been around the longest.
<hcarty>
thelema: An emailed patch would be good. I think that the Debian META file would be best for the camlzip package.
<hcarty>
thelema: And adding appropriate make target(s)
<hcarty>
thelema: Upstream would be best.
<hcarty>
There is actually an ongoing discussion about getting it upstream, as GODI uses a different naming convention than the others...
<hcarty>
thelema: camlzip already has META files in GODI, Debian and Fedora
<hcarty>
But even if not, the META files are generally useful since they are required for findlib support.
<hcarty>
GODI requires findlib support, IIRC
<hcarty>
Perhaps a better way to put it - the META files are specific to findlib, not the distribution.
<hcarty>
Yes, it's findlib for GODI, Debian, Fedora, etc.
<hcarty>
And there is the option of installing GODI. But that may be more than you want to do if you're not using it in general.
<hcarty>
Patches/wrappers to implement those targets would help.
<hcarty>
thelema: Also, to make packaging possible/easier with godiva, there should be specific make targets.
<hcarty>
thelema: :-) Getting working META files for packages that don't have them already is a start
<hcarty>
If anyone is attempting a package for a particular library, please indicate it on the wiki page next to the library listing.
<cedric___>
hcarty: no, I have no questions, but as I did the mlpost package (and cairo too), I could explain what I did if any question about it. Furthermore, if there is a way I get a GODI account, I could maintain it.
<hcarty>
bluestorm: We can discuss this when you are around, but I'm not sure if it is better to push packages today, or post the results to the GODI mailing list and request comments there
<hcarty>
bluestorm: I do not have an account to push packages to GODI, but Yoric[DT] does.
<hcarty>
cedric___: Do you have any particular questions?
<hcarty>
cedric___: There is no official format - just the hope that folks will work on packaging libraries for GODI today :-)
<kaustuv_`>
wait until hcarty or bluestorm show up for more official news
<bluestorm>
hcarty: I'll come back this evening, and wish you good luck with the sprint until then
<hcarty>
Some of those rules/compiler facts have changed, but from what I understand they are still mostly true.
<hcarty>
flux: Glad you were able to build it and have it work.
<hcarty>
Not for the Cairo case anyway.
<hcarty>
flux: No, not yet :-)
<hcarty>
flux: Yes, it's generally a pretty quick library to build. Though if you have a compiler for all of the available bindings and build the examples for all of them it can be a bit longer.
<hcarty>
bluestorm: prelude.ml?
<hcarty>
Building from the commandline, I would do (from the source checkout) : "mkdir build && cd build && cmake ../ && make"
<hcarty>
cmake creates the Makefile(s), then make builds everything.
<hcarty>
flux: cmake gets called before everything else
<hcarty>
No one has put together the OCaml package though.
<hcarty>
There is a debian/ directory in the source tree if it helps at all.
<hcarty>
I'm not certain. I've never made a Debian package. But my guess is that you would create a build directory, call cmake from there, then install the appropriate files from $SRC/build/bindings/ocaml/ and $SRC/build/examples/ocaml/
<hcarty>
flux: Yes, I haven't put together anything special yet :-) That's more for syntax at this point.
<hcarty>
flux: The real non-.in files are generated by cmake
<hcarty>
flux: If you do feel up to it at some point, http://ocaml.pastebin.com/m652c729a is a brief example of using the Plplot.Plot module.
<flux>
hcarty, how do I generate the real files fron *.in-files? I'd like to generate a debian package
<hcarty>
bluestorm: Nice, thanks.
<hcarty>
flux: The biggest challenge on an older Ubuntu is probably making sure you have a new enough CMake version (2.6.x IIRC, which may be in backports).
<hcarty>
flux: Ah, ok. The OCaml bindings are part of PLplot itself, so the whole thing would be built together.
<flux>
hcarty, no.. it looks somewhat of an ordeal to be honest ;). if the version must match, the svn HEAD and my (old) ubuntu version are not likely to match..
<hcarty>
flux: Have you had a chance to build+try the PLplot updates?
<hcarty>
bluestorm: Yes, the more pure-OCaml the better as they are very easy to package.
<hcarty>
Getting Cedric Auger's packages from the mailing list posting in to GODI would be nice as a lot of the work is already done
<hcarty>
bluestorm: Oh, cool - those were added by other folks.
<hcarty>
Not that I know of, though META files could be reused.
<bluestorm>
hcarty: did you increase the packaging suggestions, or did they just popped by themselves on the wiki since your mailing list posting ?
<hcarty>
flux: Very true :-)
<hcarty>
flux: Ah, right. I think I remember someone writing about this in a post on why they release their OCaml libraries under the GPL rather than LGPL.
<flux>
hcarty, I think it has implications in ocaml as it doesn't have shared libraries..
<hcarty>
flux: I do not as I was sticking with the license of the rest of the library. Is the lack of one a problem?
<flux>
hcarty, btw, do you have a linking exception in the LGPL of PlPlot bindings?
<bluestorm>
hcarty: glad to see you posted on the ML
<hcarty>
flux: No examples yet, but the Plplot.Plot and Plplot.Quick_plot code is pushed out to the main PLplot Subversion repository now if you want to take a look.
2009-09-07
<hcarty>
Thanks
<hcarty>
I have some 24 hour/diurnal information which I think they would work very well for.
<hcarty>
flux: Very nice - do you mind if I use that idea/encoding?
<hcarty>
But, of course, none of this means much without examples.
<hcarty>
And, with the Cairo OCaml bindings, you can embed plots in lablgtk2 windows.
<hcarty>
And yes, it is posisble, transparency and everything :-)
<hcarty>
I'm working on something similar.
<hcarty>
The clocks?
<hcarty>
But if you get PLplot building in its current state then you'll be all set for the updates.
<hcarty>
I haven't pushed the Plot or Quick_plot modules yet
<hcarty>
plplot.sf.net
<hcarty>
I should be able to get a few examples out as well.
<hcarty>
I'll be back in an hour or few, make a few touch-ups and then push out the code.
<hcarty>
flux: Yes, that's next on my todo list.
<hcarty>
flux: Very good point.
<flux>
hcarty, you know what would be extremely nice: examples
<hcarty>
flux: I haven't decided - which is part of why I'm happy to hear comments from others.
<hcarty>
.points does the same for points, and .image does the same for a float array array
<hcarty>
Quick_plot allows things like "Quick_plot.lines [xs0;xs1;xs2] [ys0;ys1;ys2];;" and it will give you a window with 3 lines, for example.
<hcarty>
If you're interested in testing
<hcarty>
flux: I have the code just about ready to push
<hcarty>
Specifically, the Plplot.Plot and Plplot.Quick_plot modules.
<hcarty>
If anyone is interested/has time, this is an RFC on a more OCaml-specific plotting (PLplot) module interface: http://0ok.org/ocaml/plplot/doc/
2009-09-06
<hcarty>
Something similar to "@param (x0, x1, y0, y1) Description here"
<hcarty>
Is there a way to group parameters for ocamldoc with the @param tag?
<hcarty>
Camarade_Tux: <lie> You don't need flash </lie>
2009-09-05
<Yoric[DT]>
hcarty: ping
<Camarade_Tux>
hcarty: vbox can't do 64bit guest on 32bit host if you don't have hardware virtualization support
2009-09-04
<hcarty>
kaustuv: Indeed. I was hoping for a bit more from it, but it appears that it needs a lot more love before it's a reasonable ocaml replacement.
<hcarty>
I reported a bug on mantis. Hopefully it will be addressed.
<hcarty>
That's true - he spoke/wrote several messages about it.
<Camarade_Tux>
hcarty: you might want to try with 3.11.0, I remember that Harrop used ocamlnat successfully
<hcarty>
I don't think people really are. It's labeled as experimental and unsupported.
<hcarty>
Camarade_Tux: 3.11.1
<hcarty>
I'm wondering if I missed something in the build
<hcarty>
In both cases, the toplevel dies and boots me back to the command line.
<hcarty>
Which, interestingly enough, is exactly the same error "#use "topfind";;" gave in a separate ocamlnat session.
<hcarty>
Yes
<hcarty>
This happens whenever I try to do anything with the Toploop module.
<hcarty>
There is apparently some issue with the Toploop module, at least with my build. ">> Fatal error: Opttoploop.dll_run /tmp/camlTOP432aa8b.so: undefined symbol: camlToploop"
<hcarty>
Compilation is thankfully quite quick with OCaml. But a toplevel would be even nicer during development.
<hcarty>
findlib support is my main concern.
<hcarty>
The labltk2 toplevel conditions may be easily reproducible under a vanilla toplevel though, so that's further down the list.
<hcarty>
I have some data analysis I'm working on, where it would be very nice to have the flexibility of the toplevel, speed of execution of native code, and a threaded GUI.
<hcarty>
Then hopefully I can get a native-code version of the lablgtk2 toplevel.
<hcarty>
I'm building ocamlnat now. Hopefully making the two play nicely together won't be overly difficult.
<hcarty>
Does findlib work with the native code toplevel (ocamlnat)?
<hcarty>
It's too bad OSX can't be (easily?) run under a VM. My advisor is a Mac person and I'd like to be able to hand off binaries for him to use.
<hcarty>
I should probably re-install a Win7 RC VM for testing as well.
<Camarade_Tux>
hcarty: the reason is that despite being on 64bit, I can't have any 64bit machine, I've tried several VMs but never succeeded (qemu could but it doesn't support windows well)
<hcarty>
And thanks for the affection :-)
<hcarty>
But the expanded compatibility is likely a larger plus at this point.
<hcarty>
There are certainly exceptions to that.
<hcarty>
I think that the limitations of OCaml on 32bit are less important for general testing and evaluation of the language and libraries.
<hcarty>
Start with something like the moblin images :-)
<hcarty>
Camarade_Tux: I think most of the customization will be in the appearance - make it REALLY obvious where everything is.
<hcarty>
Yes, local docs are a must.
<hcarty>
Camarade_Tux: Good call :-)
<hcarty>
thelema: Yes, definitely
<hcarty>
Camarade_Tux: That's the hope :-)
<hcarty>
Emacs tweaked to be simpler to get started with ... CUA mode perhaps.
<hcarty>
A simplified Ubuntu desktop may be a good start. Provide OCaml + Batteries + (other libraries) + emacs + tuareg.
<hcarty>
I think qemu can, but it's not as quick or easy to setup on non-Linux systems as virtualbox
<hcarty>
thelema: I think virtualbox on supports 64bit guests on 64bit hosts.
<hcarty>
ocamlcore may host as well
<hcarty>
Probably running either Debian or Ubuntu, and 32bit to maximize compatibility.
<hcarty>
If I get a few hours to play around with it then I may give it a shot, just as a proof of concept. Not sure if/when I will have the opportunity though.
<hcarty>
Problem solved :-)
<hcarty>
I'm not sure where it could be hosted. But it should be easier to keep up to date than an ISO.
<hcarty>
I think a virtual image (for virtualbox, as Camarade_Tux suggests) would be useful in the longer term.
2009-09-03
<hcarty>
flux: Yes, the non-camlp4 Batteries features are certainly its major strengths :-)
<hcarty>
camlp4 bugs are a large part of why (from what I understand) Batteries is aimed mostly at 3.11.x
<hcarty>
flux: There are LOTS of camlp4+toplevel bugs in OCaml 3.10.x
<hcarty>
Camarade_Tux: You shouldn't have to do that, but since the version comparison is getting in the way it's needed.
<hcarty>
I don't think GODI will pick up the new one without that
<Camarade_Tux>
hcarty: argh, no
<hcarty>
Camarade_Tux: Have you removed/uninstall Batteries?
<hcarty>
This is rather problematic.
<hcarty>
Yoric[DT]: Yes - GODI reads the old package as having a newer/higher version than the new package.
<hcarty>
Camarade_Tux: Any .tar.gz or .tgz with 0.200900405 in the name
<hcarty>
If anyone has the beta1 package sitting around in their godi/ package directory, it won't grab the actually-newer-but-looks-older files.
<hcarty>
This may be a bigger issue than just an out-of-sync mirror.
<hcarty>
Oh - remove your local batteries files
<hcarty>
It may take some time for the update to pass through?
<hcarty>
Hmm.
<hcarty>
godi.0ok.org now silently redirects to the main GODI mirror though.
<hcarty>
(with good reason, I suppose)
<hcarty>
My guess is that Gerd's update scripts rely on that not happening.
<hcarty>
Camarade_Tux: godi.0ok.org was moved to a different server (it's a shared host) and I think the SSH key was changed in the process.
<hcarty>
Camarade_Tux: Please try again
<Camarade_Tux>
hcarty: is it possible to sort the mirrors differently?
<hcarty>
So that 00405 > 09xx
<hcarty>
I'm guessing this is all down to some error/problem in the version comparisons.
<hcarty>
I may have to just disable godi.0ok.org for now
<hcarty>
Yoric[DT]: I haven't heard anything from Gerd
<hcarty>
thelema: Yes, GODI polish + distro packages + a community OCaml installer for Windows would address a lot of the concerns I think.
<hcarty>
thelema: That's wonderful news. The list postings seem largely positive, with good feedback.
<hcarty>
But the plan is to have someone around to help/collaborate all day.
<hcarty>
Yoric[DT]: :-) Presence by individuals does not have to be all day
<hcarty>
Likely Wednesday all day.
<hcarty>
If there is anyone here now who wasn't around for the discussion yesterday - any interest in a OCaml library install/GODI-packaging sprint next week?
<hcarty>
Yoric[DT]: Ok, that's good to know. I can't start on it yet, but I would be happy to help with a tutorial-writing effort.
<hcarty>
Yoric[DT]: Are any of your recent (current?) talks suitable material for this?
<hcarty>
Something that new users, at least ones using GODI, Debian-recent, Ubuntu-recent and Fedora-recent, can get their feet wet with.
<hcarty>
thelema: Given the feedback from your list post so far, perhaps a Batteries-centric OCaml tutorial would be a good thing to put together?
<hcarty>
flux: That's a very good point (no packages for non-current distributions). Semi-official backports would probably be helpful. Likely time consuming as well, though, as OCaml itself would probably have to be backported.
<hcarty>
(4) is harder to get around, and possibly (5) as well. (5) in the case of an absent findlib would hopefully be minimized by Yoric[DT]'s suggested restructuring.
<hcarty>
kaustuv: For what it's worth, (7) can be avoided (camlp4 is not required when using Batteries). (8), the enum-ization can be avoided as well. The availability is (almost?) pervasive, but I don't think enum use is ever required.
<hcarty>
Yoric[DT]: I'm off - good luck with the talk. I hope everything goes smoothly for you.
<hcarty>
Yoric[DT]: Quite the heroic effort.
<hcarty>
And they may all be 64bit as well, though I'm not certain of that.
<hcarty>
awilcox: Ah. The success stories I've seen have all been with 3.11.x
<awilcox>
hcarty: I'm using 3.10.2 with a specific patchset for the project I'm working on
<hcarty>
awilcox: There have been a number of posts on the mailing list from users attempting to build OCaml on Snow Leopard. A few folks have reported success.
<hcarty>
Yoric[DT]: Batteries from GODI builds here without error.
<hcarty>
Will build now...
<hcarty>
Yoric[DT]: 0ok.org is having other trouble now, so once I removed the local Batteries files from godi/ it downloaded the new version
<hcarty>
That still doesn't explain why the older package is overriding the newer package though.
<hcarty>
I wonder if there is an ssh key mismatch error somewhere in the pipeline of pushing updates.
<hcarty>
At least the reason 0ok.org isn't updated - it was moved to a different server today.
<hcarty>
Oh... I may know the problem.
<hcarty>
Is the release tool a GODI package? Maybe it doesn't have information on 0ok.org?
<hcarty>
I sent Gerd an email.
<hcarty>
I think Gerd pushes the updates, but I don't know how.
<hcarty>
Yoric[DT]: I'm not sure if there is anything I can do to hurry the mirror update along
<hcarty>
I don't know how often updates are pushed
<hcarty>
I can take a look - that's a mirror I'm hosting
<hcarty>
ocaml-programming.de seems to be the only mirror with beta2. Perhaps the other mirrors are somehow taking precedence?
<hcarty>
Is 004 somehow coming out as newer than 09?
<hcarty>
This is very odd
<hcarty>
I removed all traces of Batteries from my godi/ tree, and it re-downloaded the beta1 version.
<hcarty>
I'll dig further on my system
<hcarty>
Still nothing
<hcarty>
I'll see if there is something left behind in my install from some prior experiment
<hcarty>
That file has the updated Batteries version listed
<hcarty>
My thoughts as well. cocan would be a good place to put notes/results after the fact.
<hcarty>
ocamlbuild + autoconf and ocamlbuild + cmake would each be handy in general
<hcarty>
bluestorm: Any suggestions for where to put up the wiki pages? cocan is probably not a bad start, but it requires rwmjones' intervention to give out one or more accounts.
<hcarty>
bluestorm: Sorry for the silence. To catch up: I think that a wiki page is a good idea. ocamlbuild help/infrastructure would be a wonderful thing to have at the sprint.
<hcarty>
bluestorm: Probably
<hcarty>
Or a project could be setup on the forge. Something that would be recycled between sprints.
<hcarty>
mol: That's a good question. I suppose something could be put on cocan.
<hcarty>
Yoric[DT]: Testing will hopefully be a part of it, so even having an open window and repeatedly testing GODI installs would likely help.
<hcarty>
It could start in the French AM and finish in the US PM (with... 1? 2? people around?)
<hcarty>
bluestorm: :-)
<hcarty>
That may not be needed though
<hcarty>
Times when interested parties can drop in to see what has been completed and what needs to be done.
<hcarty>
bluestorm: I think the whole day is good, but it may be good to have "core" hours, or perhaps a few checkpoints.
<bluestorm>
hcarty: couldn't we say "the whole day" ? that would probably dilute workforce a bit, but make it easier to cope with people various disponibilities
<hcarty>
I would too. What is a good time of day?
<Camarade_Tux>
hcarty: ledit too
<hcarty>
Updating some GODI packages would be good as well. camlzip is out of date in GODI, I think pa_do is out of date. There are likely others as well.
<hcarty>
GODI thankfully allows patching as part of the packing/install process, so the work shouldn't be lost even if it is not immediately accepted upstream.
<hcarty>
This week or next should be ok for me. We could send a message to the list and request suggestions (I suggest Cairo and GSL for GODI packaging...).
<hcarty>
bluestorm: I think those two ideas are good ones to start out with.
<hcarty>
Packaging manually for GODI seems like a horrible task :-)
<hcarty>
GODI packages are relatively straightforward IF they can be done with godiva.