allison: You'd probably find a quick volunteer if you wrote a p6i message with a provocative subject ("Help save Allison's world") Gee, thanks, tweety. chip: ok, I'll do that, thanks cool. who should I pick on next? * chip waves his hand ... better to jump than get pushed makes it easier to control the fall :-) Actually got some good time over the weekend. THe lexical picture is shaping up. cool I know I've been mumbling about this for a while, but this time I even got a good picture for closures. Short versoin: the interface for lexicals conforms to Hash, and for Tcl, they actually will be in a Hash. (Tcl is ... hardly compilable) yay! chip, that is *exactly* what I was wishing for this weekend Perl6 lexicals will be more like a pseudohash (and the shade of Graham smiles) Everyone else grimaces. The key/value translation belongs to the Sub, while the array thus indexed (the pad) belongs to the call frame actually I wrote Class::PsuedoHash. I like them. * mdiep is just happy that chip has taken Tcl into consideration :) They're actually a useful abstraction anyway: I think we can get a leg up on Perl 5 closures. Agreed, I'm just interrupting. Sorry. In perl 5, eval STRING in a closure can't see any variables that its outer subs didn't specifically mention. I'd rather just capture all the outer pads at closure creation time. But is that a bad thing WRT object lifetime? (maybe this is a question period. autrijus think about it) chip: of course that is the way to go. autrijus: good. so much for that question and I think p6 depends on that as well Perl 5 doesn't capture all the pads, just the specific variables it's seen as far as I can remember from larry's %MY:: and %OUR:: rants in yapctoronto so pugs is snapping all pads in all its runtimes cool if parrot does that. ok I agree, this will be cool OK then. My key resource is continued free time. Looking promising. ^Z ok. matt? wait. blocking on anything, chip? jesse: the 'resource' comment was meant as an answer to that: "no" ok. :) matt, then :) I finally figured out Tcl's lexical issues this week: Eval'ing in PIR returns a closure. Leo was kind enough to provide a way to get to the underlying Sub PMCs so those issues are still fixed err, s/still // we are still blocking on unimplemented functions in charset/unicode.c, however who needs to implement those? are there tests for them? I'm afraid I don't know much about those failures. coke reported them to me. oh, PGE for nonascii stuff for pugs has been blocking on those too I committed stubs and leo fixed my broken C code but many XXXs are left mdiep: do you know which specific functions you need? pmichaud: no, I don't. but I could probably compile a list, given a little time. mdiep: that would probably be helpful. I know that PGE is now currently blocking primarily on the find_cclass ops I'll try to compile a list and send it to p6i cool. Anything else good in the tcl world? not directly tcl, but I'm also waiting for chip to get back to me about my latest namespace spec draft other than that, no. cool a-firmative patrick? it's been a very busy week for me with parrot stuff last week I checked in the initial version of a shift-reduce parser, and a few examples in the examples/pge directory since then I've converted PGE to now use the shift-reduce parser for parsing perl 6 rule expressions (instead of the previous rec-descent parser) this also changes a number of the internal interfaces, but all for the better; it's a massive cleanup as a result, the perl 6 rules code is now 30% smaller (was 2100 lines, now 1500 lines) (benchmarked? :)) not to mention it should be faster I haven't benchmarked it, no, but there's a TODO item in RT for that :-) nice :) one big benefit is that PGE can now be used to parse perl 6 rule expressions; i.e., will parse out a valid perl 6 rule expression this makes it easy to embed in grammars I've also added the ability to define custom rules (for allison) and next I'll be implementing lookahead and closures cool. checkin is simply waiting for me to get everything sync'd up with the new code interfaces and make sure all the tests pass again awesome! anything you're waiting on? the biggest thing blocking me at the moment is the need to occasionally sleep ice nice though I hear they have drugs for that. the other thing we'll have is a nice rich set of trees (and desired transformations) that could serve as test cases for the attribute grammar code in particular, p6rules could serve as an example, since it has to go from parse tree -> semantic tree -> optimizations -> code gen we have... a tree and AG rules for haskell :) (it's the place luqui copied the L::AG from) i.e. UUAG/EHC indeed so, I'm just continuing on that, and will update the milestones document (again) in a day or two when the new changes are folded in leo provided some important improvements last week that enabled all of this (thanks again, leo) $ ok. leo? .local string report= <<"ZZ" var-regs hit finally the trunk all is owrking as expected *applause* *applause* leo++ leo++ leo++ cool I had to rewrite tailcall argument passsing a bit it's not quite trivial to move arge form a->b, when the register structure changed under that currently an intermediate array holds arguments and 2 passes are done but the nice thing is: this is all statically known at compiletime and can be optimzed i.e if there would be a conflict moving arguments for the sub today I ci'ed r9677 | leo++ | trunk: 13:59 <+svnbot6> : Variable-sized reg frames 17 - no register limits * enable 'spill' tests - no spilling of course: 13:59 <+svnbot6> : new P60, .Integer # yeah the PIR line is from one of the tests cool ZZ oh I updated wikipedia "Parrot" so it no longer talk about I31 great - thanks :) blocking on anything, leo? not yet - more cleanup will follow, then is release time next week a lexical PDD would be nice ;-) ok. matt? ah - I forgot one: rafl has debianized Parrot jesse: again? I already went :) oops sorry :) chromatic? Lots of little things -- Nick's patch, looking at the configure system, porting parts of Parrot::Test to PIR. I was traveling last week so I didn't have much time. Hopefully this week will be easier. ah, so I may not even need to mess with the library paths, nice :) It depends on when you need them. aye At some point I would also like a sane way to write tests for PIR code (not Parrot), much like Perl 5's bootstrapping tests in t/op. yeah, that would be good As far as I see now, that's partly cultural, partly a path issue, and partly a "What are the minimum bits we can rely on to write the basic tests?" Of course, it's awfully hard to test some of the libraries I've written... but I suspect we can fake out NCI at some point sometime. I'll probably have more questions about library loading and initialization in the future. It feels somewhat incomplete yet. That's about it. I'm blocking on time and attention span. ok who'd I miss? me oop nick. what's new? not a huge amount. Failed to get attention span. I did apply my tweaked version of chromatic's patch I've not yet gone for a dig to remove the old names in extend.c, and all the files using them in the parrot tree Nicholas: rafl has cleared dups already Stig noticed that ponie failed to build today. For some reason now I need libparrot before libponie (to get Parrot_PMC_push_pmc) and afterwards (to give libparrot the parrot config object) so I tweaked the linker line rafl++ Leo was kind enough to get 2 of the things I mentioned last week done within hours. leo__ leo++ oops hashes this week but he didn't have time for the hash.c change, and I found the source code somewhat daunting to try to understand (cold), so didn't manage to find the calm time to deal with it I think that that's where I am. cool I seem to be mostly blocking on my ability to get into the right state of mind. Plus work scheduling is not idea - in theory as soon as something I'm blocking on on the staging evironment unblocks, I need to deal with my part of it (at high priority). And I find that unsettles me I think that's it. less cool ;) anything else? questions? Yes. I don't have a good idea of how much time I have, and I find that if I'm not sure i've got 'large wooly amount of time' I don't want to start. Happened this morning where I (deliberately) got up at DST time, and then found that I couldn't really use the extra hour. I might as well go into work, and get the commuting disturbance out of the way. I have an interface question to float (PIR and lexicals) (n/m I thought he meant for everyone) so did I :-) Nicholas: I'm finding the trick to be relaxing a little. Go into Pogo mode Idid sorry. go for it chip Pogo mode? "Don't take {life,Ponie} so serious. It ain't nohow permanent." is all PIR going to be associated with a registered HLL? * chip supposes the answer is 'no' no (that is, confirmed, the answer is 'no') no registered HLL means native parrot semantics I presume and so lexical policies can be defaulted by HLL, but not tied exclusively to it. Right. A LexPad PMC for each HLL? chromatic: it seemed a convenient place to put the default, if there was to be one. Yes it's like a TclInteger which is different I need to actually pay full attention to something else thanks everybody. I'll grab logs a bit later. sorry to have to bail. keep asking questions cya thanks jesse thanks jesse [ditto] thanks :) The only complication (such as it is) is that I'd _prefer_ not to have to create a new FooPad PMC for languages where the pad is just a Hash (e.g. Tcl). But it seems I'm going to have to do so, if only so the init methods can be unfiied unified in their interface, that is. See, a Perl6LexPad init method will need to know the Sub it's from, so it can find the key/value pairs. But a Tcl pad can just be a Hash ... but a plain old Hash init method doesn't expect to find a Sub parameter. And the naive "add a level of indirection" solution starts to look bad when it's happening on every function entry. But some optimizations can wait. I think there will be still a FooPad, and if it's just for it's type name (if a FooPad is needed of course) you mean, all pads being named *Pad is a good thing, even if their implementations are thin? like a TclFloat which afaiks inherits all from Float ah, now I see what you meant. That's a good argument, thanks EOQ Sometimes names aren't just names. that's what my Mom said when she named me "Stinky" ... so, who's up next? questions? anyone? Bueller? * autrijus ponders Float::Tcl Question: should I just put the tree transformation stuff in the Parrot repository? Is there still an event system/ allison: now I've discovered svn.lohutok.net I'll point people to it if you don't commit them to parrot tree so to reduce your server load, committing them is probably wise *smile* Putting it in parrot is the simplest way to solve my immediate problem with library paths so I can write tests. allison: I think it's as core as PGE is, so yes It will still change radically over the next month or two, which is why I hesitate, but it is at least useful now. allison: I vote yes allison: it's okay if it changes radically -- PGE has done the same then where? compilers/tte? (Tree Transformation Engine) (Resisting the urge for a Psittacus joke: Parrot Standardized Interface for Tree Transformations: Abstract, Concrete, and Unnecessarily Silly... ;) allison: I wouldn't do it if that's the reason. But don't hesitate to show work in progress. And any API changes are liekly to get automagically fixed in your code if it's in svn allison: all is changing more or less - ci early ci often allison: comptools.pod too :) autrijus: okay compilers/tte works for me, although I've been thinking that some prototyped tools can start out in examples/ and then move to their proper location when they become less "example-ish" and more "developed-ish" allison: Never miss a chance to give in to temptation pmichaud: er but languages/* is all prototypes anyway s/all/mostly/ so why should compilers/ differ? autrijus: I don't disagree :-) maybe a COMPILERS file? er .STATUS same style as LANGUAGES.STATUS okay, how's this: I'll push it to the point that it's transforming PGE trees, then check it in as compilers/tte pmichaud: can you ci the 'newsub' removal code? I'll drop that opcode very likely tomorrow I'd still rather you just commit it -- if only for my sanity of not chasing more svk mirrors leo: My new version drops 'newsub' -- it should be ci'd in a few hours -- as soon as I can finish debugging tests great - thanks EOQ * leo is seeing forward allison increasing her purl karma by a steady flow of svnbot6 reports yes, go for the karma :) lol :) ...and I just mentioned svn.lohutok.net's existence on #perl6 (to integral, who has been dying to see them) I'm just about to post a journal entry I've been writing during the irc session too woot allison++ chip: I small (and premature) lexical Q: are we doing new .Undef the lexicals? ah. I was planning not. I was planning that they'd be null PMCs on creation. (Though a customized Pad could of course do something else) okie - PMCNULL is fine (for me) I think I prefer pmcnull Reason being, I imagine that the PMC being null could be a convention that the given variable is out of scope consider sub foo { eval '$x'; my $x } or used unitialized - that's the perl5 runtime thingy w/o strict afaik Hm, I think that's a kind of .Undef but anyway, null is easier & seems OK (&faster) you can assign to .Undef, doing that with .Null throws an exception yeah, that was my point - sub foo { eval '$x = 1'; my $x } should throw (but that's just a matter of an appropriate exception handler - I'm still for .Null) } // answer thanks allison: are you the new boss, even though you're the old boss? seems like we're kind of done chip: okay, we're done :) Yeah, I I'm working my way out of boss duties :) I'll adjourn to #parrot then thanks all bye all % leo has left #parrotsketch % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net % pmichaud has left #parrotsketch bye :) % autrijus has left #parrotsketch % allison has left allison!~allison@sub17-30.member.dsl-only.net % mdiep has left mdiep!~matt@bursley-221-209.reshall.umich.edu % jesse has left jesse!~jesse@209-6-22-26.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com % Steve_p has joined #parrotsketch % Steve_p has left #parrotsketch