% particle has joined #parrotsketch % particle_ has joined #parrotsketch % particle has left particle!~particle@c-24-19-12-148.hsd1.wa.comcast.net % particle_ is now known as particle % Steve_p has joined #parrotsketch % smash has joined #parrotsketch % pmichaud has joined #parrotsketch % kjs has joined #parrotsketch % Coke has joined #parrotsketch % alek has joined #parrotsketch % jonathan has joined #parrotsketch % allison has joined #parrotsketch % bernhard has joined #parrotsketch % chromatic has joined #parrotsketch % dickdawg has joined #parrotsketch % offby1 has joined #parrotsketch aha % B2Gills has joined #parrotsketch "shhh" Morning, everyone. Here's a description for people that don't normally attend, along with today's agenda: - moderated by the parrot project manager. - if you're not normally a speaker, ping moderator out of band if you'd like to raise something during the meeting. - Part 1 - reports from core committers. - Part 2 - Q&A on reports... - Part 3 - agenda items/disucssion - branching, repository, etc. See: Please read up on the URL there before we get to that part of the meeting. http://rakudo.org/parrot/index.cgi?parallel_development_requirements for some preliminary discussion. % jisom has joined #parrotsketch Looks like most people are here already. Let's let jonathan report first, I know he has time constraints... OK Last week... * I wasn't at ParrotSketch 'cus I was at UKUUG conference * Gave two Perl 6 talks, Parrot got several slides in one of them * Feedback was very good - a lot of people now think Perl 6 will actually happen, others quite excited about what it has to offer * Much of my time went preparing for this, but I did little bits here and there in Parrot This week... * Wrote documentation for PCCMETHODs, PCCINVOKE, etc. * After discussion with Allison, I wrote a section in the PDD on how to compose roles and deal with conflicts; it's marked conjectural * Then implemented it * Parrot composed it's first role on Saturday! * Detail: we can now compose methods from roles into a class, using exclusion and aliasing to resolve conflicts; easily supports what Perl 6 needs, but has power beyond that for other languages * Still gotta deal with roles made up of other roles... * Plus composing attributes, need to think on those more and discuss with Allison. * Did other ammends to the PDD, trying to keep it in sync with latest discussions so @other know what is happening * Plus other bits on the implementation; s/MetaClass/Class/, kill MetaAttribute in favour of a Hash * Hung out on #parrot a bit, helped tewk++ with Parrot_PCCINVOKE by finding ways to break it. ;-) * Started implementing C3 MRO computation for new object model - it just uses external interface so it will work when @other implement their own HLL classes etc. in theory - changes needed on this area though * Wrote C3 tests; nothing works yet due to Parrot_PCCINVOKE bug (though it's now possibly fixed) Next week... * More on roles - want to get roles of roles done, and try and understand attribute composition better. Need input from Allison on all of this stuff - am I going in the right direction and so on. * Change NameSpace PMC so we can attach a class or role to it, then get new to play nicely with this -> old and new object systems can co-exist * More as time allows. Time is allowing pretty nicely these days. .end it's so nice to see that Parrot finally has a good role model. (rim shot) * allison groans :) pmichaud: I'm somewhat interesting in hacking on languages/perl6/ to try and get some of its OO stuff compiling in the not too distant future. jonathan: coooool % jisom_ has joined #parrotsketch I'm very interested in that as well -- part of me was waiting to see how the object/role model would shake out before going too far down that path but I'm feeling very confident about it now, and will happily turn some of the details over to you :-) :-) it should not be terribly difficult, at any rate % jisom has left jisom!~jisom@74-134-230-123.dhcp.insightbb.com (and if it is, well, you seem to be the correct person to handle it anyway :-) . o O(did we lose our moderator?) yes, sorry. ok. pm and allison next. er, wait. any questions for J? questions after all reports (pm and allison go after that request times out. =-) (J has to leave early, so his questions now) ah, right I have no questions, other than to say jonathan++ for continued outstanding work, and I'm glad he's finding tuits ditto k. next. I guess that's me. :-) Unfortunately my report is short again due to non-parrot items eating into productive coding time I expect that to change relatively soon In the meantime, over the weekend $Larry came up with some core changes to S05, especially in handling punctuation as literals I highly agree with his changes, but it also means updating quite a few grammars to accommodate the changes I plan to do this over the next day or two. Then I'll be back on perl6, and expect to be able to do quite a bit of perl6 stuff this weekend EOR (following allison: chromatic, particle, smash, tewk) - Catching up on mailing list design questions (still have more to answer). - Integrating a great set of questions and comments from Jerry and Jonathan into Objects PDD. (a good bit of my week was wiped out being sick, but I'm catching up today) EOR I've been applying patches from Steve Peters and Andy Doughterty. I read the GC (smallobject). Yow. I've nearly finished a test harness based TAP::Parser that can report TODO tests. That's it. ~ began an Exporter PMC implementation. stay tuned for the ending.... ~ jotted down some requirements for scm, talked about them in #parrot earlier today ~ keeping my eye on commits and #parrot, but not committing much lately .end "no report" tewk: ping 14:03 Fixed memleak in PCC* due to inproper use of constant pmcs. 14:03 Implemented Parrot_PCCINVOKE allowing PCCINVOKE usage outside of pmcs. Fixed a bug where the invocant wasn't passed in-band. 14:03 Implemented support for passing sub pmcs instead of method names to PCCINVOKE, not checked in yet. Anyone else have a report? Oh, sure I am just trying to grease wheels. go. =-) I've started out on looking into cflags and compilier twiddling. ... anything else? I see some of your patches to RT have been applied by c. Currently cflags are set based on the Perl running Configure Intel C++ is my first target, since its probably the most used (and available) of the bunch. on a related note, kid51 has started refactoring the configure subsystem (note to folks reporting: remember to type up your report ahead of time and then paste it in) you'll find it in the 'reconfigure' branch I'll take a look. coverage testing of configure should help your porting efforts Steve_p: anything else? I'm also working on some C code cleanup in advance of some compiler compatibility issues. That's it for me leo_, mdiep, Nicholas, report? bernhard? Added 'Plumhead partridge' to unified languages testing. Some other little tweaks to Plumhead .END_REPORT Ok. moving on to a hopefully brief Q&A: I know avar has a question. Feel free to chime in, anyone... let's try to keep it to 5m or so, and then we can discuss the URL I sent out at the beginning of the meeting... I was wondering if the Parrot::Embed wrapper someone has been working on lately was enough to wrap all the stuff PGE needs, I'm interested in writing a re::engine::PGE (along with other re::engine stuff I have on CPAN) for perl 5.10 that would wrap match objects and such what's the url? http://rakudo.org/parrot/index.cgi?parallel_development_requirements avar, I don't know what Perl 5 needs to call into PGE, but if the entrance point to PGE is a Parrot Sub PMC, P::E can handle that. chromatic: you're probably the best person to answer avar's q there. (note to self. scroll down.) and yes, the entrance point to PGE is a Parrot Sub PMC :-) excellent. I know C has two questions... c? Barring any problems with calling multis from C, it should just work. or, it _can_ be one fairly easily (depends on what version of compiler interface we use) pmichaud, are the grammar changes CAGE-able? chromatic: yes Is configure going to be implemented in miniparrot eventually? essentially we turn things like regex foo { - } into regex foo { '-' } chromatic: thanks:) quotation marks are meta, along with all other punctuation tewk: that is the plan, SFAIK. I think allison has confirmed this recently. pmichaud, seems like we could get #parrot to handle this then. tewk: i expect we will have a miniparrot, and build tools built using miniparrot. but building miniparrot will require non-parrot-based tools, like perl/make chromatic: yes, I don't think it will take long, but it does mean some things will break at the point where I convert PGE to the new syntax Steve_p, is the unportable calloc of 0-bytes an issue? tewk: yes, and particle: yes, we will at least need make (or variant) and gcc (or variant) if we can get some of the tools ported to pir using pge, we might be able to see how many external resources we need to build a complete parrot Crow is a small pir templating engine pmichaud: I once asked you how difficult it would be to implement variant syntaxes for PGE, and I think you said not difficult. is that still true? allison, does that mean we can't write a portable c compiler in pir? :) allison: yes, still true jisom_, we need better JIT for that. jisom: :) allison: we still just need a demo for how to do that I don't know if it is relevant, but if the configure people knew configure would eventually be in miniparrot that may shape how they refactor and design configure during the short term. pmichaud: you mean a syntax to target? not necessarily, not running c on parrot, but a c compiler written in parrot, for native essentially one creates an alternate parser for the new syntax allison: no, just a demo of how to create the parser for an alternate syntax allison: we had also discussed being able to derive from the existing parsers and implement changes... but I still haven't had a chance to do that refactor yet pmichaud: ah, I see, yes allison: however, if you're suggesting that we just implement the new S05 syntax as an alternate variant -- that's an excellent idea allison: and yes, I can do that such that existing grammars won't break excellent! that makes a lot more sense of course, still need a way to specify which grammar variant you're using we may want to clearly name the one that tracks S05 as "Perl 6" particle: it'll just be a different compreg value while the one we shape to our own desires is "Parrot" grammar syntax, or some such well, personally I'm in favor of keeping the Parrot grammar syntax and perl grammar syntaxes nearly the same less confusion that way I agree with pmichaud. if it really is that easy to have a separate syntax, I don't see that it's critical always make the perl 6 syntax available I'm thinking of it from a cognitive perspective, not an implementation one :-) maintainability. but python and ruby compiler writers shouldn't have to track the latest syntax changes in Perl 6 % smash has left #parrotsketch But sure, if there's a compelling reason. correct, however, in this particulare case the change to the perl 6 syntax will actually bring it closer in line to the python grammar :-) theoretically perl6 will stabalize at some point. chromatic, it may be. I double check Perl 5 handling of it. I don't know what would happen with ruby coke, it will, but not in the near future True. let's try the fork Ruby compiler writers can write compilers in Ruby anything else before we move on to the branching discussion? just for a couple of months I haven't looked at the pge code too much, but how hard is it to create a new regex syntax to use pge? i.e. add grep regex, or vim regex....etc.. (else) - ah. kjs has something. jisom: there's a glob front end, that may give you ideas jisom_: look at the PGE/P5Regex and PGE/P6Regex files in compilers/pge, as well as Util.pir in .../library/PGE/ s/Util.pir/Glob.pir/ # sorry pmichaud just said there was a pending refactor to make that easier, but it's not done/spec'd. alternate backends are also interesting:) allison: I'm okay with the fork, then. But we need a way to distinguish the current P6Regex from the new one I'm about to create, then, and to decide how we want to name these things that can be hashed out outside of this meeting. kjs? I'd say P6Regex should be the one that tracks P6 hi, yes, I was wondering if anybody's had any time to look at pirc kjs: I did Rename P6Regex to Perl6Regex, in order to make things clearer ? bernhard: good idea Allison: I did a lot of updates recently, fixed many tiny bugs, so you might have run into some. what did you think? ah, I didn't look at the latest yet, I'll look at after the meeting (I'll be around on #parrot the rest of the day) (sounds you ran into some bugs then :-) ok, let me hear what you think of it, if it's of any use etc. please :) kjs: thanks for working on it it's my pleasure kjs: we need to push on the IMCC problem from every direction to get closer to the right solution Ok. any more generic q/a? (and next time I may move that to the end of the meeting after the specific topics. =-) go ahead with the branching discussion ok. This is basically a followup to discussions that have occurred on #parrot and pp - what are our expectations about trunk in terms of stability? how can we use branching and tools to support these expectations? the outline of the various topics is on the wiki. (and I have a meeting in 8 minutes. =-) ok, let's continue the conversation on the list, then Have a bugfix branch for every release ? That's certainly a possibility, b. Gives some freedom on trunk i'd like to allow non-tpf controlled repositories Branches suck though. it'd make life easier for hll developers, for one I would need you to specify the ways in which they suck. =-) Merging between branches sucks. particle: we already have non-tpf repositories for languages Really sucks. chromatic: thank you. parallel development sucks, just like multiple inheritance. Pulling code from experimental branches into a stable branch is a lot of work. but we need it. It's a lot of not-fun work. I think that svk or some other "sits in front of svn" method of keeping track of thigns would work. especially if those svk repos were public. It doesn't work very well in Perl 5, and I fear that it won't work very well anywhere else. we need an svn-only solution then it's easy to keep things in sync. coke: I've had terrible trouble with bugs in svk messing up my repository, I've gone back to svn because it's reliable. allison: what non-tpf language repos? particle: I disagree. We need something that does svn in the back end, but I don't think we have to have the LCD be the solution everyone uses. It works OK if everyone agrees that one ( or a very few) access the maintanence branch particle: they're listed in the LANGUAGES file How many branches are we talking about 1,2 or 10 ? Steve_p, I think Nicholas might disagree that it works okay. alrightee. General plan: update the wiki page with your notes. Someone (probably me) will start a thread on p2p. Chromatic will herd you for the remainder of this meeting. =-) any discussion that continues here, I or someone else will capture and add to the wiki. thanks, Coke! my proposed solution would support infinite branches, infinite repositories. the main repository would have (at least) an integration branch, and a stable branch Oh yes, and unfortunately, scm tools tend to mess up branching. The human factor of branching comes int too. (chromatic's comments)++ Roger. Hope everyone is having fun. (and let me know if you're not!) the most important question is "what problem are we solving?" once we have that, it'll make it much easier to pick the right solution we're aiming to solve multiple problems ~ provide a stable branch It sounds like the problem is "Some changes are too large to keep stable in small patches." Lessen fear of breaking things parallel work on multiple subsystems may result in diverging code. this is the hard part to manage out of curiosity (because I don't know), how do other large systems like the Linux kernel handle it? then we need a better test suite! :) pmichaud, luck pmichaud, the Linux kernel has lots of public trees, from which various maintainers pull patchsets when they want to include them. It's highly distributed, so there's no single stable trunk. chromatic: is that a function of maturity, then? More a function of chaos. heh okay :-) answers my question! pmichaud: linux kernel folk use 'git', a tool linus wrote it's not portable enough for us, yet They use git now, yes, but they used to mail patches around and there was no central SCM besides Linus' inbox. particle: I meant more at a meta-level, in terms of managing multiple repositories and dealing with parallel work on multiple subsystems yes, it's a distributed vcs solution. we're used to, and i think aiming for, a central solution *centralized I didn't follow some of the earlier discussions, but what are some examples of specific obstacles we're encountering with the present system? presently, trunk breaks. far too often. isn't that the historical purpose of trunk/head, though? isn't that a matter of developer discipline? And trunk gets fixed My answers are no, yes, and hopefully. okay, I see the issue now we have the ability to provide a stable codeline, so we always have a release candidate. so, trunk is where stable things go, and developers should be working in branches why don't we offer it? it takes a little know-how, some discipline, and programming. not necessarially I meant as a general approach pmichaud: or trunk is where work happens and branches are for release candidates Because branches have the tendency to grow and grow and diverge further from trunk, which makes them much more difficult to merge. i propose we have branches for shared/solo subsystem coding a branch for integration and a branch for stable code. trunk is just another branch. perhaps we rename 'trunk' to 'integration', or define it that way. particle: but we have the same problem then of branches diverging rapidly, unless release branches are short-lived or, maybe we rename/identify it as 'stable' allison: as long as the development branches are kept up-to-date wrt the stable branch, they won't diverge well, if we treat the trunk branch as being the stable one, then there's a built-in incentive to get things checked into the trunk because without that new features don't make it into the release particle, that's never been my experience. s/checked in/merged in/ particle: it depends on someone actively watching and merging changes, which is pretty much a full-time job for a volunteer (and not a particularly fun job) it's a job we all do already, in a way As soon as someone checks in a change that's not appropriate for whatever point you want to merge to, it blocks that branch forever. aye, but we'd be doing ti twice crap, somebody changed the code i was working on, i have conflickts i need to merge them in my working copy chromatic, you can peel off your changes since the last baseline (synchronization point between branches), apply the changes from 'stable', and reapply your diffs ouch yes, it's merging. it's painful. but you have to do it at some point anyway ouch++ Oh I agree that it's possible, but in my experience the longer a branch lives on, the more difficult this is and the more likely it is that there's an imcompatible change you just can't work around. the question is whether the sacrifice is worth the gain i don't get it. you MUST do this before your code is committed to trunk now. the pain is no different if you wish to synchronize more frequently, you may. merge and integrate changes? yeah, but I do it on a daily basis The difference is that if you're always working off of trunk, you have much less possibility to diverge strongly. also, when working off trunk you notice divergences earlier so synch daily, and it's still no different s/divergences/conflicts/ but if we're keeping the two branches in sync daily, then what's the point of having branches? okay, let's think of trunk as an integration branch, instead of a stable one. I svnup whenever I see a check-in, 5-10 times a day. commits are only merged with the stable branch after they've been smoked It takes the same kind of developer discipline to manage a long-lived branch as it does to keep the trunk stable, and managing branches adds administrative overhead and latency. either they diverge, in which case it leads to painful merges down the road, or they stay the same and they're irrelevant. is there a 3rd option chromatic: point The smoke/integrate option is interesting. Is this automatable? of course it can be automated :) but, we need better smoke tools and what's the process when smokes fail? When smokes fail, Paul Cochrane fixes a bunch of whitespace issues. pugs has a smokebot which notifys #pugs Here's a little analagy: if a branch is a software development transaction, trunk is like forced AUTOCOMMIT particle: I meant human process guilty party get an email with the build report, and he checks in a fix. mugwump: eh? failures must be dealt with. a revision can't be considered a release candidate until it smokes. tewk: and if guilty party is on vacation? we can have smoke results for each platform, and release candidates for each platform when the revisions converge across all platforms, we have a true release candidate someone fixes it or reverts it. smoke failures should be RT tix no different than parrotbug particle: I see the appeal, but I'm not yet convinced on the cost/benefit side so with branch based development, you snapshot the current state, work on it, and eventually "commit" the transaction (merge) Before we discuss branches, perhaps we need reliable automated smokes. with trunk based development, every change you make gets "committed", there are no long-running transactions chromatic: the smokes themselves aren't unreliable, but the reports aren't great that is, if we make it significantly harder to work on parrot, it will reduce the number of new contributors we get, and we're not at a good point to be turning people away because they don't understand our archane commit system firstly, smoke reports are slow to render, secondly, they're not easy to compare to others Lets get a rockin smoke system with IM and email notification to guilty parties working first, then revisit the branching issue if it is still relevant. Do we have automated smokes though? chromatic: yes, we do Okay. Good. I didn't realize that we did. I'm totally on board for improving our smoke system ^conner_ and others have donated time and machines for that. we can use more, of course. Steve_p will be helping with that effort, i suspect :) there has been one or more folks on #parrot and #perl6 talking about better smoke tools *writing better ... So what we are really talking about here is a continious integration server on a bunch of platforms, % stephane has joined #parrotsketch It sounds like we need to know, first off, how often trunk breaks and then see how we can keep it stable. tewk: yeah, which may have nothing to do with branching, when we get down to it It has to be up and running all the time to be useful. I'd be interested to talk to the mozilla group about their build process I don't think trunk breaks across all platforms very often. A check-in quite often doesn't work on say WIN32 or with FreeBSD's make i have tests failing on win32 now. It's much easier to fix things if we can relate them to one specific checkin. patrick committed a TODO just before his release ,which caused an unexpected success on my platform we get bug reports of "this test is broken" all the time Can we smoke for every checkin and see the diffs? bernhard: that is what a continous build server does, plus it emails out reports and auto creates rt tickets we can do every checkin, or every