Banana has quit [Read error: 113 (No route to host)]
Banana has joined #ocaml
budjet has joined #ocaml
Smerdyakov has joined #ocaml
Smerdyakov has quit ["gone"]
budjet has quit [Remote closed the connection]
Banana has quit ["leaving"]
Banana has joined #ocaml
budjet has joined #ocaml
mbh has joined #ocaml
mrvn has joined #ocaml
Submarine_ has quit [Read error: 60 (Operation timed out)]
mrvn_ has quit [Read error: 110 (Connection timed out)]
budjet has quit [Remote closed the connection]
smimram has joined #ocaml
Submarine_ has joined #ocaml
pango has quit [Nick collision from services.]
pango has joined #ocaml
smimou has quit [Read error: 60 (Operation timed out)]
mrsolo has joined #ocaml
KrispyKringle has joined #ocaml
Submarine has quit ["Leaving"]
budjet has joined #ocaml
smimram is now known as smimou
budjet has quit [Remote closed the connection]
_fab has quit [Read error: 60 (Operation timed out)]
_fab has joined #ocaml
ne1 has joined #ocaml
gpciceri has joined #ocaml
budjet has joined #ocaml
budjet has quit [Remote closed the connection]
gpciceri has quit [Operation timed out]
gpciceri has joined #ocaml
Smerdyakov has joined #ocaml
gpciceri_ has joined #ocaml
gpciceri_ has quit [Read error: 104 (Connection reset by peer)]
KrispyKringle has quit [Read error: 113 (No route to host)]
KrispyKringle has joined #ocaml
Smerdyakov has quit []
KrispyKringle has quit [Nick collision from services.]
gpciceri_ has joined #ocaml
gpciceri_ has quit [Read error: 104 (Connection reset by peer)]
KrispyKringle has joined #ocaml
kd has joined #ocaml
kd has quit [Client Quit]
mbh has quit [Read error: 110 (Connection timed out)]
gpciceri has quit ["Leaving"]
KrispyKringle has quit [Read error: 110 (Connection timed out)]
<judge>
i'm having some issues with ocaml gc
<judge>
it seems to constantly allocate memory
<judge>
every time i call a function, it allocates more memory
Herrchen has quit ["bye"]
quamaretto has quit [Remote closed the connection]
Smerdyakov has joined #ocaml
mbh has joined #ocaml
<smimou>
I also have a question
<smimou>
somebody wrote to me :
<smimou>
My undertanding of what CAMLparam macros do:
<smimou>
they provide information to the garbage collector that the corresponding objects are "alive". The GC cannot figure it out on its own: it knows how to
<smimou>
scan the OCaml stack, but not the C stack. These macros prevent the corresponding objects from being *destroyed* by the garbage collector
<smimou>
but it can still *move* them around in the OCaml heap -- this is a normal GC procedure -- and after than their C pointers become invalid!
<smimou>
do you agree ?
<smimou>
I thought it would also prevent values from being relocated
<Riastradh>
If you do CAMLparam1(x), I believe it stores the address of x to store the new pointer in if the object x points to is moved.
<smimou>
do you know any doc which could clearly explain what all those macros do ?
<smimou>
(aside the source)
<Riastradh>
They push a new external GC roots frame.
<smimou>
so you think this should not cause problems when used by a multi-threded program ?
<Riastradh>
Sorry, I don't know much about how OCaml threads work.