Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-07-28

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:26 cognominal joined #perl6-dev
04:25 [TuxCM] joined #perl6-dev
04:49 AlexDaniel joined #perl6-dev
05:42 dalek rakudo/nom: 9b7c614 | TimToady++ | src/Perl6/Actions.nqp:
05:42 dalek rakudo/nom: mark method body as wanted
05:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9b7c614b97
05:42 dalek rakudo/nom: 90029ee | TimToady++ | src/core/Supply.pm:
05:42 dalek rakudo/nom: --> Nil return on Supply.emit/done/quit
05:42 dalek rakudo/nom:
05:43 dalek rakudo/nom: This works around a buglet that causes a final loop not to.
05:43 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/90029eef6f
07:36 [TuxCM] joined #perl6-dev
07:43 RabidGravy joined #perl6-dev
07:43 [TuxCM] joined #perl6-dev
07:50 [TuxCM] joined #perl6-dev
08:20 dalek rakudo/nom: cc212ce | lizmat++ | src/core/Array.pm:
08:20 dalek rakudo/nom: Bandaid fix for RT #128736
08:20 dalek rakudo/nom:
08:20 dalek rakudo/nom: Array.splice needs to be overhauled anyway, but it looks like I won't
08:20 dalek rakudo/nom: be able to do that the coming days, so a quick fix seems in order in
08:20 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128736
08:20 dalek rakudo/nom: the mean time.
08:20 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cc212cebf8
08:26 vendethiel joined #perl6-dev
08:46 sno joined #perl6-dev
10:40 dalek rakudo/nom: 7f96239 | lizmat++ | src/ (2 files):
10:40 dalek rakudo/nom: Put definition of Signature.returns in bootstrap
10:40 dalek rakudo/nom:
10:40 dalek rakudo/nom: So that we can assign --> Nil to subs/methods in the setting before
10:40 dalek rakudo/nom: we actually compile Signature.pm
10:40 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7f962394dd
11:07 dalek rakudo/nom: e87752a | lizmat++ | src/core/control.pm:
11:07 dalek rakudo/nom: Mark many builtins as --> Nil
11:07 dalek rakudo/nom:
11:07 dalek rakudo/nom: Because now we can
11:07 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e87752a431
11:11 gfldex that may be the shortest segfault we ever had :)
11:11 gfldex m: multi cross() {};
11:11 camelia rakudo-moar e87752: OUTPUT«(signal SEGV)»
11:15 lizmat yup, confirmed here as well
11:18 nine bisect: multi cross() {};
11:18 yoleaux2 27 Jul 2016 19:10Z <[Coke]> nine: tagged a [PRECOMP] related bug, RT #128548
11:18 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128548
11:18 bisectable nine: On both starting points the exit code is 0 and the output is identical as well
11:18 bisectable nine: Output on both points:
11:26 dalek rakudo/nom: acaca18 | lizmat++ | src/core/control.pm:
11:26 dalek rakudo/nom: Streamline CLONE-HASH-DECONTAINERIZED
11:26 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/acaca1881d
11:27 nine [Coke]: thanks! That's one ticket we should be able to get rid of by simply re-testing :)
11:30 jnthn Hm, that multi cross thing looks familiar
11:30 jnthn As in, maybe already RT'd
11:30 dalek rakudo/nom: 998a1ef | lizmat++ | src/core/List.pm:
11:30 dalek rakudo/nom: Fix segfault on "multi cross{}"
11:30 dalek rakudo/nom:
11:30 dalek rakudo/nom: The builtin sub cross is an alias for infix X.  But we were assigning
11:30 dalek rakudo/nom: instead of binding, so the aliasing was not complete.  This apparently
11:30 dalek rakudo/nom: caused a segfault whenever someone wanted to have their own "cross".
11:30 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/998a1ef168
11:31 lizmat well, that would be two tickets to mark as resolved then  :-)
11:38 gfldex that was mighty fast!
11:39 jnthn Hm, but that means there's still something down at the VM level that explodes
11:39 jnthn Which is less than great
11:41 lizmat jnthn: well, the explosion is easily reproduced: remove one colon, recompile, fireworks!
11:42 jnthn Indeed
11:43 jnthn A MoarVM github issue would be nice if you've a moment
11:43 jnthn (Bit tied up with $other-job here...)
11:43 lizmat sure, will do
11:46 lizmat jnthn: https://github.com/MoarVM/MoarVM/issues/387
11:48 dalek rakudo/nom: aa5e494 | lizmat++ | src/core/Distribution.pm:
11:48 dalek rakudo/nom: Mark some more BUILD's as --> Nil
11:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/aa5e4945a2
11:48 lizmat afk for a bit
12:09 lizmat afk for a bit longer&
12:50 [TuxCM] joined #perl6-dev
12:52 [TuxCM] This is Rakudo version 2016.07.1-79-gaa5e494 built on MoarVM version 2016.07-4-g236058a
12:52 [TuxCM] test            15.013
12:52 [TuxCM] test-t           8.108
12:52 [TuxCM] csv-parser      16.432
12:54 jnthn And no test failures? :)
13:01 RabidGravy joined #perl6-dev
13:12 skids joined #perl6-dev
13:27 [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:37 travis-ci joined #perl6-dev
13:37 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Fix segfault on "multi cross{}"
13:37 travis-ci https://travis-ci.org/rakudo/rakudo/builds/148008634 https://github.com/rakudo/rakudo/compare/acaca1881ddb...998a1ef168ef
13:37 travis-ci left #perl6-dev
13:41 [TuxCM] jnthn, indeed, all pass
13:41 [Coke] should jvm backend failures be fatal?
13:41 [Coke] travis doesn't like slow jvm build:
13:41 [Coke] No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
13:41 [Coke] we need to up the timeout there.
13:43 psch stage parse shouldn't take more than 2 or so minutes
13:43 psch on jvm
13:43 psch so if it takes 10+ minutes something else is weird
13:44 psch oh well
13:44 psch that's numbers on hack of course...
13:44 psch i'll look at the travis history to make actual useful statements... :)
13:44 psch the other builds is around 3 minutes stage parse
13:45 psch nqp master that is
13:45 psch --gen-nqp got stuck
13:51 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.
14:04 nine Seems to happen occasionally that the jvm build just gets stuck on travis
14:05 pyrimidine joined #perl6-dev
14:30 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:31 TimToady they shouldn't really need that to work right
14:31 TimToady it's likely to bite us elsewhere if we don't fix the underlying issue
14:32 TimToady 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 TimToady so possibly it only needs the Nil in the setting for some reason
14:34 TimToady 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 TimToady I suppose we can just wait and see if the issue pops up again somewhere outside the setting
14:35 TimToady if not, it's likely a circularity issue
14:36 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
14:36 TimToady jnthn: yeah, I have the same vague feeling
14:37 jnthn TimToady: https://rt.perl.org/Ticket/Display.html?id=128596
14:38 TimToady maybe I should work on that one then
14:38 jnthn :)
14:40 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 TimToady well, it's actually probably Sony's fault
14:42 * jnthn is still on 7 an probably won't upgrade...
14:42 jnthn *and
14:42 jnthn More likely to side-grade :)
14:43 timotimo to Mac OSX? :)
14:45 jnthn That's a candidate... :)
14:45 jnthn Or maybe it is the year of the Linux desktop already...
14:45 timotimo run android on a desktop computer!
14:46 tadzik genius.tiff
14:46 timotimo it's the way of the industry: run mobile phone operating systems on desktop computers
14:46 tadzik one good thing about windows 10 is that ubuntu userland integration
14:46 timotimo windows 10 is basically "Windows Phone, Desktop Edition", mac OSX is basically "iOS Desktop Edition"
14:46 tadzik it actually works quite well!
14:46 tadzik one bad thing is taking 40 minutes to unconditionally update when you arrive at your client's site
14:47 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?
14:47 mst jnthn: oh, good, that's going to make a bunch of my explanations much shorter in future
14:47 TimToady a lot of computers don't have a DVD drive anymore
14:47 timotimo ah
14:48 timotimo 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
14:48 mst and me going "but what do we even have that will play it?"
14:48 mst 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 ;)
14:48 timotimo neat
14:49 timotimo 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
14:49 ilmari the ps4 isa apparently a very good bluray player too
14:49 mst I managed to get perl5 installed, compiled git on-device
14:49 mst the only thing that didn't work was Module::Build
14:49 TimToady we still use our ps3 for blu-ray
14:51 TimToady we could use more android devs in p6land
14:51 TimToady or versa vica
14:56 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 mst but I'm glad I tried it
14:59 vendethiel joined #perl6-dev
15:38 * arnsholt <3 git commit --amend
15:38 arnsholt We use our PS4 for some streaming, even though the TV can do it as well
15:39 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
15:39 TimToady m: sub bar() { repeat while 0 { return; } }; bar();
15:39 camelia rakudo-moar aa5e49: OUTPUT«Attempt to return outside of any Routine␤  in block <unit> at <tmp> line 1␤␤»
15:40 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 arnsholt The Netflix app is fine, though
15:47 jnthn TimToady: Looks like that wants the same handling as for loops, which at statement list level always sink
15:47 jnthn (So you should have to put parens around it, or lazy it, or do it, to get that behavior)
15:47 TimToady that's not what worries me
15:47 TimToady I'm not trying to get the value there
15:48 TimToady look at the error
15:48 jnthn I did
15:48 TimToady it's in a routine
15:48 jnthn No, that implies that the routine returned something
15:49 jnthn And that think was sunk and tried to do the return after bar had left
15:49 jnthn s/left/returned/
15:49 jnthn m: sub foo() { for ^10 { return 1 } }; foo
15:49 camelia rakudo-moar aa5e49: ( no output )
15:49 TimToady ah, lazy you mean
15:49 jnthn m: sub foo() { (for ^10 { return 1 }) }; foo
15:49 camelia rakudo-moar aa5e49: ( no output )
15:49 jnthn hmm, I'm surprised that doesn't blow up...
15:49 timotimo m: sub foo() { (for ^10 { return 1 }) }; foo.sink
15:49 camelia rakudo-moar aa5e49: ( no output )
15:49 timotimo :\
15:49 jnthn m: sub foo() { do (for ^10 { return 1 }) }; foo
15:49 camelia rakudo-moar aa5e49: ( no output )
15:49 jnthn m: sub foo() { lazy (for ^10 { return 1 }) }; foo
15:49 camelia rakudo-moar aa5e49: ( no output )
15:50 jnthn m: sub foo() { lazy (for ^10 { return 1 }) }; say foo
15:50 camelia rakudo-moar aa5e49: OUTPUT«1␤»
15:50 jnthn ummm
15:50 jnthn Well that's bust too. Pretty sure that's a regression...
15:50 jnthn bisectable: sub foo() { lazy (for ^10 { return 1 }) }; say foo
15:50 bisectable jnthn: On both starting points the exit code is 0 and the output is identical as well
15:50 bisectable jnthn: Output on both points: 1
15:50 jnthn o.O
15:50 jnthn m: sub foo() { lazy for ^10 { return 1 } }; say foo
15:50 camelia rakudo-moar aa5e49: OUTPUT«1␤»
15:51 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
15:51 bisectable jnthn: Output on both points: 1
15:51 jnthn I'm sure that once worked lazily?
15:51 jnthn And so would give an error?
15:51 jnthn Did it change sometime late last year in the WANTED work?
15:51 TimToady not that I know of
15:52 TimToady m: sub foo() { do for ^10 { return 1 } }; foo
15:52 camelia rakudo-moar aa5e49: ( no output )
15:52 jnthn m: my \a = lazy for ^10 { say $_ };
15:52 camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤»
15:52 jnthn m: my \a = lazy for ^10 { say $_ }; say a.WHAT
15:52 camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(Seq)␤»
15:52 jnthn m: my \a = lazy for ^10 { say $_ }; say a
15:52 camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(...)␤»
15:53 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)␤»
15:53 jnthn That's less than lazy...
15:53 jnthn m: my \a = lazy for ^10 { say $_ }; say a.head
15:53 camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(True)␤»
15:53 TimToady m: my \a = lazy for 0 ... 9 { say $_ }; say a
15:53 camelia rakudo-moar aa5e49: OUTPUT«0␤1␤2␤3␤4␤5␤6␤7␤8␤9␤(...)␤»
15:54 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␤»
15:54 jnthn Yeah, I wondered if the range optimization was busting it too, but seems not
15:54 jnthn Anyway, I'm fairly sure at some point in the past it did work lazily. So... :S
15:54 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␤3␤»
15:54 TimToady m: my \a = lazy for 0 ... 900000000000 { .say; $_ }; say a[3]
15:55 TimToady 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…»
15:55 TimToady m: my \a = lazy for 0 ... 900000000000 { $_ }; say a[3]
15:55 camelia rakudo-moar aa5e49: OUTPUT«(timeout)»
15:57 TimToady don't we have tests for laziness?
15:57 TimToady m: my \a = lazy for 0 ... * { $_ }; say a[3]
15:57 stmuk maybe the absence of tests shows the laziness?
15:58 camelia rakudo-moar aa5e49: OUTPUT«(timeout)»
15:58 TimToady m: my \a = do for 0 ... * { $_ }; say a[3]
15:58 camelia rakudo-moar aa5e49: OUTPUT«(timeout)»
15:59 TimToady something seems to be sinking the for outside of statementlist
15:59 TimToady it could be my fault somehow, I suppose
15:59 jnthn I'm surprised we don't have tests for that
16:00 jnthn 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
16:00 jnthn I'm a bit disappointed I seem not to have done tests for the lazy case. :S
16:00 jnthn Yeah, but I remember carefully checking that I didn't bust the non-statementlist case
16:00 jnthn This all was pre-GLR, fwiw
16:01 jnthn 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
16:02 TimToady m: my \a = gather for 0 ... * { take $_ }; say a[3]
16:02 camelia rakudo-moar aa5e49: OUTPUT«3␤»
16:02 TimToady gather/take is pretty strict though
16:03 jnthn True, but I don't think we batch anywhere until a List is involved
16:03 jnthn Or we sink all
16:03 jnthn Or do some other kind of iteration that demands many things at once, like in hyper/race
16:46 [TuxCM] joined #perl6-dev
17:02 vendethiel joined #perl6-dev
17:58 FROGGS joined #perl6-dev
18:02 AlexDaniel joined #perl6-dev
18:03 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»:
18:03 AlexDaniel bisectable: multi cross() {};
18:03 bisectable AlexDaniel: On both starting points the exit code is 0 and the output is identical as well
18:03 bisectable AlexDaniel: Output on both points:
18:04 AlexDaniel MasterDuke: I wonder why bisectable does not catch segfaults ↑
18:05 * TimToady thinks he has been seeing more superstitious semicolons after {} lately...
18:07 AlexDaniel MasterDuke: right, because signals are handled by each bot separately…
18:44 [TuxCM] joined #perl6-dev
18:57 gfldex_www joined #perl6-dev
19:05 gfldex_www left #perl6-dev
19:40 dalek rakudo/better-O: 56dcf56 | arnsholt++ | src/Perl6/Grammar.nqp:
19:40 dalek rakudo/better-O: Update grammar to use changed HLL::Grammar.O from NQP.
19:40 dalek rakudo/better-O: review: https://github.com/rakudo/rakudo/commit/56dcf56f1f
19:41 arnsholt The hardest part of that? Remembering that map on Perl 6 objects is lazy >.<
21:37 sno joined #perl6-dev

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary