Has this been fixed in the meantime so that the Omnibrowser load script may be replaced with the Refactoring Engine load script in the workspace which opens after choosing 'Help' / 'Extending the system'?
--Hannes
On 7/4/18, Levente Uzonyi leves@caesar.elte.hu wrote:
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 >>> >> > >