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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>> On 11 May 2019, at 18:07, Ben Coman <[email protected]> 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 <[email protected]> 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 ?? >>> > >>> >>> >
