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.
00:06 reportable6 left 00:07 reportable6 joined 00:16 kjp left, pamplemoussecach joined 00:23 kjp joined 00:49 pamplemoussecach left 00:54 pamplemoussecach joined 01:05 pamplemoussecach left 02:05 notable6 left, bisectable6 left, committable6 left, coverable6 left, linkable6 left, quotable6 left, statisfiable6 left, bloatable6 left, tellable6 left, reportable6 left, squashable6 left, benchable6 left, unicodable6 left, greppable6 left, sourceable6 left, nativecallable6 left, evalable6 left, shareable6 left, releasable6 left, tellable6 joined 02:06 shareable6 joined, statisfiable6 joined, evalable6 joined, greppable6 joined, reportable6 joined, committable6 joined 02:07 benchable6 joined, quotable6 joined, squashable6 joined, sourceable6 joined, releasable6 joined, nativecallable6 joined, notable6 joined, coverable6 joined 02:08 bloatable6 joined, unicodable6 joined, bisectable6 joined, linkable6 joined 02:52 pamplemoussecach joined, pamplemoussecach left 04:19 coverable6 left, bloatable6 left, notable6 left, unicodable6 left, greppable6 left, nativecallable6 left, benchable6 left, linkable6 left, reportable6 left, quotable6 left, tellable6 left, committable6 left, bisectable6 left, statisfiable6 left, releasable6 left, sourceable6 left, squashable6 left, evalable6 left, shareable6 left, shareable6 joined 04:20 sourceable6 joined, committable6 joined, unicodable6 joined, nativecallable6 joined, squashable6 joined, notable6 joined, reportable6 joined 04:21 evalable6 joined, tellable6 joined, greppable6 joined, linkable6 joined, quotable6 joined, benchable6 joined, bisectable6 joined 04:22 bloatable6 joined, coverable6 joined, releasable6 joined, statisfiable6 joined 04:29 vrurg_ left 04:30 vrurg joined 06:06 reportable6 left 06:07 reportable6 joined
Nicholas good *, * 06:14
09:06 notable6 left, benchable6 left, quotable6 left, bisectable6 left, bloatable6 left, unicodable6 left, committable6 left, sourceable6 left, tellable6 left, linkable6 left, reportable6 left, squashable6 left, evalable6 left, coverable6 left, nativecallable6 left, shareable6 left, greppable6 left, statisfiable6 left, releasable6 left, committable6 joined, releasable6 joined, sourceable6 joined, shareable6 joined 09:07 tellable6 joined, statisfiable6 joined, benchable6 joined 09:08 squashable6 joined, unicodable6 joined, notable6 joined, evalable6 joined, nativecallable6 joined, coverable6 joined, quotable6 joined 09:09 greppable6 joined, bloatable6 joined, reportable6 joined, bisectable6 joined, linkable6 joined 09:23 sena_kun joined 10:23 squashable6 left, benchable6 left, coverable6 left, bloatable6 left, tellable6 left, reportable6 left, bisectable6 left, notable6 left, shareable6 left, unicodable6 left, evalable6 left, committable6 left, nativecallable6 left, statisfiable6 left, linkable6 left, greppable6 left, quotable6 left, sourceable6 left, releasable6 left, evalable6 joined 10:24 coverable6 joined, notable6 joined, sourceable6 joined, squashable6 joined 10:25 committable6 joined, benchable6 joined, greppable6 joined, unicodable6 joined, nativecallable6 joined, shareable6 joined, bloatable6 joined 10:26 quotable6 joined, bisectable6 joined, statisfiable6 joined, tellable6 joined, releasable6 joined, reportable6 joined, linkable6 joined 11:26 coverable6 left, bisectable6 left, nativecallable6 left, shareable6 left, committable6 left, notable6 left, bloatable6 left, sourceable6 left, quotable6 left, tellable6 left, linkable6 left, evalable6 left, squashable6 left, greppable6 left, benchable6 left, statisfiable6 left, reportable6 left, unicodable6 left, releasable6 left, linkable6 joined 11:27 benchable6 joined, squashable6 joined, nativecallable6 joined, bisectable6 joined, shareable6 joined 11:28 committable6 joined, quotable6 joined, coverable6 joined, bloatable6 joined, greppable6 joined, tellable6 joined, unicodable6 joined 11:29 statisfiable6 joined, notable6 joined, sourceable6 joined, evalable6 joined, reportable6 joined, releasable6 joined 12:07 reportable6 left 12:10 reportable6 joined 13:27 pamplemoussecach joined 13:43 pamplemoussecach left
vrurg I had no idea, how unsafe our unicode ops are... 14:53
japhb Unsafe in what way? 15:04
16:17 linkable6 left, evalable6 left 16:18 evalable6 joined 16:19 linkable6 joined 16:25 discord-raku-bot left 16:26 discord-raku-bot joined 17:52 pamplemoussecach joined 18:07 reportable6 left 18:09 reportable6 joined, pamplemoussecach left 18:11 pamplemoussecach joined 18:12 pamplemoussecach left 18:14 pamplemoussecach joined 18:18 pamplemoussecach left 18:30 squashable6 left 18:31 squashable6 joined
vrurg japhb: hash is used inside 19:43
github.com/MoarVM/MoarVM/issues/1717 19:44
20:10 sena_kun left 20:11 sena_kun joined
timo so we may have to lock against simultaneous attempts to create the property_codes_by_seq_names and property_codes_by_names_aliases hashes? 20:25
ah, you also pointed out a spot in unicodey.pm6 where we do bindkey something into the $name2pref hash? 20:27
not sure if that hash is tiny or big 20:28
20:29 sena_kun left
timo brilliant, i got a crash reproduced 20:42
takes a lot of attempts 20:43
now the setting up of the property codes lookup hashes is protected by a mutex 20:58
Geth MoarVM: 9bc1beed70 | (Timo Paulssen)++ | 3 files
protect the two property code lookup hashes being set up with a mutex
 21:00
timo vrurg: please grab this patch and see if your application still manages to crash
vrurg timo: Oh, I was about to complain that it is to be fixed at MoarVM. :)
The testing might take a week or two. Normally it fails like once in 3 days or so. 21:01
timo yeah
you can't up the load on this program?
vrurg Hence negative proof is better be ~3 times longer period.
timo if the problem is what i am fixing, it'd help to restart the program after it has successfully handled a few requests
vrurg Nah, it is VERY specific and a private property of my employee. 21:02
I'm stupid. The tools is cron-started. I can just change the schedule. 21:03
timo :D 21:04
you can run it in a tigh loop too perhaps
i'll give you my reproducer script too
use nqp; my $lmao = Promise.in(0.01); my $o; await do for ^1000 { start { await $lmao; $o = nqp::unipropcode(<ASCII ASCIIHexDigit AboveLeft Braille C CB changes_when_lowercased 3-Heth 3-Beth>.pick) } }; 21:05
just `rakudo -I. -Mdo_it -e ''` in a loop until it exits with nonzero
even though i made it do a lot less sleeping, it still takes very very long to crash sometimes 21:07
now it was two in very short succession :D
MoarVM oops: insert conflict, changeswhencasefolded is 1649993372, 38 != 96
MoarVM oops: insert conflict, prepended_concatenation_mark is 755562829, 92 != 6
vrurg It's so crazy day, I barely manage to share myself between tasks... Gonna try your script. 21:15
timo that's okay! 21:16
ith the patch i've run it for a couple of minutes and it's entirely too warm to heat up my cpu to 75degC for any extended amount of time uggghhh :)
without the "mvm oops" of course
vrurg Segfault for the first run on unpatched moar. Trying the second one. 21:25
timo oh wow segfault? not even a moarvm oops but a full blown segfault? 21:28
vrurg Right. 21:31
But the second run – it just runs so far.
timo do you happen to have a backtrace from that core dump or something? this is for your production script rather than my reproduction script? 21:32
vrurg There is no debug info. But the top frame is in MVM_uni_hash_insert 21:33
Invoked from MVM_unicode_name_to_property_code
timo good to know, i'll have a look that way 21:37
ah yes, that's one of the functions i've put a lock into
lizmat timo: the bindkey in unicodey is inside a protect block, so shouldn't be a race condition ? 21:40
timo i haven't looked at that yet :) :)
you mean the only way to ever get this crash is by going past unicodey.pm6 and straight to nqp code? 21:41
vrurg timo: don't forget, I'm still testing the unpatched version. Just wanna make sure it does fail for me with your test.
lizmat github.com/rakudo/rakudo/blob/mast...y.pm6#L155
timo aha 21:42
but the problem is the call to nqp::unipropcode
vrurg Unicode ops are used across NQP and Rakudo. The only valid protection is in their bodies.
timo that's why you can still get the race and explosion
lizmat fair enough, but then a protect block here wouldn't help either, so indeed a MoarVM solution is needed
timo ayup, the very one i've implemented i would dare claim :) 21:43
vrurg lizmat: But the protect is still needed there because $name2pref is getting updated.
timo i'm not sure what we are updating name2pref for exactly 21:44
lizmat yeah, that's rakudo land
vrurg A little improvement to the test made it fail more reliable. Two insert conflicts in a row – I'm convinced! ;) Moving on to trying the patch. 21:48
*reliably 21:53
22:09 linkable6 left, evalable6 left 22:11 evalable6 joined, linkable6 joined
vrurg 1900 repetitions of the patched version against as maximum as 72 for the unpatched one. I think the computer simulation proves the theory. ;) 22:12
timo that's a pretty good ratio of time-of-implementation to impact-of-fix i think
vrurg Not to mention that normally it fails within 30-40 repetitions.
timo: Absolutely!
timo thanks for bringing it up because i am not good at keeping up with our bug trackers 22:13
vrurg With this respect I always recall my three weeks spent on lost closures for precompiled code in BEGIN. Only to come up with a single-line patch. :) 22:14
timo sadly, it's not a "life hack" to just point me at every bug now because it just randomly happened that i saw the problem so quickly here (actually the golf to nqp::unipropcode was 99% of the work necessary)
phew
that is a rough one
vrurg This is a kind of teamwork I like. :) Thanks a lot, those `$ is not a currency sign` errors I am receiving once in a while are so annoying. 22:15
I wouldn't be surprised is another problem with `symbol not found in a module` errors would also be gone because that could be a memory corruption as a side effect. 22:16
timo aye, very unfortunate error reporting there
vrurg Anyway, thanks again! I'm going to re-focus on other tasks. 22:18
timo hey how much do you need to change in vikna to benefit from the resumption improvements we got from new-disp? do you have the opportunity to work on vikna more this year? 22:19
i don't actually have a real strong use case / need for vikna right now 22:23
it's just kinda cool that vikna more or less forced this whole piece of work to get started 22:24
vrurg timo: No spare time for the project, unfortunately. 22:52
I think it can be adapted for all the latest changes. But the biggest matter is to make use of C for canvas. 22:54
japhb vrurg: What are you using now? 22:55
vrurg Raku. :) 22:56
A lot of nqp::.
japhb Vikna is terminal-based, yes?
vrurg Right.
japhb Did you do it bespoke, or base it on Terminal::Print?
vrurg Up to some extent. Only the very basic functionality like getting the right ANSI codes. 22:57
Ah, and keyboard input.
japhb Interesting. Terminal::Print's compositing has had a fair amount of (pure Raku) tuning, so it's definitely capable of animation, though I remember something about Vikna's default compositing being more complex than Terminal::Print does out of the box. 23:00
vrurg japhb: consider overlapping windows, Z-order. 23:01
japhb Nod. I'm adding Z order in Terminal::Widgets (which is based on Terminal::Print) 23:03
vrurg What I haven't manage to done properly is synchronous drawing of frames and their client windows. 23:04
What about background scrolling/drawing of planes?
japhb Terminal::Print has a group of modules based around Terminal::Print::Animation that render (optionally in parallel) and composite their children recursively in order. This requires keeping said children in "z order" if you're overlapping. 23:07
That extra effort is part of why Terminal::Widgets will handle the Z reordering natively.
vrurg So, you could probably implement it all, eventually. 23:08
Vikna was a good experiment. But is unlikely to become a living thing. 23:09
japhb Of Vikna? Or of Vikna's rendering engine?
I thought that the cool bit of Vikna was the dispatch model?
Terminal::Widgets is using the HTML DOM "trickle down / bubble up" event model 23:10
Partially because it's reasonable to understand, and partly because I discovered that lots and lots of Supplies and Channels (my first event model design) caused a laggy UI that I didn't understand enough to be able to optimize. :-) 23:11
23:11 evalable6 left, linkable6 left 23:12 linkable6 joined
japhb (I wonder how many of my architectural decisions come down to "I'm not smart enough to make this awesome, so let's do something I *can* understand"?) 23:12
23:12 evalable6 joined
vrurg I seemingly almost failed to manage the supply/channel model too. Though it only affected the sync thing about frames/clients. 23:13
The big problem was in maintaining clipping masks. 23:14
Ok, I'll be afk for at least an hour.
japhb \o

Powered by Cro and the Raku® Programming Language.

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

Thank you!