trillion_exabyte has quit [Ping timeout: 265 seconds]
trillion_exabyte has joined #ocaml
mbuf has joined #ocaml
xd1le has quit [Quit: xd1le]
bgs has joined #ocaml
barak has joined #ocaml
barak has quit [Read error: Connection reset by peer]
bartholin has joined #ocaml
priime has joined #ocaml
priime has quit [Remote host closed the connection]
bartholin has quit [Remote host closed the connection]
olle has joined #ocaml
alexherbo2 has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
neiluj has joined #ocaml
mbuf has quit [Quit: Leaving]
Serpent7776 has joined #ocaml
<discocaml>
<darrenldl> finished writing a gopher client/crawler with it, but it remains fairly obtuse, not sure if i really enjoy using it hm
alexherbo2 has joined #ocaml
<discocaml>
<darrenldl> is there a way to do the equivalent of `Format.formatter_of_out_channel` in eio (with eio's flow or whatever)?
<discocaml>
<beajeanm> I share the feeling, I'm implementing a simple nats client in eio, got most of the basic functionality working, but I felt I had to fight the API a bit too much. I'm hoping it's just a discovery phase, and it will rub-off on me...
<discocaml>
<darrenldl> okay, i was being silly and didn't flush the formatter, using CCIO.with_out within `Eio_main.run` works fine enough ish
<discocaml>
<darrenldl> @beajeanm the type signatures read fairly obtuse to me still, maybe i'll get through it
<discocaml>
<beajeanm> I don't think Eio will prevent you from using any of the "classic" IO functions, but they won't play nice with the scheduler I assume. (I.e. same story as with Lwt in that regard)
<discocaml>
<darrenldl> yeah, still in cooperative scheduling land within a fibre
<discocaml>
<darrenldl> is the consensus that eio is the new goto?
<discocaml>
<darrenldl> go to option*
<discocaml>
<darrenldl> (maybe asking what the consensus is is a bit silly on my part)
<discocaml>
<beajeanm> Yeah, it's ocaml, we are not going to have a consensus 🙂 but Eio so far looks fairly close to become one.
<discocaml>
<beajeanm> There is https://erratique.ch/software/affect as an alternative, but I mostly see libraries going the eio route if anything.
<discocaml>
<beajeanm> Also the scope of affect seems much more limited, for better or for worse, it only offers Fiber, not the whole I/O, capabilities, mock story.
<discocaml>
<darrenldl> i guess better documentation is the way to go then since most are sticking with eio
Haudegen has quit [Quit: Bin weg.]
<discocaml>
<Bluddy> Since I don't have experience with Eio, could you describe what you didn't like about it? Which part of the API was difficult to use?
u92n has joined #ocaml
<discocaml>
<beajeanm> I don't really have my feelings about it nailed down, but let me give it a try:
<discocaml>
<beajeanm> - I've managed to successfully stay away from object in Ocaml, so for me signature like `<A; B>` or `#Foo.bar` are totally foreign and something I had to get use to it as I was learning the API. Hopefully, I'll get my head around it, and that will be a none issue.
<discocaml>
<beajeanm> - But I missed the Lwt monad 🤯 I was really surprise by that one, I would probably have listed getting rid of `Lwt.t` and `Async.t` as the main reason to switch to an effect based library. But as I was implementing my client library, I realised my brain was using the monad as a clutch to better understand which part of the program will be blocking and which part could be asynchronous. I can clearly see the difference between an `Lwt_io` f
<discocaml>
<beajeanm> - There were other minor annoyances, e.g. `Eio.Buf_read` gives you a cut down version of Angstrom, but it was too hard for me to use to implement the Nats protocol parser, so I ended doing it in Angstrom and writing the integration function with `Eio.Flow`.
<discocaml>
<beajeanm>
<discocaml>
<beajeanm> But that's me liking to whine about everything, I've implemented what looks to me a working* Nats client in a few hours spread over the course of a week using a library I've never touched before. So it's definitely a win for Eio in my book.
<discocaml>
<beajeanm> * Of course, if I ever try to use it in anger, I'll discover that it's full of bugs 😬
<discocaml>
<darrenldl> in a similar sense, it was a bit difficult to tell for me when it'll implicitly yield to the scheduler
<discocaml>
<darrenldl> i might have a proper list when i'm less tired
<discocaml>
<dinosaure> in some way, it's preferable, as `lwt` does (the diff between `lwt` & `lwt.unix`), to split the scheduler idea from I/O and let the user to wrap correctly (and as he/she wants) I/O through the scheduler.
<discocaml>
<dinosaure> and I don't think that `eio` reaches a consensus 😕
<companion_cube>
@darrendl I think you can implement Format.formatter_of_out_channel with Eio, using the out_functions API of Format
<discocaml>
<darrenldl> ah okay, thanks!
<discocaml>
<darrenldl> (I'll admit i gave up during trying to open a file the eio way already)
<companion_cube>
I sure hope that Eio reaches a consensus and that we don't have more fragmentation tho
<discocaml>
<darrenldl> then i think it has slightly too many moving components
<discocaml>
<darrenldl> (maybe i'll work out how Eio.Path, Eio.Stdenv.fs, Eio.Path.(fs / "/wherever") fit together at a later point
<discocaml>
<darrenldl> (well it gives flow, so that's there ig)
<companion_cube>
but Flow seemed niceg
<companion_cube>
-g
<companion_cube>
granted, I mostly looked at the docs, cause at the time there were no SSL bindings
<companion_cube>
but I like that channels are user-definable
Anarchos has joined #ocaml
neiluj has quit [Ping timeout: 246 seconds]
neiluj has joined #ocaml
szkl has quit [Quit: Connection closed for inactivity]
<companion_cube>
I don't think anyone is working on arenas in OCaml
<olle>
Arenas with non-boxed values that can't escape or be aliased.
<olle>
Yea I guess
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<discocaml>
<darrenldl> i think ive gotten my hands dirty enough to begin drafting the erlang style process library i had in mind, hopefully will be fun
<discocaml>
<darrenldl> (most interested in tackling the distributed process case head on)
u92n has quit [Quit: Client closed]
<zozozo>
olle: gasche wanted to experiment with arenas, or at least regions of memory that would have different behaviour with the gc (such as a long lived" region that would be treated as one big block by the gc, and not scanned, or things along these lines)
<neiluj>
oh nice, thanks for pointing out this document!
<neiluj>
(brb)
neiluj has quit [Quit: WeeChat 3.7.1]
<olle>
zozozo: oooh ok
<olle>
wouldn't biggest gain come from non-boxing tho? maybe hard to interact with other code.
<companion_cube>
they have plans for unboxing at JST
<companion_cube>
@darrendl thoughts on serialization?
<zozozo>
olle: depends on what you allocate I'd say
<olle>
zozozo: mm
<olle>
companion_cube: oh that's cool
<companion_cube>
I'd love unboxed values
<companion_cube>
e.g. if we could finally get array slices/string slices
<zozozo>
companion_cube: bigarrays ? (or something similar if you want it to store ocaml values)
<companion_cube>
no
<companion_cube>
please no
<companion_cube>
I mean actual slices of actual OCaml values :p
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
<zozozo>
companion_cube: sets of closures then, :p (basically, you need a infix-header trick or similar to get slices of ocaml values)
<companion_cube>
yikes
<companion_cube>
the whole idea of slices is that it'd be a value type
<companion_cube>
that's why I say I'd love unboxed values :p
<zozozo>
but the question is: do you really need slices of arbitrary ocaml values ? or just slices of arrays ?
<companion_cube>
arrays and strings and bytes, most likey
<companion_cube>
likely*
<companion_cube>
that's already too many to special case
<discocaml>
<darrenldl> companion_cube: re serialization, was initially thinking of relying of users to provide the serializers for remote nodes, still looking at ada and erlang for inspiration, but seems to boil down to picking a good binary encoding
<zozozo>
what would be the exact semantics you'd want for arrays of ocaml values for the GC: if you have an array, get a slice, and only keep the slice alive, should the values outside the slice be GC'd ?
<discocaml>
<darrenldl> still thinking how to remove that cost entirely when receiver is local at api level
<companion_cube>
zozozo: no
<zozozo>
companion_cube: then, just have type slice = array * int * int ?
<companion_cube>
sure
<companion_cube>
but then each slice allocates
<zozozo>
yeah, and ?
<zozozo>
if you try to program in ocaml and never allocate, well...
<companion_cube>
and that's what unboxed types are there to avoid
<companion_cube>
I mean, that's why JST is interested in unboxed types too
<zozozo>
yeah, but it's a massive change to the compiler to be able to handle the unboxed types
<zozozo>
it's coming, but it's a large change
<zozozo>
and then, unboxed types are not values
<companion_cube>
not regular values, sure
Haudegen has quit [Quit: Bin weg.]
<companion_cube>
(but you can still store them, can't you?)
<zozozo>
well... you'd need a container that can store non-values, and it's not yet clear how to do that; for instance the current proposal does not include a way to mix values and non-values in a single block, so you would not be able to do e.g. a list of non-vlaues
<zozozo>
but an array of non-values would work
<zozozo>
scratch that actually, you would have an array of the boxed versions
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
<companion_cube>
with the JST proposal, I wonder if you could reuse allocations (there's a section on thatr)
<companion_cube>
-r
<companion_cube>
like, if you have a record { …; slice: array_slice }
<companion_cube>
and you want to change it in place, you could reuse the block
<zozozo>
clearly, the jst proposal (for data races) wants to allow one to do that (using the overwrite keyword)
<companion_cube>
right
<companion_cube>
yeah that'd be swell
<companion_cube>
the particular use case I have in mind, in this case, is writing lexers/parsers
<companion_cube>
it's too useful to have string slices for that
<companion_cube>
(or locations, for that matter ;))
u92n has joined #ocaml
<theblatte>
I'd like to downcast an element in a pair without re-allocating the pair but the typechecker is fighting me hard, eg let downcast_fst (pair : high * 'a) : low * 'a = (pair :> low * _) tells me it cannot be coerced because high is incompatible with low
<theblatte>
so I have to do let downcast_fst ((x,y) : high * 'a) : low * 'a = ((x :> low), y) instead but that's rubbish
<discocaml>
<NULL> ``type high = [`A] type low = [`A | `B] let downcast_fst (pair : high * 'a) : low * 'a = (pair :> low * _)`` works for me
<discocaml>
<NULL> You don't even need that many annotations
<discocaml>
<NULL> What version of OCaml are you using ?
alexherbo2 has quit [Remote host closed the connection]
<theblatte>
ah, maybe so, but not with type low type high = private low
alexherbo2 has joined #ocaml
<discocaml>
<NULL> You're right, it's weird that it doesn't work as well. You can still make it work with a fully annotated cast : `(pair : high * _ :> low * _)`
<discocaml>
<Nat> `(val, err) result list` or `val list * err list`?
<discocaml>
<Nat> Currently leaning towards the latter
<discocaml>
<Armael> the former looks more informative to me; in the second case, the two lists could be of different lengths for instance
<discocaml>
<Armael> if the invariant is that they are actually always of the same length then the first representation seems better as it makes this invariant explicit
<discocaml>
<Nat> Sure, but we don't have that restriction
<discocaml>
<Nat> Order isn't important either
<discocaml>
<Armael> ah, also scratch that I got confused, what I just said is nonsense
<companion_cube>
if you can make use of multiple errors, the second one is nice
<companion_cube>
but oftentimes I personally might want `(val list, err) result`
<discocaml>
<Nat> Yeah, we want to allow multiple errors here
trillion_exabyte has quit [Ping timeout: 240 seconds]
alexherbo2 has quit [Remote host closed the connection]
<discocaml>
<octachron> @anmonteiro : it is a ppxlib bug.
alexherbo2 has joined #ocaml
<discocaml>
<anmonteiro> gotcha. I'm using ppxlib "trunk-support". makes sense that it isn't a compiler bug -- seems like there would be extensive tests for this
trillion_exabyte has joined #ocaml
<discocaml>
<octachron> ppxlib is erasing the constraint on the value binding which is a not-completely-unexpected bug because I added a new parsetree node in the AST to represent those.