DeadDelta [Coke]: you could also try putting the `use lib` *before* you use any modules 00:00
timotimo that's a good idea in general 00:01
i've reached P in "writing type document" 00:03
[Coke] ugexe: -I. still segvs. 00:08
DeadDelta: yup, that fixed it
BenGoldberg timotimo, "writing typ" ? 00:09
timotimo hehe 00:10
[Coke] ... ok, now it segfaults at the end. :P 00:15
[Tux] This is Rakudo version 2017.06-90-g9a2127f2b built on MoarVM version 2017.06-30-g389e9732 05:56
csv-ip5xs 2.875
test 13.013
test-t 3.999 - 4.024
csv-parser 13.940
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 08:59
Gah, when did my int $a = 1; for ^10000 { $a = $a + 1 } stop inlining the + :/ 09:05
llfourn wonders how we can stop regressions like that from happening 09:06
jnthn I'm going to add a test that obtains --target=optimize output and greps it :)
(In the rakudo set of tests) 09:07
llfourn sounds good to me :)
jnthn I know that was going to be some cleanup of multi/native semantics but...it should not have broken this :/
argh 09:08
Yes it removed the special-casing of compile-time constants :/
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
But I didn't realize it was going to rip *this* out :/
jnthn finds what's probalby the guiltiy commit, reverts, tests 09:13
I thought some odd inconsistency was being cleared up
Not ripping out the optimization around literals 09:14
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.
Geth rakudo/nom: 1c0ed61a44 | (Jonathan Worthington)++ | 2 files
Revert "Stop the optimizer from using what I assume are old semantics for multi dispatch"

This reverts commit ccfa5e51a21f5a613ecb0cfb24be6c15f4103752. The semantics it removed were not old. They were a special case analysis of the use of literals in combination with known native types, to allow native candidates to be called. The reverted commit may have been intended to fix some inconsistency (which is what I thought was happening), but in fact the code it removed is critical for good performance.		 09:24
rakudo/nom: c32d7bb8c9 | (Jonathan Worthington)++ | t/02-rakudo/08-inline-native-arith.t
Add test to ensure we don't bust native inlines.

This was broken a little while back, causing a huge regression in native integer performance. This test will help to catch such cases.
roast: f8c706da4a | (Jonathan Worthington)++ | S06-multi/type-based.t
Update test for multi literal semantics.
jnthn Now I wonder exactly what inconsistency was originally being fixed, but there aren't really tests to tell me. 09:25
I guess for now we'll enjoy the better performance and we'll see if something re-surfaces. :)
lizmat Files=1208, Tests=63399, 223 wallclock secs (13.19 usr 5.09 sys + 1348.42 cusr 137.31 csys = 1504.01 CPU) 09:47
before the last fix ^^^ 09:48
Geth rakudo/nom: ce20887760 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Add R:Q.ADD-SET-TO-MIX
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:02
DeadDelta The discussion was this 10:03
huggable: native
huggable DeadDelta, here's a ticket: rt.perl.org/Ticket/Display.html?id...xn-1433016 and here's explanation why it isn't: irclog.perlgeek.de/perl6-dev/2016-...i_13462673
DeadDelta And the answer was we don't native dispatch to multies, so pmurias tossed it 10:04
jnthn :/
timotimo irclog.perlgeek.de/perl6-dev/2016-...i_13462673 - here's that discussion
ah
already posted, i see
jnthn We *do* hative dispatch to multis though
m: multi a(int $x) { }; my int $a = 42; a($a) 10:05
camelia ( no output )
jnthn m: multi a(int $x) { say "I'm here" }; my int $a = 42; a($a)
camelia I'm here
DeadDelta m: multi a(int $x) { }; my $a = 42; a($a)
camelia Cannot resolve caller a(Int); none of these signatures match:
(int $x)
in block <unit> at <tmp> line 1
DeadDelta I meant that ^
m: multi a(int $x) { }; a(42)
camelia ( no output )
jnthn Yes, and that's correct
DeadDelta and that ^
jnthn And that is the case that the code I just re-instated is dealing in. :) 10:06
It's possible there are some inconsistentices in all of this
DeadDelta So for literals we *do* make them native when we can
m: multi a(int $x) { }; a(42000000000000000)
camelia Cannot resolve caller a(Int); none of these signatures match:
(int $x)
in block <unit> at <tmp> line 1
jnthn Yeah, in sub calls we try to do the analysis
Literals are both int/Int
Or can be
But literals are a compile time concept, not a runtime one 10:07
By runtime they're all just values
DeadDelta m: Buf.new((my int $i = 10) +& 0xFF)
camelia ( no output )
DeadDelta m: my int $i = 2482111348; say $i; $i = $i div 2; say $i
camelia 2482111348
1241055674
DeadDelta c: HEAD~10 my int $i = 2482111348; say $i; $i = $i div 2; say $i
committable6 DeadDelta, Ā¦HEAD~10: Ā«2482111348ā¤1241055674Ā»
Geth rakudo/nom: a95c70bdab | (Elizabeth Mattijsen)++ | src/core/Nil.pm
Nil.sink doesn't need any parameters

This allows Nil.sink to be JITted, whereas before it couldn't.		 10:08
DeadDelta Well, looks like the bug pmurias's commit was meant to fix is still fixed.
At least as far as I remember that bug being.
jnthn I'm mostly just irked that something so optimization critical got ripped out :/
DeadDelta Well, it was a misunderstanding I guess. 10:09
jnthn Aye
And I added a test now
lizmat at former $work, we would have graphs on displays showing average response time and so on 10:10
as soon as that went up significantly, it was red alert
sometimes I miss that :-)
DeadDelta New post "Perl 6: Seqs, Drugs, And Rock'n'Roll (Part 2)": perl6.party/post/Perl-6-Seqs-Drugs...ll--Part-2 10:14
timotimo yay 10:17
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Add R:Q.ADD-SET-TO-MIX' 10:33
travis-ci.org/rakudo/rakudo/builds/247868474 github.com/rakudo/rakudo/compare/c...2088776031
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually.
DeadDelta github errors
Geth rakudo/nom: 5975005c7e | (Elizabeth Mattijsen)++ | src/core/Any-iterable-methods.pm
Make all push-all methods have IterationEnd in signature

To make them all consistent, and hopefully be better optimizable.		 10:43
lizmat DeadDelta++ # for reminding me 10:44
DeadDelta \o/ 10:45
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 :)
lizmat DeadDelta++ # good blog post :-) 10:50
DeadDelta Thanks. 10:51
lizmat hoping for some (good) Reddit comments :-)
DeadDelta I pre-emptively unchecked the "send replies to my inbox" this time :) 10:52
lizmat m: use nqp; dd nqp::istype(True,Int) # jnthn: is this correct ? 11:17
camelia 1
lizmat m: dd (:e).Bag # consequence of ^^^ 11:20
camelia ("e"=>True).Bag
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make all push-all methods have IterationEnd in signature 11:22
travis-ci.org/rakudo/rakudo/builds/247883881 github.com/rakudo/rakudo/compare/a...75005c7e1a
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually.
lizmat m: use nqp; dd nqp::istype(True,Real) # is this intentional? 11:24
camelia 1
lizmat m: use nqp; dd nqp::istype(Bool,Real) 11:25
camelia 1
lizmat m: dd True.Real # another consequence 11:27
camelia Bool::True
lizmat m: my Int $a = True; dd $a # another weird consequence 11:35
camelia Bool $a = Bool::True
jnthn lizmat: Yes, consequence of True being an enum 11:38
Nothing weird, just the way it is.
lizmat TIL
ah, I remember the days when Bool wasn't a proper Enum yet :-) 11:39
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
*at the
lizmat m: dd True.Real # this should be 1 though, right jnthn ? 11:41
camelia Bool::True
jnthn No
lizmat no?
jnthn .Real is a coercion
True is already a Real
lizmat m: dd True.Int ?
camelia 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ā€¦
lizmat m: dd True.Int
camelia 1
jnthn o.O
lizmat but Int does coerce ?
FROGGS gpw2017 & 11:42
jnthn m: dd True.Numeric
camelia 1
jnthn Hm, Numeric also
Ah, maybe on enums those are defined to get the underlying numeric value devoid of the enumtype 11:43
Yeah, they are
lizmat because src/core/Bool.pm specifically adds them
jnthn Oh :S
So it's not a general enum behavior?
lizmat I was about to add Bool.Real for that
jnthn m: enum Foo <
camelia 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
jnthn m: enum Foo <Bar Baz>; dd Bar.Int
camelia 0
jnthn m: enum Foo <Bar Baz>; dd Bar.Numeric
camelia 0
jnthn m: enum Foo <Bar Baz>; dd Bar.Real
camelia Foo::Bar
jnthn It *is* general enum behavior 11:44
Except Real
lizmat ok, so I need to fix it there :-)
jnthn I suspect that's an oversight, then, given Numeric and Int are handled that way
Yeah
So long as we have Bool behaving consistent with other enums rather than degenerate behavior because we feel like it, it's OK
And yes, that means it's going to
type match against Int, Real, and Numeric 11:45
win 23
buggable jnthn, Thank you for entering Accidental /win Lottery! The next draw will happen in 2 days, 12 hours, 14 minutes, and 53 seconds
jnthn gah
lizmat win 42 /me joins
hmmm
win 42
buggable lizmat, Thank you for entering Accidental /win Lottery! The next draw will happen in 2 days, 12 hours, 14 minutes, and 15 seconds
lizmat whee!
Geth rakudo/nom: ad9ed1cba6 | (Elizabeth Mattijsen)++ | src/core/Enumeration.pm
Make sure we coerce enum.Real correctly

This appears to have been an oversight.		 11:55
rakudo/nom: c226b71ac4 | (Elizabeth Mattijsen)++ | src/core/Bool.pm
Make sure we Bool.Real also works

Although Bool is an enum, it does not do the Enumeration role, as Bool is needed very early in the setting compilation, before the Enumeration role even exists.		 12:09
rakudo/nom: d765f1864e | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Make sure R:Q.ADD-PAIRS-TO-(BAG|MIX) coerce Bool

  (:e).Bag|Mix would sneak an e => True into the Bag/Mix, rather than
a e => 1. This due to the fact that Bool ~~ Int and Bool ~~ Real are both True.		 12:12
[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:13
thank you for trying to repro it, though! 12:17
Geth rakudo/nom: c7922f14c2 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Fix outstanding issues with coercions done by (+)
 12:20
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
Activate now passing (+) tests
[Coke] wonder if we still have any spectests commented out on OS X. 12:23
lizmat we have some tests that *only* run on OS X :-) 12:25
[Coke] just found that one. :|
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make sure we coerce enum.Real correctly
travis-ci.org/rakudo/rakudo/builds/247905676 github.com/rakudo/rakudo/compare/5...9ed1cba617
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually.
lizmat starts plonking travis
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make sure we Bool.Real also works 12:57
travis-ci.org/rakudo/rakudo/builds/247910904 github.com/rakudo/rakudo/compare/a...26b71ac4d6
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually. 12:58
DeadDelta just some issues with debian repos 13:00
Wonder if the newfangled "machnine learning" all the cool kids use these days could make buggable learn which travis failures are bogus :) 13:01
lizmat I guess we would need a lot more failures :-( 13:09
brrt we'll be happy to oblige 13:20
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make sure R:Q.ADD-PAIRS-TO-(BAG|MIX) coerce Bool 13:34
travis-ci.org/rakudo/rakudo/builds/247911787 github.com/rakudo/rakudo/compare/c...65f1864e1d
buggable [travis build above] ā˜  Did not recognize some failures. Check results manually.
Geth rakudo/nom: b59aad15cb | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Add R:Q.ADD-(MAP|OBJECTHASH)-TO-(BAG|MIX)

Worker methods for various set operators / coercions		 13:36
rakudo/nom: 201a0bfb74 | (Elizabeth Mattijsen)++ | src/core/set_operators.pm
Make Setty (+) Map about 2.5x faster
pmurias shouldn't it be just a buf8 instead of buf8.new here? github.com/rakudo/rakudo/blob/nom/...nc.pm#L332 13:42
[Coke] jnthn: I opened 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:43
lizmat pmurias: feels to me you're right 13:44
judging by the name of the key 13:45
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Fix outstanding issues with coercions done by (+)' 14:13
travis-ci.org/rakudo/rakudo/builds/247914280 github.com/rakudo/rakudo/compare/d...922f14c23f
lizmat plonk 14:14
Geth rakudo/nom: 864fa7298c | (Elizabeth Mattijsen)++ | 3 files
Merge all -OBJECTHASH- logic into -MAP- logic

So we don't need to test for normal Map/Hash vs objecthashes all of the time. This simplifies a lot of calling code and reduces the total number of lines significantly.		 14:19
jnthn m: say buf8.HOW.^name 15:02
camelia Perl6::Metamodel::CurriedRoleHOW
jnthn pmurias: The .new is just forcing a punning, but buf8.^pun could do it 15:03
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make Setty (+) Map about 2.5x faster' 15:07
travis-ci.org/rakudo/rakudo/builds/247940177 github.com/rakudo/rakudo/compare/c...1a0bfb7402
perlpilot TIL there's a method called "pun" in the metamodel (I'd never really thought about it before) 15:12
pmurias jnthn: thanks, I'll add a comment to mention why it's there 15:18
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:35
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"
dogbert2 on this run the following is hanging: t/spec/S12-meta/exporthow.rakudo.moar 15:38
an attached strace only says: futex(0xeb51eb4, FUTEX_WAIT_PRIVATE, 1, NULL
dogbert2 tries a complete rebuild 15:40
TimToady is testing with 6 jobs 15:41
dogbert2 TimToady obviously has more core than me .. 15:42
*cores
jnthn uses 16 15:44
(TEST_JOBS=16, that is)
(box is 6 cores, 12 virtual)
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.
But a re-run was fine
I guess if others are seeing it, it wasn't some one-off relating to a local change
dogbert2 am rerunning now 15:46
will take time since I only have two cores available in my vm
according to the processlist it seems as if t/spec/S10-packages/precompilation.rakudo.moar is taking way too long 15:48
dogbert2 contemplates how to debug this 15:49
pfft, it's hanging, running with TEST_JOBS=3, hmm 15:51
TimToady no hang this time (I got one a day or two ago though) 15:54
I did get a transient fail of t/spec/S11-modules/nested.t this time
jnthn Hmm
nested.t transient failures I think I've been seeing for a month plus 15:55
TimToady my hang the other day was in t/spec/S17-procasync/encoding.t 15:56
lizmat dinner& 15:57
jnthn gets a build with debug symbols and sees if he can get anything to hang 16:00
jnthn gets a hang in t/spec/S17-procasync/no-runaway-file-limit.t 16:02
dogbert2 oO jnthn++
jnthn Hm, no threads are doing anything at all 16:10
And the main thread is blocked at the `await $p` of that test file on line 14
TimToady my hang the other day was using no cpu, fwiw 16:11
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
dogbert2 how do we figure that one out? 16:13
jnthn I dunno :)
But the surface area can't be all that big
In that the no-runaway-file-limit.t isn't using stdout/stderr, just stdin 16:14
dogbert2 should these test files be susceptible to hangs if they're run standalone as well? 16:16
jnthn In theory yes 16:17
Well
This particular one I got to hang, yes
With higher likelihood than others, I'd say 16:18
I haven't managed to get it to hang on its own yet, alas
Maybe I can put it under some more stress :) 16:19
Hm, it seems not easily 16:20
dogbert2 heh, the same file is hanging for me now 16:21
attaching gdb and looking at the threads I se this, dunno if it's useful though 16:22
spam warning
(gdb) t 3
[Switching to thread 3 (Thread 0x44852b40 (LWP 29028))]
#0 0x40024cb0 in ?? ()
(gdb) l
140 int flag;
141
142 unsigned int interval_id;
143
144 for (; (flag = parse_flag(argv[argi])) != NOT_A_FLAG; ++argi) {
145 switch (flag) {
146 case FLAG_CRASH:
147 MVM_crash_on_error();
148 continue;
jnthn o.O 16:23
That's code from main.c
Which thread 3 is never on
timotimo i assume the list is b0rked because the frame is "in ?? ()"
jnthn Yeah, I think so
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
jnthn Completed without hanging once
dogbert2 aha the other threads I've looked at so far were near code which looked like
124 int wmain(int argc, wchar_t *wargv[])
125 #endif
126 {
127 MVMInstance *instance;
128 const char *input_file;
timotimo yeah, that's very unlikely
jnthn That also seems very bogus
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
oh wait, that may be bogus though 16:26
Hah, yeah, it'll mean none are free to actually handle incoming events
jnthn goes for 12
oh wait, it does tap stdout 16:28
I misread the test
TimToady transient failures in S11-modules/require.t and S17-supply/interval.t this time 16:31
but no hangs
jnthn ah, I might spot a race 16:32
jnthn tries a fix for it 16:35
Well, to the degree I can when the only repro I have is "occasional spectest hangs"...
dogbert2 it's a start at least :) 16:36
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
TimToady (my impression is that there are no such timeouts) 16:38
jnthn TimToady: no
Well, first run was fine
And a second 16:40
TimToady
.oO(it boots twice, ship it)
 16:41
jnthn And a third was good 16:45
Forth running now
Well, here we go 16:46
Geth rakudo/nom: 2a8d1e7ce9 | (Jonathan Worthington)++ | src/core/Proc/Async.pm
Fix a data race in Proc::Async.

It is possible that the ready callback of the process will fire before the code that binds the async process handle into `$!process_handle` gets to run. This can happen if the thread that initiates the async process call is suspended very soon after it has done so, and then another thread gets the ready message. The result was that the permit issuing code would run without `$!process_handle` being bound, and so it would never issue the emit permit, and there would therefore be a deadlock because the stdout and/or stderr handles were never read.
timotimo fascinating 16:48
jnthn It's one of those "what are the chances" things
Turns out, pretty low, but if you load the system up with spectests... :)
dogbert2 will try it out after compilation is done ... 16:49
dogbert2 parse dammit 16:50
dogbert2 Stage parse : 94.123 :( 16:52
timotimo --optimize=0? :)
(in moar's configure.pl, i mean)
dogbert2 more like using 2010 vintage hardware 16:53
t/spec/S03-operators/mix.t generates mixed results :) 16:55
jnthn++, your fix seems to do the trick 17:06
DeadDelta reads blog.rust-lang.org/2017/06/27/Incr...Reach.html 17:52
While we don't got a budget to send contributors to confs, would be cool to have a RoadMap for the year. blog.rust-lang.org/2017/02/06/roadmap.html 17:53
github.com/rust-lang/rust-roadmap
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:58
Lots of stuff here applies to us as well: blog.rust-lang.org/2016/06/30/Stat...-2016.html 17:59
.oO( Perl 6 Starter Kit... )
 18:00

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!