<hcarty>
adrien: I'm guessing it's because you are effectively asking oasis to create three META files in the same location
Associat0r has quit [Quit: Associat0r]
<hcarty>
adrien: You could try sub-packages. I think there is an example in the oasis source tree illustrating their use. My xstrp4 fork uses them as well.
dnolen has joined #ocaml
rimmjob has joined #ocaml
arubin has quit [Quit: arubin]
dnolen has quit [Quit: dnolen]
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
dnolen has joined #ocaml
everyonemines has joined #ocaml
foocraft has quit [Ping timeout: 240 seconds]
foocraft has joined #ocaml
dnolen has quit [Quit: dnolen]
jimmyrcom1 has joined #ocaml
bzzbzz has quit [Quit: leaving]
jimmyrcom1 has quit [Read error: Connection reset by peer]
jimmyrcom has quit [Ping timeout: 260 seconds]
jimmyrcom has joined #ocaml
joewilliams_away is now known as joewilliams
joewilliams is now known as joewilliams_away
alxbl has quit [Ping timeout: 258 seconds]
mjonsson has quit [Remote host closed the connection]
alxbl has joined #ocaml
emmanueloga has quit [Quit: WeeChat 0.3.6-rc2]
<thelema>
does ocaml's Sys.time() or Unix.gettimeofday() give resolution better than 10ms to anyone?
<flux>
can't really tell from a few tries if there really is more precision, but at least there are more digits :)
jimmyrcom has quit [Ping timeout: 255 seconds]
milosn has joined #ocaml
hto has joined #ocaml
<adrien>
thelema: I can't remember which one I had tried but I'm pretty sure at least one of them had a bad resolution
<adrien>
hcarty: thanks
philtor has quit [Ping timeout: 258 seconds]
testcocoon has quit [Quit: Coyote finally caught me]
testcocoon has joined #ocaml
alxbl has quit [Changing host]
alxbl has joined #ocaml
ygrek has joined #ocaml
edwin has joined #ocaml
foocraft has quit [Ping timeout: 240 seconds]
foocraft has joined #ocaml
ttamttam has joined #ocaml
thomasga has joined #ocaml
ankit9 has joined #ocaml
ikaros has joined #ocaml
rixed has joined #ocaml
ygrek has quit [Remote host closed the connection]
ikaros has quit [Quit: Ex-Chat]
larhat has joined #ocaml
Cyanure has joined #ocaml
Associat0r has joined #ocaml
Associat0r has quit [Changing host]
Associat0r has joined #ocaml
ulfdoz has joined #ocaml
lopex has joined #ocaml
ulfdoz has quit [Ping timeout: 258 seconds]
redsteg has quit [Quit: leaving]
redsteg has joined #ocaml
lopex_ has joined #ocaml
lopex has quit [Ping timeout: 265 seconds]
lopex_ is now known as lopex
wormphle1m has joined #ocaml
wormphlegm has quit [Ping timeout: 244 seconds]
_andre has joined #ocaml
thomasga has quit [Quit: Leaving.]
ygrek has joined #ocaml
thomasga has joined #ocaml
lamawithonel has quit [Ping timeout: 253 seconds]
ygrek has quit [Ping timeout: 248 seconds]
ski has quit [Ping timeout: 255 seconds]
ski has joined #ocaml
ikaros has joined #ocaml
ygrek has joined #ocaml
lopex has quit [Ping timeout: 265 seconds]
lopex has joined #ocaml
ygrek has quit [Ping timeout: 248 seconds]
jamii has joined #ocaml
jimmyrcom has joined #ocaml
_andre has quit [Quit: leaving]
_andre has joined #ocaml
metasyntax|work has joined #ocaml
emmanuelux has joined #ocaml
<thelema>
I have my nice and shiny benchmarking library up and running with scary statistics, but the output is horrendous. Aside from going to graphical output, can I get suggestions to make this output more usable: http://pastebin.com/6BNBRvdN
EmmanuelOga has joined #ocaml
<thelema>
This example is benchmarking integer-comparison routines.
<adrien>
hcarty: where is your xstrp4 fork? and have you announced it?
<adrien>
thelema: what did you end up using for the timing since Sys.time and Unix.gettimeofday aren't usable?
philtor has joined #ocaml
avsm has quit [Quit: Leaving.]
thelema has quit [Ping timeout: 244 seconds]
thelema has joined #ocaml
<thelema>
adrien: I believe I made a mistake on gettimeofday
<thelema>
Sys.time seems to have a 10ms resolution, but Unix.gettimeofday has the same resolution (as measured by my methods) as clock_gettime, which should have ns resolution (but apparently doesn't)
emmanuelux has quit [Quit: Ex-Chat]
<thelema>
thus, the us resolution I'm currently measuring.
<flux>
thelema, are you perchance running the tests in a virtual machine?
<flux>
because that could well introduce inaccuracy
<thelema>
nope, just my laptop. yes, I'm aware of cpu scaling.
philtor has quit [Ping timeout: 244 seconds]
<thelema>
the point of all the crazy statistics I'm using is to deal with any sources of inaccuracy, by choosing reasonable number of samples and repetitions per sample
<thelema>
and then by taking the resulting data and using resampling techniques to determine how much error was introduced by inaccurate clocks and other sources of measurement noise
<hcarty>
adrien: No announcement - I haven't heard from Gerd
<adrien>
git over http, I can pull! \o/
<adrien>
thanks =)
<adrien>
s/pull/clone/
<hcarty>
adrien: Let me know if it works :-)
<adrien>
sure
<hcarty>
I don't want to make an announcement without hearing back from Gerd and hopefully pushing the changes upstream.
<adrien>
of course
lopex has joined #ocaml
jamii has quit [Read error: No route to host]
joewilliams_away is now known as joewilliams
randori has joined #ocaml
ulfdoz has joined #ocaml
fraggle_ has quit [Quit: Quitte]
avsm has joined #ocaml
fraggle_ has joined #ocaml
Boscop has joined #ocaml
larhat has quit [Quit: Leaving.]
rimmjob has quit [Ping timeout: 260 seconds]
larhat has joined #ocaml
rimmjob has joined #ocaml
everyonemines has quit [Quit: Leaving.]
jamii has joined #ocaml
ulfdoz has quit [Ping timeout: 255 seconds]
junsuijin has joined #ocaml
ztfw has joined #ocaml
avsm has quit [Quit: Leaving.]
ttamttam has quit [Quit: Leaving.]
avsm has joined #ocaml
Anarchos has joined #ocaml
rimmjob has quit [Ping timeout: 260 seconds]
patronus_ has quit [Ping timeout: 260 seconds]
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
patronus has joined #ocaml
rimmjob has joined #ocaml
Anarchos has joined #ocaml
abdallah has joined #ocaml
zorun has quit [Read error: Connection reset by peer]
zorun has joined #ocaml
_andre has quit [Quit: leaving]
Cyanure has quit [Ping timeout: 258 seconds]
<_habnabit>
thelema, ah, your merge from master to v2 didn't merge the inter != diff fix. probably a merge conflict because I was modifying things around there too
lpereira has joined #ocaml
ankit9 has quit [Ping timeout: 255 seconds]
ankit9 has joined #ocaml
ygrek has joined #ocaml
<thelema>
_habnabit: thanks for noticing - I'll fix that
<_habnabit>
thelema, I was just working on a branch that adds tests for union/inter/diff
<thelema>
_habnabit: great. I plan on moving all tests to quicktest format - are you using that or the testsuite tests?
<_habnabit>
thelema, oh, I was adding more things to test_set.ml
<_habnabit>
thelema, which I assume isn't quicktest
<thelema>
yes.
<thelema>
There are some quicktests for set at the end of batSet.ml
<_habnabit>
ah, I see them
<thelema>
Normally, they'd be right after the function they're testing
<thelema>
one problem with them is that when they're inside submodules, they don't inherit that submodule's scope
<_habnabit>
well, I'd just finished writing these tests as you'd mentioned it. I just submitted the pull request, anywya.
<thelema>
hopefully quicktests are easier and intuitive to write
<_habnabit>
quicktest does look interesting, though
<thelema>
ah, I guess I'll be converting them. Thanks for writing the tests.
<thelema>
_habnabit: what's this new L475 of test_set.ml: "let inter = intersect"?
<_habnabit>
there's Set.S.inter, but not Set.inter
<_habnabit>
apparently it's spelled Set.intersect
<thelema>
ah, because of the functorization of tests...
<thelema>
that makes sense.
<_habnabit>
yeah, it's just for that bit
<thelema>
a but disappointing that there's a difference - I wonder if that's fixable without breaking backwards compatibility
<thelema>
probably not - I bet those interfaces were set in 1.4.0
<thelema>
well, another thing to fix in 2.0
<hcarty>
thelema: Which one will 2.0 end up with? inter or intersect?
<thelema>
I think it'll have to end up with `intersect`, as that's what stdlib set uses
<_habnabit>
is there any interest in making operations on sets/maps tail recursive?
<thelema>
probably not, as if your set is big enough that one path down the tree blows your stack, ...
<_habnabit>
I'd have to double check, but I think I've had it happen
<_habnabit>
or maybe it was on Hashtbl
<thelema>
since tree heights are log(n), I can't imagine having a balanced tree blow the stack
<thelema>
I bet hashtbl, as it uses linked lists
<thelema>
although it should have grown before the linked list grew too big
<_habnabit>
it resizes dynamically, doesn't it?
<thelema>
but then, the old/current hash function had some pretty pathological behavior on complex objects
<thelema>
yes, it should resize dynamically, but I think based on load, and if the hash function distributes all keys into a single bucket...
<thelema>
the load can be low while still having long lists
<_habnabit>
hmm. how complex is complex? I just checked; on 3.12.1, it sometimes chokes on a hashtbl whose keys are StringSet.t list * StringSet.t * (string option * StringSet.t)
rimmjob has quit [Ping timeout: 255 seconds]
<thelema>
iirc, it has to do with nesting depth of the structure
<thelema>
# Array.init 100 (fun i -> List.make i i |> Hashtbl.hash);;