<hcarty>
And I missed your ping the other day ... was it just a request for testing?
<hcarty>
Yoric[DT]: Is the Batteries master git branch 3.11-safe?
2009-01-29
<hcarty>
Ok, thanks. Just curious.
<hcarty>
Perhaps "the earlier one" is a dropped branch then. I'm hoping to try the non-camlp4 version soon on a new app
<hcarty>
It seems like a potentially very nice library though
<hcarty>
Whereas the 2007 OSP version does not. I'm not sure what differences they have in function though.
<hcarty>
The version I found from 2006 on Google Code has an old-camlp4/camlp5 syntax extension
<hcarty>
Ah
<hcarty>
So it seems to be much easier to build on 3.10+
<hcarty>
Yoric[DT]: They seem to be significantly different... the OSP version does not include a syntax extension
<Yoric[DT]>
hcarty: I tried it briefly, one or two years ago and I liked it.
<hcarty>
Has anyone here used FrGui much, either the OSP version or the earlier one?
<hcarty>
uservoice?
<hcarty>
thelema: Init file not found: "/home/hcarty/Applications/godi/lib/ocaml/pkg-lib/camomile/../batteries/top.ml".
<hcarty>
Bigarray.* in Batteries is missing a few functions (unsafe_*) for 3.11
<thelema>
hcarty: I must have missed those comments.
<hcarty>
thelema: The alpha3 .tar.gz released yesterday compiles and runs here (3.11, 64bit), with some errors Yoric[DT] commented on
2009-01-28
<Yoric[DT]>
hcarty: ping
<hcarty>
Yes, same here
<hcarty>
Yoric[DT]: Init file not found: "/home/hcarty/Applications/godi/lib/ocaml/pkg-lib/camomile/../batteries/top.ml".
<Yoric[DT]>
hcarty: cool :)
<hcarty>
Yoric[DT]++;; thelema++;;
<hcarty>
Definitely.
<hcarty>
"make all opt install install-doc" worked here. Hooray!
<thelema>
hcarty: when yoric gets the release uploaded, grab that.
<hcarty>
Yoric[DT] and thelema: Just let me know what would be most helpful to test
<hcarty>
thelema: Thanks! I can give it a test here now, if it would help
<thelema>
hcarty: clean build on ocaml311 should work now.
<hcarty>
Yoric[DT]: Need testers?
<hcarty>
Ah, ok. estring would be a nice addition.
<Yoric[DT]>
hcarty: a version of estring adapted for Batteries.
<hcarty>
Yoric[DT]: What is pa_string?
2009-01-27
<hcarty>
My experience with objects in OCaml is that they can be very simple and easy for simple tasks. Their complexity seems to scale with the complexity of the task at hand more quickly than a comparable module-based implementation
<Yoric[DT]>
hcarty: whenever we start supporting pa-do, we will take advantage of it to get both <| and |> .
<Yoric[DT]>
hcarty: well, we want <| and |> but we don't quite support it yet because we don't want to duplicate the work on pa-do.
<vixey>
hcarty, I have a decision on it but nobody agrees with me
<hcarty>
Yoric[DT]: Is there a decision on ( **> ) and ( <** ) vs ( <| ) and ( |> )?
<hcarty>
mrvn: That works as well or better... and doesn't have the problem of getting out of sync with your local installation
<hcarty>
I think, given that the given link is from the author's home institution, it's probably ok
<mfp>
alexyk, hcarty: an alternative (less "magic") way to do that let print_flush fmt = Printf.kprintf (fun s -> print_endline s) fmt;;
<tar_>
hcarty: I'm still looking for documentation on = vs ==
<hcarty>
tar_: <> is to != as = is to ==
<hcarty>
mrvn: both a and (ref 0) have the same contents, but they are distinct entities. I think that's the correct way to phrase it...
<hcarty>
!= gives true, <> gives false here
<hcarty>
a <> ref 0)
<tar_>
hcarty: well, same results
<hcarty>
tar_: Maybe you want ( <> ) rather than ( != )?
<hcarty>
mfp: There is an example in pa-do for optimized ( <| ) and friends
<hcarty>
mfp: Thanks, that's much cleaner
<hcarty>
mfp: Oh, right! I saw something about that recently. On the mailing list possibly.
<alexyk>
hcarty: printf_debug with two arguments fails complaining of too many -- I'm afraid one s doesn't cover x y
<hcarty>
I'll hopefully get a chance to look at that
<mfp>
hcarty: let print_flush fmt = printf (fmt ^^ "%!")
<hcarty>
Ok, thanks
<hcarty>
Yoric[DT]: If I get time to make up a Batteries patch for the 3.11 Bigarray missing pieces -- how do you handle the .mli and documentation? Do you just copy directly from the stdlib?
<hcarty>
alexyk: godi has support for 3.11, though I don't know which packages are not ported yet
<Yoric[DT]>
hcarty: great :)
<hcarty>
Yoric[DT]: Very nice! I'll try to start working it in to some of my code over the next few weeks
<hcarty>
alexyk: print_debug would work just like printf, except that it flushs all output streams on each call
<Yoric[DT]>
hcarty: thanks.
<hcarty>
Yoric[DT]: How stable is the Batteries API at this point? I can compile it on 3.11 now, and while it's still missing a few 3.11-isms (unsafe set and get for Bigarrays at least) it seems to be getting nicer by the day
<alexyk>
hcarty: will this make s a single argument, so I'd have to define many? or printf makes s a magic variable argument?
<hcarty>
Or something along those lines, adjusted for the function(s) and surrounding output you want
<hcarty>
let print_debug format s = printf format s; flush_all ()
<hcarty>
Glad to help. It's an easy thing to be bitten by.
<hcarty>
I'm not entirely clear on all of the details. But if you type it in the toplevel you can see the type difference between the two definitions
<zerny>
hcarty: ok, I would be more than glad to hear your approach? Right now I am creating versions of all the CMakeDetermineOCamlCompiler.cmake and related scripts
<hcarty>
Or so I have been told
<hcarty>
I did not write the CMake integration though, and I think it is rather hackish at the moment
<hcarty>
zerny: I wrote OCaml bindings for PLplot, and PLplot uses CMake as its build system
2009-01-15
<thelema>
Yoric[DT]: fair enough. My batteries was compiling fine, hcarty had compilation errors, I did a 'make clean', and now I've got his error
<hcarty>
Tomorrow, of course
<hcarty>
Please let me know if I can help with testing or otherwise
<hcarty>
thelema: Thanks for looking in to it
<hcarty>
This is with a snapshot .tar.gz downloaded from the git web interface, from the latest ocaml311 revision
<hcarty>
"ocamlbuild src/main/nothreads/batteries.cma" gives a different error: File "src/core/toolchain.mli", line 630, characters 60-75:\nError: Unbound type constructor Extlib.IO.input
<hcarty>
thelema: That's from a "make byte"
<thelema>
hcarty: I'll look into it.
<hcarty>
Then the above error
<hcarty>
File "src/core/extlib_threads/extMutex.mli", line 91, characters 19-41:
<hcarty>
Same issue on a clean snapshot of the latest ocaml311 branch
<hcarty>
The clone is taking a very long time though
<hcarty>
I'm trying to get a clean git clone now though, in case I messed something up in the repository
<hcarty>
thelema: I get this error: Error: Unbound type constructor Extlib.Concurrent.lock
<hcarty>
Will do
<hcarty>
thelema_: Ok, thanks. I'll give it a try here...
<hcarty>
As in, do you know if it compiles and functions as one would expect?
<hcarty>
thelema_: Is the Batteries ocaml311 branch working?
<hcarty>
It also provides an API for producing more flexible extensions which are reusable across modules
<hcarty>
So you could then write Module.(a > b + c) which would be rewritten as (Module.gt a (Module.add b c))
<hcarty>
You can use syntax like "OVERLOAD Module ((<) -> lt; (>) -> gt; (+) -> add)" to define overloadings local to a single file
<hcarty>
And several examples come in the distribution
<hcarty>
Pre-made syntax rules are included for the built-in numeric types
<hcarty>
The specifics can be altered for individual modules though
<hcarty>
It would be rewritten as (float_of_int a +. 2.0), I think
<hcarty>
Float.(float_of_int a + 2) would work as expected
<hcarty>
Or be cast appropriately
<hcarty>
mrvn: So (let a = 3.0 in Float.(a + 2)) would have a value of 5.0, while let a = 3 in Float.(a + 2) would cause an error when it is type-checked
<hcarty>
mrvn: pa-do works with literals directly, while variables are expected to be of the "proper" type
2009-01-08
<hcarty>
for example
<hcarty>
let sumints l = List.fold_left ( + ) 0 l
<hcarty>
where "best" = "consistent" I suppose
<hcarty>
Since they are needed for ( * )
<hcarty>
But spaces are best
<hcarty>
Either way
<hcarty>
Well, I don't know how it works in Haskell... but you can use ( + ) and friends with folds
<alexyk>
hcarty: with spaces around + right?
<hcarty>
alexyk: Yes
2009-01-06
<hcarty>
Camarade_Tux: You could try searching the BTS. It sounds like it may be a bug.
<alexyk>
thelema, hcarty: thanks! it is clearer now
<hcarty>
And I'm apparently up too late, as this question was already answered... sorry for the noise
<hcarty>
alexyk: Array.init 2 (fun _ -> ref 0) will produce an array with a unique (ref 0) in each element.
<hcarty>
alexyk: You need to use Array.init rather than Array.make. Array.make produces an array with (effectively) two pointers to the same (ref 0) in your example.
2009-01-05
<hcarty>
mohbana: I think most folks using emacs go with tuareg
2009-01-03
<hcarty>
alexyk: That I'm not sure of... I have worked with functors a bit, but I have never tried to do that
<alexyk>
hcarty: thx! also -- can I define a signature and the body both parameterized by the same module?
<hcarty>
alexyk: max_int
2009-01-02
<hcarty>
There is a library on the forge with unsigned 32bit and 64bit integer support
2008-12-29
<hcarty>
mrvn: I have not used exceptions that way, but I think Yoric[DT] did some work along those lines
<mrvn>
hcarty, flux: How does that work with exceptions?
<hcarty>
electricfeel: OCaml does not keep type information around, for the most part, in the compiled code. So having different items in a list (or array or other structure) wouldn't be safe without extra scaffolding
<hcarty>
electricfeel: Otherwise you have to use flux's suggestion
<hcarty>
electricfeel: The type is 'a option, and 'a can only be one type for a given value (int option list, for example)
2008-12-22
<hcarty>
rlwrap is a readline wrapper
<hcarty>
Something like "alias oc='rlwrap -r -c -D 2 ocaml'" is nice
<hcarty>
Use rlwrap or ledit
<hcarty>
Ah
<hcarty>
jonafan: "do arrows"?
2008-12-21
<hcarty>
It can be very useful at times
<hcarty>
alexyk: Not a problem. In general, if you match a pattern, you can add "as foo" to bind the value to "foo" in the appropriate scope
<alexyk>
hcarty: thx!
<hcarty>
alexyk: prints "foo" then raises Failure "foo"
<hcarty>
alexyk: # try failwith "foo" with Failure s as ex -> print_endline s; raise ex;;
2008-12-18
<alexyk>
hcarty: ah, so they'll be time-sliced?
<hcarty>
alexyk: You can use threads in OCaml, but it won't take advantage of more than one CPU
<Anarchos>
hcarty i finally found my mistake : i didn't protect access to caml_local_roots, which is a global pointer
2008-12-17
<hcarty>
palomer: The official archive does not seem to have been updated since the OSP ended. But there is something there.
<Anarchos>
hcarty i still think a concurrent GC would not improve the speed, but should improve the ability to link with multithread C++ api :)
<Anarchos>
hcarty ok. i try to interface with a C++ multithreaded api, protecting the callbacks with a semaphore, but i have random segault in caml_oldify_local_roots
<hcarty>
Anarchos: You would probably have better luck on the mailing list
<hcarty>
Glad to help. The library reference is a good thing to keep close by.
<hcarty>
But even there I'm not sure it would be worth it in most cases
<hcarty>
swig does have promise for huge libraries perhaps
<hcarty>
I had hoped to use swig for some C libraries, but used camlidl + hand-written code instead
<alexyk>
hcarty: aj ok
<hcarty>
alexyk: I haven't used the extension, I've just read about it in the swig docs
<alexyk>
hcarty: is the extension a separate thing somewhere?
<hcarty>
alexyk: Regarding swig, in my (limited) experience, the generated interfaces tend to be very thick. There is a syntax extension which is, as I understand, meant to hide some of that. The Jane St. qtcaml OSP may have some useful tools for C++ bindings though.
2008-12-07
<alexyk>
hcarty: nice
<hcarty>
alexyk: When GODI adds 3.11 support, selecting OCaml for rebuild with automatically rebuild the relevant libs as well
<hcarty>
And Fedora and GODI, for that matter...
2008-12-06
<hcarty>
alexyk: You likely also want to use ( = ) rather than ( == )
<hcarty>
thelema: I'm off for now, but I am looking foward to see what comes of this library + extension
<hcarty>
Is code shared between objects of the same class, or is it duplicated for each object?
<hcarty>
But given that there is compiler magic involved, it's all but certainly application-specific
<hcarty>
(also microbenchmarks) I've found objects to be similarly performant to records when used as simple records
<hcarty>
And I imagine the specifics would depend on how the code is used
<hcarty>
Ok. I wasn't sure how much of a difference caching would make on the class side
<hcarty>
Is there a significant performance difference between using variant types vs classes or records?
<hcarty>
Or something else?
<hcarty>
thelema: What would the underlying mechanism be? Classes or records? (curiosity)
<hcarty>
thelema: Probably so, yes
<hcarty>
s/accurate/specific/
<hcarty>
Or, to be more accurate, in my larger projects
<hcarty>
I'm just worried about losing a compile time check that makes OCaml very useful in a larger project
<hcarty>
Not so much backwards compatibility
<hcarty>
It may be useful for most projects. But it is a pretty big change from the default OCaml way of working.
<hcarty>
Not many libraries change ( + ) and friends globally
<hcarty>
If it were enabled by default
<hcarty>
It would change the learning curve for Batteries of one group or the other
<hcarty>
I guess that may be a matter of folks new to OCaml vs folks new to Batteries
<hcarty>
thelema: I think the extension would be quite useful as well. I'd just prefer it to not be the OCaml-default case :-)
<hcarty>
Smerdyakov: That is probably true, though they won't do me much good until I'm in a situation where I want to and am reasonably able to switch to a language with type classes
<thelema>
hcarty: I agree the extension wouldn't be as appropriate for larger projects, but there are times it'd be useful.
<thelema>
hcarty: the cast would go whichever way the user would expect - I'm sure a general rule can be established.
<Smerdyakov>
hcarty, it sounds like type classes would do just as well for you.
<hcarty>
The only time I find it a major annoyance now is when I'm using the toplevel and want to do a quick calculation. In that case, something like you have proposed would likely be nice
<hcarty>
It has bitten me before in C, and while the ( + ) vs ( +. ) thing annoyed me at first in OCaml, I've been quite happy with it in larger projects
<hcarty>
thelema: If the cast is implicit, which way should the cast go?
<hcarty>
mfp: I'm a fan of the ( + ) vs ( +. ) operators as well... they catch a lot of bugs which would otherwise be a royal pain to track down. pa_do provides a very nice alternative to a global generic ( + )
2008-12-05
<hcarty>
Lack of sleep can do that to a person :-)
<hcarty>
Yoric[DT]: Ah, ok. That makes sense
<Yoric[DT]>
hcarty: sorry, I mixed there, too.
<hcarty>
Yoric[DT]: That's fine by me - I just don't see how?
<Yoric[DT]>
hcarty: no, I maintain that part.
<hcarty>
Yoric[DT]: I would think it would be the other way around? How does the non-hierarchy lead to fewer module clashes?
<Yoric[DT]>
hcarty: not really.
<hcarty>
Yoric[DT]: Has a decision been made on the hierarchy in Batteries?
<alexyk>
hcarty: this is the most pleasant channel in fact, so far -- and the right size; look as Haskell and C++ scroll by, too crowded; and postgresql has 2,500 messages today -- those DBAs have not much else to do, clearly :) here's size to stay coherent enough
<hcarty>
"we" being the folks in #ocaml and on the mailing lists. And the library authors I've dealt with.
<hcarty>
alexyk: To be fair, we do have our share of trolls... but the community around OCaml tends to be quite pleasant
2008-11-26
<hcarty>
alexyk: There is a printing module as part of the OCaml Calendar library ... a sprintf-like function is in there somewhere
<hcarty>
For local parallel tasks, there are several fork-based parallel functions/libraries available
<hcarty>
The last message I remember reading said that the next release would likely be against 3.11.0
<hcarty>
alexyk: JoCaml, according to the mailing list, has not been tracking the regular OCaml releases very closely
<hcarty>
The above match should be in a recursive function to be effective, as Smerdyakov suggests
<hcarty>
I'm not sure I have the syntax for the middle match case correct...
<hcarty>
match l with [] -> ... | [a] -> ... | a :: b :: tl -> ...
<hcarty>
Palace: You could build that in to the match
<Palace>
hcarty, yea it could look somthing like that, is there some generic placeholder i could place at the end of the list though for the last pair ?
<hcarty>
Palace: Something involving "match foo with a :: b :: tl -> ..." may get you started?
2008-11-16
<hcarty>
:-)
<hcarty>
bluestorm: Should I join batteries-devel?
<hcarty>
I have not really thought about how pa-do should be integrated in to Batteries. So far, I've just extended the META file to be finer grained.
<hcarty>
bluestorm: Not at all a problem. I've been busy with school/research.
<bluestorm>
hcarty: i'm sorry i didn't answer you faster
<hcarty>
Yoric[DT]: Everybody makes mistakes...
<hcarty>
Yoric[DT]: Sure. I'm happy to help where I'm able.
<Yoric[DT]>
hcarty: hi
<hcarty>
Yoric[DT]: pong
<bluestorm>
and hcarty is probably as knowledgeable as me about camlp4 so he shouldn't wait for me to go on on such things
<Yoric[DT]>
hcarty: ping
2008-11-15
<ertai>
hcarty: hum I didn't heard of 3.10.3, but I will ask that
<hcarty>
bluestorm: Yoric[DT] said that you are the one to talk with regarding camlp4 extensions in Batteries
<hcarty>
bluestorm: Regarding my pa-do + batteries comment a few days ago, I was wondering if there is an interest in making pa-do part of Batteries, either as a dependency or otherwise
<hcarty>
ertai: I saw that there is a changelog for OCaml 3.10.3 in CVS - will this get the camlp4 + toplevel fixes?
<ertai>
hcarty: pong
2008-11-14
<palomer>
hcarty, the problem with that is that it's not relative to the executable
<hcarty>
palomer: or ./data/ or similar
<hcarty>
Make them select it every time the app starts :-)
<hcarty>
palomer: configure script? Or a dot-file in their home directory?
<hcarty>
Is anyone here using some version of OCaml 3.11? In particular, I'm wondering if ocamlbuild has support for building libraries as .cmxs
<hcarty>
Yes, it is
<hcarty>
It may be in Pervasives...
<hcarty>
Does exit 0 work? I haven't used it in a gtk app