- Pharo-dev - lists.pharo.org

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

[Pharo 8.0] Build #265: 3312-KMKeymapnotifyPartialMatchTo-leads-to-an-error

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

There is a new Pharo build available! The status of the build #265 was: FAILURE. The Pull Request #3313 was integrated: "3312-KMKeymapnotifyPartialMatchTo-leads-to-an-error" Pull request url: https://github.com/pharo-project/pharo/pull/3313 Issue Url: https://github.com/pharo-project/pharo/issues/3312 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 10, 2019

[Pharo 8.0] Build #264: 3328-SubclassResponsibility-error-when-running-RBParserparseFaultyMethod

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

There is a new Pharo build available! The status of the build #264 was: SUCCESS. The Pull Request #3329 was integrated: "3328-SubclassResponsibility-error-when-running-RBParserparseFaultyMethod" Pull request url: https://github.com/pharo-project/pharo/pull/3329 Issue Url: https://github.com/pharo-project/pharo/issues/3328 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 10, 2019