2009-07-02

<hcarty> C_Tux: It's new in 3.11.1 - I wondered the same thing and checked the Changelog to be sure :-)
<hcarty> C_Tux: Yes, the improvement in mismatched type errors is certainly welcome.
<C_Tux> hcarty: yep, just making the rest of my code compile again before that ;)
<hcarty> C_Tux: It's probably worth emailing the mikmatch author. They should be able to provide either a fix or reasonable work-around.
<C_Tux> hcarty: the identifier should be explicity prefixed with the module name then, giving My_module.my_module_somename instead of just my_module.somename, that should prevent collisions
<hcarty> "items" here being automatically generated values which show up in a module's unconstrained interface.
<hcarty> I think pa-do can cause some similar items to pop up. But IIRC the names are somewhat random/unique and less likely to clash.
<hcarty> C_Tux: Excellent, I'm glad you found the issue :-)
* C_Tux hugs hcarty !
<hcarty> OCaml is a fun language to learn and work with in my experience.
<hcarty> ErikRose: Quite often :-) Smerdyakov's suggestion to read up on the module system is a good one. Both the OCaml manual and Jason Hickey's book are good resources for this.
<hcarty> ErikRose: For modules, you would then use something like "Chess.Black" and "Checkers.Black" to differentiate between the two.
<Smerdyakov> Like hcarty suggested, a common solution involves putting the datatypes in separate modules.
<hcarty> ErikRose: They will collide. The simplest options are to either change the names (ex. "type checkercolor = Red_check | Black_check ...") or to put each type in separate modules.
<hcarty> If you don't have an explicit .mli then mikmatch could be polluting the module somehow, and the "open" could expose that to your other code.
<hcarty> C_Tux: You could check the interface for the open'd module
<C_Tux> hcarty: I had to stop using mikmatch in the toplevel because of some weird/annoying behaviour
<hcarty> C_Tux: [object val x = (REPLACE '*' * -> "") "*foo*" method x = x end;;] also gives nothing. So this may be related to some mikmatch + objects feature or bug.
<hcarty> C_Tux: But [(REPLACE '*' * -> "") "*foo*"] does not give anything. So perhaps the camlp4 magic behind mikmatch explicitly checks for "let"?
<hcarty> C_Tux: [let x = (REPLACE '*' * -> "") "*foo*";;] gives x = "foo" in the toplevel.

2009-06-30

<hcarty> "[(foo :> base_class); (bar :> base_class]" will give "base_class list = [<obj>; <obj>]"
<hcarty> jonafan: I think you can force that
<hcarty> Chapter 12
<hcarty> palomer: Jason Hickey's book covers this topic very nicely.
<hcarty> It may be faster using modules as well, though I'm not certain of that.
<hcarty> A module probably makes a better replacement for a something like you are talking about, rather than a record on its own.
<hcarty> You could do "module F_derived = struct include Foo let bee x = new_bee_here end"
<hcarty> module F = struct let bee x = print_endline x.aaa end F.bee some_meow
<hcarty> You could make bee a function which takes a meow value and does the appropriate thing with it.
<hcarty> palomer: Why are you including the function in the record?
<deavid> hcarty: /usr/bin/ocaml: unknown option `-i'.
<hcarty> There are also MPI and ocamlp3l.
<hcarty> tautrimas: You might want to take a look at jocaml.
<hcarty> deavid: You can run "ocaml -i foo.ml" and it will display the inferred types for each value in foo.ml.
<hcarty> palomer: Thanks for the clarification.
<hcarty> For example, foo.ml would map to the module Foo. myLib.ml would map to MyLib.
<hcarty> jado: No, it's not a direct mapping
<hcarty> The compiler used to accept most file names. But the file name defines the module name, so 81.ml would map to the module 81, which is not valid.
<hcarty> Because 81 is not a valid module name.
<hcarty> jado: On newer versions of OCaml (3.11 and later, I think), you will get warnings and/or errors about using 81.ml as a file name.
<hcarty> jado: Add "-linkpkg" to the command
<hcarty> palomer: src/delimited_overloading.ml in the pa-do sources
<hcarty> Sorry... sent that out too soon.
<hcarty> palomer: It looks like they use <:expr< `$s$ >>
<hcarty> palomer: It looks like they use <:expr:
<hcarty> palomer: The pa-do code may serve as a reference. It has some support for overloading polymorphic variants.
<hcarty> kaustuv: Ah, of course :-)
<kaustuv> hcarty: Debian's packages.
<hcarty> kaustuv: What are you using in place of GODI?

2009-06-29

<hcarty> deavid: Welcome :-)
<hcarty> alexyk: Sys.file_exists

2009-06-28

<hcarty> thelema: Method::Signatures looks pretty cool.

2009-06-25

<Yoric[DT]> hcarty: there's a vague beginning of support for .cmxs in Batteries' myocamlbuild.ml .
<hcarty> ocamlbuild still doesn't have .cmxs support though, which is unfortunate. I'd like to try out the native code toplevel.
<hcarty> palomer: Yes, though there may be others as well. The type error change is the main one I've noticed.
<hcarty> The revised error messages in 3.11.1 seem rather nice.
<hcarty> mrvn: Indeed. "ocamlc -i" was a wonderful discovery when I started learning OCaml.
<mrvn> hcarty: and those I always generate with ocamlc
<hcarty> s/The/I/
<hcarty> Smerdyakov: Ok, thanks. I thought it was odd. The enjoy the lack of required annotations in OCaml (beyond, as you said, module signatures when desired).
<hcarty> But in the Haskell examples I've seen, almost all functions have a type annotation to go along with them.
<hcarty> Smerdyakov: I'm not sure of the proper way to ask. In OCaml, type annotations seem to be rare.
<hcarty> SML looks like it does.
<hcarty> Are there other programming languages which have type inference which is as pervasive as OCaml? I'm not sure if that is the right way to put this...
<hcarty> palomer: That's an interesting pair of language recommendations :-)
<hcarty> yziquel: A few, but I don't think any are alive at the moment.
<hcarty> break: ++ may be equivalent to @ in OCaml?
<hcarty> break: And you could, if you wanted, drop the ( ) around range, "n :: range (n - 1)", and it would work properly.
<hcarty> break: Yes
<nominolo> hcarty: ok, I see, they use polymorphic variants
<hcarty> palomer: If mono_var is defined as something like "type mono_var = [ `Foo ]" then I think it would be ok
<hcarty> Something like "gunzip_with (fun () -> some_func tmp_file) ~target:tmp_file gzip_file"
<hcarty> s/suggestions to/suggestions for how to/
<hcarty> Any suggestions to name a function which takes a gzip-ed file, extracts it to a temporary location, runs a given function, then deletes the temporary file? I'm thinking one of gunzip_in, gunzip_with or with_gunzip_in (in the spirit of Batteries.File.with_open_in).
<hcarty> nominolo: For example - http://ocaml.pastebin.com/d4ef1ce19
<hcarty> nominolo: In that example, it may be using polymorphic variants. The type definition is not in revised syntax.
<hcarty> You're welcome - I hope it was reasonably clear :-) I haven't used the revised syntax much.
<nominolo> hcarty: ah, I see. thanks
<hcarty> But there are users of the revised syntax. A lot of OCaml itself seems to be in revised syntax.
<hcarty> The standard syntax is the most commonly used
<hcarty> "type foo = [ Bar | Baz ]" in revised syntax = "type foo = Bar | Baz" in standard/original syntax
<hcarty> Written in revised syntax, that is
<hcarty> It may be revised syntax
<hcarty> nominolo: I don't think the first is valid

2009-06-23

<hcarty> Alpounet: Not quite that closely related to what I do :-)
<hcarty> Physic + Astronomy
<hcarty> Yoric[DT], Alpounet: Thank you both, I'll pass that along :-)
<hcarty> Alpounet: Both I suppose? ~850 miles and a major career shift for her (grad student -> professor)
<Yoric[DT]> hcarty: well, wish her a happy birthday from #ocaml :)
<hcarty> My wife's birthday is in a few days, and we are preparing for a move relatively soon.
<hcarty> If I forget, please feel free to ping me on this :-)
<hcarty> Yoric[DT]: I can ask. I'm not sure if it would be best to wait to hear back from the reporter though.
<Yoric[DT]> hcarty: Alpounet: does one of you feel like asking for testers?
<hcarty> thelema posted a request for more information in the bug report.
<hcarty> And I'm not sure what to think of the GZip vs Gzip error.
<hcarty> I don't have access to OSX for local testing, so I don't know if the "cp -a" issue is still present.
<hcarty> For Batteries? I'm not sure, haven't heard anything back yet.
<Yoric[DT]> hcarty: how are things with the MacOS users?
<hcarty> Yoric[DT]: pong
<Yoric[DT]> hcarty: ping
<hcarty> Yoric[DT]: Thank you for putting together the writeup and demo. It sounds quite promising.
<hcarty> ehird: Micmatch/Mikmatch may allow you to do what you want.

2009-06-22

<hcarty> ehird: Printf.* may have something
<hcarty> And PCRE is installed by default with GODI
<hcarty> As you pointed out, the libref/ directory has the complete and much nicer looking version.
<hcarty> Ah, that. It's not the proper library reference, just an overview of Pervasives.
<ehird> hcarty: but if you go to http://caml.inria.fr/pub/docs/manual-ocaml/manual033.html from the main manual index
<hcarty> I thought you meant the Batteries side panel and other associated goodies.
<hcarty> Yes, that looks the same as my local manual installation :-)
<hcarty> Oh. I have not seen that.
<hcarty> I just installed the package to check, and for local reference when the net connection decides to die.
<hcarty> ehird: That's odd. It's highlighted here in the same way it is in the web version
<ehird> hcarty: i'm switching to linux soon, but i like stuff to work now :)
<hcarty> I haven't used OSX for any length of time in several years.
<hcarty> Unfortunate
<hcarty> I don't have it installed... I use ocamlbrowser if I just want the signature, or a web browser if I want the full docs.
<hcarty> I'm not certain that has the library reference though.
<hcarty> ehird: godi-ocaml-manual perhaps
<hcarty> They are also on the OCaml web site.
<hcarty> ehird: I think the OCaml docs are in a separate package under GODI.
<hcarty> I've been spoiled by: Foo.open "fil<TAB>";; giving me what I want with a few saved keystrokes
<hcarty> ehird: I tried ledit first because it was the first thing I heard of. rlwrap Worked Better For Me.
<ehird> hcarty: that's odd, switching away from an ocaml tool when you start using ocaml
<hcarty> ehird: Yes, I just liked the feel of rlwrap more :-) I have not used ledit since I started with OCaml though, so the changes may have diminished even further.
<ehird> hcarty: same thing modulo indirection :)
<hcarty> ehird: I'm not sure if ledit supports it, but rlwrap allows for tab completion and other nifty extras
<hcarty> ehird: I'm not sure. Depends on how GODI determines what is out of date.
<hcarty> I like the OCaml syntax a lot. It drove me a little nuts at first, but I like it's feel now more than most other languages I've seen.
<ehird> hcarty: btw, won't this break when I update the package list?
<ehird> hcarty: get around to actually learning it fully? :-)
<hcarty> ehird: Hooray - Now perhaps you can do whatever it is you've been planning to do with OCaml :-)
<ehird> hcarty: Yay it works.
<hcarty> ehird: I /think/ so. Worth a shot :-)
<hcarty> ehird: Yes, according to the changelog it does
<ehird> hcarty: ah; so .12 probably works with 3.11.1 OOTB
<hcarty> ehird: Yes, you'll also need to download camlp5 version 5.12
<ehird> hcarty: OK, those files look right, but I think camlp5 will still complain about the version no matter what I do.
<hcarty> ehird: I think editing distinfo and Makefile in that directory should get you what you want, if you change them to update camlp5 to 5.12
<hcarty> palomer: Yes, though it's been updated since and does not have 100% backwards compatibility.
<hcarty> distinfo holds the names of the source files and their hashes
<hcarty> ehird: That directory holds the general build information for the package, as far as I know.
<hcarty> ehird: build/godi/godi-camlp5 is likely a good start for your camlp5 hacking
<hcarty> ehird: There is a -no-pervasives or similar compilation flag
<hcarty> Perhaps. But "Pervasives" is nice because the name tells you what it is - it's everywhere
<hcarty> ehird: No stranger than Prelude :-) But both seem like odd choices, perhaps without better substitutes.
<hcarty> ehird: build/distfiles/ contains all of the downloaded sources
<hcarty> ehird: Under your GODI prefix
<hcarty> ehird: ./build/distfiles/bin-prot-1.2.14.tar.gz
<hcarty> palomer: Very nice. I've thought about trying omake, but ocamlbuild came out right at the time I was looking for something other than OCamlMakefile.
<hcarty> ehird: The GODI messages should list it. If not, then you can delete the local copy to force GODI to grab it again.
<ehird> hcarty: Where can I find the source url?
<hcarty> palomer: Cool :-) I don't think I would have bothered without ocamlbuild, since it does most of the heavy lifting on its own.
<hcarty> And the file may have been cached locally
<palomer> hcarty, yeah, that's what I did
<hcarty> This was a few hours ago
<hcarty> ehird: Sorry, the source URL
<hcarty> Perhaps the server is down or the file was moved
<ehird> hcarty: Which source?
<hcarty> ehird: Check the source?
<hcarty> palomer: I have a library with myArray.ml, myList.ml, etc. all packed under the Mylib name.
<hcarty> palomer: You can also pack them in to one library
<hcarty> The bin-prot checksum error is odd. I just rebuilt against 3.11.1 and bin-prot built without issue.
<hcarty> ehird: I don't think so. The Appname_foo is likely used for longer module names, or to separate pieces of a library in to distinct parts.
<hcarty> ehird: And there are different ways of putting modules together that way
<hcarty> ehird: You can certainly have Foo.Bar.Baz.value
<hcarty> That is along the lines of a change I would like to see
<hcarty> palomer: For example, only Batteries itself can put modules under Batteries.* - in Perl (as an example), anything under the Batteries/ directory would end up under Batteries.*
<hcarty> Perhaps a design limitation of the compiler
<hcarty> That would certainly be nice.
<hcarty> ehird: What do you mean by hierarchical modules? The way Perl handles modules?
<hcarty> flux: Once Batteries is up and running at 1.0stable, Batteries + findlib could probably provide the base for such a tool
<hcarty> palomer: The findlib API would be a nice base to work from
<hcarty> palomer: Godi_script and Godi_script_wrapper. I don't know what they do though.
<hcarty> Still, a CPAN-like tool for OCaml would be Super Cool
<hcarty> I haven't used it much, but it has apparently improved in recent releases
<hcarty> Everything in GODI can be done from the commandline
<hcarty> And package updates, or lack of updates like camlp5, can really throw things off
<hcarty> ehird: Yes, it is definitely a shame. GODI is wonderful, but still takes some work to get up and running.
<hcarty> The camlp5 whitelist is an unfortunate-for-GODI-users feature
<hcarty> ehird: You could edit the camlp5 installation info - there is a newer release out which supports 3.11.1
<hcarty> ehird: I'm not sure if you can force GODI to use 3.11.0 without telling it to build the appropriate CVS tag, now that 3.11.1 is in place

2009-06-21

<hcarty> They can get out of sync on occasion. If you report this sort of problem to the GODI mailing list it is generally fixed rather quickly.
<hcarty> GODI is not managed as a whole - each package is managed independently
<hcarty> ehird: I'm not sure if you can directly
<ehird> hcarty: Bleh... --section 3.11 uses .1. I read nowhere that I had to use 3.11.0... guess I'll reinstall. Tomorrow.
<hcarty> You could contact the camlp5 author
<hcarty> ehird: True. It all works with 3.11.0.
<ehird> hcarty: Yes, but other things do.
<hcarty> ehird: Batteries doesn't need camlp5 either
<ehird> hcarty: But Batteries won't compile with 3.10!!
<hcarty> ehird: GODI 3.11.x is not officially released yet anyway
<hcarty> ehird: OR, you could check the mailing list and camlp5 web sites :-) They each have information on this.
<hcarty> ehird: It works fine with 3.11.0
<hcarty> ehird: OCaml versions are specifically whitelisted for camlp5. So until camlp5 is updated for 3.11.1, it will give that error.
<hcarty> s/that/that was/
<hcarty> det: Yes, sorry - that simply meant for confirmation :-)
<hcarty> det: Batteries has a rather nice (and hopefully complete?) "Exceptionless" suite of modules

2009-06-20

<hcarty> Or use pa-do for even more efficient local overloading! :-)
<hcarty> Oh, sorry - I see what you're saying
<hcarty> It wasn't a change to gZip.ml, it was a change to batteries.ml
<hcarty> thelema: Ah, no. My change was later than that.
<hcarty> It looks like the sort of problem that came from trying to rename gZip.* -> gzip.* in the Batteries source tree
<hcarty> thelema: Thank you
<hcarty> I don't have access to OSX to test locally, unfortunately
<hcarty> Perhaps
<hcarty> Yes, I'm wondering that as well
<hcarty> Hmm
<hcarty> The change was an alias in batteries.ml
<hcarty> I'm not sure how this conflict is occuring
<hcarty> thelema: I'm looking through it now
<hcarty> Yoric[DT]: pong
<Yoric[DT]> hcarty: ping

2009-06-19

<hcarty> thelema: You're in MO?
<hcarty> If it were combined with OpenGL, SDL or something similar then it could probably be made fast enough.
<hcarty> You could use Cairo for the initial rendering and keep those rendered sprites around.
<hcarty> palomer: I doubt it, unless one or more of the proposed hardware-accelerated backends make it in to Cairo
<hcarty> It's very basic, just enough for FrGui interaction. But hopefully it will grow in to more :-)
<hcarty> Yoric[DT]: I'm finding my way though FrGui now, and it has an FrCairo library
<hcarty> It is used for some if not all of the Gnome games. But I don't think any of those have significant animation.
<hcarty> It would likely require a LOT of pre-rendering
<hcarty> palomer: It probably could
<hcarty> It would be wonderful to get this in to good shape (update to support recent-ish Cairo; add findlib support officially) and make a proper release
<hcarty> You're welcome. I am excited about it as well.
<hcarty> Yes, more or less. I have an account at fd.o now and commit access for the cairo-ocaml repo
<hcarty> kaustuv: And Olivier has patches to add and is interested in staying involved
<hcarty> The "official" repo should be live soon, once I track down a strange error in the web interface
<kaustuv> hcarty: Awesome!
<hcarty> kaustuv: http://cgit.freedesktop.org/~hcarty/cairo-ocaml/ -- an attempt at cleaning up the CVS -> git import of Cairo

2009-06-18

<hcarty> julm++
<hcarty> julm: Yes, it seems to be fixed now
<hcarty> s/what I missed/how I missed them/
<hcarty> I'm not sure what I missed in the installation process, but there were two .a's not installed
<hcarty> julm: Thank you so much!
<hcarty> Which would explain a lot :-)
<hcarty> julm: I need to check that - it may not be!
<hcarty> julm: Yes
<hcarty> It's there in the build directory
<hcarty> julm: Oh, sorry
<hcarty> julm: No, but I have not compiled your version yet (it complains about a missing module - I don't remember which - when I replace the existing one with yours)
<julm> hcarty: have you looked for the missing symbols in the file(s) of the build directory with objdump?
<hcarty> julm: Yes
<julm> hcarty: but it fails in an other directory?
<hcarty> julm: That is a build of one of the demos which come with the OCaml Cairo bindings. It builds, links and runs cleanly from the build directory.
<hcarty> julm: The build of the library?
<hcarty> Camarade_Tux: Goodnight
<julm> hcarty: could you pastebin the complete trace of the build?
<hcarty> I'll have to dig through this some more
<hcarty> julm: Looking at the files directly, they seem to have the same linking information listed
<julm> hcarty: you can also open the .cmxa with your text editor, it appears in clear
<julm> hcarty: that said I do not remember if the official version of objinfo.ml handles .cmxa; I am currently using my old patch there: http://caml.inria.fr/mantis/view.php?id=4276
<hcarty> julm: "objinfo cairo.cmxa" errors out saying that it's not an object file
<hcarty> julm: Ah, thanks. Found it and compiled it.
<julm> hcarty: ocaml/tools/objinfo.ml
<Camarade_Tux> hcarty, actually I think I had troubles getting both bytecode and nativecode to work without a make clean between them : http://paste.lisp.org/display/82083
<hcarty> julm: Where do I get ocamlobjinfo? It sounds very familiar.
<hcarty> julm: Oh, cool. Thank you.
<julm> hcarty: .cmxa can store some linking information, you can print them with ocamlobjinfo as for .cma
<Camarade_Tux> hcarty, I think I had that problem for ocaml-gir, I hope I can find what I did
<hcarty> Camarade_Tux: If I recall correctly, a .cma stores some linking information a .cmxa does not
<hcarty> julm: program, globals, data_segments
<Camarade_Tux> hcarty, I've also had troubles with C bindings and native code while bytecode was working perfectly fine but I can't remember what the problem was
<julm> hcarty: what exactly are the missing caml_* ?
<hcarty> Camarade_Tux: Thanks! Sleep well tonight.
<hcarty> I've run in to this before with C bindings + native code, and I don't remember what the work-around is.
<hcarty> The only patch they seem to use is providing the META file
<hcarty> julm, Camarade_Tux: I'm using the Fedora META file and build steps (as far as I can tell)
<Camarade_Tux> hcarty, have you checked if debian/fedora have patches against ocaml-cairo ?
<julm> hcarty: perhaps that you're using a different META file?
<hcarty> But my from-source build does not link properly with native code, leading to lots of missing caml_* symbols
<hcarty> I'm having trouble getting native code linking to work. It seems to be fine for Fedora, Debian, etc packages.
<hcarty> Is anyone here using the Cairo bindings not from distro packages (ie. with GODI)?

2009-06-17

<hcarty> kaustuv: ping

2009-06-16

<hcarty> This person is using 3.10.2 and the Batteries beta package from GODI
<hcarty> Yoric[DT]: Ok, thanks. That's what I thought.
<hcarty> It may be handled properly in a later git revision though. GODI has the beta release.
<hcarty> I think I've seen questions from others about this same issue. IIRC it had to do with a 3.10.x -> 3.11.x change.
<hcarty> Alpounet: It was extLexing.ml not matching interface extLexing.cmi
<hcarty> I got an off-list email from someone saying that they are having trouble compiling the GODI Batteries package under 3.10.2.
<hcarty> Does Batteries work on 3.10.2?

2009-06-15

<hcarty> It's something of a non-issue though at this time
<hcarty> flux: That works for the company in question, but not for the OCaml community at large
<hcarty> Not to mention the "full" consortium members
<hcarty> flux: Indeed
<hcarty> I don't know how the OCaml folks would respond to the idea though
<hcarty> It may be worth proposing
<hcarty> flux: I've wondered if that would be a reasonable idea... particularly if xleroy and the rest would agree to a "failsafe" license for the community - if OCaml went unmaintained for some period of time, the community could continue maintenance under an easier license, something like LGPL throughout

2009-06-12

<hcarty> psnively: That sounds useful. Hopefully I can pick up a better understanding of the details with FrGui.
<psnively> hcarty: yes.
<hcarty> psnively: Am I right in my understand that you can chain together values and have them "automatically" update when appropriate?
<hcarty> palomer: So, hopefully the "FRP" portion will just continue to work :-)
<hcarty> palomer: I'm not sure I do either. But FrGui seems to provide the start of a very simple, clean API for GUI building in OCaml.
<hcarty> Yes, definitely
<hcarty> Yoric[DT]: He does not have time to work on FrGui, but he is happy to have someone continue its development. He offers to answer what questions he is able to.
<hcarty> It's nice to see an enthusiastic response
<hcarty> Once (if?) it gets rolling I'll post to the Caml list as well
<hcarty> Alpounet: No doubt! I Cc'd the newhope-devel list with my reply to the FrGui email.
<hcarty> Alpounet: I certainly will, thanks. I need to wrap up a few other things first, but this is fairly high on my not-directly-dissertation-related TODO list