Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-04-22

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:58 vendethiel joined #p6dev
02:59 astj joined #p6dev
04:54 astj joined #p6dev
06:05 vendethiel joined #p6dev
06:40 ugexe joined #p6dev
07:13 brrt joined #p6dev
07:28 brrt re: reframe branch, i'm sorry for increasing the frame size again :-)
07:29 ugexe joined #p6dev
07:33 RabidGravy joined #p6dev
07:34 masak jnthn: "A frame becoming the default outer thanks to “auto-close” (rare)" -- is this one the "need more vodka" case with roles?
07:48 brrt joined #p6dev
08:14 sno joined #p6dev
08:30 [TuxCM] This is Rakudo version 2016.04-5-g463e758 built on MoarVM version 2016.04
08:30 [TuxCM] test            22.579
08:30 [TuxCM] test-t          12.573
08:30 [TuxCM] csv-parser      24.805
08:49 dalek rakudo/nom: a5d53e7 | azawawi++ | README.md:
08:49 dalek rakudo/nom: Fix AppVeyor CI link
08:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a5d53e73f0
08:49 dalek rakudo/nom: 9f9f0b2 | lizmat++ | README.md:
08:49 dalek rakudo/nom: Merge pull request #753 from azawawi/nom
08:49 dalek rakudo/nom:
08:49 dalek rakudo/nom: Fix AppVeyor CI link
08:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9f9f0b2873
08:49 masak I'd like to flag up https://rt.perl.org/Ticket/Display.html?id=127789 for discussion -- also, ping TimToady
08:49 masak first off, I think lizmat++ is perfectly right, that it is a slippery slope
08:53 masak Rakudo is to spec here, by the way -- S12:1903 has this:
08:53 synopsebot6 Link: http://design.perl6.org/S12.html#1903_has_this
08:53 masak CoinFace.enums.keys       # ('Heads', 'Tails')
08:53 masak go home, synopsebot6 you're funny
08:54 masak S12:1903
08:54 synopsebot6 Link: http://design.perl6.org/S12.html#line_1903
08:55 masak but... the reason we went with the .enums and .invert design in the first place is so that we could *look up the Enum objects from the values*
08:55 lizmat joined #p6dev
08:56 masak I haven't had a use case where I needed to do that until last month
08:57 masak and my experience as a user of that API is that it'd be a whole lot more useful/sensible to get the Enum, not the Str representation
08:57 masak I am -- cautiously -- of the opinion that if fixing this requires a breaking change, we should do it
08:58 masak my caution comes from the fact that I haven't tested the ecosystem against such a change to see what falls out -- something we can, and should, do
08:59 masak tl;rd: "I think this is a slippery slope we should go down, with a toboggan!" :P
09:00 RabidGravy I think I've used the current behaviour in a couple of tests but probably not in an actual module
09:02 masak RabidGravy: do you have a link to those tests?
09:02 RabidGravy just grepping all my modules to find which ones
09:03 masak fwiw, here's my use case: https://github.com/masak/nex/blob/master/lib/Games/Nex/Test.pm#L7-L12
09:04 masak sorry, permalink: https://github.com/masak/nex/blob/ed4f5758513b85c41d4ecb35af5cf24643a3829f/lib/Games/Nex/Test.pm#L7-L12
09:04 masak and the declaration of the enum: https://github.com/masak/nex/blob/ed4f5758513b85c41d4ecb35af5cf24643a3829f/lib/Games/Nex.pm#L4-L9
09:06 RabidGravy actually interestingly in https://github.com/jonathanstowe/Lumberjack/blob/master/t/040-dispatcher-basic.t#L23 I am emulating the other behaviour
09:07 RabidGravy and I assume that wouldn't actually be broken by the proposed changed
09:08 RabidGravy the only other place is in https://github.com/jonathanstowe/Audio-Sndfile/blob/master/examples/p6sndfile-convert
09:11 RabidGravy so somewhat false memory
10:09 nine_ Of not may be that Enums stringify to their full name, i.e. Stone::Vertical, not just the short name
10:28 DrForr joined #p6dev
10:31 ugexe joined #p6dev
10:33 tomboy64 joined #p6dev
11:01 jnthn lizmat: hey, I've a new spectest record maybe!
11:01 jnthn Files=1098, Tests=51306, 88513 wallclock secs
11:01 jnthn :D
11:01 lizmat wow... progress!   :-)
11:01 jnthn m: say 88513 / (60 * 60)
11:01 camelia rakudo-moar 9f9f0b: OUTPUT«24.586944␤»
11:01 jnthn :)
11:02 lizmat 13K nursery, I suppose ?
11:02 jnthn Yeah
11:02 tadzik rakudo on RPi now has a contender
11:02 jnthn What's interesting is that it's showed up various test files that I seem to recall us having heisenfails with
11:04 lizmat ah...  that's good to know
11:05 lizmat so, would there be an easy way of running this type of test with an existing MoarVM ?
11:05 lizmat MVM_NURSERY=13 ?
11:06 lizmat m: say *.ACCEPTS(False)   # shouldn't this be False ?
11:06 camelia rakudo-moar 9f9f0b: OUTPUT«{ ... }␤»
11:06 jnthn lizmat: Not yet
11:06 lizmat m: say Whatever.ACCEPTS(False)   # shouldn't this be False ?
11:06 camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
11:07 jnthn lizmat: You have to change a value in a header file and make install
11:07 lizmat huh?
11:07 jnthn *.ACCEPTS(False) is an auto-curry
11:08 jnthn m: say (*).ACCEPTS(False)
11:08 camelia rakudo-moar 9f9f0b: OUTPUT«{ ... }␤»
11:08 jnthn oh, so is that :)
11:08 jnthn But yeah, ti's like *.foo
11:08 jnthn m: say <o m g>.map(*.uc)
11:08 camelia rakudo-moar 9f9f0b: OUTPUT«(O M G)␤»
11:08 lizmat I was trying to figure out the difference between .grep(*) and .grep({$_})
11:09 lizmat m: say Whatever.new.ACCEPTS(False)
11:09 camelia rakudo-moar 9f9f0b: OUTPUT«True␤»
11:09 lizmat m: say Whatever.ACCEPTS(False)
11:09 camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
11:09 jnthn Whatever.ACCEPTS(False) is a type test against Whatever
11:09 jnthn Just as Int.ACCEPTS(False) is
11:10 lizmat m: say Int.ACCEPTS(False)
11:10 camelia rakudo-moar 9f9f0b: OUTPUT«True␤»
11:10 jnthn m: say False.^mro # here's why True
11:10 camelia rakudo-moar 9f9f0b: OUTPUT«((Bool) (Int) (Cool) (Any) (Mu))␤»
11:10 lizmat m: say Whatever.ACCEPTS(False) # so this is wrong
11:10 camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
11:10 jnthn No?
11:11 jnthn m: say Bool ~~ Whatever
11:11 camelia rakudo-moar 9f9f0b: OUTPUT«False␤»
11:11 jnthn You're confusing Whatever the type, and *, an instance of the type, I think?
11:11 lizmat m: say Int.ACCEPTS(False)
11:11 camelia rakudo-moar 9f9f0b: OUTPUT«True␤»
11:11 lizmat jnthn: isn't that a WhateverCode ?
11:11 jnthn No
11:12 jnthn WhateverCode is produced by the compiler after an auto-curry
11:12 jnthn But a plain old * is just an instance of Whatever
11:12 jnthn m: my $x = *; say $x.WHAT; say $x.defined
11:12 camelia rakudo-moar 9f9f0b: OUTPUT«(Whatever)␤True␤»
11:13 lizmat m: (Any,42,Any).grep(*).say   # so this is correct ?
11:13 camelia rakudo-moar 9f9f0b: OUTPUT«((Any) 42 (Any))␤»
11:13 jnthn I'd except .grep(*) to just be the same as .grep(True)
11:13 jnthn Yes, looks correct to me
11:13 lizmat m: (Any,42,Any).grep({$_}).say   # as opposed to this?
11:13 camelia rakudo-moar 9f9f0b: OUTPUT«(42)␤»
11:14 jnthn Also looks correct
11:14 lizmat ok, will tell tadzik  :-)
11:14 jnthn Because in the code case we treat the result as a boolean
11:14 tadzik :(
11:14 jnthn Well, actually, more like, smart-match against a piece of code invokes it with the topic
11:15 jnthn We probably optimize the closure path rather than actually calling ACCEPTS, but an implementation that didn't need to care about speed would be correct in just calling ACCEPTS
11:15 tadzik it just seems counterintuitive, when in every conf talk we say "you can use * instead of $_ in your grep/map and that saves you writing the block around it"
11:16 jnthn We should maybe get better at explaining that the mechanism is the conjunction of * together with an operator that's whatever-curryable
11:17 jnthn Note that .grep(1..*) is different to .grep({1..$_}) also
11:22 dalek rakudo/nom: cc4dd7c | lizmat++ | src/core/Version.pm:
11:22 dalek rakudo/nom: Make Version comparisons abouut 2x as fast
11:22 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cc4dd7c2c9
11:30 tomboy64 https://bpaste.net/show/fc1dc1224509 <--- this is my build output when trying to compile rakudo.
11:31 tomboy64 this is with http://rakudo.org/downloads/rakudo/rakudo-2016.03.tar.gz
11:32 tomboy64 what my build script (ebuild) does is, it calls `perl Configure.pl --prefix=/usr --sysroot=/usr --make-install --backends=moar,`
11:32 tomboy64 now, is that expected behavior, to rely on those includes? or is it trying to build its own moarvm?
11:33 tomboy64 https://bpaste.net/show/e6960940e6d0 <--- these are the files my moarvm package installs
11:34 masak RabidGravy's https://github.com/jonathanstowe/Lumberjack/blob/master/t/040-dispatcher-basic.t#L23 is yet another use case that would benefit from .enum keys being Enum, not Str
11:35 masak whereas in https://github.com/jonathanstowe/Audio-Sndfile/blob/master/examples/p6sndfile-convert#L8 it sort of doesn't matter
12:29 tomboy64 joined #p6dev
12:43 tomboy64 joined #p6dev
13:07 * [Coke] has a slight concern that moving more perl6 code into nqp:: calls is going to make porting to non-moar harder.
13:07 [Coke] since then there's more places we have to deal with the fact that the ops can perform differently on different backends (or even not be implemented)
13:08 * [Coke] is so far away from code at this point that you should probably not listen to him, though.
13:18 lizmat m: LEAVE "say goodbye"; die
13:18 camelia rakudo-moar cc4dd7: OUTPUT«WARNINGS for /tmp/PgBu1K_e_v:␤Useless use of constant string "say goodbye" in sink context (line 1)␤Died␤  in block <unit> at /tmp/PgBu1K_e_v line 1␤␤»
13:18 lizmat m: LEAVE say "goodbye"; die
13:18 camelia rakudo-moar cc4dd7: OUTPUT«goodbye␤Died␤  in block <unit> at /tmp/NMYKDSlZC1 line 1␤␤»
13:19 lizmat surprising benchmark:
13:19 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now'
13:19 camelia rakudo-moar cc4dd7: OUTPUT«===SORRY!=== Error while compiling /tmp/gayh0ZePtF␤Two terms in a row␤at /tmp/gayh0ZePtF:1␤------> le @b { @b.shift } }; say now - INIT now⏏'␤    expecting any of:␤        infix␤        infix stopper␤        postfix␤        s…»
13:19 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now
13:19 camelia rakudo-moar cc4dd7: OUTPUT«0.4233799␤»
13:19 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now
13:19 camelia rakudo-moar cc4dd7: OUTPUT«0.59715891␤»
13:20 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now
13:20 camelia rakudo-moar cc4dd7: OUTPUT«0.55395872␤»
13:20 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now
13:20 camelia rakudo-moar cc4dd7: OUTPUT«0.63726418␤»
13:20 lizmat huh?
13:20 lizmat I get different results locally
13:21 lizmat $ 6l 'my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now'
13:21 lizmat 0.4222960
13:21 lizmat $ 6l 'my @a = ^100; for ^1000 { my @b = @a; while +@b { @b.shift } }; say now - INIT now'
13:21 lizmat 0.3064966
13:21 lizmat $ 6l 'my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now'
13:21 lizmat 0.28286319
13:22 tadzik I also get shorter times in the latter 2 cases
13:23 tadzik 0.42348009, 0.3310363 and 0.3199181
13:23 timotimo well, camelia is a quite unreliable source for timing information
13:23 timotimo when the result is under a second, you're in quite a bit of danger of the rest of the system messing with your timings
13:23 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now
13:23 camelia rakudo-moar cc4dd7: OUTPUT«0.3149762␤»
13:23 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while ?@b { @b.shift } }; say now - INIT now
13:23 camelia rakudo-moar cc4dd7: OUTPUT«0.3221899␤»
13:23 lizmat m: my @a = ^100; for ^1000 { my @b = @a; while @b { @b.shift } }; say now - INIT now
13:23 camelia rakudo-moar cc4dd7: OUTPUT«0.4029122␤»
13:24 jnthn lizmat: If you MVM_SPESH_DISABLE=1 and run them, how do they vary?
13:26 lizmat the ? and + case are within noise-level, the bare case is 10% slower
13:26 lizmat 0.60365436 vs 0.677837
13:27 jnthn Innerestin' :)
13:27 timotimo clearly we're inlining that prefix operator very well, eh?
13:27 jnthn Yeah
13:27 timotimo impressive
13:27 jnthn And I imagine we might be inlining the .Bool call not at all
13:27 jnthn Because it's an invokish thunk thing because of the boolspec stuff.
13:27 timotimo ah, sounds sensible
13:27 jnthn We should be able to optimize that out and inline .Bool
13:28 jnthn But it's possible we're not doing so yet
13:28 timotimo i didn't see code for that yet
13:28 jnthn I thought we devirt'd istrue in some cases.
13:28 timotimo yeah, but not when the boolspec is "call method"
13:28 jnthn Ah, ok
13:28 timotimo only when it's "unbox an int" or "string-like istrue"
13:28 jnthn If we rewrote that into a normal call then the inliner could nom it I guess :)
13:28 timotimo in general we don't turn things that invoke via "a thing in some spec" into a bare invocation yet
13:29 skids joined #p6dev
13:29 jnthn ah, ok
13:30 jnthn Probably not too hard, and would likely bring the while @b { } case in line with the others
14:03 perlpilot joined #p6dev
14:03 tomboy64 joined #p6dev
14:21 |Tux| joined #p6dev
15:00 lizmat dalek dead ?
15:01 * lizmat just pushed https://github.com/rakudo/rakudo/commit/af145848bba81402f223758c933eba47f6a4e64d
15:01 lizmat "Re-imagine MAIN parameter parsing"
15:01 lizmat - introduce $*MAIN-ALLOW-NAMED-ANYWHERE
15:01 lizmat - if set with True value, will allow named parameters anywhere
15:01 lizmat - should allow "panda install --foo" to work
15:01 lizmat - initialized from environment variable MAIN_ALLOW_NAMED_ANYWHERE
15:03 perlpilot lizmat++
15:03 perlpilot Once people get used to it, do you think that will become the default?
15:03 lizmat the majority of P6 people at QAH thinks so, yes  :-)
15:04 lizmat necessary diff for that:
15:04 lizmat -      %*ENV<MAIN_ALLOW_NAMED_ANYWHERE> // 0;
15:04 lizmat +      %*ENV<MAIN_ALLOW_NAMED_ANYWHERE> // 1;
15:04 tadzik perlpilot: I do hope so :}
15:05 * perlpilot was hoping too,  I just didn't know if there was any push back from anyone.
15:05 tadzik I'd go so far as to say 100% p6 people agree
15:05 tadzik (on the qah)
15:05 timotimo hm, wouldn't we want to have a "perl6" in the environment variable name?
15:05 lizmat afaik, TimToady wasn't in favour of this behaviour
15:06 perlpilot because of the deviation from normal signature processing for MAIN?
15:06 lizmat timotimo: if anything, I think it should be a RAKUDO_ prefix ?
15:07 lizmat perlpilot: I believe so
15:07 perlpilot +1 (RAKUDO_ prefix)
15:07 lizmat then that would also need to be done for DEFAULT_READ_ELEMS
15:08 timotimo oh, yeah
15:09 lizmat if the consensus here it should be both, I'll do that  :-)
15:10 perlpilot aye.
15:20 dalek joined #p6dev
15:20 synopsebot6 joined #p6dev
15:22 dalek rakudo/nom: 2b06f71 | lizmat++ | src/core/ (2 files):
15:22 dalek rakudo/nom: Add RAKUDO_ prefix to environment vars
15:22 dalek rakudo/nom:
15:22 dalek rakudo/nom: - DEFAULT_READ_ELEMS
15:22 dalek rakudo/nom: - MAIN_ALLOW_NAMED_ANYWHERE
15:22 dalek rakudo/nom:
15:22 dalek rakudo/nom: As per http://irclog.perlgeek.de/p6dev/2016-04-22#i_12378252
15:22 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2b06f71409
15:29 [Coke] joined #p6dev
15:29 lizmat m: my $a := once 42; $a = 666; say $a   # this feels wrong, note it's binding, not assigning
15:29 camelia rakudo-moar af1458: OUTPUT«666␤»
15:29 [Coke] yup, still hate IRC and my client.
15:30 [Coke] anyone know what happened to hack?
15:30 [Coke] (I see timotimo had to reboot it...)
15:30 timotimo yeah, sorry about that
15:34 japhb joined #p6dev
15:37 perlpilot timotimo: I take your apology to imply that you broke hack somehow?
15:43 TimToady putting argument processing under the control of the user feels a bit wrong-peggy to me, but I'm not sure where the right peg is
15:45 TimToady env vars are a bit like Vise Grips®, the wrong tool for every job, but it'll do every job
15:46 masak joined #p6dev
15:47 TimToady for instance, what if you call a subprocess that *isn't* expecting arg reordering, does it break?
15:49 TimToady this is the basic problem with any kind of dynamic scoping (of which env vars are a subset): they can change the API contract unexpectedly
15:53 TimToady so while I'm fine with making it easy for a given program to take named args anywhere, I suspect that this should be declared in the lexical scope of the callee (that is, where MAIN is), not the dynamic scope of the caller (that is, using env vars)
15:54 TimToady I'd also like to see a solution that allows nested command structures that are able to distinguish options on the whole command from options on the subcommand
15:55 TimToady merely mushing all the options together does not really accomplish this
15:55 astj joined #p6dev
15:56 TimToady so more like a MAIN that can delegate to sub-MAIN processors
15:59 TimToady such that a sub-MAIN could delegate tertiary commands to a sub-sub-MAIN, and not get confused about which switch is going to which level
15:59 lizmat TimToady: wrt env variable: it felt more it was for debugging
16:00 RabidGravy TimToady, y'know that you only need three things to effect any repair - a hammer, gaffer tape and wd-40 :)
16:00 lizmat but you have a point about subprocesses  :-)
16:00 TimToady dynamic scoping is always kind of an attractive nuisance
16:01 perlpilot joined #p6dev
16:01 TimToady also why we end up with things like %*LANG when surely the "current language" should be defined by the current language object, that is, the cursor
16:03 dalek rakudo/nom: 3ebf31e | lizmat++ | src/core/Main.pm:
16:03 dalek rakudo/nom: No longer use env for $*MAIN-ALLOW-NAMED-ANYWHERE
16:03 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3ebf31edcd
16:12 perlpilot TimToady: but, what do you think about making arg reordering for MAIN the default?
16:14 TimToady in general, I don't like throwing away information by default
16:15 TimToady I'm fine with an explicit reorder-args() call though
16:16 TimToady but I think using reorder-args when you really want cascaded MAIN is going to make it difficult to detect the wrong switch on the wrong subcommand
16:17 timotimo perlpilot: it broke by itself, i'm afraid
16:26 M-tadzik joined #p6dev
16:36 japhb joined #p6dev
16:42 dalek rakudo/nom: 8865365 | lizmat++ | lib/Test.pm6:
16:42 dalek rakudo/nom: Fix '#' escaping
16:42 dalek rakudo/nom:
16:42 dalek rakudo/nom: As suggested as part of leont++ 's PR #578
16:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8865365122
16:45 dalek rakudo/nom: 3ec6b36 | lizmat++ | lib/Test.pm6:
16:45 dalek rakudo/nom: Update copyright date
16:45 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3ec6b3636a
16:57 hankache joined #p6dev
17:02 japhb joined #p6dev
17:10 hankache joined #p6dev
17:16 TimToady joined #p6dev
17:23 dalek rakudo/nom: 0b8e08a | lizmat++ | lib/Test.pm6:
17:23 dalek rakudo/nom: Streamline Test.pm a bit
17:23 dalek rakudo/nom:
17:23 dalek rakudo/nom: Basically, lose scopes when we can.  Unscientifically appears to save
17:23 dalek rakudo/nom: me 10 seconds wallclock on a spectest.
17:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0b8e08ad4b
17:36 brrt joined #p6dev
17:49 sno joined #p6dev
17:57 lizmat drink!   &
18:29 FROGGS joined #p6dev
18:30 perlpilot TimToady: Hmm.  All very good points.  It's too bad we don't have some syntactic help to declare a cascaded MAIN (or any other routine) that would work well with MMD.  It seems to me that something like that would also be useful in web frameworks to do chaining ala Catalyst.
18:33 perlpilot The ++foo ... ++/foo  style options (are those even implemented?) are close in that they can provide a bounded area for separate processing
18:34 TimToady perlpilot: the trick will be to turn an argument list into a sequence of Captures, I suspect
18:34 TimToady or to somehow do the Capture transformation lazily as we match signatures
18:35 TimToady it's a little bit like how map matches a signature to part of an argument list
18:36 TimToady but extended to named args
18:36 perlpilot Lazy Capture transformation feels right.
18:39 TimToady lunch feels about right :) &
19:00 psch joined #p6dev
19:01 psch perlpilot: i've recently revisited rakudo PR #324, which implements the ++ opts
19:02 psch so, no, it's not implemented in nom
19:02 psch moritz++ did voice a valid concern back then, and while i do have an idea how to fix it i couldn't make it work yet
19:04 psch it's also something that could/(was speculated to) handle what PR #752 tries to
19:05 psch the ++ opts that is
19:09 psch i was also thinking whether the Perl6::CommandLine in PR 324 couldn't hand something a bit more structured to the p6-level interpreter
19:10 psch although i haven't thought too much about how that would interact with post-program opt parsing
19:27 brrt joined #p6dev
20:18 sortiz joined #p6dev
20:57 cognominal joined #p6dev
21:55 lizmat joined #p6dev
21:57 MadcapJake What about something like `sub install (Str $name, Bool :$force) is subcommand<MAIN> { ... }` which would allow nested subcommands and each signature would be arguments before any deeper subcommand.
22:01 hoelzro that sounds like the purview of a module
22:14 MadcapJake Perhaps. Also seems like something that could just be powerful/complete ootb.
23:04 dalek rakudo/nom: b3d8169 | lizmat++ | lib/Test.pm6:
23:04 dalek rakudo/nom: Nativy counter for a small speedup
23:04 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b3d8169649
23:23 lizmat good night, #p6dev!
23:24 masak 'night, lizmat++

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary