<energizer>
naively it seems convenient to say `match x with | isprime? -> 1 | _ -> 2`
<energizer>
i guess that's the same as `| y when isprime y -> 1`
<energizer>
a bit verbose tho since it's not pointfree and needs ` when `
<d_bot>
<NULL> That's why `if` is still useful
<dh`>
yeah, you can't do that and it's not meant to do that
<companion_cube>
energizer: match isprime x with true -> ... | false -> ...
<dh`>
you can write type primeness = Prime | Composite, fun check_prime: int -> primeness, and then do match check_prime n with | Prime ... | Composite ...
<dh`>
but usually that's just excess verbiage
<dh`>
bool is often sufficient, option tends to be sufficient for most cases bool isn't, and sometime ocaml will get a native "either"
zebrag has joined #ocaml
Techcable has quit [Ping timeout: 250 seconds]
perrierjouet has quit [Quit: WeeChat 3.4]
<d_bot>
<NULL> Module `Either` and its type `('a, 'b) t = Left of 'a | Right of 'b` already exist
perrierjouet has joined #ocaml
Techcable has joined #ocaml
rgrinberg has joined #ocaml
gentauro has quit [Read error: Connection reset by peer]
<d_bot>
<concatime> > Dune will however continue to use the OCAMLPATH variable
wingsorc has joined #ocaml
<rgrinberg>
Seems like a bug. I'd report it
zebrag has quit [Quit: Konversation terminated!]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<Kakadu> I'm using dune with cram tests. I compile a few executables for this cram tests, and I don't want to install them. How dune decides which projects do these executables belong? It looks like I can't use `(package ...)` stanze, because it is about installation.
shawnw has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
Tuplanolla has joined #ocaml
<d_bot>
<darrenldl> i think via `public_name`? though i dont remember if you can bundle multiple binaries under the same public_name, but it'd seem unusual
<d_bot>
<Kakadu> I don't want to install them. So public_name should be wrong
<adrien>
what's the best way to try Eio?
<adrien>
well, I guess I'll stick to what's mentioned in its README.md because it's indeed probably better to avoid ocaml 5 for now :P
Serpent7776 has joined #ocaml
<d_bot>
<Kakadu> I read somewhere that 4.12+domains was recommended
<adrien>
that's what I went for; I'll see later on if I want to change that
mro has joined #ocaml
<d_bot>
<darrenldl> @Kakadu when you said you dont want to install them, did you mean you have a main project code and you only want to install that?
mro has quit [Remote host closed the connection]
<d_bot>
<darrenldl> then i think by not putting the test executables in public_name, they cannot be named during installation and are not installed
<d_bot>
<KW78> > I’ve also been working on a multicore monorepo 2 that uses the opam-monorepo tool 1 to provide a quick way to get up and running with OCaml 5.00.0+trunk and some of the experiments and libraries in awesome-multicore-ocaml 2 (e.g. the direct-style dream that uses lwt_eio). The idea being you should only need to:
spip has joined #ocaml
bobo has quit [Ping timeout: 256 seconds]
mro has joined #ocaml
bartholin has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
bartholin has quit [Ping timeout: 260 seconds]
bartholin has joined #ocaml
<ns12>
Hello, does Bytes.length have a run time that is independent of the number of bytes given in its argument?
<octachron>
Yes. Bytes.t is essentially the mutable array type specialized for char
<companion_cube>
It's basically free, yes
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
<ns12>
Thank you.
waleee has joined #ocaml
rgrinberg has joined #ocaml
bartholin has quit [Ping timeout: 252 seconds]
shawnw has quit [Ping timeout: 256 seconds]
xgqt has quit [Ping timeout: 250 seconds]
bartholin has joined #ocaml
xgqt has joined #ocaml
jlrnick has joined #ocaml
mro has joined #ocaml
motherfsck has joined #ocaml
mro has quit [Read error: Connection reset by peer]
mro has joined #ocaml
motherfsck has quit [Ping timeout: 260 seconds]
<adrien>
is there a way to import a file descriptor from Unix into Eio's world?
motherfsck has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bartholin has quit [Ping timeout: 240 seconds]
jlrnick has quit [Ping timeout: 240 seconds]
hyphen has quit [Ping timeout: 256 seconds]
hyphen has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
wingsorc has quit [Quit: Leaving]
gravicappa has joined #ocaml
bartholin has joined #ocaml
hyphen has quit [Read error: Connection reset by peer]
hyphen has joined #ocaml
motherfsck has quit [Quit: quit]
<d_bot>
<VPhantom> Speaking of I/O, I'm finally getting to that point in my journey. For reading files, I'm mostly interested in `Unix.mmap_file` and some day perhaps a `Lwt` equivalent. What would be an efficient way to read all of `Unix.stdin` into a bigstring so that I'd get the same structure to read from as `Unix.mmap_file`? Just a good old loop of `Unix.read` into a manually-growing bigstring?
<d_bot>
<VPhantom> (I'd read directly from stdin but I need to "rewind" a bit sometimes, which stdio isn't suitable for AFAIK.)
<d_bot>
<VPhantom> Hm, actually loading the file into `bytes` would work just as well, I can read from both types.
Haudegen has joined #ocaml
rgrinberg has joined #ocaml
bartholin has quit [Ping timeout: 245 seconds]
bartholin has joined #ocaml
bartholin has quit [Ping timeout: 272 seconds]
bartholin has joined #ocaml
gravicappa has quit [Ping timeout: 256 seconds]
bartholin has quit [Ping timeout: 256 seconds]
hyphen has quit [Ping timeout: 256 seconds]
hyphen has joined #ocaml
bartholin has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 260 seconds]
bobo has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
spip has quit [Ping timeout: 250 seconds]
<d_bot>
<hcarty> @VPhantom It depends on what you're trying to read. Last time I looked - which was a long while ago! - mmap didn't work well with Lwt because it doesn't have a way to perform non-blocking reads and writes
<d_bot>
<hcarty> What kind of values are you trying to manipulate?
<d_bot>
<VPhantom> I'm learning in general but short-term I'm going to read and write files in a few formats which I'm converting between (namely ANSI EDI X12 and a custom Protobuf structure).
<d_bot>
<VPhantom> I'll avoid stdio for now and just operate directly on files. I don't use Lwt for now so I intend to mmap for reading. For writing, I just need to create a file and append data to it so channels or file descriptors will be fine.
<d_bot>
<VPhantom> I'll want to figure out how to load files in memory eventually though, because that's very likely going to be needed down the road. (Template files and what not.) I hadn't looked at `Lwt_bytes` and `Lwt_io` closely yet; didn't think mmap for reading would be an issue there.
<d_bot>
<VPhantom> Thanks, I'm checking it out right now.
<d_bot>
<VPhantom> In my case I _almost_ read my input sequentially but there's a few instances of reading too much and rewinding a bit, hence why I scrapped the stdin idea.
sagax has quit [Quit: Konversation terminated!]
<companion_cube>
@VPhantom: if the files are not ginormous, reading them to memory is probably fast enough™
Serpent7776 has quit [Quit: leaving]
<d_bot>
<VPhantom> That's what I'm betting on. This is a batch tool so as long as memory use stays decent, I'm good. I just need to figure out a decent way to load a file into `bytes` and vice versa.
<d_bot>
<VPhantom> (I'm scrapping the mmap idea for now because I'll need `bytes` for `ocaml-protoc` anyway.)
<companion_cube>
I forget if there's a stdlib function for that now
<d_bot>
<VPhantom> Funny, there's an `in_channel.ml` in the Stdlib but I can't find it in the namespaces available in `utop`. 🤔
<companion_cube>
not sure it's released yet
<companion_cube>
anyway, my personal solution is `CCIO.with_in "foo" CCIO.read_all`
<d_bot>
<VPhantom> Oh wow Septembre 2021, I see yeah.
<d_bot>
<VPhantom> Thanks, I'll check that out.
<d_bot>
<VPhantom> `try while true do ... raise Exit done with Exit -> ...` I would never have thought of doing a "read-it-all" loop like that! 😱
<companion_cube>
:D
<companion_cube>
these days I use `let continue = ref true in while !continue do … done`
<companion_cube>
but you know, same difference.
<d_bot>
<VPhantom> I managed to miss `Bytes.extend` when I played with those last month. Sounds much better than creating a new one every time I need to grow.
<companion_cube>
hu, didn't know it either
<companion_cube>
I mean it still allocates
<d_bot>
<VPhantom> Oh, nevermind, it still creates a new `Bytes.t` and blits to it anyway, in all cases.
<d_bot>
<Anurag> extend creates a new bytes behind the scenes and then uses blit to copy things over
<d_bot>
<VPhantom> I thought it might've used `realloc()` or something when only extending on the right.
<companion_cube>
it's just simpler than create + blit
<d_bot>
<VPhantom> I still think a bit too much in C terms. 😉
<companion_cube>
well, the GC doesn't have realloc afaik :)
<d_bot>
<VPhantom> Yeah, I thought I might've seen a realloc somewhere for growing Bigarrays but I can't find it now so it must've been wishful thinking. 😛
<companion_cube>
ah, but bigarrays are different
<companion_cube>
they're in the C heap I think.
<d_bot>
<VPhantom> Of course, yes.
<companion_cube>
which is why they're pinned and can be passed to C blabla
<d_bot>
<VPhantom> bla indeed.
<d_bot>
<VPhantom> Just curious, since you do a final copy anyway in your `read_all`, why not read into a `Buffer.t` and then get `bytes` out of that at the end?
<d_bot>
<VPhantom> (…instead of hermit crab'ing growing bytes along the way)
<d_bot>
<Anurag> @VPhantom you probably saw `realloc` in core. They have functions that perform that operation for their bigstring
<d_bot>
<VPhantom> Possibly.
<sleepydog>
@VPhantom what do you want to eventually do with the data?
<d_bot>
<VPhantom> In this case, feed it to a Protobuf decoder which requires `bytes` input. The other decoder can take various things as input (bigstring, bytes, buffer, string) but I'll stick to bytes.
<sleepydog>
ah ok. I like the approach of reading into a `Buffer.t` and pulling your bytes out of that when you're done.
<d_bot>
<VPhantom> @Anurag Yup, that must be it.
<d_bot>
<VPhantom> @sleepydog: Yeah that's what I might do, although I just realized if I'm not bothering with `stdin` I might as well use the file's length to create an appropriately-sized `bytes` from the start and loop-read into that.
<sleepydog>
ah right, you said you ditched the mmap idea
<companion_cube>
@VPhantom: because I can't get the bytes out of Buffer
<d_bot>
<VPhantom> For now yes. I'd love to read that way but since half my formats require bytes anyway, might as well just use those uniformly for now.
unyu has quit [Quit: WeeChat 3.4]
<companion_cube>
I guess I could use `contents`, but well, it's simpler in this particular case to grow it myself
<d_bot>
<VPhantom> @companion_cube There's `Buffer.to_bytes` which copies to achieve it.
<d_bot>
<VPhantom> …but I think your `Bytes.sub_string` copies as well. 🤔
<companion_cube>
also, at the time, Buffer.input (or whatever) was broken
<companion_cube>
yes
<companion_cube>
reading into the buffer was hard
rgrinberg has joined #ocaml
<companion_cube>
I fixed that in the stdlib years ago but my code is still compatible with 4.03
<companion_cube>
anyway, at this point, fuck Buffer
<d_bot>
<VPhantom> I see, yes.
<sleepydog>
i missed the memo, what's wrong with Buffer?
<d_bot>
<VPhantom> Yeah I know where you stand on Buffer. 😉
<companion_cube>
look at Buffer.add_channel, it's weird
<sleepydog>
the implementation?
<companion_cube>
sleepydog: the API too restrictive and apparently no one cares
<d_bot>
<VPhantom> There was a pull request from ccube which didn't go well.
<sleepydog>
raises Invalid_argument if len < 0 or len > Sys.max_string_length -- huh?
<companion_cube>
yeah I'm angry about the PR
<d_bot>
<VPhantom> I thought it was quite reasonable but hey I'm new here.
unyu has joined #ocaml
<d_bot>
<VPhantom> (I'm wondering if blitting from an mmaped input file to bytes would be simpler than a DIY reading loop…)
<sleepydog>
but then you're back to only supporting files. as a lover of unix pipes I must object! :)
<companion_cube>
or unix sockets
<sleepydog>
unix sockets are mmap-able?
<companion_cube>
no, no
<sleepydog>
ah, sorry, misread
<companion_cube>
just saying reading loops are nice.
bobo has quit [Ping timeout: 256 seconds]
<d_bot>
<VPhantom> Even my loop would need the size of its input, the way I'm looking at things, to allocate one bytes of exactly the right size from the start. I agree that supporting stdio would be nice, but I'm cutting a few corners right now due to a deadline.
spip has joined #ocaml
<d_bot>
<VPhantom> Lots of `(* TODO ... *)` comments peppered around. 😛
<companion_cube>
do you _know_ it'll be too slow if you just use `CCIO.read_all`?
<d_bot>
<VPhantom> Oh, no Sir! But I'm not pulling in Containers _yet_ so this is a DIY function.
<companion_cube>
didn't you mention a deadline? 🙃
<d_bot>
<VPhantom> hehehe
<sleepydog>
:)
<d_bot>
<VPhantom> I might make more sense tomorrow. Time to call it a day!
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
zebrag has joined #ocaml
bartholin has quit [Quit: Leaving]
<d_bot>
<Guy Moquet> just wondering why there are no `List.reduce` in stdlib
<d_bot>
<Guy Moquet> is it because it'ss a bad practice? The stdlib yet contains many functions that throw exceptions
<sleepydog>
reduce is the same as fold, right?
rgrinberg has quit [Ping timeout: 250 seconds]
<sleepydog>
there is List.fold_{left, right}
<d_bot>
<NULL> fold with no default and an exception if the list is empty
rgrinberg has joined #ocaml
<d_bot>
<glennsl> doesn't seem all that useful when you can just combine `hd` and `tl` with a `fold` to accomplish the same.
<sleepydog>
e.g. `let reduce f l = List.(fold_left f (hd l) (tl l))
rgrinberg has quit [Read error: Connection reset by peer]
<d_bot>
<Guy Moquet> ah yes of course, thank
rgrinberg has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]