Task 2.0 in a target for API change . I can only get a subset of what it claims to do working.
On Sun, Aug 14, 2011 at 10:25 AM, Peter Lavender <pla...@internode.on.net>wrote: > ** > > My 2 Ct.: Test and fix as much as possible to release 0.90 as soon as > possible (5days sounds good), then start breaking (and fixing) the APIs until > we're stable for 0.92. > > > > > Fine by me. > > I see a few things have been sorted out, like that tasks test. > > It actually failed for me during the release process I go through here and > reported it in IRC, Adam grabbed it and committed a fix that I tested and it > worked again fine. > > Based on the comments though it did appear to be a problem for some people > and not others... > > However given it's been fixed, and the few other annoying issues with 0.88 > I'm more than happy to get 0.90 out. > > It might be worth checking with Adam to see where he got to his reworking > of the API's. > > I'd like to get 0.90 out there and solid to allow time between the next few > releases should we need to the time stablise after the API changes. > > Peter. > > > > > Gabor Szabo <szab...@gmail.com> schrieb: > > >On Thu, Aug 11, 2011 at 12:05 PM, Adam Kennedy > ><adamkennedybac...@gmail.com> wrote: > >> Greetings all > >> > >> With the 0.88 release looking so stable (notwithstanding Sewi's > >> issues) my thoughts are starting to turn towards what is left to go > >> for 1.00 and what we can do to simplify the job of maintaining > >> compatibility for plugins as long as possible after 1.00. > >> > >> So I'd like to propose a big sweep over the entire codebase, and to > >> break as many API things as possible now rather than later. > >> > >> For example: > >> > >> Padre does not import constants from Wx because there's simply too > >> many, and across hundreds of classes this can add up to 10's of megs > >> of ram just for constants. > >> > >> As a result, we're stuck using the somewhat ugly Wx::wxFOO style > >> constants (which also aren't constants since they are AUTOLOAD > >> hooked). > >> > >> I'd like to move to using a naming scheme similar to wxPython and use > >> Wx::FOO instead. > >> > >> While ultimately we need support from Wx.pm for this different style > >> of constant, in the short term I've implemented a demonstration you > >> can see with > >> > >> use Padre::Wx ':api2'; > >> > >> This will call all 3000 of the constant functions in Wx and capture > >> their values. It then calls constant.pm with all the captured values > >> to create "proper" constants with the shorter naming style. > >> > >> Along similar lines, we have a lot of methods named "on_foo" scattered > >> around the API. > >> > >> I'd like to clean some of these up, so that we only use on_foo_bar for > >> handlers which actually catch events directly (i.e. Are passed > >> Wx::Event objects) rather than the mix of some having it and some not > >> that we have now. > >> > > > >These both seem to be like welcome improvements and I think if we > >provide stable releases of Padre with enough time for transition of the > >from the old API calls to the new calls (in which time both work) then > >it ok to do it now. > > > >Will we be able to release all that and the fixes of 0.88 in the next 5 days? > > > >regards > > Gabor > >_______________________________________________ > >Padre-dev mailing list > >Padre-dev@perlide.org > >http://mail.perlide.org/mailman/listinfo/padre-dev > _______________________________________________ > Padre-dev mailing > listPadre-dev@perlide.orghttp://mail.perlide.org/mailman/listinfo/padre-dev > > > > _______________________________________________ > Padre-dev mailing list > Padre-dev@perlide.org > http://mail.perlide.org/mailman/listinfo/padre-dev > >
_______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
