I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError." | window | self halt. bring a debugger but with a cut stack .... open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend so it does not really help to understand the syntax error. I do not get why this is so opaque. Stef -- Using Opera's mail client: http://www.opera.com/mail/
coz u putting exception inside an exception handler.. yo gawd, so you like exceptions? lets put an exception inside your exception, so it will be thrown while it thrown :)))))) (i hope everyone knows this reference :) On 8 December 2016 at 22:07, stepharong <stepharong@free.fr> wrote:
I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in
buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError."
| window | self halt.
bring a debugger but with a cut stack ....
open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend
so it does not really help to understand the syntax error. I do not get why this is so opaque.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
Sorry igot but I do not understand what you are saying. Too tired.
coz u putting exception inside an exception handler.. yo gawd, so you like exceptions? lets put an exception inside your exception, so it will be thrown while it thrown:)))))) (i hope everyone knows this reference :)
On 8 December 2016 at 22:07, stepharong <stepharong@free.fr> wrote:
I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in
buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError."
| window | self halt.
bring a debugger but with a cut stack ....
open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend
so it does not really help to understand the syntax error. I do not get why this is so opaque.
Stef
--Using Opera's mail client: http://www.opera.com/mail/
--Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
On 8 December 2016 at 22:56, stepharong <stepharong@free.fr> wrote:
Sorry igot but I do not understand what you are saying. Too tired.
the exception handler if it runs in UI process does following: - spawns new UI process, suspending the old one, that caused exception, then creates a debugger that showing where the original exception occur. but if you put halt somewhere in the middle of exception handler , you will either create an endless loop (of attempting to bring debugger), or, when you lucky, as in your case - it will show you debugger , where you interrupted the exception handling, but not the original exception.
coz u putting exception inside an exception handler.. yo gawd, so you like exceptions? lets put an exception inside your exception, so it will be thrown while it thrown :)))))) (i hope everyone knows this reference :)
On 8 December 2016 at 22:07, stepharong <stepharong@free.fr> wrote:
I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in
buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError."
| window | self halt.
bring a debugger but with a cut stack ....
open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend
so it does not really help to understand the syntax error. I do not get why this is so opaque.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
and this: <primitive: 19> "Simulation guard" is a good indication of what's gone wrong.. you are basically attempting to debug a debugger, using the very same debugger and this primitive is used throughout the debugger code to guard against such cases. On 9 December 2016 at 01:06, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 December 2016 at 22:56, stepharong <stepharong@free.fr> wrote:
Sorry igot but I do not understand what you are saying. Too tired.
the exception handler if it runs in UI process does following: - spawns new UI process, suspending the old one, that caused exception, then creates a debugger that showing where the original exception occur.
but if you put halt somewhere in the middle of exception handler , you will either create an endless loop (of attempting to bring debugger), or, when you lucky, as in your case - it will show you debugger , where you interrupted the exception handling, but not the original exception.
coz u putting exception inside an exception handler.. yo gawd, so you like exceptions? lets put an exception inside your exception, so it will be thrown while it thrown :)))))) (i hope everyone knows this reference :)
On 8 December 2016 at 22:07, stepharong <stepharong@free.fr> wrote:
I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in
buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError."
| window | self halt.
bring a debugger but with a cut stack ....
open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend
so it does not really help to understand the syntax error. I do not get why this is so opaque.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Nice to now understand how this debugger thing behaves. I have some issues when debugging tests GTDebugger in Pharo5 when there is a self halt in the test method. For some reason the step through looks like out of what with the actual thing to step through. How does that work? Phil On Fri, Dec 9, 2016 at 12:06 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 December 2016 at 22:56, stepharong <stepharong@free.fr> wrote:
Sorry igot but I do not understand what you are saying. Too tired.
the exception handler if it runs in UI process does following: - spawns new UI process, suspending the old one, that caused exception, then creates a debugger that showing where the original exception occur.
but if you put halt somewhere in the middle of exception handler , you will either create an endless loop (of attempting to bring debugger), or, when you lucky, as in your case - it will show you debugger , where you interrupted the exception handling, but not the original exception.
coz u putting exception inside an exception handler.. yo gawd, so you like exceptions? lets put an exception inside your exception, so it will be thrown while it thrown :)))))) (i hope everyone knows this reference :)
On 8 December 2016 at 22:07, stepharong <stepharong@free.fr> wrote:
I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in
buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError."
| window | self halt.
bring a debugger but with a cut stack ....
open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend
so it does not really help to understand the syntax error. I do not get why this is so opaque.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
-- Using Opera's mail client: http://www.opera.com/mail/
-- Best regards, Igor Stasenko.
On 9 December 2016 at 01:39, phil@highoctane.be <phil@highoctane.be> wrote:
Nice to now understand how this debugger thing behaves.
I have some issues when debugging tests GTDebugger in Pharo5 when there is a self halt in the test method. For some reason the step through looks like out of what with the actual thing to step through.
How does that work?
well, IIRC, when you stepping through, the debugger running a simulation and detects that you trying to interrupt it and since it is not a good idea to interrupt the debugger itself , else you will need to open yet another debugger window, showing where the simulation/exception handling was interrupted.. and so you enter an endless recursive loop, and as result won't be able to debug anything :) And this 'simulation guard' is serving to prohibit further processing in such cases, or in certain cases, it simply ignores it and pretends that it is done, suppressing actual code behavior, which would be triggered, if it wouldn't run simulated by debugger.
Phil
-- Best regards, Igor Stasenko.
and this works simply by knowing that primitive 19 always fails (this is guaranteed by VM itself). so when you run code naturally - the primitive fails, and so it runs the body of method. but when same method attempted to activate(simulate) via debugger - it doesn't runs a method body and doing something else, what exactly - look at debugger code, because i don't remember :). On 9 December 2016 at 02:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 December 2016 at 01:39, phil@highoctane.be <phil@highoctane.be> wrote:
Nice to now understand how this debugger thing behaves.
I have some issues when debugging tests GTDebugger in Pharo5 when there is a self halt in the test method. For some reason the step through looks like out of what with the actual thing to step through.
How does that work?
well, IIRC, when you stepping through, the debugger running a simulation and detects that you trying to interrupt it and since it is not a good idea to interrupt the debugger itself , else you will need to open yet another debugger window, showing where the simulation/exception handling was interrupted.. and so you enter an endless recursive loop, and as result won't be able to debug anything :)
And this 'simulation guard' is serving to prohibit further processing in such cases, or in certain cases, it simply ignores it and pretends that it is done, suppressing actual code behavior, which would be triggered, if it wouldn't run simulated by debugger.
Phil
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Change line 3 of RBExtractMethodRefactoring>>extractMethod to something like: [ extractedParseTree := RBParser parseExpression: extractCode ] on: SyntaxErrorNotification do: [ :ex| ex debug ]. To bring up a debugger. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharong Sent: Thursday, December 8, 2016 9:08 PM To: pharo-dev@lists.pharo.org Subject: [Pharo-dev] about syntaxError I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError." | window | self halt. bring a debugger but with a cut stack .... open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend so it does not really help to understand the syntax error. I do not get why this is so opaque. Stef -- Using Opera's mail client: http://www.opera.com/mail/
Change line 3 of RBExtractMethodRefactoring>>extractMethod to something like: [ extractedParseTree := RBParser parseExpression: extractCode ] on: SyntaxErrorNotification do: [ :ex| ex debug ].
To bring up a debugger.
Tx this is what I was trying to do (but I should not because I was in a hacking session) and then I went to bed. I will try it. STef
Best regards, Henrik
-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharong Sent: Thursday, December 8, 2016 9:08 PM To: pharo-dev@lists.pharo.org Subject: [Pharo-dev] about syntaxError
I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in
buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError."
| window | self halt.
bring a debugger but with a cut stack ....
open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend
so it does not really help to understand the syntax error. I do not get why this is so opaque.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
-- Using Opera's mail client: http://www.opera.com/mail/
participants (4)
-
Henrik Nergaard -
Igor Stasenko -
phil＠highoctane.be -
stepharong