00:44
colomon joined
|
|||
timotimo | i'm running a long-term job on hack.p6c.org, i've it to be nice, so i hope it doesn't disturb anyone | 01:03 | |
if it misbehaves, feel free to kill it; it can be resumed if necessary | |||
01:34
colomon joined
|
|||
lizmat | jnthn: a while ago, when working on Blob/Buf, I realiized that Buf ~= Blob is really implemented as Buf = Buf ~ Blob | 07:52 | |
jnthn: which means that there's quite a lot of copying going on when Buf's get bigger | 07:53 | ||
jnthn: so I was wondering whether it would be an idea to implement ~= for Buf/Blob "beforehand" | |||
jnthn: which would then internally be an nqp::splice | |||
psch | .tell skids ec52cce does indeed seem to have fixed RT #126527 | 07:54 | |
lizmat | jnthn: opinions / suggestions / feasibility ? | ||
psch | ah | ||
neaux yoleaux | |||
08:01
RabidGravy joined
|
|||
jnthn | lizmat: No, because = is an operator on a container (a Scalar in this case) rather than on the Buf itself. | 08:37 | |
lizmat: We already have $buf.append(Blob) for in-place, no? | 08:38 | ||
psch | aha, RT #126491 is somewhere in the optimizer! | 09:35 | |
apparently something happens to the ast that loses the clone with the mixin | |||
hm, or maybe r-j just can't deal with the ast correctly that comes out... | 09:36 | ||
'cause they do look identical across r-j and r-m, which i suppose is good :) | |||
the bug itself is < my $value = 42 but False; say ?$value > printing "True" | 09:37 | ||
which doesn't happen when calling it as &infix:<but>(42, False) or when passing 42 but False into a sub | 09:38 | ||
on the other hand, binding the original expression to $value produces the same, wrong, result | |||
moritz | psch: you can try with --optimize=off, no? | ||
psch | moritz: i did, that works, hence why i think it's in the optimizer | 09:39 | |
ah, but --optimize=0 still has the bug | 09:41 | ||
hm, so apparently using the optimizer at all is what causes this..? | 09:42 | ||
...doesn't that mean that walking the ast already changes it, and isn't that bad? :P | 09:44 | ||
jnthn | Could also easily mean that some optimization forgets to check the current level and just applies itself unconditionally | 09:45 | |
psch | hm, lexical -> local lowering seems to always happen | 09:55 | |
well, that's the first thing i saw at least | |||
...but that's not for dynamics, and $*v = ... has the same problem vOv | 09:59 | ||
12:47
[Tux] joined
13:16
skids joined
|
|||
psch | progress! | 13:20 | |
$ ./perl6-j -e'my $x = (rand * 3).Int; my $v = $x but False; say ?$v' | |||
False | |||
so infix:<but> is pure, which does constant folding, but something there doesn't work | |||
note, it's just progress in figuring this out, not progress in fixing it... :) | 13:21 | ||
further, it apparently only happens with Str,Num and Int as LHS to but, which means Perl6/Optimizer.pm:1435-1444 are probably involved | 13:24 | ||
which still means that nqp-j interprets the ast differently, doesn't it..? :/ | 13:25 | ||
m: my $x = 42 but False; say +($x.^can('Bool')) | 13:31 | ||
camelia | rakudo-moar 61d231: OUTPUT«3» | ||
psch | that's 2 on r-j | ||
and $x.WHAT is Int, without the anon role | 13:32 | ||
psch isn't sure where to look from there vOv | |||
15:39
synopsebot6 joined
16:49
dogbert2 joined
18:16
FROGGS joined
18:30
bartolin joined
19:06
perlpilot left
19:12
AlexDaniel joined
19:33
TimToady joined
|
|||
nine | jnthn: how can a <unit> node and a nameless block share the same cuid when I already changed cuid assignment to random numbers, i.e. 127638.666581016? | 19:39 | |
19:54
Skarsnik joined
|
|||
jnthn | nine: No idea...I made them just ascending integers which shoulda been good enough already | 20:20 | |
nine: I mean, the same code maybe coulda been compiled twice, which would have this result | 20:21 | ||
In fact, that's probably the most likely reason | 20:24 | ||
Log calls into the QAST -> MAST compiler to see where it happens, maybe? | 20:25 | ||
20:38
hankache joined
|
|||
nine | will do :) | 20:41 | |
Well the thing is already riddled with debug output...so it's mostly a matter of knowing what to look out for | 20:42 |