Erich Wälde, the current maintainer of AmForth, asked me to forward this
E-mail from the AmForth mailing list to clf:

Erich Wälde <ew.forth@nassur.net> writes:
> Dear AmForthers,
>
> I am herewith stepping down from the maintainer role of AmForth. For
details,
> read on. If anyone is interested to take over, get in touch with me.
>
>
> In 2020 I received the logins of amforth.sourceforge.net, basically
because I
> was lucky enough to have met Matthias personally a few times. At that
time I
> had a lot of ideas on how to proceed. And while I managed to create an
> official release, there are a few obstacles in this path.
>
> First and foremost I am facing a health issue. It is subtle, but it
> seriously limits, what I can do. I still have to make several difficult
> decisions regarding my daily life. I have started to decrease the number
of
> things on my list by cancelling items. I have to accept the fact, that
I'm not
> in a position any more to advance the AmForth project in a meaningful
way.
>
> Secondly, AmForth has become complex over time. Matthias added support
for
> three more target platforms (msp430, arm, riscv32). Allthough access to
these
> is easily achievable, I use only avr. And I use it less these days.
>
> Thirdly, AmForths tools are depending heavily on python code, a language
I > consider myself illiterate in. I have written a few small perl scripts
around
> AmForth to serve my needs. I heavily depend on those and on a Makefile.
>
> Add the fact, that in 2020 I spent countless hours to port my data
acquisition
> stuff at home from amforth 4.6 to 6.9 and it just did not become stable.
To
> this day I still have no clue, why the thing hangs itself after some
time,
> sometimes hours, sometimes several days. In other words: unusable.
>
>
> Step back: what would I have done, if I didn't know Matthias, and the
project
> would just have become silent? Simplify. Simplify heavily.
>
> Very recently I have made a fork of AmForth release 5.0. That version is
> before support for msp430 was officially added (5.5). That version
happens to
> compile with avra rather than wine/avrasm2.exe. Along the way I found,
that
> avra has seen new releases, which add support for my beloved atmega644p
and
> lots of fixes, which is nice! This removes the dependancy from wine and
allows
> for smaller systems for development.
>
> So I have picked up my data acquisition project again with the fork
mentioned
> above. Any Interrupt Service Routines are written in assembly to avoid
the
> thing that I uncovered in 2017, namely a race condition 1 bit wide and 1
> instruction cycle long. I pick missing bits and pieces from later
releases. I
> would like to add a few features regarding sensors with different needs.
A > first experiment has run more than 10^6s (12d) without any failure. So I
am
> moderately optimistic to continue along this simplified path.
>
>
> Thanks to all, who have answered the list, contributed code, ideas,
> documentation in one form or other. It has been an interesting
experience.
> And should you still care to listen: if you have one or a few more
important
> plans, do not delay them, you might be unable to pursue them later.
>
> Happy hacking, and use the Forth!
>
> Cheers
> Erich

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
https://bernd-paysan.de/

On Friday, 20 May 2022 at 14:33:13 UTC-4, Bernd Paysan wrote:
> Erich Wälde, the current maintainer of AmForth, asked me to forward this
> E-mail from the AmForth mailing list to clf:
>
> Erich Wälde <ew.f...@nassur.net> writes:
> > Dear AmForthers,
> >
> > I am herewith stepping down from the maintainer role of AmForth. For
> details,
> > read on. If anyone is interested to take over, get in touch with me.
> >

I saw this on the AmForth mailing list.

This is really too bad; AmForth is a nice turnkey solution for the platforms it targets. I liked how it was basically an old-school Forth but with Arduino parts that acknowledged the hardware in a way that made sense to anyone who had already worked with the usual Arduino tools.

I wish I was the sort of person who could successfully adopt the project.

On Friday, 20 May 2022 at 19:33:13 UTC+1, Bernd Paysan wrote:
> Erich Wälde, the current maintainer of AmForth, asked me to forward this
> E-mail from the AmForth mailing list to clf:
>
> Erich Wälde <ew.f...@nassur.net> writes:
> > Dear AmForthers,
> >
> > I am herewith stepping down from the maintainer role of AmForth. For details,
> > read on. If anyone is interested to take over, get in touch with me.
> >
> >
> > In 2020 I received the logins of amforth.sourceforge.net, basically because I
> > was lucky enough to have met Matthias personally a few times. At that time I
> > had a lot of ideas on how to proceed. And while I managed to create an
> > official release, there are a few obstacles in this path.
> >
> > First and foremost I am facing a health issue. It is subtle, but it
> > seriously limits, what I can do. I still have to make several difficult
> > decisions regarding my daily life. I have started to decrease the number
> of
> > things on my list by cancelling items. I have to accept the fact, that
> I'm not in a position any more to advance the AmForth project in a meaningful way.
> >
> > Secondly, AmForth has become complex over time. Matthias added support for
> > three more target platforms (msp430, arm, riscv32). Allthough access to these
> > is easily achievable, I use only avr. And I use it less these days.
> >
> > Thirdly, AmForths tools are depending heavily on python code, a language
> I consider myself illiterate in. I have written a few small perl scripts
> around AmForth to serve my needs. I heavily depend on those and on a Makefile.
> >
> > Add the fact, that in 2020 I spent countless hours to port my data
> acquisition
> > stuff at home from amforth 4.6 to 6.9 and it just did not become stable..
> To
> > this day I still have no clue, why the thing hangs itself after some
> time,
> > sometimes hours, sometimes several days. In other words: unusable.
> >
> >
> > Step back: what would I have done, if I didn't know Matthias, and the
> project
> > would just have become silent? Simplify. Simplify heavily.
> >
> > Very recently I have made a fork of AmForth release 5.0. That version is
> > before support for msp430 was officially added (5.5). That version
> happens to
> > compile with avra rather than wine/avrasm2.exe. Along the way I found,
> that
> > avra has seen new releases, which add support for my beloved atmega644p
> and
> > lots of fixes, which is nice! This removes the dependancy from wine and
> allows
> > for smaller systems for development.
> >
> > So I have picked up my data acquisition project again with the fork
> mentioned
> > above. Any Interrupt Service Routines are written in assembly to avoid
> the
> > thing that I uncovered in 2017, namely a race condition 1 bit wide and 1
> > instruction cycle long. I pick missing bits and pieces from later
> releases. I
> > would like to add a few features regarding sensors with different needs..
> A
> > first experiment has run more than 10^6s (12d) without any failure. So I
> am
> > moderately optimistic to continue along this simplified path.
> >
> >
> > Thanks to all, who have answered the list, contributed code, ideas,
> > documentation in one form or other. It has been an interesting
> experience.
> > And should you still care to listen: if you have one or a few more
> important
> > plans, do not delay them, you might be unable to pursue them later.
> >
> > Happy hacking, and use the Forth!
> >
> > Cheers
> > Erich
>
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> https://bernd-paysan.de/

I reposted this in the Forth facebook group and this was the feedback there..

Is there any chance to modify the license type -
or is the view this is not necessary?

If yes - who could authorize this change?

+++++++++++++++++++++++++++++++++++++++++++++++++

Guy Proteus
Cool project but GPL3 always kept it unavailable for use, alas.

Reply19h
Travis Bemann
Guy Proteus The GPL2/3 is an unfortunate choice of licenses for an embedded Forth implementation, which is very often intimately intertwined with code compiled by it, so, if one wants to go by how the FSF interprets things, one would have to license any code that one wants to distribute binaries for generated with said Forth implementation as GPL2/3 the same way. I know that Mecrisp-Stellaris is also licensed as GPL3, so AmForth is not the only Forth implementation for which this applies.
For this reason, with zeptoforth I specifically chose the MIT license, not out of any particular love for permissive licenses (I find the BSD people's fears of gcc contaminating their code and hence the rationale for adopting clang rather silly) but rather so I would not force any particular license upon users of zeptoforth who wanted to generate binaries from their code.

Reply18h
Juergen G Pintaske
Author
Travis Bemann I assume the type of licence had been selected in good faith - as this Forth is educational.
How should this be changed to make it free to use?

Reply1h
Travis Bemann
Juergen G Pintaske The problem is that the original author is dead, so unless we manage to find his next of kin and convince them of the necessity of changing the license, such is practically impossible.
That said, one can still use AmForth - one just has to distribute all of one's code for use with it as source-only unless one also wishes to license one's code as GPL3.

Reply25m
Guy Proteus
Sadly that's the problem with these viral licenses. They're very difficult to unwind.
Reply7m

Jurgen Pitaske <jpitaske@gmail.com> writes:
> Is there any chance to modify the license type - or is the view this
> is not necessary?
> If yes - who could authorize this change?

The GPL license is one of the things I find attractive about both
amForth and gforth. Gforth is the main Forth that I use. The main
reason I don't use amForth is that up til recently I haven't cared much
about AVR hardware.

These days there is an AVR program that I'm interested in
(tiny.cc/TKAnduril). It is written in C but it could be cool to have a
Forth version, so amForth immediately suggests itself.

>
> Reply25m
> Guy Proteus
> Sadly that's the problem with these viral licenses. They're very difficult to unwind.

"Humans have complicated every simple gift of the gods" - Diogenes

On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
> >
> > Reply25m
> > Guy Proteus
> > Sadly that's the problem with these viral licenses. They're very difficult to unwind.
> "Humans have complicated every simple gift of the gods" - Diogenes

I just add this to your pile of useless bullshit contributions.

On 17/06/2022 16:07, Jurgen Pitaske wrote:
> On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
>> >
>> > Reply25m
>> > Guy Proteus
>> > Sadly that's the problem with these viral licenses. They're very difficult to unwind.
>> "Humans have complicated every simple gift of the gods" - Diogenes
>
> I just add this to your pile of useless bullshit contributions.

Then you would have loved this:

Ray Duncan writes,

> One of the reasons the surviving Forth vendors have concentrated
> on embedded systems is that this is one of the few market niches
> that has not been systematically destroyed by the FIG-public domain-
> hacker cabal. Now that people like Ting are circulating atrocities
> like EFORTH, even the embedded systems market is dying. This is not
> a flame, it's just the sad truth.

> It's certainly been clear to me from lurking in this newsgroup for
> months that *this* sector of the Forth community, although it
> prides itself on being a center of Forth expertise, has no clue
> whatsoever as to what the Forth vendors (Forth Inc., LMI,
> Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
> or the capabilities of their systems. Thus, newcomers to Forth,
> who come here for advice, are being steered to EFORTH, FPC, and
> other undocumented unstable unsupported public domain Forth systems
> as "solutions." No wonder Forth is in decline!

On Saturday, 18 June 2022 at 05:49:33 UTC+1, dxforth wrote:
> On 17/06/2022 16:07, Jurgen Pitaske wrote:
> > On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
> >> >
> >> > Reply25m
> >> > Guy Proteus
> >> > Sadly that's the problem with these viral licenses. They're very difficult to unwind.
> >> "Humans have complicated every simple gift of the gods" - Diogenes
> >
> > I just add this to your pile of useless bullshit contributions.

> Then you would have loved this:
>
> Ray Duncan writes,
>
> > One of the reasons the surviving Forth vendors have concentrated
> > on embedded systems is that this is one of the few market niches
> > that has not been systematically destroyed by the FIG-public domain-
> > hacker cabal. Now that people like Ting are circulating atrocities
> > like EFORTH, even the embedded systems market is dying. This is not
> > a flame, it's just the sad truth.
>
> > It's certainly been clear to me from lurking in this newsgroup for
> > months that *this* sector of the Forth community, although it
> > prides itself on being a center of Forth expertise, has no clue
> > whatsoever as to what the Forth vendors (Forth Inc., LMI,
> > Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
> > or the capabilities of their systems. Thus, newcomers to Forth,
> > who come here for advice, are being steered to EFORTH, FPC, and
> > other undocumented unstable unsupported public domain Forth systems
> > as "solutions." No wonder Forth is in decline!

As said before
We can just add this to your pile of useless bullshit contributions.

But now you are getting worse.

Ting just died.

YOU ARE DISGUSTING. BUT THIS IS JUST YOU.

Ting did what he thought helps the Forth community.
I learnt a lot from him.
An offer he generated that people can either take up or not.
Who else generated so much Forth Documentation.

YOU HAVE NOT CONTRIBUTED ANYTHING HERE THAT WILL LAST.
Except for your bullshit obviously.

FORTH IS IN DECLINE AS OF FORTH KILLERS LIKE YOU.

On Saturday, June 18, 2022 at 12:49:33 AM UTC-4, dxforth wrote:
> On 17/06/2022 16:07, Jurgen Pitaske wrote:
> > On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
> >> >
> >> > Reply25m
> >> > Guy Proteus
> >> > Sadly that's the problem with these viral licenses. They're very difficult to unwind.
> >> "Humans have complicated every simple gift of the gods" - Diogenes
> >
> > I just add this to your pile of useless bullshit contributions.
> Then you would have loved this:
>
> Ray Duncan writes,
>
> > One of the reasons the surviving Forth vendors have concentrated
> > on embedded systems is that this is one of the few market niches
> > that has not been systematically destroyed by the FIG-public domain-
> > hacker cabal. Now that people like Ting are circulating atrocities
> > like EFORTH, even the embedded systems market is dying. This is not
> > a flame, it's just the sad truth.
>
> > It's certainly been clear to me from lurking in this newsgroup for
> > months that *this* sector of the Forth community, although it
> > prides itself on being a center of Forth expertise, has no clue
> > whatsoever as to what the Forth vendors (Forth Inc., LMI,
> > Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
> > or the capabilities of their systems. Thus, newcomers to Forth,
> > who come here for advice, are being steered to EFORTH, FPC, and
> > other undocumented unstable unsupported public domain Forth systems
> > as "solutions." No wonder Forth is in decline!

I can't argue with that. I probably should have bought MPE Forth a long time ago. Stephen has explained to me some of the advantages and how facile their licensing is. I just never pulled the trigger on buying it. I guess it was too easy to use a "free" Forth, even though it is largely unsupported now.

I am finishing up a large board order at the moment. When that is done I may be getting work to design a new board which means I will design a new test fixture and supporting program on the PC. So it will be a new opportunity to start with a different tool, such as MPE Forth.

This time, I'm not going to cut any corners on designing the testing. I've had many troubles with test fixtures and those can be more expensive than mistakes in the board design itself.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On 18/06/2022 16:09, Jurgen Pitaske wrote:
>
> Ting did what he thought helps the Forth community.

I wouldn't know what he thought besides which that's his business.
If anyone did imagine they were here to help the Forth community:

"One of the symptoms of an approaching nervous breakdown is the
belief that one’s work is terribly important"

On Saturday, 18 June 2022 at 07:48:15 UTC+1, dxforth wrote:
> On 18/06/2022 16:09, Jurgen Pitaske wrote:
> >
> > Ting did what he thought helps the Forth community.
> I wouldn't know what he thought besides which that's his business.
> If anyone did imagine they were here to help the Forth community:
>
> "One of the symptoms of an approaching nervous breakdown is the
> belief that one’s work is terribly important"

You are just explaining your misbehaviour - great.
You seem to be able to learn:

"One of the symptoms of an approaching nervous breakdown is the
belief that one’s work is terribly important"

On 18/06/2022 16:59, Jurgen Pitaske wrote:
> On Saturday, 18 June 2022 at 07:48:15 UTC+1, dxforth wrote:
>> On 18/06/2022 16:09, Jurgen Pitaske wrote:
>> >
>> > Ting did what he thought helps the Forth community.
>> I wouldn't know what he thought besides which that's his business.
>> If anyone did imagine they were here to help the Forth community:
>>
>> "One of the symptoms of an approaching nervous breakdown is the
>> belief that one’s work is terribly important"
>
> You are just explaining your misbehaviour - great.
> You seem to be able to learn:
>
> "One of the symptoms of an approaching nervous breakdown is the
> belief that one’s work is terribly important"

Duncan had the foresight to leave before he started typing in CAPS
shouting FORTH KILLER. We can only hope it'll be the same for us :)

On Saturday, 18 June 2022 at 08:38:45 UTC+1, dxforth wrote:
> On 18/06/2022 16:59, Jurgen Pitaske wrote:
> > On Saturday, 18 June 2022 at 07:48:15 UTC+1, dxforth wrote:
> >> On 18/06/2022 16:09, Jurgen Pitaske wrote:
> >> >
> >> > Ting did what he thought helps the Forth community.
> >> I wouldn't know what he thought besides which that's his business.
> >> If anyone did imagine they were here to help the Forth community:
> >>
> >> "One of the symptoms of an approaching nervous breakdown is the
> >> belief that one’s work is terribly important"
> >
> > You are just explaining your misbehaviour - great.
> > You seem to be able to learn:
> >
> > "One of the symptoms of an approaching nervous breakdown is the
> > belief that one’s work is terribly important"
> Duncan had the foresight to leave before he started typing in CAPS
> shouting FORTH KILLER. We can only hope it'll be the same for us :)

I do not know him, so do not imply what he meant and in which context.

We have a few FORTH KILLERS here.
Hugh Aguilar
Peter Fuck
You
come to mind.

On Saturday, 18 June 2022 at 08:38:45 UTC+1, dxforth wrote:
> On 18/06/2022 16:59, Jurgen Pitaske wrote:
> > On Saturday, 18 June 2022 at 07:48:15 UTC+1, dxforth wrote:
> >> On 18/06/2022 16:09, Jurgen Pitaske wrote:
> >> >
> >> > Ting did what he thought helps the Forth community.
> >> I wouldn't know what he thought besides which that's his business.
> >> If anyone did imagine they were here to help the Forth community:
> >>
> >> "One of the symptoms of an approaching nervous breakdown is the
> >> belief that one’s work is terribly important"
> >
> > You are just explaining your misbehaviour - great.
> > You seem to be able to learn:
> >
> > "One of the symptoms of an approaching nervous breakdown is the
> > belief that one’s work is terribly important"
> Duncan had the foresight to leave before he started typing in CAPS
> shouting FORTH KILLER. We can only hope it'll be the same for us :)

You are such a nasty person, you do not even consider what this post is about.

Somebody else in the Forth community had died.
AMForth taken over by sombody else to keep the work alive,
who unfortunately cannot continue.

A DISGUSTING person you are

dxforth <dxforth@gmail.com> writes:
>On 17/06/2022 16:07, Jurgen Pitaske wrote:
>> On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
>>> >
>>> > Reply25m
>>> > Guy Proteus
>>> > Sadly that's the problem with these viral licenses. They're very difficult to unwind.
....
>Ray Duncan writes,
>
>> One of the reasons the surviving Forth vendors have concentrated
>> on embedded systems is that this is one of the few market niches
>> that has not been systematically destroyed by the FIG-public domain-
>> hacker cabal. Now that people like Ting are circulating atrocities
>> like EFORTH, even the embedded systems market is dying. This is not
>> a flame, it's just the sad truth.

Well, these two statements are at odds with each other: Those who
complain about "viral licenses" tend to love public-domain code that
they can just copy into their proprietary product, slap their
copyright on, put the product under a commercial license (which of
course also sticks to the code and is at least as restrictive as the
"viral license") and sell it.

Ray Duncan's position was that he did not want competition from
public-domain Forth systems, and that he thought that competition
destroyed the market for commercial Forth systems.

What's your position?

>> It's certainly been clear to me from lurking in this newsgroup for
>> months that *this* sector of the Forth community, although it
>> prides itself on being a center of Forth expertise, has no clue
>> whatsoever as to what the Forth vendors (Forth Inc., LMI,
>> Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
>> or the capabilities of their systems. Thus, newcomers to Forth,
>> who come here for advice, are being steered to EFORTH, FPC, and
>> other undocumented unstable unsupported public domain Forth systems
>> as "solutions."

I have certainly seen commercial Forth vendors suggest their products
here in reply to requests for Forth system suggestions. I have not
used eForth nor F-PC, but AFAIK one of the strong points of eForth was
its documentation, and I also think that F-PC would not have been as
popular as it was if it had not been documented. There was quite a
bit of community surrounding both that provides some support, and at
least F-PC has seen several releases; it was also used in production,
so I doubt that it was unstable. As for eForth, it was not intended
as production system, so it must have had qualities beyond its
intended usage in order to pose a threat to a commercial Forth system
like what Ray Duncan produced.

It seems to me that Ray Duncan saw his Forth business in decline (and
eventually got out of that business), and blamed public domain Forth
systems for that. And the commercial vs. free aspect has certainly
been discussed frequently enough (mostly in earlier times) that it
even made it onto the FAQ:
<https://www.complang.tuwien.ac.at/forth/faq/faq-general-4.html#ss4.1>

> No wonder Forth is in decline!

Ah, that one. If we look at the most popular languages, free
implementations dominate most of them, and apparently most
implementors have found ways to get paid for their work on these free
implementations. So it may well be that free implementations have
crowded out the proprietary ones (however, Green Hills software still
seems to exist), but it has not hurt these languages.

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

In article <2022Jun18.105334@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>dxforth <dxforth@gmail.com> writes:
>>On 17/06/2022 16:07, Jurgen Pitaske wrote:
>>> On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
>>>> >
>>>> > Reply25m
>>>> > Guy Proteus
>>>> > Sadly that's the problem with these viral licenses.
>...
>>Ray Duncan writes,
>>
>>> One of the reasons the surviving Forth vendors have concentrated
>>> on embedded systems is that this is one of the few market niches
>>> that has not been systematically destroyed by the FIG-public domain-
>>> hacker cabal. Now that people like Ting are circulating atrocities
>>> like EFORTH, even the embedded systems market is dying. This is not
>>> a flame, it's just the sad truth.
>
>Well, these two statements are at odds with each other: Those who
>complain about "viral licenses" tend to love public-domain code that
>they can just copy into their proprietary product, slap their
>copyright on, put the product under a commercial license (which of
>course also sticks to the code and is at least as restrictive as the
>"viral license") and sell it.

+1
I also want to add that a system like mine (ciforth) although
it is not widely used, is stable, well documented and usable.
Can it be that bad mouthing GLP has come from not entirely
independant sources?

I can't believe that a couple of hundred euro's will stop
a business from using a commercial Forth. The they decide to
type in a FIG-Forth listing.

I draw attention to this statement.
>>They're very difficult to unwind.

The GPL is designed to be impossible to unwind. The intention of doing
so, reflects bad faith on the actor. OTOH all contributions on top of
a BSD license will get lost, as soon as Apple meets his demise. Or get
bought by an other company that lost interest in the copyright. Or get
a suite of owners (think Dec) that it becomes virtually impossible to
find out who owns the copyright, provided the sources don't get lost
in the first place.
Gpl is a big loss for legal firms in the US, perhaps in the billions,
comparing copyright lawsuits between gpl and other copyrights.

>- anton

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Saturday, June 18, 2022 at 12:13:28 PM UTC+2, none albert wrote:
[..]
> I can't believe that a couple of hundred euro's will stop
> a business from using a commercial Forth. The they decide to
> type in a FIG-Forth listing.
[..]
I can believe it. It is not the business that sees the need for a
commercial Forth, it is some individual inside it. How would such
an individual defend his desire to purchase a license, even if
it is just a few hundred dollars?

Without a license, the individual can't try to apply a professional
Forth for his problems and will not find out if it will do any good.
(This problem is the same for all less well-known languages.)

I guess if the individual persists, s/he tries to find a free system
to play with at home. The commercial systems has to
overcome the bad impressions made by the free products (it is
o so easy to loose faith by even something simple like an ALL CAPS
setting, yellow-on-orange colors (I mean you notepad++ !), block
files, no type-ahead, or cursor keys not working).

I guess we now observe to what business model this leads to,
eventually.

There is another way, and that is to be impressed by the
professionalism of the people working with Forth and seeing
the stuff they work on/with. That is how I got hooked myself,
the Dutch FIG had some great people at the time, and I
consulted for Pijnenburg. Great guys and gals.

-marcel

dxforth <dxforth@gmail.com> writes:
> > Ting did what he thought helps the Forth community.
> I wouldn't know what he thought besides which that's his business.
> If anyone did imagine they were here to help the Forth community:
>
> "One of the symptoms of an approaching nervous breakdown is the
> belief that one's work is terribly important"

If you had ever met Dr. Ting, you would not have suggested this. You might
conclude that he had made what turned out to be non-optimal decisions--eforth,
various custom CPU work, .... But behind it all was his life's
principle of Taoism. You saw it in how he interacted with people, and you
saw it in how he looked at technology.

He loved Forth because he saw the essential elegance and beauty
inherent in it.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Marcel Hendrix <mhx@iae.nl> writes:
>I can believe it. It is not the business that sees the need for a
>commercial Forth, it is some individual inside it. How would such
>an individual defend his desire to purchase a license, even if
>it is just a few hundred dollars?

Commercial Forth vendors have attacked that problem with gratis
evaluation versions.

>Without a license, the individual can't try to apply a professional
>Forth for his problems and will not find out if it will do any good.
>(This problem is the same for all less well-known languages.)
>
>I guess if the individual persists, s/he tries to find a free system
>to play with at home. The commercial systems has to
>overcome the bad impressions made by the free products (it is
>o so easy to loose faith by even something simple like an ALL CAPS
>setting, yellow-on-orange colors (I mean you notepad++ !), block
>files, no type-ahead, or cursor keys not working).

Well, if that's what irks you: Gforth is case-insensitive, up to 0.7
did not do colors in the xterm, and in development it has a setting
for light backgrounds (default), but you can also invoke DARK-MODE to
get better colours for dark backgrounds; gforth supports block files
as well as newline-separated files. Gforth treats typeahead like any
other stuff typed, and its command line allows to use cursor keys for
editing and command-line history.

And Gforth is free, so if the individual finds Gforth, none of your
list applies. But of course this may lead to a much worse problem for
the commercial vendor: The individual actually likes the free Forth,
and uses it for the project.*

Here are some that I irk me when dealing with iForth, lxf, sf, and
vfx.

Forth system startup clears the screen (IIRC iForth, lxf, vfx)
Ctrl-D at the start of the line does not do BYE (iforth, lxf, vfx)
Pasting into the xterm does not work (lxf (not useful at all),
vfx (short pieces work))
No FP wordset on startup, requires arcane incantations (sf, vfx4 (fixed in vfx5))
Long and varying startup time (iForth)

I modified iForth and VFX to get rid of the screen-clearing and some
of iForth's startup time, but as a result iForth does not understand
relative file names.

I observe that commercial Forth's are just as prone to these things as
the non-commercial one.

>I guess we now observe to what business model this leads to,
>eventually.

Gratis evaluation versions. Or do you have something else in mind?

[*] One interesting case is when MPE customer Micross (Nick Nelson)
discovered Raspberry Pis to replace the PCs for his applications. VFX
did not run on Raspis at the time, but Gforth did. So as a stopgap
MPE suggested that Micross uses Python, which they did. I am sure
that's because Python is a proper you-get-what-you-pay-for commercial
operation, unlike Gforth (hint: Python is free, just like Gforth).
MPE had judged Micross correctly: they switched to VFX on the Raspis
when that became available.

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

On Saturday, June 18, 2022 at 4:54:33 PM UTC+2, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> >I can believe it. It is not the business that sees the need for a
> >commercial Forth, it is some individual inside it. How would such
> >an individual defend his desire to purchase a license, even if
> >it is just a few hundred dollars?

It was not my intention to attack the free Forths, as it appears you
suspect. However, I did describe the situation of a few years ago,
that I assumed Albert was presumably talking about, and tried
to point out how that has changed.

> Commercial Forth vendors have attacked that problem with gratis
> evaluation versions.

Exactly.

> >Without a license, the individual can't try to apply a professional
> >Forth for his problems and will not find out if it will do any good.
> >(This problem is the same for all less well-known languages.)
> >I guess if the individual persists, s/he tries to find a free system
> >to play with at home.

Should have used the past tense.

> >The commercial systems has to
> >overcome the bad impressions made by the free products (it is
> >o so easy to loose faith by even something simple like an ALL CAPS
> >setting, yellow-on-orange colors (I mean you notepad++ !), block
> >files, no type-ahead, or cursor keys not working).
> Well, if that's what irks you: Gforth is case-insensitive, up to 0.7
> did not do colors in the xterm, and in development it has a setting
> for light backgrounds (default), but you can also invoke DARK-MODE to
> get better colours for dark backgrounds; gforth supports block files
> as well as newline-separated files. Gforth treats typeahead like any
> other stuff typed, and its command line allows to use cursor keys for
> editing and command-line history.

Well, there is that slight problem when I need it to run on Windows,
isn't there?

> And Gforth is free, so if the individual finds Gforth, none of your
> list applies. But of course this may lead to a much worse problem for
> the commercial vendor: The individual actually likes the free Forth,
> and uses it for the project.*

I would not have any problem introducing Gforth where I work.

> Here are some that I irk me when dealing with iForth, lxf, sf, and
> vfx.
>
> Forth system startup clears the screen (IIRC iForth, lxf, vfx)
> Ctrl-D at the start of the line does not do BYE (iforth, lxf, vfx)

I definitely don't want that, but users have the source of proced
and can install that themselves with little effort.

> Long and varying startup time (iForth)

I don't recognize it but vaguely remember you measuring that
in the past. On Windows there is not much I can do, the first
start pulls in dll's and that takes a few seconds, after that it
is near instantaneous (in my perception).

The VFX system I sometimes use deliberately prevents quick
startup and wants me to click away a popup (first prevents
type-ahead and then wait a few extra seconds for good measure).
At least I don't do *that* stuff.

> I modified iForth and VFX to get rid of the screen-clearing and some
> of iForth's startup time, but as a result iForth does not understand
> relative file names.

"as a result" ? Relative file names might be useful and I have looked
at it in the past but I don't recall why I didn't implement it (I do have
some user tools for it but never use them). In my C compiler
environment relative files are a pain as I have no idea where a certain
file lives on disk. Python is even worse, it has a file manager package
that I can't (and actually don't want to) understand at all. It is easier
to simply paste text in the main source than trying to include it. (And
yes, I actually did that.)

> I observe that commercial Forth's are just as prone to these things as
> the non-commercial one.

Yes, but I suppose the commercial ones react more favorably when
customers actually complain.

> >I guess we now observe to what business model this leads to,
> >eventually.
> Gratis evaluation versions. Or do you have something else in mind?

Indeed, a very good thing!

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>On Saturday, June 18, 2022 at 4:54:33 PM UTC+2, Anton Ertl wrote:
>> Marcel Hendrix <m...@iae.nl> writes:
>> >I can believe it. It is not the business that sees the need for a
>> >commercial Forth, it is some individual inside it. How would such
>> >an individual defend his desire to purchase a license, even if
>> >it is just a few hundred dollars?
>
>It was not my intention to attack the free Forths, as it appears you
>suspect. However, I did describe the situation of a few years ago,
>that I assumed Albert was presumably talking about, and tried
>to point out how that has changed.

I don't think the situation has changed much in the last few years,
certainly wrt. Gforth's capabilities. And evaluation versions for
commercial Forth's have also been available for more than a few years.

>Well, there is that slight problem when I need it to run on Windows,
>isn't there?

Not that I know of.

Most recent snapshot (currently from July 2020):

http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.exe

Gforth 0.7.0:

http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/gforth-0.7.0-20081226.exe
http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/gforth-0.7.0-20090215.exe

Or you can build a Linux binary and run it under WSL.

>> Here are some that I irk me when dealing with iForth, lxf, sf, and
>> vfx.
>>
>> Forth system startup clears the screen (IIRC iForth, lxf, vfx)
>> Ctrl-D at the start of the line does not do BYE (iforth, lxf, vfx)
>
>I definitely don't want that, but users have the source of proced
>and can install that themselves with little effort.

That's not quite the answer that the user of a commercial Forth wants
to read (especially not without any pointer where to look).

>> Long and varying startup time (iForth)
>
>I don't recognize it but vaguely remember you measuring that
>in the past.

The variation looks ok with my changes (IIRC without my changes it
took a lot longer and varied a lot, say, between 0.2s and 0.5s); the
startup time is still long. Here's 100 startups on a Skylake:

[~:130742] perf stat -r100 iforth bye

Performance counter stats for 'iforth bye' (100 runs):

78.60 msec task-clock # 0.934 CPUs utilized ( +- 0.27% )
2 context-switches # 0.031 K/sec ( +- 2.88% )
0 cpu-migrations # 0.000 K/sec ( +-100.00% )
3374 page-faults # 0.043 M/sec ( +- 0.56% )
312778534 cycles # 3.979 GHz ( +- 0.07% )
383340770 instructions # 1.23 insn per cycle ( +- 0.05% )
59045145 branches # 751.216 M/sec ( +- 0.05% )
1066105 branch-misses # 1.81% of all branches ( +- 0.06% )

0.084142 +- 0.000211 seconds time elapsed ( +- 0.25% )

For comparison:

cycles
6740582 gforth-fast 0.7.3 (Debian, no dynamic native code generation)
41409174 gforth-fast development version, with dynamic native code
312778534 iForth
1328939 lxf
11607005 sf
11282568 vfx4.72

But given that there is not much variation in startup cycles, one can
just subtract them from the results.

>The VFX system I sometimes use deliberately prevents quick
>startup and wants me to click away a popup (first prevents
>type-ahead and then wait a few extra seconds for good measure).
>At least I don't do *that* stuff.

Yes, that's horrible. I have the better experience in Linux. VFX5
even has fixed the xterm corruption that resulted from exiting from
VFX4 after an error.

>> I modified iForth and VFX to get rid of the screen-clearing and some
>> of iForth's startup time, but as a result iForth does not understand
>> relative file names.
>
>"as a result" ? Relative file names might be useful and I have looked
>at it in the past but I don't recall why I didn't implement it

Ok, I thought that it was a result of my changes, and therefore did
not report it, because I could not imagine you doing this on purpose.
Doing it the stupid way that VFX and SF do it (relative to the working
directory, which comes out of Unix file handling by default) is not
great, but far better than not being able to deal with relative file
names at all. The right way, of course, for INCLUDE etc. is to be
relative to the directory the currently text-interpreted file is in
(or, on the command line, the working directory).

Having to change to absolute file names ensures that I never will use
iforth for any file that contains an INCLUDE/REQUIRE itself.

IIRC iforth used to be better. I used iforth-2.1 to run appbench
programs, many of which consist of several files. I would have
noticed if that worked only with absolute file names.

>(I do have
>some user tools for it but never use them). In my C compiler
>environment relative files are a pain as I have no idea where a certain
>file lives on disk.

In C 'include <file>' searches the files in a path, so that may be
hard. If I had that problem, I would use locate, and in hard cases
strace to find out which files are included. If you are using gcc,
gcc -E -MD is supposed to produce a dependency file, which should
contain file paths (probably relative to the working directory).

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

On Saturday, 18 June 2022 at 18:49:40 UTC+1, Anton Ertl wrote:
> Marcel Hendrix <m...@iae.nl> writes:
> >On Saturday, June 18, 2022 at 4:54:33 PM UTC+2, Anton Ertl wrote:
> >> Marcel Hendrix <m...@iae.nl> writes:
> >> >I can believe it. It is not the business that sees the need for a
> >> >commercial Forth, it is some individual inside it. How would such
> >> >an individual defend his desire to purchase a license, even if
> >> >it is just a few hundred dollars?
> >
> >It was not my intention to attack the free Forths, as it appears you
> >suspect. However, I did describe the situation of a few years ago,
> >that I assumed Albert was presumably talking about, and tried
> >to point out how that has changed.
> I don't think the situation has changed much in the last few years,
> certainly wrt. Gforth's capabilities. And evaluation versions for
> commercial Forth's have also been available for more than a few years.
> >Well, there is that slight problem when I need it to run on Windows,
> >isn't there?
> Not that I know of.
>
> Most recent snapshot (currently from July 2020):
>
> http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.exe
>
> Gforth 0.7.0:
>
> http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/gforth-0.7.0-20081226.exe
> http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/gforth-0.7.0-20090215.exe
>
> Or you can build a Linux binary and run it under WSL.
> >> Here are some that I irk me when dealing with iForth, lxf, sf, and
> >> vfx.
> >>
> >> Forth system startup clears the screen (IIRC iForth, lxf, vfx)
> >> Ctrl-D at the start of the line does not do BYE (iforth, lxf, vfx)
> >
> >I definitely don't want that, but users have the source of proced
> >and can install that themselves with little effort.
> That's not quite the answer that the user of a commercial Forth wants
> to read (especially not without any pointer where to look).
> >> Long and varying startup time (iForth)
> >
> >I don't recognize it but vaguely remember you measuring that
> >in the past.
> The variation looks ok with my changes (IIRC without my changes it
> took a lot longer and varied a lot, say, between 0.2s and 0.5s); the
> startup time is still long. Here's 100 startups on a Skylake:
>
> [~:130742] perf stat -r100 iforth bye
>
> Performance counter stats for 'iforth bye' (100 runs):
>
> 78.60 msec task-clock # 0.934 CPUs utilized ( +- 0.27% )
> 2 context-switches # 0.031 K/sec ( +- 2.88% )
> 0 cpu-migrations # 0.000 K/sec ( +-100.00% )
> 3374 page-faults # 0.043 M/sec ( +- 0.56% )
> 312778534 cycles # 3.979 GHz ( +- 0.07% )
> 383340770 instructions # 1.23 insn per cycle ( +- 0.05% )
> 59045145 branches # 751.216 M/sec ( +- 0.05% )
> 1066105 branch-misses # 1.81% of all branches ( +- 0.06% )
>
> 0.084142 +- 0.000211 seconds time elapsed ( +- 0.25% )
>
> For comparison:
>
> cycles
> 6740582 gforth-fast 0.7.3 (Debian, no dynamic native code generation)
> 41409174 gforth-fast development version, with dynamic native code
> 312778534 iForth
> 1328939 lxf
> 11607005 sf
> 11282568 vfx4.72
>
> But given that there is not much variation in startup cycles, one can
> just subtract them from the results.
> >The VFX system I sometimes use deliberately prevents quick
> >startup and wants me to click away a popup (first prevents
> >type-ahead and then wait a few extra seconds for good measure).
> >At least I don't do *that* stuff.
> Yes, that's horrible. I have the better experience in Linux. VFX5
> even has fixed the xterm corruption that resulted from exiting from
> VFX4 after an error.
> >> I modified iForth and VFX to get rid of the screen-clearing and some
> >> of iForth's startup time, but as a result iForth does not understand
> >> relative file names.
> >
> >"as a result" ? Relative file names might be useful and I have looked
> >at it in the past but I don't recall why I didn't implement it
> Ok, I thought that it was a result of my changes, and therefore did
> not report it, because I could not imagine you doing this on purpose.
> Doing it the stupid way that VFX and SF do it (relative to the working
> directory, which comes out of Unix file handling by default) is not
> great, but far better than not being able to deal with relative file
> names at all. The right way, of course, for INCLUDE etc. is to be
> relative to the directory the currently text-interpreted file is in
> (or, on the command line, the working directory).
>
> Having to change to absolute file names ensures that I never will use
> iforth for any file that contains an INCLUDE/REQUIRE itself.
>
> IIRC iforth used to be better. I used iforth-2.1 to run appbench
> programs, many of which consist of several files. I would have
> noticed if that worked only with absolute file names.
> >(I do have
> >some user tools for it but never use them). In my C compiler
> >environment relative files are a pain as I have no idea where a certain
> >file lives on disk.
> In C 'include <file>' searches the files in a path, so that may be
> hard. If I had that problem, I would use locate, and in hard cases
> strace to find out which files are included. If you are using gcc,
> gcc -E -MD is supposed to produce a dependency file, which should
> contain file paths (probably relative to the working directory).
> - 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: https://forth-standard.org/
> EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

These might be interesting points.

But please explain to me, what this has to do with this thred:

AmForth ready for adoption

On Saturday, June 18, 2022 at 7:49:40 PM UTC+2, Anton Ertl wrote:
[..]
> >I definitely don't want that, but users have the source of proced
> >and can install that themselves with little effort.
> That's not quite the answer that the user of a commercial Forth wants
> to read (especially not without any pointer where to look).

I'm not aware of seeing any request for this feature in my mailbox,
but, given a non-customized iForth, type "EDIT proced" (the include
directory (home/dfwforth/include) is in the default searchpath
and your editor was asking to be configured the first time you started
iForth), then go to line 734:

: DO-KEY CASE
--> OF 1RIGHT ENDOF
<-- OF 1LEFT ENDOF
^--> OF WORDRIGHT ENDOF
^<-- OF WORDLEFT ENDOF
--^ OF up-arrow ENDOF
--v OF down-arrow ENDOF
PgUp OF SWITCHCASE ENDOF
^PgUp OF INITIALIZE ENDOF
^PgDn OF SEARCH&REPLACE ENDOF
^End OF -TAIL ENDOF
BS OF BACKSPACE ENDOF ( potential problem for Paste? )
ESC OF EMPTY ENDOF
Tab OF SEARCH&REPLACE ENDOF ( problem for Paste )

[ WINDOWS? LINUX? OR ]

[IF] PgDn OF COMPLETE-FNAME ENDOF
^V OF PASTE-CLIPBOARD ENDOF
[THEN]
Hme OF GOHOME ENDOF
End OF GOEND ENDOF
Del OF DELETE ENDOF
Ins OF INSERT-MODE ENDOF
F1 OF fkey1 ENDOF
F2 OF fkey2 ENDOF
F3 OF fkey3 ENDOF
F4 OF fkey4 ENDOF
F5 OF fkey5 ENDOF
F6 OF fkey6 ENDOF
F7 OF fkey7 ENDOF
F8 OF fkey8 ENDOF
F9 OF fkey9 ENDOF
F10 OF fkey10 ENDOF
F11 OF fkey11 ENDOF
F12 OF fkey12 ENDOF
DUP STUFF-CHAR
ENDCASE ; PRIVATE

I am confident you can find a suitable spot for " ^D OF BYE ENDOF ".

-marcel

On 6/17/22 23:49, dxforth wrote:
....
> Ray Duncan writes,
>
>> One of the reasons the surviving Forth vendors have concentrated
>> on embedded systems is that this is one of the few market niches
>> that has not been systematically destroyed by the FIG-public domain-
>> hacker cabal. Now that people like Ting are circulating atrocities
>> like EFORTH, even the embedded systems market is dying. This is not
>> a flame, it's just the sad truth.
>
>> It's certainly been clear to me from lurking in this newsgroup for
>> months that *this* sector of the Forth community, although it
>> prides itself on being a center of Forth expertise, has no clue
>> whatsoever as to what the Forth vendors (Forth Inc., LMI,
>> Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
>> or the capabilities of their systems. Thus, newcomers to Forth,
>> who come here for advice, are being steered to EFORTH, FPC, and
>> other undocumented unstable unsupported public domain Forth systems
>> as "solutions." No wonder Forth is in decline!

Do you have a link to the above newsgroup post? I was not aware that Ray
Duncan blamed the free Forths, and in such harsh terms, for the demise
of his Forth business. In any case, I think his venting of his business
frustration was misdirected.

--
Krishna Myneni

On 6/18/22 06:19, Marcel Hendrix wrote:
> On Saturday, June 18, 2022 at 12:13:28 PM UTC+2, none albert wrote:
> [..]
>> I can't believe that a couple of hundred euro's will stop
>> a business from using a commercial Forth. The they decide to
>> type in a FIG-Forth listing.
> [..]
> I can believe it. It is not the business that sees the need for a
> commercial Forth, it is some individual inside it. How would such
> an individual defend his desire to purchase a license, even if
> it is just a few hundred dollars?
>

I've worked in places where I requested and procured several commercial
Forth systems to use them or simply to try them out for possible use on
work-related projects. Perhaps it is more difficult in a small business,
but really should not be much problem in a medium or large enterprise.

--
KM