drunK has quit [Remote host closed the connection]
ftrvxmtrx has joined #ocaml
seafood has quit [Ping timeout: 240 seconds]
drunK has joined #ocaml
jm has joined #ocaml
gmarik has joined #ocaml
coucou747 has joined #ocaml
mike_mcclurg has quit [Ping timeout: 240 seconds]
eye-scuzzy has quit [Quit: leaving]
mike_mcclurg has joined #ocaml
yezariaely has joined #ocaml
yezariaely has left #ocaml []
LeNsTR has joined #ocaml
LeNsTR has quit [Changing host]
LeNsTR has joined #ocaml
LeNsTR has quit [Client Quit]
<kaustuv>
Is github unusually slow for anyone else? Like ~2 minutes for a git pull?
* thelema
tries
<thelema>
nope, took ~5 seconds for me
<kaustuv>
Damn gremlins must be eating my packets
<thelema>
github.com has address 207.97.227.239
<thelema>
maybe you're using a bad server?
LeNsTR|away has joined #ocaml
LeNsTR|away has quit [Changing host]
LeNsTR|away has joined #ocaml
<thelema>
or maybe github is just being flaky, as it's wont to do
<kaustuv>
What is the difference between batteries.mllib and batteries_uni.mllib ?
cyanure has joined #ocaml
<thelema>
batteries_uni.mllib is the list of modules assembled into batteries_uni.cma cnd .cmxa
<thelema>
right now the only difference is BatMutex, BatRMutex and the Batteries (to replace Batteries_uni)
<kaustuv>
Yeah, but what is the diff. between batteries.cm(x)a and batteries_uni.cm(x)a?
<thelema>
one supports threads, while the other works in a thread-free compile
<thelema>
"uni = no threads", somehow I got the name from uniprocess
<thelema>
looking back, it's a pretty terrible name
<kaustuv>
Yeah, it might not be an optimal name because uni can = universe, and anyway -threads doesn't give you multiprocessing
<thelema>
yes, I know
<thelema>
but "nothread" seemed too long
<thelema>
the plan for 2.0 when we can break backwards compatibility is to have "batteries" be non-threaded and "batteries_thr" be threaded
<mrvn>
name it the same way the stdlib does
<mrvn>
/usr/lib/ocaml/threadUnix.mli
<thelema>
ThreadBatteries?
<mrvn>
small t.
<thelema>
open ThreadBatteries
<mrvn>
Or is that Thread::Unix?
<mrvn>
thelema: does the threaded batteries have more functions?
<thelema>
mrvn: it has Mutex and RMutex modules that non-threaded doesn't
<mrvn>
Ahh, so you can't do archive(native) = "unix.cmxa" and archive(byte,mt_vm) = "vmthreads/unix.cma" automatic switching.
<mrvn>
And why is that vmthreads/unix.cma there? Whats threadUnix.mli for then?
<thelema>
iirc, one still does 'open Unix'
<thelema>
even in threaded programs
<mrvn>
thelema: exactly. The META file picks the right unix.cma for you.
<mrvn>
But forget the threadUnix suggestion. That seems to have to do with the old Thread::Unix module.
<hcarty>
thelema: Could Mutex and RMutex be replaced by dummy versions in the non-thread case?
<thelema>
probably
<thelema>
If someone wants to make it work automatically, I wouldn't mind.
<mrvn>
hcarty: easily. You just use an int and increment/decrement it without locking.
<thelema>
I don't recall why we failed at doing this before... maybe we just need a src/threads folder
<thelema>
there was something that prevented doing it automatically before.
<mrvn>
thelema: how does that work with the unix module and bytecode? There doesn't seem to be a thread and non-thread version?
<thelema>
there is a thread version in otherlibs/threads/unix.ml
<thelema>
and a nonthread version in otherlibs/unix/unix.ml
<mrvn>
which generate /usr/lib/ocaml/unix.cma and /usr/lib/ocaml/vmthreads/unix.cma
<thelema>
yup.
<mrvn>
aeh, sorry. I ment how does this work for native code. There is only /usr/lib/ocaml/unix.cmxa, no vmthreads version.
* thelema
doesn't know
<thelema>
maybe it's already threadsafe in native code?
<mrvn>
anyway, if you add dummy Mutex/RMutex modules so the interface is the same you can do the archive(byte,mt_vm) = ... trick.
eye-scuzzy has joined #ocaml
ygrek has quit [Remote host closed the connection]
ygrek has joined #ocaml
ulfdoz has joined #ocaml
NaCl is now known as melatonin
oriba has quit [Quit: Verlassend]
melatonin is now known as NaCl
NaCl is now known as NameStolen
NameStolen is now known as Invincible
ftrvxmtrx has quit [Quit: Leaving]
avsm has quit [Quit: Leaving.]
brendan has joined #ocaml
Invincible is now known as NaCl
ikaros has joined #ocaml
Yoric has joined #ocaml
Yoric has quit [Client Quit]
Obfuscate has quit [Read error: Connection reset by peer]
ttamttam has quit [Remote host closed the connection]
<jm>
Is there a good reason why BatSet doesn't have a subset function (it's part of the BatSet.S module type)?
Associat0r has joined #ocaml
<thelema>
jm: the upcoming release has a compare_subset function that returns the information you want ... hmm, still only for functorized sets, not polymorphic ones...
<thelema>
jm: you're welcome to write one with a few tests, and we can include it.
<thelema>
I think the limiting factor is the ordering of the sets - even if they're the same type, different comparison functions make this inefficient
<jm>
thelema: Thanks! Well, I don't really care about efficiency in my current application so mine version would be very naive and possibly not approriate for batteries...
<thelema>
I can assure you that there's a few set/map functions that aren't so efficient
<thelema>
such as BatSet.union, which just adds all the elements in the second set to the first with a fold
<jm>
Ok, here's what I would do: let subset s1 s2 = forall (fun x -> mem x s2) s1.
<jm>
*for_all
<jm>
Still think you want something like this in batteries? :p
<thelema>
I'm writing the mli docs right now
<mrvn>
Can't you get access to the comparison function and if they are equal then compare efficiently?
<thelema>
mrvn: yes. bluestorm has a branch which does this - yet unmerged
<mrvn>
As for union. It is a bit hard to insert into a tree without starting from the root each time. At lest if each insert balances.
<thelema>
jm: how should I attribute your code?
<mrvn>
thelema: .oO(reject patch unless attributed properly in its header :)
<jm>
thelema: That's fine. It's too trivial for an attribution.
ftrvxmtrx has joined #ocaml
<thelema>
mrvn: I just copied the code from IRC to batSet.ml, there's no patch
<thelema>
jm: are you going to make me track you down so I can put you in the commit log?
<jm>
thelema: What exactly do you need from me? My name? Or a github account name?
<thelema>
although this will be more difficult with you being in the UK.
<thelema>
usually git commits are attributed to a "Full Name <email@address>"
<thelema>
if you insist, I can attribute it to less, but "JM <JM@ip address on #ocaml@freenode>" isn't a very good one
<jm>
Ok, ok. Make it: "Justus Matthiesen <justus.matthiesen@gmail.com>".
<thelema>
jm: your next commit, please write the doc for
<mrvn>
When the aliens invade they will forever wonder who this Justus was that wrote this horrible code. :)))
<thelema>
and the tests
<jm>
thelema: Sure thing (my first commit was completely unintentional, after all)!
<mrvn>
I'm veen thinking. With a functional set wouldn't it be faster to remove each element from the first set from the second. If one isn't present the sets aren't equal. If the set is empty at the end they are equal.
<thelema>
it passed all tests the first time, though. that counts for something
<thelema>
mrvn: that sounds like it'd work - show me the code.
<mrvn>
jm: care to implement that and compare for different sized sets?
<thelema>
on the other hand, the lower levels of the set would likely be cached, and the cost of rebalancing once might kill any benefit gained.
<jm>
That's a relieve because I didn't actually run the code.
<mrvn>
thelema: sure, the remove costs more that member but the set will be getting smaller and smaller.
<mrvn>
thelema: you could improve it by an unbalanced removal.
<thelema>
I dunno about all the rebalances that would be necessary. Maybe if the elements could be removed in random order...
<thelema>
or in some order less likely to unbalance the tree than sorted min -> max
<mrvn>
thelema: if the comparison function is the same the order will be in order. otherwise who knows.
<mrvn>
But removal without balancing will just shorten the paths until you end up with an empty set. that would be ideal.
<thelema>
in order removals are bad just as in order inserts are bad
<mrvn>
thelema: do you know of some algorithm to do inorder removal/insert?
<thelema>
I recall seeing one...
<thelema>
but I can't seem to google it ATM
<mrvn>
Specifically I have a list of sorted and continious keys (no gaps) and want to insert them into a B-Tree. Or I want to remove all keys between A and B.
<mrvn>
The other case I often have is that I insert at the end. That is also verry bad for the balance.
<mrvn>
One thing I'm currently doing is that if the node is the rightmost node of a level and needs splitting then I move nearly all elements in the lower node instead of half and half.
drunK has quit [Remote host closed the connection]
<kaustuv>
thelema: I am still debugging that, so please don't hack on it yet. I'll give you a pull request when make test works for me locally.
<thelema>
ok, well I seem to have it hooked into the build system satisfactorily, so don't worry about that part,
<kaustuv>
Actually, just fetch that URL again. I think pushing to git will be hard given how much my local master has diverged. I would rather toss the work out than try to rewrite history.
<thelema>
no problem.
<kaustuv>
OK, all tests pass for me locally.
drunK has joined #ocaml
<thelema>
things look good here too. running one more clean test before pushing
<thelema>
ok, pushed.
<kaustuv>
I would propose one modification to the inline tests syntax -- using (*{ }*) instead of (** **) -- to prevent accidental collision with ocamldoc
<kaustuv>
(even if ocamldoc is only run on the .mlis)
<thelema>
there was a couple accidental collisions with .ml ocamldocs that started with (**T...*), but I found and fixed them.
<thelema>
in the future, I don't expect there to be too many problems that way, but we could probably require **) on tests, which would cut down the accident rate.
<thelema>
further, we could require whitespace after the (**T
<ounit>
someone here experienced wiht ounit?
<thelema>
oh, you have already required the whitespace
<kaustuv>
thelema: yes, and also the **) as terminator
<thelema>
ounit: go ahead and ask
<thelema>
well, I guess if someone does (**T ... *), they deserve to raise an error (instead of being treated as a normal comment)
<ounit>
i am new at unit tests and should programm some tests in ounit, but have no idea how to start, has someone usefull pages or tutorials?
<thelema>
although "(*** " might be common enough...
<ounit>
i have read the rather short explanations on ounit homepage
<thelema>
ounit: I assume you have some code to test. The usual way to do this is by having a separate program that runs the code and compares the result with the expected result, raising an error if there's a difference
<thelema>
step 1: make a separate program that calls your code successfully, ignoring the result. It's best if this program has any needed input built in to it.
<thelema>
(ounit isn't needed for step 1)
<ounit>
i have working compiler files in separate folders can i make one main test file in the root folder to test the separated modules?
<thelema>
step 2: add ounit to your step 1 program to check the result, so you get nice progress and harness integration, with nicer printing of any problems and heirarchical testing, plus naming for all your tests
<thelema>
ounit: of course
<ounit>
and how do i open those files so ounit doesnt complain?
<thelema>
often people have source code in "lib/" and tests in "lib_test/", batteries has code in "src/" and tests in "testsuite/" and "qtest/"
<thelema>
that's a step 1 problem, unrelated to ounit.
<thelema>
ocamlc -I compiler_folder/ test.ml -o test
<thelema>
(this is without ounit)
<thelema>
with ounit, you probably want to use ocamlfind:
<thelema>
ocamlfind ocamlc -package oUnit -I compiler_folder test.ml -o test
<ounit>
can you explain that line, please
<thelema>
"ocamlfind ocamlc" tells ocamlfind you want to compile bytecode, "-package oUnit" tells it to add whatever compiler options the oUnit package needs
<thelema>
"-I compiler_folder/" adds compiler_folder/ to the include directory, so it'll be searched for .cmo files (the result of compiling your main program)
<thelema>
and I hope you understand the rest
<ounit>
not really
<thelema>
"test.ml" says to compile the file test.ml, and "-o test" says to output the result to the file "test"
<ounit>
i have a predone makefile in this folder so i had never to work with ocamlc or ocamlfind
<thelema>
fair enough. you'll need to use that to build the compiler before you can build the tests
<thelema>
... I'm assuming you want to test various functions in the compiler, and not to test the whole compiler on various test programs
<ounit>
yes exactly
<thelema>
and I'm gone for the next hour and a half, be back then
<ounit>
thanks, will be here than
_andre has quit [Quit: leaving]
ymasory has joined #ocaml
Snark has quit [Quit: Ex-Chat]
BiDOrD has joined #ocaml
BiDOrD has quit [Client Quit]
BiDOrD has joined #ocaml
drunK has quit [Remote host closed the connection]
drunK has joined #ocaml
LeNsTR|away has quit [Remote host closed the connection]
ygrek has quit [Ping timeout: 240 seconds]
ymasory has quit [Remote host closed the connection]
ygrek has joined #ocaml
mnabil has joined #ocaml
lpereira has joined #ocaml
myu2 has quit [Remote host closed the connection]
cyanure has quit [Quit: Quitte]
boscop has quit [Ping timeout: 240 seconds]
Yoric has quit [Quit: Yoric]
kaustuv_ has joined #ocaml
boscop has joined #ocaml
vk0 has quit [Read error: Operation timed out]
mfp_ has joined #ocaml
mfp has quit [Ping timeout: 240 seconds]
vk0 has joined #ocaml
Edward__ has joined #ocaml
mfp_ is now known as mfp
Obfuscate has joined #ocaml
<ounit>
thelema: are you back?
<thelema>
ounit: yes
Yoric has joined #ocaml
gmarik has quit [Quit: Leaving.]
gmarik has joined #ocaml
<ounit>
thelema: perfect
<ounit>
could you continue with explanation please
<thelema>
that was my explanation. Have you tried to do what I listed as step 1?
<ounit>
isnt that what my makefile does?
<thelema>
no ounit, just write a program that calls the functions you want to test
<thelema>
your makefile compiles your compiler
<thelema>
you need to make a new file (call it test.ml) and call internal compiler functions from it.
<ounit>
yes, now i can follow again
<ounit>
i have such a test.ml file in the root folder
<thelema>
And figure out how to compile that against the parts of the compiler you're compiling
<thelema>
and you're calling one function from the compiler with appropriate arguments?
<ounit>
thats where all the problems start
<thelema>
appropriate arguments? or compiling?
<ounit>
one step earlier, just for my understanding, i compile first the compiler and then i compile the test.ml?
<thelema>
yes, use the makefile to compile the compiler
<thelema>
then compile your test.ml against the .cmo/cmx files produced
<ounit>
how do i compile against .cmo/cmx files?
<thelema>
If you're calling a function Foo.bar, ocaml will want to find a file foo.cmo (for bytecode) or foo.cmx (for native compiled)
<thelema>
if it's not in the current directory, you should add -I dir/ to the command line to tell it to look in dir/
<ounit>
and if i have several different files to test in different folders, should i then write multiple dirs?
<thelema>
-I dir1 -I dir2 -I dir3
<thelema>
start with a single function and expand from there once it's working
ymasory has joined #ocaml
<ounit>
the compiled test.ml, i start it with ./test ?
<thelema>
ounit: before adding ounit, it's not important that the program do anything - the output of whatever functions you're testing can be ignored
<kaustuv_>
thelema: also, there is a problem with make_suite (and also with the earlier make_suite.rb) -- if the tests are not in the top level of the module, then the generated file cannot compile. They can break even if the tests are in a submodule. This makes testing stuff like BatArray.Cap very convoluted
<thelema>
kaustuv_: the changes look good. I guess we could parse module structure and use open M in .. for each test within a submodule
<ounit>
thelema: why ignoring the output of the functions?
<thelema>
ounit: because the purpose of step 1 is to just be able to compile against the code to be tested, part 2 adds the actual testing functions, and ounit consumes the output of the function itself
ygrek has quit [Ping timeout: 240 seconds]
Yoric has quit [Quit: Yoric]
<kaustuv_>
thelema: yes, I thought about parsing the module structure, or at least the [module Foo = struct ... end] fragment. The full solution (i.e., for functors) would still be impossible, I think.
<thelema>
sure, I think we'll have to do testing differently for i.e. Set.Make
<thelema>
luckily we don't have too many of those
<ounit>
thelema: now i can follow :)
<ounit>
thelema: so basically the test.ml just contains open OUnit and let _ = run_test_tt_main () ?
DimitryKakadu has quit [Remote host closed the connection]
<thelema>
ounit: a bit more than that - you'll want to run_test_tt_main on a group of tests
<ounit>
thelema: but those tests do not call functions from the compiler?
<thelema>
you can use "testgroup_name" >::: [ t1; t2; ... ] to make a group from tests t1 t2 t3
<thelema>
and "test_name" >:: test_function to make a test
<thelema>
the tests absolutely call functions from the compiler
<ounit>
the tests t1 to t3 are empty?
<thelema>
no, they're created by "test_name" >:: test_function
<thelema>
and test_function probably uses OUnit.assert_equal to check that the output of the compiler function matches what it should be.
<ounit>
open OUnit let test1 = assert_equal 7 (Graph.string_of_node 7) let graph_suite = "Graph-suite">::: ["test1">:: test1] let suite = "Test-suite">::: [graph_suite] let _ = run_test_tt_main suite
<ounit>
something like that?
<thelema>
yes, something like that, probably with some changes in test1:
<ounit>
but that would call some theoretical function a test file
<mfp>
hmm seems a number of students got an assignment involving ounit(?)
<adrien>
hahaha
<thelema>
also involving a compiler that they haven't written...
ikaros has quit [Quit: Leave the magic to Houdini]
<thelema>
I'd guess TAs for the compiler class that's using OCaml (that we're also getting beginner questions about), except they're in the wrong hemisphere
<thelema>
the compiler they're working on looks a bit like caml-light
<kaustuv_>
ounit is such a trivial library that it must either not do something basic that other testing libraries such as JUnit do (reflection?) or unit testing must be a fundamentally bogus software engineering discipline
<thelema>
quickcheck is a pretty trivial library too. Unit testing is bogus in most situations.
<kaustuv_>
Well, quickcheck is good for checking the obvious boundary conditions, and it did find a bug in my code recently, so I am not entirely against it
<thelema>
unit testing is good for library code, not quite as good for user-facing code
ftrvxmtrx has quit [Quit: Leaving]
tautologico has joined #ocaml
kaustuv_ has left #ocaml []
drunK has quit [Remote host closed the connection]