% particle_ has joined #parrotsketch % particle_ is now known as particle % leo has joined #parrotsketch % allison has joined #parrotsketch good evening hi all howdy "And now we play 'Guess Jesse's timezone' GMT+1? GMT leo wins :) (Or is Germany technically on a non-GMT timezone?) % Nicholas has joined #parrotsketch germany is gmt+1 afaik, as austria hi Guenos Dias (guanos? cool tyop) lots of bats Hey chip. svk ci MANIFEST docs/pdds/pdd21_namespaces.pod and nicholas, and so on howdy chip: don't forget "svk push" ;) obra: I should probably convert to a branch style of dev, but for now I still work in a mirrored checkout. chip++ #pdd chip: ok, then :) mdiep++ # main body, patience hm. no tcl people. and no audrey. but let's get going. we'll catch up with them when they show Leo, you're up first. - implemented named argument passing as posted on p6i/p6c - refactored arg passing guts into a nice and managable state machine % chromatic has joined #parrotsketch - ambs (Alberto Simoes) provided the PIR support for it e.g.: (kw :named :slurpy) = foo(1, 'a' => a, kw :named :flat) .sub foo .param int i .param pmc a :named('a') .param pmc b :named('b') :optional .param pmc h :named :slurpy ... I'm seeing forward to hear some comments from our chief designer :-) EOR ok chip? How's things in your world? I'm happy to have produced the namespace pdd, metaphorically 1.0 (which is not to say 1.0 is final, 'course) way cool. What's next for you? The main delta is that there are not going to be any list functions that require examining "does" predicates on objects that are contained Next is to give first opinions on Leo's pending dev docs. Leo, is the feather directory still the current place to find those? % mdiep has joined #parrotsketch chip: yep ok Next will be going back to the clips well and fleshing out what is and shall be Are 'first opinions' likely to be oneliners or page-long rationales? one-liners. or maybe one-paragraphers. cool. anything besides real life blocking you? that's all, thanks ok * obra makes a note to do away with 'real life' allison? how's punieland? always a design complications I guess it's been two weeks for me In that time I finished off comma expressions, and added support for value types. I worked on the operator precedence parser, but stalled and dropped a question to Patrick. Next I'll either work on adding a few more functions, or on control structures. *nod* Speaking of, since he's not here, do you have an idea of pge status? Well, milestone one is pretty much finished. Patrick is working on a perl6 grammar to give it a good workout. but I don't know the progress on that EOR ok blockers? just getting some of Patrick's time ok I think it's just a bit of the operator precedence parser that isn't documented. (I've jsut shot patrick mail to harass him) mdiep: how's things? I've been really busy with $job I sure know that feeling. anything going on in the greater parrot tcl world that's worth reporting? so I've had no time for any parroty things in the past couple weeks. that's bound to continue for another couple weeks. although if the namespace pdd gets implemented, I probably won't be able to resist. noted. I hear a rumor chip wants to answer some questions now since geography might get in his way soon. is it ok if we pause for that? I'm not even sure. I'm a bit behind on what coke's been doing. and given that, anyone got questions for chip? yeah, chip a short note wrt named args? Shortnote: "Good AFAICT". I haven't seen anything that's either excessive or problematic so far I'll be going over the interaction of positional with named very carefully, making sure the right things are specified and the right things are not specified. Wiggle room is the designer's safety blanket end of note ok. more for chip? thanks - should I update pdd03 to current state or are you doing it? (oh, but please don't do proposals in the form of code any more) if you proffer a diff that'd save time, so if that's something you'd like to do, thanks ok, I'll mail you a diff chip: there were 2 proposals 1) syntax 2) semantics which both are needed yes I'm down to one more Q, then reception will be spotty ok. looks like an empty question queue quite. I'm back to lurk enjoy your tunnel :-P ok. mdiep. anything else? nope :-) ok particle: what's new in the world of testing and other? added t/TESTS.STATUS.pod (aka http://www.parrotcode.org/testing_status.html) to the repo this week it's incomplete, but i have a feeling it always will be catching up :) it should help, well, track status of the testing effort :) also, added some tests for required positional arguments in prep for leo's massive param passing changes however, extensive testing of the new semantics should take some time to develop, due to the large number of permutations in the meantime, ambs and leo have provided a good set of tests for these things the old-fashioned way, one at a time there are a large number of things that need testing, and i'm falling behind. no blockers, just time. nod. is the set of things that need testing well specced? IE, could a "todo" list lure in more testers? yes. my first step was to create the above-mentioned doc, an overall status. now, those items can be entered as TODO tx, and those can be broken down further if requested cool after i enter the tx, i'll make some noise on p6i and ask for volunteers cool anything else? no. ok Nicholas: anything new in parrot-that's-not-your-problem? er. ponie-that well, the two plausible next tasks are both blocking refactoring sv_setsv (prior to using PMC set methods) really needs to be done in trunk perl 5, because code there is already modified, and it avoids two may merging. But Rafael has requested that trunk perl 5 is kept stable prior to 5.9.3's release, which is taking him quite some time and the task of reorganising the use of PMC blocks on Chip responding to Leo's PMC layout proposal, and whatever results from that. So it's good to hear that Chip is about to be able to look at that. so arguably it's all blocked. Which isn't fun. I think that that's all I can say ok chromatic: how's by you? The book is almost ready. woo After I finish that, I'm going to submit a TPF grant request to write a series of PIR tutorials. My intent is to take people from "Hello, world" to the point of being about to write libraries (NCI and otherwise) in PIR. cool That's it for me for now. ok. audreyt: you here? and if not, anyone got questions? did I miss anyone? I forgot a bit to report: 17:46 <+svnbot6> : now nbody is really fast orig: 1m25, now: 6s (one of the shootout benches) cool How much effort is being spent on performance work vs feature work right now? performance 0.5% ... * obra worries a bit about optimizing before we've got a fully specced parrot. that _always_ bites you. heh. ok. if we're 99+% in featureland, we're in good shape I was just optimizing the PIR code a bit (prefetching array access and such) cool. anyone got anything else? If not, well, I'll see everybody next week, when I'm back home Nicholas: do you have some comments on PMC layout? Most importantly I'd like it figure out what it needs to be, and attempt to stay that way chasing churn is no fun, as it would be work being repeated. apart from that, I know that Dan had always said that variable sized bodies were a problem with Perl 5 and threads, but I never managed to understand his explaination of why. Hence I don't know how relevant it is he said variabled sized PMCs - which I'm not proposing Ah OK. I confused that with variable sized SV bodies Other than that, I don't mind, but if I am my sucessor, then I'd be wanting a stable target to shoot at so the proposal to change the layout comes at a bad time, but, heck, that's how life seems to work PMC layout changes can't be defered to later, when we start optimizing and should have be done (imho) much earlier k * obra shoos further discussion to #parrot % particle has left #parrotsketch % allison has left allison!~allison@ppp-71-139-1-208.dsl.snfc21.pacbell.net % chromatic has left #parrotsketch % leo has left #parrotsketch % Nicholas has left #parrotsketch % mdiep_ has joined #parrotsketch % mdiep_ has left mdiep_!~matt@bursley-216-65.reshall.umich.edu % mdiep has left mdiep!~matt@bursley-216-65.reshall.umich.edu