MacIvory prices

[Barry Margolin <barmar@THINK.COM>]

    Date: Fri, 2 Sep 88 15:29 EDT
    From: Scott McKay <SWM@sapsucker.scrc.symbolics.com>

	Date: Fri, 2 Sep 88 13:08 EDT
	From: Barry Margolin <barmar@Think.COM>

	    Date: Fri, 2 Sep 88 10:44 EDT
	    From: SWM@sapsucker.scrc.symbolics.com (Scott McKay)

	    Zwei.  Zmail.  The Debugger.  Metering.  Most of the compiler.  You get
	    the idea...

	How do you take out the debugger?  What does it do when the application
	gets an error?

    Um, you're misquoting me here.  Here's the rest of my reply again:

    "In fact, the ultimate delivery package contains very little except for
    the operating system itself (paging, GC, scheduler, etc.), Symbolics
    Common Lisp, and the user-interface support.  In reality, each delivery
    application will have special requirements which will necessitate
    additional pieces of Genera being included."

OK, but what does this mean for the software developer?  He needs to
know what pieces of Genera he can count on finding in the runtime
environment.  Or is he supposed to include the Debugger or Zwei in his
distribution if he needs it?

Perhaps I misunderstood your reference to "ultimate delivery package".
By "ultimate" I assumed you were describing a hypothetical future
barebones delivery vehicle, not MacIvory as it will be released this
year.  That's why I didn't think that paragraph was relevant.

    The answer is "some applications may need the Debugger, and some may
    not."  Besides, the condition system is not the debugger.  When an
    "application gets an error", it could handle the condition itself, no?

I know the difference between the Debugger and the condition system.
Many applications choose not to handle most conditions, though.  It is
much simpler to just set up restart points and let the user manually
invoke them.  Is there a difference between the Debugger and the default
error handler?  In Genera 7.2 there isn't much difference.

What about portable Common Lisp code?  If one uses CCASE, for example,
the debugger must be around to allow the user to supply a new value
(unless you've changed CERROR, CCASE, and CTYPECASE for MacIvory).
The application can't handle the condition itself because there's
currently no way to do that portably, and CLtL says that the
implementation will do it.  In the current version of the software, this
Common Lisp feature is implemented by the Debugger.

There are also plenty of parts of Genera that depend on the Debugger.
For example, when a network connection attempt times out, there are a
number of useful retry options.

I suppose you could resolve most of these issues by including a default
error handler that simply lets the user select a proceed option, rather
than perform all debugger functions.  I agree that there is little need
in a delivery environment for the :Proceed Trap on Call command.  On the
other hand, the Debugger is often the only way to deal with some
situations.  For example, I frequently tell my users "there's a bug in
the FOOBAR program -- if it goes into the debugger with the FROB error,
type two control-N's followed by control-R."  Symbolics has long
maintained that the debugger MUST be part of any runtime environment
because no program is ever really debugged.  It sounds as if you're
reversing yourselves now.

	Also, when you said "Zwei", I hope you meant "Zmacs".  I imagine there
	are many applications that use Zwei standalone editor windows for
	accepting input from the user, and I can't see why you wouldn't want
	these to port to MacIvory delivery environments.

    "In fact, the ultimate delivery package contains very little except for
    ... and the user-interface support.

Well, since the use of Zwei standalone editor windows is documented in
"Programming the User Interface", that makes it "user-interface
support".  So, shouldn't it be included in the delivery environment?

                                                barmar