<Yoric[DT]>
catch_* are the reference implementations
<Yoric[DT]>
catch.ml and catch.mli are the one I'm trying to optimize
<Yoric[DT]>
torturetest.ml is the test
thermoplyae has quit ["daddy's in space"]
love-pingoo has quit ["Connection reset by pear"]
<Yoric[DT]>
Anyway, I'm gonna call this a night.
<Yoric[DT]>
Cheers
Yoric[DT] has quit ["Ex-Chat"]
jonathanv has joined #ocaml
AxleLonghorn has left #ocaml []
Snrrrub__ has joined #ocaml
Tetsuo has quit ["Leaving"]
thermoplyae has joined #ocaml
travisbrady has quit []
jonafan has quit [Read error: 110 (Connection timed out)]
jonafan has joined #ocaml
jonathanv has quit [Read error: 110 (Connection timed out)]
julm has quit [Read error: 104 (Connection reset by peer)]
Snrrrub has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
coucou747 has quit ["bye ca veut dire tchao en anglais"]
netx has quit [brown.freenode.net irc.freenode.net]
ertai has quit [brown.freenode.net irc.freenode.net]
bla has quit [brown.freenode.net irc.freenode.net]
lnostdal has quit [brown.freenode.net irc.freenode.net]
netx has joined #ocaml
lnostdal has joined #ocaml
bla has joined #ocaml
ertai has joined #ocaml
chacun has quit []
<morner>
okay, how's this for a newb question: what's the syntax for defining the 'main' function in ocaml? damned if i can find anything apart from stuff talking about c FFI
<thermoplyae>
morner: there isn't one. running a compiled ocaml file is more or less the same as pushing the file straight through the interpreter
<thermoplyae>
if you feel the need to wrap it in /something/, try let _ = ...
<morner>
ah
<morner>
ah, that works
<morner>
kick ass ^_^
<julm>
well, you'd better take the habit to use let () = instead of let _ = because the later does not issue a warning for partial applications
ita has joined #ocaml
<morner>
just /win 3
<morner>
whoops
LordMetroid has quit ["Leaving"]
bzzbzz has joined #ocaml
ita has quit [Remote closed the connection]
goalieca has joined #ocaml
ttamttam has joined #ocaml
det has quit [brown.freenode.net irc.freenode.net]
katz has quit [brown.freenode.net irc.freenode.net]
Demitar has quit [brown.freenode.net irc.freenode.net]
romanoffi has quit [brown.freenode.net irc.freenode.net]
palomer has quit [brown.freenode.net irc.freenode.net]
fremo has quit [brown.freenode.net irc.freenode.net]
Mr_Awesome has quit [brown.freenode.net irc.freenode.net]
det has joined #ocaml
palomer has joined #ocaml
Mr_Awesome has joined #ocaml
Demitar has joined #ocaml
AxleLonghorn has joined #ocaml
fremo has joined #ocaml
evn has joined #ocaml
thermoplyae has quit ["daddy's in space"]
evn_ has joined #ocaml
Snrrrub__ has left #ocaml []
Snrrrub has joined #ocaml
|Catch22| has quit []
evn has quit [Read error: 110 (Connection timed out)]
evn_ has quit []
palomer has quit ["Leaving"]
mwc_ has joined #ocaml
mrsolo has left #ocaml []
mrsolo has joined #ocaml
mwc has quit [Read error: 110 (Connection timed out)]
Snrrrub has quit [Read error: 110 (Connection timed out)]
<rwmjones>
it's funny actually, what you _don't_ see in the above demonstration is that 'java' (the JVM) takes a good second to start up
<letrec>
I'm using ocamlgraph (http://ocamlgraph.lri.fr/doc/Sig.html). The graph types for vertex, edge,... are abstracted in modules. Now, I've got a demo program that creates sample graphs. But I don't see anything in that program that would allow the type inference for the graphs. How the hell can ocaml work if actual type is unknown?? Is there a notion of 'default' type?
<rwmjones>
letrec, you mean 'type t'
<rwmjones>
there are two sorts of abstracted type:
<rwmjones>
(1) 'type t' in the signature, and 'type t = <some defn>' in the implementation
<rwmjones>
(2) 'type t' in both the signature and implementation
<rwmjones>
with (1) the OCaml compiler knows the real type (but won't reveal it outside the module) and unifies based on the real type
jlouis has quit [Read error: 110 (Connection timed out)]
<rwmjones>
in case (2) it just unifies the 't's with each other, but not with anything else
<rwmjones>
case (2) is commonly used when the real type is hidden inside eg. a C library
<rwmjones>
eg. it's a malloc'd C block or something
<rwmjones>
actually maybe I'm wrong about case (1), but anyway ...
<letrec>
rwmjones: Thanks. Will do. In the ocamlgraph doc it is written "These implementations are written as functors: you give the types of vertices labels, edge labels, etc. and you get the data structure as a result." So I'm confused!
<rwmjones>
ah functors ... fun
<letrec>
I'll have a look to the Ocaml doc.
<rwmjones>
best bet is to look at some example code using ocamlgraph
<letrec>
Ok, but I don't get how the compiler can figure out what actual type to use. I'll study hard over the week-end :) Thanks.
middayc_ has joined #ocaml
linktim_ has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
jlouis_ has quit [Read error: 110 (Connection timed out)]
ben_ has quit [Read error: 110 (Connection timed out)]
middayc has quit [Read error: 110 (Connection timed out)]
middayc_ has left #ocaml []
robyonrails has joined #ocaml
ita has joined #ocaml
Snrrrub has joined #ocaml
Snrrrub__ has joined #ocaml
rogo has joined #ocaml
Snrrrub has quit [Read error: 110 (Connection timed out)]
olleolleolle has left #ocaml []
Yoric[DT] has joined #ocaml
<bluestorm>
hm
<bluestorm>
i've just ran in a suprising typing error
<bluestorm>
looks a bit like the monomorphism restriction, but it's only related to the "and"
<bluestorm>
is that explained in the manual somewhere ?
<bluestorm>
(it's not that annoying, as the 'bug' can be spotted easily, and is quite natural, but still i'm surprised to have never heard of that before)
<Yoric[DT]>
yeah, that's weird
linktim__ has joined #ocaml
<thelema>
bluestorm: what's the difference between your two pass functions?
<thelema>
oh, the rec .. and
<julm>
Yoric[DT]: welcome back, about catch.ml, why does content is a record? why not directly using Obt.t?
<julm>
Obj.t*
<julm>
well this is container, not content
<thelema>
hmm... well, I guess it can't generalize 'a because of the specific use in its definition, and two different specific uses definitely don't get allowed.
<bluestorm>
what i think strange is
<bluestorm>
hmm, nevermind :p
<letrec>
bluestorm: what could be the use of this function pass?? (Beginner question)
<bluestorm>
let incr (x : 'a) = x + 1 does work too
<bluestorm>
letrec: it's the identity function
<bluestorm>
sometimes useful
<bluestorm>
but in that case, it's a reduction of a problem i had with a bigger code
Snrrrub__ is now known as Snrrrub
<bluestorm>
thelema: it's still strange that the "and" reduce generalization
<bluestorm>
but hm
<letrec>
Why not use let pass x = x ??
<bluestorm>
i guess i'll have to seriously learn the theorical sides of ML typing one day
<thelema>
since pass isn't defined completely yet, any uses of it constrain its definition.
<bluestorm>
letrec: i wanted to force the use of my 'a t type
<bluestorm>
but actually it works (ie. fails) even with 'a
<bluestorm>
let rec pass x = x and i = pass 2 and x = pass 3.14
<thelema>
bluestorm: you can't force a more general type than the typechecker infers, only a more specific.
<bluestorm>
thelema: what's funny is that forcing a more general type doesn't even raise a warning
<bluestorm>
when debugging my code, i tend to add typing annotations thinking "if no error is raised here, then i'm sure the inferred type is this one"
<bluestorm>
works most of the time
<bluestorm>
but that time i got struck :p
<thelema>
I think a warning would be appropriate. Want to submit that request to inria?
<bluestorm>
julm: you must be right : the mutual recursion creates a problem of polymorphism recursion here, even if the functions actually aren't polymorphic
<bluestorm>
thelema: hm
<bluestorm>
have to said i'm a bit afraid :-'
<bluestorm>
thelema: is the bug tracker the place to go ?
<thelema>
don't be afraid of the bug tracker. Most likely all that'll happen is the bug'll stay ignored.
<dwmw2_BOS>
(which is just the one I had working for 3.09.3 dusted off and made to apply).
<rwmjones>
probably buy xleroy a beer is the way forward here ... I offered to get RH to buy him a PS3 but he wasn't too interested
<dwmw2_BOS>
I had it all working once... built lots of packages and never finished debugging a SEGV I saw in freetennis
<dwmw2_BOS>
this (linking against -lm) ought to be the _easy_ part :)
<rwmjones>
dwmw2_BOS, do I still have that ppc64 account on infradead? if you can get it to a single freetennis segfault (or even better, some command-line program) I can have a look
<rwmjones>
but building stack frames correctly on PPC is somewhat out of my experience
<dwmw2_BOS>
rwmjones: I did all that (stack frame)
<dwmw2_BOS>
I couldn't get a command-line program to fail
<dwmw2_BOS>
they all worked perfectly, even when I fucked around with lots and lots of arguments and mixture of float/int/etc
<dwmw2_BOS>
all against 3.09.3 -- so now I'm trying to update to 3.10.1
<dwmw2_BOS>
and it fails to build because it can't link against ceil -- I think it's not linking against libm
<rwmjones>
dwmw2_BOS, are you sure that error indicates it's not linking against -lm though?
<dwmw2_BOS>
no
<dwmw2_BOS>
I'm not
<julm>
dwmw2_BOS: I see: command for building...... gcc -shared -o lib.so -Wl,-rpath,/a/path objs, is this "/a/path" normal?
<rwmjones>
where does the @@GLIBC bit come from?
<dwmw2_BOS>
rwmjones: it's versioning on the symbol. toolchain magic
<dwmw2_BOS>
julm: er, not sure
<rwmjones>
it looks like /a/path is normal
<rwmjones>
$ grep '/a/path' `find -type f`
<rwmjones>
./configure:echo " command for building...... $mksharedlib lib.so $mksharedlibrpath/a/path objs"
<rwmjones>
./configure.cflags:echo " command for building...... $mksharedlib lib.so $mksharedlibrpath/a/path objs"
<rwmjones>
./configure.tclver:echo " command for building...... $mksharedlib lib.so $mksharedlibrpath/a/path objs"
<rwmjones>
that's on a built ocaml-3.10.1 i386 directory
<julm>
dwmw2_BOS: ok I have "/a/path" too
<julm>
dwmw2_BOS: do you have several gcc installed?
<rwmjones>
dwmw2_BOS, as an aside, don't you need to pass 'gcc -m64'
<rwmjones>
remember that ocaml really needs a 64 bit userspace
<dwmw2_BOS>
rwmjones: that's just $RPM_OPT_FLAGS. I don't think I did that on purpose
<dwmw2_BOS>
julm: no, only 64-bit. This is built in a pure 64-bit chroot
<dwmw2_BOS>
rwmjones: how can I see the actual linker invocation?
<rwmjones>
dwmw2_BOS, ocamlopt -verbose
<rwmjones>
in *normal* code
<rwmjones>
but that probably is the mini ocamlopt
<rwmjones>
so don't know if it'll work there
<dwmw2_BOS>
I'd settle for strace but can't actually reproduce the build command
<dwmw2_BOS>
Exit code 2 while executing this command:
* dwmw2_BOS
overrides gcc with a shell script which copies the file in question out of the way
julm has quit [Read error: 113 (No route to host)]
<dwmw2_BOS>
and fork-bombs the machine to death
<dwmw2_BOS>
note to self: /usr/bin/gcc. Not "gcc".
<rwmjones>
heh
evn has joined #ocaml
thermoplyae has joined #ocaml
RobertFischer has left #ocaml []
jstanley has joined #ocaml
<jstanley>
Question about OO in OCaml. I've been reading through some source code and attempting to determine relationships between various classes. The .mli file for object 'foo' has something like class foo : unit -> blah, where blah is some other, apparently unrelated class. I can't find any inheritance relationship between foo and blah, but foo does define all of the appropriate methods. Is this a common paradigm in OCaml?
<thelema>
jstanley: foo seems a function that returns a class. I've done this before to implement a simple finite field
<rwmjones>
jstanley, duck typing?
<jstanley>
thelema: with the 'class' keyword though? the class foo has unit as an explicit instantiation parameter.
<jstanley>
rwmjones: i've heard of it, but don't know much about it.
<jstanley>
rwmjones: this is the row polymorphism etc, or is that something else?
<thelema>
jstanley: with an int parameter, but yes, using 'class'
<rwmjones>
let o = object method foo = "method foo on o" end ;;
xavierbot has quit [Remote closed the connection]
<jstanley>
thelema: in this case the class is defined like: class foo () = ... ; I assumed that the calss foo : unit -> blah line in the .mli was expression the constructor signature, but maybe I'm wrong.
xavierbot has joined #ocaml
<rwmjones>
let o = object method foo = "method foo on o" end ;;
<xavierbot>
val o : < foo : string > = <obj>
<dwmw2_BOS>
oh, wank
<rwmjones>
let rhubarb obj = obj#foo ;;
<dwmw2_BOS>
rwmjones: I know what the problem is. We're still using the contents of asmcomp/power/ instead of asmcomp/power64/
<xavierbot>
val rhubarb : < foo : 'a; .. > -> 'a = <fun>
<rwmjones>
so rhubarb is a method which works on any object with a foo method
<rwmjones>
o happens to be an anonymous object
<jstanley>
yup, got it.
<jstanley>
rwmjones: so in my particular case there is no explicit semantic relationship between the two classes, just duck typing to enforce method existence.
<TFK>
is the memprof for OCaml 3.0.7 usable in 3.0.9?
<TFK>
Alternatively, is there another way of tracking down memory leaks?
<dwmw2_BOS>
rwmjones: yeah, that should be better now. Starting the build from scratch...
<thelema>
TFK: apparently there's a version for 3.10 too
<TFK>
That does mean I have to uninstall everything OCaml-related that Synaptic installed and compile everything from source, right?
<evn>
GODI lets you use CVS caml relatively easily
<TFK>
Looks interesting, and it looks like I don't have any other choice. Thanks!
<Snrrrub>
Is it possible for an object to hold a val without initializing it inline but doing it in the 'initializer' instead?
<thelema>
Snrrrub: use a function that returns an object
<thelema>
class i = let precalc = i lsl 3 in object method get_prec = precalc end
<thelema>
(something like that)
<Snrrrub>
thelema, I don't think I described it properly: I'm attempting something like: class foo arg = object(self) val v = ??? initializer v = some_fn_result arg end
<thermoplyae>
i've looked for a way to do that, didn't come up with anything better than making the val an option type
<thelema>
err, class i arg = let precalc = some_fn_result arg in object val v = precalc end
<thermoplyae>
thelema: the only reason you'd want to delay evaluation would be to call methods or reference other variables in the class you're instantiating, which that doesn't get around
<thermoplyae>
rather, that's equivalent (i think) to just class i arg = object val v = some_fn_result arg end, which is where we started
<petchema>
TFK: it should be possible to get ocaml package sources, patch it, and recreate packages
<thelema>
thermoplyae: when do you want some_fn_result evaluated?
<TFK>
petchema, under GODI? I'm looking for the relevant docs right now.
<petchema>
no, Debian
<thermoplyae>
some point after the class is 'instantiated' in a proper sense so that i can make method calls on self
<TFK>
petchema, hmm, any further pointers on that? I'm only familiar with Synaptic.
<petchema>
it's not related to Synaptic, but to deb packages
<TFK>
Of which I know nothing save that Synaptic handles them for me :-(
<thelema>
thermoplyae: that's exactly what the initializer does - what's the problem?
<thermoplyae>
thelema: you have to supply some intermediary value for whatever val you're initializing as part of the class definition
<thermoplyae>
you have to either come up with a junk value or use an option type. understandable, but inconvenient
<thelema>
thermoplyae: obj.magic works for me when I'm sure the initializer will overwrite that value
<thermoplyae>
heh, okay
dwmw2_BOS has quit [Read error: 101 (Network is unreachable)]
<thermoplyae>
i've never played with obj.magic before. sounds dangerous, but i'll give it a spin after class
thermoplyae has quit ["daddy's in space"]
<thelema>
therm: it is dangerous, only use it in great need.
<rwmjones>
excellent ... we expect this one to build though. If it builds I'll start to rebuild some more packages until something breaks.
<dwmw2_BOS>
your guidance on testing it would be appreciated. Last time, as I said, I built a bunch of packages and then freetennis.
<dwmw2_BOS>
if there are simpler test cases that would be good
<rwmjones>
well, it being able to get through builds (ie. run ocamlc.opt & ocamlopt.opt) is a good start
<rwmjones>
and some of the builds will use those
<rwmjones>
some of the packages I've added recently have big %check sections
<dwmw2_BOS>
cool
<dwmw2_BOS>
I remember dealing with a bunch of 'special' cases especially in function calls.
<dwmw2_BOS>
don't remember if I made tests up, found tests, or they were just within the compiler
<dwmw2_BOS>
but I made them all happy, either way :)
<rwmjones>
ocaml-cryptokit depends only on base ocaml and has a moderate %check section
<rwmjones>
does koji run %check sections?
<dwmw2_BOS>
not sure
<dwmw2_BOS>
I can set up a repo on bombadil and a mock configuration to pull from it
<dwmw2_BOS>
or we could just do it in Fedora.
<dwmw2_BOS>
you should still have an account there
<rwmjones>
dwmw2_BOS, I'm going to have to go soon, but if that build works I'll build the other ocaml packages over the weekend and get back to yuo if any probs
<rwmjones>
yuck we failed on ppc (32)
<rwmjones>
strange I don't understand how that patch can affect 32 bit ppc
<TFK>
thelema, you said there's a 3.0.10 patch somewhere - any specifics, it doesn't seem to google?
dwmw2_BOS has quit [Read error: 113 (No route to host)]
<TFK>
Ah, it's 3.10, not 3.0.10, nevermind...
<letrec>
What's the idea behind polymorphic variants? It looks to me that one can always rewrite a program not to use them -- using 'normal' types. Thanks.
<letrec>
let foo = function Alpha -> 'a' | Beta -> 'b';;
<xavierbot>
val foo : t -> char = <fun>
olleolleolle has joined #ocaml
<letrec>
Ok, I'll have a look to the paper. Thanks.
<flux>
bluestorm, regarding your pass-function: at times it's nice to have the current behavior, such as when I have a more complex type but still want to partially define it. ("return a value that's like ('a * 'a option), even though it might turn out to be (int * int option)") but I suppose I wouldn't lose much even if the approach was changed (not likely).. the best would be if both the ways were available.
<bluestorm>
hm
<bluestorm>
i see
<bluestorm>
you take ('a * 'a option) as a shape
<flux>
jstanley, maybe it wasn't clear from the discussion, but in ocaml there are never other than structural relationships between classes
<bluestorm>
wich you wouldn't have to change if the concrete type evolved ?
<flux>
I must admit the place where I've used such annotations has been perhaps inside functions, where I only care about some aspects of the value type..
dwmw2 has joined #ocaml
dwmw2 has quit [Read error: 104 (Connection reset by peer)]
marmottine has quit [Remote closed the connection]
<Yoric[DT]>
Mmmhhh....
<Yoric[DT]>
I have tested with manual inlining and I get a large performance increase.
<Yoric[DT]>
So I can only assume that this inlining doesn't happen in my case.
<Yoric[DT]>
Which is too bad, as the function is essentially fun x y -> y x
<Yoric[DT]>
(plus type info)
<Yoric[DT]>
mmmhhh.... there's a tag ocamlopt -inline
<thelema>
as far as I can tell, the -inline option changes a magic parameter that inlines more or less, but there's no way to insist on a certain function getting inlined
<Yoric[DT]>
Well, it's a one-line function.
|Catch22| has joined #ocaml
thermoplyae has joined #ocaml
* Yoric[DT]
is afk
<TFK>
everything I put into godi's distfiles patches directory is automatically applied upon rebuilt, right?
<dwmw2>
rwmjones: I'm about to get on a plane and head home. Can I leave you with building the world? If something breaks, let me know and I'll poke it when I get home
Amorphous has quit [Connection timed out]
evn has quit [Remote closed the connection]
evn has joined #ocaml
jwest-- has joined #ocaml
jwest-- has left #ocaml []
dwmw2 has quit ["foo"]
thermoplyae has quit ["daddy's in space"]
Amorphous has joined #ocaml
linktim__ has quit [Remote closed the connection]
pattern_ has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
pattern has quit [Read error: 110 (Connection timed out)]
pattern_ is now known as pattern
ygrek has quit [Remote closed the connection]
dwmw2 has joined #ocaml
dwmw2 is now known as dwmw2_BOS
Snrrrub__ is now known as Snrrrub
<TFK>
Sheesh. I compiled everything manually, but heapstats won't work, tells me "Fatal error: exception End_of_file" no matter what I do.
<TFK>
And on the first file I generates, it gives me Fatal error: exception Out_of_memory
<thelema>
TFK: do you have enough memory? memory usage goes up a lot using the memprof patch
<TFK>
I have 1 gig of RAM and a few gigs free on the HDD
<TFK>
(And 2 gigs of swap)
Snrrrub has left #ocaml []
Snrrrub has joined #ocaml
<TFK>
The dump files are less than 40 MBs
<thelema>
and how much memory did your program use before profiling?
<TFK>
100+ MBs
<thelema>
should suffice...
<TFK>
:-(
<TFK>
And why would I get End_of_file?
<thelema>
can't explain that.
<TFK>
Stack traces would come in handy at this point...
<thelema>
OCAMLRUNPARAM=b
<TFK>
Yeah, but I have to recompile heapstats with -g
<pango>
and compile with -g, iirc
<TFK>
And how do I recompile *just* heapstats?
<thelema>
look in the Makefile
bluestorm has quit ["Konversation terminated!"]
olleolleolle has left #ocaml []
<TFK>
While the code's compiling - does anyone have any experience with Valgrind? They say it can work with any programming language.
<Snrrrub>
Can someone tell me if I've got this right: with OCaml's module system, if I have two circularly dependent modules A and B, I have three options: 1) merge the modules 2) make them submodules of a parent module and use 'and' 3) create a module C which depends on A and B and ties them together using functions as arguments instead of having A call into B and vice versa
<thelema>
Snrrrub: Sounds good to me.
<Snrrrub>
Cool, sounds like I'm starting to get the hang of this. :-)
<evn>
what about valgrind
<evn>
i've used valgrind memcheck but not with ocaml
<TFK>
evn, I wonder if it can be used to track down memory leaks.
<evn>
i am not really familiar with the way ocaml tracks heap references but it probably would foil valgrind
<evn>
valgrind is for finding malloc()s that never call free() basically
<evn>
if the ocaml heap still has valid pointers into itself it wont appear lost to valgrind even though it might be lost to ocaml
<thelema>
ocaml's GC should do a more than sufficient job of freeing unreachable memory. The problem of 'memory leaks' in GCed languages seems to mostly come from keeping references to data that you don't really need anymore.
<evn>
yeah that is more what i should have said
<thelema>
OTOH, if you're interfacing with C, those assumptions no longer hold. :)
thelema is now known as thelema|away
<TFK>
I'm using GSL. But I'm also creating lots of small objects at a fast rate...
<TFK>
Also, my usage of GSL is pretty simple, I use it for its random algo only. And my code is sufficiently small to make me doubt the bug is on my side... then again, PEBKAC is common with me :-/