<adrien>
what's the minimum set of things to do to get packs with ocamlbuild? only the M.mlpack file?
<adrien>
it's not using -for-pack _anymore_ here
<adrien>
and I haven't changed my setup
<adrien>
needs the -for-pack(M) tag too; but I don't understand why it's not in use anymore in my oasis project
<adrien>
ah, sorry for the noise; I had additional lines in my _oasis file which I've lost now: oasis does not handle packs using files starting with lowercase letters
<adrien>
it doesn't handle them if they start with a lowercase letter *and* are in a subdirectory
letrec has joined #ocaml
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
Cyanure has quit [Read error: Connection reset by peer]
Qrntzz is now known as Qrntz
Snark has joined #ocaml
antegallya has joined #ocaml
gasche has joined #ocaml
<gasche>
hi there
olasd_ is now known as olasd
<adrien>
morning
<adrien>
thomasga: I've actually seen more questions that I expected to see on StackOverflow
avsm has joined #ocaml
<Ptival>
s/that/than/
<adrien>
heh, yeah
<gasche>
avsm, out of curiosity, are you related to "ashima games"?
<avsm>
i advise them, yes. but dsheets is doing all the hard work
<gasche>
(I found 'gloc', a project they're working on, which looks interesting, and then I looked at the webpage and didn't really understand what "ashima" is or was)
<gasche>
ok
<gasche>
(I got the latter part :p)
<avsm>
ashima's a group, doing a bunch of different things. ocaml heavily features in many of them :)
<gasche>
that's good to hear, thanks
<thizanne>
hey gasche
<gasche>
hi
emmanuelux has quit [Ping timeout: 240 seconds]
dsheets has quit [Ping timeout: 240 seconds]
dsheets has joined #ocaml
willb has quit [Ping timeout: 265 seconds]
emmanuelux has joined #ocaml
emmanuelux has quit [Read error: Connection reset by peer]
emmanuelux has joined #ocaml
Xizor has joined #ocaml
logicgeezer has quit [Remote host closed the connection]
ikaros has joined #ocaml
Drakken has joined #ocaml
ousado has quit [Quit: bye]
letrec_ has joined #ocaml
pheredhel has quit [Write error: Broken pipe]
letrec has quit [Write error: Broken pipe]
<Drakken>
I'm getting exception Out_of_memory, but there's plenty of free RAM. The error seems to occur when I call a function that removes duplicates from a list.
pheredhel` has joined #ocaml
<thelema_>
Drakken: gdb?
<thelema_>
also, possibly stack overflow - those can do wierd things
<Drakken>
I've already called the function several times with similar arguments.
<Drakken>
thelema_ what's gdb?
thelema has joined #ocaml
<Drakken>
gnu debugger?
<thelema>
yes
<thelema>
gdb foo.native
<thelema>
> run
<thelema>
> bt
<adrien>
there might be no stack if the process exits "normally"
<thelema>
OOM should be caught by gdb
<adrien>
that one is an ocaml exception however
<adrien>
for some things, strace might help too
thelema_ has quit [Ping timeout: 252 seconds]
<thelema>
yes, but it's triggered by some underlying error from the OS that ... hmm maybe gdb won't catch it in addition to the ocaml runtime.
<gasche>
it looks like a typical Stack Overflow due to a non-tailrec function, though
<thelema>
Drakken: batteries has functions for removing duplicates - maybe use one of those.
<adrien>
Drakken: how many elements in your list?
<gasche>
(I mean gdb is a bit overkill if he only needs to make his function tail-rec and that's it; that would probably take less time than testing this thoroughly)
<Drakken>
adrien 3
<gasche>
hm
<thelema>
broken uniquify function?
<gasche>
yeah, infinite loop
<Drakken>
How can it do that? Each call pulls the first element off the list and just calls filter.
<thelema>
Drakken: pastebin?
<Drakken>
on the tail.
<Drakken>
hold on a second...
Drakken has left #ocaml []
<Ptival>
haha
Tobu has quit [Ping timeout: 272 seconds]
Drakken has joined #ocaml
joewilliams has joined #ocaml
<gasche>
thelema, I'm playing with odb.ml right now, works rather well
<thelema>
gasche: thanks. are you using the packages file?
<gasche>
but I don't like the way the "prefix" is set: you forcefully add "--prefix fooo" to configure
<gasche>
I'm trying to get some more packages to compile (menhir and kaputt currently)
<thelema>
tell me a better way...
<gasche>
my point :]
<thelema>
:)
<gasche>
I wanted to add an property to the package configuration that would look like
<gasche>
menhir prefix="PREFIX="
companion_cube has joined #ocaml
<gasche>
kaputt prefix="-ocaml-prefix "
<gasche>
but the property parsing is a fragile regexp that won't be happy with that
<thelema>
is it unreasonable to expect menhir and kaputt to change?
<gasche>
so I suggest instead a slightly more over-engineered solution of
<gasche>
I'm also contemplating writing _oasis files for them, which would be a win in the long run
<thelema>
but pragmatism is important... getting things working.
<gasche>
but if there is a rather simple way to generalize odb.ml to require no changes for those, that would be nice
<gasche>
yes
<gasche>
what do you think of the none, env(FOO), param(foo) idea?
<thelema>
one hack is to oasis-ify them without changing build systems - just have oasis call their build system
<gasche>
yes but this won't work terribly for kaputt because the problem is not that the prefix is not set, but that you pass it an option that it doesn't recognize
<gasche>
(I mean just "./configure" would work, but "./configure <some garbage randomly added by odb>" doesn't)
<gasche>
hence my idea to generalize the way odb adds the garbage
<thelema>
I wonder if oasis can pass the -prefix from "ocaml setup.ml -configure" into its custom commands...
<gasche>
hum
<gasche>
that would be a possibility
roha has joined #ocaml
<gasche>
should I deduce that you're not terribly tented by the env/param idea?
<thelema>
if so, cheap-oasisification might still be better than modifying odb. Not that I'm opposed to hacking on odb - it's designed to be easy to hack
<thelema>
"tented"? heh
<gasche>
hm
<gasche>
tempted
<thelema>
ah. that makes more sense, although in a weird slang way, tented makes sense too.
<gasche>
(separate feature with: I wished I could just write ocaml odb.ml menhir package=.... , without having to insert the options in a ~/.odb/package config file)
<thelema>
gasche: that second feature wish has occurred to me as well, and I'd be very happy to add
<thelema>
I'm a little tempted by the env/param idea - it would work reasonably cleanly (I think) and the changes would be reasonably encapsulated.
Tobu has joined #ocaml
<thelema>
I just see it as a bit too much adapting to custom build systems when I want to push ocaml projects towards some standards of how to build...
<thelema>
although, to do that, I shoudl probably document the assumptions that odb makes
<Drakken>
thelema this is the function:
<Drakken>
let rec uniqs ?(eq=(=)) ?(key=ident) = function [] -> [] | x::xs -> x :: uniqs (List.filter (fun y -> not (eq (key y) (key x))) xs)
<Drakken>
where ident x = x
<gasche>
doesn't look wrong
<thelema>
doesn't look wrong to me either
<gasche>
but "eq" makes me suspicious: are you using cyclic values or something?
<gasche>
polymorphic structural equality (=) can go wrong in surprising way
<gasche>
hm
<gasche>
doesn't look wrong but is quadratic: will definitely sucks for long lists
<thelema>
Drakken: fwiw, I think you can get away with not needing both key and eq; eq could do the key projections before comparing, and key could project to integers or something easy to compare with polymorphic =
<thelema>
it is non-tail recursive, though, so if you were really running on a long list, it'd explode the stack
<gasche>
(but having "key" separately is handy if you want an efficient implementation that doesn't compute keys twice on the same element)
<thelema>
gasche: which he doesn't, and which is why batteries' unique only takes a key function
<Drakken>
thelema this is a convention I learned in Lisp. Sometimes it's useful to test for "partial" equality.
<Drakken>
i.e. equality of a piece of the data structure
<thelema>
yes, you don't need both a projection and a custom eq function to do that; either one will suffice
<gasche>
thelema, regarding the --prefix thing, I think we better have odb.ml playing nice with the maximum number of packages for now, so that it gains traction, and put the pressure to standardize later on, eg. in OASIS-DB
<gasche>
Drakken, do you use equalities on suble data structures that have implicit cycles? that could be a reason for failure
<Drakken>
gasche I'm calling the function with a custom eq function that uses (==) for records.
<thelema>
gasche: If you write the prefix env/param code, I'll include it.
<gasche>
ok
<thelema>
I fear that this commit will finally push odb over 500 lines...
<thelema>
:)
<thelema>
oops, something else already did - it's 504... :)
<thelema>
one sec, maybe I've not pushed my latest code to github
<thelema>
n/m, just a change to packages
<gasche>
what's your advice for quick&dirty parsing of the property? Scanf,Str?
<thelema>
I think scanf will work best for what you're trying to do.
<gasche>
agreed; the worry is the ugly way to handle failure
<gasche>
(You should include a subset of jun's monadic parser library! ;)
<thelema>
you don't have to be elegant at all about failure...
<thelema>
gasche: planck? hmm
<thelema>
I don't think so - it depends on secplib...
<thelema>
*sexplib
<gasche>
yeah, the whole thing does, but the core is rather simple
<gasche>
anyway, that was more of a joke, maybe we can keep it simple and ugly
<thelema>
:)
<gasche>
btw, I noticed that your behavior, on config lines that you can't parse, is to do nothing, not even a warning
<gasche>
is that intentional?
<gasche>
(line 148: | _ -> () )
<thelema>
not really, just lazy coding. I'll put in a warning that some line was bad, but I'm not counting line numbers, so it'll be not so useful
<gasche>
you could print the line
<gasche>
or count line numbers, or both; if you wish I'll write the patch as well
<thelema>
small size... escaping...
<thelema>
... heh I don't even have the line - it gets fed immediately into Str.split.
<thelema>
I guess I could re-assemble the line with String.concat
<thelema>
but it wouldn't necessarily match the real line.
<thelema>
it would be helpful, I guess.
<thelema>
I'll write the line-number counting.
<thelema>
pushed. Thanks for suggestion
<Qrntz>
could a recursive function, which last calls a List.iter with the function argument of itself be tail-recursive?
ulfdoz has joined #ocaml
<thelema>
Qrntz: no, as the last thing it does is call List.iter, not itself
<Qrntz>
hrm, makes sense
<thelema>
you can't have tail recursion if you call yourself multiple times in one input
<thelema>
only the last of those can be in the tail position.
<Qrntz>
thanks
<gasche>
hum
<gasche>
I'm not sure I understood Qrntz question correctly
<gasche>
but
<gasche>
let rec deep_iter f = function Node (hd,rest) -> f hd; deep_iter f | End ends -> List.iter f ends
<gasche>
*is* tail-recursive
<thelema>
there might be some corner cases involving lists of length 0 or 1 and specially implemented List.iter
<gasche>
(and seems to correspond to its destriction)
<gasche>
cription
<gasche>
(with type 'a foo = Node of 'a * 'a foo | End of 'a list )
<thelema>
maybe I'm pushing the semantics of what I call tail recursion...
<thelema>
that function does run with constant stack space
<thelema>
but there's no recursive call in the tail position
ftrvxmtrx has quit [Quit: Leaving]
<gasche>
hum
<gasche>
the Node case should be f hd; deep_iter f rest of coursr
<gasche>
and that's where the recursive tail-call is
<thelema>
ok, there is one tail recursion.
<gasche>
Qrntz specified that the "function argument" is used in the last List.iter, not the recursive function itself
<gasche>
so I'd say Qrntz that your question is too vague and that you better stick to simple syntactic criterions for tail-calls
<gasche>
ok so prefix=none gets kaputt (and, I expect, bolt and co) to compile
<gasche>
but menhir doesn't quite work because it requires the environment to be set on the "make" call, and my current generalization only affect the "configure" step
<gasche>
(plus it does sh configure FOO=bar instead of sh FOO=bar configure...)
<thelema>
gasche: oops, more changes...
ocp has quit [Ping timeout: 260 seconds]
ivan\ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
cago has quit [Quit: Leaving.]
ivan\ has joined #ocaml
srcerer_ is now known as srcerer
ikaros has quit [Quit: Ex-Chat]
letrec_ has quit [Ping timeout: 260 seconds]
<Qrntz>
gasche: > with the function argument of itself
<Qrntz>
I actually meant something like your example.
<thelema>
Qrntz: ok then, no problem
<gasche>
if you still have doubt, just paste the code somewhere and show it
<thelema>
"tail recursion" is just a special case of TCO, Tail Call optimization
<thelema>
which just says that function calls in the tail position can be optimized to jumps instead of calls
avsm has quit [Quit: Leaving.]
<thelema>
so the List.iter is in the tail position, and can be jumped to instead of called, but this isn't a recursive call, so I don't call it tail recursion
ousado has joined #ocaml
ousado has quit [Changing host]
ousado has joined #ocaml
ttamttam has joined #ocaml
gasche has quit [Quit: Leaving]
beginner has joined #ocaml
<Qrntz>
thelema: http://paste.in.ua/3854/ is my piece of code (uses the ocaml-syck bindings for yaml support)
<thelema>
that won't quite run in constant stack space, but will run in log stack space
<thelema>
line 5, where you call parse twice inside iter - this will need an actual function call to parse for k
<Qrntz>
hm
<thelema>
all the other function calls are in tail position
<Qrntz>
this code isn't final, just a prototype. I just wanted to know if a List.iter like that would work as I expect it to
<Qrntz>
so, if I remove the separate parsing for keys and values, it's going to be tail-recursive?
<thelema>
if you only parse one or the other, the whole thing will run in constant stack space
<Qrntz>
alright, that's what I wanted to know
<Qrntz>
thanks a lot
<thelema>
even if you parse both, your stack space will be proportional to the depth of the tree
<thelema>
i.e. the number of keys within keys within keys...
<thelema>
and only that branch matters
TaXules_ is now known as TaXules
<Qrntz>
all of my keys are scalar so it's actually a single call to pattern match a YamlNode.SCALAR and return the value
<thelema>
then under that assumption, the existing code will run in constant stack space
ftrvxmtrx has joined #ocaml
<_andre>
is it possible to have a funtor scheme like this and be able to pattern-match on M.t? http://pastebin.com/ua8AfJ6M
<_andre>
functor*
<thelema>
module type XMod = sig type t = A | B end
EmmanuelOga has joined #ocaml
<_andre>
but then i wouldn't be able to do module M = Make (struct type t = C | D end)
dwhj has quit [Quit: dwhj]
<thelema>
_andre: you're right - what would pattern matching mean if you don't know the variants to match with?
<_andre>
well, i know what they are for that specific M, but i think i understand why it can't work
<hcarty>
I have an OCaml string that I need to access from C. Am I correct in assuming that the address given by String_val(ocaml_string_value) may change after a call to caml_alloc?
<thelema>
hcarty: yes, strings may get moved by the GC
<thelema>
although string literals I don't think will be moved.
<thelema>
as they're statically constructed
<hcarty>
thelema: Is there a way to prevent that from happening for the duration of the C FFI call? Is there where global roots come into play?
<hcarty>
thelema: That makes sense re: string literals. In this case the string is dynamically allocated.
<thelema>
it generally doesn't make sense to set a string as a GC root, but it may prevent its being moved.
<hcarty>
s/there/this/
<thelema>
I'm trying to imagine the GC moving roots... that said, I wonder what would happen if you set a value in the minor heap to be a root...
<hcarty>
I have a bit of a tricky situation. I need to take data from an OCaml string and hand it off to a C function which stores a pointer to that string.
<thelema>
I assume the string is really long, so the cost of copying it is high, right?
<hcarty>
thelema: Yes
<hcarty>
thelema: That is correct
<hcarty>
It's a large binary file being read by a C API
<thelema>
ok, so why can't you get the pointer each time you need it?
<hcarty>
Well, in this case a binary blob read from a file..
<thelema>
hmm, actually, if you set that pointer as a GC root, I think the GC would update it when the string is moved.
<hcarty>
thelema: The C API returns a 'handle' value which stores a pointer to the data internally.
<thelema>
I don't think you can pin data with the ocaml GC
<thelema>
(other than moving it outside the GC)
<hcarty>
The short version of the process in this case is: Download data with ocurl |> Parse data with C API, returning an OCaml list of values extracted from the raw binary data
<hcarty>
I may be stuck with copying the data. That's unfortunate.
<thelema>
hcarty: sounds like you should dowbload the data with libcurl
<thelema>
*download
<thelema>
so the huge blob stays in C land and won't be moved
<hcarty>
That's my other option. It's not clean, but it does avoid copying the data.
<hcarty>
This was tough to track down. GC interaction bugs are tricky.
ttamttam has quit [Ping timeout: 244 seconds]
<adrien>
we need a valgrind-on-steroids
<thelema>
one other possibility is to not allocate the C values until the very end of parsing...
roha has quit [Ping timeout: 244 seconds]
Drup has joined #ocaml
yezariae1y is now known as yezariaely
<hcarty>
thelema: I could push the values onto a C list
<hcarty>
Then convert that to an OCaml list once the C work is done
<thelema>
hcarty: you'd only have to copy the parsed values, not the raw.
<hcarty>
thelema: Correct
<thelema>
(I don't think you could avoid this anyway)
pango__ is now known as pango
<hcarty>
The parsed results are about the same size as the raw data they come from. Given that, copying the data upfront should have about the same overhead as building a C list then copying the data over to OCaml values.
<thelema>
actually, it'd be much better if you copy first, as block copies are faster than lots of little piece copies
<thelema>
s/much better/better/
<hcarty>
thelema: Good point
<hcarty>
thelema: Thank you once again for your help!
<thelema>
you're welcome.
othiym23 has joined #ocaml
antegallya1 has joined #ocaml
antegallya has quit [Read error: Connection reset by peer]
milosn has quit [Ping timeout: 265 seconds]
milosn has joined #ocaml
Snark has quit [Quit: Quitte]
ttamttam has joined #ocaml
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
blackdog_ has joined #ocaml
thomasga has quit [Quit: Leaving.]
avsm has joined #ocaml
avsm has quit [Quit: Leaving.]
mdelaney has joined #ocaml
_andre has quit [Quit: leaving]
ocp has joined #ocaml
ocp has left #ocaml []
strlen_ is now known as strlen
ocp has joined #ocaml
joewilliams has quit [Read error: Operation timed out]
lopex has quit [Excess Flood]
lopex has joined #ocaml
joewilliams has joined #ocaml
Submarine__ has joined #ocaml
antegallya1 has quit [Quit: Leaving.]
antegallya has joined #ocaml
ttamttam has left #ocaml []
lopex_ has joined #ocaml
ocp has quit [Ping timeout: 260 seconds]
lopex has quit []
lopex_ is now known as lopex
lopex has quit [Max SendQ exceeded]
joewilliams has quit [Ping timeout: 260 seconds]
bobry has quit [Ping timeout: 276 seconds]
lopex has joined #ocaml
joewilliams has joined #ocaml
metasyntax|work has quit [Quit: WeeChat [quit]]
joewilliams has quit [Ping timeout: 240 seconds]
oriba has joined #ocaml
ikaros has joined #ocaml
joewilliams has joined #ocaml
lopex_ has joined #ocaml
cdidd has quit [Remote host closed the connection]
edwin1 has quit [Remote host closed the connection]
edwin has joined #ocaml
lopex has quit []
lopex_ is now known as lopex
Submarine__ has quit [Ping timeout: 240 seconds]
Submarine__ has joined #ocaml
edwin has quit [Remote host closed the connection]
Submarine__ has quit [Ping timeout: 245 seconds]
ftrvxmtrx has quit [Ping timeout: 252 seconds]
ftrvxmtrx has joined #ocaml
othiym23` has joined #ocaml
wagle has quit [Ping timeout: 252 seconds]
djcoin has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
ikaros has joined #ocaml
wagle has joined #ocaml
mdelaney has quit [Quit: mdelaney]
mdelaney has joined #ocaml
bacam_ is now known as bacam
antegallya has quit [Ping timeout: 245 seconds]
Drup has quit [Quit: Leaving.]
antegallya has joined #ocaml
letrec_ has joined #ocaml
MaskRay has joined #ocaml
MaskRay has quit [Changing host]
MaskRay has joined #ocaml
mdelaney has quit [Quit: mdelaney]
roha has joined #ocaml
asdfhjkl has quit [Quit: Leaving]
ulfdoz_ has joined #ocaml
ulfdoz has quit [Read error: Operation timed out]
ulfdoz_ is now known as ulfdoz
ikaros has quit [Quit: Ex-Chat]
antegallya has quit [Remote host closed the connection]
Xizor has quit []
MaskRay has quit [Remote host closed the connection]
emmanuelux has quit [Read error: Connection reset by peer]