Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: A Decent Environment. Where is it? (some flame, some advice) Message-ID: <11746@think.UUCP> Date: Thu, 12-Nov-87 18:06:47 EST Article-I.D.: think.11746 Posted: Thu Nov 12 18:06:47 1987 Date-Received: Sat, 14-Nov-87 20:42:14 EST References: <21493@ucbvax.BERKELEY.EDU> <2630001@hpfcmp.HP.COM> Sender: usenet@think.UUCP Reply-To: barmar@sauron.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 86 In article <179@utah-orion.UUCP> shebs@orion.utah.edu.UUCP (Stanley T. Shebs) writes: > But consider that a high-level debugger must know >about the language implementation, and therefore be different for each. >The Symbolics debugger is only useful for official Symbolics languages. No, it's useful for any language that generates code in the same style as Symbolics's languages. Just because a language wasn't implemented by the vendor doesn't mean that it can't produce the data that the debugger needs. There may be documentation issues, in that Symbolics doesn't document everything that a language implementor must do to be compatible, but that is different from a technical inability. >If I were to, say, port PSL to a Symbolics, the pre-existing debugger would >be quite useless. Only if you choose not to put the effort into your port to make it generate Symbolics standard functions. If you want the edebugger to be able to figure out local variable names, all you have to do is generate a local-map; if you want it to be able to find the source line associated with an instruction, generate source-locators. Of course, it goes without saying that you should follow Symbolics's stack discipline. Before I was a Symbolics user I was a Multics user. In Multics, the entire runtime environment is standardized across all languages (except some esoteric ones like MacLisp and SNOBOL). They all use the same stack frame layouts, the same argument list formats, even the same data type descriptors (the Multics equivalent of varargs allows the subroutine to determine the data type of the parameter). Object file formats are similarly standardized. This means that the same debugging tools are useful for all languages that follow the standards. > Unix systems run a great variety of languages. There are >C debuggers out there, but C is a very low-level language, and it's quite >easy for a C program to trash things so badly that the symbolic debugger's >own data structures are destroyed. Well, if a program trashes its stack, very few debugging systems can deal with it. Most of the other data structures that debuggers need are in the read-only section of the object file, and are unlikely to be trashed (this isn't as true on a dynamically-linked system, where it is possible to destroy the linkage between subroutines). >Now if one were to take a tools-oriented approach to debugging, there would >be a small language/interface to specify types of debugging actions, the state >of execution would be available as a normal data object to be looked at, the >user interface would be separate from the basic breakpoint/examine/step code, >and the debugger would have a published interface to the language system, >so that a conforming language would be usable with that debugger. Even >Lisp machine debuggers haven't managed all that yet (unless there's an >amazing new one I haven't heard about?). We've been told that the debugger coming in the next Symbolics release will be sensitive to the language of the program it is debugging, and allow the user to type in expressions in the appropriate syntax. As far as I'm concerned, that's the only part of a debugger that should be language-dependent. Stack tracing, stepping, and breakpoints deal with language-independent data structures. >To take a realistic example, I've been having to debug some subtle misbehavior >where I'm not quite sure what exactly is wrong. I've been applying pipes of >Unix tools (grep mostly) to a 1-2 megabyte log file, trying to get a feel for >patterns in it. Even a Lisp machine has a hard time dealing with dozens of >ephemeral objects each several megabytes in size... To take another example, >Aho, Sethi, and Ullmann formatted the multi-megabytes of their compiler book >with a long pipe of various tools. (no, I'm not defending troff!) I'm still not sure what the point you're trying to make is. First of all, people rarely debug programs using large data sets; when you are debugging you create small sample data sets, if only just to speed up the debugging cycle. I'm sure that when people debug long pipelines they do it by incrementally building up from pairs and triples, perhaps sending intermediate output to files so they can examine the results. I do the same thing in Lisp: I create lists 5-10 elements long, save the results of things on other little lists, etc. Of course, most of the time you only need to debug the function that is being called on each iteration, so you don't even need a list. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar