[Tux] This is Rakudo version 2016.09-166-gf117a61 built on MoarVM version 2016.09-39-g688796b 06:22
csv-ip5xs 3.247
test 15.957
test-t 6.959
csv-parser 18.170
lizmat below 7 again :-) 07:32
afk& 08:34
Zoffix Anyone on arch? What rakudo version is in the repo? 10:43
Nothing's showing up in search www.archlinux.org/packages/?sort=&...p;flagged= 10:45
dalek p: 3ca32a5 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
[js] Generate generalized accessors for nqp::getattr and nqp::bindattr ops.
 10:46
p: 80327cb | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Speed up the setting of defaults values for native attributes by generating code for that.
p: a92c7ad | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Generate attr accessors to speed things up.
p: 00aaf68 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Delete dead code.
Zoffix ( was just wondering what this feller was trying to use www.reddit.com/r/perl6/comments/56...ms/d8mvlgk )
psch_ Zoffix: the arch user repo is aur.archlinux.org so they're probably using aur.archlinux.org/packages/panda/ 10:52
Zoffix Thanks. 10:53
They look fresh. Weird they weren't working for that person. 10:54
psch well, it might also be aur.archlinux.org/packages/perl6-panda/ 10:55
note the former has the latter as prereq, as well as Shell::Command 10:56
so, yeah, dunno
Zoffix "I destroyed my system and for some reason perl6 doesn't work right. It's too raw".... I suspect it's a case of that :} 10:57
psch dunno, arch always felt pretty destruction-proof to me
compared to gentoo at least :P
anyway, yeah, the error looks like they're using the latter package 10:58
because yeah, prereqs vOv
or dependencies or whatever :P
p3rln00b ZOFVM: Files=1195, Tests=129675, 128 wallclock secs (21.30 usr 3.18 sys + 2367.44 cusr 193.01 csys = 2584.93 CPU) 12:24
Just curious: have any dates been mulled over for 6.d release? 13:26
jnthn I think TimToady mumbled something about next summer, which feels reasonable to me also 13:33
p3rln00b nods 13:34
[Coke] if we're aiming at summer, we should try to have a plan in place by the end of the year 13:39
dalek ast: 07d14e2 | (Zoffix Znet)++ | S03-junctions/misc.t:
[coverage] Cover Junction.new
 13:49
jdv79_ is there a way to explicitly pay for a bug to be fixed?:) 14:13
p3rln00b m: say .from, .to given (class { method from { 'this ' } }, class { method to { 'is obscene' } })
camelia rakudo-moar f117a6: OUTPUT«this is obscene␤»
p3rln00b jdv79: what bug?
jdv79 i've been blocked on a bug for months now and i can't fix it myself
its async related
p3rln00b jdv79: what's the RT number?
jdv79 its probbably a few different issues but the bug report says it i think. 14:14
i need to find it
p3rln00b List.from and List.to make me squirm a little :( 14:16
jdv79 128833
p3rln00b RT#128833
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128833
jdv79 just updated and basically the same results 14:17
p3rln00b Reproduced on my VM: gist.github.com/zoffixznet/3d286a2...63fe594a8b 14:21
Over my head to fix it though :) ... Yet! 14:22
timotimo Message body is not shown because it is too large. - F you, RT :\
p3rln00b timotimo: rt.perl.org/Ticket/Attachment/1414725/764551/
timotimo yeah, i know 14:23
but still ...
jdv79: i'll have a quick look, but i'm usually not good at finding this stuff out 14:26
nine Referring to yesterday's discussion about source files/line numbers of CORE: I cannot see any downside of pointing at the actual source files. It sure wouldn't affect runtime and supporting file/line markers in the compiler will probably have a negligible cost. That you need to know the exact version for it to be useful is a red herring. Same is true for the concatenated source file.
It's usually the version in my checkout anyway. Or if I've installed rakudo from OS packages, I just do zypper si rakudo do get the exact same source. 14:27
jdv79 p3rln00b: thanks anyway 14:29
timotimo: thanks
p3rln00b nine: what do you mean: "Same is true for the concatenated source file."? 14:34
I can open concatenated file and find the code that's run.
s: &say 14:35
SourceBaby p3rln00b, Sauce is at github.com/rakudo/rakudo/blob/f117...ors.pm#L20
p3rln00b ^ that's what the bot does. I can do it programmatically.
nine If you can open the gen/moar/m-CORE.setting and be sure it's the right one, you can open the real source file with the same sureness.
p3rln00b I don't have real source file. 14:36
nine Why would you not have the real source file but would have a build artifact? 14:37
p3rln00b Is it just an artifact?
nine Regardless of which software, if I have a source file name + line number, I usually can get the source file and look at that line. Why would rakudo be any different?
m-CORE.setting is a build artifact. That's why it nowadays is in a gen/ directory. It's generated during the build? 14:38
psch CORE.setting is a build artifact, yes. it's concatenated so we don't need module loading and name space code during bootstrapping
at least that's my understanding
p3rln00b OK then 14:39
psch s/bootstrapping/core compilation/
although i suppose the same argument could be made for Metamodel vOv
p3rln00b I thought setting was part of normal install 14:40
nine psch: the most important reason is probably that we can't use forward declarations between different compilation units
p3rln00b MasterDuke: ^
nine p3rln00b: no, why would it? 14:41
psch nine: oh, right, stubbing was the reason. thanks for clearing that up
p3rln00b nine: ¯\_(ツ)_/¯ I saw it in my install dir and assumed 14:42
psch p3rln00b: CORE.setting.nqp?
...wait it doesn't have .nqp in gen i think
anyway, my $prefix for r-j has CORE.setting.jar 14:43
and the rakudo checkout has gen/jvm/CORE.setting
which is the concatenated pm files
nine If anything, the real source file is easier to access. To get at it, a normal user would just have to install the source package. To get at m-CORE.setting, you have to execute at least parts of the build.
psch (not nqp... i probably really should walk away for today, can't make into thinking good :P )
timotimo ... how do you debug this stuff ... 14:44
p3rln00b j: &say.file.say
camelia rakudo-jvm 2a1605: OUTPUT«unknown␤»
psch m: &say.file.say
camelia rakudo-moar f117a6: OUTPUT«gen/moar/m-CORE.setting␤»
psch ...different kinds of annotation?
arnsholt I agree. I can't see any reason to use CORE.setting coordinates, if we can provide equivalent coordinates in the actual source files
jnthn timotimo: Concurrency things? With a loooot of patience :) 14:45
p3rln00b jnthn: but what tools do you use?
p3rln00b has a loooooot of patients. I could use a brain tho :P
arnsholt Going through the indirection of CORE.setting when debugging core stuff has always been an annoyance if you ask me
timotimo yeah, but how do i even start?
when it doesn't crash in valgrind, instead we just have corrupt data at the perl6 level ... 14:46
jnthn p3rln00b: Depends enormously on the kind of bug. If it's a hang, attach with gdb to get the high-level backtraces. Sometimes the MoarVM cross-thread write logging can show up suspicious things. A lot of the time, it's a case of golfing it down though.
Looking at the code-gen of the golf has sometimes showed up missing closure cloning 14:47
I've got a branch that fixed a couple of those, but along the way regressed a spectest...
But the missing clones can cause over-sharing of state 14:48
Other times it's been stranger stuff yet (I had one case where a $/ was accidnetally shared due to it not being propagated, for example) 14:49
If we want better tooling for hunting this stuff, then we'll need to do the trickier task of implementing a real data race detector. 14:50
(Since the cross-thread write logging thing turns up various false positives) 14:51
p3rln00b sounds fancy 14:52
timotimo oh, mostly just "add_to_cache" :P 14:53
jnthn Yeah, that one is benign, for example. 14:54
pmurias anyone opposed to hidding empty flags for a QAST::Node (so in effect turn "<>" in the output into "")? 14:59
dalek kudo/nom: bfe6219 | (Zoffix Znet)++ | src/core/List.pm:
Fix proto of infix:<xx>

The current proto does not match the () and ($) candidates.		 15:02
timotimo ASAN doesn't spit out anything for this bug 15:04
FROGGS o/ 15:07
p3rln00b m: sub foo {rand}; say &foo xx 2 15:10
camelia rakudo-moar f117a6: OUTPUT«(sub foo () { #`(Sub|77046384) ... } sub foo () { #`(Sub|77046384) ... })␤»
p3rln00b m: sub foo {rand}; say infix:<xx>(&foo, 2)
camelia rakudo-moar f117a6: OUTPUT«(0.145600101934383 0.556302076395789)␤»
p3rln00b I'm guessing the A xx B version is doing some magics
psch m: sub foo {rand}; say foo xx 2 15:11
camelia rakudo-moar f117a6: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Undeclared routine:␤ xx used at line 1␤␤»
psch m: sub foo {rand}; say foo() xx 2
camelia rakudo-moar bfe621: OUTPUT«(0.49677774614035 0.715203940340046)␤»
psch p3rln00b: i don't see any magic. you're just nouning the sub
p3rln00b: and (i think) LTM is why it can't warn about needing parens
p3rln00b psch: I see magic. Any other thing will use the return value of foo() as argument 15:12
m: sub infix:<Δ> { dd [$^a, $^b] }; sub foo {rand}; foo() Δ 2 15:13
camelia rakudo-moar bfe621: OUTPUT«[0.94687149208834e0, 2]␤»
timotimo the magic is in xx thunking its LHS
psch p3rln00b: oh, that. yeah xx thunks the lhs
p3rln00b OK
dalek ast: 693052d | (Zoffix Znet)++ | S03-operators/repeat.t:
[coverage] cover List.[to|from] and infix:<xx> candidates
 15:17
ast: 33c09fc | (Zoffix Znet)++ | S0 (2 files):
Move test to better place
 15:21
b2gills m: say &[xx](5).perl; say &[xx](5,1).perl; say (5 xx 1).perl; # is there a good reason the one-arg version doesn't return a list? 15:23
camelia rakudo-moar bfe621: OUTPUT«5␤(5,)␤(5,)␤»
lizmat b2gills: yes, because you want to be consistent 15:24
xx always returns a list
b2gills &[xx](5) returns 5 not (5,)
lizmat m: dd 5 xx 0
camelia rakudo-moar bfe621: OUTPUT«()␤»
lizmat m: dd 5 xx 1 15:25
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
b2gills m: say [xx] 5
p3rln00b &[xx](5) is a 1-arg version that was uncallable until about 10 minutes ago.
camelia rakudo-moar bfe621: OUTPUT«5␤»
timotimo m: dd [xx] 5
camelia rakudo-moar bfe621: OUTPUT«5␤»
timotimo mhm
lizmat and if so, one could argue that it's wrong now 15:26
psch m: say [xx] 1, 2
camelia rakudo-moar bfe621: OUTPUT«(1 1)␤»
b2gills I am aware, now that it is lets fix it if it needs fixing
psch if anything it makes sense in that reduction use-case
p3rln00b Doesn't the 1-arg [] thing just returns its argument 15:27
b2gills m: say [,] 5
camelia rakudo-moar bfe621: OUTPUT«(5)␤»
p3rln00b ah
psch hm, it depends on the op, actually
b2gills m: say [+] 5
camelia rakudo-moar bfe621: OUTPUT«5␤»
p3rln00b I can fix
b2gills star-m: say [xx] 5; 15:29
camelia star-m 2016.04: OUTPUT«5␤»
b2gills ^- That is why I'm asking
lizmat afk again&
p3rln00b s: infix:<,>, \(42) 15:33
SourceBaby p3rln00b, Something's wrong: ␤ERR: Cannot resolve caller sourcery(List, Capture); none of these signatures match:␤ ($thing, Str:D $method, Capture $c)␤ ($thing, Str:D $method)␤ (&code)␤ (&code, Capture $c)␤ in block <unit> at -e line 6␤␤
p3rln00b s: &infix:<,>, \(42)
SourceBaby p3rln00b, Sauce is at github.com/rakudo/rakudo/blob/bfe6...t.pm#L1360
p3rln00b m: say infix:<,>(42)
camelia rakudo-moar bfe621: OUTPUT«42␤»
p3rln00b What other listy things we have like that?
'cause this is the behaviour with a fix to infix:<xx>($): gist.github.com/zoffixznet/47f1b77...2daf8d642f 15:35
And there's an inconsistency either way you slice it. 15:36
[Coke] the 1-arg stuff has specific multi methods for the single arg case. 15:37
no?
p3rln00b Not for infix:<,>
s: &prefix:<[,]>, \(5) 15:39
SourceBaby p3rln00b, Sauce is at github.com/rakudo/rakudo/blob/bfe6...ps.pm#L296
p3rln00b m: sub (+values) { dd values }(5) 15:40
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
p3rln00b m: sub (+values) { dd infix:<,>(|values) }(5) 15:41
camelia rakudo-moar bfe621: OUTPUT«5␤»
p3rln00b m: dd [,] 5
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
p3rln00b I don't get where this difference is coming from :/
psch m: sub (+values) { dd infix:<,>(values) }(5) 15:42
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
psch m: say 5.Slip,;
camelia rakudo-moar bfe621: OUTPUT«(5)␤»
p3rln00b But it's called with a |
psch m: dd [,] 5.Slip 15:43
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
psch m: say [,] 5.Slip
camelia rakudo-moar bfe621: OUTPUT«(5)␤»
p3rln00b m: dd infix:<,>(5.Slip)
camelia rakudo-moar bfe621: OUTPUT«slip(5,)␤»
p3rln00b m: dd infix:<,>(|5)
camelia rakudo-moar bfe621: OUTPUT«5␤»
psch m: dd infix:<,>(5.Slip), 15:44
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
psch m: dd infix:<,>(5),
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
psch ...commas are weird?
p3rln00b no. you're giving dd a 1-item list, with 0th item being output of a sub call
psch yeah, but that should already be a 1 item list 15:45
the output that is
m: dd (infix:<,>(5)),
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
psch m: dd (5,),
camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
psch m: dd ((5,),)
camelia rakudo-moar bfe621: OUTPUT«((5,),)␤»
psch m: dd (infix:<,>(5),)
camelia rakudo-moar bfe621: OUTPUT«((5,),)␤»
timotimo m: dd (5;)
camelia rakudo-moar bfe621: OUTPUT«5␤»
travis-ci Rakudo build failed. Zoffix Znet 'Fix proto of infix:<xx> 15:49
travis-ci.org/rakudo/rakudo/builds/166780128 github.com/rakudo/rakudo/compare/f...e621976931
buggable [travis build above] ☠ Did not recognize some failures. Check results manually 15:50
p3rln00b So what's the verdict for infix:<xx>($)?
And what's the verdict for MasterDuke's yesterday's PR for attributes that busted JVM. Is there an easy fix or should I revert it? 15:51
geekosaur might teach buggable to note jvm-only errors...
p3rln00b buggable: source 15:52
buggable p3rln00b, See: github.com/zoffixznet/perl6-buggable
p3rln00b Patches welcome :D
m: dd infix:<xx>(5) 15:53
camelia rakudo-moar bfe621: OUTPUT«5␤»
p3rln00b m: dd infix:<,>(5)
camelia rakudo-moar bfe621: OUTPUT«5␤»
psch uh 15:54
p3rln00b I'm gonna leave it like this then. I don't understand why [,] 5 gives (5,) and not 5. Reading the code, I'd expect it to give a 5, just as it does for [xx] 5
psch: the PR that busted it was this one: github.com/rakudo/rakudo/pull/901
psch okay, lemme look at travis real quick 15:55
i don't have a lot of time now though, so expect a rough hint or two at best
p3rln00b And making infix:<xx>(5) return (5,) gives consistency with [xx]/[,], but breaks it with infix:<xx>/infix:<,>
psch as for buggable ignoring jvm... dunno, i kinda fought pretty hard to turn jvm on in travis again in the first place :P
p3rln00b psch: I don't know Java at all, so I doubt I'd be able to fix it ://
Nah, not ignoring. Just detecting if failures are all JVM and saying stuff like "all failures are on JVM" 15:56
geekosaur I didn't say ignore. I was thinking just mention ... that
psch oh, right, i misread
hrm, obviously the error message from travis points at the processed BOOTSTRAP.nqp, which doesn't have the #?if moar parts 16:02
soo, no easy way to see where stuff breaks without building r-j from HEAD :l
well, build at least up to that gen-cat invocation that generates CORE.setting... 16:06
err, BOOTSTRAP.nqp actually /o\ 16:07
okay, yeah, definitely weird 16:10
the failure is in find_best_dispatchee
specifically the branch that tries to invoke the handler sub for X::Multi::NoMatch 16:11
but, it's a "can't atpos", not "can't atkey" failure
aha, line numbers don't match up between travis and locally... 16:16
so that wasn't actually it
the line, i mean
okay, the switch from BOOTSTRAPATTR (or whatever the capitalization was) to Attribute somehow messed up what we store in $!compstuff 16:18
well, or maybe *how* we store it 16:19
ah, so $cs after 'Otherwise, may need full bind check' in BOOTSTRAP.nqp is Mu 16:21
and nqp::atpos(Mu, $idx) is bogus
r: use nqp; say nqp::isnull(Mu) 16:22
camelia rakudo-jvm 2a1605, rakudo-moar bfe621: OUTPUT«0␤»
psch curious how that same thing doesn't break on moar
github.com/MasterDuke17/rakudo/blo....nqp#L2240 16:26
that's the line that dies
...contrary to what travis says
$cs is Mu, not null, which we don't seem to check differently on moar and jvm, so idk why it happens like that 16:27
maybe different autoviv behavior
anyway, i gotta run, spent too long on this right now already :S 16:28
p3rln00b psch++
m: Map.new((:42bar)).ACCEPTS(class {}) 16:31
camelia rakudo-moar bfe621: OUTPUT«Type check failed in binding to &call; expected Callable but got Method+{<anon|59764352>} (Method+{<anon|5976435...)␤ in block <unit> at <tmp> line 1␤␤»
p3rln00b m: Map.new((:42bar)).ACCEPTS(class {}.any) 16:32
camelia ( no output )
p3rln00b c: Map.new((:42bar)), 'ACCEPTS', \(class {}) 16:33
Undercover p3rln00b, The code is NOT hit during stresstest See perl6.WTF/src_core_Map.pm.coverage.html#L53 for details
p3rln00b :S no idea how that error happens :/
Or why it doesn't infiniloop for that matter... 16:35
Ah, seems to be due to this bug: rt.perl.org/Ticket/Display.html?id...et-history 16:37
dalek ast: 0d9a5b1 | (Zoffix Znet)++ | S32-hash/map.t:
[coverage] Improve coverage of Map.pm
 16:45
p3rln00b m: dd Map.new: :42b 17:07
camelia rakudo-moar bfe621: OUTPUT«Map.new(())␤»
p3rln00b Is there a reason why that wasn't made to work like the list form?
guess 'cause of Map.new: (:72a), :42b 17:09
m: class Foo { multi method foo (*@args, *%args ()) { dd @args }; multi method foo (*%args) { self.foo: %args.Slip }; }.foo: (:9x), :42a, :72b 17:16
camelia rakudo-moar bfe621: OUTPUT«Cannot resolve caller foo(Foo: Pair, :a(Int), :b(Int)); none of these signatures match:␤ (Foo $: *@args, *%args ())␤ (Foo $: *%args)␤ in block <unit> at <tmp> line 1␤␤»
p3rln00b *% () is almost twice slower than *% :/ 17:20
DrForr Here might be a more pertinent place to ask, or at least more active - I'm contemplating renaming Perl6::Tidy to Perl6::Parser to better reflect its actual purpose and releasing to the ecosystem. 17:36
p3rln00b +1 17:37
m: dd Hash.new: 1, 2, 3, 4, :42foo 17:45
camelia rakudo-moar bfe621: OUTPUT«{"1" => 2, "3" => 4}␤»
p3rln00b m: dd Map.new: 1, 2, 3, 4, :42foo
camelia rakudo-moar bfe621: OUTPUT«Map.new(("1" => 2,"3" => 4))␤»
p3rln00b m: dd Hash.new: :42foo
camelia rakudo-moar bfe621: OUTPUT«{}␤»
p3rln00b m: dd Bag.new: 1, 2, 3, 4, :42foo
camelia rakudo-moar bfe621: OUTPUT«(4=>1,3=>1,1=>1,2=>1).Bag␤»
p3rln00b fuggid then 17:46
geekosaur wonders if the pair is being parsed as an adverb instead of data 17:47
p3rln00b Yeah, it is.
I know what the fix is, but I'm warry of fixing it for performance reasons 17:48
With fix just for Map, my stresstest is clocking at 9seconds extra 17:49
m: say "{9/128} slower"
camelia rakudo-moar bfe621: OUTPUT«0.070313 slower␤»
perlpilot DrForr: +1 17:52
p3rln00b Consistently 7% slower, so screw it :)
DrForr Making changes as I type :)
perlpilot p3rln00b: good, because I'm not sure that's something that needs fixing :) 17:54
p3rln00b Yeah, it's a real minor thing.
perlpilot See S06:817 17:56
synopsebot6 Link: design.perl6.org/S06.html#line_817
perlpilot S06:Named_arguments 17:57
synopsebot6 Link: design.perl6.org/S06.html#Named_arguments
perlpilot oh ... I need focus follows eyes :) 17:58
p3rln00b What am I meant to look for?
perlpilot m: dd Hash.new: (1, 2, 3, 4, :42foo) 18:00
camelia rakudo-moar bfe621: OUTPUT«{"1" => 2, "3" => 4, :foo(42)}␤»
perlpilot Just that :foo42 and foo => 42 are always named args. 18:01
p3rln00b Sure. That's why that behaviour is there. Just because you can explain it, doesn't make it any less LTA :) 18:02
m: dd Hash.new: :42foo :56bar
camelia rakudo-moar bfe621: OUTPUT«{}␤»
p3rln00b ^ it's easy to assume the hash got right data.
geekosaur sadly I think that's always going to be the WAT to named parameters' DWIM
perlpilot geekosaur: yep
p3rln00b
.oO( where's a DWIM there's a WAT )
 18:03
Does WAT stand for anything?
moritz Wat A Terrible thing
(no, not really) 18:04
perlpilot S99:WAT
synopsebot6 Link: design.perl6.org/S99.html#WAT
perlpilot :)
If you're Dutch WAT means something
p3rln00b Can't play video, but I think I saw that talk. 18:05
perlpilot DWIM begets WAT begets FAQ. Such is the way of Perl. 18:06
p3rln00b
.oO( begets a wart )
 18:11
dalek kudo/nom: e5df7a7 | (Zoffix Znet)++ | src/core/Date (2 files):
Polish Date <-> DateTime conversions

Support .Date and .DateTime on all of Date:D, Date:U, DateTime:D, DateTime:U
  - Make conversion to self return self
  - Make conversion of :U return a typeobject
   (fixes DateTime:U.Date spilling guts in LTA error message)
  - Make Date:D.DateTime return DateTime constructed from Date:D		 19:03
ast: 3c51724 | (Zoffix Znet)++ | S32-temporal/Date (2 files):
Test [Date|DateTime].[Date|DateTime] conversion
 19:04
kudo/nom: e2cd7a3 | (Zoffix Znet)++ | src/core/Date.pm:
Unzoffix method call to use same style as rest of code
 19:31
MasterDuke FYI, i have a fix for the JVM. i'm going to do a little more testing, and maybe integrate it with some more BOOTSTRAP.nqp changes, but either way i'll create a PR this evening 22:07
travis-ci Rakudo build failed. Zoffix Znet 'Unzoffix method call to use same style as rest of code' 22:10
travis-ci.org/rakudo/rakudo/builds/166855657 github.com/rakudo/rakudo/compare/e...cd7a3207fa
buggable [travis build above] ☠ Did not recognize some failures. Check results manually
Zoffix MasterDuke++ 22:11
MasterDuke, and I assumed you saw this convo about the setting line/file: irclog.perlgeek.de/perl6-dev/2016-...i_13378247 22:44
MasterDuke in passing. seems like there's some mild agreement that source file and/or line would be good also? 23:13
Zoffix Yeah. My disagreement was based on flawed data, as I thought CORE.setting was part of standard installation. Not sure who else was in disagreement. 23:15
MasterDuke well i don't have an implementation queued up, but at least the idea has merit 23:17
(or is at least slightly less controversial than my last error message related proposal) 23:18

Powered by Cro and the Raku® Programming Language.

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

Thank you!