Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
03:32 vrurg left 03:44 vrurg joined 08:35 mandrillone joined
mandrillone In my opinion, libuv, a part for being an obvious semi-unmantained security hole, solves the problem of portability the wrong way 08:36
it made up an arbitrary (and often unsafe) api loosely inspired on posix 08:37
but worse
while the solutions working historically has been two: 1. stick to posix, with a lesser experience on GNU and worse in Windows 08:38
2. make it optimal on GNU, letting the windows people implement their own backend if they care so much 08:39
there is no magical libuv recipe 08:40
A part of this rant, async io exists for two reasons 08:42
1. to save memory by using cheaper kernel side structures then threads when they were used for asynchronous io 08:43
2. more subtle, to improve on page faults when doing zero copy cow memory transfers from user to kernel by making sure that user side buffers aren’t reused for writing 08:45
things like ring buffers and shared memory 08:46
This applies to very low level languages. I don’t see how any of this applies to raku, that clearly has stronger overheads 08:47
There are things in raku that will make it forever unsuitable for things like web services. For instance paying for Unicode in every single string. Very slow dynamic scoping 08:49
08:49 mandrillone left 10:54 mandrillone joined
mandrillone Personally, if I have to populate an hash with keys, it is faster to pipe them to Perl and make a hash over there then to just doing it in Raku. The reasons for this are still totally a mistery to me, I suspect Unicode but brutally even the hashing algorithm (that is something nobody should ever care about ) could be the culprit 10:56
10:57 mandrillone left
lizmat I wonder whether mandrillone can rant all they will, but unless they start actually making PRs, I think they can better be continue to use Perl, as that's "clearly" a better language 11:30
jdv it is faster on the whole 12:58
lizmat yeah, getting kinda tired of people telling us all the things wrong with Rakudo, especially if they're coming from Perl 13:07
if someone would really care, they would help fixing it, rather than just telling what's wrong in their opinion 13:08
jdv ideally, yeah 13:11
but the people that use a thing arent always able to make/improve it 13:12
lizmat true, but this person clearly is not the average non-technical user 13:41
ugexe you have to expect some people are going to complain about any given language. ive never used a language which lacked people complaining about aspects of it. it is also true most of that complaining provides no value to anyone 14:04
jdv trends arent valuable? if a bunch of peeps complain about something it might be a thing:) 14:33
but yeah, complainers gonna complain:) 14:34
ugexe it depends on the complaint. trade-offs inherently mean something is less-than-ideal, and most complaints with little to no value do not recognize that and come from a mindset that there is one True solution and that it is practical 14:37
jdv too many :), sorry
ugexe for instance commenting on libuvs shortcomings likely isn't enlightening to anyone here when it was used primarily because it made it practical to accomplish things that otherwise there was not bandwidth for 14:39
nine Well at least it serves as a reminder that the decision that may have been correct back then might no longer be the right one now. 14:47
ugexe it is probably more correct now than ever if we are talking about bus factor 14:49
nine There's that. On the other hand we have a quite mature base and no pressure to do huge changes, so an enterprising individual may give ripping out libuv a try at their leisure 14:50
ugexe potentially. that assumes there is appropriate bus factor for reviewing such changes (I'd argue there is not) 14:51
15:09 nine left 15:10 nine joined
timo i think there's a lot of untapped potential in spesh if someone smart enough™ can revive jn's more-pea work from years ago 18:14
i don't think the cost to NFG in every string is prohibitively high for real world usage, but I don't exactly have a benchmark to look at for the given suggestion 18:16
how do we feel about making a TTY a first-class citizen in Raku? libuv has a "make raw" function that also does whatever is necessary on windows i seem to recall 18:17
and if we "makeraw" down in moar land, we can also properly atexit the corresponding makecooked so even in case a segfault or other kind of catastrophic error happens we leave the terminal in a sane state 18:18
like when we hit MVM_oops or MVM_panic
lizmat feels like a plan to me!
timo then we have to decide how it should look in the language when $*IN is a tty or isn't one. currently we have $*IN.t for "is a tty?". it could be a different type, or simply a subtype kind of like CatHandle, or just an IO::Handle that is able to .Supply properly asynchronously 18:20
but that latter thing can easily become confusing
also, of course you can have not just $*IN be a TTY, you can also open files from the file system, like /dev/pty*, that can be opened as a tty 18:21
and for creating a tty that can be passed to another program, we have the initial work from patrickb 18:22
learn.microsoft.com/en-us/windows-...ne-utility - whoa. 19:38
[Coke] nifty 19:40
timo does anybody remember if i had anything very specific that i was looking into when trying to find what about rakudo on arm debian was not working? 19:47
looks like it was particularly segfaults in the nqp package on arm buildds 19:50
I think I might have missed that the buildd's that got segmentation faults for nqp were still using moarvm packages without the fix and therefore it was very unsurprising that they crashed, and when I tried my best to reproduce the crashes on arm porter boxes I was already getting the fixed moarvm versions and that's why i could absolutely not get the crash reproduced 20:01
so maybe i'll go crawl into a little hole in the dirt and never ever come out again? 20:02
lizmat nooo! 22:23
tellable6 2025-04-24T19:21:09Z #raku <melezhik.> lizmat: thanks 🙏 for all your help

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!