% particle has joined #parrotsketch % PerlJam has left PerlJam!duff@feather.perl6.nl % leo has left leo!lt@feather.perl6.nl % kjs has joined #parrotsketch % pmichaud has joined #parrotsketch I may be late or miss #parrotsketch today -- have to run some other errands my report is that I've been working on getting perl6 and other parrot compiler tools to work with the new pdd15 implementation I expect to have a "Protoobject" class and/or role checked in later today % PerlJam has joined #parrotsketch % allison has joined #parrotsketch % mdiep has joined #parrotsketch % chromatic has joined #parrotsketch % jhorwitz has joined #parrotsketch % smash has joined #parrotsketch % barney has joined #parrotsketch Hello everyone. * particle waves hi hello hallo Let's go in alphabetical order, so as not to confuse everyone who types while allison is pasting. - Merged the pdd15oo branch back into trunk. - Cleaned up a few remaining issues with the new object model. - Started deleting old code that is no longer used by any systems. (Most notably, the ParrotClass and ParrotObject PMCs.) - Have nearly completed a review of the PIR PDD. EOR barney? Continued with 'languages/scheme' .eor I checked in the harsh GC runcore, which is great for finding and diagnosing GC problems. Consequently I found several and fixed most of them. I think there are two or three more in core Parrot. i should run that. I poked at Lua and Tcl but they weren't quite PDD 15 ready yet, so I put that on hold. It may be that they get fixed as a consequence of the others. I also added a couple of optimizations to make PDD 15 objects and classes nearly as fast as the previous version. CONST_STRING() in the right place can be a big win. Per Coke's request, I'm writing a short guide on fixing memory problems with the gcdebug runcore. jhorwitz? chromatic++ # for all this desperately-needed GC work was going to submit a long overdue past-pm patch for quoted types, but started seeing perl6 test failures. working with particle on that. i'd like to see everything pass before generating the final patch began divorcing HLLs from mod_parrot -- i.e. distribute mod_perl6 separately from mod_parrot. looks very doable. EOR kjs? just lurking, thanks mdiep? - Actually did some Parrot work (locally) this week - May try to push some of that refactoring (of Parrot_readbc) back to trunk today - Building a mental picture of what things the Packfile PMCs should handle - Question: anyone know what's meant by RT#46153 and RT#46155? The descriptions are rather sparse ^D particle? ~ added -R, --runcore parrot options to select runcore TODO: decide on migration/deprecation strategy for old options ~ improved parallel make performance by modifying compile order ~ discussed a protoobject implementation i have a protounderstanding of what to do ~ successfully avoided a discussion on coding style *phew* ~ haven't looked at the new pdds yet ~ patches and cleanups continued .end pmichaud? enoperl6pumpking Does someone have his report? (11:04:24) pmichaud: my report is that I've been working on getting perl6 and other parrot compiler tools to work with the new pdd15 implementation (11:04:46) pmichaud: I expect to have a "Protoobject" class and/or role checked in later today smash? no report smash: pdd19? allison: not finished yet Let's move on to questions. mdiep had one -- "What's up with these tickets?" (when y'all are done I have something to talk about) mdiep: some of those TODOs are quite old and may not even be relevant to the current state of the code allison: that's sort of my concern. I'm hoping someone can shed some light on if they're relevant and how. mdiep: if they turn out not to be relevant, feel free to delete them from the code and reject the tickets cleaning up irrelevant TODOs is also progress how about directed efforts on new code that has unticketed TODOs first prototype systems with TODOs is no surprise final implementation code with TODOs is bad Any other questions? * particle shakes his fist at PerlJam to speak up oh! Should we clean up branches, maybe move old branches to https://svn.perl.org/parrot/branches_old ? I'm planning to write an article for TPR on the state of parrot. barney: let's just delete the old branches, they're always there in the history unless someone already has something like that in the work. (delete branches)++ PerlJam: sounds great in any case, I'll be buggin people for help in figuring out exactly what the state of parrot actually *is* :) perljam: when's the deadline? it'd be nice if it's *after* 0.5 goes out make sure to ask if there are branches that people want kept around first co https://svn.perl.org/parrot/branches could give all active branches particle: ostensibly it's Nov 1, but bdf said that's more of a guideline than a deadline. oh! i forgot something else i did today. PerlJam: if the print date is after mid-november, maybe we can fudge a little particle: I'll ask him how much leeway I have in that regard :) so, tired of waiting for anybody else to do it, i created a wiki page to help us decide on release numbers from now until 1.0. http://www.perlfoundation.org/parrot/index.cgi?release_planning please review, make changes, discuss, etc * PerlJam wonders where to put the "optimize for speed" release that's probably 0.999 or 1.5 I profile every couple of weeks and try to improve things. I really think parrot should be as fast as possible for the 1.0 release. That's when it's "real" for all of the naysayers and you know they're going to nitpick everythign. my point was mainly that speed is under consideration all the time, not that we shouldn't think about it at all Hmm. Maybe make JIT the default runcore, where possible. JIT isn't necessarily the fastest. It depends on the workload. and delaying the 1.0 release to spend 3 months optimizing will probably hurt us more than simply acknowledging that we haven't focused on optimization yet, but will in a post 1.0 release perhaps if there were a public record of areas that have room for improvement, it could give people a scoreboard to shoot for. (release early, release often) Remember, this is Free Software. allison: oh yes. I agree when put in that light. That means the entire world is free to whinge and cry about whatever they think we should care about, but don't. (I don't want to delay the 1.0 release at all if possible :) we have wiki pages may your tuits be round :) particle: your version numbers reflect what I expect from the milestones chromatic: don't need to be so radical smash: he's not radical; just tired of people who aren't participating whining about what's not done. i think it's funny that after seven years, allison thinks a three month delay will hurt us :) parrot isn't 7 years old ;) particle: time is relative :) some might say parrot's not even born yet :) My only concern is if there are potential optimizations that might break backwards compatibility. particle: with such a long gestation period, it had better live a really long time :) I don't know how to predict those, however. chromatic: we'll have a deprecation cycle after 1.0, it'll just be longer chromatic: a good testing environment will help with regression tests chromatic: save those for the next major release then. Would an optimization be a show-stopper? probably 6 months or 1 year okay, i'll make sure coke has a look at the wiki page and he can decide what to do with the info All I mean is that optimization closer to an official release may be easier in some ways and more difficult in others. Getting rid of ugly and dead code right now will help more than anything else. particle: and also, I hope the minor subsystem implementation won't wait until after the 0.50 release, but will go on between the major milestones allison: yep, agreed. Are there other questions? Is anyone blocking on anything technical or social that we can resolve? (if i may:) will there be 'optimize for space' (in particular pbc size) before (or after) 1.0? (32 or 64 bit register numbers, e.g.) chromatic: yes, it's not an "XOR" proposition, it's an "AND" proposition, optimization both now and later spinclad: if that proves to be important, yes, need some real benchmarks and performance use cases, though spinclad: so may be delayed until we have realworld uses IS anyone using parrot in "the real world"? Dan :) PerlJam: a few, but I don't expect real world uses to be large before the 1.0 release Parrots are not flying in tornados once we have a working compiler toolkit, i have a feeling i'll be using perl6/parrot at work particle: I'm hoping for the right project to come along at work so that I can say, "I know how to do that with parrot!" :) But chances seems slim right now :( It sounds like we're through here. Shall we adjourn? anyway ... I'll see you guys next week with a rough draft of my article probably. yes. thanks for shepherding, c! % jhorwitz has left #parrotsketch % chromatic has left #parrotsketch % barney has left barney!~bernhard@p549A1D3A.dip0.t-ipconnect.de % kjs has left kjs!~IceChat7@ip565fd420.direct-adsl.nl % leo has joined #parrotsketch % allison has left allison!~chatzilla@nat-147-99.oreilly.com % allison has joined #parrotsketch % smash has left #parrotsketch % particl1 has joined #parrotsketch % particle has left particle!~particle@c-24-22-165-145.hsd1.wa.comcast.net % particl1 is now known as particle