Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
releasable6 Next release in ≈2 days and ≈11 hours. 5 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
[Tux] Rakudo version 2018.12-230-gbb36f04a6 - MoarVM version 2018.12-31-geccbc8541
csv-ip5xs0.767 - 0.772
csv-ip5xs-206.681 - 6.820
csv-parser23.113 - 23.896
csv-test-xs-200.432 - 0.434
test8.134 - 8.163
test-t1.815 - 1.875
test-t --race0.848 - 0.879
test-t-2029.908 - 30.469
test-t-20 --race10.085 - 10.312
 08:04
lizmat Files=1265, Tests=88016, 382 wallclock secs (20.23 usr 5.98 sys + 2724.97 cusr 228.74 csys = 2979.92 CPU) 09:20
AlexDaniel releasable6: status 14:25
releasable6 AlexDaniel, Next release in ≈2 days and ≈4 hours. 5 blockers. 109 out of 230 commits logged (⚠ 41 warnings)
AlexDaniel, Details: gist.github.com/0cb9a178389c15ce93...7fb00c34e7
AlexDaniel pmurias: I think you were planning to log your changes :)
cfa thanks for the reply jnthn; AlexDaniel`: i re-patched URI::Encode, this one might be a better fix 15:41
cfa hmm 15:55
Geth rakudo: 5d70797742 | (Jonathan Worthington)++ | src/core/control.pm6
Add an `is raw` onto the THROW helper

It's always called from within another control exception sub, which can do the correct thing with the return value. Avoids some decont logic on each use of `THROW`; given control exceptions don't really return in the common case, this will only really help much with things like `take`, although it does make the code smaller, and - thanks to `THROW` being a juicy inline target - will make everything it's inlined into smaller too.		 16:34
jnthn github.com/rakudo/rakudo/issues/2606 is resolved thanks to MoarVM fixes 16:36
(That was one of the release blockers)
cfa re: rx, lexical topic, github.com/perl6-community-modules...de/pull/11 is a simpler fix for now 16:38
$rx => /$rx/ seems problematic (at least, there are coercion warnings which make me hesitant to commit as is)
#11 should be fairly innocuous
(colabti.org/irclogger/irclogger_lo...1-17#l825) 16:40
AlexDaniel wait uh, so just sticking v6.c in there fixes the thing? 19:28
jnthn: isn't it weird? 19:29
but if it is so, then it's a non-issue, right?
cfa AlexDaniel: 6.c isn't lexically scoping $_ 19:57
see github.com/rakudo/rakudo/issues/26...-454085241
so in specifying the version we hit case (i) rather than (ii)
without having to change anything else
at least, that's my understanding of the situation---if we don't specify a version then we have to ensure that topic capture is done inside the map sub scope 19:58
situation for URI::Encode, that is 20:00
jnthn AlexDaniel: 6.d by spec allows the optimizer to do something that 6.c by spec did not. I made sure when I did the work to respect `use v6.c`. 20:13
cfa jnthn++ :) 20:19
i should really mention that i only realised the simpler patch was possible from jnthn's #2, github.com/rakudo/rakudo/issues/26...-455200826 20:20
hence closing the older pr, opening this one
AlexDaniel: tested under HEAD, passes
AlexDaniel c: 2018.12,HEAD use v6.c; my token blah { foo }; dd ("foo").grep: { /<blah>/ } 22:56
committable6 AlexDaniel, ¦2018.12: «("foo",).Seq␤» ¦HEAD(5d70797): «().Seq␤»
AlexDaniel bisect: old=2018.12 use v6.c; my token blah { foo }; dd ("foo").grep: { /<blah>/ }
bisectable6 AlexDaniel, Bisecting by output (old=2018.12 new=5d70797) because on both starting points the exit code is 0
AlexDaniel, bisect log: gist.github.com/37e92ebd6710533dba...dfe260dcbc
AlexDaniel, (2019-01-03) github.com/rakudo/rakudo/commit/eb...2c4dbcd9b2
jnthn ...how does that work in the first place? 22:58
Does grep set $_? 22:59
AlexDaniel c: 2018.12,HEAD use v6.c; my token blah { foo }; dd ("foo").grep: -> $_ { /<blah>/ }
committable6 AlexDaniel, ¦2018.12: «("foo",).Seq␤» ¦HEAD(5d70797): «().Seq␤»
AlexDaniel c: 2018.12,HEAD use v6.c; my token blah { foo }; dd ("foo").grep: -> $_ { $_ ~~ /<blah>/ }
committable6 AlexDaniel, ¦2018.12,HEAD(5d70797): «("foo",).Seq␤»
AlexDaniel c: 2018.12,HEAD use v6.c; my token blah { foo }; dd ("foo").grep: -> { /<blah>/ } 23:00
committable6 AlexDaniel, ¦2018.12,HEAD(5d70797): «Too many positionals passed; expected 0 arguments but got 1␤ in block <unit> at /tmp/X2uYIdHg2E line 1␤␤ «exit code = 1»»
AlexDaniel jnthn: nah it just passes it to the block
jnthn AlexDaniel: But the regex isn't evaluated in the block?
It's returned from the block and boolified inside of grep
AlexDaniel oooh
c: 2018.12,HEAD use v6.c; my token blah { foo }; dd ("foo").grep: { so /<blah>/ } 23:01
committable6 AlexDaniel, ¦2018.12,HEAD(5d70797): «("foo",).Seq␤»
AlexDaniel riiight
jnthn Thus my question "is grep setting $_"?
AlexDaniel now that I look at it, it's a weird piece of code… never thought about it…
jnthn And we compile the setting with full optimizations on, and grep is in the setting, so the use v6.c in the program won't make a bit of difference
Yeah, it's obvious until you think about it :P
AlexDaniel c: 2018.12,HEAD use v6.c; my token blah { foo }; dd ("foo").grep: /<blah>/ 23:02
committable6 AlexDaniel, ¦2018.12,HEAD(5d70797): «("foo",).Seq␤»
AlexDaniel that should make the golf smaller
c: 2018.12,HEAD use v6.c; dd ("foo").grep: /<foo>/ 23:03
committable6 AlexDaniel, ¦2018.12,HEAD(5d70797): «No such method 'foo' for invocant of type 'Match'␤ in block <unit> at /tmp/ZiK5eDdJeL line 1␤␤ «exit code = 1»»
AlexDaniel c: 2018.12,HEAD use v6.c; dd ("foo").grep: /foo/
committable6 AlexDaniel, ¦2018.12,HEAD(5d70797): «("foo",).Seq␤»
AlexDaniel c: 2018.12,HEAD use v6.c; dd ("foo").grep: { /foo/ }
committable6 AlexDaniel, ¦2018.12: «("foo",).Seq␤» ¦HEAD(5d70797): «().Seq␤»
AlexDaniel there
jnthn { nqp::if($test($_),$_,Empty) }, 23:04
That's how it worked 23:05
AlexDaniel anyway it's R#2614
b2gills AlexDaniel: Regexes are code in Perl6
jnthn Yeah, this one I'll find a fix for of some kind 23:06
AlexDaniel aaaaand 6 more modules ahead… 23:08
jnthn builds an attempted fix 23:13
jnthn m: use Test; is-deeply ("foo").grep({ /foo/ }), ("foo",) 23:15
camelia not ok 1 -
# Failed test at <tmp> line 1
# expected: $("foo",)
# got: $( )
AlexDaniel lizmat: hello! 23:17
jnthn Fix works, now waiting on spectest, which on this machine is about twice as long as at the office 23:19
Added the above case as a spectest too 23:20
This worked for pretty terrible reasons, but I don't really want to try arguing it shouldn't DWIM when there's an easy enough fix...
lizmat AlexDaniel: hello, just back from NR.PM meeting 23:21
AlexDaniel lizmat: maybe this is something that will be easy to figure out for you: github.com/rakudo/rakudo/issues/2615 23:22
something about .succ, I'm not sure 23:23
lizmat too tired now, will look at it first thing tomorrow 23:24
AlexDaniel uhhh also P5tie fails after github.com/rakudo/rakudo/commit/68...1cc36e34de 23:35
Geth rakudo: lizmat self-assigned Weird issue with Date creation and Date::WorkdayCalendar module github.com/rakudo/rakudo/issues/2615
f71ca0de12 | (Jonathan Worthington)++ | src/core/Any-iterable-methods.pm6

This worked for the slightly dubious reason that `grep` happened to set
  `$_`, and boolify the regex that was returned. This was relying on an
implementation detail - there's nothing that says `grep` has to have the test element in its `$_` - however there's code in the wild that relies on this construct, and it's hard to argue that it shouldn't DWIM. ... (9 more lines)
roast: ae6ebade28 | (Jonathan Worthington)++ | S32-list/grep.t
Test .grep: { /foo/ }

Covers github.com/rakudo/rakudo/issues/2614.
AlexDaniel jnthn++ 23:43
lizmat this last fix doesn't fix P5tie :-(
jnthn AlexDaniel: How confident are you in the bissect result of github.com/rakudo/rakudo/issues/2616 ?
lizmat will also look at that tomorrow
jnthn I think I'm going to fix P5tie by just making `use P5.*` eliminate a much broader swathe of optimizations :)
AlexDaniel jnthn: 0% confident… one second… 23:44
lizmat jnthn: well, I could just also just drop all of the P5 modules that use $_ dynamically from CPAN
jnthn lizmat: I guess if people use them as a porting aid, they can live with things being a bit slower until they switch to native Perl 6 constructs, though? 23:45
AlexDaniel ok maybe a some more seconds… the test passes when it's in the same file (?!)
jnthn lizmat: This one isn't use $_ dynamically
lizmat ah
jnthn I think it's this:
github.com/lizmat/P5tie/blob/maste...ie.pm6#L35
The comment is accurate ;)
AlexDaniel c: 685f6cc^,685f6cc gist.github.com/AlexDaniel/674e67f...26e1bef615 23:46
committable6 AlexDaniel, Using file “scalar.p6” as a main file, other files are placed in “sandbox/”
jnthn I'm surprised that BIND-KEY is allowed though, given the variable is not `is dynamic`
committable6 AlexDaniel, ¦685f6cc^,685f6cc: «not ok 1 - did we get Int␤# Failed test 'did we get Int'␤# at sandbox/scalar.p6 line 17␤# expected: (Int)␤# got: (Any)␤ «exit code = 1»»
jnthn AlexDaniel: If you place things in the same file, the presence of CALLER:: will poison all kinds of opts
AlexDaniel: It actually just looks for any use of a pseudostash and poisons them 23:47
AlexDaniel c: 2018.12 gist.github.com/AlexDaniel/674e67f...26e1bef615
committable6 AlexDaniel, Using file “scalar.p6” as a main file, other files are placed in “sandbox/”
AlexDaniel, ¦2018.12: «ok 1 - did we get Int␤»
AlexDaniel well ok let's try this then…
bisect: old=2018.12 gist.github.com/AlexDaniel/674e67f...26e1bef615
bisectable6 AlexDaniel, Using file “scalar.p6” as a main file, other files are placed in “sandbox/”
AlexDaniel, Bisecting by exit code (old=2018.12 new=f71ca0d). Old exit code: 0
jnthn lizmat: Anyway, it looks like BIND-KEY isn't even checking if the thing is `is dynamic`, so this arguably shouldn't have worked before now. 23:48
lizmat what and how should it check ? 23:49
bisectable6 AlexDaniel, bisect log: gist.github.com/59a3d9a9dd40009056...8badb5fc4d
AlexDaniel, There are 2 candidates for the first “new” revision. See the log for more details
jnthn lizmat: Well, one way would be to see what's there now, though I'm kind of thinking about starting to attach static information to frames about what dynamic symbols they have, since we actually have other problems in this area. 23:50
AlexDaniel c: e73853a1^,e73853a1,c28a0924 gist.github.com/AlexDaniel/674e67f...26e1bef615
committable6 AlexDaniel, Using file “scalar.p6” as a main file, other files are placed in “sandbox/”
AlexDaniel, gist.github.com/384dda83bbb41117a0...901cc967cc 23:51
jnthn m: class C { method m { say CALLER::<$foo> } }; { my $foo is dynamic = 42; C.m }
camelia 42
lizmat jnthn: I always assumed they already did
jnthn m: class C { method m { say CALLER::<$foo> } }; { my $foo is dynamic := 42; C.m }
camelia 42
jnthn Hm, I wonder how that one works too
AlexDaniel jnthn: hm I wonder why Blin managed to complain about a different commit… this last result is correct though 23:52
jnthn lizmat: No, at the moment we look up the variable, do .VAR on it, and check .dynamic
lizmat and then die if it isn't dynamic ?
jnthn Yeah, but I don't really follow how the bound case works today 23:53
I'll have to dig into it
I think we're doing a good amount of cheating.
lizmat also: I've always understood that CALLER:: and friends had nothing to do with being dynamic or not
jnthn CALLER:: should only be allowed on things declared `is dynamic`
lizmat I've always understood that to be a kind of PadWalker
jnthn m: class C { method m { say CALLER::<$foo> } }; { my $foo = 42; C.m } 23:54
camelia Cannot access '$foo' through CALLER, because it is not declared as dynamic
in method m at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn m: class C { method m { say CALLER::<$foo> } }; { my $foo := 42; C.m }
camelia Cannot access '$foo' through CALLER, because it is not declared as dynamic
in method m at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn m: class C { method m { say CALLER::<$foo> } }; { my $foo is dynamic := 42; C.m }
camelia 42
jnthn Huh, I wonder how it knows the difference there...
jnthn m: class C { method m { say CALLER::<$foo>.VAR } }; { my $foo is dynamic := 42; C.m } 23:55
camelia 42
AlexDaniel yeah, Blin--, unfortunately
lizmat "CALLERContextual symbols in the immediate caller's lexical scope" 23:55
doesn't say anything about having to be dynamic
jnthn lizmat: But anyway, it was intended all the way back in the design docs that things had to be "is dynamic"
"Contextual variable" is the old word for "dynamic variable" 23:56
jnthn Or a synonym at least 23:56
I guess "environmental variable" is the term for them that absolutely didn't survive.
(I think it was dropped 10 years ago or so... :)) 23:57
Anyway, the intent absolutely is things have to be `is dynamic`, and there's even spectets to that effect.
lizmat m: sub a() { dd CALLER::.keys }; a # shouldn't this list less then ? 23:58
camelia ("!UNIT_MARKER", "\&a", "GLOBALish", "\$=pod", "\$!", "\$=finish", "\$?PACKAGE", "EXPORT", "::?PACKAGE", "\$¢", "\$_", "\$/").Seq
jnthn Yup :) 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!