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