00:05
librasteve_ left
|
|||
[Coke] | Thanks, will try to trim it back again. | 00:41 | |
(not right now) | |||
Geth | Blin: cf24264375 | (Will Coleda)++ | config-default.json Re-trim config defaults |
00:51 | |
[Coke] | ok, now | 00:52 | |
[Coke] kicks off a blin run for the first few commits since the release. | 00:55 | ||
Blin only cares about *new* failures, yes? | 01:06 | ||
02:14
AlexDaniel left
02:42
AlexDaniel joined
|
|||
AlexDaniel | [Coke]: That's correct! so it will test the module on the `new` revision first. If it's OK, that's it. If it's not, then it'll test it on the `old` revision. If it's also not OK, then it's a SNAFU situation, nothing to do. However, if it's good on the old revision, it should rerun the tests a couple of times on the old revision again (to make sure | 02:46 | |
we're not bisecting a flapper). If it's consistently good on the `old` revision, then it bisects. | |||
that's how I remember implementing it :) Maybe something has changed | |||
and I'm happy to see that this tooling is getting some love again <3 | 02:48 | ||
03:06
AlexDaniel left
05:25
kjp left
05:27
kjp joined
05:36
kjp left
05:37
kjp joined
05:46
kjp left
05:47
kjp joined
05:49
kjp left
05:50
kjp joined,
kjp left
05:51
kjp joined,
kjp left,
kjp joined
|
|||
Geth | rakudo/main: a27ae5ed7d | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod RakuAST: support NEXT phasers in non-for loops Fixes: loop { NEXT say "next"; last if $++ > 1 } |
07:22 | |
rakudo/main: 3e2684a465 | (Stefan Seifert)++ | src/Raku/ast/statementprefixes.rakumod RakuAST: actually add phasers to CompUnit $resolver.find-attach-target('block') will return Nil when we're in the CompUnit itself. Sadly this does not throw any error, because the following method call on Nil will just be ignored. Thus we missed this special case. Fix by falling back to compunit if there's no surrounding block. |
08:28 | ||
rakudo/main: a383c8bb6b | (Stefan Seifert)++ | 2 files RakuAST: fix KEEP, UNDO and LEAVE phasers running in their lexical order |
|||
09:11
sena_kun joined
|
|||
Geth | rakudo/main: 307efa6d65 | (Stefan Seifert)++ | src/Raku/ast/statement-mods.rakumod RakuAST: fix loop modifier on block with placeholders Fixes: { say $^x } given 69 |
10:09 | |
rakudo/main: cd0e6ee601 | (Stefan Seifert)++ | 2 files RakuAST: fix for statement modifier on block with placeholder Fixes: { say $^x } for 69 |
|||
nine | 1058 now | ||
ab5tract | [Coke]++ AlexDaniel++ | 10:55 | |
nine++ | 10:56 | ||
nine | m: { say "block" }; { say "block loop" } for ^1 | 17:08 | |
camelia | block block loop |
||
nine | M: -> $_ { say "pointy block" }; -> $_ { say "pointy block loop" } for ^1' | 17:09 | |
m: -> $_ { say "pointy block" }; -> $_ { say "pointy block loop" } for ^1' | |||
camelia | ===SORRY!=== Error while compiling <tmp> Two terms in a row at <tmp>:1 ------> -> $_ { say "pointy block loop" } for ^1⏏' expecting any of: infix infix stopper |
||
nine | m: -> $_ { say "pointy block" }; -> $_ { say "pointy block loop" } for ^1 | ||
camelia | pointy block loop | ||
nine | So what are the real rules for when a pointy block is called automatially? | ||
ab5tract | Oh weird…. | 17:21 | |
m: { dd &?ROUTINE } | |||
camelia | ===SORRY!=== Error while compiling <tmp> Undeclared name: ?ROUTINE used at line 1. Did you mean 'Routine'? |
||
ab5tract | I guess that variable isn’t set for mere blocks | 17:24 | |
nine | m: { dd &?BLOCK } | 17:25 | |
camelia | -> ;; $_? is raw = OUTER::<$_> { #`(Block|3593690399512) ... } | ||
ab5tract | But I was trying to ascertain whether { say “block? } is really a block that is being run or if it’s just a scope being entered and executed | ||
So I guess that’s the answer to that :) | 17:26 | ||
nine: but I guess it kind of makes sense that pointy blocks don’t run unless called. It seems a bit like having blocks get called automatically is a way to allow arbitrary unnamed scoping. But pointy blocks don’t we’ve such a purpose, and so they don’t need to be called in sink context? | 17:32 | ||
It might make sense to have a warning about a useless use, in such a situation though | 17:33 | ||
nine | yeah | 17:36 | |
18:03
finanalyst joined
|
|||
[Coke] | Crap. I had a run yesterday running in azure under tmux and this morning the window was closed and there was no session to reattach to. | 18:13 | |
Looks like there's an output/overview that has the progress - only "Unknown/MissingDependency/AlwaysFail/OK" in there. | 18:15 | ||
(278 OKs) | 18:16 | ||
Geth | Blin: cf77811d86 | (Will Coleda)++ | bin/blin.p6 Be slightly more forgiving on command line params. e.g. --heartbeat=300 |
18:48 | |
19:01
finanalyst left
|
|||
[Coke] | the Blin runs aren't completing - I had it in tmux, and while it was waiting, opened a new tmux tab so I could run top - it just hung so I ignored it for a while; came back to the new window, the old window was *gone* and the progress was gone. | 19:47 | |
the output shows it's getting partway through. | |||
er, the output file | 19:49 | ||
timo | gist.github.com/timo/959f8fd36ee9e...df8db199fb - ppc64 spectest results | 21:33 | |
22:03
sena_kun left
22:22
sena_kun joined
22:30
sena_kun left
|
|||
[Coke] wonders if he needs to ramp up the VM again for *running* blin (vs. building rakudo&blin) | 23:26 | ||
Geth | Blin: bfbb25832e | (Will Coleda)++ | bin/blin.p6 follow quote code style |
23:50 |