Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
_,,,^..^,,,_ best, Eliot
I used it in my 3.9 images, which I still have around. Are you looking for just menu structure or actual menu-creation code? We've made so many changes, code might not port more easily than re-writing.
On Tue, Oct 31, 2017 at 6:34 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser.I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
_,,,^..^,,,_ best, Eliot
Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1] http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2] http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
...there is also a Metacello script in "http://www.squeaksource.com/MetacelloRepository" behind "ConfigurationOfRefactoringTools".
Best, Marcel
Am 01.11.2017 11:15:29 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1] http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2] http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
If the refactoring tools are known to work in current Squeak, and if there is active support for the package, then we should have an entry for this on SqueakMap.
Looking at the SqueakMap Package Loader in my trunk image, I see entries for Refactoring Browser for Squeak 3.2 through Squeak 3.8. There is also an entry for Refactoring Engine for Squeak 3.9. These were maintained by Marcus Denker, who is no longer active in Squeak development.
Could someone please volunteer to make an entry for the current tools that are being maintained for Squeak today?
Thanks!
Dave
On Wed, Nov 01, 2017 at 11:15:29AM +0100, Marcel Taeumel wrote:
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1]??http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2]??http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
On 01.11.2017, at 12:26, David T. Lewis lewis@mail.msen.com wrote:
If the refactoring tools are known to work in current Squeak, and if there is active support for the package, then we should have an entry for this on SqueakMap.
Looking at the SqueakMap Package Loader in my trunk image, I see entries for Refactoring Browser for Squeak 3.2 through Squeak 3.8. There is also an entry for Refactoring Engine for Squeak 3.9. These were maintained by Marcus Denker, who is no longer active in Squeak development.
Could someone please volunteer to make an entry for the current tools that are being maintained for Squeak today?
We (at hpi) currently only maintain the Metacello Config...
Thanks!
Dave
On Wed, Nov 01, 2017 at 11:15:29AM +0100, Marcel Taeumel wrote:
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1]??http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2]??http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
A squeakmap entry may contain just an installation script such as the ones at
http://wiki.squeak.org/squeak/831
It is a matter of contacting Marcus Denker and ask him for the rights to add a new version entry to the existing 'Refactoring Engine' entry on SqueakMap.
On 11/1/17, Tobias Pape Das.Linux@gmx.de wrote:
On 01.11.2017, at 12:26, David T. Lewis lewis@mail.msen.com wrote:
If the refactoring tools are known to work in current Squeak, and if there is active support for the package, then we should have an entry for this on SqueakMap.
Looking at the SqueakMap Package Loader in my trunk image, I see entries for Refactoring Browser for Squeak 3.2 through Squeak 3.8. There is also an entry for Refactoring Engine for Squeak 3.9. These were maintained by Marcus Denker, who is no longer active in Squeak development.
Could someone please volunteer to make an entry for the current tools that are being maintained for Squeak today?
We (at hpi) currently only maintain the Metacello Config...
Thanks!
Dave
On Wed, Nov 01, 2017 at 11:15:29AM +0100, Marcel Taeumel wrote:
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1]??http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2]??http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
Hi Eliot, Hi Marcel,
IMO refactoring support is one of those features that belong to trunk. I am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?
Bernhard
Am 01.11.2017 um 11:15 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
<image.png>
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1] http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2] http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de:
Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/RefactoringTools-...
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
On 02-11-2017, at 10:38 AM, Bernhard Pieber bernhard@pieber.com wrote:
Hi Eliot, Hi Marcel,
IMO refactoring support is one of those features that belong to trunk. I am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?
I have a small objection, not specifically to the refactoring stuff but to the effect adding more facilities will have on the more general problem of giant menus and overfilled tables of hotkeys.
Generally our menus are horribly poorly arranged. Some are hierarchical menus, some fake it badly with the “fooble…” entries that open another menu, or sometimes a different UI widget. The code side of menus is even worse with approximately 42 classes involved in making a once-simple menu concept.
So whilst I’d like to see refactoring support included by default in the tools, let’s try to make use of that to refactor our really messy, untidy, badly in need of refactoring, UI framework(s)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you don't pay the exorcist do you get repossessed?
2017-11-02 18:48 GMT+01:00 tim Rowledge tim@rowledge.org:
On 02-11-2017, at 10:38 AM, Bernhard Pieber bernhard@pieber.com wrote:
Hi Eliot, Hi Marcel,
IMO refactoring support is one of those features that belong to trunk. I
am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?
I have a small objection, not specifically to the refactoring stuff but to the effect adding more facilities will have on the more general problem of giant menus and overfilled tables of hotkeys.
Generally our menus are horribly poorly arranged. Some are hierarchical menus, some fake it badly with the “fooble…” entries that open another menu, or sometimes a different UI widget. The code side of menus is even worse with approximately 42 classes involved in making a once-simple menu concept.
So whilst I’d like to see refactoring support included by default in the tools, let’s try to make use of that to refactor our really messy, untidy, badly in need of refactoring, UI framework(s)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you don't pay the exorcist do you get repossessed?
IOW, what we need is a tool for understanding those legacy messy untidy codes which is a preamble to applying any refactoring... Something like a brain, but better than the poor one we have. Precisely because we started to complexify that code once we lost the overall picture of the problem/solution... And we stopped modifying once it was humanely impossible to add a feature without breaking two others. Such code is a sort of local optimum...
2017-11-02 18:56 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2017-11-02 18:48 GMT+01:00 tim Rowledge tim@rowledge.org:
On 02-11-2017, at 10:38 AM, Bernhard Pieber bernhard@pieber.com
wrote:
Hi Eliot, Hi Marcel,
IMO refactoring support is one of those features that belong to trunk.
I am not suggesting that any one of you should do the work. I just want to find out what you and others think about this? Would any one object and if yes, why?
I have a small objection, not specifically to the refactoring stuff but to the effect adding more facilities will have on the more general problem of giant menus and overfilled tables of hotkeys.
Generally our menus are horribly poorly arranged. Some are hierarchical menus, some fake it badly with the “fooble…” entries that open another menu, or sometimes a different UI widget. The code side of menus is even worse with approximately 42 classes involved in making a once-simple menu concept.
So whilst I’d like to see refactoring support included by default in the tools, let’s try to make use of that to refactor our really messy, untidy, badly in need of refactoring, UI framework(s)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you don't pay the exorcist do you get repossessed?
IOW, what we need is a tool for understanding those legacy messy untidy codes which is a preamble to applying any refactoring... Something like a brain, but better than the poor one we have. Precisely because we started to complexify that code once we lost the overall picture of the problem/solution... And we stopped modifying once it was humanely impossible to add a feature without breaking two others. Such code is a sort of local optimum...
I wanted to finish with a return to main subject:
I still think that refactoring tools are helpful well before we reach such critical state.
Precisely because we started to complexify that code once we lost the overall picture of the problem/solution... And we stopped modifying once it was humanely impossible to add a feature without breaking two others. Such code is a sort of local optimum...
:-)) I thoroughly dislike those just trying to make a genetic optimizer less prone to be stuck in them. But then the real world mainly consists of those. SCNR, Herbert
Hi Tobias & Marcel,
On Wed, Nov 1, 2017 at 3:15 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
That's great news. I'll use your code. I think the tools should be in the base image but perhaps we can put the browser integration in the base and have it not show menus until the refactoring code is loaded.
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?
Best, Marcel
[1] http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2] http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I
wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/ RefactoringTools-mt.3.mcz
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
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.
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... ;-)
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
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.
--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
- performing the refactoring on some larger scope (e.g. the entire system)
- quitting the system
- 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
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/831seems 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
- performing the refactoring on some larger scope (e.g. the entire system)
- quitting the system
- 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
... and... how to get Metacello please?
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/831seems 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
- performing the refactoring on some larger scope (e.g. the entire system)
- quitting the system
- 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
The wiki page cited above
RefactoringTools http://wiki.squeak.org/squeak/831
has a link to
Metacello http://wiki.squeak.org/squeak/6157
which has a paragraph. called 'Installation'.
On 5/10/18, Chris Muller asqueaker@gmail.com wrote:
... and... how to get Metacello please?
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/831seems 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
- 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
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
- performing the refactoring on some larger scope (e.g. the entire system)
- quitting the system
- 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
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
- 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
+1, but the configuration has to be updated first to load the correct versions.
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
- 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
Alternative Browser is a good thing. Do not matter OmnniBrowser is not developed any more. If people could have the last version working , maybe some find inspiration and continue. Another old Broser's
StarBrower Tamaris
Edgar @morplenauta
On 02/07/2018, 10:26, "Levente Uzonyi" leves@caesar.elte.hu 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 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?
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 >
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 >> >
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 >>> >> > >
On Thu, 6 Sep 2018, H. Hirzel wrote:
Has this been fixed in the meantime so that the Omnibrowser load
As far as I know, there has been no new Metacello configuration published, so no.
script may be replaced with the Refactoring Engine load script in the workspace which opens after choosing 'Help' / 'Extending the system'?
It should be replaced anyway, since OB will probably not load into the Trunk.
Levente
--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 >>>> >>> >> >> >
Using Eliots screenshot as an example to hang some points on -
That’s a way too long menu. I has hierarchical submenus *and* a ‘more…’ submenu. The refactoring stuff is probably less frequently used than many items below, which is usually a bad idea. The usage of the ellipsis for items like ‘senders of…’ at least indicates there is a further list to come but it confuses with ‘more…’ indicating a submenu.
At the very least I’d want to break this up into a better tree of menus, though it seems to me that some of those options really would be better off not in a menu at all but removed to some other UI element. We have the button list in the Browser that subsumes the sender/implementors stuff and there’s probably more that could be done there. I can’t see why ‘class refs’ is in a method menu at all! Nor indeed the three browse options which are all class list related.
Another interesting UI idea from the past might be useful to consider for the ‘senders of… ‘ type entries; RISC OS menus can include attached dialogues of various types. (In fact even entire application windows can be used but that’s going a bit far in my opinion) Now clearly we could simply add a submenu with the list of selectors used in the method for this particular case and it would be an improvement. Using dialogues (like the ListChoosers we currently open) directly from the menu offers the filtering and multiple input field or multiple lists and hierarchies and buttons capabilities. One might have a dialogue that lists all the selectors used, provides the filtering (yes, I know menus can do basic filtering) and several buttons to choose global or local searching for the implementing methods, limit to this package, check the history database for implementors no longer in the system, whatever. A crucial point would be to make sure the dialogues open and display *fast* even on slower machines.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HCFI: Halt and Catch Fire Immediate
I could easily do without 6 items on that menu, but I need the rest. It's possible others might like those features, though.
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".
On Thu, Nov 2, 2017 at 2:34 PM, tim Rowledge tim@rowledge.org wrote:
Using Eliots screenshot as an example to hang some points on -
That’s a way too long menu. I has hierarchical submenus *and* a ‘more…’ submenu. The refactoring stuff is probably less frequently used than many items below, which is usually a bad idea. The usage of the ellipsis for items like ‘senders of…’ at least indicates there is a further list to come but it confuses with ‘more…’ indicating a submenu.
At the very least I’d want to break this up into a better tree of menus, though it seems to me that some of those options really would be better off not in a menu at all but removed to some other UI element. We have the button list in the Browser that subsumes the sender/implementors stuff and there’s probably more that could be done there. I can’t see why ‘class refs’ is in a method menu at all! Nor indeed the three browse options which are all class list related.
Another interesting UI idea from the past might be useful to consider for the ‘senders of… ‘ type entries; RISC OS menus can include attached dialogues of various types. (In fact even entire application windows can be used but that’s going a bit far in my opinion) Now clearly we could simply add a submenu with the list of selectors used in the method for this particular case and it would be an improvement. Using dialogues (like the ListChoosers we currently open) directly from the menu offers the filtering and multiple input field or multiple lists and hierarchies and buttons capabilities. One might have a dialogue that lists all the selectors used, provides the filtering (yes, I know menus can do basic filtering) and several buttons to choose global or local searching for the implementing methods, limit to this package, check the history database for implementors no longer in the system, whatever. A crucial point would be to make sure the dialogues open and display *fast* even on slower machines.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HCFI: Halt and Catch Fire Immediate
Hi Tim.
Just type a word. It will filter the menu and help you focus. ...maybe we should expand this search to submenus? :) Just thinking about our current state of tree-node filtering in the object explorer...
Best, Marcel Am 02.11.2017 20:49:48 schrieb Chris Muller asqueaker@gmail.com: I could easily do without 6 items on that menu, but I need the rest. It's possible others might like those features, though.
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".
On Thu, Nov 2, 2017 at 2:34 PM, tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]> wrote:
Using Eliots screenshot as an example to hang some points on -
That’s a way too long menu. I has hierarchical submenus *and* a ‘more…’ submenu. The refactoring stuff is probably less frequently used than many items below, which is usually a bad idea. The usage of the ellipsis for items like ‘senders of…’ at least indicates there is a further list to come but it confuses with ‘more…’ indicating a submenu.
At the very least I’d want to break this up into a better tree of menus, though it seems to me that some of those options really would be better off not in a menu at all but removed to some other UI element. We have the button list in the Browser that subsumes the sender/implementors stuff and there’s probably more that could be done there. I can’t see why ‘class refs’ is in a method menu at all! Nor indeed the three browse options which are all class list related.
Another interesting UI idea from the past might be useful to consider for the ‘senders of… ‘ type entries; RISC OS menus can include attached dialogues of various types. (In fact even entire application windows can be used but that’s going a bit far in my opinion) Now clearly we could simply add a submenu with the list of selectors used in the method for this particular case and it would be an improvement. Using dialogues (like the ListChoosers we currently open) directly from the menu offers the filtering and multiple input field or multiple lists and hierarchies and buttons capabilities. One might have a dialogue that lists all the selectors used, provides the filtering (yes, I know menus can do basic filtering) and several buttons to choose global or local searching for the implementing methods, limit to this package, check the history database for implementors no longer in the system, whatever. A crucial point would be to make sure the dialogues open and display *fast* even on slower machines.
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Strange OpCodes: HCFI: Halt and Catch Fire Immediate
On 02-11-2017, at 1:07 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote: Just type a word. It will filter the menu and help you focus
Yeah, but no, that doesn’t solve the over-complication problem. It helps *if* you already know what you want. It’s no use for discovery, nor much for muscle memory usage. I’m not saying it shouldn’t be available or indeed improved, but it is only a very small aspect of the whole issue.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim My computer NEVER cras
Hi Tim,
yes, discoverability and good defaults are key. We should re-design the menus. Yet, it is a challenging endeavour. I read things about adaptive menus, tried them out in former MS Office versions ... such "cleverness" stands in the user's way if not done right. :-/ Maybe even does more harm than good.
The menus we have in Squeak do not work for daily usage - I suppose. You can browse them, discover new features, maybe recall a long forgotten one if you got stuck. Nevertheless, most of them got keyboard shortcuts and you should learn them. ...relying on those menus in the long term is tedious. :-(
Other environments have multiple kinds of menus: classic tool bars, pop-up menus, ribbon bars, floating versions of all these... labels in combination with icons, you can make more features available without annoying the user too much. Again, if all menu entries get an icon, the effect of icons is gone again. ...unless being REALLY GOOD icons ... which they usually aren't. :)
So, I hear you. I understand the issue with the status quo. I really would like to improve it someday.
Speaking of good defaults and means of configuration:
Best, Marcel Am 02.11.2017 21:12:16 schrieb tim Rowledge tim@rowledge.org:
On 02-11-2017, at 1:07 PM, Marcel Taeumel wrote: Just type a word. It will filter the menu and help you focus
Yeah, but no, that doesn’t solve the over-complication problem. It helps *if* you already know what you want. It’s no use for discovery, nor much for muscle memory usage. I’m not saying it shouldn’t be available or indeed improved, but it is only a very small aspect of the whole issue.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim My computer NEVER cras
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/
Best, Marcel
Am 02.11.2017 23:00:03 schrieb Bob Arning arning315@comcast.net: that's not too hard
On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".
well, that's not too hard, either ;-)
On 11/3/17 4:41 AM, Marcel Taeumel wrote:
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/
Best, Marcel
Am 02.11.2017 23:00:03 schrieb Bob Arning arning315@comcast.net:
that's not too hard
On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".
Well, it is not too hard to come up with something, right. ;) Especially coding it is much easier than designing it (wrt. configuration and extensibility). You suggestion is, in my opinion, not better than keyboard-filtering of (hierarchical/grouped) menus. Hmm... user-friendly configuration would be more like expressing what you do frequently instead of filling a blacklist with things to not use.
It might be constructive to look for a good implementation of adaptive menus, whose design we could employ in Squeak. MS Office got rid of their approach, which I think is good. :)
Best, Marcel Am 03.11.2017 10:50:16 schrieb Bob Arning arning315@comcast.net: well, that's not too hard, either ;-)
On 11/3/17 4:41 AM, Marcel Taeumel wrote:
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/
Best, Marcel
Am 02.11.2017 23:00:03 schrieb Bob Arning arning315@comcast.net [mailto:arning315@comcast.net]: that's not too hard
On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".
These papers might be interesting reads in this regard:
"A comparison of static, adaptive, and adaptable menus", 2004, Findlater et al. "Adaptable versus adaptive menus on the desktop: Performance and user satisfaction", 2007, Park et al. "Ephemeral adaptation: The use of gradual onset to improve menu selection performance", 2009, Findlater et al.
Google (Scholar) can find PDFs of these.
Best, Marcel Am 03.11.2017 10:58:08 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Well, it is not too hard to come up with something, right. ;) Especially coding it is much easier than designing it (wrt. configuration and extensibility). You suggestion is, in my opinion, not better than keyboard-filtering of (hierarchical/grouped) menus. Hmm... user-friendly configuration would be more like expressing what you do frequently instead of filling a blacklist with things to not use.
It might be constructive to look for a good implementation of adaptive menus, whose design we could employ in Squeak. MS Office got rid of their approach, which I think is good. :)
Best, Marcel Am 03.11.2017 10:50:16 schrieb Bob Arning arning315@comcast.net: well, that's not too hard, either ;-)
On 11/3/17 4:41 AM, Marcel Taeumel wrote:
I suppose it would be more user-friendly to think about convenient means of menu configuration instead of just straying from one set of hard-coded values to another. :-/
Best, Marcel
Am 02.11.2017 23:00:03 schrieb Bob Arning arning315@comcast.net [mailto:arning315@comcast.net]: that's not too hard
On 11/2/17 3:48 PM, Chris Muller wrote:
It'd be neat if the IDE could somehow keep a collection of items to omit from the menu; with option to "restore all".
On Fri, Nov 3, 2017 at 03:04 Marcel Taeumel marcel.taeumel@hpi.de wrote:
These papers might be interesting reads in this regard:
"A comparison of static, adaptive, and adaptable menus", 2004, Findlater et al. "Adaptable versus adaptive menus on the desktop: Performance and user satisfaction", 2007, Park et al. "Ephemeral adaptation: The use of gradual onset to improve menu selection performance", 2009, Findlater et al.
Google (Scholar) can find PDFs of these.
i saw this adaptive menu on a Japanese device once a long time ago where the most recently used menu item rises to the top and i liked it and i still like it so i made one in Smalltalk and i still use it the short cut keys are <WindowsPopUpMenuKey> , <M> , <FirstLetterOfTheComand> the menu is divided up into sections and the most recently used section rises to the top such that from then on just the three key presses will execute the menu item the menu is just a list Chooser Dialog <—-[ Dolphin ] there is a menu command that opens a text View on all the menu commands which can be searched there are a lot of them many menu commands have documentation which pops up first which unconscious hitting <Spacebar> bypasses it shows that something is happening one could turn this prefix doc off but i never want to ( the Pharo Message dialogs are too dark i think i want white ) there are many old dead menu commands in the list left over from long ago which i just leave deprecated but have not removed since no one else will see them ( spies excepted i guess ) it’s easy to add new commands which act on the text selection in the TextView which gives a command line effect
if one was to implement these menu commands as KEGArrows<—-[ see Haskell arrows ] then the user might be able to compose them into scripts or programs like named MSOffice macros i guess with some ..Arrows able to look at their surroundings to keep it correct if they get refactored ..Arrows try to minimize the need for program variables so code looks more like a list of ..Arrows i would like to publish this ..Arrows Package soon but how do i do it do i have to be a member of something to get it more widely viewed and if so what is it? ( i have seen where members were encouraged to ignore non members of something but i can’t remember what i noticed some kind of member list for Pharo Squeak which i would like to join if possible but how ) i am trying to move to mostly ..Arrows based programming not quite sure what the best ways are because it looks is convenient for TDDev etc and it makes it easier to handle more complexity i think and have more tests much more integration tests which might even act like Iffel runtime correctness checks when turned on the test instrumentation in the target Method is brief just a few Charaters ..Arrows could also be a functional way to handle state via the state monad idea of pure and impure functions which helps the Compiler could help it they say
Oh my goodness this is awesome!
On Wed, Nov 1, 2017 at 5:15 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
as Tobias mentioned, we have a working integration [1] of the well-known "Refactoring"-Package [2] for Squeak's System Browser. It is missing a preview of the refactoring, but otherwise works fine:
Please extend the "RefactoringToolsForSqueak" package and consider integrating it into Trunk. Please do not start a new kind of integration in this regard. :) We have been using the existing integration successfully in Squeak 5.1 and Squeak Trunk in our student courses.
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.
Best, Marcel
[1] http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak [2] http://www.squeaksource.com/rb/
Am 01.11.2017 07:34:04 schrieb Tobias Pape das.linux@gmx.de: Hi Eliot,
On 01.11.2017, at 00:34, Eliot Miranda wrote:
Hi All,
I'm finally adding refactoring support to the standard Squeak browser. I
wonder if anyone knows of refactoring submenu code suitable for the browser I could start from. I'm looking at Pharo's Nautilus integration as one model but wondered if there's anything closer.
Have you seen the Refactoring tools? We have done exactly that two years ago
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak.html
http://ss3.gemtalksystems.com/ss/RefactoringToolsForSqueak/ RefactoringTools-mt.3.mcz
http://wiki.squeak.org/squeak/831
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Bob Arning -
Chris Muller -
David T. Lewis -
Edgar J. De Cleene -
Eliot Miranda -
H. Hirzel -
Herbert König -
Jakob Reschke -
Kjell Godo -
Levente Uzonyi -
Marcel Taeumel -
Nicolas Cellier -
tim Rowledge -
Tobias Pape