% mdiep has joined #parrotsketch
% autrijus has joined #parrotsketch
<autrijus> sketch in 30 mins?
* autrijus tries to not fall asleep
% leo has joined #parrotsketch
<leo> hi all
<mdiep> hello
<obra> hi
<obra> right then.
<obra> Allison is on a plane.
<obra> My bet is that nick is on hte tube
<obra> Allison asked me to paste her report from use.perl
<obra> I've checked in the code to transform Punie match objects into AST trees. The core pieces are:
<obra>     * A tree grammar for the transformation in languages/punie/lib/pge2past.g
<obra>     * A series of AST nodes in languages/punie/lib/PAST/
<obra>     * A script that parses a Punie source file, transforms the match result into an AST tree, and dumps the tree in a text format for verification. This is named punie2.pir, because it's still not far enough along to replace punie.pir.
<obra> So, if you run:
<obra>     parrot punie2.pir demo.p1
<obra> You'll get a match object something like:
<obra>     "$/" => PMC 'PGE::Rule' => "print 1;" @ 0 {
<obra>         <PunieGrammar::expr> => PMC 'PunieGrammar' => "print 1" @ 0 {
<obra>             <PunieGrammar::gprint> => PMC 'PunieGrammar' => "print 1" @ 0 {
<obra>                 <PunieGrammar::expr> => PMC 'PunieGrammar' => "1" @ 6 {
<obra>                     <PunieGrammar::term> => PMC 'PunieGrammar' => "1" @ 6
<obra>                 }
<obra>                 [0] => PMC 'PunieGrammar' => "print" @ 0
<obra>             }
<obra>         }
<obra>     }
<obra> And an AST something like:
<obra>     <PAST::Stmts> => {
<obra>         'source' => 'print 1;',
<obra>         'pos' => '0',
<obra>         'children' => [
<obra>             <PAST::Stmt> => {
<obra>                 'source' => 'print 1;',
<obra>                 'pos' => '0',
<obra>                 'children' => [
<obra>                     <PAST::Exp> => {
<obra>                         'source' => 'print 1',
<obra>                         'pos' => '0',
<obra>                         'children' => [
<obra>                             <PAST::Op> => {
<obra>                                 'source' => 'print 1',
<obra>                                 'pos' => '0',
<obra>                                 'op' => 'print',
<obra>                                 'children' => [
<obra>                                     <PAST::Exp> => {
<obra>                                         'source' => '1',
<obra>                                         'pos' => '6',
<obra>                                         'children' => [
<obra>                                             <PAST::Val> => {
<obra>                                                 'source' => '1',
<obra>                                                 'pos' => '6',
<obra>                                                 'value' => '1',
<obra>                                             }
<obra>                                         ]
<obra>                                     }
<obra>                                 ]
<obra>                             }
<obra>                         ]
<obra>                     }
<obra>                 ]
<obra>             }
<obra>         ]
<obra>     }
<obra> In these source is the chunk of source code from the original file corresponding to the current node (good for error reporting), pos is the offset from the start of the source file to the point where the corresponding match node started to match, and children is a list of child nodes for the current node. Some node types, like PAST::Op and PAST::Val have custom attributes.
<obra> I've still got some time left to work today, so I'll start on the OST now (though, I probably won't bother to post about it unless I run across something exciting).
<obra> And that's allison's report
<obra> Who can I pick on next?
<obra> leo: you here?
<leo> yup
<autrijus> me too :)
<obra> What's new and exciting?
<leo> all boring
<obra> (Then I'll ask autrijus, so he can not worry about falling asleep)
<leo> *g*
<leo> finished dynlexpad - interops with standard pad aka .lex vars
<leo> refined introspection e.g.:
<leo> pad = interp["outer"; "pad"; 3]
<leo> pad = interp["outer"; "lexpad"; 3]
<leo> sorry
<leo> next was imcc cleanup - tossed about 200 lines related to 'bsr'
<leo> and finally I experimented a bit with optimizing get_params
<leo> with the help of PIC and code rewriting
<leo> gives a fine speedup
<leo> EOR
<autrijus> my turn?
<obra> yep
<obra> go for it
<autrijus> as my journal indicated, 90% of free time is tied up to paying $job at this moment. expect free from Friday onwards for 10 days, then sink back to $job until end of January
<autrijus> the remaining 10% was spent on PIL2, in particular turning it from a functional calculus into an object calculus
<autrijus> in particular, this makes anything object potentially act as a function.
<autrijus> also need to chase IMCC again -- the previous abstraction of PIR language is kinda stale
<autrijus> but it sounds like allison is already doing that part of work as POST
<autrijus> so was intending to ask her
<autrijus> also chip popped on #perl6 today inquiring about parrot targetting and I missed the call; will be glad to answer things if chip is around
<autrijus> not blocking on anything really, except for time available
<autrijus> EOR
<obra> ok.
<obra> chip, you here?
<obra> patrick?
<obra> matt?
<mdiep> yep
<obra> hey matt. what's up?
% coke has joined #parrotsketch
<mdiep> as of ~20 minutes ago, Tcl has implemented pdd20 and is passing 100% of tests
<autrijus> ooooh!
<leo> woot
<mdiep> with much help from coke and leo
<obra> Very cool
<obra> What are you folks blocking on?
<mdiep> we spent a lot of time on the changes
<mdiep> I don't think we're blocking on anything currently. Give us some time to catch up from all the changes. :-)
<obra> Very cool
<mdiep> on the namespace front, chip finally got back to me
<mdiep> he added some things to the draft I sent him. I need to add/change around a few things and then the next draft will be sent to p6i
<mdiep> ^D
<obra> chip? 
<obra> alternatively, questions?
<chip> hi guys
<obra> hey chip
<chip> woot
<autrijus> yo chip
<chip> I'm updating pdd03 and looking forward to matt's next revision
<chip> I'm also realizing that in the long term (not necessarily yet) exception handling should be based on an exception table with ranges of opcodes, rather than dynamic opcodes like push_eh.  Exception handling can be a bit more expensive, if it makes the straight code case faster
<chip> not blocking.
<chip> also, I'm appreciating the flow of code ... nice work guys
<obra> cool.
<chip> I'm going to drop out shortly due to a tunel
<chip> (autrijus, the question turned out to be self-answerinhg, but thanks anyway)
<obra> Can I harass you about getting the milestones doc updated?
* chip considers himself harrassed
<obra> Ok. I'll mail you the small segment that wants comments.
<chip> DIVE DIVE DIVE (tunnel)
<autrijus> chip: return() and next() are exceptions also
<autrijus> so I'm curious about the opcode range idea
<chip> return is not handled like one; next, yes ... frankly I think it'll make everything faster.  static good, dynamic bad
<autrijus> but as it's long term, I'm not too worried :)
<chip> autrijus: see gcc
<autrijus> http://gcc.gnu.org/onlinedocs/gccint/GIMPLE-Exception-Handling.html # this?
<autrijus> so by "range of opcodes" you actually mean "opcodes"
<autrijus> no problem then. static good :)
<obra> Right then. Anything else?
<obra> If not...
* obra bangs the gavel
<obra> Until next week.
<obra> (When I may be in Germany)
<autrijus> cool. thanks obra!
% rafl has left rafl!~rafl@feather.perl6.nl
% chip has left chip!~chip@feather.perl6.nl
% autrijus has left autrijus!~autrijus@feather.perl6.nl
% rafl has joined #parrotsketch
% autrijus has joined #parrotsketch
% chip has joined #parrotsketch
% leo has left #parrotsketch