- Pharo-dev - lists.pharo.org

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

by ducasse

> On 12 May 2019, at 18:13, Tim Mackinnon <tim(a)testit.works> wrote: > > 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. Yes :) This is why this is important to get feedback from the regression. stef

May 12, 2019

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

by Tim Mackinnon

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(a)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(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

Call for Papers: COP 2019

by Fabio Niephaus

============================================================================ Call for Papers: COP 2019 The 11th International Workshop on Context-Oriented Programming and Advanced Modularity (COP) Co-located with ECOOP 2019 July 15th - 19th, 2019, London, United Kingdom https://2019.ecoop.org/home/COP-2019 ============================================================================ Contextual information plays an ever-increasing role in our information- centric world. Current-day software systems adapt continuously to changing execution and usage contexts, even while running. Unfortunately, mainstream programming languages and development environments still do not support this kind of dynamicity very well, leading developers to implement complex designs to anticipate various dimensions of variability. Context-Oriented Programming directly supports variability at the programming level, depending on a wide range of dynamic attributes. It enables run-time behavior to be dispatched directly on any detected properties of the execution or user context. Since more than a decade, researchers have been working on a variety of notions approaching that idea. Implementations ranging from first prototypes to mature platform extensions used in commercial deployments have illustrated how multidimensional dispatch can be supported effectively to achieve expressive run-time variation in behavior. The previous editions of this workshop at ECOOP (since 2009) have each attracted around 30 participants. The goal of the 11th Workshop on Context-Oriented Programming is to further establish context orientation as a common thread throughout language design, application development, and system support. In 2019 we also hope to advance this vibrant research domain at ECOOP in the versatile city of London. According to Wikipedia, London is considered to be one of the worldâs most important global cities and has been termed the worldâs most powerful, most desirable, most influential, most visited, most expensive, innovative, sustainable, most investment friendly, most popular for work, and the most vegetarian friendly city in the world, all depending on the context. Call for Papers --------------- COP invites submissions of high-quality papers reporting original research, or describing innovative contributions to, or experience with context- oriented programming, its implementation, and application. Papers that depart significantly from established ideas and practices are particularly welcome. All papers must be original. Submissions must not have been published previously and must not be simultaneously submitted or under review at any other refereed event or publication. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Topics ------ Topics of interest to the workshop include, but are not limited to: - Interesting application domains and scenarios for COP; - Programming language abstractions for COP (e.g., dynamic scoping, roles, traits, prototype-based extensions); - Implementation techniques and mechanisms for COP (e.g., different kinds of dynamic, contextual, and multi-dimensional dispatch or pre-dispatch); - Implementation issues for COP (e.g., optimization, VM support, JIT compilation); - Implemented use-cases, case studies, or prototypes of COP; - Theoretical foundations for COP (e.g., semantics, type systems); - Configuration languages (e.g., feature description interpreters, transformational approaches); - Interaction between non-functional programming concerns and COP (e.g., security, persistence, concurrency, distribution); - Modularization approaches for COP (e.g., modules, aspects, features, layers, plugins); Guidelines to apply COP (e.g., best practices, idioms, patterns); - Run-time support for COP (e.g., reflection, dynamic binding); - Tool support (e.g., design tools, IDEs, debuggers); - Support for COP at the modeling level; - Beyond context-oriented behavior adaptation (e.g., UI adaptation, DB adaptation). Submission Guidelines --------------------- Papers are to be submitted via EasyChair. They must be written in English, provided as PDF documents, and follow the new ACM Master Article Template with the sigconf option. They should not exceed 8 pages. Accepted papers will be published in the ACM Digital Library. Submission Site: https://easychair.org/conferences/?conf=cop2019 Template: https://www.acm.org/publications/proceedings-template Important Dates --------------- Submission deadline: 2019-05-20 Author notification: 2019-06-10 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Program Committee ----------------- Walter Binder, University of Lugano, Switzerland Walter Cazzola, UniversitÃ degli Studi di Milano, Italy Shigeru Chiba, University of Tokyo, Japan Cynthia Disenfeld, University of Toronto, Canada BenoÃ®t Duhoux, UniversitÃ© catholique de Louvain, Belgium David H. Lorenz, Open University and Technion IIT, Israel Robert Hirschfeld, Hasso-Plattner-Institut (HPI), Germany Atsushi Igarashi, Kyoto University, Japan Tetsuo Kamina, Oita University, Japan Gary Leavens, University of Central Florida, United States Mariana Marasoiu, University of Cambridge, United Kingdom Hidehiko Masuhara, Tokyo Institute of Technology, Japan Roly Perera, Alan Turing Institute, United Kingdom Organizers ---------- David H. Lorenz, Open University and Technion IIT, Israel Robert Hirschfeld, Hasso-Plattner-Institut (HPI), Germany Atsushi Igarashi, Kyoto University, Japan Hidehiko Masuhara, Tokyo Institute of Technology, Japan

May 12, 2019

[Pharo 8.0] Build #268: Fixes #3115

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

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

May 12, 2019

Re: [Pharo-dev] consortium engineers

by ducasse

Yes this is on my todo to do an announce. But I was too busy > On 12 May 2019, at 04:00, Ben Coman <btc(a)openinworld.com> wrote: > > 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 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