On 30 January 2013 20:04, <commits(a)source.squeak.org> wrote:
> Frank Shearar uploaded a new version of Kernel to project The Inbox:
> http://source.squeak.org/inbox/Kernel-fbs.736.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-fbs.736
> Author: fbs
> Time: 30 January 2013, 8:04:08.926 pm
> UUID: 1d99c937-4c68-475c-987b-2990c8040c29
> Ancestors: Kernel-fbs.735
>
> Rename NotImplemented errors in line with conventions 2 of 3.
>
> =============== Diff against Kernel-fbs.735 ===============
If folks are happy with what I've got, I'd like to make one more
change, and remove NotYetImplemented>>#defaultAction. This will make
this message send open up a Debugger. Then I just need to tweak the
Debugger to show the Create button.
If people think that's sensible I'll make the change and resubmit,
clearing out obsolete Inbox ancestors to show a more complete diff.
frank
On 30 January 2013 18:33, <commits(a)source.squeak.org> wrote:
> Frank Shearar uploaded a new version of Kernel to project The Inbox:
> http://source.squeak.org/inbox/Kernel-fbs.735.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-fbs.735
> Author: fbs
> Time: 30 January 2013, 6:33:47.078 pm
> UUID: 18ffff61-cfcf-4843-8c64-caea3ceb3fbc
> Ancestors: Kernel-fbs.734
>
> Actually, return a Message, and find out the receiver of the Message from the signalercontext.
>
> Also, _returning_ the value of #subclassResponsibility means that you can return to the original caller the value of your just implemented method.
>
> =============== Diff against Kernel-fbs.734 ===============
>
> Item was added:
> + ----- Method: ContextPart>>asMessage (in category 'converting') -----
> + asMessage
> + | sender selector args |
> + sender := self sender.
> + selector := sender method selector.
> + args := Array new: selector numArgs.
> + 1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
> + ^ Message selector: selector arguments: args.!
>
> Item was removed:
> - ----- Method: ContextPart>>asMessageSend (in category 'converting') -----
> - asMessageSend
> - | sender selector args |
> - sender := self sender.
> - selector := sender method selector.
> - args := Array new: selector numArgs.
> - 1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
> - ^ MessageSend receiver: self receiver selector: selector arguments: args.!
<snip>
Diffs serve as a helper for reviewers. To that end, the diffs ought to
actually show what changes would be applied to trunk should the change
be accepted. This diff, for instance, shows the removal of
#asMessageSend and the addition of #asMessage, but really the change
applied to trunk will be just the addition of #asMessage.
In other words when something undergoes a few rounds of review (and
I'd think this should be the _norm_) the reviewer must reconstruct a
series of diffs to get an idea of how trunk will change.
Wouldn't it be better to diff against trunk rather than against the
mcz's ancestor? (*)
frank
(*) This is actually how github's pull requests work: you _can_ see
the commit history, but you also have a straight "this is what will
change" view, which is where I normally look.
Frank Shearar uploaded a new version of Kernel to project The Inbox:
http://source.squeak.org/inbox/Kernel-fbs.738.mcz
==================== Summary ====================
Name: Kernel-fbs.738
Author: fbs
Time: 5 February 2013, 11:09:23.219 pm
UUID: 792498b5-658b-4286-a580-755e9ae392a0
Ancestors: Kernel-nice.731
Backported From: Kernel-fbs.737
Stay in the debugger for longer. Part 3 of _5_.
Stack introspection so the Debugger doesn't have to. Signal the new exceptions when necessary.
=============== Diff against Kernel-nice.731 ===============
Item was added:
+ ----- Method: ContextPart>>asMessage (in category 'converting') -----
+ asMessage
+ | sender selector args |
+ sender := self sender.
+ selector := sender method selector.
+ args := Array new: selector numArgs.
+ 1 to: selector numArgs do: [ :i | args at: i put: (sender tempAt: i)].
+ ^ Message selector: selector arguments: args.!
Item was added:
+ ----- Method: ContextPart>>exceptionMessage (in category 'accessing') -----
+ exceptionMessage
+ ^ self selector caseOf: {
+ [#doesNotUnderstand:] -> [self tempAt: 1].
+ [#notYetImplemented] -> [self asMessage].
+ [#shouldBeImplemented] -> [self asMessage].
+ [#subclassResponsibility] -> [self asMessage]}
+ otherwise: [self error: 'This context is not the result of a message exception.'].!
Item was added:
+ ----- Method: ContextPart>>selectorCategory (in category 'accessing') -----
+ selectorCategory
+ "Return the category to which this message belongs (relative to the receiver). If no superclass categorises this message, use the default."
+ | organizers |
+ organizers := self receiver class withAllSuperclasses collect: [:ea | ea organization].
+ organizers addFirst: self receiver class organization.
+ ^ (organizers collect: [ :org | org categoryOfElement: self selector])
+ detect: [:ea | ea ~= ClassOrganizer default and: [ ea ~= nil]]
+ ifNone: [ClassOrganizer default]!
Item was added:
+ ----- Method: MessageSend>>asMessage (in category 'converting') -----
+ asMessage
+ ^ Message selector: selector arguments: arguments.!
Item was changed:
----- Method: Object>>shouldBeImplemented (in category 'error handling') -----
shouldBeImplemented
"Announce that this message should be implemented"
+ ^ NotImplemented signal: ('{1} or a superclass should implement {2}' format: {self className. thisContext sender selector})!
- self error: 'This message should be implemented'!
Item was changed:
----- Method: Object>>shouldNotImplement (in category 'error handling') -----
shouldNotImplement
"Announce that, although the receiver inherits this message, it should
not implement it."
+ NotImplemented signal: ('{1} is not a message appropriate for a {2}' format: {thisContext sender selector. self className}).!
- self error: 'This message is not appropriate for this object'!
Item was changed:
----- Method: Object>>subclassResponsibility (in category 'error handling') -----
subclassResponsibility
"This message sets up a framework for the behavior of the class' subclasses.
Announce that the subclass should have implemented this message."
+ ^ SubclassResponsibility
+ signal: ('My {1} subclass should have overridden {2}'
+ format: {self className. thisContext sender selector}).!
-
- self error: 'My subclass should have overridden ', thisContext sender selector printString!
Frank Shearar uploaded a new version of Exceptions to project The Inbox:
http://source.squeak.org/inbox/Exceptions-fbs.43.mcz
==================== Summary ====================
Name: Exceptions-fbs.43
Author: fbs
Time: 5 February 2013, 11:06:32.257 pm
UUID: 1a5409d5-3bfb-4728-9945-6898e8c3adca
Ancestors: Exceptions-cmm.37
Backported From: Exceptions-fbs.42
Stay in the debugger for longer. Part 2 of 3.
New exception hierarchy lets interesting parties catch NotImplemented errors to encourage developers to implement missing parts.
=============== Diff against Exceptions-cmm.37 ===============
Item was changed:
+ NotImplemented subclass: #MessageNotUnderstood
- Error subclass: #MessageNotUnderstood
instanceVariableNames: 'message receiver reachedDefaultHandler'
classVariableNames: ''
poolDictionaries: ''
category: 'Exceptions-Kernel'!
!MessageNotUnderstood commentStamp: '<historical>' prior: 0!
This exception is provided to support Object>>doesNotUnderstand:.!
Item was added:
+ Error subclass: #NotImplemented
+ instanceVariableNames: ''
+ classVariableNames: ''
+ poolDictionaries: ''
+ category: 'Exceptions-Kernel'!
Item was changed:
+ NotImplemented subclass: #NotYetImplemented
- Error subclass: #NotYetImplemented
instanceVariableNames: 'receiverClass selector context'
classVariableNames: ''
poolDictionaries: ''
category: 'Exceptions-Kernel'!
!NotYetImplemented commentStamp: 'jcg 10/21/2009 01:20' prior: 0!
Sent by #notYetImplemented. Better than the age-old behavior of opening a notifier window, because this can be caught and handled.
!
Item was removed:
- ----- Method: NotYetImplemented>>defaultAction (in category 'handling') -----
- defaultAction
- self inform: 'Not yet implemented (', self messageText, ')'!
Item was added:
+ NotImplemented subclass: #SubclassResponsibility
+ instanceVariableNames: ''
+ classVariableNames: ''
+ poolDictionaries: ''
+ category: 'Exceptions-Kernel'!
+
+ !SubclassResponsibility commentStamp: 'fbs 1/26/2013 00:20' prior: 0!
+ I am signalled when a subclass fails to implement an "abstract method" and something sends an instance of this subclass the unimplemented message.!
Frank Shearar uploaded a new version of Morphic to project The Inbox:
http://source.squeak.org/inbox/Morphic-fbs.638.mcz
==================== Summary ====================
Name: Morphic-fbs.638
Author: fbs
Time: 5 February 2013, 11:03:21.697 pm
UUID: 78dd37be-9165-4279-a78a-d8892418990f
Ancestors: Morphic-bf.636
Backported From: Morphic-fbs.637
Stay in the debugger for longer. Part 1 of 3.
UI hooks to create overriding methods.
=============== Diff against Morphic-bf.636 ===============
Item was added:
+ ----- Method: PreDebugWindow>>createOverridingMethod (in category 'as yet unclassified') -----
+ createOverridingMethod
+ model createOverridingMethod!
Chris Muller uploaded a new version of SUnit to project The Trunk:
http://source.squeak.org/trunk/SUnit-cmm.90.mcz
==================== Summary ====================
Name: SUnit-cmm.90
Author: cmm
Time: 4 January 2013, 3:33:36.616 pm
UUID: 8533f0b4-2587-412b-b465-4ad7f20331d0
Ancestors: SUnit-ul.89
- Do not wipe out pre-initialized state on TestCases. Tests do not need to be prevented from running more than once if proper setUp/tearDown methods are present.
=============== Diff against SUnit-ul.89 ===============
Item was changed:
----- Method: TestCase>>debug (in category 'running') -----
debug
+ self resources do:
+ [ : res | res isAvailable ifFalse: [ ^ res signalInitializationError ] ].
+ [ self runCase ] ensure:
+ [ self resources do:
+ [ : each | each reset ] ]!
- self resources do: [:res |
- res isAvailable ifFalse: [^res signalInitializationError]].
- [(self class selector: testSelector) runCase]
- ensure: [self resources do: [:each | each reset]]
- !
I've just spent a ridiculous amount of time trying to explain to a curious new-user how to open the Score Player and use it to play a midi file. It took probably ten times as long as a suitable video tutorial would run for.
Has anybody done some videos? Would anyone like to? I'm thinking 2/3/4 minute snippets on different themes to introduce newcomers to the wild list of stuff we can do. Make a nice big batch of them, stick'em on youtube and become a star!
Hang on a mo'. Looks like Lawson English has done a pretty decent list already - good for you Lawson. And a few other contributors; excellent start. We could do with a good list of them for the website as introductions. I only found one very short sound related vid though.
tim
--
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: LOW: Launch on Warning