Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
01:00 tyil left
Geth rakudo: b9ad5fd983 | (Vadim Belman)++ | t/02-rakudo/15-gh_1202.t
Added test for async bug

rakudo/rakudo#1202		 01:19
rakudo: 7f69ef1d22 | (Vadim Belman)++ | t/02-rakudo/15-gh_1202.t
Followup to corrections from ugexe.
synopsebot RAKUDO#1202 [open]: github.com/rakudo/rakudo/issues/1202 [SEGV][severe][tests needed] Async qqx sometimes hangs or dies ( await (^5).map({start { say qqx{… …} } }) )
rakudo: c0c99e77c7 | (Vadim Belman)++ (committed using GitHub Web editor) | t/02-rakudo/15-gh_1202.t
Merge pull request #2966 from vrurg/rakudo_1202

Added test for async bug
01:52 tyilanmenyn joined 02:02 Kaiepi left 02:16 tyilanmenyn is now known as tyil 02:39 squashable6 left 02:42 squashable6 joined 03:09 epony joined 03:10 epony left 03:11 epony joined 03:20 Kaiepi joined 05:41 squashable6 left 05:47 squashable6 joined, ChanServ sets mode: +v squashable6 05:51 squashable6 left 05:55 squashable6 joined
lizmat Files=1262, Tests=108018, 205 wallclock secs (26.74 usr 7.78 sys + 2863.29 cusr 283.35 csys = 3181.16 CPU) 08:16
10:50 camelia left 12:35 ggoebel joined 12:59 squashable6 left 13:05 squashable6 joined
lizmat status of from-json re-imagination: 13:16
1. passes all but a few pesky encoding tests... (12 in total) 13:17
2. parses the 5MB example JSON in 2.3 seconds instead of 3
3. with significantly lower memory usage 13:18
4. only hot block not JITted / inlined is the block with nqp::strfromcodes
taking a break now to look later at the pesky failing tests 13:19
Kaiepi good work 13:20
lizmat inlining nqp::strfromcodes could probably take it below 2 seconds
(it's now taking 40% exclusive time)
oh, and the failing tests are for unicode encoding errors not seen as errors 13:21
jnthn Don't see why it'd not be able to inline strfromcodes, but can easily imagine it missing JIT 13:34
Though I don't expet that's ave much aside from letting the surrounding things be JITted
Since that op is backed by C code I guess 13:35
May be a way to speed it up
13:57 Kaiepi left
jnthn m: say 'aaa' ~~ /(.)+/ 14:01
evalable6 ｢aaa｣
0 => ｢a｣
0 => ｢a｣
0 => ｢a｣
jnthn m: nqp::push(nqp::create(Array), 'x') 14:02
evalable6 (exit code 1) 04===SORRY!04=== Error while compiling /tmp/MSdmB4KdKk
Could not find nqp::create, did you forget 'use nqp;' ?
at /tmp/MSdmB4KdKk:1
------> 03nqp::push(nqp::create(Array)08⏏04, 'x')
jnthn m: use nqp; nqp::push(nqp::create(Array), 'x')
evalable6 (exit code 1) This type (Array) does not support positional operations
in block <unit> at /tmp/vBw56o18tz line 1
jnthn heh, github.com/rakudo/rakudo/blob/mast...ch.pm6#L79 would be busted were it reachable 14:03
But the final part of the conditon at github.com/rakudo/rakudo/blob/mast...ch.pm6#L64 means it is not 14:04
I'm guessing it was meant to be negated
Debating whether to fix that or just toss the special case
14:07 Kaiepi joined
dogbert17 jnthn: will the stuff you're tinkering with improve parse times? 15:02
jnthn dogbert17: Yes. 16:33
Or at least, my initial measurements suggest it does; my VM on my home machine is quite noisy on timings, alas.
The NQP part will help Rakudo's compilation time, and the Rakudo part should help regexes and grammars.
Not tinkered much more today, though...expect the travel next week will be tiring, so should rest up well. 16:37
16:43 ggoebel left
Kaiepi i looked through some of the js vm's code but my node's too rusty to do the big refactors i want to do 17:03
mainly i really, really don't like how STable.ObjConstructor is handled 17:04
i'm thinking there's a way to write it so it doesn't use Proxy since Proxy has terrible performance and isn't intended to be object prototypes anyways 17:05
something like an ES5 constructor or Object.create would probably work better 17:06
actually re-reading it i don't think it's possible not to use Proxy in its current implementation 17:20
global-context.js could certainly be refactored to just export one instance of a GlobalContext class though 17:21
vrurg jnthn: if you have 5 mins, just your "go/no go" for github.com/perl6/problem-solving/issues/3 18:05
18:22 dogbert11 joined 18:23 vrurg left, vrurg joined, pyrimidi_ joined, dogbert17 left, pyrimidine left
Geth rakudo: 847a2f0d2b | (Kaz Wesley)++ (committed by Nick Logan) | t/04-nativecall/23-incomplete-types.t
add tests for #2965 (#2967)

This will segfault until it's built on MoarVM/MoarVM#1116		 18:26
synopsebot RAKUDO#2965 [closed]: github.com/rakudo/rakudo/issues/2965 I can't HAS stub?
ugexe t\04-nativecall\04-pointers.t 18:27
failed on windows
ci.appveyor.com/project/rakudo/rak...omsr#L4845
ci.appveyor.com/project/rakudo/rak...true#L2773 18:30
i got no ideas for this one 18:31
Kaiepi according to an ancient japanese legend an out of date version of nqp-configure is always lurking out of the corner of your eye, waiting to strike when you least expect it 18:56
ugexe t\04-nativecall\04-pointers.t works for me on 2019.03.1, but fails every single time i run it on blead 18:57
again on windows 18:58
timotimo is that related to the PR that just got merged, i wonder? github.com/MoarVM/MoarVM/pull/1116 18:59
ugexe maybe, but i dont see how
timotimo yeah, that PR makes it throw exceptions; what does the failure look like?
ugexe no exceptions. looks like incorrect sizes 19:01
timotimo oh? like nativesizeof returns the wrong thing? 19:02
ugexe ci.appveyor.com/project/rakudo/rak...true#L2773
sure seems like rebuilding moar on windows is broken too.it just gets stuck at "Generating code" 19:05
i think it might be time we require green builds to put stuff into master 19:06
the first windows issue made things red, and then 3 other windows regressions snuck in 19:07
19:08 AlexDaniel joined
dogbert11 there are also lots of spectext fails on (Linux) 32 bit 19:08
*spectest
ugexe dogbert11: did you try on master? the mp_digit thing should be fixed 19:10
dogbert11 ugexe: yes I tried master 19:11
switching bigintops.c to the version released with 2019.03.1 makes all errors go away 19:13
ugexe i wonder if the spectest can be run fast enough to finish on a CI run
19:13 travis-ci joined
travis-ci Rakudo build failed. Kaz Wesley 'add tests for #2965 (#2967) 19:13
travis-ci.org/rakudo/rakudo/builds/543453547 github.com/rakudo/rakudo/compare/c...7a2f0d2b5e
19:13 travis-ci left
ugexe could be on a once-a-day cron or something 19:13
looks like the new guy is off the hook for his two PRs at least 19:15
timotimo appveyor gives us 60 minutes of life time for each vm 19:18
Kaiepi js backend rakudo builds are broken but i'm working on a fix for it 19:43
i think it's just a config error
i'll find out when all three backends finish building 19:44
b2gills That last commit shouldn't have been applied until after a MoarVM and NQP bump. 20:00
ugexe well the current windows failure goes back at least to last month 20:01
b2gills It broke my build script 20:02
It also breaks --gen-moar
ugexe anything that builds rakudo master without building moar master is already broke 20:03
if you are building HEAD then you should be using --gen-moar=HEAD. sure you dont*have* to but then situations like this shouldnt be surprising
b2gills My build script uses NQP_REVISION to checkout NQP, and MOAR_REVISION to checkout MoarVM. It works very reliably. 20:04
ugexe by sheer coincidence it has worked reliably based on the times you happened to run it
b2gills It works reliably because most commits that require a NQP or MoarVM bump are applied after said bump. 20:05
ugexe im not sure you can quantify that "most" because my instinct tells me its not 20:06
b2gills I purposely rebuild on commits that may be broken because of issues like that. 20:07
ugexe CI will already catch those, as well as show that --gen-moar=HEAD indeed works
b2gills Which it just did catch. 20:08
ugexe ...yes 20:09
it is almost like we wanted to see if --gen-moar=HEAD was fixed 20:10
but really we wanted to break everyones build scripts on blead
b2gills I purposely made it so that it worked like --gen-moar, even though that is more work 20:11
ugexe im done trying to find this windows regression so bump away 20:13
20:29 |Tux| left
Geth nqp: f2b319db94 | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/MOAR_REVISION
Bump MoarVM
 20:35
rakudo: 80a5a41a06 | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Bump NQP
 20:36
rakudo: b8669fe6f5 | (Nick Logan)++ (committed using GitHub Web editor) | tools/templates/NQP_REVISION
Bump NQP
 20:37
lizmat hmmm... after this upgrade, I'm getting MVMArray: slice index out of bound :-( 20:54
ugexe oops. i didnt spectest, i had tunnel vision re: CI going green 20:56
lizmat in code that worked before the upgrade
lizmat also runs spectest 20:57
showing the values before the nqp::slice, it shows valid values :-( 20:59
MasterDuke lizmat: what's the code? 21:00
lizmat start_pos = 1787140, end_pos = 1787152, elems = 5173603 21:01
both values are within the 5M buffer, and start_pos is before the end_pos
yet it decides to MVMArray: Slice index out of bounds
ugexe: spectest is clean for me 21:02
problem goes away with MVM_JIT_DISABLE=1 21:05
and returns with MVM_JIT_EXPR_DISABLE=1 21:06
since the actual code does nqp;:strfromcodes(nqp::slice(...)) 21:07
and this moar has a JITted nqp::strfromcodes
ugexe i was just gonna say... try reverting 6053919 heh 21:08
lizmat I have to assume that the problem is really with nqp::strfromcodes
MasterDuke lizmat: got a golf to share? 21:12
lizmat alas, not really... it happens when running the new "from-json" on a 5MB unpretty JSON file
ugexe hmm. i ran my jit change on the ecosystem json 50 times as a benchmark 21:13
lizmat the JSON::Fast test-suite passes (apart from a known issue wrt to wrongly encoded \u sequences
ugexe ah but it wouldnt have *your* new code
MasterDuke lizmat: hm, well mind sharing the json file? i can try adding some context to the 'MVMArray: Slice index out of bounds' error message to see if it helps 21:14
lizmat MasterDuke: sorry, cannot share that with you :-( 21:15
MasterDuke k, np
21:16 |Tux| joined
lizmat hmmm... I seem to be able to work around it by putting the nqp::slice into a separate sub, and call that inside the nqp::strfromcodes 21:20
21:23 squashable6 left 21:24 squashable6 joined
lizmat also: --profile appears to be borked 21:26
ugexe lizmat: maybe try reverting b55658b ? thats a different jit commit (so the op should still get jitted) 21:27
lizmat the first 4 routines in the profile, all have exactly 25%, and the rest all 0%
(exclusive time)
21:27 travis-ci joined
travis-ci Rakudo build passed. Nick Logan 'Bump NQP' 21:27
travis-ci.org/rakudo/rakudo/builds/543481558 github.com/rakudo/rakudo/compare/8...669fe6f581
21:27 travis-ci left
lizmat with the first 4 entries having more exclusive time than inclusive time 21:28
MasterDuke lizmat: hm, that's likely a result of my recent change
lizmat MasterDuke: gist.github.com/lizmat/2ed4732f8ac...71a130b78c 21:32
2 profiles: the first ok, the second borked, basically the same code run
MasterDuke hm, i put in a check for that kind of overflow, but it wasn't *completely* rigorous. maybe that does in fact need to be beefed up... 21:38
lizmat m: use nqp; my uint32 @a = 65..127; nqp::strfromcodes(nqp::slice(@a,10,13)) for ^100000 21:40
evalable6 (exit code 1) MVMArray: Slice index out of bounds
in block <unit> at /tmp/R0WWal2rkf line 1
lizmat ugexe: ^^^ golf 21:41
jnthn D'oh, managed to pour boiling water over my fingers while cooking and it hurt too much to type for a few hours :/ 21:49
ugexe lizmat: it must be my commit that breaks it. but there is nothing wrong with my commit either as far as i can tell 21:51
lizmat yeah, so maybe it's tickling an underlying bug in the JIT 21:52
the fact that it happens at 57251, but not at 57250 iterations, feels like an inlining / OSR issue 21:53
ugexe locally for me it always happens between 3000-4000, otherwise it finishes
use nqp; my uint32 @a = 65..127; say($++) && nqp::strfromcodes(nqp::slice(@a,10,13)) for ^100000 # although this say probably slows it down alot 21:54
lizmat yeah, for ma as well, around 3800 21:58
lizmat calls it a day 22:15
Geth nqp/match-speedup: 335434dbb4 | (Jonathan Worthington)++ | src/core/NQPRoutine.nqp
Bring back the onlyname optimization
 22:16
nqp/match-speedup: 63d4b74efc | (Jonathan Worthington)++ | src/core/NQPRoutine.nqp
Use flags/bitmask to cheapen/avoid some work

Now cheaper to see if we have any captures at all, and if so to find out if any of them are quantified, which saves effort when none of them are.		 22:35
MasterDuke lizmat: do you happen to have some code you can share to generate the broken profile? 23:19
jnthn Urgh, `make` will now go and try to helpfully rebuild NQP for me? :/ 23:34
How do I get my "I worked on this thing for 10+ years and know what I'm doing" behavior back?
I can kinda live with it automatically doing that as a default at configure time 23:35
Well, maybe, but I think I still want an option to just complain about the NQP being out of date 23:37
Since otherwise it goes and leaves my development NQP repo with a detached head
Geth rakudo/match-speedup: 4 commits pushed by (Jonathan Worthington)++ 23:38
jnthn sleep & 23:39
evalable6 Use of uninitialized value of type Callable in numeric context
in block <unit> at /tmp/9…
jnthn, Full output: gist.github.com/cd7a4c31f6c3bf8fbd...6571f2555b

Powered by Cro and the Raku® Programming Language.

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

Thank you!