nine timotimo: variable declarations after code are now longer an issue :) 07:10
ShimmerFairy nine: docs/contributing.org under MoarVM still claims MoarVM is living in the stone age, is that no longer true then? 07:24
nine ShimmerFairy: ah, that's out of date. We require at least VS2017 which finally fully supports C99 07:45
patrickb . 08:28
ShimmerFairy I can't seem to figure out a universal name of getting the name of a type in NQP (trying to write a quick little dumper). The consternation seems to be with the BOOT types, but simple examples work fine. 09:01
nqp: say(nqp::istype(nqp::bootint(), nqp::bootint())) 09:02
camelia 0
ShimmerFairy I can't even hardcode support for their typenames, so far.
lizmat Files=1306, Tests=111379, 223 wallclock secs (29.73 usr 8.57 sys + 3064.50 cusr 291.29 csys = 3394.09 CPU) 09:18
MasterDuke patrickb: any idea why e.g., github.com/MoarVM/MoarVM/pull/1312 has its top three azure jobs failing? seems like those particular ones are failing across a bunch of different commits/prs 09:24
patrickb MasterDuke: I have no idea, but they look like legitimate failues on first sight. 09:25
MasterDuke hm, fails in repl.t in windows. i don't have any way of seeing/testing. but they're not caused by that specific pr at least 09:29
nqp: say(nqp::bootint().HOW.name(nqp::bootint())) 09:34
camelia BOOTInt
MasterDuke ShimmerFairy: does ^^^ help?
ShimmerFairy That's one of those simple examples that works, but $obj.HOW.name($obj) in practice falls apart (this is dealing with the output from instrumented profiling, btw). 09:35
I wish I could generate a minimal (non)working example, but it's kinda hard to know what about the object makes it fall apart when all you can know about it is its REPR. 09:36
For the record, it's some kind of VMArray that's breaking things. 09:37
MasterDuke hm, then i'd suggest pinging timotimo 09:39
ShimmerFairy here's the script, btw, with a workaround for the bad type: gist.github.com/ShimmerFairy/9d754...0b89b7d797 09:44
Geth roast: 3b6d36d12d | (Elizabeth Mattijsen)++ | 73 files
Final tweaks RT -> Github migration

  - removed double references
  - moved some lines to front of code
  - added some more references that the conversion program had missed		 11:23
[Tux] Rakudo version 2020.05.1-280-g5b507c8ad - MoarVM version 2020.05-77-gb9fa480ad
csv-ip5xs1.040 - 1.094
csv-ip5xs-2012.694 - 13.155
csv-parser26.259 - 26.720
csv-test-xs-200.385 - 0.386
test9.203 - 9.570
test-t3.094 - 3.144
test-t --race1.085 - 1.098
test-t-2055.864 - 56.121
test-t-20 --race14.188 - 15.783
 12:58
Still slow
Altai-man_ Have we not merged the perf fix yet? Ping lizmat, MasterDuke? 13:13
lizmat afaik, that has not been merged yet, and definitely not bumped yet 13:15
MasterDuke timotimo suggested the PR should perhaps be modified 13:15
lizmat Altai-man_: after the dispatch fiasco, I'm *very* reluctant merging MoarVM's PR's
Altai-man_ I see. 13:16
Geth rakudo: f10e5bcef1 | (Elizabeth Mattijsen)++ | src/core.c/Grammar.pm6
Simplify code in Grammer

  - less nqp
  - remove unneeded :$filename parameter
  - simplify handling of default rule		 13:50
Geth rakudo: 8be24067d9 | (Elizabeth Mattijsen)++ | src/core.c/Grammar.pm6
Simplify Grammar.parse further

  - no need to call .MATCH while parsing
  - especially if the parse fails
  - so only call .MATCH on the final cursor, it will recurse if needed
  - this makes parses fail faster, and successful ones marginally faster		 14:13
dogbert17 o/ 14:16
should we trust Timotimo's cats who claimed that github.com/MoarVM/MoarVM/pull/1311 should be changed :-) 14:18
lizmat they *are* pretty smart :-) 14:21
MasterDuke i suspect this is one of those cases where in all likelihood it'd be fine in practice, but in theory there's a chance for error 14:22
dogbert17 I'll try to amend then 14:23
I've now made the edit directly on github, does it look ok? 14:29
MasterDuke looks good 14:31
dogbert17 MasterDuke: thx for checking 14:32
anyone around with the power to merge? 14:38
many thanks Jimmy 14:45
timotimo ShimmerFairy:at the moment profile data from threads that have been removed again (which i assume threadjoin will do) will be discarded in the instrumented profiler 15:08
ShimmerFairy: have you tried the debugname ops? nqp::getdebugname perhaps
ShimmerFairy Haven't heard of the debugname ops, would probably help. (And btw, using threads even with threadjoin did seem to keep data, it's how I found out how multiple threads' hashes are put in the return of mvmendprofile) 15:10
timotimo good to know, i thought i'd for sure have to put something in there to hold on to thread's data after they die 15:11
nqp: say(nqp::debugname(nqp::bootint))
camelia No registered operation handler for 'debugname'
at gen/moar/stage2/QAST.nqp:1504 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)
from gen/moar/stage2/QAST.nqp:6173 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_no…
timotimo nqp: say(nqp::getdebugname(nqp::bootint))
camelia No registered operation handler for 'getdebugname'
at gen/moar/stage2/QAST.nqp:1504 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)
from gen/moar/stage2/QAST.nqp:6173 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile…
timotimo hum?
ShimmerFairy they don't exist, turns out 15:12
timotimo aha 15:13
there is only setdebugtypename in moar's interpreter
i suppose it really is only for giving a c string name to moarvm's internals for easier / cheaper debug outputting in error messages and such? 15:14
they are probably set everywhere we're also setting a name in the metaobject though? 15:15
ShimmerFairy The one time I managed to create an error message giving some kind of name was from an error generated in MoarVM that directly looks into the STable. 15:16
timotimo debugtypenames are also used in the spesh log for example 15:18
ShimmerFairy nqp-m: say(nqp::bootint().new) # one such MVM-based error, as an example
camelia Cannot find method 'new' on 'BOOTInt': no method cache and no .^find_method
at <tmp>:1 (<ephemeral file>:<mainline>)
from gen/moar/stage2/NQPHLL.nqp:1947 (/home/camelia/rakudo-m-inst-1/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nq…
timotimo 691:#define IS_CONCRETE(o) (!(((MVMObject *)o)->header.flags & MVM_CF_TYPE_OBJECT))
looks like we do want a null check in front of IS_CONCRETE if something can be null 15:19
ShimmerFairy AFAIK nqp::isconcrete() (at least currently) is meant to be just "is it NOT a type object?", which a null counts as not being. 15:21
I don't know if that macro maps directly to the opcode, though.
timotimo i think we mostly use isconcrete when we want to access something's attributes and such, which we can't do for type objects and can't do for null, so that's my intuition 15:23
indeed, the isconcrete opcode is implemented as a null check + IS_CONCRETE
ShimmerFairy I guess "is a null a type object" is a question that borders on the philosophical, could go either way :P 15:24
btw, I was surprised to find that nqp::isnull_s($x) stringifies its argument. Not necessarily wrong, just didn't expect it. 15:26
timotimo we did put in a type explicitly to mimic a null but not a null pointer 15:27
ah, yes, that really is slightly odd; i guess you're expected to only use it on str registers in the first place? i.e. after a decont_s or some such? 15:29
and if the register you're using it on is num, int, or obj, the qast compiler will helpfully place a coercion for you 15:30
ShimmerFairy In the script I posted, I tried a nqp::isnull_s check right after the isnull check to print a special "null string" thing. I could've easily put a nqp::isstr($obj) in front to avoid the coercion issue, but it wasn't that important. 15:31
timotimo did you steal anything from the built-in profiler dumper? 15:35
ShimmerFairy there's a built-in profiler dumper? 15:39
timotimo it dumps to html / json / sql 15:43
so maybe "dumper" isn't the right word for it?
ShimmerFairy tbf my little script is probably more of a pretty printer (or, a Raku dumper I guess) 15:44
timotimo there ought to be a way to get the default dumper from regular user code 15:45
Telemetry, which comes with rakudo, already offers a heap snapshot function
but that's easier since moarvm does all the file output parts there
Geth nqp: 52bf8bda51 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump Moar to get performance fix and FreeBSD build fix
 19:36
sena_kun starts Blin, with perf fix included 19:40
Oh, rakudo is not bumped yet. 19:41
sena_kun await bump
lizmat running tests now 19:43
confirmed the performance issue is gone
Geth rakudo: e2b1230806 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get MoarVM performance and FreeBSD build fixes
 19:48
lizmat sena_kun ^^
sena_kun lizmat++
dogbert17 lizmat++ 19:49
something tells me that jnthn will grumble when he finds out that the SEGV in spreadsheet::xlsx has returned 20:04
sena_kun dogbert17, I think he suggested the fix, no? 20:06
I mean, his fix was not reverted, but "improved", no?
lizmat that's also my understanding
dogbert17 yes, it fixed the perf regression but somehow made the SEGV return
sena_kun Urhg. 20:07
dogbert17 unless I'm doing something wrong which is always a possibility
Geth nqp: 4f599deaf2 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get double-free fix
 20:12
Geth rakudo: 26a7869b38 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get double-free fix
 20:27
lizmat sena_kun ^^
Geth roast: fea1d16d99 | (Elizabeth Mattijsen)++ | 1581 files
Give all files the same # vim: line

  - without mention of perl6, filetype should be set manually by user
  - use extended form of parameters for readability		 20:43
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Bump NQP to get MoarVM performance and FreeBSD build fixes' 20:45
travis-ci.org/rakudo/rakudo/builds/698044951 github.com/rakudo/rakudo/compare/8...b1230806e9
Geth rakudo: 8134470538 | (Elizabeth Mattijsen)++ | 358 files
Make sure all text files have the same # vim: line

  - with expanded tags
  - without mention of filetype, should be set by the user		 21:05
roast: 2b7e71604b | (Elizabeth Mattijsen)++ | 113 files
Expand sw=4 to shiftwidth=4

  - if a file didn't have a # vim: line, it got the unexpanded version		 21:13
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make sure all text files have the same # vim: line 22:28
travis-ci.org/rakudo/rakudo/builds/698058441 github.com/rakudo/rakudo/compare/2...3447053845

Powered by Cro and the Raku® Programming Language.

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

Thank you!