May 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] DNU Create button auto extension category

by ducasse

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(a)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(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > >>> On 11 May 2019, at 18:07, Ben Coman <btc(a)openinworld.com <mailto: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(a)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 ?? > > > >

May 12, 2019

Re: [Pharo-dev] DNU Create button auto extension category

by ducasse

> > 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(a)openinworld.com> wrote: > >>>> On 11 May 2019, at 18:07, Ben Coman <btc(a)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(a)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 ?? >> > >

May 12, 2019

[Pharo 8.0] Build #267: 3320-Improve-HistorySlot-and-other-small-fixes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #267 was: FAILURE. The Pull Request #3321 was integrated: "3320-Improve-HistorySlot-and-other-small-fixes" Pull request url: https://github.com/pharo-project/pharo/pull/3321 Issue Url: https://github.com/pharo-project/pharo/issues/3320 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 12, 2019

Re: [Pharo-dev] DNU Create button auto extension category

by Ben Coman

On Sun, 12 May 2019 at 15:41, Tim Mackinnon <tim(a)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(a)openinworld.com> wrote: > > >>> On 11 May 2019, at 18:07, Ben Coman <btc(a)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(a)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 ?? > > > > >

May 12, 2019

Re: [Pharo-dev] DNU Create button auto extension category

by Tim Mackinnon

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. Tim Sent from my iPhone On 12 May 2019, at 07:30, Ben Coman <btc(a)openinworld.com> wrote: >>> On 11 May 2019, at 18:07, Ben Coman <btc(a)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(a)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 ?? >

May 12, 2019

Re: [Pharo-dev] DNU Create button auto extension category

by Ben Coman

> > On 11 May 2019, at 18:07, Ben Coman <btc(a)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(a)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 ??

May 12, 2019

consortium engineers

by Ben Coman

I hadn't heard before... four consortium engineers for a year, very cool... slides 3 & 4... https://www.slideshare.net/pharoproject/pharo-70-and-80-alpha thanks Schmidt & LIfeware, and all consortium partners. cheers -ben

May 12, 2019

Re: [Pharo-dev] DNU Create button auto extension category

by Christopher Fuhrman

I had opened an issue with Create in DNU some weeks ago that's related. See https://github.com/pharo-project/pharo/issues/3242 On Sat, 11 May 2019 at 23:06, Tim Mackinnon <tim(a)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. > > Tim > > Sent from my iPhone > > > On 11 May 2019, at 18:07, Ben Coman <btc(a)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. > > > > cheers -ben > > > > >

May 11, 2019

Re: [Pharo-dev] DNU Create button auto extension category

by Tim Mackinnon

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. Tim Sent from my iPhone > On 11 May 2019, at 18:07, Ben Coman <btc(a)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. > > cheers -ben >

May 11, 2019

DNU Create button auto extension category

by Ben Coman

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. cheers -ben

May 11, 2019