<mattam>
That depends a lot on the actual implementation choices (e.g. if you use bigger or smaller chunks), but in general it should be ok, it's only constants.
<thelema_>
ropes are great for mutating large strings (including size-changing mutations)
<mattam>
Actually I think the particular problem of having too many small amounts of data is handled by most implementations using different heuristics.
coucou747 has quit ["bye ca veut dire tchao en anglais"]
|Catch22| has quit [Read error: 113 (No route to host)]
jlouis has quit [Connection timed out]
<thelema_>
mattam: having too many small amounts of data? you mean appending lots of small strings?
<mattam>
Actually, I have my own ropes-on-top-of-fingertrees and that's been a problem there too.
<mattam>
The original paper by Boehm already discussed that IIRC.
<julm>
this name sounds familiar
bluestorm has quit ["Konversation terminated!"]
<mattam>
Hans, the one your thinking about
<thelema_>
if you want to append data, use a buffer. If you want to mutate in the middle/beginning, ropes allow you to do that without blitting out the tail of the string each time.
<julm>
of course, gcc's GC
<julm>
I've encountered this because Greg Morissett's TAL uses it
<julm>
special cases guarantee that if a rope is built by repeatedly concatenating individual
<julm>
characters to its end, we still obtain a rope with leaves of reasonable size"
<julm>
it's rather optimistic
<julm>
so all depends on what is considered as a `short leaf'
<thelema_>
I'm using 256-byte leaves for my ropes. The comment on that says "up to 50% overhead in worst case"
<julm>
thelema_: is it a hardcoded value?
<thelema_>
julm: yes. The other hardcoded variable is max_height = 48, which is commented to result in max rope sizes of 220GB on 64-bit machines and ~700M on 32-bit
<julm>
thelema_: can't you use an optional argument for them?
LordMetroid has quit ["Leaving"]
<thelema_>
not at the moment - they're module-global variables
<julm>
and adding fields to the rope type could be too heavy?
<thelema_>
I don't see much benefit to it.
<thelema_>
do you want multiple ropes with different parameters?
<thelema_>
or you just want thicker/thinner or shorter/longer ropes?
<julm>
the greater control I have the better
postalchris has quit [No route to host]
<julm>
but if it hurts performances...
<thelema_>
feh, why aren't you clamoring for command-line arguments in ocaml to change the (N-10)-bit array size
<julm>
I often find myself stuck between these two requirements; since I also work for self, most often I do not care about performances and I sacrifice them...
<thelema_>
Since the code is open, it doesn't seem too unreasonable for someone making that level of tuning choices to copy the code of the module and set different constants
<julm>
command-line arguments in ocaml to change the (N-10)-bit array size <- that would be great indeed since I've a 32bits processor, but would it be easy to do? I don't know.
<julm>
thelema_: I agree, but I'm not found of that kind of copy/pasting à la vendor branch
<bluestorm>
try to provide the ip instead of "gaia" ?
<Yoric[DT]>
darcs failed: (scp) failed to fetch: gaia:/home/prof/teller/public_html/darcs/icfp08/_darcs/inventory
<Yoric[DT]>
I can't, it's on another network.
<Yoric[DT]>
I have to tunnel my ssh.
<bluestorm>
hm, i don't know, then
<bluestorm>
however
<bluestorm>
i get you could separate the two issue by using a fuse-like abstraction over the SSH
<bluestorm>
e.g. shfs allows you to mount a distant ssh place on your disk as a local directory
<bluestorm>
and then you can use darcs easily
<Yoric[DT]>
erf
<Yoric[DT]>
Yeah, I guess.
LordMetroid has quit [Read error: 110 (Connection timed out)]
Yoric[DT] has quit [Remote closed the connection]
Yoric[DT] has joined #ocaml
<Yoric[DT]>
grrrr
<Yoric[DT]>
sshfs won't work with darcs :(
<Yoric[DT]>
But for some reason, the exact same command I attempted to use before trying sshfs now works.
coucou747 has quit [Read error: 104 (Connection reset by peer)]
coucou747 has joined #ocaml
LordMetroid has joined #ocaml
<flux>
yoric[dt], but darcs can use ssh directly?
<flux>
oh, right, you had some trouble
<flux>
I had one issue with darcs: darcs push remotehost:(relative or no path here) didn't work, the path had to be absolute
<flux>
someone(TM) should implement a language extension that would convert keyword TODO into fun _ -> failwith "Modulename.function_name: not implemented (line 42, file modulename.ml)"
<flux>
I suppose automatic synchronization of .mli to .ml so that nonimplemented functions would get that would be ok too ;) (line number information obviously wouldn't work with that approach)
<Yoric[DT]>
:)
<Yoric[DT]>
"assert False" is a bit shorter to write :)
<bluestorm>
flux:
<bluestorm>
do you really mean it ?
<bluestorm>
i can do that in a couple of (tens of) minutes if you want
<bluestorm>
but hm
<flux>
bluestorm, atleast the idea did feel very important a while back when I was converting .mli to .ml manually, filling in placeholders ;)
<flux>
that environment is not yet in 3.10.x, so it might not be worth the trouble
<bluestorm>
ah, i don't know pre-3.10 extensions
<bluestorm>
but i guess you can use post-3.10 camlp4 on 3.09 ocaml code
<bluestorm>
flux: on a larger note, you could create a camlp4 program to convert a .mli into a .ml
<bluestorm>
(filling in placeholders)
<flux>
bluestorm, how would one do it in parts? say, I'm adding new interfaces..
<flux>
I would very much like to see something where I can just mark the region in xemacs and it puts the stub to the corresponding .ml
<bluestorm>
hm
<flux>
I wonder how much tuareg actually know about the language.. (I doubt it knows much)
<bluestorm>
you could use camlp4 -str command line option
<bluestorm>
and code a little elisp script to send it your code and put the result in the good place
<flux>
it's not quite as simple, though? because the marked region might depend on other stuff declared in the .mli?
<bluestorm>
camlp4 only do the syntax side
<flux>
ah, true
<flux>
so that would work then
<bluestorm>
i guess so
<flux>
another thing I've been thinking of writing is a search tool for those .annot-files, so I would be able to search for instances of a type..
<bluestorm>
hm
<bluestorm>
another thing that could be intersting would be to integrate camlp4 better into emacs
<bluestorm>
there is an emacs module for "live syntax checking" iirc
<bluestorm>
i think someone could create an ocaml version with camlp4
<bluestorm>
(ah sh-thing)
<flux>
does camlp4 support resuming after first error?
<bluestorm>
hm, not sure
<bluestorm>
as it's a recursive descent parser
<hcarty>
bluestorm: I would be interested in a let foo x = TODO kind of camlp4 extension if you decide to write it
<bluestorm>
it's merely a proof of concept actually
<bluestorm>
if you're interested, i could think a little bit more and try to make that string argument optional
<flux>
bluestorm, how about if the string with the function name was automatically filled in?
<flux>
right :-)
<bluestorm>
flux: i could do that
<bluestorm>
but it would loose some flexibility
<bluestorm>
as-is, you can use that in any expression
<bluestorm>
not just a function declaration
<flux>
how would that work with any expression?
<bluestorm>
hm
<flux>
I mean, when the compiler just attempts to compile it, it would fail?
<flux>
so top level definitions are out
<bluestorm>
you can do for example
<bluestorm>
(if pretty_print then TODO "pretty-printing function" else print_endline) "foo"
<bluestorm>
hm flux
<bluestorm>
concerning your specific problem
<bluestorm>
i could even do something more specific lire
<bluestorm>
TODO function_signature;;
<bluestorm>
s/lire/like/
<bluestorm>
TODO val pretty_printer : my_type -> unit
<flux>
that might be even more useful
<flux>
and I would be able to almost directly feed it to camlp4 to create a stub?
<flux>
I suppose there might already be "camlp4 expand" in tuareg
<flux>
(apparently there isn't)
<hcarty>
bluestorm: Very nice, thank you for putting that out. The automatic use of function names would be handy for a simple version, but this is very nice as is.
vpalle has quit [Read error: 110 (Connection timed out)]
<bluestorm>
the error location is a bit ugly, though
<flux>
nice
<bluestorm>
i'm not sure it's possible to provide camlp4 with a "start-from-here" quotation
olleolleolle has joined #ocaml
julm has quit [Read error: 104 (Connection reset by peer)]
rossberg has joined #ocaml
det has joined #ocaml
julm has joined #ocaml
AxleLonghorn has joined #ocaml
AxleLonghorn has left #ocaml []
bongy has joined #ocaml
bongy has quit ["Leaving"]
middayc has joined #ocaml
middayc has left #ocaml []
pango has quit [Remote closed the connection]
jorik808 has quit ["no *YOU* quit"]
pango has joined #ocaml
jonathanv has joined #ocaml
Just[a]Doll has joined #ocaml
Just[a]Doll has left #ocaml []
jonafan has quit [Read error: 110 (Connection timed out)]
jonathanv is now known as jonafan
musically_ut has joined #ocaml
musically_ut has quit [Remote closed the connection]
Snrrrub__ has joined #ocaml
musicallyut has quit [Remote closed the connection]
munga has joined #ocaml
marmottine has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
Amorphous has quit [Connection reset by peer]
OChameau has quit ["Leaving"]
Morphous has joined #ocaml
RobertFischer has joined #ocaml
munga has quit ["Leaving"]
Snrrrub__ is now known as Snrrrub
Yoric[DT] has joined #ocaml
Morphous has quit [Connection timed out]
middayc_ has joined #ocaml
ita has joined #ocaml
letrec has joined #ocaml
middayc has joined #ocaml
middayc__ has joined #ocaml
middayc_ has quit [Read error: 110 (Connection timed out)]
middayc_ has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
<letrec>
Hi! Can somebody explain what the idiom let () =... means?
<petchema>
let does pattern matching... That's how let (a, b) = (2, "blah") works
<jonafan>
it makes sure whatever is on the other side of that returns unit
<petchema>
yup
<letrec>
But let () = show g1 ?
<petchema>
But what?
<letrec>
Does it execute the thing or create a binding?
<letrec>
let a = ... creates a binding
<letrec>
(I think)
<petchema>
it execute de thing, there's nothing to bind
<petchema>
s/de/the/
<letrec>
Ok, thanks. I don't really see what's the use though.
<rwmjones>
letrec, let () = .. does immediately execute the '...' code
<rwmjones>
and it also ensures that the '...' code returns unit
<jonafan>
if it's not in a function, let () = ... is sort of like a main function
<rwmjones>
it's useful because of the difference in parsing between "top" let and "inner" let, since some people prefer to use the inner style of let in their code
<jonafan>
if it's in a function, it means do this, and don't let me write something that doesn't evaluate to unit
<letrec>
Yes, ok, it makes sense.
linktim_ has joined #ocaml
<bluestorm>
letrec: the syntax is let <pattern> = <expression>
<bluestorm>
let a = ... create a binding because "a" is a binding pattern
<bluestorm>
but with a pattern you can create no binding (constant patterns : let 1 = ... , let () = ..; universal pattern : let _ = ....), or create numerous binding at once : let (a, b) = ...
<bluestorm>
let in inself isn't a "binding", it's a cute syntax for pattern-matching, with some subtelties at the polymorphism level regarding functions
<bluestorm>
but hm
<bluestorm>
iirc, we have already discussed that with you
<bluestorm>
(log says : 02/13/2008, ~16:30)
<letrec>
With me, I don't think so.
<letrec>
Anyway, I last thing: if I write: module type WHATEVER = sig ... end. What's WHATEVER in this case? Is it also a type?
<letrec>
s/, I/, a/
<bluestorm>
hm
<bluestorm>
it's a module interface name
<bluestorm>
isn't at the type level
<bluestorm>
(doesn't share the same namespace, either)
Linktim has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
That code is about 100 times slower than the same one with monads.
<Yoric[DT]>
In bytecode.
|Catch22| has joined #ocaml
<Yoric[DT]>
Am I missing something obvious ?
<thelema_>
and you need to run this at gazillions of operations per second?
thelema_ is now known as thelema
<Yoric[DT]>
I'm testing performance.
<Yoric[DT]>
Of my monad library, that is.
<Yoric[DT]>
But it should be slower than OCaml's native exceptions.
<thelema>
I don't see anything obvious, describe your test data...
<Yoric[DT]>
Erf, in native code, the native exceptions are about 300x slower.
<thelema>
"string_of_expr e" ?? where comes e from?
<Yoric[DT]>
I only pasted the internal loop.
<Yoric[DT]>
10000 random trees (the same ones for each implementation), all of them of depth 10 or less and filled with numbers between -5 and +5.
<thelema>
do you do mostly adds or divs?
<Yoric[DT]>
Same probability.
<Yoric[DT]>
I'm running the test 5 times and discarding the first 4 in case of cache issues.
<Yoric[DT]>
Oh, sorry, that was depth 20 or less.
<Yoric[DT]>
And it gets muuuch worse when I grow the depth to 25.
<Yoric[DT]>
So I guess I'm introducing some non-tail-recursion.
<Yoric[DT]>
But I don't see how.
<thelema>
all your recursion is non-tail
<Yoric[DT]>
Fair enough :)
<Yoric[DT]>
So I'm doing something wrong somewhere.
<thelema>
but the depth should be small enough for this not to matter
<thelema>
try | Add (f,g) -> let f' = aux f and g' = aux g in f'+g'
<Yoric[DT]>
At depth 25, it's getting 1500x faster for my library.
<Yoric[DT]>
That should be illegal.
<bluestorm>
what's the faster code like ?
<bluestorm>
(on a side note, "Val f" sounds like a function to me. Seems your variable-naming tastes are exotic, as the usual maths folks would use a/b or x/y there, certainly not f/g)
<Yoric[DT]>
but for some reason, the non-monadic version fails to catch that
<Yoric[DT]>
Ok, fixed that.
<Yoric[DT]>
I had mistaken two arguments.
<Yoric[DT]>
Checking again...
|Catch22| has quit [Read error: 104 (Connection reset by peer)]
<thelema>
how about 'string_of_expr g' in the exception
<Yoric[DT]>
Okay, now my monad and the exception management work at the exact same speed.
<Yoric[DT]>
Which looks more coherent.
<thelema>
:)
<Yoric[DT]>
Which is a bit faster than the regular error exception.
<Yoric[DT]>
Testing with large trees...
<Yoric[DT]>
And going to eat something in the meantime :)
<thelema>
can you paste the corrected code, or was the error outside what you showed us?
crathman has joined #ocaml
<Yoric[DT]>
Er... the error seems to have appeared after I pastebined that.
<Yoric[DT]>
Don't ask me why...
marmottine has quit ["Quitte"]
ygrek has joined #ocaml
travisbrady has joined #ocaml
RobertFischer has left #ocaml []
crathman has quit ["ChatZilla 0.9.81 [Firefox 2.0.0.12/2008020121]"]
<julm>
Well, just sharing a few benchmarks on the efficiency of labels vs. functors, both with and without eta-expansion; here they are: http://pastebin.com/d66a5a723
<julm>
These *very* little benchmarks gave me this execution speed order:
<julm>
Weird isn't it? functors seem to be slower than just labels, and non-eta-expanded functions are much slower than their eta-expanded version; I would have bet the opposite :/
<thelema>
julm: label-eta has one less closure to build
<julm>
and that makes quite a big difference :/
<thelema>
when you're iterating max_int times... yes
<julm>
:)
Linktim has quit [Remote closed the connection]
* thelema
can't run the test as given on his computer - it takes too long