oster@dewey.soe.berkeley.edu.UUCP (10/29/87)
I've been using Lucid Common Lisp + Portable Common Loops + X version 10
on Sun 3/50 and Sun 3/160 hardware, and I am very unhappy with the system.
If anyone has any advise, or can tell me how to get software to ameliorate
some of my problems, I would truly appreciate it.
I'd be happy to switch from Lucid to Franz, if it made a big difference in
programmer productivity. (We are using Lucid because our program runs twice
as fast under Lucid as Franz, and Franz tends to core dump if you call
an X function with incorrect arguments.)
1.) I'm having these problems with the debugger:
Has anyone fixed it to allow single-stepping from a breakpoint?
(I can set breakpoints, and I can single step, but my problems are all
deep within large systems. For the moment, I set a breakpoint, recompile,
run, and at the break, compile a fresh version of the function without
the breakpoint, laborously call it under the stepper with the same arguments
that the break trace shows (using :l 0, :l 1, :l 2 to get the arguments
where I can setq them into temporaries.))
Has anyone fixed it to allow continuing the stepper with just a mouse
click?
(I have to type ":n<return>" now, which is pretty painful.)
Has anyone fixed it so that it preserves the names of the local variables?
(local 0...n are hard to associate with the names in the original code.)
Has anyone fixed PCL so it uses gensyms based on the original method
names?
(most of the procedures on my backtrace are completely anonymous gensyms.)
Has anyone fixed it so I can see data structures, each in its own
window, as scrollable list of labelled data field where I can click
and type at a data value to change it? I want to edit the stack backtrace
as a scrollable list of scrollable lists.
Is there a package so that I can examine interlinked data structures as
a graph, and edit it by mousing on and dragging the links?
Is there anything like the InterLisp advise package, so I can decorate
functions with preambles and postambles without having to recompile them?
Does anyone have a window based stepper that will show me the current
expression, underlined, in an editor window?
Does anyone have a decent code profiler? (I want to click on a button,
run something, click the button off, and get a graph of the calling tree,
with a bar for each function of how often it got called and how much time
it took.)
2.) X problems
Has anyone fixed X so that it will save the bitmap of my output
window and restore it when that window is re-revealed? (My program is still
too sick to burden my programming with worrying about redraw events.)
(this is in the spec for X v11, but no-one has implemented it, and X v11
is still too rocky for us to convert.)
Where is the fix to Xv10 to allow clipboards longer than 512 characters?
Actually, this may be more nearly a problem with pipe blockage running
processes under emacs.
(I'm having problems with Lucid's built-in mini-emacs, but if I run
lucid under real emacs, this problem makes it impossible to send a
complete function definition to Lucid.)
Does anyone have file for emacs for running lisp that maintains the
common lisp package environment?
3.) I'm having these problems with Lucid's editor:
Has anyone fixed Lucid's built-in mini-emacs so that it doesn't trash
my files? (I've had problems with extra text showing up in my source code.)
So it doesn't abort if I un-thinkingly edit a directory? (like you can in
real emacs.)
So you can position the cursor on a function name and have it display
the calling sequence in the mini-buffer?
So you can position the cursor on a function name and have it display the
documentation? the definition?
So you can position the cursor on a function name and have it display
a list of windows, each window centered on the function who called it?
How do I make it command complete my function names?
Running under the editor, it doesn't tell me it is garbage collecting
until it finishes. I need to know before that so I won't get frustrated
by the frequent wait-15-seconds-while-it-garbage-collects. has anyone
fixed this?
----------------
I'm not asking for much, just a bare minimum of programmer's tools
for doing serious lisp programming on a workstation.
I apologize if I'm wasting the net's time and the answers to these
requests are already in documentation I have.
Please answer by E-mail. I will repost if there is any interest.
--- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edurshu@zodiac.UUCP (10/30/87)
In article <21493@ucbvax.BERKELEY.EDU> you write: >I've been using Lucid Common Lisp + Portable Common Loops + X version 10 >on Sun 3/50 and Sun 3/160 hardware, and I am very unhappy with the system. > No kidding. >If anyone has any advise, or can tell me how to get software to ameliorate >some of my problems, I would truly appreciate it. > So would I. My advice is buy a *REAL* Lisp Machine (i.e. Symbolics) >(I'm having problems with Lucid's built-in mini-emacs, but if I run >lucid under real emacs, this problem makes it impossible to send a >complete function definition to Lucid.) > Sorry for the flipness of this reply. I have also been struggling with the SUN environment (FRANZ and GNUEMACS) and I ***HATE*** it. Where the #$#%@@ is the window inspector, the flavor examiner, etc. Seriously, I find that using Gnuemacs' inferior lisp mode (aptly named when referring to Franz or Lucid) to communicate to Franz is marginally acceptable. I make my Emacstool window as wide as the entire screen and almost as tall and then split it in two using c-x 5. I then do a M-x run-lisp (I've modified the emacs variable "inferior-lisp-program" so that run-lisp runs Franz instead of Lucid). Now I can cut and paste from either the Lisp buffer or any other buffer. I use C-m-x to send function definitions from gnuemacs to the inferior-lisp buffer. I haven't sent very large functions but Franz seems to be reading a temp file so my guess is that there shouldn't be any size limitation. By the way, make sure to use Emacstool so that Emacs will know about the mouse. I find Gnuemacs enticing because the source is available. I haven't hacked the sources much yet but the fact that I can makes a big difference. After working in Symbolics Release 6 for two years, I'm spoiled by the availability of source code. Too bad Symbolics is becoming secretive. I'm beginning to think that Stallman and the Free Software Foundation are not so bonkers after all. But that's the topic for a different flame. > >---------------- >I'm not asking for much, just a bare minimum of programmer's tools >for doing serious lisp programming on a workstation. Clearly, you're asking for more than most computer manufacturer's are willing to deliver. Pity the poor programmers of conventional languages who don't even EXPECT this level of support, let alone get it. Once again, buy a Symbolics. (Maybe, just maybe, Sun's SPE will be an acceptable improvement whenever it shows up). > >--- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. >Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Neither even qualifies as a poor Symbolics. -- Richard F. Shu Today, the Fulda Gap. Tomorrow, the world.
chan@hpfcmp.HP.COM (Chan Benson) (11/02/87)
It doesn't do you much good since you're running on a Sun, but take a
look at HP's Common Lisp environment running on our Series 300 Unix
workstations sometime. The Emacs based NMODE environment has much of
the debugging and development tools that are missing in the Lucid
environment on Sun. It's not as window oriented as a Symbolics and at
the moment it doesn't have Flavors or access to X (since it runs in HP's
proprietary windowing system), but it's lots better than the other
workstation offerings in terms of programming features.
Any unbiased HP Lisp users from the grants program care to comment? If
you have any specific questions about features, e-mail them and I'll
try and answer.
-- Chan Benson
HP Fort Collins
(303) 229-3892
{ihnp4|hplabs}!hpfcla!chansteve@siemens.UUCP (Steve Clark) (11/05/87)
As long as everyone is plugging their favorite Lisp environment, I have to throw in my 2 cents. When I read the original message, I honestly thought the guy was going to say he had come from the Xerox Interlisp-D environment. The things he expected, which weren't there, are what I am used to in the Interlisp-D environment (with the exception of X, whose implementation in Interlisp is still in its infancy). Now for the good news: Not only has Xerox (finally) come through with Common Lisp on their workstations (although CL has lots of disadvantages (and a few advantages) over Interlisp-D), but the latest news is that Xerox will stop making their own hardware in the next few years, and move all their great stuff onto SUN-4's. I wouldn't expect to see anything for at least a year, and by the time they are ready they will doubtless have gotten all the great things in Interlisp-D to run in Common Lisp.
shebs@utah-orion.UUCP (Stanley T. Shebs) (11/07/87)
In article <2630001@hpfcmp.HP.COM> chan@hpfcmp.HP.COM (Chan Benson) writes: >It doesn't do you much good since you're running on a Sun, but take a >look at HP's Common Lisp environment running on our Series 300 Unix >workstations sometime. The Emacs based NMODE environment has much of >the debugging and development tools that are missing in the Lucid >environment on Sun. > >Any unbiased HP Lisp users from the grants program care to comment? (What is "unbiased" is supposed to mean?) Utah's comment on NMODE is that we don't use it anymore. It was great on the old Chipmunk Pascal workstations, but has gone downhill steadily since then. It's slow, flaky, and restrictive. No sources, so we can't fix things; doesn't understand termcap/lib, so can't run from anywhere except the workstation; huge, so you get a choice of thrashing VM or doing long waits for the GC; excessive consing, so GCs are not uncommon while you're typing (how any editor could manage to cons while reading characters is beyond me); no multiple control threads, so can't edit while a Lisp program is running; and more. Kind of a shame, since the hardware is outstanding, and the original NMODE was really fun to use. Definitely a case of galloping featurism getting in the way of little things like editing text. At present, we use Gnumacs with HP CL as a subprocess. We lose debugging goodies, but it's better than getting stopped cold with a minute-long GC while typing a program in, or losing files because your Lisp code had a bug in it... > -- Chan Benson While I'm here, I'd like to make a plea for more flexible Lisp programming environments. People coming out of Interlisp/Symbolics traditions are very big on integration, but have no concept of tools. How hard can it be to supply grep and wc and diff? There is just one way to use the environments now; program in exactly the way the developers insist on (i.e. get an error, jump into monster debug menu). If your style is even slightly different, it's quite painful to deal with. Even a few customization options would be better than nothing... stan shebs shebs@cs.utah.edu
dzzr@beta.UUCP (Douglas J Roberts) (11/09/87)
In article <177@utah-orion.UUCP>, shebs@utah-orion.UUCP (Stanley T. Shebs) writes: > In article <2630001@hpfcmp.HP.COM> chan@hpfcmp.HP.COM (Chan Benson) writes: > . . . SOME STUFF DELETED . . . > While I'm here, I'd like to make a plea for more flexible Lisp programming > environments. People coming out of Interlisp/Symbolics traditions are very > big on integration, but have no concept of tools. HA! The 15 or so of us in my group who have experimented with Knowledge Engineering Environment (KEE) and LISP running on a SUN would *swear* that UNIX folks had never heard of software development tools! However, we have been promised that this will change when SUN releases their Symbolic Programming Environment (SPE). We are told that it will provide a usable window debugger, multiple LISP listeners, and a slew of other goodies that may compare favoribly with the rich development environment provided by a Symbolics. -- --------------------------------------------------------------- Doug Roberts dzzr@lanl.gov ---------------------------------------------------------------
shebs@utah-orion.UUCP (Stanley T. Shebs) (11/10/87)
In article <12076@beta.UUCP> dzzr@beta.UUCP (Douglas J Roberts) writes: >HA! The 15 or so of us in my group who have experimented with Knowledge >Engineering Environment (KEE) and LISP running on a SUN would *swear* >that UNIX folks had never heard of software development tools! This is a very puzzling remark. Unix systems were the first to exploit the idea of using tools instead of big, fancy, and inflexible systems (recent years have seen a proliferation of such systems in Unix, though). Perhaps there's a misconception - when I say "tool", I have in mind the software equivalents of hammers and screwdrivers and bench saws. Sure, three-story-high milling machines are amazing creations, but everything they do has to be cast in terms of milling (for instance, cutting = engraving a channel so deep it goes all the way through), and they are totally useless for anything that the milling machine designers did not think of already. Getting back to software, there is *no* programming environment designer clever enough to anticipate what I want to do. They're better off supplying a set of simpler tools that can fit together in different ways. In Unix, the interface is a character stream, which is good for text and general file processing, but bad for Lisp. A tool-oriented Lisp environment would presumably use S-expressions as the basic interface, although one would probably need some sort of lazy version, so that heap space isn't exhausted by the creation of one intermediate object. Useful operations include many already in Common Lisp, such as sorting, set operations, and reversing, but extended to operate on incompletely-defined things. Generalization of streams is a good thing as well. (For some more ideas like this, see the Fraser/Hanson paper on the EZ programming environment in POPL 85.) A classic example of tool usage in Unix is the one-line spelling checker; I have yet to see any Lisp programming environment support anything quite as elegant and useful. There is actually an interesting research question here: integration vs tools. Both approaches have their advantages and disadvantages, and nobody really knows enough about programming environments to say which is better, and under what conditions. Unfortunately, doing believable experiments on this sort of question involves a horrendous amount of work... > Doug Roberts > dzzr@lanl.gov stan shebs shebs@cs.utah.edu
barmar@think.COM (Barry Margolin) (11/11/87)
In article <178@utah-orion.UUCP> shebs@orion.utah.edu.UUCP (Stanley T. Shebs) writes: >In article <12076@beta.UUCP> dzzr@beta.UUCP (Douglas J Roberts) writes: > >>HA! The 15 or so of us in my group who have experimented with Knowledge >>Engineering Environment (KEE) and LISP running on a SUN would *swear* >>that UNIX folks had never heard of software development tools! > >This is a very puzzling remark. Unix systems were the first to exploit >the idea of using tools instead of big, fancy, and inflexible systems >(recent years have seen a proliferation of such systems in Unix, though). >Perhaps there's a misconception - when I say "tool", I have in mind the >software equivalents of hammers and screwdrivers and bench saws. I think the two of you are talking about different things when you say "software development tools". Everyone knows that Unix is built on a toolbox philosophy. Unix provides many tools for use in applications. However, Unix is lacking many tools that directly aid the programming process. The most significant lack is in the debuggers. I don't think there are any Unix debuggers that even come close the Symbolics Lisp Machine debugger. Unix is twice as old as Lisp Machines, and you'd think that with all the zillions of lines of C code that have been written for Unix there would be some really amazing debuggers by now. On the contrary, I suspect that there are still a large number of Unix programmers using adb, not even source-level debugging. >Getting back to software, there is *no* programming environment designer >clever enough to anticipate what I want to do. They're better off supplying >a set of simpler tools that can fit together in different ways. In Unix, >the interface is a character stream, which is good for text and general file >processing, but bad for Lisp. A tool-oriented Lisp environment would >presumably use S-expressions as the basic interface, although one would >probably need some sort of lazy version, so that heap space isn't exhausted >by the creation of one intermediate object. I don't understand this point. I create lots of intermediate objects all the time while debugging and prototyping in Lisp. > Useful operations include >many already in Common Lisp, such as sorting, set operations, and reversing, >but extended to operate on incompletely-defined things. Most of these operations are generalized to some extent in Common Lisp; in my view, this was one of its most significant innovations. All the set, list, and sequence operations take options specifying how to operate on the elements; for example, SORT lets the programmer specify a comparison function and a function for extracting the key, and set operations let you specify the equality function. > Generalization of >streams is a good thing as well. (For some more ideas like this, see the >Fraser/Hanson paper on the EZ programming environment in POPL 85.) > >A classic example of tool usage in Unix is the one-line spelling checker; >I have yet to see any Lisp programming environment support anything quite >as elegant and useful. You can do an amazing amount in one line of APL, too, but that doesn't make it a great language (please, no flaming from the APL enthusiasts). --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmare
shebs@utah-orion.UUCP (Stanley T. Shebs) (11/12/87)
In article <11639@think.UUCP> barmar@sauron.UUCP (Barry Margolin) writes: >[...] I don't think there >are any Unix debuggers that even come close the Symbolics Lisp Machine >debugger. Unix is twice as old as Lisp Machines, and you'd think that >with all the zillions of lines of C code that have been written for >Unix there would be some really amazing debuggers by now. On the >contrary, I suspect that there are still a large number of Unix >programmers using adb, not even source-level debugging. You have a good point. 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. If I were to, say, port PSL to a Symbolics, the pre-existing debugger would be quite useless. 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. Adb has the advantage that it *almost* always works (although I've been in situations in Lisp implementation work where even adb couldn't fathom what had happened...). 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?). >>A tool-oriented Lisp environment would >>presumably use S-expressions as the basic interface, although one would >>probably need some sort of lazy version, so that heap space isn't exhausted >>by the creation of one intermediate object. > >I don't understand this point. I create lots of intermediate objects >all the time while debugging and prototyping in Lisp. 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!) >> Useful operations include >>many already in Common Lisp, such as sorting, set operations, and reversing, >>but extended to operate on incompletely-defined things. > >Most of these operations are generalized to some extent in Common >Lisp; in my view, this was one of its most significant innovations. >[...] I'm all too familiar with CL sequence functions and their innards! :-) :-( Nevertheless, they must conform to Lisp's strictness - the arguments are completely evaluated before the operation starts. In general, I was suggesting a research program rather than demanding a particular kind of Lisp environment. Certainly it's not reasonable to make Lisp look like Unix or APL or EZ! On the other hand, although Lisp people might once have had the lead in environments, not much has happened in recent years, and people working in conventional languages are catching up fast. It's disappointing to see a defense of the status quo rather than new ideas. >Barry Margolin >Thinking Machines Corp. stan shebs shebs@cs.utah.edu
alex@umbc3.UUCP (11/12/87)
<mucho stuff made gone...>
There has been much heated discussion about what is wrong with various systems,
but mostly vaguaritys & generalizations...SO:
I am running KCL on an AT&T 3b1, I also have GNU Emacs. As an extension to
a school project, I would like to design a working environment for lisp stuff.
I plan to write all the code (unless someone else is interested :-)) and have
an abundance of tools, graphics, windows, mouse, menus, editors, lisp etc.
So my question: What makes a good lisp environment? do i need/want
full unix shell stuff inside of lisp? I can link all of the syscalls into
lisp & dynamicly load a shell, but the command syntax seems a bit odd. also,
while i can get lisp to fork, forking 2meg of lisp for ls is a bit extranious.
I am considering satalite processes, like a shell & editor, & communicatiion
through message packes or pipes, but...
SO, In 25 words or less, What do you want?? whate shal i go? what shal
i do? all suggestions are welcome! either post or email & i will summerize.
:alex.
alex@umbc3.umd.edu
.
barmar@think.COM (Barry Margolin) (11/13/87)
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
shebs@utah-orion.UUCP (Stanley T. Shebs) (11/14/87)
In article <11746@think.UUCP> barmar@sauron.UUCP (Barry Margolin) writes: >Only if you choose not to put the effort into your port to make it >generate Symbolics standard functions. [...] >Of course, it goes without saying that you should follow Symbolics's >stack discipline. The reason I mentioned PSL specifically is that it uses a register protocol instead of a stack protocol. That's what I meant about environment designers not being clever enough to anticipate what programmers will come up with. It shouldn't "go without saying" that I have to implement my languages the way somebody else implemented theirs. After all, the whole point of higher level languages is to allow different implementations! >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). [...] This is good but too restrictive. It's analogous to the use of intermediate languages in optimizing compilers - the language ends up mirroring the source language and hairifying the backend, or it looks too much like a particular machine and code for other machines is poor as a result. An answer is to use machine description languages, although satisfactory ones for compilers have yet to appear. In the environments world, there has been some work on interface description languages; I don't believe any of it is being done in a Lisp context, however. >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. Better, but not there yet. The structure of the stack is certainly not language-independent! The only language-independent stepping I can think of is at the machine language level, but surely you can't be stepping by machine instructions in a high-level debugger? The *concept* of a breakpoint is independent of language, but certainly the display at a break in a Prolog is rather different than that for Lisp (at least for those Lisps which don't have logical variables and choice points :-) ). >[...] 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. Of course, if that's possible; if the problem breaks up into little pieces. That's the easy part of debugging, and I consider it a solved problem. It's the system integration bugs that are nasty. You know the sort; all the parts seem to work perfectly, the bug appears only once in a hundred runs or only to particular users, and it only appears after the program has been running for an hour. Lisp system garbage collectors are a traditional example - I don't know of any Lisp hackers that would bet large amounts of money against a tiger team attack on their storage allocator. A rationale for Unix-style tools is that one can use them to construct more powerful debugging tools than those already provided. >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. The pipes I mentioned specifically are *for* debugging; they don't need debugging themselves! In fact, a Symbolics-type debugger is completely useless, because the program (xconq) runs perfectly, but I'm unhappy about the intelligence of the machine players, and am trying to figure out why. Small-scale behavior seems to be OK, but is poor on larger examples and after longer times. You must not have used pipes very much - the whole point of them is to *avoid* "sending intermediate output to files". I've used Unix for quite a while, and my tool usage is far inferior to what real experts do, which is on a scale that would swamp most Lisps if those tools were in Lisp. On the other hand, accommodating Unix tools can involve peculiar restrictions on the format of data - I believe the ideal is some as-yet-unachieved combination of tools and integration. The Lisp community is setting itself up for a fall by continually calling for more integration, while the rest of the world is looking for more flexibility... (Of course, I may be misreading the future, but then that's one of the hazards of academic life!) >Barry Margolin stan shebs shebs@cs.utah.edu
dzzr@beta.UUCP (Douglas J Roberts) (11/16/87)
> 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. The last time I looked, my Symbolics debugger worked just fine on FORTRAN, and PASCAL, and I have no reason to suspect that it won't work on the ADA as well. 'C' will be available soon, as well. -- --------------------------------------------------------------- Doug Roberts dzzr@lanl.gov ---------------------------------------------------------------