- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Metacello/Iceberg detached head of cascade loaded requirements

by Gabriel Cotelli

If the dependencies are pinned to a git tag it's a normal situation. You don't need to do nothing unless you want to change some of the code in the dependencies in which case just create a branch On Sat, May 11, 2019, 05:40 Ben Coman <btc(a)openinworld.com> wrote: > I have a query about "Detached HEAD" status after a Metacello/Iceberg > cascade load of required packages. Starting with the general questions... > Is that a common status for this scenario? > How to leave the status looking good as "Up to date"? > > Here is a case example... > To avoid the a Filetree repo "filename too long" error on Windows, > I pre-cloned the repo to specify s shorter path name... > Repositories > Add > Clone from github.com > Owner: dionisiydk > Project name: Mocketry > Local directory: C:\Temp\Mocketry > Protocol: SSH > > Then in Playground evaluated... > Metacello new > baseline: 'Mocketry'; > repository: 'github://dionisiydk/Mocketry'; > load > > This cascade loaded Ghost and StateSpecs repos leaving them > with a status of "Detached HEAD". > What does this mean? > And how to have these load cleanly so they are left "Up to date" ? > > To ease others testing on Windows, I forked the repo and converted to > Tonel, > so the same result comes by just evaluating.... > Metacello new > baseline: 'Mocketry'; > repository: 'github://bencoman/Mocketry'; > load > > cheers -ben > > P.S. I've issued a PR upstream for the Tonel conversion. > >

May 11, 2019

Metacello/Iceberg detached head of cascade loaded requirements

by Ben Coman

I have a query about "Detached HEAD" status after a Metacello/Iceberg cascade load of required packages. Starting with the general questions... Is that a common status for this scenario? How to leave the status looking good as "Up to date"? Here is a case example... To avoid the a Filetree repo "filename too long" error on Windows, I pre-cloned the repo to specify s shorter path name... Repositories > Add > Clone from github.com Owner: dionisiydk Project name: Mocketry Local directory: C:\Temp\Mocketry Protocol: SSH Then in Playground evaluated... Metacello new baseline: 'Mocketry'; repository: 'github://dionisiydk/Mocketry'; load This cascade loaded Ghost and StateSpecs repos leaving them with a status of "Detached HEAD". What does this mean? And how to have these load cleanly so they are left "Up to date" ? To ease others testing on Windows, I forked the repo and converted to Tonel, so the same result comes by just evaluating.... Metacello new baseline: 'Mocketry'; repository: 'github://bencoman/Mocketry'; load cheers -ben P.S. I've issued a PR upstream for the Tonel conversion.

May 11, 2019

[Pharo 8.0] Build #266: Fix wording typo

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

There is a new Pharo build available! The status of the build #266 was: SUCCESS. The Pull Request #3335 was integrated: "Fix wording typo" Pull request url: https://github.com/pharo-project/pharo/pull/3335 Issue Url: https://github.com/pharo-project/pharo/issues/fix Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 11, 2019