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.
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
nine Ah, yes, that's the unfinished business in QASTCompilerMAST 07:36
MasterDuke today is windsday, but it's not very blustery here 09:05
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
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
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
lizmat nine++ on a roll! 10:20
Nicholas <lizmat>bump?</lizmat> 10:21
lizmat I think nine++ already did
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
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
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
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)
Nicholas (now more tests running as I created that PR. I think CodeFactor was on branch push) 14:05
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
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
Geth MoarVM: c00abdf385 | (Daniel Green)++ | src/6model/reprs/P6opaque.c
Silence warning about ignoring return value from libtommath function
 16:44
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
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
lizmat feels to me that that hash should be an attribute :-) 19:18
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
lizmat Nicholas++ # for making thready hash accesses not segfault, but panic 20:58
jnthnwrthngtn Wonder how much that .unique locking fix will tank performance... 21:37
MasterDuke i haven't noticed any difference 21:38
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.

Powered by Cro and the Raku® Programming Language.

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

Thank you!