maskd has quit [robinson.freenode.net irc.freenode.net]
maskd has joined #ocaml
yminsky has joined #ocaml
ulfdoz_ has joined #ocaml
ulfdoz has quit [Read error: 60 (Operation timed out)]
ulfdoz_ is now known as ulfdoz
Mr_Awesome has quit [Remote closed the connection]
Alpounet has quit ["Leaving"]
Amorphous has quit [Connection timed out]
Amorphous has joined #ocaml
tmaedaZ is now known as tmaeda
willb has joined #ocaml
h3r3tic has quit ["Segmentation Fault"]
flux has quit [Read error: 104 (Connection reset by peer)]
jeddhaberstro has quit [Client Quit]
verte has joined #ocaml
Mr_Awesome has joined #ocaml
<thelema>
I can't figure why backtraces aren't on by default.
<thelema>
Just like array bounds checking. It has a cost, but it's totally worth it.
<orbitz>
as in stack traces?
<thelema>
And when it's not, turn it off.
<thelema>
yes, as in stack traces
<orbitz>
does it significantly slow down exceptions? ocaml uses them in a lot of ways that are too expensive in most languages
<thelema>
I don't know.
<thelema>
it does - I don't know by how much. Time for another micro benchmark
<orbitz>
ocaml uses exceptions in a lot of places i wish it used options
<thelema>
orbitz: there's a movement to option-ize the stdlib in batteries
<orbitz>
sounds like something I can get behind
<orbitz>
see the release of Core 0.6.0 today?
<thelema>
yes. I got working on aaa a little bit because of it.
<thelema>
not enough. and it's late.
<orbitz>
wil there be a good reason to use AAA over Core?
<thelema>
yes - no dependencies on pcre, type_conv, sexplib, bin-prot and fieldslib
thrasibule has quit [Read error: 131 (Connection reset by peer)]
thrasibule has joined #ocaml
ski_ has joined #ocaml
<palomer>
what's AAA?
<orbitz>
skinny version of Batteries
ski_ has quit [Client Quit]
seanmcl has quit []
ski_ has joined #ocaml
caligula_ has joined #ocaml
nickgibbon has joined #ocaml
caligula__ has quit [Read error: 110 (Connection timed out)]
nickgibbon has left #ocaml []
jimmyb2187 has quit [Read error: 110 (Connection timed out)]
kaustuv_` has joined #ocaml
flux has joined #ocaml
thrasibule has quit [Read error: 110 (Connection timed out)]
kaustuv_ has quit [Read error: 110 (Connection timed out)]
ulfdoz has quit [Read error: 110 (Connection timed out)]
ttamttam has joined #ocaml
ttamttam has quit ["Leaving."]
jimmyb2187 has joined #ocaml
morse has joined #ocaml
morse is now known as valross_
Mr_Awesome has quit [Read error: 104 (Connection reset by peer)]
verte has quit ["~~~ Crash in JIT!"]
ttamttam has joined #ocaml
ikaros has joined #ocaml
_zack has joined #ocaml
valross_ has quit ["Ex-Chat"]
ikaros has quit ["Leave the magic to Houdini"]
boringwall has joined #ocaml
ikaros has joined #ocaml
julm has joined #ocaml
f[x] has joined #ocaml
<boringwall>
((int -> int) -> bool) -- Does this mean a function that takes in an integer returning function as a parameter and itself returns a boolean value?
<flux>
a function that returns a boolean. it takes a function that takes an integer and returns an integer.
<flux>
ah, reparsing your message, indeed yes :)
<flux>
hm, or not
onigiri has quit []
<flux>
no "returning function" is occurring here
<flux>
(a -> b) is a function from a to b
<flux>
so (xxx -> bool) is a function that takes something and returns a bool
<flux>
that xxx in this case is (int -> int), which is a function from integers to integers
<flux>
but otherwise.. well, if postscript was great, the factor is surely even more great :)
<kaustuv>
I used Forth in an earlier life when I was working with Open Firmware on Sparcs
<kaustuv>
Someone who comments on reddit should mention that Batteries has unicode ropes (to counter slava's point that ocaml doesn't have a unicode string type)
<flux>
I've somehow broken my javascript for reddit :)
<flux>
and the site's slightly limited without it.. I must've disabled it somehow when they had the attack, but.. :)
hkBst has joined #ocaml
<thelema>
flux: Foo could be the result of functor application.
<rwmjones>
forth is fscking crazy, and I say that as the author of a forth compiler myself
* Camarade_Tux
is wating for slava to say what he thinks "int**" is (the question is pretty broad on purpose :) )
<_andre>
anyone got this while compiling Core? "Error: Unbound module Bin_prot.Utils.Make_iterable_binable1"
<flux>
missing d?
<_andre>
i have bin-prot installed
<_andre>
hmm
<_andre>
although not the latest version
Ched has joined #ocaml
<flux>
I mean missing 'd'-letter in the source
<rwmjones>
markus like to upgrade those libraries every week (or that's how it feels anyway)
<flux>
well, I suppose binable makes sense too
<flux>
in this context
petchema_ has quit [Remote closed the connection]
<_andre>
yeah it was the version
<Camarade_Tux>
regarding ffi, automated bindings don't have a nice api so they're not very interesting
<Camarade_Tux>
anyway
<flux>
camarade_tux, hm?
<_andre>
but you could write wrappers for the automated bindings
<Camarade_Tux>
_andre: which means you end up writing code for the bindings anyway ;)
<Camarade_Tux>
flux: keep in mind I'm also a bit too obsessed about glib2/gtk/friends ;p
<_andre>
sure... i guess the idea is just to avoid having to write C
<flux>
what is this ffi discussion about?-)
<flux>
in any case, I would like to see an ffi binding genrator library. I think camarade_tux is working on somthing like that?-)
<Camarade_Tux>
I found out you don't need much C actually, it's a bit hard at the beginning but you quickly find out it's easy
<Camarade_Tux>
flux: slava pestov saying ocaml has no ffi
<flux>
camarade_tux, oh. how does he think ocaml integrates with C libraries then?
<Camarade_Tux>
flux: hmmm, who is doing that? me? :P
<Camarade_Tux>
flux: good question ;)
<flux>
maybe slava is just means something different
<flux>
for example that to integrate C libraries you must write some glue in C, that is, you cannot do it in pure O'Caml
<Camarade_Tux>
but I think people on reddit don't have the same definition of "FFI", slava probably means "completely automated"
<mfp>
Camarade_Tux, flux: he's basically referring to some high-level wrapper for dlopen/dlsym
<flux>
except for very trivial functions, double -> double or something
<mfp>
w/ support for more complex types like structs and such
<flux>
hey that sounds nice, who's writing it :P
<Camarade_Tux>
mfp: I still have to find a way to figure out C structs without parsing the header files...
<flux>
the thing is that integrating C code with struct often requires parsing the structs the same way as a C compiler would, complete with padding etc
<Camarade_Tux>
and maybe reordering
ski_ has quit ["Lost terminal"]
<flux>
not to mention integrating C++..
<Camarade_Tux>
well, it could be easier because it has more types
<flux>
a C code generation library would go a long way for building, say, camlp4 bindings that generate the bindings with some description, embedded in your code
<hcarty>
For (simple) C, camlidl produces fairly nice results.
<mfp>
Camarade_Tux: a FFI, as per slava's def, would require that you specify the types using OCaml code --- it doesn't involve parsing .h files
<flux>
hcarty, but when you hit the wall, you hit the wall hard
<mfp>
flux: yes, that's the sort of thing he's referring to
<Camarade_Tux>
like int* can be 'int array' or an int passed by address or ... an out parameter but in C++, you should/could/would really have some type for that
<Camarade_Tux>
I'm not convinced about this kind of ffi, probably because I don't think it will work for any library
<flux>
this doesn't look that bad: dlsym_t dll "print_string" (string_t @-> int_t)
<mfp>
yeah that dlopen thingy looks interesting
<flux>
let struct_t = record4_t (char_t, mutable_t int_t, char_t, float_t) in let set_tuple = dlsym_t dll "set_tuple" (star_t (mutable_t struct_t) @-> int_t) in ..
<hcarty>
orbitz: All or almost all of the modules in Batteries have an "Exceptionless" sub-module which can be used to remove non-fatal exceptions from the module
<mfp>
Camarade_Tux: I'm not fond of it either, because you never compiler against the headers and lose the (loose) checking performed by the C compiler you'd get with regular stubs
<mfp>
*compile
<orbitz>
hcarty: cool
<Camarade_Tux>
and also because gobject-introspection which I'm using aims at that for python (and maybe others) and I find it just doesn't work well
<Camarade_Tux>
like it changs the arity of functions...
<Camarade_Tux>
*changes
<hcarty>
orbitz: It brought me around to making my code "exceptionless" and I've been quite happy with the results
<flux>
interfacing with linux iptables system with that kind of system would be a bitch
<flux>
you need everything properly aligned etc
<flux>
I suppose it's not that simple even from C, though :)
<orbitz>
hcarty: same, i prefer to explitily be able to ignore an error via a | _ -> then to not know that i am wtih an exception
<orbitz>
i specially hate that they chose an exception for EOF it make writing pure code a bitch since you need to manually wrap all your reads ina n option
<flux>
orbitz, yes. a file ending is not really an exceptional condition :/
<orbitz>
yeah
<Camarade_Tux>
mfp: thanks for the link
<flux>
mfp, that's great.. what happens when a new version is not binary compatible with the previous one? ..
<mfp>
FUNCTION: XmpFilePtr xmp_files_open_new ( char* , XmpOpenFileOptions options ) ; after TYPEDEF: void* XmpFilePtr --- essentially the same thing as the dlopen stuff found by flux, with combinators to define stuff
<Camarade_Tux>
mfp: now that I've opened it, I wish I hadn't... my eyes! :o
<mfp>
flux: boom, I guess, that's what I dislike about this sort of FFIs, as I said
<Camarade_Tux>
(I'm not sure it's because of the ffi or because of factor)
<mfp>
w/ stubs at least cc will catch some changes
<Camarade_Tux>
and when a function gets removed? :)
<mfp>
Camarade_Tux: failing to compile is fine by me, that's something you can fix easily. Crashes, not so much.
<hcarty>
Although they "cheat" and let LLVM do the work.
<mfp>
hcarty: pure is like a simplified Haskell with a diff evaluation discipline and macros?
<Camarade_Tux>
on http://paste.factorcode.org/paste?id=422 , the perl script that generated everything is really unreliable, well, it parses C with regexps, that probably says it all
<hcarty>
mfp: It's based on... I think term rewriting is the name
<hcarty>
mfp: It's superficially similar to Haskell, but from my limited experience it seems equidistant from both Haskell or OCaml
<_andre>
mfp: iirc it doesn't have strong typing
<hcarty>
No, no strong tying
<hcarty>
typing
<mfp>
Camarade_Tux: hah, I think the idea is to write the FFI decls manually (the Perl generator is a one-time thing)
<hcarty>
Though it can be forced
<flux>
camarade_tux, but it's library-specific, it doesn't have to be robust
<Camarade_Tux>
mfp: yeah, I think so too
<Camarade_Tux>
flux: it's C, you never know what could happen ;p
<flux>
I'm yet to see the quotations for C, even though that one white paper references to them
bzzbzz has joined #ocaml
<Camarade_Tux>
like a "long int" <- type with two words
<hcarty>
Camarade_Tux: You should see the evil code used to prep the PLplot headers for consumption by camlidl - handling things like two-word types makes for some ugly regexps.
<flux>
hcarty, so you use camlidl for plplot? how was that?
<Camarade_Tux>
hcarty: yeah, I've been there too ;)
<hcarty>
flux: It saves me a huge amount of time
* Camarade_Tux
should write a book to serve as horror stories for grandchildren :P
<hcarty>
flux: And it's easy enough to wrap the problem functions by hand
<Camarade_Tux>
hcarty: aren't there some cases you can't use it?
<hcarty>
flux: My biggest complaint at this point is that it imposes an extra compile-time requirement
<hcarty>
Camarade_Tux: I don't think it handles (void *) very well
<flux>
hcarty, and that's not that big a complaint IMO
<flux>
has anyone tried using olmar for something?
<hcarty>
flux: No, I
<flux>
(elsa+olmar is bloody 50 megabytes, compressed! :-o)
<hcarty>
flux: Ack... small keyboard! I've been happy with it overall.
<Camarade_Tux>
hcarty: I've tried camlidl and I think there were some types it didn't play nicely with
<hcarty>
flux: Much better than not having camlidl
<Camarade_Tux>
flux: what is o.. oh, I see :P
<hcarty>
Camarade_Tux: Almost everything in PLplot is one of : string, int, double or a pointer to one of these
<flux>
bah, my g++ doesn't anymore have iostream.h, and elsa's test doesn't cope with that
<hcarty>
Camarade_Tux: So it works well for this particular library. I've used it for HDF4 as well, and it was helpful there but I had to manually wrap more since it uses a lot of void*
<Camarade_Tux>
flux: I'll maybe kill gobject-introspection for ocaml-gir and use frama-c instead, which means I could also try with elsa
<Camarade_Tux>
hmm, how would elsa parse a C source?
<flux>
pretty I suppose nicely. IIRC they boast being able to parse Linux.
<Camarade_Tux>
flux: I'll maybe try elsa instead then
<hcarty>
CIL seems like it would be a good base for a FFI generator. But I thought the same about Frama-C and was told otherwise by folks who know more about this than me.
<flux>
what c parsers are there for ocaml?
<hcarty>
CIL, Frama-C and I think at least one other.
<Camarade_Tux>
hcarty: not really, it's pretty hard to use
<flux>
cil doesn't compile with -j3, a bad sign ;)
<Camarade_Tux>
it aims at preserving the style of the source, not to give you something in a nice and usable format
<Camarade_Tux>
flux: ocaml doesn't either on windows ^^
<mfp>
hcarty: 2 more, one which is in GODI (don't remember the name) and Yacfe
<Camarade_Tux>
well, not always
<flux>
CIL doesn't come with META, bah
<hcarty>
mfp: Frontc perhaps... I think that builds on top of CIL but I'm not sure.
<Camarade_Tux>
hmm, it was maybe rather yacfe that tried to keep the style of the source...
<hcarty>
flux: CIL has an ugly build system from what I remember. It seemed very fragile.
<Camarade_Tux>
and I'm also maybe mixing frama-c and frontc, there are too many C parsers in ocaml ;p
* Camarade_Tux
should check his old pieces of code
<mfp>
IIRC Frama-C used CIL, FrontC is yet another parser
<Camarade_Tux>
but considering frontc's homepage is dead, I was probably using frama-c (plus I remember it was from the CEA)
<flux>
a project with that long url to its home page cannot be good.. :P
<Camarade_Tux>
he
<Camarade_Tux>
I think I had the url to the previous homepage
<Camarade_Tux>
anyway, gotta go, laterz :)
<flux>
frama-c indeed includes CIL
ttamttam has joined #ocaml
Snark has quit ["Ex-Chat"]
<flux>
I suppose if someone's written a library on top of CIL, it's bound to be more high-level somehow :)
<flux>
frama-c apparently isn't a library anymore
<flux>
but you can write plugins for it
seanmcl has quit []
robocop has joined #ocaml
mishok13 has quit [Read error: 60 (Operation timed out)]
Alpounet has quit ["Leaving"]
<Camarade_Tux>
while walking, I remembered two things: first you usually have to support everything just to support one thing and, I've forgotten the second one :)
julm_ has joined #ocaml
seanmcl has joined #ocaml
julm has quit [Read error: 60 (Operation timed out)]
Gooffy has left #ocaml []
julm has joined #ocaml
kaustuv_ has joined #ocaml
julm__ has joined #ocaml
julm has quit [Read error: 104 (Connection reset by peer)]
waleee has quit ["Lost terminal"]
ttamttam1 has joined #ocaml
kaustuv has quit [Read error: 110 (Connection timed out)]
ttamttam2 has joined #ocaml
julm_ has quit [Read error: 113 (No route to host)]
_zack has quit ["Leaving."]
ttamttam has quit [Read error: 110 (Connection timed out)]
ttamttam1 has quit [Read error: 110 (Connection timed out)]