<palomer>
sexplib sucks when you need to use external datatypes
<palomer>
(not to diss sexplib, it's still cool)
<kaustuv>
Is there a way to pin a value in memory to prevent the GC from relocating it? I am willing to (deep) copy the value and/or muck with it from C-side if needed. I also don't care about objects and polymorphic variants.
<mrvn>
kaustuv: You have 2 options: 1) create a pointer to the value and register it as new root, 2) deep copy it
<mrvn>
Unfortunately there is no "unmovable" tag for the ocaml GC or even a custom tag that still scans contained values.
<kaustuv>
My brief attempt at deep copying has been abortive because the GC moves it while I'm copying. I suppose I have to precompute the space for the data and do some manual memory management from C.
<mrvn>
kaustuv: 1) why would the GC run at all while you copy? 2) you should tell the GC about all values you handle so it updates your pointers too.
<mrvn>
Deep-copy is really evil though. That makes your code depend on the memory layout of the GC.
<Yoric[DT]>
palomer: ok, [Standard.result] is now sexplib-compatible (on the git)
<kaustuv>
Try changing the example at the end on (fibtree 10) or (fibtree 15)
<kaustuv>
Anyway, I think I've figured out a solution that does not require pinning.
<mrvn>
kaustuv: and the problem is where? The entries namex 0x3FA2345C4CE4?
<mrvn>
s/namex/named/
<kaustuv>
Yeah. The solution is to prune everything that doesn't have "root" as a parent.
<kaustuv>
Well, that works for purely functional data structures. Dunno what it does to references.
<mrvn>
where does the 0x... come from?
<kaustuv>
I add it. It's a very cheap hack: the "pointer value" of x, assuming x is a block, is (Obj.magic x : int)
<mrvn>
But why isn't it a Node like all the others?
<kaustuv>
Good question. And my naive "solution" doesn't work anyway.
<mrvn>
You start at the root node and then you recurse the 2 trees. It should never reach anything not a child of root.
<mrvn>
I think you need to use Hashtbl.hash or something instead of loc.
<kaustuv>
It can if the GC moves stuff around. The parent->child relationships are computed lazily. Only the last thing that was the parent is named "Node()"
<mrvn>
or assign each object an id and record it in a Hashtbl.
<kaustuv>
I'm pretty sure loc works because I've tested it with Gc.compact (). However, compact() is just too slow for my sanity.
<mrvn>
but "loc x" changes when the GC runs.
<mrvn>
You could use Marshal.to_string and then use the offset in the string instead of loc x.
<mrvn>
Althought then you have to implement your own Obj.... stuff.
<kaustuv>
Well, I know how to do it correctly from C with malloc(), so that's what I'll do.
<mrvn>
let id_tbl = Hashtbl.create 0 let next_id = ref 0 let loc r = try Hashtbl.find id_tbl r with Not_found -> let id = !next_id in incr next_id; Hashtbl.add id_tbl id r; id
<kaustuv>
Interesting. Thanks. That seems to pass my small battery of tests.
<mrvn>
Doesn't compile here. did you fix anything?
<kaustuv>
Yeah, switch the args to Hashtbl.add.
ttamttam has left #ocaml []
<kaustuv>
But it's not faithful to the memory layout, unfortunately. Two different allocations of the same structure will be given the same id.
<mrvn>
kaustuv: you need to use the functor interface to Hashtbl and define HashedType.equla to physical equality.
<kaustuv>
Already tried that earlier. Since view is polymorphic, I cannot use Hashtbl.Make() because ocaml doesn't allow writing type declarations such as [type t = 'a].
<mrvn>
let r = Obj.repr r in
<mrvn>
That way all your 'a become one type.
<mrvn>
Although I don't know if that collides with physical equality.
<mrvn>
kaustuv: your explaination seems to fit and with that in mind the output graph is right.
<mrvn>
display ~name:"n4" (fibtree 7) (tree None);; shows 2 Node(Empty, 0, Empty). Does (==) break when the GC moves things?
<mrvn>
or the Obj.repr does.
<kaustuv>
OK the show_lazy.ml at the above url has the current best attempt that seems to work for simple tests. Will test other stuff later. Thanks, mrvn.
<mrvn>
np. interesting code.
ygrek has joined #ocaml
thelema has quit [Remote closed the connection]
<palomer>
http://pastebin.com/m57af918e <--what the blazes could this mean? Oset.Node_func is the same module as OsetNode_func
<mrvn>
I would say there is a "." missing.
<mrvn>
I'm not sure if you can use one module by 2 paths interchangably.
<palomer>
that's a huge bummer!
* palomer
will have to investigate this further
<kaustuv>
Something needs to know that 'a Oset.Node_func.conode = 'a OsetNode_func.conode. If the signature for Oset hides this, then all bets are off.
Yoric[DT] has quit ["Ex-Chat"]
willb has joined #ocaml
ppsmimou has quit [Read error: 104 (Connection reset by peer)]
ygrek has quit [Remote closed the connection]
gim has joined #ocaml
authentic has left #ocaml []
authentic has joined #ocaml
Associat0r has joined #ocaml
willb1 has joined #ocaml
Amorphous has quit [Read error: 104 (Connection reset by peer)]
ched_ has quit ["Ex-Chat"]
Ched has joined #ocaml
jeremiah has quit [Read error: 110 (Connection timed out)]
jeremiah has joined #ocaml
willb has quit [Remote closed the connection]
komar_ has joined #ocaml
Amorphous has joined #ocaml
ppsmimou has joined #ocaml
s4tan has quit []
Associat0r has quit [Client Quit]
_zack has joined #ocaml
ttamttam has joined #ocaml
jeanbon has joined #ocaml
mikeX has joined #ocaml
willb1 is now known as willb
willb has quit ["Leaving"]
willb has joined #ocaml
ygrek has joined #ocaml
_zack1 has joined #ocaml
_zack has quit [Read error: 110 (Connection timed out)]
_zack1 has quit [Client Quit]
LeCamarade has quit ["Gone."]
Snark has joined #ocaml
j_lenorm has joined #ocaml
<j_lenorm>
is omake in redhat?
<j_lenorm>
can't find it anywhere
<hcarty>
j_lenorm: As in RHEL?
<j_lenorm>
fedora
<hcarty>
It should be in Fedora, at least for recent versions
<hcarty>
"yum search omake" should find it
<j_lenorm>
I don't have permission to use yum
<j_lenorm>
on a school computer
<hcarty>
Then you may have to compile it on your own, unless you can get someone with admin rights to install it for you
hardcoding has joined #ocaml
<hardcoding>
Hello can someone help me find a solution to create a type chiffreCar = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'} ?
<flux>
j_lenorm, you might just ask the administrators to install it for you, too
<j_lenorm>
yeah, currently finding out which packages I need to request
<hcarty>
j_lenorm: It should be called "ocaml-omake"
<j_lenorm>
yeah, I googled every package
j_lenorm has quit [Remote closed the connection]
itewsh has joined #ocaml
<hardcoding>
please?
<mfp>
hardcoding: use one (constant) constructor per digit in a variant type
hcarty has quit [Read error: 60 (Operation timed out)]
itewsh has quit ["There are only 10 kinds of people: those who understand binary and those who don't"]
<hardcoding>
ok thanks mfp it worked. Now I'm stuck because I would like to do int_of_char to all the elements of a list.. I thought about let rec tr = function [] -> [] | e::r -> int_of_char(e)::tr(r)::[];; but it doesn't work...
<totom>
you need int_of_char(e)::tr(r)
<totom>
:: appends one element
<totom>
you're trying to concatenate two lists here
<totom>
that would be @, but you don't need that empty list
<totom>
anyway, List.map int_of_char l will do
<hardcoding>
Oh yeah I see thank you! and I prefer writing everything myself.
<mfp>
(stylistically, drop those parentheses)
<hardcoding>
which?
<mfp>
function application is meant to be "cheap" syntactically, so it's just juxtaposition
<mfp>
int_of_char e :: tr r
<hardcoding>
ok^^
<hardcoding>
and I substract 48 to int_of_char e I even get to convert char lists such as ['1';'2';'3';'4'] to [1;2;3;4] ! :D
<hardcoding>
when I*
<kaustuv>
Is there ever a good reason for the tag of a block to change from (say) double_tag to forward_tag?
ttamttam has left #ocaml []
<mfp>
kaustuv: isn't forward_tag used only by Lazy and when forwarding pointers to the major heap?
<kaustuv>
Definitely for %lazy_force, but I'm trying to find out what else might introduce forward_tags. Thanks for reminding me about the major heap.
<mfp>
well the blocks with the forward tag would remain in the minor heap and disappear once the minor GC run is done, so AFAICS the only possible conversion that would be visible is the one you mentioned (lazy_tag -> forward_tag)
hcarty has joined #ocaml
OChameau has quit [Read error: 113 (No route to host)]
hardcoding has quit ["Leaving"]
jonafan_ is now known as jonafan
<mrvn>
Does the GC convert evaluated lazy values back to lazies when it compactifies?
<mfp>
back to lazy? wouldn't that be silly?
<mrvn>
would be nice to have for a cache module.
Snark has quit ["Ex-Chat"]
<mfp>
AFAIK what it does it replace the block with the forward_tag with the actual value
<mfp>
so there's no extra indirection needed in the next access
<mfp>
isn't Lazy.force guaranteed to force only once anyway? (in the absence of threads, I know it's not thread-safe)
kaustuv_ has quit [Remote closed the connection]
kaustuv_ has joined #ocaml
<Alpounet_>
have anybody seen some libraries for image/video analysis ? (I know there aren't for machine learning, btw :-()
jeanbon has quit ["Reconnecting"]
jeanbon has joined #ocaml
caligula has quit [Remote closed the connection]
caligula has joined #ocaml
jeanbon has quit [Client Quit]
mikeX has quit [calvino.freenode.net irc.freenode.net]
jamii_ has quit [calvino.freenode.net irc.freenode.net]
jedai has quit [calvino.freenode.net irc.freenode.net]
mrvn has quit [calvino.freenode.net irc.freenode.net]
holgr has quit [calvino.freenode.net irc.freenode.net]
ertai has quit [calvino.freenode.net irc.freenode.net]
catface has quit [calvino.freenode.net irc.freenode.net]
ygrek has quit [calvino.freenode.net irc.freenode.net]
tab__ has quit [calvino.freenode.net irc.freenode.net]
animist has quit [calvino.freenode.net irc.freenode.net]
smimou has quit [calvino.freenode.net irc.freenode.net]
Ori_B has quit [calvino.freenode.net irc.freenode.net]
maxote has quit [calvino.freenode.net irc.freenode.net]
vuln has joined #ocaml
ygrek has joined #ocaml
mikeX has joined #ocaml
jamii_ has joined #ocaml
tab__ has joined #ocaml
catface has joined #ocaml
animist has joined #ocaml
smimou has joined #ocaml
jedai has joined #ocaml
Ori_B has joined #ocaml
mrvn has joined #ocaml
ertai has joined #ocaml
holgr has joined #ocaml
maxote has joined #ocaml
jeanbon has joined #ocaml
vuln has quit [Client Quit]
jeanbon has quit [Client Quit]
jeanbon has joined #ocaml
<olegfink>
Alpounet_: I know there was some image spam bayesian filter in ocaml, but I don't know how far the project went.
<flux>
hmph, github may employ distributed technology, but the website itself remains a single point-of-failure.. (I'd like to take a look at that ocaml-raytracer's source!)
<mrvn>
I would think that the boxing of floats make it somewhat slow.
<mfp>
mrvn: they are unboxed in the vector type where a large part of the floating point ops happen
<mrvn>
ok, so you have a lot of Array.make 16 0.0 for your matrices.
<mfp>
the author used a float array for the (fixed size) 3D vector, instead of a record with 3 elms
<mrvn>
or would you use a 2D array?
<mrvn>
3D? 3D is more fun as you can do your perspective transformation easily in it.
<mfp>
I didn't see any matrix ops, it's just vectors
<mrvn>
4D I mean
<mfp>
mostly dot & cross product, and things like let ( +| ) v0 v1 = [| v0.(0) +. v1.(0); v0.(1) +. v1.(1); v0.(2) +. v1.(2) |]
<mrvn>
mfp: The algorithm I know uses matrix inversions to determine the points where a ray hits a surface.
<mfp>
(yes, I know, a record would be safer here & a bit faster because it'd monomorphize some functions, but I didn't want to rewrite all the code that accesses the components)
<mrvn>
but slower as it would box flotas
<mrvn>
or does ocaml convert a record of floats into a float taged block?
<mfp>
mrvn: the original code is here > http://www.hxa.name/minilight/ I haven't read all the code (let alone modified the algo), just removed some pitfalls
<mfp>
a record with only floats is unboxed
<mrvn>
does it have a gui or at least display a picture?
<mfp>
that is, the floats in a record with... is
<mfp>
just output a ppm
<mfp>
even Graphics should suffice to display something
<mrvn>
shouldn't be too hard to use the Graphics module.
<mfp>
val rgb : int -> int -> int -> color make_image : color array array -> image draw_image : image -> int -> int -> unit
<mfp>
that's about all it takes
<flux>
I'd like to use two-tuples for floating point coordinates, but sadly it's not efficient :)
<flux>
but the real problem is that it can never be optimized either, because it would break C interoperability..
<mrvn>
mfp: bah, set_color, plot. I want to watch it trace.
<mfp>
why 2-elm tuples instead of records, for easier pattern matching?
<flux>
mfp, yes
<flux>
and besides it seems more fitting to me. (x, y), what's more convenient than that!
<mrvn>
flux: If arrays and records of floats are special cased then why not tuples as well?
<flux>
mrvn, indeed
<flux>
one issue that leads from that is that when you have two libraries, they will likely have their own coordinate format
<flux>
so to interchange data you need to convert it first
<flux>
while if everyone just use 2-tuples it'd work more likely :)
<mfp>
mrvn: it uses a stochastic method for global illumination & performs many iterations
<flux>
or simply just when using another library with your own code, you might have a 2d point format before you integrate that library.
<mfp>
it'd have to be modified to put the inner loops inside out, so to speak
<flux>
and thus you always need to convert points back and forth, or alternatively, switch to the point format of the library
<flux>
perhaps a compiler-verified structural casting would fix those from the performance point of view
<kaustuv_>
ITYM "views"
<mfp>
Alpounet_: that manipulates/creates images, I thought you wanted image processing stuff like segmentation and such?
<flux>
(like: { foo_x : float; foo_y : float } could be safely casted to { bar_x : float; bar_y : float } ; sure, you can do it with Obj.magic, but..)
<mfp>
flux: I think the reason why tuples are not special cased is that they are not mutable
<flux>
mfp, what reason is that?
<Alpounet_>
mfp, that's what I want indeed.
<flux>
you just get double the allocation rate when doing things in immutable way when you have floats boxed :)
_andre has quit ["leaving"]
vuln has joined #ocaml
<Alpounet_>
But I didn't think there was a library for image processing
<mfp>
well, you probably want to be able to change your vector elements, so you're going to use records/arrays anyway
<kaustuv_>
mfp: what do you mean by not mutable? There is no difference between {a:int, b:float} and (int * float) at runtime.
<mfp>
yes, at runtime
<mfp>
but there is between {a : float; b : float} and (int * float)
<mfp>
I mean ... and (float * float)
<kaustuv_>
Yes, but mutability is not the reason, I think. Treating a record of floats as an array of floats is just a cheap optimisation.
<flux>
I wonder what's the point in _not_ optimizing float * float, other than C interface compatibility issues
<mfp>
and the reason for not bothering to unbox the latter I can see is that the language doesn't allow to change the tuples
<mfp>
ah I see
<mfp>
because float records are monomorphic
<mrvn>
mfp: what does that change? Makes no difference. (float*float) could just as well be a float block of size 2.
<mfp>
this would force the compiler to check whether the tuple is a "float only" one or not
<mfp>
the same way it does for unboxed float arrays
<mrvn>
as it does for records and arrays
<mfp>
not for records
<mfp>
they are only unboxed if monomorphic IIRC
<mfp>
-> this would make all tuple deconstructing slower
<mfp>
even though tuples are arguably a bad choice for any numerical stuff (since non-mutable at the lang level)
<mrvn>
mfp: you mean for something like let first 'a. 'b. ('a, 'b) -> 'a = function (x, y) -> x?
<mfp>
yes
<mrvn>
What about Array.get x 0?
<mfp>
any pattern matching over tuples would become slower
<mfp>
it does test whether it's a float array or not, in general
<mfp>
(unless it's positive it isn't)
<mrvn>
is the cross module inlining smart enough to eliminate those tests?
<kaustuv_>
This is slow?: let fst x = if Obj.tag (Obj.repr x) == Obj.double_array_tag then floatpair_fst x else poly_fst x
<mfp>
mrvn: I don't think so, as OCaml doesn't monomorphize
<mfp>
kaustuv: yes, slower than just getting the 1st elm
<kaustuv_>
maybe the bigger issue is that in an unboxed pair p, fst p != fst p.
<mfp>
that's also the case with a.(0), isn't it?
<mrvn>
Earlier today we found out that Node(Empty, 0, Empty) == Node(Empty, 0, Empty) even when constructed via a function
<kaustuv_>
... but only if the expression occurs in the same function, it turns out.
<Alpounet_>
fst p = fst p returns true sometimes
<mrvn>
== is a tricky thing
<Alpounet_>
depends on how p is given value
<mrvn>
mfp: Next on the ToDo: Write a radiosity algorithm and then real time fligh through with GL.
<Alpounet_>
that would be great
<Alpounet_>
I would beta test it heh :-)
<mrvn>
Would give me a reason to try to get 3D support running again.
<mfp>
mrvn: tell the orig author :) all I did was cleaning up the code (removing the ugliest bits, but still quite unidiomatic)
<mrvn>
mfp: radiosity is a tinsy tiny bit different to raytracing. :)
<mrvn>
In raytracing you go from your camera and cast rays at the objects till you hit some light source. In radiosity you basically do the reverse. You throw out a ton of photons from the light source, bounce them around is see if any hit the camera. :)
<mrvn>
For it to work before the sun goes dark you make every surface a light source that glows as much as it recieves light from other surfaces modulated by its color and reflectivity. And then you iterate till there isn't much change anymore.
<flux>
isn't that called path tracing or photon tracing?
<flux>
while radiosity can be performed with other tricks
jeanbon has quit ["J'y trouve un goût d'pomme."]
<mrvn>
path tracing/photon tracing is when you actualy do it by paths.
<flux>
hm, actually I think you just listed the trick :)
<flux>
but there doesn't need to be that many photons you throw out
<mrvn>
Path tracing is somewhat a mixture of raytracing and radiosity.
<mrvn>
flux: In each iteration you have to calculate the lightflow from each surface to every other surface. And you have to subdivide larger surfaces into small enough chunks first.
<mfp>
mrvn: the details of the algo used are explained at http://www.hxa.name/minilight/ turns out it actually does path tracing (monte-carlo path tracing with emitter sampling)
<mrvn>
In the end you get a texture for every surface. The neat thing is that after the initial huge computation you can view the scene from any angle.
<mrvn>
But back to being on-topic: Can I write a functor or something to transform an unknown module signature: module type MAny = sig ... end module Any = functor (M : MAny) -> struct type t = { v : M.t val } ''x = v.M.x end for any x in M?
<mrvn>
And is there a shorter way to write (fun x -> x#foo)?
seafood has joined #ocaml
smimou has quit [Read error: 104 (Connection reset by peer)]
<mfp>
mrvn: sounds like code generation with camlp4
<mfp>
in both cases, actually
<mrvn>
It is too bad you can
<mrvn>
't write class Foo ... Foo#bar
Yoric[DT] has joined #ocaml
<Alpounet_>
Good night all.
Alpounet_ has quit ["Ex-Chat"]
* palomer
kicks lablgtk2 and bad columns!
smimou has joined #ocaml
seafood has quit []
komar_ has quit [Remote closed the connection]
Camarade_Tux has quit ["Leaving"]
thelema_ has joined #ocaml
maxote has quit [Read error: 104 (Connection reset by peer)]
maxote has joined #ocaml
caligula_ has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
caligula has quit [Read error: 110 (Connection timed out)]
maxote has quit [Read error: 110 (Connection timed out)]
maxote has joined #ocaml
seafood has joined #ocaml
ygrek has quit [Remote closed the connection]
<palomer>
is it possible to install ocaml without root access?
<palomer>
ie. install ocaml + libraries in your home folder
Yoric[DT] has quit ["Ex-Chat"]
<palomer>
hrmph
<palomer>
my school admins are refusing to install ocaml in the public labs
hkBst has quit [Read error: 104 (Connection reset by peer)]