AmForth ready for adoption

[Bernd Paysan]

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/

[Clever Monkey]

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.

[Jurgen Pitaske]

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

[Paul Rubin]

Jurgen Pitaske <jpit...@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.

[dxforth]

>
> 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

[Jurgen Pitaske]

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

[dxforth]

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!

[Jurgen Pitaske]

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.

[Rick C]

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

[dxforth]

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"

[Jurgen Pitaske]

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

[dxforth]

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 :)

[Jurgen Pitaske]

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.

[Jurgen Pitaske]

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

[Anton Ertl]

dxforth <dxf...@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

[none albert]

In article <2022Jun1...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>dxforth <dxf...@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

[Marcel Hendrix]

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

[Andy Valencia]

dxforth <dxf...@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

[Anton Ertl]

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?

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.

[Marcel Hendrix]

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

[Anton Ertl]

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).

[Jurgen Pitaske]

These might be interesting points.

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

AmForth ready for adoption

[Marcel Hendrix]

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

[Krishna Myneni]

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

[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

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> 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.

The language where you'd expect non-free implementations to do the best
is probably Ada, because of its use in the cost-is-no-object aerospace
and related sectors. But, even today in 2022, there is only one
implementation of Ada 2012, which is Adacore/GNAT. It really does seem
to have crowded out the conventionally proprietary implementations.

Green Hills has a viable C compiler and maybe Ada 2005. I don't know if
they have anything like a modern C++.

[Paul Rubin]

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?

An individual (e.g. a hobbyist) can decide to spend a few hundred
dollars or not spend it, though that is a significant enough amount that
they might resist. They are more likely to spend $20 or $50, so Power C
and Turbo Pascal were very successful.

Someone working for a company is in a worse situation. To spend even 1
dollar, they have to get management approval, which means convincing
someone else to spend the 1 dollar and dealing with their objections.
The bureaucratic friction is a much bigger obstacle than the money, so
the 1 dollar license doesn't get requested. The person finds some other
way to solve the problem instead.

FOSS products took over the corporate world not because they were free,
but because engineers could use them without having to get them approved
by a bureaucracy. Proprietary products (compilers, anyway) ironically
may have had more acceptance by individuals.

[dxforth]

On 18/06/2022 20:13, albert wrote:
> ...

> 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?

GPL? AFAIK I'm independent but should someone wish to fund me...

> 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.

Unless a business is flushed with other people's money, who better
to make a sound economic judgment? It's not just about the quality
of the product, but whether one can make effective use of it. Who
hasn't bought stuff based on their imagination of how they'd use it
only to have it languish in a cupboard. Advertisers know us better
than we do. It's their job.

[dxforth]

On 19/06/2022 07:31, Krishna Myneni wrote:
> 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?

ftp://ftp.taygeta.com/pub/Forth/Archive/news

> 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.

At the very least a misunderstand what of drew many to Forth. What is
Forth without hackers? It seems to have been brewing for some time...

( Forth->Asm->Forth Ray Duncan 11:32 11/01/85 )
( This code good for LMI 8086 FORTH models only. )
( We don't know, and don't care, if it works on Laxen/Perry )

: >CODE HERE 2+ , HERE 2+ ,
STATE OFF R> DROP
[COMPILE] ASSEMBLER ; IMMEDIATE

: CODE> ?EXEC ASSEMBLER
SI, # HERE 6 + MOV NEXT-LINK JMP
[COMPILE] FORTH
COMPILER ; IMMEDIATE

[none albert]

In article <2022Jun1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

>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)

ciforth: check

>Ctrl-D at the start of the line does not do BYE (iforth, lxf, vfx)

ciforth: check

>Pasting into the xterm does not work (lxf (not useful at all),
> vfx (short pieces work))

ciforth: check

>No FP wordset on startup, requires arcane incantations (sf, vfx4 (fixed in vfx5))

ciforth: WANT -fp-
Inconvenient?
You can do
WANT -fp- SAVE-SYSTEM
"ciforth-fp" SAVE-SYSTEM
once and for all.

>Long and varying startup time (iForth)

If you want a command history:
alias lina-'rlwrap lina'

>
>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 don't think relative file names is a good idea.
I prefer the concept of "working directory" over "project" that is
not well explained and application dependant.
Note that ciforth will not a plethora of small files that contribute
library code to an application. They are nicely tucked away in a
block file.

<SNIP.

>
>- anton
>--
>M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

[Anton Ertl]

albert@cherry.(none) (albert) writes:
>In article <2022Jun1...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>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)
>ciforth: check
>>Ctrl-D at the start of the line does not do BYE (iforth, lxf, vfx)
>ciforth: check
>>Pasting into the xterm does not work (lxf (not useful at all),
>> vfx (short pieces work))
>ciforth: check
>>No FP wordset on startup, requires arcane incantations (sf, vfx4 (fixed in vfx5))
>ciforth: WANT -fp-
>Inconvenient?

Less convenient than having it present from the start, but easier to
remember than what you have to do in sf and vfx4.

>I don't think relative file names is a good idea.
>I prefer the concept of "working directory" over "project" that is
>not well explained and application dependant.

"working directory" only makes sense with relative file names.

I have no idea what you mean with "project". Is this a Windows
concept?

The problem with absolute file names is that the source code for all
the INCLUDEs, REQUIREs etc. in the source files have to be changed
when unpacking a Forth application consisting of multiple source files
in a different place. And I have to do it for every update of the
application.

The problem with working-directory-relative file names is that such an
application works only for one specific setting of the working
directory.

That's why every competent language implementation (e.g., gcc)
interprets relative file names as relative to the directory of the
including file (for 'include "file"' in case of gcc), which has
neither of these problems.

>Note that ciforth will not a plethora of small files that contribute
>library code to an application. They are nicely tucked away in a
>block file.

This does not help at all when one wants to load a Forth application
consisting of several source files.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

[Stephen Pelc]

On 18 Jun 2022 at 18:30:06 CEST, "Marcel Hendrix" <m...@iae.nl> wrote:

> 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.

VFX 5 (32 bit and 64 bit) hasn't done that fhor some years, and that was only
on the Windows version

>
> "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.)

A good justification for the use of SUBSTITUTE and text macros in file
names.

Stephen

--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[none albert]

In article <2022Jun2...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
<SNIP>

>"working directory" only makes sense with relative file names.
>
>I have no idea what you mean with "project". Is this a Windows
>concept?

I also have no idea what a project are supposed to mean, it is to much
honour to call it a concept.
But for most gui application (see the Slicer of Prusa, or Visual Code
shit or a circuit board drawing program) you have to define a "project"
or else you can't continue.

>
>
>That's why every competent language implementation (e.g., gcc)

Let's concede that you "competent" reflects your opinion.

>interprets relative file names as relative to the directory of the
>including file (for 'include "file"' in case of gcc), which has
>neither of these problems.
>
>>Note that ciforth will not a plethora of small files that contribute
>>library code to an application. They are nicely tucked away in a
>>block file.
>
>This does not help at all when one wants to load a Forth application
>consisting of several source files.

I interpret an application to mean, that you are going to run it several times.
I presume that as several users wants to run the same Forth application
that leads to a great hassle if done in this way.
A ciforth application is build once in this situation, and then
installed possibly system wide.

>
>- anton

[Gerry Jackson]

On 20/06/2022 08:08, Anton Ertl wrote:
> "working directory" only makes sense with relative file names.
>
> I have no idea what you mean with "project". Is this a Windows
> concept?
>
> The problem with absolute file names is that the source code for all
> the INCLUDEs, REQUIREs etc. in the source files have to be changed
> when unpacking a Forth application consisting of multiple source files
> in a different place. And I have to do it for every update of the
> application.
>
> The problem with working-directory-relative file names is that such an
> application works only for one specific setting of the working
> directory.

As I test my software on several systems I gave up long ago on the way
different systems handled directory structures and wrote a small program
that generated absolute paths to included files. This uses:
- a base directory (the project directory)
- a list of possible paths to the file

It appends a base relative path and filename to the base directory and
tries to open it. If it fails move on to the next relative path until
one succeeds.

--
Gerry