Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #1540 > unrolled thread

Checking the stack is empty at the end of the program

Back to article view | Back to comp.lang.postscript

Contents

  Checking the stack is empty at the end of the program Cecil Westerhof <Cecil@decebal.nl> - 2013-08-01 00:16 +0200
    Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-07-31 15:41 -0700
      Re: Checking the stack is empty at the end of the program Cecil Westerhof <Cecil@decebal.nl> - 2013-08-01 02:36 +0200
    Re: Checking the stack is empty at the end of the program Dan Coby <adcoby@earthlink.net> - 2013-07-31 18:36 -0700
      Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-07-31 23:53 -0700
        Re: Checking the stack is empty at the end of the program Cecil Westerhof <Cecil@decebal.nl> - 2013-08-01 10:41 +0200
          Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-08-01 02:37 -0700
            Re: Checking the stack is empty at the end of the program Cecil Westerhof <Cecil@decebal.nl> - 2013-08-01 12:40 +0200
              Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-08-01 03:53 -0700
                Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-08-01 03:56 -0700
                  Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-08-01 04:23 -0700
                    Re: Checking the stack is empty at the end of the program Cecil Westerhof <Cecil@decebal.nl> - 2013-08-01 15:45 +0200
                Re: Checking the stack is empty at the end of the program Cecil Westerhof <Cecil@decebal.nl> - 2013-08-01 13:18 +0200
                  Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-08-01 09:33 -0700
                    Re: Checking the stack is empty at the end of the program luser- -droog <mijoryx@yahoo.com> - 2013-08-01 18:25 -0700

#1540 — Checking the stack is empty at the end of the program

I would like to check that the stack is empty when a program is
finished. For this I made the following function:
    /endProgram {
        (end program) ==
        pstack
        (there should be nothing between (end program) en this line) ==
    } def

But this displays:
    (end program)
    (there should be nothing between \(end program\) en this line)

It is not a very big problem, but could I display:
    (end program)
    (there should be nothing between (end program) en this line)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#1541

On Wednesday, July 31, 2013 5:16:58 PM UTC-5, Cecil Westerhof wrote:
> I would like to check that the stack is empty when a program is
> 
> finished. For this I made the following function:
> 
>     /endProgram {
> 
>         (end program) ==
> 
>         pstack
> 
>         (there should be nothing between (end program) en this line) ==
> 
>     } def
> 
> 
> 
> But this displays:
> 
>     (end program)
> 
>     (there should be nothing between \(end program\) en this line)
> 
> 
> 
> It is not a very big problem, but could I display:
> 
>     (end program)
> 
>     (there should be nothing between (end program) en this line)
> 
> 

Put the outer parentheses inside the string and use `print`.

  ((there should be nothing between (end program) and this line)) print

[toc] | [prev] | [next] | [standalone]

#1542

Op donderdag 1 aug 2013 00:41 CEST schreef luser:

> On Wednesday, July 31, 2013 5:16:58 PM UTC-5, Cecil Westerhof wrote:
>> I would like to check that the stack is empty when a program is
>>
>> finished. For this I made the following function:
>>
>> /endProgram {
>>
>> (end program) ==
>>
>> pstack
>>
>> (there should be nothing between (end program) en this line) ==
>>
>> } def
>>
>>
>>
>> But this displays:
>>
>> (end program)
>>
>> (there should be nothing between \(end program\) en this line)
>>
>>
>>
>> It is not a very big problem, but could I display:
>>
>> (end program)
>>
>> (there should be nothing between (end program) en this line)
>>
>>
>
> Put the outer parentheses inside the string and use `print`.
>
> ((there should be nothing between (end program) and this line))
> print

Then there is no newline. I changed the code to:
    /endProgram {
        ("end program") ==
        pstack
        (there should be nothing between "end program" and this line) ==
    } def

That is reasonable clear I think.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1543

On 7/31/2013 3:16 PM, Cecil Westerhof wrote:
> I would like to check that the stack is empty when a program is
> finished. For this I made the following function:
>      /endProgram {
>          (end program) ==
>          pstack
>          (there should be nothing between (end program) en this line) ==
>      } def
>
> But this displays:
>      (end program)
>      (there should be nothing between \(end program\) en this line)
>
> It is not a very big problem, but could I display:
>      (end program)
>      (there should be nothing between (end program) en this line)
>

The 'count' operator returns the number of items on the stack.
See page 550 of the PRLM 3rd.

[toc] | [prev] | [next] | [standalone]

#1544

On Wednesday, July 31, 2013 8:36:55 PM UTC-5, Dan Coby wrote:
> On 7/31/2013 3:16 PM, Cecil Westerhof wrote:
> 
> > I would like to check that the stack is empty when a program is
> 
> > finished. For this I made the following function:
> 
> >      /endProgram {
> 
> >          (end program) ==
> 
> >          pstack
> 
> >          (there should be nothing between (end program) en this line) ==
> 
> >      } def
> 
> >
> 
> > But this displays:
> 
> >      (end program)
> 
> >      (there should be nothing between \(end program\) en this line)
> 
> >
> 
> > It is not a very big problem, but could I display:
> 
> >      (end program)
> 
> >      (there should be nothing between (end program) en this line)
> 
> >
> 
> 
> 
> The 'count' operator returns the number of items on the stack.
> 
> See page 550 of the PRLM 3rd.

I agree with Dan here. Using the count operator you can do sthg like

  count {
     (Unexpected object on stack: ) print
     ==
  } repeat

which does nothing if the stack is empty.

[toc] | [prev] | [next] | [standalone]

#1546

Op donderdag 1 aug 2013 08:53 CEST schreef luser:

> On Wednesday, July 31, 2013 8:36:55 PM UTC-5, Dan Coby wrote:
>> On 7/31/2013 3:16 PM, Cecil Westerhof wrote:
>>
>>> I would like to check that the stack is empty when a program is
>>
>>> finished. For this I made the following function:
>>
>>> /endProgram {
>>
>>> (end program) ==
>>
>>> pstack
>>
>>> (there should be nothing between (end program) en this line) ==
>>
>>> } def
>>
>>>
>>
>>> But this displays:
>>
>>> (end program)
>>
>>> (there should be nothing between \(end program\) en this line)
>>
>>>
>>
>>> It is not a very big problem, but could I display:
>>
>>> (end program)
>>
>>> (there should be nothing between (end program) en this line)
>>
>>>
>>
>>
>>
>> The 'count' operator returns the number of items on the stack.
>>
>> See page 550 of the PRLM 3rd.
>
> I agree with Dan here. Using the count operator you can do sthg like
>
> count {
> (Unexpected object on stack: ) print
> ==
> } repeat
>
> which does nothing if the stack is empty.

Good idea, I amended it a little:
    % to be called at the end of a program
    % if stack empty (as it should be) say this
    % otherwise signal this and show the stack
    % ends the program to circumvent/signal it being called to soon
    /endProgram {
        count 0 eq {
            (Stack empty at end of program) ==
            quit
        } {
            count dup
            1 eq {
                (ERROR: object on stack at the end of the program)   ==
            } {
                (ERROR: objects on stack at the end of the program)  ==
            } ifelse
            {
                (Unexpected object on stack: ) print
                ==
            } repeat
            quit
        } ifelse
        (This message should never be shown)       ==
        (If it is, the quit operater is overruled) ==
    } def

In this way I see that endProgram is executed. Also when quit is
overruled it is signalled.

Only one thing is missing. When the stack is not empty, I want to
signal an error. In this way the calling script will terminate. Is
this possible?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1548

On Thursday, August 1, 2013 3:41:29 AM UTC-5, Cecil Westerhof wrote:

> 
> Only one thing is missing. When the stack is not empty, I want to
> signal an error. In this way the calling script will terminate. Is
> this possible?
> 

Sure. In ghostscript, use `signalerror`.

  error-object error-name  signalerror  

Now the error name should be one of the standard postscript
errors if you want to trip the normal mechanism. 
But the error object can be an informative name.

  /STACK-NOT-EMPTY cvx /unregistered signalerror

which results in:
Error: /unregistered in STACK-NOT-EMPTY
...(normal error stack dumps)

[toc] | [prev] | [next] | [standalone]

#1549

Op donderdag 1 aug 2013 11:37 CEST schreef luser:

> On Thursday, August 1, 2013 3:41:29 AM UTC-5, Cecil Westerhof wrote:
>
>>
>> Only one thing is missing. When the stack is not empty, I want to
>> signal an error. In this way the calling script will terminate. Is
>> this possible?
>>
>
> Sure. In ghostscript, use `signalerror`.
>
> error-object error-name  signalerror  
>
> Now the error name should be one of the standard postscript
> errors if you want to trip the normal mechanism. 
> But the error object can be an informative name.
>
> /STACK-NOT-EMPTY cvx /unregistered signalerror
>
> which results in:
> Error: /unregistered in STACK-NOT-EMPTY
> ...(normal error stack dumps)

Works, thanks. Only one thing: I already showed the stack. Is it
possible to circumvent the stack dumps?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1550

On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:
> Op donderdag 1 aug 2013 11:37 CEST schreef luser:
> 
> 
> 
> > On Thursday, August 1, 2013 3:41:29 AM UTC-5, Cecil Westerhof wrote:
> 
> >
> 
> >>
> 
> >> Only one thing is missing. When the stack is not empty, I want to
> 
> >> signal an error. In this way the calling script will terminate. Is
> 
> >> this possible?
> 
> >>
> 
> >
> 
> > Sure. In ghostscript, use `signalerror`.
> 
> >
> 
> > error-object error-name  signalerror  
> 
> >
> 
> > Now the error name should be one of the standard postscript
> 
> > errors if you want to trip the normal mechanism. 
> 
> > But the error object can be an informative name.
> 
> >
> 
> > /STACK-NOT-EMPTY cvx /unregistered signalerror
> 
> >
> 
> > which results in:
> 
> > Error: /unregistered in STACK-NOT-EMPTY
> 
> > ...(normal error stack dumps)
> 
> 
> 
> Works, thanks. Only one thing: I already showed the stack. Is it
> 
> possible to circumvent the stack dumps?
> 

Well, yeah. But aren't you going waaay overboard on this?

Be that as it may, you can install your own error handler
in errordict.

   errordict/unregistered{
      (Error: unregistered in ) print =
   } put

This is the procedure that signalerror looks up and calls.

[toc] | [prev] | [next] | [standalone]

#1551

On Thursday, August 1, 2013 5:53:20 AM UTC-5, luser- -droog wrote:
> On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:

> > Works, thanks. Only one thing: I already showed the stack. Is it
> > possible to circumvent the stack dumps?
> 
> 
> Well, yeah. But aren't you going waaay overboard on this?
> 
> 
> 
> Be that as it may, you can install your own error handler
> in errordict.
> 
>    errordict/unregistered{
>       (Error: unregistered in ) print =

        interrupt %= stop

>    } put
> 
> 
> 
> This is the procedure that signalerror looks up and calls.

[remember to call `interrupt` or `stop` in the error handler
or else it won't bail-out of the execution.]

[toc] | [prev] | [next] | [standalone]

#1552

On Thursday, August 1, 2013 5:56:09 AM UTC-5, luser- -droog wrote:
> On Thursday, August 1, 2013 5:53:20 AM UTC-5, luser- -droog wrote:
> 
> > On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:
> 
> 
> 
> > > Works, thanks. Only one thing: I already showed the stack. Is it
> 
> > > possible to circumvent the stack dumps?
> 
> > 
> 
> > 
> 
> > Well, yeah. But aren't you going waaay overboard on this?
> 
> > 
> 
> > 
> 
> > 
> 
> > Be that as it may, you can install your own error handler
> 
> > in errordict.
> 
> > 
> 
> >    errordict/unregistered{
> 
> >       (Error: unregistered in ) print =
> 
> 
> 
>         interrupt %= stop
> 
> 
> 
> >    } put
> 
> > 
> 
> > 
> 
> > 
> 
> > This is the procedure that signalerror looks up and calls.
> 
> 
> 
> [remember to call `interrupt` or `stop` in the error handler
> 
> or else it won't bail-out of the execution.]

Actually, after looking at the error code again,

http://code.google.com/p/xpost/source/browse/err.ps

(borrowed from the book Inside Postscript),
it's errordict/handleerror that you'd want to override.
That's the procedure that prints out the error report.

Although the above will probably work (maybe not, since
we're explicitly calling signalerror), it bypasses 
several steps.

[toc] | [prev] | [next] | [standalone]

#1555

Op donderdag 1 aug 2013 13:23 CEST schreef luser:

> On Thursday, August 1, 2013 5:56:09 AM UTC-5, luser- -droog wrote:
>> On Thursday, August 1, 2013 5:53:20 AM UTC-5, luser- -droog wrote:
>>
>>> On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:
>>
>>
>>
>>>> Works, thanks. Only one thing: I already showed the stack. Is it
>>
>>>> possible to circumvent the stack dumps?
>>
>>>
>>
>>>
>>
>>> Well, yeah. But aren't you going waaay overboard on this?
>>
>>>
>>
>>>
>>
>>>
>>
>>> Be that as it may, you can install your own error handler
>>
>>> in errordict.
>>
>>>
>>
>>> errordict/unregistered{
>>
>>> (Error: unregistered in ) print =
>>
>>
>>
>> interrupt %= stop
>>
>>
>>
>>> } put
>>
>>>
>>
>>>
>>
>>>
>>
>>> This is the procedure that signalerror looks up and calls.
>>
>>
>>
>> [remember to call `interrupt` or `stop` in the error handler
>>
>> or else it won't bail-out of the execution.]
>
> Actually, after looking at the error code again,
>
> http://code.google.com/p/xpost/source/browse/err.ps
>
> (borrowed from the book Inside Postscript),
> it's errordict/handleerror that you'd want to override.
> That's the procedure that prints out the error report.
>
> Although the above will probably work (maybe not, since
> we're explicitly calling signalerror), it bypasses 
> several steps.

Now it works:
    % to be called at the end of a program
    % if stack empty (as it should be) say this
    % otherwise signal this and show the stack
    % ends the program to circumvent/signal it being called to soon
    /endProgram {
        count 0 eq {
            (Stack empty at end of program) ==
            quit
        } {
            count dup
            1 eq {
                (ERROR: object on stack at the end of the program)   ==
            } {
                (ERROR: objects on stack at the end of the program)  ==
            } ifelse
            {
                (Unexpected object on stack: ) print
                ==
            } repeat
            errordict/handleerror {
                interrupted
            } put
            /STACK-NOT-EMPTY cvx /unregistered signalerror
        } ifelse
        (This message should never be shown)       ==
        (If it is, the quit operater is overruled) ==
    } def

And now I get:
    $ psConvert.sh brainDump.ps 
    15:35:01: converting postscript
    15:35:06: generating PDF
    (ERROR: object on stack at the end of the program)
    Unexpected object on stack: (test endProgram)
    $

And when I cleanup the stack I get (default the PDF is converted to
PNG('s)):
    $ psConvert.sh brainDump.ps 
    15:39:44: converting postscript
    15:39:48: generating PDF
    (Stack empty at end of program)
    15:39:49: generating graphics
    15:39:50: brainDump.ps converted
    $

I am happy now: thanks.

By the way: what is the difference between interrupted and stop?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1553

Op donderdag 1 aug 2013 12:53 CEST schreef luser:

> On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:
>> Op donderdag 1 aug 2013 11:37 CEST schreef luser:
>>
>>
>>
>>> On Thursday, August 1, 2013 3:41:29 AM UTC-5, Cecil Westerhof wrote:
>>
>>>
>>
>>>>
>>
>>>> Only one thing is missing. When the stack is not empty, I want to
>>
>>>> signal an error. In this way the calling script will terminate.
>>>> Is
>>
>>>> this possible?
>>
>>>>
>>
>>>
>>
>>> Sure. In ghostscript, use `signalerror`.
>>
>>>
>>
>>> error-object error-name  signalerror  
>>
>>>
>>
>>> Now the error name should be one of the standard postscript
>>
>>> errors if you want to trip the normal mechanism. 
>>
>>> But the error object can be an informative name.
>>
>>>
>>
>>> /STACK-NOT-EMPTY cvx /unregistered signalerror
>>
>>>
>>
>>> which results in:
>>
>>> Error: /unregistered in STACK-NOT-EMPTY
>>
>>> ...(normal error stack dumps)
>>
>>
>>
>> Works, thanks. Only one thing: I already showed the stack. Is it
>>
>> possible to circumvent the stack dumps?
>>
>
> Well, yeah. But aren't you going waaay overboard on this?

A little bit maybe, but this is the foundation I am going to build on,
so better make it a good one. ;-)

I am thinking about letting my preprocessor always add endProgram at
the end. This makes sure I see a certain type of errors in my code.


> Be that as it may, you can install your own error handler
> in errordict.
>
> errordict/unregistered{
> (Error: unregistered in ) print =
> } put
>
> This is the procedure that signalerror looks up and calls.

There is no stack dump, but the program is not terminated also. So
that does not work.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#1557

On Thursday, August 1, 2013 6:18:41 AM UTC-5, Cecil Westerhof wrote:
> Op donderdag 1 aug 2013 12:53 CEST schreef luser:
> > On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:
> >> Op donderdag 1 aug 2013 11:37 CEST schreef luser:
> >>> On Thursday, August 1, 2013 3:41:29 AM UTC-5, Cecil Westerhof wrote:
> >>>> Only one thing is missing. When the stack is not empty, I want to
> >>>> signal an error. In this way the calling script will terminate.
> >>>> Is
> >>>> this possible?
> >>>>
> >>> Sure. In ghostscript, use `signalerror`.
> >>>
> >>> error-object error-name  signalerror  
> >>>
> >>> Now the error name should be one of the standard postscript
> >>> errors if you want to trip the normal mechanism. 
> >>> But the error object can be an informative name.
> >>>
> >>> /STACK-NOT-EMPTY cvx /unregistered signalerror
> >>>
> >>> which results in:
> >>> Error: /unregistered in STACK-NOT-EMPTY
> >>> ...(normal error stack dumps)
> >>
> >> Works, thanks. Only one thing: I already showed the stack. Is it
> >> possible to circumvent the stack dumps?
> >
> > Well, yeah. But aren't you going waaay overboard on this?
> A little bit maybe, but this is the foundation I am going to build on,
> so better make it a good one. ;-)
> 
> I am thinking about letting my preprocessor always add endProgram at
> the end. This makes sure I see a certain type of errors in my code.
> 
> 
> > Be that as it may, you can install your own error handler
> > in errordict.
> >
> > errordict/unregistered{
> 
> > (Error: unregistered in ) print =
> 
> > } put
> 
> >
> 
> > This is the procedure that signalerror looks up and calls.

I got this backwards. errordict/errorname procedures
*call* `signalerror`, which collects error information
and then calls `interrupt`.

> 
> There is no stack dump, but the program is not terminated also. So
> 
> that does not work.
> 

In your /handleerror, it should be `interrupt`, not
`interrupted`. And this is the procedure that prints
the error report. One way of defining it is this:

    errordict /handleerror {
        //$error begin
            newerror {
                /newerror false def
                (%%[ Error: ) print
                errorname //=print exec
                (; OffendingCommand: ) print
                /command load //=print exec
%comment these 4 lines to suppress stack dumps:
                (]%%\n) print
                (Stack:\n) print
                ostack { = } forall
                (ExecStack:\n) print
                estack { = } forall
                flush
            } if
        end
    } put 

[toc] | [prev] | [next] | [standalone]

#1562

On Thursday, August 1, 2013 11:33:07 AM UTC-5, luser- -droog wrote:
> On Thursday, August 1, 2013 6:18:41 AM UTC-5, Cecil Westerhof wrote:
> 
> > Op donderdag 1 aug 2013 12:53 CEST schreef luser:
> 
> > > On Thursday, August 1, 2013 5:40:46 AM UTC-5, Cecil Westerhof wrote:
> 
> > >> Op donderdag 1 aug 2013 11:37 CEST schreef luser:
> 
> > >>> On Thursday, August 1, 2013 3:41:29 AM UTC-5, Cecil Westerhof wrote:
> 
> > >>>> Only one thing is missing. When the stack is not empty, I want to
> 
> > >>>> signal an error. In this way the calling script will terminate.
> 
> > >>>> Is
> 
> > >>>> this possible?
> 
> > >>>>
> 
> > >>> Sure. In ghostscript, use `signalerror`.
> 
> > >>>
> 
> > >>> error-object error-name  signalerror  
> 
> > >>>
> 
> > >>> Now the error name should be one of the standard postscript
> 
> > >>> errors if you want to trip the normal mechanism. 
> 
> > >>> But the error object can be an informative name.
> 
> > >>>
> 
> > >>> /STACK-NOT-EMPTY cvx /unregistered signalerror
> 
> > >>>
> 
> > >>> which results in:
> 
> > >>> Error: /unregistered in STACK-NOT-EMPTY
> 
> > >>> ...(normal error stack dumps)
> 
> > >>
> 
> > >> Works, thanks. Only one thing: I already showed the stack. Is it
> 
> > >> possible to circumvent the stack dumps?
> 
> > >
> 
> > > Well, yeah. But aren't you going waaay overboard on this?
> 
> > A little bit maybe, but this is the foundation I am going to build on,
> 
> > so better make it a good one. ;-)
> 
> > 
> 
> > I am thinking about letting my preprocessor always add endProgram at
> 
> > the end. This makes sure I see a certain type of errors in my code.
> 
> > 
> 
> > 
> 
> > > Be that as it may, you can install your own error handler
> 
> > > in errordict.
> 
> > >
> 
> > > errordict/unregistered{
> 
> > 
> 
> > > (Error: unregistered in ) print =
> 
> > 
> 
> > > } put
> 
> > 
> 
> > >
> 
> > 
> 
> > > This is the procedure that signalerror looks up and calls.
> 
> 
> 
> I got this backwards. errordict/errorname procedures
> 
> *call* `signalerror`, which collects error information
> 
> and then calls `interrupt`.
> 
> 
> 
> > 
> 
> > There is no stack dump, but the program is not terminated also. So
> 
> > 
> 
> > that does not work.
> 
> > 
> 
> 
> 
> In your /handleerror, it should be `interrupt`, not
> 
> `interrupted`. And this is the procedure that prints
> 
> the error report. One way of defining it is this:
> 
> 
> 
>     errordict /handleerror {
> 
>         //$error begin
> 
>             newerror {
> 
>                 /newerror false def
> 
>                 (%%[ Error: ) print
> 
>                 errorname //=print exec
> 
>                 (; OffendingCommand: ) print
> 
>                 /command load //=print exec
> 
> %comment these 4 lines to suppress stack dumps:
> 
>                 (]%%\n) print
> 
>                 (Stack:\n) print
> 
>                 ostack { = } forall
> 
>                 (ExecStack:\n) print
> 
>                 estack { = } forall
> 
>                 flush
> 
>             } if
> 
>         end
> 
>     } put

For ghostscript, replace `//=print exec` with `=only`.
The rest are all standard names. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web