[colorforth] about colorforth

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Sat, 11 May 2002, Bob Shafer wrote:

> At 03:01 PM 5/11/02 -0400, you wrote:
> >I'm pretty happy with colorForth, if I could make it simpler or better in
> >someway I might create my own colorForth, but I'd probably sugest my ideas
> >to Chuck Moore first. I think it provides a good focal point for a
> >colorForth community to develop. It would take me much to long to write
> >all the code I would like to use under colorForth. My hope is that some
> >skilled colorForthers come forward and tackle some of the projects Chuck
> >has sugested. I'm working on a jpeg decoder at the moment, it should be
> >usefull in a web browser or just general image viewing.
> 
> I'm looking forward to seeing some networking stuff, because then
> I might start to be able to do something useful. I'd really love
> writing (and using) a simple telnet client, for example. That is
> assuming I can improve my colorForth skills a bit more.
> 

I'm looking foward to the networking code as well. It should be
interesting  just to see what reasonable networking code looks like, I get
lost very quickly trying to understand the linux networking code. The
telnet app would be useful to me too. Actually I'm writing this mail
through a telnet client, though I might just prefer a colorForth mail
client.

> Currently, I'm trying to program Conway's game of life, and don't
> have it working yet. It's only half a screen, so far. When it's done,
> it shouldn't be much larger, except I'm planning to add a menu (keyboard)
> for it, and that might get me into a second screen. But first I have to
> figure out why it makes colorForth reboot. :-)
>

Sounds neat. Some common errors I have found myself making are forgeting
the ';', forgeting '*next' when breaking out of a loop. One strange error
is putting too much stuff between 'if' and 'then', the displacement must
fit inside one byte. This is usually the case for properly factored
code. Simple arithmetic can cause colorForth to crash, such as overflow,
or divsion by zero. There should probably be intererupt handlers in place
for these so you know if you made a simple error.

> My strategy, next time I sit down to it, is to start rewriting it on a
> fresh screen, writing the code in an order and form that allows me to
> test each definition as I go, so I don't again end up where I'm at now.
> 
> BTW to Mark: Thanks for the mandelbrot code! I keyed it in a while back
> (my first real use of the editor: it took me a couple of evenings to do)
> and it worked great (after I figured out that I'd encoded hex as decimal
> (or was it vice versa?)). The only disk I had that on has since gone bad,
> but I still have the printout.
> 

Good to see someone found use in it! I've since created a simpler version,
all those 'if's for computing the hue can be replaced by simple jump
table. I should upload it soon.

> Also, just wanted to mention that there are at least two bad results
> of mine revealed above, for which Chuck has explicitly suggested
> good practices to help ward off. In particular, interactive testing
> as you go and a stack of diskettes for saving each day's colorForth
> work. 

The interactive testing is such a nice feature. I think there is some
initial difficulty in working with the colorForth environment. I think
for me it is being so used to other methods of developement. In
colorForth the testing takes the place of debuging. But testing is so
much more productive overall. Testing forces you to break the problem
down in smaller pieces, this make the code easier to understand, easier 
to write. The required skills do grow on you, and the results are
generally productive for all people involved.

Mark  

------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com