<hcarty>
Camarade_Tux: Could your generator handle Cairo bindings? I know they already exist, but I'm curious to see what your generator would produce.
2009-05-08
<hcarty>
Yoric[DT]: Will do, thanks. Probably tomorrow though, as I am off for the evening.
<hcarty>
Yoric[DT]: Do you think the myocamlbuild.ml change is worth adding to Batteries? Or would you prefer that I send it to the mailing list for comments?
<hcarty>
And my mistake... I wrote "ocaml -i" rather than "ocamlc -i" for most of the examples above
<hcarty>
mrvn: I agree that such a tool would be useful. automli may do something along those lines
<hcarty>
mrvn: I think that's what "ocamlbuild foo.inferred.mli" uses to create the .mli
<hcarty>
mrvn: Does "ocamlc -i foo.ml" reuse foo.mli?
<mrvn>
hcarty: But if someone does create inferred.mli and there happens to be an .mli then it should reuse that.
<hcarty>
mrvn: No special processing is done beyond the inferred interface. So I don't know that it would make sense to create a .inferred.mli from a .mli since there is nothing to infer
<hcarty>
Both with Batteries and with non-Batteries myocamlbuild.ml files
<hcarty>
Yoric[DT]: Yes, I've tried
<hcarty>
where "ocamlbuild foo.inferred.mli" = "ocaml -i foo.ml"
<mrvn>
hcarty: not foo.inferred.mli from foo.mli or foo.ml?
<hcarty>
foo.inferred.mli from foo.ml
<hcarty>
Sorry, that was a mistype
<hcarty>
mrvn: Oops!
<mrvn>
hcarty: you said foo.inferred.mli from foo.mli from foo.ml?
<hcarty>
mrvn: I don't understand the question?
<hcarty>
But without the above changes, the findlib and camlp4 goodies will not be applied. So if any non-stdlib packages or syntax is used then it won't work.
<mrvn>
hcarty: why go through foo.mli?
<hcarty>
It's ocamlbuild's support for "ocaml -i"
<hcarty>
Yoric[DT]: ocamlbuild foo.inferred.mli
<mrvn>
hcarty: can you declare types rivatesomehow so the infered.mli shows them abstract or not at all?
<hcarty>
Yoric[DT]: Thoughts? Do you think that this is a worthwhile addition?
<hcarty>
Yoric[DT]: A Batteries example myocamlbuild.ml patch to allow creating foo.inferred.mli from foo.mli from foo.ml using ocamlbuild : http://ocaml.pastebin.com/m7feb8fd5
<hcarty>
The diff comes from a different repository, but the myocamlbuild.ml come directly from Batteries
<hcarty>
thelema: It adds support for creating foo.inferred.mli from foo.ml (ocamlbuild foo.inferred.mli)
<hcarty>
kaustuv: I am still waiting for an account to be created for something other than read-only access, and hopefully a stand-alone project for the OCaml bindings.
<hcarty>
Alpounet: And I agree that maintaining the original version scheme is best, unless there is some specific reason to do otherwise
<hcarty>
Alpounet: Thank you for putting the FAQ up
<Alpounet>
hcarty, palomer, kaustuv, gildor ?
2009-05-05
<Ariens_Hyperion>
hcarty: I'm going to install gnu utils
<hcarty>
Ariens_Hyperion: I have not tried, but it is probably worth submitting a bug report. I think most if not all of the Batteries devs are developing on some form of Linux
<hcarty>
aij: Then something else in the full example probably breaks it
<aij>
hcarty: yes, I know, my point is that the '_a was't being a problem there
<hcarty>
This question and workaround/fix is listed in the FAQ I linked to earlier
<hcarty>
That gives you a fully polymorphic version without the : T
<hcarty>
aij: My guess is that some code in the rest of your module is breaking the simple example case
<hcarty>
aij: Was the type still '_a?
<hcarty>
aij: It isn't. Doesn't '_a mean that the type is undetermined (or whatever the proper CS-speak is)?
<hcarty>
gildor: Certainly
<gildor>
hcarty: if you decide to ask him, could you cc:newhope-devel@lists.forge.ocamlcore.org ?
<hcarty>
gildor: Fair enough :-)
<gildor>
hcarty: just ask him
<gildor>
hcarty: well if it is separate and "He is not maintaining the bindings any longer", you can reasonably ask him if he don't mind rehosting it in newhope
<hcarty>
gildor: It is separate
<hcarty>
gildor: It could link to projects such as the Cairo bindings, bitstring, ocamlgsl, etc which are hosted elsewhere
<gildor>
hcarty: is cairo-ocaml a separate package from cairo ?
<hcarty>
gildor: Perhaps there should be an "outside programs and modules" section on the forge?
<hcarty>
gildor: I agree. But I don't want to step on the toes of the code's original author
<gildor>
hcarty: well as for everything that touch OCaml, I think you'll have more chance to find interested maintainer with newhope (hosted on OCaml forge) than to stay on freedesktop which is mostly about C/python
<hcarty>
kaustuv: Your thoughts?
<hcarty>
Though it would be nice to move it from their CVS to their git repository
<hcarty>
gildor: I'm not sure. It may be less disruptive to continue maintaining the project at fd.o
<gildor>
hcarty, kaustuv: you want a git repo for cairo-ocaml in newhope project ?
<kaustuv>
hcarty: cool!
<hcarty>
kaustuv: He is not maintaining the bindings any longer, but suggested getting an freedesktop.org account and maintaining it there
<hcarty>
kaustuv: I heard from the Cairo-OCaml dev
<Alpounet>
ok hcarty
<hcarty>
If there are problems then development can be moved over
<hcarty>
I'd prefer not to start the project with a hostile takeover of a project :-)
<hcarty>
I'll discuss it with kaustav, and try to get a fd.o account some time soon
<Alpounet>
hcarty, hmm
<hcarty>
He did say that he is not actively maintaining the bindings
<hcarty>
So it looks like that may be a better approach than bringing it in to New Hope
<hcarty>
Alpounet: He said the best way to contribute would be to request an account on fd.o and join the project that way
<hcarty>
Alpounet: I heard back from Olivier Andrieu, the Cairo-OCaml developer
<hcarty>
palomer: camlp4 may not be "prettier", but it will/can do what you are asking
<hcarty>
palomer: Emacs+tuareg or camlp4?
<hcarty>
munga_: Thanks for the cmxs rule
2009-05-04
<hcarty>
I'm off for now. Take care all.
<hcarty>
s/produceds/produces/
<hcarty>
Camarade_Tux: Yes, the only reason I made the ocamlbuild transition is because the default build system produceds broken binaries on my system
<hcarty>
Once things have settled out a bit I will ping the Cairo-OCaml dev again. If we don't hear from them reasonably soon then I think it's reasonable to start up a git repo for it, particularly with kaustuv's updates
<hcarty>
Alpounet: I do have a changed build system here (autoconf -> ocamlbuild), but I'm not sure if that is a good idea
<Alpounet>
hcarty, by the way, you just can do anything more than waiting until you get an answer from the old Cairo-OCaml devs
<hcarty>
Alpounet: Thank you for keeping me in the loop :-) I hope to be able to put together a reasoned reply some time soon.
<hcarty>
My adviser just got back in town though, and it looks like I can set a date for my topic defense. So I likely won't be able to do much with NH over the next few weeks.
<hcarty>
Alpounet: Sorry, yes your response as well
<hcarty>
Alpounet: I saw the one from Sylvain
<Alpounet>
hcarty, have you seen the post on the ML ?
<hcarty>
I find Haskell rather ugly... though I think that has a lot to do withTheNamingConventions_
2009-05-03
<hcarty>
Though I'm not sure if that is needed, since I imagine (and hope) the New Hope will be more a loose collection of developers than a strictly run project
<hcarty>
If there is an author you would like to contact then I'd be happy to work with you on a "standard" email template for New Hope use
<hcarty>
If so, then I asked for the best way to submit patches
<hcarty>
In the email I asked if they are still interested in maintaining the Cairo bindings. I said that if not, another OCaml user and I are interested in continuing their development.
<hcarty>
If they reply I will send a follow-up mentioning the project though
<hcarty>
Alpounet: I'm not sure if it would serve as a good template. I don't mention New Hope because I sent it before the project idea was set in stone.
<Alpounet>
hcarty, can you fwd me the email you sent ?
<Alpounet>
hcarty, you should rather thank gildor who spent some hours on this mailman problem.
<hcarty>
It will still likely be a little while before I can spend much time on it. And I have not heard back yet from the Cairo OCaml dev
<hcarty>
Alpounet: Thanks for getting it setup :-)
<Alpounet>
hcarty, the ML is up and waiting for messages: )
<Alpounet>
Fine, thanks hcarty !
<hcarty>
That is pulled out of a function with "file" being the filename of the XML file to process. It somewhat obviously uses pa_openin.
<hcarty>
Alpounet: http://ocaml.pastebin.com/d3d109bde -- this the short, and probably horribly inefficient and dirty, way I use PXP for some simple data extraction
<hcarty>
s/was/is/ I suppose, since I'm still using the code
<hcarty>
Alpounet: Mine was similar. I have XML files with some basic information on other (binary) data files. I extract a few pieces of information (times and dates) from each.
<hcarty>
I don't think I tried xmlm... I tried xml-light and then PXP. PXP did what I wanted in just a couple lines of code - but as I said, my needs were quite simple
<hcarty>
I'm working with very simple files though, and for what I'm doing regexps would work almost as well, with a little preprocessing
<hcarty>
Alpounet: For the very limited XML handling I've had to do in OCaml, I've been reasonably happy with PXP.
2009-05-02
<hcarty>
palomer: If you're drawing graphics using put_pixel, I'm not sure why you'd be unhappy with a few extra text rendering steps :-)
<palomer>
hcarty, I'm just using put_pixel
<hcarty>
palomer: SDL would require much more care on the drawing end, I would think, than using Cairo
<hcarty>
palomer: Then you could update to SDL 1.3. Or Clutter looks like a promising base as well.
<palomer>
hcarty, but sdl gives me both!
<hcarty>
palomer: If you want low-level GUI control, you're going to have to sacrifice a little bit of API simplicity
<Camarade_Tux>
hcarty, I wanted to use my actual windows installation in virtualbox on linux, and my actual linux installation in vbox on windows and therefore needed 64bit emulation
<tab>
hcarty: it doesn't have such a distinction
<hcarty>
Camarade_Tux: Is it not something you could test on a 32bit VM?
<hcarty>
Camarade_Tux: I didn't realize such a distinction exists in their chips
<hcarty>
Camarade_Tux: That's ... quite awful re: no 64bit emulation
<Camarade_Tux>
hcarty, I'm running on 64bit and my crappy intel cpu won't emulate 64bit !
<hcarty>
Or whatever the latest and greatest Linux kernel virtualization method is
<hcarty>
Camarade_Tux: qemu or VirtualBox perhaps?
<hcarty>
palomer: It may be best to do some basic tests first :-)
<hcarty>
palomer: I imagine Pango and/or Cairo would do something like that
<hcarty>
palomer: If you use Cairo + Gtk, you could use Gtk's signals, as you mentioned earlier
<hcarty>
palomer: If SDL doesn't work for you, you could try Cairo + X or Cairo + Gtk for window management
<palomer>
hcarty, err, I needed to draw directly to the framebuffer
<hcarty>
palomer: What complaints do you have regarding Gtk that SDL fixed for you?
<hcarty>
Camarade_Tux: Please let us know how it goes
<hcarty>
The code is there in Subversion so anyone can grab it and give it a try
<hcarty>
Tux__: I've trusted the authors on the front of utility. There are a lot of tools in the source tree though, so there may be something useful there.
<Tux__>
hcarty, yeah, it's big, the idea was that qtcaml would probably benefit from some manpower since its original authors are currently busy
<hcarty>
I don't remember which list though
<hcarty>
Tux__: The authors posted that it will likely be ~1 year before qtcaml is useful for projects
<hcarty>
Tux__: I think qtcaml is a little too large scale for newhope, unless several folks were involved in its upkeep
2009-05-01
<hcarty>
And DrScheme + DrOCaml seem to play nicely together again
<hcarty>
A friend is attempting to try out OCaml, but he's working on a Mac and I am unfamiliar with the landscape
<hcarty>
Any official-INRIA-binary-using OSX users here?
<hcarty>
I suppose that's a more logical source :-)
<hcarty>
Camarade_Tux: Oh, very nice
<Camarade_Tux>
hcarty, it is a binding generator for any gtk-based app
<hcarty>
An OCaml version of Zim's robot
<hcarty>
Camarade_Tux: ocaml-gir?
<hcarty>
Thanks again for working on that
<hcarty>
kaustuv: Sounds reasonable
<hcarty>
(for the normal variant case)
<hcarty>
kaustuv: Maybe not. How would you provide compile-time checks?
<hcarty>
kaustuv: Sounds reasonable
<hcarty>
kaustuv: Then would it be better to change [> `Any ] to Cairo.surface_type?
<hcarty>
kaustuv: Ah, of course
<hcarty>
Alpounet: As soon as something comes up, will do
<hcarty>
Ah, right
<hcarty>
kaustuv: Would it be better to define a type such as "type surface_kind_t = [ `Image | `Pdf | ... ]" and make those functions take a surface_kind_t surface?
<kaustuv>
hcarty: also, for example, representing rectangles as a float record instead of a tuple.
<hcarty>
kaustuv: But I'd still like to hear from the original author
<hcarty>
kaustuv: It shouldn't break my code, so I'd be ok with that :-)
<hcarty>
Alpounet: Since GSL seems to be maintained (I've submitted a patch for it already), my main interest in is Cairo
<kaustuv>
hcarty: mainly functions of type such as [> `Any ] surface -> ... when they really want to be 'a surface -> ...
<hcarty>
kaustuv: What are you interested in breaking?
<hcarty>
kaustuv: Perhaps the tagged 1.0 release in CVS counts as an official release
<hcarty>
kaustuv: For the Cairo bindings, I'd say backwards compatibility is mildly important - there was never an official release from what I can tell
<hcarty>
No tagged releases though
<hcarty>
Alpounet: Their SVN is populated
<gildor>
hcarty: no release on googlecode... for now
<kaustuv>
hcarty: how important is backwards compatibility?
<hcarty>
I use both the Cairo and GSL bindings, so I've been doing my best to follow them wherever they end up...
<Alpounet>
gildor, yeah, waiting for hcarty and palomer to subscribe to the ML
<Alpounet>
hcarty hasn't sent it to me yet
2009-04-30
<hcarty>
I don't remember having trouble with the Debian or Fedora packages. But it's been a while since I've used either.
<hcarty>
kaustuv: Makes sense
<kaustuv>
hcarty: (delayed) I haven't tried building cairo-ocaml myself. I was testing with the Debian package.
<hcarty>
mrvn: Fair point
<hcarty>
mrvn: It's nice when you find a bug/change unrelated to what you are working on
<hcarty>
Coming from Subversion and others tools which would only allow file-at-a-time checkins
<hcarty>
It worked much too well for me to want to give it up
<hcarty>
psnively: "darcs record" is what spoiled me
<hcarty>
After seeing to darcs' chunk-by-chunking method of checking in changes I became horribly spoiled
<hcarty>
And the addition of "git add -p" brought back the thing I missed the most from darcs
<hcarty>
Alpounet: git-svn is what allowed my (relatively) easy transition to git
<psnively>
hcarty: Yeah, often that's how it goes... external influences. :-)
<hcarty>
This was a few years ago though so I'm not certain
<hcarty>
psnively: It may have been a hosting issue... I was able to get easy access to Subversion hosting, so SVN + SVK became compelling
<psnively>
hcarty: It could happen with surprisingly small repos, but honestly, I never hit it either.
<hcarty>
psnively: I was only using it at the time for personal projects which were never large enough to hit the super-long-merge issue
<psnively>
hcarty: darcs 1 had two really major flaws, IMHO: the superexponential merge issue, and identically-changed lines coming from different repos were considered conflicting.
<hcarty>
psnively: Yes, I don't remember what broke that made me look for alternatives.
<psnively>
hcarty, indeed! When using mercurial, I rely on hg record, hg fetch... to get as close to darcs' operational model as I can.
<hcarty>
git's lightweight branches, or whatever their proper name is, tipped the scale for me over other options
<hcarty>
I really liked the darcs interface
<hcarty>
Alpounet: I don't use darcs for personal projects, and I'm not currently tracking any upstream darcs repositories
<Alpounet>
hcarty, "used" darcs ?
<hcarty>
They all had their strengths
<hcarty>
palomer: I used darcs for a while as well, as well as Subversion and SVK
<hcarty>
Alpounet: Except the OCaml devs :-)
<hcarty>
gildor: Thanks!
<gildor>
hcarty, Alpounet: git repository created
<hcarty>
gildor: Thank you for setting up the account
<hcarty>
gildor: Git please
<gildor>
hcarty, Alpounet: what SCM do you want ?
<Alpounet>
hcarty, thanks
<hcarty>
Alpounet: And you should now be added as an admin
<hcarty>
Alpounet: I just got the email
<hcarty>
Alpounet: Definitely. I'll bring it up on here and/or send an email when I have the confirmation email
<hcarty>
But I think a gutted version of the compiler embedded in another source tree is less likely to work
<hcarty>
kaustuv: I would think so... it seems quite commonly used here and on the mailing lists
<hcarty>
Still waiting on the project approval
<hcarty>
Alpounet: Nothing yet
<Alpounet>
hcarty, no news for new hope ?
<hcarty>
It looks like they (snowflake) have cut out chunks of the OCaml source tree
<awilcox>
hcarty: Thanks :)
<hcarty>
awilcox: Not a problem. Best of luck if you continue with it
<hcarty>
Your best bet is really going to be to start with an official OCaml release and go forward from there
<hcarty>
Lots of folks here use OSX, so I suppose it's ok
<hcarty>
It's a programming language
<hcarty>
And you aren't using an "official" OCaml release so the configuration is likely quite different
<hcarty>
You already said that the snowflake folks don't support OSX
<hcarty>
awilcox: It is probably not configured properly for running under OSX
<hcarty>
Or posting to one of the mailing lists
<hcarty>
awilcox: You could try compiling OCaml separately
<hcarty>
I don't know what version they have or what modifications they have made though, so you may have a bit of a hard time with it
<hcarty>
awilcox: OCaml has OSX support, though I have not used it
<awilcox>
hcarty: They don't support OS X and said to ask here.
<hcarty>
awilcox: You might want to ask the snowflake devs. It looks like they have their own copy of OCaml in their source tree
<hcarty>
awilcox: What are you trying to compile?
<hcarty>
"Qualification: The Best" and "Grade Expected: Also the best"
<Alpounet>
palomer, not yet. hcarty has just registered it on ocamlcore, so it's waiting for approval.
<Alpounet>
Cairo-OCaml : hcarty & kaustuv
<hcarty>
It's at the top of my list, as long as the author is not going to maintain it further
<hcarty>
Alpounet: I agree :-)
<hcarty>
Alpounet: It looks like the C pieces are not all linked in properly
<hcarty>
This is with godi + OCaml 3.11
<hcarty>
Alpounet: Linking native binaries spits out a large number of linking errors
<hcarty>
I have a version of cairo-ocaml locally which uses ocamlbuild. It has fewer linking issues, but there are still problems with the toplevel
<hcarty>
s/default/existing/
<hcarty>
kaustuv: Have you used Cairo-OCaml much? Its default build system seems to have a number of linking problems on my system.
<hcarty>
I can add you as an admin/developer for New Hope as well if you'd like
<hcarty>
kaustuv: Very nice. Do you have a forge account?
<hcarty>
palomer: If you would like to volunteer to contact the ocamlsdl author to see if the library has been abandoned and then maintain it, please join! :-)
<hcarty>
Alpounet: Quite...
<hcarty>
Alpounet: In the mean time, we should probably contact the authors of libraries we are considering for New Hope to see if the libraries really are abandoned
<Alpounet>
hcarty, "alp"
<hcarty>
Alpounet: What is your forge account? I'll add you as an admin once the project is added
<hcarty>
Alpounet: Submitted
<hcarty>
Thank you, my French is ... nonexistant beyond what I can connect to the Spanish I studied :-)
<hcarty>
No
<hcarty>
Ah
<hcarty>
Alpounet: I agree that git is quite nice
<hcarty>
Hopefully gildor will have some idea of what is happening there
<hcarty>
It's giving an error when I try to create the project: ERROR: Could not create group: ERREUR: valeur trop longue pour le type character varying(255)
<hcarty>
Alpounet: That sounds reasonable
<Alpounet>
hcarty, we can create master/<some lib> branches on the origin
<hcarty>
gildor: ping
<hcarty>
I still prefer git though... hopefully this won't end up with more than a small number of libraries
<hcarty>
Although one benefit to Subversion here is that one could avoid checking out the whole source tree to work on one module
<hcarty>
Alpounet: I'd prefer git - are you ok with that choice?