Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcrdcf.UUCP
Path: utzoo!utcs!lsuc!pesnta!hplabs!sdcrdcf!darrelj
From: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Newsgroups: net.arch,net.ai,net.lang,net.lang.lisp
Subject: Re: Lisp Machines
Message-ID: <2020@sdcrdcf.UUCP>
Date: Fri, 24-May-85 09:45:04 EDT
Article-I.D.: sdcrdcf.2020
Posted: Fri May 24 09:45:04 1985
Date-Received: Sat, 25-May-85 22:22:26 EDT
References: <922@noscvax.UUCP> <5604@utzoo.UUCP> <3345@utah-cs.UUCP> <4314@mit-eddie.UUCP> <3346@utah-cs.UUCP> <63644@apple.UUCP>
Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Organization: System Development Corp. R+D, Santa Monica
Lines: 17
Xref: utcs net.arch:1231 net.ai:2627 net.lang:1564 net.lang.lisp:454
Summary: 

The main reason I debug running compiled code (on Xerox lisp machines) is
the substantial difference in speed between native code and interpretation.
Because the Xerox debugging tools are unable to do much inside compiled
code, I switch back to source for the current problem function only.
[The Xerox break package only works at the point a function is about to be
entered.  As a result, inline errors may result in unwinding back to
"before" the error occurred and then breaking.]

-- 
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
                                                            !sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA