gildor changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | OCaml 3.12.0 http://bit.ly/aNZBUp
cthuluh has joined #ocaml
elehack has joined #ocaml
dnolen has joined #ocaml
elehack has quit [Quit: Farewell, programs.]
sheets has quit [Ping timeout: 246 seconds]
othiym23 has joined #ocaml
philtor has joined #ocaml
lopex has quit []
joewilliams is now known as joewilliams_away
alexyk has quit [Quit: alexyk]
alexyk has joined #ocaml
rgrinberg_ has joined #ocaml
rgee has quit [Ping timeout: 255 seconds]
Modius has joined #ocaml
impy has quit [Ping timeout: 260 seconds]
impy has joined #ocaml
ski has quit [Read error: Operation timed out]
ski has joined #ocaml
dnolen has quit [Quit: dnolen]
bzzbzz has joined #ocaml
alexyk has quit [Quit: alexyk]
joewilliams_away is now known as joewilliams
bzzbzz has quit [Quit: leaving]
dnolen has joined #ocaml
bzzbzz has joined #ocaml
ulfdoz has joined #ocaml
dnolen has quit [Quit: dnolen]
joewilliams is now known as joewilliams_away
othiym23 has quit [Quit: Leaving...]
philtor has quit [Ping timeout: 255 seconds]
ulfdoz has quit [Ping timeout: 240 seconds]
jamii has joined #ocaml
Snark_ has joined #ocaml
Snark_ is now known as Snark
Modius has quit [Read error: Connection reset by peer]
Modius has joined #ocaml
jamii has quit [Ping timeout: 276 seconds]
edwin has joined #ocaml
larhat has joined #ocaml
worstadmin has joined #ocaml
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
ftrvxmtrx has joined #ocaml
ftrvxmtrx has quit [Client Quit]
ikaros has joined #ocaml
edwin has quit [Remote host closed the connection]
avsm^away is now known as avsm
sgnb has quit [Remote host closed the connection]
ftrvxmtrx has joined #ocaml
sgnb has joined #ocaml
Snark has quit [Remote host closed the connection]
alfa_y_omega has quit [Ping timeout: 250 seconds]
alfa_y_omega has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
eikke has joined #ocaml
<eikke> hija
<eikke> is there any tool to profile allocations in ocaml? as in -> profile which types of objects are allocated and GC'ed
<eikke> I have a very basic app which shouldnt do much memory-related things, but when time-profiling it, I get +- 30% of time (runtime of less than a second in total) spent in GC
Cyanure has joined #ocaml
<flux> there are some memory usage analysis tools, but I haven't used them
<flux> fidling with the GC parameters is likely to help you
<flux> the defaults are quite conservative
<flux> increasing the minor heap and/or the overhead for example are good things to try
<eikke> I found ocamlviz, but that seems to give real-time introspection of value types
<eikke> which doesnt work for me since I cant read those values in <1s :D
<flux> if you just want your short-lived program to run as fast as possible, you could just up all the limits to the extreme
<flux> then it should take no time in GC :)
<eikke> that wont help :) the 'app' is a little testsuite for a library/component I'm working on, which will be used in long-running applications
<flux> I don't see why it wouldn't help, if you're checking for correctness of an O'Caml program - it wouldn't affect it
<flux> unless you use weak references or something..
<eikke> I cant rely on changing global GC settings, since the app in which the lib is hosted might need more conservative GC behaviour
<flux> you can adjust GC parameters with the environment variable OCAMLRUNPARAM as well
ftrvxmtrx has quit [Ping timeout: 260 seconds]
<f[x]> _habnabit, if you are using ocamlgsl debian package mind that native version is build without debug
<f[x]> this is probably a bug worth reporting
<f[x]> _habnabit, after rebuilding with debug backtrace points at gsl_error.ml line 54
<f[x]> the question why bytecode and native have different behaviour needs further investigation
f[x] has quit [Read error: Connection reset by peer]
f[x] has joined #ocaml
Amorphous has quit [Ping timeout: 255 seconds]
Amorphous has joined #ocaml
edwin has joined #ocaml
alfa_y_omega has quit [Ping timeout: 246 seconds]
alfa_y_omega has joined #ocaml
meltem has joined #ocaml
alfa_y_omega has quit [Ping timeout: 276 seconds]
alfa_y_omega has joined #ocaml
wagle has quit [Ping timeout: 258 seconds]
thelema_ has quit [Ping timeout: 240 seconds]
wagle has joined #ocaml
thelema has joined #ocaml
alfa_y_omega has quit [Ping timeout: 240 seconds]
lopex has joined #ocaml
alfa_y_omega has joined #ocaml
_andre has joined #ocaml
ftrvxmtrx has joined #ocaml
Anarchos has joined #ocaml
<f[x]> is it ok to raise exceptions or alloc from external "float" functions?
<flux> I would like to say 'yes', because I've only heard about that limitation in relation to "noalloc" functions
<flux> but I don't even know what "float" functions are :-)
<flux> sin etc are "float"?
alfa_y_omega has quit [Ping timeout: 240 seconds]
<f[x]> yep
<f[x]> see pervasives.ml
alfa_y_omega has joined #ocaml
lamawithonel has quit [Remote host closed the connection]
Cyanure has quit [Ping timeout: 240 seconds]
alfa_y_omega has quit [Ping timeout: 246 seconds]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Max SendQ exceeded]
alfa_y_omega has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
alfa_y_omega has quit [Ping timeout: 244 seconds]
worstadmin has quit [Ping timeout: 240 seconds]
lamawithonel has joined #ocaml
alfa_y_omega has joined #ocaml
dnolen has joined #ocaml
_nejimban has joined #ocaml
alfa_y_omega has quit [*.net *.split]
nejimban has quit [*.net *.split]
_nejimban is now known as nejimban
<thelema> f[x]: can you disable the batteries build under 3.10? (qemu-armel-debian,default) Batteries needs 3.11 to compile
<f[x]> thelema, done
alfa_y_omega has joined #ocaml
<thelema> f[x]: thank you. I wonder why it chose now to fail - that code has been there since 2010
alfa_y_omega has quit [Excess Flood]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Ping timeout: 255 seconds]
<f[x]> strange
alfa_y_omega has joined #ocaml
dnolen has quit [Quit: dnolen]
alfa_y_omega has quit [Excess Flood]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Max SendQ exceeded]
alfa_y_omega has joined #ocaml
alfa_y_omega has quit [Ping timeout: 255 seconds]
alfa_y_omega has joined #ocaml
Obfuscate has quit [Ping timeout: 246 seconds]
Obfuscate has joined #ocaml
eikke has quit [Read error: Operation timed out]
lopex has quit []
eikke has joined #ocaml
ztfw has joined #ocaml
iratsu has quit [Ping timeout: 250 seconds]
iratsu has joined #ocaml
larhat has quit [Quit: Leaving.]
Cyanure has joined #ocaml
lopex has joined #ocaml
lopex has quit [Client Quit]
lopex has joined #ocaml
ikaros has joined #ocaml
sepp2k has joined #ocaml
<_habnabit> f[x], I'm building everything with godi on OS X.
<_habnabit> f[x], are you the maintainer for ocamlgsl, or an interested party? (just curious.)
joewilliams_away is now known as joewilliams
<f[x]> _habnabit, more of a passer-by
<f[x]> notice that adding print_endline after try fixes thing
<f[x]> I suspect that it is forbidden to raise exceptions from "float" external functions (that's how it is declared by ocamlgsl)
<_habnabit> does it? let me try.
<_habnabit> 'after the try' meaning in the `try` block?
<f[x]> yup
<f[x]> or maybe it is ocamlopt bug :)
<_habnabit> oh. did you see the paste that I made?
<_habnabit> because I'm still seeing the same issue.
<thelema> f[x]: the no exceptions from "float" externals makes sense - float seems to imply a desire for speed, and changing the ABI for this would likely pull out exception returns
<_habnabit> oh, adding the print_endline /before/ it.
<f[x]> thelema, but why? iiuc raising exception means looking up the stack of exception handlers which is already setup before call to "float"
eikke has quit [Ping timeout: 252 seconds]
<thelema> ah, maybe I misunderstood exceptions
<f[x]> I am not sure either
<_habnabit> ... oh, wacky.
<_habnabit> that does fix it.
<f[x]> I think this qualifies for caml-list
<_habnabit> that is baffling.
alexyk has joined #ocaml
avsm1 has joined #ocaml
avsm has quit [Read error: Connection reset by peer]
<mfp> f[x]: I believe you can't raise an exception from a "float" function; after all, that implies allocation, which would require the call to go through caml_c_call
ulfdoz has joined #ocaml
<f[x]> and "float" doesn't setup registers the way caml_c_call expects?
<mfp> it calls the function directly AFAIK
<f[x]> oops, I mean allocation requires some setup that is not done by "float" - right?
<thelema> float implies noalloc?
<mfp> that's what I meant, yes
<f[x]> if so - then ocamlgsl is awfully broken
<mfp> but I'm not so sure after looking at the assembly for external foo : float -> float = "foo" "float" let f x = foo x
<mfp> sin x is a mere call sin@PLT though
<mfp> oops, got the external syntax wrong
* f[x] can reproduce the issue without gsl
<mfp> this makes more sense > external foo : float -> float = "foobar_1" "foobar_2" "float" let f x = foo x
<mfp> generates movlpd (%rax), %xmm0 call foobar_2@PLT
<mfp> so I'd conclude you cannot allocate in "float" functions (avoiding the allocation (float boxing) is the very point)
<f[x]> why?
<f[x]> allocation requires single register pointing to heap
<f[x]> and it is not eax
<mfp> because it's not going through caml_c_call, as other non-noalloc functions
<mfp> caml_c_call does this amongst other things before calling the C function -> /* Make the exception handler and alloc ptr available to the C code */ STORE_VAR(%r15, caml_young_ptr) STORE_VAR(%r14, caml_exception_pointer)
<f[x]> ah
<mfp> there's none of this if the call is direct, as happens in the above code
<f[x]> now that makes perfect sense
<f[x]> caml_exn_ptr is hoisted in register and so "float" func sees the old value of it
<f[x]> and so exn is raised as if outside try block
<f[x]> mfp, thanks a lot!
<mfp> np
<mfp> hmm now, one could conceive a "float-noalloc" function
<mfp> oops, I meant "float-alloc"
<f[x]> so now ocamlgsl is broken :)
<mfp> that does caml_c_call's thing, but doesn't use boxed floats
<f[x]> interesting
<mfp> not sure if the use case is common enough to justify the change to the compiler, though
* f[x] wonders whether it is possible to preallocate exn block and raise it without allocations
<f[x]> from "float" func
<mfp> hmm maybe it'd be possible to use caml_c_call _inside_ the stub function
<_habnabit> that's incredible.
<_habnabit> see, I just don't know how nobody noticed this until now. I couldn't find any mailing lists posts or anything about this issue.
<thelema> _habnabit: often the register will have the correct value, if there was a regular C call since the last exception handler was registered
<_habnabit> so, is the best workaround to make a regular C call before making this call?
<_habnabit> like, define a no-op function just to call it?
<thelema> or put the necessary setup inside the C function that raises an exception
ulfdoz has quit [Quit: deprecated]
<mfp> if he could, he'd just have to remove the "float" external (and rearrange the function params/retvalue), so I guess the no-op C function that forces a caml_c_call is the easiest workaround
<f[x]> I guess you can't do this at raise side because those registers can be overwritten by gsl C code
<mfp> registers? caml_c_call saves registers in caml_xxxx variables
<thelema> mfp: quite a terrible workaround
* f[x] commented on "or put the necessary setup inside the C function that raises an exception"
<_habnabit> hmm.
<thelema> ok, so the right way is to not have float externals that raise exceptions.
<_habnabit> heh.
* f[x] thinks that preallocating the exn block should work
<f[x]> ok, no, I don't think so
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
<adrien> what would be a quick way to make sure a function isn't inlined?
<thelema> adrien: increase its code size
<thelema> possibly with dead code that the compiler doesn't eliminate
<adrien> how to be sure it doesn't get eliminated? ;-)
<thelema> use a ref - minor runtime penalty for checking that ref, but it'll prevent elimination of code that depends on it.
<thelema> if !false_ref then <lots of code>; assert false else <real code>
<adrien> well, ok, I used a for loop from 1 to 40 and print_endline, and it didn't change anything to my segfault
<thelema> there were some other compiler limitations that prevent inlining, but there's active work to remove them in the compiler.
<adrien> (brb)
sepp2k has quit [Ping timeout: 255 seconds]
jderque has joined #ocaml
sepp2k has joined #ocaml
ikaros has quit [Ping timeout: 255 seconds]
ftrvxmtrx has joined #ocaml
ikaros has joined #ocaml
ulfdoz has joined #ocaml
ikaros has quit [Ping timeout: 260 seconds]
ankit9 has quit [Quit: Leaving]
ankit9 has joined #ocaml
jamii has joined #ocaml
ulfdoz has quit [Quit: deprecated]
ikaros has joined #ocaml
ulfdoz has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
ankit9 has quit [Quit: Leaving]
Anarchos has joined #ocaml
lamawithonel has quit [Remote host closed the connection]
iratsu has quit [Quit: Leaving.]
jamii has quit [Ping timeout: 246 seconds]
lopex has quit [Ping timeout: 240 seconds]
_andre has quit [Quit: leaving]
lopex has joined #ocaml
edwin has quit [Remote host closed the connection]
ulfdoz has quit [Ping timeout: 240 seconds]
avsm1 has quit [Quit: Leaving.]
eye-scuzzy has quit [Ping timeout: 255 seconds]
eye-scuzzy has joined #ocaml
eikke has joined #ocaml
<_habnabit> f[x], oh, I submitted an issue on ocamlgsl's google code project, if you hadn't seen it: http://code.google.com/p/ocamlgsl/issues/detail?id=7
<_habnabit> f[x], if you wanted to add a comment or something.
<thelema> _habnabit: this is an unusually brief bug report
<_habnabit> I was on my way out from work; maybe I should've just waited until this morning.
<thelema> ah, this was from yesterday, before we knew what was the bug
<_habnabit> right.
<thelema> nevermind then - it's pretty reasonable.
<thelema> Any chance of bringing OCaml out of the 80's re: http://groups.google.com/group/seajure/msg/75f38e71298a072a
<thelema> also, function names in backtraces - it's a pain cross-referencing the stdlib by line/character pos
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
lopex has quit [Ping timeout: 260 seconds]
lopex has joined #ocaml
jderque has quit [Quit: leaving]
elehack has joined #ocaml
<thelema> elehack: I think it's about time for another batteries release
eikke has quit [Quit: Lost terminal]
<elehack> thelema: sweet!
* elehack has been largely out-of-touch lately... most energy on Java coding @ school
<thelema> I've also looked at the difference between 1.4 and 2.0, and 2.0 doesn't add much (we've been doing that in the 1.x series), but renames a bit a removes some things that should go away.
jamii has joined #ocaml
<thelema> s/a removes/and removes/
<elehack> has 2.0 see some UTF8 interface cleanup yet?
<elehack> I know we've discussed that a bit in a github ticket
<thelema> yes, 2.0 has the Unicode infrastructure replaced by ulib
<thelema> ulib should probably be in libs/ instead of src...
<thelema> well, I'll just put out 1.4 today
<elehack> kk, didn't realize ulib entirely replaced utf8
<thelema> it's not a perfect replacement - ulib keeps more of the original design, I only had to make minor tweaks to integrate it
<thelema> batRope -> Ulib.Text, BatUTF8 -> Ulib.UTF8, that kind of thing
<thelema> elehack: btw, are you interested in more statistically sound benchmarking than ocaml-benchmark?
<elehack> I haven't used ocaml-benchmark, so I don't know.
<elehack> then again, I've never tried to do robust ocaml benchmarking.
<thelema> ok, not so interested. Just checking. I've been spending some time on a benchmarking library that goes so far as to measure clock resolution and the cost of getting the time.
<elehack> that sounds quite interesting, but much more complex than my work ever mandates. My benchmarking and profiling needs are typically in the 10s of seconds accuracy department.
<thelema> the other thing it'll do is analyze the pattern of timings and determine if the outliers contributed excessively to the variance of the result, skewing the results.
<elehack> Now I could use one of those in Java...
<elehack> sounds like a useful way to deal with early delays due to the JIT and various caches being cold.
<thelema> the library I'm stealing good ideas from is Criterion, a haskell library. Haskell and Java both have horrible challenges for benchmarking.
<elehack> yeah.
ztfw has quit [Remote host closed the connection]
lopexx has joined #ocaml
lopex has quit [Ping timeout: 258 seconds]
* elehack needs to head home & see if he can get his laptop to stop crashing - ttylater
elehack has quit [Quit: Headed out, possibly to home]
sepp2k has quit [Quit: Leaving.]
lopexx has quit []
lopex has joined #ocaml
bzzbzz has quit [Ping timeout: 252 seconds]
bzzbzz has joined #ocaml
joewilliams is now known as joewilliams_away
<thelema> Batteries 1.4.0 released, let the bug reports roll in
<thelema> hmm, 1.4.0 < 1.4.0pre2 -- time to fix version comparator
lamawithonel_ has joined #ocaml
lamawithonel__ has joined #ocaml
lamawithonel_ has quit [Ping timeout: 255 seconds]
Cyanure has quit [Remote host closed the connection]
dnolen_ has joined #ocaml
joewilliams_away is now known as joewilliams
elehack has joined #ocaml
lamawithonel__ has quit [Remote host closed the connection]
elehack has quit [Quit: Farewell, programs.]
lamawithonel__ has joined #ocaml
joewilliams is now known as joewilliams_away