jidar8 has quit [Remote host closed the connection]
jayvdb13 has joined #ocaml
jayvdb13 has quit [Remote host closed the connection]
karlguy has quit [Quit: Leaving]
apostolis has quit [Quit: WeeChat 1.6]
anoopcs11 has joined #ocaml
Vel0city10 has joined #ocaml
anoopcs11 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
Vel0city10 has quit [Remote host closed the connection]
cpt_nemo20 has joined #ocaml
cpt_nemo20 has quit [Remote host closed the connection]
neatonk has quit [Ping timeout: 245 seconds]
lostman has quit [Quit: Connection closed for inactivity]
jstolarek has joined #ocaml
jstolarek has quit [Remote host closed the connection]
jao has quit [Ping timeout: 272 seconds]
lopex has quit [Quit: Connection closed for inactivity]
arcan1s_ has joined #ocaml
mfp has quit [Ping timeout: 252 seconds]
arcan1s_ has quit [Killed (Sigyn (Spam is off topic on freenode.))]
quipa has quit [Read error: Connection reset by peer]
tormen has joined #ocaml
tormen_ has quit [Ping timeout: 252 seconds]
neatonk has joined #ocaml
Zic27 has joined #ocaml
Zic27 has quit [Ping timeout: 268 seconds]
toxync19 has joined #ocaml
toxync19 has quit [Remote host closed the connection]
kvda has quit [Read error: Connection reset by peer]
troydm has quit [Ping timeout: 252 seconds]
noitakomentaja has quit [Quit: leaving]
apostolis has joined #ocaml
apostolis has quit [Client Quit]
noitakomentaja has joined #ocaml
troydm has joined #ocaml
discord has quit [Remote host closed the connection]
discord2 has joined #ocaml
martin_16 has joined #ocaml
martin_16 has quit [Remote host closed the connection]
kini has quit [Quit: No Ping reply in 180 seconds.]
sagotch has joined #ocaml
kini has joined #ocaml
sjoerd12 has joined #ocaml
sjoerd12 has quit [K-Lined]
freyr69 has joined #ocaml
yurug has joined #ocaml
SCSi1 has joined #ocaml
SCSi1 has quit [Remote host closed the connection]
Saphire19 has joined #ocaml
Saphire19 has quit [Remote host closed the connection]
trixisowned3 has joined #ocaml
Haudegen has joined #ocaml
trixisowned3 has quit [Remote host closed the connection]
noitakomentaja has quit [Ping timeout: 252 seconds]
yurug has quit [Ping timeout: 244 seconds]
Emi25 has joined #ocaml
justanotherbody1 has joined #ocaml
Emi25 has quit [Remote host closed the connection]
johnel_away is now known as johnelse
johnelse has quit [Quit: leaving]
justanotherbody1 has quit [Ping timeout: 244 seconds]
johnelse has joined #ocaml
<johnelse>
Leonidas: apologies, that should be turned off now
ggole has joined #ocaml
yurug has joined #ocaml
johnelse has quit [Quit: leaving]
ziyourenxiang_ has joined #ocaml
yurug has quit [Quit: WeeChat 2.2]
quipa has joined #ocaml
jimt has joined #ocaml
kvda has joined #ocaml
jim7j1ajh has joined #ocaml
jim7j1ajh has quit [Client Quit]
jimt has quit [Quit: leaving]
jimt has joined #ocaml
FreeBirdLjj has joined #ocaml
johnelse has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kvda has joined #ocaml
mfp has joined #ocaml
Elec_A has joined #ocaml
noitakomentaja has joined #ocaml
Elec_A has quit [Remote host closed the connection]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 260 seconds]
lopex has joined #ocaml
Haudegen has quit [Read error: Connection reset by peer]
sagotch has quit [Quit: Leaving.]
johnelse has quit [Quit: leaving]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
noitakomentaja has quit [Ping timeout: 260 seconds]
johnelse has joined #ocaml
troydm has quit [Ping timeout: 252 seconds]
SuperLagYg has joined #ocaml
SuperLagYg has quit [Remote host closed the connection]
johnelse has quit [Quit: Lost terminal]
jao has joined #ocaml
c_wraithsm has joined #ocaml
c_wraithsm has quit [Remote host closed the connection]
EvilDMPxr has joined #ocaml
muelleme has joined #ocaml
EvilDMPxr has quit [Remote host closed the connection]
francisl has joined #ocaml
cbreakro has joined #ocaml
muelleme has quit [Ping timeout: 252 seconds]
sagotch has joined #ocaml
troydm has joined #ocaml
cbreakro has quit [Remote host closed the connection]
okamis has joined #ocaml
okamis has quit [Remote host closed the connection]
erkin has joined #ocaml
kakadu has joined #ocaml
al-damiri has joined #ocaml
johnelse has joined #ocaml
francisl has quit [Quit: francisl]
francisl has joined #ocaml
WintereiseDi has joined #ocaml
WintereiseDi has quit [Remote host closed the connection]
_andre has joined #ocaml
Lord_of_LifeSQ has joined #ocaml
Lord_of_LifeSQ has quit [Remote host closed the connection]
spew has joined #ocaml
francisl has quit [Quit: francisl]
pmetzger has joined #ocaml
pmetzger has quit [Client Quit]
francisl has joined #ocaml
Haudegen has joined #ocaml
JimmyRcom has joined #ocaml
JimmyRcom has quit [Max SendQ exceeded]
JimmyRcom has joined #ocaml
discord2 has quit [Remote host closed the connection]
discord3 has joined #ocaml
erkin has quit [Remote host closed the connection]
KethsarCI has joined #ocaml
KethsarCI has quit [Remote host closed the connection]
platicus2 has joined #ocaml
silver has joined #ocaml
platicus2 has quit [Killed (Sigyn (Spam is off topic on freenode.))]
ski has quit [Ping timeout: 245 seconds]
<sagotch>
Hey. How can I use a string as an in_channel?
<companion_cube>
sadly you can't
<sagotch>
:'(
<companion_cube>
yes, standard IO are not flexible enough
<ggole>
Yeah, really should be able to read from and print to strings/buffers
<companion_cube>
you should be able to define your own channels
<companion_cube>
dynamic dispatch baby
ski has joined #ocaml
<ggole>
I assume the reason they're in C because of the bytecode interpreter
<ggole>
*is because of
<companion_cube>
but on the OCaml side there could be a sum type `Native_chan of c_level_chan | User_chan of { ... }` with a record of closures
<Drup>
companion_cube: dynamic dispatch is *not* a good solution for that, particularly if you want something even remotely efficient :)
<ggole>
You don't need full dynamic dispatch
<ggole>
Only for refilling the buffer
<companion_cube>
Drup: it's how it's done in other languages, sorry
<companion_cube>
(I mean, not in rust since they have specialization)
<companion_cube>
but anyway if you don't do your IO in batch you have other problems
<companion_cube>
and paying one dynamic dispatch call to refill a buffer should really be ok
<ggole>
I agree that dispatch on every byte is excessive, but that shouldn't be necessary
<Drup>
Right, that's for reading
<def`>
(the kernel does a dynamic dispatch on the underlying fd, at worst it should be faster when we spare context switches)
<companion_cube>
if you read byte by byte, ugh
<companion_cube>
Drup: surely you don't write byte by byte either?
<sagotch>
Hum... I am currently using js_of_ocaml so Sys_js.register_file is probably the solution for me here :)
<Drup>
No, I was thinking about writing, not reading.
<companion_cube>
Drup: you know what's worse than dynamic dispatch in `channel`? having a system of objects on top of `channel`, like in cryptokit
<companion_cube>
when it should all be based on channel in a language where IO wasn't an afterthought
<Drup>
erk, true x)
<Drup>
(especially since records are enough, you really don't need objects ...)
<companion_cube>
I'm saying cryptokit, but who knows how many people do dirty hacks to compress?
steenuil has quit [Ping timeout: 246 seconds]
<companion_cube>
or open a file/pipe to work around limited APIs that work only with channels?
<Drup>
Yeah, camlpdf does something similar. Batteries also has a fairly complicated channel system
<companion_cube>
(rust shines for that, btw — the solver I forked can read and parse a 500MB cnf in 1s)
<def`>
it is not too late to fix that :P
<ggole>
It might be reasonable to implement a new channel system using the Unix stuff, but you would lose printf and friends
<companion_cube>
ggole: which is why it should be done in the `channel` type itself
<ggole>
Right.
<ggole>
(Same goes for Buffer, I guess.)
<companion_cube>
ugh, buffer :/
<companion_cube>
talk about limited APIs
<def`>
what's wrong with Buffer?
<companion_cube>
it sucked (might be better now, but well)
steenuil has joined #ocaml
<ggole>
The interface is pretty stark, there's lots of things you can't do with it
<companion_cube>
stuff like add_channel which is pretty useless
<ggole>
It also holds onto the initial buffer, which is usually useless and can waste memory if you pass a large initial size
<def`>
companion_cube: and the thing doing substitution :')
<companion_cube>
:DDDD
<companion_cube>
right
<ggole>
The most eyebrow raising omission for me is that you can't reserve space to avoid copying
<companion_cube>
I'd rather have `buffer_in : in_channel -> in_channel` and same for `buffer_out`
<companion_cube>
ggole: or iterate on it, or obtain a slice easily…
<companion_cube>
ugh, objects or traits are so much better for this kind of things :/
<oni-on-ion>
ocaml has modules and functors instead of type classes and traits.
szahertv has joined #ocaml
<Armael>
:^)
quipa has quit [Ping timeout: 250 seconds]
<companion_cube>
yeah and it's much more verbose for composition in the small
<companion_cube>
(but possibly better in the large)
<oni-on-ion>
might not need it then, then
<oni-on-ion>
or use ocaml objects. =)
<oni-on-ion>
or basic parameterized struct
<ggole>
The printf support for Buffer is quite nice though
<Drup>
yeah, except you should never use it :>
<ggole>
Why not?
<companion_cube>
and why is that? because channels are not flexible enough 🙄
<Drup>
ggole: use formatters instead
<def`>
wow, that's going a bit too far for my tates
<def`>
taste*
<ggole>
formatters do a very different job
<companion_cube>
Drup: funny that you talked about performance earlier though :D
<Drup>
formatters can delegate to a buffer trivially, and you can use all the printers available in the wild
szahertv has quit [Remote host closed the connection]
<ggole>
I don't see the point unless I want pretty-printing
<companion_cube>
the point is not to define printers twice
<Drup>
companion_cube: Well, for all intent and purposes, Format.formatter does the job you want new output channels to do.
<ggole>
I guess ppx_deriving_show doesn't play nice with buffers
<companion_cube>
Drup: with an incredible overhead, yes
<Drup>
Lot's of printers work on them, you can disable the formatting, and you can write formatters to exotic targets
<companion_cube>
I mean, I do that too, but it's not satisfactory
<companion_cube>
how do you totally disable the formatting?
<Drup>
right now, you put the margin to max_int :3
<companion_cube>
…
<Drup>
I need to write a patch for that
<companion_cube>
please don't ever talk about IO performance again :p
<Drup>
Well, I want customizable output as much as you want customizable input.
<Drup>
I just ... have a solution that works right now :D
<companion_cube>
I'd want both, but yeah
<Drup>
Also, the perfs are really not so bad.
<Drup>
Especially compare to doing lot's of copies everywhere ....
<companion_cube>
and they wouldn't be so bad with dynamic `channels` either
<Drup>
But, it's not dyanmic dispatch ... it's just abstraction
<companion_cube>
wait, aren't formatters built around this dynamic-dispatch-y record of functions?
<companion_cube>
the one you can overload? :p
<Drup>
We probably don't have the same definition of what "dynamic dispatch" means. For me, it means table of methods, aka objects
<companion_cube>
record of functions is the same, in my book
<companion_cube>
objects are just a more builtin way of doing it
<ggole>
My understanding is that dispatch in this case is that the channel/whatever structure contains a function which is called in order to replenish or forward the bytes
<Drup>
Abstraction+record (mutable or not, btw. I would tend to say not, but that's debatable) does the job well
<ggole>
Ideally things like printing ints would be able to format characters right into such buffers, rather than going through a string
<companion_cube>
Drup: and that's what I have been thinking of as "dynamic dispatch" all this time
<companion_cube>
calling functions (closures) that are not known at compile time
<companion_cube>
whether it's done with a record or an object I don't care much
<Drup>
Right, ok
<Drup>
So, when do you make a patch ? :D
<companion_cube>
I don't have enough patience to work on such a patch for 2 years
jbrown has quit [Ping timeout: 252 seconds]
<companion_cube>
better transition to rust for stuff where perf really matters anyway
<Drup>
Come oon, lot's of things are getting merged in the stdlib now
<Drup>
it's time!
<companion_cube>
I should redo my PR on io first
iTeVXG has joined #ocaml
iTeVXG has quit [Remote host closed the connection]
jbrown has joined #ocaml
ski has quit [Ping timeout: 252 seconds]
ziyourenxiang_ has quit [Ping timeout: 250 seconds]
sagotch has quit [Quit: Leaving.]
SpiceGuid has joined #ocaml
Haudegen has quit [Remote host closed the connection]
freyr69 has quit [Remote host closed the connection]
frefity has joined #ocaml
frefity has quit [Client Quit]
SpiceGuid has quit [Ping timeout: 268 seconds]
SpiceGuid has joined #ocaml
SpiceGuid has quit [Client Quit]
muelleme has joined #ocaml
francisl has quit [Quit: francisl]
rymate1234OL has joined #ocaml
muelleme has quit [Ping timeout: 245 seconds]
rymate1234OL has quit [Remote host closed the connection]
struktured has joined #ocaml
francisl has joined #ocaml
noitakomentaja has joined #ocaml
Haudegen has joined #ocaml
brakkvatn has joined #ocaml
brakkvatn has quit [Killed (Sigyn (Spam is off topic on freenode.))]
kuba-orlikYP has joined #ocaml
jnavila has joined #ocaml
kuba-orlikYP has quit [Remote host closed the connection]
quipa has joined #ocaml
jnavila has quit [Ping timeout: 244 seconds]
jnavila has joined #ocaml
govg has joined #ocaml
francisl has quit [Quit: francisl]
jnavila has quit [Ping timeout: 246 seconds]
struktured has quit [Remote host closed the connection]
jnavila has joined #ocaml
xorpse has joined #ocaml
jnavila has quit [Ping timeout: 264 seconds]
jnavila has joined #ocaml
muelleme has joined #ocaml
kakadu has quit [Quit: Konversation terminated!]
muelleme has quit [Ping timeout: 252 seconds]
Anarchos has joined #ocaml
GLaDERDQ has joined #ocaml
GLaDERDQ has quit [Remote host closed the connection]
sagotch has joined #ocaml
ggole has quit [Quit: ggole]
sagotch has quit [Quit: Leaving.]
orbifx has joined #ocaml
<orbifx>
sup
kakadu has joined #ocaml
Haudegen has quit [Remote host closed the connection]
pierpal has joined #ocaml
yokeOX has joined #ocaml
takanuva has joined #ocaml
yokeOX has quit [Remote host closed the connection]
takanuva has quit [Client Quit]
<companion_cube>
anyone knows if there's a way to have threads die on sigterm? :/
<companion_cube>
seems like it's hard
buboqW has joined #ocaml
buboqW has quit [Remote host closed the connection]
Haudegen has joined #ocaml
erkin has joined #ocaml
takanuva has joined #ocaml
takanuva has quit [Client Quit]
number80jR has joined #ocaml
number80jR has quit [Remote host closed the connection]
elit3x has joined #ocaml
dedgrant has joined #ocaml
dedgrant has quit [Remote host closed the connection]
<orbifx>
companion_cube: can you kill the whole process?
<companion_cube>
well I'd ctrl-c it, but it doesn't respond to it, that's the issue
elit3x has quit [Remote host closed the connection]
jnavila has quit [Remote host closed the connection]
<orbifx>
that's weird, has a special signal handler been installed?
<orbifx>
ctrl-c should kill your process unless you have a custom handler
<orbifx>
also, do you have C bindings companion_cube ?
<companion_cube>
no C bindings, but apparently some thread operations (mutex stuff) is not interruptible :(