% cognominal_ has left cognominal_!~stef@cac94-1-82-67-232-89.fbx.proxad.net % cognominal_ has joined #parrotsketch % cognominal_ has left cognominal_!~stef@cac94-1-82-67-232-89.fbx.proxad.net % cognominal_ has joined #parrotsketch % cognominal_ has left cognominal_!~stef@cac94-1-82-67-232-89.fbx.proxad.net % cognominal_ has joined #parrotsketch % mdiep has joined #parrotsketch % leo has joined #parrotsketch % allison has joined #parrotsketch % PerlJam has joined #parrotsketch 'afternoon good afternoon good $daytime all good morning :) nick and autrijus send their regrets % rafl has joined #parrotsketch % pmichaud has joined #parrotsketch right then. shall we get started? * obra spins his wheel-of-victims leo! you win! What's new? * implemented unicode character classification code (is_upper ...) * fixed a lot of bugs, like 'neg N0, 0.0' * prepared for release * emitted a "Wart" aka Parrot 0.3.1 to the public :-) * checked in today a huge improvement in PASM/PIR compilation speed (can't tell yet how much faster it is - didn't have any big code piece but compiling sudoku.pir went down from 0.4s to non-measurable) * started today with register allocation for lexicals and non-volatiles leo: Yay! on Wart. blame chip ;-) (the latter are persistent vars around a subroutine call) leo: a good comparison might be the speed of the pge tests leo: which I did notice were faster today got a big piece of code from jonathan * the continuation bug that was the very reason for variable-sized register frames is gone now EOR tcl's tests also seem to be moving a bit faster. for these small code pieces it's not much, but jonathan reported compiling times of minutes I'm waiting for results from him still end-of-report so far cool. patrick: what's new? still more features and things being added to pge I sent mail to p6c/p6i detailing the improvements so I won't repeat them all here all of the new parrot features (thanks again to leo) are making my tasks much easier I'm currently adding a couple of simple optimizations to the matching engine, then I'll revise the code to take advantage of PIR's new hereis syntax I'm going to spec out the error-handling (or end-of-string handling) for the shift/reduce parser later today and other than that it's just a continual progression forward. I'm hoping to draft up a p6 parser tomorrow or wednesday cool! blocking on anything? not really, although I'll soon be in a position where it would be really nice to have lexicals working the way they're likely to end up cool. and there are a few areas where it would be nice for us to have spec'd out the subroutine calling conventions for perl 6 (leo, blocking on anything, since I forgot to ask ) (i.e., how perl 6 subroutine calls map to parrot subs) I'm blocking on nothing but I forgot 2 things above: * heredoc = <<'SQ_delimted' and emit(code, <<'EOCODE', args) both are working now too that is heredocs work almost everywhere, where a string is allowed that's heredocs inside PIR? yep cool! I've been wishing for those working on p6rules :) the compiler-writers special edition :-) patrick: who shoulds be writing the p6subs->parrotsubs doc? yes, I wanted those so I could speed up p6rules code gen a fair bit thanks to pmichaud obra: I'm not sure -- I think that's something that may require a meeting of the minds between allison, chip, leo, and myself ok. anything that can be done to help make that happen? chip probably has the best insight into it at the moment, but he may also be the most time constrained (besides heckling from the sidelines) chip: are you here? I need to re-review S06 and the latest document regarding namespaces, fold those into my mental map, and then maybe I can draft a very rough proposal *nod* it's not something that I'm blocking on in any way, it's just something that we'll eventually need and the sooner I have it the better I can fold it into other designs *nod* anything else before I pick on allison? btw, allison, I don't know if you noticed but PGE::Util has a built in "parse_rules" function that will take a string containing grammar statements and rules and load them all at once oops, s/parse_rules/compile_rules/ patrick: I hadn't noticed yet, I'll look at it .yield() ok, I've been working on the tree transformation stuff. (I've started calling it TGE for tree grammar engine, because TTE made me think of something biological.) It has the ability to transform PGE match trees now. The biggest thing I had to change was to allow attribute fetch calls to pass in a string telling the type of the tree node in addition to the tree node itself. (This is because PGE match nodes are named by the hash key, so the node itself doesn't know what type it is.) My test case for transforming PGE match trees was TGE's syntax parser. Partly because it was a good working example, and partly because I was tired of using TGE's procedural interface (which works, but is clunky, much like PGE's p6rule). I'm currently doing some refactoring, gradually moving away from Luke's Language::AttributeGrammar. Giving it more meaningful method names, fleshing out the documentation a bit... Next I'll add it to Parrot. (compilers/tge) Then use it in Punie, to see how it handles a larger scale grammar. EOR, but one request Request: a bit of PIR syntactic sugar for if_null and unless_null opcodes. Maybe something like "if null $P5 goto LABEL". blocking on anything? nope just a side note that it's possible to get a match object of a different type by using in the grammar (assuming, of course, that ClassName is a subclass of PGE::Rule) but yes, one still needs to be able to identify match object type based on its hash index name matt: what's new? or chip tcl is failing fewer tests this week quite a bit fewer, actually cool. due to tcl hacking or parrot hacking? coke has reported that we're tickling another GC bug on his machine (#37617). but no response on that yet. obra: both there's one undiagnosed failure that just popped up today other than that, the 4 remaining failures are due to the fact that there's no unicode implementation of the downcase opcode but leo committed unicode implementations of the cclass opcodes last week, which helped us pass another handful of tests cool any large (or small) blockers besides the unicode? I'm also waiting to get in touch with chip again about the namespace spec the GC bug is also blocking nod I have now a timing of a code piece provided by jonathan: 6247 .subs in 450K PIR: compile time before r9816 2m48s - now it's 35s as is communication with chip. other than that, we're clear. leo: nice mdiep: *nod* and I think that brings us to question time the timing are from an old 600Mhz notebook anyone got questions or can I let class out early? * mdiep has a question for pmichaud go for it pmichaud: are there any PIR tasks for PGE that other people can help with? mdiep: good question mdiep++ # really good question I think I'd answer that with a question, which is "are there any things PGE needs to be doing that it isn't now?" with this next set of updates I think I'm going to be at a fairly stable plateau with PGE, and it would be great if someone else wanted to pick up the feature development for PGE i.e., PGE needs to be able to handle the array capture syntax in the (as yet unreleased) latest version of S05, and a few other oddities pmichaud: I think if you made a list of PIR tasks you'd find that some of them got accomplished. I, for one, am much more able to contribute PIR code than I am to hack on Parrot's innards. I'd like to be able to add more of the modifiers, but to do that "right" it'd be nice to know what the standard calling conventions are going to be (especially for passing named parameters to sub) oh, I have a biggie :-) coke wants to have something that can parse perl 5 regexes, I was going to write a very very simple perl 5 regex parser today/tomorrow that handled just the basics it would be great to have that extended to the full p5 regex syntax, and that's definitely something I'm not working on but, for now I'll start a TODO file in compilers/pge and list PIR-related tasks that would be good for that excellent and, of course, there are probably all sorts of rule optimizations we could add to pge who's next? HI (just made it in to work. funny weekend. sorry.) Hi chip! What's new? (you're up) I'm responding about namespaces today, sorry mdiep I finally nailed the lexical spec to the wall. pdd20. np, chip I'm doing a once-over on pdd03 to bring it up to current status, then I'll see if I can toss named parameter handling in there chip: yay! (thanks) is pdd20 in svn? obra: it is that's it for the report ok. a question for chip on behalf of autrijus: would you do him the favor of reviewing the S17 draft he wrote with liz m. to see how well it maps to what you're thinking about for parrot threads http://svn.openfoundry.org/pugs/docs/AES/S17draft.pod (S17 is 'threading and concurrency') this is very much not a draft blessed by @larry, at this point. fetched. cool will review, np anyone else got anything? just an observation ... allison: wrt if null syntax - please drop a TODO or Nice-to-have on p6l leo/chip: I sent you mail from ovid asking about grant status. I'll poke you again on wednesday or so. p6i sorry leo: will do obra: yes it's in my todo list leo: cool er, n/m, it's not really a Parrot thing, just a Perl 6 thing obra: found it this darned 450K pir thingy has killed kde :-( ok. last call before I bang the notional gavel and declare this meeting over *bang* I'll catch y'all next week thanks see you all next week thanks, jesse! cyall thanks and see you * obra wonders if we should try to get someone to summarize logs for the public % pmichaud has left #parrotsketch % leo has left #parrotsketch % allison has left allison!~allison@sub17-30.member.dsl-only.net % PerlJam has left #parrotsketch % cognominal_ has left cognominal_!~stef@cac94-1-82-67-232-89.fbx.proxad.net