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:05 linkable6 joined 00:06 reportable6 left 02:14 greppable6 left, committable6 left, releasable6 left, notable6 left, sourceable6 left, evalable6 left, squashable6 left, coverable6 left, statisfiable6 left, bisectable6 left, benchable6 left, nativecallable6 left, shareable6 left, unicodable6 left, linkable6 left, quotable6 left, tellable6 left, bloatable6 left 02:15 greppable6 joined, shareable6 joined, coverable6 joined 02:16 nativecallable6 joined, bisectable6 joined, evalable6 joined 02:17 benchable6 joined, bloatable6 joined, tellable6 joined 03:11 discord-raku-bot left, discord-raku-bot joined 03:15 releasable6 joined, committable6 joined 03:17 notable6 joined 04:17 evalable6 left, unicodable6 joined 04:32 Techcable joined 05:08 reportable6 joined 05:17 statisfiable6 joined 05:18 evalable6 joined 05:25 frost joined 05:45 frost left 05:56 frost joined 06:07 reportable6 left 06:15 quotable6 joined 06:16 sourceable6 joined, squashable6 joined 07:10 reportable6 joined 07:16 linkable6 joined 08:29 evalable6 left 09:04 squashable6 left
nine Ah, yes, we really should re-use those deprecated ops much more agressively 09:14
09:30 evalable6 joined
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
10:28 frost left
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: ^^^
10:58 dogbert11 left 11:05 squashable6 joined 11:06 dogbert17 joined 11:53 linkable6 left 11:54 linkable6 joined 12:06 reportable6 left
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
13:09 reportable6 joined 13:10 linkable6 left
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
15:13 linkable6 joined
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
16:47 linkable6 left, evalable6 left 16:49 evalable6 joined 16:50 linkable6 joined 17:07 sena_kun left 17:08 sena_kun joined
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
18:09 reportable6 left 18:56 patrickb joined
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
20:10 reportable6 joined
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
21:00 patrickb left 21:20 japhb left 21:36 japhb joined
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
22:04 [Coke] left 22:07 [Coke] joined
MasterDuke huh. why is REPR(obj)->name = "P6opaque"? shouldn't it be MVMHash (or BOOTHash)? 22:10
22:12 [Coke] left, [Coke] joined
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
22:27 [Coke] left
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
22:40 [Coke] joined
japhb Agreed, definitely 22:56
23:40 evalable6 left, linkable6 left 23:42 evalable6 joined, linkable6 joined 23:48 Kaiepi left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!