NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
boogie has quit [Remote host closed the connection]
studybot_ has quit [Remote host closed the connection]
racycl___ has quit [Quit: ZZZzzz…]
shinnya has quit [Ping timeout: 252 seconds]
WraithM has quit [Quit: Lost terminal]
q66 has quit [Quit: Leaving]
eikke__ has quit [Ping timeout: 245 seconds]
rgrinberg has joined #ocaml
alpounet has joined #ocaml
alpounet has quit [Ping timeout: 264 seconds]
inf-groupoid has quit [Quit: brb]
pyon has joined #ocaml
tlockney_away is now known as tlockney
studybot_ has joined #ocaml
ygrek has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
ollehar has quit [Ping timeout: 240 seconds]
jao has quit [Ping timeout: 240 seconds]
jpdeplaix has quit [Ping timeout: 252 seconds]
huza has joined #ocaml
jpdeplaix has joined #ocaml
racycle_ has joined #ocaml
BitPuffin has quit [Ping timeout: 252 seconds]
ThatTreeOverTher has quit [Remote host closed the connection]
studybot_ has quit [Remote host closed the connection]
NoNNaN has quit [Remote host closed the connection]
studybot_ has joined #ocaml
NoNNaN has joined #ocaml
agarwal1975 has quit [Quit: agarwal1975]
WraithM has joined #ocaml
WraithM has quit [Client Quit]
WraithM has joined #ocaml
WraithM has quit [Ping timeout: 240 seconds]
frankbro has joined #ocaml
<frankbro>
Anyone here uses vim with merlin and syntastic? Every opens are marked as an error and also every types defined in them. However, it compiles properly with my makefile. Does anyone know how to fix this?
BitPuffin has joined #ocaml
axiles has joined #ocaml
<def`>
frankbaro: you need a .merlin look at the dlcumentation
<def`>
frankbro: ^
<frankbro>
def`, oh wow I missed that part, now I feel silly. Thank you.
philtor_ has joined #ocaml
<def`>
np
huza has quit [Quit: WeeChat 0.3.8]
tnguyen has joined #ocaml
tlockney is now known as tlockney_away
philtor_ has quit [Ping timeout: 252 seconds]
frankbro has left #ocaml ["But no matter how many fish in the sea, it'd be so empty without me.... "]
rand000 has joined #ocaml
tnguyen has quit [Ping timeout: 240 seconds]
rand000 has quit [Ping timeout: 240 seconds]
racycle_ has quit [Quit: ZZZzzz…]
Simn has joined #ocaml
ygrek has quit [Ping timeout: 252 seconds]
huza has joined #ocaml
alpounet has joined #ocaml
Submarine has joined #ocaml
rand000 has joined #ocaml
michael_lee has joined #ocaml
araujo has quit [Quit: Leaving]
yacks has quit [Ping timeout: 240 seconds]
yacks has joined #ocaml
rand000 has quit [Ping timeout: 252 seconds]
Submarine has quit [Remote host closed the connection]
AltGr has joined #ocaml
cago has joined #ocaml
gasche has joined #ocaml
eikke__ has joined #ocaml
ygrek has joined #ocaml
ggole has joined #ocaml
hhugo has joined #ocaml
ollehar has joined #ocaml
thomasga has joined #ocaml
eikke__ has quit [Ping timeout: 265 seconds]
thomasga has quit [Client Quit]
<gargawel>
Hi
<companion_cube>
hi
<gargawel>
Does anyone have experience passing file descriptors from/to C with ctypes ?
<gargawel>
Say I don't care about Windows (the library I'm writing bindings for is not Windows-compatible anyway)
<gargawel>
can I just treat Unit.file_descr as the OCaml equivalent of FILE * ?
<companion_cube>
I have no idea
<companion_cube>
isn't a basic file descriptor just an int?
thomasga has joined #ocaml
<companion_cube>
I'm not sure Unix uses the fopen-style operators under the hood
<gargawel>
Humm
<companion_cube>
but you should ask competent people :3
<gargawel>
stdio.h suggests FILE is actually a struct, not sure what it contains
<companion_cube>
it's abstract anyway
<companion_cube>
in ctypes you should always use a FILE*, never a FILE
ygrek_ has joined #ocaml
<whitequark>
gargawel: why do you want to use FILE* and not just unix fds?
<gargawel>
whitequark: because that's what the library uses...
<gargawel>
anyway, stdin, stdout and stderr are defined as FILE*
<whitequark>
they're also fds 0, 1 and 2
<whitequark>
but ok
ygrek has quit [Ping timeout: 240 seconds]
<gargawel>
I should have said "file handles" and not "file descriptors"
<gargawel>
the file handle is a pointer to a struct containing the descriptor, among other things (read/write pointers, etc.)
<adrien_oww>
gargawel: FILE * is not a "file descriptor"
<gargawel>
Unix.file_descr is indeed an int, not a FILE *
<adrien_oww>
file descriptor is an integer
<gargawel>
adrien_oww: Yeah, that's what I just realized
<adrien_oww>
FILE is a structure used by the libc
<adrien_oww>
with buffers and more
<adrien_oww>
and not compatible with in/out_channel either
<gargawel>
do you know of a way to solve my problem ?
<gargawel>
Hum, there is fdopen
<gargawel>
and fileno
<companion_cube>
you may have issue with buffering though
<gargawel>
that should do the trick
thomasga has quit [Quit: Leaving.]
<companion_cube>
if you use stdout (the FILE*) and Pervasives.stdout, you have two buffers for the fd 1
<companion_cube>
so take care of calling flush() consistently...
<gargawel>
Yep.
<gargawel>
Thanks for your insights :)
<reynir>
what does the _oww suffix mean?
<adrien_oww>
I'm hurt
<adrien_oww>
by companion_cube's yoloisms
<reynir>
haha okay :)
<companion_cube>
:D
<adrien_oww>
gargawel: btw, you really should understand why the library gives you something of type FILE; you might want to go as far as using the C runtime to write data
<adrien_oww>
meaning no Unix.write or print_endline but calls to C's fprintf()
<gargawel>
adrien_oww: It's mostly serializing / deserializing data structures to files
ygrek has joined #ocaml
Enjolras has quit [Remote host closed the connection]
lopex has joined #ocaml
<gargawel>
I think letting people open an out_channel and converting it to a FILE * with descr_of_out_channel and fdopen is just fine
ygrek_ has quit [Ping timeout: 240 seconds]
<adrien_oww>
won't work
<gargawel>
Why that ?
<adrien_oww>
well, it depends
<adrien_oww>
and again
<adrien_oww>
descr_of_out_channel DOES NOT give you anything compatible with FILE
ygrek_ has joined #ocaml
<gargawel>
nope, but I can call libc's fdopen to get a FILE * out of a file descriptor
<adrien_oww>
and with a single file descriptor (which is an int), if you call twice a function that creates FILE from it, you will get two different results
<adrien_oww>
you're accumulating two many layers imho
thomasga has joined #ocaml
eikke__ has joined #ocaml
<gargawel>
Well I have to do with what the library handles, ...
<gargawel>
I don't want to rewrite the lib in caml
ygrek has quit [Ping timeout: 252 seconds]
<companion_cube>
what are the handles used for exactly?
<gargawel>
they're just in/out channels to read/write data structures to files, basically
<adrien_oww>
from OCaml, create strings
<adrien_oww>
pass the strings to the C side
<adrien_oww>
write from there
<adrien_oww>
you'd probably want to keep the channels/descrs/whatever opaque anyway
<companion_cube>
+1
<companion_cube>
if the C side wants to control files, better let it do
<adrien_oww>
because, yes, the user will try to call print_endline "laaaappppiiiiinnnnn !!!!!" in the middle of a serialization
<adrien_oww>
or, if the user is companion_cube, probably "yolo" instead
<gargawel>
it wants to *read* and *write* from files, not to open them, people still need a convenient way to open files from the caml-side
<adrien_oww>
val your_lib_open_out_file : string -> your_lib_out_channel
<companion_cube>
gargawel: then you should expose a few more functions
<companion_cube>
exactly
<gargawel>
I'm not sure I get your suggestion about strings, are you suggesting to write C-stubs ?
<companion_cube>
maybe even val with_out_file : string -> (your_lib_out_channel -> 'a) -> 'a
<gargawel>
I'm using ctypes to avoid doing that ;)
<companion_cube>
gargawel: you can write some OCaml functions that use ctypes to call fopen/fclose
<mk270>
any Lwt adepts here?
<companion_cube>
ask, don't ask to ask, anyway
<mk270>
:)
<mk270>
so i have got postgres running with lwt
<gargawel>
hmmm, thanks for the suggestion
<adrien_oww>
gargawel: int fputs(const char *s, FILE *stream);
<mk270>
but in practice i want to keep the postgres db connection open, and send it a queue of requests, and get responses back
<companion_cube>
gargawel: please consider the with_ version, that always closes cleanly ;)
<mk270>
and i'm not sure how to make a thread with the handle in it, and reunite it with the work items later in the code
<mk270>
handle == database connection
<gargawel>
adrien_oww: how does that help ? I'm not writing anything myself, the library does
<gargawel>
companion_cube: yes, the issue I see here is that the user can't pass stdout / stderr anymore :(
<companion_cube>
gargawel: it can pass the stdout/stderr you give
<companion_cube>
val stdout : your_lib_out_channel
<gargawel>
Unless I provide MyLibrary.stdout, which sounds clumsy
<adrien_oww>
gargawel: exactly, and if you bind fputs and make it private to your bindings, you will have no problem
<companion_cube>
it's not particularly clumsy imho
<adrien_oww>
you'll be able to use the function and pass a string and where to write, and still hide the details from the user
<gargawel>
OK, I'll give it a thought. Converting in_/out_channel to FILE * automagically sounded like a good idea...
<gargawel>
(Coming from MonadHell, aka Haskell, I'm still learning The Right Way (tm))
yacks has quit [Ping timeout: 264 seconds]
<adrien_oww>
"automagically" isn't a good idea when it comes to C stubs
<adrien_oww>
one issue is that C bindings can be tricky and it's much better to keep things simple
<adrien_oww>
btw, you'll need to have a call to fflush() too in order to make sure the data is flushed
thomasga has quit [Quit: Leaving.]
<adrien_oww>
(note that it does not guarantee data integrity which is something additional and close to the OS)
freling has joined #ocaml
<gargawel>
I still have to put a lot of automagic in my bindings, because the C library insists on freeing most of the functions' arguments unless they are "copied" beforehand :(
<companion_cube>
-_-
<gargawel>
(these "copy" just increase a reference counter...)
<adrien_oww>
ah, fun stuff
<adrien_oww>
opencv is awful in this regard
<gargawel>
It's probably convenient for C programmers, but very annoying for us
<adrien_oww>
yup, double GC is no fun
<def`>
gargawel: reference counting scheme are easy to bind i think
<def`>
much you just increment the counter when importing the block in ocaml heap (via a custom block), and decrement in the finalizer. the process is completely transparent and integrate seamlessly on the ml-side
<adrien_oww>
until you forget one :D
<gargawel>
They're not hard per se, but generating the bindings implies parsing and handling a lot of annotations
<def`>
adrien_oww: you can't forget, if the api is reasonable there should be only one point where you traverse the barrier
<gargawel>
adrien_oww: I have ~2000 functions to bind ; no way I'm doing this by hand ;)
<def`>
otherwise it's a general problem of the API, not of the memory management scheme
thomasga has joined #ocaml
<adrien_oww>
def`: :]
<adrien_oww>
gargawel: how do you parse?
<gargawel>
Haskell's language-c library :] Parsing the headers require pre-processor support. I map the annotations with __attribute__s with defines
<gargawel>
I have considered many options, but it seems to be the most appropriate for my use case
<adrien_oww>
because that's right in the usecase of my "cowboy" library
<adrien_oww>
but if you already know language-c and your stuff already works...
<gargawel>
adrien_oww: Yeah, we actually talked about it a few months ago ;) I had a look at it. I don't know if my way is "simpler" but I am more familiar with it
yacks has joined #ocaml
<adrien_oww>
as long as it workds
<adrien_oww>
works*
divyanshu has joined #ocaml
maattdd has joined #ocaml
thomasga has quit [Quit: Leaving.]
Kakadu has joined #ocaml
skchrko has joined #ocaml
maattdd has quit [Ping timeout: 252 seconds]
huza has quit [Ping timeout: 245 seconds]
dsheets has joined #ocaml
maattdd has joined #ocaml
maattdd has quit [Ping timeout: 240 seconds]
macron has quit [Ping timeout: 240 seconds]
macron has joined #ocaml
thomasga has joined #ocaml
agarwal1975 has joined #ocaml
huza has joined #ocaml
agarwal1975 has quit [Client Quit]
Hannibal_Smith has joined #ocaml
agarwal1975 has joined #ocaml
maattdd has joined #ocaml
ustunozgur has joined #ocaml
ustunozg_ has joined #ocaml
ustunozgur has quit [Ping timeout: 240 seconds]
ustunoz__ has joined #ocaml
ustuno___ has joined #ocaml
ygrek_ has quit [Ping timeout: 276 seconds]
ustunozg_ has quit [Ping timeout: 240 seconds]
ustunoz__ has quit [Ping timeout: 265 seconds]
_andre has joined #ocaml
mort___ has joined #ocaml
mort___ has quit [Remote host closed the connection]
mort___ has joined #ocaml
ustuno___ has quit [Read error: Connection reset by peer]
ustunozgur has joined #ocaml
ustunozgur has quit [Read error: Connection reset by peer]
ustunozgur has joined #ocaml
thomasga has quit [Quit: Leaving.]
ustunozgur has quit [Remote host closed the connection]
mort___ has quit [Remote host closed the connection]
mort___ has joined #ocaml
<jpdeplaix>
gasche: what's up for the macaque release ?
<adrien_oww>
gasche: and I wanted you to be aware of the existence of a win32-native zsh, which means it could be much much faster than cygwin or msys' bash
<adrien_oww>
gasche: and worth a try for 4.02 (I'll try to try it)
studybot_ has quit [Remote host closed the connection]
agarwal1975 has quit [Quit: agarwal1975]
Kakadu has quit [Ping timeout: 240 seconds]
Submarine has joined #ocaml
Submarine has joined #ocaml
Submarine has quit [Changing host]
ontologiae has joined #ocaml
agarwal1975 has joined #ocaml
ollehar1 has joined #ocaml
Kakadu has joined #ocaml
ontologiae has quit [Ping timeout: 252 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
agarwal1975 has quit [Quit: agarwal1975]
ontologiae has joined #ocaml
agarwal1975 has joined #ocaml
arj has joined #ocaml
avsm1 has joined #ocaml
ollehar has quit [Ping timeout: 245 seconds]
thomasga has joined #ocaml
ollehar has joined #ocaml
studybot_ has joined #ocaml
yacks has quit [Ping timeout: 264 seconds]
shinnya has joined #ocaml
cago has quit [Ping timeout: 245 seconds]
divyanshu has joined #ocaml
studybo__ has joined #ocaml
studybot_ has quit [Ping timeout: 272 seconds]
<gasche>
jpdeplaix: I could do neither ocamlbuild nor Macaque work this week-end, but I'll try to fix that by the beginning of the week
<gasche>
you had a question on the work to be done on ocamlbuild: we also want to implement -no-ocamlfind as suggested (it's actually a major blunder that we didn't think of putting it in 4.01)
<gasche>
I'm sorry to be the bottleneck in both cases
ontologiae has quit [Ping timeout: 276 seconds]
studybo__ is now known as studybot
avsm has joined #ocaml
<jpdeplaix>
gasche: I don't understand :/ My PR doesn't remove -no-ocamlfind
avsm1 has quit [Ping timeout: 245 seconds]
<companion_cube>
o/ gasche
ollehar has quit [Ping timeout: 245 seconds]
rand000 has joined #ocaml
agarwal1975 has quit [Quit: agarwal1975]
cago has joined #ocaml
thomasga has quit [Quit: Leaving.]
agarwal1975 has joined #ocaml
tobiasBora has joined #ocaml
thomasga has joined #ocaml
deavidsedice has quit [Ping timeout: 252 seconds]
ontologiae has joined #ocaml
deavid has joined #ocaml
cago has quit [Ping timeout: 252 seconds]
ontologiae has quit [Ping timeout: 255 seconds]
ontologiae has joined #ocaml
BitPuffin has quit [Ping timeout: 264 seconds]
darkf has quit [Quit: Leaving]
hhugo has quit [Quit: Leaving.]
cago has joined #ocaml
cesar_ has joined #ocaml
cesar_ is now known as Guest17716
shinnya has quit [Ping timeout: 245 seconds]
NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
divyanshu has quit [Ping timeout: 252 seconds]
divyanshu has joined #ocaml
ustunozgur has joined #ocaml
divyanshu has quit [Ping timeout: 260 seconds]
divyanshu has joined #ocaml
Thooms has joined #ocaml
ygrek_ has joined #ocaml
divyanshu has quit [Ping timeout: 252 seconds]
divyanshu has joined #ocaml
huza has quit [Quit: WeeChat 0.3.8]
hhugo has joined #ocaml
Submarine has quit [Quit: Leaving]
slash^ has joined #ocaml
BitPuffin has joined #ocaml
ontologiae has quit [Ping timeout: 240 seconds]
slash^ has quit [Quit: Leaving.]
ustunozgur has quit [Remote host closed the connection]
maattdd has quit [Ping timeout: 260 seconds]
ustunozgur has joined #ocaml
tlockney_away is now known as tlockney
avsm has quit [Quit: Leaving.]
ustunozgur has quit [Ping timeout: 240 seconds]
skchrko has quit [Quit: Leaving]
avsm has joined #ocaml
jerry__ has joined #ocaml
<jerry__>
adrien_oww
<jerry__>
adrien_oww: Hi I got a problem at the building of win_build 1.4.0 on linux 64 at nearly the end of the build at libid3tag
<adrien>
compares Objective-C, Python and Swift; obviously you do RC4, yourself, and using Python
eikke__ has joined #ocaml
thomasga has joined #ocaml
<companion_cube>
weird, no C++ on this chart
maattdd has quit [Ping timeout: 255 seconds]
ustunozg_ has quit [Remote host closed the connection]
<adrien>
woah
<adrien>
it even has a... REPL
<parcs_>
why the objective c impl so slow?
<adrien>
parcs_: Objective-C isn't fast
<adrien>
and I guess the style didn't help
<parcs_>
isn't it a superset of C
<adrien>
there are some heavy constructs in Objective-C
<adrien>
I don't think that it you take C code and build it as Objective-C you'll get something which runs at the same speed
maattdd has joined #ocaml
<flux>
hmm, I think you may very well get
<flux>
but the thing is when you write objective C apps, you typically use the.. objective C featuers
<flux>
or the standard library
<flux>
and things like arrays, dictionaries, etc, are all objective C stuff
<flux>
(not int arrays[2]; but NSArray)
slash^ has quit [Ping timeout: 252 seconds]
slash^ has joined #ocaml
<flux>
first thing that slows down is the fact that everything is heap-allocated
<parcs_>
i wonder if they used cython in the python version
<flux>
another is that the compiler probably has similar issues in method dispatch as ocaml does
<parcs_>
most likely not because then it wouldn't look so impressive :)
<adrien>
right, they didn't show the implementation so the benchmark is meaningless
<adrien>
and calling that a benchmark is an insult to Phoronix
<flux>
and it null checks the calls on object..
<flux>
at least null check is something OCaml doesn't need to do ;)
<adrien>
parcs_: I think they used the slowest things possible for every implementation that isn't Swift
<companion_cube>
ohhh ??
<companion_cube>
such dishonesty :D
<flux>
they cherry-picked the example of course but if it's llvm-backed properly typed language.. it's not going to be slower than objective C or python.
<adrien>
heh, on reddit:
<adrien>
Q: What was with the random comparison with Python?
<adrien>
A: Apple trick; compare performance stats with the slowest of the slowest thing that's out there to make numbers look good.
<flux>
in a sense it's better to compare with objective C or python, because they are apparently 'as safe' - well, except objective C is more unsafe
<flux>
I guess few here would call C a safe language and C++ "is safe if you write it properly"
<adrien>
have they mentionned safety?
<adrien>
C for crypto is not an issue
<reynir>
yea, I think so
<reynir>
In the link someone posted earlier
<adrien>
if you're not too bad at C, you won't make more bugs in crypto using C than using another language
<adrien>
protocols, yeah; crypto? these 30 lines of code? doubtful
<reynir>
from the theverge link earlier: "By design, Swift helps developers write safer and more reliable code by eliminating entire categories of common programming errors"
<reynir>
super vague and doesn't really say anything, though
thomasga has quit [Quit: Leaving.]
<adrien>
hadn't seen that; indeed super vague
<ggole>
Anything is "safe if you write it properly"
<parcs_>
in a way c is one of the safest languages because of the maturity and breadth of its tooling (including static and runtime analyzers)
<parcs_>
that a programming language intrinsicly eliminates entire categories of errors is a red herring, i think
hhugo has quit [Quit: Leaving.]
<adrien>
python is safe; it might crash but it's still safe :P
<ggole>
That's a very strange definition of "safest"