emmanuel__ has quit [Read error: Connection reset by peer]
letrec has quit [Ping timeout: 248 seconds]
cdidd has quit [Remote host closed the connection]
<thelema>
mrvn: I use this for whitespace: (add-hook 'before-save-hook 'delete-trailing-whitespace)
iago has quit [Quit: Leaving]
lamawithonel_ has quit []
lihaitao has joined #ocaml
oriba has quit [Quit: oriba]
Tobu has quit [Ping timeout: 272 seconds]
Tobu has joined #ocaml
eni has joined #ocaml
eni has quit [Client Quit]
ftrvxmtrx has joined #ocaml
michael-alex has joined #ocaml
ulfdoz has quit [Ping timeout: 245 seconds]
caligula_ has joined #ocaml
deavidsedice has joined #ocaml
adrien_ has joined #ocaml
hcarty_ has joined #ocaml
testcoco` has joined #ocaml
testcocoon has quit [*.net *.split]
alxbl has quit [*.net *.split]
deavid has quit [*.net *.split]
fooc has quit [*.net *.split]
bobry has quit [*.net *.split]
adrien has quit [*.net *.split]
ocp has quit [*.net *.split]
mfp has quit [*.net *.split]
Fnar has quit [*.net *.split]
haelix has quit [*.net *.split]
lorilan has quit [*.net *.split]
Derander_ has quit [*.net *.split]
tlockney has quit [*.net *.split]
joewilliams has quit [*.net *.split]
othiym23 has quit [*.net *.split]
noamsml has quit [*.net *.split]
pou has quit [*.net *.split]
ousado has quit [*.net *.split]
dsheets has quit [*.net *.split]
caligula has quit [*.net *.split]
maufred has quit [*.net *.split]
tomprince has quit [*.net *.split]
hcarty has quit [*.net *.split]
gnuvince has quit [*.net *.split]
TDJACR has quit [*.net *.split]
NaCl has quit [*.net *.split]
ski has quit [*.net *.split]
rixed has quit [*.net *.split]
chambart has quit [*.net *.split]
gildor_ has quit [*.net *.split]
companion_cube has quit [*.net *.split]
`micro has quit [*.net *.split]
IbnFirnas has quit [*.net *.split]
BiDOrD has quit [*.net *.split]
patronus has quit [*.net *.split]
srcerer has quit [*.net *.split]
j2d2j2d2 has quit [*.net *.split]
nimred has quit [*.net *.split]
ccasin has quit [*.net *.split]
jonafan has quit [*.net *.split]
maufred has joined #ocaml
gnuvince has joined #ocaml
lorilan has joined #ocaml
ocp has joined #ocaml
alxbl has joined #ocaml
BiDOrD has joined #ocaml
TDJACR has joined #ocaml
NaCl has joined #ocaml
mfp has joined #ocaml
Fnar has joined #ocaml
ski has joined #ocaml
rixed has joined #ocaml
haelix has joined #ocaml
chambart has joined #ocaml
patronus has joined #ocaml
Derander_ has joined #ocaml
gildor_ has joined #ocaml
dsheets has joined #ocaml
tlockney has joined #ocaml
companion_cube has joined #ocaml
fooc has joined #ocaml
srcerer has joined #ocaml
ousado has joined #ocaml
pou has joined #ocaml
noamsml has joined #ocaml
othiym23 has joined #ocaml
joewilliams has joined #ocaml
`micro has joined #ocaml
j2d2j2d2 has joined #ocaml
bobry has joined #ocaml
IbnFirnas has joined #ocaml
nimred has joined #ocaml
ccasin has joined #ocaml
jonafan has joined #ocaml
adrien_ is now known as Guest45975
srcerer has quit [Ping timeout: 245 seconds]
tomprince has joined #ocaml
testcoco` has quit [Quit: Coyote finally caught me]
testcocoon has joined #ocaml
testcocoon has quit [Quit: Coyote finally caught me]
testcocoon has joined #ocaml
ankit9 has joined #ocaml
mononofu has joined #ocaml
Guest45975 is now known as adrien
eni has joined #ocaml
pango has quit [Remote host closed the connection]
pango has joined #ocaml
roha has joined #ocaml
ggherdov has joined #ocaml
larhat has joined #ocaml
Tobu has quit [Ping timeout: 272 seconds]
eni has quit [Ping timeout: 250 seconds]
Tobu has joined #ocaml
eni has joined #ocaml
larhat has quit [Ping timeout: 244 seconds]
larhat has joined #ocaml
rly has joined #ocaml
<rly>
Is it easy to create a C compatible library on Linux with OCaml?
<rly>
I want the OCaml code to be called from a C environment.
larhat has quit [Ping timeout: 272 seconds]
<mrvn>
yes, see the manual
larhat has joined #ocaml
<rly>
mrvn: I also want to create the equivalent of a particular C struct in OCaml. Is that also possible? So, more than primitive types.
<rly>
mrvn: are there any tools that help with building such libraries?
<mrvn>
equialent sure
michael-alex has quit [Ping timeout: 260 seconds]
michael-alex has joined #ocaml
Tobu has quit [Ping timeout: 272 seconds]
Tobu has joined #ocaml
<rly>
mrvn: (by equivalent I mean one that is bit by bit the same as what GCC would produce.) So, perhaps exactly the same would be a better characterization.
<mrvn>
you can make a C struct available to ocaml but then you need to provide C stubs to access its contents.
tufisi has joined #ocaml
<mrvn>
or you can copy the contents between a C struct and ocaml data type every time it crosses the boundary
avsm has quit [Quit: Leaving.]
<rly>
mrvn: no, I want to provide something to a C library which accepts only something like struct foo{int x; char [20] y; }.
<rly>
mrvn: if I have to do extra conversions manually on the C side, then there is no point in using OCaml.
eni has quit [Quit: Leaving]
<rly>
mrvn: think for example of plugin development.
<rly>
er char y[20];
<mrvn>
rly: you would do the conversions on the C side but inside your lib. You do need some glue code between ocaml and C, there is no way around that.
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
<rly>
mrvn: sure there is a way around that.
<rly>
mrvn: some domain specific language could be used to do alignment, etc.
<rly>
mrvn: in fact, in Haskell I think this is already possible.
<mrvn>
No way around playing nice with the GC.
<rly>
mrvn: I wouldn't mind for copies being sent.
lpereira has joined #ocaml
<rly>
mrvn: which means there is no GC interaction needed.
<mrvn>
rly: and who would send copies? Bingo, your glue code.
<rly>
mrvn: yes, but why can't the glue code be in OCaml?
<mrvn>
if ocaml could safely do that then you wouldn't need it
<rly>
mrvn: in Haskell such tools do exist.
<rly>
I think it just means that they don't want people to use OCaml.
<rly>
If they would, there would be means of playing with the rest of the world.
<mrvn>
try ocamlidl or something. But you will still need to write some glue stuff.
<rly>
mrvn: I think you don't understand: I want to create a struct exactly matching some C struct as gcc would expect it.
<rly>
mrvn: is there any library which already does this such that I can see whether it is semi-acceptable?
<mrvn>
I don't know of any C library that uses ocaml internaly but the manual covers it.
larhat has quit [Ping timeout: 248 seconds]
larhat has joined #ocaml
avsm has joined #ocaml
pango is now known as pangoafk
avsm has quit [Client Quit]
alxbl has quit [*.net *.split]
fooc has quit [*.net *.split]
bobry has quit [*.net *.split]
alxbl has joined #ocaml
Submarine has quit [Read error: Operation timed out]
cdidd has joined #ocaml
roha has quit [Remote host closed the connection]
roha has joined #ocaml
Submarine has joined #ocaml
iago has joined #ocaml
Hussaind has joined #ocaml
michael-alex has quit [Remote host closed the connection]
mononofu has quit [Remote host closed the connection]
lihaitao has quit [Ping timeout: 272 seconds]
ankit9 has quit [Ping timeout: 260 seconds]
fooc has joined #ocaml
bobry has joined #ocaml
ankit9 has joined #ocaml
Cyanure has joined #ocaml
BiDOrD_ has joined #ocaml
BiDOrD has quit [Ping timeout: 245 seconds]
joelr has joined #ocaml
dgfitch_ has quit [Ping timeout: 252 seconds]
dgfitch has joined #ocaml
_andre has joined #ocaml
joelr has quit [Quit: joelr]
roha has quit [Ping timeout: 260 seconds]
roha has joined #ocaml
Hussaind has quit [Remote host closed the connection]
Hussaind has joined #ocaml
Hussaind has left #ocaml []
hiptobecubic has joined #ocaml
Submarine_ has joined #ocaml
Submarine has quit [Ping timeout: 245 seconds]
Tobu has quit [Remote host closed the connection]
Tobu has joined #ocaml
untroubled has joined #ocaml
roha has quit [Ping timeout: 252 seconds]
letrec has joined #ocaml
snearch has joined #ocaml
eni has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
roha has joined #ocaml
roha has quit [Client Quit]
roha has joined #ocaml
everyonemines has joined #ocaml
mononofu has joined #ocaml
iago has quit [Ping timeout: 272 seconds]
avsm has joined #ocaml
everyonemines has quit [Quit: Leaving.]
letrec has quit [Quit: Konversation terminated!]
letrec has joined #ocaml
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
mononofu has quit [Remote host closed the connection]
ankit9 has quit [Quit: Leaving]
hcarty_ is now known as hcarty
<hcarty>
rly: I don't think that there has been enough demand for completely automated C bindings from OCaml. There are a number of tools and libraries to help with the process, but nothing that is 100% automated.
<pippijn>
hcarty: why not?
<hcarty>
pippijn: Why not what?
<pippijn>
why is there not much demand for it?
<f[x]>
camlidl comes close - but nobody uses it anyway
<hcarty>
pippijn: There are a limited number of C libraries that people need. People have generally wrapped the ones they need by hand, or with some assistance from something like camlidl.
<hcarty>
f[x]: I've used camlidl a few times, but I'm trying to move away from it. At least as build-time dependency.
<pippijn>
consider libpurple
<hcarty>
pippijn: ciml provides some camlp4 magic to make writing bindings a bit cleaner. camlidl automates part of the process if header files are setup properly. swig can produce ugly bindings.
lpereira has quit [Remote host closed the connection]
<hcarty>
pippijn: adrien has written some tools as well, but I don't know what state they are in.
<pippijn>
maybe I'll write some
<hcarty>
pippijn: Do!
<pippijn>
after I gather experience with the C interface
<hcarty>
It certainly wouldn't hurt to have a nice, up-to-date tool for (mostly) automating the generation of clean C bindings.
<pippijn>
generation of clean C bindings needs experience
<pippijn>
knowledge
<hcarty>
camlidl isn't actually that bad for simple interfaces. But it's old and not well supported by modern tools.
<hcarty>
pippijn: That's true
<hcarty>
pippijn: Something that an automated tool generally doesn't have
<pippijn>
right
<pippijn>
but you can aid them
<pippijn>
and the goal is to have a tool that does as much as possible with as few annotations as possible
<pippijn>
and the annotations should be enough to automate the entire process
Anonyme23296 has joined #ocaml
<hcarty>
pippijn: ciml does a bit of that, and camlidl does a lot of it
<hcarty>
pippijn: camlidl does a reasonably good job for the areas it covers
iago has joined #ocaml
gnuvince has quit [Ping timeout: 250 seconds]
<pippijn>
is there a menhir repository?
<rwmjones>
any gmp users around? Is it permitted to reuse a parameter for the return value, eg. Mpz.add a a b
smondet has joined #ocaml
<pippijn>
source repository that is
gnuvince has joined #ocaml
<hcarty>
diml: How reliable is the timing of Lwt_unix.sleep?
<hcarty>
pippijn: That's what I expect. I'd be curious to know how much that article applies to Lwt-type threads.
<pippijn>
hcarty: probably even more, because there is no preemption
<hcarty>
The memory use arguments don't really apply, but I wouldn't be surprised if the general idea of 'sleep implies flawed logic' applies.
<hcarty>
pippijn: Perhaps. But sleeping doesn't block other threads and (I think) can be canceled safely.
gnuvince has quit [Ping timeout: 244 seconds]
gnuvince has joined #ocaml
snearch has quit [Quit: Verlassend]
<flux>
I didn't bother reading the article, but I think the general idea behind sleeping being bad is that it implies some sort of polling
<flux>
or some work being left behind
<flux>
ie. sleep 5 seconds and if that comes up, issue a cancel. but if the task has already been cancelled, you're just cancelling it for nothing. rather you should wait for at most 5 seconds until the task is cancelled, etc
<flux>
probably too many applications have approaches like "check is condition X true, if not, sleep some time, check again"
<flux>
and the sleep is there just because otherwise it would be busylooping
<flux>
and how to pick a proper timeout for that kind of operation? it's the matter of choosing how late your application can react.
<flux>
of course, a better solution would be to react on the condition it is waiting for and otherwise never do work
<flux>
that can be difficult to perfectly achieve, though.. waking only when some subcondition has changed can be better but it can also be worse.
avsm1 has joined #ocaml
avsm has quit [Read error: Connection reset by peer]
Anarchos has joined #ocaml
err404 has joined #ocaml
avsm1 has quit [Quit: Leaving.]
Plex- has left #ocaml []
eni has quit [Ping timeout: 245 seconds]
Tobu has quit [Ping timeout: 272 seconds]
emmanuelux has joined #ocaml
larhat has quit [Quit: Leaving.]
Tobu has joined #ocaml
Submarine_ has quit [Quit: Leaving]
letrec has quit [Ping timeout: 252 seconds]
Cyanure has quit [Remote host closed the connection]
mononofu has joined #ocaml
Tobu has quit [Ping timeout: 272 seconds]
iago has quit [Read error: Operation timed out]
iago has joined #ocaml
<hcarty>
flux: That's part of the situation I'm in. I want to wait approximately n seconds before checking on a condition again, OR wait until some event arrives which may change the result of the checked condition.
mononofu has quit [Remote host closed the connection]
<hcarty>
flux: The source being checked (a task pool) is unaware of the process(es) doing the checking (workers who perform tasks)
<jonafan>
if you haven't played fallout 3, you probably don't know what this is
<jonafan>
this is easily the most incomprehensible js file i've ever created
bzzbzz_ has joined #ocaml
jbapple1 has left #ocaml []
bzzbzz has quit [Ping timeout: 248 seconds]
<adrien>
hcarty: would the task pool be able to send events over a file descriptor?
<adrien>
you wouldn't select() yourself on that fd but pretty much any library that handles events can listen on fds
<adrien>
listen/wait
lihaitao has quit [Quit: Ex-Chat]
avsm has joined #ocaml
<hcarty>
adrien: It is sent using zeromq, so the receipt of a task by a worker is event driven
<hcarty>
adrien: But some tasks need to be sent at specific times so I am looking for a clean way to implement that piece.
<adrien>
what all libraries seem to do: select (or similar) on file descrs; it's almost certainly provided and understood by the libraries you use
<hcarty>
adrien: That part works. Lwt and zeromq play nicely together that way.
<hcarty>
The part I'm unsure of is how to tell Lwt "wake this thread up and execute it at HH:MM:SS"
snearch has joined #ocaml
Tobu has joined #ocaml
<hcarty>
adrien: Once that part is done, Lwt can use the file descriptor provided by zeromq to do its select/polling
roha has quit [Read error: Operation timed out]
joelr has joined #ocaml
<joelr>
moin
<joelr>
is it sensible to cache the closure returned from caml_named_value if the lookup is being done several times a second?
<hcarty>
joelr: I think the example in the manual does some basic caching/validity checking
<hcarty>
joelr: If it doesn't there, then I may be thinking of one of the other OCaml/C tutorials
<joelr>
grr
<joelr>
stupid question, the manual says yes :D
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
hiptobecubic has quit [Read error: Operation timed out]
avsm has quit [Quit: Leaving.]
iago has quit [Quit: Leaving]
bobzhang has joined #ocaml
<mrvn>
The problem with bindings is that all those are only "mostly" automatic. And they can never be fully automatic. The C language simply leaves too much information out and relies on the programmer to use a library right. Most importantly returned pointers. Are they to be freed by the application or not?
<adrien>
annotations work, but they need to be good enough
<thelema>
mrvn: sure, I'm not suggesting a solution that covers 100% of cases perfectly, just one that covers 80% of cases correctly
<adrien>
go explain to someone who does C and python that he should put enough annotations for you to be able to have strong static types
<adrien>
and it's library-dependant
pangoafk is now known as pango
<thelema>
Anything that's not basically a primitive value in both C and OCaml can be left to other solutions
<mrvn>
thelema: that throws out pretty much every single library since they all have pointers.
<thelema>
but functions that take ints/floats as parameters and return an int or float should not require writing wrappers
<mrvn>
And then there is error handling with errno and such
<mrvn>
thelema: floats are not primitive in ocaml
<mrvn>
but automatable
<pippijn>
mrvn: getting the calling conventions right is a big step
<thelema>
mrvn: you're right about pointers, they're trouble.
<pippijn>
once you have all the functions callable from ocaml and struct fields accessible, you can do the rest from there
<adrien>
thelema: but int and floats are very easy to deal with
<mrvn>
pippijn: you can wrap every C value in a custom block an provide access functions for structs and enums and alloc/free functions. But then you loose a lot.
<pippijn>
what do you lose?
<thelema>
adrien: yes, writing stubs for them is dumb enough to be automatable, which is exactly what I'm suggesting
<adrien>
pippijn: if you ever think of using libffi or similar to get runtime bindings, try something else
<mrvn>
thelema: The thing is the C stub you need to write for functions on ints is so trivial it isn't worth the automation tool.
<thelema>
mrvn: if the C side has such access functions, great.
<thelema>
mrvn: you're sure there's no worth to having all the Int_val / Val_int conversions automated?
<mrvn>
thelema: I mean for a struct foo { int x; int y; } you write type foo external foo_x ... external foo_y ... external free_foo ....
<mrvn>
thelema: compared to the work for complexer functions the few pure int functions are negible usualy.
<pippijn>
I'm thinking about the ncurses bindings
<adrien>
what I see that is working is lablgtk; ML_2(add, Int_val, Int_val, Val_int) and external add : int -> int -> int = "ml_add"
<pippijn>
the ocaml ncurses bindings are a huge mess of incomprehensible macros
<mrvn>
Imho a lot of work for bindings also goes into thinking how to map the C API to something ocaml-ish.
<pippijn>
mrvn: you can do that once it's actually in ocaml
<mrvn>
pippijn: like camlidl that copies everything around x times? No thank you.
<pippijn>
the high level wrappers are still up to the programmer, but not having to deal with the low level FFI is good, I think
<pippijn>
copies?
<adrien>
well, you better do something low-level and simple for the bindings and then add another layer that gives a better API, but you also need the bindings to not be awful
bobzhang has quit [Read error: Connection reset by peer]
bobzhang has joined #ocaml
<mrvn>
pippijn: that was my impression from camlidl. You get multiple stubs between ocaml and the C functions and stuff gets copied into temporary structures by one stub and out of them again by the other.
<pippijn>
is that necessary?
<mrvn>
I don't know. I gave up on camlidl after that and just wrote the 4 bindings I needed manually.
<pippijn>
maybe because I come from a world where computers are not infinitely fast and program execution time matters
<adrien>
CIL and your parser do not do the same things
<pippijn>
adrien: at first, they do
<pippijn>
they parse C
<pippijn>
then, CIL does some other stuff as well
<pippijn>
but CIL can't even complete the parsing step
<adrien>
what if it needs more info at parsing-time?
<adrien>
I don't think the outputs of your parser and CIL's are equivalent
<pippijn>
maybe not exactly
<pippijn>
but largely
<pippijn>
I don't know how precisely CIL keeps track of source positions
<pippijn>
I don't keep track of them in types, but otherwise I can reconstruct the source pretty well
<pippijn>
and attributes are collapsed, so that's also ugly
<pippijn>
adrien: I think it's just some inefficiency.. it's not OK for any parser to take hours on a file that GCC compiles in 0.3 seconds
<pippijn>
where hours means "more than 20 minutes" :)
<adrien>
oh, I never said CIL was perfect, but I also think it's definitely going slower than your parser (and it would have a right to be much slower)
<adrien>
yacfe is not very fast either
<pippijn>
yacfe has a completely different goal
<adrien>
yup
<pippijn>
an interesting goal, but not in the area I want to go
jamii has joined #ocaml
Fnar has quit [Ping timeout: 276 seconds]
<adrien>
I use it for automated bindings
<pippijn>
yacfe?
<pippijn>
do you generate bindings for macros, too?
Fnar has joined #ocaml
<adrien>
you can't bind macros
<adrien>
that makes no sense ;p
<pippijn>
it does
<adrien>
a macro does not exist
<adrien>
it has no associated memory
<pippijn>
it exists to the C programmer
<adrien>
it's like binding a virtual class
<adrien>
you don't bind programmers' mind, you bind functions, code, memory
<adrien>
macros don't exist as symbols, you can't link against them
<pippijn>
#define COLOR_WHITE 7
<pippijn>
I didn't say anything about linking
<pippijn>
library bindings are not just symbols
<adrien>
œwthen you're defining new things
<pippijn>
some libraries provide functionality as macros
<pippijn>
you would want bindings for those in ocaml, too
<joelr>
how do you print a float to, say, 5 decimal points?
<pippijn>
joelr: with printf?
<joelr>
actually 6, padded with 0 at the end
<pippijn>
%.5f I assume
<joelr>
pippijn: what about padding with 0 at the end? automatic?
<pippijn>
# Printf.printf "%.5f" 1.2;;
<pippijn>
1.20000- : unit = ()
<joelr>
awzum
roha has joined #ocaml
<joelr>
thanks!
<joelr>
<- is printing market data
<pippijn>
oh
<pippijn>
joelr: do you want to print a + in front of the number, too?
<joelr>
no, that's fine. prices are always positive. thanks
<pippijn>
(if it is positive)
<pippijn>
ok
<joelr>
what would you call the directory where the c stubs go?
<joelr>
c_stubs?
<mrvn>
I wouldn't call it anything. I just call the file <module>_stubs.c
<joelr>
well
<joelr>
but i want the stubs to go into a separate directory
<joelr>
to separate them from the ml cod
<joelr>
code
<thelema>
then put them in stubs/
<joelr>
yeah
<thelema>
but foo_stubs.c is normal.
<joelr>
i call them caml_...
alpounet has joined #ocaml
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
<pippijn>
I call them ml_*.c
<pippijn>
but don't take an example of me
<joelr>
I wish Oasis had a CPath
Anonyme23296 has quit []
Xizor has joined #ocaml
ulfdoz has joined #ocaml
larhat has joined #ocaml
gnuvince has quit [Ping timeout: 255 seconds]
gnuvince has joined #ocaml
emmanuelux has quit [Remote host closed the connection]
<mrvn>
but more often you use type t = Bit0 | Bit1 | Bit2 and t list
<thelema>
mrvn: yes, in general, low level representation details aren't optimized in ocaml, preferring more explicit representations built out of variants, as mrvn said
<pippijn>
it would be nice if ocaml directly supported a bitset made of parameterless variants
emmanuelux has joined #ocaml
<mrvn>
like list_to_bitmap and list_of_bitmap?
<thelema>
There's a number of nice features of parameterless variants that could be built into OCaml, but probably never will be because they could be done in camlp4
<pippijn>
does that exist?
<mrvn>
pippijn: not that I know
<pippijn>
thelema: they could be done with Obj.magic
<pippijn>
but they would not be safe, because they wouldn't check for parameterlessness
<thelema>
and they'd break if any implementation details changed
<mrvn>
thelema: so would a lot of C bindings
<mrvn>
list_to_bitmap and list_of_bitmap would be trivial to write but how do you type them?
<joelr>
mrvn: yes, i should probably use that
<thelema>
true.
<pippijn>
mrvn: they could be made type-safe with a universal type module
<mrvn>
pippijn: They would work on int list or [ constructor without args ] list
<thelema>
pippijn: but then the resulting values wouldn't be compatible with normal variants, etc.
<pippijn>
mrvn: yse, and they would break horribly on constructor with args
<thelema>
mrvn: it'd be like Marshal, horribly unsafe
<pippijn>
or just assert
<mrvn>
pippijn: you could fix that, you just wouldn't get sensible results with a mix of constructors with and without args
<pippijn>
you could assert for bit value > 1000 or so
<mrvn>
pippijn: runtime checks sucks
<pippijn>
yes
<mrvn>
pippijn: and you would nee bit < 32 or < 64
<pippijn>
not necessarily
<joelr>
you would normally use foldl, correct?
<joelr>
since it's tail-recursive
<pippijn>
bit vectors can go up to any number of bits
<thelema>
joelr: yes, when possible use fold_left
<joelr>
yes, that one
<pippijn>
BatBitset or so
<thelema>
joelr: although batteries (and core) have tail recursive implementations of fold_right
* joelr
is using neither batteries nor core
<joelr>
i should probably start using the jane st version
<thelema>
joelr: give them a little bit to have a proper release; there's a bunch of pain to get their code working.
<joelr>
i see
<thelema>
There are install instructions, but the library dependencies are a bit crazy at the moment, I hear.
<joelr>
ok
Tobu has quit [Quit: No Ping reply in 180 seconds.]
Tobu has joined #ocaml
<hcarty>
I've heard rumors that Batteries is a simple "odb.ml batteries" away
<thelema>
hcarty: he clearly wants core, because... jane street, I guess. :)
mononofu has quit [Remote host closed the connection]
smerz has joined #ocaml
<hcarty>
thelema: Bah! :-) I've been tempted by the call of Core. But I can't give up the sweet sweet call of BatIO, BatPrintf, and others.
<thelema>
hcarty: but sexplib!
<hcarty>
Also, on a more or less meaningless level, |! is ugly.
<thelema>
|!?
nimred has quit [Quit: leaving]
<hcarty>
IIRC |! is Core's |>
<mrvn>
I think it would be nice if ocaml could generate .h files with enums matching the constructor numbers/tags.
<hcarty>
thelema: sexplib is something of a draw, but ultimately not enough.
nimred has joined #ocaml
nimred has quit [Changing host]
nimred has joined #ocaml
<hcarty>
thelema: And it seems (seemed?) to break often, probably due to the camlp4 complexities involved.
<thelema>
hcarty: ah. |> is better.
<thelema>
I've heard a rumor that core may shed camlp4 in its core. That said, I can't figure out how to do that - adding sexplib to modules that don't have it?
<hcarty>
thelema: Pervasive serialization support is nice, but something like json would be more pragmatic I would think.
<hcarty>
When I looked at it last, sexplib seemed easy enough to use by hand. No more or less difficult than json-wheel.
<hcarty>
But that's a lot of hand-coded (de)serialization to write if they are removing camlp4
<thelema>
it could be generated and patched in via modules
<thelema>
but maybe core will not drop camlp4
<hcarty>
True, similar to how atd works
<mrvn>
I know there is a ocaml fork out there providing a runtime type for every type and they can be passed to functions and such. Anyone know if that might be merged in soon?
<thelema>
mrvn: extremely unlikely
<mrvn>
any reason?
<thelema>
intrusive changes
<mrvn>
but worth it
<thelema>
for some apps. just waste of memory for others
<thelema>
which slows those others down
<mrvn>
thelema: they only waste memory if you use them
<thelema>
if every value is tagged with its type, the tag becomes 2 words
<thelema>
meaning twice the overhead
<thelema>
how could you not tag some values?
<mrvn>
thelema: they aren't tagged with a type. You can basically pass the type as extra argument but they are dependent
<gildor_>
f[x]: ping
<thelema>
ah, that's something else. I thought you were talking about G'caml, which is what I was escribing
bobzhang has quit [Remote host closed the connection]
<thelema>
mrvn: that is much less intrusive, and not nearly as unlikely to be merged in.
<mrvn>
thelema: forcing runtime types obviously is bad. No. This was something introducing "#a" being the type of "`a" with some compiler magic that would automatically construct the runtime type and pass it to functions using #a.
<thelema>
I wish I knew what was happening behind the ocaml consortium curtain so I could help with that.
avsm has joined #ocaml
<mrvn>
thelema: So foo : #a -> #a, foo 1 would pass int along with 1.
<thelema>
sure. That's got its own branch in ocaml svn, but I know of no discussion or partial steps towards merging it.
<thelema>
I would love for that to make it into 4.00 coming soon, but most likely we'll have to wait for 4.01 or later
<mrvn>
I wonder how much camlp4 magic it would need together with GADTs to implement it without compiler changes.
<thelema>
camlp4 can't get at types
<thelema>
it can't find out the type of a value
<mrvn>
thelema: but for every type t = .... it could insert a type t_ty = ... GADT.
<hcarty>
I hadn't read that Lexifi proposal in a while. It looks quite interesting after reading through it again.
<thelema>
hcarty: yes, I'm wishing I could build batteries' print infrastructure on top of that.
<joelr>
i wish there was a way to implement stuff in a bunch of modules (A, B, C) and mark then as "not exported, no interface", then export their interfaces from API.A, API.B and API.C
<thelema>
hcarty: same with ord
<joelr>
is there a way to do this? I know i can include a module in API but i don't think there's a way to have naked A, B and C to be interface-less
<thelema>
joelr: you want API.A to be able to access A, but no other module?
<joelr>
basically, i don't want to have a huge API.ml
<joelr>
thelema: right you are
<joelr>
thelema: in fact, i will include A in API.A, that's what i was thinking
<thelema>
joelr: and what's the problem with having API.ml just include the other modules as submodules?
<thelema>
API.ml: module A = A module B = B ...
<joelr>
thelema: no problem with that but seems inelegant that you can just use the modules directly
<thelema>
no way to prevent that.
<joelr>
thelema: ah, i want to export an api
<joelr>
fair enough
<thelema>
batteries prefixes all the modules with "Bat", and then provides a Batteries.ml that does 'module Foo = BatFoo' for all the modules
<thelema>
that way they don't collide with any other module names
<thelema>
you could do the same with some other prefix
<thelema>
and let people know not to use the prefixed names.
<hcarty>
joelr: You can pack modules to make that work
<joelr>
aha!
<thelema>
hcarty: I've had more than my fair share of problems with packing and consider it a dirty hack.
<adrien>
issues like what?
<thelema>
If all that's in your API module is submodules, then packing will do more or less what you seem to want
<thelema>
adrien: mainly namespace problems, but also compile errors
<hcarty>
thelema: I'm not a huge fan of it either. I would love to see namespace support added to OCaml.
<joelr>
hcarty: can you pack modules with oasis?
<hcarty>
joelr: With 0.3.x, yes
<thelema>
hcarty: yes, ocaml definitely needs a not-flat namespace of modules
<hcarty>
joelr: With 0.2.x, only if you patch support in yourself
<adrien>
thelema: hmmm, ok, I've been compiling stuff separately (because ocamlbuild forced me to in the first place)
<adrien>
that's probably what has spared me from these issues
<joelr>
hcarty: i have 0.3.x
<joelr>
hcarty: does it make it easier?
<hcarty>
joelr: Then it should work, although I haven't tried it
<gildor_>
joelr: yes using 0.3.0~rcX
<joelr>
hcarty: is that described somewhere, are there examples?
<joelr>
gildor_: right, the one i'm using
<joelr>
gildor_: any examples?
<gildor_>
examples/packedlib/_oasis in the oasis sources
<hcarty>
thelema: Regarding printing and Ord - yes, it would be very nice to have LefiFi's extension in place for those.
<joelr>
yay
<gildor_>
joelr: but you just have to add "Pack: true" to your library
<joelr>
gildor_: thanks
_andre has quit [Quit: leaving]
<joelr>
gildor_: when you pack a library like that, what module is the "interface"?
<joelr>
hcarty: ^
<joelr>
never ind, me stupid
<joelr>
it's via Packedlib.Mod.interface
<joelr>
hcarty: what's the advantage of the approach, though? i want to hide a bunch of modules
<hcarty>
joelr: The advantage of packing A, B, C into Parent rather including A, B, C in Parent?
<joelr>
hcarty: i suppose so
<hcarty>
One somewhat significant one is that packing helps reduce name conflicts
<joelr>
hcarty: because your submodules are now under the Parent namespace?
<hcarty>
If you don't pack then the module A, B, C are all directly exposed
<adrien>
you can have a module interface and packs also create modules so you can have an interface there too
<joelr>
here's an example
<joelr>
suppose i pack everything into a RAPI library
<hcarty>
adrien: Yep. I have a few libraries written that way. There is a parent.mli but no parent.ml
<joelr>
i want to have RAPI.MarketData.Flags
<joelr>
but I want Flags.ml to implement the flags and then hide it so that there's no RAPI.Flags, only RAPI.MarketData.Flags
<joelr>
possible? how?
<thelema>
recursive packing? I think not.
<hcarty>
joelr: Include or pack each sub-module into its parent
<thelema>
hcarty: can a pack be packed again?
<hcarty>
thelema: I saw a bug report that indicated it was supported in 3.11.x, broke in 3.12.x, and is fixed again for 4.x
<thelema>
I was pretty sure packing was one level only, for some reason
<thelema>
I recall that, but apparently I've forgotten the details
<joelr>
hcarty: i will include the submodule in the parent but how do i hide the submodule then? so that it's not accessible other than via the parent?
<hcarty>
thelema: I haven't tried it so I don't know exactly how it works
<thelema>
I'll have to look it up sometime
<thelema>
joelr: my suggestion is still to keep things simple, and write your modules as private_foo, and then write one API.ml that includes everything where you want it
<joelr>
hcarty: i want a packaged API and then API.MarketData.Flags but no API.Flags
<hcarty>
joelr: Pack and use RAPI.mli to hide whatever you don't want users to see.
<joelr>
hcarty: so when i pack into RAPI I can still have an mli file? cool!
<hcarty>
joelr: Yes
<joelr>
hcarty: that solves my problem, i think
<joelr>
thanks
<joelr>
thelema: hcarty's solution is a tad more elegant
<thelema>
joelr: I agree, and hope you have no problems with it.
<joelr>
oasis to the rescue!
<thelema>
I'll admit I didn't have oasis when I was trying to make pack work.
<hcarty>
joelr: Either approach should work - if you have trouble with packing, it's relatively easy to switch to the approach thelema suggested. Both have their benefits.
<joelr>
suppose i have a Flags module. the function to_int would convert a single flag to int but how would i name the function that converts a list of flags to int?
<joelr>
i suppose i could provide -just- the list function… hmmm
<joelr>
and call that to_int
<thelema>
Flags.to_int and Flags.of_int
<thelema>
n/m, misunderstood
<thelema>
list vs. single flag
<joelr>
right
<joelr>
why bother with single flag, though.
<thelema>
just the list function as .to_int, maybe .to_int_single for a single flag
<joelr>
just provide the list
<joelr>
ok, thanks
Tobu has quit [Ping timeout: 272 seconds]
* joelr
is trying to provide a nice api around a c++ library
<thelema>
I dunno if the ocaml community is impressed by deep module heirarchies.
<thelema>
I generally don't consider them so nice.
snearch has quit [Quit: Verlassend]
<hcarty>
thelema: The anti-Java layout.
<thelema>
as flat as possible, and no flatter
<thelema>
Although I wouldn't mind Array_labels etc in the stdlib being submodules of Array etc.
<joelr>
hehe
<joelr>
i like it haskell-style
eni has joined #ocaml
nimred has quit [Quit: leaving]
gnuvince has quit [Ping timeout: 250 seconds]
Tobu has joined #ocaml
<diml>
hcarty: equivalent of Unixqueue.once: let once d f = Lwt.on_success (Lwt_unix.sleep d) f
<hcarty>
diml: Thank you. I wasn't sure if there was something special required beyond sleeping.
<hcarty>
diml: Do Lwt_unix.sleep threads cost any more/less than a any other Lwt thread?
<hcarty>
diml: 'cost' as in any kind of overhead
<diml>
hcarty: it is the cost of Unix.gettimeofday
<joelr>
is there some library that would print my parameter-less constructors?
<hcarty>
diml: Is that implementation any better/worse than this? let once d f = Lwt_unix.sleep d >> f ()
<joelr>
e.g. give me "A" from type foo = A | B | C
<hcarty>
joelr: Deriving may provide something like that. You would need to use something camlp4-based.
<joelr>
right
<joelr>
thanks
<hcarty>
joelr: You're welcome, and good luck
<diml>
hcarty: the difference is only the allocation of: { state = Return () }
ulfdoz has quit [Ping timeout: 245 seconds]
nimred has joined #ocaml
tufisi has quit [Ping timeout: 260 seconds]
<hcarty>
diml: Thanks
<avsm>
sigh, OASIS is just opaque to me
<joelr>
avsm: need help?
<avsm>
packaging a camlp4 extension
<avsm>
or trying to... is this "XMETAType: syntax" significant?
<avsm>
(i'm cribbing from the pa_lwt OASIS file)
<avsm>
click-3:ocaml-cstruct avsm$ oasis setup
<avsm>
W: Field XMETAType is set but matching plugin is not enabled.
<avsm>
W: No replace section found in file Makefile
* avsm
thinks he'll use the 1980s technology known as a Makefile
<hcarty>
avsm: Are you using the META plugin?
<avsm>
i have no idea
<avsm>
Plugins: DevFiles (0.2), META (0.2)
<avsm>
yep (?)
<avsm>
this works for normal stuff
<avsm>
but i cant get it to build a syntax extension, and use it on a unit test
<hcarty>
avsm: Drat. I'm out of ideas -
<avsm>
it just skips it
* avsm
wonders if you are meant to to build the syntax extensions in one pass, and actually use them in another
<gildor_>
avsm: a warning that I should get rid of
<hcarty>
avsm: Building the extension should be fine. Using it in a executable or unit test was unsupported the last time I asked.
<avsm>
ahhh, very helpful to know I'm not missing an XMETAFOOBARWIZZLYBAR flag. thanks!
<gildor_>
W: No replace section found... it means that there is no # OASIS_START/STOP section in the Makefile and that it cannot inserted the generated content in it
<avsm>
ohh, hrm
<avsm>
is it legal to put stuff before the OASIS_START?
<gildor_>
avsm: legal and encouraged, it is designed for that
<gildor_>
avsm: I do it all the time
<avsm>
oh hang on, why is it doing anything with the Makefile?
<avsm>
oasis generates a Makefile now?
<avsm>
or is that the DevFiles plugin or something?
* avsm
is sure it didnt do that last time :-)
<gildor_>
probably because you have Plugins: DevFiles
<avsm>
aha
<gildor_>
DevFiles generate a Makefile
<gildor_>
and a configure
<avsm>
ack; I use a smaller one that compiles setup.ml to native code
<avsm>
so, just to confirm, it's not possible to build a camlp4 extension, and then invoke it on an executable compile?
<avsm>
i'm just putting in the usual "add camlp4o_syntax to _tags" and BuildDepends on the foo.syntax library
<gildor_>
if you are using oasis 0.3.0~rcX, I encourage you to replace native code compilation by oasis setup -setup-update dynamic
<gildor_>
avsm: not yet, it will be possible in 0.4 (at least I need it)
<gildor_>
it generate a 20 lines setup.ml that basically load oasis.cma at runtime
<avsm>
it falls back to ocamlc if ocamlopt isnt around
<gildor_>
i.e. it comes with setup.ml precompiled
<gildor_>
the extra cost is just to always parse _oasis
<gildor_>
which is way faster than compiling a 6kLoC .ml file
untroubled has quit [Quit: leaving]
<gildor_>
but try it and see if it matches the speed of your compilation
<avsm>
not really; this happens just once, and is pretty fast afterwards, and no mysterious dynlink issues
* avsm
is doing this on a dreamplug ARM too, so not too fast a machine
<gildor_>
no dynlink involved, just plain old .ml script with a plain old "#load" directive
<gildor_>
well with a little bit of findlib in the middle
<gildor_>
but this stuff has been designed to help people like you that need a minimal overhead when invoking oasis, so you are the perfect tester for this feature
<gildor_>
I do prefer -setup-update weak
<avsm>
honestly, i don't see what's wrong with my makefile rather than yet more stuff in oasis
<gildor_>
nothing wrong with your makefile
<gildor_>
you can continue using it, you are the one sensible to overhead and the one that can help me on this topic
<gildor_>
if you are not satisfied, tell me about it and I can see if I can improve that
<avsm>
ack, thanks!
gnuvince has joined #ocaml
NihilistDandy has joined #ocaml
ssbr_ has joined #ocaml
<ssbr_>
Hey folks! I'm just getting started with ocaml I pulled an ocaml project I'm going to be working on (an implementation of datalog) and tried to build it (make config and then make datalog), this was the output of "make datalog": http://bpaste.net/show/FBiOrBnu4F0LOI4TwxWP/
<ssbr_>
I'm not sure what to do now.
<thelema>
compile the .cmi file first
<thelema>
ocamlc buddy.cmi
<thelema>
should produce a .cm file
<thelema>
.cmx
<thelema>
err... wow, that's all wrong
<thelema>
compile the .mli file first
<thelema>
ocamlc -c buddy.mli
<thelema>
should produce the .cmi file that's being asked for
<thelema>
ssbr_: ^^
<thelema>
the .cmi file can go in the same dir as the .ml and .mli
Tobu has quit [Ping timeout: 272 seconds]
<ssbr_>
thelema: ah, er, there is no buddy.cmi file