Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-04-12

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

All times shown according to UTC.

Time Nick Message
00:00 samcv note to self: skin calming bodywish stings horribly if you accidently get in your eyes
00:00 samcv i feel they should have put a warning label on it.
00:00 timotimo you get what you wish for, eh?
00:01 samcv "Skin calming eye irritant body wash"
00:01 samcv i'm sure it would sell millions
00:02 MasterDuke the "allocated" tab: http://i.imgur.com/zgZAAGF.png
00:03 timotimo i wonder if it, like, endlessly recurses or something?
00:03 samcv heaptrack is good yes MasterDuke ? how should i compile mvm to get best diagnostic stuff on it.
00:03 samcv just full debug?
00:04 MasterDuke i usually just do --debug=3
00:04 MasterDuke hm, though i think i'm still using the version i compiled with --optimize=1
00:05 MasterDuke timotimo: would that effect the profile?
00:05 MasterDuke samcv: yeah, i've liked it
00:05 timotimo shouldn't
00:05 timotimo heaptrack most likely just instruments malloc and free and such
00:05 MasterDuke believe so
00:05 timotimo those are cross-.so-file
00:06 timotimo so the compiler wouldn't muck them up
00:09 samcv wow my gh-pages branch is already really big. i'm trying to check it out now so i can add a page to it
00:09 samcv it's still unpacking objects after 30 secs
00:10 samcv well not really meant for anybody to check out anyway.
00:11 timotimo i wonder if you should force-push over it a bunch so that it frees up space
00:11 timotimo or instead keep the history because history is good?
00:12 samcv history is good
00:12 samcv idk i may force push over it if it gets too big
00:12 timotimo right
00:12 samcv but nobody is supposed to check out that branch
00:12 timotimo can you "git clone" without grabbing the extra branch?
00:12 samcv it just really keeps history. the main branch has never had any appimages in it
00:12 samcv yeah
00:12 samcv i don't think it grabs it
00:12 timotimo i know you can --depth=1, but that leaves you with a repo that can't do stuff
00:12 samcv i should try though
00:13 MasterDuke if anybody is interested, profile of `htmlify.pl --no-highlight --sparse=50`: https://gist.github.com/MasterDuke17/754d88e9805171a89b273e9516c87ae3
00:13 MasterDuke samcv: what's gh-pages?
00:13 timotimo aaargh the extremely long filenames :D
00:13 samcv it can host websites
00:14 samcv i'm gonna set up a github pages for appimages and also one for moarvm coverage reports
00:14 MasterDuke ah, right. very cool
00:14 timotimo aha, it spends a whole lot of time inside "wait"
00:14 samcv so we'll get automated mvm coverage reports and i won't have to do any  work
00:14 timotimo wait, is that without --parallel?
00:14 samcv well. after it's automated
00:14 timotimo like, it doesn't highlight, so what is it waiting for?
00:14 MasterDuke --parallel=1
00:15 samcv ok yeah it's cloning everything when i ask to clone it
00:15 MasterDuke i.e., the default
00:15 timotimo that could be harsh
00:16 timotimo if every appimage is 10 megs big
00:17 timotimo and you do daily blead and master builds
00:17 MasterDuke if i remember how i originally did it (though it's been changed since then by others), --parallel is just how many things to `start` at once
00:18 timotimo right
00:18 timotimo oh, so the main thread probably awaits all-of the started things
00:18 MasterDuke so --parallel=1 is essentially `start` and then immediately `await`
00:18 timotimo right
00:18 timotimo in that case we'll get like no info out of the profile
00:18 timotimo since it doesn't know how to reach into other threads' data yet
00:20 MasterDuke i do remember when i first did it, that with --parallel=10, only 1 in 5 runs would finish, but running it 5 times was still faster than once non-parallelized
00:20 timotimo the problem with that is that the moment we reach "end of profile, collect data now", all the other threads are like "yup, still runnin'!"
00:21 MasterDuke so think you can knock out making the profiler thread-aware tonight?
00:21 MasterDuke that's what, a good 10-15min job?
00:21 samcv git clone --single-branch https://github.com/samcv/rakudo-appimage.git # will only clone the master branch
00:21 samcv and is super fast
00:21 samcv so put a readme
00:22 timotimo yes, readme be good
00:22 timotimo i gotta go sleep now
00:22 timotimo have a good one!
00:22 timotimo oh
00:22 samcv in the future, sleep is illegal
00:22 timotimo how do you feel about using the appimages to travis-test our ecosystem modules?
00:23 samcv sure
00:23 timotimo thought so!
00:23 timotimo it should save boatloads of time
00:23 samcv automate everything
00:24 samcv and can have it autocommit reports too now that i've mastered that
00:24 samcv though i still have no clue how gh-pages works
00:24 timotimo well, you put the right files in there an dit ends up on like samcv.github.io or something
00:26 samcv yep
00:27 samcv https://samcv.github.io/rakudo-appimage/ ok well i got it sorta working
00:28 timotimo ah, yes, good
00:29 timotimo i believe gh-pages can also run some static-website-generators for you
00:29 timotimo but that may be outdated knowledge
00:29 timotimo okay, bedtime for reals
00:30 MasterDuke later
01:03 samcv well i got this https://samcv.github.io/rakudo-appimage/
01:03 samcv so that's nice
01:03 samcv got it generating a basic inde
01:36 MasterDuke what's star-testing?
01:46 samcv it's rakudo star. the testing refers to the appimage thing
01:46 samcv makes sense if you compare the source of perl6-stable and perl6-testing here https://github.com/samcv/rakudo-appimage
01:46 samcv the testing one resolves relative paths and such
01:46 samcv the other one thinks paths that are relative are relative to the appimages virtual disk
01:46 MasterDuke ah, ok
01:47 samcv .o(if we build an appimage with EVERY eco module then who cares if you can't install them)
01:47 samcv heh
01:47 samcv brb walk
01:47 samcv gonna walk the puppy
02:02 samcv though i'm about to change testing to stable i think. becuase i can't run any of the rakudo sanity tests
02:02 samcv without it
02:20 samcv gonna go ahead and remove the appimages that were made before testing had been implemented so people don't dl borked files (cuase it only updates files if they pass a travis build) but before they passed even if it didn't properly work
05:49 tomboy64 joined #perl6-dev
05:51 RabidGravy joined #perl6-dev
05:52 [Tux] This is Rakudo version 2017.03-222-g184d49996 built on MoarVM version 2017.03-128-gc9ab59c6
05:52 [Tux] csv-ip5xs        3.028
05:52 [Tux] test            12.611
05:52 [Tux] test-t           5.160 - 5.172
05:52 [Tux] csv-parser      12.874
06:01 samcv left #perl6-dev
06:01 samcv joined #perl6-dev
06:56 RabidGravy joined #perl6-dev
07:58 sasheto joined #perl6-dev
08:00 [TuxCM] joined #perl6-dev
08:37 stmuk_ joined #perl6-dev
08:41 stmuk joined #perl6-dev
08:54 samcv .tell Zoffix HTML::Parser is broken due to IO changes
08:54 yoleaux samcv: I'll pass your message to Zoffix.
08:55 samcv actually haven't updated my perl6 in a day or two gonna do that
09:14 samcv err wait it's zef doing it
09:15 tadzik joined #perl6-dev
09:24 ilmari[m] joined #perl6-dev
09:34 lizmat afk for the coming day or so&
10:01 samcv Zoffix, ok it's the XML module that's failing Calling from-xml-stream(IO::Handle) will never work with declared signature (IO $input) on latest rakudo
10:03 samcv weird and i get that error if i do `echo hi | perl6` too
10:03 samcv odd
10:04 samcv echo "say 'welcome';" | perl6 # this shows the error. but this -> echo "say 'welcome'; exit;" | perl6 #this is fine
10:10 pmurias joined #perl6-dev
10:21 pmurias why does: sub infix:<++> {'this creates %?LANG'}; CALLER::<%?LANG>; work?
10:21 pmurias the %?LANG doesn't seem to be installed as dynamic
10:22 pmurias m: sub infix:<++> {...}; say(VAR(%?LANG).dynamic)
10:22 camelia rakudo-moar 184d49: OUTPUT: «Nil␤»
10:25 geekosaur it's "dynamic" but at compile time; by run time it's presumably no longer dynamic
10:26 geekosaur by run time it's too late to change the language the code was compiled with
10:28 geekosaur at one point there was a bug allowing ?-twigil vars to be created uselessly at run time; if you managed to do so, maybe you found a remaining edge case?
10:33 samcv night all
10:33 pmurias night
10:34 pmurias geekosaur: dynamic refers the ability to get the variable with CALLER, not to overwrite it
10:35 geekosaur that's not the point. the point is compile time. the caller nevertheless has a language it was compiled in, and presumably the compile-time $?LANG is therefore available for it
10:35 geekosaur it's not *runtime*-dynamic, except in the sense that every scope has a language it was compiled with and you can introspect that scope for that language
10:53 pmurias geekosaur: doesn't dynamic refer to the ability to introspect it from the caller (which EVAL depends on)
10:53 pmurias geekosaur: i'm trying to figure out what's wrong on the js backend that CALLER::<%?LANG> doesn't work
10:54 Zoffix .
10:54 yoleaux 08:54Z <samcv> Zoffix: HTML::Parser is broken due to IO changes
10:54 geekosaur afaik dynamic means * twigil
10:54 Zoffix XML has been already fixed 2 days ago. Update it.
10:55 samcv the version was not bumped
10:56 samcv can can --force install it. i'll open an issue
10:58 samcv Zoffix, i made sure i ran zef upgrade. but people don't always bump versions :\
10:58 timotimo pmurias: i think geekosaur didn't mean "dynamic" as in "perl6 dynamic variable", just "based on the callstack, not on lexical environments"
10:59 geekosaur I was walking around that (hence scare quotes on "dynamic")
11:00 geekosaur but yes, it's confusing
11:00 geekosaur and because it's a compile time thing, it's likely not going to obey simple rules
11:01 timotimo the value of %?LANG is dynamic in the compiler because the compiler has a call stack that resembles the lexical scopes of the program it's compiling
11:01 samcv and looks like even --force isn't working. it's using the already cached files in ~/.zef/store
11:01 samcv eek
11:11 timotimo there's "zef nuke" :P
11:11 pmurias n
11:11 pmurias sorry
11:27 Zoffix zef --/cache --force install XML
11:27 * Zoffix nukes everything on every upgrade
11:27 Zoffix update-perl6 is aliased to `rm -fr ~/.zef; rm -fr ~/.perl6; rm -fr ~/.rakudobrew/; git clone https://github.com/tadzik/rakudobrew ~/.rakudobrew; rakudobrew build moar; rakudobrew build zef; zef --/test install … long list of modules I use …
11:28 * Zoffix adds --serial to zef switches in that command...
11:40 pmurias (try ...)--
11:46 Zoffix ZofBot: am I getting fired?
11:46 ZofBot Zoffix, On the other hand, pragmas designed to influence deep semantics should not be named identically, though of course some similarity is good
11:47 Zoffix Man, I still don't have access to Adobe's Creative Suite at work.
11:48 Zoffix TFW you can't figure out if someone's amazingly incompetent to not renew a license or you're getting canned so they didn't bother renewing it :S
11:56 * Zoffix looks at .slurp-rest impl
11:56 Zoffix takes :bin and :enc...
11:59 Zoffix with a where clause checking :bin is true in one multi
12:00 pmurias why does Scalar.dynamic returns False, True *and* Nil, Nil being treated as not dynamic by the optimizer and as dynamic by the caller?
12:01 pmurias s/caller/CALLER
12:01 Zoffix On replacement .slurp(), don't wanna do that. Going to use $!encoding to figure out mode to use. Keeps it all the same for all other routines.
12:02 pmurias CALLER:: uses the "does not give a f**k" form of try so it might be treating it that way accidently
12:02 Zoffix What form is that?
12:16 pmurias try without a handler
13:01 TimToady joined #perl6-dev
13:11 Zoffix ===SORRY!===
13:11 Zoffix arg expression cannot be void
13:11 Zoffix Well, that's new :|
13:12 MasterDuke i've never seen that before either
13:13 Zoffix was due to dd in dd nqp::seekfh($!PIO, $size, 0)
13:13 Zoffix say works there too
13:14 MasterDuke happens in src/vm/moar/QAST/QASTOperationsMAST.nqp:1333
13:36 timotimo ah, yeah, seekfh doesn't return anything
13:37 timotimo that seems to upset the compiler, though the message could definitely be less LTA
13:38 MasterDuke `nqp::die("arg expression cannot be void") if $arg_mast.result_kind == $MVM_reg_void;`
13:38 MasterDuke what could it do instead of die?
13:40 timotimo does it point anywhere near where the problem happened?
13:41 timotimo can i get at the JSONPrettyGrammar inside the rakudo internals?
13:41 timotimo like, from inside user level perl6 code?
13:44 timotimo it's probably internal to that. .. bleh, need to use something else,t hen
13:45 Zoffix_ joined #perl6-dev
13:45 Zoffix_ I'm a genius!
13:46 Zoffix_ Wrote .slurp that's ~16x faster... but the genius part is I wrote it in /tmp/z.p6 file and then tried to slurp a very huge file, thereby "forkbombing" my box.
13:46 Zoffix_ It looks frozen solid, but I don't wanna reboot it 'cause I'll lose that file :P
13:48 MasterDuke can you ssh in to it?
13:49 Zoffix_ Doubt it. I don't think it even has ssh server installed. (It's a local VirtualBox VM)
13:49 Zoffix_ There's not much code lost and I remember it from memory, I'm just amused by how I lost it :)
13:51 MasterDuke wonder how easy it is to browse virtualbox's disk images. i.e., just close it saving state and then access the fs inside the image
13:52 timotimo boot a livecd into the box perhaps?
13:52 timotimo if the /tmp gets freed at startup
13:52 timotimo if /tmp is a memdisk, however ...
13:59 MasterDuke timotimo: i can repro it locally, but it doesn't say anything about where in my script there's a problem
14:00 timotimo right, you think we can figure that out from there? do we have a .node somewhere in the vicinity?
14:02 MasterDuke `$arg, $qastcomp, @ins, @arg_regs, @arg_flags, @arg_kinds` are args to handle_arg. `$arg_mast := $qastcomp.as_mast($arg), my int $arg_mast_kind := $arg_mast.result_kind;` are the only variables created before it dies
14:11 timotimo hm. i wonder how other places in there make error messages ... if they do at all?
14:11 MasterDuke nqp::die("arg code did not result in a MAST::Local") unless $arg_mast.result_reg && $arg_mast.result_reg ~~ MAST::Local;
14:11 MasterDuke is the very next line
14:11 MasterDuke but that's the only other die in that functino
14:12 timotimo maybe we should stash this for later
14:12 MasterDuke *function
14:12 timotimo though maybe the $qastcomp has something for us? not sure what $arg exactly would be
14:13 MasterDuke if you're in the middle of making grammars faster don't get distracted by this, i'll play around a bit
14:13 timotimo sadly, it won't make grammars much faster all in all
14:13 timotimo the improvement won't scale, it's just a tiny bit off of startup time
14:14 MasterDuke improving startup time is awesome, it makes everything else feel faster
14:14 timotimo and it only cuts off of the startup time when startup includes running a user-made grammar
14:14 timotimo so regular rakudo startup is not going to be changed
14:17 MasterDuke well, one of the perl 6 selling points is custom grammars, and #perl6 certainly sees a lot of questions about them, so it's a good optimization
14:18 timotimo i guess it's fair
14:19 Zoffix_ left #perl6-dev
14:30 Geth ¦ rakudo/nom: 064b5858b2 | (Timo Paulssen)++ | 3 files
14:30 Geth ¦ rakudo/nom: allow Grammars to precompute their nfas during precompilation
14:30 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/064b5858b2
14:34 MasterDuke nice
14:38 timotimo well, if you load a precompiled module that has a grammar in it, like, a million times ... i'm sure it'll save you a second or two!
14:39 MasterDuke do the savings depend on the size of the grammar?
14:39 jnthn Hm, I should try it against the YAMLish profile I took
14:39 timotimo depends on the amount of stuff in the grammar that you touch
14:40 timotimo though "touching" in this sense can be very contagious and far-reaching
14:40 jnthn According to the profile I saw, we spent a ton of time in merge_substates or related when parsing a small (just 5-10 lines) YAML file. It was like 50% of the parse time.
14:41 jnthn I'll reproduce that and then upgrade Rakudo :)
14:41 timotimo 50% of 10ms is still just 5ms :D
14:41 MasterDuke would this help Text::CSV since it uses Slang::Tuxic? or Perl6::Parser?
14:42 timotimo hm, not quite sure
14:54 Zoffix Killed my VM again, but now I'm surprised. It's got two loops of for ^$x { my $fh = $s.open; $ = $fh.slurp-rest; $fh.close } slurping a 6MB file 300 times...
14:55 Zoffix I would've figured the $ would be reused and previous slurpage cleaned up?
14:56 jnthn That isn't how scalars in Perl 6 work
14:56 jnthn The Scalar stores a reference to something
14:56 jnthn The something is the expensive thing
14:56 jnthn There's probably some missing memory pressure somewhere
14:56 jnthn If it's being overly hungry
14:57 Zoffix Oh, so all those slurps still live in memory until gc
14:59 Zoffix OK. Now I'm getting sane numbers again :)
15:05 Zoffix k, my new IO::Handle.slurp in binary mode is 16x faster and uses 2.1x less memory
15:05 Zoffix ZofBot: but will it blend?
15:05 ZofBot Zoffix, The mark characters are ignored only for the purpose of determining the truth of the assertion; the actual text matched includes all ignored characters, including any that follow the final base character
15:06 jnthn Zoffix: Wow, looking forward to seeing that patch :)
15:06 Zoffix I still have to run stresstest on it :}
15:07 timotimo i wonder what we did bad in slurps binary mode
15:10 jnthn Oh dear, bumping Rakudo version doesn't end too well for $dayjob project
15:10 Zoffix oops
15:10 jnthn No such method 'abspath' for invocant of type 'IO::Path' in block  at /home/jnthn/dev/MoarVM/install/share/perl6/site/sources/8922A2BA7BE89CE9C1AF2017551EC8B1435BA924 (Digest::SHA1::Native) line 5
15:10 Zoffix jnthn: change to .absolute
15:11 Zoffix jnthn: oh, upgrade the module
15:11 Zoffix It was fixed yesterday
15:11 jnthn Oh, cool :)
15:11 Zoffix huggable: IO kills
15:11 huggable Zoffix, 15 x [✔]; 3 x [✘]: See https://gist.github.com/zoffixznet/0ea1f4db792fc674abdde73f8dd11cc1
15:11 jnthn Doing so :)
15:11 Zoffix um... zef --force install Digest::SHA1::Native
15:11 Zoffix 'cause the version wasn't bumped.
15:11 * Zoffix notes to that for any future PRs :|
15:11 jnthn Aww, the version wasn't bumped
15:12 * Zoffix hopes that's the only breakage :}
15:25 jnthn The test suite thinks so :)
15:25 jnthn Need to check it on Windows also
15:25 [TuxCM] joined #perl6-dev
15:25 MasterDuke `$arg_mast := $qastcomp.coerce($arg_mast, $MVM_reg_str) if $arg_mast.result_kind == $MVM_reg_void;` makes `./nqp-m -e 'say(nqp::seekfh(nqp::open("a", "r"), 1, 0))'` just print an empty string instead of dying
15:26 MasterDuke and passes spectest. but it seems a bit hackish...
15:26 jnthn That loosk...weird
15:27 MasterDuke before you'd get: `===SORRY!===arg expression cannot be void`
15:27 jnthn That seems more sensible.
15:28 MasterDuke then any way to get some information about where things went wrong into the message?
15:28 Zoffix buggable: speed 2
15:28 buggable Zoffix, ▁▁ data for 2017-04-12–2017-04-12; range: 5.160s–5.172s; ~0% difference
15:28 Zoffix buggable: speed 3
15:28 buggable Zoffix, ▁▃▃ data for 2017-04-11–2017-04-12; range: 4.996s–5.172s; 4% slower
15:28 Zoffix buggable: speed 4
15:28 buggable Zoffix, ▁▂▄▄ data for 2017-04-11–2017-04-12; range: 4.942s–5.172s; 5% slower
15:28 Zoffix buggable: speed 6
15:28 buggable Zoffix, ▃▁▁▂▄▅ data for 2017-04-10–2017-04-12; range: 4.921s–5.172s; 3% slower
15:29 Zoffix The 5% slower seems to be from the MoarVM bump last night: https://github.com/rakudo/rakudo/commit/d0924f1a28
15:29 Zoffix Unless it's something with [Tux]'s box that made the measurements this morning slower
15:29 jnthn MasterDuke: Probably, though I thought we had various CATCH blocks in place that annotated errors like that with a source location
15:30 pmurias jnthn: what should Scalar.dynamic return when the scalar has no descriptor? It currently return Nil in this case but I think it should be either True or False
15:30 jnthn pmurias: False, I'd think
15:31 MasterDuke jnthn: fyi, this is in src/vm/moar/QAST/QASTOperationsMAST.nqp, what i commented out is `nqp::die("arg expression cannot be void")`
15:31 jnthn Well, the error is correct
15:32 pmurias ok. so I should explicitly set %?LANG as dynamic?
15:33 jnthn If you use nqp::ops that are void you should expect a code-gen error if you try to use them. It'd be good if it could give the nearest annotated source location, however.
15:33 Zoffix MasterDuke: FYI, it took me exactly 3 seconds to debug that error in my code
15:34 jnthn But I thought that we had a CATCH in stmts notes that would add location into and rethrow
15:34 Zoffix s/FYI/FWIW/
15:34 jnthn pmurias: Ah, 'cus EVAL needs to access it through the caller chain?
15:35 jnthn pmurias: Seems reasonable enough
15:35 MasterDuke Zoffix: yeah, i wasn't going to PR my change, but like jnthn said, getting the nearest annotated source location would be nice
15:36 pmurias jnthn: yes, EVAL needs that. Should other compile-time variables be marked as dynamic too?
15:37 jnthn I was wondering that, but don't have an immediate feeling for it :)
15:37 jnthn Probably not all though
15:37 Geth ¦ nqp/uncurse: bd4f38a416 | TimToady++ | src/QRegex/Cursor.nqp
15:37 Geth ¦ nqp/uncurse: PRECURSOR should not trim $!orig
15:37 Geth ¦ nqp/uncurse: review: https://github.com/perl6/nqp/commit/bd4f38a416
15:37 jnthn Because some are actually just transforms
15:39 MasterDuke jnthn: fwiw, this is the relevant ast https://gist.github.com/MasterDuke17/c360883b4065e29a1a508d69bc7faa72
15:44 TimToady this might or might not be relevant, but $?LANG is now supposed to be dynamically generated at the point of mention like $?LINE, but as far as I know EVAL doesn't use it quite yet
15:44 * TimToady goes to get another cuppa to see if his brane unfogs anysome
15:46 Zoffix :o It took me thiiis long to realize I can write L«C<Type>|/type/Type» in docs as just L<Type> :|
15:46 * TimToady didn't sleep so well last night, between having the snuffles and having the house full of butyl mercaptans all night
15:46 Zoffix I even bound L«C<>|/type/» to a key on my keyboard :(
15:46 TimToady courtesy of a skunk in the back yard that probably met a cat or a racoon
15:47 Zoffix ewww
15:47 * Zoffix remembers moving to US and smelling the first skunk roadkill.
15:47 TimToady progress report on uncurse, we're now down to blowing only 25 spectest .t files completely out of the water :)
15:47 Zoffix There were moments I thought I was going to die.
15:48 Zoffix Cool \o/
15:51 jnthn TimToady++
15:51 TimToady and it does seem slightly faster, but the big speedups will come later
15:51 TimToady the problem with our current cstack is that it's more optimized for backtracking than for forwardtracking
15:52 TimToady I think we can make parsing a lot faster by making backtracking a bit slower
15:52 TimToady well, hopefully without slowing down backtracking, but we'll see
15:53 TimToady but basically by assuming we will succeed rather than assuming we'll fail
15:53 jnthn Sounds interesting :)
15:53 TimToady and by putting things directly into where the match object can provide them
15:54 TimToady another potential speedup, once we get $<foo> to not go through the hash interface mandatorily, is to avoid capturing to hashes at all
15:55 TimToady for any given rule, the names we capture are statically known, so could just be a static mapping to fixed array locations
15:55 jnthn Indeed
15:55 jnthn I guess the challenge there is that we cheat like heck on hash/array access
15:55 TimToady a capturing match really only needs to know "put yourself into this array at this position if you match"
15:56 jnthn In NQP
15:56 jnthn We can stop doing that
15:56 TimToady and that array will be in the cursor/match object itself, not the cstack, so we never have to copy
15:57 TimToady yes, we can either implement AT-KEY, but that still is a string interface on each call
15:57 TimToady or we can do something maybe a little smarter at compile time, or on first use, or somethin'
15:57 TimToady AT-KEYish stuff might be sufficient with smart enough type spesh
15:58 TimToady but currently the $/<foo> interface is boxing us into a performance corner I don't like
15:58 jnthn Well, it was an optimization with the assumption we'd have a real array and real hash
15:58 TimToady I'm thinking AT-KEY is the slow path
15:59 TimToady and the compile can be smarter about literal $<foo>
15:59 jnthn That dates back to the Parrot days
15:59 TimToady sure, not complaining about how we go here :)
15:59 TimToady *got
15:59 jnthn And, to be fair, the early Moar days too when we had no inlining
15:59 TimToady just trying to see around the corners to where we'd like to be
15:59 jnthn Now it's mostly just more complexity in the VM :)
16:01 TimToady we don't internal hash keys yet the way P5 does, do we?
16:01 TimToady *intern
16:01 jnthn We intern strings inside a single compilation unit
16:02 jnthn And we have a fast path in hash string equality checks that first looks at the pointer
16:02 jnthn We don't yet do interning between compilation units
16:02 jnthn And don't do anything about non-literal strings
16:02 TimToady that doesn't help one mention of $<foo> vs another $<foo> which is presumably a different string "foo"
16:03 TimToady or does it?
16:03 timotimo if they are in the same file, i'd imagine they get the same "foo" object
16:03 timotimo when it lands in the string hash they'll be deduplicated
16:03 TimToady okay
16:03 jnthn Yeah, what timotimo said. We de-dupe at bytecode assembly time
16:04 jnthn I suspect that there'd be a bit of a win to be had if we de-duped cross-compilation unit
16:04 timotimo it'd be interesting to see if we can "just" take strings from another compunit when we load one from another's string heap, but then we'll need a hash again, and then thread-safety and urgh
16:04 jnthn Because then your grammar and actions, if in separate files, could also get the faster path
16:05 jnthn But of course you gotta then be mighty careful that you don't introduce a new memory leak for EVAL :)
16:05 timotimo hm, is our string heap sorted? i seem to remember it is
16:05 timotimo so we'd have the ability to use merging of pre-sorted lists here, or perhaps binary search.
16:05 TimToady anyway, that's all well and good, but I think we can do better by taking more advantage of the staticness of rule names directly, and basically have a string mapper to position for each rule
16:05 timotimo right
16:06 TimToady and mostly make that translation instantly at compile time
16:06 timotimo can't imagine right now what corners the data has to flow around there :)
16:06 TimToady anyhoo that's the direction I'm thinking once the uncurse branch settles down
16:06 timotimo sounds exciting
16:07 TimToady just not calling .CURSOR and .MATCH all over the place should help some too
16:07 jnthn It'll work well inside of rules
16:07 jnthn Action methods I guess will still have to do a hash lookup along the way
16:08 TimToady but hopefully not more than one lookup per call, anyway
16:08 TimToady and we can also look at gluing action routines more closely to rules at compile time or first use time
16:09 TimToady the double dispatch seems suboptimal
16:09 TimToady though we do have to do both dispatches at least once, since there's no 1-to-1 mapping necessarily
16:10 timotimo reminds me a little of how OpenGL did vertex and fragment shaders
16:10 timotimo you were forced to compile a new object for every combination of vertex and fragment shader
16:10 timotimo even though the interface between the two is kind of static
16:10 timotimo there's extensions for more freedom there, though
16:10 jnthn I've already got some plans to change how we call action methods
16:10 jnthn So we can better spesh 'em
16:10 jnthn And even inline the tiny ones
16:11 TimToady of course, if we really want to parse Perl 6 fast, we write a yacc grammar that parses "standard" P6 and just drops down into recursive descent when the language changes :)
16:11 timotimo that sounds nice
16:11 timotimo is that based on more code gen? like CompilationHelpers?
16:14 * timotimo grocery shopping
16:16 geekosaur joined #perl6-dev
16:17 TimToady one thing I noticed was that the action method actually seems to currently be in the dynamic scope of its corresponding rule, which is nice, but I hadn't expected
16:17 TimToady for instance, rule O sets %*SPEC, and action method O uses that, which wouldn't work if the action method were called at the same level as the rule
16:17 TimToady anyway, we probably need to preserve that
16:18 TimToady however we hook rules with actions
16:19 * TimToady turns his glare upon the 25 broken .t files...
16:20 Zoffix *files magically stop being broken*
16:21 jnthn TimToady: I'd figured it had to be that way :)
16:21 jnthn 'cus of the dynamic variable pattern you just mentioned :)
16:21 TimToady well, it fits with how we were thinking of action methods as equivalent to embedded {}
16:22 jnthn Aye
16:22 jnthn I don't think it's a perf issue to have it this way
16:22 TimToady so adding an action method to / foo | bar / is turning it into / [ foo | bar ] { your ac here } /
16:22 jnthn If anything, it's good if we fix our code-gen
16:22 jnthn Because we can emit the action callsite directly in the regex body
16:23 jnthn Meaning that it'll be speshable, inlinable, etc.
16:23 Zoffix Ah. There's no apparent memory improvement with my .slurp patch. When I run it on my VM with 24GB, the use is the same. I guess the diff I've seen was due to GCed stuff on my 4GB VM on homebox
16:23 Zoffix The speed is there tho :P
16:23 TimToady most of P5 trades *more* memory for more speed :)
16:24 TimToady so keeping it the same is kind of a win, or at least a non-lose :)
16:24 Zoffix hehe
16:24 TimToady me puts too many smileys on his messages :)
16:26 jnthn Me too :D
16:26 Zoffix :D :D :D
16:35 Zoffix Booo. My faster slurp crashed and burned in stresstesting. All is no lost however, I should still be able to reap the benefit. But will have to do it after work.
16:36 robertle joined #perl6-dev
16:42 jnthn Zoffix: Dammit. Turns out that on Windows, various things use .abspath to locate DLLs :(
16:42 jnthn So there's more module breakage there
16:42 Zoffix :(
16:43 Zoffix Module as in ecosystem module?
16:43 Zoffix All but three are fixed
16:43 Zoffix huggable: IO kills
16:43 huggable Zoffix, 15 x [✔]; 3 x [✘]: See https://gist.github.com/zoffixznet/0ea1f4db792fc674abdde73f8dd11cc1
16:43 jnthn Yeah
16:43 jnthn Oh, maybe something didn't version bump
16:44 Zoffix p6-native-libc is listed as unfixed. There's a PR for it tho: https://github.com/cygx/p6-native-libc/pull/3
16:44 Zoffix And other two are Crust and Net::FTP
16:45 jnthn Archive::LibArchive::Raw seems not updated
16:45 jnthn $ git grep abspath
16:45 jnthn lib/Archive/Libarchive/Raw.pm6:        ?? %?RESOURCES<libarchive.dll>.abspath
16:45 jnthn (that's after a git pull)
16:45 jnthn oh, hang on
16:45 jnthn haha
16:46 jnthn No, that's my local fork of it
16:46 Zoffix Is there a way to tell if a handle can't bee nqp::seekfh'ed other than a try?
16:47 jnthn Hm, it had been version bumped
16:47 jnthn OK, I dunno what I did...
16:47 jnthn But looks better now
16:48 jnthn Zoffix: In MoarVM I guess we know...
16:48 jnthn Oh, but maybe not even reliably then
16:48 jnthn Yeah, I think probably not
16:48 Zoffix Alright
16:48 jnthn I was thinking we could check if the handle type implemented the seekable thing
16:50 jnthn (But then realized that doesn't mean it will succeed)
16:50 Zoffix "/* Cannot seek a TTY of named pipe (could fake the forward case, probably). */"
16:51 Zoffix Is it a safe assumption in Rakudo that if I can forward-seek a handle, I can seek back to original position too?
16:52 Zoffix 'cause that's what my 16x improvement is doing. And if it ain't safe, then it's out of the window
16:52 Zoffix And it fails with $*IN, so Imma pop a `try .seek` on it and fallback to the slowpath
16:52 jnthn Heh, not if we do what that comment suggests...
16:52 jnthn What was your speedup?
16:52 timotimo oh
16:52 timotimo probably seek + tell + pre-size
16:53 jnthn aha
16:53 Zoffix jnthn: 16x
16:53 Zoffix And 2x for a "few bytes" file
16:53 jnthn No, I meant what did you do to acehive it :)
16:53 geekosaur also can't seek a socket
16:53 geekosaur or a normal pipe
16:54 Zoffix jnthn: the tell -> seek to end -> tell -> seek back; use the diff
16:54 Zoffix jnthn: https://gist.github.com/zoffixznet/310c12ca64d01e59e3f7d8bc3ff68787
16:54 timotimo geekosaur: yeah, i have trouble finding my socks, too
16:55 geekosaur also, is there a binding to fstat?
16:56 Zoffix And the code in Pipe.pm in that diff, will be moved back into Handle.pm and be executed when `try seek` fails.
16:56 jnthn Zoffix: Can we not just pass some integer max value to read?
16:57 jnthn And it'll read all it can and return to us?
16:57 jnthn That'd save the whole seek/tell thing
16:57 Zoffix jnthn: good plan.
16:58 Zoffix Gonna try that after work.
17:02 Zoffix Um... lol. There are 2 plumbers. One came in and said he'd be back, I told him to just come in. I'm sitting in my bedroom right now with the door closed and second plumber came in. And judging by the amount of swearing he's doing he thinks no one's home :)
17:02 Zoffix brb... gonna scare teh crap outta him :)
17:04 Zoffix heh
17:04 Zoffix Well. That was good 3 seconds of fun :)
17:05 timotimo :D
17:08 TimToady .oO(Mr Plumber, in the kitchen, with a lead pipe.)
17:12 Zoffix No idea what handle->body.ops->sync_readable->read_bytes(tc, handle, &buf, length); calls  (like where that ->read_bytes is at)
17:13 Zoffix But thinking: wouldn't passing a max int allocate a crapton of memory to read all of the stuff?
17:15 Zoffix Yup
17:15 Zoffix $ perl6 -e 'use nqp; dd nqp::readfh(nqp::getattr("rakudo/foo".IO.open(:bin), IO::Handle, q|$!PIO|), buf8.new, 2**63-1)'
17:15 Zoffix MoarVM panic: Memory allocation failed; could not allocate 18446744073709551615 bytes
17:17 Zoffix jnthn: I guess we could make it a bit larger than 0x100000 but probably not by much
17:17 Zoffix m: say 0x100000/1024
17:17 camelia rakudo-moar 064b58: OUTPUT: «1024␤»
17:17 Zoffix 1mb
17:19 Zoffix (context: we currently read in 0x100000 chunks, .appending to a buf each time)
17:20 Zoffix I guess I can knock it all on the head. If you want fast file slurp: use IO::Path.slurp, not IO::Handle.
17:20 * Zoffix chooses that option
17:49 bartolin Zoffix: I plan to open a ticket for newly failing IO related tests on JVM. I'd like to fudge those tests for now. (If I'm able to make them work, I'll do that instead.) If you have a better suggestion please let me know
17:58 Zoffix bartolin: other than leaving them as is and letting me take care of them on Monday, no suggestions.
18:04 bartolin Zoffix: ok, I'm going to fudge them. Maybe that makes things a bit easier for you, too.
18:04 Geth ¦ rakudo/nom: f1b4af7af4 | (Zoffix Znet)++ | src/core/IO/Handle.pm
18:04 Geth ¦ rakudo/nom: [io grant] Implement IO::Handle.slurp
18:04 Geth ¦ rakudo/nom:
18:04 Geth ¦ rakudo/nom: - Per IO plan, add .slurp as a replacement for .slurp-rest
18:04 Geth ¦ rakudo/nom:     - Will add a DEPRECATED to .slurp-rest when we cut 6.d, as
18:04 Geth ¦ rakudo/nom:         currently the compiler version for that is unknown
18:04 Geth ¦ rakudo/nom: - Leave .slurp-rest as is, but in new .slurp, toss :bin and :enc
18:04 Geth ¦ rakudo/nom:     params. Use the handle's $!encoding attr. This aligns the routine
18:04 Geth ¦ rakudo/nom: <…commit message has 8 more lines…>
18:04 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f1b4af7af4
18:08 Geth ¦ roast: 7e4a2ae34b | (Zoffix Znet)++ | 15 files
18:08 Geth ¦ roast: [io grant] Swap .slurp-rest to .slurp
18:08 Geth ¦ roast:
18:08 Geth ¦ roast: Rakudo impl: https://github.com/rakudo/rakudo/commit/f1b4af7af4
18:08 Geth ¦ roast:
18:08 Geth ¦ roast: Since current master is a to-be 6.d and .slurp-rest is to be deprecated
18:08 Geth ¦ roast: in 6.d, we piggy-back on existing tests, but just swapping to the new
18:08 Geth ¦ roast: method & changing 2 tests that use :bin mode without bin-modded handle
18:08 Geth ¦ roast:
18:08 Geth ¦ roast: The .slurp-rest() tests will still exist in 6.c-errata branch and will
18:08 Geth ¦ roast: work just fine with current and 6.d rakudo; issuing a deprecation
18:08 Geth ¦ roast: warning in 6.d;
18:08 Geth ¦ roast: review: https://github.com/perl6/roast/commit/7e4a2ae34b
18:10 Zoffix I figured that's OK ^ . Releases do 6.c-errata tests and once I have the bot running, it'll run them daily. So .slurp-rest is still tested as before if you consider all the branches of tests in combination.
18:16 Zoffix we still have .tree in Any
18:16 Zoffix m: <a b c>.tree.say
18:16 camelia rakudo-moar f1b4af: OUTPUT: «(a b c)␤»
18:17 Zoffix m: (<a b c>, <z b g>).tree.say
18:17 camelia rakudo-moar f1b4af: OUTPUT: «((a b c) (z b g))␤»
18:17 * Zoffix doesn't know what its point is
19:11 TimToady it's supposed to take mapping arguments for each level of the tree
19:12 Zoffix m: .signature.say for ().^lookup("tree").candidates
19:12 camelia rakudo-moar f1b4af: OUTPUT: «(Any:U $: *%_)␤(Any:D $: *%_)␤(Any:D $: Whatever, *%_)␤(Any:D $: Cool $count, *%_)␤(Any:D $: @ (&first, *@rest), *%_)␤(Any:D $: &first, *@rest, *%_)␤»
19:13 Zoffix m: say (<a b c>, <z b g>).tree: &uc
19:13 camelia rakudo-moar f1b4af: OUTPUT: «A B C Z B G␤»
19:14 Zoffix m: say (<a b c>, <z b g>).tree: {"[$_]"}
19:14 camelia rakudo-moar f1b4af: OUTPUT: «[a b c z b g]␤»
19:14 * Zoffix shrugs
19:14 TimToady it was only ever half implemented the way it was specced
19:14 Zoffix Ah
19:25 AlexDaniel joined #perl6-dev
20:01 Zoffix m: printf '%.3fe%d', $_/10**(.chars-1), .chars-1 with 123456789
20:01 camelia rakudo-moar f1b4af: OUTPUT: «1.235e8»
20:01 Zoffix m: printf '%.3fe%d', $_/10**(.chars-1), .chars-1 with [*] 1..361
20:01 camelia rakudo-moar f1b4af: OUTPUT: «1.438e768»
20:43 Zoffix FFS
20:43 Zoffix My plan to power through the IO stuff before release is being stymied by a couple of dirty strange men occupying area where I wanna take a shit.
20:44 Zoffix I'm actually working for my other job now--I'm not even supposed to. Can't think straight will all the banging
20:44 Zoffix ZofBot: HELP ME!
20:44 ZofBot Zoffix, pred
20:59 sasheto joined #perl6-dev
21:00 jnthn Hurrah, seems I've nailed the occasional data loss bug in IO::Socket::Async::SSL
21:01 jnthn That means it's pretty close to ready to ship off to the ecosystem
21:03 Zoffix Sweet
21:04 sasheto joined #perl6-dev
21:18 MasterDuke jnthn: i can't get any of the nqp::die() conditions in src/vm/moar/QAST/QASTOperationsMAST.nqp to give source location. e.g.,
21:18 MasterDuke m: use nqp; nqp::if_i("foo")
21:18 camelia rakudo-moar f1b4af: OUTPUT: «===SORRY!===␤No registered operation handler for 'if_i'␤»
21:18 MasterDuke m: use nqp; nqp::die("foo")
21:18 camelia rakudo-moar f1b4af: OUTPUT: «foo␤  in block <unit> at <tmp> line 1␤␤»
21:21 jnthn MasterDuke: Hmm, maybe there is no current handling for that, then
21:21 jnthn The most common one is no such operation handler, which is easy to grep for :)
21:22 jnthn And, to be fair, errors at this layer are pretty rare :)
21:23 MasterDuke true. but if it's easy to fix, seems like a good thing to do. i just don't know where the fix would go
21:33 [Coke] fff
21:43 MasterDuke jnthn, Zoffix: a lot of the nqp::die()s in src/vm/moar/QAST/QASTOperationsMAST.nqp could at least have some extra information added (e.g., the name of the void arg in the case Zoffix found), like how the `No registered operation handler for '<foo>'` one does
21:44 MasterDuke think it would be worth adding relevant info where possible?
21:45 Zoffix My opinion is: not if there's any sort of performance impact
21:46 MasterDuke in pretty much every case we're already dying, so i doubt an extra nqp::elems, or .op() would really matter
21:47 jnthn If we're dying anyway it's likely quite cheap
21:47 Zoffix Ah right.
21:47 Zoffix I mean if there's any perf impact for non-dying paths :)
21:48 MasterDuke but i wasn't planning on doing anything extensive, just there are a couple things like "can only have one foo", and i'd just add ", got '+@foo'"
21:48 Zoffix Though even with dying anyway: we have 87 CATCHes just in core alone; people catch deaths
21:49 Zoffix This is dying in nqp tho? Never mind me.
21:49 * Zoffix closes the chat window and focuses on stuff :)
21:51 MasterDuke it'll be a PR so (any|every)body can take a look, but i'm just anticipating minor changes
21:54 jnthn I'd in principle be fine with such a PR :)
22:11 Zoffix Interesting. My IO::Path.slurp is dying with "Failed to close filehandle: bad file descriptor" after N number of iterations, where the number of iterations varies with env vars I specify... Like bogus env vars, but just adding one changes at which iterations it throws that :S
22:12 Zoffix ZofBot: what sourcery is this
22:12 ZofBot Zoffix, it's still unpacking objects after 30 secs
22:12 timotimo interesting, can you strace that?
22:12 Zoffix I've no idea what that means... just run strace perl6 foo.p6?
22:12 timotimo yeah
22:12 timotimo thatg ives you a trace of all system calls
22:13 timotimo you ought to be able to see what file descriptor number it complains about by 1) when the error message from rakudo comes, and 2) when something is listed as = ESOMEERROR
22:13 Zoffix there's like a billion screenfuls of output
22:14 timotimo yup
22:14 timotimo mostly mmap and such
22:14 timotimo i know you can filter with -e, but you'll need a negative filter
22:16 Zoffix Descriptor 2? https://gist.github.com/zoffixznet/8423293fc7538ef06d67e751e0e32c79
22:19 timotimo no, tha tought to be stderr
22:19 timotimo where it outputs the error
22:19 Zoffix Here's the code: https://gist.github.com/zoffixznet/344a158837d5a1bd5d02b83e744675ce
22:19 timotimo close(-1)                               = -1 EBADF (Bad file descriptor)
22:19 timotimo it's trying to close fd -1, that's very wrong
22:21 Zoffix ugh --optimize=off gets rid of the bug :/
22:22 Zoffix Sad, 'cause it means it's likely not in my code :\
22:22 timotimo uh oh
22:22 timotimo it doesn't panic, so you should be able to --ll-exception perhaps?
22:23 Zoffix huh
22:23 Zoffix "at SETTING::src/core/IO/Handle.pm:878  (./CORE.setting.moarvm:DESTROY)"
22:24 timotimo now that's interesting
22:24 Zoffix Ah, I gotta unset the $!PIO in the handle, I'm guessing
22:24 timotimo perhaps it's already closed and closing it manually has reset or invalidated the fd?
22:24 timotimo and the DESTROY method is erroneously running?
22:24 Zoffix I see my mistake
22:25 timotimo good!
22:25 Zoffix Old code called $handle.close, but I'm doing nqp::closefh($PIO)
22:25 Zoffix Thanks :)
22:25 timotimo ah
22:25 timotimo sure thing
22:27 timotimo i'm really glad to be of help
22:27 pmurias joined #perl6-dev
22:59 Geth ¦ rakudo/nom: c13480c82a | (Zoffix Znet)++ | src/core/IO/Path.pm
22:59 Geth ¦ rakudo/nom: [io grant] IO::Path.slurp: make 12%-35% faster; propagate Failures
22:59 Geth ¦ rakudo/nom:
22:59 Geth ¦ rakudo/nom: - In fast path: use `try` so we catch throwage by nqp::open
22:59 Geth ¦ rakudo/nom:     - and if we threw there, the slowpath will return a Failure
22:59 Geth ¦ rakudo/nom: - The perf improvent is only for the slurp call itself, not the actual
22:59 Geth ¦ rakudo/nom:     reading, so stated measurements apply only tiny files
22:59 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c13480c82a
23:02 Zoffix *to slurps of tiny files
23:31 Zoffix Is there a full list of encodings MoarVM supports?
23:31 Zoffix Like, stuff you can give to open :enc<...>
23:32 Zoffix Is this it? https://github.com/MoarVM/MoarVM/blob/master/src/strings/ops.c#L1940-L1951
23:33 Zoffix Looks like it
23:35 timotimo we do have that "canonicalize_encoding" function or table or somesuch
23:35 Zoffix R::I.NORMALIZE_ENCODING
23:35 timotimo btw, if you find us a junior coder, they could try putting in all the iso-9999-blah encodings
23:35 timotimo into moarvm
23:35 timotimo there's a table for every one of those on the unicode 'site somewhere
23:35 Zoffix Cool
23:36 Zoffix Maybe I take a crack at it later on
23:36 timotimo just in the last month or maybe two it was discussed, but i don't remember who was involved in the conversation
23:36 timotimo i'm not even sure if it was in #moarvm or not
23:37 timotimo 8859 is the number i was looking for
23:38 timotimo http://www.unicode.org/Public/MAPPINGS/ISO8859/
23:38 timotimo http://irclog.perlgeek.de/perl6/2017-03-24#i_14318239 - and surrounding lines
23:39 Zoffix huggable: encoding
23:39 huggable Zoffix, nothing found
23:39 Zoffix huggable: encoding :is: Add more encodings to MoarVM: http://irclog.perlgeek.de/perl6/2017-03-24#i_14318239
23:39 huggable Zoffix, Added encoding as Add more encodings to MoarVM: http://irclog.perlgeek.de/perl6/2017-03-24#i_14318239
23:42 timotimo did you ever wonder what a timeline where EBCDIC won over ASCII would look like?
23:43 Zoffix Nope
23:43 timotimo OK!
23:43 Zoffix I don't even know what EBCDIC is about; it's one of those "before I was born" things
23:44 timotimo http://www.unicode.org/Public/MAPPINGS/VENDORS/IBM/IBM_conversions.html *cough*
23:44 timotimo http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/EBCDIC/ - on top of that
23:44 timotimo because of course there's codemaps on top of ecbdic
23:44 timotimo cp037_IBMUSCanada - don't you just love that
23:45 Zoffix heh, well, looking at one of those files, I see why it didn't win. The letter ranges are not contiguious
23:45 timotimo do i even wanna know what "WindowsBestFit" is all about %)
23:46 Zoffix :)
23:46 timotimo there's also a mapping for Atari ST and TT character maps
23:46 timotimo this code map interestingly contains the big integral that's made up of three code points (top, middle, bottom)
23:47 timotimo # This table contains the data the Unicode Consortium has on how
23:47 timotimo #       IBM PC memory-mapped video graphics map into Unicode.
23:48 timotimo for some reason all of this makes me a little bit giddy
23:48 Zoffix wow, it's 8PM already. Kinda feel bad for these plumbers, since I still hear them banging on pipes. Still no water :|
23:48 timotimo :(
23:51 Zoffix Also, TIP: if building manager posts notice that hot water will be off. Fill some jugs with water, because they might turn off all of it. I'm like a dumbass with half a kettle here all day.
23:57 timotimo i'll go to bed now
23:58 timotimo i hope your pipe situation gets better soon :(
23:58 Zoffix night

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