Re: Re(2): [colorforth] abort

[Samuel Falvo <falvosa@xxxxxxxxx>]

> 1) Closed, data controlled environments such as industrial process control,
> standalone development systems or anywhere that the computer generates all
> data such as in colorForth.
> 
> 2) Open, external communication based systems like DOS, linux, Windows and
> the
> ill-fated iTV project.

In both cases, you must be able to handle errors that can crop up.  The
so-called closed environments that you speak of are not truely closed: they
ultimately still depend on the programmer or user to accept their initial data
sets.

For example, while working in XcolorForth, it is a fairly common occurance for
it to outright crash if I edit any block beneath 18.  I really can't imagine
why: the editor should never actually change anything unless I tell it to.  I
think it's a good bet that it doesn't change this region of memory.  Yet, it
still crashes, leaving the fault point somewhere in the editor itself.  It's
probably encountering a color token it never expected to see.

Even on a normal source block, you can advance the cursor beyond the end of the
block's last word.  The cursor disappears, leaving me without any knowledge of
where it actually is.  If you go too far, it will probably crash too.  I don't
know because I haven't tried it.

In both cases, we're dealing with a closed development environment that is
"unstable" with respect to the user's input.  In both cases, proper error
handling is missing.

Chuck does not advocate NOT handling errors.  He advocates handling the errors
as close to their source as possible, preferably within the same block that
they occur.

> Contiki is a multi-tasking, graphical OS with TCP/IP stack, web
> browser/server
> and telnet client all in 42k. It is written in C.

You forgot to mention that it runs on the Commodore 64 -- quite an achievement.
 I used to have a Commodore 64 before I moved to the Amiga, and they're both
still near and dear to me.  :)

> Trying to figure out whether colorForth with its non-standard character
> encoding would be a good fit, or to use the ASCII'd colorForth or my own
> flat-real mode 4word. 

The premise of ColorForth does not dictate the use of pretokenized,
color-tagged words.  Chuck's specific implementation uses them, but it's not
required to implement the concept, any more than non-color Forths are required
to support only a length and the first three characters of a word.

Also remember that when exporting or importing source out of or into the
ColorForth environment, word names are (un)packed to normal ASCII for the
purposes of transmission.

> The differences are worth soaking up a few beers over, discussing the merits
> of the various implementations, but are actually moot until such time as
> someone in the community produces a TCP/IP stack.

The very nature and philosophy of ColorForth effectively prohibits this to ever
happen.  The reason is ColorForth advocates, "Make what you need, when you need
it, and no more."  Hence, any application that uses TCP/IP will likely
implement *just enough* of the TCP/IP stack to get the application working.  It
will be highly specialized to that application's requirements.

This, to me, means that if you want to TCP/IP-enable your application, you'll
have to write enough of a TCP/IP implementation to do it.  The uIP package
proves that such a package can be small, even small enough to write it yourself
from scratch, so it is within the realm of possibility.

--
Samuel A. Falvo II


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com