Steffen , I tested (briefly) the slave-driver branch. It failed some tests but still appeared to work w/ the swarm service provided the plugin was not enabled at startup - probably just an ordering issue between pluginmanager and taskmanager. The effect was a SEGV when the slave thread tried to ->post_event to it's service event.
Of the plugins and other code in padre/trunk/ only swarm is using Padre::Service and the swarm audience is virtually non-existent at present. Perhaps you and I can workshop the idea of Service, certainly the original implementation is brutal and the mechanism for communicating with a service not well defined. On Thu, Jan 28, 2010 at 9:08 PM, Steffen Mueller <[email protected]> wrote: > Hi Pete, > > Peter Lavender wrote: >>> There's this branch in branches/Padre-slave-driver that has the memory >>> consumption/threading optimizations that Adam blogged about. It works >>> well on my computer (linux), but it's a pretty devious and significant >>> change. To the best of my knowledge, it's also only been tested by me >>> despite my multiple suggestions on IRC that others should give it a >>> shot. Now, I guess our development model or our developers mindset is >>> such that it won't get a lot of testing time *unless* I just dump it >>> into the trunk and let Murphy figure it out. I'm certain there'll be >>> breakage. > >> Right.. it's a bit like that.. I had a patch waiting for ages for >> someone to check out in the end I added it to trunk. It was very simple >> really, nothing like what you're doing, but it's the same end result.. >> it's not noticed until it hits trunk and then a release. > > It's not really surprising either. We're a volunteer group. I think all > of us are in it for our own enjoyment. Testing branches is no fun. > >>> This suggests two possible routes: >>> a) Make a release now, then merge the branch into trunk. Buys us time to >>> fix things. >>> b) Merge the branch into trunk and delay the release until we're certain >>> we've fixed the most serious issues. Could make Padre 0.56 an even more >>> significant release (cf. Adam's blog entry). >>> >>> I'd love to have this in the upcoming (hyped) 0.56 release. But it's >>> quite risky and it might be better to stick with a). What do you guys think? >> >> Ok, I'll do a switch here and try it out myself. > > Thanks! The branch may be behind trunk by a few revisions (check svn > info if in doubt). > >> I'm quite open on this matter myself. If we want to wait that's fine. >> >> I'm quite a fan of least changes at once to make sure we can at least >> see what's going on at the time a major change comes in. > > Given that we're usually using the frequent Padre releases to whittle > out bugs ("the problem manifested between 0.38 and 0.39." vs. the more > usual "bisection tells me the problem manifested with change 10000") and > that's probably a difficult to break habit (cf. comment about volunteer > groups) it's probably better to push out a 0.56 release without my > dubious changes. > >> In the recent past many of the 'big' changes we've seen to Padre has >> come from Adam where incremental changes aren't overly an issue and I >> know I've done releases with Adam's changes only partially applied, with >> major gains seen up to 2 releases later. >> >> Given what I understand of the changes from Adams Blog, I will say that >> making it for 0.56 make sense, but it means we need the time to do it. > > Yes. If we were to merge my branch to trunk, we'd have to delay 0.56 for > sure. Anything else would be unfair to the beta testers^W^W users. > >> The only issue I see is that there are already a large number of changes >> listed already, and Sebastian's concern with problems he's seeing means >> merging now just to squeeze in before 0.56 might make sorting out any >> issues harder than it needs to be. > > Agreed. > >> While it might hurt a little bit in terms of the "marketing" done for >> 0.56, I think we could make 0.56 with what's already done, with the >> merge to trunk after the release being your changes - and two weeks to >> get it ironed out, keeping major changes out until your changes are >> stabilised. > > Adam's changes have impacted the apparent performance *a lot*. When I > tried them for the first time, I really was amazed. Just as he's written > in his blog, 0.56 is going to be *the* release to try out and to upgrade > to. My changes are quite different if still important. They wouldn't > really be visible to the users (modulo Scalars Leaked) unless they're > very memory bottlenecked. > >> This gives us a fairly clear and visible progression with major changes >> to Padre. > > Agreed! > > Best regards, > Steffen > > PS: I'd particularly appreciate testing with Padre::Service related > functionality. Not sure where that's used. For sure in ::Plugin::Swarm, > though. > _______________________________________________ > Padre-dev mailing list > [email protected] > http://mail.perlide.org/mailman/listinfo/padre-dev > _______________________________________________ Padre-dev mailing list [email protected] http://mail.perlide.org/mailman/listinfo/padre-dev
