...

On 11 May 2019, at 18:07, Ben Coman <btc@openinworld.com> wrote:

Currently when a DNU occurs we get this cool <Create> button, but when this presents the dialog "New Protocol Name" I get a blank list and the default is "as yet unclassified" and I end up with a heap of such unclassified methods to sort later.

I am wondering if it could be smarter when tests are being run. A reasonable assumption could be that the test's package name is closely related to the likely extension package name. So for a DNU, I wonder if the debugger could walk the stack to discover if a TestCase subclass was on the stack (e.g. MyTestCase) and then determine which package MyTestCase belonged to, and present that as a choice for "New Protocol Name", helping categorize extension methods.

I've started to play like this...

TestCase subclass: #MyTestRoot

MyTestRoot >> runCase [ super runCase ] on: MessageNotUnderstood do: [ :ex | "do something here, but for now..." ex pass ].

but before getting to deep, I'm seeking suggestions/solutions from the community.

On Sun, 12 May 2019 at 05:06, Tim Mackinnon <tim@testit.works> wrote:

It’s a good point Ben - in fact categorisation in general has not been finished in pharo7 - the move to Calypso lost smart method categories and its on the todo list to fix and improve it.

I don't think this is related to Calypso, more to do with the debugger. I got what I wanted with the following change... ``` DoesNotUnderstandDebugAction>>defaultProtocol "new method" "Facilitate DNU with TDD creating extension methods by suggesting that as default protocol" | interruptedContext candidateContext | "self halt" interruptedContext := self interruptedContext. candidateContext := interruptedContext sender. [ candidateContext isNil or: [ candidateContext contextClass isKindOf: TestCase class ] ] whileFalse: [ candidateContext := candidateContext sender ]. candidateContext ifNotNil: [ | testPackage dnuPackage| dnuPackage := interruptedContext receiver class package. testPackage := candidateContext contextClass package. (testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name ]. ]. ^'as yet unclassified' DoesNotUnderstandDebugAction>>executeAction "diff modified method" | msg msgCategory chosenClass exception | msg := self interruptedContext tempAt: 1. exception := self interruptedContext tempAt: 2. (exception class == ClassNotUnderstood) ifTrue: [ self createMissingClassWith: exception variableNode in: self interruptedContext ]. chosenClass := self askForSuperclassOf: self interruptedContext receiver class toImplement: msg selector ifCancel: [^self]. - msgCategory := (self askForCategoryIn: chosenClass default: 'as yet unclassified' ). + msgCategory := (self askForCategoryIn: chosenClass default: self defaultProtocol). self session implement: msg classified: msgCategory inClass: chosenClass forContext: self interruptedContext. self debugger selectTopContext ``` Tim, Can you trial this with your Exercism Die exercise? Alternatively an isolated test... ``` Object subclass: MyApp ... package: 'MyPackage' TestCase subclass: MyTestCase ... package: 'MyPackage' MyTestCase >> testAutoExtensionProtocol MyApp new unknown ``` Run the test then click <Create> button to add following method with default protocol... as yet unclassified ``` MyApp >> unknown 42 unknown ``` Click <Create> button to add method with default protocol... *MyPackage cheers -ben P.S. Next question is how to create a unit test for such behaviour ??

On Sun, 12 May 2019 at 15:41, Tim Mackinnon <tim@testit.works> wrote:

My point was that in general - method categorisation has degraded (not just your debugger case, but in a broader sense).

Nautilus used to infer method protocols , and if not inferred, you used to see protocols already in your package... now you basically have to type out protocols and search for them every time.

I don’t think you can even bulk categorise methods either.

I keep meaning to have a look, as it’s all quite annoying and doesn’t really encourage you to categorise anything as it’s too much like hard work.

With Calypso I've had some success using Protocols Pane > Categorize all uncategorized. but as an after-the-fact clean up maybe not what your looking for. cheers -ben

Tim

Sent from my iPhone

On 12 May 2019, at 07:30, Ben Coman <btc@openinworld.com> wrote:

...

...

...

On 11 May 2019, at 18:07, Ben Coman <btc@openinworld.com> wrote:

Currently when a DNU occurs we get this cool <Create> button, but when this presents the dialog "New Protocol Name" I get a blank list and the default is "as yet unclassified" and I end up with a heap of such unclassified methods to sort later.

I am wondering if it could be smarter when tests are being run. A reasonable assumption could be that the test's package name is closely related to the likely extension package name. So for a DNU, I wonder if the debugger could walk the stack to discover if a TestCase subclass was on the stack (e.g. MyTestCase) and then determine which package MyTestCase belonged to, and present that as a choice for "New Protocol Name", helping categorize extension methods.

I've started to play like this...

TestCase subclass: #MyTestRoot

MyTestRoot >> runCase [ super runCase ] on: MessageNotUnderstood do: [ :ex | "do something here, but for now..." ex pass ].

but before getting to deep, I'm seeking suggestions/solutions from the community.

...

On Sun, 12 May 2019 at 05:06, Tim Mackinnon <tim@testit.works> wrote:

It’s a good point Ben - in fact categorisation in general has not been finished in pharo7 - the move to Calypso lost smart method categories and its on the todo list to fix and improve it.

I don't think this is related to Calypso, more to do with the debugger. I got what I wanted with the following change... ``` DoesNotUnderstandDebugAction>>defaultProtocol "new method" "Facilitate DNU with TDD creating extension methods by suggesting that as default protocol" | interruptedContext candidateContext | "self halt" interruptedContext := self interruptedContext. candidateContext := interruptedContext sender. [ candidateContext isNil or: [ candidateContext contextClass isKindOf: TestCase class ] ] whileFalse: [ candidateContext := candidateContext sender ]. candidateContext ifNotNil: [ | testPackage dnuPackage| dnuPackage := interruptedContext receiver class package. testPackage := candidateContext contextClass package. (testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name ]. ]. ^'as yet unclassified'

DoesNotUnderstandDebugAction>>executeAction "diff modified method" | msg msgCategory chosenClass exception | msg := self interruptedContext tempAt: 1. exception := self interruptedContext tempAt: 2. (exception class == ClassNotUnderstood) ifTrue: [ self createMissingClassWith: exception variableNode in: self interruptedContext ]. chosenClass := self askForSuperclassOf: self interruptedContext receiver class toImplement: msg selector ifCancel: [^self]. - msgCategory := (self askForCategoryIn: chosenClass default: 'as yet unclassified' ). + msgCategory := (self askForCategoryIn: chosenClass default: self defaultProtocol). self session implement: msg classified: msgCategory inClass: chosenClass forContext: self interruptedContext. self debugger selectTopContext ```

Tim, Can you trial this with your Exercism Die exercise?

Alternatively an isolated test... ``` Object subclass: MyApp ... package: 'MyPackage'

TestCase subclass: MyTestCase ... package: 'MyPackage'

MyTestCase >> testAutoExtensionProtocol MyApp new unknown ```

Run the test then click <Create> button to add following method with default protocol... as yet unclassified ``` MyApp >> unknown 42 unknown ```

Click <Create> button to add method with default protocol... *MyPackage

cheers -ben

P.S. Next question is how to create a unit test for such behaviour ??

Just want ensure this doesn’t come across as all negative - there is lots of good stuff in Calypso and surrounding tools - it was a big job, but we just need to remember we haven’t finished yet. Also some ideas need refining now that we’ve used them a bit more. Tim Sent from my iPhone

On 12 May 2019, at 09:52, ducasse <stepharo@netcourrier.com> wrote:

We are working on making sure that in the future it will be easier to add new command to calypso.

- First step is to put calypso/commander/system commander in the Pharo repo (because we cannot have to do 4 PR for a stupid fix). - Second we are experimenting with a new version of commander that is less based on class creation but more on objects. We are validating it with real examples, and soon we will release an alpha version and work on automatic migration. The goal is to integrate this new version to Spec2.0. - The goal is to use all that for the - DrTests - Spec2 - Refactoring improvements.

Stef

...

...

On Sun, 12 May 2019 at 15:41, Tim Mackinnon <tim@testit.works> wrote: My point was that in general - method categorisation has degraded (not just your debugger case, but in a broader sense).

Nautilus used to infer method protocols , and if not inferred, you used to see protocols already in your package... now you basically have to type out protocols and search for them every time.

I don’t think you can even bulk categorise methods either.

I keep meaning to have a look, as it’s all quite annoying and doesn’t really encourage you to categorise anything as it’s too much like hard work.

With Calypso I've had some success using Protocols Pane > Categorize all uncategorized. but as an after-the-fact clean up maybe not what your looking for.

cheers -ben

...

Tim

Sent from my iPhone

On 12 May 2019, at 07:30, Ben Coman <btc@openinworld.com> wrote:

...

...

...

On 11 May 2019, at 18:07, Ben Coman <btc@openinworld.com> wrote:

Currently when a DNU occurs we get this cool <Create> button, but when this presents the dialog "New Protocol Name" I get a blank list and the default is "as yet unclassified" and I end up with a heap of such unclassified methods to sort later.

I am wondering if it could be smarter when tests are being run. A reasonable assumption could be that the test's package name is closely related to the likely extension package name. So for a DNU, I wonder if the debugger could walk the stack to discover if a TestCase subclass was on the stack (e.g. MyTestCase) and then determine which package MyTestCase belonged to, and present that as a choice for "New Protocol Name", helping categorize extension methods.

I've started to play like this...

TestCase subclass: #MyTestRoot

MyTestRoot >> runCase [ super runCase ] on: MessageNotUnderstood do: [ :ex | "do something here, but for now..." ex pass ].

but before getting to deep, I'm seeking suggestions/solutions from the community.

...

On Sun, 12 May 2019 at 05:06, Tim Mackinnon <tim@testit.works> wrote:

It’s a good point Ben - in fact categorisation in general has not been finished in pharo7 - the move to Calypso lost smart method categories and its on the todo list to fix and improve it.

I don't think this is related to Calypso, more to do with the debugger. I got what I wanted with the following change... ``` DoesNotUnderstandDebugAction>>defaultProtocol "new method" "Facilitate DNU with TDD creating extension methods by suggesting that as default protocol" | interruptedContext candidateContext | "self halt" interruptedContext := self interruptedContext. candidateContext := interruptedContext sender. [ candidateContext isNil or: [ candidateContext contextClass isKindOf: TestCase class ] ] whileFalse: [ candidateContext := candidateContext sender ]. candidateContext ifNotNil: [ | testPackage dnuPackage| dnuPackage := interruptedContext receiver class package. testPackage := candidateContext contextClass package. (testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name ]. ]. ^'as yet unclassified'

DoesNotUnderstandDebugAction>>executeAction "diff modified method" | msg msgCategory chosenClass exception | msg := self interruptedContext tempAt: 1. exception := self interruptedContext tempAt: 2. (exception class == ClassNotUnderstood) ifTrue: [ self createMissingClassWith: exception variableNode in: self interruptedContext ]. chosenClass := self askForSuperclassOf: self interruptedContext receiver class toImplement: msg selector ifCancel: [^self]. - msgCategory := (self askForCategoryIn: chosenClass default: 'as yet unclassified' ). + msgCategory := (self askForCategoryIn: chosenClass default: self defaultProtocol). self session implement: msg classified: msgCategory inClass: chosenClass forContext: self interruptedContext. self debugger selectTopContext ```

Tim, Can you trial this with your Exercism Die exercise?

Alternatively an isolated test... ``` Object subclass: MyApp ... package: 'MyPackage'

TestCase subclass: MyTestCase ... package: 'MyPackage'

MyTestCase >> testAutoExtensionProtocol MyApp new unknown ```

Run the test then click <Create> button to add following method with default protocol... as yet unclassified ``` MyApp >> unknown 42 unknown ```

Click <Create> button to add method with default protocol... *MyPackage

cheers -ben

P.S. Next question is how to create a unit test for such behaviour ??

My point was that in general - method categorisation has degraded (not just your debugger case, but in a broader sense).

Nautilus used to infer method protocols , and if not inferred, you used to see protocols already in your package... now you basically have to type out protocols and search for them every time.

Yes and I was sad since I spent time improving it :(

I don’t think you can even bulk categorise methods either.

I keep meaning to have a look, as it’s all quite annoying and doesn’t really encourage you to categorise anything as it’s too much like hard work.

Tim

Sent from my iPhone

On 12 May 2019, at 07:30, Ben Coman <btc@openinworld.com> wrote:

...

...

...

On 11 May 2019, at 18:07, Ben Coman <btc@openinworld.com> wrote:

Currently when a DNU occurs we get this cool <Create> button, but when this presents the dialog "New Protocol Name" I get a blank list and the default is "as yet unclassified" and I end up with a heap of such unclassified methods to sort later.

I am wondering if it could be smarter when tests are being run. A reasonable assumption could be that the test's package name is closely related to the likely extension package name. So for a DNU, I wonder if the debugger could walk the stack to discover if a TestCase subclass was on the stack (e.g. MyTestCase) and then determine which package MyTestCase belonged to, and present that as a choice for "New Protocol Name", helping categorize extension methods.

I've started to play like this...

TestCase subclass: #MyTestRoot

MyTestRoot >> runCase [ super runCase ] on: MessageNotUnderstood do: [ :ex | "do something here, but for now..." ex pass ].

but before getting to deep, I'm seeking suggestions/solutions from the community.

...

On Sun, 12 May 2019 at 05:06, Tim Mackinnon <tim@testit.works> wrote:

It’s a good point Ben - in fact categorisation in general has not been finished in pharo7 - the move to Calypso lost smart method categories and its on the todo list to fix and improve it.

I don't think this is related to Calypso, more to do with the debugger. I got what I wanted with the following change... ``` DoesNotUnderstandDebugAction>>defaultProtocol "new method" "Facilitate DNU with TDD creating extension methods by suggesting that as default protocol" | interruptedContext candidateContext | "self halt" interruptedContext := self interruptedContext. candidateContext := interruptedContext sender. [ candidateContext isNil or: [ candidateContext contextClass isKindOf: TestCase class ] ] whileFalse: [ candidateContext := candidateContext sender ]. candidateContext ifNotNil: [ | testPackage dnuPackage| dnuPackage := interruptedContext receiver class package. testPackage := candidateContext contextClass package. (testPackage = dnuPackage) ifFalse: [ ^ '*', testPackage name ]. ]. ^'as yet unclassified'

DoesNotUnderstandDebugAction>>executeAction "diff modified method" | msg msgCategory chosenClass exception | msg := self interruptedContext tempAt: 1. exception := self interruptedContext tempAt: 2. (exception class == ClassNotUnderstood) ifTrue: [ self createMissingClassWith: exception variableNode in: self interruptedContext ]. chosenClass := self askForSuperclassOf: self interruptedContext receiver class toImplement: msg selector ifCancel: [^self]. - msgCategory := (self askForCategoryIn: chosenClass default: 'as yet unclassified' ). + msgCategory := (self askForCategoryIn: chosenClass default: self defaultProtocol). self session implement: msg classified: msgCategory inClass: chosenClass forContext: self interruptedContext. self debugger selectTopContext ```

Tim, Can you trial this with your Exercism Die exercise?

Alternatively an isolated test... ``` Object subclass: MyApp ... package: 'MyPackage'

TestCase subclass: MyTestCase ... package: 'MyPackage'

MyTestCase >> testAutoExtensionProtocol MyApp new unknown ```

Run the test then click <Create> button to add following method with default protocol... as yet unclassified ``` MyApp >> unknown 42 unknown ```

Click <Create> button to add method with default protocol... *MyPackage

cheers -ben

P.S. Next question is how to create a unit test for such behaviour ??