Unless I'm way off, REBOL has a stack-based architecture to it - could we
not have a Smalltalk-like walkback window that shows the call sequence, and
what lines each call is related to (where they are related)?

Clicking on a line item shows the context/state of all relevant store at
that point. Very handy.

Kemp

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: September 11, 2002 10:31 PM
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: Beginner's questions on REBOL/Core and REBOL/View


Gregg:

> But is that feasible, and what would we have to give up in return?

I hope it is, and I hope nothing at all.

You make a series of absolutely spot on and valid points about the need to
write defensive code, and add our own industrial strength error checking and
recovery. I agree completely.

But (isn't there always a but?), the current Rebol error reporting is barely
adequate as a hint about where an error is.

That works fine if the error is around about the code I'm working on. But if
I've screwed up and the error floats a long way down stream before
exploding,
I'm left trashing a haystack to find that bent needle.

I'm happy to leave it to Carl to come up with something better. And I'm sure
if he puts his mind to it, he'll come up with something elegant and
succinct.

When I get an error, I want debug information, lots of it.

Let me throw in a few ideas for debugging that I would like to have. Anyone
who can write these as mezzanine functions will be a hero in my eyes.

-- Much better context on the error. How about the last 50 words in the
"near" statement.

-- Debug mode that, on error, will show the last n-teen words modified,
like:
  mycounter <== 4
  myblock <== append now/precise

-- Silent trace -- trace is on but displays no output unless there is an
untrapped error. Then it displays the last n-teen operations. Right now,
trace is too verbose to be any use.

-- I'd be happy for there to be a debug version of Rebol. Maybe it'd be
twice
the size of the production release. But it'd be chock full of
instrumentation
to check. That way, if we do lose some speed, it'd be only during
development
against that version. Trusted, live, code would run most of the time against
the slick Rebol executable.

Sunanda.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.

-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to