pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
[particle] thanks, zgold! wanna help? 00:01
zgold [particle]: How can I? 00:05
I'm having some issues compiling pugs atm
[particle] i'll give you a commit bit 00:06
then you can fix whatever you find broken
zgold That'd be cool
[particle] i need a username, and email addr. 00:07
zgold zgs, [email@hidden.address]
[particle] upenn++
zgold You have a connection?
[particle] many friends used to go there
zgold Great place :) 00:08
[particle] and i used to live just north of phili
Juerd_: diakopter: moritz_: ping
seems commitbit server is down :(
zgold Do you know if pugs gets unhappy with ghc 6.8.x? 00:09
mncharity re unhappy, it was. There was an effort to fix it. I'm not sure what it's current state is. 00:12
zgold Still broken
mncharity r19955 works on 6.6.2
re broken, :(
zgold Perhaps thats something i can do :) 00:13
mncharity :) :)
zgold hehe
[particle] well, if you don't get a commit bit in time (sorry for the delay) you can submit a patch to perl [email@hidden.address]
perl6-compiler@
zgold Don't expect miracles though... my brain is still fried from monad transformers hw 2 weeks ago
00:17 thoughtpolice joined
zgold Found a useful irc log from this channel about this sort of error and how to fix em, perhaps i can send in some commits :) 00:18
Juerd_ Patterner: pong 00:19
[particle]: What's the url for that?
mncharity Consider a 5kb p6 file with 700 lines of "2+3*4;". How long does it take to parse?
redsix... get's enormous and dies.
rakudo.exe --target=parse, 75 sec. 00:20
STD_red_run, 15 sec.
pugs...
...
3 seconds.
Juerd_ Hm
zgold a bug you have found
[particle] Juerd_: commitbit.pugscode.org 00:22
Botje zgold: pugs is broken on 6.8, but there's a patch 00:26
pugs_svnbot r20119 | putter++ | [STD_red] Accept input with trailing newline (as from a file). Quiet the OPP.
diff: dev.pugscode.org/changeset/20119
lambdabot Title: Changeset 20119 - Pugs - Trac
zgold Botje: do you know where I can get the patch?
Botje it's in the svn repo, actually 00:27
pugs_svnbot r20120 | putter++ | misc/winter_jig/elf_on_rakudo/elf_one.p6: Is now the generated p6 file, and ./elf_one will be the emitted p5 executable.
diff: dev.pugscode.org/changeset/20120
lambdabot Title: Changeset 20120 - Pugs - Trac
Botje see NOTES-pugs-ghc681.txt and pugs-ghc681.diff
zgold ohh okay... I was thinkign some funky feature of SVN i didn't know :) 00:28
Alright, i'll mess with this. Thanks Botje and [particle] !
Botje I got pugs to build using that 00:29
Juerd_ [particle]: It was hard coded to use /usr/local/bin/perl, which I removed because it caused LOTS of trouble
feather has one big problem: there's no communication between people with root access, and the little communication there is (me saying: don't do that) doesn't always work well. 00:30
[particle]: And apparently the other Perl installation used a newer Jifty 00:31
[particle]: And this one now won't use the database
VOLUNTEER NEEDED to install Perl 5.10, with a bunch of modules, on feather
But NOT in the path.
[particle] heh. sorry for the hassle, not my fault. 00:34
Juerd_ Certainly not your fault 00:35
[particle] TimToady installed 5.10 there
Juerd_ But I don't know whose it is
Ah
TimToady: Could you please re-install perl 5.10 on feather, but this time outside the regular paths? Many things depend on CPAN modules, and they're installed with debian packages, so not available for the custom perl 5.10. 00:36
TimToady: But apparently some things were already changed to depend on 5.10...
mncharity misc/winter_jig/elf_on_rakudo/elf_one.p6... 700 lines of class defs, 15kb. STD_red_run... not ready for it. redsix, 55 sec. rakudo, 40 sec. pugs, 10 sec (and finds the syntax error). 00:38
mncharity is slightly tempted to do a GLR bison grammar for boostrap p6, perhaps with p5 as the lexer. 00:43
re parser numbers, note the "2+3*4" file mainly just bangs on the OPP. so STD_red_run may have ok performance on the more typical elf_one.p6 (once it could parse it). And it wasn't possible to check yet_another_regex_engine, as a p6 grammar has never been tailored to it. 00:46
But the one minute rakudo parse time for elf_one.p6 is a real problem for elf_on_rakudo. :/ 00:49
700 lines of "use Foobar;". redsix... gets enormous and killed. rakudo.exe... segfaults. rakudo.pbc, 45 sec. pugs, 15 seconds (including insisting Foobar.pm exist, and hitting the filesystem 700 times). 00:57
sigh. and STD_red_run, the motivation for that last test, has regressed, and can't parse it. :/ 01:00
hmm, not regressed. just a bug. 01:02
700 lines of "$x;". redsix... really doesn't like these big file'o statements. rakudo.exe, 40 sec. STD_red_run, 3 sec. pugs... 1 sec. 01:12
01:13 lyokato_ joined
mncharity Ah, redsix has something nonlinear going on. 200 lines of "$x;", 40 sec. 100 lines, 6 sec. 50 lines, 2- sec. 01:22
01:32 araujo joined 01:41 baest joined 01:43 pmichaud joined, Caelum joined, diakopter joined 01:48 [particle1 joined 01:52 pjcj joined 01:56 araujo joined 01:59 nipotan joined
mncharity strawman concept: a "fast parser". p6 (static, perhaps somewhat restricted) -> yaml. p6-> p5 tokenizer -> one-token-per-line stream -> flex (minimal) -> bison (GLR; grammar derived from STD) -> yaml (dumped from actions?). 02:27
motivation: need a 100+ line/sec parser to be "usable". paths: Rakudo optimization (seems unlikely; have even worse problems the moment you bootstrap off of it). Redsix optimization (still leaves you with an unwanted ruby codebase, and questionable parsing). STD_red mutant (strongest alternative; but ruby again; "mutant" to be bison-like, attempting 02:32
to reduce "its a research project, not a grammar" aspect).
repeat: "mutant (strongest alternative; but ruby again; "mutant" to be bison-like, attempting"
pugs hybrid (still painful; pugs grammar getting old; no-one to fix problems). 02:34
runnable ruby with ruby-parsetree-to-p6 converter (ruby again). 02:36
02:36 peepsalot joined
mncharity ruby-anything doesn't seem viable, unless a ruby coder other than me expresses interest i 02:36
n working on it.
ruoso: pmurias: any interest in participating in a "fast parser". 02:37
?
yet_another_regex_engine p6 grammar (hypothesizing redsix-like speed (without the nonlinearity?); with a p5 codebase (crufty; fragile on 5.8; if restricted to 5.10, and cleaned up, then perhaps someone might care about it?); if worked, then the plan 02:41
to transliterate it into p6, and then compile back to p5, would produce a similarly working/usable parser).
what am i missing? 02:42
so big picture: bison .. usable p6 .. backend bootstrap .. yare transliteration into p6 .. parsable p6 grammar .. frontend bootstrap. or parsable p6 grammar (on current p5 yare) .. usable p6 .. backend bootstrap .. yare transliteration into p6 .. frontend boostrap. 02:44
or i suppose: option1 =~ s/ bison / try to live with and work around rakudo slowness / 02:46
with ruby support: hmm... STD_red .. usable p6 (p5 or rb backend?) .. backend bootstrap ...? or yare translated to rb (chance to clean it up) .. parsable p6 grammar .. frontend .. usable p6 .. bootstrap backend .. translate rb yare to p6 .. frontend bootstrap. 02:53
maze of twisty little passages. 02:54
PerlJam all different 02:55
mncharity but a primary issue is becoming that there is someone else who cares about it, will work on it an pursue development. both because I'm finding myself increasingly spending coding time on non-p6 work, where I actually get to work with others, and because end of March approaches, my default pumpkin deadline. 02:56
PerlJam we haven't even reached the ides of march yet! :) 02:57
mncharity all different, but all so painfully familiar. and rank. we've been living here, clawing away at the walls, for 3 years now.
well, 2.5.
PerlJam mncharity: how slow is rakudo for your purposes? Painfully so? 02:59
mncharity en.wikipedia.org/wiki/Ides_of_March www.infoplease.com/spot/ides1.html news.bbc.co.uk/1/hi/special_report/...296942.stm www.amurgsval.org/squishy/ides.html 03:01
lambdabot Title: Ides of March - Wikipedia, the free encyclopedia
wknight8111 and where does the slowness happen? Is it in the Rakudo grammar, or in the built-ins, or in parrot?
PerlJam has an affinity for rakudo btw :) 03:03
mncharity PerlJam: 40 sec to parse elf_one.p6. even if it were broken into pieces, that's just not a happy place to work.
wknight8111: re where, i've no idea. rakudo --target=parse blah.p6, but no idea what's happening under the covers. 03:04
PerlJam mncharity: so, I take that as "painfully slow". So, as wknight8111 says ... has anyone profiled it?
mncharity not I. 03:05
PerlJam Hmm. I supposed we only have parrot-level profiling still (i.e., no higher level profiling of parrot-subs or perl6-lines or perl6-subs)
s/ed/e/
mncharity my parrot fu is close to nonexistent at this point.
PerlJam I think higher level profiling options will become more important as rakudo approaches perl6. (or meybe they are already ueber important given rakudo is so slow) 03:06
mncharity re already ueber important, well, or not. it's only an issue now because I'm trying to actually use it to do software development in p6. which from a parrot-only perspective, isn't something one can/wants to do yet. 03:09
then again, pm suggested that parrot development "focus" is whatever the much needed volunteers are motivated to focus on. 03:11
PerlJam mncharity: if someone is doing software development in perl 6 using rakudo, then it's important because that's the goal we're striving for. And it helps to have someone using it in production to gauge how well we're doing. 03:12
mncharity point. though a less... "extreme" attempt at use, might provide generally more useful feedback. eg, in so far as the effort is reallocatable, it might be better spent on improving the grammar, rather than pushing to support not-small sized project which can be run anywhere else either yet. 03:18
PerlJam mncharity: perhaps.
mncharity sigh. "A not-small sized project which can'T be run anywhere else either yet." 03:19
PerlJam Though, extreme use might tell us where we need to focus too.
mncharity truth
spinclad
.oO( check it into the test suite! )
 03:22
a wonderful/horrible/terrible idea, i know
mncharity :) 03:23
PerlJam Does the test suite do timeouts? 03:24
not ok # 13 ... this test took more than 30 seconds to execute
That would be nice I think
mncharity re tests, we still really need a test suite overhaul, or a section with a different, less textual style. something to generate performance profiles would be a nice part of that. 03:25
re timeouts, traditionally, one just ulimit()s the shell from which one starts the tests. I don't know of anything built in. 03:26
or forgets to ulimit, and finds in the morning that the overnight test run got stuck early in the suite. :) 03:27
spinclad different tests want different timeouts, and calibrating them is a moving target and hardware dependent 03:28
mncharity it would be neat to have graphs of various implementations' performance vs calendar time. 03:29
spinclad times may be available in the smoke reports 03:30
(afk for the news) &
mncharity re different timeouts, yeah. the big regex tests are usually the longest running. so one approach to ulimit is to set it just beyond the regex's, or below them if you don't care that they get clipped. i've mostly just used ulimit as a way to catch the non-terminators, for which task the choice of timeout is less... err, more flexible. 03:31
re 'times may be available in the smoke reports', hmm, there's an interesting distraction. if one can find sets of reports from overlapping hardware. 03:33
spinclad (from my looks at the parrot test suite, non-terminators were often multithreading, and producing a result before a consumer was ready to listen...)
mncharity ah. redsix and pilrun non-terminators were often 'the thing which is supposed to terminate the loop isn't quite working yet, so doesn't'. don't recall what pugs non-terminators tended to look like. 03:34
PerlJam: a 'prove' modification? 1..3 \n timeout 30 bogogi \n :P 03:38
"bogomips" -> bogus Giga instructions, 1 bogogi ~= 1 sec on a 1 GHz cpu. 03:40
Juerd Ah, the bogomips. Something people used to boast about, when linux boxes were still slow enough that you could actually read the kernel output while it was booting itself. 03:41
mncharity lol :) 03:44
spinclad (i should say some non-terminators, and i haven't dug into them enough to be sure...) 03:46
mncharity i wonder how much of the rakudo grammar.pg yare could be easily coaxed to recognize. hmm. 03:51
ah well. end of day. good night all &
pugs_svnbot r20121 | duff++ | Update a couple of string autoinc, autodec tests to be in line with S03 04:19
diff: dev.pugscode.org/changeset/20121
lambdabot Title: Changeset 20121 - Pugs - Trac
04:36 justatheory joined 05:39 alc joined 06:18 devogon joined 06:20 kst``` joined, baest_ joined 06:23 eternaleye joined, simcop2387 joined, bockmabe joined, lisppaste3 joined, Lorn joined, drbean joined, stevan_ joined, kst`` joined, silug_ joined 06:26 mj41__ joined 06:30 mj41__ joined 06:31 pjcj joined, xinming joined, baest_ joined, xinming_ joined, mj41_ joined, baest joined 06:49 Aankhen`` joined 07:16 xinming_ joined, BinGOs_ joined 07:48 Alias_ joined 07:57 Helios_ joined 07:58 ycheng_ joined 07:59 audreyt_ joined 08:17 iblechbot joined 08:47 rindolf joined 08:59 [particle] joined 09:22 [particle1 joined 09:45 Helios joined 09:50 wknight-away joined, Helios_ joined 10:38 ruoso joined 10:44 baest joined 10:54 Willman joined 10:57 zamolxes joined 11:03 rindolf joined 11:12 penk joined 11:13 peepsalot joined 11:15 peepsalot joined 11:26 cognominal_ joined 11:31 mj41____ joined 11:35 devogon joined 11:36 gbarr joined 12:00 dada joined
dada pugsbot_r17185: say $?LINE; 12:01
12:02 iblechbot joined
dada pugsbot_r17185: are you an evalbot? 12:03
12:19 chris2 joined 13:06 marmic joined 13:46 rindolf joined 14:05 Zygo joined 14:22 wknight-away joined 14:53 pmurias joined 14:54 cookys joined 15:20 gbarr joined 15:21 rindolf joined
ruoso heh www.langorigami.com/art/mammals/bull_moose.jpg 15:32
15:46 marmic joined 15:56 FurnaceBoy joined 15:57 marmic joined 16:09 explorer joined 16:18 kst```` joined 16:33 justatheory joined 16:44 barney joined 16:56 japhb joined 16:59 zongfist joined 17:00 braceta joined 17:09 Zygo joined 17:15 ebassi joined 17:24 mncharity joined
mncharity remember yesterday's parser timings? well, one p6 implementation was missing (well, actually a couple, but). kp6. 17:32
kp6: 700 "2+3*4", 4 sec. "use Foobar;", 3 sec. "$x;", 2 sec.
spinclad not at all bad. very useable. 17:35
17:35 pbuetow joined 17:39 pmurias joined
pmurias mncharity: kp6 is faster than rakudo? 17:40
parsing i mean
mncharity pmurias: dramatically so. 17:41
pmurias that's really bad 17:42
mncharity possible causes include kp6 being ratchet-only(?), vs PGE backtracking, and the parrot grammar being bigger, and thus providing an opportunity to backtrack.
ruoso seriously?
mncharity given the redsix experience, another possibility is something nonlinear in parrot. haven't checked. 17:43
ruoso I didn't have that impression on parsing sm0p grammar
rakudo parses incredibly faster
mncharity curious. which file? 17:44
ruoso smop/sm0p/RakudoGrammar.pm
vs
smop/sm0p/KP6sm0p.p6
pmurias you used --perl5rx? 17:45
ruoso hmmm... nopes...
pmurias Token does *loads* as it turns rules into p6 code and then parses them 17:46
mncharity rakudo.exe --target=parse, on "$x;", a slight nonlinearity. 700: 36s. 350: 13s. 100: 3s. 17:49
ruoso: ah, not the same file? 17:50
pmurias mncharity: do you think emitting to c is required for a fast rules engine?
mncharity no
well, I suppose it depends on the meaning of "fast".
for p5 level fast, either bummed C, or very wizzy haskell. 17:51
ruoso mncharity, but they are very similar files...
mncharity for "it isn't getting in our way", redsix (and I suppose yare) suggest one can be fast enough without C.
ruoso mncharity, the thing is, you're probably comparing with too simple files
mncharity, try with a more complex one... 17:52
pmurias ruoso: kp6 has a high startup cost
mncharity the elf_one.p6 is less simple. hmm, didn't try kp6 on it. might work, checking...
pmurias so the slowness bites more on slow ones
mncharity kp6 -Cast-yaml on elf_one.p6 is 6 sec. 17:53
misc/winter_jig/elf_on_rakudo/elf_one.p6 17:54
pmurias parsing of KP6sm0p.pl takes 10sec 17:56
mncharity by?
pmurias kp6
mncharity rakudo.exe --target=parse elf_one.p6 is 40 s. 17:57
trying kp6 -Cast-yaml on smop/sm0p/KP6sm0p.p6 ...
pmurias mncharity: use --profile
mncharity cat ../../v6/smop/sm0p/KP6sm0p.p6 | time ./script/kp6 -Cast-yaml > deleteme; 2 sec (user) 17:59
parsefail on rakudo. 18:00
pmurias mncharity: you have a better machine ;) 18:01
mncharity re --profile, ooo, nifty. :)
hmm. re better machine, that's curious. An old x86_64 Athlon. That being 5x up from anything... laptop? With CPU throttling? 18:03
pmurias uname -a 18:05
Linux localhost 2.6.14-gentoo-r5 #8 PREEMPT Wed Apr 25 19:43:40 CEST 2007 i686 Intel(R) Celeron(R) CPU 2.20GHz GenuineIntel GNU/Linux
mncharity curious. my uname -a is much less informative. ... fc8 #1 SMP ... x86_64 ... . 18:06
pmurias emitting c shouldn't be that hard
mncharity re C, um, I'm missing the objective. it looks like the kp6 parser is quite wizzy enough. questions are why the rest of it isn't, and why ruoso is seeing rakudo as faster. applying sweat and C to the part which is already fast enough... 18:08
pmurias mncharity: the rest is even faster 18:09
the times with --profile don't seem to sum up to the total 18:10
ruoso mncharity, maybe I was thinking the slowness is in the parser and it isn't... 18:11
mncharity I see time ../sixen/sixcmd rakudo.exe --target=parse ../../../v6/smop/sm0p/RakudoGrammar.pm > deleteme as 2 sec.
kp6 parsefails on it.
ruoso ok... so it basically takes the same time 18:12
as the both grammars are similar
mncharity re "the rest is even faster", of kp6?
ruoso so, the slowness of kp6 is really in the runtime after all 18:13
mncharity re same time, yes, looks like.
ruoso pmurias, did you give up on the kp6-mp6-mp6 idea?
mncharity ruoso: well, might be the emitter. trying --profile (to p5) on elf_one.p6... 18:14
re "kp6-mp6-mp6", say that 5 times fast. :)
ruoso heh 18:15
pmurias perltidy is that slow
ruoso: lack of time 18:17
pugs_svnbot r20122 | pmurias++ | [kp6] --profile mentions perltidy
diff: dev.pugscode.org/changeset/20122
lambdabot Title: Changeset 20122 - Pugs - Trac
pmurias ruoso: and thought the parser was really slow 18:18
mncharity kp6 --profile elf_one.p6 goes boom. DISPATCH: calling HOW on invalid object:$VAR1 = undef; 18:19
but that's trying to run it. let's see, what arguments *should* I be giving kp6... 18:20
pmurias ruoso: --noperltidy is also a huge speedup 18:22
mncharity trying...
ruoso hmm... 18:24
pmurias not with -Cast-yaml of course
mncharity cat ../../misc/winter_jig/elf_on_rakudo/elf_one.p6 | time ./script/kp6 --noperltidy --profile -Cperl5 > deleteme; I'm seeing 7 sec, vs 5 for -Cast-yaml. I didn't see an impact from --noperltidy - curious.
pugs_svnbot r20123 | pmurias++ | [kp6] --profile prints the total amount of time categorised 18:26
diff: dev.pugscode.org/changeset/20123
lambdabot Title: Changeset 20123 - Pugs - Trac 18:27
pmurias &
mncharity maybe perltidy is currently disabled by default? the plain -Cperl5 output looks non-tidy.
pmurias: what is the state of your "fast runtime for kp6" effort? how far did you get? 18:28
ruoso: so yes, it looks like the runtime is the bear.
pmurias some parts of kp6 compiled to correct code
ruoso that gets me back to smop 18:29
which is my attempt of having a faster runtime
mncharity ruoso: a no-p6-frills direct to p5 is probably a lower hanging fruit for that. :) 18:30
pmurias mncharity: and t/mp6 run
mncharity /me goes to find pmurias's files, see what the backend design is...
ruoso mncharity, except that kp6 already implements semantics that I don't think can be mapped to p5
like lazy-autovivification 18:31
mncharity re mapping semantics, like? binding?
/me no care about lazy.
pmurias src/KindaPerl6/Visitor/Emit/MiniPerl6Like.pm 18:32
ruoso mncharity, then you can probably just take mp6 and extend it
it's probably easier
mp6 doesn't implement any semantic, it just uses p5
mp6 is like nqp
mncharity p5 semantics with p6 syntax and "not much slower than p5 to run" and "not dreadfully slow to compile" would make me happy.
ruoso the only reason to kp6 to exist is that it's impossible to bootstrap real Perl 6 from mp6, because of the lack of semantics 18:33
mncharity I suggest getting semantics right should follow, not preceed, having a usable bootstrap. especially if getting semantics right means unusable performance, as it seems likely to without wizzy compilation or a ruby backend. 18:38
ruoso mncharity, that was achieved by mp6
mncharity, mp6 bootstrapped with the simplified semantics 18:39
you can just start to work on a second version of the mp6 grammar
and keep mp6 runtime
but you should know that you won't get too far with that... 18:40
the semantics will beat you sooner than you expect
mncharity writing a runtime with simplified semantics is not difficult. with ruby, even not so simplified isn't very difficult. the challenge is the parse, and to a lesser extent, the ast. 18:41
pmurias hooking an OPP into mp6 should be easy
mncharity "not difficult" as in "takes a day, maybe two". 18:42
lol 18:43
18:43 pbuetow joined
pmurias mncharity: what are you laughing at ? ;) 18:44
mncharity re "hooking an OPP into mp6 should be easy", err, not in my experience. unless you happen to have a working one? I have one embedded in rakudo, an overkill one embedded in redsix, and non-working STD5 and STD_red ones in p6,p5, and ruby. 18:45
pmurias mncharity: as a matter of fact i do have one ;)
mncharity ! :)
pmurias: do tell 18:46
ruoso: re 'but you should know that you won't get too far with that...', what obstacles to you forsee? 18:47
pmurias mncharity: i'll finish the refactoring and commit it soon
mncharity :)
18:48 justatheory joined
ruoso mncharity, context in Perl 6 is much more complex than in Perl 5... 18:49
and it won't look like Perl 6 sometimes because of that
mncharity ok, let's see... reality check... 18:50
18:51 meppl joined
pmurias mncharity: commiting the non-refactored-to-oo version 18:51
pugs_svnbot r20124 | pmurias++ | and quick & dirty version of an Operator Precendence Parser
diff: dev.pugscode.org/changeset/20124
lambdabot Title: Changeset 20124 - Pugs - Trac
pmurias as i don't trust file-version-number.pl "source control" schemes much 18:52
mncharity my impression is the project bottleneck is lack of warm bodies. making the key question, "what will attract warm bodies?".
are our existing tools inherently unattractive? is it advertising? is it...?
I, myself, find our existing tools inherently unattractive. From which I make the perhaps too large leap to fixing the tools is necessary and sufficient to get bodies. 18:53
pugs one can't create non-small systems on, such as a prelude or a regex ast and emitter. one get's bogged down attempting to work around pugsbugs, and then fails. 18:54
as also happened with STD on pugs. 18:55
pmurias i agree tools that the tools are either horribly slow or extremly ugly
mncharity kp6 is annoying it its restricted dialect, but then deadly in it's slow speed.
redsix has been dependent on bleading edge ruby, no one cares about it, and it never got shaken down to the point of real oo working. 18:57
[particle1 heads out of town, and does not have screen set up &
18:57 Psyche^ joined
mncharity [particle1]: cherio 18:57
I've never tried to use mp6, as distinct from kp6. 18:58
looking at OPP... err, wait, so... 18:59
my impression is attempts to get real p6 semantics on a p5 backend bogged down in assorted p5 and cpan package bugs. 19:00
pmurias mp6 just sacrifices all the correctness and emitts raw perl6 19:01
perl5
mncharity I find writing non-small systems in p5 painful. And so find peoples disinterest in writing a p6 implementation directly in p5 unsurprising. But... perhaps that needs a closer look. 19:02
so it would seem an attractive p6 implementation would need properties of
pmurias mncharity: re OPP what did you mean to say? 19:03
mncharity "compile isn't so slow as to be unattractive", "runtime performance isnt so slow as to be unattractive"; language isn't something other than p6 (or p6-like); "dialect of p6 isn't so restricted as to be unattractive"; ...pause... 19:04
re OPP, I wan't to look at it, but realized I should finish this tread first. :) 19:05
...unpause... and a speculative "semantics aren't so un-p6-like so as to be unattractive".
pmurias that's it 19:06
mncharity re language, that's both the 'implementation of p6' language, and the language folks would use with it. I'm after bootstrap not for prettiness or dogfood, but because it seems the only language which will actually attract people to work on it.
re semantics, I'm hypothesizing p5 semantics would be "good enough", both practially good enough to do the bootstrap, and attractively good enough to get people to work on it. 19:08
ruoso: so re contect, I'd be happy with restrictions like "everything behaves like a scalar", "no multiple return values", etc. 19:10
pmurias what i think is also important is the ability to use libraries of some sort (either cpan or something else) 19:11
ruoso mncharity, well... so you just need to take mp6 and start extending its grammar/emitter
mncharity re libraries, any in particular in mind? or needed for attractiveness? 19:12
ruoso home & 19:13
mncharity ruoso: re 'take mp6 and start extending its grammar/emitter', could be. but if
ruoso but if?
mncharity the parser is indeed the hard part, then the question is whether it's easier to mutate the mp6 parser/ast, or to build on some other parser. 19:14
ruoso you don't need to mutate the mp6 parser (i think)...
you just need to extend its grammar
and emitter
the engine just works.. I think...
mncharity err, ok. I was using "parser" as "grammar+". though the engine is another source of concern. 19:15
ruoso yeah... you won't be able to parse STD with mp6 engine... 19:16
but you can go further than mp6 grammar is today...
mncharity I was kind of surprised when you wrote a grammar comparable in size to kp6's p6 grammar, and expected it to work in kp6. my impression is the engine development has been a "just in time - kp6 now needs feature X" approach. 19:17
ruoso but I think it's probably a good idea to consider it a separated project than mp6 itself, as to avoid breaking kp6
you're confusing the engine with the grammar
mncharity re breaking, oh yeah. any of these kp6 or mp6 based things would be a code fork.
re 'you're confusing the engine with the grammar', how so? 19:18
ruoso the mp6 engine is a different thing than its grammar
its features are not exactly related to what it can parse
what its grammar can parse, actually
there are things you can do in the grammar but that are not there yet... 19:19
and there are things you can't do, because the engine won't support
like multi token
mp6 engine simply doesn't support that
mncharity I'm still unclear on why you object to the observation that 19:20
ruoso because I don't really know how far you can go with mp6 engine... 19:21
mncharity mp6/kp6 engine development is, rather than being driven by test suites, was driven by "feature X now needs to exist and work because mp6/kp6 needs it". and so one should be unsurprised to find any feature not currently needed by mp6/kp6, to be unimplemented or buggy. as a rule of thumb. maybe.
ruoso even if you can parse a grammar, it doesn't mean that the grammar will run correctly
yes... it's test-driven...
but there are architectural issues... 19:22
in mp6 engine...
and that was one of the reasons fglock started kp6
but I don't know precisely which problems are that
but... home & 19:23
ruoso will backlog, as usual...
mncharity ok, later. :)
re tests, I've major problems with the hand generated tailored tests approach. basically, if it's not running against the p5 re_tests, and/or the p6 equivalent, then there doesn't seem any reason to believe it's working. on the "if it isn't tested, then it doesn't work" basis. 19:24
pmurias mncharity: re opp shaking a bug out 19:25
mncharity ruoso: re "the only reason to kp6 to exist is that it's impossible to bootstrap real Perl 6 from mp6, because of the lack of semantics", "but there are architectural issues... in mp6 engine... and that was one of the reasons fglock started kp6", any other thoughts on mp6? 19:27
19:28 cmarcelo joined
mncharity I just have the one-liner mental model of "anything mp6 can do, kp6 can do better" and "too crufty to worry about". 19:28
soo, if anyone, anyone at all, has any thoughts, any at all, on the "why I think an attractive implementation is needed" or "what an attractive implementation needs", please, please, say something. Getting the needs analysis wrong, that is, getting things wrong at the very start, is the best 19:30
guarantee of a failed project.
let's see, oop...
dev.pugscode.org/browser/misc/pX/Co...opp/opp.pl 19:31
lambdabot Title: /misc/pX/Common/opp/opp.pl - Pugs - Trac
pmurias mncharity: wait
pugs_svnbot r20125 | pmurias++ | a refactored version which only works for the first expression 19:33
diff: dev.pugscode.org/changeset/20125
lambdabot Title: Changeset 20125 - Pugs - Trac
pmurias mncharity: refactored and fixed the bug - you can know safely go on with the reading ;) 19:34
pugs_svnbot r20126 | pmurias++ | fixed bug
diff: dev.pugscode.org/changeset/20126
lambdabot Title: Changeset 20126 - Pugs - Trac
19:36 meppl joined
mncharity (sorry, calls) 19:39
19:46 rdice joined
mncharity oky 19:52
an issue is the "pseudo-code of the algorithm taken from en.wikipedia.org/wiki/Operator-prec...e_parser". p6 is a bit different. 19:53
let's see, my very fuzzy year+ old recollection is the closest match in the literature was the "sugar"(?) opp? let's see...
sooo should have put it in READTOO... 19:57
spinclad re p5 semantics: for OO semantics, i would C<use Moose;> AMAP; it seems to reflect p6 in that a closed class compiles to quickness, an open one stays slow... it uses a similar MOP as nuffin proposed, and is in fact a port of it to p5... (more) 19:58
one should be able to target it well, from my shallow examination
but context semantics is different issue entirely
19:59 gbarr joined
spinclad (context/aliasing/containers) which is my vague impression of the other difference (besides oo) driving kp6 to fork from mp6 20:00
which _combined_ with open, irreducible classes, means layers and layers of KP6_DISPATCH left for runtime 20:02
purl, AMAP is as much as possible 20:03
#ENOPURL
mncharity I'm losing. I'm fairly sure it was mentioned on irc. perhaps around the time of misc/pX/tewk, so 2006-02. 20:05
spinclad which, the MOP? 20:06
mncharity bottom line, the p6 opp, though rather simplified over the last two years, is still more involved than a simple opp, or even say a prolog opp.
spinclad nm, crossing threads... 20:07
mncharity spinclad: re which, sorry, no - I'm just surfacing from a "search for old OPP literature".
spinclad right, got that finally
mncharity pmurias: the closest thing we currently have to an opp-for-p6 spec is in src/perl6/STD.pm. but while it works somewhat, it's not quite finished. setting aside the @fate and DFA one pass concept, which is even more a work in progress. 20:09
s/rather simplified/very much simplified/ :)
*vastly
pmurias: so I guess it depends on the objective. for a "just get it working, as for bootstrap", dropping in a simple opp could be sufficient. hmm, there's an interesting thought. add a simple-but-working opp to STD_red or yare to get EXPR working. 20:12
spinclad and a simple tokenizer, pending longest-token project, maybe 20:13
(tho that's not a current blocker)
(for the existing impls and their simplified dialects) 20:14
mncharity the one or two year ago attempt to take yet_another_regex_engine, add a p6 grammar, and thus get a parser hung in part on 'what would the p6 opp look like'. was still thinking about trying to do things right back then, rather than "just do anything that gets us an active development community again".
/me backlogs 20:15
re Moose, I like moose just because it let's you dump "has" decls inline, and not have to compile them into something more bare p5-ish. :) 20:20
elf_zero is using Moose for just that reason. With the potential for a Moose performance hit(?), given that an rx_on_re p6 version of yare would likely be an early use, i've been thinking of it a "something which simplifies life now, but may go away", rather than as "this let's us do lots of p6 semantics on p5". For the latter, I'd rather be building on a ruby 1.9 backend. 20:23
spinclad for an implementation dialect, i wouldn't be averse a few parentheses to simplify precedence levels
mncharity indeed
spinclad s/averse/& to/
s/let's/lets/ # plz forgive nitpick 20:25
mncharity svn.pugscode.org/pugs/v6/v6-KindaPe...rl6Like.pm
lambdabot tinyurl.com/2wsb9t
mncharity pmurias: in svn.pugscode.org/pugs/src/perl6/STD.pm , the OPP is EXPR... plus anywhere you see <prec> and such being passed around. :/ 20:29
including through environment variables. 20:31
sigh
20:31 peeps[work] joined
mncharity it's almost(?) an emergent property of the grammar, rather than a well defined component. 20:32
ok, thinking of it that way is just depressing. 20:33
the redsix opp took the approach of breaking multi-part tokens (eg, circumfix) into "lexemes", and then loading them with potential opinions on where they could match (eg, on what nearby whitespace could be, or what types of lexeme could follow), and then supported backtracking too. 20:35
just because it wasn't clear which way the opp/parser story would evolve. 20:36
I don't know if a sufficiently bulky but contained OPP implementation could do what is currently emergent in STD. Especially not with the DFA-ness stuff. 20:37
sigh. back to trying to get unstuck. need a fast parser. kp6 is fast. so... perhaps explore a kp6 fork. perhaps a more manageable metaprogrammed single-file one. 20:40
stevan_ mncharity: honestly, the Moose performance hit (after making classes immutable) is likely less then the same ruby 20:47
mncharity: the latest Moose is pretty much "fast enough" for most everything, I get very few complaints 20:51
except from peple who want to use it under Vanilla CGI, which is soooooooo 1997 anyway ;P 20:52
jrockway (the set of people that use CGI) and (the set of people that know what Moose is) don't intersect 20:53
stevan_ except for mkanat, who wants Moose for Bugzilla and which needs to run under VanCGI
jrockway MX::Compile, I guess 20:55
stevan_ thats the whole reason that MX::COmpile was started 20:58
21:01 kyrbe joined 21:02 kyrbe left
pmurias mncharity: why a single-file one? 21:04
mncharity stevan_: re Vanilla CGI, lol :) 21:15
re immutable "fast enough", hmm, interesting. 21:16
re "single-file one",
21:18 Jamtech joined
mncharity I guess the key is that at least at the moment, p6 compilers aren't very modular. parser grammar decisions propagate into ast and ir and thus into any compilation and into emitters, and thus into runtimes. 21:19
pmurias shower&
mncharity any time one wants to do something differently, it's likely everything down stream will be affected.
k
a problem both pugs and mp6/kp6 had is "there's only one version", and thus you're always in maintenance mode - all changes have to be carefully propagated, or things bit rot. 21:21
with redsix and yare, everything is in a single file. you copy the file, and you have an internally consistent fork with no external sources of breakage. 21:22
elf_on_rakudo wasn't there yet, with rakudo grammar changes an unavoidable source of bitrot, and elf_zero with a bunch of crufty external config files, but the hope was to move it towards being more contained. 21:23
if we had a working standard, eg, for a STD parse tree, or for an AST, or IR, we could do an abstraction wall there. but everything is broken, thus evolving, so it's not clear breaking it into pieces helps you much. 21:25
stevan_ mncharity: what exactly are you looking to use Moose for? 21:26
mncharity the p5 runtime for a "usable" p6 compiler. "p6 syntax with bare p5 semantics - no expensive chasing after p6 semantics". 21:28
fast, a place one can happily work to do a bootstrap. providing a real-ish, bootstrapped p6. which will hopefully attract more developer attention than the haskell/p5/ruby alternatives are currently managing. 21:30
stevan_ gotcha
I suspect Moose will be fast enough then
certain features can be avoided to make it faster too 21:31
like the type constraints
and type coercion
pmurias doesn't Moose offer mostly syntax sugar and metaprogramming?
stevan_ pmurias: its got a full MOP underneath through Class::MOP 21:32
the type constraint system has gotten pretty nice too
we have parameterized types and type unions
pmurias i meant the MOP by metaprogramming
stevan_ well they are not the same thing
you can metaprogram with a MOP 21:33
but it is not required
mncharity re avoiding features, ok. the only things I was so far thinking of using were has() and autoboxing. recognizing that the latter would be a performance it, but would make things so much simpler.
stevan_ actually the autoboxing is not *that* bad
but thats not core Moose 21:34
its Moose::AUtobox
mncharity implications of non-coreness?
stevan_ nothing
mncharity ok :)
stevan_ Moose is built to be extremely extensible
all the sub protocols (attribute, method, instance) can be extended individually 21:35
pmurias: we also offer the only correct roles implementation in existence
the parrot one is still kinda broken
mncharity anyone tried to write a p6 implementation on moose? :)
stevan_ and all the other p5 ones are hopelessly broken
mncharity: nope, most people just use Moose instead :) 21:36
close enough, and all that
mncharity right. sigh
pmurias an understatment is a good way of getting a feature list ;)
stevan_ mncharity: see Devel::Declare and Devel::BeginLift too
pmurias: :) 21:37
pmurias: I could go on if you want too, I am just throwing out some highlights
pmurias highlights++ 21:38
mncharity re search.cpan.org/~mstrout/Devel-Decl...Declare.pm SYNOPSIS "Look at the tests.". sigh. no doubt useful for expectation management, but... sigh 21:39
lambdabot Title: Devel::Declare - - search.cpan.org, tinyurl.com/2gk6zd
jrockway what's wrong with looking at the tests?
would you prefer that he just cut-n-pasted them into the POD?
stevan_ mncharity: basically D::D is a lexer hack to enable custom syntax 21:40
I am trying to get mst (the author) to follow along the lines of MetaLua for syntax extensions
21:40 dareonion joined
jrockway Method::Signatures is a module that uses Devel::Declare 21:41
stevan_ mncharity: and Devel::BeginLift just lifts subs into the BEGIN phase
jrockway lets you write method foo ($arg1, $arg2) { $self->whatever } instead of sub foo { my ($self, $arg1, $arg2) = @_; ... }
pmurias jrockway: great 21:42
jrockway not that great, still flaky and causes segfaults :)
and the lexer hack needs a ; after the declaration
method {}; instead of sub {}
it's ugly.
mncharity jrockway: re "what's wrong with looking at the tests?", deriving "basically D::D is a lexer hack to enable custom syntax" from 'looking at the tests' is non-trivial, often unlikely to happen, etc.
search.cpan.org/~mstrout/Devel-Begi...ginLift.pm 21:43
lambdabot Title: Devel::BeginLift - make selected sub calls evaluate at compile time - search.cpa ..., tinyurl.com/2ey34n
jrockway well, it's aimed at library writers, not "joe average perl hacker"
keeps support costs down for mst ;)
anyway, my article explains it better than the docs IMHO :) blog.jrock.us/articles/Devel::BeginLift.pod 21:44
lambdabot Title: Devel::BeginLift
pmurias jrockway: mp6 requires a ; too 21:45
mncharity my impression is the "use hairy perlguts p5 cpan modules as a p6 runtime" got stuck on various bugs in perlguts and the assorted modules. does that match your understanding? is there a list anywhere of what's working/not? 21:48
s/is/was long ago/ ;) 21:51
pmurias: re single file, basically to simplify/clarify what exactly a version/fork of X is, and how to modify, run, fork, and bootstrap it. 21:53
and help contain bitrot, and make it easy to capture and keep old versions (for workingness and bitrot avoidance). 21:55
basically our versioning systems don't have things like "put the set of files named frob-with-dead-code-removed-and-api-diddle-13 down over there, and call it frob2". you have to go up to the repo level to get it. 22:01
22:01 IllvilJa joined
mncharity jrockway: any thoughts on 'impression is the "use hairy perlguts p5 cpan modules as a p6 runtime" got stuck on various bugs in perlguts and the assorted modules.'? 22:02
stevan_: ?
stevan_ sorry, phone call
mncharity at one time, that was the "official p6 bootstrap story", slides and all. 22:03
np
stevan_ yeah p5 guts is hairy
22:03 milanj joined
stevan_ there is no way we can implement all of p6 on top of p5 without basically adding an interpreter 22:03
mst's work with Devel::{Declare, BeginLift} is still in the "oh interesting" phase, and not in the "yeah I will use this for real" phase 22:04
jrockway the p5 guts are my least favorite part of perl 22:06
i am attracted to langauges that have much worse syntax because of clean implementations and fast runtime
i don't really *need* the speed, but it feels nice :)
mncharity :) 22:07
jrockway so really, the most important feature of perl6 is a rewritten implementation
oh yeah, and i was upset to find that 5.10's given doesn't work the same as perl6's :)
given($foo){ s/.../.../ } # no change
mncharity ah 22:08
jrockway my $value = given($foo){ do stuff with $_; $_ } # error
mncharity :(
jrockway there are other p5 features that i would like, of course :) 22:09
sub foo($&) { ... } ... foo 'bar' { baz }
mncharity so are there particular hairy extension modules that are notably working or not working? or being blocked on or otherwise awaited? 22:10
stevan_ not really 22:11
not that I know of
jrockway there is lots of stuff on CPAN that's hairy :) 22:12
mncharity re foo($&), yeah, have to go to macros for that in p6. though the redsix opp was hypothetically capable of doing smalltalkish carry $basement to $attic now carry_to_now multifix
so the p6 as p5+cpan approach isn't being pursued is... 22:13
?
is because...
stevan_ not really
people are waiting for the real Perl 6 22:14
jrockway or at least a "finished" parrot
stevan_ and most of the p5+cpan folks have decided that we have (with 5.10, Moose, etc) have close enough to p6
jrockway i want to work on perl6, but not in the context of the parrot bureaucracy 22:15
also, working on perl5 things meets my immediate needs :)
mncharity so () p6 as p5+cpan is stalled. this because potential p5+cpan developers () found 5.10+Moose+etc was close enough to meet their immediate needs, and () they are waiting for (someone else to do) the "real" Perl 6 (on parrot?). 22:19
a fair summary?
22:19 LazyJim joined
stevan_ mncharity: all 'cept the last part 22:20
p6 on parrott will be nice
mncharity :), which last part? 22:21
stevan_ but its an untested VM using some funky (not well tested) concepts (register based not stack based)
and a new language
jrockway yeah, register-based machines don't work
stevan_ with some craxy stuff in it
jrockway pushes a value onto his eax :P
stevan_ I will be using perl 6 on christmas + 1 year
jrockway i wish they consulted you for the object system though 22:22
stevan_ and even then not likely in prod
jrockway it depends on how good the initial 1.0 feels
if it randomly crashes, then i would not be comfortable about using it for important things for a while
if it seems solid, though, it could be less than 1 year
IMO
stevan_ yeah true
22:23 LazyJim joined
stevan_ and that is by no means a slight on the p6 team, they are all execllent developers 22:23
jrockway i am also dreading rewriting everything in perl6
mncharity stevan_: I'm still unclear on which last part wasn't a fair summary? the entire "() they are waiting for (someone else to do) the "real" Perl 6 (on parrot?)." item?
jrockway i know it's not required
but it's like moose, once you see how good it is, it's hard to work on things that don't use it
i imagine perl6 will be like that
stevan_ mncharity: basically, there are not that many people waiting for that as there used to be I think
mncharity re imagine perl6 will be like that, indeed. :)
stevan_ jrockway: thats the whole reason I wrote Moose, Pugs spoiled me
mncharity: p6 has a well known PR problem 22:24
and Parrot does too
jrockway if moose didn't exist i wouldn't have to worry about the catalyst + dbic moose rewrites
instead i could be playing video games
so you-- :)
stevan_ not my fault they didnt use Moose in the first place
jrockway who needs moose when you can use Class::Accessor::Fast! 22:25
it's Fast!
mncharity ah, ok. so () p6 as p5+cpan is stalled. this because potential p5+cpan developers () found 5.10+Moose+etc was close enough to meet their immediate needs, and they are () either waiting for (someone else to do) the real Perl 6, or () have given up on it. something like that?
stevan_ yeah, but without all the () :P
mncharity LOL 22:26
stevan_ mncharity: and given up is maybe too harsh
"have thier doubts about p6"
cause once it is production ready, I *will* be switching 22:27
but not before that
and I am too damn impatient to sit around and do nothing until then
mncharity "p6 as p5+cpan is stalled. this because potential p5+cpan developers found 5.10+Moose+etc was close enough to meet their immediate needs, and they are either waiting for (someone else to do) the real Perl 6, or have their doubts about p6."
stevan_ "p6 as p5+cpan is abandoned. this because most of the p5+cpan developers found 5.10+Moose+etc was close enough to meet their needs, and they are either waiting for (someone else to do) the real Perl 6" 22:29
potential doesnt make sense in that context 22:30
and that last bit I am having trouble with
lemme fiddle a sec
mncharity if there was an easier way to actually help with p6 development, do you think people would join in?
stevan_ maybe 22:31
mncharity re fiddle a sec, np. just seemed like you and jrockway provided an opportunity to clearly understand what current state is.
stevan_ Pugs was fun, but never anything to be used seriously (audrey excempted of course)
jrockway mncharity: the real issue with working on perl6 is seeing results
cpan is fun becase you can get instant production use and feedback from other people 22:32
mncharity are people doing p6 rx on p5? or other "Grammar"-ish (sets of named rules) games? 22:33
jrockway yes, but not for parsing perl 22:34
5.10 regexes let you sort-of do real grammars
(if that's what you're asking)
stevan_ mncharity: I cant rework that paragraph really 22:35
I think p5 is not a suitable platform for the full p6
it is however a nice platform for almost-p6
mncharity I've been noticing the classes-as-Grammars concept has been getting "churn" in ruby-land. Wondered what was happening in p5 land. And perhaps if yet_another_regex_engine should become a cpan module.
stevan_ which I consider to be 5.10 + Moose + Devel::{Declare, BeginLift} + Autobox + other misc. CPAN goodies 22:36
mncharity re almost-p6, where 5.10+Moose+etc is almost, or something closer?
stevan_ mncharity: there is that Ruby tree parser module that looks a lot like p6 rules
mncharity ah, answered before asked
stevan_ mncharity: at some point, almost-p6 may evolve to the point ofbeing p6 22:37
we may wake up one day and suddenly find we have 99% of p6 available in p5 22:38
and perhaps parrot will be ready by then
who knows :)
I guess you could say we are moving bottom up, while parrott is moving top down 22:39
mncharity re 'uby tree parser module that looks a lot like p6 rules', really? not that I know of. rb is still stuck without being able to embed code in rx. there is the occasional isolated person doing a "cute little hack" of methods as rules, but nothing even remotely real. there is ripper and parsetree for compile and runtime parsing, but
nothing rule-ish that I know of.
stevan_ but unfortunately there is no place to meet in the middle (see the dead Ponie over there in the corner)
mncharity: lemme see if I can locate the webpage
mncharity lol
"not to beat a dead horse, but.." 22:40
s/compile and runtime parsing,/$1 of ruby code and op trees/ 22:41
stevan_ mncharity: treetop.rubyforge.org/
mncharity jrockway: re 'seeing results'+fun, so if one could get a "limited p6 written in p6" into cpan, suitable for "production use and feedback", people might hack on it? 22:43
jrockway sure
as soon as it's work-related it's very easy to justify :)
mncharity re treetop, ah, ok. unfortunately it's still quite new and rather toyish. 22:45
stevan_ yeah
mncharity lol # re work-related
stevan_ but looks kinda like rules
mncharity oh, indeed
stevan_ ok,.. dinner time here,.. mncharity good talking to you again, we should meet up at a Boston.PM meeting or something soon 22:46
mncharity re work-related, so perhaps that's an alternate (admittedly more difficult) target than "usable". "work-related", hmm. 22:47
stevan_ walk obra's neighborhood 5x over discussing multiple dispatch algorithms again or something :P
mncharity stevan_: re meet up, I'd really like that.
jrockway well, pretty much anything is work-related actually :)
mncharity :)
re mmd, :P
jrockway "does working on this help me solve some other problem"
mncharity stevan_: thanks. good talking with you. 22:48
jrockway: right. hmm...
there was a p6 implementation on cpan, wasn't there... 22:49
search.cpan.org/~fglock/v6-0.020/li...r/Perl6.pm
lambdabot Title: Pugs::Compiler::Perl6 - An experimental compiler for Perl 6 - search.cpan.org, tinyurl.com/2x4zl2
mncharity it gets no love because...? any idea? 22:50
22:53 ispy_ joined, ispy_ left
mncharity search.cpan.org/~agent/Pugs-Compile...r/Perl5.pm 23:01
lambdabot Title: Pugs::Emitter::Grammar::Perl5 - Perl 5 emitter for grammar ASTs - search.cpan.or ..., tinyurl.com/2m8n6z
mncharity search.cpan.org/~avar/KindaPerl6-0.001/ "** UNAUTHORIZED RELEASE **" 23:04
lambdabot Title: &#198;var Arnfj&#246;r&#240; Bjarmason / KindaPerl6-0.001 - search.cpan.org
mncharity PASS (3)   FAIL (12)
search.cpan.org/~agent/Pugs-Compiler-Rule-0.28/ in general 23:06
lambdabot Title: Agent Zhang (&#31456;&#20134;&#26149;) / Pugs-Compiler-Rule-0.28 - search.cpan.o ...
23:07 Psyche^ joined
mncharity jrockway: anything besides PCR come to mind as "Grammars"-for-p5? 23:09
23:14 zgold joined 23:29 explorer joined
mncharity anyone heard how TimToady is doing? 23:39
23:59 ebassi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!