- Pharo-dev - lists.pharo.org

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

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

by Esteban Lorenzano

Hi, On May 14, 2012, at 8:45 PM, 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. yep... that's the idea... :) > 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? relevant issues for 1.4 are tagged now 2.0/1.4... some others just 1.4 (not many). What we considered non-relevant were re-tagged just 2.0... maybe we made a mistake in our review, but we are willing to retag them if someone has other feelings :) now... the slices can be applied in both versions or be version specific... the bugtracker keeps the information needed to the integration. times, times... we still didn't thought on times for versions release for 1.4 because we are still adjusting all to the process... but I think some time on july is good for first 1.4 release and maybe october for lastest... in any case, we are doing regular 1.4 integrations (weekly), that incorporates some bugfixes. best, Esteban

May 15, 2012

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

by Ben Coman

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

Re: [Pharo-project] Problem with Zinc?

by Sven Van Caekenberghe

Damien, On 15 May 2012, at 16:42, Damien Cassou wrote: > ZnClient new > systemPolicy; > multiPartFormDataEntity; > http; > host: 'http://code.google.com'; > path: '/p/pharo/issues/entry.do'; > queryAt: 'summary' put: 'A summary text', Date today asString; > queryAt: 'comment' put: 'A short comment'; > post Please try: ZnClient new logToTranscript; http; host: 'code.google.com'; path: '/p/pharo/issues/entry.do'; formAt: 'summary' put: 'A summary text', Date today asString; formAt: 'comment' put: 'A short comment'; post. It still gives a bad request. I suppose you are trying to submit a form, maybe you did not add enough form fields, maybe you need a session id or cookie, or authentication. The hang occured in my 1.4 image as well and is probably related to the 'http://' in the host field and DNS resolving. I can't say for sure, since I couldn't do an interrupt and debug. HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 15, 2012

Re: [Pharo-project] Pharo Kernel 2.0 Reload by Fuel activated

by Mariano Martinez Peck

On Tue, May 15, 2012 at 4:51 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 15/05/12 3:21 AM, Pavel Krivanek wrote: > >> >> The resultant image is not production-ready because Fuel Package >> Loader currently doesn't work with changes file. >> > > What does this mean? Is Fuel Package Loader supposed to append > corresponding source to the changes file, when compiled methods are loaded > via fuel? Shouldn't that be optional? > > Hi. First, let me say that FuelPackageLoader is just a baby borning. Nothing is decied completly yet. So far, the best design we have in mind is: 1) The user can export/import packages without source code. This serialization goes into a file. Say we call it yourPackage.fuel. The application can be run, deployed, and even browse decompiled code. Nothing go to .changes. 2) The user has ANOTHER possibility to ALSO serialize source code. That does not mean just source code but also timestamp, class commetns, etc. Then during import, we should do kind of waht monticello does: include source code in the system (.changes or whatever). This would be in a differnt file (also serialized with fuel, and also being a binary fuel) called it for example, yourPackage.source So you can distribute your app with or without source code. Well, that's the plans at least we have with Martin so far. 1) is working quite well (but still there are work to do). 2) is not even started (and that's why Martin is in GSoC). is this clear? This setup reminds me of .SLL files used in VSE (Visual Smalltalk > Enterprise). You could start with a "frozen" base image, and on startup, > load all your application code through .SLL "library units". (I can't > remember whether or not you could dynamically link/unlink the .SLL > packages; I think you could.) > > I don't know such details but indeed it looks similar. Cheers -- Mariano http://marianopeck.wordpress.com

May 15, 2012