[Pharo-project] Preferences removal Re: [update 1.2] #12092
On Sun, Aug 15, 2010 at 1:48 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
12092 -----
Issue 2803: Final Preference Clean
This update does ScriptLoader new cleanUpForRelease. in the postscript.
Preferences and Preference are gone... all obsolete classes related to Preferences are gone, finally.
But I think we should add back a Preferences class for allowing to load old code. (it's referenced in the class side initialize in old code often...)
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. I mean...is there a mapping between each previous preference a the new ones? Cheers Mariano
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
But I think we should add back a Preferences class for allowing to load old code. (it's referenced in the class side initialize in old code often...)
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that.
What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preference class return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g. compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...).
I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I think not really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removing unsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On Sunday, August 15, 2010, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
But I think we should add back a Preferences class for allowing to load old code. (it's referenced in the class side initialize in old code often...)
Please don't add such a fake classes, it just makes everything more difficult and less functional. People should not use outdated code, and if they do they should be able to fix it themselves. I am fixing right now the remaining references in OB and Shout (RB and eCompletion are already fixed). Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a  near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2...    Marcus
--Marcus Denker  -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <renggli@gmail.com> wrote:
On Sunday, August 15, 2010, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
But I think we should add back a Preferences class for allowing to load
old code. (it's referenced
in the class side initialize in old code often...)
Please don't add such a fake classes, it just makes everything more difficult and less functional. People should not use outdated code, and if they do they should be able to fix it themselves.
I am fixing right now the remaining references in OB and Shout (RB and eCompletion are already fixed).
Lukas, Shout won't load in Pharo 1.2 because of issue http://code.google.com/p/pharo/issues/detail?id=2734 :(
Lukas
The problem are the external pacakges. I have 100 references to
Preferences in Pharo dev....almost EVERY external package uses Preferences.
So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus
--Marcus Denker -- http://www.marcusdenker.de < http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Name: Refactoring-Core-lr.149 Author: lr Time: 15 August 2010, 5:18:09 pm UUID: 27652b7f-9069-49e2-ad79-b6c3ecb077d9 Ancestors: Refactoring-Core-lr.148 - removed all references to Preferences Name: ShoutWorkspace-lr.7 Author: lr Time: 15 August 2010, 5:20:07 pm UUID: 851aa393-9367-4731-b695-1bcec55add0c Ancestors: ShoutWorkspace-lr.6 - removed all references to Preferences Name: Shout-lr.86 Author: lr Time: 15 August 2010, 5:20:53 pm UUID: 07aa43a8-8669-4cc8-b5a7-e8c8f002adfd Ancestors: Shout-lr.85 - removed all references to Preferences (next is to add settings for the format, but that requires quite some heavy changes) Name: OmniBrowser-lr.487 Author: lr Time: 15 August 2010, 5:25:43 pm UUID: fc4947b3-c23c-4cbb-a7af-7876306dc8de Ancestors: OmniBrowser-lr.486 - removed all references to Preferences Name: OB-Standard-lr.488 Author: lr Time: 15 August 2010, 5:26:21 pm UUID: 8a31228c-89e8-4450-8408-9d47576d9db5 Ancestors: OB-Standard-lr.487 - removed all references to Preferences Name: OB-Tests-Core-lr.83 Author: lr Time: 15 August 2010, 5:26:43 pm UUID: 8ebb0466-c329-4eaa-a5a9-9e1114cf5da2 Ancestors: OB-Tests-Core-lr.82 - removed all references to Preferences Name: OB-Tests-Morphic-lr.28 Author: lr Time: 15 August 2010, 5:27:19 pm UUID: 043cf6f5-a9dd-4c9e-8846-fe43a280de07 Ancestors: OB-Tests-Morphic-lr.27 - removed all references to Preferences Name: OB-Tests-Standard-lr.115 Author: lr Time: 15 August 2010, 5:27:39 pm UUID: 3459c99b-df43-4ad9-b277-e579ff5a9bff Ancestors: OB-Tests-Standard-lr.114 - removed all references to Preferences 2010/8/15 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <renggli@gmail.com> wrote:
On Sunday, August 15, 2010, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
But I think we should add back a Preferences class for allowing to load old code. (it's referenced in the class side initialize in old code often...)
Please don't add such a fake classes, it just makes everything more difficult and less functional. People should not use outdated code, and if they do they should be able to fix it themselves.
I am fixing right now the remaining references in OB and Shout (RB and eCompletion are already fixed).
Lukas, Shout won't load in Pharo 1.2 because of issue
http://code.google.com/p/pharo/issues/detail?id=2734
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a  near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2...    Marcus
--Marcus Denker  -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
coooooooooooooooooool probably to be put in configurationOf for pharo1.2 Stef On Aug 15, 2010, at 5:28 PM, Lukas Renggli wrote:
Name: Refactoring-Core-lr.149 Author: lr Time: 15 August 2010, 5:18:09 pm UUID: 27652b7f-9069-49e2-ad79-b6c3ecb077d9 Ancestors: Refactoring-Core-lr.148
- removed all references to Preferences
Name: ShoutWorkspace-lr.7 Author: lr Time: 15 August 2010, 5:20:07 pm UUID: 851aa393-9367-4731-b695-1bcec55add0c Ancestors: ShoutWorkspace-lr.6
- removed all references to Preferences
Name: Shout-lr.86 Author: lr Time: 15 August 2010, 5:20:53 pm UUID: 07aa43a8-8669-4cc8-b5a7-e8c8f002adfd Ancestors: Shout-lr.85
- removed all references to Preferences (next is to add settings for the format, but that requires quite some heavy changes)
Name: OmniBrowser-lr.487 Author: lr Time: 15 August 2010, 5:25:43 pm UUID: fc4947b3-c23c-4cbb-a7af-7876306dc8de Ancestors: OmniBrowser-lr.486
- removed all references to Preferences
Name: OB-Standard-lr.488 Author: lr Time: 15 August 2010, 5:26:21 pm UUID: 8a31228c-89e8-4450-8408-9d47576d9db5 Ancestors: OB-Standard-lr.487
- removed all references to Preferences
Name: OB-Tests-Core-lr.83 Author: lr Time: 15 August 2010, 5:26:43 pm UUID: 8ebb0466-c329-4eaa-a5a9-9e1114cf5da2 Ancestors: OB-Tests-Core-lr.82
- removed all references to Preferences
Name: OB-Tests-Morphic-lr.28 Author: lr Time: 15 August 2010, 5:27:19 pm UUID: 043cf6f5-a9dd-4c9e-8846-fe43a280de07 Ancestors: OB-Tests-Morphic-lr.27
- removed all references to Preferences
Name: OB-Tests-Standard-lr.115 Author: lr Time: 15 August 2010, 5:27:39 pm UUID: 3459c99b-df43-4ad9-b277-e579ff5a9bff Ancestors: OB-Tests-Standard-lr.114
- removed all references to Preferences
2010/8/15 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <renggli@gmail.com> wrote:
On Sunday, August 15, 2010, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
But I think we should add back a Preferences class for allowing to load old code. (it's referenced in the class side initialize in old code often...)
Please don't add such a fake classes, it just makes everything more difficult and less functional. People should not use outdated code, and if they do they should be able to fix it themselves.
I am fixing right now the remaining references in OB and Shout (RB and eCompletion are already fixed).
Lukas, Shout won't load in Pharo 1.2 because of issue
http://code.google.com/p/pharo/issues/detail?id=2734
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus
--Marcus Denker -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Aug 15, 2010 at 6:19 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
coooooooooooooooooool probably to be put in configurationOf for pharo1.2
Of course :) That's why I asked about Shout repo....
Stef
On Aug 15, 2010, at 5:28 PM, Lukas Renggli wrote:
Name: Refactoring-Core-lr.149 Author: lr Time: 15 August 2010, 5:18:09 pm UUID: 27652b7f-9069-49e2-ad79-b6c3ecb077d9 Ancestors: Refactoring-Core-lr.148
- removed all references to Preferences
Name: ShoutWorkspace-lr.7 Author: lr Time: 15 August 2010, 5:20:07 pm UUID: 851aa393-9367-4731-b695-1bcec55add0c Ancestors: ShoutWorkspace-lr.6
- removed all references to Preferences
Name: Shout-lr.86 Author: lr Time: 15 August 2010, 5:20:53 pm UUID: 07aa43a8-8669-4cc8-b5a7-e8c8f002adfd Ancestors: Shout-lr.85
- removed all references to Preferences (next is to add settings for the format, but that requires quite some heavy changes)
Name: OmniBrowser-lr.487 Author: lr Time: 15 August 2010, 5:25:43 pm UUID: fc4947b3-c23c-4cbb-a7af-7876306dc8de Ancestors: OmniBrowser-lr.486
- removed all references to Preferences
Name: OB-Standard-lr.488 Author: lr Time: 15 August 2010, 5:26:21 pm UUID: 8a31228c-89e8-4450-8408-9d47576d9db5 Ancestors: OB-Standard-lr.487
- removed all references to Preferences
Name: OB-Tests-Core-lr.83 Author: lr Time: 15 August 2010, 5:26:43 pm UUID: 8ebb0466-c329-4eaa-a5a9-9e1114cf5da2 Ancestors: OB-Tests-Core-lr.82
- removed all references to Preferences
Name: OB-Tests-Morphic-lr.28 Author: lr Time: 15 August 2010, 5:27:19 pm UUID: 043cf6f5-a9dd-4c9e-8846-fe43a280de07 Ancestors: OB-Tests-Morphic-lr.27
- removed all references to Preferences
Name: OB-Tests-Standard-lr.115 Author: lr Time: 15 August 2010, 5:27:39 pm UUID: 3459c99b-df43-4ad9-b277-e579ff5a9bff Ancestors: OB-Tests-Standard-lr.114
- removed all references to Preferences
2010/8/15 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <renggli@gmail.com>
wrote:
On Sunday, August 15, 2010, Marcus Denker <marcus.denker@inria.fr>
wrote:
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
But I think we should add back a Preferences class for allowing to
load
old code. (it's referenced in the class side initialize in old code often...)
Please don't add such a fake classes, it just makes everything more difficult and less functional. People should not use outdated code, and if they do they should be able to fix it themselves.
I am fixing right now the remaining references in OB and Shout (RB and eCompletion are already fixed).
Lukas, Shout won't load in Pharo 1.2 because of issue
http://code.google.com/p/pharo/issues/detail?id=2734
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses
Preferences.
So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus
--Marcus Denker -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas, Shout won't load in Pharo 1.2 because of issue
I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate. I guess PluggableTextMorph should be fixed, or why was this instance variable added? Is this coming from Squeak? Lukas
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a  near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2...    Marcus
--Marcus Denker  -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <renggli@gmail.com> wrote:
Lukas, Shout won't load in Pharo 1.2 because of issue
I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate.
I guess PluggableTextMorph should be fixed, or why was this instance variable added? Is this coming from Squeak?
I have no idea. I asked several times if someone can fix it... I am trying to start building PharoDev on top of PharoCore 1.2 but I have this problem.
Lukas
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses
Preferences.
So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus
--Marcus Denker -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
As far as I know, this happens because now a TextMorph has a styler strategy. By default, the styler is the NullStyler but it can be set from outside to be something else (like a ShoutStyler). Like that you have the two concerns (editing, and highlighting) nicely supported by the framework without requiring subclassing. So, I would say that the simplest way to go around this problem and still be somewhat backward compatible would be to renamed styler to shoutStyler in the PluggableShoutMorph. Cheers, Doru On 15 Aug 2010, at 18:48, Mariano Martinez Peck wrote:
On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <renggli@gmail.com> wrote:
Lukas, Shout won't load in Pharo 1.2 because of issue
I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate.
I guess PluggableTextMorph should be fixed, or why was this instance variable added? Is this coming from Squeak?
I have no idea. I asked several times if someone can fix it... I am trying to start building PharoDev on top of PharoCore 1.2 but I have this problem.
Lukas
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses
Preferences.
So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus
--Marcus Denker -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Every successful trip needs a suitable vehicle."
On Aug 15, 2010, at 7:03 PM, Tudor Girba wrote:
As far as I know, this happens because now a TextMorph has a styler strategy. By default, the styler is the NullStyler but it can be set from outside to be something else (like a ShoutStyler).
Like that you have the two concerns (editing, and highlighting) nicely supported by the framework without requiring subclassing.
So, I would say that the simplest way to go around this problem and still be somewhat backward compatible would be to renamed styler to shoutStyler in the PluggableShoutMorph.
why not but having a 1.2 version would solve the problem too.
Cheers, Doru
On 15 Aug 2010, at 18:48, Mariano Martinez Peck wrote:
On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <renggli@gmail.com> wrote:
Lukas, Shout won't load in Pharo 1.2 because of issue
I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate.
I guess PluggableTextMorph should be fixed, or why was this instance variable added? Is this coming from Squeak?
I have no idea. I asked several times if someone can fix it... I am trying to start building PharoDev on top of PharoCore 1.2 but I have this problem.
Lukas
:(
Lukas
The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). I mean...is there a mapping between each previous preference a the new ones?
In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus
--Marcus Denker -- http://www.marcusdenker.de <http://www.marcusdenker.de/> INRIA Lille -- Nord Europe. Team RMoD.
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Lukas Renggli -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse -
Tudor Girba