A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1292.mcz
==================== Summary ====================
Name: Kernel-ct.1292 Author: ct Time: 3 January 2020, 2:21:26.297116 am UUID: 95936a10-85a4-734e-a10b-0f87290b70f9 Ancestors: Kernel-nice.1291
Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.
For an impression of possible users, have a look at:
self systemNavigation browseMessageList: ((self systemNavigation allCallsOn: #on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel])) name: 'Potential users of #on:when:do:'
=============== Diff against Kernel-nice.1291 ===============
Item was added: + ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate do: handlerAction + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [handlerAction cull: exception] + ifFalse: [exception pass]]!
Item was added: + ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate ensure: aBlock + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [aBlock value]. + exception pass]!
Please note that the #on:when:do: proposal would be only one possible implementation. Another idea of mine was to expand ExceptionSets and implement the common exception protocol also on BlockClosure! Watch some rewritten examples based on a true image:
[self model merge]
on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty]
do: [:request | request resume: true].
[client unusedBytecode]
on: MessageNotUnderstood
& [:ex | ex receiver == client]
& [:ex | ex message selector == #unusedBytecode]
do: [self error: 'unusedBytecode'].
references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount < 2 ifTrue: [ ex return: #()] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].
(original version of the latter was: references := [ self resolvePackageSpecReferences: packageSpec gofer: gofer ] on: Error , GoferRepositoryError do: [ :ex | self class retryPackageResolution ifFalse: [ ex pass ]. retryCount >= 2 ifTrue: [ (ex isKindOf: GoferRepositoryError) ifTrue: [ Transcript showln: 'gofer repository error: ' , ex description printString , '...ignoring'. repositoryError := ex. ex resume: #() ] ifFalse: [ ex pass ] ]. ex return: #() ].
)
Another advantage against #on:when:do: would be integrated support for SUnit:
sz := 1024*1024*1024*1024.
self
should: [Array new: sz]
raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument'])
I am excited to hear your opinions about both proposals!
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Freitag, 3. Januar 2020 02:21 Uhr An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Kernel-ct.1292.mcz
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1292.mcz
==================== Summary ====================
Name: Kernel-ct.1292 Author: ct Time: 3 January 2020, 2:21:26.297116 am UUID: 95936a10-85a4-734e-a10b-0f87290b70f9 Ancestors: Kernel-nice.1291
Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.
For an impression of possible users, have a look at:
self systemNavigation browseMessageList: ((self systemNavigation allCallsOn: #on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel])) name: 'Potential users of #on:when:do:'
=============== Diff against Kernel-nice.1291 ===============
Item was added: + ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate do: handlerAction + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [handlerAction cull: exception] + ifFalse: [exception pass]]!
Item was added: + ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate ensure: aBlock + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [aBlock value]. + exception pass]!
Outlook jumbled my message completely. Here the examples again:
[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].
[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].
references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].
sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).
Note that VA Smalltalk has a legacy approach to exceptions that precedes the ANSI standard. It uses #when:do: in place of #on:do:. (Nowadays it also supports #on:do: but not for old-style exceptions in applications.) Might not a blocker for the proposed nomenclature, but you should at least be aware of it.
commits@source.squeak.org schrieb am Fr., 3. Jan. 2020, 02:21:
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1292.mcz
==================== Summary ====================
Name: Kernel-ct.1292 Author: ct Time: 3 January 2020, 2:21:26.297116 am UUID: 95936a10-85a4-734e-a10b-0f87290b70f9 Ancestors: Kernel-nice.1291
Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.
For an impression of possible users, have a look at:
self systemNavigation browseMessageList: ((self systemNavigation allCallsOn:
#on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel])) name: 'Potential users of #on:when:do:'
=============== Diff against Kernel-nice.1291 ===============
Item was added:
- ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') -----
- on: exceptionOrExceptionSet when: aPredicate do: handlerAction
^ self
on: exceptionOrExceptionSet
do: [:exception |
(aPredicate value: exception)
ifTrue: [handlerAction cull: exception]
ifFalse: [exception pass]]!
Item was added:
- ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions')
- on: exceptionOrExceptionSet when: aPredicate ensure: aBlock
^ self
on: exceptionOrExceptionSet
do: [:exception |
(aPredicate value: exception)
ifTrue: [aBlock value].
exception pass]!
Note Squeak's object events: #when:send:to:. There, "when" requires an event object as a look-up key in the event map. Usually a Symbol.
Best, Marcel Am 03.01.2020 07:43:42 schrieb Jakob Reschke forums.jakob@resfarm.de: Note that VA Smalltalk has a legacy approach to exceptions that precedes the ANSI standard. It uses #when:do: in place of #on:do:. (Nowadays it also supports #on:do: but not for old-style exceptions in applications.) Might not a blocker for the proposed nomenclature, but you should at least be aware of it.
<commits@source.squeak.org [mailto:commits@source.squeak.org]> schrieb am Fr., 3. Jan. 2020, 02:21:
A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1292.mcz [http://source.squeak.org/inbox/Kernel-ct.1292.mcz]
==================== Summary ====================
Name: Kernel-ct.1292 Author: ct Time: 3 January 2020, 2:21:26.297116 am UUID: 95936a10-85a4-734e-a10b-0f87290b70f9 Ancestors: Kernel-nice.1291
Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.
For an impression of possible users, have a look at:
self systemNavigation browseMessageList: ((self systemNavigation allCallsOn: #on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel])) name: 'Potential users of #on:when:do:'
=============== Diff against Kernel-nice.1291 ===============
Item was added: + ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate do: handlerAction + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [handlerAction cull: exception] + ifFalse: [exception pass]]!
Item was added: + ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate ensure: aBlock + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [aBlock value]. + exception pass]!
Okay, so you would prefer a different naming?
On the other side, there are many prepositions that have different meanings in different selectors ...
For example, "in:" for Objects expects an evaluable. "in:" for Compilers expects either an environment or a context.
"on:" expects either an exception, or a model, or an event name, or a stream. :)
Personally, I don't really care - each selector in Squeak is only one Cmd + M or Cmd + ArrowRight away from revealing their argument's true names. Smalltalk's complexity is just greater than the complexity of any natural language :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 6. Januar 2020 10:42:56 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Kernel-ct.1292.mcz
Note Squeak's object events: #when:send:to:. There, "when" requires an event object as a look-up key in the event map. Usually a Symbol.
Best, Marcel
Am 03.01.2020 07:43:42 schrieb Jakob Reschke forums.jakob@resfarm.de:
Note that VA Smalltalk has a legacy approach to exceptions that precedes the ANSI standard. It uses #when:do: in place of #on:do:. (Nowadays it also supports #on:do: but not for old-style exceptions in applications.) Might not a blocker for the proposed nomenclature, but you should at least be aware of it.
<commits@source.squeak.orgmailto:commits@source.squeak.org> schrieb am Fr., 3. Jan. 2020, 02:21: A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1292.mcz
==================== Summary ====================
Name: Kernel-ct.1292 Author: ct Time: 3 January 2020, 2:21:26.297116 am UUID: 95936a10-85a4-734e-a10b-0f87290b70f9 Ancestors: Kernel-nice.1291
Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.
For an impression of possible users, have a look at:
self systemNavigation browseMessageList: ((self systemNavigation allCallsOn: #on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel])) name: 'Potential users of #on:when:do:'
=============== Diff against Kernel-nice.1291 ===============
Item was added: + ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate do: handlerAction + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [handlerAction cull: exception] + ifFalse: [exception pass]]!
Item was added: + ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions') ----- + on: exceptionOrExceptionSet when: aPredicate ensure: aBlock + + ^ self + on: exceptionOrExceptionSet + do: [:exception | + (aPredicate value: exception) + ifTrue: [aBlock value]. + exception pass]!
#on:when:do: isn't a terrible idea but be aware of the all-too-common problem of getting too clever. Remember, debugging is at least twice as hard as writing code and so if you make your code as clever as you can...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
Tim, I understand the theory of your argument, but I don't see how it would apply here. Wouldn't debugging be even easier if you had two instead of one knobs for debugging?
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Montag, 6. Januar 2020 23:26:03 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Exception patterns (The Inbox: Kernel-ct.1292.mcz)
#on:when:do: isn't a terrible idea but be aware of the all-too-common problem of getting too clever. Remember, debugging is at least twice as hard as writing code and so if you make your code as clever as you can...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
Hi all,
I'd like to push this discussion again because I still do think that an #on:when:do: mechanism or whatever you'd like to call it can be useful in several situations.
One of my favorite usages is this:
[self downloadFile: aFile on: HttpError "this is from one of my packages" when: [:ex | ex statusCode = 403] do: [self inform: 'Forbidden!'].
Do I see it right that we only need to find a better name for this or am I the only one who would like to something like this in the Trunk? And would anyone be so kind and leave some feedback on my other proposal for exception conditions? :-)
[self downloadFile: aFile on: HttpError & [:ex | ex statusCode = 403] do: [self inform: 'Forbidden!'].
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Christoph,
Are these equivalent --
On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Outlook jumbled my message completely. Here the examples again:
[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].
equal to:
[self model merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts notEmpty ifTrue: [request resume: true] ifFalse: [request pass] ]
?
[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].
equal to
[client unusedBytecode] on: MessageNotUnderstood do: [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ]) ifTrue: [ self error: 'unusedBytecode' ] ifFalse: [ ex pass ] ]
?
Not sure if I fully understood it, but is it just a reformat of the syntax? Or something more empowering?
references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].
(wait, is that, #on:do:on: ? I'm confused on this one...)
- Chris
sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).
Hi Christoph,
you are proposing an interface to avoid having to deal with Exception >> #pass and #resume:. I like #on:when:do:, maybe renamed to: #on:satisfying:do:. I do not like your & syntax because it would mix Exception, ExceptionSet, and BlockClosure -- which may be hard to understand and debug.
Bset, Marcel Am 09.10.2020 03:15:43 schrieb Chris Muller asqueaker@gmail.com: Hi Christoph,
Are these equivalent --
On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]> wrote:
Outlook jumbled my message completely. Here the examples again:
[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].
equal to:
[self model merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts notEmpty ifTrue: [request resume: true] ifFalse: [request pass] ]
?
[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].
equal to
[client unusedBytecode] on: MessageNotUnderstood do: [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ]) ifTrue: [ self error: 'unusedBytecode' ] ifFalse: [ ex pass ] ]
?
Not sure if I fully understood it, but is it just a reformat of the syntax? Or something more empowering?
references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].
(wait, is that, #on:do:on: ? I'm confused on this one...)
- Chris
sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).
Hi Marcel, Hi Chris,
thanks for your feedback. I see your point of complexity, still, I think BlockClosure #& etc. could be a nice concept, but it would rather belong in an own repository (such as Xtreams, for example).
See Kernel-ct.1292/2 for the next attempt. :-)
@Chris: You're right with your interpretation, I'm aiming to get rid of this low-level #pass sends and all the condition logic inside handlerActions.
(wait, is that, #on:do:on: ? I'm confused on this one...)
Oops, this should have been #on:do:on:do: instead. But I fear this would be over-complicated anyway ...
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 9. Oktober 2020 08:57:05 An: Chris Muller; squeak-dev Betreff: Re: [squeak-dev] Exception patterns (The Inbox: Kernel-ct.1292.mcz)
Hi Christoph,
you are proposing an interface to avoid having to deal with Exception >> #pass and #resume:. I like #on:when:do:, maybe renamed to: #on:satisfying:do:. I do not like your & syntax because it would mix Exception, ExceptionSet, and BlockClosure -- which may be hard to understand and debug.
Bset, Marcel
Am 09.10.2020 03:15:43 schrieb Chris Muller asqueaker@gmail.com:
Hi Christoph,
Are these equivalent --
On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote: Outlook jumbled my message completely. Here the examples again:
[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].
equal to:
[self model merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts notEmpty ifTrue: [request resume: true] ifFalse: [request pass] ]
?
[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].
equal to
[client unusedBytecode] on: MessageNotUnderstood do: [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ]) ifTrue: [ self error: 'unusedBytecode' ] ifFalse: [ ex pass ] ]
?
Not sure if I fully understood it, but is it just a reformat of the syntax? Or something more empowering?
references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].
(wait, is that, #on:do:on: ? I'm confused on this one...)
- Chris
sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).
See Kernel-ct.1292/2 for the next attempt. :-)
Hm, no, SqueakSource has renamed it into Kernel-ct.1303. Eliot, didn't you mention that one can use slashes to create branches in Monticello?
Best, Christoph
________________________________ Von: Thiede, Christoph Gesendet: Freitag, 9. Oktober 2020 16:41:09 An: Chris Muller; squeak-dev Betreff: AW: [squeak-dev] Exception patterns (The Inbox: Kernel-ct.1292.mcz)
Hi Marcel, Hi Chris,
thanks for your feedback. I see your point of complexity, still, I think BlockClosure #& etc. could be a nice concept, but it would rather belong in an own repository (such as Xtreams, for example).
See Kernel-ct.1292/2 for the next attempt. :-)
@Chris: You're right with your interpretation, I'm aiming to get rid of this low-level #pass sends and all the condition logic inside handlerActions.
(wait, is that, #on:do:on: ? I'm confused on this one...)
Oops, this should have been #on:do:on:do: instead. But I fear this would be over-complicated anyway ...
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 9. Oktober 2020 08:57:05 An: Chris Muller; squeak-dev Betreff: Re: [squeak-dev] Exception patterns (The Inbox: Kernel-ct.1292.mcz)
Hi Christoph,
you are proposing an interface to avoid having to deal with Exception >> #pass and #resume:. I like #on:when:do:, maybe renamed to: #on:satisfying:do:. I do not like your & syntax because it would mix Exception, ExceptionSet, and BlockClosure -- which may be hard to understand and debug.
Bset, Marcel
Am 09.10.2020 03:15:43 schrieb Chris Muller asqueaker@gmail.com:
Hi Christoph,
Are these equivalent --
On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote: Outlook jumbled my message completely. Here the examples again:
[self model merge] on: MCMergeResolutionRequest & [:request | request merger conflicts notEmpty] do: [:request | request resume: true].
equal to:
[self model merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts notEmpty ifTrue: [request resume: true] ifFalse: [request pass] ]
?
[client unusedBytecode] on: MessageNotUnderstood & [:ex | ex receiver == client] & [:ex | ex message selector == #unusedBytecode] do: [self error: 'unusedBytecode'].
equal to
[client unusedBytecode] on: MessageNotUnderstood do: [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ]) ifTrue: [ self error: 'unusedBytecode' ] ifFalse: [ ex pass ] ]
?
Not sure if I fully understood it, but is it just a reformat of the syntax? Or something more empowering?
references := [self resolvePackageSpecReferences: packageSpec gofer: gofer] on: [self class retryPackageResolution] & (Error , GoferRepositoryError) do: [:ex | retryCount >= 2 ifFalse: [ ex return: #() ] on: [self class retryPackageResolution] & GoferRepositoryError. Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'. (repositoryError := ex) resume: #()].
(wait, is that, #on:do:on: ? I'm confused on this one...)
- Chris
sz := 1024*1024*1024*1024. self should: [Array new: sz] raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).
Christoph Thiede wrote
See Kernel-ct.1292/2 for the next attempt. :-)
Hm, no, SqueakSource has renamed it into Kernel-ct.1303. Eliot, didn't you mention that one can use slashes to create branches in Monticello?
Eliot's example, though, VMMaker.oscog-<author>.<nnn>, uses a dot to separate the branch name and puts the branch name behind the package name.
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"), but it was uploaded as Kernel-ct.1362 ... The next time I will try it without a dot in the branch name. :-)
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
So yes Monticello can produce branches, but it seems all but obvious how to use them (right).
Am Sa., 7. Nov. 2020 um 13:51 Uhr schrieb Christoph Thiede christoph.thiede@student.hpi.uni-potsdam.de:
Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"), but it was uploaded as Kernel-ct.1362 ... The next time I will try it without a dot in the branch name. :-)
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
On Sat, Nov 07, 2020 at 03:58:58PM +0100, Jakob Reschke wrote:
Am Sa., 7. Nov. 2020 um 13:51 Uhr schrieb Christoph Thiede christoph.thiede@student.hpi.uni-potsdam.de:
Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"), but it was uploaded as Kernel-ct.1362 ... The next time I will try it without a dot in the branch name. :-)
So yes Monticello can produce branches, but it seems all but obvious how to use them (right).
For a memory aid, look at the packages 'Compiler' and 'Compiler.spur' in trunk. The entries in Compiler.spur are of the form Compiler.spur-eem.287, so the naming convention when saving a branch version is to add '.spur' the the package name 'Compiler' to get 'Compiler.spur'. The '-eem' and '.287' are author and file version number. The actual branching is seen only in the version history of any of these version entries, and it may not match the history implied by the names.
For the example that Christoph provides above, suppose that Christoph was working on the Kernel package, and he wants to save some inbox versions branched from Kernel-eem.1361. In this example, the changes are going to be related to Context>>runSimulated, so he might want to identify these as a feature branch called 'runSimulated'. in that case, he might enter the name 'Kernel.runSimulated-ct.1362' rather than 'Kernel-ct.1362' when saving 1362 to the inbox. Then, when saving the next version 1363, it would be saved as 'Kernel.runSimulated-ct.1363'.
This system is far from perfect, but it does work. Do not expect it to be as elegant or efficient as git, it is not.
As Jakob says, the above is not obvious and that's why I mention it here.
Dave
Hi all,
anybody objects if I merged BlockClosure>>#on:satisfying:do: and #on:satisfying:ensure: as proposed via Kernel-ct.1303? Since originally writing this proposal, I really have missed something like this in the trunk. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2020-11-07T12:50:10-05:00, lewis@mail.msen.com wrote:
On Sat, Nov 07, 2020 at 03:58:58PM +0100, Jakob Reschke wrote:
Am Sa., 7. Nov. 2020 um 13:51 Uhr schrieb Christoph Thiede <christoph.thiede at student.hpi.uni-potsdam.de>:
Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"), but it was uploaded as Kernel-ct.1362 ... The next time I will try it without a dot in the branch name. :-)
So yes Monticello can produce branches, but it seems all but obvious how to use them (right).
For a memory aid, look at the packages 'Compiler' and 'Compiler.spur' in trunk. The entries in Compiler.spur are of the form Compiler.spur-eem.287, so the naming convention when saving a branch version is to add '.spur' the the package name 'Compiler' to get 'Compiler.spur'. The '-eem' and '.287' are author and file version number. The actual branching is seen only in the version history of any of these version entries, and it may not match the history implied by the names.
For the example that Christoph provides above, suppose that Christoph was working on the Kernel package, and he wants to save some inbox versions branched from Kernel-eem.1361. In this example, the changes are going to be related to Context>>runSimulated, so he might want to identify these as a feature branch called 'runSimulated'. in that case, he might enter the name 'Kernel.runSimulated-ct.1362' rather than 'Kernel-ct.1362' when saving 1362 to the inbox. Then, when saving the next version 1363, it would be saved as 'Kernel.runSimulated-ct.1363'.
This system is far from perfect, but it does work. Do not expect it to be as elegant or efficient as git, it is not.
As Jakob says, the above is not obvious and that's why I mention it here.
Dave
squeak-dev@lists.squeakfoundation.org