The Trunk: Collections-fbs.516.mcz
Locked
 
|
Frank Shearar uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-fbs.516.mcz ==================== Summary ==================== Name: Collections-fbs.516 Author: fbs Time: 1 May 2013, 10:14:23.588 pm UUID: e787006a-d096-47f3-93da-c4681285fae2 Ancestors: Collections-ul.515 Surrounding the -> in an Assocation in printed form allows the left side to be a binary selector without things breaking: #* -> #+ otherwise prints as '#*->#+', which is the Symbol #*-> followed by garbage. =============== Diff against Collections-ul.515 =============== Item was changed: ----- Method: Association>>printOn: (in category 'printing') ----- printOn: aStream super printOn: aStream. + "If the key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." + aStream nextPutAll: ' -> '. - aStream nextPutAll: '->'. value printOn: aStream! Item was changed: ----- Method: Association>>storeOn: (in category 'printing') ----- storeOn: aStream "Store in the format (key->value)" aStream nextPut: $(. key storeOn: aStream. + "If key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." + aStream nextPutAll: ' -> '. - aStream nextPutAll: '->'. value storeOn: aStream. aStream nextPut: $)! |
Re: The Trunk: Collections-fbs.516.mcz
|
|
Hmph -- since you were asking for consensus on something, it would be
nice to have a little more time to respond -- as I did in < 24 hours, but still apparently too late. didn't get much discussion. ay we please have more time On Thu, May 2, 2013 at 5:56 AM, <[hidden email]> wrote: > Frank Shearar uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-fbs.516.mcz > > ==================== Summary ==================== > > Name: Collections-fbs.516 > Author: fbs > Time: 1 May 2013, 10:14:23.588 pm > UUID: e787006a-d096-47f3-93da-c4681285fae2 > Ancestors: Collections-ul.515 > > Surrounding the -> in an Assocation in printed form allows the left side to be a binary selector without things breaking: #* -> #+ otherwise prints as '#*->#+', which is the Symbol #*-> followed by garbage. > > =============== Diff against Collections-ul.515 =============== > > Item was changed: > ----- Method: Association>>printOn: (in category 'printing') ----- > printOn: aStream > > super printOn: aStream. > + "If the key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." > + aStream nextPutAll: ' -> '. > - aStream nextPutAll: '->'. > value printOn: aStream! > > Item was changed: > ----- Method: Association>>storeOn: (in category 'printing') ----- > storeOn: aStream > "Store in the format (key->value)" > aStream nextPut: $(. > key storeOn: aStream. > + "If key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." > + aStream nextPutAll: ' -> '. > - aStream nextPutAll: '->'. > value storeOn: aStream. > aStream nextPut: $)! > > |
Re: The Trunk: Collections-fbs.516.mcz
|
|
On 2 May 2013 19:19, Chris Muller <[hidden email]> wrote:
> Hmph -- since you were asking for consensus on something, it would be > nice to have a little more time to respond -- as I did in < 24 hours, > but still apparently too late. > > > didn't get much discussion. ay we please have more time Sure. In my defence, this was seriously getting in my way... but I guess the response to that is "well keep the change in your image". Ah, well. frank > On Thu, May 2, 2013 at 5:56 AM, <[hidden email]> wrote: >> Frank Shearar uploaded a new version of Collections to project The Trunk: >> http://source.squeak.org/trunk/Collections-fbs.516.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-fbs.516 >> Author: fbs >> Time: 1 May 2013, 10:14:23.588 pm >> UUID: e787006a-d096-47f3-93da-c4681285fae2 >> Ancestors: Collections-ul.515 >> >> Surrounding the -> in an Assocation in printed form allows the left side to be a binary selector without things breaking: #* -> #+ otherwise prints as '#*->#+', which is the Symbol #*-> followed by garbage. >> >> =============== Diff against Collections-ul.515 =============== >> >> Item was changed: >> ----- Method: Association>>printOn: (in category 'printing') ----- >> printOn: aStream >> >> super printOn: aStream. >> + "If the key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." >> + aStream nextPutAll: ' -> '. >> - aStream nextPutAll: '->'. >> value printOn: aStream! >> >> Item was changed: >> ----- Method: Association>>storeOn: (in category 'printing') ----- >> storeOn: aStream >> "Store in the format (key->value)" >> aStream nextPut: $(. >> key storeOn: aStream. >> + "If key is a binary selector and we don't use whitespace, we will stream (key, '->') asSymbol." >> + aStream nextPutAll: ' -> '. >> - aStream nextPutAll: '->'. >> value storeOn: aStream. >> aStream nextPut: $)! >> >> > |
Re: The Trunk: Collections-fbs.516.mcz
|
|
On 2013-05-02, at 20:49, Frank Shearar <[hidden email]> wrote: > On 2 May 2013 19:19, Chris Muller <[hidden email]> wrote: >> Hmph -- since you were asking for consensus on something, it would be >> nice to have a little more time to respond -- as I did in < 24 hours, >> but still apparently too late. >> >> >> didn't get much discussion. ay we please have more time > > Sure. In my defence, this was seriously getting in my way... but I > guess the response to that is "well keep the change in your image". > Ah, well. > > frank Maybe you should try my "allow partial commits" Monticello mod (Monticello-bf.540 in inbox). I have been using it for months now and it works really well. Back in January I got a few +1s but Chris was opposed so I did not put it into trunk, yet. I have not found the time to add the "do yet another snapshot when pressing save" Chris wanted because in my workflow it's not needed. But perhaps it's good enough? For me it certainly was a relief keeping some changes to my image while still being able to commit "clean" packages to trunk. - Bert - |
Re: The Trunk: Collections-fbs.516.mcz
|
|
A possible side effect with this scenario: If so, that might be a problem when later trying to merge Z again in another image...1) I merge load trunk package version X 2) I merge a third-party version Z, 3) I partially publish version Y without the Z changes. Will Z figure in the Y ancestors? 2013/5/3 Bert Freudenberg <[hidden email]>
|
Re: The Trunk: Collections-fbs.516.mcz
|
|
Good point, I'm not sure. Colin? If this is a problem we should disallow/warn about partial commits from merges. - Bert - On 2013-05-03, at 13:23, Nicolas Cellier <[hidden email]> wrote:
|
Re: The Trunk: Collections-fbs.516.mcz
|
|
In reply to this post by Bert Freudenberg
Let's talk about rationales before votes ok? I figure we're all on
the same page: that since Save implies Review, the goal is to integrate those two activities together on the Save dialog. Are we good so far? Monticello-bf.540 addresses it very nicely except for the fact that Review implies Fix. When the actor arrives at Fix he's stuck, and the original goal of Save+Review integration has been subverted. Save, once again, at this point must be a very separate, and now ungraceful act, given what the actor is put through to simply save the contents of the reviewed-and-fixed package as we can today. Maybe I'm missing another use-case that describes what you want to do, and if so maybe it should be a preference or a separate function with its own button..? On Fri, May 3, 2013 at 5:12 AM, Bert Freudenberg <[hidden email]> wrote: > > On 2013-05-02, at 20:49, Frank Shearar <[hidden email]> wrote: > >> On 2 May 2013 19:19, Chris Muller <[hidden email]> wrote: >>> Hmph -- since you were asking for consensus on something, it would be >>> nice to have a little more time to respond -- as I did in < 24 hours, >>> but still apparently too late. >>> >>> >>> didn't get much discussion. ay we please have more time >> >> Sure. In my defence, this was seriously getting in my way... but I >> guess the response to that is "well keep the change in your image". >> Ah, well. >> >> frank > > > Maybe you should try my "allow partial commits" Monticello mod (Monticello-bf.540 in inbox). I have been using it for months now and it works really well. Back in January I got a few +1s but Chris was opposed so I did not put it into trunk, yet. I have not found the time to add the "do yet another snapshot when pressing save" Chris wanted because in my workflow it's not needed. But perhaps it's good enough? For me it certainly was a relief keeping some changes to my image while still being able to commit "clean" packages to trunk. > > - Bert - > > > |
Re: The Trunk: Collections-fbs.516.mcz
|
|
In reply to this post by Bert Freudenberg
What is a partial commit and when/why do I want to do it?
On Fri, May 3, 2013 at 6:42 AM, Bert Freudenberg <[hidden email]> wrote: > Good point, I'm not sure. Colin? If this is a problem we should > disallow/warn about partial commits from merges. > > - Bert - > > On 2013-05-03, at 13:23, Nicolas Cellier > <[hidden email]> wrote: > > A possible side effect with this scenario: > > 1) I merge load trunk package version X > 2) I merge a third-party version Z, > 3) I partially publish version Y without the Z changes. > > Will Z figure in the Y ancestors? > If so, that might be a problem when later trying to merge Z again in another > image... > > Nicolas > > > 2013/5/3 Bert Freudenberg <[hidden email]> >> >> >> On 2013-05-02, at 20:49, Frank Shearar <[hidden email]> wrote: >> >> > On 2 May 2013 19:19, Chris Muller <[hidden email]> wrote: >> >> Hmph -- since you were asking for consensus on something, it would be >> >> nice to have a little more time to respond -- as I did in < 24 hours, >> >> but still apparently too late. >> >> >> >> >> >> didn't get much discussion. ay we please have more time >> > >> > Sure. In my defence, this was seriously getting in my way... but I >> > guess the response to that is "well keep the change in your image". >> > Ah, well. >> > >> > frank >> >> >> Maybe you should try my "allow partial commits" Monticello mod >> (Monticello-bf.540 in inbox). I have been using it for months now and it >> works really well. Back in January I got a few +1s but Chris was opposed so >> I did not put it into trunk, yet. I have not found the time to add the "do >> yet another snapshot when pressing save" Chris wanted because in my workflow >> it's not needed. But perhaps it's good enough? For me it certainly was a >> relief keeping some changes to my image while still being able to commit >> "clean" packages to trunk. >> >> - Bert - >> >> >> > > > > > > |
Re: The Trunk: Collections-fbs.516.mcz
|
|
A partial commit is useful when you have several unrelated changes in the same pakage and you don't want to commit them all. A clean and costly process would be to- save all changes locally (file out, local package-cache, whatever...) 2013/5/3 Chris Muller <[hidden email]> What is a partial commit and when/why do I want to do it? |
Re: The Trunk: Collections-fbs.516.mcz
|
|
Ah, yes, a partial-commit is a definite use-case. The way I handle
that today is I simply leave up the Changes window. I select the changes I want to leave behind and select "revert" on them individually. Then I click "Ok" on the Save dialog, then "install" back on the Changes window to reinstall them and continue development on them. Clumsy, for sure. Today Monticello-bf.540 has "Accept" and "Cancel" I propose we add two buttons: Refresh List -- re-snapshots the package and redisplays the list Accept List -- Commits the changes listed in the list. Accept Package -- Commits all changes to the package, whether listed or not. Cancel That way all of the use-cases are integrated together. How does that sound? On Fri, May 3, 2013 at 3:50 PM, Nicolas Cellier <[hidden email]> wrote: > A partial commit is useful when you have several unrelated changes in the > same pakage and you don't want to commit them all. > A clean and costly process would be to > - save all changes locally (file out, local package-cache, whatever...) > - download a fresh and clean up to date image > - selectively re-install some of the changes in clean image > - test > - commit > An alternative is to partially commit to a local package from the dirty > image, and load from clean. > A quick and dirty process is to directly and partially commit to inbox or > trunk from the dirty image (more dangerous, but for a few lines of changes > it rocks). > > > 2013/5/3 Chris Muller <[hidden email]> >> >> What is a partial commit and when/why do I want to do it? >> >> On Fri, May 3, 2013 at 6:42 AM, Bert Freudenberg <[hidden email]> >> wrote: >> > Good point, I'm not sure. Colin? If this is a problem we should >> > disallow/warn about partial commits from merges. >> > >> > - Bert - >> > >> > On 2013-05-03, at 13:23, Nicolas Cellier >> > <[hidden email]> wrote: >> > >> > A possible side effect with this scenario: >> > >> > 1) I merge load trunk package version X >> > 2) I merge a third-party version Z, >> > 3) I partially publish version Y without the Z changes. >> > >> > Will Z figure in the Y ancestors? >> > If so, that might be a problem when later trying to merge Z again in >> > another >> > image... >> > >> > Nicolas >> > >> > >> > 2013/5/3 Bert Freudenberg <[hidden email]> >> >> >> >> >> >> On 2013-05-02, at 20:49, Frank Shearar <[hidden email]> wrote: >> >> >> >> > On 2 May 2013 19:19, Chris Muller <[hidden email]> wrote: >> >> >> Hmph -- since you were asking for consensus on something, it would >> >> >> be >> >> >> nice to have a little more time to respond -- as I did in < 24 >> >> >> hours, >> >> >> but still apparently too late. >> >> >> >> >> >> >> >> >> didn't get much discussion. ay we please have more time >> >> > >> >> > Sure. In my defence, this was seriously getting in my way... but I >> >> > guess the response to that is "well keep the change in your image". >> >> > Ah, well. >> >> > >> >> > frank >> >> >> >> >> >> Maybe you should try my "allow partial commits" Monticello mod >> >> (Monticello-bf.540 in inbox). I have been using it for months now and >> >> it >> >> works really well. Back in January I got a few +1s but Chris was >> >> opposed so >> >> I did not put it into trunk, yet. I have not found the time to add the >> >> "do >> >> yet another snapshot when pressing save" Chris wanted because in my >> >> workflow >> >> it's not needed. But perhaps it's good enough? For me it certainly was >> >> a >> >> relief keeping some changes to my image while still being able to >> >> commit >> >> "clean" packages to trunk. >> >> >> >> - Bert - >> >> >> >> >> >> >> > >> > >> > >> > >> > >> > >> > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |