Hi Forthers,

I am pleased to announce an updated version of colorForth : cf2022.

https://sourceforge.net/projects/colorforth/
https://github.com/Howerd/colorForth
or from my website:
https://www.inventio.co.uk/cf2022/

Documentation is here :
http://www.inventio.co.uk/cf2022/cf2022_colorForth.pdf

Readme is here :
https://www.inventio.co.uk/cf2022/readme.txt

The main difference between cf2019 and cf2022 is that cf2022 has an
ASCII font, even though it still uses Shannon-Fano encoding for the cf
token names.
This is step in the direction of the rest of the programming world.

It occurred to me while I was updating cf2022 that I like colorForth
because it is as close to the metal as you can get - I see a connection
between colorForth and this video : https://youtu.be/gNRnrn5DE58
colorForth is the equivalent of the Surface Plate that everything else
can be referenced too. Just my 2c worth.

Enjoy!

Cheers,
Howerd

On Monday, 4 April 2022 at 21:44:03 UTC+1, Howerd wrote:
> Hi Forthers,
>
> I am pleased to announce an updated version of colorForth : cf2022.
>
> https://sourceforge.net/projects/colorforth/
> https://github.com/Howerd/colorForth
> or from my website:
> https://www.inventio.co.uk/cf2022/
>
> Documentation is here :
> http://www.inventio.co.uk/cf2022/cf2022_colorForth.pdf
>
> Readme is here :
> https://www.inventio.co.uk/cf2022/readme.txt
>
> The main difference between cf2019 and cf2022 is that cf2022 has an
> ASCII font, even though it still uses Shannon-Fano encoding for the cf
> token names.
> This is step in the direction of the rest of the programming world.
>
> It occurred to me while I was updating cf2022 that I like colorForth
> because it is as close to the metal as you can get - I see a connection
> between colorForth and this video : https://youtu.be/gNRnrn5DE58
> colorForth is the equivalent of the Surface Plate that everything else
> can be referenced too. Just my 2c worth.
>
> Enjoy!
>
> Cheers,
> Howerd

I just had a look at the documentation you did
- brilliant and a lot of your time invested.

But for a beginner like me
- is there an easy way to get it onto a RPI?

On Tuesday, April 5, 2022 at 9:16:51 AM UTC+2, jpit...@gmail.com wrote:
> I just had a look at the documentation you did
> - brilliant and a lot of your time invested.
Really?! A three page primer? 24 page content - because the rest is just a lazy code dump?

I don't know what your standards are concerning documentation - but they're REALLY not mine..

Hans Bezemer

On Tuesday, 5 April 2022 at 15:13:46 UTC+1, the.bee...@gmail.com wrote:
> On Tuesday, April 5, 2022 at 9:16:51 AM UTC+2, jpit...@gmail.com wrote:
> > I just had a look at the documentation you did
> > - brilliant and a lot of your time invested.
> Really?! A three page primer? 24 page content - because the rest is just a lazy code dump?
>
> I don't know what your standards are concerning documentation - but they're REALLY not mine..
>
> Hans Bezemer

I am awfully sorry, that your counting capabilities seem to be limited,

but 184 pages A4 is quite an effort,
and nicely formatted.
http://www.inventio.co.uk/cf2022/cf2022_colorForth.pdf

Please show us what you have produced
that comes close to Howerd's work,
so we can really compare and understand why you are so negative.
I assume we would like to understand how you define your documentation standard.
Thank you.

On Tuesday, April 5, 2022 at 4:54:35 PM UTC+2, jpit...@gmail.com wrote:
> Please show us what you have produced
> that comes close to Howerd's work,
> so we can really compare and understand why you are so negative.
> I assume we would like to understand how you define your documentation standard.
I wish you hadn't said that - but had taken my remark seriously: https://thebeez.home.xs4all.nl/4tH/4tHmanual.pdf

> Thank you.
You're welcome.

Hans Bezemer

On Tuesday, 5 April 2022 at 16:41:48 UTC+1, the.bee...@gmail.com wrote:
> On Tuesday, April 5, 2022 at 4:54:35 PM UTC+2, jpit...@gmail.com wrote:
> > Please show us what you have produced
> > that comes close to Howerd's work,
> > so we can really compare and understand why you are so negative.
> > I assume we would like to understand how you define your documentation standard.
> I wish you hadn't said that - but had taken my remark seriously: https://thebeez.home.xs4all.nl/4tH/4tHmanual.pdf
>
> > Thank you.
> You're welcome.
>
> Hans Bezemer

Well, I had been there already
and looked quickly at the 650+ pages.
Let the Forth Community judge about quality of either.
Never heard such negativity from Howerd about work others did and were proud of,
but there we are.

On Tuesday, April 5, 2022 at 5:58:03 PM UTC+2, jpit...@gmail.com wrote:
> Let the Forth Community judge about quality of either.
> Never heard such negativity from Howerd about work others did and were proud of,
> but there we are.

I've always been critical of the level of documentation in the Forth community.
My first experience was the Artic Forth compiler for the ZX Spectrum - which was a few pages
of "tutorial", a glossary, an editor reference - and "Lot's of luck, guys".

I ended up buying hundreds of dollars worth of text books - which were always not quite like
the compiler I tended to use. But I managed - since here we are.

When I began in the early '90-ies, the was a lot of tough talking like "the glossary is enough -
if you're not getting it that way, you'll never get it" - which was not quite the experience I had had.
I'd "gotten it", but with a lot of help - pages and pages of it.

So, yes - I said I'd do better. My introduction says "Don't you hate it? You've just got a new
programming language and you're trying to write your first program. You want to use a
certain feature (you know it's got to be there) and you can't find it in the manual.

I've had that experience many times. So when I wrote 4tH I promised myself, that would
not happen to 4tH-users. In this manual you will find many short features on all kind of
topics. How to input a number from the keyboard, what a cell is, etc.

I hope this will enable you to get quickly on your way. If it didn't, email me. You will not only
get an answer, but you will help future 4tH users as well".

And yes, I get remarks. For the v3.64.0 release a user helped me to do a complete overhaul
of the "Quick tour" section. I can tell you: testing it took a lot of time. Until what appeared on
the screen *EXACTLY* matched what was written in the manual.

I consider the documentation to be a PART of the release. Just as much as changing some source
may have on other sources or data files, changes have impact on possibly every section of
your documentation. So yes, I think what effort is concerned with documentation.

You take however, a stereotypical feminine take on criticism. Take it as a hint to do better.
It does not concern the amount work that has been done, nor does it concern the character
or the work ethics of the persons who has been working on it - it simply means the
end product does not cut it IMHO. And I'm willing to apply those same standards on my
own work.

That's it done "for free" is irrelevant IMHO. A watch that you get for free with a box of cereals
has to work as well. If not, it's still a lousy watch.

Hans Bezemer

On Tuesday, 5 April 2022 at 17:55:17 UTC+1, the.bee...@gmail.com wrote:
> On Tuesday, April 5, 2022 at 5:58:03 PM UTC+2, jpit...@gmail.com wrote:
> > Let the Forth Community judge about quality of either.
> > Never heard such negativity from Howerd about work others did and were proud of,
> > but there we are.
> I've always been critical of the level of documentation in the Forth community.
> My first experience was the Artic Forth compiler for the ZX Spectrum - which was a few pages
> of "tutorial", a glossary, an editor reference - and "Lot's of luck, guys".
>
> I ended up buying hundreds of dollars worth of text books - which were always not quite like
> the compiler I tended to use. But I managed - since here we are.
>
> When I began in the early '90-ies, the was a lot of tough talking like "the glossary is enough -
> if you're not getting it that way, you'll never get it" - which was not quite the experience I had had.
> I'd "gotten it", but with a lot of help - pages and pages of it.
>
> So, yes - I said I'd do better. My introduction says "Don't you hate it? You've just got a new
> programming language and you're trying to write your first program. You want to use a
> certain feature (you know it's got to be there) and you can't find it in the manual.
>
> I've had that experience many times. So when I wrote 4tH I promised myself, that would
> not happen to 4tH-users. In this manual you will find many short features on all kind of
> topics. How to input a number from the keyboard, what a cell is, etc.
>
> I hope this will enable you to get quickly on your way. If it didn't, email me. You will not only
> get an answer, but you will help future 4tH users as well".
>
> And yes, I get remarks. For the v3.64.0 release a user helped me to do a complete overhaul
> of the "Quick tour" section. I can tell you: testing it took a lot of time. Until what appeared on
> the screen *EXACTLY* matched what was written in the manual.
>
> I consider the documentation to be a PART of the release. Just as much as changing some source
> may have on other sources or data files, changes have impact on possibly every section of
> your documentation. So yes, I think what effort is concerned with documentation.
>
> You take however, a stereotypical feminine take on criticism. Take it as a hint to do better.
> It does not concern the amount work that has been done, nor does it concern the character
> or the work ethics of the persons who has been working on it - it simply means the
> end product does not cut it IMHO. And I'm willing to apply those same standards on my
> own work.
>
> That's it done "for free" is irrelevant IMHO. A watch that you get for free with a box of cereals
> has to work as well. If not, it's still a lousy watch.
>
> Hans Bezemer

Hi Howerd,

thanks for you nice post and the great documentation
and all of the links.
I hope it will convince a few more to try out colorforth

https://sourceforge.net/projects/colorforth/
https://github.com/Howerd/colorForth
and on your website:
https://www.inventio.co.uk/cf2022/
Documentation is here :
http://www.inventio.co.uk/cf2022/cf2022_colorForth.pdf

Howerd schrieb am Montag, 4. April 2022 um 22:44:03 UTC+2:
> Hi Forthers,
>
> I am pleased to announce an updated version of colorForth : cf2022.
>
> https://sourceforge.net/projects/colorforth/
> https://github.com/Howerd/colorForth
> or from my website:
> https://www.inventio.co.uk/cf2022/
>
> Documentation is here :
> http://www.inventio.co.uk/cf2022/cf2022_colorForth.pdf
>
> Readme is here :
> https://www.inventio.co.uk/cf2022/readme.txt
>
> The main difference between cf2019 and cf2022 is that cf2022 has an
> ASCII font, even though it still uses Shannon-Fano encoding for the cf
> token names.
> This is step in the direction of the rest of the programming world.
>
> It occurred to me while I was updating cf2022 that I like colorForth
> because it is as close to the metal as you can get - I see a connection
> between colorForth and this video : https://youtu.be/gNRnrn5DE58
> colorForth is the equivalent of the Surface Plate that everything else
> can be referenced too. Just my 2c worth.

Thanks for keeping cf alive! It is one of the few refreshing aspects in the
tiny Forth world.

Although I believe that cf's exotic human interface do/did more harm
to it than good...

BTW I grew up with long assembly listings, so the documentation looks
fine to me ;-)

em.. thinking back in reality I grew up with tube radios .....

On 6/04/2022 01:58, Jurgen Pitaske wrote:
> On Tuesday, 5 April 2022 at 16:41:48 UTC+1, the.bee...@gmail.com wrote:
>> On Tuesday, April 5, 2022 at 4:54:35 PM UTC+2, jpit...@gmail.com wrote:
>> > Please show us what you have produced
>> > that comes close to Howerd's work,
>> > so we can really compare and understand why you are so negative.
>> > I assume we would like to understand how you define your documentation standard.
>> I wish you hadn't said that - but had taken my remark seriously: https://thebeez.home.xs4all.nl/4tH/4tHmanual.pdf
>>
>> > Thank you.
>> You're welcome.
>>
>> Hans Bezemer
>
> Well, I had been there already
> and looked quickly at the 650+ pages.
> Let the Forth Community judge about quality of either.
> Never heard such negativity from Howerd about work others did and were proud of,
> but there we are.

Howerd is clearly a nice guy and I've certainly found his works useful -
even if not always for the purposes he intended. OTOH Hans does have a
point - namely why include a listing in a manual if nobody is going to
read it. That said I did enjoy reading about Howerd's background even
if it had little bearing on colorForth. If only my own background were
as colorful...

On 6/04/2022 03:47, minf...@arcor.de wrote:
> ...
> BTW I grew up with long assembly listings, so the documentation looks
> fine to me ;-)
>
> em.. thinking back in reality I grew up with tube radios .....

IOW book listings are reminiscent of the days pre-floppy and internet.
When folks had the luxury of 'getting it right the first time' because
there was a long time between technology changes.

On Wednesday, 6 April 2022 at 03:29:09 UTC+1, dxforth wrote:
> On 6/04/2022 03:47, minf...@arcor.de wrote:
> > ...
> > BTW I grew up with long assembly listings, so the documentation looks
> > fine to me ;-)
> >
> > em.. thinking back in reality I grew up with tube radios .....
> IOW book listings are reminiscent of the days pre-floppy and internet.
> When folks had the luxury of 'getting it right the first time' because
> there was a long time between technology changes.

It just shows the type of people you are.

If I like the work Howerd invested and post it,

then the rest of your comments is ripping his work apart.
Does it add anything to his work or post or colorforth?

It would be just like me saying:
What a waste of everybody' s time for 650 pages that hardly anybody will look at, or use.
You probably had your reasons?

But you do not have a clue why he did it like this.

DEMOTIVATION PURE.
And reflect carefully what you post here.
Or even if.

jpit...@gmail.com schrieb am Mittwoch, 6. April 2022 um 08:53:36 UTC+2:
> On Wednesday, 6 April 2022 at 03:29:09 UTC+1, dxforth wrote:
> > On 6/04/2022 03:47, minf...@arcor.de wrote:
> > > ...
> > > BTW I grew up with long assembly listings, so the documentation looks
> > > fine to me ;-)
> > >
> > > em.. thinking back in reality I grew up with tube radios .....
> > IOW book listings are reminiscent of the days pre-floppy and internet.
> > When folks had the luxury of 'getting it right the first time' because
> > there was a long time between technology changes.
> It just shows the type of people you are.
>
> If I like the work Howerd invested and post it,
>
> then the rest of your comments is ripping his work apart.
> Does it add anything to his work or post or colorforth?
>
> It would be just like me saying:
> What a waste of everybody' s time for 650 pages that hardly anybody will look at, or use.
> You probably had your reasons?
>
> But you do not have a clue why he did it like this.
>
> DEMOTIVATION PURE.
> And reflect carefully what you post here.
> Or even if.

Well and good, I certainly had no demotivation in mind. So put your good
advices elsewhere.

Back to cf: Again kudos to Howerd!

My remark on cf's exotic human interface was intended to perhaps discuss whether
it could be innovated to be more 'palatable' with normal hardware and for people with
visual deficiencies. But I guess this is an old discussion.

On Wednesday, 6 April 2022 at 10:10:08 UTC+1, minf...@arcor.de wrote:
> jpit...@gmail.com schrieb am Mittwoch, 6. April 2022 um 08:53:36 UTC+2:
> > On Wednesday, 6 April 2022 at 03:29:09 UTC+1, dxforth wrote:
> > > On 6/04/2022 03:47, minf...@arcor.de wrote:
> > > > ...
> > > > BTW I grew up with long assembly listings, so the documentation looks
> > > > fine to me ;-)
> > > >
> > > > em.. thinking back in reality I grew up with tube radios .....
> > > IOW book listings are reminiscent of the days pre-floppy and internet.
> > > When folks had the luxury of 'getting it right the first time' because
> > > there was a long time between technology changes.
> > It just shows the type of people you are.
> >
> > If I like the work Howerd invested and post it,
> >
> > then the rest of your comments is ripping his work apart.
> > Does it add anything to his work or post or colorforth?
> >
> > It would be just like me saying:
> > What a waste of everybody' s time for 650 pages that hardly anybody will look at, or use.
> > You probably had your reasons?
> >
> > But you do not have a clue why he did it like this.
> >
> > DEMOTIVATION PURE.
> > And reflect carefully what you post here.
> > Or even if.

> Well and good, I certainly had no demotivation in mind. So put your good
> advices elsewhere.
>
> Back to cf: Again kudos to Howerd!
>
> My remark on cf's exotic human interface was intended to perhaps discuss whether
> it could be innovated to be more 'palatable' with normal hardware and for people with
> visual deficiencies. But I guess this is an old discussion.

Can you please advise how this should be done.
It has been posted here based on what you had said.
It will stay here for the rest of our lives. And probably longer.

Can you recommend a better place where to post it?
And waste more of everybody's time?

On Wednesday, April 6, 2022 at 8:53:36 AM UTC+2, jpit...@gmail.com wrote:
> On Wednesday, 6 April 2022 at 03:29:09 UTC+1, dxforth wrote:
> If I like the work Howerd invested and post it,
> then the rest of your comments is ripping his work apart.
> Does it add anything to his work or post or colorforth?
>
> It would be just like me saying:
> What a waste of everybody' s time for 650 pages that hardly anybody will look at, or use.
> You probably had your reasons?
>
> But you do not have a clue why he did it like this.
>
> DEMOTIVATION PURE.
> And reflect carefully what you post here.
> Or even if.

Look. Nobody is denying the significance of colorForth here. As a matter of fact - some of the ideas
found their way in my own compiler. And be assured - everyone is applauding the effort to keep it
viable.

But the most significant lesson to learn when you start a project - ANY project - is that you should
basically be doing it for yourself. Life is NOT a Chinese party convention where everybody automatically
applauds every single thing you're doing.

As a matter of fact, when you're bringing it into the public, you make yourself vulnerable to criticism.
Now - you can respond in two ways. Either you take a long good look at those criticisms and see if
they have any merit (and if so: make your product better) - or you reject them and go your own way
because you're ABSOLUTELY convinced this is the way you want to go.

Both of these approaches are valid. What doesn't help is whining or trying to make some kind of
emotional blackmail - because frankly nobody is gonna care whether you quit or not.

As a matter of fact, when I presented my 4tH 30 years ago, some people went to great length to make
me stop, because they felt it was "an abomination". Needless to say - in that regard I took approach II
because I loved was I was doing - and nobody was gonna stop me doing it.

Sure, I'm always happy to see when people like the product and help it shape with their suggestions
- and it also happens that I say "No". Or I say "Maybe". And it takes me YEARS to turn around.

If you actually get "demotivated" because you're not hearing what you want to hear, may be, just may be,
you're not the right person to do or lead the project.

And most CERTAINLY don't take it to c.l.f. Believe it or not - we're actually the nice guys. ;-)

Hans Bezemer

On Wednesday, April 6, 2022 at 9:40:06 PM UTC+10, the.bee...@gmail.com wrote:
> On Wednesday, April 6, 2022 at 8:53:36 AM UTC+2, jpit...@gmail.com wrote:
> > On Wednesday, 6 April 2022 at 03:29:09 UTC+1, dxforth wrote:
> > If I like the work Howerd invested and post it,
> > then the rest of your comments is ripping his work apart.
> > Does it add anything to his work or post or colorforth?
> >
> > It would be just like me saying:
> > What a waste of everybody' s time for 650 pages that hardly anybody will look at, or use.
> > You probably had your reasons?
> >
> > But you do not have a clue why he did it like this.
> >
> > DEMOTIVATION PURE.
> > And reflect carefully what you post here.
> > Or even if.
> Look. Nobody is denying the significance of colorForth here. As a matter of fact - some of the ideas
> found their way in my own compiler. And be assured - everyone is applauding the effort to keep it
> viable.
>
> But the most significant lesson to learn when you start a project - ANY project - is that you should
> basically be doing it for yourself. Life is NOT a Chinese party convention where everybody automatically
> applauds every single thing you're doing.
>
> As a matter of fact, when you're bringing it into the public, you make yourself vulnerable to criticism.
> Now - you can respond in two ways. Either you take a long good look at those criticisms and see if
> they have any merit (and if so: make your product better) - or you reject them and go your own way
> because you're ABSOLUTELY convinced this is the way you want to go.
>
> Both of these approaches are valid. What doesn't help is whining or trying to make some kind of
> emotional blackmail - because frankly nobody is gonna care whether you quit or not.
>
> As a matter of fact, when I presented my 4tH 30 years ago, some people went to great length to make
> me stop, because they felt it was "an abomination". Needless to say - in that regard I took approach II
> because I loved was I was doing - and nobody was gonna stop me doing it.
>
> Sure, I'm always happy to see when people like the product and help it shape with their suggestions
> - and it also happens that I say "No". Or I say "Maybe". And it takes me YEARS to turn around.
>
> If you actually get "demotivated" because you're not hearing what you want to hear, may be, just may be,
> you're not the right person to do or lead the project.
>
> And most CERTAINLY don't take it to c.l.f. Believe it or not - we're actually the nice guys. ;-)
>
> Hans Bezemer

It certainly has a negative vibe to it. You got to remember, it's only free personal stuff, as long as the documentation covers the functionality correctly, and I an non-obtuse way, your fine. Some people around here seem insanely jealous of people sticking theirs heads up, chest out, or neck out. It's nuts. Though, you should be able to do it in not many pages. When I wanted to do my own OS and language, real time, deterministic etc, I wanted to do 20 pages that taught you how to program, the languages, and the remaining 80 pages, the OS interfaces. That's 100 pages to learn the most high performance advanced OS design. I didn't tell people, because it would be quite an achievement. It's like the 10 minute floating astronaut film intro I wanted to do, no flash back, memories, speaking etc, just a practice of presence and micro expressions etc. This requires real delivery talent, to make something like that not stagnant or boring. But, it pays when criticising others to realise, you could do more.

So, you could rewrite your documentation for color fourth the, and charge $10 for the effort. I certainly would think it's interesting. But, you could do this for many languages you think are deficient, as a sort of programming guide system.

Howard is right, to keep going, you are right, that documentation standards should be more, but not many are good at that, and around here, not many seem to need more than the basics. So, a happy minimum is needed. There is a 1000:1 difference between best and worse programmers. Don't matter what you right the lower 1% may not be good programmers, and I say, maybe we should forget the lower 10% professionally, and raise the standard to accommodate the other 90%. But, maybe the good programmers are a lot less percent than 90%. So, you night like to collaborate with other Forth language writers, on a format for writing documentation to replace Starting Forth + manual approach. There is potential fur tend of thousands of ashes per year, I'd it open forth up to new experimenters. But, I think a big issue is forth roots being stuck in the past, in pages and simple text display programming. The standard needs to be more user friendly and advanced. This means, that an gui/text menued widowed, community open source editing and program project software package, with error checking interface, could be done to be shipped with any forth compiler. The language writer, then only needs to customise that package, or just use the standard one for the host or target OS. Headaches gone. The documentation fir that can be written well once. The language documentation can use a listing and tutorial framework, that the language is inserted into, and into standardised help files. I don't care if somebody makes theirs light grey text on dark purple back ground as their branding, as long as people can hop over to another forth and know how the packages work, and quickly learn the language. That's more, and offers a solution for your problems with other forths.

On Wednesday, April 6, 2022 at 8:37:41 PM UTC+10, jpit...@gmail.com wrote:
> On Wednesday, 6 April 2022 at 10:10:08 UTC+1, minf...@arcor.de wrote:
> > jpit...@gmail.com schrieb am Mittwoch, 6. April 2022 um 08:53:36 UTC+2:
> > > On Wednesday, 6 April 2022 at 03:29:09 UTC+1, dxforth wrote:
> > > > On 6/04/2022 03:47, minf...@arcor.de wrote:
> > > > > ...
> > > > > BTW I grew up with long assembly listings, so the documentation looks
> > > > > fine to me ;-)
> > > > >
> > > > > em.. thinking back in reality I grew up with tube radios .....
> > > > IOW book listings are reminiscent of the days pre-floppy and internet.
> > > > When folks had the luxury of 'getting it right the first time' because
> > > > there was a long time between technology changes.
> > > It just shows the type of people you are.
> > >
> > > If I like the work Howerd invested and post it,
> > >
> > > then the rest of your comments is ripping his work apart.
> > > Does it add anything to his work or post or colorforth?
> > >
> > > It would be just like me saying:
> > > What a waste of everybody' s time for 650 pages that hardly anybody will look at, or use.
> > > You probably had your reasons?
> > >
> > > But you do not have a clue why he did it like this.
> > >
> > > DEMOTIVATION PURE.
> > > And reflect carefully what you post here.
> > > Or even if.
>
> > Well and good, I certainly had no demotivation in mind. So put your good
> > advices elsewhere.
> >
> > Back to cf: Again kudos to Howerd!
> >
> > My remark on cf's exotic human interface was intended to perhaps discuss whether
> > it could be innovated to be more 'palatable' with normal hardware and for people with
> > visual deficiencies. But I guess this is an old discussion.
> Can you please advise how this should be done.
> It has been posted here based on what you had said.
> It will stay here for the rest of our lives. And probably longer.
>
> Can you recommend a better place where to post it?
> And waste more of everybody's time?

Color forth editor could be written to display the different colours in a different style, that the user selects. I think Chuck might have mentioned this before, bold underline etc. But, you could also start different words with a lower right ASCII like quarter block graphic, or solid block. Anytime the user uses the normal technique to enable color words, the editor inserts the virtual block, or other representation. So, it's doable fur pie who have color challenged equipment or vision. In my own editor, I wanted to actually use lines to link the depths of loops, to make them easy to track. If we look at forth, what do we need, their is compile time and run time sections, and loops and words (which are non overlapping sections of code, normally :). That is three different in portrayal, under line, bold italic. But colorforth is more than that. With the ascii character set vertical nested loops can be portrayed with vertical and horizontal lines. So, there is an gui like text alternative interface system there.

On Thursday, April 7, 2022 at 4:57:46 PM UTC+2, Wayne morellini wrote:
> It certainly has a negative vibe to it.
Nagging aboout "the tone": lack of arguments. https://en.wikipedia.org/wiki/File:Graham%27s_Hierarchy_of_Disagreement.svg

> You got to remember, it's only free personal stuff
I already addressed that one.

> as long as the documentation covers the functionality correctly
If it is incorrect - agreed, that's worse.

> Some people around here seem insanely jealous of people sticking theirs heads up, chest out, or neck out. It's nuts.
Weasel speak. Which people - be specific. The only thing *I* object to is that when you say you have WONDERFUL documentation, it'd better BE wonderful. And IMHO - it's not.

> Though, you should be able to do it in not many pages.
I'd genuinely like to see that. But if I take the best documentation I ever viewed (Unix manuals and Borland manuals) and the ones I threw out of the window in frustration, I'm somewhat skeptical.

> So, you could rewrite your documentation for color fourth the, and charge $10 for the effort. I certainly would think it's interesting. But, you could do this for many languages you think are deficient, as a sort of programming guide system.
FYI: I already published a Forth manual under FDL. They're free to use it. Others have done it - and I'm happy to provide a link: https://thebeez.home.xs4all.nl/ForthPrimer/
And you can't have me for a mere $10 ;-) That's not a fee, that's change.

> Howard is right, to keep going, you are right, that documentation standards should be more, but not many are good at that, and around here, not many seem to need more than the basics.
How do you know?! Do you measure it by the number of survivors or the ones that silently sank to the bottom of the ocean?

> So, you night like to collaborate with other Forth language writers, on a format for writing documentation to replace Starting Forth + manual approach.
I've started "And so Forth.." in the last century, because people complained that my manual had errors, because the code didn't work.
It proved to be they were applying the lessons to their own Forth variant - and that was not what the manual was all about. So I wrote
this vanilla thing, asked if somebody wanted to participate, nobody came - and in the meanwhile I've lost just about every interest.

Hans Bezemer

On Monday, April 4, 2022 at 4:44:03 PM UTC-4, Howerd wrote:
> Hi Forthers,
>
> I am pleased to announce an updated version of colorForth : cf2022.
>
> https://sourceforge.net/projects/colorforth/
> https://github.com/Howerd/colorForth
> or from my website:
> https://www.inventio.co.uk/cf2022/
>
> Documentation is here :
> http://www.inventio.co.uk/cf2022/cf2022_colorForth.pdf
>
> Readme is here :
> https://www.inventio.co.uk/cf2022/readme.txt
>
> The main difference between cf2019 and cf2022 is that cf2022 has an
> ASCII font, even though it still uses Shannon-Fano encoding for the cf
> token names.
> This is step in the direction of the rest of the programming world.
>
> It occurred to me while I was updating cf2022 that I like colorForth
> because it is as close to the metal as you can get - I see a connection
> between colorForth and this video : https://youtu.be/gNRnrn5DE58
> colorForth is the equivalent of the Surface Plate that everything else
> can be referenced too. Just my 2c worth.
>
> Enjoy!
>
> Cheers,
> Howerd

Dear Howerd,

I too, like getting as close to the metal as I can. So I've been exploring how to design stack computers in Verilog for FPGAs, and their requisite assemblers in whatever language gets the job done (gforth, Common Lisp, Guile, Python3).

I suggest that you provide a "System Requirements" section in cf2022_colorForth.pdf near the beginning that makes it clear that colorForth requires a legacy i386 box/BIOS. Or perhaps I'm misinterpreting the "Under the Hood" section.

Many moons ago, I was running a main/backup pair of colorForth floppys on a i386 box, and made a bit of progress "getting it". But other i386 boxes failed due (I thought) to incompatible video hardware.

I admire your tenacity.

Respectfully,
Myron Plichota

On 6/04/2022 21:40, Hans Bezemer wrote:
>
> But the most significant lesson to learn when you start a project - ANY project - is that you should
> basically be doing it for yourself. Life is NOT a Chinese party convention where everybody automatically
> applauds every single thing you're doing.

Don't you mean ANS Forth? 'If you're not with us then you must be against us' :)

On 8/04/2022 07:30, Hans Bezemer wrote:
> On Thursday, April 7, 2022 at 4:57:46 PM UTC+2, Wayne morellini wrote:
> ...
>> Howard is right, to keep going, you are right, that documentation standards should be more, but not many are good at that, and around here, not many seem to need more than the basics.

> How do you know?! Do you measure it by the number of survivors or the ones that silently sank to the bottom of the ocean?

By "basics" I assume Wayne meant the 'nitty gritty'. Few of us are trained or
employed as technical writers but find ourselves having to document. The main
criteria being it can be understood by our peers. That said, docs written by
bona-fide technical writers are a delight. I was employed in telecoms and the
manuals provided by Siemens for their equipment were second-to-none - at least
in the 60/70's when there was time to produce great manuals and 'investor profits'
didn't have the importance it has today.

dxforth <dxforth@gmail.com> writes:
> Few of us are trained or employed as technical writers but find
> ourselves having to document. The main criteria being it can be
> understood by our peers.

RMS told me how he writes documentation. I don't follow the method
exactly, but keep something like it in mind, and I find that it helps.

Basically he writes a sentence of documentation, then sits back and
re-reads it, and asks himself what the next thing is that the user will
want to know after reading that sentence. That tells him what sentence
to write next. Repeat until all topics for the document are covered.

Then, print out the resulting document and circulate it to a few people
for comments. Implement the suggestions and circulate again. Two or so
iterations of that is usually enough to get a serviceable document.

On Thu, 7 Apr 2022 14:30:32 -0700 (PDT)
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

[]
> FYI: I already published a Forth manual under FDL. They're free to use it. Others have done it - and I'm happy to provide a link: https://thebeez.home.xs4all.nl/ForthPrimer/
[]

Very minor point: It's Lego blocks (or maybe bricks), in UKE, not Lego stones.

--
Bah, and indeed Humbug.

On Friday, April 8, 2022 at 10:10:52 AM UTC+2, Paul Rubin wrote:
> RMS told me how he writes documentation. I don't follow the method
> exactly, but keep something like it in mind, and I find that it helps.
> Basically he writes a sentence of documentation, then sits back and
> re-reads it, and asks himself what the next thing is that the user will
> want to know after reading that sentence. That tells him what sentence
> to write next. Repeat until all topics for the document are covered.
Basically - I think that's exactly the proper method. E.g. I was recently working
on the basics of basics - absolute beginner stuff. Assign a value to a variable.
Well, if *I* were a perfect beginner, I would ask myself "what if I REASSIGN
the same or a different value to the same variable? Would it still be taken?
Or do I have to erase it first? So yes - that's a proper thing. I support that one.

> Then, print out the resulting document and circulate it to a few people
> for comments. Implement the suggestions and circulate again. Two or so
> iterations of that is usually enough to get a serviceable document.
Agreed again. The feedback from your users is EXACTLY what you need to make
it better. The problem is - you know all this stuff already. It's crystal clear to you,
otherwise you wouldn't be writing about it. My take is, basically every comment
should lead to some changes in the text. Because most people wouldn't go to
the trouble informing you if everything was alright.

Thanks for your valuable insight! I appreciate it.

Hans Bezemer

On Friday, April 8, 2022 at 3:27:05 AM UTC+2, dxforth wrote:
> On 6/04/2022 21:40, Hans Bezemer wrote:
> >
> > But the most significant lesson to learn when you start a project - ANY project - is that you should
> > basically be doing it for yourself. Life is NOT a Chinese party convention where everybody automatically
> > applauds every single thing you're doing.
> Don't you mean ANS Forth? 'If you're not with us then you must be against us' :)
ANS Forth is a standard - like "Das Kapital" is a book. You either adopt it or don't - it's
that easy.

If you adopt it, you're a proponent. If you don't, you're the antagonist. A group of proponents
is a party. And you can be with them (and follow party rule) or you don't. If you don't
they don't have any influence on you or your work (given you're basically doing it for yourself).
Which pretty much makes everything they say moot, including 'If you're not with us then
you must be against us'.

Be aware though, that rules change if a group is violent, like communists, fascists or BLM.
I don't feel however, this applies to ANS Forth proponents. Correct me if I'm wrong.

Hans Bezemer