The Trunk: Collections-cmm.541.mcz
Locked
 
|
Chris Muller uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-cmm.541.mcz ==================== Summary ==================== Name: Collections-cmm.541 Author: cmm Time: 15 October 2013, 2:08:54.58 pm UUID: 412ef59f-6c4a-4844-94b8-137546e2f0f0 Ancestors: Collections-nice.540 - Revert addition of WriteStream>>#endEntry. - Fix to recent Transcripter change. =============== Diff against Collections-nice.540 =============== Item was changed: ----- Method: Transcripter>>readEvalPrint (in category 'command line') ----- readEvalPrint | line okToRevert | okToRevert := true. [#('quit' 'exit' 'done' ) includes: (line := self request: '>')] whileFalse: [line = 'revert' ifTrue: [okToRevert + ifTrue: [RecentMessages default revertMostRecent. - ifTrue: [RecentMessages default revertLastMethodSubmission. self cr; show: 'reverted: ' , RecentMessages default mostRecent. okToRevert := false] ifFalse: [self cr; show: 'Only one level of revert currently supported']] ifFalse: [self cr; show: ([Compiler evaluate: line] ifError: [:err :ex | err])]]! Item was removed: - ----- Method: WriteStream>>endEntry (in category 'compatibility') ----- - endEntry - "No-op for compatibility with TranscriptStream."! Item was changed: + ----- Method: WriteStream>>flush (in category 'accessing') ----- - ----- Method: WriteStream>>flush (in category 'compatibility') ----- flush! |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On 15 October 2013 20:09, <[hidden email]> wrote:
> Chris Muller uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-cmm.541.mcz > > ==================== Summary ==================== > > Name: Collections-cmm.541 > Author: cmm > Time: 15 October 2013, 2:08:54.58 pm > UUID: 412ef59f-6c4a-4844-94b8-137546e2f0f0 > Ancestors: Collections-nice.540 > > - Revert addition of WriteStream>>#endEntry. > - Fix to recent Transcripter change. > > =============== Diff against Collections-nice.540 =============== > > Item was changed: > ----- Method: Transcripter>>readEvalPrint (in category 'command line') ----- > readEvalPrint > | line okToRevert | > okToRevert := true. > [#('quit' 'exit' 'done' ) includes: (line := self request: '>')] > whileFalse: > [line = 'revert' > ifTrue: [okToRevert > + ifTrue: [RecentMessages default revertMostRecent. > - ifTrue: [RecentMessages default revertLastMethodSubmission. > self cr; show: 'reverted: ' , RecentMessages default mostRecent. > okToRevert := false] I realise I'm the guy who touched this last, but it looks completely wrong. I mean, the new name's an improvement. But we revert the most recent submission, and then say that we reverted the _new_ most recent submission... which was surely the _second_ most recent submission?! Maybe that block needs to say ifTrue: [ |reverted| reverted := RecentMessages default mostRecent. RecentMessages default revertMostRecent. self cr; show: 'reverted: ', reverted printString. okToRevert := false] ? frank |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On 15-10-2013, at 2:40 PM, Frank Shearar <[hidden email]> wrote: > . But we revert the most > recent submission, and then say that we reverted the _new_ most recent > submission... which was surely the _second_ most recent submission?! > > Maybe that block needs to say > > ifTrue: [ |reverted| > reverted := RecentMessages default mostRecent. > RecentMessages default revertMostRecent. > self cr; show: 'reverted: ', reverted printString. > okToRevert := false] > > ? I *think* you're right. I'm also a bit puzzled why we can't then revert the new most-recent etc and work our way back several bad choices to possible redemption. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim There are two ways to write error-free programs; only the third one works. |
Re: The Trunk: Collections-cmm.541.mcz
|
|
In reply to this post by Frank Shearar-3
The only thing I did to this method was to fix the selector -- there
was no implementor of #revertLastMethodSubmission on RecentMessages. It never got moved/copied from Utilities. > I realise I'm the guy who touched this last, but it looks completely > wrong. I mean, the new name's an improvement. But we revert the most > recent submission, and then say that we reverted the _new_ most recent > submission... which was surely the _second_ most recent submission?! I don't think so. A installation of any method, whether by save or revert, makes it the most-recent submission, irregardless of its prior position / existence in the list. > Maybe that block needs to say > > ifTrue: [ |reverted| > reverted := RecentMessages default mostRecent. > RecentMessages default revertMostRecent. > self cr; show: 'reverted: ', reverted printString. > okToRevert := false] > > ? > > frank > |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On 16 Oct 2013, at 3:25, Chris Muller <[hidden email]> wrote:
> The only thing I did to this method was to fix the selector -- there > was no implementor of #revertLastMethodSubmission on RecentMessages. > It never got moved/copied from Utilities. Huh. It wouldn't be the first time I'd missed something. Thanks! >> I realise I'm the guy who touched this last, but it looks completely >> wrong. I mean, the new name's an improvement. But we revert the most >> recent submission, and then say that we reverted the _new_ most recent >> submission... which was surely the _second_ most recent submission?! > > I don't think so. A installation of any method, whether by save or > revert, makes it the most-recent submission, irregardless of its prior > position / existence in the list. That's my point. Given submissions in order of a, b, c the most recent is c. We revert that, and then ask what the most recent submission is, to display to the user. But most recent now means b! frank >> 453177 that block needs to say >> >> ifTrue: [ |reverted| >> reverted := RecentMessages default mostRecent. >> RecentMessages default revertMostRecent. >> self cr; show: 'reverted: ', reverted printString. >> okToRevert := false] >> >> ? >> >> frank >> > |
Re: The Trunk: Collections-cmm.541.mcz
|
|
In reply to this post by timrowledge
On 15 Oct 2013, at 22:56, tim Rowledge <[hidden email]> wrote:
> > On 15-10-2013, at 2:40 PM, Frank Shearar <[hidden email]> wrote: >> . But we revert the most >> recent submission, and then say that we reverted the _new_ most recent >> submission... which was surely the _second_ most recent submission?! >> >> Maybe that block needs to say >> >> ifTrue: [ |reverted| >> reverted := RecentMessages default mostRecent. >> RecentMessages default revertMostRecent. >> self cr; show: 'reverted: ', reverted printString. >> okToRevert := false] >> >> ? > > I *think* you're right. I'm also a bit puzzled why we can't then revert the new most-recent etc and work our way back several bad choices to possible redemption. I need to fix Transcripter anyway, and make it a serious tool in its own right (and its own package - why oh why is it in Collections?!) so we can add this to the feature list! Which makes me think that a bug report in a new category is in order, so we can fail to forget this feature! frank > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > There are two ways to write error-free programs; only the third one works. > > > |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On 16.10.2013, at 09:29, Frank Shearar <[hidden email]> wrote:
> I need to fix Transcripter anyway, and make it a serious tool in its own right But keep in mind that it needs to be as self-sufficient as possible - its sole purpose is to be used when the system is seriously broken. - Bert - |
Re: The Trunk: Collections-cmm.541.mcz
|
|
In reply to this post by Frank Shearar-3
>>> I realise I'm the guy who touched this last, but it looks completely
>>> wrong. I mean, the new name's an improvement. But we revert the most >>> recent submission, and then say that we reverted the _new_ most recent >>> submission... which was surely the _second_ most recent submission?! >> >> I don't think so. A installation of any method, whether by save or >> revert, makes it the most-recent submission, irregardless of its prior >> position / existence in the list. > > That's my point. Given submissions in order of a, b, c the most recent is c. We revert that, and then ask what the most recent submission is, to display to the user. But most recent now means b! It sounds like you're thinking that "most-recent submission" means "the one with the latest timestamp" but that is not the case. Timestamps do not come into play at all w.r.t. recent submissions. It's simply the order of installations of methods, whether the method is from 2013 or 2002. The only scenario I can think of that matches your description would be if "c" was a brand-new method addition, and revertMostRecent would therefore cause it to be deleted. |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On 16 October 2013 15:53, Chris Muller <[hidden email]> wrote:
>>>> I realise I'm the guy who touched this last, but it looks completely >>>> wrong. I mean, the new name's an improvement. But we revert the most >>>> recent submission, and then say that we reverted the _new_ most recent >>>> submission... which was surely the _second_ most recent submission?! >>> >>> I don't think so. A installation of any method, whether by save or >>> revert, makes it the most-recent submission, irregardless of its prior >>> position / existence in the list. >> >> That's my point. Given submissions in order of a, b, c the most recent is c. We revert that, and then ask what the most recent submission is, to display to the user. But most recent now means b! > > It sounds like you're thinking that "most-recent submission" means > "the one with the latest timestamp" but that is not the case. > Timestamps do not come into play at all w.r.t. recent submissions. > It's simply the order of installations of methods, whether the method > is from 2013 or 2002. My point is this: the method submissions _are_ ordered, if nothing else than because they're in an OrderedCollection. (*) So: a := OrderedCollection with: 1 with: 2 with: 3. Transcript showln: 'About to remove ', a last printString. a removeLast. Transcript showln: 'Removed ', a last printString That gives About to remove 3 Removed 2 Because you removed the last item in the collection! Unless I'm completely mistaken, that's what the Transcripter is currently saying! frank (*) The pedant in me insists on mentioning that since all method submissions in an image occur from one process, and from a user, that they _are_ ordered by timestamp. |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On Wed, Oct 16, 2013 at 10:09 AM, Frank Shearar <[hidden email]> wrote:
> On 16 October 2013 15:53, Chris Muller <[hidden email]> wrote: >>>>> I realise I'm the guy who touched this last, but it looks completely >>>>> wrong. I mean, the new name's an improvement. But we revert the most >>>>> recent submission, and then say that we reverted the _new_ most recent >>>>> submission... which was surely the _second_ most recent submission?! >>>> >>>> I don't think so. A installation of any method, whether by save or >>>> revert, makes it the most-recent submission, irregardless of its prior >>>> position / existence in the list. >>> >>> That's my point. Given submissions in order of a, b, c the most recent is c. We revert that, and then ask what the most recent submission is, to display to the user. But most recent now means b! >> >> It sounds like you're thinking that "most-recent submission" means >> "the one with the latest timestamp" but that is not the case. >> Timestamps do not come into play at all w.r.t. recent submissions. >> It's simply the order of installations of methods, whether the method >> is from 2013 or 2002. > > My point is this: the method submissions _are_ ordered, if nothing > else than because they're in an OrderedCollection. (*) > > So: > > a := OrderedCollection with: 1 with: 2 with: 3. > Transcript showln: 'About to remove ', a last printString. > a removeLast. > Transcript showln: 'Removed ', a last printString > > That gives > > About to remove 3 > Removed 2 > > Because you removed the last item in the collection! Unless I'm > completely mistaken, that's what the Transcripter is currently saying! Sounds like we're in violent agreement. That's what I was saying in my last paragraph of my last message, (e.g., "The only scenario..."). But, as I said, I was only correcting the method name, not trying to fix the scenario of reverting a brand-new method addition. > (*) The pedant in me insists on mentioning that since all method > submissions in an image occur from one process, and from a user, that > they _are_ ordered by timestamp. Not necessarily. They're ordered by the sequence they're installed, irregardless of their timestamp. If you, as a user, revert a 2013 method back to a 2002 method, the 2002 method is put to the top of the list as the "most-recent submission". |
Re: The Trunk: Collections-cmm.541.mcz
|
|
On 16 October 2013 17:24, Chris Muller <[hidden email]> wrote:
> On Wed, Oct 16, 2013 at 10:09 AM, Frank Shearar <[hidden email]> wrote: >> On 16 October 2013 15:53, Chris Muller <[hidden email]> wrote: >>>>>> I realise I'm the guy who touched this last, but it looks completely >>>>>> wrong. I mean, the new name's an improvement. But we revert the most >>>>>> recent submission, and then say that we reverted the _new_ most recent >>>>>> submission... which was surely the _second_ most recent submission?! >>>>> >>>>> I don't think so. A installation of any method, whether by save or >>>>> revert, makes it the most-recent submission, irregardless of its prior >>>>> position / existence in the list. >>>> >>>> That's my point. Given submissions in order of a, b, c the most recent is c. We revert that, and then ask what the most recent submission is, to display to the user. But most recent now means b! >>> >>> It sounds like you're thinking that "most-recent submission" means >>> "the one with the latest timestamp" but that is not the case. >>> Timestamps do not come into play at all w.r.t. recent submissions. >>> It's simply the order of installations of methods, whether the method >>> is from 2013 or 2002. >> >> My point is this: the method submissions _are_ ordered, if nothing >> else than because they're in an OrderedCollection. (*) >> >> So: >> >> a := OrderedCollection with: 1 with: 2 with: 3. >> Transcript showln: 'About to remove ', a last printString. >> a removeLast. >> Transcript showln: 'Removed ', a last printString >> >> That gives >> >> About to remove 3 >> Removed 2 >> >> Because you removed the last item in the collection! Unless I'm >> completely mistaken, that's what the Transcripter is currently saying! > > Sounds like we're in violent agreement. That's what I was saying in > my last paragraph of my last message, (e.g., "The only scenario..."). > > But, as I said, I was only correcting the method name, not trying to > fix the scenario of reverting a brand-new method addition. I know - that's why I said I was happy with your change, and thought that the basic idea of the _context_ of the change seemed wrong. >> (*) The pedant in me insists on mentioning that since all method >> submissions in an image occur from one process, and from a user, that >> they _are_ ordered by timestamp. > > Not necessarily. They're ordered by the sequence they're installed, > irregardless of their timestamp. If you, as a user, revert a 2013 > method back to a 2002 method, the 2002 method is put to the top of the > list as the "most-recent submission". And "the sequence they're installed" means "ordered by wall clock time", assuming a clock that doesn't run backwards. This is what I mean when I say "timestamp". So, er, yes, seems like we are in violent agreement. But the method's still wrong :) It claims to have reverted something that it has not. frank |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |