julm has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
ski_ has joined #ocaml
caligula__ has quit [Read error: 131 (Connection reset by peer)]
caligula__ has joined #ocaml
julm has quit [Read error: 145 (Connection timed out)]
julm has joined #ocaml
tmaedaZ is now known as tmaeda
julm_ has joined #ocaml
Mr_Awesome_ has quit [Read error: 104 (Connection reset by peer)]
julm__ has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
julm_ has quit [Read error: 110 (Connection timed out)]
blackdog_ has quit [Remote closed the connection]
julm has joined #ocaml
julm__ has quit [Read error: 110 (Connection timed out)]
julm_ has joined #ocaml
thrasibule_ has quit [Read error: 110 (Connection timed out)]
julm has quit [Nick collision from services.]
julm_ is now known as julm
clog has joined #ocaml
_zack has joined #ocaml
onigiri has quit []
<Camarade_Tux>
morning :)
tmaeda is now known as tmaedaZ
<Yoric[DT]>
'morning
<Camarade_Tux>
hahaha: http://www.google.com/trends <- ^top5 hot trends: "gmail down", "gmail outage", "gmail not working", "gmail problems" and "gmail down september 1 2009" ^^ (actually the whole top10 is like that but I'm to lazy to copy everything ;) )
Yoric[DT] has quit ["Ex-Chat"]
<Camarade_Tux>
gildor or _zack: do you know if safe_camlp4 a binary that comes with findlib?
<Camarade_Tux>
(and not with inria's ocaml)
<xevz>
Camarade_Tux: Part of findlib, it seems.
<Camarade_Tux>
ok, thanks :)
<Camarade_Tux>
it's a shell script with a comment at the top: "Call camlp4 with fallback method if dynamic loading is not supported" and I'm suspecting it's the reason I have "undefined reference to dynlink.cma" errors :D
<Camarade_Tux>
(findlib doesn't call camlp4, it calls safe_camlp4)
Yoric[DT] has joined #ocaml
Submarine has joined #ocaml
<Submarine>
howdie
<Submarine>
Has somebody here got access to ACM Computing Reviews?
<Camarade_Tux>
what is the use for the sexplib.cma in 'camlp4 sexplib.cma pa_sexp_conv.cmo'? it doesn't seem to be needed
<Submarine>
it probably implements s-expressions? :-)
<Camarade_Tux>
I'm trying to debug something on windows and as far as I can tell everything works fine without the .cma files and only the pa_*.cmo
<Camarade_Tux>
it looks like they can be used just like .cmo files but are useless here (at least for sexplib)
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
matthias_1 has joined #ocaml
<Camarade_Tux>
I thought the order in which .cma files where passed to ocamlc didn't matter =/
<Camarade_Tux>
basically ocamlfind calls safe_camlp4 which provides a fallback in case dynlink isn't supported, this fallback uses mkcamlp4
<Camarade_Tux>
in turn, mkcamlp4 calls ocamlc: [ ocamlc -I +camlp4 camlp4lib.cma dynlink.cma Camlp4Bin.cmo a.ml -linkall ] fails with undefined reference to dynlink
<Camarade_Tux>
a simple solution is to move dynlink.cma before in the chain of arguments like: [ ocamlc dynlink.cma -I +camlp4 camlp4lib.cma Camlp4Bin.cmo a.ml -linkall ]
<Camarade_Tux>
another possibility is to remove the need for any .cma file when calling safe_camlp4, that would probably require fixing several packages which maybe isn't even easy and some may actually use .cma files and not .cmo ones which means this is not a guaranteed fix
<Camarade_Tux>
</spam>
bluestorm has joined #ocaml
<bluestorm>
flux: just in case, I just pushed current_timestamp
<bluestorm>
(I have started working on the default values, but that's a not-so-trivial feature and I'm quite busy so I won't give any timeline)
<Camarade_Tux>
I think a simple change to mkcamlp4.ml solves the "undefined reference to dynlink" problem with camlp4 on archs that don't support dynlink and use ocamlfind \o/
matthias_1 has left #ocaml []
<Camarade_Tux>
(the only thing I don't understand is what is the use for dynlink when dynlink doesn't work)
marteo has joined #ocaml
wzp has quit [Read error: 54 (Connection reset by peer)]
<Camarade_Tux>
(seems the first line got stripped but anyway, it's for the idea)
mol has joined #ocaml
<ertai>
Camarade_Tux: you have swapped some arguments
<ertai>
why ?
rbancrof1 has joined #ocaml
rbancroft has quit [Remote closed the connection]
<Camarade_Tux>
ertai: so that dynlink.cma appears before camlp4lib.cma when it is given on the command-line
<Camarade_Tux>
it makes things better here (cygwin) although it's not perfect yet
<ertai>
Camarade_Tux: ok sounds good
<Camarade_Tux>
nice :)
<Camarade_Tux>
right now I just needed to know if the approach was good, I'm trying to get a project of mine buildable with ocamlbuild on cygwin, I'll try to make a complete patch then :)
verte has joined #ocaml
<ertai>
ok
Alpounet has joined #ocaml
* Camarade_Tux
thinkgs teh windows just got a virus
<Alpounet>
impossible.
<Alpounet>
any batteries folk in here ?
_zack has quit ["Leaving."]
_zack has joined #ocaml
mol has quit ["Leaving"]
<thelema>
Alpounet: pong
<Alpounet>
what's your opinion about the lite version's hierarchy, etc ?
<thelema>
I'm the originator of aaa - I'm all for simplifying batteries to allow more people to use it.
<thelema>
you want to know whether I approve of taking out some particular module?
<thelema>
functionality?
<thelema>
or the idea of a cluster of related projects?
<Alpounet>
hmm
<Alpounet>
rather the way the user will use batteries
* thelema
just caught up on the batteries mailing list to your post
<Alpounet>
like module hierarchy, the way people will link batteries against their projects, etc
<Alpounet>
that's very important and is definitively a key topic for the use of batteries aaa.
<thelema>
I want a single "open Batteries" to enable all the functionality provided by whatever batteries are installed
<thelema>
(of course it would be available through Batteries.* before that, but I really approve of overriding String, etc. through the one command.
<Alpounet>
okay, we would then have access to Enum, String, IO, etc modules.
valross has quit ["Ex-Chat"]
<Alpounet>
It looks ok to me.
<Alpounet>
what about linking batteries against some ocaml code ?
<Alpounet>
one big batteries .cm(x)a ?
_zack has quit ["Leaving."]
<thelema>
for now, I'm fine with a single module approach, and leaving it to the compiler authors to improve the linker
caligula_ has joined #ocaml
<thelema>
I like the idea of improving binary size, but don't think that it really matters
<thelema>
in most situations
<Alpounet>
Me too. OCaml isn't (yet !) much used in embedded systems, AFAIK.
<thelema>
an improved linker would help a lot in such situation.
<gildor>
thelema, Alpounet: an improve linker that can drop useless code is REALLY the best way to go
<gildor>
thelema: what is aaa ?
<thelema>
gildor: aaa batteries is a smaller version of the batteries library - no camlp4, no sexplib
<thelema>
If we can get conditional compilation going right, it could form the core of batteries, with "car batteries" providing the kitchen sink experience.
<flux>
alpounet, I could've actually used it, but the binary size can be an issue there.. at the very least you'd need to do a multi-call binary to limit the impact.
<thelema>
flux: you rejected batteries because of battery size?
<Alpounet>
Yeah ok.
<thelema>
s/battery size/executable size/
caligula__ has quit [Read error: 104 (Connection reset by peer)]
<gildor>
correct me if i am wrong but haskell generate much bigger executable ?
<gildor>
what's the size of an exec with batteries ?
<Alpounet>
flux, I think that if there was more demand regarding linker improvements, it could be done. But it doesn't seem to be a priority for now.
<thelema>
3MB for a pretty simple program
Snark has joined #ocaml
<gildor>
/usr/bin/darcs (haskell) is 4MB...
<gildor>
so haskell/ocaml seems comparable on this point
<thelema>
do we want to compete with haskell? I say we want to compete with C, maybe with Java/.NET
<Alpounet>
yep. But they're doing a lot of work for a Haskell iPhone SDK, and there they may work around this problem.
<gildor>
haskell is probably closer to us than C/Java/.Net
<gildor>
however, being able to compare with C/Java/.NET is great -- but we must take into account our direct competitor
<gildor>
just a matter of knowing what is feasible or not...
<thelema>
3MB is aaa batteries (That's what I'm dogfooding on my computers)
<gildor>
(but i think linker improvement to remove useless code is feasible, just that direct competitor doesn't see any value at doing it)
* thelema
wants to provide enough value that using batteries is worth it despite these disadvantages of exe size
<gildor>
thelema: ah ok, do you have any size for the same exec with pure batteries
* thelema
is recompiling
<thelema>
okay, hello_world.native under aaa is 4mb (hmm, how is my other exe 3.5mb?)
<thelema>
(also, this is x64)
_zack has joined #ocaml
deavid has quit [SendQ exceeded]
* thelema
is finally back to compiling old batteries (had to reinstall sexplib)
deavid has joined #ocaml
_andre has joined #ocaml
deavid has quit [SendQ exceeded]
ski_ has quit ["Lost terminal"]
<thelema>
hello_world under full batteries: 4.3MB
<gildor>
so using aaa allow 4.3MB -> 4MB...
deavid has joined #ocaml
<thelema>
curious result - switching the ocamlbuild tag from use_batteries to pkg_batteries results in a 700K executable... hmmm
<thelema>
I wonder if that's the dynlink mojo that DT was working on
<flux>
thelema, no, batteries wasn't around at that time
<Camarade_Tux>
you should check the actual ocaml{c,opt} command-line
<thelema>
gildor: yes, so far, the aaa proect has little effect on executable size - that wasn't something I wanted to fix. Yoric's reorg of batteries into many subprojects will result in much smaller executables.
<thelema>
but that reorg will take away the "standard" part of the idea of a stdlib
spidermario has joined #ocaml
ski_ has joined #ocaml
<gildor>
thelema: we talk a little bit of that kind of (size) stuff with other debian folks
<gildor>
thelema: basically there is two way to improve size of exec
<gildor>
thelema: squeezing useless code
<gildor>
thelema: using shared library (i.e. dynlink stuff), not linked with exec
<gildor>
of course, shared library can result in very small exec
<gildor>
but I don't know which one could interest ocaml community
<thelema>
In theory ocaml has dynamic libraries, but in practice, not so much.
<thelema>
so I see more value in the 'dropping useless code' direction
<thelema>
especially since we don't (and likely won't) have any binary compatibility between versions of ocaml
<gildor>
make sense
<gildor>
but dropping useless code won't drop the exec size to <100K
<flux>
gildor, wouldn't it, for hello world atleast?-)
<flux>
if it was pervasive to cover, say, Pervasives..
<flux>
+enough
<gildor>
I think Pervasives only is >100K
<flux>
yes, but if the intelligent linker would simply remove all code that isn't required
<flux>
I imagine the required portion of Pervasives for hello world to work is very small
<flux>
and from there on it would be 'pay as you go'
<flux>
hm, statically compiled (&stripped) hello world in C (with gcc) is already 0.5M :-o
<gildor>
flux: you are hitting the "using shared library" stuff
thrasibule has joined #ocaml
<gildor>
flux: but you probably linked libc statically, which is not done for ocaml
mapreduce has joined #ocaml
<gildor>
this kind of deps is already outside OCaml exec
<flux>
gildor, yes, I was merely comparing.. while ocaml does use libc for doing its stuff, the amount of code requried to produce 'hello world' is about the same (I imagine) in both C and ocaml
<flux>
I was thinking not all of the libc.a would be linked in either, but apparently a large part of it does
<flux>
a minimal binary produced with ocamlc -nopervasives foo foo.ml is 5 kilobytes
<thelema>
bytecode or native?
<flux>
ah, of course I had something wrong in it :)
<flux>
it's bytecode
<flux>
but I can't compile an empty program with ocamlopt -nopervasives
<mapreduce>
I'm trying to grok ML modules. Modules being parameterised by other modules seems like it'd be implemented by generating code for each 'instantiation' of a module. Is this roughly accurate?
<flux>
main, caml_globals_inited and caml_system__frametable are missing
<flux>
the minimal native binary is 120k (32-bit platform)
<flux>
scratch that, the minimal hello world that is
<gildor>
flux: minimal bytecode for hello that work is 5,6k
<gildor>
(which output something on the screen)
willb has joined #ocaml
<flux>
merely including the Unix-module grows it by 40k
<gildor>
compare to bytecode hello-full which is 12K
<flux>
adding netstring adds 250k more :)
mapreduce has left #ocaml []
thrasibule has quit [Read error: 145 (Connection timed out)]
f_[x] has quit [Read error: 110 (Connection timed out)]
jimmyb2187 has joined #ocaml
Eataix has joined #ocaml
Eataix has quit []
<Camarade_Tux>
seems I got the camlp4 issue sorted but now I have troubles with C libs :)
spidermario has quit [Remote closed the connection]
marteo has quit ["Debian GNU/Hurd is Good."]
bombshelter13_ has joined #ocaml
spidermario has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
tmaedaZ is now known as tmaeda
bjorkintosh has quit ["Leaving"]
julm_ has joined #ocaml
julm has quit [Nick collision from services.]
julm_ is now known as julm
<spidermario>
does the OCaml standard library contain a function for numeroted formatting of strings ?
<thelema>
numeroted?
<Camarade_Tux>
could you give an example of what you want?
<spidermario>
"{0} is the first, {1} is the second"
<thelema>
ah, no.
<spidermario>
ok, thanks anyway
<thelema>
you want a function 1 -> "first" | 2 -> "second" | 3 -> "third"
<thelema>
etc
<thelema>
and a bunch of these for all different ways of writing numbers
<spidermario>
something like Qt "arg" function
<thelema>
it wouldn't be difficult to write, but that's definitely not made the list of important things to put into a stdlib
<spidermario>
ok, thanks for your help :)
* thelema
reads arg
<thelema>
I think we had positional parameters in printf
<thelema>
but there was a bug in them and noone used them, so they got dropped
<thelema>
in 3.11, I think.
<spidermario>
ok
<spidermario>
again, thank you
<thelema>
what do you want them for?
<spidermario>
for now, nothing specific
<thelema>
ok. Enjoy ocaml.
<spidermario>
thanks ^^
mol has joined #ocaml
Ched has joined #ocaml
<thelema>
Is anyone else interested in OCaml support in emacs' ECB?
<flux>
ECB?
<thelema>
Emacs Code Browser
<flux>
oh, haven't used it
<flux>
should I?-)
<flux>
but I've found ocamlspotter to be nice
mfp has quit [Read error: 104 (Connection reset by peer)]
* thelema
doesn't use ocamlspotter, but it looks similar
<Camarade_Tux>
if I want to mkcamlp4 with mikmatch which uses pcre, do I have to give it '-ccopt -lpcre' or is there another solution?
<thelema>
patching the compiler seems excessive.
<Camarade_Tux>
I think it's camlp4 is ok on the inria side, now I need to patch findlib's safe_camlp4
* thelema
is happy to avoid camlp4
<Camarade_Tux>
mikmatch is really nice :)
<Camarade_Tux>
and not having to write tons of definitions for each type with sexplib is nice too :)
* thelema
approves of mikmatch
ched_ has quit [Read error: 110 (Connection timed out)]
<Alpounet>
thelema, it can be interesting [concerning ECB & OCaml]
mfp has joined #ocaml
<Camarade_Tux>
\o/
<hcarty>
The current state of Batteries seems to be getting a little depressing, with the semi-departure of David and pre-release forking.
<thelema>
hcarty: the fork will be merged once we get some good structure for pre-processing
<thelema>
I'm thinking about doing it all using configure
<thelema>
and having a ton of .in files
<hcarty>
thelema: That's reassuring. I don't want to have to rip out all of the Batteries-dependent code I've written so far :-)
<thelema>
as long as I'm using it, it'll be maintained.
<thelema>
and I hope to keep using ocaml for a long, long time.
<thelema>
despite all the pressures otherwise. I hope not to switch to F#.
<Alpounet>
Don't !
<hcarty>
thelema: :-) And thank you for the information.
<thelema>
I've forgotten what glaring flaw F# had that I stopped considering it
<thelema>
but I just saw a debug session with VS, and the data inspection would be really nice.
<hcarty>
Yes, a proper IDE or similar suite of tools would be quite nice. There are a lot of half-finished projects to help with this, but nothing that feels ready to go.
<Alpounet>
yaeh
<Alpounet>
lots of candidates for newhope...
<orbitz>
thelema: Null Pointers probably
<Camarade_Tux>
ertai: this patch ( http://ocaml.pastebin.com/f753b1408 ) checks if "dynlink.cma" is given in the list of arguments to mkcamlp4 and if it is, it moves it so it is the first module passed to ocamlc (since other modules depend on it and it doesn't depend on any)
<Camarade_Tux>
does it look ok? I tried to make it short without having to dive through the whole camlp4 sources
verte has quit ["~~~ Crash in JIT!"]
f_[x] has joined #ocaml
_zack has quit ["Leaving."]
Submarine has quit ["using sirc version 2.211+KSIRC/1.3.12"]
julm has quit [Remote closed the connection]
julm_ has joined #ocaml
julm_ is now known as julm
smimou has joined #ocaml
Yoric[DT] has joined #ocaml
onigiri has joined #ocaml
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
spidermario has quit [Remote closed the connection]
Yoric[DT] has joined #ocaml
<thelema>
orbitz: in f#, everything's an option type?
<orbitz>
thelema: i'm not sure how it works, but if you call out to anything esle on .net you can get a null pointer
<thelema>
hopefully that means they're all returning option types, and the real types are non-nullary
<thelema>
in any case, I appreciate your help making me hate F# so I can keep working on batteries
<orbitz>
thelema: i'm under the impression it isn't an 'a option
<thelema>
Null Pointer Exceptions are a good reason to avoid F#
<bluestorm>
'a option and NULL values does not have exactly the same semantic, at least for SQL NULL (wich are probably the most wicked NULL values out there)
<orbitz>
"The null value is not normally used in F# for values or variables. However, null appears as an abnormal value in certain situations. If a type is defined in F#, null is not permitted as a regular value. If a type is defined in some other .NET language, null is a possible value, and when you are interoperating with such types, your F# code might encounter null values."
<bluestorm>
I don't think it's quite fair to blame that on F#, as they're barely managing with their other .NET compatriots, but this still could be a bit hairy
<orbitz>
bluestorm: it seems easy enough to handle, just easy to forget to handle too
<orbitz>
and the type checker isn't going to help you at all
<thelema>
which is why I love OCaml - lots of help from the type checker
<thelema>
I imagine I could make a wrapper to turn a nullary into an option
<thelema>
but I don't want to use F#
<orbitz>
accorig nto minksy's caml trading talk .net's VM also has trouble keeping up with functional languages, which may or may no tbe a significant drawback
<thelema>
performance is important for what I'm doing, so that's enough of a reason to stick with OCaml
slash_ has joined #ocaml
<Alpounet>
I can't program in a dynamically typed language, anymore...
<orbitz>
Alpounet: poor thign!
<Alpounet>
heh
<bluestorm>
use OCaml : with a little Obj.magic, you can have dynamic languages too ! :-'
<orbitz>
or the universal type hat thelema send me last week
<Alpounet>
I don't want them at all, actually.
<bluestorm>
(and for the most nostalgic, real men segfaults are also available)
<thelema>
orbitz: you can write a wrapper for everything that allows using a Univ.t for all values
<thelema>
s/everything/every function/
<orbitz>
Alpounet: i used to think dynamic was the sex, then i found languages that actually had decent static type systems
<Alpounet>
heh
<thelema>
yup
<bluestorm>
well static type systems are always limited somehow, so it's good to be able to escape them from time to time
<Alpounet>
for the moment, I'm happily enjoying 3 languages : C++, OCaml and Haskell.
<thelema>
the first language I found that had a decent static type system was Ada, but that was always so icky.
<thelema>
incredibly verbose
<Alpounet>
bluestorm, some say that people escaping static type systems never come back...
<orbitz>
I've been rewritign a lot of my python script sin Ocaml
<Alpounet>
(true story ? lie ?)
<orbitz>
and i'm going to try a slightly more intersting project in Haskell soon
<Alpounet>
what ?
<orbitz>
Alpounet: not flame bait, but how do ocaml and haskell stack up for you? I often go back and forth between them (not that i am too adept at either yet)
<bluestorm>
orbitz: i found Haskell to be a great read-only language
jimmyb2187 has quit [Read error: 110 (Connection timed out)]
<bluestorm>
learning Haskell is lots of fun, reading Haskell papers is great, writing Haskell is not so interesting actually
<Alpounet>
"read-only language" huh never heard that before.
<orbitz>
Alpounet: my project is to nail our web service with concurrent requests. this will do further requests based on teh response, like how an actual user would use it
<Alpounet>
ok
<orbitz>
Alpounet: shoudl be a good chance ot learn concurrency in haskell
<bluestorm>
I very much like Haskell, but it also have considerable drawbacks and I think OCaml is a better choice for programming medium-to-large size systems
<Alpounet>
yeah
<Alpounet>
forkIO $ do { {- interesting stuffs -} }
<Alpounet>
orbitz, I do the same.
<Alpounet>
I like many things from both of them.
<orbitz>
bluestorm: i've been fairly impressed with haskells concurrency form what i'ev read so far
<bluestorm>
well
<Alpounet>
OCaml's polymorphic variants, module/functor system. Haskell's typeclasses. Etc.
<bluestorm>
it's nice, but right now I'm not so interested in concurrency
<orbitz>
i find the bigest sticking point i've had with haskell is going from what i write to what a haskell programmer writes. there is a missing link there for me
<bluestorm>
there also is JOCaml wich is interesting, and there is that "Haskell Prelude for OCaml" wich provides painless Unix.fork-based concurrency
<orbitz>
bluestorm: Haskell just appears to have a great communication layer too. it's greenthreads but you can also spread them out over N Os threads
<bluestorm>
(I don't pretend it will be as light and integrated to the compiler as GHC concurrency, but I have found it suits my modest needs quite well)
<orbitz>
and communication is easy
<orbitz>
i'm just very impressed righ tnow. i might not be after ia ctually use it though hah
<bluestorm>
If you ever want to have the same things OCaml-side, you should check Zheng Li's work, coThreads and his STM library
<orbitz>
rad
<orbitz>
bluestorm: any work being done on making ocamls compiler more aggressive when it comes to ptimizations?
<bluestorm>
none
<bluestorm>
hm
<bluestorm>
actually there is HLVM, if it's still alive
<bluestorm>
(and it could use a name change)
<Alpounet>
haha
<Alpounet>
it's not dead
<Alpounet>
Harrop has less time, that's all.
<orbitz>
Hah, is it optimized for hash tables?
<Alpounet>
but there was a possible compiler modification to change the backend to a HLVM-based one, but it's been dropped :-"
<bluestorm>
orbitz: how should the compiler be optimized for hash tables ? that does not makes sense to me : is that not a library-only problem ?
<bluestorm>
Alpounet: you mean HLVM the real LLV HLVM project ?
<orbitz>
bluestorm: i was making a funny
<bluestorm>
+M
<Alpounet>
bluestorm, I thought you were talking about this one, indeed.
<orbitz>
I find typeclassea and large stdlib being two of mani thigns hat keep on pulling me back to Haskell when I play with Ocaml
<Alpounet>
orbitz, you can achieve "overloading" with pa_openin
<orbitz>
Alpounet: and you can do some neat stuff iwth pa_do i believe
<Alpounet>
if the module system was doing a lookup in the module/functors automatically (implicitly), it'd be ... wow.
<bluestorm>
hm
<bluestorm>
the point is that the ability to do that is related to the major by-design type classes drawback : you can only have one instance per type
<Alpounet>
s/module system/type system/
<bluestorm>
it is a severe limitation of type classes
<bluestorm>
that I wouldn't want to see reproduced in the OCaml module system
<Alpounet>
what would mean 2 instances for a single type ?
<bluestorm>
(though a lighter notation for type-class-like uses could be interesting)
<bluestorm>
Alpounet: have you never seen two instances of the same algebraic structure over the same set ?
<Alpounet>
with different operations
<Alpounet>
yeah ok I see
<Alpounet>
thanks.
<bluestorm>
there is a workaround for that, wich is to declare a type alias ( something like "data Polynomials_with_composition_as_multiplicative_operator = Polynomials" )
<bluestorm>
but it doesn't always work
<bluestorm>
there is also the problem that type classes live in a global name space : so much for composability...
<orbitz>
still, in my limited experience, even with those drawbacks it to make life easier in haskell for some things
jimmyb2187 has joined #ocaml
<bluestorm>
that's right
<orbitz>
bluestorm: are there any plans to provide a better solution in Ocaml to typeclasses?
<orbitz>
or are the current solutiosn considered satisfactory
<thelema>
orbitz: [open ... in] does a quite good job. It's too bad it's camlp4
<thelema>
pa_do, IIRC
<bluestorm>
open .. in is pa_openin, much simpler than pa_do
<thelema>
heh, googling pa_do opens pennsylvania's tourism site
<thelema>
yes, delimited overloading is ocaml's best alternative to typeclasses
Snark has quit ["Ex-Chat"]
<bluestorm>
actually, in most cases "open .. in" is enough
<thelema>
true
<thelema>
but Module.(expression) is pretty nice syntax
<Camarade_Tux>
in camlp4, what are the reasons to use a .cma file rather than a .cmo one?
<Camarade_Tux>
like pa_mikmatch_pcre.cm(a|o)
sramsay has joined #ocaml
<Alpounet>
orbitz, you're an experienced C++ programmer too, IIRC, right ? I'm sure I've seen you speaking many times on ##C++.
<orbitz>
Alpounet: yep
<Alpounet>
what do you think of C++ templates VS OCaml/Haskell genericity ?
<orbitz>
Alpounet: I'm also an Erlang fan (although the type system is rather annoying now that I've discovered nonsuck)
<Alpounet>
heh, ok.
<orbitz>
Alpounet: I think C++ templates are too complicated relative to Ocaml/haskell
<orbitz>
and all of the examples of "oh look at how powerful C++ templates are" tend to be so confusing even very experienced programmers don't know what they do
<Alpounet>
structural polymorphism is good, though :-)
<Alpounet>
(there is too, in OCaml)
sramsay has quit [Remote closed the connection]
<orbitz>
Ocaml/haskell generate code a bit better too right?
<bluestorm>
hm
<orbitz>
templates are basically code generators, so for every template<T> you get new object code. I'm under the impression ocaml/haskell are smarter about that
<bluestorm>
I wouldn't bet on that, given the amount of time and money spent on making good C++ compilers for industrial users
<thelema>
gcc does so many optimizations, the output is usually unrecognizable
<mfp>
Camarade_Tux: organization; one module vs. several ones, for larger extensions
<Camarade_Tux>
mfp: can you think of anything else? like handling of external C libaries or...
<Camarade_Tux>
because if there is no differnce, let's use .cmo files everywhere and be happy (for camlp4 on windows)
<mfp>
huh, using externals in syntax extensions sounds pretty bad
<Camarade_Tux>
yeah, definitely
<mfp>
Camarade_Tux: .cma carry -L options and such for link time, but I don't think any of those are used when you load them with dynlink (don't see HOW they could)
<Camarade_Tux>
it's in mikmatch_pcre, I don't know where the exact limit is (and my eyes are starting to seriously cross)
<mfp>
so you could just pack several .cmo into a single module, achieving more or less the same effect as the .cma
<mfp>
hmm I assume all the modules are initialized when you dynlink a .cma?
<mfp>
(so e.g. registration funcs are executed)
<Camarade_Tux>
afaik, yes
<Camarade_Tux>
and I think it's how you should do it: when dynlinking, have some global initializer register some functions in the "parent" application
<Camarade_Tux>
(how precise :) )
<mfp>
that differs from the usual behavior with .cma (where only explicitly referenced modules are linked & initialized)
<mfp>
but this means .cma and .cmo should be about equivalent as far as camlp4o is concerned
<Camarade_Tux>
I've successfully compiled my program using camlp4 .cmo files but ocamlfind and mikmatch_pcre's apparently want to use cma files instead
<Camarade_Tux>
(and I'll be trying to get everything merged upstream to make ocaml on windows much easier, that's why I keep on trying with ocamlbuild+findlib)
ulfdoz has quit [Read error: 110 (Connection timed out)]
<hcarty>
Regarding pa_do vs pa_openin, pa_do has the benefit that it does not incur any runtime overhead, and in some cases brings about improvements in runtime.
<hcarty>
Whereas pa_openin does incur a runtime penalty, though it can range from negligible to quite large.
<bluestorm>
hcarty: I however feel that pa_openin, as it is much simpler, tends to be more reliable
<bluestorm>
(because the actual scope resolution is fully handled by semantic processes, instead of syntaxic in pa_do)
<bluestorm>
pa-do is a good framework but I would be a bit reluctant to use it for such simple things
<hcarty>
"Simple things" - such as?
<bluestorm>
such as exactly what open...in does
<hcarty>
Ah, ok. I think their scope is different though. And pa_do can, overall, make things a little clearer.
* thelema
broke let rec
<bluestorm>
(you mean because of the closed scope with an ending parenthesis ?)
<thelema>
This kind of expression is not allowed as right-hand side of `let rec'
<bluestorm>
eta-expansion !
<bluestorm>
my bets are on "and foo = bar"
<thelema>
I don't see how I can eta-expand anything, but I'll look
<bluestorm>
hm
<hcarty>
bluestorm: Float.(1 + 2) is, I think, easier to read and comprehend (as a person reading code) than open Float in \n 1 + 2
<thelema>
does pa_do auto-upcast ints to floats?
<bluestorm>
hcarty: agreed, and moreover pa_do has specific features regarding numeric operators
<bluestorm>
(wich could partly be emulated through plain infix operators, wich is simple but not quite enough)
<hcarty>
bluestorm: I definitely think both have their uses/places.
<bluestorm>
agreed
<hcarty>
thelema: If the module/plugin says to. The included Float overloading does.
<thelema>
hcarty: wow, I'm impressed
<hcarty>
thelema: It's quite a nice piece of work. I use it often, and the only trouble I've had is that #use'ing a .ml file which uses pa_do from the toplevel gives some errors.
<hcarty>
mikmatch has similar problems - I'm not familiar enough with the internals to know exactly what is going on.
<hcarty>
It's something I need to report to the authors, though they may know already.
<thelema>
I have two functions that depend on a data structure, whose initialization depends on having references to those functions. This causes [let rec] problems.
<hcarty>
pa_do is also one of the (VERY) few Jane St. OSP projects still being maintained.
<bluestorm>
I think user feedback is crucial in getting the motivation to maintain the project
<bluestorm>
and you probably have played a key role in that
<thelema>
hcarty: it was last updated last november, no?
<hcarty>
thelema: pa-do's last release was in July
<hcarty>
There may have been updates in the bzr repo since then though.
<thelema>
ok.
<thelema>
great.
<hcarty>
bluestorm: Yes, user feedback can be a powerful motivator. I hope it has been helpful.
<Camarade_Tux>
I remember someone from ffmpeg saying google summer projects usually didn't result in something usable and that their main benefit was to get _a_ _few_ new contributors
<hcarty>
And the pa_do author provides .godiva files for each release, which is nice as a GODI user.
<bluestorm>
hum
<bluestorm>
sometimes I feel like I should try to make the godi tools more usable
<Camarade_Tux>
imho, godi's main problem is that it's slow to react/move to new library versions
<bluestorm>
hm
<bluestorm>
I'm not sure : is that just a problem of lack of godi-side maintainers ?
<bluestorm>
+not
<Camarade_Tux>
actually there's maybe too many godi package maintainers which means some maintainer do one package which doesn't make them update it very often
<Camarade_Tux>
*do only one package
<bluestorm>
I think upstream developpers should take care of notifying godi maintainers for update
<Camarade_Tux>
btw, for the tools, fl*x made something to search in godi and I noticed godi_console is a bytecode which makes it much slower (a native one is easily compiled)
<bluestorm>
I often use godi_perform actually
<bluestorm>
when you're reasonably confident what the name of a package will be, godi_perform -build godi-foo is nice
<bluestorm>
Camarade_Tux: has flux tried to push his code upstream ?
<Camarade_Tux>
I've used godi_perform too, it's much faster but I don't always use it; especially when I don't know the package name ;)
<Camarade_Tux>
bluestorm: I don't think but I'm not 100% sure
<bluestorm>
we should try, I think Gerd would probably accept patches
<Camarade_Tux>
yeah, he's very welcome to patches and contributions
<bluestorm>
I should really try to work a bit on that
<Camarade_Tux>
I think an actual community around godi would be nice, with feedback and contribs
<bluestorm>
I think if everyone tried to improve the general infrastructure once in a while, like what you're doing on windows, that would be really nice
<bluestorm>
maybe we should try to set up fancy not-so-social events such as remote sprints or something like that :-'
<bluestorm>
"ocamlbuild improvement week !"
<Camarade_Tux>
for instance I have a problem with ocaml-sqlite: I need to link it with -ldl on slackware (and Asma* too) but I've still not reported it, mainly because I'm not sure where to do that, to who... it's a bit weird
<Camarade_Tux>
hehe :P
<Camarade_Tux>
(for ocaml-sqlite, it's also because I don't know why slackware needs that)
<hcarty>
bluestorm: I think that's an excellent idea
<hcarty>
Try to get some basic infrastructure to make it easy to, during the sprint, quickly share and push out changes for people to test.
<Camarade_Tux>
I'd like to see something people could ask for specific improvements no matter the library, and people could see the progress in different topics or see what would have to be tested
<Camarade_Tux>
for example, a place to try cross-compilation
<hcarty>
Camarade_Tux: user-suggested sprint!
<Camarade_Tux>
sprint or marathon ;)
<hcarty>
It would be particularly nice if the INRIA folks (xleroy, etc.) would agree to accept improvements from these events if they involve OCaml itself.
<hcarty>
But, if not, they could be pushed in to Community OCaml or a similar project.
<hcarty>
That's getting a bit ahead of this though.
<thelema>
if it can be done over IRC, schedule it and I'll attend
<bluestorm>
hcarty: I think userland stuff is a more reasonable target, at least for a beginning
betehess has joined #ocaml
<betehess>
#ocaml-fr
<hcarty>
bluestorm: I agree
<bluestorm>
but, yeah, if you're interested, we would have to choose a reasonable time period and can get started soon
<hcarty>
Any thoughts on a good first target?
<bluestorm>
hum
<bluestorm>
I was thinking godi & ocamlfind packaging, but perhaps upstream developpers wouldn't be too happy to be suggested to change their install system ?
<bluestorm>
hcarty: any other suggestions ?
<Camarade_Tux>
I thought about that before and I've alwaus thought it could be seen as an aggressive move/takeover but it's almost required and I know lots of people would be really relieved if you gave them a portable build system that works everywhere including on windows and for cross-compilation
<bluestorm>
I think the focus should be on the not-so-sexy tasks that we never imagine doing when coding our own pet projects
<Camarade_Tux>
it's definitely a weak point for many libs no matter the language and the project (I saw vlc's project leader complain about one configure system today, maybe even vlc's)
_andre has quit ["leaving"]
<bluestorm>
the problem is : I do not have much experience of configure scripts, and absolutely none of GODI packaging
<bluestorm>
but I guess I could learn that
<bluestorm>
and pure-ocaml packages probably don't raise that much configuration issues
<hcarty>
GODI packages are relatively straightforward IF they can be done with godiva.
<hcarty>
Packaging manually for GODI seems like a horrible task :-)
<Camarade_Tux>
yeah, as long as you don't try to touch the system libs (linking with C), you're completely safe
<hcarty>
bluestorm: I think those two ideas are good ones to start out with.
<bluestorm>
when do you think would be an appropriate time period ?
<bluestorm>
(I think a short period like two days would be good, and it need a bit of advertisment before)
<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...).
<bluestorm>
oh, asking for packaging suggestions would be a good idea
<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.
Yoric[DT] has joined #ocaml
<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.
<bluestorm>
Yoric[DT]: would you have some time for a little "ocaml build infrastructure love sprint" next week ?
<Camarade_Tux>
hcarty: ledit too
<Yoric[DT]>
I can try
f_[x] has quit [Read error: 110 (Connection timed out)]
<bluestorm>
well I'd be glad to participate to something like that
<hcarty>
I would too. What is a good time of day?
<bluestorm>
we should try to put links to the related documentation in one place, give a few advices, choose a date, and prepare an annoucment on the list
<bluestorm>
hm
<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>
bluestorm: I think the whole day is good, but it may be good to have "core" hours, or perhaps a few checkpoints.
<bluestorm>
ok
<hcarty>
Times when interested parties can drop in to see what has been completed and what needs to be done.
<bluestorm>
people better than me at timezone calculations should try to decide something :-'
<hcarty>
That may not be needed though
<Camarade_Tux>
that means something around the end of the day in France I think
<hcarty>
bluestorm: :-)
<hcarty>
It could start in the French AM and finish in the US PM (with... 1? 2? people around?)
<Yoric[DT]>
....
<Yoric[DT]>
Ok, me wonders exactly what he has signed for.
<Yoric[DT]>
What exactly do you mean by "ocaml build infrastructure love sprint"?
<bluestorm>
Yoric[DT]: it's taking the shape of an ocamlfind & godi packaging day
<Yoric[DT]>
So, choose arbitrary tarballs and make a ocamlfind and a godi package for each?
<mol>
maybe make a TODO list before?
<bluestorm>
yes, perhaps not so arbitrary
<Yoric[DT]>
Sounds like a good idea.
<Yoric[DT]>
I'm not sure how much time I'll be able to spend on it.
<Yoric[DT]>
But it sounds like a good idea.
<mol>
is there some wiki for people to post and discuss which packages?
<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>
mol: That's a good question. I suppose something could be put on cocan.
<hcarty>
Or a project could be setup on the forge. Something that would be recycled between sprints.
<bluestorm>
maybe that's a bit heavy for a start ?
<hcarty>
bluestorm: Probably
<bluestorm>
i'd rather go for a free-form wiki that we would sort of for reuse if useful a posteriori
<Camarade_Tux>
I've known how to test a godi package once (was batteries I think), it'll take a good how to too ;)
<bluestorm>
do you think simple ocamlbuild scripts could interest people ?
<bluestorm>
(that's probably the part I know better, but it's maybe a bit too intrusive)
<Camarade_Tux>
it would probably attract several testers for mac os x or other less-widespread archs
<bluestorm>
Camarade_Tux: ocamlbuild ?
<Yoric[DT]>
Gasp.
<Yoric[DT]>
I've finally found how exactly how long my talk is supposed to last.
<Yoric[DT]>
3 hours
* Yoric[DT]
returns to prepare some slides.
<bluestorm>
:D
<julm>
\o/
<Yoric[DT]>
It's tomorrow 9am.
<bluestorm>
3 hours is much better than 20 minutes
<bluestorm>
if that can be of any help :-'
<Camarade_Tux>
it's hard to say, I don't know enough ocamlbuild but every week someone has a library that doesn't compile on some OS
<Camarade_Tux>
but I'm getting too tired to say express myself properly :)
<bluestorm>
:p
<Camarade_Tux>
Yoric[DT]: if you bring coffee, croissants and sandwiches, it should be ok :P
<Yoric[DT]>
Ok, it's official, I have *no* idea how I'm going to get out of this.
* Yoric[DT]
grumbles at Brian O'Sullivan for neither saying this nor answering his e-mails.
* Yoric[DT]
also grumbles at the other organizers of ICFP for not being able to answer his questions.
<Yoric[DT]>
In addition, as far as I know, noone will have Batteries or even OCaml installed on their laptop.
<Yoric[DT]>
I guess we can take some time to install GODI :)
<bluestorm>
hum
<Camarade_Tux>
if your talk last three hours it should be ok :P
<bluestorm>
is that a talk or a common coding question ?
<bluestorm>
s/question/session/
<bluestorm>
"workshop" maybe ?
<Yoric[DT]>
It's a DEFUN tutorial.
<bluestorm>
oh, I see
<Yoric[DT]>
I *thought* it was a 45 minutes lecture.
<Camarade_Tux>
ouch :o
<Yoric[DT]>
Since there was no answer, I remained in my blissful ignorance until I checked last year's program.
* Camarade_Tux
going to bed, good night :)
<bluestorm>
side not : will you attend the "bondi" tutorial ? I checked the DEFUN schedule a few days ago and that got me curious
<Camarade_Tux>
and good luck Yoric[DT] :)
<Yoric[DT]>
bluestorm: I don't know yet.
<bluestorm>
well
<bluestorm>
the talks all look interesting (yours included), so that certainly will make for good audience reports anyway
<Yoric[DT]>
(and yes, schedules are given in small characters, just under the title -- I just thought that this was the schedule of the session, not that of the talk)
ulfdoz has joined #ocaml
<mol>
well, break a leg as they say. good evening all :D
mol has quit ["Leaving"]
AxleLonghorn has joined #ocaml
ched__ has joined #ocaml
<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: 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>
ocamlbuild + autoconf and ocamlbuild + cmake would each be handy in general
<bluestorm>
I probably already have a cocan account but perhaps a wiki with no registration would be simpler for a first try ?
<bluestorm>
i've recently seen http://couch.it/ used as a simple wiki / common pastebin and it works decently, while being very primitive
<hcarty>
My thoughts as well. cocan would be a good place to put notes/results after the fact.
<bluestorm>
what's the autoconf part for ? does it also handle installation scripts ?
Ched has quit [Read error: 110 (Connection timed out)]
<bluestorm>
oh
<gildor>
autoconf is no yet started
<gildor>
I use the internal configure system
<gildor>
basically, the autoconf part in ocaml-autobuild will translate requirement
<gildor>
into autoconf macro
<gildor>
autoconf should the generate setup.data which is a simple text file
<gildor>
setup.data is then used to run rest of the build/install
<gildor>
but it needs a lot of work before being fully useable
<bluestorm>
that looks nice
<bluestorm>
I think however that for a first sprint, we should focus on install & packaging rather than building
<gildor>
it is also lacking support for C library (though I have 1 library that use it and compile some object)
<bluestorm>
because I suppose upstream developpers would reasonably easily accept a drop-in installation script & godi package (user sides), while they may be a bit less happy to change their own development tools
<bluestorm>
gildor: isn't there another ocamlbuild-related project for C linking, ocamlbuild-ctools or something ?
<gildor>
gildor: indeed, but handling C objects here is just a matter of defining objetcs that will be generated and installed
<gildor>
(i don't provide a build system in fact, this already ocamlbuild concern)
<bluestorm>
I sometimes think ocamlbuild could use some external contributions
<hcarty>
bluestorm: what = subject of the sprint, when = date (To Be Determined), where = where the communication will take place
<hcarty>
The format is in no way fixed. I simply wanted to get something up and running.
<bluestorm>
of course
<bluestorm>
I was just asking why those infos were on the "ocamlfind and Godi package" subpage instead of Home
<hcarty>
Ah - if we have more events, then the main site can be reused.
<bluestorm>
oh
<bluestorm>
ok
<hcarty>
And the ocamlfind/GODI portion can stay intact for future reference.
<hcarty>
I "claimed" the ocamlsprint site but left it open for public editing. I can pass the claim on to someone else if they want it.
<hcarty>
That is very nice that it includes syntax highlighting support in the wiki pages.
ulfdoz has quit [Read error: 145 (Connection timed out)]
AxleLonghorn has left #ocaml []
<bluestorm>
I don't think edition right management will be an issue
<hcarty>
Likely not
<hcarty>
We would be lucky to have that level of interest :-)
<bluestorm>
hcarty: I added some documentation links
<bluestorm>
I think it would be very useful to provide examples (that's what make the "META files .." link valuable imho)
smimou has quit ["bli"]
<bluestorm>
if someone has some real-life yet simple examples of godiva packaging for example, he should definitely put them on the wiki (possibly in a separate subpage)
onigiri_ has joined #ocaml
betehess has quit ["Ex-Chat"]
<hcarty>
bluestorm: Thanks, and good ideas
<bluestorm>
hcarty: I wont be there (or at least not until late) tomorrow, but feel free to discuss (and make changes) with the others
ski_ has quit ["Lost terminal"]
<bluestorm>
I think something around the middle of next week would be a reasonable aim
<bluestorm>
(I certainly won't be there Thursday afternoon, but I can also understand it's difficult to satisfy everybody's needs)
<hcarty>
bluestorm: Sounds good.
<hcarty>
This Thursday, or next week's Thursday?
<hcarty>
We can shoot for a week from today.
<bluestorm>
(next week's Thursday)
onigiri has quit [Read error: 110 (Connection timed out)]
onigiri_ is now known as onigiri
bluestorm has quit [Remote closed the connection]
thrasibule has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
Is there a master of command-line GODI around here?
<Yoric[DT]>
i.e. how the heck can I try a .tgz without going to the trouble of uploading and redownloading it?
<hcarty>
Yoric[DT]: Did you make a change to Batteries' Gzip module? I got an email about a bug update, but saw no git activity.
<Yoric[DT]>
Actually, it seems that I had forgotten to pull.
<hcarty>
Yoric[DT]: If you put the .tgz file in the build tree I think it should find it.
<Yoric[DT]>
Someone else had made the change already.
<hcarty>
Yes, that's why I was asking :-)
<Yoric[DT]>
:)
<Yoric[DT]>
So I rolled back my changes.
<hcarty>
A user was kind enough to track it down
<Yoric[DT]>
I've just uploaded a preversion of Beta 2.
<Yoric[DT]>
I'm going to try and use it tomorrow for my demo.
<hcarty>
Yoric[DT]: Excellent!
<hcarty>
I'm off - have fun with the demo tomorrow.
<Yoric[DT]>
Not all the expected changes/bugfixes made it, but, well, it's a start.
<Yoric[DT]>
fun...
<Yoric[DT]>
Yeah.
<Yoric[DT]>
Well, goodnight.
<hcarty>
Goodnight
<Alpounet>
Good night Yoric[DT].
<Yoric[DT]>
'night
thrasibule has quit [Read error: 60 (Operation timed out)]
Jedai has quit [Read error: 110 (Connection timed out)]
Jedai has joined #ocaml
tmaeda is now known as tmaedaZ
<Yoric[DT]>
Looking for a volunteer using GODI to test the installation of Batteries Beta 2.