travis-ci Rakudo build passed. Elizabeth Mattijsen 'Prevent mutable keys in Pairs, RT #128965' 03:01
travis-ci.org/rakudo/rakudo/builds/152789578 github.com/rakudo/rakudo/compare/b...9b760fcedc
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128965
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Revert "Prevent mutable keys in Pairs, RT #128965" 03:41
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128965
travis-ci travis-ci.org/rakudo/rakudo/builds/152805207 github.com/rakudo/rakudo/compare/d...0d92de142f
[Tux] This is Rakudo version 2016.07.1-200-gb00d92d built on MoarVM version 2016.07-18-g2f269d8 06:12
csv-ip5xs 10.036
test 15.581
test-t 7.578
csv-parser 16.997
And a second run 06:16
csv-ip5xs 10.155
test 15.324
test-t 7.335
csv-parser 16.855
arnsholt Hee hee hee! Discovered while digging into Rakudo's parser actions: "sub thunkity_thunk" 07:43
jnthn: From what I can gather, a hash lookup on an NQPMu just returns NQPMu again. That right? 07:54
Bah. Tracking down errors is going to be harder when the line numbers are off =( 08:27
Holy crap, it worked! 08:49
Now to see how many metaop spectests I broke!
gfldex i would vote for RT#127019 to be changed from LTA to [BUG] 09:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127019
jnthn morning, #perl6 09:08
arnsholt o/ 09:09
jnthn got some decent sleep and will hopefully be able to track down the 6harness issues today :)
arnsholt: Yes, if you use the indexing syntax you'll get NQPMu back. If the nqp::atkey op directly, an nqp::null
arnsholt Yeah, that's what it looked like
The better-O refactor had to expand some tests like "if $<infix><OPER><O><iffy>" to "if $<infix><OPER> && $<infix><OPER><O><iffy>" 09:10
Anyways, I think I'm on track to getting Rakudo refactored as well 09:11
The hard part last time I did this was getting the setting to compile, which I managed to get right just now
lizmat jnthn: I'm thinking about DEPRECATing Pair.freeze for the following reasons:
arnsholt There's some spectest fallout, but hopefully that won't be too hard to fix
lizmat 1. this is the one case that I know of where it changes the .WHICH of an existing object 09:12
2. it only deconts one level, so it could still be mutable
3. I thought I needed it for Bag|Mix.pairs, but I don't
I feel 1. is the most important reason 09:13
there are 2 spectests for it, and there is some doc for it 09:14
jnthn Wait, was .freeze in-place?
(or "is" for now but... :)) 09:16
I'd sorta assumed when I heard about it that it returned a Pair with key and value decont'd :)
lizmat no, it in placed :-( 09:30
jnthn: (sorry, was called away for a photo session with a lot of butterflies)
jnthn Bufferflies!
Uh
Butterflies
.oO( Am I really awake enough to be debugging 6harness... :P)
 09:31
lizmat :-)
jnthn On the "No subtests run" - dunno if you'd already figured this out but if you comment out the test immediately before the one that first says that in spectest.data, it gets further. Until another one causes it to go awry after it so you comment that out and...further it gets again. 09:32
arnsholt Comment-driven development!
lizmat jnthn: no hadn't figured that out yet this time
jnthn So, now to see what these tests have in common :) 09:33
OK, just thought I'd check I'm not re-discovering stuff :)
lizmat I would assume some precomp issue with use lib
jnthn That seems unlikely given the candidates
nine exhales 09:34
lizmat sorry nine, but since it says "No subtests run", it probably means it didn't compile, so ... 09:35
nine No worry :) 09:37
Just turns out that I really enjoyed not having worked on module loading for a couple of weeks.
But the next two big issues in Inline::Perl5 will involve going back to module loading.
lizmat so, do we have an HLL way of deconting ? 09:44
jnthn The only thing in common between these tests so far is that they all produce over 200 lines of output :) 09:46
lizmat which ones ? 09:54
jnthn gist.github.com/jnthn/6cadf2259a61...d37a4de212 09:58
arnsholt Haha! I was trying to fix a reverse metaop spectest introduced *yesterday* =D 09:59
lizmat jnthn: could it be the *size* of the output in bytes, rather than # of lines
jnthn Very possibly, but those would corellate :)
What's odd is that a test that outputs 400+ lines is itself handled OK. It hoses stuff up for the *next* test is what's really odd. 10:00
TEST_JOBS= HARNESS_TYPE=6 make localtest 10:01
make: *** No rule to make target `m-localtest6', needed by `localtest'. Stop.
aww :( 10:02
nine Reminds me a bit of people having problems with run(:out) and large outputs 10:03
jnthn nine: Got a link? 10:04
Hm, this is odd 10:05
m-localtest: m-all spectest_checkout t/localtest.data @$(M_HARNESS6_WITH_FUDGE) --tests-from-file=t/localtest.data
oops, paste fail
But that looks like localtest *always* uses the 6 harness?
Apart from it seems not to 10:06
nine jnthn: sorry, no :( Just feels like I've read things like that from time to time. Where do we buffer pipe output anyway? AFAIR a UNIX pipe buffers ~ 4K before blocking 10:08
So unless one actually reads the output, the processes will start hanging. 10:09
arnsholt I get two spectest failures in S15-nfg/regex.t, are those expected? 10:10
(not ok 10 - Do not have accidents involving range char class and NFC, and not ok 11 - Do not have accidents involving range char class and NFC under :i) 10:11
jnthn that was fixed recently...you're not missing the fix (think it was a fix in NQP, so could your O branch be beind?)
*behind
Aha, it seems that it's actually an OSR bug 10:17
Which makes sense in that the OSR limit is around 200
(strace kinda give the hint; I could see the JIT mapping executable memory...)
nine Ah, 200 iterations of reading a line :) 10:19
or processing
jnthn Right, processing
Wowser, and if I stick a debug printf in the OSR-ing code, it doesn't fail?! 10:25
Zoffix What's OSR? 10:32
lizmat On Stack Replacement 10:34
if a sub is called many times at the same place, it can be optimized by just inserting the code of the sub at that place
at least, that's my interpretation :-) 10:35
Zoffix ah 10:36
jnthn OSR of the first loop in IO::Pipe.lines seems to be guilty 10:38
nine Looks so innocent
arnsholt jnthn: Yeah, the better-O branch is behind NQP a bit so that's probably it 10:39
Woot! No fails but the NFG one =D 10:40
Zoffix s: IO::Pipe, "lines", \() 10:43
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/b00d...ipe.pm#L10
dalek kudo/nom: a4140a3 | gfldex++ | src/core/Bool.pm:
fix for RT#127019
 10:50
kudo/nom: 40706bf | lizmat++ | src/core/Bool.pm:
Merge pull request #836 from gfldex/RT127019

fix for RT#127019
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127019
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127019
arnsholt jnthn: In Perl6::Grammar there's a method AS_MATCH (Grammar.nqp:3971 here), mostly used for O stuff (but also colonpairs that's eminently killable); does it differ much from the construct "$<O> = {$<postfix><O>}"? 10:51
gfldex lizmat: github.com/perl6/roast/pull/141 10:54
dalek ast: df65307 | gfldex++ | S02-types/bool.t:
tests for RT#127019
ast: d0f8198 | lizmat++ | S02-types/bool.t:
Merge pull request #141 from gfldex/RT127019

tests for RT#127019
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127019
p/no-eval: 4eeaa2e | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Get rid of dead variable.
 11:24
p/no-eval: d2eae8a | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] Load ctx by calling ctxsave on the ModuleLoader rather than using a hacky nqp.ctxsave()
jnthn back 12:06
arnsholt: It just makes a passed Cursor that has $!match (so its .MATCH result) set to whatever was passed in 12:08
arnsholt: And no, it's not really the same as: 12:09
nqp: my $m := "a" ~~ /$<O>={'xyz'}/; say($m<O>.HOW.name($m<O>))
camelia nqp-moarvm: OUTPUT«NQPMatch␤»
jnthn Whereas with AS_MATCH that'd come back as a string 12:10
unmatched} So many camelias :D scontent-lga3-1.xx.fbcdn.net/t31.0...7754_o.jpg
masak whoa 12:12
oh, poor liz got bandaids :/
dalek kudo/nom: 424d725 | lizmat++ | docs/ChangeLog:
Add some more (recent) ChangeLog entries
lizmat masak: actually, I'm bandaid free at the moment 12:15
nine lizmat: there's one on your shirt ;)
lizmat unfortunately, not yet bruis-free :-(
*bruise
masak here's hoping for a quick de-bruising
lizmat Ah, that...
not a bandaid, but part of the Dutch Perl Workshop T-shirt last April in Amsterdam 12:16
the X is one of the 3 X's in the logo of Amsterdam
en.wikipedia.org/wiki/Amsterdam#/m...onatum.svg # coat of arms
nine just learned something :) 12:17
arnsholt jnthn: I think I see. And I think I see what I'll try to do about it. $dayjob right now, but I'll probably poke you again in a few days for a review 12:39
jnthn OK :) 12:41
arnsholt: I suspect its reason for existing is because we stored the hash of details under the match slot rather than in .ast, so it may no longer be needed after you changes. 12:50
arnsholt Yeah, I think they all more or less build equivalent structures 12:51
AS_MATCH is also used twice elsewhere, but also for storing hashes in the tree, so I think I'll replace it with a more generic "zero-width match and attach this thingy as the AST" mechanism 12:52
Should work for both the AS_MATCH and $<O> = {...}
jnthn Now into S05 using the Perl 6 test harness with TEST_JOBS= 12:54
And still going strong 12:55
(With a local patch)
arnsholt Or maybe I can just replace the AS_MATCH thingies with $<O> = {...}? Since getting the thing will now actually be an NQPMatch, not a hash? 12:56
jnthn Your changes stick the hash into .ast, no? 12:57
arnsholt Yeah
[Coke] jnthn: "we
jnthn So I'd expect token AS_MATCH($v) { { make $v } } or so
[Coke] jnthn: "we'll deal with this later" is perfectly fine; we just need to encapsulate that on the ticket. 12:58
arnsholt jnthn: Yeah, basicall.
*y
But other code also does $<O> = {$<postfix><O>} which also appears to work, with expecting things to be in .ast. Should that not work? 13:01
jnthn Oh, hmm :)
I wasn't aware that'd set the .ast :)
Does it really? :) 13:02
arnsholt Well $<postfix><O> has the appropriate .ast
[Coke] (that said, lizmat++ for improving the situation in the meantime.)
lizmat what did I do this time ?
jnthn arnsholt: Ah, OK :)
arnsholt Which is then supposed to be available through the other rule's .ast
[Coke] lizmat: patched some thing or other. Danke. :) 13:03
lizmat ah, that :-)
jnthn Now up to S17
arnsholt AFAICT the two constructs have more or less the same effects, at least with regards to .ast
But I guess the rest of the match information might go a bit weird with $<O> = {$<postfix><O>} 13:04
[Coke] RT: 1346; @LARRY: 11; CONC: 26; GLR: 4; JVM: 66; LHF: 1; LTA: 113; NEW: 867; NYI: 83; OSX: 5; PERF: 23; POD: 17; PRECOMP: 10; RFC: 33; SEGV: 33; STAR: 5; TESTNEEDED: 17; TODO: 10; UNI: 28; UNTAGGED: 489; WEIRD: 3 13:06
also:
Remaining tags, any of interest?
@IXS: 1; BOOTSTRAP: 3; BUG: 425; BUILD: 7; CSTRUCT: 1; DOCS: 1; EFG: 1; FOO: 1; INT: 1; MATH: 1; MOARVM: 1; NATIVECALL: 5; NUMERIC: 1; REPL: 1; RT: 1; SPESH: 1; STR: 1; WEB: 1
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Add some more (recent) ChangeLog entries' 13:07
travis-ci.org/rakudo/rakudo/builds/152951941 github.com/rakudo/rakudo/compare/4...4d725ea585
buggable ✓ [travis build above] One job failed due to the timeout. No other failures.
dalek kudo/nom: 0f420ad | lizmat++ | src/core/Bag (2 files):
Make Bag/BagHash.Mix coercion 1000x faster

This thing is, since Mix is immutable, we can just transplant the inside of the Bag/BagHash, since Mixes can also contain Ints as values.
OTOH, this type of coercion is not likely, so YMMV.
unmatched} holy crap 1000x
lizmat++
lizmat well, for a 1000 element bag
it was actually not quite measurable
jnthn If I mutate the BagHash, will the Mix remain the same?
lizmat jnthn: yes, because it cloned the internal hash 13:08
jnthn Dammit 13:09
t/spec/S32-trig/cotan.t ................................... ok
Aborted (core dumped)
make: *** [m-spectest6] Error 134
Nearly got there :P
lizmat ah, indeed, for the BagHash.Mix we need to clone, then it's only about 80x faster :-)
m: dd mix(<a b b c c c>) 13:13
camelia rakudo-moar 0f420a: OUTPUT«("a"=>1,"c"=>3,"b"=>2).Mix␤»
lizmat m: dd mix(<a b b c c c>).values.map: { .WHAT }
camelia rakudo-moar 0f420a: OUTPUT«(Int, Int, Int).Seq␤»
[Coke] wonders what ribasushi's problem is. 13:26
(having just read some comments on reddit)
unmatched} To me it feels he never got over his miserably failed attempt to sponsor Perl work. And in its description of it, it sounded like he was kinda desperate for money, in order to be able to continue open source work at all. 13:29
[Coke] I can't speak to that, I guess. On the face of it, is it just "Perl is a bad name for Perl 6" ? I mean, there's probably one person who is happy about that. 13:30
jnthn Funding people to do non-trivial open source work that is unreasonable for them to do in their spare time is certainly a genuine problem. 13:36
(And a problem far, far broader than a Perl problem.) 13:38
It's fair enough for people to look for funding so they can do open source stuff without trashing their work/life balance. Also, people's circumstances change, and energy levels with them. I for one have nowhere near the free quality time I used to have. It's highly unlikely I'd be able to sit all day hunting concurrency issues without funding at present. So, please don't call people trying to save their significant open source involvement by 13:40
Bringing up the naming thing, on the other hand, is silly, and not really excusable at this point. 13:41
nine jnthn: your message was cut off 13:42
jnthn gah, where
nine open source involvement by 13:43
jnthn So, please don't call people trying to save their significant open source involvement by having it fudned desperate.
unmatched} No, I meant that he explicitly stated that without this funding he won't be able to do anything and will have to walk away from his work that's used by many businesses: www.tilt.com/tilts/year-of-ribasus...escription 13:45
The goal was $120K for the year and he got only $30K. The plan was for business that use his code to chip in, but virtually none did. 13:46
lizmat afk& # yes, gone cycling again :-) 13:54
jnthn Be careful!! :)
jnthn has a fix for one more issue afflicting TAP.pm6, and is debugging a third 14:29
unmatched} \o/ 14:46
jnthn Seems it may be to do with deferral (callsame and friends) 14:47
Didn't get to the bottom of that yet, but fixed a different and related issue on the way :) 14:57
(Both latest ones were code-gen bugs in Rakudo) 14:58
dalek p/no-eval: 86fb863 | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] Rename HLLBackend::JavaScript to JavaScriptBackend.
 15:22
p/no-eval: 57daedd | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] Stop evaling code when deserializing closures.
p/no-eval: a107d32 | (Pawel Murias)++ | src/vm/js/nqp-runtime/code-ref.js:
[js] Get rid of the global CodeRef.cuids cuid to codeRef mapping.
p/no-eval: bad4c0d | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Stop passing unused static info to CodeRefs.
gfldex rt.perl.org/Public/Bug/Display.html?id=127019 can be closed 16:02
unmatched} Done. 16:03
dalek kudo/nom: b08527f | jnthn++ | src/core/control.pm:
Propagate caller $/ through deferral.

Otherwise, all callees end up seeing the same $/, which is the one in the setting mainline. This caused an over-sharing issue in threaded code. Since the `subparse` method returns the $/ it assigned to, it could cause seeing a completely unrelated Match object from another operation in another thread. This was the cause of the substr out of range problem in the Perl 6 TAP harness.		 16:07
jnthn My other two fixes will need a little more work, 'cus I've managed to regress a state test, of all things... 16:08
unmatched} I plan on exposing Test.pm6's die_on_fail functionality as PERL6_TEST_DIE_ON_FAIL env var. The functionality seems to be there, but not exposed to the user in any way, and it's a very useful feature when dealing with large test suites. 16:53
dalek kudo/missing-clones: 02a0477 | jnthn++ | src/Perl6/Actions.nqp:
Avoid double code-gen of closure clone.

The blorst action already emits that; doing it twice is just extra CPU time and more throwaway objects to GC.		 18:35
rakudo/missing-clones: 739d1a3 | jnthn++ | src/Perl6/ (2 files):
rakudo/missing-clones: Fix mis-scoping of blocks in s///.
rakudo/missing-clones:
rakudo/missing-clones: Now we create the outer scopes sooner, so the things inside of them
rakudo/missing-clones: naturally end up in the correct places. We'll want a similar thing for
rakudo/missing-clones: other regexy constructs too, I suspect; this one got done first as it
rakudo/missing-clones: fixes RT #128809.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128809
jnthn Will see if I can get any of those 4 mergeable before the release :) 18:38
(yes, there's 4, dalek was being lazy)
I know one of the latter two regresses something 18:39
Was hoping neither of the first two did
oh, the first two are fine 18:40
The fail is in a local test partly covering the second two :) 18:41
dalek kudo/nom: 02a0477 | jnthn++ | src/Perl6/Actions.nqp:
Avoid double code-gen of closure clone.

The blorst action already emits that; doing it twice is just extra CPU time and more throwaway objects to GC.
rakudo/nom: 739d1a3 | jnthn++ | src/Perl6/ (2 files):
rakudo/nom: Fix mis-scoping of blocks in s///.
rakudo/nom:
rakudo/nom: Now we create the outer scopes sooner, so the things inside of them
rakudo/nom: naturally end up in the correct places. We'll want a similar thing for
rakudo/nom: other regexy constructs too, I suspect; this one got done first as it
rakudo/nom: fixes RT #128809.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128809
unmatched} \o/
timotimo \o/
jnthn If somebody fancies writing a test, rt.perl.org/Ticket/Display.html?id=128809 :) 18:44
Food for me :) 18:45
unmatched} Yeah, I can write. 18:52
dalek ast: 16d333d | (Zoffix Znet)++ | S05-substitution/subst.t:
code in replacement part of s/// has correct scoping

RT#128809		 19:11
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128809
unmatched} m: { my $_ = 42 } 19:15
camelia rakudo-moar 739d1a: OUTPUT«Potential difficulties:␤ Redeclaration of symbol $_␤ at <tmp>:1␤ ------> { my $_⏏ = 42 }␤»
dalek ast: c316607 | (Zoffix Znet)++ | S05-substitution/subst.t:
Avoid spurious warnings in output

my $_ ... does not need a my on it		 19:17
kudo/nom: 848add9 | niner++ | src/core/CompUnit/Repository/FileSystem.pm:
Fix -Ilib and friends not overriding installed dependencies

When checking the dependencies of a precomp file, we did not take development version of modules in FileSystem repositories into account. I.e. with A depending on B putting a new version of B into the lib directory and running perl6 -Ilib -MA you would still get the precompiled version of A that uses the installed version of B.
Fixed by having the identity of a FileSystem repository reflect its complete content. So by changing the content we detect a change in the repository chain and know to re-resolve dependencies.		 19:23
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make Bag/BagHash.Mix coercion 1000x faster 19:42
travis-ci.org/rakudo/rakudo/builds/152965365 github.com/rakudo/rakudo/compare/4...420ad2dc10
buggable ☢ [travis build above] Build log missing from at least one job. Check results manually.
unmatched} Results are fine
[Coke] jnthn: looks like #125048 was skipping some flapping tests. 20:14
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125048
[Coke] down to < 450 tickets that are untagged. 20:19
lizmat hmmm.... quite some seemingly precomp related spectest error atm ?
reconfiguring and rebuilding to make sure... 20:20
jnthn [Coke]: Hm, we could try unskipping them to see if latest fixes help 20:24
[Coke]: It's tagged CONC, and I'm working through those anyway, so will get it to if nobody else does :)
nine There are skips in S17-procasync/basic.t and S17-procasync/print.t because of flapping 20:25
[Coke] yup, just tagged it for that reason. :) 20:27
jnthn nine: Do they still flap with recent fixes, though? :) 20:28
nine jnthn: can't say right now. Broke my rakudo quite well by playing around with symbol merging :) 20:29
jnthn ah, OK :) 20:30
No hurry :)
I'm beat for the day anyway :)
[Coke] ponders adding [OO] and [REGEX] tags. 20:32
lizmat $ perl6 -Ilib t/spec/S11-modules/nested.t 20:38
===SORRY!===
P6M Merging GLOBAL symbols failed: duplicate definition of symbol Grammar
lizmat nukes install, tries again 20:39
nine Odd. I did run a full spectest before pushing :/
lizmat: your command runs just fine here 20:41
lizmat well, not here... but I'm now on a fresh install, rebooting panda and installing Inline::Perl5 20:43
hmmm.... 20:44
nine lizmat: can you paste RAKUDO_MODULE_DEBUG output of a failed run?
lizmat will in a mo, after I've determined it is not some uncommitted change doing this 20:45
even bootstrapping panda failed :-( 20:47
nine ouch
Is it a failed test? 20:48
lizmat gist.github.com/lizmat/9e9af080e53...2b0109030b 20:50
nine: ^^^
this is without my uncommitted change, fwiw
nine Ok, I get the same here. I did even use the installed panda, but not re-bootstrap
Oh, may be a trivial fix 20:53
dalek kudo/nom: 7d80466 | niner++ | src/core/CompUnit/Repository/FileSystem.pm:
Fix loading modules when a FileSystem repo doesn't actually exist

Commit 848add944fe6de9090f0abc3b17e9a3a8e2cc42b broke module loading when a FileSystem repo pointing to a non-existing directory was in the repo-chain, i.e. perl6 -I/this/path/does/not/exist Affected panda's bootstrap.		 20:57
nine lizmat: ^^^
lizmat ok, will try :-) 20:58
nine: isn't "$file.slurp(:enc<latin1>)" a bit fragile? I mean, don't we support utf-8 ? wouldn't utf8-c8 be better ? 21:01
nine lizmat: latin1 is the closest we get to :bin as long as nqp::sha1 only supports Str, not blob 21:02
lizmat but if there are UTF-8 sequences in the file, the slurp will fail, no?
nine lizmat: we've been using the same in src/core/CompUnit/PrecompilationStore/File.pm for a couple of weeks
lizmat I mean, you're slurping the source, no ? 21:03
geekosaur lizmat, the other direction would fail, but latin1 will accept any byte sequence and doesn't even know about multibyte characters
nine Yes, but only to feed it to sha1
And SHA1 is actually an algorithm for byte sequences :)
geekosaur now, fi you tried to render it as text you;d get mojibake, but for the stated purpose it's fine 21:04
lizmat ok, nine geekosaur thanks for the explanation :-)
nine: confirmed panda bootstrap now ok
nine And nested.t?
lizmat ok now 21:05
nine great :)
lizmat nine++
running full spectest now
:-( still same breakage 21:17
eh.... maybe I forgot to start the spectest :-)
running again :-)
nine: no, still breakage 21:28
still same breakage :-( 21:29
gist.github.com/lizmat/a51aa789923...100d0d2c75 21:30
.tell nine with 848add944fe6de9090f0 and 7d804663db8fdd331 reverted, all works fine for me :-( 22:12
yoleaux2 lizmat: I'll pass your message to nine. 22:15
Zoffix 0.o
lizmat good night, #perl6-dev! 22:17
Zoffix night
dalek kudo/nom: a23c39c | (Zoffix Znet)++ | docs/release_guide.pod:
Remove dollar signs from shown shell commands

So it's easier to copy-paste those commands into the terminal		 22:19
Zoffix t/spec/S17-procasync/kill.rakudo.moar (Wstat: 0 Tests: 9 Failed: 0) 22:54
TODO passed: 9
But only when I do make stresstest and not make t/spec/S17-procasync/kill.t strangely
dalek kudo/nom: 71f156e | (Zoffix Znet)++ | .gitignore:
Ignore panda/ dir

So we don't worry about accidentally committing it when stresstesting		 23:19
kudo/nom: 1c7ca5e | (Zoffix Znet)++ | / (2 files):
Add PERL6_TEST_DIE_ON_FAIL env var to Test.pm6

  - Lets abort test suite on first failure (useful on large suites)
  - Remove die_on_fail() sub. It seems to be a leftover from old times
   as it's not used in Test.pm6 and one can't use it from outside either.
  - Do not stick $die_on_fail into the var stack and just keep a single one
   for the entire suite.
ast: eae3265 | (Zoffix Znet)++ | S24-testing/8-die_on_fail.t:
Test PERL6_TEST_DIE_ON_FAIL env var

Must abort test suite on first failure.		 23:21
kudo/nom: e97fb7d | (Zoffix Znet)++ | t/spectest.data:
Add S24-testing/8-die_on_fail.t to list of tests to run
 23:22
Zoffix (Note to self: git commit some-file commits all of it, even if you staged a chunk from it already ~_~) 23:23
☢☢☢ our REPL seems to be borked entirely. IMO this is a release blocker: rt.perl.org/Ticket/Display.html?id=128973 23:52
and we aaalmost have a test to detect this failure mode :) if only it tried to use those variables: github.com/perl6/roast/blob/master...repl.t#L60 lol 23:53
And I'm guessing rt.perl.org/Ticket/Display.html?id=127933 got fixed simply because the variables disappear, not because the issue has been fixed, so that test likely will have to be fudged back in again 23:55
Zoffix leaves to fly in No Man's Sky :) 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!