dalek kudo/nom: 9b7c614 | TimToady++ | src/Perl6/Actions.nqp:
mark method body as wanted
 05:42
kudo/nom: 90029ee | TimToady++ | src/core/Supply.pm:
--> Nil return on Supply.emit/done/quit

This works around a buglet that causes a final loop not to.
kudo/nom: cc212ce | lizmat++ | src/core/Array.pm:
Bandaid fix for RT #128736

Array.splice needs to be overhauled anyway, but it looks like I won't be able to do that the coming days, so a quick fix seems in order in the mean time.		 08:20
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128736
kudo/nom: 7f96239 | lizmat++ | src/ (2 files):
Put definition of Signature.returns in bootstrap

So that we can assign --> Nil to subs/methods in the setting before we actually compile Signature.pm		 10:40
kudo/nom: e87752a | lizmat++ | src/core/control.pm:
Mark many builtins as --> Nil

Because now we can		 11:07
gfldex that may be the shortest segfault we ever had :) 11:11
m: multi cross() {};
camelia rakudo-moar e87752: OUTPUT«(signal SEGV)»
lizmat yup, confirmed here as well 11:15
nine bisect: multi cross() {}; 11:18
yoleaux2 27 Jul 2016 19:10Z <[Coke]> nine: tagged a [PRECOMP] related bug, RT #128548
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128548
bisectable nine: On both starting points the exit code is 0 and the output is identical as well
nine: Output on both points:
dalek kudo/nom: acaca18 | lizmat++ | src/core/control.pm:
Streamline CLONE-HASH-DECONTAINERIZED
 11:26
nine [Coke]: thanks! That's one ticket we should be able to get rid of by simply re-testing :) 11:27
jnthn Hm, that multi cross thing looks familiar 11:30
As in, maybe already RT'd
dalek kudo/nom: 998a1ef | lizmat++ | src/core/List.pm:
Fix segfault on "multi cross{}"

The builtin sub cross is an alias for infix X. But we were assigning instead of binding, so the aliasing was not complete. This apparently caused a segfault whenever someone wanted to have their own "cross".
lizmat well, that would be two tickets to mark as resolved then :-) 11:31
gfldex that was mighty fast! 11:38
jnthn Hm, but that means there's still something down at the VM level that explodes 11:39
Which is less than great
lizmat jnthn: well, the explosion is easily reproduced: remove one colon, recompile, fireworks! 11:41
jnthn Indeed 11:42
A MoarVM github issue would be nice if you've a moment 11:43
(Bit tied up with $other-job here...)
lizmat sure, will do
jnthn: github.com/MoarVM/MoarVM/issues/387 11:46
dalek kudo/nom: aa5e494 | lizmat++ | src/core/Distribution.pm:
Mark some more BUILD's as --> Nil
 11:48
lizmat afk for a bit
afk for a bit longer& 12:09
[TuxCM] This is Rakudo version 2016.07.1-79-gaa5e494 built on MoarVM version 2016.07-4-g236058a 12:52
test 15.013
test-t 8.108
csv-parser 16.432
jnthn And no test failures? :) 12:54
[Coke] RT: 1325; @LARRY: 10; CONC: 11; GLR: 6; JVM: 66; LHF: 1; LTA: 94; NEW: 852; NYI: 53; OSX: 6; PERF: 18; POD: 17; PRECOMP: 9; RFC: 24; SEGV: 29; STAR: 4; TESTNEEDED: 12; TODO: 9; UNI: 26; UNTAGGED: 577; WEIRD: 3 13:27
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Fix segfault on "multi cross{}" 13:37
travis-ci.org/rakudo/rakudo/builds/148008634 github.com/rakudo/rakudo/compare/a...8a1ef168ef
[TuxCM] jnthn, indeed, all pass 13:41
[Coke] should jvm backend failures be fatal?
travis doesn't like slow jvm build:
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
we need to up the timeout there.
psch stage parse shouldn't take more than 2 or so minutes 13:43
on jvm
so if it takes 10+ minutes something else is weird
oh well 13:44
that's numbers on hack of course...
i'll look at the travis history to make actual useful statements... :)
the other builds is around 3 minutes stage parse
nqp master that is 13:45
--gen-nqp got stuck
gfldex the build scripts for debian got a 150min timeout. Since arm builds of rakudo take more then 2 hours, it wont propagate to testing automatically. 13:51
nine Seems to happen occasionally that the jvm build just gets stuck on travis 14:04
TimToady I would still like to understand why my 'want method body' patch forces us to put --> Nil on certain Supply methods like emit 14:30
they shouldn't really need that to work right 14:31
it's likely to bite us elsewhere if we don't fix the underlying issue
it seems as though the loop isn't running if it's in the final statement position, but I can't reproduce the problem in user code 14:32
so possibly it only needs the Nil in the setting for some reason
I mean, loop is one of those things that we force to run anyway at statementlist level, but maybe something in the setting doesn't enforce that soon enough somehow 14:34
I suppose we can just wait and see if the issue pops up again somewhere outside the setting
if not, it's likely a circularity issue 14:35
jnthn TimToady: I have vague recollection of an RT along those lines 14:36
TimToady at one point, I just disabled the 'want' if $*COMPILING_CORE_SETTING, but that bugs me, since it did, in fact, find a bug in the setting
jnthn: yeah, I have the same vague feeling
jnthn TimToady: rt.perl.org/Ticket/Display.html?id=128596 14:37
TimToady maybe I should work on that one then 14:38
jnthn :)
TimToady unfortunately, I have to go try to rescue a computer I "upgraded" from Windows 7 to Windows 10 yesterday, and which now doesn't successfully login :( 14:40
well, it's actually probably Sony's fault
jnthn is still on 7 an probably won't upgrade... 14:42
*and
More likely to side-grade :)
timotimo to Mac OSX? :) 14:43
jnthn That's a candidate... :) 14:45
Or maybe it is the year of the Linux desktop already...
timotimo run android on a desktop computer!
tadzik genius.tiff 14:46
timotimo it's the way of the industry: run mobile phone operating systems on desktop computers
tadzik one good thing about windows 10 is that ubuntu userland integration
timotimo windows 10 is basically "Windows Phone, Desktop Edition", mac OSX is basically "iOS Desktop Edition"
tadzik it actually works quite well!
one bad thing is taking 40 minutes to unconditionally update when you arrive at your client's site
jnthn I'm doing pretty much all my development in my Linux VM these days. 14:47
timotimo why not bring a DVD chock-full of updates with you?
mst jnthn: oh, good, that's going to make a bunch of my explanations much shorter in future
TimToady a lot of computers don't have a DVD drive anymore
timotimo ah
on top of that, normal USB keys are already bigger than DVDs are anyway 14:48
mst right, yeah, I remember maybe four years ago my girlfriend coming home with a DVD she's borrowed from a frined for us to watch
and me going "but what do we even have that will play it?"
and she pointed out that there was a slot in the side of the 27" iMac I use as a TV that I'd forgotten existed ;)
timotimo neat
my parents use a playstation 4 for DVD playback as well as on-demand streams and such 14:49
mst actually, I did spend a summer doing a bunch of my development on android
ilmari the ps4 isa apparently a very good bluray player too
mst I managed to get perl5 installed, compiled git on-device
the only thing that didn't work was Module::Build
TimToady we still use our ps3 for blu-ray
we could use more android devs in p6land 14:51
or versa vica
mst after a while I concluded that while I can work from a nexus 7 in a pinch, using it as a primary travelling machine failed the -Ofun test, and went back to thinkpads 14:56
but I'm glad I tried it
arnsholt <3 git commit --amend 15:38
We use our PS4 for some streaming, even though the TV can do it as well
timotimo the next TV i buy, i'll make extra sure it doesn't have a single "smart" feature 15:39
arnsholt It's just that the Android TV app for the Norwegian broadcaster is utterly crap, and the PS4 app is much much better
TimToady m: sub bar() { repeat while 0 { return; } }; bar();
camelia rakudo-moar aa5e49: OUTPUT«Attempt to return outside of any Routine␤ in block <unit> at <tmp> line 1␤␤»
arnsholt I think the PS4 stutters less too, suspect there's just a mite too little computing horsepower in the TV to decompress the highest qualities flawlessly 15:40
The Netflix app is fine, though
jnthn TimToady: Looks like that wants the same handling as for loops, which at statement list level always sink 15:47
(So you should have to put parens around it, or lazy it, or do it, to get that behavior)
TimToady that's not what worries me
I'm not trying to get the value there
look at the error 15:48
jnthn I did
TimToady it's in a routine
jnthn No, that implies that the routine returned something
And that think was sunk and tried to do the return after bar had left 15:49
s/left/returned/
m: sub foo() { for ^10 { return 1 } }; foo
camelia ( no output )
TimToady ah, lazy you mean
jnthn m: sub foo() { (for ^10 { return 1 }) }; foo
camelia ( no output )
jnthn hmm, I'm surprised that doesn't blow up...
timotimo m: sub foo() { (for ^10 { return 1 }) }; foo.sink
camelia ( no output )
timotimo :\
jnthn m: sub foo() { do (for ^10 { return 1 }) }; foo
camelia ( no output )
jnthn m: sub foo() { lazy (for ^10 { return 1 }) }; foo
camelia ( no output )
jnthn m: sub foo() { lazy (for ^10 { return 1 }) }; say foo 15:50
camelia rakudo-moar aa5e49: OUTPUT«1␤»
jnthn ummm
Well that's bust too. Pretty sure that's a regression...
bisectable: sub foo() { lazy (for ^10 { return 1 }) }; say foo
bisectable jnthn: On both starting points the exit code is 0 and the output is identical as well
jnthn: Output on both points: 1
jnthn o.O
m: sub foo() { lazy for ^10 { return 1 } }; say foo
camelia rakudo-moar aa5e49: OUTPUT«1␤»
jnthn bisectable: sub foo() { lazy for ^10 { return 1 } }; say foo 15:51
bisectable jnthn: On both starting points the exit code is 0 and the output is identical as well
jnthn: Output on both points: 1
jnthn I'm sure that once worked lazily?
And so would give an error?
Did it change sometime late last year in the WANTED work?
TimToady not that I know of
m: sub foo() { do for ^10 { return 1 } }; foo 15:52
camelia ( no output )
jnthn m: my \a = lazy for ^10 { say $_ };
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤»
jnthn m: my \a = lazy for ^10 { say $_ }; say a.WHAT
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(Seq)␤»
jnthn m: my \a = lazy for ^10 { say $_ }; say a
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(...)␤»
jnthn m: my \a = lazy for ^10 { say $_ }; say a.eager 15:53
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(True True True True True True True True True True)␤»
jnthn That's less than lazy...
m: my \a = lazy for ^10 { say $_ }; say a.head
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(True)␤»
TimToady m: my \a = lazy for 0 ... 9 { say $_ }; say a
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(...)␤»
TimToady m: my \a = lazy for 0 ... 9 { say $_ }; say a[3] 15:54
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤True␤»
jnthn Yeah, I wondered if the range optimization was busting it too, but seems not
Anyway, I'm fairly sure at some point in the past it did work lazily. So... :S
TimToady m: my \a = lazy for 0 ... 9 { .say; $_ }; say a[3]
camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤3␤»
TimToady m: my \a = lazy for 0 ... 900000000000 { .say; $_ }; say a[3]
not very lazy 15:55
camelia rakudo-moar aa5e49: OUTPUT«(timeout)0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤11␤12␤13␤14␤15␤16␤17␤18␤19␤20␤21␤22␤23␤24␤25␤26␤27␤28␤29␤30␤31␤32␤33␤34␤35␤36␤37␤38␤39␤40␤41␤42␤43␤44␤45␤46␤47␤48␤49␤50␤51…»
TimToady m: my \a = lazy for 0 ... 900000000000 { $_ }; say a[3]
camelia rakudo-moar aa5e49: OUTPUT«(timeout)»
TimToady don't we have tests for laziness? 15:57
m: my \a = lazy for 0 ... * { $_ }; say a[3]
stmuk maybe the absence of tests shows the laziness?
camelia rakudo-moar aa5e49: OUTPUT«(timeout)» 15:58
TimToady m: my \a = do for 0 ... * { $_ }; say a[3]
camelia rakudo-moar aa5e49: OUTPUT«(timeout)»
TimToady something seems to be sinking the for outside of statementlist 15:59
it could be my fault somehow, I suppose
jnthn I'm surprised we don't have tests for that
I'm pretty sure I remember implementing the "for is never lazy at statementlist level" logic 16:00
TimToady yes, but this is the flip side of that
jnthn I'm a bit disappointed I seem not to have done tests for the lazy case. :S
Yeah, but I remember carefully checking that I didn't bust the non-statementlist case
This all was pre-GLR, fwiw
So it's entirely possible tests got lost/mangled in that. 16:01
TimToady also, we don't guarantee strict laziness, so it's possible that batchiness interferes with testing that
m: my \a = gather for 0 ... * { take $_ }; say a[3] 16:02
camelia rakudo-moar aa5e49: OUTPUT«3␤»
TimToady gather/take is pretty strict though
jnthn True, but I don't think we batch anywhere until a List is involved 16:03
Or we sink all
Or do some other kind of iteration that demands many things at once, like in hyper/race
AlexDaniel committable: releases multi cross() {}; 18:03
committable AlexDaniel: ¦«2015.10,2015.11,2015.12,2016.02,2016.03,2016.04,2016.05,2016.06,2016.07»: «exit signal = SEGV (11)»␤|«HEAD»:
AlexDaniel bisectable: multi cross() {};
bisectable AlexDaniel: On both starting points the exit code is 0 and the output is identical as well
AlexDaniel: Output on both points:
AlexDaniel MasterDuke: I wonder why bisectable does not catch segfaults ↑ 18:04
TimToady thinks he has been seeing more superstitious semicolons after {} lately... 18:05
AlexDaniel MasterDuke: right, because signals are handled by each bot separately… 18:07
dalek kudo/better-O: 56dcf56 | arnsholt++ | src/Perl6/Grammar.nqp:
Update grammar to use changed HLL::Grammar.O from NQP.
 19:40
arnsholt The hardest part of that? Remembering that map on Perl 6 objects is lazy >.< 19:41

Powered by Cro and the Raku® Programming Language.

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

Thank you!