<thermoplyae>
anyway, try ... with ... i what you want
<thermoplyae>
is
<mbishop>
I tried " | Failure" but it errored, now that I think about it, it's error message probably told me the right way to do it heh
<mbishop>
thanks
<mbishop>
yeah I knew try ... with, just not what to match for
dobblego is now known as dick
<thermoplyae>
_ ->, Failure _ ->, and Failure "int_of_string" -> will all catch it
<mbishop>
Yeah, it complained that it wanted a string
<mbishop>
anyway, it works now, thanks :)
<mbishop>
Will the GC close open files every time, or is it kind of hit or miss or what?
<thermoplyae>
i don't think that the GC runs unless you force it or the program runs out of memory
<thermoplyae>
relying on it is a bad idea
yminsky has quit [Read error: 104 (Connection reset by peer)]
<pango>
GC doesn't close file descriptors at all
<thermoplyae>
also that
<pango>
for resources that have a well defined lifespan, the best trick I know is to use a high order function to factorize allocation and deallocation with exception protection... like http://pastebin.be/8880
<pango>
then you can do tryopen_read "filename" (fun ic -> ...) tryopen_write "filename" (fun oc -> ...) etc.
yminsky has joined #ocaml
dick is now known as dibblego
seafood__ has joined #ocaml
seafood_ has quit [Read error: 104 (Connection reset by peer)]
<thelema|away>
pango: you sure about GC not closing file descriptors at all? I thought it did, but that it's still easy to run out of descriptors if the GC doesn't need to run...
thelema|away is now known as thelema
<pango>
feel free to check, but I'm quite confident it doesn't
<thelema>
I agree that relying on GC to close descriptors works poorly
<thelema>
agreed. I wonder what overhead would appear if Gc.finalise found its way into Pervasives.open_in
<AxleLonghorn>
what's the point of that code?
bluestorm has joined #ocaml
<pango>
95% of the time you can use the HoF trick, and immediately get rid of most leaks
<thelema>
AxleLonghorn: testing whether the OCaml GC closes file descriptors
<AxleLonghorn>
I'm guessing it doesn't
<pango>
correct
<AxleLonghorn>
huh
<AxleLonghorn>
ok
<AxleLonghorn>
thanks
<mwc>
Yeah, it's sort of a poor-man's RAII. I really love that C++ idiom
<mwc>
pretty much the only think I love about C++
<thelema>
it could, I just wonder what over head would get incurred...
<mwc>
s/think/thing/
<mwc>
thelema, well, I think the problem you run into is similar to the problem of trying to GC in C/C++. GC really can't be used for management of resources that aren't entirely under it's control, like memory allocation
<mwc>
suppose you open a file, getting it's file descriptor
<mwc>
marshall that FD out into a file
<mwc>
then "forget" all the references to that file descriptor. Theoretically, it get's GC'd since no part of the program in memory is aware of the FD
<mwc>
so the GC closes it for you
<mwc>
now mashall in the freeze-dried FD from the file, and try to use it
<mwc>
oops.
<mwc>
the HoF trick pango showed is the correct way to do it
<mwc>
the only thing I don't like about it is that it's possible to leak the resources out of the client function
<thelema>
marshalling FDs seems like a losing proposition to me. You can't pass it to a different process to use, you can't save it for later, so might as well just keep the FD alive
<mwc>
thelema, it's not something one would do in practice
<mwc>
it's a pathological case to make a point
<mwc>
I think that as a mathematician, such things keep me up worrying at night, and most people just ignore it out of practicality
<mwc>
still, it feels like there's something that's still wrong with the HoF approach
<thelema>
there is - one could save the channel and try to use it later in the program
<thelema>
tryopen_read "fn" (fun ic -> global_ic := ic)
<mwc>
that's what I mean
<pango>
well, feel free to shoot yourself in the foot ;)
<mwc>
the abstraction is leaky
<mwc>
and it pains me
<bluestorm>
mwc: hm
<bluestorm>
i have not seen the HoF trick exactly
<bluestorm>
and there are several implementations
<bluestorm>
but i think it is possible not to let outside code access the ressource
<bla>
I wonder what's the most simpliest way to read an image file into array of rgbs.
<bla>
dev-ml/ocamlsdl?
<flux>
sdl is quite easy
<flux>
it will load sdl surfaces though, and you need to convert them to an array
filp has joined #ocaml
<bla>
Hm, might do.
middayc has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
What's the easiest manner of loading textures for LablGL ?
* Yoric[DT]
used that some time ago but doesn't remember.
<bla>
Hmhm. Maybe there's a glut implementation somewhere?
Morphous_ has joined #ocaml
<bla>
Or lablgtk?
<bla>
HM.
<Yoric[DT]>
Well, LablGl is glut :)
<bla>
GLUT? (openGL Utility Toolkit?)
<Yoric[DT]>
Yeah, LablGL is a OCaml layer on top of GLUT.
<Yoric[DT]>
It has the same API as GLUT, iirc.
<Yoric[DT]>
(just typed)
<bla>
Probably it has some ways to read files then. ;)
<bla>
(But I don't want to use *gl* in raytracer.)
Morphous has quit [Read error: 110 (Connection timed out)]
Yoric[DT] has quit ["Ex-Chat"]
hsuh has left #ocaml []
gaja has joined #ocaml
gabriel__ has joined #ocaml
gabriel__ has left #ocaml []
gabriel__ has joined #ocaml
<flux>
rwmjones, it just came to my mind that I don't think e ven openssl provides an incremental md5 digest generator.. did you find it?
rwmjones has quit [Remote closed the connection]
rwmjones has joined #ocaml
hkBst has joined #ocaml
middayc has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
olleolleolle has joined #ocaml
Tetsuo has quit [Remote closed the connection]
Tetsuo has joined #ocaml
<mfp>
flux, rwmjones: Cryptokit.Hash
Tetsuo has quit [Read error: 104 (Connection reset by peer)]
<rwmjones>
mfp thanks I'll take a look
Tetsuo has joined #ocaml
middayc has joined #ocaml
StoneNote has quit []
rwmjones has quit ["Closed connection"]
rwmjones has joined #ocaml
olleolleolle has left #ocaml []
seafood_ has joined #ocaml
petchema_ has quit [Remote closed the connection]
schme has joined #ocaml
jlouis has joined #ocaml
Mr_Awesome has quit ["aunt jemima is the devil!"]
munga has quit ["Leaving"]
gabriel__ has quit ["leaving"]
Mr_Awesome has joined #ocaml
fradiavalo has joined #ocaml
middayc has quit [Read error: 104 (Connection reset by peer)]
middayc has joined #ocaml
mauke has joined #ocaml
middayc has quit []
_andre has joined #ocaml
<_andre>
hello
<_andre>
anyone using nethttpd_plex?
petchema has joined #ocaml
letrec has quit [Read error: 110 (Connection timed out)]
Cosmos95 has quit []
Yoric[DT] has joined #ocaml
<Yoric[DT]>
e
<Yoric[DT]>
hi again
letrec has joined #ocaml
tar_ has joined #ocaml
<tar_>
Is there a description of what types of optimizations ocamlopt attempts?
ttamttam has left #ocaml []
dramsay has joined #ocaml
seafood_ has quit []
ita has joined #ocaml
Stx has quit ["reboot."]
<tar_>
I coded a neural net which recursively evaluates output values. Will these values be re-evaluated needlessly, or are the return values cached for future calls?
RobertFischer has joined #ocaml
<fradiavalo>
Do any of you guys code in both ocaml and python?
<fradiavalo>
I would like to know how ocaml compares with python in terms of productivity once you know both languages very well
* Yoric[DT]
codes only a little in Python.
Yoric[DT] has quit ["Ex-Chat"]
<tar_>
I imagine I'd write my neural net in Python almost as I would in Ruby
<tar_>
The OCaml version was much faster for that because everything is recursively defined
<tar_>
(I meant to say that I _did_ write it in Ruby. Writing the OCaml version was faster, and I'm just learning it.)
AxleLonghorn has left #ocaml []
tar_ has quit ["byebye"]
<ita>
fradiavalo: i use both - if you like the python syntax try ocaml+twt
<ita>
fradiavalo: the static typing in caml helps a lot for large codebases (in python, one has to do the compiler's job)
authentic has joined #ocaml
pango has quit [Remote closed the connection]
<fradiavalo>
ita, thanks
<fradiavalo>
I have to check out twt
ttamttam has joined #ocaml
pango has joined #ocaml
<fradiavalo>
ita, does ocaml have an enhanced shell like ipython and array libs like numpy/scipy?
<fradiavalo>
sorry for noob questions, but I am sort of evaluating ocaml
ttamttam has left #ocaml []
<ita>
fradiavalo: yes and no - try it yourself
Snrrrub has joined #ocaml
RobertFischer has left #ocaml []
bluestorm has joined #ocaml
romanoffi has joined #ocaml
bluestorm has quit ["Konversation terminated!"]
authentic has quit [Remote closed the connection]
ygrek has joined #ocaml
filp has quit ["Bye"]
authentic has joined #ocaml
psnively has joined #ocaml
^authentic has joined #ocaml
Demitar has quit [Read error: 110 (Connection timed out)]
letrec has quit []
authentic has quit [Remote closed the connection]
postalchris has joined #ocaml
jderque has joined #ocaml
jlouis_ has joined #ocaml
olleolleolle has joined #ocaml
olleolleolle has quit [Remote closed the connection]
middayc has joined #ocaml
filp has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
<flux>
mfp, I suppose one nice thinf about sqlite support would be that it brings type checking into otherwise quite untyped sql system
<Snrrrub>
Is it fair to say that (x == y) implies (x = y)?
<flux>
yes
<Snrrrub>
Great, thanks!
<pango>
nope, x = y may also not terminate, for example
<flux>
true :)
<Snrrrub>
Ghmm. Good point.
<flux>
and for objects that are implemented with the C-interface a = a doesn't need to hold true
<thelema|away>
as long as (x=y) has a value, (x==y) implies (x=y)
thelema|away is now known as thelema
<flux>
(of course, that's broken semantics)
<flux>
hm, infact
<flux>
if the object is nan, that condition doesn't hold true
<flux>
nan == nan;;
<flux>
darn, xavierbot's gone
<Snrrrub>
flux, I just tried that. You're right, nan == nan but nan <> nan
<thelema>
I guess that's why we have two definitions of =
<thelema>
to confuse users maximally
<flux>
I would mind if physical equality was for example a function instead of an operator..
<flux>
phys_equal a b
<Snrrrub>
:) I think every language has its own interesting equality properties
<flux>
when you've coded in C for a while and come back to ocaml, it can make a == b look perfectly reasonable :)
ygrek has quit [Remote closed the connection]
<thelema>
flux: you mean structural equality should require a function call (as it's the heavyweight process)
ReachingFarr has joined #ocaml
<flux>
thelema, no, I would expect object identity to be a function
<flux>
it might be a slow process, but it's the common case; should be in a functional language anyway..
petchema has quit [Read error: 113 (No route to host)]
_andre has quit ["leaving"]
<flux>
the first step of a = b could be a == b; of course, if the objects are 'almost the same', it doesn't help
<thelema>
flux: iirc, that first step was tried, but it broke nan = nan, so it got removed
<flux>
thelema, good point. it would still work for objects implemented in "c-library", such as records, arrays, lists.. ?
<Snrrrub>
Hmm, floating point results are different between bytecode and native code. Is this expected?
<flux>
(I don't really know how = works, but the c-interface atleast provides the means to provide a custom comparator)
<flux>
maybe ocamlopt optimizes the calculation away
<Snrrrub>
I can see why this wouldn't produce "It's 1" on hardware - the bit representation of 1/3 is a problem in general. Fine.
<flux>
oh, right, ocamlopt gives the "wrong" answer
<thelema>
floating point comparisons *need* some amount of fudge factor.
<Snrrrub>
But is the VM supposed to emulate IEEE floating point or does it do its own thing?
<flux>
I would be really suprised if ocaml implemented ieee floating point numbers on its own
bluestorm has joined #ocaml
<thelema>
I expect it uses the FPU, same as ocamlopt. Maybe one of ocamlopt's optimizations... I dunno.
<Snrrrub>
thelema, true, but I guess the question I'm asking is what level of consistency does OCaml guarantee between bytecode interepreted and native execution (in this case w.r.t. floating point)?
<Snrrrub>
I suppose they could use softfloat...
<thelema>
on my computer, both say it's true.
<thelema>
err, it's 1
<thelema>
They try to set the FP flags on all archs for consistency
<thelema>
And there exists (at least in the developers minds, if not on paper) a standard for FP math in ocaml.
<thelema>
err, "paper"
pattern has quit [Remote closed the connection]
<thelema>
both ocamlopt and ocaml 3.09.2 and 3.10.2+dev2 on 64-bit intel
<Snrrrub>
:) I'd ask on the newsgroup but I think it would require a lot of work on the developers' end to document it for something that I'm just randomly curious about. It's not like I have any major numerical apps that I'm working on :)
<flux>
snrrrub, I think it could be investigated (by you?-)) if evaluation order can affect things
<flux>
(in ieee-math level)
<Snrrrub>
flux, good point.
dibblego has quit [Nick collision from services.]
dobblego has joined #ocaml
<flux>
snrrrub, I was thinking if you could run both the programs in some sort of a trace which would dump all the executed floating point instructions, but I don't think such a tool exists..
<flux>
qemu could be patched to do it I suppose :)
<pango>
I think I've read something about that quite some time ago... Something about fitting 80bits float registers into 64bits boxen, and native programs doing less boxing than bytecode ones, something like that
thelema has quit [Read error: 104 (Connection reset by peer)]
thelema has joined #ocaml
<postalchris>
Any LLVM enthusiasts in the house?
bongy has joined #ocaml
<flux>
I'm interested in it, but hardly an enthuasist :)
Yoric[DT] has joined #ocaml
<psnively>
Same here: I have, I think, a good idea for an LLVM project.
Cygal has joined #ocaml
<Yoric[DT]>
psnively: what kind ?
Le-Chuck_IT1 has joined #ocaml
Le-Chuck_IT1 has left #ocaml []
<psnively>
A denotational semantics for LLVM, in Coq.
jderque has quit [Read error: 113 (No route to host)]
<psnively>
Or perhaps using LLVM as a target for "A Very Modal Model of a Modern, Major, General Type System."
<flux>
I'm trying to use ocaml 3.10.1 with godi and its sexplib, and I'm getting erro Camlp4: Uncaught exception: DynLoader.Error ("/opt/stow/godi/lib/ocaml/pkg-lib/sexplib/pa_sexp_conv.cmo", "error while linking /opt/stow/godi/lib/ocaml/pkg-lib/sexplib/pa_sexp_conv.cmo.\nReference to undefined global `Pa_type_conv'") - any suggestions?
<jlouis_>
mmm, Coq! mmm Types!
<flux>
I'm using -pp "camlp4o -I `ocamlfind query sexplib` pa_sexp_conv.cmo"
<jlouis_>
mmm, Twelf!
<psnively>
Twelf! Gack. ;-)
<Snrrrub>
pango, thanks for that link!
<jlouis_>
psnively: Twelf is cool!
<psnively>
I know. I'm teasing, hence the wink.
<psnively>
There are lots of good tools: Twelf, Isabelle, Coq, PVS...
<psnively>
Coq feels most natural to me, maybe because I'm an OCaml programmer.
Cygal has quit ["leaving"]
<postalchris>
I'm looking at doing static analysis with LLVM via OCaml, but it looks like the bindings are woefully inadequate
<postalchris>
I'm wondering if anybody's actually written some OCaml code that calls into LLVM
<mfp>
flux: sexplib depends on type-conv... try w/ pa_type_conv.cmo pa_sexp_conv.cmo + appropriate -I for the former
ahf has quit [Read error: 104 (Connection reset by peer)]
ttamttam has joined #ocaml
^authentic has quit ["getting wasted"]
<Snrrrub>
Curious, what build system do most people use for OCaml projects? OMake?
<hcarty>
Snrrrub: I think it's split between OCamlMakefile, omake and ocamlbuild
<flux>
funny, this had compiled on an older ocaml: `Move ofs (`Surface idx)
<hcarty>
With several projects just using custom Makefiles
<flux>
now it gave an error about currified constructor
<flux>
(not surprisingly)
ahf has joined #ocaml
bongy has quit [Read error: 110 (Connection timed out)]
<flux>
mfp, thanks for the pointer. apparently I was too lazy to find it myself :)
Snark has quit ["Ex-Chat"]
Anarchos has joined #ocaml
<Anarchos>
i have a problem with the makefiles of the ocaml distrib
Morphous_ has quit ["shutdown"]
Amorphous has joined #ocaml
<thelema>
Anarchos: what problem?
Oatschool has quit [Read error: 104 (Connection reset by peer)]