Smalltalk › Pharo › Pharo Smalltalk Developers

about syntaxError

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

stepharong

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/

Igor Stasenko

Re: about syntaxError

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 <[hidden email]> 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.

stepharong

Re: about syntaxError

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 <[hidden email]> 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/

Henrik Nergaard-2

Re: about syntaxError

In reply to this post by stepharong

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:[hidden email]] On Behalf Of stepharong
Sent: Thursday, December 8, 2016 9:08 PM
To: [hidden email]
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/

Igor Stasenko

Re: about syntaxError

In reply to this post by stepharong

On 8 December 2016 at 22:56, stepharong <[hidden email]> 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 <[hidden email]> 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.

Igor Stasenko

Re: about syntaxError

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 <[hidden email]> wrote:

On 8 December 2016 at 22:56, stepharong <[hidden email]> 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 <[hidden email]> 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.

philippeback

Re: about syntaxError

In reply to this post by 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 <[hidden email]> wrote:

On 8 December 2016 at 22:56, stepharong <[hidden email]> 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 <[hidden email]> 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.

Igor Stasenko

Re: about syntaxError

On 9 December 2016 at 01:39, [hidden email] <[hidden email]> 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.

Igor Stasenko

Re: about syntaxError

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 <[hidden email]> wrote:

On 9 December 2016 at 01:39, [hidden email] <[hidden email]> 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.

stepharong

Re: about syntaxError

In reply to this post by Henrik Nergaard-2

> 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:[hidden email]] On Behalf Of
> stepharong
> Sent: Thursday, December 8, 2016 9:08 PM
> To: [hidden email]
> 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/