<Smerdyakov>
flux, OK, but isn't it also some trouble to work with crappy programming languages?
<TFK>
flux, what language(s) do you write in at work (besides OCaml)?
<flux>
tfk, c, c++
<flux>
smerdyakov, well, it can be an inconvenience..
<flux>
smerdyakov, I guess the most trouble comes from debugging the old software written in C ;)
<Smerdyakov>
flux, working for someone else at all is an inconvenience. Apparently you found a price for it that inspires you to do it anyway.
<flux>
tfk, and the obvious ones: perl, sh
* TFK
<3 pointer arithmetic ^_^
<Smerdyakov>
It makes a joke?
xtacy[] has quit [Remote closed the connection]
<flux>
I almost blisfully forgot about java, that too..
|Lupin| has joined #ocaml
<|Lupin|>
Hello, there.
<TFK>
howdy
<|Lupin|>
Anybody willing to help with compiling Caml bindings for a C library in a proper and portable way ?
<Smerdyakov>
There aren't examples you can work from?
<|Lupin|>
Smerdyakov: I don't know actually
<Smerdyakov>
Maybe you should look first....
<|Lupin|>
any suggestion welcome
<|Lupin|>
the library I am working on consists of a C file and two Caml modules
<|Lupin|>
also, it comes from the same package as the C library it provides an interface too
<Smerdyakov>
No, I don't know anything about the subject.
<|Lupin|>
so when the Caml bindings are compiled, the -L flag it receives points at the compiled C lib, but the -L flag that should be used later should point to the installed lib
<|Lupin|>
(this is one of the issues)
Len1 has joined #ocaml
_andre has joined #ocaml
<_andre>
hello
<|Lupin|>
Hi.
<_andre>
when i define a function as "let f ~a = print_int a; raise Exit;;", if i call it without the label (e.g. "f 1;;"), i get this warning: "Warning X: this argument will not be used by the function."
<_andre>
why is that? (if i remove the "raise" statement, "f 1;;" works fine)
<Smerdyakov>
The argument you're passing is treated as an argument to "raise Exit".
<Smerdyakov>
Or, that's my guess.
<_andre>
hmm
<Smerdyakov>
Labeled and optional arguments make me suspicious, so I don't remember much about them. :)
<_andre>
it seems to be a problem only with 'raise' though (maybe because it causes the return value of f to be 'a?)
<Smerdyakov>
That's what I'm thinking, though I would say "return type" instead of "return value."
<_andre>
i meant to write "to be of type" :P
<flux>
I must admit that that looks like a bug to me :-o
<flux>
perhaps someone can explain what's happening
<_andre>
should i ask it at caml-list?
<flux>
maybe, just maybe, it is like a function a:int -> 'a, which can be interpreted to be for example a:int -> ('a -> 'b), which is the same as a:int -> 'a -> 'b, and the application without label applies it to the second parameter..
<flux>
but yeah, go ahead
<Smerdyakov>
This is a good example illustrating why labeled arguments are a bad idea. :P
<flux>
well, an obscure corner case I'd say.. labeled arguments are nice for currying, and optional ones nice for extending interfaces without breaking existing code.
tty56_ has joined #ocaml
tty56 has quit [Read error: 60 (Operation timed out)]
leo037 has joined #ocaml
tty56_ has quit [Read error: 110 (Connection timed out)]
<pango>
it seems to match the documented behavior "But beware that functions [...] whose result type is a type variable will never be considered as totally applied. [hence labels can't be omitted]"
<pango>
I don't know what's the reason for that, though
<flux>
I like my theory :)
leo037 has quit ["Leaving"]
<flux>
it apparently cannot be worked around either.. I thought adding a unit parameter would work, but no
schme has joined #ocaml
<pango>
yes, only using f ~a:1 works
<|Lupin|>
still no library compiling expert available ?