Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-10-11

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #perl6-dev
01:48 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
05:11 geekosaur joined #perl6-dev
06:22 [Tux] This is Rakudo version 2016.09-166-gf117a61 built on MoarVM version 2016.09-39-g688796b
06:22 [Tux] csv-ip5xs        3.247
06:22 [Tux] test            15.957
06:22 [Tux] test-t           6.959
06:22 [Tux] csv-parser      18.170
07:32 lizmat below 7 again  :-)
07:34 RabidGravy joined #perl6-dev
08:34 lizmat afk&
08:36 psch_ joined #perl6-dev
08:47 RabidGravy joined #perl6-dev
08:48 brrt joined #perl6-dev
08:49 huggable joined #perl6-dev
08:49 dalek joined #perl6-dev
08:49 Undercover joined #perl6-dev
08:49 SourceBaby joined #perl6-dev
08:49 NeuralAnomaly joined #perl6-dev
08:49 buggable joined #perl6-dev
08:49 yoleaux2 joined #perl6-dev
08:49 bisectable6 joined #perl6-dev
08:49 synopsebot6 joined #perl6-dev
08:49 JimmyZ joined #perl6-dev
10:36 FROGGS joined #perl6-dev
10:38 b2gills joined #perl6-dev
10:43 Zoffix Anyone on arch? What rakudo version is in the repo?
10:44 pmurias joined #perl6-dev
10:45 Zoffix Nothing's showing up in search https://www.archlinux.org/packages/?sort=&q=rakudo&maintainer=&flagged=
10:46 dalek nqp: 3ca32a5 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
10:46 dalek nqp: [js] Generate generalized accessors for nqp::getattr and nqp::bindattr ops.
10:46 dalek nqp: review: https://github.com/perl6/nqp/commit/3ca32a5586
10:46 dalek nqp: 80327cb | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
10:46 dalek nqp: [js] Speed up the setting of defaults values for native attributes by generating code for that.
10:46 dalek nqp: review: https://github.com/perl6/nqp/commit/80327cb7e6
10:46 dalek nqp: a92c7ad | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
10:46 dalek nqp: [js] Generate attr accessors to speed things up.
10:46 dalek nqp: review: https://github.com/perl6/nqp/commit/a92c7adb8b
10:46 dalek nqp: 00aaf68 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
10:46 dalek nqp: [js] Delete dead code.
10:46 dalek nqp: review: https://github.com/perl6/nqp/commit/00aaf68a25
10:46 Zoffix ( was just wondering what this feller was trying to use https://www.reddit.com/r/perl6/comments/56qy7w/panda_problems/d8mvlgk )
10:52 psch_ Zoffix: the arch user repo is https://aur.archlinux.org so they're probably using https://aur.archlinux.org/packages/panda/
10:53 Zoffix Thanks.
10:54 Zoffix They look fresh. Weird they weren't working for that person.
10:55 psch well, it might also be https://aur.archlinux.org/packages/perl6-panda/
10:56 psch note the former has the latter as prereq, as well as Shell::Command
10:56 psch so, yeah, dunno
10:57 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
10:57 psch compared to gentoo at least :P
10:58 psch anyway, yeah, the error looks like they're using the latter package
10:58 psch because yeah, prereqs vOv
10:58 psch or dependencies or whatever :P
11:31 stmuk_ joined #perl6-dev
12:24 p3rln00b ZOFVM: Files=1195, Tests=129675, 128 wallclock secs (21.30 usr  3.18 sys + 2367.44 cusr 193.01 csys = 2584.93 CPU)
13:12 ilmari joined #perl6-dev
13:26 p3rln00b Just curious: have any dates been mulled over for 6.d release?
13:33 jnthn I think TimToady mumbled something about next summer, which feels reasonable to me also
13:34 * p3rln00b nods
13:39 [Coke] if we're aiming at summer, we should try to have a plan in place by the end of the year
13:49 dalek roast: 07d14e2 | (Zoffix Znet)++ | S03-junctions/misc.t:
13:49 dalek roast: [coverage] Cover Junction.new
13:49 dalek roast: review: https://github.com/perl6/roast/commit/07d14e2d60
14:13 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' } })
14:13 camelia rakudo-moar f117a6: OUTPUT«this is obscene␤»
14:13 p3rln00b jdv79: what bug?
14:13 jdv79 i've been blocked on a bug for months now and i can't fix it myself
14:13 jdv79 its async related
14:13 p3rln00b jdv79: what's the RT number?
14:14 jdv79 its probbably a few different issues but the bug report says it i think.
14:14 jdv79 i need to find it
14:16 p3rln00b List.from and List.to make me squirm a little :(
14:16 jdv79 128833
14:16 p3rln00b RT#128833
14:16 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128833
14:17 jdv79 just updated and basically the same results
14:21 p3rln00b Reproduced on my VM: https://gist.github.com/zoffixznet/3d286a2ef92b402f5b519263fe594a8b
14:22 p3rln00b Over my head to fix it though :) ... Yet!
14:22 timotimo Message body is not shown because it is too large.  -  F you, RT :\
14:22 p3rln00b timotimo: https://rt.perl.org/Ticket/Attachment/1414725/764551/
14:23 timotimo yeah, i know
14:23 timotimo but still ...
14:25 perlpilot joined #perl6-dev
14:26 timotimo 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.
14:27 nine 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:28 Woodi joined #perl6-dev
14:29 jdv79 p3rln00b: thanks anyway
14:29 jdv79 timotimo: thanks
14:34 p3rln00b nine: what do you mean: "Same is true for the concatenated source file."?
14:34 p3rln00b I can open concatenated file and find the code that's run.
14:35 p3rln00b s: &say
14:35 SourceBaby p3rln00b, Sauce is at https://github.com/rakudo/rakudo/blob/f117a61/src/core/io_operators.pm#L20
14:35 p3rln00b ^ that's what the bot does. I can do it programmatically.
14:35 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.
14:36 p3rln00b I don't have real source file.
14:37 nine Why would you not have the real source file but would have a build artifact?
14:37 p3rln00b Is it just an artifact?
14:37 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?
14:38 nine 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
14:38 psch at least that's my understanding
14:39 p3rln00b OK then
14:39 psch s/bootstrapping/core compilation/
14:39 psch although i suppose the same argument could be made for Metamodel vOv
14:39 ilmari joined #perl6-dev
14:40 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
14:40 p3rln00b MasterDuke: ^
14:41 nine p3rln00b: no, why would it?
14:41 psch nine: oh, right, stubbing was the reason.  thanks for clearing that up
14:42 p3rln00b nine: ¯\_(ツ)_/¯ I saw it in my install dir and assumed
14:42 psch p3rln00b: CORE.setting.nqp?
14:42 psch ...wait it doesn't have .nqp in gen i think
14:43 psch anyway, my $prefix for r-j has CORE.setting.jar
14:43 psch and the rakudo checkout has gen/jvm/CORE.setting
14:43 psch which is the concatenated pm files
14:43 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.
14:43 psch (not nqp... i probably really should walk away for today, can't make into thinking good :P )
14:44 timotimo ... how do you debug this stuff ...
14:44 p3rln00b j: &say.file.say
14:44 camelia rakudo-jvm 2a1605: OUTPUT«unknown␤»
14:44 psch m: &say.file.say
14:44 camelia rakudo-moar f117a6: OUTPUT«gen/moar/m-CORE.setting␤»
14:44 psch ...different kinds of annotation?
14:44 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
14:45 jnthn timotimo: Concurrency things? With a loooot of patience :)
14:45 p3rln00b jnthn: but what tools do you use?
14:45 * p3rln00b has a loooooot of patients. I could use a brain tho :P
14:45 arnsholt Going through the indirection of CORE.setting when debugging core stuff has always been an annoyance if you ask me
14:45 timotimo yeah, but how do i even start?
14:46 timotimo 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.
14:47 jnthn Looking at the code-gen of the golf has sometimes showed up missing closure cloning
14:47 jnthn I've got a branch that fixed a couple of those, but along the way regressed a spectest...
14:48 jnthn But the missing clones can cause over-sharing of state
14:49 jnthn 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:50 jnthn 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:51 jnthn (Since the cross-thread write logging thing turns up various false positives)
14:52 p3rln00b sounds fancy
14:53 timotimo oh, mostly just "add_to_cache" :P
14:54 jnthn Yeah, that one is benign, for example.
14:59 pmurias anyone opposed to hidding empty flags for a QAST::Node (so in effect turn "<>" in the output into "")?
15:02 dalek rakudo/nom: bfe6219 | (Zoffix Znet)++ | src/core/List.pm:
15:02 dalek rakudo/nom: Fix proto of infix:<xx>
15:02 dalek rakudo/nom:
15:02 dalek rakudo/nom: The current proto does not match the () and ($) candidates.
15:02 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bfe6219769
15:04 timotimo ASAN doesn't spit out anything for this bug
15:06 FROGGS joined #perl6-dev
15:07 FROGGS o/
15:10 p3rln00b m: sub foo {rand}; say &foo xx 2
15:10 camelia rakudo-moar f117a6: OUTPUT«(sub foo () { #`(Sub|77046384) ... } sub foo () { #`(Sub|77046384) ... })␤»
15:10 p3rln00b m: sub foo {rand}; say infix:<xx>(&foo, 2)
15:10 camelia rakudo-moar f117a6: OUTPUT«(0.145600101934383 0.556302076395789)␤»
15:10 p3rln00b I'm guessing the A xx B version is doing some magics
15:11 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␤␤»
15:11 psch m: sub foo {rand}; say foo() xx 2
15:11 camelia rakudo-moar bfe621: OUTPUT«(0.49677774614035 0.715203940340046)␤»
15:11 psch p3rln00b: i don't see any magic.  you're just nouning the sub
15:11 psch p3rln00b: and (i think) LTM is why it can't warn about needing parens
15:12 p3rln00b psch: I see magic. Any other thing will use the return value of foo() as argument
15:13 p3rln00b m: sub infix:<Δ>  { dd [$^a, $^b] }; sub foo {rand}; foo() Δ 2
15:13 camelia rakudo-moar bfe621: OUTPUT«[0.94687149208834e0, 2]␤»
15:13 timotimo the magic is in xx thunking its LHS
15:13 psch p3rln00b: oh, that.  yeah xx thunks the lhs
15:13 p3rln00b OK
15:17 dalek roast: 693052d | (Zoffix Znet)++ | S03-operators/repeat.t:
15:17 dalek roast: [coverage] cover List.[to|from] and infix:<xx> candidates
15:17 dalek roast: review: https://github.com/perl6/roast/commit/693052d1e6
15:21 dalek roast: 33c09fc | (Zoffix Znet)++ | S0 (2 files):
15:21 dalek roast: Move test to better place
15:21 dalek roast: review: https://github.com/perl6/roast/commit/33c09fc88f
15:23 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,)␤»
15:24 lizmat b2gills: yes, because you want to be consistent
15:24 lizmat xx always returns a list
15:24 b2gills &[xx](5) returns 5 not (5,)
15:24 lizmat m: dd 5 xx 0
15:24 camelia rakudo-moar bfe621: OUTPUT«()␤»
15:25 lizmat m: dd 5 xx 1
15:25 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:25 b2gills m: say [xx] 5
15:25 p3rln00b &[xx](5) is a 1-arg version that was uncallable until about 10 minutes ago.
15:25 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:25 timotimo m: dd [xx] 5
15:25 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:25 timotimo mhm
15:26 lizmat and if so, one could argue that it's wrong now
15:26 psch m: say [xx] 1, 2
15:26 camelia rakudo-moar bfe621: OUTPUT«(1 1)␤»
15:26 b2gills I am aware, now that it is lets fix it if it needs fixing
15:26 psch if anything it makes sense in that reduction use-case
15:27 p3rln00b Doesn't the 1-arg [] thing just returns its argument
15:27 b2gills m: say [,] 5
15:27 camelia rakudo-moar bfe621: OUTPUT«(5)␤»
15:27 p3rln00b ah
15:27 psch hm, it depends on the op, actually
15:27 b2gills m: say [+] 5
15:27 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:27 p3rln00b I can fix
15:29 b2gills star-m: say [xx] 5;
15:29 camelia star-m 2016.04: OUTPUT«5␤»
15:29 b2gills ^- That is why I'm asking
15:29 lizmat afk again&
15:33 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␤␤
15:33 p3rln00b s: &infix:<,>, \(42)
15:33 SourceBaby p3rln00b, Sauce is at https://github.com/rakudo/rakudo/blob/bfe6219/src/core/List.pm#L1360
15:33 p3rln00b m: say infix:<,>(42)
15:33 camelia rakudo-moar bfe621: OUTPUT«42␤»
15:33 p3rln00b What other listy things we have like that?
15:35 p3rln00b 'cause this is the behaviour with a fix to infix:<xx>($): https://gist.github.com/zoffixznet/47f1b77349e874cf509f9d2daf8d642f
15:36 p3rln00b And there's an inconsistency either way you slice it.
15:37 [Coke] the 1-arg stuff has specific multi methods for the single arg case.
15:37 [Coke] no?
15:37 p3rln00b Not for infix:<,>
15:39 p3rln00b s: &prefix:<[,]>, \(5)
15:39 SourceBaby p3rln00b, Sauce is at https://github.com/rakudo/rakudo/blob/bfe6219/src/core/metaops.pm#L296
15:40 p3rln00b m: sub (+values) { dd values }(5)
15:40 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:41 p3rln00b m: sub (+values) { dd infix:<,>(|values) }(5)
15:41 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:41 p3rln00b m: dd [,] 5
15:41 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:41 p3rln00b I don't get where this difference is coming from :/
15:42 psch m: sub (+values) { dd infix:<,>(values) }(5)
15:42 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:42 psch m: say 5.Slip,;
15:42 camelia rakudo-moar bfe621: OUTPUT«(5)␤»
15:42 p3rln00b But it's called with a |
15:43 psch m: dd [,] 5.Slip
15:43 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:43 psch m: say [,] 5.Slip
15:43 camelia rakudo-moar bfe621: OUTPUT«(5)␤»
15:43 p3rln00b m: dd infix:<,>(5.Slip)
15:43 camelia rakudo-moar bfe621: OUTPUT«slip(5,)␤»
15:43 p3rln00b m: dd infix:<,>(|5)
15:43 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:44 psch m: dd infix:<,>(5.Slip),
15:44 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:44 psch m: dd infix:<,>(5),
15:44 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:44 psch ...commas are weird?
15:44 p3rln00b no. you're giving dd a 1-item list, with 0th item being output of a sub call
15:45 psch yeah, but that should already be a 1 item list
15:45 psch the output that is
15:45 psch m: dd (infix:<,>(5)),
15:45 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:45 psch m: dd (5,),
15:45 camelia rakudo-moar bfe621: OUTPUT«(5,)␤»
15:45 psch m: dd ((5,),)
15:45 camelia rakudo-moar bfe621: OUTPUT«((5,),)␤»
15:45 psch m: dd (infix:<,>(5),)
15:45 camelia rakudo-moar bfe621: OUTPUT«((5,),)␤»
15:45 timotimo m: dd (5;)
15:45 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:49 travis-ci joined #perl6-dev
15:49 travis-ci Rakudo build failed. Zoffix Znet 'Fix proto of infix:<xx>
15:49 travis-ci https://travis-ci.org/rakudo/rakudo/builds/166780128 https://github.com/rakudo/rakudo/compare/f117a61595fa...bfe621976931
15:49 travis-ci left #perl6-dev
15:50 buggable [travis build above] ☠ Did not recognize some failures. Check results manually
15:50 p3rln00b So what's the verdict for infix:<xx>($)?
15:51 p3rln00b 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...
15:52 p3rln00b buggable: source
15:52 buggable p3rln00b, See: https://github.com/zoffixznet/perl6-buggable
15:52 p3rln00b Patches welcome :D
15:53 p3rln00b m: dd infix:<xx>(5)
15:53 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:53 p3rln00b m: dd infix:<,>(5)
15:53 camelia rakudo-moar bfe621: OUTPUT«5␤»
15:54 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
15:54 p3rln00b psch: the PR that busted it was this one: https://github.com/rakudo/rakudo/pull/901
15:55 psch okay, lemme look at travis real quick
15:55 psch i don't have a lot of time now though, so expect a rough hint or two at best
15:55 p3rln00b And making infix:<xx>(5) return (5,) gives consistency with [xx]/[,], but breaks it with infix:<xx>/infix:<,>
15:55 psch as for buggable ignoring jvm... dunno, i kinda fought pretty hard to turn jvm on in travis again in the first place :P
15:55 p3rln00b psch: I don't know Java at all, so I doubt I'd be able to fix it ://
15:56 p3rln00b 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
15:56 psch oh, right, i misread
16:02 psch hrm, obviously the error message from travis points at the processed BOOTSTRAP.nqp, which doesn't have the #?if moar parts
16:02 psch soo, no easy way to see where stuff breaks without building r-j from HEAD :l
16:06 psch well, build at least up to that gen-cat invocation that generates CORE.setting...
16:07 psch err, BOOTSTRAP.nqp actually /o\
16:10 psch okay, yeah, definitely weird
16:10 psch the failure is in find_best_dispatchee
16:11 psch specifically the branch that tries to invoke the handler sub for X::Multi::NoMatch
16:11 psch but, it's a "can't atpos", not "can't atkey" failure
16:16 psch aha, line numbers don't match up between travis and locally...
16:16 psch so that wasn't actually it
16:16 psch the line, i mean
16:18 psch okay, the switch from BOOTSTRAPATTR (or whatever the capitalization was) to Attribute somehow messed up what we store in $!compstuff
16:19 AlexDaniel joined #perl6-dev
16:19 psch well, or maybe *how* we store it
16:21 psch ah, so $cs after 'Otherwise, may need full bind check' in BOOTSTRAP.nqp is Mu
16:21 psch and nqp::atpos(Mu, $idx) is bogus
16:22 psch r: use nqp; say nqp::isnull(Mu)
16:22 camelia rakudo-jvm 2a1605, rakudo-moar bfe621: OUTPUT«0␤»
16:22 psch curious how that same thing doesn't break on moar
16:26 psch https://github.com/MasterDuke17/rakudo/blob/e8c8af60c40bbbee2c9dd8d63bb9fb75fe065e30/src/Perl6/Metamodel/BOOTSTRAP.nqp#L2240
16:26 psch that's the line that dies
16:26 psch ...contrary to what travis says
16:27 psch $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 psch maybe different autoviv behavior
16:28 psch anyway, i gotta run, spent too long on this right now already :S
16:28 p3rln00b psch++
16:31 p3rln00b 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␤␤»
16:32 p3rln00b m: Map.new((:42bar)).ACCEPTS(class {}.any)
16:32 camelia rakudo-moar bfe621: ( no output )
16:33 p3rln00b c: Map.new((:42bar)), 'ACCEPTS', \(class {})
16:33 Undercover p3rln00b, The code is NOT hit during stresstest See http://perl6.WTF/src_core_Map.pm.coverage.html#L53 for details
16:33 p3rln00b :S no idea how that error happens :/
16:35 p3rln00b Or why it doesn't infiniloop for that matter...
16:37 p3rln00b Ah, seems to be due to this bug: https://rt.perl.org/Ticket/Display.html?id=128905#ticket-history
16:45 dalek roast: 0d9a5b1 | (Zoffix Znet)++ | S32-hash/map.t:
16:45 dalek roast: [coverage] Improve coverage of Map.pm
16:45 dalek roast: review: https://github.com/perl6/roast/commit/0d9a5b1430
17:07 p3rln00b m: dd Map.new: :42b
17:07 camelia rakudo-moar bfe621: OUTPUT«Map.new(())␤»
17:07 p3rln00b Is there a reason why that wasn't made to work like the list form?
17:09 p3rln00b guess 'cause of Map.new: (:72a), :42b
17:16 p3rln00b 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␤␤»
17:20 p3rln00b *% () is almost twice slower than *% :/
17:36 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:37 p3rln00b +1
17:38 lucasb joined #perl6-dev
17:45 p3rln00b m: dd Hash.new: 1, 2, 3, 4, :42foo
17:45 camelia rakudo-moar bfe621: OUTPUT«{"1" => 2, "3" => 4}␤»
17:45 p3rln00b m: dd Map.new: 1, 2, 3, 4, :42foo
17:45 camelia rakudo-moar bfe621: OUTPUT«Map.new(("1" => 2,"3" => 4))␤»
17:45 p3rln00b m: dd Hash.new: :42foo
17:45 camelia rakudo-moar bfe621: OUTPUT«{}␤»
17:45 p3rln00b m: dd Bag.new: 1, 2, 3, 4, :42foo
17:45 camelia rakudo-moar bfe621: OUTPUT«(4=>1,3=>1,1=>1,2=>1).Bag␤»
17:46 p3rln00b fuggid then
17:47 * geekosaur wonders if the pair is being parsed as an adverb instead of data
17:47 p3rln00b Yeah, it is.
17:48 p3rln00b I know what the fix is, but I'm warry of fixing it for performance reasons
17:49 p3rln00b With fix just for Map, my stresstest is clocking at 9seconds extra
17:49 p3rln00b m: say "{9/128} slower"
17:49 camelia rakudo-moar bfe621: OUTPUT«0.070313 slower␤»
17:52 perlpilot DrForr:  +1
17:52 p3rln00b Consistently 7% slower, so screw it :)
17:52 DrForr Making changes as I type :)
17:54 perlpilot p3rln00b: good, because I'm not sure that's something that needs fixing  :)
17:54 p3rln00b Yeah, it's a real minor thing.
17:56 perlpilot See S06:817
17:56 synopsebot6 Link: http://design.perl6.org/S06.html#line_817
17:57 perlpilot S06:Named_arguments
17:57 synopsebot6 Link: http://design.perl6.org/S06.html#Named_arguments
17:58 perlpilot oh ... I need focus follows eyes  :)
17:58 p3rln00b What am I meant to look for?
18:00 perlpilot m: dd Hash.new: (1, 2, 3, 4, :42foo)
18:00 camelia rakudo-moar bfe621: OUTPUT«{"1" => 2, "3" => 4, :foo(42)}␤»
18:01 perlpilot Just that :foo42 and foo => 42 are always named args.
18:02 p3rln00b Sure. That's why that behaviour is there. Just because you can explain it, doesn't make it any less LTA :)
18:02 p3rln00b m: dd Hash.new: :42foo :56bar
18:02 camelia rakudo-moar bfe621: OUTPUT«{}␤»
18:02 p3rln00b ^ it's easy to assume the hash got right data.
18:02 geekosaur sadly I think that's always going to be the WAT to named parameters' DWIM
18:02 perlpilot geekosaur: yep
18:03 p3rln00b .oO( where's a DWIM there's a WAT )
18:03 p3rln00b Does WAT stand for anything?
18:03 moritz Wat A Terrible thing
18:04 moritz (no, not really)
18:04 perlpilot S99:WAT
18:04 synopsebot6 Link: http://design.perl6.org/S99.html#WAT
18:04 perlpilot :)
18:04 perlpilot If you're Dutch WAT means something
18:05 p3rln00b Can't play video, but I think I saw that talk.
18:06 perlpilot DWIM begets WAT begets FAQ.  Such is the way of Perl.
18:11 p3rln00b .oO( begets a wart )
18:17 hankache joined #perl6-dev
19:03 dalek rakudo/nom: e5df7a7 | (Zoffix Znet)++ | src/core/Date (2 files):
19:03 dalek rakudo/nom: Polish Date <-> DateTime conversions
19:03 dalek rakudo/nom:
19:03 dalek rakudo/nom: Support .Date and .DateTime on all of Date:D, Date:U, DateTime:D, DateTime:U
19:03 dalek rakudo/nom:
19:03 dalek rakudo/nom: - Make conversion to self return self
19:03 dalek rakudo/nom: - Make conversion of :U return a typeobject
19:03 dalek rakudo/nom:     (fixes DateTime:U.Date spilling guts in LTA error message)
19:03 dalek rakudo/nom: - Make Date:D.DateTime return DateTime constructed from Date:D
19:03 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e5df7a7bef
19:04 dalek roast: 3c51724 | (Zoffix Znet)++ | S32-temporal/Date (2 files):
19:04 dalek roast: Test [Date|DateTime].[Date|DateTime] conversion
19:04 dalek roast: review: https://github.com/perl6/roast/commit/3c51724df3
19:31 dalek rakudo/nom: e2cd7a3 | (Zoffix Znet)++ | src/core/Date.pm:
19:31 dalek rakudo/nom: Unzoffix method call to use same style as rest of code
19:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e2cd7a3207
22:07 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:10 travis-ci joined #perl6-dev
22:10 travis-ci Rakudo build failed. Zoffix Znet 'Unzoffix method call to use same style as rest of code'
22:10 travis-ci https://travis-ci.org/rakudo/rakudo/builds/166855657 https://github.com/rakudo/rakudo/compare/e5df7a7befd5...e2cd7a3207fa
22:10 travis-ci left #perl6-dev
22:10 buggable [travis build above] ☠ Did not recognize some failures. Check results manually
22:11 Zoffix MasterDuke++
22:17 MasterDuke joined #perl6-dev
22:44 Zoffix MasterDuke, and I assumed you saw this convo about the setting line/file: https://irclog.perlgeek.de/perl6-dev/2016-10-11#i_13378247
23:13 MasterDuke in passing. seems like there's some mild agreement that source file and/or line would be good also?
23:15 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:17 MasterDuke well i don't have an implementation queued up, but at least the idea has merit
23:18 MasterDuke (or is at least slightly less controversial than my last error message related proposal)
23:48 tadzik joined #perl6-dev
23:50 ilmari[m] joined #perl6-dev

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary