[squeak-dev] saving debugger

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] saving debugger

Ralph Boland
I am developing a parser generator tool in Squeak
(It should eventually replace  SmaCC among others).

My method for dealing with parsing errors is the same as for SmaCC.
That is an error is generated and caught and then an error message
is inserted into the text being parsed at the point of the error.
This works but is not entirely satisfactory especially when debugging
grammars;  messages  like "unexpected token -->"  at the point of error
don't tell you much when you have a problem with your grammar or
computer program.

Better in such situations is to perform some other action such as simply
bringing up the debugger at the point of the error or starting up some utility
to help explain the problem.  I wish to be able to do both but I also want
the error message inserted into the program text as  SmaCC does now.

So what I want to happen is have my parser generator tool generate the
error message  as  SmaCC does.  If at this point the programmer needs
more help he makes one of two selections from a menu:
   1)  Start up my bug finding utility.
   2)  Bring up the Smalltalk debugger as would happen if the
         error signal had not been caught.

My question now is how do I do  2).  In essence I need to be able to
catch the error signal and then reissue it under user control (if requested)
so that the debugger is brought up.  I expect that the solution here is
complicated but the more advice I can be given the better.
It seems to me that I need to do some kind of process fork (copy)
in order to have two identical processes.
This sounds expensive (and I don't know much about processes/forks)
given that the user may not choose to bring up the debugger so the
fork may not have been necessary. Thus if a fork is needed I want to be
able to avoid generating it until it is known that it is actually required
(if this is possible).

The solution will have relevance to 1) as well since if the user selects 1)
It will be necesary to know where the bug occurred.
I don't yet know how I will extract this information but it may involve
analyzing the call stack.

I appreciate that what I am trying to do is probably difficult and am going
to have to do most of the work in solving it but the more pointers I get
the less time I will spend on poor solutions.
At least this is the kind of problem that can be solved in Smalltalk.
Eventually I intend to port (parts of) my parser generator tool to
other languages
such as Java and C.  Making user selections 1) and 2) work in other languages is
going to be difficult.

Thanks in advance for any and all pointers.

Ralph Boland

--
Quantum Theory cannot save us from the
tyranny of a deterministic universe.
But it does give God something to do.