Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-06-28

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

All times shown according to UTC.

Time Nick Message
00:00 DeadDelta [Coke]: you could also try putting the `use lib` *before* you use any modules
00:01 timotimo that's a good idea in general
00:03 timotimo i've reached P in "writing type document"
00:08 [Coke] ugexe: -I. still segvs.
00:08 [Coke] DeadDelta: yup, that fixed it
00:09 AlexDaniel joined #perl6-dev
00:09 BenGoldberg timotimo, "writing typ" ?
00:10 timotimo hehe
00:15 [Coke] ... ok, now it segfaults at the end. :P
00:31 astj joined #perl6-dev
00:49 astj joined #perl6-dev
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
02:40 btyler joined #perl6-dev
04:12 Ben_Goldberg joined #perl6-dev
05:02 astj_ joined #perl6-dev
05:40 brrt joined #perl6-dev
05:56 [Tux] This is Rakudo version 2017.06-90-g9a2127f2b built on MoarVM version 2017.06-30-g389e9732
05:56 [Tux] csv-ip5xs        2.875
05:56 [Tux] test            13.013
05:56 [Tux] test-t           3.999 - 4.024
05:56 [Tux] csv-parser      13.940
06:02 astj joined #perl6-dev
06:44 brrt joined #perl6-dev
07:17 epony joined #perl6-dev
07:27 patrickz joined #perl6-dev
08:07 TimToady joined #perl6-dev
08:59 jnthn [Coke], ugexe About the --doc / .lines bug - have either of you seen it happen *not* on OSX? I just tried it on Linux and it worked fine 10 times in a row
09:05 jnthn Gah, when did my int $a = 1; for ^10000 { $a = $a + 1 } stop inlining the + :/
09:06 * llfourn wonders how we can stop regressions like that from happening
09:06 astj joined #perl6-dev
09:06 jnthn I'm going to add a test that obtains --target=optimize output and greps it :)
09:07 jnthn (In the rakudo set of tests)
09:07 llfourn sounds good to me :)
09:07 jnthn I know that was going to be some cleanup of multi/native semantics but...it should not have broken this :/
09:08 jnthn argh
09:08 jnthn Yes it removed the special-casing of compile-time constants :/
09:09 llfourn one day I hope I find the time to contribute some auto-benchmarker which keeps track of the run time for snippets of code.
09:09 jnthn I seem to remember some discussion of some change in this area
09:09 jnthn But I didn't realize it was going to rip *this* out :/
09:13 * jnthn finds what's probalby the guiltiy commit, reverts, tests
09:13 jnthn I thought some odd inconsistency was being cleared up
09:14 jnthn Not ripping out the optimization around literals
09:14 jnthn Yes, *of course* the compile-time multi-dispatch semantics are a tad different here because at compile time we know what's a literal and what's not.
09:24 Geth ¦ rakudo/nom: 1c0ed61a44 | (Jonathan Worthington)++ | 2 files
09:24 Geth ¦ rakudo/nom: Revert "Stop the optimizer from using what I assume are old semantics for multi dispatch"
09:24 Geth ¦ rakudo/nom:
09:24 Geth ¦ rakudo/nom: This reverts commit ccfa5e51a21f5a613ecb0cfb24be6c15f4103752. The
09:24 Geth ¦ rakudo/nom: semantics it removed were not old. They were a special case analysis
09:24 Geth ¦ rakudo/nom: of the use of literals in combination with known native types, to
09:24 Geth ¦ rakudo/nom: allow native candidates to be called. The reverted commit may have
09:24 Geth ¦ rakudo/nom: been intended to fix some inconsistency (which is what I thought was
09:24 Geth ¦ rakudo/nom: happening), but in fact the code it removed is critical for good
09:24 Geth ¦ rakudo/nom: performance.
09:24 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1c0ed61a44
09:24 Geth ¦ rakudo/nom: c32d7bb8c9 | (Jonathan Worthington)++ | t/02-rakudo/08-inline-native-arith.t
09:24 Geth ¦ rakudo/nom: Add test to ensure we don't bust native inlines.
09:24 Geth ¦ rakudo/nom:
09:24 Geth ¦ rakudo/nom: This was broken a little while back, causing a huge regression in
09:24 Geth ¦ rakudo/nom: native integer performance. This test will help to catch such cases.
09:24 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c32d7bb8c9
09:24 Geth ¦ roast: f8c706da4a | (Jonathan Worthington)++ | S06-multi/type-based.t
09:24 Geth ¦ roast: Update test for multi literal semantics.
09:24 Geth ¦ roast: review: https://github.com/perl6/roast/commit/f8c706da4a
09:25 jnthn Now I wonder exactly what inconsistency was originally being fixed, but there aren't really tests to tell me.
09:25 jnthn I guess for now we'll enjoy the better performance and we'll see if something re-surfaces. :)
09:36 brrt joined #perl6-dev
09:47 lizmat Files=1208, Tests=63399, 223 wallclock secs (13.19 usr  5.09 sys + 1348.42 cusr 137.31 csys = 1504.01 CPU)
09:48 lizmat before the last fix ^^^
09:48 Geth ¦ rakudo/nom: ce20887760 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
09:48 Geth ¦ rakudo/nom: Add R:Q.ADD-SET-TO-MIX
09:48 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ce20887760
09:55 [TuxCM] joined #perl6-dev
10:02 timotimo you know ... since we have the bot report all commits, we can totally search for a commit short id in the irclogs and hopefully find the discussion that goes with it
10:03 DeadDelta The discussion was this
10:03 DeadDelta huggable: native
10:03 huggable DeadDelta, here's a ticket: https://rt.perl.org/Ticket/Display.html?id=129844#txn-1433016 and here's explanation why it isn't: https://irclog.perlgeek.de/perl6-dev/2016-10-25#i_13462673
10:04 DeadDelta And the answer was we don't native dispatch to multies, so pmurias tossed it
10:04 jnthn :/
10:04 timotimo https://irclog.perlgeek.de/perl6-dev/2016-10-25#i_13462673  -  here's that discussion
10:04 timotimo ah
10:04 timotimo already posted, i see
10:04 jnthn We *do* hative dispatch to multis though
10:05 jnthn m: multi a(int $x) { }; my int $a = 42; a($a)
10:05 camelia rakudo-moar c32d7b: ( no output )
10:05 jnthn m: multi a(int $x) { say "I'm here" }; my int $a = 42; a($a)
10:05 camelia rakudo-moar c32d7b: OUTPUT: «I'm here␤»
10:05 DeadDelta m: multi a(int $x) { }; my $a = 42; a($a)
10:05 camelia rakudo-moar c32d7b: OUTPUT: «Cannot resolve caller a(Int); none of these signatures match:␤    (int $x)␤  in block <unit> at <tmp> line 1␤␤»
10:05 DeadDelta I meant that ^
10:05 DeadDelta m: multi a(int $x) { }; a(42)
10:05 camelia rakudo-moar c32d7b: ( no output )
10:05 jnthn Yes, and that's correct
10:05 DeadDelta and that ^
10:06 jnthn And that is the case that the code I just re-instated is dealing in. :)
10:06 jnthn It's possible there are some inconsistentices in all of this
10:06 DeadDelta So for literals we *do* make them native when we can
10:06 DeadDelta m: multi a(int $x) { }; a(42000000000000000)
10:06 camelia rakudo-moar c32d7b: OUTPUT: «Cannot resolve caller a(Int); none of these signatures match:␤    (int $x)␤  in block <unit> at <tmp> line 1␤␤»
10:06 jnthn Yeah, in sub calls we try to do the analysis
10:06 jnthn Literals are both int/Int
10:06 jnthn Or can be
10:07 jnthn But literals are a compile time concept, not a runtime one
10:07 jnthn By runtime they're all just values
10:07 DeadDelta m: Buf.new((my int $i = 10) +& 0xFF)
10:07 camelia rakudo-moar c32d7b: ( no output )
10:07 astj joined #perl6-dev
10:07 DeadDelta m: my int $i = 2482111348; say $i; $i = $i div 2; say $i
10:07 camelia rakudo-moar c32d7b: OUTPUT: «2482111348␤1241055674␤»
10:07 DeadDelta c: HEAD~10 my int $i = 2482111348; say $i; $i = $i div 2; say $i
10:07 committable6 DeadDelta, ¦HEAD~10: «2482111348␤1241055674»
10:08 Geth ¦ rakudo/nom: a95c70bdab | (Elizabeth Mattijsen)++ | src/core/Nil.pm
10:08 Geth ¦ rakudo/nom: Nil.sink doesn't need any parameters
10:08 Geth ¦ rakudo/nom:
10:08 Geth ¦ rakudo/nom: This allows Nil.sink to be JITted, whereas before it couldn't.
10:08 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a95c70bdab
10:08 DeadDelta Well, looks like the bug pmurias's commit was meant to fix is still fixed.
10:08 DeadDelta At least as far as I remember that bug being.
10:08 jnthn I'm mostly just irked that something so optimization critical got ripped out :/
10:09 DeadDelta Well, it was a misunderstanding I guess.
10:09 jnthn Aye
10:09 jnthn And I added a test now
10:10 lizmat at former $work, we would have graphs on displays showing average response time and so on
10:10 lizmat as soon as that went up significantly, it was red alert
10:10 lizmat sometimes I miss that  :-)
10:14 DeadDelta New post "Perl 6: Seqs, Drugs, And Rock'n'Roll (Part 2)": https://perl6.party/post/Perl-6-Seqs-Drugs-and-Rock-n-Roll--Part-2
10:16 astj joined #perl6-dev
10:17 timotimo yay
10:31 FROGGS joined #perl6-dev
10:33 travis-ci joined #perl6-dev
10:33 travis-ci Rakudo build failed. Elizabeth Mattijsen 'Add R:Q.ADD-SET-TO-MIX'
10:33 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247868474 https://github.com/rakudo/rakudo/compare/c32d7bb8c93e...ce2088776031
10:33 travis-ci left #perl6-dev
10:33 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
10:33 DeadDelta github errors
10:43 Geth ¦ rakudo/nom: 5975005c7e | (Elizabeth Mattijsen)++ | src/core/Any-iterable-methods.pm
10:43 Geth ¦ rakudo/nom: Make all push-all methods have IterationEnd in signature
10:43 Geth ¦ rakudo/nom:
10:43 Geth ¦ rakudo/nom: To make them all consistent, and hopefully be better optimizable.
10:43 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5975005c7e
10:44 lizmat DeadDelta++  # for reminding me
10:45 DeadDelta \o/
10:48 lizmat DeadDelta++   # writing a blog post about Iterators I've been meaning to write for a long time but didn't have the energy for
10:48 DeadDelta :)
10:50 lizmat DeadDelta++  # good blog post  :-)
10:51 DeadDelta Thanks.
10:51 lizmat hoping for some (good) Reddit comments  :-)
10:52 DeadDelta I pre-emptively unchecked the "send replies to my inbox" this time :)
10:55 sivoais joined #perl6-dev
11:01 astj joined #perl6-dev
11:17 lizmat m: use nqp; dd nqp::istype(True,Int)   # jnthn: is this correct ?
11:17 camelia rakudo-moar 597500: OUTPUT: «1␤»
11:20 lizmat m: dd (:e).Bag   # consequence of ^^^
11:20 camelia rakudo-moar 597500: OUTPUT: «("e"=>True).Bag␤»
11:22 travis-ci joined #perl6-dev
11:22 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make all push-all methods have IterationEnd in signature
11:22 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247883881 https://github.com/rakudo/rakudo/compare/a95c70bdab5e...5975005c7e1a
11:22 travis-ci left #perl6-dev
11:22 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
11:24 lizmat m: use nqp; dd nqp::istype(True,Real)   # is this intentional?
11:24 camelia rakudo-moar 597500: OUTPUT: «1␤»
11:25 lizmat m: use nqp; dd nqp::istype(Bool,Real)
11:25 camelia rakudo-moar 597500: OUTPUT: «1␤»
11:27 lizmat m: dd True.Real  # another consequence
11:27 camelia rakudo-moar 597500: OUTPUT: «Bool::True␤»
11:35 lizmat m: my Int $a = True; dd $a  # another weird consequence
11:35 camelia rakudo-moar 597500: OUTPUT: «Bool $a = Bool::True␤»
11:38 jnthn lizmat: Yes, consequence of True being an enum
11:38 jnthn Nothing weird, just the way it is.
11:38 lizmat TIL
11:39 lizmat ah, I remember the days when Bool wasn't a proper Enum yet  :-)
11:40 jnthn Yes, there was lots of "argh make it a proper enum" followed by surprise as the consequences when we finally did :P
11:40 jnthn *at the
11:41 lizmat m: dd True.Real   # this should be 1 though, right jnthn ?
11:41 camelia rakudo-moar 597500: OUTPUT: «Bool::True␤»
11:41 jnthn No
11:41 lizmat no?
11:41 jnthn .Real is a coercion
11:41 jnthn True is already a Real
11:41 lizmat m: dd True.Int ?
11:41 camelia rakudo-moar 597500: OUTPUT: «5===SORRY!5=== Error while compiling <tmp>␤Confused␤at <tmp>:1␤------> 3dd True.Int7⏏5 ?␤    expecting any of:␤        infix␤        infix stopper␤        postfix␤        statement end␤        statement modifier␤        stat…»
11:41 lizmat m: dd True.Int
11:41 camelia rakudo-moar 597500: OUTPUT: «1␤»
11:41 jnthn o.O
11:41 lizmat but Int does coerce ?
11:41 brrt joined #perl6-dev
11:42 FROGGS gpw2017 &
11:42 jnthn m: dd True.Numeric
11:42 camelia rakudo-moar 597500: OUTPUT: «1␤»
11:42 jnthn Hm, Numeric also
11:43 jnthn Ah, maybe on enums those are defined to get the underlying numeric value devoid of the enumtype
11:43 jnthn Yeah, they are
11:43 lizmat because src/core/Bool.pm specifically adds them
11:43 jnthn Oh :S
11:43 jnthn So it's not a general enum behavior?
11:43 lizmat I was about to add Bool.Real for that
11:43 jnthn m: enum Foo <
11:43 camelia rakudo-moar 597500: OUTPUT: «5===SORRY!5=== Error while compiling <tmp>␤Unable to parse expression in quote words; couldn't find final '>'␤        ␤at <tmp>:1␤------> 3enum Foo <7⏏5<EOL>␤    expecting any of:␤        quote words␤»
11:43 jnthn m: enum Foo <Bar Baz>; dd Bar.Int
11:43 camelia rakudo-moar 597500: OUTPUT: «0␤»
11:43 jnthn m: enum Foo <Bar Baz>; dd Bar.Numeric
11:43 camelia rakudo-moar 597500: OUTPUT: «0␤»
11:43 jnthn m: enum Foo <Bar Baz>; dd Bar.Real
11:43 camelia rakudo-moar 597500: OUTPUT: «Foo::Bar␤»
11:44 jnthn It *is* general enum behavior
11:44 jnthn Except Real
11:44 lizmat ok, so I need to fix it there  :-)
11:44 jnthn I suspect that's an oversight, then, given Numeric and Int are handled that way
11:44 jnthn Yeah
11:44 jnthn So long as we have Bool behaving consistent with other enums rather than degenerate behavior because we feel like it, it's OK
11:44 jnthn And yes, that means it's going to
11:45 jnthn type match against Int, Real, and Numeric
11:45 jnthn win 23
11:45 buggable jnthn, Thank you for entering Accidental /win Lottery! The next draw will happen in 2 days, 12 hours, 14 minutes, and 53 seconds
11:45 jnthn gah
11:45 lizmat win 42  /me joins
11:45 lizmat hmmm
11:45 lizmat win 42
11:45 buggable lizmat, Thank you for entering Accidental /win Lottery! The next draw will happen in 2 days, 12 hours, 14 minutes, and 15 seconds
11:45 lizmat whee!
11:54 AlexDaniel joined #perl6-dev
11:55 Geth ¦ rakudo/nom: ad9ed1cba6 | (Elizabeth Mattijsen)++ | src/core/Enumeration.pm
11:55 Geth ¦ rakudo/nom: Make sure we coerce enum.Real correctly
11:55 Geth ¦ rakudo/nom:
11:55 Geth ¦ rakudo/nom: This appears to have been an oversight.
11:55 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ad9ed1cba6
12:09 Geth ¦ rakudo/nom: c226b71ac4 | (Elizabeth Mattijsen)++ | src/core/Bool.pm
12:09 Geth ¦ rakudo/nom: Make sure we Bool.Real also works
12:09 Geth ¦ rakudo/nom:
12:09 Geth ¦ rakudo/nom: Although Bool is an enum, it does not do the Enumeration role, as
12:09 Geth ¦ rakudo/nom: Bool is needed very early in the setting compilation, before the
12:09 Geth ¦ rakudo/nom: Enumeration role even exists.
12:09 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c226b71ac4
12:12 Geth ¦ rakudo/nom: d765f1864e | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
12:12 Geth ¦ rakudo/nom: Make sure R:Q.ADD-PAIRS-TO-(BAG|MIX) coerce Bool
12:12 Geth ¦ rakudo/nom:
12:12 Geth ¦ rakudo/nom: (:e).Bag|Mix would sneak an e => True into the Bag/Mix, rather than
12:12 Geth ¦ rakudo/nom: a e => 1.  This due to the fact that Bool ~~ Int and Bool ~~ Real are
12:12 Geth ¦ rakudo/nom: both True.
12:12 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d765f1864e
12:13 [Coke] jnthn: I hadn't quite gotten to the point of running a linux docker container to see if it failed there. I'm like 99% OS X.
12:17 [Coke] thank you for trying to repro it, though!
12:20 Geth ¦ rakudo/nom: c7922f14c2 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
12:20 Geth ¦ rakudo/nom: Fix outstanding issues with coercions done by (+)
12:20 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c7922f14c2
12:21 jnthn [Coke]: I'm somewhat fearing it's gonna turn out to show up on OSX only
12:21 Geth ¦ roast: 96a400278a | (Elizabeth Mattijsen)++ | S03-operators/addition.t
12:21 Geth ¦ roast: Activate now passing (+) tests
12:21 Geth ¦ roast: review: https://github.com/perl6/roast/commit/96a400278a
12:23 [Coke] wonder if we still have any spectests commented out on OS X.
12:25 lizmat we have some tests that *only* run on OS X  :-)
12:25 * [Coke] just found that one. :|
12:25 travis-ci joined #perl6-dev
12:25 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make sure we coerce enum.Real correctly
12:25 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247905676 https://github.com/rakudo/rakudo/compare/5975005c7e1a...ad9ed1cba617
12:25 travis-ci left #perl6-dev
12:25 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
12:25 * lizmat starts plonking travis
12:57 travis-ci joined #perl6-dev
12:57 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make sure we Bool.Real also works
12:57 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247910904 https://github.com/rakudo/rakudo/compare/ad9ed1cba617...c226b71ac4d6
12:57 travis-ci left #perl6-dev
12:58 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
13:00 DeadDelta just some issues with debian repos
13:01 DeadDelta Wonder if the newfangled "machnine learning" all the cool kids use these days could make buggable learn which travis failures are bogus :)
13:09 lizmat I guess we would need a lot more failures  :-(
13:13 astj joined #perl6-dev
13:20 brrt we'll be happy to oblige
13:34 travis-ci joined #perl6-dev
13:34 travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make sure R:Q.ADD-PAIRS-TO-(BAG|MIX) coerce Bool
13:34 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247911787 https://github.com/rakudo/rakudo/compare/c226b71ac4d6...d765f1864e1d
13:34 travis-ci left #perl6-dev
13:34 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
13:36 Geth ¦ rakudo/nom: b59aad15cb | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
13:36 Geth ¦ rakudo/nom: Add R:Q.ADD-(MAP|OBJECTHASH)-TO-(BAG|MIX)
13:36 Geth ¦ rakudo/nom:
13:36 Geth ¦ rakudo/nom: Worker methods for various set operators / coercions
13:36 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b59aad15cb
13:36 Geth ¦ rakudo/nom: 201a0bfb74 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
13:36 Geth ¦ rakudo/nom: Make Setty (+) Map about 2.5x faster
13:36 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/201a0bfb74
13:40 pmurias joined #perl6-dev
13:42 pmurias shouldn't it be just a buf8 instead of buf8.new here? https://github.com/rakudo/rakudo/blob/nom/src/core/Proc/Async.pm#L332
13:43 [Coke] jnthn: I opened https://rt.perl.org/Ticket/Display.html?id=131670 and could not find your comment about how an enterprising person might fix that in the irclogs.
13:44 lizmat pmurias: feels to me you're right
13:45 lizmat judging by the name of the key
14:13 travis-ci joined #perl6-dev
14:13 travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix outstanding issues with coercions done by (+)'
14:13 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247914280 https://github.com/rakudo/rakudo/compare/d765f1864e1d...c7922f14c23f
14:13 travis-ci left #perl6-dev
14:14 lizmat plonk
14:19 Geth ¦ rakudo/nom: 864fa7298c | (Elizabeth Mattijsen)++ | 3 files
14:19 Geth ¦ rakudo/nom: Merge all -OBJECTHASH- logic into -MAP- logic
14:19 Geth ¦ rakudo/nom:
14:19 Geth ¦ rakudo/nom: So we don't need to test for normal Map/Hash vs objecthashes all of
14:19 Geth ¦ rakudo/nom: the time.  This simplifies a lot of calling code and reduces the total
14:19 Geth ¦ rakudo/nom: number of lines significantly.
14:19 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/864fa7298c
14:45 FROGGS joined #perl6-dev
15:02 jnthn m: say buf8.HOW.^name
15:02 camelia rakudo-moar 864fa7: OUTPUT: «Perl6::Metamodel::CurriedRoleHOW␤»
15:03 jnthn pmurias: The .new is just forcing a punning, but buf8.^pun could do it
15:07 travis-ci joined #perl6-dev
15:07 travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make Setty (+) Map about 2.5x faster'
15:07 travis-ci https://travis-ci.org/rakudo/rakudo/builds/247940177 https://github.com/rakudo/rakudo/compare/c7922f14c23f...201a0bfb7402
15:07 travis-ci left #perl6-dev
15:07 brrt joined #perl6-dev
15:12 perlpilot TIL there's a method called "pun" in the metamodel  (I'd never really thought about it before)
15:18 pmurias jnthn: thanks, I'll add a comment to mention why it's there
15:29 pmurias joined #perl6-dev
15:31 astj joined #perl6-dev
15:35 dogbert2 does anyone have a theory explaining why a random test file hangs when running 'make spectest' or am I the only one getting this?
15:37 DeadDelta the only time it happened to me in the past is when INET tests sit and wait for a connection that failed to happen
15:37 yoleaux 14:06Z <[Coke]> DeadDelta: apparently I need a better system for "did my connection drop"
15:38 dogbert2 on this run the following is hanging: t/spec/S12-meta/exporthow.rakudo.moar
15:38 dogbert2 an attached strace only says: futex(0xeb51eb4, FUTEX_WAIT_PRIVATE, 1, NULL
15:40 * dogbert2 tries a complete rebuild
15:41 * TimToady is testing with 6 jobs
15:42 * dogbert2 TimToady obviously has more core than me ..
15:42 dogbert2 *cores
15:44 * jnthn uses 16
15:44 jnthn (TEST_JOBS=16, that is)
15:44 jnthn (box is 6 cores, 12 virtual)
15:45 * dogbert2 has a Ryzen 1600 waiting for him at the local computer store :)
15:45 jnthn I did see a hanging run not so long back.
15:45 jnthn But a re-run was fine
15:45 jnthn I guess if others are seeing it, it wasn't some one-off relating to a local change
15:46 dogbert2 am rerunning now
15:46 dogbert2 will take time since I only have two cores available in my vm
15:48 dogbert2 according to the processlist it seems as if t/spec/S10-packages/precompilation.rakudo.moar is taking way too long
15:49 * dogbert2 contemplates how to debug this
15:51 brrt left #perl6-dev
15:51 dogbert2 pfft, it's hanging, running with TEST_JOBS=3, hmm
15:54 TimToady no hang this time (I got one a day or two ago though)
15:54 TimToady I did get a transient fail of t/spec/S11-modules/nested.t this time
15:54 jnthn Hmm
15:55 jnthn nested.t transient failures I think I've been seeing for a month plus
15:56 TimToady my hang the other day was in t/spec/S17-procasync/encoding.t
15:57 lizmat dinner&
16:00 * jnthn gets a build with debug symbols and sees if he can get anything to hang
16:02 * jnthn gets a hang in t/spec/S17-procasync/no-runaway-file-limit.t
16:02 dogbert2 oO jnthn++
16:10 jnthn Hm, no threads are doing anything at all
16:10 jnthn And the main thread is blocked at the `await $p` of that test file on line 14
16:11 TimToady my hang the other day was using no cpu, fwiw
16:12 dogbert2 in my last run all three TEST_JOBS hung the entire spectest was doing absolutely nothing
16:12 jnthn I wonder if somewhere in the recent bunch of Proc::Async improvements we ended up with a deprovement
16:13 dogbert2 how do we figure that one out?
16:13 jnthn I dunno :)
16:13 jnthn But the surface area can't be all that big
16:14 jnthn In that the no-runaway-file-limit.t isn't using stdout/stderr, just stdin
16:16 dogbert2 should these test files be susceptible to hangs if they're run standalone as well?
16:17 jnthn In theory yes
16:17 jnthn Well
16:17 jnthn This particular one I got to hang, yes
16:18 jnthn With higher likelihood than others, I'd say
16:18 jnthn I haven't managed to get it to hang on its own yet, alas
16:19 jnthn Maybe I can put it under some more stress :)
16:20 jnthn Hm, it seems not easily
16:21 dogbert2 heh, the same file is hanging for me now
16:21 astj joined #perl6-dev
16:22 dogbert2 attaching gdb and looking at the threads I se this, dunno if it's useful though
16:22 dogbert2 spam warning
16:22 dogbert2 (gdb) t 3
16:22 dogbert2 [Switching to thread 3 (Thread 0x44852b40 (LWP 29028))]
16:22 dogbert2 #0  0x40024cb0 in ?? ()
16:22 dogbert2 (gdb) l
16:22 dogbert2 140     int flag;
16:22 dogbert2 141
16:22 dogbert2 142     unsigned int interval_id;
16:22 dogbert2 143
16:22 dogbert2 144     for (; (flag = parse_flag(argv[argi])) != NOT_A_FLAG; ++argi) {
16:22 dogbert2 145         switch (flag) {
16:22 dogbert2 146             case FLAG_CRASH:
16:22 dogbert2 147             MVM_crash_on_error();
16:22 dogbert2 148             continue;
16:23 jnthn o.O
16:23 jnthn That's code from main.c
16:23 jnthn Which thread 3 is never on
16:23 timotimo i assume the list is b0rked because the frame is "in ?? ()"
16:23 jnthn Yeah, I think so
16:24 jnthn bah, I got it to run the code in that test on 8 concurrent workers
16:24 timotimo i haven't figured it out exactly, but it'll just give you "whatever" code it thinks is fun to look at when it can't figure out the right code
16:24 jnthn Completed without hanging once
16:24 dogbert2 aha the other threads I've looked at so far were near code which looked like
16:24 dogbert2 124 int wmain(int argc, wchar_t *wargv[])
16:24 dogbert2 125 #endif
16:24 dogbert2 126 {
16:24 dogbert2 127     MVMInstance *instance;
16:24 dogbert2 128     const char  *input_file;
16:24 timotimo yeah, that's very unlikely
16:24 jnthn That also seems very bogus
16:25 timotimo as jnthn said, the threads get started at some internal function, they never go through any of the main functions
16:25 jnthn hah, OK, I got it to hang by trying to run 16 threads at a time
16:26 jnthn oh wait, that may be bogus though
16:26 jnthn Hah, yeah, it'll mean none are free to actually handle incoming events
16:26 * jnthn goes for 12
16:28 jnthn oh wait, it does tap stdout
16:28 jnthn I misread the test
16:31 TimToady transient failures in S11-modules/require.t and S17-supply/interval.t this time
16:31 TimToady but no hangs
16:32 jnthn ah, I might spot a race
16:35 * jnthn tries a fix for it
16:35 jnthn Well, to the degree I can when the only repro I have is "occasional spectest hangs"...
16:36 dogbert2 it's a start at least :)
16:37 TimToady hmm, does the harness have any kind of timeout that might be making some hangs look like transient failures if the test runs early enough?
16:37 dogbert2 attacking it with valgrind produces the occasional invalid read
16:38 TimToady (my impression is that there are no such timeouts)
16:38 jnthn TimToady: no
16:38 jnthn Well, first run was fine
16:40 jnthn And a second
16:41 TimToady .oO(it boots twice, ship it)
16:45 jnthn And a third was good
16:45 jnthn Forth running now
16:45 astj joined #perl6-dev
16:46 jnthn Well, here we go
16:46 Geth ¦ rakudo/nom: 2a8d1e7ce9 | (Jonathan Worthington)++ | src/core/Proc/Async.pm
16:46 Geth ¦ rakudo/nom: Fix a data race in Proc::Async.
16:46 Geth ¦ rakudo/nom:
16:46 Geth ¦ rakudo/nom: It is possible that the ready callback of the process will fire before
16:46 Geth ¦ rakudo/nom: the code that binds the async process handle into `$!process_handle`
16:46 Geth ¦ rakudo/nom: gets to run. This can happen if the thread that initiates the async
16:46 Geth ¦ rakudo/nom: process call is suspended very soon after it has done so, and then
16:46 Geth ¦ rakudo/nom: another thread gets the ready message. The result was that the permit
16:46 Geth ¦ rakudo/nom: issuing code would run without `$!process_handle` being bound, and so
16:46 Geth ¦ rakudo/nom: it would never issue the emit permit, and there would therefore be a
16:46 Geth ¦ rakudo/nom: deadlock because the stdout and/or stderr handles were never read.
16:46 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2a8d1e7ce9
16:48 timotimo fascinating
16:48 jnthn It's one of those "what are the chances" things
16:48 jnthn Turns out, pretty low, but if you load the system up with spectests... :)
16:49 dogbert2 will try it out after compilation is done ...
16:50 * dogbert2 parse dammit
16:52 * dogbert2 Stage parse      :  94.123   :(
16:52 timotimo --optimize=0? :)
16:52 timotimo (in moar's configure.pl, i mean)
16:53 dogbert2 more like using 2010 vintage hardware
16:55 dogbert2 t/spec/S03-operators/mix.t generates mixed results :)
16:57 robertle joined #perl6-dev
17:06 dogbert2 jnthn++, your fix seems to do the trick
17:52 * DeadDelta reads https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html
17:53 DeadDelta While we don't got a budget to send contributors to confs, would be cool to have a RoadMap for the year. https://blog.rust-lang.org/2017/02/06/roadmap.html
17:53 DeadDelta https://github.com/rust-lang/rust-roadmap
17:58 DeadDelta And one theme I notice in rust's blogs and stuff is positivity. "We were pleasantly surprised ...." under a graph that I would've called ain't that pretty.
17:59 DeadDelta Lots of stuff here applies to us as well: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html
18:00 DeadDelta .oO( Perl 6 Starter Kit... )
18:10 AlexDaniel joined #perl6-dev
18:18 FROGGS joined #perl6-dev
18:50 FROGGS_ joined #perl6-dev
18:52 MasterDuke joined #perl6-dev
19:57 astj joined #perl6-dev
19:57 astj joined #perl6-dev
20:10 lizmat joined #perl6-dev
22:11 AlexDaniel joined #perl6-dev
22:20 stmuk joined #perl6-dev
22:39 BenGoldberg joined #perl6-dev
22:40 AlexDaniel joined #perl6-dev
22:48 AlexDaniel joined #perl6-dev
22:50 AlexDaniel joined #perl6-dev

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