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.
nine Ah, yes, we really should re-use those deprecated ops much more agressively 09:14
nine Nice: though there are tons of failures in the current Blin run, none of them seem to be caused by my changes 09:38
Nicholas I'm inferring that installed systems (mostly) have to rebuild installed bytecode on new releases of the setting, 09:46
meaning that we don't actually have to run older bytecode on new MoarVM *that* often
meanign that it doesn't matter *as much* that it's efficient. Only that it works. 09:47
that we might be able to completely re-number the opcodes
(and know how to load and re-map older bytecode in the validator)
but then I thought "worry about this when extops die"
MasterDuke Nicholas: did you see my comment on 'mimalloc' vs 'use_mimalloc' on github.com/MoarVM/MoarVM/pull/1638 ? i think that's the reason for the ci fails 09:50
Nicholas yes. incoming. 09:52
but the comment on it will not be incoming for a bit
(thanks for the diagnosis)
MasterDuke i also have a wip patch (against master) to convert MVM_recalloc to take a new count + new size (like calloc does) instead of old total size + new total size so we can use mi_recalloc 09:53
oh, and do you think you could add `ignore = untracked` to the .gitmodule entry? 09:55
Nicholas ah OK. But not right now as I'm building something else 09:56
and "need" coffee
MasterDuke no worries, just got a second cup a couple min ago myself 09:57
MasterDuke committable6: 25ca206~1,25ca206 say List({:1a, :2b})   # this is what broke Crane 10:28
committable6 MasterDuke, ¦25ca206~1: «({a => 1, b => 2})␤» ¦25ca206: «(b => 2 a => 1)␤»
MasterDuke is this a bug in coercion/dispatch, or expected behavior? if the latter, then we'll have to revert 25ca206 (i.e., add back those CALL-MEs i removed) 10:31
jnthnwrthngtn, vrurg: ^^^
Geth MoarVM/fix_unsigned_for_merge: 6 commits pushed by (Stefan Seifert)++ 12:30
MoarVM: niner++ created pull request #1639:
More preparations for fixing unsigned handling		 12:37
nine With those out of the way, the remaining core of interdependent changes looks somewhat manageable :) 12:55
lizmat let's merge! :-) 13:02
bartolin nine: I didn't really follow your work on fixing/improving handling of unsigned ints. Am I right in assuming that the other backends would need to support the new ops as well? 13:03
(or should I raise that question in one of the PR or over at #raku-dev?) 13:07
lizmat bartolin: looks to me raising it in the PR would be the best chance of it not falling through the cracks :-) 13:13
bartolin will do 13:17
nine Yes, they will 13:23
bartolin ah, I just asked in github.com/Raku/nqp/pull/756 13:24
lizmat sanity check: can MoarVM be considered a registered based VM ? 14:20
nine Register based VM? Yes, absolutely
lizmat oki, thanks! 14:26
MasterDuke lizmat: been reading news.ycombinator.com/item?id=29850562 ? 14:47
MasterDuke m: my $v = 3; my $sign = $v +> 31 ?? -1 !! 1; say $sign    # this is less than ideal 15:22
camelia (signal SEGV)
Nicholas ==22075==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f322e7be1f2 bp 0x7ffeba1d2800 sp 0x7ffeba1d27f0 T0) #0 0x7f322e7be1f1 in at_key src/6model/reprs/P6opaque.c:1469 16:10
lizmat MasterDuke: no, actually it was twitter.com/chrisgardenuk/status/1...0109725697 16:13
dogbert17 bisect: my $v = 3; my $sign = $v +> 31 ?? -1 !! 1 18:06
bisectable6 dogbert17, Will bisect the whole range automagically because no endpoints were provided, hang tight
dogbert17, Output on all releases: gist.github.com/9f32a8d5d9273967bb...f98b9c296c
dogbert17, Bisecting by exit signal (old=2021.12 new=21d988d). Old exit signal: 0 (None)
dogbert17, bisect log: gist.github.com/31e0f21d74489a410d...5f4c6e3909
dogbert17, (2021-12-16) github.com/rakudo/rakudo/commit/71...7d13855ce1
dogbert17, Output on all releases and bisected commits: gist.github.com/c861c8877f1e7a9b61...0a7d850c9f
vrurg MasterDuke: It is expected. You coerce a hash into a List. 19:44
m: say {:1a, :2b}.List
camelia (a => 1 b => 2)
vrurg m: say List.new({:1a, :2b}) 19:45
camelia ({a => 1, b => 2})
Geth MoarVM: nwc10++ created pull request #1640:
Support using C11 atomics as an alternative libatomic_ops		 19:49
Nicholas Geth: technically that was a *draft* PR 19:53
MasterDuke vrurg: ok, guess we need to revert github.com/rakudo/rakudo/pull/4701 then 19:56
so that segfault i demoed and dogbert17 bisected points to new code i added. however, i'm not yet 100% sure that code is entirely at fault. i don't think it should segfault, even if it does end up happening to be wrong 20:00
it dies here github.com/MoarVM/MoarVM/blob/mast...ue.c#L1469 because del is 0x0 20:03
however, repr_data->ass_del_slot is 0 and repr_data->attribute_offsets[repr_data->ass_del_slot] is 8, which seem like plausible values 20:04
nine MasterDuke: your code cannot be at fault. Nothing Rakudo does may lead to a segfault in the VM. Except via NativeCall of course. 20:18
MasterDuke yeah, the segfault definitely shouldn't happen. i was looking to see if i was also doing something incorrect 20:19
fwiw, no change with MVM_SPESH_DISABLE
if i change the code to do an nqp::existskey first that still dies. something's wrong with what it gets from `.prec` 20:37
vrurg MasterDuke: I don't see why removal of CALL-ME is a wrong move? It was a workaround for incorrectly working coercions which is not the matter anymore. 20:43
MasterDuke because i breaks the ecosystem
*it breaks
vrurg Perhaps it's the modules who got it wrong? 20:44
MasterDuke github.com/rakudo/rakudo/issues/4705 crane, first one on the list 20:45
vrurg Let's not shoot from the hip. For example, the fact that Chronic expects `1 ~~ all(1,2,3)` to be true doesn't mean I'd revert the fixes for smartmatching. :)
Let me get over those which point at my commits. Then I hope to have time for Crane. 20:46
MasterDuke vrurg++
vrurg BTW, what exact type does it fail with? Did you manage to find this out? 20:47
MasterDuke what do you mean type? what i showed is pretty much a golf of one of its fails 20:48
it's creating Lists 20:49
vrurg Ah, I see. Then it is certainly bad reason to revert. If it needs a list with a hash element, the approach is the same, as for everything else: containerize, or itemize with extra comma. 20:52
m: say List({:1a, :2b},)
camelia (a => 1 b => 2)
vrurg m: say List(({:1a, :2b},))
camelia ({a => 1, b => 2}) 20:53
MasterDuke yeah, but it used to work that way for 6 years, i doubt that's the only code relying on the behavior
vrurg Ah, containerization wouldn't work. Anyway. 20:54
This is a bad reason to preserve a bug, in my eyes.
MasterDuke i'm not disagreeing that it's "wrong", but i'm not sure we can just change that behavior
vrurg Let's see how it goes. But as long as it's just a couple of modules, it should be manageable, I hope. 20:56
MasterDuke backing up to the segfault, looks like what `.prec` is returning is concrete, but nqp::existskey and nqp::atkey segfault if given it 20:57
vrurg BTW, is there a way in new-disp to program two chained method calls? In my spare time I'm playing with expressing smartmatch via new-disp and can't see if .ACCEPTS.Bool can be done without introducing an extra block/frame around them. 21:37
MasterDuke huh. why is REPR(obj)->name = "P6opaque"? shouldn't it be MVMHash (or BOOTHash)? 22:10
MasterDuke yeah, so it's usually a VMHash. that's the current problem. now to figure why is it a P6opaque instead? 22:18
japhb thinks that would depend on whether you're looking at a Rakudo Hash or its $!storage 22:20
MasterDuke oh interesting. if i do indeed replace $obj.prec<iffy> with `my $prec := $obj.prec; nqp::atkey(nqp::getattr($prec,Map,'$!storage'),'iffy')` then there's no segfault 22:30
but `$obj.prec<iffy>` should still not cause a segfault 22:32
japhb Agreed, definitely 22:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!