travis-ci Rakudo build errored. Elizabeth Mattijsen 'Give 1dimmed arrays its own .antipairs 00:07
travis-ci.org/rakudo/rakudo/builds/173746785 github.com/rakudo/rakudo/compare/c...425f972644
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
mst I ... don't think this is right 00:50
m: 1...10 >>*>> 2
camelia ( no output )
mst m: say 1...10 >>*>> 2
camelia rakudo-moar 1c425f: OUTPUT«(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)␤»
mst m: say 1,2...10 >>*>> 2
camelia rakudo-moar 1c425f: OUTPUT«(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)␤»
mst m: say 1,2,4...10 >>*>> 2
camelia rakudo-moar 1c425f: OUTPUT«(1 2 4 8 16)␤»
mst the compile time expansion of the arithmetic sequence is fucking up precedence, I guess? 00:51
viki ... is lower precedence 01:21
m: say 2 + 2 «*» 10 01:25
camelia rakudo-moar 1c425f: OUTPUT«22␤»
viki m: say 2 * 2 «+» 10
camelia rakudo-moar 1c425f: OUTPUT«14␤»
viki m: say (1,2,4…10) »*» 2
camelia rakudo-moar 1c425f: OUTPUT«(2 4 8 16)␤»
MasterDuke jnthn: i'm not following something. just to see what's going on i added a print in lineof (github.com/perl6/nqp/blob/master/s...nqp#L664). i see it when building nqp, but it's not getting triggered when building rakudo 03:36
[Tux] This is Rakudo version 2016.10-196-g1c425f9 built on MoarVM version 2016.10-39-g4b9e3a8 07:19
csv-ip5xs 3.060
test 14.601
test-t 6.931
csv-parser 16.426
dalek ast: 779d02e | moritz++ | S12-construction/TWEAK.t:
Initial tests for submethod TWEAK
07:50
moritz timotimo: time to merge your branch ^^
dalek kudo/POSTBUILD_method: 6b8d481 | moritz++ | t/spectest.data:
Run TWEAK tests
08:40
tadzik so, TWEAK, eh? 08:41
it's a nice name :)
timotimo++ for putting this in motion :)
lizmat Files=1151, Tests=53712, 214 wallclock secs (12.77 usr 3.66 sys + 1301.86 cusr 122.57 csys = 1440.86 CPU) 09:18
m: my @a[2;2] = <a b>,<c d>; say @a[0;0]:!exists # buglet 11:03
camelia rakudo-moar 1c425f: OUTPUT«Partially dimensioned views of arrays not yet implemented. Sorry. ␤ in block <unit> at <tmp> line 1␤␤»
lizmat m: my @a[2;2] = <a b>,<c d>; say @a[0;0]:exists
camelia rakudo-moar 1c425f: OUTPUT«True␤»
dalek kudo/js: b48c448 | (Pawel Murias)++ | src/vm/js/perl6-runtime/runtime.js:
[js] Call $$decont directly instead of using the no longer present nqp.op.decont.
11:07
kudo/js: 91dd06e | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] Fix some bugs after null -> Null transition.
lizmat re: TWEAK, has anybody looked at the influence that has on general object building ? 11:16
performance wise, I mean ?
dalek kudo/nom: 0b97362 | lizmat++ | src/core/array_slice.pm:
postcircumfix[;] 9x faster 2/3 dimmed arrays
11:22
kudo/nom: ce85ba3 | lizmat++ | src/core/array_slice.pm:
assign to [;] for 2/3 dimmed arrays 10x faster
11:38
p: 34828da | (Pawel Murias)++ | src/vm/js/bin/run_tests_bootstrapped.pl:
[js] Update our nqp-js-on-js test run to take in account changes where the compiled code is stored.
11:53
p: a620574 | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Remove trailing space.
p: 3c6892a | (Pawel Murias)++ | src/vm/js/RegexCompiler.nqp:
[js] $¢ is declared by the surrounding Block no need to do weird stuff with it.
kudo/nom: bb662ff | lizmat++ | / (4 files):
Split off postcircumfix[;] candidates

into a separate multidim_slice.pm file, as there will be plenty more candidates coming and most of it will be rewritten by me anyway.
11:56
travis-ci Rakudo build errored. Elizabeth Mattijsen 'postcircumfix[;] 9x faster 2/3 dimmed arrays' 12:09
travis-ci.org/rakudo/rakudo/builds/173864832 github.com/rakudo/rakudo/compare/1...973628ee20
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
travis-ci Rakudo build failed. Elizabeth Mattijsen 'assign to [;] for 2/3 dimmed arrays 10x faster' 12:45
travis-ci.org/rakudo/rakudo/builds/173868125 github.com/rakudo/rakudo/compare/0...85ba378d29
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek kudo/nom: e3e3fef | lizmat++ | src/core/multidim_slice.pm:
Make [;]:exists 7x faster for 2/3 dimmed arrays

Also fix :!exists, it would break before
12:59
TimToady lizmat: I'd say that the existence of a submethod TWEAK can be determined at composition time when we put together the build plan, so shouldn't be a problem in theory 13:14
lizmat ah, indeed :-) 13:15
dalek kudo/nom: 3b9c4c9 | lizmat++ | src/core/multidim_slice.pm:
Make [;]:delete 10 faster for 2/3 dimmed arrays

Also fix :!delete, it would break before
13:17
lizmat oops, 10x
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Split off postcircumfix[;] candidates 13:18
travis-ci.org/rakudo/rakudo/builds/173871978 github.com/rakudo/rakudo/compare/c...662ff6cfff
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek kudo/nom: b71a8bc | ab5tract++ | src/core/set_operators.pm:
Two-arg version of symmetric difference should DWIM
13:20
kudo/nom: 6ab0c48 | ab5tract++ | src/core/set_operators.pm:
Make chained (^) work as expected for bags/mixes
kudo/nom: f9fec1c | ab5tract++ | src/core/set_operators.pm:
Unicode op version should not be constrained to returning Setty
rakudo/nom: 40704b8 | (Zoffix Znet)++ | src/core/set_operators.pm:
rakudo/nom: Merge pull request #911 from ab5tract/ab5tract/sym-diff-bag-mix
rakudo/nom:
timotimo lizmat: hold on, that's 10 fast 20 me!
dalek ast: 21fc586 | ab5tract++ | S03-operators/ (3 files):
Test updated for proper bag/mix symmetric difference (#179)
13:22
[Coke] we should probably decomission perl6-release; hasn't been used for the past few releases, only send there in months was a political spammer. 13:27
nine +1
dalek ast: 6b20963 | (Zoffix Znet)++ | S03-operators/mix.t:
Adjust plan

Per discussion[^1], the adjustment is needed due to PR#179 removing some redundant tests, while forgetting to adjust the plan.
  github.com/perl6/roast/pull/179#di..._r86182898
13:33
ast: c667421 | (Zoffix Znet)++ | S03-operators/bag.t:
Unfudge now-passing tests

Tests made passing by github.com/rakudo/rakudo/pull/911
RT#124529: rt.perl.org/Public/Bug/Display.html?id=124529
13:38
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124529
mst viki: yes, but why does the precedence of ... *change* ?
timotimo misses that context
viki mst: it doesn't
timotimo: irclog.perlgeek.de/perl6-dev/2016-...i_13525128 13:39
mst: ** is higher precedence than ...
Or *
mst viki: ...
viki: please read the last two examples I sent to the bot again, more carefully.
viki m: say (1,2,4...Inf)[30] 13:40
camelia rakudo-moar 40704b: OUTPUT«1073741824␤»
viki m: .say for (1,2,4...Inf)[30]
camelia rakudo-moar 40704b: OUTPUT«1073741824␤»
viki oh
m: say (1,2,4...Inf)[^30] 13:41
camelia rakudo-moar 40704b: OUTPUT«(1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912)␤»
masak m: say (1,2,4...10) >>*>> 2
camelia rakudo-moar 40704b: OUTPUT«(2 4 8 16)␤»
masak mst: the precedence of `...` is very loose. usually needs parentheses when interacting with something as tight as `>>*>>`
viki mst: the penultimate example stops at 20, because it's one of the generated numbers, the other stops at 16, because 32 is higher than 20
mst: the two examples are basically m: say 1,2,4...20 and say 1,2...20, and they stop at different points because of different generated sequences. 13:42
mst ah BALLS I misread the output of the geometric one
viki \o/
masak mst: the one thing that always bites me is a (similar) interaction between `...` and (something like) `.map`
or `map` 13:43
very tricksy
I'm not one to superstitiously put in parentheses -- and Perl 5/6 generally allow you to avoid parentheses because the prec levels make sense
but `...` is one of the exceptions, where I tend to put them in, just to be safe :)
also gives the sequence a little bit of a visual-pill-ness 13:44
dalek kudo/nom: eaf4132 | lizmat++ | src/core/multidim_slice.pm:
Make [;] := foo 10 faster for 2/3 dimmed arrays
13:46
lizmat argh... 10x :-) 13:47
cutnpastefail
mst viki: yeah, sorry, thing is 13:48
m: 1,2,4...10 >>*>> 2
camelia ( no output )
mst m: say 1,2,4...10 >>*>> 2
camelia rakudo-moar 40704b: OUTPUT«(1 2 4 8 16)␤»
mst m: say (1,2,4...10) >>*>> 2
camelia rakudo-moar 40704b: OUTPUT«(2 4 8 16)␤»
mst viki: ^^ notice how similar those are if you're mst and not paying attention properly
viki Oh yeah :)
masak m: say 1,2,4...(10 >>*>> 2)
camelia rakudo-moar 40704b: OUTPUT«(1 2 4 8 16)␤»
masak much clearer :) 13:49
mst masak: yeah, I understand fine now
masak thought so
mst just explaining precisely how I confused myself
since I prefer to be laughed at accurately
viki I guess ... takes 2 nums of the LHS and say prints the "1" as is.
masak .oO( How to be Properly Confused, a mini-course )
viki m: .say for 1,2,4...10 >>*>> 2
camelia rakudo-moar 40704b: OUTPUT«1␤2␤4␤8␤16␤»
masak viki: guess again :) 13:50
viki masak: what is it?
masak see my eval above
mst masak: there is actually an entire section in the lesswrong sequences about that.
viki masak: your eval has the same result?
as without any parens
masak because that's how natural precedence makes it
`...` is very loose 13:51
`say` is a listop here, so that's already out of consideration
viki Oh, OK. Now I confused myself :D
masak `...` ends up getting `1,2,4` as lhs and `10 >>*>> 2` as rhs
viki Yeah
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make [;]:exists 7x faster for 2/3 dimmed arrays 13:56
travis-ci.org/rakudo/rakudo/builds/173887279 github.com/rakudo/rakudo/compare/b...e3fefd34ce
dalek ast: 3c6277f | (Zoffix Znet)++ | S03-operators/mix.t:
Fix broken test

The test was previously fudged and rework in
  github.com/perl6/roast/pull/179 left some old code in it, causing
it to remain failing after unfudging.
13:59
viki ZOFVM: Files=1200, Tests=130105, 142 wallclock secs (20.38 usr 3.20 sys + 2462.70 cusr 227.48 csys = 2713.76 CPU) 14:02
awww abstr5ct's PR did break 6.c-errata >_< 14:07
So much for my detailed review :/
m: say <a network> (^) <b network> (^) <a network>
camelia rakudo-moar eaf413: OUTPUT«set(b, network)␤»
viki Well, can't think of anything better than to methodically revert all of the commits I pushed today in reverse order.... :/ 14:15
Totally missed that the very last file had changes to non-fudged tests: github.com/perl6/roast/pull/179/fi...28a0a42ac1 14:16
And those are in 6.c-errata too
moritz you can squash the revert commits into one 14:17
or do a git diff -R start..end | git apply
or something like
viki pokes dalek 14:25
error: Commit 40704b82dd6126c60e7f9a99a2ebd0aaab445003 is a merge but no -m option was given.
hmmm
now I have to learn what a parent is. 14:26
This sounds scary... talking about trees and never wanting things :/ 14:30
moritz a merge brings two branches together, so it has two "previous" commits, aka parents 14:31
if you want to revert a merge commit, you have to specify which changes to revert: the changes between the commit and its first parent, or between the commit and its second parent 14:32
viki Right, I now know how to revert it, I think, but it comes with "but it's very important you realize that doing so "declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want"
And I've no idea what trees I want or not want :)
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make [;]:delete 10 faster for 2/3 dimmed arrays
travis-ci.org/rakudo/rakudo/builds/173891521 github.com/rakudo/rakudo/compare/e...9c4c95b94e
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only. 14:33
viki Oh, I can do the git diff -R thing again... \o/ 14:34
lizmat viki: is it ok if I push again, or would you like me to refrain from that while you're doing the unwinding ?
viki OK. I think I'm done. 14:35
and dalek is AWOL
dalek kudo/nom: 45236f1 | (Zoffix Znet)++ | src/core/set_operators.pm:
Revert merge of #911 as it breaks 6.c-errata

PR: github.com/rakudo/rakudo/pull/911
viki lizmat: go ahead. I'm finished. 14:36
lizmat viki: okidoki
travis-ci Rakudo build errored. Zoffix Znet 'Merge pull request #911 from ab5tract/ab5tract/sym-diff-bag-mix 15:09
travis-ci.org/rakudo/rakudo/builds/173892370 github.com/rakudo/rakudo/compare/3...704b82dd61
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek kudo/nom: bcf1d9a | lizmat++ | src/core/Rakudo/Internals.pm:
Re-imagine R:I:NOT_ALL_(DEFINED|)TYPE

  - rewrite using nqp ops
  - don't bother coercing to bool as this is an internal method anyway
15:22
kudo/nom: 93ca094 | lizmat++ | src/core/ (4 files):
Refactor R:I:NOT_ALL_(DEFINED)_TYPE removing NOT

Turned out it would be very useful if these internal methods worked the other way around and return number of elems if all of the given type. fc7c480 | lizmat++ | src/core/multidim_slice.pm: Use R:I:ALL_DEFINED_TYPE in [;] handling
FROGGS o/ 15:39
lizmat FROGGS o\ 15:40
dalek kudo/nom: 29a3faa | lizmat++ | src/core/multidim_slice.pm:
Revert "Use R:I:ALL_DEFINED_TYPE in [;] handling"

This reverts commit fc7c480df6c952c0a7eedfef1aa729e4863ad775.
I should have checked the performance effects on this before pushing. Making it 4x slower is not an option for such hot code paths :-(
15:42
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Make [;] := foo 10 faster for 2/3 dimmed arrays' 15:55
travis-ci.org/rakudo/rakudo/builds/173899058 github.com/rakudo/rakudo/compare/4...f4132f4682
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
dalek kudo/nom: 764cfcd | lizmat++ | src/core/multidim_slice.pm:
Implement :kv,:p,:k,:v on 1 element multidim [;]
16:12
lizmat So I have some LHF/MHF for someone more versed in Grammar/Actions/World 16:36
if you do: for ^10000 { my @a } 16:37
what in fact happens, is that at compile time, an Array object is created, and then install_lexical_symbol adds the code to clone the created object 16:38
during execution (with an nqp::clone)
what happens if you do for ^10000 { my @a[10] }, is that the object is completely created at runtime every time, instead of a cloned one
that in itself wouldn't be so bad, but for some reason, each time we do a @a[10], we get a global deopt 16:39
I think this is the one showstopper between normal and shaped arrays that we need to fix to have performance between normal and shaped arrays on par 16:40
so, any pointers / patches would be greatly appreciated
lizmat now starts working on the P6W
travis-ci Rakudo build failed. Zoffix Znet 'Revert merge of #911 as it breaks 6.c-errata 16:41
travis-ci.org/rakudo/rakudo/builds/173913947 github.com/rakudo/rakudo/compare/e...236f10b54a
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
nine lizmat: do you think it's a good idea to post a notice in the weekly about lexical_module_loading? That people should prepare for the change by making sure they add use statements for all modules they use and not rely on indirect loading? 16:43
lizmat nine: excellent point, will do! 16:44
dalek kudo/nom: e10f767 | (Zoffix Znet)++ | src/core/set_operators.pm:
Handle negative Mixy weights in ∪ operator

Lookup of a non-existant key in a Mixy gives a zero, which when `max`ed against a key with a negative weight would lead to that key being removed from the final union, making the operator trim all the negative weights for keys present in just one Mixy.
Add a check for whether a key exists: if it does, take a `max` value, if it doesn't, just use the value of the key from other Mixy as is.
ab5tract++ for submitting code that revealed this bug.
17:12
ast: c28b010 | (Zoffix Znet)++ | S02-types/mix (2 files):
Test negative weights survive ∪ operator

Fixed in Rakudo in
  github.com/rakudo/rakudo/commit/e1...ecd4f82927
17:22
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Refactor R:I:NOT_ALL_(DEFINED)_TYPE removing NOT 17:27
travis-ci.org/rakudo/rakudo/builds/173928761 github.com/rakudo/rakudo/compare/4...ca094c9f76
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
viki .seen psch 17:31
yoleaux2 I saw psch 25 Oct 2016 19:12Z in #perl6-dev: <psch> don't we do that for closures as substituting argument?
dogbert17 lizmat++, shaped array benchmark: real 1m53.602s user 1m52.960s, This is Rakudo version 2016.10-213-ge10f767 built on MoarVM version 2016.10-37-gf769569
compare with: Real 4m38.345s, user 4m37.488s, This is Rakudo version 2016.10-176-gaa97f86 built on MoarVM version 2016.10-37-gf769569
and real 6m17.384 user 6m16.172s with Rakudo version 2016.09-105-g4abc28c built on MoarVM version 2016.09-13-g34c375a 17:32
lizmat m: say 377 / 113
camelia rakudo-moar e10f76: OUTPUT«3.336283␤»
lizmat not too shabby :-) 17:33
dogbert17 very impressive
lizmat dogbert17: oddly enough, I'm on 2016.10-199 ? so you're 14 commits ahead ? 17:41
dogbert17 lizmat: interesting
viki is on 2016.10-213-ge10f767 17:42
dogbert17 oO
lizmat pulls and rebuilds 17:43
hmmm.. I pulled a commit from viki, then rebuilt: still at 2016.10-199-gbb662ff 17:44
mst git clean dxf ? 17:45
japhb
.oO( git clean --aliens-style )
viki shrugs
mst git clean --gangnam-style 17:46
viki bb66 is 2 commits prior to my merge-revert fiasco, so at least it's not that :)
ilmari watched Aliens Live yesterday, it was great
in Royal Albert Hall with the Royal Philharmonic Concert Orchetra playing the score live
japhb That's ... really damn cool, actually. 17:47
viki lizmat: hm. Interesting. The 213 is what I got from git describe... the actual perl6 -v is This is Rakudo version 2016.10-207-g45236f1 17:48
lizmat ah, I know what it is 17:49
git describe tells me 2016.10-213-ge10f767
viki And the reason for that is likely 'cause my build was made by running make t/spec.... instead of full thing
lizmat could very well be that -199 was the last time I did a Configure.pl
viki yeah, prolly 17:50
nine ilmari: sounds pretty epic
lizmat do we have some docs on TWEAK ?
japhb is rather jealous ... that had to be an awesome experience (Aliens Live)
viki yeah, I now got 213 in perl6 -v after running perl Configure.pl --gen-moar --gen-nqp --backends=moar; make; make test; make install 17:51
lizmat remembers seeing Koyaanisqatsi live
viki: yup, same here 17:52
nine: do you have a writeup somewhere I can refer people to re lexical_module_loading ? 18:05
nine lizmat: sorry, no :( 18:16
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Use R:I:ALL_DEFINED_TYPE in [;] handling' 18:17
travis-ci.org/rakudo/rakudo/builds/173931704 github.com/rakudo/rakudo/compare/9...7c480df6c9
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. 18:18
viki t/04-nativecall/20-concurrent.t 18:19
And reprd on 4th run: ===SORRY!=== Cannot invoke this object (REPR: P6opaque; Scalar)
Slightly more info on the 20-concurrent.t crash: gist.github.com/zoffixznet/26cd878...04b53948e0 18:47
dogbert17 viki: could it be here github.com/rakudo/rakudo/blob/nom/...se.pm#L175 18:56
lizmat fwiw, that's where I've seen this fail as well, with "code" being null all of a sudden
timotimo when you get that kind of error, we have some kind of oversharing going on, or memory corruption or something like that 19:00
dogbert17 the second row in viki's gist seems to point to github.com/rakudo/rakudo/blob/nom/...er.pm#L163 19:02
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Revert "Use R:I:ALL_DEFINED_TYPE in [;] handling" 19:07
travis-ci.org/rakudo/rakudo/builds/173935016 github.com/rakudo/rakudo/compare/f...a3faa8df65
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
viki dogbert17: yeah, that's the line referenced by exception backtrace. 19:45
It's all above my head :'(
Well, I can follow jnthn++'s advice: golf it down 19:46
masak always golf it down 19:47
viki True.
arnsholt Golf it down should be the first step in almost any debugging routine, IMO
masak it's just Science: strangelyconsistent.org/blog/im-doi...till-alive 20:06
viki Interestingly, that test just hangs on my 32-bit 2-core box. 20:08
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Implement :kv,:p,:k,:v on 1 element multidim [;]' 20:10
travis-ci.org/rakudo/rakudo/builds/173944530 github.com/rakudo/rakudo/compare/2...4cfcd88248
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
viki OK. Well, I'm gonna give masak's broken window theory a go. 20:11
masak in the long run, I'd like for us to give it a structured consistent go in the form of some more or less formalized process :) 20:18
dalek kudo/nom: c68e85b | (Zoffix Znet)++ | t/04-nativecall/20-concurrent.t:
Temporarily skip flopping test

To quite down Travis IRC bot. Ticket opened as RT#130042:
  rt.perl.org/Ticket/Display.html?id=130042
20:22
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130042
kudo/nom: 62005f1 | (Zoffix Znet)++ | .travis.yml:
Quiet JVM Travis Failures

Frequent failures with java.lang.OutOfMemoryError. Opened ticket as RT#130043:
  rt.perl.org/Ticket/Display.html?id=130043
20:23
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130043
viki .tell psch I disabled JVM reporting again on Travis. It frequently gives OutOfMemoryError; dunno if it's just Travis? RT: rt.perl.org/Ticket/Display.html?id=130043 20:25
yoleaux2 viki: I'll pass your message to psch.
viki masak: yeah, maybe have buggable detect frequent failures and cry about it 20:28
.oO( hm, but then we're just making TWO bots assault us )
dalek kudo/nom: bf51eca | Xliff++ | src/core/DateTime.pm:
Suggested shortcut method similar to the Date methods in Datish.pm

If yyyy-dd-mm is a thing, then this at least adds consistency. ;)
20:49
kudo/nom: 25ef3d9 | (Zoffix Znet)++ | src/core/DateTime.pm:
Merge pull request #913 from Xliff/patch-3

Suggested shortcut method similar to the Date methods in Datish.pm
masak viki: maybe the same bot that reports the failure could also have some heuristic about tests flapping? 20:52
I dunno, just an idea
viki Yeah, probably.
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/11/07/...t-a-boost/ 21:05
fwiw, I cannot build JVM backend on OS X anymore either 21:10
Stage classfile : java.lang.OutOfMemoryError: PermGen space
in classfile (gen/jvm/stage2/NQPHLL.nqp:93)
travis-ci Rakudo build errored. Zoffix Znet 'Handle negative Mixy weights in ∪ operator 21:12
travis-ci.org/rakudo/rakudo/builds/173962369 github.com/rakudo/rakudo/compare/7...0f76758b09
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
timotimo ctrl-f TWEAK, no result :( 21:15
was it actually merged?
lizmat timotimo: no. afaik 21:19
timotimo ah, that explains it 21:20
jnthn lizmat: "He also fixed an issue with Lock.protect that would not release the lock if an exception occurred in the code being protected." - that'll confuse most people in so far as what they think of as exceptions worked totally fine :) 21:26
lizmat: It's control exceptions that were the issue
lizmat ah, like "next" and "last" and "return" ? 21:27
jnthn: ?
jnthn Yes, return was the particular case where I stubbed my toe on it :)
lizmat++ for the weekly :) 21:29
lizmat updated 21:31
m: say await start die
camelia rakudo-moar 25ef3d: OUTPUT«===SORRY!===␤Died␤»
lizmat hmmm... 21:32
m: say await start { die }
camelia rakudo-moar 25ef3d: OUTPUT«===SORRY!===␤Died␤»
lizmat m: say await start { LEAVE say "bye"; 42 } 21:34
camelia rakudo-moar 25ef3d: OUTPUT«bye␤42␤»
lizmat m: say await start { 42; LEAVE say "bye" } # this is wrong, I think
camelia rakudo-moar 25ef3d: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant integer 42 in sink context (line 1)␤bye␤Nil␤»
lizmat both for the warning, and the value being returned.
jnthn m: try await start { die }; say $!.WHAT 21:36
camelia rakudo-moar 25ef3d: OUTPUT«(AdHoc+{Broken})␤»
jnthn Huh, it's getting that bit right
m: try await start { die }; say $! 21:37
camelia rakudo-moar 25ef3d: OUTPUT«Tried to get the result of a broken Promise␤ in block <unit> at <tmp> line 1␤␤Original exception:␤ Died␤ in block at <tmp> line 1␤␤»
jnthn And that
So why on earth does it think it's a compile-time error?
geekosaur it's worse than that 21:38
lizmat m: say await start { die }; INIT say "foo" # the error is in the messaging
camelia rakudo-moar 25ef3d: OUTPUT«foo␤===SORRY!===␤Died␤»
geekosaur m: say 'hi'; say await start die;
camelia rakudo-moar 25ef3d: OUTPUT«hi␤===SORRY!===␤Died␤»
geekosaur so either it's using a SORRY preamble on a runtime message, or it's EVAL-ing something 21:40
jnthn Oh, I'm pretty sure it's in the "is this a compile time error" detection 21:42
afk for a bit
lizmat yeah, feels like that
travis-ci Rakudo build failed. Zoffix Znet 'Temporarily skip flopping test 22:14
travis-ci.org/rakudo/rakudo/builds/174014267 github.com/rakudo/rakudo/compare/e...8e85b4faf0
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
lizmat m: my @a = ^10; say @a.EXISTS-POS(-1) 22:26
camelia rakudo-moar 25ef3d: OUTPUT«False␤»
lizmat m: my @a[10] = ^10; say @a.EXISTS-POS(-1) # so is this the correct behaviour, or the previous one? 22:27
camelia rakudo-moar 25ef3d: OUTPUT«Index -1 for dimension 1 out of range (must be 0..9)␤ in block <unit> at <tmp> line 1␤␤»
lizmat ah, I see negative subscripts are caught by postcircumfix:<[ ]> code 22:28
dogbert17 lizmat: " In the lexical_module_loading branch, Stefan Seifert *as* fixed this." 22:29
lizmat dogbert17++ removed :-)
dogbert17 must be cached somehow, looks the same to me :) 22:31
lizmat forced reload fixed it for me 22:35
dogbert17 yeah it's gone now. lizmat++ Weekly
lizmat m: my str @a[3]; dd @a # jnthn: could it be we forgot native shaped str arrays ? 22:43
camelia rakudo-moar 25ef3d: OUTPUT«MultiDimArray: atpos expected string register␤ in block <unit> at <tmp> line 1␤␤»
lizmat I guess there's no VM support for it... 22:46
dalek kudo/nom: c000614 | lizmat++ | src/core/native_array.pm:
Mark native shaped str arrays as NYI
22:59
lizmat and with I wish #perl6-dev a good night!
*that 23:00
travis-ci Rakudo build errored. Zoffix Znet 'Quiet JVM Travis Failures 23:23
travis-ci.org/rakudo/rakudo/builds/174014787 github.com/rakudo/rakudo/compare/c...005f13b535
buggable [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only.
AlexDaniel hm, I've seen some run-time SORRY! errors before 23:38
not sure if there are any open tickets for that
m: say 42; *...‘WAT’; say 24 23:39
camelia rakudo-moar c00061: OUTPUT«42␤No such method 'succ' for invocant of type 'Whatever'␤ in block <unit> at <tmp> line 1␤␤»
AlexDaniel that's new
m: say 0, * ... "what"
camelia rakudo-moar c00061: OUTPUT«No such method 'pred' for invocant of type 'Whatever'␤ in block <unit> at <tmp> line 1␤␤»
AlexDaniel #128161 23:40
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128161
AlexDaniel bisect: *...‘WAT’
bisectable6 AlexDaniel, Bisecting by output (old=2015.12 new=c000614) because on both starting points the exit code is 1
AlexDaniel, bisect log: gist.github.com/816d9f3ea80621a679...8997e7ecc6
AlexDaniel, (2016-08-19) github.com/rakudo/rakudo/commit/25...b0673f26e2
AlexDaniel commit: 25e9fd76e85f^,25e9fd76e85f say 0, * ... "what" 23:41
committable6 AlexDaniel, ¦«25e9fd76e85f^»: ===SORRY!===␤Method 'pred' not found for invocant of class 'Whatever' «exit code = 1»␤¦«25e9fd7»: Method 'pred' not found for invocant of class 'Whatever'␤ in block <unit> at /tmp/UJmaNsyS3r line 1␤ «exit code = 1»
AlexDaniel yea, so it's no longer sorry after 25e9fd7 23:42