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.
lizmat timo: it looks like the Windows sleep fix breaks Terminal::LineEditor on ARM 11:42
the symptoms: \n appears to become a LF only in the terminal, and messes up the terminal so badly that even a hard reset doesn't fix it 11:43
does that ring a bell? 11:44
going to revert the sleep fix for now 11:49
lizmat after double checking on Intel 11:53
timo uhhh 11:54
i don't think it's possible for that to be the cause
that sounds really really strange
lizmat well, if I build rakudo at dfcf45b8f999091eb30, there is no issue
timo by "hard reset" you mean the "reset" terminal command? can you also try "stty sane"?
lizmat if I build rakudo at 775e8ff96e784165b72, there is
timo and when you say \n "becomes LF only" that means newlines don't move the cursor back to the left? 11:55
lizmat selected the "hard reset" in the terminal app
yes
timo ok i have no idea what that is or does :)
lizmat ok, building main again 11:56
to verify
timo wait, you're on arm 11:57
there isn't even jit there
lizmat yes
timo the change was only in the jit
lizmat well, I can only tell you what I see :-) 11:58
timo when the situation is there where it's treating \n wrong, is there still a rakudo or moar process running on the terminal?
lizmat the problem does not exist on Intel
timo it's still possible there's a bug with the makeraw nativecall stuff 11:59
if we're getting the struct size wrong still (or again, or different) we might be getting random data fed into the syscall in question that depends on stuff like exact size of the binary, history of malloc and free calls before that point, memory layout randomization, etc etc 12:00
is it easy for you to build a rakudo with ASan? 12:01
lizmat if you can tell me how :-)
meh 12:02
timo you can pass --asan on moar's Configure, it will also spit out a little piece of commandline that you need to use if you want to build rakudo or run pretty much anything because there's a little bit of stuff left un-deallocated when we quit because we let the destruction of the process do all the work
oh, you probably also need to rebuild nqp?? 12:03
lizmat I have no idea how, but the problem appears to have gone away
timo that's annoying :(
lizmat only difference since last night, is that I nuked ~/.raku/precomp
timo we really need to figure something out to make all your stuff easier and faster to reproduce 12:05
how much hard drive space do you have free?
lizmat less than 40G
ah, no
timo ok, how big is your ~/.raku + the folder the rakudo stuff is installed to, i.e. your prefix? 12:06
lizmat 556K 12:07
timo sounds like it would be viable to just copy the entirety of those away to a fresh directory after any rebuild you do 12:08
556K is the size of these folders, not how much free space you have right?
lizmat yes 12:09
sorry for the noise 12:17
I guess once we hit full test coverage in RakuAST, we need to look at the whole precomp logic again
because I suspect there's at least 1 race condition in MoarVM / NQP / Rakudo re precompilation 12:18
(because almost all spectest flappers actually need to load an external module)

Powered by Cro and the Raku® Programming Language.

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

Thank you!