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.
clkao i am not saying we don't need testing. 00:13
oop miscan 00:14
meppl good night 02:00
mncharity i suppose it's technically tomorrow already, and way past end of day, but let's see, something quick... 04:30
mncharity v6/v6-KindaPerl6/src/KindaPerl6/Runtime/Perl6/Match.pm is Capture is Value... hmm. simpler... 04:34
g'night all & 04:37
pugs_svnbot r20166 | putter++ | [elf_b] Dropped new() from ir_nodes.p6. Moose provides. The real-soon-now elf_b_create ast_handler creator can almost as easily use named arguments as positional.
diff: dev.pugscode.org/changeset/20166
lambdabot Title: Changeset 20166 - Pugs - Trac 04:37
ruoso . o O ( *sigh* It's probably two weeks without coding SMOP... real life sucks... *sigh* ) 10:38
mncharity ruoso: re two weeks without coding SMOP, :/ 14:58
pmurias mncharity: does the order of fields returned by field_names matter (other than being the same as field_values)? 16:17
pugs_svnbot r20167 | lwall++ | [STD] fighting all kinds of YAML, TRE, and P5 bugs... 17:00
diff: dev.pugscode.org/changeset/20167
lambdabot Title: Changeset 20167 - Pugs - Trac
mncharity lol #re commit message 17:17
sigh
re YAML, it might be easier and faster to do a "dump as p5" format like STD_red_run's new --dump5. 17:18
TimToady I'm just dumping lex/* as raw lines now 17:22
TimToady the only thing left in YAML is the DATA section, and that seems pretty harmless 17:23
mncharity ok 17:29
err, "nod" 17:30
mncharity my first bit of programming on elf_b. yay. :) 17:53
pugs_svnbot r20168 | putter++ | [elf_a] Start of for() and while() support. New -xe option: -xe -e 3 runs 3 in a separate perl.
r20168 | putter++ | [elf_b] New -e CODE. Calls STD_red, and builds a Match tree. Match::describe is unfinished.
diff: dev.pugscode.org/changeset/20168
lambdabot Title: Changeset 20168 - Pugs - Trac
mncharity oops, forgot to svn add Match 17:55
pugs_svnbot r20169 | putter++ | [elf_b] Add the new Match.pm file missing from r20168. 17:59
diff: dev.pugscode.org/changeset/20169
lambdabot Title: Changeset 20169 - Pugs - Trac
pmurias mncharity: why do you prefere positional arguments to named ones? 18:01
* prefer 18:02
mncharity pmurias: in what context? 18:03
the --dump5 format uses positional because it's faster in p5, plus smaller and simpler. 18:04
pmurias in Match.pm you wrote a special positional version of new 18:05
mncharity with it, knowledge about Match's exact method names remains localized in Match for now, rather than leaking into main.p6, which otherwise has no need for it. so it's a firewall to stop Match naming decisions from propagating into main.pl. 18:07
Also, Match, and its field name choices, hadn't been written yet when the main.p6 code was. :) 18:08
err, s/main.*/main.p6/g
pmurias the first reason is a bit lame 18:11
can i purge Match.make ? 18:14
mncharity re lame, perhaps, but it's compartmentalization. The dump pipe/format and its ends should be independent of the Match format used (since every single p6 impl has had a different one, and that's not likely to stop). make() is basically make_from_dump5_match_format(). 18:16
pmurias you count on the positionals being maped to the right attribiutes nonetheless 18:17
mncharity placing the make_from_dump5_match_format in Match rather than in a not yet existent Parser class which encapsulates the pipe might be something to refactor in future, but as Parser doesn't really exist yet, just scattered pieces of it, and as Match is likely to change, the current location seems plausible. 18:18
the match() terms on the --dump5 pipe are defined positionally. 18:19
and subject to change of course - I punted bool for instance, since it currently isn't being used in STD_red match trees. which perhaps needs to change, but for now, kiss.
but the contents and layout of those terms are a separate issue from how any particular p6 client may chose to structure its Match object. 18:20
pmurias sorry, misunderstood Match.make() intended purpose 18:21
wouldn't 18:22
package Fastdump { sub match ($r,$s,$f,$t,$h){Match.new('rule',$r,'str',$s,'from',$f,'to',$t,'hash',$h)}
}
be cleaner?
forgot the rationale at the top 18:23
silly me
mncharity so the question is, should the nacient Parser code, depend Match providing an "undump" function (ie, "Match understanding pipe format"), or should Parser understand Match layout. I guess it doesn't matter much at the moment, since they are both likely to change. spreading pipe knowledge around seemed simpler... not sure why. perhaps because the current Match
seems even more of a hack than the pipe layout. 18:24
pmurias the Match.new interface needs to be specced 18:26
* speced
mncharity with the exception of from() and to() there, everything else is non-spec. AST handlers unavoidably have to deal with it, though the current ast_handler.config preprocessor provides insulation from .rule and .str.
re speced, yes
Match has "been in need of" spec'ing for a very long time. But there are sort of different visions for what Match is. And the choices seem non-local, tied up in regex engine implementation for instance. So... the issue gets deferred, probably properly so. 18:28
my impression is only the from(), to() and the coerced behavior of Match (eg, as hash or bool or ...) have been speced. I could well be wrong/out of date though. 18:29
taking a look at Snn and making elf_b_src/Match.pm ... err... can't resist... making elf_b_src/Match.pm match them... would be great. 18:30
hmm, though maybe that should wait for elf_c.
pmurias you can't resist looking at the spec? 18:31
mncharity focus of elf_b is to work at least as well as elf_a, being able to compile itself and be used as the platform for further development.
re ?, err, no, lame pun, never mind.
mncharity so anyway, that's the story on make(). no big deal - whichever. feel free to do your suggested edit. a first commit by someone else to elf_b! woot :) that would be nice. 18:37
mncharity pmurias: I'm contemplating adding a cache for parser output, to speed things up. I'd be interested in any feedback re "it's fine" vs "yeah, faster would be more usable". 18:43
pmurias it dosn't matter to the user much only for the elf developer 18:47
mncharity hmm, re "AST handlers unavoidably have to deal with it", err, no. that's wrong. I was confused. the whole point of that preprocessing of ast_handlers.config to avoid dependency on .str is because then the handlers *don't* have to deal with it. Keeping the internal structure of Match something only (un)dumpers and elf_x_create have to worry about. 18:48
elf developers are currently the only users. :) so I gather that was a "yes, faster would be more usable"?
pmurias yes 18:50
mncharity ok. sounds like a plan. indeed, even the 7 sec delay when working on main.p6 was getting to be a pain. 18:51
so caching and perhaps better error messages for usability, finishing match_describe and a start at ast_handlers for elf_b. 18:53
pmurias & 18:57
mncharity lunch & 18:58
pmurias mncharity: would it speed up the compile if methods in ir_nodes where inherited instead of generated? 21:03
mncharity pmurias: anything which reduces the code to be parsed, would speed up the compile. but since our objective to create lots more code, it's a best a very short term fix. let me check in an attempt at a caching STD_red_run... 21:33
pmurias mncharity: caching code - that assumes the code dosn't change right? 21:40
mncharity right
so it doesn't help if you are working one something big, like ir_nodes.p6 21:41
pugs_svnbot r20170 | putter++ | [STD_red_run] An attempt at caching, to speed repeated parsing.
diff: dev.pugscode.org/changeset/20170
lambdabot Title: Changeset 20170 - Pugs - Trac
mncharity but if you are working on something else, eg, Match.p6, then the ir_nodes.p6 parse will be fast after the first run. 21:42
just set STD_RED_CACHEDIR to some temporary dir.
for me, the caching takes the 7 sec ./elf_b_create down to 3 sec. 21:44
of which 1+ is ./elf_b perl5 startup time, so the compile+emit is taking < 1 sec.
err, no. < 2 sec. 21:45
I'd be interested in hearing how it runs for you. 21:46
pmurias STD_RED_CACHEDIR env var? 21:50
mncharity yes 21:52
--help has some details. only one of note here is -e CODE isn't cached. 21:53
pmurias 11sec 21:54
mncharity :/ 21:57
pmurias the orginal thing is even slower
mncharity the first run takes how long?
pmurias mncharity: the cached matches are very large 21:58
24sec
the cached file is 968K 21:59
* are 22:00
mncharity could try compressing them. but on a cpu limited machine that seems problematic. success would depend on the filesystem being even slower. hmm. 22:02
i really really want to avoid the mess of build systems and individual file compilation. 22:04
pmurias the string that was matched against is duplicated over and over again
mncharity I don't suppose your laptop has a cpu knob, one with a "waste power, be hot, run fast" setting? :) 22:05
"the string that was matched against"? oh, yes.
currently each Match object has its own copy of its match string, rather than using indexes into a single copy of it. 22:06
mncharity perhaps order 10x bigger. 22:07
went back and forth a couple of times fighting with yaml. didn't seem to have any performance impact. 22:08
pmurias mncharity: i'm using a standalone box 22:09
pmurias * desktop box 22:10
mncharity oh, sorry, misremembered 22:13
hmm.
sigh. 22:14
pmurias np
;)
mncharity lol 22:15
relieved lol :)
pmurias mncharity: is there a reason for not keeping on copy of the str? (besides simplisity) 22:20
mncharity pmurias: not really. could tweak the --dump5 protocol to be something like matching_string('...one copy...',match('comp_unit',0,3,{...})) and then unpack it at the other end. 22:24
pmurias i get try doing it tomorrow
s/get// 22:25
mncharity hmm.. matching_string('...one copy...'); match('comp_unit',0,3,{...})
not s-expressions, but function calls. :)
re tomorrow, :)
might want to check how fast it is just to pipe it through compress or gzip -<small int>. with the text gone, it will be more a machine format than one which can be eyeballed, so could go all the way. :) 22:27
pmurias maybe bind_str('string',0); match(...,get_string(0)) 22:28
mncharity (un)compressing it would just be a 2 line change.
pmurias loading the match by perl takes 0.65sec
mncharity re 10000 copies of "get_string", perhaps have a match2(...) in which the get_string is implicit. 22:29
but I like being able to index into multiple strings... 22:30
pmurias i should get to sleep instead of wasting time not coding 22:31
mncharity good night... 22:34
the current dump is 34x bigger than the ir_nodes.p6. gzip -9 takes that down to 3x in < 0.1 sec. 22:36
s/than/for 22:37
but... we are talking less than a MB. for a big file. do we care?
Blazeix Hi, I'm trying to learn Perl 6, so I'm implementing a card game. I was originally going to use an array of strings to keep track of the suit types, but I was wondering if there was a more perl6-centric way. Any insights? 22:43
maybe a junction? 22:46
mncharity class Suit?
Blazeix And just have publicly accessible constants? 22:50
pugs_svnbot r20171 | putter++ | [elf_a] Added kludgy primitives for s/// and file_exists(). Added quote:regex and its IR node. $x.re_gsub(/b/,'B') emits as $x =~ s/b/B/g; 22:53
r20171 | putter++ | [elf_b] Fleshed out match_describe(). elf_b, given its own code, currently dumps a description of the Match tree. >4x slower than elf_a does.
diff: dev.pugscode.org/changeset/20171
lambdabot Title: Changeset 20171 - Pugs - Trac
mncharity p5 encouraged a very "bottom up, non-oo, minimalistic" style. p6 is much more like ruby or python in encouraging a more oo approach. so more like "what are my concepts, and the operations on them - those can be objects", than a p5-ish "what language primitive shall I use to express a concept". 22:56
my answer to "how to learn p6" is starting to be "learn ruby". :) 23:00

Powered by Cro and the Raku® Programming Language.

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

Thank you!