Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!islington-terrace.csc.ti.com!pf From: pf@islington-terrace.csc.ti.com (Paul Fuqua) Newsgroups: comp.sys.ti.explorer Subject: Re: PDL Message-ID: <2837261731-9120323@Islington-Terrace> Date: 28 Nov 89 16:15:31 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 72 Date: Monday, November 27, 1989 11:32pm (CST) From: raskin at ee.ecn.purdue.edu (Victor Raskin) Subject: PDL Are there any risks involved in changing the PDL? Are there limits (inherent or practically recommendable)? There aren't any risks in changing the size of the PDL. There really aren't any limits, aside from those limiting the size of any array (since PDLs are just arrays of type ART-REG-PDL and ART-SPECIAL-PDL (the former for argument/control stacks, the latter for special-variable bindings)). In fact, MAKE-STACK-GROUP and all its users, including MAKE-PROCESS and PROCESS-RUN-FUNCTION, allow a :REGULAR-PDL-SIZE argument so you can specify the sizes at creation time. You can also do it in the init-forms of flavors built on TV:PROCESS-MIXIN. See page 6-13 in the Window manual or the :init methods and daemons for ZWEI:ZMACS-FRAME and W:LISTENER-MIXIN-INTERNAL. There are times when you can't do that, for instance if you don't want to run in a separate process. I ran into one of those situations a year or so ago and did something I include below. It wraps a condition handler around the offending piece of code that allows up to ten automatically-grown pdl-overflows (controlled by a variable) before signalling an error. Within the body of the function, I have (let ((overflow-count 0) ; Allow several automatically-handled pdl overflows. (eh:*allow-pdl-grow-message* nil)) (condition-bind ((sys:pdl-overflow 'grow-pdl (locf overflow-count))) )) and somewhere else (usually nearby) I define (defparameter *pdl-overflow-count* 9) (defun grow-pdl-handler (c n-loc) (cond ((not (string= (symbol-name (send c :pdl-name)) "REGULAR")) nil) ((>= (contents n-loc) *pdl-overflow-count*) (setf (contents n-loc) 0) nil) (:else (incf (contents n-loc)) :grow-pdl))) The CONDITION-BIND sends control to GROW-PDL on pdl-overflow errors. Binding EH:*ALLOW-PDL-GROW-MESSAGE* to NIL inhibits the "[Growing pdl to N]" messages. The handler checks the symbol-name of the :PDL-NAME slot of the signalled condition because I only want to handle regular-pdl overflows (I've hardly ever seen special-pdl overflows), and some places set the slot to :REGULAR and some to EH:REGULAR. I use a locative to a local for the running count because in some perverse way it seems cleaner than binding another special. If the count is exceeded or the overflow is not in the regular PDL, the handler returns NIL so the debugger will get it. Otherwise, it returns :GROW-PDL, the proceed-type that is also used by the Resume key in the debugger. I hope this is of some use. Paul Fuqua pf@csc.ti.com {smu,texsun,cs.utexas.edu,rice}!ti-csl!pf Texas Instruments Computer Science Center PO Box 655474 MS 238, Dallas, Texas 75265