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.
meppl good night 01:16
pmurias mncharity: should ruby STD_red_run --yaml -e 'say(1)' run on ruby1.119 15:13
pmurias * 1.19 15:13
* 1.9
mncharity hi pmurias, one sec, backlogging 15:47
mncharity 1.9 has a yaml problem. there's a note and patch in README. re say(1), I think so, checking... 15:49
pmurias it works on 1.8 15:50
mncharity ruby1.9 STD_red_run --yaml -e 'say(1)' works for me with a patched yaml.rb. and ruby1.8 without it.
:) 15:51
I was actually thinking of adding a fast path to <after> to help 1.8 with <ws>. let's see...
pmurias seen the patch 15:53
fixed it 15:56
mncharity eep. looks like there's been a performance regression, with both 1.8 and 1.9. perhaps yesterday's "clean up the Match tree" changes. 15:58
mncharity nothing obvious. so rolling back through revisions looking for the regression. 16:08
mncharity ok, so with 1.9, the hit, 2 sec->12 sec, is coming from YAML::Syck. that 2 sec includes the "never been optimized" original Match dump, so Syck's 10 sec is surprising. Removing expect_term's nounphrase, which introduces a non-tree-ness, saves Syck 3 sec. 1.8's Syck is a bit worse, and doesn't improve when nounphrase goes away. 16:43
so... custom yaml dumper? 1.8 with yaml is up around 40 sec, and so unusable. 1.9 at 12 sec is iffy. 2 sec is nice. 16:45
hmm, wonder if ruby's Syck can be told "don't try to connect up non-tree-ness - just be fast". because that's the only possibility which comes to mind on why Syck is losing so badly. 16:46
pmurias why is no-tree-ness slow? 16:47
allbery_b ..meaning it's searching for multiply referenced subtrees? 16:51
or nodes
mncharity re 'why is no-tree-ness slow?', keeping track of all the nodes seen, and checking new nodes against them? where node is any string or Match. 16:53
hmm, the 'each Match has a copy of the string it matched' might cut that in half... well, parts of it in half, each Match would still need its copy of the original source string then. 16:54
err, switching from the current design choice of 'each Match...' might cut... 16:55
re why slow, that's the only thing which came to mind on why Match's match_describe is <2 sec, while Syck is 10 sec. 16:56
the 3 sec improvement when nounphrase goes away also suggests this interpretation 16:57
ah, another almost 3 sec is spent on the formatting of those Match strings. 17:01
with Match's just containing crosslinks to a single original string, Syck costs 8 sec, down from 9. :/ 17:04
ok. live with 1.9 12 sec parse for now. sigh. 17:06
custom dumper later, especially if Match-tree non-treeness can be minimized or localized. 17:09
pugs_svnbot r20139 | putter++ | [elf_a] slightly prettier Match tree output. 17:25
diff: dev.pugscode.org/changeset/20139
lambdabot Title: Changeset 20139 - Pugs - Trac
mncharity what's the p5 magic phrase to interpolate an expression into a string? @{...} something like that...? 17:47
wolverian @{[ ... ]} if you want list context, ${\...} if scalar 17:48
lambdabot Maybe you meant: . ? @ bf ft id pl rc v wn
wolverian just like outside strings :)
mncharity thanks! :) 17:51
wolverian you're welcome
pugs_svnbot r20140 | putter++ | [elf_a] beginnings of an IR. 17:58
diff: dev.pugscode.org/changeset/20140
lambdabot Title: Changeset 20140 - Pugs - Trac
mncharity bbl & 17:59
pmurias mncharity: will the matches from STD_red be similiar to matches from STD.pm? 18:11
is there ctags support for perl6 (STD.pm specificly) 18:18
marshmallows hi, hope everything is going well :) 21:20
TimToady so do we... 21:30
rindolf TimToady: hi. 21:38
TimToady: I've been using TAP to test Anarki Arc.
marshmallows hey TimToady, How is it going? 21:44
(what's being worked on currently?)
(pugs.blogs hasn't updated in a long time..)
mncharity pmurias: re 'will the matches from STD_red be similiar to matches from STD.pm?', yes. STD_red's std.rb is just a hand modified version of STD.pm, converting it into executable ruby. 22:06
re yes, well, that's the intent. In so far as it doesn't look like a Match tree emitted by STD_red could be produced by STD.pm, that's more or less a STD_red bug. That said, there seemed no need to add Matches for "pass through" rules. And there are places where I mishandled the #= comments, which should be tweaked. 22:09
mncharity And the few backtracking rules, don't. So some as-yet-unknown portion of p6 won't be parsing. And the same for the absence of longest token. That said, STD.pm doesn't yet itself define a workable parser, so no big deal. 22:11
And there's a bit of "well, we're not quite synced with parts of STD.pm, but focus on using it and worry about details later, as STD.pm matures". But, basically yes. 22:14
Re backtracking, there's a story for how to add it. But it's a bit crufty, so I'm just waiting to see if the absence causes problems in practice. 22:15
mncharity pmurias: ctags? I'd be surprised (very) if there were a ctags mode for p6, but other than that, it should work fine, no? 22:17
what do you wish it to do?

Powered by Cro and the Raku® Programming Language.

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

Thank you!