On Tue, 3 Jul 2018, Tobias Pape wrote:
On 02.07.2018, at 15:26, Levente Uzonyi leves@caesar.elte.hu wrote:
+1, but the configuration has to be updated first to load the correct versions.
ok.. can you elaborate?
If you evaluate the proposed snippet in a Trunk image, you'll find that the loaded Refactoring Engine code sends deprecated methods and there is no support for the new class formats introduced by Spur.
Levente
Levente
On Mon, 2 Jul 2018, H. Hirzel wrote:
Proposal
Take the result of this discussion
Installer ensureRecentMetacello. Metacello new configuration: 'RefactoringTools'; load.
and put it into the Squeak help file subject 'Extending the system' thus replacing the Omnibrowser script.
--Hannes
On 5/11/18, Tobias Pape Das.Linux@gmx.de wrote:
On 10.05.2018, at 18:41, Chris Muller asqueaker@gmail.com wrote:
... and... how to get Metacello please?
Installer ensureRecentMetacello
On Thu, May 10, 2018 at 6:29 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi
> On 10.05.2018, at 09:19, H. Hirzel hannes.hirzel@gmail.com wrote: > > Hello > > Following up on this thread. > > Where do I get the latest version of the RefactoringTools updated for > the most recent trunk version? > > There are some SqueakMap entries but they are outdated. > > This > > http://wiki.squeak.org/squeak/831 > > seems to give recent information as well.
This is the most recent info.
I short, if you have Metacello,
Metacello new configuration: 'RefactoringTools'; load.
That's about it. Marcel and Me will keep the Config up to date. We have not made any SqueakMap entries.
Best regards -Tobias
> > --Hannes > > On 11/3/17, Eliot Miranda eliot.miranda@gmail.com wrote: >> Hi Jacob, >> >> On Thu, Nov 2, 2017 at 12:30 PM, Jakob Reschke >> forums.jakob@resfarm.de >> wrote: >> >>> Am 02.11.2017 7:11 nachm. schrieb "Eliot Miranda" >>> <eliot.miranda@gmail.com >>>> : >>> >>> >>> On Wed, Nov 1, 2017 at 3:15 AM, Marcel Taeumel marcel.taeumel@hpi.de >>> wrote: >>> >>>> >>>> Next step would be to build a preview tool that supports add/remove >>>> steps >>>> of a refactoring. For example, a "rename message" might tackle too >>>> much >>>> methods. That is, there is no scoping at the moment. >>>> >>> >>> OK. We likely definitely want to scope by package(s), right? >>> >>> >>> >>> Unless you wanted to say "packages, not classes or categories" I do >>> not >>> think so. Mostly because projects/software is often divided into -Core >>> and >>> -Tests packages. Or think of -Examples, -Plugins, -Extensions... So I >>> fear >>> explicit input of the scope (a set of packages) will be required. >>> >> >> I think offering two scopes is adequate: >> a) the entire system >> b) classes and extension methods whose package name matches either a >> prefix >> or a pattern >> >> >> >>> Using package dependencies (like in ENVY) would be nice, but they are >>> unmaintained in Monticello (often only supplied with Metacello). >>> >>> Oh, and my Environments bell is ringing again... ;-) >>> >> >> Remember that one can always generate more narrowly scoped refactoring >> by >> 1. performing the refactoring on some larger scope (e.g. the entire >> system) >> 2. quitting the system >> 3. using the changes crash recovery tool to select the desired >> refactorings >> or by using method versions to revert any unwanted >> >> So having a simple generally useful scope such as package or package >> prefix >> would work for me. >> >> _,,,^..^,,,_ >> best, Eliot >> >