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:08 reportable6 left 01:03 [Coke]_ joined, [Coke] left 01:08 reportable6 joined 02:03 squashable6 left 02:17 frost joined 02:52 [Coke] joined 02:53 [Coke]_ left 03:03 frost left 03:06 squashable6 joined 04:32 unicodable6 left, statisfiable6 left, greppable6 left, benchable6 left, nativecallable6 left, tellable6 left, quotable6 left, shareable6 left, coverable6 left, notable6 left, bisectable6 left, bloatable6 left, sourceable6 left, releasable6 left, committable6 left, evalable6 left, squashable6 left, linkable6 left, reportable6 left, nativecallable6 joined 04:33 reportable6 joined, committable6 joined 04:34 notable6 joined, releasable6 joined, sourceable6 joined, squashable6 joined, statisfiable6 joined, greppable6 joined, bisectable6 joined, coverable6 joined 05:38 AlexDaniel left 05:39 nine left, Techcable left, statisfiable6 left, sourceable6 left, ugexe left, [Coke] left, harrow left, moon-child left, coverable6 left, squashable6 left, notable6 left, committable6 left, reportable6 left, psydroid left, JRaspass left, jdv left, Voldenet left, mst left, samcv left, bartolin_ left, gfldex left, jnthnwrthngtn left, rypervenche left, Util left, samebchase left, lizmat left, tbrowder left, leont left, rba left, codesections left 05:50 Geth left, MasterDuke left, Altai-man left, nebuchadnezzar left, leedo left 05:52 Kaiepi left, vrurg left, japhb left, discord-raku-bot left, kjp left, timo left, ilogger2 left, camelia left 05:53 camelia left, leedo joined, nebuchadnezzar joined, Altai-man joined, MasterDuke joined, Geth joined, [Coke]_ joined, quotable6 joined, linkable6 joined, bloatable6 joined, unicodable6 joined, coverable6 joined, statisfiable6 joined, squashable6 joined, sourceable6 joined, notable6 joined, committable6 joined, reportable6 joined, AlexDaniel joined, psydroid joined, ugexe joined, jnthnwrthngtn joined, rypervenche joined, nine joined, Techcable joined, mst joined, samcv joined, Voldenet joined, lizmat joined, Util joined, harrow joined, bartolin_ joined, gfldex joined, moon-child joined, leont joined, rba joined, codesections joined, jdv joined, JRaspass joined, samebchase joined, tbrowder joined 05:54 Kaiepi joined, vrurg joined, japhb joined, discord-raku-bot joined, kjp joined, timo joined, ilogger2 joined, camelia joined 05:55 SmokeMachine joined, Nicholas joined, patrickb joined, TempIRCLogger__ joined, dogbert17 joined, RakuIRCLogger joined, nativecallable6 joined, releasable6 joined, greppable6 joined, bisectable6 joined, leedo joined, nebuchadnezzar joined, Altai-man joined, MasterDuke joined, Geth joined, [Coke]_ joined, quotable6 joined, linkable6 joined, bloatable6 joined, unicodable6 joined, coverable6 joined, statisfiable6 joined, squashable6 joined, sourceable6 joined, notable6 joined, committable6 joined, reportable6 joined, AlexDaniel joined, psydroid joined, ugexe joined, jnthnwrthngtn joined, rypervenche joined, nine joined, Techcable joined, mst joined, samcv joined, Voldenet joined, lizmat joined, Util joined, harrow joined, bartolin_ joined, gfldex joined, moon-child joined, leont joined, rba joined, codesections joined, jdv joined, JRaspass joined, samebchase joined, tbrowder joined, camelia joined 06:07 reportable6 left 06:08 reportable6 joined 06:13 linkable6 left 06:33 evalable6 joined, shareable6 joined 06:34 tellable6 joined, benchable6 joined
Nicholas good *able6, * 06:38
It was a windy night. No wonder everything flapped a lot
nine m: dd class :: { has uint8 $.x; }.new( x => 255 ) 07:20
camelia <anon|1>.new(x => 255)
nine m: dd class :: { has uint8 $.x; }.new( x => 255 ).x # but
camelia -1
nine m: dd class :: { has uint8 $.x is rw; }.new( x => 255 ).x # oh! 07:31
camelia 255
07:32 squashable6 left 07:33 squashable6 joined
nine Ah, yes, that's the unfinished business in QASTCompilerMAST 07:36
08:07 frost joined
MasterDuke today is windsday, but it's not very blustery here 09:05
09:16 frost left
nine Now this is bizarre: 09:20
m: my uint64 $no = 2**64 - 1; say $no
camelia -1
nine But:
m: my uint64 $no = 2**64 - 2; say $no
camelia 18446744073709551614
nine So there's the last known uint problem and it's with exactly one value 09:21
japhb That sounds like an off-by-one (or equivalently < instead of <=) in determining bounds
nine++ for the continuing massive effort, THANK YOU 09:22
nine Aaah...it's the int cache! I also used it for autobox_uint, but the int cache also contains -1 09:44
09:44 squashable6 left
MasterDuke ha, nice find 09:45
nine Total luck... I just wanted to use a value that would stand out more than -1 (which appears in unrelated places as well) in my debug output 09:47
09:51 frost61 joined 10:03 mst left
Geth MoarVM: a851fcf406 | (Stefan Seifert)++ | src/core/args.c
Fix autobox_uint finding negative Ints in the int cache

The int cache also contains a boxed -1 which autobox_uint would find for the value 2**64 - 1. Just exclude values with the high bit set from getting looked up at all, in case we add further negative values to the int cache.
10:03
10:05 mst joined 10:09 squashable6 joined 10:13 linkable6 joined
lizmat nine++ on a roll! 10:20
Nicholas <lizmat>bump?</lizmat> 10:21
lizmat I think nine++ already did
10:43 frost61 left
jnthnwrthngtn is feeling positive about nine++'s uint work 10:52
dogbert17 :) 10:54
m: my int8 $x = 2**7 - 1; say $x; say $x++; say $x # is this correct? 10:55
camelia 127
-129
-128
jnthnwrthngtn dogbert17: I think so, on the basis that calculations are done at full-width, and smaller sizes are only units of storage 11:00
11:01 linkable6 left
jnthnwrthngtn But wait...uh...how does ++ make it smaller? :) 11:01
lizmat
.oO( there is no place for negativity! )
jnthnwrthngtn lizmat: This is not what I want to here while I'm watching today's anti-gen test process :P 11:02
*hear
lizmat it was only a though!
-)
jnthnwrthngtn Phew, there was at least a little room for negativity :) 11:05
lizmat good!
maybe an idea to have a GSOC project to port MoarVM to the web with this? leaningtech.com/webvm-server-less-...e-browser/ 11:20
Nicholas are they single threaded? 11:31
lizmat I have no idea... but I guess you can't run a Debian without being multi-threaded ? 11:33
even on a single CPU 11:34
11:43 sena_kun joined 12:02 linkable6 joined 12:07 reportable6 left 12:12 frost joined
Geth MoarVM: ef270d7f5e | (Stefan Seifert)++ | 11 files
Proper uint support for multidim arrays.

Introduce new ops: atposnd_u, atpos2d_u, atpos3d_u, bindposnd_u, bindpos2d_u, bindpos3d_u and multidimref_u and fix deconting unsigned multidimrefs.
12:14
12:30 sena_kun left 12:33 sena_kun joined 12:45 frost left 13:26 [Coke]_ is now known as [Coke] 13:56 discord-raku-bot left 13:57 discord-raku-bot joined
Geth MoarVM: nwc10++ created pull request #1662:
Serialize bigints in base 32, not base 10
14:04
Nicholas Epic, um, well, epic fail: 14:05
All checks have failed
1 failing check
(CodeFactor)
14:05 discord-raku-bot left
Nicholas (now more tests running as I created that PR. I think CodeFactor was on branch push) 14:05
14:05 discord-raku-bot joined 14:24 sena_kun left 14:25 sena_kun joined
MasterDuke Nicholas: very interesting. so we have a couple places doing semi-custom str-to-int and a couple places doing semi-custom int-to-str. definitely seems like they should be investigated to see how much (if any) of the code can be consolidated 14:50
btw, since you're writing an ascii string, can't you assume it's ascii and well-formed when read back and then you don't have to use the iterator and can just read from the MVMString's storage? 14:52
Nicholas I don't know enough about string serialisation to be confident that it guarantees any particular representation on the way out 14:55
(and I didn't go digging)
(was faster to steal the existing iterator code) 14:56
MasterDuke i guess that's something that could be figured out during an investigation into consolidating 14:58
btw, did my explanation in github.com/MoarVM/MoarVM/pull/1661...r796990689 make sense? 14:59
Nicholas I spotted that last night when I was tired and so far failed to get back to it (sorry)
MasterDuke no particular hurry
15:09 reportable6 joined
vrurg MasterDuke: BTW, the yesterdays SEGV is gone after full removal of the installation directory. No other changes were needed. Some leftovers, I guess, but no idea of what kind as --full-rebuild didn't help. 15:51
MasterDuke huh. well as long as a clean checkout + build is fine i guess that's the most important thing
16:03 Kaipi joined 16:06 Kaiepi left
Geth MoarVM: c00abdf385 | (Daniel Green)++ | src/6model/reprs/P6opaque.c
Silence warning about ignoring return value from libtommath function
16:44
17:25 colemanx joined 18:06 reportable6 left 18:24 sena_kun left
lizmat do we know that EVAL is not threadsafe ? 18:44
gist.github.com/lizmat/e94b93e0645...73c834c05e
ugexe is the code you are evaling thread safe? 18:46
lizmat Looks like the BlockVarOptimizer class has more of these: %!usages_flat 18:47
the code in fact is just doing (try $code.EVAL) on something inside of a :ver( ) 18:48
ugexe is $code thread safe? 18:49
lizmat it consists of strings like 'v0.0.42+'
I'd say: yes 18:50
which is run inside of a .hyper
the string does *not* reference anything outside of it
ugexe `use MONKEY-SEE-NO-EVAL; (1..10000).race.map({ EVAL "1" })` works well enough 18:51
lizmat indeed... it's the first time I see this error
ugexe but we can see and be quite certain "1" is thread safe 18:52
lizmat but we knew there are still gremlins with EVALling code in parallel, and thats why I made sure I created a gist with the stack trace
ugexe can you get one of the strings being evald and plug it into a minimal example like the one above? 18:54
lizmat v0.3.3+ 18:58
ugexe m: use MONKEY-SEE-NO-EVAL; (1..1000000).race.map({ my class Bar:ver(EVAL "v0.3.3+") {} }).eager 18:59
camelia ( no output )
ugexe why can't it be that simple :/ 19:00
lizmat ugexe: it was extracting the string inside a :ver( ) dependency specification
well, that's it, I haven't been able to reproduce either
but I felt it was important enough to mention, because of the stack trace and indeed the use of hashes at the given locations 19:01
19:10 Merfont joined 19:13 Kaipi left
lizmat I think I found the problem: in QAST::Node 19:17
my %uniques;
method unique($prefix) {
gen/moar/stage2/QASTNode.nqp:249 19:18
19:18 colemanx left
lizmat feels to me that that hash should be an attribute :-) 19:18
19:19 colemanx joined
lizmat hmm... looks like QAST::Node.unique is used as a class method 19:29
so I guess we need to add a lock ?
my attempt to fix that race: github.com/Raku/nqp/pull/760 19:36
comments very welcome 19:38
20:19 evalable6 left, linkable6 left 20:36 Altai-man left 20:39 sena_kun joined
lizmat Nicholas++ # for making thready hash accesses not segfault, but panic 20:58
21:11 camelia left, mst left, vrurg left, japhb left, kjp left, timo left, ilogger2 left, sena_kun left, Geth left, MasterDuke left, nebuchadnezzar left, leedo left, AlexDaniel left, nine left, Techcable left, Merfont left, squashable6 left, benchable6 left, shareable6 left, bloatable6 left, unicodable6 left, statisfiable6 left, sourceable6 left, ugexe left, discord-raku-bot left, harrow left, moon-child left, colemanx left, coverable6 left, notable6 left, committable6 left, psydroid left, JRaspass left, jdv left, Voldenet left, samcv left, bartolin_ left, gfldex left, jnthnwrthngtn left, rypervenche left, Util left, samebchase left, [Coke] left, quotable6 left, lizmat left, tbrowder left, leont left, rba left, codesections left 21:12 RakuIRCLogger left, TempIRCLogger__ left, dogbert17 left, patrickb left, Nicholas left, SmokeMachine left, sena_kun left, Geth left, MasterDuke left, nebuchadnezzar left, leedo left, AlexDaniel left, nine left, Techcable left, Merfont left, squashable6 left, benchable6 left, shareable6 left, bloatable6 left, unicodable6 left, statisfiable6 left, sourceable6 left, ugexe left, discord-raku-bot left, harrow left, moon-child left, colemanx left, coverable6 left, notable6 left, committable6 left, psydroid left, JRaspass left, jdv left, Voldenet left, samcv left, bartolin_ left, gfldex left, jnthnwrthngtn left, rypervenche left, Util left, samebchase left, [Coke] left, quotable6 left, lizmat left, tbrowder left, leont left, rba left, codesections left 21:14 gfldex joined, discord-raku-bot left, bartolin_ joined, samcv joined, ilogger2 joined, timo joined, kjp joined, japhb joined, vrurg joined, mst joined, Techcable joined, nine joined, AlexDaniel joined, codesections joined, rba joined, leont joined, jdv joined, JRaspass joined, committable6 joined, discord-raku-bot joined, Merfont joined, squashable6 joined, benchable6 joined, shareable6 joined, bloatable6 joined, unicodable6 joined, statisfiable6 joined, sourceable6 joined, ugexe joined 21:15 camelia joined, AlexDaniel left, jnthnwrthngtn joined, rypervenche joined, Util joined, samebchase joined 21:19 evalable6 joined
jnthnwrthngtn Wonder how much that .unique locking fix will tank performance... 21:37
MasterDuke i haven't noticed any difference 21:38
22:17 psydroid joined 22:19 MasterDuke left 22:53 AlexDaniel joined 22:58 MasterDuke joined
lizmat in most cases there won't be any lock cintention, right ? 23:07
*contention
jnthnwrthngtn No, but it'd still imply an atomic op in userspace 23:18
I don't think that's avoidable
Probably a drop in the ocean
RakuAST's QAST production approach actually gives us a better peg to hang this off anyway
So no point spending more time over it than this 23:19
vrurg jnthnwrthngtn: NQP doesn't have atomics, unfortunately. 23:34
jnthnwrthngtn vrurg: I was talking about what happens inside nqp::lock in the non-contention case 23:36
One could arrange for atomics in NQP if they're needed 23:37
(But here they'd not help)
vrurg I thought an atomic guard would have less overhead, than a lock. 23:39
But, whatever.