- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Working on Pharo 1.2

by Adrian Lienhard

We are working on it... or rather, we are discussing how to do it. It's not forgotten. Adrian On Aug 15, 2010, at 14:42 , Sean P. DeNigris wrote: > > > StÃ©phane Ducasse wrote: >> >> send the code :) >> > > What is the status of the unique link to stable and trunk discussed at > http://forum.world.st/is-there-an-unique-URL-to-the-latest-pharo-core-or-de… > ? Having a static url would prevent having to constantly update the URL > referenced in the "find trunk here" message. I created an issue: > http://code.google.com/p/pharo/issues/detail?id=2805 > > Sean > -- > View this message in context: http://forum.world.st/Working-on-Pharo-1-2-tp2322972p2325897.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 15, 2010

Re: [Pharo-project] [Settings] Preferences defaultAnnotationRequests

by Marcus Denker

On Aug 15, 2010, at 3:54 PM, Lukas Renggli wrote: > How do I get the list of annotation selectors with the new settings > framework? Previously this was: > > Preferences defaultAnnotationRequests In 1.1, this returns always #timeStamp #messageCategory #sendersCount #implementorsCount #allChangeSets There is no way to change it. There is a method with all the choices, bit it is unsent: annotationInfo "Answer a list of pairs characterizing all the available kinds of annotations; in each pair, the first element is a symbol representing the info type, and the second element is a string providing the corresponding balloon help" ^ #( (timeStamp 'The time stamp of the last submission of the method.') (firstComment 'The first comment in the method, if any.') (masterComment 'The comment at the beginning of the supermost implementor of the method if any.') (documentation 'Comment at beginning of the method or, if it has none, comment at the beginning of a superclass''s implementation of the method') (messageCategory 'Which method category the method lies in') (sendersCount 'A report of how many senders there of the message.') (implementorsCount 'A report of how many implementors there are of the message.') (recentChangeSet 'The most recent change set bearing the method.') (allChangeSets 'A list of all change sets bearing the method.') (priorVersionsCount 'A report of how many previous versions there are of the method' ) (priorTimeStamp 'The time stamp of the penultimate submission of the method, if any')) This is all not used in Core.... so maybe the best would be to add this as a Setting to OB. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 15, 2010

Re: [Pharo-project] [update 1.2] #12092

by Alexandre Bergel

> Preferences and Preference are gone... all obsolete classes related to Preferences > are gone, finally. Cool! We have been waiting for it for a long long time... Alexandre > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 15, 2010

[Pharo-project] [Settings] Preferences defaultAnnotationRequests

by Lukas Renggli

How do I get the list of annotation selectors with the new settings framework? Previously this was: Preferences defaultAnnotationRequests Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 15, 2010

Re: [Pharo-project] Preferences removal Re: [update 1.2] #12092

by Mariano Martinez Peck

On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > On Sunday, August 15, 2010, Marcus Denker <marcus.denker(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 15, 2010

Re: [Pharo-project] Preferences removal Re: [update 1.2] #12092

by Lukas Renggli

On Sunday, August 15, 2010, Marcus Denker <marcus.denker(a)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

Aug. 15, 2010

Re: [Pharo-project] Working on Pharo 1.2

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > send the code :) > What is the status of the unique link to stable and trunk discussed at http://forum.world.st/is-there-an-unique-URL-to-the-latest-pharo-core-or-de… ? Having a static url would prevent having to constantly update the URL referenced in the "find trunk here" message. I created an issue: http://code.google.com/p/pharo/issues/detail?id=2805 Sean -- View this message in context: http://forum.world.st/Working-on-Pharo-1-2-tp2322972p2325897.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 15, 2010

[Pharo-project] [ANN 1.2] pre-built 1.2Core#12092

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27353/PharoCore-1.2-12092.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 15, 2010

Re: [Pharo-project] Preferences removal Re: [update 1.2] #12092

by Marcus Denker

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.

Aug. 15, 2010

Re: [Pharo-project] [update 1.2] #12092

by StÃ©phane Ducasse

> 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. Great news > > 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...) Yes.

Aug. 15, 2010