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:02 reportable6 left 00:04 reportable6 joined 00:09 patrickb left 00:58 discord-raku-bot joined 01:19 discord-raku-bot left 01:20 discord-raku-bot joined 01:48 discord-raku-bot left 01:56 discord-raku-bot joined 02:01 CaCode_ joined 02:03 CaCode- joined 02:04 CaCode left 02:06 CaCode_ left 02:08 discord-raku-bot left, discord-raku-bot joined 04:10 nativecallable6 left, quotable6 left, greppable6 left, reportable6 left, notable6 left, linkable6 left, coverable6 left, bisectable6 left, unicodable6 left, bloatable6 left, statisfiable6 left, squashable6 left, committable6 left, sourceable6 left, evalable6 left, releasable6 left, shareable6 left, tellable6 left, benchable6 left, committable6 joined 04:11 releasable6 joined, bisectable6 joined, squashable6 joined 04:12 coverable6 joined, greppable6 joined, unicodable6 joined, nativecallable6 joined 04:13 statisfiable6 joined 05:11 notable6 joined, sourceable6 joined 05:12 reportable6 joined, shareable6 joined 05:13 bloatable6 joined 06:02 reportable6 left 06:03 reportable6 joined 06:12 benchable6 joined 07:12 quotable6 joined, evalable6 joined 08:11 tellable6 joined
Geth MoarVM: bb719a6304 | (Stefan Seifert)++ | src/spesh/inline.c
Fix uninitialized register after PEA and inlining

The register in question should have been written to by a PHI node and carried the appropriate deopt usage markers. The other side of the PHI (just one version) didn't. So PEA optimized away the writer.
Fix by copying the dopt_users from the PHIs target to the PHI's sources when rewriting returns. This way PEA knows that it has to keep the writer alive.		 08:59
09:13 linkable6 joined
dogbert17 Good morning Nine, already hard at work I see :) 09:15
Geth MoarVM/fix_unwind_missing_frame: 4 commits pushed by (Stefan Seifert)++ 09:19
nine dogbert17: Good morning! Well, I didn't do much this week. About time to finish up these PRs 09:20
Geth MoarVM/master: 5 commits pushed by (Stefan Seifert)++, niner++
dogbert17 checks if the commits fixes the 'indent' bug 09:21
nine It doesn't 09:25
dogbert17 Yep, I even reported it as github.com/MoarVM/MoarVM/issues/1616 09:26
nine Ah, yes, it's a clear bug in MVM_disp_program_run 09:43
Collects MVMObject pointers in the local resume_state_values array but those are ignored by the GC
dogbert17 what, no rabbit hole? 09:49
09:54 CaCode_ joined 09:56 CaCode- left
Geth MoarVM: 6fd623291a | (Stefan Seifert)++ | src/disp/program.c
Fix possible access to fromspace in MVM_disp_program_run

MVM_disp_program_run collected MVMObject pointers in the local resume_state_values array but neglected to tell the GC about those. This could lead to outdated pointers getting written to resume state targets followed by memory corruption.
... (5 more lines)		 10:07
dogbert17 Nine++, impressive 10:17
10:29 squashable6 left 10:31 squashable6 joined
timo whew, you actually ran into this, huh :D 10:38
did we run that gcc plugin any time in the recent-ish past?
(should we perhaps put it into CI?)
10:38 linkable6 left
timo oh, i should probably really run coverity scan again 10:39
10:39 linkable6 joined
nine Well first step would be to make running the GC plugin easier 10:42
10:49 linkable6 left
dogbert17 ++timo for coverity scan, it's been a while 10:50
10:51 linkable6 joined
dogbert17 I'm more or less out of bugs, only the 'hyper' one remains although I'm not certain that it's MoarVM related 10:52
10:54 CaCode- joined
dogbert17 shouldn't all these fixes warrant a bump? 10:56
dogbert17 looks for lizmat
10:56 CaCode_ left
lizmat you rang? 10:56
tellable6 2021-12-03T21:38:44Z #raku <tbrowder> lizmat are you going to publish yr day 4 at midnight utc today?
2021-12-04T01:18:28Z #raku <tbrowder> lizmat i published yr day 4 article, mine is in draft for day 5. for some reason i cannot find the way to schedule the post, just publish manually.
dogbert17 lizmat: fancy a bump given that there aren't any protests. Nine is on a bug killing spree :) 10:57
lizmat ok, could do
10:58 linkable6 left
dogbert17 ++lizmat 11:06
lizmat bumped 11:21
11:27 CaCode- left
dogbert17 yay, lizmat++ 11:28
lizmat: out of curiosity, are you planning on getting an M1 Mac? 11:55
nine Darn....when testing my latest fix I got a segfault in repl.t. Coredump says we processed beyond the boundaries of the current frame's bytecode. Have tried to reproduce it in rr, but so far no luck 11:58
12:02 reportable6 left
lizmat dogbert17: not for the foreseeable future as I'm a bit cash strapped atm :-( 12:06
dogbert17 let's hope some Euros comes flying your way then :) or Apple lowering their prices ... 12:13
lizmat he... yeah, probably won't be this year... but there's fortunately not a lot of this year left :-) 12:15
nine Fixing the p6-algorithm-evolutionary-simple test failure won't be as easy as I'd hoped either. I figured we could just disable the "Cannot unbox %d bit wide bigint into native integer" errors for values > -2**64 and < 2**64. But a test and 2 spec tests explicitly test for those 12:34
Disable until the multitude of errors in handling unsigneds are fixed I mean
13:04 reportable6 joined 13:19 [Coke] left
jnthnwrthngtn Hmm. So what in MVM_disp_program_run allocates? 14:09
ah, right, the resume states are written after the bytecode frame invocation 14:12
nine Ah, adding a uint_box_type leads to the joy of bootstrapping issues. Maybe I should just add a syscall for setting single hll config keys, so I can do that later on. We don't really need UInts that early on anyway 14:21
14:35 evalable6 left, evalable6 joined 14:59 linkable6 joined
nine Oh syscalls are so nice. Just a single file to modify for adding one. No changes to NQP necessary :) 16:16
16:38 evalable6 left, linkable6 left 16:39 evalable6 joined
nine "Fun" fact 16:39
P6ints only get the unsigned flag in their storage spec initialized if a native size is set at compose time 16:40
For MoarVM, uint is actually not unsigned
Well NQP's uint that is 16:41
rakudo actually does it right, so the fix is easy to steal :) 16:44
Now that it's finally doing the right thing (tm), I end up with "You cannot create an instance of this type (UInt)" 16:48
Because of course....UInt is a subset type (hence the bootstrap issue mentioned earlier). It cannot be created directly. But...where then do UInts actually come from?
lizmat nowhere yet, afaik 16:49
UInt is just a subtype atm
nine Hm....I can actually use the int_box_type as target of the boxing but call MVM_repr_box_uint based on the lexref target type's (i.e. UInt) unsignedness. That's kind of baking the subset issue into the VM. 16:53
But! With this p6-algorithm-evolutionary-simple passes its test suite!
17:03 [Coke] joined 17:41 linkable6 joined 18:02 reportable6 left 19:05 patrickb joined 20:04 reportable6 joined
nine A little downside of handling unsigneds correctly is that Blob and Buf need to use the correct ops, i.e. atpos_u vs. atpos_i depending on the signedness of their base type. I wonder how I can implement that without tanking performance 20:20
In theory the static optimizer should be able to constant fold something like T.^unsigned ?? atpos_u(...) !! atpos_i(...) 20:21
MasterDuke why would it tank performance? a new branch for every op?
nine That or somehow use mixins or something like that to get the appropriate methods 20:22
MasterDuke sena_kun, jnthnwrthngtn: fyi, the cert for commaide.com expired today 20:33
but i accepted the risk and continued, because i want to try out the heap snapshot viewer 20:37
20:40 Guest12 joined 20:43 [Coke]_ joined 20:45 [Coke] left
Geth MoarVM: MasterDuke17++ created pull request #1617:
Alloca the nativecall args that we can		 21:25
22:27 Guest12 left 22:36 [Coke]_ is now known as [Coke]
lizmat nine: I wouldn't worry about the performance in that respect: we can easily generate the code for using atpos_u vs atpos_i 22:36
timo and put everything spesh has that's already working for atpos_i to work in atpos_u without any change i assume 22:48
sena_kun MasterDuke, not sure if jnthn was that quick, but cannot confirm, it says valid to 5 March to me. 23:14
MasterDuke huh. someone else in #raku got the same message, but i'm not getting it now 23:16
timo it's the difference between www.commaide.com and commaide.com i think 23:17
without www i can access it fine, otherwise i get a security warning

Powered by Cro and the Raku® Programming Language.

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

Thank you!