travis-ci Rakudo build passed. Zoffix Znet 'Add fudged tests for restrictive protos 00:46
travis-ci.org/rakudo/rakudo/builds/369361601 github.com/rakudo/rakudo/compare/4...ccaccad7b6
Zoffix oh, we also need to make protos named-slurpy 01:00
m: say 275/349 01:02
camelia 0.787966
Zoffix 79% of protos are wrong 01:03
ZofBot: brew some coffee; it's gunna be a long night
ZofBot Zoffix, which is both more expensive to keep track of and can introduce bugs when behavior is attached to the wrong aspect (which iirc is one perl 6 has run into) but if someone can figure out a way to make the generic case better, i'd 100% be fine with removing those special cases MasterDuke: do you know
Zoffix weird that some core multies ain't got no protos 02:41
&prompt, &undefine, &warn
s: &warn
SourceBaby Zoffix, Sauce is at github.com/rakudo/rakudo/blob/20cc...l.pm6#L186
Zoffix that ain't a proto 02:42
samcv releasable6: status 03:22
releasable6 samcv, Next release in ≈15 hours. 3 blockers. 224 out of 247 commits logged
samcv, Details: gist.github.com/2f13e3eb681dade3dd...bf87dc577b
Zoffix .... mf... 03:43
A single test doesn't let me experience a dopamine boost.
For some reason tells me the proto for &postcircumfix:<{ }> got a Mu param, when it doesn't :S 03:44
oh, I'm not reading the results right 03:45
All tests successful. 03:50
Files=1, Tests=352, 1 wallclock secs ( 0.06 usr 0.01 sys + 1.34 cusr 0.25 csys = 1.66 CPU)
Oh yes...
ZofBot: this is better than cocaine!
ZofBot turns more for loops into loop loops
Zoffix shit looks like the profiler doesn't like more specific protos :| 04:06
`my int $i = 1; say $i * 2` that used to be optimized to `mul_i`, now it's just callstatic of infix:<*> 04:08
m: proto z(|) {*}; multi z($) {}; z Mu 04:19
camelia Cannot resolve caller z(Mu); none of these signatures match:
($)
in block <unit> at <tmp> line 1
Zoffix m: proto z($) {*}; multi z($) {}; z Mu
camelia Type check failed in binding to parameter '<anon>'; expected Any but got Mu (Mu)
in block <unit> at <tmp> line 1
Zoffix Some tests are failing due to this :(
:| and t/spec/S02-types/array.t t/spec/S02-types/hash.t t/spec/S06-multi/type-based.t fail during stresstest but succeed by themselves 04:29
:/ 04:36
Might've been something with my `./perl6` missing and t/fudgeandrun defauling to `perl6` in those cases.
m: multi foo (Regex $bar) { "Regex " ~ gist(WHAT( $bar )) } 04:44
camelia ( no output )
Zoffix this now fails. Tells me Calling gist(Mu) will never work with any of these multi signatures:
()
at -e:1
Without even calling that multi
There's no way I'm shipping this into the release
$ ./perl6 -e 'multi foo ($bar) { gist $bar }; foo "x"' 04:50
Too many positionals passed; expected 0 arguments but got 1
... wat :S
oh.. luckily this is my fuckup. gist() has wrong sig and instead it pokes into p6argvmarray 04:52
oh it does has proper sig, I just messed it up :D 05:00
Geth roast/proto-fix-R1739: 0faa97adf8 | (Zoffix Znet)++ | packages/Test/Util.pm
Implement throws-like-any helper routine

Same as throws-like but checks the exception among possibilities		 05:59
roast/proto-fix-R1739: d35c12e39f | (Zoffix Znet)++ | S32-list/sort.t
Test .sort doesn't crash with &lc

Covers github.com/rakudo/rakudo/issues/1739		 06:00
roast/proto-fix-R1739: 16594c6187 | (Zoffix Znet)++ | 2 files
Loosen no-multi tests for Mu.[]/Mu.{}

The tests test there's no candidate to handle the Mu, but testing for X::Multi::NoMatch is too strict a restriction.
Allow X::TypeCheck::Binding::Parameter to be thrown as well in those cases.		 06:03
rakudo/proto-fix-R1739: 105bc34259 | (Zoffix Znet)++ | t/02-rakudo/12-proto-arity-count.t
Expand proto narrowness tests

  - Unfudge
  - Test proto Mu args match the candidates
  - Add more candidates that didn't have protos		 06:05
rakudo/proto-fix-R1739: a3a7c142a4 | (Zoffix Znet)++ | t/02-rakudo/08-inline-native-arith.t
Temp-fudge mul_i opt test
 06:06
rakudo/proto-fix-R1739: 4b5d36f3a8 | (Zoffix Znet)++ | 37 files
Fix up proto .arity/.count for all core multi subs

Fixes github.com/rakudo/rakudo/issues/1739
THIS COMMIT HAS REGRESSION IN OPTIMIZATION of rewriting stuff like `*` with natives to `mul_i`. That still needs to be looked at. ... (10 more lines)		 06:11
Zoffix has trouble finding where infix:<*> is being rewritten to mul_i 06:22
ZofBot: If you tell me where the opt is at now, that'll be the end of it. I will not look for you, I will not pursue you. But if you don't, I will look for you, I will find you, and I will kill you. 06:55
ZofBot Zoffix, Then Mrs
Zoffix Looks like the reason I can't find it is 'cause it's actually being rewritten in NQP land. 07:43
A puzzle for past-powerdown-period. 07:44
.tell AlexDaniel FWIW R#1739 is already fixed in a branch but the fix disables at least one native math op optimizations and (very likely more if not all of them). Looks like the opt is in nqp's repo and I'm guessing the old opt that takes care of slurpy capture needs to be taught the same trick with named slurpy. Gonna take a look at it after sleeping. I think that's the only real release blocker left. 08:08
yoleaux Zoffix: I'll pass your message to AlexDaniel.
synopsebot R#1739 [open]: github.com/rakudo/rakudo/issues/1739 [⚠ blocker ⚠] Unintended consequences of converting routines from `only` to `multi`
AlexDaniel OK 08:31
yoleaux 08:08Z <Zoffix> AlexDaniel: FWIW R#1739 is already fixed in a branch but the fix disables at least one native math op optimizations and (very likely more if not all of them). Looks like the opt is in nqp's repo and I'm guessing the old opt that takes care of slurpy capture needs to be taught the same trick with named slurpy. Gonna take a look at it after sleeping. I think that's the only real release blocker left.
synopsebot R#1739 [open]: github.com/rakudo/rakudo/issues/1739 [⚠ blocker ⚠] Unintended consequences of converting routines from `only` to `multi`
AlexDaniel Thank you 08:32
yes indeed it's the last blocker blocker
Geth rakudo: 8f3237c28d | (Stefan Seifert)++ | 3 files
Add gist methods to AbsolutePath, NQP and Perl6 repositories

This gives much more uniform and less confusing output on:
  .say for $*REPO.repo-chain
Should have done this years ago...		 08:54
nqp: 888e05af83 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/MOAR_REVISION
[MoarVM Bump] 05d589e5c fix confused pointer o […]

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g05d589e5c		 12:52
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...g05d589e5c
rakudo: 1c6701b92a | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/build/NQP_REVISION
[NQP Bump] 888e05af8 [MoarVM Bump] 05d589e5c f […]

NQP bump brought: github.com/perl6/nqp/compare/2018....g888e05af8
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....g888e05af8
¦ rakudo: AlexDaniel self-assigned Toaster results show several modules' tests rely on buggy Num stringification github.com/rakudo/rakudo/issues/1736 13:00
AlexDaniel bisect: subset ZInt of Cool where { $_ == $_}; sub foo(ZInt(Cool) $Z) { }; say 42 15:02
bisectable6 AlexDaniel, Bisecting by output (old=2015.12 new=1c6701b) because on both starting points the exit code is 0
AlexDaniel, bisect log: gist.github.com/ad987cd9dd12118454...70d5918f80
AlexDaniel, (2018-04-04) github.com/rakudo/rakudo/commit/82...e6a4af9493
AlexDaniel c: 2018.03,HEAD subset ZInt of Cool where { $_ == $_}; sub foo(ZInt(Cool) $Z) { }; say 42
committable6 AlexDaniel, ¦2018.03: «42␤» ¦HEAD(1c6701b): «Use of uninitialized value of type Iterable in numeric context␤42␤ in block at /tmp/k5k131IdHV line 1␤Use of uninitialized value of type Iterable in numeric context␤ in block at /tmp/k5k131IdHV line 1␤»
AlexDaniel c: 82b19b1f^,82b19b1f subset ZInt of Cool where { $_ == $_}; sub foo(ZInt(Cool) $Z) { }; say 42 15:03
committable6 AlexDaniel, ¦82b19b1f^: «42␤» ¦82b19b1: «Use of uninitialized value of type Iterable in numeric context␤42␤ in block at /tmp/Ks3uwul4GB line 1␤Use of uninitialized value of type Iterable in numeric context␤ in block at /tmp/Ks3uwul4GB line 1␤»
AlexDaniel I'm afk for shower, but this ↑ is why a module is failing github.com/briandfoy/perl6-chemistry-elements
c: 2018.03,HEAD subset ZInt of Cool where { say $_; True }; sub foo(ZInt(Cool) $Z) {} 16:07
committable6 AlexDaniel, ¦2018.03: «» ¦HEAD(1c6701b): «(Iterable)␤»
AlexDaniel that looks wrong
Zoffix bisect: 2018.03,HEAD subset ZInt of Cool where { say $_; True }; sub foo(ZInt(Cool) $Z) {} 16:18
bisectable6 Zoffix, Using old=2018.03 new=HEAD in an attempt to DWIM
Zoffix, Bisecting by output (old=2018.03 new=1c6701b) because on both starting points the exit code is 0
Zoffix, bisect log: gist.github.com/e03607cd3608bdbf71...09910c20c8
Zoffix, (2018-04-04) github.com/rakudo/rakudo/commit/82...e6a4af9493
AlexDaniel ticket R#1753 16:19
synopsebot R#1753 [open]: github.com/rakudo/rakudo/issues/1753 [regression][⚠ blocker ⚠] Iterable appearing in subset constraints
Zoffix *sigh* just can't find it :/ 16:35
$code_obj.inline_info got the rewritten op, but I can't find where it's being set :/ 16:36
[TuxCM] nine, github.com/Tux/CSV/blob/master/43_binary.t 16:37
nine [TuxCM]: the "Cannot look up attributes in a CSV::Field type object" error is actually dependent on the Buf's contents. I have an example that reproducs 100 % 16:48
[TuxCM]: my $b = Buf.new(224,34,204,182); 16:58
stmuk_ releasable6: status 17:13
releasable6 stmuk_, Next release in ≈1 hour. 2 blockers. 224 out of 249 commits logged
stmuk_, Details: gist.github.com/26fd18f831a36e30aa...f7be0c70bd
stmuk_ "it's the final countdown!" 17:14
maybe
Zoffix www.youtube.com/watch?v=9jK-NcRmVcw
AlexDaniel well, in 1 hour definitely not, but very likely it's happening this weekend or so 17:16
Zoffix It's definitely a final countdown for my op bug. 17:17
... I can smell its presence.
ZofBot: ready the sandwich bread!
ZofBot Zoffix, Or that we might move into her house
timotimo Zoffix: talk to me, what are you looking for?
AlexDaniel robertle: sorry, what does that mean? “I have been unable to reproduce the problem without the patch however” 17:18
robertle: what problem are we talking about exactly?
robertle_ the SIGBUS. A short while ago I was able to get a SIGBUS on armhf quite consistently, with the test suite and the small case in the bug report... 17:20
I hava not had a terrible lot of time today though... 17:21
Zoffix timotimo: proto infix:<*> (|) causes `my int $x; say $x * 2` to get rewritten to mul_i, but `proto infix:<*>($, $, *%)` doesn't. So far, I tracked it to to analyze_args_for_ct_call and I want to teach it to handle *% the same as it handles | but I don't really see any handling for | so looks like it's just ignored :/
AlexDaniel robertle_: ok, so with the patch it no longer happens, right? Isn't it good?
robertle_ yeah, it is good! but it would be even better if teh problem could be reproduced... 17:22
AlexDaniel aaaaaaaaaaaaaaah
ok I get it now, sorry
robertle_ but the patch looks desirable independently from the crash, really
Zoffix tries s/$_.named ne ''/($_.named && ! $_.slurpy)/
AlexDaniel nine: can you commit it? ↑
robertle_ I wanna try the big endian libffi patch next... 17:23
timotimo Zoffix: isn't that "flattening" related? 17:24
ah, that's what you're changing there
Zoffix damn Cannot find method 'slurpy' on object of type QAST::Op+{QAST::SpecialArg}
it's just named and flat it got 17:25
timotimo slurpy is called flattening in those parts i think?
hm, though, that's probably the differnce between a specific call vs the signature 17:26
nine AlexDaniel: will do 17:30
AlexDaniel thank you
( github.com/perl6/nqp/issues/431#is...-382871449 ) 17:38
[TuxCM] samcv, I'd like a chat with tou when you're visiting an Amsterdam.PM meeting again :) 17:41
I'm out for the day. bbl 17:49
Zoffix looks like App::MoarVM::Debug doesn't work on src/Perl6/Optimizer.nqp 18:56
(unless I just dun it wron) 18:57
timotimo interesting, let's check it out together 18:58
what are you doing, what's happening?
Zoffix Trying to dump this array: github.com/rakudo/rakudo/blob/mast....nqp#L1586 18:59
While running code my int $x = 4; say 2 * $x
timotimo oh, now rakudo's exploding because FSA_SIZE_DEBUG found something 19:00
Zoffix :o 19:01
timotimo right, the debugserver is using it wrong there
oh, thats fun 19:05
i use MVM_calloc at one point to create that. that could be the problem :D
Zoffix: i have a sneaking suspicion already 19:07
Zoffix About what?
timotimo wait, i didn't even ask what wasn't working 19:08
did you reach the right position in the code with a breakpoint?
Zoffix timotimo: it doesn't stop at the breakpoint. Here's the session: gist.github.com/zoffixznet/0fe1eb3...2044a1bed4 19:09
timotimo yup, there is not actually a file that has that path 19:10
has to be gen/moar/Perl6-Optimizer.nqp
in that file, 1581 is a comment line 19:11
1589 is the right one
that breakpoint is hit on my end 19:12
Zoffix oh
timotimo if you need the filenames that are valid listed to you, you can run moar with MDS_PROTOCOL=yes in the environment and it'll flood you with info
Zoffix huggable: debug
huggable Zoffix, nothing found
Zoffix huggable: debug :is: github.com/edumentab/p6-app-moarvm...oarvmdebug if you need the filenames that are valid listed to you, you can run moar with MDS_PROTOCOL=yes in the environment and it'll flood you with info 19:13
huggable Zoffix, Added debug as github.com/edumentab/p6-app-moarvm...oarvmdebug if you need the filenames that are valid listed to you, you can run moar with MDS_PROTOCOL=yes in the environment and it'll flood you with info
timotimo there's not yet anything in the protocol to signal this info, i assume there ought to be in the future
i don't get any lexicals for analyze_args_for_ct_call, hooray for lexical-to-local-lowering :S 19:15
maybe rebuild rakudo with the perl6-optimizer turned off for its own code 19:20
so that all lexicals remain in there
Zoffix I managed to dump them manually
Types end up being [Int, int] in broken version and [int] in working :/ 19:21
oh wait, nm, there are two places they get dumped at 19:23
timotimo damn, you had to change the code and recompile rakudo?
Zoffix Ok, finally golfed it down to something outside rakudo 19:30
m: use nqp; dd nqp::p6trialbind(:($?, $?), nqp::list(Int, int), nqp::list(33, 1))
camelia 1
Zoffix m: use nqp; dd nqp::p6trialbind(:($?, $?, *%), nqp::list(Int, int), nqp::list(33, 1))
camelia 0
Zoffix Needs to say 1 in both cases
nine zef now officialy supports Distribution::Builder as specified in S22 since last PTS :)
Zoffix nice 19:31
"# If there's a single capture parameter, then we're OK. (Worth handling especially as it's the common case for protos)." 19:32
Well, not anymore :/
nine It's funny to discover what amazing stuff we did last year and almost forgot about it later. And that it's at least as much work to get this stuff into the toolchain while maintaining backwards compatibility
Zoffix Wonder if all these more specific protos stuff will make stuff slower to compile now
"# If the parameter is anything other than a boring old positional parameter, we won't analyze it." 19:35
I guess that's the ticket. Need to make it treat *% as "ok"
ZofBot: ohyea boiii 19:42
ZofBot Zoffix, We do this because sometimes Father wants to give me a hug, but do not like hugging people so we do this instead, and it means that he loves me
AlexDaniel O_O 19:45
Zoffix XD 19:46
ZofBot: and who's your Father? 19:48
ZofBot Zoffix, It's the same concept but written in a more explicit way
Zoffix ZOFVM: Files=1294, Tests=153320, 147 wallclock secs (19.92 usr 3.15 sys + 3118.95 cusr 146.01 csys = 3288.03 CPU) 19:54
win
Well, I hope it's a win and I didn't actually mess something up :P 19:55
hm 19:56
jnthn: are you around? 20:02
.ask jnthn is it right that we OKing a capture param in trial bind; 'cause it might have a `where` clause on it, doesn't it? github.com/rakudo/rakudo/blob/mast...P.nqp#L998 Asking 'cause I'm sticking `if $flags +& $SIG_ELEM_SLURPY_NAMED { next }` before this line github.com/rakudo/rakudo/blob/mast....nqp#L1014 to ignore named slurpy 20:04
yoleaux Zoffix: I'll pass your message to jnthn.
Zoffix params, since we now use them in protos, but now I'm wondering what if they got a where clause on them......
.tell jnthn params, since we now use them in protos, but now I'm wondering what if they got a where clause on them......
yoleaux Zoffix: I'll pass your message to jnthn.
Geth rakudo/proto-fix-R1739: d443076dab | (Zoffix Znet)++ | t/02-rakudo/08-inline-native-arith.t
Revert "Temp-fudge mul_i opt test"

This reverts commit a3a7c142a48026db434893e79930478efba926c9.		 20:06
rakudo/proto-fix-R1739: 6a65ed02bf | (Zoffix Znet)++ | src/Perl6/Metamodel/BOOTSTRAP.nqp
Teach Binder's .trial_bind to handle named slurpies

Since this one would accept any named param, just ignore it while trial binding. This lets us use `*%` in our protos as part of fixing github.com/rakudo/rakudo/issues/1739
rakudo/proto-fix-R1739: d17f7535aa | (Zoffix Znet)++ | t/02-rakudo/08-inline-native-arith.t
Unfudge mul_i inline / add additional test for *% trialbind
roast/proto-fix-R1739: bae723ceaa | (Zoffix Znet)++ | S06-signature/unspecified.t
Tweak test to work even when we find error at compile time

The test assumes the dispatch failure will only ever going to be detected at runtime, but we're now smart enough to detect it at compile time.
Fix the test by using eval-dies-ok instead of just dies-ok.
rakudo: zoffixznet++ created pull request #1755:
Proto fix r1739		 20:08
rakudo/master: 7 commits pushed by (Zoffix Znet)++
roast: zoffixznet++ created pull request #417:
Proto fix r1739		 20:09
roast/master: 5 commits pushed by (Zoffix Znet)++
AlexDaniel Zoffix++
samcv [Tux]: looking forward to it :) 20:10
Zoffix AlexDaniel: there are three commits that need to be cherry-picked to 6.c-errata: 16594c6187 which just fixes up test to not assuming the call will fail with a multi dispatch failure (it can also and now does fail with single-sub param bind failure, since we fail in proto, before we even get to candidates); 0faa97adf8 is the helper routine used in previous commit; and bae723ceaa just makes the assumption 20:11
call failure will be done at runtime, but we now are able to detect that it'll never work at compile time, so the test is tweaked to handle compile time throwage.
AlexDaniel: and github.com/rakudo/rakudo/issues/1739 is now fixed, but would be nice for jnthn to OK this commit github.com/rakudo/rakudo/pull/1755...036e7652c6 ( I sent a robot message here irclog.perlgeek.de/perl6-dev/2018-...i_16075200 ) 20:12
It's just too obvious a thing to have it check so the fact that it wasn't makes me think there might be a reason.
AlexDaniel I see 20:13
Zoffix And if that commits needs to be reverted, then we got a problem, as pretty much all our protos now have a *% (all except those that got a |)
AlexDaniel so, from my side, toaster looked good (at least before these changes)
but
releasable fails when trying to install Inline::Perl5
trying to figure out why 20:14
but it just says
===> Building: Inline::Perl5:ver<0.32>:auth<github:niner>
(Any)
No building backend available
nine: ↑ does that ring any bells?
(well there's a backtrace also obviously)
Kaiepi that reminds me i need to get rakudobot to support inline::perl5
AlexDaniel ah 20:17
right, can reproduce it 20:18
just had to update zef
tony-o we're here working on it 20:20
AlexDaniel nine: I filed this ticket, let me know if there's anything else I should do: github.com/ugexe/zef/issues/240
oh 20:21
tony-o oh, not on the issue afaik, just on zef in general
okay, now we're looking at it
AlexDaniel good, thank you
tony-o nine just flipped open his pc
AlexDaniel \o/ :) 20:22
tony-o if you want the play by play, he can reproduce 20:24
he's typing furiously
AlexDaniel this is amazing :D 20:26
MasterDuke is he livestreaming on twitch? 20:29
nine AlexDaniel: just pushed a fix 20:30
at least I hope so :)
tony-o he's anxiously awaiting an update on his progress
AlexDaniel
.oO( 20$ for another hour trying to fix a bug )
nine: don't you have to bump the version? 20:31
tony-o ugexe is waiting to do that since all 3 of us are testing
nine Fix is good...ugexe is doing the version bump 20:32
tony-o nine is now napping
AlexDaniel thanks to all of you \o/ 20:33
nine AlexDaniel: thanks for the report 20:34
jnthn Currently testing a fix for github.com/rakudo/rakudo/issues/1753 20:35
yoleaux 20:04Z <Zoffix> jnthn: is it right that we OKing a capture param in trial bind; 'cause it might have a `where` clause on it, doesn't it? github.com/rakudo/rakudo/blob/mast...P.nqp#L998 Asking 'cause I'm sticking `if $flags +& $SIG_ELEM_SLURPY_NAMED { next }` before this line github.com/rakudo/rakudo/blob/mast....nqp#L1014 to ignore named slurpy
20:04Z <Zoffix> jnthn: params, since we now use them in protos, but now I'm wondering what if they got a where clause on them......
AlexDaniel c: HEAD subset ZInt of Cool where *.elems; sub foo(ZInt(Cool) $Z) {}; say "well that's compile time 20:45
committable6 AlexDaniel, ¦HEAD(92eaa11): «===SORRY!===␤Method 'iterator' must be implemented by Iterable because it is required by roles: Iterable.␤ «exit code = 1»»
jnthn It's so compile time you get the error before your syntax error. :-) 20:46
AlexDaniel :)
jnthn My change extended an optimization to include coercion types, but I'd not considered that he target of a coercion type might be a subset type. In theory that shouldn't be a problem. 20:47
But practice ain't theory. ;)
nine In theory theory and practice are the same
jnthn But all I really need is the nominal type the subset type is based on.
AlexDaniel golfing it was fun, I just deleted everything in the file from some point (all these closing braces) and the error was still there 20:48
jnthn So I've got a patch to do that. I've checked in --target=ast that the opt still applies how I expect. Spectest is nearly done.
Geth rakudo: zoffixznet self-assigned Iterable appearing in subset constraints github.com/rakudo/rakudo/issues/1753
12a38f1f65 | (Jonathan Worthington)++ | src/Perl6/Actions.nqp

Since that's all it needs anyway. As noted in issue #1753, subset type
  `where` clauses will often not be written so robustly as to handle
having the `Iterable` role passed in to check. Since we've no need to do that anyway, this change side-steps the problem, in the same way it is side-stepped for the optimization on a `Foo $x` parameter.		 20:54
Zoffix oh damn, my IRC was hung 20:55
synopsebot RAKUDO#1753 [open]: github.com/rakudo/rakudo/issues/1753 [regression][⚠ blocker ⚠] Iterable appearing in subset constraints
Zoffix My patch was just sticking nqp::how($*W.find_symbol: ['Metamodel', 'SubsetHOW'], :setting-only)) before testing for istype Iterable 20:57
AlexDaniel: so then that's it. All blockers are fixed 20:58
AlexDaniel yeah, that's awesome
jnthn Zoffix: Something like that would fix it, but be a missed opportunity (in that if we pull out the nominal base type then we can still apply the opt). 20:59
AlexDaniel jnthn: so what's the answer to the robomessage?
Zoffix jnthn: yeah, I see it now 21:00
jnthn Was just about to read that, now I'm done with that ticket :-)
AlexDaniel ♥
jnthn Zoffix: Yes, you're right, a `where` clause on that `Capture` would break that opt. 21:01
I'm pretty sure the syntax admits one
m: sub foo(|c where *.elems) { }
camelia ( no output )
jnthn Yeah, it does
Note that below there's: 21:02
unless nqp::isnull(nqp::getattr($param, Parameter, '@!post_constraints')) {
return $TRIAL_BIND_NOT_SURE;
}
So we cover that in general
If a handling of *% comes before that test, then we'd need to check that also 21:03
Zoffix Yeah, it does. Gonna add it
jnthn Zoffix++
Nice catch
OK, anything else release-blocking that wants my eyes?
Zoffix AlexDaniel: ping ^ 21:04
AlexDaniel to my knowledge there's nothing left :)
jnthn \o/
timotimo very cool.
Geth roast: 3d94721d68 | (Zoffix Znet)++ | S12-coercion/coercion-types.t
Test coercer with subset target does not crash

Closes github.com/rakudo/rakudo/issues/1753 R#1753		 21:05
AlexDaniel Zoffix: proposed errata changes look fine too, I hope no one is relying (they really shouldn't) on subs dying at run time 21:07
but I'll run toaster once again anyway, because I can :) 21:08
Zoffix AlexDaniel: 1 sec, let me commit the fix for trial bind
nine jnthn: I'd just be interested in your opinion on doing github.com/MoarVM/MoarVM/commit/876aa90ee7 on all architectures for potential performance wins of keeping pointers aligned 21:09
AlexDaniel you can also do a bump
Zoffix will do
jnthn nine: Not sure; it's a trade-off against how much fits into caches. 21:11
nine: I suspect we don't have many things that actually need padding, however. 21:12
nine Aren't cache entries aligned anyway?
jnthn In fact, I'm curious where this does come up
Cache lines are, but they're also 64 bytes in size
Or 32, or 16... 21:13
But bigger an an individual item
I think it's probably worth doing alignment to pointer size everywhere 21:14
Whether it's worth doing 8-byte alignment on 32-bit platforms so that doubles are always aligned, on the other hand, I'm much less sure about.
(On platforms where we don't need it, I mean)
Zoffix hm, can't come up with a piece of code that would show `sub foo(|c where *.elems) { }` as problematic case 21:16
jnthn It'd need to be a multi, I think? 21:17
jnthn afk a bit 21:19
Zoffix I give up 21:21
Geth rakudo: 859178b066 | (Zoffix Znet)++ | src/Perl6/Metamodel/BOOTSTRAP.nqp
Check postconstraints when we handle capture/named slurpy in trial bind

  irclog.perlgeek.de/perl6-dev/2018-...i_16075429		 21:22
Zoffix c: 2018.03 proto z(|) is pure {*}; multi z(Str) {say "called"}; say "runtime"; $ = z "" 21:25
committable6 Zoffix, ¦2018.03: «called␤runtime␤»
Zoffix c: 2018.03 proto z(| where *.head.so) is pure {*}; multi z(Str) {say "called"}; say "runtime"; $ = z ""
committable6 Zoffix, ¦2018.03: «runtime␤Constraint type check failed in binding to parameter '<anon>'; expected anonymous constraint to be met but got Capture (\(""))␤ in block <unit> at /tmp/UQSWQjJu_f line 1␤␤ «exit code = 1»»
Zoffix Like, I would've expected that to miss the `where` in the proto and behave the same as the first case
m: use nqp; dd nqp::p6trialbind(:(| where *.not), nqp::list(Int, int), nqp::list(33, 1)) 21:27
camelia 1
Zoffix c: HEAD use nqp; dd nqp::p6trialbind(:(| where *.not), nqp::list(Int, int), nqp::list(33, 1))
committable6 Zoffix, ¦HEAD(12a38f1): «1␤»
Zoffix that prolly it
yup
Geth nqp: a24e43d8f4 | (Zoffix Znet)++ | tools/build/MOAR_REVISION
[MoarVM Bump] 876aa90 Ensure memory blocks in […]

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...6-g876aa90		 21:29
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...6-g876aa90
rakudo: db7e79a015 | (Zoffix Znet)++ | tools/build/NQP_REVISION
[NQP Bump] a24e43d [MoarVM Bump] 876aa90 Ensur […]

NQP bump brought: github.com/perl6/nqp/compare/2018....5-ga24e43d
MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...6-g876aa90
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....5-ga24e43d
fa979c9227 | (Zoffix Znet)++ | t/02-rakudo/08-inline-native-arith.t

Ensure it notices `where` on capture / named slurpy
AlexDaniel BeastieBot: all 21:31
BeastieBot [freebsd] Configuring Rakudo...
Zoffix AlexDaniel: I'm done. All good for toasting
AlexDaniel cool
BeastieBot [freebsd] Building Rakudo... 21:33
[freebsd] Build successful! 21:36
[freebsd] Testing Rakudo...
Geth roast/6.c-errata: 75b4fb032a | (Zoffix Znet)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | packages/Test/Util.pm
Implement throws-like-any helper routine

Same as throws-like but checks the exception among possibilities		 21:39
roast/6.c-errata: 7dc87a906f | (Zoffix Znet)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | 2 files
Loosen no-multi tests for Mu.[]/Mu.{}

The tests test there's no candidate to handle the Mu, but testing for X::Multi::NoMatch is too strict a restriction.
Allow X::TypeCheck::Binding::Parameter to be thrown as well in those cases.
BeastieBot [freebsd] | t/04-nativecall/02-simple-args.t (Wstat: 256 Tests: 14 Failed: 1)
[freebsd] Tests failed. See the output at fpaste.scsys.co.uk/577186
AlexDaniel, done!
roast/6.c-errata: b8889f73f3 | (Zoffix Znet)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | S06-signature/unspecified.t
Tweak test to work even when we find error at compile time

The test assumes the dispatch failure will only ever going to be detected at runtime, but we're now smart enough to detect it at compile time.
Fix the test by using eval-dies-ok instead of just dies-ok.
AlexDaniel Kaiepi: is that something I should worry about?
Kaiepi is what? 21:52
oh lemme check
yes and no 21:53
i already made a pullreq to mitigate it, and there's another way that might work for os x as well
github.com/rakudo/rakudo/pull/1620 21:54
i'll get pufferbot up and check its tests 21:56
the stresstests i'll have to run myself for both bots since i need to refactor it badly before i can support it properly 21:57
AlexDaniel uhhh 21:58
Geth rakudo: 71d23f0abe | (Ben Davies)++ | t/04-nativecall/02-simple-args.t
Skip NativeCall TakeUint16 test on FreeBSD

  See #1619		 21:59
rakudo: a138dcf50d | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | t/04-nativecall/02-simple-args.t
Merge pull request #1620 from Kaiepi/nativecall

Skip NativeCall TakeUint16 test on FreeBSD
synopsebot RAKUDO#1619 [open]: github.com/rakudo/rakudo/issues/1619 NativeCall TakeUint16(0xFFFE) test fails in certain cases on FreeBSD
AlexDaniel Kaiepi: ok can you please file a ticket mentioning that these tests are skipped?
Kaiepi ok 22:00
AlexDaniel skipping is probably ok for now given that we already do it for osx, but we want to fix that eventually
thanks
Kaiepi how do i open a ticket on the site though? 22:02
Zoffix Kaiepi: file it on github: github.com/rakudo/rakudo/issues/new
Kaiepi ohhh 22:03
lol
i've been doing that since it seemed like the style here, but didn't realize it opened tickets 22:04
Zoffix Kaiepi: what site were you talking about? fail.rakudo.party/
?
AlexDaniel oh, there is a ticket already: R#1619 22:05
Kaiepi ....the perl 5 one it looks like
AlexDaniel I guess both fail.rakudo.party/ and RT should now say that new tickets are preferably submitted on github 22:08
Kaiepi that's a relief 22:09
AlexDaniel otherwise people tracking these websites probably get a feeling that no one is reporting bugs anymore
Zoffix :)
travis-ci Rakudo build passed. Aleks-Daniel Jakimenko-Aleksejev 'Merge pull request #1620 from Kaiepi/nativecall 22:35
travis-ci.org/rakudo/rakudo/builds/369606309 github.com/rakudo/rakudo/compare/f...38dcf50df2
Kaiepi i'm gonna need to upu the ram on my freebsd vps, beastiebot doesn't handle stresstest unless you're lucky 22:38
timotimo maybe it's enough to set TEST_JOBS to a lower number?
Kaiepi i'll give that a shot 22:40
timotimo though i could imagine we have marked some tests as "memory hungry" and perhaps run these in isolation?
*shrug*
Kaiepi the vps has only one core, so TEST_JOBS might be what i need 22:45
or more cores 22:46
timotimo is that the core of your problem? 22:49
Kaiepi possibly :) 22:50
ok Inline::Perl5 won't install on freebsd 23:00
i'll see how the stresstest goes without it 23:01
freebsd stresstest results: hastebin.com/zebiranuce.sql 23:07
wait i interrupted it? 23:09
nvm lemme run it again
AlexDaniel ok releasable is happy
toaster not done yet but I'm not expecting any new failures from there 23:10
so having said that, I'll now get some sleep, see you all tomorrow :)
Kaiepi night 23:11
AlexDaniel samcv: it looks like everything is ready for rakudo release (except for some paperwork) \o/
timotimo good night AlexDaniel :)
AlexDaniel Kaiepi: please file a bug report if you get some consistent failures
Kaiepi: sometimes things flap, so rerun if you get one failure somewhere 23:12
… well sometimes maybe more than one :)
Kaiepi if i haven't been doing it consistently enough, i'll work on that 23:13
actually wait i should mention the io-socket-async ipv6 failures on systems without it 23:14
openbsd stresstests done: a bunch failed hastebin.com/molupujeqo.sql 23:31
depending on what stresstest's doing it might just be an issue with login.com 23:32
*login.conf
Zoffix It's a 1-core box? Likely why t/spec/MISC/bug-coverage-stress.t failed 23:39
Kaiepi the link i just posted is my desktop
the freebsd one's still going
Zoffix Ah
Kaiepi could be a login.conf issue 23:40
Zoffix That reminds me. Spectest failures for Win10: gist.github.com/zoffixznet/c0cf58a...7f205fdcd6 23:42
on head
tony-o timotimo: ping 23:43
Kaiepi the tests i'm running are on head
i stopped working in t/spec and cloned roast, so those errors shouldn't pop up anymore 23:44

Powered by Cro and the Raku® Programming Language.

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

Thank you!