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 releasable6: statisfiable6: 08:42
releasable6 nine, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Releasable
nine releasable6: status
releasable6 nine, Next release in ≈19 days and ≈10 hours. There are no known blockers. Changelog for this release was not started yet
nine, Details: gist.github.com/f574a1b543f8a8bf95...886b0e39e2
Geth MoarVM/master: 4 commits pushed by (Stefan Seifert)++, niner++ 08:43
Nicholas good *, * 08:50
Geth MoarVM: a3476e2869 | (Stefan Seifert)++ | 2 files
Turn on C11 atomics by default

It's been a while since these were enabled optionally and I've been using them for almost as long without any fault whatsoever. It's time we give them some more exposure.
08:53
Nicholas oh, "may you live in interesting times"
nine Well, Linux distros will like this as it gets us rid of one more bundled dependency 08:59
The packages for openSUSE Tumbleweed already build with --has-libffi --has-libtommath --has-libuv and work just fine. 09:00
lizmat nine: compilation seems slower since I bumped MoarVM... should it ? 11:44
nine No. How much slower? 11:46
lizmat finger in the air: up to 5% ? 11:51
nine That would be ~ 1s for core.c parsing. Sounds like that's within noise 12:09
lizmat I also see it in spectest timing 12:17
afk for a few hours& 12:20
in any case, it shouldn't be slower, right ? 12:22
ugexe well doing .mkdir is twice as slow than .e for the common case, and now that is happening during every path object creation 12:27
moon-child users.cs.northwestern.edu/~robby/c...g-data.pdf
ugexe ...in CUR. which is still a lot 12:28
[Coke] would it work to re-add the "once"? 12:29
and then still not bother calling .e then?
jnthnwrthngtn nine: Nice work on the package vars; left a couple of comments on the commit, but also t/12-rakuast/package.t has regressed, also spectest lost 28 fully passing test files. 12:32
(The latter by `make spectest` and then `RAKUDO_RAKUAST=1 make spectest | grep '\. ok' | wc -l`, which was 320 before and now 292 12:33
)
nine I'll try to get those declarations to work without making the Package do LexicalScope 12:38
It's kinda funny that packages and $?PACKAGE specifically are often used as examples in comments, when they were not actually implemented :) 12:40
jnthnwrthngtn Well, `$?PACKAGE` was already bound to GLOBAL in RakuAST::CompUnit, I believe 13:13
But yeah, any kind of nested package stuff hasn't really been done yet
Well, it's getting done now thanks to you :) 13:14
nine This stuff is complicated... Replacing PRODUCE-IMPLICIT-DECLARATIONS and direct QAST manipulation with an apply-implicit-block-semantics that calls $!body.add-generated-lexical-declaration, we get correct runtime behaviour, but at compile time it doesn't find the package's $?PACKAGE 13:47
nine Ah, I'm actually so close... problem is just that QAST::Var(lexical $?PACKAGE :decl(static)) is generated right after the QAST::Op(bind) that looks up $?PACKAGE 14:34
And now its working :) 14:48
jnthnwrthngtn: I wonder: do we actually need to lookup $?PACKAGE for initializing package scoped variables? It's used for $bar := $?PACKAGE.AT-KEY('$bar'). Seems to work just fine when I use a WVal for the meta-object and I guess that would be a little bit faster? 14:50
lizmat ugexe: good catch 15:01
TIL nqp::mkdir is pretty expensive
ugexe src\moar.h(44): fatal error C1083: Cannot open include file: 'stdatomic.h': No such file or directory 16:13
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.EXE"' : return code '0x2'
Stop.
Stop. 16:14
jnthnwrthngtn nine: I think the WVal approach should work 16:26
nine done :) 16:33
nine Would be so nice to just be able to use note(...) for debug output in the nodes 18:30
lizmat what can't you ? 18:34
nine They're part of the bootstrap. No settings available yet and NQP's setting is not in scope either 18:39
lizmat hmmm 18:41
nqp::say()
nine Apparently I have a nack for breaking things. My "less hacky" commit broke class Foo { method foo() { 456 } }; which now gives "Package 'Foo' already has a method 'foo'". No idea how though. 19:18
Looks like the parser attaches the method multiple times which means that it will be added to the package multiple times. 19:19
lizmat existence check always returning true ?
ah... yes, that would do it
nine Removing "is RakuAST::ImplicitBlockSemanticsProvider" from RakuAST::Package again unbreaks it. What the? 19:22
nine Aaah...it's the self.meta-object call in apply-implicit-block-semantics 19:35
Commit ae3b46ee51 fixes the package regression. 19:44
Doesn't fix all the spectests though :/ commit 023ec833f gives me 277 ok, HEAD^ gives 246 and HEAD is at 254 20:00