MacIvory prices

[Scott McKay <SWM@sapsucker.scrc.symbolics.com>]

    Date: Fri, 2 Sep 88 17:46 EDT
    From: 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?

Software developers use the delivery system.  If he thinks he will need
the Debugger and Zwei later, he needs to arrange to have them included.

    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.

It would not be unreasonable to have a different default condition
handler which is not the Debugger, whose sole purpose is to provide for
proceeding for unhandled errors.  Ah, you say this below...

    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.

Have you seen the delivery software yet?  I haven't.  We aren't
reversing anything yet.  Please don't read between the lines of what I
said.  The delivery version of Genera depends on the application.
That's all.

	    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?

You are assuming that the delivery environment is one monolithic
program.  Don't make that assumption.  The delivery version of Genera
depends on the application.