dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<dinosaure> Not yet but I plan to port caqti at least, it should require no much work, I can put on top of my todo list 🙂
<discocaml>
<yawaramin> is Miou a work-stealing scheduler? (sorry, i promise i read through the home page but am blanking on this 😅 )
<discocaml>
<limp.biskit> if you make a start on this, ping me. i’ll see if i can find any time to work on it
<discocaml>
<dinosaure> `Miou.call` transfers the promise to a random core, and `Miou.parallel` distributes tasks equally to all cores
<discocaml>
<dinosaure> I will do this week end 🙂 I will ping you when I have a PoC
<discocaml>
<limp.biskit> i’ve been working on an Eio web framework, and a long term goal for that is to experiment with a port to miou, since it seems to do a lot of things i want more cleanly than eio
<discocaml>
<dinosaure> So I think moonpool is probably better at this purpose if you think your application as CPU-bound conputation but about I/O bound, the random fact (for `Miou.call`) is important
<discocaml>
<limp.biskit> could miou run under moonpool!
<discocaml>
<dinosaure> So I think moonpool is probably better at this purpose if you think your application as CPU-bound computation but about I/O bound, the random fact (for `Miou.call`) is important
<discocaml>
<limp.biskit> could miou run under moonpool?
<discocaml>
<dinosaure> Not yet but if @companion_cube works on the same `Await` as me (about `picos`), a _transparent_ support should be possible
<discocaml>
<dinosaure> I mean, for my perspective, Miou launches several domains and we attribute randomly a specific core for a task via `Miou.call`. By this way, it's better, in some ways, to trigger some non-obvious bugs which depends on the core where the task is assigned (and for a security purpose, it's better to _obfuscate_ the way we execute tasks). For a CPU-bound application, it's surely better to assign the task to the first core available and, I think,
<companion_cube>
I want to do it, I just haven't had the time yet
waleee has quit [Ping timeout: 260 seconds]
tri has joined #ocaml
tri has quit [Ping timeout: 245 seconds]
<discocaml>
<dinosaure> And the composition between effects and handlers is open. Currently, you can just say: ok, I will run moonpool inside miou and it is possible actually
pi3ce has quit [Quit: No Ping reply in 180 seconds.]
pi3ce has joined #ocaml
<companion_cube>
we could also have a shim between the two, it's not that hard
<companion_cube>
eg await-ing a moonpool future from miou might be easy enough
<companion_cube>
(even though picos is the correct long term solution)
<discocaml>
<fabric.input_output> oh so I can just ditch lwt altogether
<discocaml>
<yawaramin> if you are ok with targeting OCaml 5+ only and using Eio
<discocaml>
<fabric.input_output> yeah I'm trying to make more of an app than a library
<discocaml>
<fabric.input_output> lwt was just the thing that came up more often
<discocaml>
<fabric.input_output> thanks
n8n has joined #ocaml
n8n has quit [Client Quit]
n8n has joined #ocaml
mima has joined #ocaml
n8n has quit [Quit: WeeChat 4.2.2]
n8n has joined #ocaml
tri has joined #ocaml
tri has quit [Remote host closed the connection]
tri has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ocaml
boozec has quit [Quit: boozec]
n8n has quit [Quit: WeeChat 4.2.2]
dnh has joined #ocaml
zanetti has quit [Quit: zanetti]
mima has quit [Ping timeout: 245 seconds]
waleee has joined #ocaml
bartholin has quit [Quit: Leaving]
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<limp.biskit> eio streams are pretty good
<discocaml>
<limp.biskit> is it just me or are the ocaml forums really unhelpful and passive aggressive? i've never posted there, but simple questions (which could be answered by very simple answers like 'use bytes!') often incite long arguments about the one true functional programmer
<discocaml>
<limp.biskit> and not as in pointing people towards less imperative datastructures, more just a nasty attempt to prove superiority over newcomers (in a language which has the intrinsic strength of being more attractive to newcomers than purer ones!)
<discocaml>
<contextfreebeer> example?
<discocaml>
<contextfreebeer> I have not seen that in the posts I've read but I don't hang around there so I only see a sample
<discocaml>
<limp.biskit> this is a minor example and most posts are people being sincerely useful - it just has one person being very rude which jumped out at me, and the best answer IMO (explaining, in the clearest language, the two methods and their safety and performance tradeoffs) is all the way at the bottom.
<discocaml>
<contextfreebeer> 😵💫
<discocaml>
<contextfreebeer> Yes, I'm inclined to agree
<discocaml>
<contextfreebeer> also I understand maybe wanting to stick to vanilla solutions but nobody seriously recommended any of the stdlib replacements which offer this operation directly? rather than simulating it manually with `mapi`?
<discocaml>
<contextfreebeer> it reminds me a bit of some Stack Overflow posts where somebody asks a simple question and there are a ton of answers with extremely indirect and complicated answerst
<discocaml>
<contextfreebeer> those really annoy me
<discocaml>
<contextfreebeer> this isn't quite the same though
<discocaml>
<limp.biskit> didn't realise this was in any
<discocaml>
<limp.biskit> containers has it which im already linking, which is probably the best route
<discocaml>
<contextfreebeer> yeah I am a big containers fan so I was thinking of that, I think I have seen it in Base but now you made me unsure
<discocaml>
<limp.biskit> i landed up using bytes.copy, which while im sure will piss many people in that thread off but was the best choice for what i'm doing
<discocaml>
<contextfreebeer> Base has `tr`, which is not exactly the same thing but works in a pinch
<discocaml>
<limp.biskit> containers inits a new string and sets each byte, which i *think* is slower than bytes.set
<discocaml>
<contextfreebeer> well considering it's an extension of normal strings I think it must do that
<discocaml>
<contextfreebeer> like somebody said if performance is your big worry then you should maybe consider how much string code you want to have anyway
<discocaml>
<contextfreebeer> probably bytes.copy and set will be faster I imagine
<discocaml>
<limp.biskit> yeah, i'm working with binary data and known indexes
<discocaml>
<limp.biskit> if anybody can point me to a good way to get a base64 string out of `bytes` i could skip using binary strings altogether
<dh`>
can't you just use String.init? maybe I didn't read the scroll carefully enough
<dh`>
as in, base64 encoding is basically just peeling 6-bit values off a stream of 8-bit values
<dh`>
so it's fundamentally a fold and you can tuck that inside the argument to String.init because we aren't limited to stateless functions
<discocaml>
<limp.biskit> yeah, true
<discocaml>
<limp.biskit> think i will rewrite like that actually, was being stupid and over-reliant on libraries
<dh`>
I'm not sure the library actually guarantees that String.init will call its init function in order, but I can't imagine any sane implementation where it doesn't
<dh`>
worst case probably is that it's back-to-front
<discocaml>
<limp.biskit> base64 is simple enough i can just convert a char myself
<dh`>
you can also use String.init and just compute the bits you need for the character it asks for, and fetch those from the bytes, and see if the resulting output code is adequate for your needs, it might well be
<dh`>
also if you're making strings to write to a file, and you care about the performance, check if writing the base64 characters to the file one at a time is actually faster, because it might be
<dh`>
(files are buffered, so if you write characters directly you add the overhead of the per-character write path, but lose the memory overhead of the intermediate string, and it's definitely possible to win that way, depending on circumstances and the sizes of the strings)
<dh`>
(raw OS-level writes one character at a time will never win though because system calls are expensive)
<discocaml>
<deepspacejohn> @limp.biskit I remember when this was posted. For context, I believe the OP had been asking a LOT of similar questions which I assume had worn down some people’s patience. Not trying to make excuses for anyone’s rude behavior, but I don’t think that topic is the best example of discussion there.
<discocaml>
<deepspacejohn> Although it goes to show how important it is to watch your behavior on a public forum, where your posts will live forever 🙂
<discocaml>
<limp.biskit> that's the only one that jumped out at me as people being outright hostile. nothing on that discourse is as bad as stack overflow and some projects irc's
<discocaml>
<limp.biskit> that's the only one that jumped out at me as a couple people being outright hostile. nothing on that discourse is as bad as stack overflow and some projects irc's
<discocaml>
<yawaramin> eh, you need only go back as far as yesterday to find this gem: 'maybe it’s time for you to find a basic programming course or a mentor.'
<discocaml>
<limp.biskit> still, it's a case of patience when you're dealing with people learning something for the first time. if i had encountered more threads like that as an outright beginner i would never have stuck with the language
<discocaml>
<limp.biskit> ok. maybe its worse than stack overflow :\
<discocaml>
<deepspacejohn> @yawaramin oh yeah I saw that. Oof.
<discocaml>
<limp.biskit> i think mainly people need to watch their behaviour on a forum indexed by google 🙂
<discocaml>
<limp.biskit> you tell one beginner to wear a dunce cap and go back to javascript, you tell everyone who has that same question the same thing
<dh`>
indeed
<dh`>
especially underrepresented folks
<discocaml>
<limp.biskit> the 'find a programming course' line is especially bad in that aspect
<discocaml>
<limp.biskit> if you want ocaml to be the only language you can't teach yourself, then go ahead. the end result will probably be fairly impractical, localised to people who went to expensive universities and not held onto very long by most that learn it
<discocaml>
<limp.biskit> if you took that approach to it's logical extreme and wrote all documentation in as dense terms as your brain can muster, then tell anyone who complains to get a tutor, i doubt most languages would ever make it out of the academic circuit in their country of origin
<dh`>
most languages don't
<dh`>
:-)
<dh`>
anyway, people should never post stuff like that, even in response to annoying questions. where's the moderator?
<dh`>
there is definitely a phenomenon where people at a certain level post questions before bothering to think for thirty seconds on their own, and it's irritating to deal with, but it's also a well-known phenomenon and any beginner-oriented questions forum should have a procedure in place
<discocaml>
<limp.biskit> people don't remember there's a human on the other side who, if they're asking a question, is probably also tired or confused
<dh`>
at some level the phenomenon where people ask first and think later happens because they've been trained to
<dh`>
in a class where people are paying attention to these issues, answers will become progressively slower and more in the form of leading questions the more people ask, to avoid this
<dh`>
however, lots of people get trained by badly run classes to ask early and often and not bother thinking first
<dh`>
and lots of classes encourage this in the mistaken belief that asking questions and engaging is an unlimited good, which it isn't entirely
<dh`>
but in random places on the internet there are rarely teachers and easy questions usually get quick answers, so people get trained this way and it works fine until they overdraw, at which point people who aren't teachers don't recognize the symptoms, they just run out of patience
<dh`>
and then some fraction of them will become nasty as a result, and that doesn't go well
<dh`>
and when it comes down to it, encouraging people to think is the hard part
<dh`>
nearly everyone would rather avoid having to think