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.
AlexDaniel interesting 02:09
github.com/rakudo/rakudo/commit/e943f3eb
GH-2916 is linked properly
help.github.com/en/articles/autoli...s-and-urls 02:10
lizmat: that's the format that should be used then
or we can ask them to add GH#123 too
synopsebot GH#123 [closed]: github.com/rakudo/rakudo/pull/123 For infix:<ne>, use nqp::isne_s instead of !eq
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/3b4a4719 02:17
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....g8c8d0a820
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/80a5a41a 02:21
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....g23d91629d
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/b8669fe6
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....gf2b319db9
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/cbb9034a 02:22
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....9-g9d14819
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/8a37b931 02:25
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....g8c90f6266
rakudo: vrurg++ created pull request #3040:
Implement support for defining new symbols in CORE.e.setting		 03:15
roast: vrurg++ created pull request #557:
Support for fixed pseudo-packages		 03:16
04:53 nebuchadnezzar joined 05:31 robertle left 06:40 [TuxCM] left 07:06 patrickb joined 08:05 [TuxCM] joined 09:51 MasterDuke left
vrurg jnthn: would you review R#3040, please? It would allow me to move on with github.com/perl6/problem-solving/issues/47 :) 14:43
synopsebot R#3040 [open]: github.com/rakudo/rakudo/pull/3040 Implement support for defining new symbols in CORE.e.setting
14:43 lucasb joined 14:44 pamplemousse joined
jdv79 is any of the pea stuff merged yet? 14:45
jnthn jdv79: Yes, the initial basic round of it was merged a while ago. The next round of it give some nice wins, but is still a bit explosive. :) 14:49
vrurg: OK, will try and do that later today 14:50
vrurg jnthn: Thanks!
jnthn (The next round does: transitive analysis, partial escapes, and can avoid the GC-based allocations associated with Int) 14:51
14:52 TimToady joined
jnthn The big known problem is that the partial escape materializations break the SSA form. After that, it's just all of the other problems. :) 14:52
jdv79 nice. was just wondering cause i thought something from that was merged but tux's numbers and my personal stuff didn't seem to change much yet. 14:54
15:01 dogbert11 left
vrurg jnthn++ 15:06
15:23 patrickb left 15:24 MasterDuke joined 15:41 Kaypie left 15:42 Kaypie joined
jdv79 anything on the radar for perf after pea? 15:52
15:52 epony left
jnthn Well, various things in parallel with it too. Currently some invocation speedups. 15:53
(pea is *really* tricky, so I'm doing a few relatively easier things alongside it)
jdv79 neat. iirc invocation is one of the perf issue with p5. 15:57
*issues
jnthn For Perl 6 it's not that great at present either, the big difference being that we have multi-level inlining
So in a lot of cases you invocations disappear 15:58
Inlining rates in micro-benchmarks tend to be around 99%; for a more realistic situation, they can still exceed 80%.
(Depends on the micro-benchmark, but I mean the "tight loop doing primitive thing" ones.) 15:59
16:01 epony joined 16:11 [TuxCM] left
|Tux| Rakudo version 2019.03.1-680-g82fc4e570 - MoarVM version 2019.05-99-g729303de7
csv-ip5xs0.685 - 0.701
csv-ip5xs-205.284 - 5.313
csv-parser33.085 - 33.843
csv-test-xs-200.439 - 0.441
test7.358 - 7.980
test-t1.684 - 1.787
test-t --race0.778 - 0.809
test-t-2028.148 - 28.586
test-t-20 --race8.975 - 9.322
 16:20
16:38 Kaypie is now known as Kaiepi
jnthn vrurg: I took a look and let some comments; seems good overall 16:55
vrurg jnthn: thank you! 17:04
jnthn: I would make SETTING a precise scope. See no point of having SETTINS because it would be an alias to CORE. 17:22
As to MY: making it precise invalidates a test in S02-names/pseudo.t where an outer dynamic symbol is visible inside a sub. 17:23
lizmat fwiw, I think MY: should be precise, and maybe add a LEXICAL:: pseudo for the current meaning 17:25
17:26 klapperl joined
vrurg I like LEXICAL. 17:26
what about: sub foo { my $foo; { say MY::<$foo> } }?
If MY is precise this must fail. 17:27
lizmat it would be Any or Nil, I guess 17:28
or a Failure...
vrurg lizmat: Failure is what I chose – following ::() semantics. Seems very reasonable to me.
lizmat yup, works for me :-) 17:29
vrurg I would even change module Foo { }; Foo::<DoesntExists> to return Failure too (it currently returns Any)
lizmat for 6.e semantics, yeah :-)
vrurg Aha. Oki, have some work for today then. 17:30
vrurg hopes to have this merged by tonight.
lizmat vrurg++ 17:31
Geth rakudo: af10886354 | (Elizabeth Mattijsen)++ | src/core/Match.pm6
Don't use HLL ! for negation

since the rest is already in nqp:: ops. Shaves off just a little bit on !MATCH-PASS in a tight loop.		 17:33
vrurg m: use nqp; class Foo { method foo is raw { nqp::list(1,2) } }; say Foo.new.foo.^name; 17:47
camelia List
vrurg ^ I wonder if this is intended behaviour?
m: use nqp; sub foo is raw { nqp::list(1,2) }; say foo.^name 17:48
camelia BOOTArray
lizmat vrurg: nqp::list and nqp::hash auto-HLLize 17:49
that's why we have IterationBuffer for nqp::list, and IterationSet for nqp::hash 17:50
vrurg Even with `is raw`?
lizmat with methods, I think yes
but jnthn would know for sure 17:51
vrurg But not with subs. Obscure, but accepted.
I hoped to have a little bit of speed up in my code by avoiding Array in a return and using nqp::list
lizmat well, it should be a List, now? immutable and all ? 17:54
not an Array ?
vrurg lizmat: it should be BOOTArray, like with sub foo. 17:58
17:58 MasterDuke left
lizmat ok, so no HLL Array :-) that's ok 17:59
vrurg My point is that when nqp::list is returned from a raw routine it gets HLLized for methods but not for subs.
m: use nqp; sub foo is raw { nqp::list(1,2) }; say foo.^name 18:00
camelia BOOTArray
vrurg ^
m: use nqp; class Foo { method foo is raw { nqp::list(1,2) } }; say Foo.new.foo.^name;
camelia List
vrurg I was pretty confused when got an error from nqp::atpos... ;)
lizmat yeah, I see it... I'm surprised the "is raw" actually works on the sub
I wonder what jnthn has to say about the "is raw" not working on methods 18:01
vrurg I like the way it is now. Handy way if avoiding extra cost when already dealing with low-level types.
s/if// 18:02
lizmat: BTW, do you use macOS? 18:10
lizmat yes
vrurg does utf8 test in roast fail for you too?
lizmat yes
has been doing that for months
looked at it once for a few hours... but could not make heads or tails of that 18:11
vrurg Considering I'm in rakudo for 1yr it fails for me like forever. ;)
lizmat yeah, could well be a year
time flies when you're having -Ofun
vrurg :D
ok, I'm off for installing SSD into an old mac mini... 18:12
18:26 pamplemousse left 18:34 MasterDuke joined 18:43 lucasb left 19:34 MasterDuke left 19:35 MasterDuke joined 19:54 pamplemousse2 joined 20:04 pamplemousse2 left
samcv AlexDaniel, release has been done 21:00
21:37 squashable6 left 21:38 squashable6 joined
AlexDaniel oh wow rly 21:56
nice! 21:57
japhb AlexDaniel: Are you doing the nqp and rakudo releases, or will it be kawaii? 21:59
AlexDaniel japhb: mostly me, I think, as kawaii is currently figuring out some real life stuff 22:00
unless there are any objections :)
japhb Of course not!
Just wondering who to ++ :-) 22:01
samcv++; ++AlexDaniel;
AlexDaniel both then, kawaii also did some work for this release 22:03
japhb kawaii++ then for work already done. :-) 22:04
vrurg Does anybody knows why EVAL adds two extra contexts on top of its unit? Is it avoidable? 22:18
jnthn vrurg: I'd guess one of them - though maybe only needed during compile - is to make all the symbols visible in the context of the EVAL visible 22:56
vrurg Ok, then from SETTING:: with PRECISE_SCOPE point of view EVAL is different from normal code. 22:57
jnthn That said, I'm not sure if that needs to be the case by runtime 22:58
vrurg Actually, PseudoStash can take care of it if knows it's been currently under EVAL. 22:59
Another thing: MY with PRECISE_SCOPE breaks require in EVAL too. That's currently a mystery to me. 23:00
jnthn Eww
vrurg Could be a combination of MY and SETTING changed together. I stumbled upon this just a few mintes ago and still trying to work out what's going on. 23:02
SETTING with PRECISE_SCOPE breaks some other cases of require. Phew... 23:05
jnthn Yeah, I suspect SETTING is going to have to at least flatten the various CORE versions 23:06
vrurg I this is what STATIC_CHAIN was doing. 23:07
But then SETTING is almost no different from CORE. If differrent at all.
jnthn CORE is always the CORE.setting. SETTING would factor in any custom ones the language user might write 23:09
vrurg So, CORE is 6.c CORE only? No CORE.d, CORE.e included? 23:11
Kaiepi just need to update CStr, P6int, P6num, and P6str's REPRs on the JVM and JS backend and nativecall wide string support is ready to pullreq! 23:12
jnthn No, I think CORE should include your 6.d/6.e 23:14
But if you do perl6 --setting=RESTRICTED, for example, then SETTING would point to that, while CORE would always point to the CORE.setting 23:15
Of course, such a RESTRICTED would have to chose a version of CORE to use as its setting. 23:16
(Always point to the CORE.*.setting, I should say)
If you don't pass a --setting= argument, then SETTING and CORE would be identical. 23:17
vrurg Ok, this is what I was missing.
Then SETTING:: is a STATIC_CHAIN thing.
jnthn Yes, settings are effectively the outer lexical environment of a program
Rather than having a default set of imports, Perl 6 does this as having a default lexical environment 23:18
vrurg m: use nqp; sub foo is raw { nqp::list(1,2) }; say foo.^name
camelia BOOTArray
vrurg m: use nqp; class Foo { method foo is raw { nqp::list(1,2) } }; say Foo.new.foo.^name;
camelia List
vrurg jnthn: That's ^ another question I had. Why method HLLise with is raw? 23:19
jnthn Because we assume that anything that's a sub is part of our language, so needn't be hllized, while methods could be from some other language, so we hllize them 23:20
vrurg I though I could spare a couple of CPU cycles on using nqp::list instead of an Array in PseudoStash, but ...
jnthn The hllize happens on the *caller* side, so the `is raw` isn't relevant
You can save them; use a Perl 6 type with the VMArray REPR. IterationBuffer is convenient for that.
m: say IterationBuffer.REPR 23:21
camelia VMArray
vrurg Ok, will try that. Thanks!
jnthn nqp::list compiles into an nqp::create and then a sequence of nqp::push, iirc 23:22
(I think it's push rather than indexes)
vrurg I gues it would still be faster than [1,2] -> return -> @a[0]? 23:23
jnthn Yes 23:25
For now ;)
vrurg is looking for 👍🏻 button :) 23:27
23:29 vrurg left, vrurg joined
vrurg Heh, my IRC client died from a uncode char... 23:30
jnthn hah, mine rendered it wrong too...I wondered why, then realized that my linode got rebooted, and it seems I'm using irssi instead of weechat after... :) 23:34
I *think* I got the latter rendering things better, at least :)
vrurg Mine dies while having the symbol in the input field. :( 23:43
23:53 MasterDuke left

Powered by Cro and the Raku® Programming Language.

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

Thank you!