[Tux] This is Rakudo version 2016.10-104-gdb61aaa built on MoarVM version 2016.10-27-g196361f 07:43
csv-ip5xs 3.153
test 14.272
test-t 7.141
csv-parser 15.633
lizmat Files=1150, Tests=53695, 211 wallclock secs (12.73 usr 3.85 sys + 1285.24 cusr 122.27 csys = 1424.09 CPU) 08:46
m: my @a = (1,2),(3,4); my @b; @b.append(@a.pop); dd @a, @b # not entirely what I expected? 09:47
camelia rakudo-moar db61aa: OUTPUT«Array @a = [(1, 2),]␤Array @b = [(3, 4),]␤»
lizmat shouldn't that be @b = [3,4] ?
jnthn TimToady ^^^ ??
dalek kudo/nom: fe9e92a | lizmat++ | src/core/IO/Handle.pm:
Remove some superfluous Nil

If we have --> Nil, we don't have to return it as well		 09:49
jnthn m: my @a = (1,2),(3,4); dd @a.pop 10:21
yoleaux2 29 Oct 2016 02:06Z <japhb> jnthn: Created a new OO::Monitors issue (#8) ... monitor methods swallow ad hoc exceptions and throw a 'Cannot invoke this object (REPR: Null; VMNull)' error instead.
camelia rakudo-moar fe9e92: OUTPUT«List @a = $(3, 4)␤»
yoleaux2 29 Oct 2016 04:06Z <japhb> jnthn: Went on a golfing spree from a different angle trying to figure out the underlying bug that was catching up OO::Monitors; results added to issue #8 and are humerously insane.
jnthn lizmat: That's why.
(The List is in a Scalar continer, and append respects that) 10:22
lizmat aha, the difference between: 10:23
m: my @a; @a.append( (3,4) ); dd @a
camelia rakudo-moar fe9e92: OUTPUT«Array @a = [3, 4]␤»
lizmat and:
m: my @a; @a.append( (3,4).item ); dd @a
camelia rakudo-moar fe9e92: OUTPUT«Array @a = [(3, 4),]␤»
lizmat m: dd (3,4) 10:24
camelia rakudo-moar fe9e92: OUTPUT«(3, 4)␤»
lizmat m: dd (3,4).item
camelia rakudo-moar fe9e92: OUTPUT«$(3, 4)␤»
lizmat ok, gotcha
MasterDuke i was thinking about taking a break from BOOTSTRAP.nqp and play around with getting backtraces to give the actual source filename and line number (instead of m-CORE.setting) 12:32
but i'm not finding it obvious where/when that information is actually populated in a Backtrace::Frame 12:33
is that happening in moar? 12:34
dalek kudo/nom: 4986d68 | lizmat++ | src/core/IO/Spec/Unix.pm:
Properly handle / at beginning

The nqp::ord is nice and fast, but it is based on the base character of a grapheme. So it would also match on /'s adorned with accents.		 12:41
kudo/nom: fc47bbf | lizmat++ | src/core/Baggy.pm:
Make Baggy.roll()/pick() about 10% faster

Specifically on larger Bags/Mixes
lizmat MasterDuke: I think that's really in nqp::backtrace 12:42
afk&
dalek p: 2f839d7 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/io/FileHandle.java:
[jvm] Make nqp::open throw if directory is passed

Adjust to behaviour of MoarVM, cmp. #310		 12:57
p: e564489 | FROGGS++ | src/vm/jvm/runtime/org/perl6/nqp/io/FileHandle.java:
Merge pull request #316 from usev6/jvm_open_dir

  [jvm] Make nqp::open throw if directory is passed
bartolin huh, that was fast :-) 12:58
FROGGS :o) 13:00
nine MasterDuke: nqp most likely. File names and line numbers are annotations to QAST nodes 13:57
dalek ast: fc9a4a8 | usev6++ | S04-statements/for.t:
Add test for RT #123506
 14:15
ast: e783d93 | usev6++ | S (5 files):
Use ticket number RT #126524 for fudging
 14:30
ast: b06e156 | usev6++ | S12-introspection/attributes.t:
Add test for RT #127059
 16:20
FROGGS MasterDuke: I'd look in Exception.pm, there is a place where it walks the callstack, and is supposed to stop *before* reaching the setting... maybe it just does not stop early enough? (or perhaps too early) 16:25
lizmat FROGGS: I think that's in Backtrace.pm actually :) 17:03
FROGGS ohh yeah :o) 17:09
MasterDuke lizmat, nine, FROGGS_: yeah, i've been looking at Exception.pm, Backtrace.pm, and CallFrame.pm at the Perl 6 level. nqp::backtrace just seems to be mapped to MVM_exception_backtrace and it adds the annotations that are read at the Perl 6 level (if i'm interpreting things correctly) 17:25
lizmat MasterDuke: fwiw, I think that whole area is due for a refactor 17:26
it makes warnings *way* too expensive
MasterDuke lizmat: refactoring the whole area may be beyond my scope at this point. and in fact, i suspect all of the thoughts i've had so far on how to reference the original files would slow things down. but hey, if i manage to implement it, i have no doubt you can speed it up 17:33
lizmat one can hope :-)
mst warnings being expensive is useful though, it slows the program down so you have longer before they fill the log partition 17:40
lizmat true, but I'd rather make them fast and then slow artificially somehow, then waisting a lot of CPU needlessly as well 17:43
m: say "foo bar baz".samespace(" ") # TimToady: sorta expected to have the last whitespace "stick", so "foo bar baz" as result ?
camelia rakudo-moar fc47bb: OUTPUT«foo bar baz␤»
lizmat m: use nqp; say nqp::where($/); for 42 { say "foo".match(/foo/); say nqp::where($/); say $/ } # inner $/ =:= outer $/ 18:33
camelia rakudo-moar fc47bb: OUTPUT«29965056␤｢foo｣␤29965056␤Nil␤»
lizmat star: use nqp; say nqp::where($/); for 42 { say "foo".match(/foo/); say nqp::where($/); say $/ } # inner $/ is DIFFERENT from outer $/
camelia star-m 2016.04: OUTPUT«47089312␤｢foo｣␤140664756450384␤｢foo｣␤»
lizmat so it looks like .match is assigning to a $/ in the blue 18:34
"ins blaue hinein" 18:36
dalek ast: 9fbdcc0 | usev6++ | S04-statements/loop.t:
Add test for RT #127238
 18:37
lizmat m: for "foo" { /foo/; say $/ } # *sigh*, this does work 18:39
camelia rakudo-moar fc47bb: OUTPUT«｢foo｣␤»
lizmat m: for "foo" { .match(/foo/); say $/ } # this doesn't :-(
camelia rakudo-moar fc47bb: OUTPUT«Nil␤»
lizmat m: use nqp; say nqp::where($/); for "foo" { my $/; say nqp::where($/); say .match(/foo/); say $/; say nqp::where($/) } # the second $/ in the body of the for is different 18:59
camelia rakudo-moar fc47bb: OUTPUT«26938112␤26938568␤｢foo｣␤｢foo｣␤139623261592488␤»
lizmat m: use nqp; say nqp::where($/); for "foo" { say nqp::where($/); say .match(/foo/); say $/; say nqp::where($/) } # the second $/ in the body of the for is different
camelia rakudo-moar fc47bb: OUTPUT«19614464␤19614464␤｢foo｣␤Nil␤19614464␤»
lizmat and now they're *all* the same
MasterDuke bisect: for 42 { say "foo".match(/foo/); say $/ } 19:05
bisectable6 MasterDuke, Bisecting by output (old=2015.12 new=fc47bbf) because on both starting points the exit code is 0
MasterDuke, bisect log: gist.github.com/641e9c5b129a8b88d3...c9e5a4948d 19:06
MasterDuke, (2016-10-23) github.com/rakudo/rakudo/commit/b7...e8f5c77f41
lizmat MasterDuke: yeah, I already established that 19:09
:-(
MasterDuke oops, missed that
lizmat yet, the same code running in an augment class Str with slighlty different naming to prevent clashes, works as expected :-( 19:10
FROGGS_ lizmat: is that class also Cool?
lizmat it's an "augment class Str" 19:11
FROGGS_ because the code that is failing here might involve Cool.match
ahh, okay
lizmat so it's just adding stuff to it
I mean, in the for { } case, the $/ outside of the for, and inside the body of the for, should be the same $/ 19:12
and looking at debug code with nqp::where, they are 19:13
m: $/ = 42; for "foo" { .match(/foo/; say $/ }; say $/ 19:15
camelia rakudo-moar fc47bb: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unable to parse expression in argument list; couldn't find final ')' ␤at <tmp>:1␤------> = 42; for "foo" { .match(/foo/; say $/ ⏏}; say $/␤ expecting any of:␤ postfix␤»
lizmat m: $/ = 42; for "foo" { .match(/foo/); say $/ }; say $/
camelia rakudo-moar fc47bb: OUTPUT«42␤42␤»
lizmat so the .match is just not assigning :-( 19:16
if I add debug code in the private method that does the assigning, it sees the correct nqp::where 19:17
FROGGS_ and it is not spesh related? 19:18
lizmat gist.github.com/lizmat/4dd5117f34f...8b297d8b19 19:19
doesn't appear to be
(added diff) 19:20
FROGGS_: MVM_SPESH_DISABLE=1 to disable spesh and all optimizations, no? 19:33
or also --optimize=0 ?
FROGGS_ correct 19:34
lizmat no difference :-(
FROGGS_ though, the setting gets compiled with --optimize=3, and you cannot set it to 0 IIRC
lizmat well, that's the thing: outside of the setting, the code works correctly 19:35
and that's with --optimize=3, right ?
FROGGS_ true
lizmat so, whenever I introspect, I see that the correct $/ is being used
yet, it does not get assigned 19:36
FROGGS_ okay, you've changed getlexcaller to getlexdyn, right? 19:37
lizmat yes, but changing it back doesn't change anything
FROGGS_ when I read both descriptions: github.com/perl6/nqp/blob/master/d...#getlexdyn
they do different things
lizmat so what is the difference? the description doesn't make it clear to me 19:38
FROGGS_ I guess we need getlexrelcaller now, starting with a calling context 19:42
because you also turned method match into a multi
and that introduces a callframe, at least for these nqp ops
so I'd try: nqp::getlexrelcaller(nqp::ctxcaller(nqp::ctx()), '$/')
lizmat ok, will do
FROGGS_ getlexdyn just looks at the caller of the caller of the caller of the... 19:43
an the other one looks at the outer of the outer [...] of your caller
lizmat FROGGS_: but I don't think it is a lookup problem: the gist shows that the $/ is the $/ of the outer scope (outside of the for {} ) 19:47
and I made sure the proto has its $/ set to its outer $/
*aliased to
replacing getlexdyn with nqp::getlexrelcaller(nqp::ctxcaller(nqp::ctx()), '$/') doesn't fix it :-( 19:48
.oO( make up das mind, viki :-)
FROGGS_ damn 19:49
no idea then
dalek kudo/nom: d92222f | usev6++ | src/core/Date.pm:
Revert "At least temporary fix for RT #127161"

This reverts commit d80c728e257dbe17384c48c9a6e516158e6627a4.
This temporary fix is no longer needed, since a workaround for the underlying problem was added with commit 986891f7ea
kudo/nom: c9730a2 | (Zoffix Znet)++ | src/core/Date.pm:
Merge pull request #910 from usev6/rt127161

Revert "At least temporary fix for RT #127161" d3a0907 | lizmat++ | src/core/Any.pm: Make 2d/3d array accesses about 7x as fast
By adding candidates handling ($,$) and ($,$,$) and adding the necessary code for AT-POS, EXISTS-POS, DELETE-POS, ASSIGN-POS and BIND-POS
lizmat m: for "foo" { say nqp::where($/); /foo/; say $/; say nqp::where($/) } 19:54
camelia rakudo-moar fc47bb: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Could not find nqp::where, did you forget 'use nqp;' ?␤at <tmp>:1␤------> for "foo" { say nqp::where($/)⏏; /foo/; say $/; say nqp::where($/) }␤»
lizmat m: use nqp; for "foo" { say nqp::where($/); /foo/; say $/; say nqp::where($/) }
camelia rakudo-moar fc47bb: OUTPUT«41724672␤｢foo｣␤140161577709608␤»
lizmat FROGGS_: note that in this case the memory address of $/ changed *after* the match 19:55
*within* the same scope!
hmmm... could be a code gen issue for /foo/, I guess 19:56
FROGGS_ or due to GC the $/ gets moved in memory 19:57
I dunno, really 19:58
lizmat well, I guess I'm going to sleep a night over this, hoping jnthn will have some insight in the morrow 20:01
because at the moment, I'm uberfragt
FROGGS_ aye
lizmat and reverting the Str.match opts would be painful :-( 20:02
lizmat goes back to proofreading
FROGGS_ yeah... I guess there will be a better solution than this 20:06
bartolin bisect: constant $R = /f(oo)/; say so "foo" ~~ $R; say ~$0 # RT #126969 20:19
bisectable6 bartolin, Bisecting by output (old=2015.12 new=fc47bbf) because on both starting points the exit code is 0 20:20
bartolin, bisect log: gist.github.com/310260c8822acd531b...cd0be0aada
bartolin, (2016-09-01) github.com/rakudo/rakudo/commit/63...6892a7df4f
lizmat looks like a false positive to me
bartolin m: constant $R = /f(oo)/; say so "foo" ~~ $R; say ~$0 20:21
camelia rakudo-moar c9730a: OUTPUT«True␤oo␤»
bartolin nods
lizmat bartolin: that looks correct, no ? 20:22
bartolin yes, it does. I wonder what's the latest commit bisectable6 knows
MasterDuke it's just two off from HEAD (usev6 reverting d80c728e257dbe17384c48c9a6e516158e6627a4) 20:27
fyi, it says in the output "new=fc47bbf" 20:28
bartolin oops, my fault. I looked for fc47bbf, but my local rakudo is too old *g* 20:29
MasterDuke++
MasterDuke pebkac! 20:30
bartolin bisect: good=fc47bbf bad=631e2f770e constant $R = /f(oo)/; say so "foo" ~~ $R; say ~$0 # RT #126969 20:34
bisectable6 bartolin, bisect log: gist.github.com/2c916177c8bd2a2226...97c80d7675
bartolin, bisect init failure
bartolin :-/ 20:35
one last try ...
bisect: good=631e2f770e bad=fc47bbf constant $R = /f(oo)/; say so "foo" ~~ $R; say ~$0 # RT #126969 20:36
bisectable6 bartolin, Bisecting by output (old=631e2f7 new=fc47bbf) because on both starting points the exit code is 0
bartolin, bisect log: gist.github.com/d48431a920b3d40eac...740fd02375
bartolin, (2016-10-27) github.com/rakudo/rakudo/commit/5a...925c544ea4
bartolin ha, that looks better 20:37
lizmat m: say 42[0;0;0;0] # do we really want to hang off multi-dim indexing off off Any.AT-POS ? 21:01
camelia rakudo-moar c9730a: OUTPUT«42␤»
lizmat *of off 21:02
I guess that's to allow for any AT-POS capable class to be intermixed, eh? 21:11
kudo/nom: 4fdf6d7 | lizmat++ | src/core/Any.pm:
Correct AT-POS cs signature to only do Any:D:

This broke BIND-POS, so the two/three-dimensional cases have been removed (will revisit at a later time)		 22:09
lizmat good night, #perl6-dev! 22:19
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Correct AT-POS cs signature to only do Any:D: 23:06
travis-ci.org/rakudo/rakudo/builds/171849317 github.com/rakudo/rakudo/compare/d...df6d7721a6
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0). All failures are on JVM only.

Powered by Cro and the Raku® Programming Language.

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

Thank you!