<hcarty>
Probably a bit of the wrong implication though
<hcarty>
Alpounet: Excellent name :-)
<hcarty>
Alpounet: I am now, but will be away soon.
<Alpounet>
hcarty, still here ?
<Alpounet>
hcarty, hmm...
<hcarty>
Alpounet, kaustuv: I think registering a project is a good idea. Any ideas for a title?
<Alpounet>
hcarty, kaustuv should we register the project on OCamlCore and start discussing on the ML ?
<Alpounet>
hcarty, I'd like to know what setup you'd need, too
<gildor>
hcarty: what setup did you need ?
<hcarty>
Ideally I'd be able to put in the time to get the basics set up in the next month or two
<hcarty>
Alpounet: This summer would likely be a good time, though it may end up being late summer before I can dedicate regular time to it
<hcarty>
gildor, Alpounet: I'm not able to tackle this quite yet, but if someone doesn't beat me to it then I certainly will as soon as I'm able
<gildor>
Alpounet, hcarty: just begin by creating a project on ocamlforge and discuss the rules to adopt a project...
<gildor>
hcarty, Alpounet: even if it happens once in a while this is still better than today situation
<hcarty>
gildor Alpounet: Yes, I think it would be nice (though I doubt it would happen often) if projects could be adopted from the pooled of maintained libraries
<gildor>
hcarty, Alpounet: for most project this can be a good "resurection" point
<gildor>
hcarty, Alpounet: the point is that this will just be a way to setup something where abandonned project can get minimum care (we are not talking about full dev. only bug report + patch for a first step)
<gildor>
hcarty: I think this can be worth to setup a forge project and do an announcement on caml mailing list when ready
<hcarty>
gildor: As you said, it is important to at least attempt to get in touch with the library authors to get their blessing
<hcarty>
The author just moved their development of another set of bindings (GSL) to Google Code though, so they may not be abandoned at this point
<hcarty>
gildor: I'm a little concerned about the Cairo bindings. I don't know if they are abandoned or have simply not been updated in a long time.
<gildor>
Alpounet hcarty: behind glcaml what are other concerned library ?
<hcarty>
gildor: I agree fully
<gildor>
Alpounet, hcarty: and of course, you can create a forge.ocamlcore.org project for this ;-)
<gildor>
Alpounet, hcarty: fixing most obvious bug and problem in this library is probably the best thing to do first
<gildor>
Alpounet, hcarty: Batteries compat is a long term goal
<gildor>
Alpounet, hcarty : this can be a good idea, but better start with only convincing some upstream to give you the maintainance of their library
<gildor>
hcarty, Alpounet: I think what you are talking look like Debian collab-maint project
<hcarty>
I agree that a tie of some sort to Batteries would be beneficial both for Batteries and the non-Batteries maintained library
<hcarty>
And I think that would get to be too problematic since the libraries and their current state as maintained by such a group would probably change much more quickly than Batteries
<hcarty>
Though it would probably be a good idea to make sure any such libraries play nicely with Batteries
<hcarty>
Alpounet: I think group of library maintainers as mentioned by kaustuv would be, at most, a pre-Batteries stage
<hcarty>
kaustuv: Yes, almost a Batteries-lite. They don't all have to be related, but it may make it easier to at least keep them working with the latest compiler and library revisions
<hcarty>
The SDL bindings which come with/from the author of glcaml look reasonable as well
<hcarty>
Particularly if a few users band together to work on it
<hcarty>
I think glcaml would be fairly straightforward to maintain
<Alpounet>
hcarty, indeed. I have to give him most of OCaml compiler's .cmo, compiled with the same compiler than mlbot...
<hcarty>
> open Foo it.x;;
<hcarty>
> it.Foo.x;;
<hcarty>
> it.x;;
<hcarty>
> module Foo = struct type t = { x : int; y : int } end let it = { Foo.x = 1; y = 1 };;
<hcarty>
Alpounet: Yes, I imagine that would take a bit of preparation
<hcarty>
I think the lack of continuous presence is a large part of what hindered the use of xavierbot
<hcarty>
Alpounet: Certainly!
<hcarty>
sOpen: It can get odd if you nest a lot of modules and end up with types where have to type things like "it.Foo.bar.Baz.x"
<hcarty>
module Foo = struct type t = { x : int; y : int } end let it = { Foo.x = 1; y = 1 } ... open Foo let it2 = {x = 1; y = 1}
<sOpen>
hcarty, ok, cool. thanks :-)
<hcarty>
sOpen: Yes, that is correct
<sOpen>
hcarty, they are bound to the module, though, right? not forced private? If you open the module, they spill out?
<hcarty>
sOpen: Module
<hcarty>
mrvn: I haven't spent much time in C++ recently, thanks to OCaml...
<mrvn>
hcarty: In C++ method lookup is static. I miss that in ocaml.
<hcarty>
The OSP 2007 FrGui and underlying library structure seems nice, though perhaps not complete
<hcarty>
With records everything is determined statically at compile time
<hcarty>
s/looked up/performed/
<hcarty>
Method lookup is looked up at run-time, since < field : t ... > is an "acceptable" (correct terminology?) type in OCaml, while { field : t ... } is not
<sOpen>
hcarty, ok... this should be a type checking, static thing, thlugh
<hcarty>
sOpen: Object methods have a potential run-time penalty associated with them when compared with records
2009-04-27
<hcarty>
I hope someone proposed and gets funded for an updated defunctorizing tool. Or a continuation of FrGui...
<hcarty>
Hopefully the projects this year will have similar success and continued development like those from last year
<Alpounet>
hcarty, I thought it would finally be added to OCaml's standard distribution, or as an "add-on"
<hcarty>
They may be worried about potentially splintering the community though. Or the scope of the project, though I suppose we'll have to wait for the results to know the size of the projects they did pick.
<hcarty>
Alpounet: Just curious. I think it would have been a very nice project
<hcarty>
Alpounet: Bummer - you proposed to work on the HLVM backend for OCaml?
2009-04-26
<hcarty>
jbapple: There may be something in the ocamlgsl bindings
<hcarty>
palomer: The FrGui examples provide some nice illustrations, though I have found them rather hard to follow at times
2009-04-25
<dartelin>
hcarty, i have problem with catching, becase the last line throws the excception
<hcarty>
dartelin: Catch the thrown exception (End_of_file if you are using the stdlib functions)
2009-04-24
<hcarty>
I don't want it to introduce other bugs later on though
<hcarty>
It seems to work
<hcarty>
I want to compare hash_variant("foo") with (value variant_foo) and I'm not sure if (hash_variant("foo") == variant_foo) is the right thing to do
<hcarty>
So I'm not quite certain what it is supposed to do
<hcarty>
But it looks like it's a C int returned as a value
<hcarty>
mrvn: It returns value
<hcarty>
What is the proper way to use a polymorphic variant in the OCaml C ffi? Is Int_val(hash_variant(foo)) appropriate?
2009-04-23
<mrvn>
hcarty: arrays already have a tag for the type of content.
<hcarty>
kaustuv_: I imagine something like this would cause some amount of cheers as well. What would this mean for arrays?
<hcarty>
kaustuv_: If you have a working patch then it probably would cause loud grumbling as "OCaml 4.0"
2009-04-22
<hcarty>
flux: Array.sort sorts in-place
<hcarty>
Camarade_Tux: You could submit one for Batteries!
<hcarty>
mrvn: It uses Int64.t on 32bit systems and int on 64bit systems
<hcarty>
mrvn: pa_do has an int63 example
<hcarty>
The Bigarray C portion is pretty straightforward to modify. If the UInt32 and UInt64 modules were added to OCaml (or Community OCaml) then updating Bigarray appropriately should be a pretty simple process.
<hcarty>
There is an unsigned integer library on the forge which provides uint32 and uint64 types and functions. No Bigarray support though.
<hcarty>
Camarade_Tux: I put a feature request in to Mantis for this
2009-04-21
<hcarty>
Yoric[DT]: You're welcome
<hcarty>
Didn't mean to paste the full URL
<hcarty>
Oh my, very sorry about that
<hcarty>
Yoric[DT]: It looks like your Makefile.in fix missed a trailing \ on the ocamlbuild line - http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=batteries/batteries.git;a=blobdiff;f=Makefile.in;h=f63885ed409428b1b43411ab4919606e643e1b71;hp=544762ad04077407463feac5f4bbfc20a23484a3;hb=d6b4dc710d1d1097a85bbfa777165d410eb73ea5;hpb=99d62c947c488e0303dc79cc5d74b347e02b0b56
2009-04-20
<hcarty>
Yoric[DT]: Best of luck... I've been using some combination of Cairo, PLplot and (labl)Gtk for displaying graphics recently. But I'm not constrained to lab/student computers, which brings interesting challenges.
<Yoric[DT]>
hcarty: (let's say well enough)
<Yoric[DT]>
hcarty: and it doesn't work too well...
<Yoric[DT]>
hcarty: yes, I've finally found something in camlimages.
<hcarty>
Yoric[DT]: Does camlimages have anything useful? I don't have it installed to check locally
<vuln>
hcarty: ok, I will try it
<hcarty>
vuln: Follow Yoric[DT]'s suggestion - that will get you a working function
<hcarty>
vuln: Yes
<vuln>
hcarty: inside I can, you mean as neasted function right?
<hcarty>
vuln: Are you sure you can't use another function inside of maximizer?
<hcarty>
vuln: Then adapt that approach to recursion
<vuln>
hcarty: That's the problem
<hcarty>
vuln: You could try writing it in a non-recursive (imperative) manner
<vuln>
hcarty: He is out town and passed a huge list of recursion exercises to we do while he's out
<hcarty>
vuln: If this is homework, then you should probably ask the instructor for assistance
<hcarty>
Hydrant: I don't know what sort of research is involved, but I think both GHC (Haskell) and mlton (SML) pride themselves on their optimizations
<hcarty>
Hydrant: ocamlp3l and jocaml are examples of similar work in OCaml land
<hcarty>
mfp: Ok, thanks. Same workaround here - renaming gzip.ml to gnuzip.ml fixes the problem.
<mfp>
hcarty: goes away if I rename gzip.ml
<hcarty>
mfp: With the patch or without?
<mfp>
hcarty: fwiw., I can reproduce the Circular build detected error
<hcarty>
kaustuv: It does it you otherwise use ; or let () = ...
<hcarty>
I definitely use ; when useful, but ignore (...) seems a better route for throwing away a value if it's absolutely needed
<hcarty>
kaustuv: let _ = ... can also hide some unfortunate bugs
<hcarty>
thelema: I don't do that either
<hcarty>
kaustuv: Thought so! :-)
<hcarty>
Although 22 may be a mix? I've only spent a brief time with SML
<hcarty>
kaustuv: 22 as well
<hcarty>
Reading through more of that page, there seems to be a lot of SML mixed in with the OCaml
<thelema>
hcarty: I agree - point 11 seems odd
<kaustuv>
hcarty: Yeah, I agree. I meant mainly follow Pierce's whitespacing scheme.
<hcarty>
kaustuv: Point 11 seems rather extraneous, or at least non-standard for OCaml
<hcarty>
s/saving/saving and/
<hcarty>
Camarade_Tux: I'm using Bigarrays in several places here due to memory constraints. It can also make data saving sharing simpler in a few cases
<mfp>
hcarty, thelema: pushed mfp/ounit-testsuite. Once I have the toplevel tests back, I'll be rebasing against master, pushing and killing the branch, if nobody opposes.
<mfp>
hcarty: thx, trying
<hcarty>
mfp: I think it's git+ssh://git.ocamlcore.org/gitroot/batteries/batteries.git
<hcarty>
mfp: It's not on the forge, from what I know
<hcarty>
thelema: Quite
<thelema>
hcarty: well, it would be silly raising End_of_file for an IO that's reading from a string or non-file input
<hcarty>
thelema: Yes, I'm not sure regarding IO.No_more_input <-> End_of_file. That is a tough one to judge, given the flexibility of IO
<hcarty>
List.hd and List.tl may be bad style, but they are tempting functions to use when one is new to OCaml and functional programming. I think these folks are good targets for Batteries adoption so they may be hit by this
<hcarty>
Sorry, I meant specifically for IO in that statement
<hcarty>
There are not many functions available in the stdlib to get around that, at least for IO
<hcarty>
Exceptions seem to be used often for flow control though, particularly when working in the confines of stdlib
<thelema>
hcarty: it'd be pretty easy given knowledge of all the places batteries diverges from stdlib in ways that could possibly break things
<hcarty>
IO.No_more_input vs End_of_file makes sense given the new IO infrastructure, but oh my is it a pain to not find until run-time :-)
<hcarty>
I don't know how difficult it would be to build such a thing though
<hcarty>
I think a "open Batteries with Compatible" would be a good idea for legacy code as it would allow users to take advantage of new Batteries goodness without breaking existing code
<thelema>
hcarty: my proposal to fix this is to have a Compatibility module, so one can "open Batteries with Compatible" (or whatever the exact syntax is) and have the original exceptions and in/out_channels instead of IO.input/output
<hcarty>
And bad form or not, the functions are there to be abused in both libraries
<hcarty>
thelema: It may be bad form, but it is something that is not caught until run time
<hcarty>
thelema and Yoric[DT]: Would you mind reading over this when you have a chance? It is a list of some of the pitfalls I have faced while porting my code to Batteries. I think sometime similar, though perhaps better written, would be useful to include when Batteries 1.0 goes out the door: http://ocaml.pastebin.com/m541d893e
<hcarty>
And helping them with any compilation or other errors which come up
<hcarty>
I still think that is a lot easier than directing them to all of the GODI prereqs
<hcarty>
It is more usable by others though
<hcarty>
That, though, is far more work than installing GODI :-)
<hcarty>
That is certainly true. Hence the attempt at setting up an outside package repository
<hcarty>
Particularly for someone new to the process
<hcarty>
Ariens_Hyperion: It's much easier to type "apt-get install ocaml-foo" or "yum install ocaml-foo" than to go through the GODI installation
<hcarty>
It's a bit of an initial investment, but doesn't seem to generally be too difficult as long as the Debian infrastructure has not diverged too far from Ubuntu's last import
<hcarty>
I started making a 3.11 PPA for Intrepid
<hcarty>
flux: Ubuntu Personal Package Archive
<flux>
hcarty, PPA?
<hcarty>
flux: You could make a PPA :-)
<hcarty>
I don't know how it should fall with respect to the module naming scheme since the two capital letters are next to one another like IO, not spread out like BigArray
<hcarty>
It is at least worth a mention in the documentation
<hcarty>
So code which previously worked with open_in and Gzip.* now fails with a type error
<hcarty>
thelema: It breaks pre-Batteries code since Gzip (raw) uses OCaml in_channel and out_channel while GZip (Batteries) uses the Batteries IO
<thelema>
hcarty: I don't.
<hcarty>
thelema: Do you know the reason for the change?
<hcarty>
mfp: Cool, thanks
<mfp>
hcarty: git log <hashid>
<hcarty>
gitk will let you go to a hash id
<hcarty>
Ah, I see
<hcarty>
thelema: How do I view a specific commit by hash in git?
<thelema>
hcarty: you're right about GZip vs. Gzip. It was an intentinal change back in November. git commit id e8691a8a...
<hcarty>
Yoric[DT]: ping
<hcarty>
thelema: I think the camlzip library is named Gzip rather than GZip
<hcarty>
thelema: Sorry for disappearing, my net connection died
<hcarty>
thelema: I noticed this today when porting some code to Batteries
<thelema>
hcarty: probably just a typo
<hcarty>
thelema: Is there a reason Batteries.GZip is not Batteries.Gzip (same name as the parent module)?
2009-04-17
<hcarty>
marteo: It's ok, errors like this are part of starting out in a new language :-)
<hcarty>
marteo: aux [2;1] 0 2;; works as expected
<hcarty>
Because you typed in the list as a "(int * int) list" rather than an "int list"
<hcarty>
marteo: Yes
<marteo>
hcarty, yes but try aux [2,1] 0 2 ;;
<hcarty>
marteo: And seems to work as expected
<hcarty>
marteo: val aux : 'a list -> int -> 'a -> int * 'a list = <fun> is what I get here when entering it in the toplevel
<hcarty>
marteo: Then post a link here with your question(s)
<hcarty>
marteo: Paste to a code pasting site, ex: ocaml.pastebin.com
2009-04-16
<hcarty>
You have to disable any extra output (the Batteries splash in particular, it seems). But with that in place, the two play well together.
<hcarty>
At least a bit anyway
<hcarty>
For what it's worth, the latest DrOCaml seems to work with Batteries
<hcarty>
"Come to the OCaml side, we have monads"
<hcarty>
Both for utility and recruitment
<hcarty>
Alpounet: Given their popularity in Haskell-land, it is probably useful
<Alpounet>
hcarty, my current work just aims at providing monads in OCaml for either old Haskellers or people that just want to discover what monad are without having to implement them or switch to Haskell.
<hcarty>
kaustuv: I somewhat agree... I like the fact that monads aren't shoved down your throat in OCaml
2009-04-11
<hcarty>
I have been happy overall with the transition
<hcarty>
My evaluation has been largely to help me decide if I should use Batteries or just cherry pick the parts I want :-)
<hcarty>
thelema: Thank you for the clarification and for posting the List fix. If these things have been biting me in moving my relatively small code base over I imagine they will affect others as well
<hcarty>
Or is Empty_list to be treated as a special case of Invalid_argument?
<hcarty>
thelema: In this case, should functions which can raise exceptions such as Empty_list be added to the appropriate Exceptionless module?
<hcarty>
Either lots of special, per-module exceptions or none
<hcarty>
I would prefer, in an ideal world, that every module has the same structure for exceptions.
<hcarty>
Yes, it looks like Extlib introduced the Empty_list exception
<hcarty>
bluestorm: I think Extlib introduced the special handling of List, though I may be wrong about that
<thelema>
hcarty: lists are special in functinal languages
<bluestorm>
hcarty: why so ?
<hcarty>
thelema: That sounds ok to me. Perhaps List deserves a bit of special treatment.
<hcarty>
thelema: Is the fix to make everything use Empty_list or Invalid_argument?
<thelema>
hcarty: I'm committing a fix for that now. anything else?
<hcarty>
thelema: And I'm not sure if it would be best to give every module its own "Empty_foo" exception or if it would be better to stick with Invalid_argument everywhere
<hcarty>
thelema: For example, (List.hd []) raises Empty_list while (List.reduce f []) raises Invalid_argument
<hcarty>
thelema: Their use is inconsistent in the List module
<hcarty>
s/is //
<hcarty>
I don't like that there is are separate "Empty_list" and "Invalid_argument" exceptions used in Batteries.List though
<hcarty>
thelema: I'm not sure what the proper approach would be though
<hcarty>
thelema: I think the changes are largely for the best - replacing Failure exceptions
<thelema>
hcarty: can we put the List exceptions back to what they were in stdlib?
<hcarty>
Particularly the changes in the List module
<hcarty>
I'm leaning toward switching large portions of my code to use the Exceptionless modules since the move to Batteries is biting me with a lot of changes in exceptions thrown by various functions
<hcarty>
There are functions in there which raise Invalid_argument in the normal module, and according to Yoric[DT]'s comment this is acceptable in the Exceptionless case
<hcarty>
Yoric[DT], thelema: Sorry to keep asking this - Should I remove some of the functions from Seq.Exceptionless?
<hcarty>
It would make it more difficult to switch to Core rather than Batteries with an existing set of code using stdlib/Extlib
<hcarty>
No, particularly given the issues discussed in yminsky's talk and their code review procedures
<hcarty>
thelema: They wrote a bit about that on blog post, or perhaps on the mailing list. They gave up stdlib compatibility for consistency in argument order, labeling and a few other items
<hcarty>
bouzu: You really need to read the OCaml manual
2009-04-07
<hcarty>
palomer: There is also a Google Code repo, but it is an earlier and significantly different implementation
<hcarty>
palomer: I don't think it's being maintained. But it's in a usable, if very basic, state now in the 2007 Jane St. OSP Subversion repository
<hcarty>
flux: Yes - I wonder if the limiting factor is "I don't like lablgtk" or "I don't need/want to write a GUI app in OCaml"
<hcarty>
I'd volunteer to work on it, but it would be close to a year, most likely, before I really could
<hcarty>
I think FrGui, or something similar, is worth investing in for Batteries
<hcarty>
I've been reasonably happy with lablgtk + Cairo for my limited needs so far
<hcarty>
Spiwack: Do you know if it has been updated or maintained at all since the last OSP? It seemed quite promising, so it would be a shame for it to go away
<hcarty>
bouzu: Check out the Random module
<hcarty>
Or OSP rather
<hcarty>
Unfortunately I don't think Qt OCaml has been updated since the last SoC ended
<Alpounet>
hcarty, that's what I think for the moment, yep.
<hcarty>
Yoric[DT]: Best of luck recovering
<hcarty>
Alpounet: Gtk and Tk are your two main GUI options in OCaml, I think
<Yoric[DT]>
hcarty: thanks :)
<Alpounet>
hcarty, a handy GUI library, that will have to surviving to my tests and little tools programming ;-)
<hcarty>
Yoric[DT]: Hello and congrats on surviving all the way to a Batteries beta release :-)
<hcarty>
I've used it with lablgtk for some simple GUI testing, and for mixing lablgtk with a plotting library
<hcarty>
Alpounet: What sort of GUI are you after?
<hcarty>
Alpounet: It's a nice Cairo binding
2009-04-06
<hcarty>
The definition of appropriate may not always be clear, of course
<hcarty>
palomer: I feel fully justified in using ( = ), as long as it's appropriate!
<hcarty>
bjorkintosh: There has been noise about such things on the mailing list, but I don't have any specific examples