Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #39255 > unrolled thread

ColorForth - another dead end?

Back to article view | Back to comp.lang.forth

Contents

  ColorForth - another dead end? borota@gmail.com - 2015-05-24 12:22 -0700
    Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-24 14:00 -0700
      Re: ColorForth - another dead end? borota@gmail.com - 2015-05-24 16:18 -0700
        Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-24 16:45 -0700
        Re: ColorForth - another dead end? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-24 14:50 -1000
          Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-24 18:12 -0700
            Re: ColorForth - another dead end? onewhohopes@gmail.com - 2015-05-28 13:00 -0700
              Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-28 18:55 -0700
              Re: ColorForth - another dead end? Howerd <howerdo@yahoo.co.uk> - 2015-05-29 00:49 -0700
                Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 07:56 -0700
                  Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 15:04 +0000
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 10:03 -0700
                      Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 10:15 -0700
                    Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 19:28 -0700
                      Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-30 12:34 +0000
                  Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 19:19 -0700
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 22:30 -0700
                  Re: ColorForth - another dead end? "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-30 00:14 -0400
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 22:22 -0700
                      Re: ColorForth - another dead end? "Alex McDonald" <blog@rivadpm.com> - 2015-05-30 09:27 +0100
                        Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 02:05 -0700
                          Re: ColorForth - another dead end? "Alex McDonald" <blog@rivadpm.com> - 2015-05-30 10:21 +0100
                            Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 04:08 -0700
                              Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-30 07:43 -0700
                                Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 09:42 -0700
                                  Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-30 10:25 -0700
                                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 22:36 -0700
                                      Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-31 16:38 -0700
                              Re: ColorForth - another dead end? "Alex McDonald" <blog@rivadpm.com> - 2015-05-31 09:11 +0100
                              Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-05-31 11:31 -0700
                                Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-01 13:21 +0000
                                  Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 08:18 -0700
                                  Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 09:07 -0700
                                  Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 23:31 -0700
                                    Field name overloading (was: ColorForth - another dead end?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-02 09:47 +0000
                                      Re: Field name overloading (was: ColorForth - another dead end?) humptydumpty <ouatubi@gmail.com> - 2015-06-02 13:07 -0700
                                Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 08:20 -0700
                      Re: ColorForth - another dead end? "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-30 15:34 -0400
                  Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 22:55 -0700
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 00:54 -0700
                Re: ColorForth - another dead end? stephen@mpeforth.com (Stephen Pelc) - 2015-05-30 17:20 +0000
                  Re: ColorForth - another dead end? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-31 15:17 +0000
          Re: ColorForth - another dead end? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-05-25 10:06 +0300
          Re: ColorForth - another dead end? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-25 11:11 -0700
            Re: ColorForth - another dead end? rickman <gnuarm@gmail.com> - 2015-05-25 14:22 -0400
              Re: ColorForth - another dead end? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:57 -1000
                Re: ColorForth - another dead end? borota@gmail.com - 2015-05-25 20:42 -0700
                Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 19:46 -0700
                  Re: ColorForth - another dead end? "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-30 00:03 -0400
    Re: ColorForth - another dead end? Howerd <howerdo@yahoo.co.uk> - 2015-05-24 21:51 -0700
      Re: ColorForth - another dead end? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-25 11:17 +0000
    Re: ColorForth - another dead end? Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:50 -0700
      Re: ColorForth - another dead end? Howerd <howerdo@yahoo.co.uk> - 2015-05-25 02:11 -0700
    Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:11 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#39465

On Fri, 29 May 2015 00:49:34 -0700 (PDT), Howerd <howerdo@yahoo.co.uk>
wrote:

>IIRC Stephen Pelc has  powerful C-like struct support in VFX, and these
>are very useful when interfacing to Windows etc.

There are plenty in VFX ranging from classical Forth-style structures
as now standardised to intelligent structures with a dot parser and
methods (see ClassVFX) to a C++ style OOP package (see CIAO - C
Inspired Active Objects).

ClassVFX was written by a client for a huge app. CIAO was written
by a member of MPE staff.

We are currently supplying five or six OOP packages. They all
have their places. Unfortunately, there is little desire for
common practice in Forth OOP anomg the Forth community. I
suspect that most OOP packages are very little used except
for GUI programming.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#39480

In article <5569ef4a.941868578@news.eternal-september.org>,
Stephen Pelc <stephen@mpeforth.com> wrote:
>On Fri, 29 May 2015 00:49:34 -0700 (PDT), Howerd <howerdo@yahoo.co.uk>
>wrote:
>
>>IIRC Stephen Pelc has  powerful C-like struct support in VFX, and these
>>are very useful when interfacing to Windows etc.
>
>There are plenty in VFX ranging from classical Forth-style structures
>as now standardised to intelligent structures with a dot parser and
>methods (see ClassVFX) to a C++ style OOP package (see CIAO - C
>Inspired Active Objects).
>
>ClassVFX was written by a client for a huge app. CIAO was written
>by a member of MPE staff.
>
>We are currently supplying five or six OOP packages. They all
>have their places. Unfortunately, there is little desire for
>common practice in Forth OOP anomg the Forth community. I
>suspect that most OOP packages are very little used except
>for GUI programming.

Well. I've found my one screen OOP indispensible for non-trivial programs,
like my assemblers, and the manx musical score program.
I've used that oo in 50 of the 400 Euler project problems I've solved.
Interestingly in problem 514 I had just one class with just one
object. This could have been replaced by just a bunch of variables,
and regular colon definitions. Apparently the OO thinking helps me
to keep the data straight, such as forcing relationship between fields.

I've done some GUI stuff, but never in Forth.

>
>Stephen
>
>--
>Stephen Pelc, stephenXXX@mpeforth.com
>MicroProcessor Engineering Ltd - More Real, Less Time
>133 Hill Lane, Southampton SO15 5AF, England
>tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
>web: http://www.mpeforth.com - free VFX Forth downloads
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#39276

On 25.05.2015 03:50, Elizabeth D. Rather wrote:

>
> Unfortunately, Starting Forth presents a very simplified view of the
> state of Forth 30 years ago, which even more unrepresentative of Forth
> today than K&R is of the current state of C programming (K&R was at
> least aimed at professional programmers). If you are interested in Forth
> I highly recommend some more recent and more technical books on the
> language, of which there are several. My book, the Forth Programmer's
> Handbook, is available from Amazon as well as a free pdf included with
> the evaluation version of FORTH, Inc.'s SwiftForth (windows, Linux, OSX)
> and SwiftX (interactive cross-compiler for popular microcontrollers) in
> addition to extensive documentation of these respective implementations.
> Both SwiftForth and SwiftX have been used in major software projects:
> SwiftX, for example, runs communication multiplexors that manage much of
> the electric power grid in North America.
>

I liked Brodie's Starting and Thinking Forth books. A while ago I read 
it through and compared its ideas to jonesforth. They work nicely 
together. Thinking Forth gave some thoughts to consider while using 
other languages as well. I also found your Forth programmers handbook 
very useful.

However, even I don't find myself total newbie any more, I end up asking 
quite a lot of questions which newbie would ask. And when I find answer, 
it is always the simplest one which I didn't even consider.

I would like to propose that on some course you record all sessions and 
write a book where you solve those questions your students asked. And if 
course subject can be set some direction, have Arduino or some other 
common MCU development environment and write something more complicated 
than normal led blinker and control software on PC for it.

And for Hugh there should be structs, linked list and maybe some tree 
build in a forth way.

But I have impression, you don't teach nor write that much any more.

Best regards,
Hannu Vuolasaho

[toc] | [prev] | [next] | [standalone]

#39295

On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:

> arrays and tables that range-check index parameters

Or, for that matter arrays and tables that DON'T 
range-check index parameters, for those of you
who need that extra bit of speed, or for those 
of you who like to live on the wild side. :^)

Jason

[toc] | [prev] | [next] | [standalone]

#39296

On 5/25/2015 2:11 PM, Jason Damisch wrote:
> On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
>
>> arrays and tables that range-check index parameters
>
> Or, for that matter arrays and tables that DON'T
> range-check index parameters, for those of you
> who need that extra bit of speed, or for those
> of you who like to live on the wild side. :^)

I recently used a table without range checking even during debug because 
I could guaranty that the index could not be out of range.  Range 
checking is not always required in an array.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#39313

On 5/25/15 8:22 AM, rickman wrote:
> On 5/25/2015 2:11 PM, Jason Damisch wrote:
>> On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
>>
>>> arrays and tables that range-check index parameters
>>
>> Or, for that matter arrays and tables that DON'T
>> range-check index parameters, for those of you
>> who need that extra bit of speed, or for those
>> of you who like to live on the wild side. :^)
>
> I recently used a table without range checking even during debug because
> I could guaranty that the index could not be out of range.  Range
> checking is not always required in an array.

Absolutely. And in applications where you *do* want to do range 
checking, you may not always want to do the same thing. In some cases, 
you want to give an error message, in others you want to clip or 
substitute for the errant value or take some completely different action.

The programmer should have full control.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#39320

On Monday, May 25, 2015 at 7:57:27 PM UTC-5, Elizabeth D. Rather wrote:
> On 5/25/15 8:22 AM, rickman wrote:
> > On 5/25/2015 2:11 PM, Jason Damisch wrote:
> >> On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
> >>
> >>> arrays and tables that range-check index parameters
> >>
> >> Or, for that matter arrays and tables that DON'T
> >> range-check index parameters, for those of you
> >> who need that extra bit of speed, or for those
> >> of you who like to live on the wild side. :^)
> >
> > I recently used a table without range checking even during debug because
> > I could guaranty that the index could not be out of range.  Range
> > checking is not always required in an array.
> 
> Absolutely. And in applications where you *do* want to do range 
> checking, you may not always want to do the same thing. In some cases, 
> you want to give an error message, in others you want to clip or 
> substitute for the errant value or take some completely different action.
> 
> The programmer should have full control.
> 
> Cheers,
> Elizabeth
> 
> -- 
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045
> http://www.forth.com
> 
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

I like what I "hear" in here. I am looking forward to getting a better grasp of what Forth is.
I remember when I had to switch from C to Java, the frustration of being so constraint and with so little control over things. It felt like I lost my freedom and also lost power over the computer (but not having to worry about memory allocation was something that I began to appreciate after a while).

After decades of programming in strong typed, convoluted syntax languages, I feel like I am getting tired of so much syntax, can't take it any longer. There must be something simpler/nicer than having to keep track of parens, parameters, etc. Although I am not sure if Forth actually just replaces one thing with another - now the drudge is shifted to keeping track of the stack instead. We shall see...

Thank you all for the nice pointers and welcome.

[toc] | [prev] | [next] | [standalone]

#39441

On Monday, May 25, 2015 at 5:57:27 PM UTC-7, Elizabeth D. Rather wrote:
> On 5/25/15 8:22 AM, rickman wrote:
> > On 5/25/2015 2:11 PM, Jason Damisch wrote:
> >> On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
> >>
> >>> arrays and tables that range-check index parameters
> >>
> >> Or, for that matter arrays and tables that DON'T
> >> range-check index parameters, for those of you
> >> who need that extra bit of speed, or for those
> >> of you who like to live on the wild side. :^)
> >
> > I recently used a table without range checking even during debug because
> > I could guaranty that the index could not be out of range.  Range
> > checking is not always required in an array.

Just use my arrays in the novice-package --- range-checking can be turned on or off as needed.

Also, I don't believe that you could guarantee that the index would not be out of range when you were still debugging --- that is what "debugging" means, that there might be bugs. Lots of bold programmers feel confident that their program is going to work the first time, but few are so bold as to "guarantee" this, because past experience indicates that this is almost never true.

> Absolutely. And in applications where you *do* want to do range 
> checking, you may not always want to do the same thing. In some cases, 
> you want to give an error message, in others you want to clip or 
> substitute for the errant value or take some completely different action.

This is just more of Elizabeth Rather's lifelong effort to convince every Forther that every program has to be written entirely from scratch and that general-purpose data-structures can never be used.

This is total baloney. It is always an error to give an out-of-range index to an array. In the rare cases in which you want to clip or substitute an index (I have never seen this 30 years), you would write a wrapper for your array, but you would still be required to provide a valid index to the array. This does not at all imply that every data-structure has to be written from scratch every time, and that general-purpose data-structures can never be used.

> The programmer should have full control.

This is meaningless drivel --- similar to a politician saying: "I say that the people should be free!" (implying that the other candidate wants them to be enslaved).

You are always spouting meaningless drivel --- typical salesperson...

[toc] | [prev] | [next] | [standalone]

#39442

On Fri, 29 May 2015 22:46:36 -0400, <hughaguilar96@gmail.com> wrote:

> It is always an error to give an out-of-range index to an array.

Data? Yes.
Address? No.

There are some rare but valid uses for address pointers computed
 from an array address and an out-of-range index, at least, for C.
Of course, accessing data there is always invalid.


Rod Pemberton
-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?

[toc] | [prev] | [next] | [standalone]

#39272

On Sunday, May 24, 2015 at 8:22:28 PM UTC+1, bor...@gmail.com wrote:
> Hello everybody,
> 
> I am Greg. This is my first post here.
> 
> I was searching the web about ColorForth and I saw a lot of activity around it some good years ago and then lately almost nothing. Lots of people who put effort into it seem to have completely abandoned it lately.
> 
> So my question is why? Did people investigate it and then found out it doesn't give you as much for the buck as initially thought? 
> 
> My Forth expertise is at the Starting Forth level (reading it a second time). I was thinking to try to figure out ColorForth after that. Even on this list, I see people showing interest in it couple of years back, but almost nothing about it in later years.
> 
> I have read that Chuck admitted "sourceless" programming was a dead end and he completely abandoned it. Is ColorForth another dead-end too?

Hi Greg,

Welcome to clf :-)

> Is ColorForth another dead-end too? 
No, definitely not.

I happen to be working on my distro of colorForth this morning when I read your post (its a bank holiday here today) :-)
This is only a back-burner project for me, so in elapsed time its taking forever, hence the lack of updates...

GreenArrays supply their ArrayForth dialect of colorForth which runs either native or under Windows - you can download it from here :  http://www.greenarraychips.com/home/support/download-02b.html

Chuck has used, and as far as I know is still using, colorForth/arrayForth to write OKAD which he uses to develop his Forth chips.
OKAD is a Domain Specific Language which is an alternative to the usual CAD development environments.

> Did people investigate it and then found out it doesn't give you as much for > the buck as initially thought? 
Speaking for myself, no.
Back in 2001 it was easy to find a PC or laptop with a built in floppy drive. Today a programming language that only runs from a floppy disk is not taken seriously - computer science has more in common with the fashion industry these days than science (thanks to Stephen Pelc for pointing this out to me :-).

My back-burner colorForth project is to make my distro run from a USB drive.
This is extremely challenging, and not really that much fun, because it is battling a menagerie of complicated beasts : Windows, FAT32, MBRs, BPBs etc.
But I am doing it because I think colorForth is worth it...

Best regards, and thanks for your interest,
Howerd

[toc] | [prev] | [next] | [standalone]

#39282

In article <935bf6d1-e59e-4a9b-bb37-3e4ee183ae3c@googlegroups.com>,
Howerd  <howerdo@yahoo.co.uk> wrote:
<SNIP>
>
>Chuck has used, and as far as I know is still using,
>colorForth/arrayForth to write OKAD which he uses to develop his Forth
>chips.
>OKAD is a Domain Specific Language which is an alternative to the usual
>CAD development environments.

I understood that OKAD got lost when Chuck's laptop broke down that
was the only one to boot the OKAD floppies?

<SNIP>

>Best regards, and thanks for your interest,
>Howerd
>
>
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#39280

ColorForth is really neat, however, the major barrier for most people
is the *extremely* un-user-friendly user interface. I tried it and got
nowhere with it. Gave up in frustration. For a long time it was Dvorak
input only, IIRC. Only later, as a concession to "normal" people was 
the ability to use a normal keyboard added (I may have got that wrong).

There is a version which runs from Windows available from Green Arrays
but it still uses the awful user interface. The user interface should
be scrapped IMO and replaced with something more friendly. It doesn't
have to be graphics/windows based. DOS style character mode would be
just fine - as long as it displays colo(u)r.

Welcome to CLF.

[toc] | [prev] | [next] | [standalone]

#39281

On Monday, May 25, 2015 at 9:50:08 AM UTC+1, Mark Wills wrote:
> ColorForth is really neat, however, the major barrier for most people
> is the *extremely* un-user-friendly user interface. I tried it and got
> nowhere with it. Gave up in frustration. For a long time it was Dvorak
> input only, IIRC. Only later, as a concession to "normal" people was 
> the ability to use a normal keyboard added (I may have got that wrong).
> 
> There is a version which runs from Windows available from Green Arrays
> but it still uses the awful user interface. The user interface should
> be scrapped IMO and replaced with something more friendly. It doesn't
> have to be graphics/windows based. DOS style character mode would be
> just fine - as long as it displays colo(u)r.
> 
> Welcome to CLF.

Hi Mark,

> the major barrier for most people
> is the *extremely* un-user-friendly user interface.
I agree that the colorForth 24-key interface is an acquired taste - GreenArray's arrayForth defaults to a relatively normal ASCII mode - 
but I would not call it un-user-friendly, just different.
In terms of the recent Eurovision song contest, its more Montenegro or Belgium than Sweden or Russia, if you get what I mean ;-)

Best regards,
Howerd

[toc] | [prev] | [next] | [standalone]

#39286

borota@gmail.com writes:
>I have read that Chuck admitted "sourceless" programming was a dead end and=
> he completely abandoned it. Is ColorForth another dead-end too?

I think that Chuck Moore sees it as a stage on the way to arrayForth
(and whatever comes after that).  Sourceless was a dead end for him,
because he went back to using source code.

And it seems to be that those people who are particularly interested
in what Chuck Moore is doing are now looking into the Greenarrays
chips and arrayForth, that's why there is less buzz about colorForth.

I don't think many of the interested people have used colorForth for
production purposes, and the same will probably happen with
arrayForth.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.forth

csiph-web