I guess for a bit of historical record - I fixed the Pharo 6.1 image in 
exercism to properly handle the creation of a missing class. Not a lot of code 
(but you do need the right code - and it is slightly confusing how the debugger 
window is so tightly tied to the model which also has the stack and context - 
and thus getting rid of the window gets rid of the context - which in 
retrospect makes sense as closing the debugger should terminate everything).

I’ll kick it around a bit with Exercism - and if it seems good I’ll make a PR 
for Pharo 7 as Think its worth having?

It does raise an interesting point however - when you hit a missing class, the 
debugger says “#message was sent to nil” - I would think we can do better than 
that given what Marcus discussed further below. If we were to save an 
UndefinedClass in the compiled method - then the error could be much better 
(not nil - but UndefinedClass, or UndefinedGlobal) - and equally the corrective 
action could be much better too. I think this is what Marcus was getting at - 
and I think it would be a much better thing for us to do.

Having used one of his suggestions below (and tried it when coding some 
exercises) - I also think we should stop the disruptive prompting for missing 
classes or variables when you save and just show them as gutter warnings or 
squiggles in the editor. You could add some other key to walk you through fixes 
if you want to deal with them right at that moment.

Anyway - this really shows how flexible our environment is (and the work we can 
keep doing).

Tim

> On 10 Aug 2018, at 23:16, Tim Mackinnon <tim@testit.works> wrote:
> 
> Actually I think I figured that bit out - a bit clumsily - (pointers 
> appreciated)
> 
> createMissingClassActionFor: aMessage in: aContext
>       |errorNode senderContext newClass variableNode |
>       senderContext := aContext sender.
>       errorNode := senderContext method sourceNodeExecutedForPC: 
> senderContext pc. 
>       variableNode := errorNode receiver receiver.
>       
>       newClass := OCUndeclaredVariableWarning new node: variableNode; 
> defineClass: variableNode name.
>       aContext restart.
> 
> However that last line is wrong, as it doesn’t restart with my newly defined 
> class - I also tried
> 
> aContext restartWithNewReceiver: newClass
> 
> But again, I get a debugger where my class is still bound to nil. So what’s 
> the trick to re-evaluate with the new class I’ve created? Or maybe I’m 
> totally on the wrong track (still its very interesting…)
> 
> Tim
> 
>> On 10 Aug 2018, at 16:30, Tim Mackinnon <tim@testit.works 
>> <mailto:tim@testit.works>> wrote:
>> 
>> Hey Marcus (or those knowledgable about stacks and contexts) - to self #1 - 
>> where the create button generates a class instead of a method, I’m a bit out 
>> of my depth.
>> 
>> I can see there is a DoesNotUnderstandDebugAction (which the create button 
>> calls).
>> 
>> So to determine if the failure was due to a missing class or method - would 
>> this work?
>> 
>> msg := self interruptedContext tempAt: 1.
>> (msg lookupClass == UndefinedObject ) ifTrue: [ … create a class
>> 
>> E.g. if you’re trying to send a msg to nil (which is what got patched into 
>> the compiled method for a missing class) then you are dealing with a missing 
>> class?
>> 
>> 
>> AND then for create a class - how do I extract the name?
>> 
>> I can get the compiled method for msg - but how do I marry that up with what 
>> you were executing? Am I write in thinking that the AST nodes and there 
>> locations might line up with the stack pointer somehow (or something like 
>> that)… if I can get that - then I get the name of the missing class and can 
>> then create it and then rerun the method right?
>> 
>> This is very neat stuff I ‘ve never played with before.
>> 
>> Tim
>> 
>> 
>> 
>> 
>> 
>>> On 9 Aug 2018, at 11:02, Marcus Denker <marcus.den...@inria.fr 
>>> <mailto:marcus.den...@inria.fr>> wrote:
>>> 
>>> 
>>> 
>>>> On 9 Aug 2018, at 10:59, Guillermo Polito <guillermopol...@gmail.com 
>>>> <mailto:guillermopol...@gmail.com>> wrote:
>>>> 
>>>> Hi Marcus,
>>>> 
>>>> Is it wise to backport things that may break things like this?
>>> maybe not, but it just took 5 minutes as it is very simple
>>> 
>>>> I'd prefer to put the energy on backporting the workaround to avoid the 
>>>> infinite debuggers...
>>>> 
>>> 
>>> Yes.
>>> 
>>>> On Thu, Aug 9, 2018 at 10:50 AM Marcus Denker <marcus.den...@inria.fr 
>>>> <mailto:marcus.den...@inria.fr>> wrote:
>>>>> 
>>>>>> 2) when coding - if you want reference a missing class, why don’t we let 
>>>>>> you? TonelReader seems to do it, why can’t the editor? (This probably 
>>>>>> applies to variables as well - show them broken, let me fix it when I 
>>>>>> choose. The iVar case is a little rarer - although I hate the way we 
>>>>>> prompt fix, prompt fix instead of doing it in one go - it’s very old 
>>>>>> fashioned)
>>>>>> 
>>>>> 
>>>>> This is fixed in Pharo7: we added a menu entry “leave undeclared” as the 
>>>>> first option:
>>>>> <leave undeclared.png>
>>>>>> Does anyone have tips on solving these? It spoils the exercism 
>>>>>> experience that I thought we could convey, so I’d like to at least fix 
>>>>>> #1 in 6.1 if I can.
>>>>>> 
>>>>> 
>>>>> I will back port the fix for 2) to Pharo6 and will do a quick prototype 
>>>>> for 1) 
>>>>> 
>>>> 
>>>> https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-Undeclared
>>>>  
>>>> <https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-Undeclared>
>>>> 
>>>>    Marcus
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>>    
>>>> Guille Polito
>>>> Research Engineer
>>>> 
>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>> CRIStAL - UMR 9189
>>>> French National Center for Scientific Research - http://www.cnrs.fr 
>>>> <http://www.cnrs.fr/>
>>>> 
>>>> Web: http://guillep.github.io <http://guillep.github.io/>
>>>> Phone: +33 06 52 70 66 13
>>> 
>> 
> 

Reply via email to