May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo on Stackexchange

by Igor Stasenko

On 15 May 2012 13:49, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 15 May 2012 12:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On May 15, 2012, at 1:18 PM, Frank Shearar wrote: >> >>> On 15 May 2012 12:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> On Tue, May 15, 2012 at 10:38 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>> With the dev mailing list slowly getting out of control ;) we should think of >>>>> means of communication with the masses! >>>>> >>>>> I created stackexchange proposal which needs YOUR support: >>>>> >>>>> http://area51.stackexchange.com/proposals/40717/pharo?referrer=gXC4FWspxSud… >>>>> >>>>> we need now: >>>>> - 60 Followers >>>>> - 40 questions with some answers! >>>>> >>>> It seems that this will not work: someone is tagging all questions as >>>> "can be asked on Stackoverflow" >>>> and requests to close the area. >>>> >>>> So I think we will have to install our own thing instead. >>> >>> If what you want is something other than a QA site, absolutely. >>> >>> If you want a QA place, I don't see why people can't just use SO: >>> there are already 113 questions tagged "pharo" there, and all people >>> need do is... just ask your question there. It's one more thing you >>> don't need to write/install/maintain, and one LESS thing for you to >>> track: lists, RSS feeds, newsgroups, QA sites, ... >> >> >> I did not have an account on StackOverflow until 1 hour ago. >> It's one more thing in itself, and I don't see how a big mess of questions >> helps of all topics in the world will help us. >> >> We need somethign focussed. > > http://stackoverflow.com/feeds/tag/pharo would probably be exactly > what you'd want, possibly with > http://stackoverflow.com/feeds/tag/smalltalk just to catch non-Pharo > questions that could be answered from a Pharo perspective. > > But yes, I guess there is a cost in that you need an SO account to ask > questions. Having paid that cost long ago, I didn't think about that. SO account? what is it? I authorized with OpenID. So registering is few clicks. I think we don't need separate site. SO is just fine. I added 'smalltalk' tag into my favorites, and i get notified by mail every time there's a new question > > frank >> >> Â Â Â Â Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > -- Best regards, Igor Stasenko.

May 15, 2012

Re: [Pharo-project] Pharo on Stackexchange

by Nicolas Cellier

I perceive SO answers as rather high-quality. Maybe it's just due to the rating, but I recommend this site professionally. Of course, you may think that Smalltalk already implies high-quality, and that the community is too small for having reliable rating... Nonetheless I'd say +1 for SO Nicolas 2012/5/15 Marcus Denker <marcus.denker(a)inria.fr>: > > On May 15, 2012, at 1:49 PM, Frank Shearar wrote: >>> >>> I did not have an account on StackOverflow until 1 hour ago. >>> It's one more thing in itself, and I don't see how a big mess of questions >>> helps of all topics in the world will help us. >>> >>> We need somethign focussed. >> >> http://stackoverflow.com/feeds/tag/pharo would probably be exactly >> what you'd want, possibly with >> http://stackoverflow.com/feeds/tag/smalltalk just to catch non-Pharo >> questions that could be answered from a Pharo perspective. >> >> But yes, I guess there is a cost in that you need an SO account to ask >> questions. Having paid that cost long ago, I didn't think about that. >> > To me it feels like if every open source project would just use one > Bug tracker because there are tags... while I already thing that > I want sub-projects on the current one. > > I personally don't think that tagging subsumes grouping. > > Â Â Â Â Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

May 15, 2012

Re: [Pharo-project] Pharo on Stackexchange

by Nicolas Cellier

2012/5/15 Frank Shearar <frank.shearar(a)gmail.com>: > On 15 May 2012 12:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On May 15, 2012, at 1:18 PM, Frank Shearar wrote: >> >>> On 15 May 2012 12:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> On Tue, May 15, 2012 at 10:38 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>> With the dev mailing list slowly getting out of control ;) we should think of >>>>> means of communication with the masses! >>>>> >>>>> I created stackexchange proposal which needs YOUR support: >>>>> >>>>> http://area51.stackexchange.com/proposals/40717/pharo?referrer=gXC4FWspxSud… >>>>> >>>>> we need now: >>>>> - 60 Followers >>>>> - 40 questions with some answers! >>>>> >>>> It seems that this will not work: someone is tagging all questions as >>>> "can be asked on Stackoverflow" >>>> and requests to close the area. >>>> >>>> So I think we will have to install our own thing instead. >>> >>> If what you want is something other than a QA site, absolutely. >>> >>> If you want a QA place, I don't see why people can't just use SO: >>> there are already 113 questions tagged "pharo" there, and all people >>> need do is... just ask your question there. It's one more thing you >>> don't need to write/install/maintain, and one LESS thing for you to >>> track: lists, RSS feeds, newsgroups, QA sites, ... >> >> >> I did not have an account on StackOverflow until 1 hour ago. >> It's one more thing in itself, and I don't see how a big mess of questions >> helps of all topics in the world will help us. >> >> We need somethign focussed. > > http://stackoverflow.com/feeds/tag/pharo would probably be exactly > what you'd want, possibly with > http://stackoverflow.com/feeds/tag/smalltalk just to catch non-Pharo > questions that could be answered from a Pharo perspective. > > But yes, I guess there is a cost in that you need an SO account to ask > questions. Having paid that cost long ago, I didn't think about that. > > frank You get a google account, facebook, or something, then the cost is approximately 4 clicks in your favourite web browser Nicolas >> >> Â Â Â Â Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >

May 15, 2012

Re: [Pharo-project] Pharo on Stackexchange

by Francois Stephany

+1 > Why not simply use stackoverflow and tag your questions with "pharo"? > > frank >

May 15, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Nicolas Cellier

Since Pharo has the courage of rewriting ClassBuilder, it may be a good idea to rename this copy into a shallowCopy. On the other hand, if #copy creates a new binding (Association className->class copy), it will presumably only return the new class copy, and not the new binding... If you want to make your copy accessible thru some Namespace, you'll have to retrieve the binding... So I'm not completely sure #copy is the good candidate for this purpose... It may be easier to add a new selector like copyIntoBinding: anAssociation This a rationale for #copy statu quo (with the comment of Eliot of course....). Up to you to analyze use cases now... Nicolas 2012/5/15 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, May 15, 2012 at 9:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> >> >> On Tue, May 15, 2012 at 9:39 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >>> >>> >>> >>> On Sun, May 13, 2012 at 5:31 AM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> It depends of the usage of copy... >>>> If the purpose is to modify a class, then the copy will replace the >>>> original in a short future, and you should better keep the >>>> associations untouched and only change them in a final Namespace at: >>>> className put: theClassCopy... >>>> If the purpose is to create a new class, then yes, there's some >>>> additional operation required. >>>> But where will you bind the new association? Another namespace? >>> >>> >>> I agree. Â If copy is supposed to create a fully-fledged copy then the >>> Class>>copy method is broken in several ways: >>> - As Mariano noted, it doesn't copy CompiledMethods nor update their >>> methodClass associations. >>> - It doesn't add the copy to the superclass's subclass >>> - the class has the same name as the original but isn't reachable from >>> Smalltalk >>> >>> But if the use case is some temporary transformation, as Nicholas notes, >>> then the method is ok. Â Except that "copy" is a really unhelpful name. Â This >>> is a specialised copy for certain circumstances and the selevtor should >>> reflect that. Â Anyone know what the use case this copy was written for is? >> >> >> It's clearly for the ClassBuilder. Â See SystemNavigation new >> browseAllCallsOn: #copy localTo: ClassBuilder. Â SO the comment could be more >> helpful, e.g. >> >> copy >> "Answer a copy of the receiver without a list of subclasses. >> Â This copy is used by the ClassBuilder when mutating classes on >> redefinition. >> Â (SystemNavigation new browseAllCallsOn: #copy localTo: ClassBuilder)" > > > find attached. > >> >> >>> >>> >>>> >>>> Nicolas >>>> >>>> 2012/5/13 Igor Stasenko <siguctua(a)gmail.com>: >>>> > yes, this looks like a bug. >>>> > But i would recompile all methods of copied class, so all these >>>> > nuances is handled. >>>> > >>>> > On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> > wrote: >>>> >> >>>> >> >>>> >> On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse >>>> >> <stephane.ducasse(a)inria.fr> wrote: >>>> >>> >>>> >>> >>>> >>> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: >>>> >>> >>>> >>> > Hi guys. The last literal of a instance-side compiled method >>>> >>> > always >>>> >>> > points to the SAME (#==) association of the class in Smalltalk >>>> >>> > global. >>>> >>> > The literals of a compiled method that refer to class variables >>>> >>> > refer to >>>> >>> > the same association (#==) of the classPool of its class: >>>> >>> > >>>> >>> > self assert: ((GRPlatform class >> #current) literalAt: 1) == >>>> >>> > (GRPlatform classPool associationAt: #Current). Â -> true >>>> >>> > >>>> >>> > However, if I do a copy of the class: >>>> >>> > >>>> >>> > | copy | >>>> >>> > copy := GRPlatform copy. >>>> >>> > self assert: ((copy class >> #current) literalAt: 1) == (copy >>>> >>> > classPool >>>> >>> > associationAt: #Current). >>>> >>> > >>>> >>> > this is not true anymore. Of course, you can see this because of >>>> >>> > the >>>> >>> > Class >> #copy implementation: >>>> >>> > >>>> >>> > So my question is....is #copy breaking the contract (and therefore >>>> >>> > it >>>> >>> > has to be fixed) or this is not mandatory for the system (as it is >>>> >>> > with the >>>> >>> > last literal pointing to classes)? >>>> >>> >>>> >>> since namespace binding are shared between method literal and >>>> >>> namespace, I >>>> >>> think that this is a bug. >>>> >>> >>>> >> >>>> >> I did this workaround >>>> >> >>>> >> Class >> rebindClassVariablesInMethods >>>> >> >>>> >> Â Â Â self class methodDict valuesDo: [ :aCompiledMethod | >>>> >> Â Â Â Â Â Â 1 to: aCompiledMethod numLiterals-2 do: [ :index | >>>> >> Â Â Â Â Â Â Â Â Â | literal | >>>> >> Â Â Â Â Â Â Â Â Â literal := aCompiledMethod literalAt: index. >>>> >> Â Â Â Â Â Â Â Â Â literal isVariableBinding ifTrue: [ >>>> >> Â Â Â Â Â Â Â Â Â Â Â Â (self innerBindingOf: literal key) ifNotNil: >>>> >> [:aBinding | >>>> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â aCompiledMethod literalAt: index put: aBinding >>>> >> Â Â Â Â Â Â Â Â Â Â Â Â ] >>>> >> Â Â Â Â Â Â Â Â Â ] >>>> >> Â Â Â Â Â Â ] >>>> >> Â Â Â ] >>>> >> >>>> >>> >>>> >>> Stef >>>> >>> > >>>> >>> > Thanks, >>>> >>> > >>>> >>> > -- >>>> >>> > Mariano >>>> >>> > http://marianopeck.wordpress.com >>>> >>> > >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Mariano >>>> >> http://marianopeck.wordpress.com >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Best regards, >>>> > Igor Stasenko. >>>> > >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> best, >> Eliot >> > > > > -- > best, > Eliot >

May 15, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Eliot Miranda

On Tue, May 15, 2012 at 9:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Tue, May 15, 2012 at 9:39 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Sun, May 13, 2012 at 5:31 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> It depends of the usage of copy... >>> If the purpose is to modify a class, then the copy will replace the >>> original in a short future, and you should better keep the >>> associations untouched and only change them in a final Namespace at: >>> className put: theClassCopy... >>> If the purpose is to create a new class, then yes, there's some >>> additional operation required. >>> But where will you bind the new association? Another namespace? >>> >> >> I agree. If copy is supposed to create a fully-fledged copy then the >> Class>>copy method is broken in several ways: >> - As Mariano noted, it doesn't copy CompiledMethods nor update their >> methodClass associations. >> - It doesn't add the copy to the superclass's subclass >> - the class has the same name as the original but isn't reachable from >> Smalltalk >> >> But if the use case is some temporary transformation, as Nicholas notes, >> then the method is ok. Except that "copy" is a really unhelpful name. >> This is a specialised copy for certain circumstances and the selevtor >> should reflect that. Anyone know what the use case this copy was written >> for is? >> > > It's clearly for the ClassBuilder. See SystemNavigation new > browseAllCallsOn: #copy localTo: ClassBuilder. SO the comment could be > more helpful, e.g. > > copy > "Answer a copy of the receiver without a list of subclasses. > This copy is used by the ClassBuilder when mutating classes on > redefinition. > (SystemNavigation new browseAllCallsOn: #copy localTo: ClassBuilder)" > find attached. > > >> >> >>> Nicolas >>> >>> 2012/5/13 Igor Stasenko <siguctua(a)gmail.com>: >>> > yes, this looks like a bug. >>> > But i would recompile all methods of copied class, so all these >>> > nuances is handled. >>> > >>> > On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> >> >>> >> >>> >> On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse >>> >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> >>> >>> >>> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: >>> >>> >>> >>> > Hi guys. The last literal of a instance-side compiled method always >>> >>> > points to the SAME (#==) association of the class in Smalltalk >>> global. >>> >>> > The literals of a compiled method that refer to class variables >>> refer to >>> >>> > the same association (#==) of the classPool of its class: >>> >>> > >>> >>> > self assert: ((GRPlatform class >> #current) literalAt: 1) == >>> >>> > (GRPlatform classPool associationAt: #Current). -> true >>> >>> > >>> >>> > However, if I do a copy of the class: >>> >>> > >>> >>> > | copy | >>> >>> > copy := GRPlatform copy. >>> >>> > self assert: ((copy class >> #current) literalAt: 1) == (copy >>> classPool >>> >>> > associationAt: #Current). >>> >>> > >>> >>> > this is not true anymore. Of course, you can see this because of >>> the >>> >>> > Class >> #copy implementation: >>> >>> > >>> >>> > So my question is....is #copy breaking the contract (and therefore >>> it >>> >>> > has to be fixed) or this is not mandatory for the system (as it is >>> with the >>> >>> > last literal pointing to classes)? >>> >>> >>> >>> since namespace binding are shared between method literal and >>> namespace, I >>> >>> think that this is a bug. >>> >>> >>> >> >>> >> I did this workaround >>> >> >>> >> Class >> rebindClassVariablesInMethods >>> >> >>> >> self class methodDict valuesDo: [ :aCompiledMethod | >>> >> 1 to: aCompiledMethod numLiterals-2 do: [ :index | >>> >> | literal | >>> >> literal := aCompiledMethod literalAt: index. >>> >> literal isVariableBinding ifTrue: [ >>> >> (self innerBindingOf: literal key) ifNotNil: >>> [:aBinding | >>> >> aCompiledMethod literalAt: index put: aBinding >>> >> ] >>> >> ] >>> >> ] >>> >> ] >>> >> >>> >>> >>> >>> Stef >>> >>> > >>> >>> > Thanks, >>> >>> > >>> >>> > -- >>> >>> > Mariano >>> >>> > http://marianopeck.wordpress.com >>> >>> > >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Mariano >>> >> http://marianopeck.wordpress.com >>> >> >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> > >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > best, > Eliot > > -- best, Eliot

May 15, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Eliot Miranda

On Tue, May 15, 2012 at 9:39 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Sun, May 13, 2012 at 5:31 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> It depends of the usage of copy... >> If the purpose is to modify a class, then the copy will replace the >> original in a short future, and you should better keep the >> associations untouched and only change them in a final Namespace at: >> className put: theClassCopy... >> If the purpose is to create a new class, then yes, there's some >> additional operation required. >> But where will you bind the new association? Another namespace? >> > > I agree. If copy is supposed to create a fully-fledged copy then the > Class>>copy method is broken in several ways: > - As Mariano noted, it doesn't copy CompiledMethods nor update their > methodClass associations. > - It doesn't add the copy to the superclass's subclass > - the class has the same name as the original but isn't reachable from > Smalltalk > > But if the use case is some temporary transformation, as Nicholas notes, > then the method is ok. Except that "copy" is a really unhelpful name. > This is a specialised copy for certain circumstances and the selevtor > should reflect that. Anyone know what the use case this copy was written > for is? > It's clearly for the ClassBuilder. See SystemNavigation new browseAllCallsOn: #copy localTo: ClassBuilder. SO the comment could be more helpful, e.g. copy "Answer a copy of the receiver without a list of subclasses. This copy is used by the ClassBuilder when mutating classes on redefinition. (SystemNavigation new browseAllCallsOn: #copy localTo: ClassBuilder)" > > >> Nicolas >> >> 2012/5/13 Igor Stasenko <siguctua(a)gmail.com>: >> > yes, this looks like a bug. >> > But i would recompile all methods of copied class, so all these >> > nuances is handled. >> > >> > On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> >> >> >> >> On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse >> >> <stephane.ducasse(a)inria.fr> wrote: >> >>> >> >>> >> >>> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: >> >>> >> >>> > Hi guys. The last literal of a instance-side compiled method always >> >>> > points to the SAME (#==) association of the class in Smalltalk >> global. >> >>> > The literals of a compiled method that refer to class variables >> refer to >> >>> > the same association (#==) of the classPool of its class: >> >>> > >> >>> > self assert: ((GRPlatform class >> #current) literalAt: 1) == >> >>> > (GRPlatform classPool associationAt: #Current). -> true >> >>> > >> >>> > However, if I do a copy of the class: >> >>> > >> >>> > | copy | >> >>> > copy := GRPlatform copy. >> >>> > self assert: ((copy class >> #current) literalAt: 1) == (copy >> classPool >> >>> > associationAt: #Current). >> >>> > >> >>> > this is not true anymore. Of course, you can see this because of the >> >>> > Class >> #copy implementation: >> >>> > >> >>> > So my question is....is #copy breaking the contract (and therefore >> it >> >>> > has to be fixed) or this is not mandatory for the system (as it is >> with the >> >>> > last literal pointing to classes)? >> >>> >> >>> since namespace binding are shared between method literal and >> namespace, I >> >>> think that this is a bug. >> >>> >> >> >> >> I did this workaround >> >> >> >> Class >> rebindClassVariablesInMethods >> >> >> >> self class methodDict valuesDo: [ :aCompiledMethod | >> >> 1 to: aCompiledMethod numLiterals-2 do: [ :index | >> >> | literal | >> >> literal := aCompiledMethod literalAt: index. >> >> literal isVariableBinding ifTrue: [ >> >> (self innerBindingOf: literal key) ifNotNil: >> [:aBinding | >> >> aCompiledMethod literalAt: index put: aBinding >> >> ] >> >> ] >> >> ] >> >> ] >> >> >> >>> >> >>> Stef >> >>> > >> >>> > Thanks, >> >>> > >> >>> > -- >> >>> > Mariano >> >>> > http://marianopeck.wordpress.com >> >>> > >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Mariano >> >> http://marianopeck.wordpress.com >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> > >> >> > > > -- > best, > Eliot > > -- best, Eliot

May 15, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Eliot Miranda

On Sun, May 13, 2012 at 5:31 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > It depends of the usage of copy... > If the purpose is to modify a class, then the copy will replace the > original in a short future, and you should better keep the > associations untouched and only change them in a final Namespace at: > className put: theClassCopy... > If the purpose is to create a new class, then yes, there's some > additional operation required. > But where will you bind the new association? Another namespace? > I agree. If copy is supposed to create a fully-fledged copy then the Class>>copy method is broken in several ways: - As Mariano noted, it doesn't copy CompiledMethods nor update their methodClass associations. - It doesn't add the copy to the superclass's subclass - the class has the same name as the original but isn't reachable from Smalltalk But if the use case is some temporary transformation, as Nicholas notes, then the method is ok. Except that "copy" is a really unhelpful name. This is a specialised copy for certain circumstances and the selevtor should reflect that. Anyone know what the use case this copy was written for is? > Nicolas > > 2012/5/13 Igor Stasenko <siguctua(a)gmail.com>: > > yes, this looks like a bug. > > But i would recompile all methods of copied class, so all these > > nuances is handled. > > > > On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > >> > >> > >> On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> > >>> > >>> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: > >>> > >>> > Hi guys. The last literal of a instance-side compiled method always > >>> > points to the SAME (#==) association of the class in Smalltalk > global. > >>> > The literals of a compiled method that refer to class variables > refer to > >>> > the same association (#==) of the classPool of its class: > >>> > > >>> > self assert: ((GRPlatform class >> #current) literalAt: 1) == > >>> > (GRPlatform classPool associationAt: #Current). -> true > >>> > > >>> > However, if I do a copy of the class: > >>> > > >>> > | copy | > >>> > copy := GRPlatform copy. > >>> > self assert: ((copy class >> #current) literalAt: 1) == (copy > classPool > >>> > associationAt: #Current). > >>> > > >>> > this is not true anymore. Of course, you can see this because of the > >>> > Class >> #copy implementation: > >>> > > >>> > So my question is....is #copy breaking the contract (and therefore it > >>> > has to be fixed) or this is not mandatory for the system (as it is > with the > >>> > last literal pointing to classes)? > >>> > >>> since namespace binding are shared between method literal and > namespace, I > >>> think that this is a bug. > >>> > >> > >> I did this workaround > >> > >> Class >> rebindClassVariablesInMethods > >> > >> self class methodDict valuesDo: [ :aCompiledMethod | > >> 1 to: aCompiledMethod numLiterals-2 do: [ :index | > >> | literal | > >> literal := aCompiledMethod literalAt: index. > >> literal isVariableBinding ifTrue: [ > >> (self innerBindingOf: literal key) ifNotNil: [:aBinding > | > >> aCompiledMethod literalAt: index put: aBinding > >> ] > >> ] > >> ] > >> ] > >> > >>> > >>> Stef > >>> > > >>> > Thanks, > >>> > > >>> > -- > >>> > Mariano > >>> > http://marianopeck.wordpress.com > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- best, Eliot

May 15, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Eliot Miranda

On Sat, May 12, 2012 at 3:05 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. The last literal of a instance-side compiled method always points > to the SAME (#==) association of the class in Smalltalk global. > The literals of a compiled method that refer to class variables refer to > the same association (#==) of the classPool of its class: > > self assert: ((GRPlatform class >> #current) literalAt: 1) == (GRPlatform > classPool associationAt: #Current). -> true > > However, if I do a copy of the class: > > | copy | > copy := GRPlatform copy. > self assert: ((copy class >> #current) literalAt: 1) == (copy classPool > associationAt: #Current). > > this is not true anymore. Of course, you can see this because of the Class > >> #copy implementation: > > So my question is....is #copy breaking the contract (and therefore it has > to be fixed) or this is not mandatory for the system (as it is with the > last literal pointing to classes)? > Yes. Class>>copy: is broken. Not changing the associations (on the class side as well) at the very least breaks super sends. -- best, Eliot

May 15, 2012

Re: [Pharo-project] About the new release process

by Esteban Lorenzano

Hi, I don't understand completely your question... PharoXX repositories are for integrated stuff (by version) and just integrators can access there. PharoInbox is the place where stuff who need to be integrated goes... always tracked by an issue in the issue tracker. So, we can know if it belongs to 1.4 or 2.0 just because we have more information than just the packages commited. Ideally, if you want to fix something, you need to do it, then create a slice, commit it to inbox, then announce in bugtracker "FixReviewNeeded", then we review and if everything is ok, we integrate it :) (In fact, we are not going to integrate anything that is absent from tracker, because otherwise it is going to be really hard to see) best, Esteban On May 15, 2012, at 5:45 PM, Ben Coman wrote: > Sean P. DeNigris wrote: >> EstebanLM wrote >> >>> our new release process... >>> two bug fix releases at month 4 and month 8... During this year we'll also release bugfix versions of Pharo 1.4. >>> >> >> This is exciting because as soon as a version is released, everyone starts >> pounding on it and inevitably finding bugs. It will be nice to have those >> fixes go into the current version instead of instantly starting to focus on >> the next major version months or a year away. >> >> I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How >> do we get fixes into the 1.4 bug release versions? If we make a slice off >> the 1.4 package, there may be many conflicts merging into 2.0, but if we >> merge in the future version, there will be many 2.0-only changes that have >> nothing to do with the fix, won't there? What's the protocol? And now that >> we're time-based, what's the date for the first bug fix release? >> >> > > I have been considering asking similar questions for a while. First, can someone confirm and clarify my understanding of the purpose of the standard repositories... > > * Pharo14 - Read Only. I see five admins who presumably are the only integrators who can commit to the repository. I assume that at the time Pharo 1.4 was released, the latest versions in this repository exactly matched loaded into the released image. I assume this is now low traffic, but browsing this repository I see some packages have updates. Are these the ones that will form the basis of a Pharo 1.4.1 maintenance release? > > * PharoInbox - Read/Write. Anyone can submit packages here to await review by testers and integrators. > * PharoTreatedInbox - Read Only. Squeaksource says "Repository for packages from the inbox that are either released or reject by the release team" but I am not clear on whether "released" means items accepted into the mainline Pharo14 repository are copied to PharoTreatedInbox as well as going to the Pharo14 repository. > > * Pharo20 - Read Only. Active HEAD of Pharo development. > > What I am not clear on is how the integrators know whether a submission to PharoInbox is based off Pharo 1.4 or 2.0. From previous discussions it seems a possibility that due to limited resources a community submission to fix something in 1.4 might just be consumed into the mainline 2.0 and not backported to 1.4. Not withstanding that I understand and support the desire to push forward as fast as possible, as a business user trying to stabilize a deployed product this would be annoying. Note that I am referring here to user community contributions and not how mainline developers choose which version in which to attack ticketed issues. > > So then, an uncertain proposal... to create a Pharo14MaintInbox repository for contributions submitted from within a Pharo1.4 image. Optionally, any package accepted from Pharo14MaintInbox into Pharo14 could incrementally copied at that time into the mainline 2.0 PharoInbox, so as not to lose any fixes that might carry over to mainline 2.0. Alternatively, this might be done in one go when a tested 1.4.1 maintenance version is released. > > cheers -ben > > > > > > >

May 15, 2012