Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2016-06-08

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

All times shown according to UTC.

Time Nick Message
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today
02:56 skids joined #perl6-dev
03:13 sortiz joined #perl6-dev
05:38 jrusso joined #perl6-dev
07:51 Ven joined #perl6-dev
08:09 |Tux| Holy shizzles!
08:09 |Tux| This is Rakudo version 2016.05-64-g1254bbe built on MoarVM version 2016.05-18-g1339332
08:09 |Tux| test            18.442
08:09 |Tux| test-t          11.323
08:09 |Tux| csv-parser      22.029
08:16 DrForr Someone a few months back mentioned an adverb or something to add to here-docs in order to completely suppress interpolation of {} blocks in strings - Got a handy link?
08:19 DrForr Maybe the :c adverb?...
08:19 DrForr Wrong channel, sorry.
08:24 RabidGravy joined #perl6-dev
08:31 masak [Tux]: wow! o.O
08:31 masak that... is no longer noise.
08:37 Ven joined #perl6-dev
08:39 |Tux| joined #perl6-dev
08:41 timotimo that could be liz' for loop improvements?
09:07 Ven joined #perl6-dev
09:11 jnthn morning, #p6dev
09:12 jnthn Measuring stuff using time is going to be pretty noisy, but yeah, the trend has been downwards of late. :)
09:17 * masak .oO( the trend lines indicate we'll be hitting negative numbers by 2019 )
09:18 jnthn :D
09:19 * jnthn is doing callgrind measurements on most of his opts these days, which lack the noise (and are slooow :))
09:33 jnthn m: say ::(q/$*IN/).WHAT
09:33 camelia rakudo-moar 1254bb: OUTPUT«(Failure)␤»
09:33 jnthn hmm
09:43 dalek rakudo/nom: d86dc49 | lizmat++ | src/core/Any-iterable-methods.pm:
09:43 dalek rakudo/nom: Further 8% improvement on @a.map in sink context
09:43 dalek rakudo/nom:
09:43 dalek rakudo/nom: - remove superfluous nqp::stmts
09:43 dalek rakudo/nom: - use native int flag to indicate status
09:43 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d86dc49fac
09:43 dalek rakudo/return-without-lexotic: f99bb9a | jnthn++ | src/core/Exception.pm:
09:43 dalek rakudo/return-without-lexotic: Update Exception.fail after return changes.
09:43 dalek rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/f99bb9a076
09:44 jnthn Well, that gets me down to less than 10 failing test files in that branch.. :)
09:50 Ven .tell brrt interesting LuaJIT talk by one of the current DartVM engineers: http://mrale.ph/talks/vmss16
09:52 Ven ah, no bot here?
09:52 timotimo no :(
09:53 timotimo alas, i haven't been able to figure out who owns this instance of yoleaux
09:53 Ven okay! well, yolo'd in the other channel. thanks timo :)
09:53 timotimo mhm
09:53 Ven (you also might be interested in that talk)
10:08 * masak .oO( you only live eauxnce )
11:30 dalek rakudo/nom: 9942c42 | lizmat++ | src/core/Any-iterable-methods.pm:
11:30 dalek rakudo/nom: Decont label at iterator creation
11:30 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9942c421c4
11:31 * masak .oO( all this talk of decanting makes me want some wine )
11:31 nine How expensive is deconting actually?
11:32 nine I'd naïvely expect it to be just a pointer dereference post JIT
11:56 jnthn It's not quite that simple yet, but close
11:56 jnthn It's as cheap as an attribute access
11:57 jnthn It's a tad more expensive 'cus we have to do a "was this mixed into" check, but there's plans to eliminate it
11:57 jnthn At which point it will be really just a pointer check
11:57 jnthn uh, pointer deref
11:58 * masak .oO( pointer decaf )
11:58 lizmat yeah, but if it isn't needed in a loop, why put it in a loop, however small, right
11:58 lizmat ?
12:01 jnthn Well, if it's not needed then we might rip it out entirely, but it may still cost a guard... :)
12:03 lizmat pretty sure it's needed, but let me double check  :-)
12:10 nine lizmat: oh your change looks absolutely reasonable to me :) I was just curious.
12:10 * nine hasn't given deconts much thought before
12:17 dalek rakudo/nom: 3d50c98 | lizmat++ | src/core/Any-iterable-methods.pm:
12:17 dalek rakudo/nom: The label case also handled by no phaser case
12:17 dalek rakudo/nom:
12:17 dalek rakudo/nom: It only adds about 1% overhead, but it will make optimising the phasers
12:17 dalek rakudo/nom: case a lot more simple.
12:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3d50c9871a
12:29 lizmat the decont is necessary
12:57 dalek rakudo/nom: 2bd4211 | lizmat++ | src/core/Any-iterable-methods.pm:
12:57 dalek rakudo/nom: Remove now unnecessary CAN_FIRE_PHASERS flag
12:57 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2bd4211a47
12:57 lizmat afk&
13:01 skids joined #perl6-dev
13:21 dalek rakudo/return-without-lexotic: 198ac34 | jnthn++ | src/Perl6/World.nqp:
13:21 dalek rakudo/return-without-lexotic: Avoid CONTROL swallowing return control exception.
13:21 dalek rakudo/return-without-lexotic:
13:21 dalek rakudo/return-without-lexotic: Since `return` now uses real control exceptions, we need to be a bit
13:21 dalek rakudo/return-without-lexotic: more careful when using a `return` in a block with a `CONTROL`. In NQP
13:21 dalek rakudo/return-without-lexotic: especially, since we don't have the need to match on an exception
13:21 dalek rakudo/return-without-lexotic: type.
13:21 dalek rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/198ac3434e
13:38 RabidGravy joined #perl6-dev
13:49 dalek joined #perl6-dev
13:51 brrt joined #perl6-dev
14:07 dalek rakudo/return-without-lexotic: a0f0a17 | jnthn++ | src/Perl6/World.nqp:
14:07 dalek rakudo/return-without-lexotic: Extend handling of colonpair canon. in setting.
14:07 dalek rakudo/return-without-lexotic:
14:07 dalek rakudo/return-without-lexotic: We'll soon be able to switch `return` to be a sub. However, doing so
14:07 dalek rakudo/return-without-lexotic: fixes evaluating code that does a `return` while compiling the
14:07 dalek rakudo/return-without-lexotic: setting. That in turn meant that we produced some better code at
14:07 dalek rakudo/return-without-lexotic: compile-time for certain colonpairs, which in turn triggered an
14:07 dalek rakudo/return-without-lexotic: unhandled case in canonicalization, which broke setting compilation.
14:07 dalek rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/a0f0a17514
14:08 dalek rakudo/return-without-lexotic: 85af0aa | jnthn++ | src/core/control.pm:
14:08 dalek rakudo/return-without-lexotic: Turn `return` and `return-rw` into subs.
14:08 dalek rakudo/return-without-lexotic:
14:08 dalek rakudo/return-without-lexotic: Meaning they're compile-time declarations rather than late-bound
14:08 dalek rakudo/return-without-lexotic: symbols, which opens them up to much better compiler optimization.
14:08 dalek rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/85af0aae77
14:41 dalek nqp/return-without-lexotic: 6822d3a | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
14:41 dalek nqp/return-without-lexotic: Make lex throw ops as not static-inlinable.
14:41 dalek nqp/return-without-lexotic: review: https://github.com/perl6/nqp/commit/6822d3a2fe
14:49 pyrimidine joined #perl6-dev
14:51 dalek rakudo/return-without-lexotic: 28d2c84 | jnthn++ | src/core/control.pm:
14:51 dalek rakudo/return-without-lexotic: Break out `return` into multi candidates.
14:51 dalek rakudo/return-without-lexotic:
14:51 dalek rakudo/return-without-lexotic: Which are simpler and should be something the VM can inline.
14:51 dalek rakudo/return-without-lexotic: review: https://github.com/rakudo/rakudo/commit/28d2c84892
14:54 brrt joined #perl6-dev
16:50 Ven joined #perl6-dev
17:04 MasterDuke joined #perl6-dev
17:10 MasterDuke any idea why rakudo has ~40 instances of 'my $no-sink; ...; $no-sink := $target.push(...) ...;'?
17:11 MasterDuke in at least a couple of the places the spec-tests all pass if you remove the $no-sink entirely and performance seems to improve slightly
17:12 [Coke] MasterDuke: were they added by Larry?
17:12 [Coke] ISTR he did a lot of sink work immediately pre-xmas
17:13 lizmat it's because if we don't put a $no-sink there, the .sink method will be called on the rsult
17:13 lizmat which is something we may not want for some situations
17:14 lizmat that's at least my understanding of it
17:16 nine yes, that's the reason
17:16 b2gills There are performance reasons, and API reasons for $no-sink
17:17 MasterDuke hmm. looking at a profile before and after removing it from Iterator.push-all, the number of sink calls is the same
17:28 geekosaur it will depend on the context in which it occurs
17:58 MasterDuke in all the profiles i've looked at the performance is better without $no-sink. also, the spec-tests pass
17:59 MasterDuke just trying to learn more here, are the API reasons documented anywhere i could take a look at?
18:00 timotimo it could very well be that Iterator.push-all isn't covered at all by the spec tests?
18:02 MasterDuke not sure i want to profile all the spec-tests to find out...
18:02 MasterDuke guess i can look for something like code i was running
18:02 timotimo maybe not profile ...
18:02 timotimo i have a branch of MoarVM that allows you to get a line-by-line coverage report
18:03 timotimo it's not perfect, because for many lines we don't record annotations at all, but a simple grep over moar --dump foo.moarvm helps with that
18:04 MasterDuke well, S32-str/split-simple.t has "split_test 'a1b24f'.split(/\d+/),  <a b f>, 'Str.split(/regex/)';"
18:05 MasterDuke which looks pretty close to what i was doing, but i don't know all the other contexts Iterator.push-all could be called in
18:08 timotimo some custom iterators may implement their own push-all for performance reasons
18:09 MasterDuke then wouldn't they not care if the default one changes?
18:09 timotimo correct. that's why you might not see spec test fallout from changing the no-sink in there
18:12 MasterDuke there are only 6 calls to any push-all in all of rakudo
18:13 * timotimo shrugs
18:13 timotimo i haven't dipped my toe into iteration code in a long while
18:14 lizmat MasterDuke: but those few ones are hot code paths, afaik
18:16 MasterDuke 2 are in Array.pm, 2 are in List.pm, 1 in metaops.pm, and 1 in Iterator.pm
18:17 MasterDuke it looks like Array and List are redifining their own push-all
18:17 MasterDuke Iterator is obviously using its own, i think metaops is using Iterator's
18:18 MasterDuke well yeah, if those are hot paths wouldn't it make sense to optimize them as much as possible?
18:18 tomboy64 joined #perl6-dev
18:25 MasterDuke interesting. Array.kv creates a new Seq which does Iterator and defines its own push-all, which is a bit different since it pushes both key and value, but neither of those pushs are sunk
18:25 MasterDuke just '$target.push(nqp::p6box_i($key));' and '$target.push($pulled);'
18:26 MasterDuke the other two push-alls redefined in Array do $no-sink their push
18:27 MasterDuke oops, sorry, that was List
18:41 dalek rakudo/nom: 30b33e3 | lizmat++ | src/core/Any-iterable-methods.pm:
18:41 dalek rakudo/nom: Make @a.map with phasers about 10% faster
18:41 dalek rakudo/nom:
18:41 dalek rakudo/nom: - use native int flags where possible
18:41 dalek rakudo/nom:   Couldn't do this for $!NEXT, because apparently using a native int
18:41 dalek rakudo/nom:   attribute in a nqp::if() is a very bad thing to do performance wise
18:41 dalek rakudo/nom:   (like making the whole iterator logic 2x as slow)
18:41 dalek rakudo/nom: - initialize the $!NEXT flag at iterator creation time
18:41 dalek rakudo/nom:   Probably didn't matter, but part of trying to get rid of the
18:42 dalek rakudo/nom:   $!did-init logic.
18:42 dalek rakudo/nom: - use nqp::if instead of postfix if/unless
18:42 dalek rakudo/nom:   To at least make this piece of code consistent.
18:42 dalek rakudo/nom: - use a native int flag for running state
18:42 dalek rakudo/nom:   Rather than checking for IterationEnd.
18:42 lizmat MasterDuke: thanks for the extra set of eyes
18:42 lizmat the maze can be quite intimidating at times  :-)
18:44 lizmat jnthn: would it make sense to create a setting global $NO-SINK for stuff to be not sinked to ?
18:44 lizmat so at least we wouldn't need to burden local scopes with its creation ?
18:44 MasterDuke lizmat: you're welcome, it's fun
18:48 jnthn lizmat: No
18:48 jnthn lizmat: It'll prevent inlining
18:48 lizmat ok
18:49 lizmat jnthn: even if it is a lexcial ?
18:49 lizmat *lexical ?
18:49 jnthn Yes, things that refer to lexical variables outside of their scope can't be inlined.
18:50 lizmat so: my $no-sink; for { $no-sink := ... }  would be bad ?
18:50 jnthn That's OK, I thought you meant moving it out further than the routine?
18:50 jnthn (e.g. setting global)
18:51 jnthn The other reason setting global would be bad is that it'll hurt concurrency
18:51 jnthn By creating loads of contention on the cache line
18:51 jnthn Holding the var
18:51 MasterDuke fyi, i tried removing all $no-sinks from all push-alls, so far all spec-tests have passed, but spec/integration/advent2013-day14.t appears to have hung
18:53 MasterDuke that may have just been from setting TEST_JOBS=6, it passes when run by itself
18:54 lizmat jnthn: ok, message received :-)
18:54 hankache joined #perl6-dev
19:10 dalek rakudo/nom: 965ca6a | lizmat++ | src/core/Any-iterable-methods.pm:
19:10 dalek rakudo/nom: Squeeze a few more % out of @a.map with phasers
19:10 dalek rakudo/nom:
19:10 dalek rakudo/nom: - turn the if/else into a ternary inside the loop
19:10 dalek rakudo/nom:
19:10 dalek rakudo/nom: Oddly enough, it turned out to be impossible to make the outer
19:10 dalek rakudo/nom: while loop a postfix while (either with "while" or with nqp::while):
19:10 dalek rakudo/nom: It would give "Cannot reference undeclared local '__lowered_lex_3194"
19:10 dalek rakudo/nom: during the MAST stage.
19:10 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/965ca6a2a5
19:21 Ven joined #perl6-dev
19:48 dalek rakudo/nom: 0a16ed5 | TimToady++ | src/Perl6/Actions.nqp:
19:48 dalek rakudo/nom: always mark enum expression as wanted
19:48 dalek rakudo/nom:
19:48 dalek rakudo/nom: Previously we only marked comma lists, but there are other ways to
19:48 dalek rakudo/nom: generate lists, including range ops.
19:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0a16ed597d
19:51 MasterDuke after a break for errands, ran a complete spectest with all $no-sinks removed from all push-alls, everything passed
19:53 lizmat MasterDuke: try making a class with a .sink method that says "sunk", then put it in a list and iterate over it
19:54 lizmat it should never say "sunk"
19:54 lizmat we should probably need to add tests for this
19:56 brrt joined #perl6-dev
19:59 dalek rakudo/nom: 072a6c2 | lizmat++ | src/core/Any-iterable-methods.pm:
19:59 dalek rakudo/nom: Make @b = @a.map with phasers about 20% faster
19:59 dalek rakudo/nom:
19:59 dalek rakudo/nom: - use nqp::eqaddr instead of =:=
19:59 dalek rakudo/nom: - use nqp::not_i instead of !
19:59 dalek rakudo/nom: - remove nqp::stmts where possible by reducing number of lines to 1
19:59 dalek rakudo/nom: - use postfix if where possible
19:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/072a6c2566
19:59 MasterDuke m: my class A { method sink { say "sunk"; } }; say "hi" for (A.new, A.new)
19:59 camelia rakudo-moar 965ca6: OUTPUT«hi␤hi␤»
19:59 MasterDuke lizmat: like that? i get the same output on my build
20:00 lizmat m: my class A { method sink { say "sunk"; } }; A.new
20:00 camelia rakudo-moar 965ca6: OUTPUT«sunk␤»
20:00 lizmat hmmm
20:01 * lizmat would love to be able to get rid of $no-sink
20:01 lizmat jnthn: opinions ??  ^^
20:02 [Coke] gah, TimToady++ is comitting again! ;)
20:17 jnthn I'm pretty sure they're there for a reason...would be good to add tests.
20:17 jnthn I'd rather not second-guess 'em
20:17 jnthn And break stuff
20:20 lizmat jnthn: another weird thing:
20:20 lizmat m: use nqp; class A { has int $.a; method a() { nqp::if($!a,42) } }; my $a = A.new; for ^1000000 { $a.a }; say now - INIT now
20:20 camelia rakudo-moar 072a6c: OUTPUT«0.54265644␤»
20:20 lizmat m: use nqp; class A { has $.a; method a() { nqp::if($!a,42) } }; my $a = A.new; for ^1000000 { $a.a }; say now - INIT now
20:20 camelia rakudo-moar 072a6c: OUTPUT«0.33593612␤»
20:20 lizmat m: say .543 / .336
20:20 camelia rakudo-moar 072a6c: OUTPUT«1.616071␤»
20:21 lizmat jnthn: so, using a native int attribute in an nqp::if() is 1.6x slower than not using a native int
20:22 lizmat jnthn: should I rakudo bug this performance difference ?
20:22 jnthn NO
20:22 jnthn *No
20:22 lizmat ok
20:22 jnthn Note that you're if is not in void context there
20:23 jnthn So there's very probably a boxing going on at some point
20:23 jnthn Oh
20:24 lizmat even if I put it in void context, I see similar numbers
20:24 jnthn And since it's a method call also...we don't know
20:24 jnthn Oh, no, you accessed it as $!a
20:24 jnthn Hm, more curious in void context.
20:24 jnthn Though did you do it with nqp::if or a statement if?
20:24 lizmat m: use nqp; class A { has int $.a; method a() { nqp::if($!a,42) } }; my $a = A.new; for ^1000000 { $a.a; Nil }; say now - INIT now
20:24 camelia rakudo-moar 072a6c: OUTPUT«0.3547077␤»
20:24 lizmat m: use nqp; class A { has $.a; method a() { nqp::if($!a,42) } }; my $a = A.new; for ^1000000 { $a.a; Nil }; say now - INIT now
20:24 camelia rakudo-moar 072a6c: OUTPUT«0.24572299␤»
20:25 lizmat m: say .358 / 246
20:25 camelia rakudo-moar 072a6c: OUTPUT«0.0014553␤»
20:25 jnthn But it's not in void context in method a
20:25 lizmat m: say .358 / .246
20:25 camelia rakudo-moar 072a6c: OUTPUT«1.455285␤»
20:25 jnthn So it's still being returned
20:26 jnthn m: use nqp; class A { has $.a; method a() { nqp::if($!a,42); Nil } }; my $a = A.new; for ^1000000 { $a.a }; say now - INIT now
20:26 camelia rakudo-moar 072a6c: OUTPUT«0.50680681␤»
20:26 jnthn m: use nqp; class A { has $.a; method a() { nqp::if($!a,42); Nil } }; my $a = A.new; for ^1000000 { $a.a }; say now - INIT now
20:26 camelia rakudo-moar 072a6c: OUTPUT«0.47445983␤»
20:26 jnthn Hm, curious
20:27 lizmat m: use nqp; class A { has int $.a; method a() { nqp::if($!a,42); Nil } }; my $a = A.new; for ^1000000 { $a.a }; say now - INIT now
20:27 camelia rakudo-moar 072a6c: OUTPUT«0.57380869␤»
20:27 jnthn m: use nqp; class A { has $.a; method a() { nqp::if($!a,42); Nil } }; my $a = A.new; for ^1000000 { $a.a; Nil }; say now - INIT now
20:27 camelia rakudo-moar 072a6c: OUTPUT«0.5022255␤»
20:27 lizmat fwiw, in a profile I see a IntAttrRef allocation for each iteration
20:28 jnthn Ah
20:28 lizmat is that to be expected ?
20:28 jnthn Yes, in so far as we're not always very good at optimizing them away :)
20:28 jnthn Spesh doesn't understand them at all yet.
20:28 lizmat ok, then I suggest this be a LHF for optimizing rakudo
20:29 lizmat because there's a lot of them in the core
20:29 lizmat or there *could* be a lot of them
20:29 jnthn Well, except spesh and Moar are improving continually also :)
20:30 MasterDuke btw, re the $no-sinks, not all the push-alls had them. with the admittedly quick run through the code i did, i didn't notice any obvious reason why some did and some didn't
20:30 AlexDaniel joined #perl6-dev
20:30 lizmat well, I'm about to basically remove all native int attributes from the core for this reason
20:30 jnthn I wouldn't
20:30 lizmat MasterDuke: sometimes you can be sure there won't be an object that has a custom .sink
20:31 lizmat jnthn: I would mark them as fixable as soon as spesh / optimizer knows how to grok native attributes properly
20:32 jnthn What are you going to change them to? Bool?
20:32 lizmat Int I guess
20:34 jnthn OK, but what else happens with them?
20:34 lizmat usually they're set to 1 to indicate some condition has been met
20:34 jnthn I mean, presumably they're getting set/incremented instead of just read/boolified all the time
20:34 jnthn Ah
20:34 jnthn Then bool is more natural? :)
20:35 lizmat yeah, but then I would need to say = True and then later when native ints *would* work fast, I would have to change more than just the declaration
20:37 jnthn True
20:37 jnthn It's fairly clear, I think, that the native int one will be the more optimizable
20:37 jnthn Up to you if you want to change it now, then change it back later
20:38 lizmat ok, it's a deal  :-)
20:40 jnthn Dunno if you saw the result on #moarvm earlier today, but in the branches I'm working on improving return, `sub foo($a) { if $a { return 1 } }; for ^2000000 { foo(1) }` runs in around half the time
20:40 lizmat cool!
20:42 brrt yes, really cool
20:44 brrt also, please don't kill the natives :-)
20:44 brrt how else are we going to show off the new spesh/jit swagger
20:44 lizmat brrt: you fix native int attribute performance, I'll put them back in the core, ok ?  :-)
20:45 brrt sounds like a plan, except that i don't really know the details
20:45 brrt :-)
20:46 lizmat I mean, 5+% performance improvement on @a.map by just doing s/int/Int/ is too easy a change to not do
20:46 brrt actually, i'm going to sleep, i'll have to wake up early enough tomorrow
20:46 lizmat good night, brrt
20:46 brrt aye... just renember to change it back when we've proven the reverse is better
20:46 brrt see you!
20:54 dalek rakudo/nom: 60731a0 | lizmat++ | src/core/Any-iterable-methods.pm:
20:54 dalek rakudo/nom: Make @a.map with phaser about 5% faster still
20:54 dalek rakudo/nom:
20:54 dalek rakudo/nom: It appears native int attributes incur an overhead that is still not
20:54 dalek rakudo/nom: optmized away.  So, until then we'll use Int instead of int and mark
20:54 dalek rakudo/nom: these lines for change when things get better.
20:54 dalek rakudo/nom:
20:54 dalek rakudo/nom: See http://irclog.perlgeek.de/perl6-dev/2016-06-08#i_12630061
20:54 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/60731a0a24
21:31 jnthn Rest time...hopefully I'll get a little more time on the return stuff tomorrow to fix the last regression. After that, will need to port a few changes to the JVM.
21:32 jnthn *JVM backend
21:33 lizmat good night, jnthn
21:54 MasterDuke lizmat: since i've already done the work of removing those $no-sinks, would it be a problem to put them in a PR, in case it's decided to get rid of them at some point?
23:36 skids joined #perl6-dev

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