_unK has quit [kubrick.freenode.net irc.freenode.net]
mal`` has quit [kubrick.freenode.net irc.freenode.net]
Alpounet has quit [kubrick.freenode.net irc.freenode.net]
bzzbzz has quit [kubrick.freenode.net irc.freenode.net]
diml has quit [kubrick.freenode.net irc.freenode.net]
[df] has quit [kubrick.freenode.net irc.freenode.net]
[df]_ has joined #ocaml
bzzbzz has joined #ocaml
mal`` has joined #ocaml
Alpounet has joined #ocaml
diml has joined #ocaml
_unK has joined #ocaml
pimmhogeling has quit [Read error: 110 (Connection timed out)]
tmaedaZ is now known as tmaeda
tmaeda is now known as tmaedaZ
jeddhaberstro has quit [Client Quit]
* thelema
is impressed by bluestorm
<julm>
why?
<thelema>
he found the bug reported in batteries, tracked it to a problem in camlp4 and has a quite well written bug report in ocaml's bug tracker, as well as a response to the person who found the batteries bug in our bugtracker
<julm>
:)
<thelema>
it makes me feel good about that code - that it'll be very well maintained.
<palomer>
so...any chance of oset making it in batteries :P?
<yakischloba>
what is the reason for something external like batteries instead of having these things in the core language? they are considered extraneous or not robust or what?..
<yakischloba>
in stdlib i guess rather is the right term
<julm>
ocaml's upstream is not accessible by mere mortals
<yakischloba>
is that just an assumed attitude or have people actually made a good effort?
<julm>
some efforts on the mailing-list, and on the bug-tracker, yep
<thelema>
yakischloba: more or less what julm said - ocaml's gods have made it clear that they don't want to maintain a large stdlib
<yakischloba>
it sucks to think that it'll stagnate while people that are actually doing stuff with it are having to maintain their own stdlibs
<yakischloba>
its hard enough for newcomers to figure out as it is
<thelema>
palomer: huh? how is oset at all appropriate for batteries?
<thelema>
yakischloba: It's possible to have a community set of addons that everyone installs with ocaml.
<thelema>
the ocaml gods like this idea
tmaedaZ is now known as tmaeda
<yakischloba>
and is batteries the only one or are people putting efforts to different places?
<thelema>
There is one other sorta competitor - jane street's core
<palomer>
thelema, I was (half) kidding
<yakischloba>
and what are the differences?
<thelema>
They've had it for a long time internally. Batteries will take the good bits of it and leave the rest.
<palomer>
thelema, it generates structure editors based on datatype definitions (generically)
<thelema>
core is... definitely more consistent than batteries. Very integrated with the other Jane Street libraries (binprot, sexplib, etc)
<thelema>
palomer: yes, I kinda remember. I don't see much general purpose in that.
<thelema>
core also does a ton of argument labeling, which I'm thinking about taking into batteries
tmaeda is now known as tmaedaZ
struktured is now known as structured
<thelema>
core also seems to be about lower level library tools, vs. batteries working at nicer syntax and high-level constructs
structured is now known as struktured
thrasibule has joined #ocaml
rhar has quit [Read error: 110 (Connection timed out)]
Drk-Sd has quit [Client Quit]
struktured has quit [Remote closed the connection]
<tensorpudding>
is the int type a standard machine int like in C or is it unbounded?
<palomer>
bounded
<palomer>
smaller than the C one
<tensorpudding>
hmm
<tensorpudding>
so what can i do to represent large integers?
<flux>
rwmjones, btw, ocaml-bitstring used to be inconvenient for writing paresr that would read more data on-demand. has that been improved?
<rwmjones>
but there are still plenty of errors in it
<rwmjones>
flux, no you still have to read everything in
<flux>
rwmjones, bah :)
<thelema>
rwmjones: fun
alp has joined #ocaml
Alpounet has quit [Read error: 104 (Connection reset by peer)]
ikaros has joined #ocaml
boscop has joined #ocaml
joewilliams_away is now known as joewilliams
thelema has quit [Read error: 110 (Connection timed out)]
eldragon has joined #ocaml
inkbottle has joined #ocaml
ulfdoz_ has joined #ocaml
julm has quit [Remote closed the connection]
julm has joined #ocaml
ulfdoz has quit [Read error: 110 (Connection timed out)]
chicco has joined #ocaml
avsm1 has joined #ocaml
thelema has joined #ocaml
_unK has joined #ocaml
Modius has quit [Read error: 110 (Connection timed out)]
Modius has joined #ocaml
avsm has quit [Read error: 110 (Connection timed out)]
mfp has quit ["Leaving"]
ikaros has quit ["Leave the magic to Houdini"]
pimmhogeling has quit [Read error: 110 (Connection timed out)]
pimmhogeling has joined #ocaml
komar_ has joined #ocaml
komar_ has left #ocaml []
rwmjones has quit [Read error: 104 (Connection reset by peer)]
rwmjones_lptp has joined #ocaml
ikaros has joined #ocaml
rwmjones_lptp is now known as rwmjones
fx_ has quit [Read error: 110 (Connection timed out)]
yakischloba has joined #ocaml
ccasin has joined #ocaml
_unK has quit [Remote closed the connection]
yziquel has joined #ocaml
<yziquel>
hi. i'm having the following C typedef that i want to wrap up. Depending on the arch, i have 'typedef size_t oid;' or 'typedef unsigned int oid;'. What's the proper way to wrap such an value into ocaml?
<mrvn>
yziquel: fix your broken code
<yziquel>
mrvn: why?
<mrvn>
Because if you need a size_t then use size_t. If you need 32bit then use int32_t. And if you need something that can hold a pointer use intptr_t.
<yziquel>
mrvn: i'll ask the authors of what i'm trying to wrap. suppose it's a size_t. how do you wrap it up?
avsm1 has quit [Read error: 110 (Connection timed out)]
<yziquel>
mrvn: custom block with sizeof(size_t)?
Submarine has joined #ocaml
<mrvn>
malloc() one, define an abstract type and use the pointer. Or, and safer usualy, a custom block.
<yziquel>
mrvn: ok. thanks.
<mrvn>
type oid = private Int32.t might work too if it is actualy 32bit.
ttamttam has quit ["Leaving."]
ulfdoz_ has quit [Client Quit]
ulfdoz has joined #ocaml
_zack has quit ["Leaving."]
ygrek has joined #ocaml
inkbottle has quit ["Leaving"]
rulo has joined #ocaml
tmaeda is now known as tmaedaZ
rwmjones has quit ["This computer has gone to sleep"]
<yziquel>
mrvn: no, it's 32 or 64 bits depending on compilation flags... cannot know. what's the 'private' keyword for, btw?
<mrvn>
yziquel: prevents anything outside your module from creating a value of that type while still telling the compiler what the type actually is so it can optimize access to it.
<mrvn>
Basically makes it read only.
<yziquel>
mrvn: the point is that i'd like to wraè it up in a more lightweight structure than a custom block... Some caml_alloc_small would be nice, but I need to know the size beforehand...
<mrvn>
Will it ever be 64bit on 32bit archs?
<yziquel>
could.
<mrvn>
Then you can't put it into a value. You need a pointer to it that is outside the heap or a custom block.
Yoric has quit []
<mrvn>
And the pointer must remain outside the heap as long as any ocaml code has a copy of the oid + the time the GC needs to free it. That is the dangerous part as the GC can allocate new heaps and suddenly an old pointer points to inside the heap.
_zack has joined #ocaml
<mrvn>
yziquel: What you probably want is an abstract block. See 18.2.3 in the manual.
<mrvn>
caml_alloc(1, Abstract_tag) or caml_alloc(2, Abstract_tag) and then store the oid in there.
<mrvn>
Me I would go with private Int32.t or private Int64.t depending on how your lib is compiled.
<yziquel>
mrvn: Highest bit cleared always. Thus, oids are 31-bit numbers on 32-bit systems, and 63-bit numbers on 64-bit systems.
<yziquel>
mrvn: from the documentation...
<mrvn>
yziquel: then an ocaml int would work.
<mrvn>
type oid = private int
<yziquel>
mrvn: cool. because this is a high speed stuff, and I'd hate an extra level of indirection, plus a malloc, plus a finalizer calling free...
<mrvn>
You might have to mask out the highest bit when converting from ocaml value to C though as ocaml only has signed int and I bet they sign extend in the macro.
mihamina has quit ["Leaving."]
derdon has joined #ocaml
rulo has quit ["leaving"]
pad has joined #ocaml
yziquel has quit [Ping timeout: 180 seconds]
ttamttam has joined #ocaml
rhar has joined #ocaml
_unK has joined #ocaml
_andre has quit ["leaving"]
Submarine has quit ["Leaving"]
gdmfsob has joined #ocaml
bzzbzz_ has joined #ocaml
TaXules has quit [Read error: 54 (Connection reset by peer)]
ikaros has quit ["Leave the magic to Houdini"]
_zack has quit ["Leaving."]
ttamttam has quit ["Leaving."]
ccasin has quit ["Leaving"]
avsm has joined #ocaml
avsm has quit [Client Quit]
itewsh has joined #ocaml
bzzbzz_ has quit [Client Quit]
ikaros has joined #ocaml
Drk-Sd has joined #ocaml
djanderson has joined #ocaml
palomer has quit ["Leaving"]
ygrek has quit [Remote closed the connection]
itewsh has quit [Client Quit]
avsm has joined #ocaml
Drk-Sd has quit [Client Quit]
hyperboreean has joined #ocaml
derdon has quit []
yziquel has joined #ocaml
gdmfsob has quit [Read error: 110 (Connection timed out)]
<yziquel>
how kosher is this: #define Val_ptr(p) ((value) (((uintnat) p) ^ 1)) and #define Ptr_val(v) ((void *) (((uintnat) v) ^ 1))
<mrvn>
not at all.
<yziquel>
what's the issue? to the GC, it's just an integer, for something outside the ocaml heap. And hopefully more efficient than abstract blocks. what could be the problem?
<yziquel>
mrvn: typedef intnat value; but yes, should.
<mrvn>
#define my_Val_oid(x) (Val_int(x))
<mrvn>
The reverse needs custom code
<yziquel>
mrvn: no. oid can be 32 bits, while intnat may be 64 bits.
<yziquel>
hmm, not sure...
<mrvn>
yziquel: you said it is 31bit on 32bit cpus and 63bit on 64bit cpus.
<yziquel>
mrvn: yes, but it *can* be 31 bits on 64 bit cpus.
<yziquel>
mrvn: if you compile what i'm trying with perverse flags.
<mrvn>
then you have some top bits 0, big deal.
<mrvn>
As long as it never is 63 bits on 32bit cpus that is ok
<yziquel>
mrvn: about the 0s, i was just wondering if cast from 32 unsigned to 64 signed, well...
<yziquel>
wasn't so sure about the 0s. couldn't it be top bits of 1?
<mrvn>
yziquel: first cast to unsigned of the same type, then cast to smaller/different type
<mrvn>
uint32_t -> int64_t will not sign extend.
<yziquel>
ok.
<mrvn>
Not sure what int32_t -> uint64_t would do
<mrvn>
yziquel: But (oid)(Int_val(x)) will sign extend in Int_val.
mfp has joined #ocaml
<mrvn>
yziquel: For that you need to cast to unsigned before shifting the tag bit away.
<yziquel>
mrvn: i did (((oid) x) >> 1)
<yziquel>
so casting to 32 bits unsigned before shifting. thanks.
<mrvn>
that will do since oid is unsigned.
<mrvn>
And it will do for 63bit and 31bit
<yziquel>
yep
<mrvn>
yziquel: If you wrap pointers I usualy find that you need to free them at some point again and then a custom block with finalizer is really neat.
<yziquel>
mrvn: sure, but it's not the case. As a matter of fact, it depends if there is a clean finaliser possible... not always the case.
<mrvn>
the alternative is an abstract block
<mrvn>
or your int trick if the pointer is aligned
<yziquel>
mrvn: that's what i was trying to move away from...
<yziquel>
mrvn: how can i know if the pointer is aligned or not?
<mrvn>
if it isn't a char pointer then assume it is aligned
<yziquel>
mrvn: because that would be mighty useful in my situation.
<yziquel>
mrvn: "assume"... up to which point?
<mrvn>
as in it doesn't give an bus error on various archs or an alignment trap or is slow on x86/amd64.
<mrvn>
An unaligned pointer would be broken code
<mrvn>
yziquel: put an assert in there and test if you are unsure