- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Deprecation policy

by StÃ©phane Ducasse

at least we should get this list studied and we decide. we shoudl open a bug entry. On Aug 30, 2011, at 1:34 AM, Sean P. DeNigris wrote: > Are pre-1.3 deprecated methods purposely put into protocol *deprecated13? > > For example: > String>>asDefaultDecodedString on: 2/13/2010 in: 1.1 > PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2 > SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2 > SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1 > > -- > View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777660.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 30, 2011

Re: [Pharo-project] Deprecation policy

by Marcus Denker

On Aug 30, 2011, at 1:35 AM, Sean P. DeNigris wrote: > Are pre-1.3 deprecated methods purposely put into protocol *deprecated13? > > For example: > String>>asDefaultDecodedString on: 2/13/2010 in: 1.1 > PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2 > SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2 > SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1 Sometimes we move methods to keep them longer, somtimes methods get "lost" from the package because of accidental re-categoration, and than moved to the current deprecated package. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by Damien Cassou

On Tue, Aug 30, 2011 at 8:31 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > So maybe we should just release with the same VMs as 1.2, just to get it done? What is the problem with the 1.2 VM that doesn't make it a good candidate for 1.3 ? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 30, 2011

Re: [Pharo-project] Deprecation policy

by StÃ©phane Ducasse

On Aug 30, 2011, at 1:43 AM, Sean P. DeNigris wrote: > Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August, > 2011'. Does it matter? not really right now. but ok to live with it. Now it would be good to have a refactoring to deprecate a method (but I had no time and know how to add one) > > -- > View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 30, 2011

Re: [Pharo-project] Deprecation policy

by Marcus Denker

On Aug 30, 2011, at 1:44 AM, Sean P. DeNigris wrote: > Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August, > 2011'. Does it matter? No > > -- > View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://marcusdenker.de

Aug. 30, 2011

Re: [Pharo-project] Deprecation policy

by StÃ©phane Ducasse

On Aug 30, 2011, at 1:23 AM, Sean P. DeNigris wrote: > I want to add a comment to #deprecated:on:in: > > This is my understanding (it is implemented inconsistently in 1.4 update > #14112): > > For methods: > 1. Have the method call deprecated:on:in: as its first step > - the versionString should be e.g. 'Pharo1.4' (although I found #Pharo1.4, > see the problem; and '1.4', those were mine, hee hee). Is it redundant to > say 'PharoXxx'? > 2. Move the method to protocol e.g. deprecated14 for Pharo 1.4 > this protocol could be an extension of the deprecatedXX package but not necessarily. because sometimes we want to keep the method longer > For classes: > 1. Move to Category e.g. 'Deprecated14' for Pharo 1.4 > 2? Should #deprecated:on:in: be called from the methods? It's inconsistent > in the image and seems unnecessary, except maybe for some class-side > methods. Yes because this is a lot of work and not convincing :) > > Is all this correct? > > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777647.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 30, 2011

Re: [Pharo-project] Pharo 1.3 release

by Marcus Denker

The state is the same as 3 week ago, (and I fear the same as in 3 weeks): -> image is finished, there are some (5 or so bugreport) that will be integrated as they get fixed, but this does not hold up the release -> What is missing are VMs and the one-click. I do not know which VMs to take. This has not changed in 3 weeks. So maybe we should just release with the same VMs as 1.2, just to get it done? Marcus On Aug 30, 2011, at 7:53 AM, laurent laffont wrote: > Hi, > > maybe I haven't read correctly the mailing-list but I still don't know if Pharo 1.3 is released or not, cannot find any official announcement, release date .... > > The website is misleading, I can help on this, but need to be sure. > > I've also prepared a french announcement but needs to be up to date before. > > Cheers, > > Laurent Laffont -- Marcus Denker -- http://marcusdenker.de

Aug. 30, 2011

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Damien Cassou

On Mon, Aug 29, 2011 at 10:25 PM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > Should I remove this? it looks like that if you remove "aBlock value: self", aBlock will never get executed. The question is now "does the name #allElementsDo: makes sense with this behavior?" I don't think so. One way to fix it is to move "aBlock value: self" to XMLNodeWithElements>>allElementsDo: -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 30, 2011

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Tudor Girba

Indeed, it should be named withAllElementsDo: to be consistent with Smalltalk naming, and then it would exactly what the name says :) Doru On 30 Aug 2011, at 07:51, Max Leske wrote: > â¦ and maybe it should be renamed to #withAllElementsDo: ? > > > On 30.08.2011, at 00:01, Levente Uzonyi wrote: > >> On Mon, 29 Aug 2011, Nicolas Anquetil wrote: >> >>> In XML-Parser-Nodes we have: >>> >>> XMLNodeWithElements >>> XMLDocument >>> XMLElement >>> >>> A document is composed of elements that can hold recursively other elements >>> >>> XMLNodeWithElements implements (in protocol enumerating) >>> allElementsDo: aBlock >>> "Descend depth-first visiting each element with aBlock." >>> >>> self hasElements >>> ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] >>> >>> Looks perfectly normal to me >>> But then: >>> >>> XMLElement implements (in protocol searching !) >>> allElementsDo: aBlock >>> "See superclass version." >>> >>> aBlock value: self. >>> >>> super allElementsDo: aBlock. >>> >>> which means that >>> anXMLElement allElementsDo: [...] >>> runs first on itself and then on its elements ?!? >>> Seems counter intuitive to me. >>> >>> Should I remove this? >> >> IMHO you shouldn't, because it is enumerating the whole tree, which is exactly what I'd expect from this method. But the method should be recategorized. >> >> >> Levente >> >>> >>> nicolas >>> >>> >> > > -- www.tudorgirba.com "Live like you mean it."

Aug. 30, 2011

[Pharo-project] Pharo 1.3 release

by laurent laffont

Hi, maybe I haven't read correctly the mailing-list but I still don't know if Pharo 1.3 is released or not, cannot find any official announcement, release date .... The website is misleading, I can help on this, but need to be sure. I've also prepared a french announcement but needs to be up to date before. Cheers, Laurent Laffont

Aug. 30, 2011