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.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 9 Aug 2018, at 10:59, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@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.denker@inria.fr <mailto:marcus.denker@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-Un... <https://pharo.fogbugz.com/f/cases/22305/Backport-to-Pharo6-Leave-Variable-Un...>
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