jecaplan@phoenix.Princeton.EDU (Joshua Elliot Caplan) (04/07/90)
I'm working on a utility which will be useful to us all: a PostScript
debugger written mostly in PostScript for portability. I want the NeXT
machine's user interface to drive the PostScript code and enable things like
a continuously-updated operand stack window whose entries open into windows
themselves, breakpoints set by mouse, an "output so far" window, a back-trace
stack, etc. Unfortunately, documentation on communication between the
Objective-C application and the PostScript interpreter in the window server
is extremely rare and sketchy at best, and I'm having a really hard time
getting these two beasts talking to each other.
For example, I wrote a bone-headed application which just takes
a user's input from a TextFieldCell and spits it right to the PostScript
interpreter via DPSPrintf (or DPSWritePostScript, or DPSWriteData). If
the input was correct and contained no partial tokens or incomplete
objects, it worked...but on a line like "0 1 100 {", which one might use
before a procedure definition and "} for" later on, the program froze
indefinitely. Is there any way to send partial programs?
Also, the front-end is going to need to resume control while the
executing user PS code is paused at a breakpoint. The documentation
doesn't explain what happens to the executing PS context when a call-back
procedure is invoked; it does strongly advise against using any Client
Library routines while in a call-back procedure, however. Unfortunately
the only way I see to implement the action of a breakpoint is to cause PS
to execute a special "wait for an instruction" routine which would send a
signal to the standard output (causing the context's TextProc to run) and also
perform some sort of standard input _read_ function--which would wait for
input from the TextProc procedure! This is the recursion that Adobe so
vigorously discourages. Is there a better way to pause a PS program?
Finally, I've gone to great lengths to provide mechanisms whereby
at any given moment during execution of the user's PS code we can find the
entire back trace stack for the currently executing object, i.e. the
list of "return addresses" for all nested procedure calls. But the
execstack in pure PostScript already maintains most of this information;
all that's missing is some way of identifying WHICH object in each procedure
on the stack is the one currently running. Does Display PostScript provide
any facility for determining this information? I know that psh (NeWS)
on the IRIS 4Ds I use sometimes is able to report where we are in
each procedure on the stack in its executive error messages, but I don't
know how it does it.
Any responses on any of the above would be greatly appreciated
(please use e-mail).
-------------------------------------------------------------------------------
Joshua Caplan '91, Princeton University
jecaplan@phoenix.Princeton.EDU
jec@cs.Princeton.EDU