<HalfMadDad>
Hi Everyone. I am investigating ocaml. There is lots of documentation and I have found some on the FFI but is it easy to call ocaml from a C main ?
<ollehar>
HalfMadDad: no idea. google ocaml c api and read bottom at the manual.
<ollehar>
jpdeplaix: hey?
<HalfMadDad>
thanks ollehar . I can certainly do this do this and should, the thing is it may not give me an idea as to whether this is easy to use part. Opions are highly valued
<Drup>
HalfMadDad: I don't know about "easy" but it's possible
<Drup>
there is a special thing in ctypes for that
<HalfMadDad>
thanks Drup
ollehar has quit [Quit: ollehar]
bjorkintosh has quit [Quit: Leaving]
bjorkintosh has joined #ocaml
rgrinberg has joined #ocaml
ousado has quit [Ping timeout: 260 seconds]
HalfMadDad has quit [Quit: Leaving]
ousado has joined #ocaml
enamex has quit [Ping timeout: 240 seconds]
mac10688 has quit [Ping timeout: 240 seconds]
ygrek has joined #ocaml
darkf has joined #ocaml
ygrek has quit [Ping timeout: 272 seconds]
nicoo has quit [Ping timeout: 260 seconds]
johnf_ has joined #ocaml
samrat has joined #ocaml
mal`` has quit [Quit: Leaving]
lolisa has joined #ocaml
johnf_ has quit [Read error: Connection reset by peer]
uu_ has joined #ocaml
mal`` has joined #ocaml
ggole has joined #ocaml
shinnya has joined #ocaml
slash^ has joined #ocaml
enamex has joined #ocaml
shinnya has quit [Ping timeout: 264 seconds]
enamex has quit [Read error: Connection reset by peer]
enamex has joined #ocaml
MercurialAlchemi has joined #ocaml
uu_ has quit [Ping timeout: 244 seconds]
ontologiae has joined #ocaml
Algebr has joined #ocaml
ontologiae has quit [Ping timeout: 268 seconds]
<Algebr>
How can I get opam to give me the path of an ocaml executable from a package?
<Algebr>
something `opam config ..`?
psy_ has joined #ocaml
samrat has quit [Ping timeout: 265 seconds]
<Algebr>
okay, so opam config var <pkg>:bin is a start.
samrat has joined #ocaml
rgrinberg has quit [Ping timeout: 244 seconds]
enamex has quit [Read error: Connection reset by peer]
enamex has joined #ocaml
Algebr has quit [Remote host closed the connection]
samrat has quit [Ping timeout: 260 seconds]
enamex has quit [Ping timeout: 265 seconds]
ril has joined #ocaml
mort___ has joined #ocaml
ril has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ousado has quit [Read error: Connection reset by peer]
enamex has joined #ocaml
tmtwd has joined #ocaml
ousado has joined #ocaml
ousado has quit [Ping timeout: 250 seconds]
tane has joined #ocaml
mort___ has quit [Quit: Leaving.]
Kakadu has joined #ocaml
tmtwd has quit [Ping timeout: 244 seconds]
ousado has joined #ocaml
ousado has quit [Changing host]
ousado has joined #ocaml
ggole has quit [Read error: Connection reset by peer]
ggole has joined #ocaml
nicoo has joined #ocaml
samrat has joined #ocaml
ggole has quit [Read error: Connection reset by peer]
ggole has joined #ocaml
andrea has joined #ocaml
andrea is now known as Guest55729
ggole has quit [Ping timeout: 250 seconds]
<Guest55729>
hello, I have a question: all the packages in the OPAM repository are installable by OPAM?
<Guest55729>
def`: thanks, with that I tell opam to grab the package from the github repo directly
<def`>
yes
<Guest55729>
is this the practice to adopt if the package is not used by many?
ggole has joined #ocaml
gustav_ is now known as gustav1234x
gustav1234x is now known as gustav___
Haudegen has joined #ocaml
segmond has quit [Ping timeout: 240 seconds]
Kakadu has quit [Remote host closed the connection]
<def`>
Guest55729: not really, more the practice for development package
<def`>
I think this one will be published on main repo sonner or later, maybe it's worth contacting its author
AlexRussia has joined #ocaml
rand__ has joined #ocaml
tane has joined #ocaml
nullcatxxx_ has joined #ocaml
sagotch has joined #ocaml
<Guest55729>
def`: thanks a lot for your help!
<def`>
you're welcome
ril has joined #ocaml
xet7_ has quit [Ping timeout: 264 seconds]
xet7_ has joined #ocaml
samrat has quit [Ping timeout: 256 seconds]
samrat has joined #ocaml
samrat has quit [Remote host closed the connection]
ril has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tane has quit [Quit: Verlassend]
nyon is now known as nyon-zero-pyon-
sh0t has joined #ocaml
ericsmithvt has joined #ocaml
ericsmithvt has quit [Client Quit]
ericsmithvt has joined #ocaml
nyon-zero-pyon- has quit [Quit: F...ix you, Emacs.]
ely-se has joined #ocaml
nyon-zero-pyon has joined #ocaml
Guest55729 has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
ericsmithvt has quit [Ping timeout: 244 seconds]
nullcatxxx_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<enamex>
Is there any article/paper on why Ocaml places type variables before the name of the type constructor?
<enamex>
I know my questions have been very specific to this point but there's an important reason...
mort___ has joined #ocaml
iosys has quit [Quit: Leaving]
ontologiae has joined #ocaml
<mrvn>
Enamex: int list sounds better than list int.
<mrvn>
Only technical reason for it I can think of is that it might make the grammar simpler since it can build up the type from the inside out instead from the outside in.
<mrvn>
i.e. left vs. right associative
Submarine has quit [Ping timeout: 250 seconds]
ontologiae has quit [Ping timeout: 255 seconds]
ontologiae has joined #ocaml
mort___ has quit [Quit: Leaving.]
Submarine has joined #ocaml
<companion_cube>
mrvn: meh.
<companion_cube>
list int is as readable, and more consistent
<mrvn>
companion_cube: but doesn't sound so good
<companion_cube>
I don't read my code alourd
<mrvn>
'list of int' would sound good again
<companion_cube>
(int, string) Hashtbl.t doesn't sound good either
rand__ has quit [Quit: leaving]
<adrien>
companion_cube: we know you don't read it aloud: you're clearly not applying rubber duck debugging
<companion_cube>
I apply rubber duck debbuging within my head, with my other personalities
sagotch has quit [Ping timeout: 246 seconds]
<adrien>
but is one of these a rubber duck? if not it's not going to be very effective
<companion_cube>
let me ask them
<companion_cube>
is a wooden duck ok?
<flux>
I think many would agree, though, that it would in generally nicer if types worked the same as functions, ie. list int. but, too late to change ;)
<flux>
in fact didn't alternative ocaml syntax have that?
<companion_cube>
also, curried constructor syntax would be nice
<mrvn>
I wish for 'a 'b
rgrinberg has joined #ocaml
snyp has joined #ocaml
snyp has quit [Client Quit]
<def`>
this goes back to sml. I'd say one reason is that they don't have higher-kinded types
<def`>
So there is no application at type-level, just instantiation of type schemes.
<def`>
This might motivate a different syntax...
rgrinberg has quit [Ping timeout: 255 seconds]
<companion_cube>
it's ok, let's just hope the next ML™ will have a better syntax :-)
<def`>
If you find how to make hkt and modules behave well, syntax won't be a problem.
<companion_cube>
I'm counting on 1ML and Eff designers to do the research :)
<ggole>
I don't think 1ML tries to solve that one at all
iosys has joined #ocaml
s1n4 has quit [Quit: leaving]
<companion_cube>
well it should :p
<ggole>
My (pretty poor) understanding is that it's 'with' that causes the problem
<ggole>
You can have an abstract type that is only later found to be equal to some concrete type (due to with) and this ruins everything
sepp2k has joined #ocaml
<companion_cube>
yeah, type aliases that are abstracted
<companion_cube>
so unification inside the module is not the same as outside
<flux>
seems interesting, someone's adding ocaml support to lldb (llvm's debugger)
chinglish has joined #ocaml
chinglish has left #ocaml [#ocaml]
ely-se has quit [Quit: Leaving]
obadz- is now known as obadz
ely-se has joined #ocaml
rgrinberg has joined #ocaml
<ggole>
Typeful PPX and Value Implicits indicates a patch exists for curried constructors, companion_cube should be happy
rgrinberg has quit [Ping timeout: 240 seconds]
jbrown has quit [Ping timeout: 255 seconds]
jbrown has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 265 seconds]
snyp has joined #ocaml
LnL has joined #ocaml
mac10688 has joined #ocaml
jun has joined #ocaml
travisbrady has joined #ocaml
snyp has quit [Quit: WeeChat 1.3]
mort___ has joined #ocaml
rbocquet has quit [K-Lined]
rgrinberg has joined #ocaml
<Drup>
in 1ML, parametrized types are functions over a module containing only one type
<Drup>
so, yes, it solves the problem
<Drup>
(the problem of order of application and, to a certain extent, the problem of HKT)
oscar_toro has joined #ocaml
oscar_toro has left #ocaml [#ocaml]
ely-se has quit [Quit: Leaving]
snyp has joined #ocaml
<rgrinberg>
Drup: maybe if opa is revived on top of 1ML it will be a resounding success :P
<Drup>
eh
<rgrinberg>
just think of how much better than js it will be...
<Drup>
everything is much better than js at doing what js is doing
shinnya has joined #ocaml
travisbrady_ has joined #ocaml
travisbrady has quit [Ping timeout: 240 seconds]
travisbrady_ is now known as travisbrady
travisbrady has quit [Client Quit]
Topher512 has joined #ocaml
ely-se has joined #ocaml
JuggleTux has joined #ocaml
travisbrady has joined #ocaml
rbocquet has joined #ocaml
Topher512 has quit [Quit: This computer has gone to sleep]
sagotch has quit [Quit: Page closed]
native_killer has joined #ocaml
xet7_ has quit [Ping timeout: 250 seconds]
BitPuffin|osx has joined #ocaml
Topher_ has joined #ocaml
snyp has quit [Quit: WeeChat 1.3]
tmtwd has joined #ocaml
mort___ has quit [Quit: Leaving.]
Topher_ has quit [Quit: This computer has gone to sleep]
tane has joined #ocaml
cthuluh has quit [Ping timeout: 240 seconds]
Haudegen has quit [Ping timeout: 246 seconds]
<mfp>
rgrinberg: still interested in the closure leak detector?
<companion_cube>
sounds interesting, what is it?
<ggole>
Is this the "space safety" problem that the ML people went through a while back?
<mfp>
a hack to collect the (code) addresses of closure blocks in the OCaml heap, take deltas and infer which closures are being leaked
<mfp>
useful for instance to locate leaks w/ lwt
<ggole>
Oh, neat
<companion_cube>
I wonder, is it related to the hack done by ocamlpro for their memory profiler
<ggole>
Hmm, how do you do that for things like caml_curryN?
* mfp
might as well put it in github instead of pastebin'ing it
<ggole>
I guess there are a fixed number you could check for
MercurialAlchemi has joined #ocaml
<mfp>
got caml_curryN half working by looking recursively for pointers to code in closure blocks (in addition to the Code_val)
<mfp>
I found my leak w/o that, though, so that part is not entirely functional (it sometimes segfaulted/didn't terminate, so just limited recursion at first and the disabled)
<mfp>
companion_cube: ocamlpro's stuff stores the allocation point in the header (it's got way more bits for block size than needed)
<ggole>
Of course, you don't need a precise map if you can analyse the pointers
<mfp>
my hack just collects closure (code) addresses, but even just that is of some use
Haudegen has joined #ocaml
<mfp>
k, dropping it to github w/o build sys
travisbrady has quit [Quit: travisbrady]
<ggole>
It'd be nice to have a standard way to traverse the heap with full type info (where possible)
<Drup>
ggole: ocp-memprof ...
<ggole>
No, I mean programmatically
<Drup>
Oh
<ggole>
So you can write heap-grep that scans the heap looking for values that match a type, that kind of thing
<mfp>
Drup: ocp-memprof segfault'ed on me when I tried to run it on code using lwt :-|
<ggole>
I think that there is a runtime cost in some cases though :(
<Drup>
ggole: I guess you assume runtime types ?
cthuluh has joined #ocaml
<ggole>
The method I was thinking of is more like the tagless GC stuff: put (GADT-like) type info off to one side
<ggole>
Then use maps which annotate the type structure of the static parts of the program + the stack
<ggole>
That's... sort of like runtime types if you squint
<mrvn>
DWARF debug format can cover that.
<ggole>
But like tagless GC, you run into trouble: polymorphic functions don't know the type of their arguments
<mrvn>
ggole: and they shouldn't.
<ggole>
The tagless GC proponents argue that you can walk up the stack and look at the caller, but with TCE the caller may not exist any more
<rgrinberg>
mfp: yeah
<ggole>
I don't know how to solve that problem without a (significant?) runtime hit
<mrvn>
ggole: ocaml only needs those infos because some types have a optimized memory structure, e.g. float arrays.
<ggole>
Yes, but a putative type revealing heap-walking library would need "full" type info
mort___ has joined #ocaml
<mrvn>
ggole: they also need the full type, not just the GC tags.
<ggole>
No, there's no difference between type r = { x : int; y : float } and int * float at runtime
<ggole>
(Or did I misunderstand what you were saying there?)
<mrvn>
ggole: but if you are searching to a type r { x=1; y=1.0; } you don't want it to find (1, 1.0)
snyp has joined #ocaml
<ggole>
mrvn: yeah :(
<mfp>
rgrinberg: pushed
<ggole>
So you need full type info, and there's a cost for that
<ggole>
Which is why I'm sad
<companion_cube>
I wish flambda will eliminate: 1/ variants with 1 case, records with 1 field 2/ record fields of type unit
<mrvn>
So on the heap you have to save a type info for every type. So the tag becomes a unique type ID or pointer to the type info.
<ggole>
The problem is that type info isn't static
<mrvn>
In most cases and on 64bit there are probably enough spare bits in the header to cover all used types.
travisbrady has joined #ocaml
<ggole>
You can have a function 'a -> 'b -> 'a * 'b and where do you get the right type info for 'a * 'b for the result of a given application?
<ggole>
You have to concatenate type records at runtime :/
<ggole>
(As far as I know.)
<mrvn>
ggole: you create it from typeof('a) and typeof('b)
<mfp>
rgrinberg: no build sys and don't remember in which state I left it exactly (I added non-Code_val pointer collection too and limited/removed at some point due to segfaults)
<ggole>
mrvn: this is possible, it's the 'intensional polymorphism' stuff that Harper and those guys did back in the day
<ggole>
And there's a considerable performance hit
johnf_ has joined #ocaml
<ggole>
In particular, I believe you take the hit even with phantom types, the abstractions for which would no longer be free.
<mrvn>
ggole: problem is then you have to use a pointer and allocate them on the fly. That increases all your data. Or you memorize them but that costs more cpu time.
<ggole>
Right.
<ggole>
like I said, I don't know of a solution that doesn't have such a runtime cost.
native_killer has quit [Quit: Leaving]
<mrvn>
You might be able to lift that 'a*'b type into into the calling function and have it pass a static block.
<mrvn>
tope level functions could end up having to pass quite a lot of typoe infos then though.
Haudegen has quit [Ping timeout: 246 seconds]
<ggole>
Yeah. And I'm not sure that you could cover polymorphic recursion with such a scheme.
<mrvn>
ggole: i don't think the type could change in the recusion so that would be a closed set. GADTs might be trickier.
ollehar has joined #ocaml
sh0t has quit [Ping timeout: 252 seconds]
<mrvn>
With GADTs you have dynamic runtime types and then you have to construct the combined types on the fly or store them dynamically in the witness part of the GADT.
<ggole>
Maybe having a special execution mode that runs slower but allows perfect reconstruction would be the way to go.
<mrvn>
ggole: For that I would just increase all data and store the type infos in them as pointers.
Algebr has joined #ocaml
<mrvn>
doesn't the toplevel already do that at least for the toplevel functions and values?
meiji11 has joined #ocaml
<ggole>
It keeps type info for bindings, yeah
<ggole>
You can see it breaking down by hiding the types behind sigs, whereupon all the printing stuff will stop working properly
Haudegen has joined #ocaml
<mfp>
rgrinberg: ok, now builds (manually :P) and should be functional as-is. The idea is to run addr2line on the reported pointers and figure out where the closure code lies, which fortunately usually matches the allocation site
jao has joined #ocaml
travisbrady has quit [Quit: travisbrady]
johnf_ has quit [Read error: Connection reset by peer]
rgrinberg has quit [Ping timeout: 252 seconds]
ontologiae has joined #ocaml
JuggleTux has quit [Ping timeout: 240 seconds]
sepp2k has quit [Quit: Leaving.]
empyrean has joined #ocaml
zpe has joined #ocaml
AlexRussia has quit [Ping timeout: 268 seconds]
<ely-se>
"Parametric polymorphism, sometimes called method overlaoding, allows methods within a class to have the same method name, differing in the number and type of parameters"
<ely-se>
this makes no sense, right?
<companion_cube>
this is bullshit indeed
<ely-se>
I got it from the COBOL 2014 standard draft.
<companion_cube>
hu
<cmtptr>
makes sense to me
<ggole>
Seems like a thinko: surely they meant "ad-hoc" instead of "parametric"
<companion_cube>
yep
<ggole>
With that substitution it seems to make a reasonable amount of sense
<companion_cube>
and even then it's not linked to "methods"
<ely-se>
yeah, it says elsewhere: "COBOL supports three types of polymorphism: class polymorphism, ad-hoc polymorphism and parametric polymorphism"
<ely-se>
but that's the only mention of ad-hoc polymorphism
<ely-se>
companion_cube: well in COBOL it is
<ely-se>
you can't overload functions and programs, only methods
swgillespie has joined #ocaml
<companion_cube>
what a joy this language must be
<ggole>
Hmm, method overloading isn't the usual OO meaning of "polymorphic" indeed
<ely-se>
well, what a joy implementing this language must be if the only free document that is similar to the standard contains such mistakes ;_;
<companion_cube>
why do you inflict such pain upon yourself?
<ggole>
Are you writing a COBOL implementation?
shinnya has quit [Ping timeout: 240 seconds]
* ggole
looks at the date
<ely-se>
yes
<ggole>
Nice
sh0t has joined #ocaml
<ely-se>
For this weekend I planned to write a text-based adventure game, each function in a different programming language. But I couldn't get GnuCOBOL to work on my machine (because Windows is crap), and I don't use proprietary language implementations, so I figured I had to write my own COBOL implementation first.
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Drup>
(ok, he's french, but the reference to the french mascot is a by product, afaik)
<companion_cube>
also, coc
<MercurialAlchemi>
yeah, another goddamn pun, what did expect?
<MercurialAlchemi>
"you expect"
<Drup>
MercurialAlchemi: :D
<MercurialAlchemi>
:)
<Drup>
The Coq ecosystem adapted well and kept doing innuendos in various library names.
<companion_cube>
OCaml does that too
<flux>
hmm, the Coq wikipedia page says it has bits of C as well. whatever for?
<companion_cube>
it uses the OCaml virtual machine for execution, in some cases
<flux>
and comes with its own ocaml vm?
rgrinberg has quit [Ping timeout: 240 seconds]
<flux>
or incorporates a copy of ocaml's?
rgrinberg has joined #ocaml
<companion_cube>
I don't knwo the details :)
<companion_cube>
hmm, I have to think about what I need to add to containers
darkf has quit [Quit: Leaving]
tane has quit [Quit: Verlassend]
psy_ has joined #ocaml
Haudegen has quit [Ping timeout: 260 seconds]
johnf_ has joined #ocaml
jao has quit [Ping timeout: 240 seconds]
Haudegen has joined #ocaml
Algebr has joined #ocaml
<Algebr>
I have a straight up insane issue, writing bindings and adding new function, get this error: error: use of undeclared identifier 'caml__frame'; did you mean 'caml_raise'?
<Algebr>
on usage of CAMLreturn in this function, been using CAMLreturn fine else where.
<ollehar>
Algebr: forgot CAMlparam0 ?
<mrvn>
forgot to include something?
tnguyen has quit [Quit: tnguyen]
<Algebr>
this function just gets void, no param, will try CAMLparam0. mrvn everything else is working using CAMLreturn
<Algebr>
ollehar: yep, CAMLparam0 did the trick.
<ollehar>
Algebr: check the def of that macro, it inserts the stack frame (or whatever the hell it's called)
<Algebr>
ollehar: yep! just found it struct caml__roots_block *caml__frame = caml_local_roots
<Algebr>
nice one, thanks!
<ollehar>
yey, I contributed!
Algebr` has joined #ocaml
Algebr has quit [Read error: Connection reset by peer]
ggole has quit []
Sorella has joined #ocaml
ollehar has quit [Ping timeout: 272 seconds]
<Algebr`>
What can I do in this situation? I want to use caml_alloc_custom and I need to take a sizeof of the object I want to box up, but the library that this object comes from doesn't expose the internals of and so on sizeof(*thing) I get a compiler error of sizeof being used on incomplete type
zpe has quit [Remote host closed the connection]
Haudegen has quit [Ping timeout: 260 seconds]
<mrvn>
you box up the pointer
<mrvn>
That thing probably wouldn't like it when the GC moves it anyway.
<Algebr`>
what do you mean
<Algebr`>
oh you mean another layer of indirection
<mrvn>
not another, just one.
<Algebr`>
what do you mean? I have this caml_alloc_custom(&custom_thing, sizeof(*foo), 0, 1) where foo is a typedefed pointer.
<mrvn>
and you remove the * to make it indirect
<Algebr`>
but now I am only making enough space for the pointer
<mrvn>
and you only put the pointer in there
rgrinberg has quit [Ping timeout: 264 seconds]
<Algebr`>
but now segfaulting when used, memcpy(Data_custom_val(custom_thing), &foo, sizeof(foo));
<Algebr`>
<mrvn>
Data_custom_val(custom_thing) = foo?
<mrvn>
or *Data_custom_val(custom_thing) = foo, can't remember