Extension methods in p7
Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g. *Magritte-model-builder These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested. Norbert
Hi Norbert. In Calypso there are no protocols for extensions. You should simply call command Move methods to package either from menu or drag and drop to package (where you see it). I don't know what the reason for commit and removal. I will check. вÑ, 21 авг. 2018 г., 8:32 Norbert Hartl <norbert@hartl.name>:
Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g.
*Magritte-model-builder
These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested.
Norbert
Denis, I have the same in voyage, too. Marcus gave a possible reference for this https://github.com/pharo-project/pharo/pull/1685/files <https://github.com/pharo-project/pharo/pull/1685/files> Norbert
Am 21.08.2018 um 10:05 schrieb Denis Kudriashov <dionisiydk@gmail.com>:
Hi Norbert.
In Calypso there are no protocols for extensions. You should simply call command Move methods to package either from menu or drag and drop to package (where you see it).
I don't know what the reason for commit and removal. I will check.
вÑ, 21 авг. 2018 г., 8:32 Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>: Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g.
*Magritte-model-builder
These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested.
Norbert
NorbertHartl wrote
I'll try to review today. I tried to port a project to Pharo 7, but this bug made it unbearable. IMHO recategorizing methods is *not* the way to go. Let's just fix the bug! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi Norbert, maybe it is unrelated - but I saw strange behavior with extensions and upper/lowercase leading to Iceberg showing "Uncomitted changes in latest image" as I wrote in http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-August/27281... My scenario: I use my https://github.com/astares/pharo-contributor project to automatically get the most recent pharo image (Pharo-7.0+alpha.build.1185) and synch my github fork with the development branch of pharo-project as shown in the video of this project. When Iceberg synchs it should usually SHOW A CLEAN IMAGE WITHOUT CHANGES DONE but since a week or so (maybe after the latest Iceberg integration) I see that there are uncommitted changes (see screenshot) although it is a fresh image. But my forks development branch is definitely in synch with the pharo-project development branch and the latest image (as it was green in CI) should be in synch with the sources as well. If I look more detailed on what Iceberg display as "changed" or "uncommitted" then one will notice that these are all extensions methods look different in the browser. For instance #goferPriority is an extension on package "Gofer-Core" but the extension is displayed in Calypso as "Gofer-core-accessing" with lowercase in the name. Maybe there was a change related to package detection ... Dont know if it is a known problem but for Iceberg I found something here from Pablo: (https://github.com/pharo-vcs/iceberg/pull/981) Bye T.
Gesendet: Dienstag, 21. August 2018 um 09:31 Uhr Von: "Norbert Hartl" <norbert@hartl.name> An: "Pharo Dev" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Extension methods in p7
Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g.
*Magritte-model-builder
These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested.
Norbert
Yes, the problem related to some changes. In latest image I have two packages: Gofer-Core and Gofer-core-accessing. So all such extensions force separate packages. 2018-08-21 10:10 GMT+01:00 Torsten Bergmann <astares@gmx.de>:
Hi Norbert,
maybe it is unrelated - but I saw strange behavior with extensions and upper/lowercase leading to Iceberg showing "Uncomitted changes in latest image" as I wrote in http://lists.pharo.org/pipermail/pharo-dev_lists. pharo.org/2018-August/272816.html
My scenario: I use my https://github.com/astares/pharo-contributor project to automatically get the most recent pharo image (Pharo-7.0+alpha.build.1185) and synch my github fork with the development branch of pharo-project as shown in the video of this project.
When Iceberg synchs it should usually SHOW A CLEAN IMAGE WITHOUT CHANGES DONE but since a week or so (maybe after the latest Iceberg integration) I see that there are uncommitted changes (see screenshot) although it is a fresh image.
But my forks development branch is definitely in synch with the pharo-project development branch and the latest image (as it was green in CI) should be in synch with the sources as well.
If I look more detailed on what Iceberg display as "changed" or "uncommitted" then one will notice that these are all extensions methods look different in the browser.
For instance #goferPriority is an extension on package "Gofer-Core" but the extension is displayed in Calypso as "Gofer-core-accessing" with lowercase in the name.
Maybe there was a change related to package detection ...
Dont know if it is a known problem but for Iceberg I found something here from Pablo: (https://github.com/pharo-vcs/iceberg/pull/981)
Bye T.
Gesendet: Dienstag, 21. August 2018 um 09:31 Uhr Von: "Norbert Hartl" <norbert@hartl.name> An: "Pharo Dev" <pharo-dev@lists.pharo.org> Betreff: [Pharo-dev] Extension methods in p7
Iâm about preparing magritte to be loadable in pharo 7. I encountered a bit strange behaviour where I had to take cumbersome measures. Magritte has method extensions that are called e.g.
*Magritte-model-builder
These methods get loaded but when I commit something all of these methods are to be removed. The only thing I could do was to rename the extension methods. Is this intended? Doing the renaming I encountered of few things. Magritte had the extension method above in the Magritte-Model package. When I rename the category *Magritte-model-builder to *Magritte-Model the method gets removed. Not a very usual case but still strange. In order to create a method extension one needs first to create a new protocol before converting to extension method. If the new protocol is empty and you convert it to an extension method it gets removed. So I had to first create a protocol, move a method in and then convert. This combined with the behaviour that if you select two methods the method pane jumps to the beginning of the list is a lot of work just to do this job. Still it is not a very usual case but some might be interested.
Norbert
participants (4)
-
Denis Kudriashov -
Norbert Hartl -
Sean P. DeNigris -
Torsten Bergmann