Dear AmForthers,details,
I am herewith stepping down from the maintainer role of AmForth. For
read on. If anyone is interested to take over, get in touch with me.
In 2020 I received the logins of amforth.sourceforge.net, basicallybecause I
was lucky enough to have met Matthias personally a few times. At thattime 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.of
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
things on my list by cancelling items. I have to accept the fact, thatI'm not
in a position any more to advance the AmForth project in a meaningfulway.
Secondly, AmForth has become complex over time. Matthias added supportfor
three more target platforms (msp430, arm, riscv32). Allthough access tothese
is easily achievable, I use only avr. And I use it less these days.I
Thirdly, AmForths tools are depending heavily on python code, a language
consider myself illiterate in. I have written a few small perl scriptsaround
AmForth to serve my needs. I heavily depend on those and on a Makefile.acquisition
Add the fact, that in 2020 I spent countless hours to port my data
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 sometime,
sometimes hours, sometimes several days. In other words: unusable.
Step back: what would I have done, if I didn't know Matthias, and theproject
would just have become silent? Simplify. Simplify heavily.happens to
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
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 atmega644pand
lots of fixes, which is nice! This removes the dependancy from wine andallows
for smaller systems for development.mentioned
So I have picked up my data acquisition project again with the fork
above. Any Interrupt Service Routines are written in assembly to avoidthe
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 laterreleases. 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 Iam
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 interestingexperience.
And should you still care to listen: if you have one or a few moreimportant
plans, do not delay them, you might be unable to pursue them later.
Happy hacking, and use the Forth!
Cheers
Erich
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. Fordetails,
read on. If anyone is interested to take over, get in touch with me.
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 numberof
things on my list by cancelling items. I have to accept the fact, thatI'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 languageI 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 dataacquisition
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 sometime,
sometimes hours, sometimes several days. In other words: unusable.
Step back: what would I have done, if I didn't know Matthias, and theproject
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 versionhappens 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 atmega644pand
lots of fixes, which is nice! This removes the dependancy from wine andallows
for smaller systems for development.
So I have picked up my data acquisition project again with the forkmentioned
above. Any Interrupt Service Routines are written in assembly to avoidthe
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 laterreleases. 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 Iam
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 interestingexperience.
And should you still care to listen: if you have one or a few moreimportant
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/
Is there any chance to modify the license type - or is the view this
is not necessary?
If yes - who could authorize this change?
Reply25m
Guy Proteus
Sadly that's the problem with these viral licenses. They're very difficult to unwind.
Reply25m"Humans have complicated every simple gift of the gods" - Diogenes
Guy Proteus
Sadly that's the problem with these viral licenses. They're very difficult to unwind.
On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
"Humans have complicated every simple gift of the gods" - Diogenes
Reply25m
Guy Proteus
Sadly that's the problem with these viral licenses. They're very difficult to unwind.
I just add this to your pile of useless bullshit contributions.
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 17/06/2022 16:07, Jurgen Pitaske wrote:
On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
"Humans have complicated every simple gift of the gods" - Diogenes
Reply25m
Guy Proteus
Sadly that's the problem with these viral licenses. They're very difficult to unwind.
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 17/06/2022 16:07, Jurgen Pitaske wrote:
On Friday, 17 June 2022 at 04:10:00 UTC+1, dxforth wrote:
"Humans have complicated every simple gift of the gods" - Diogenes
Reply25m
Guy Proteus
Sadly that's the problem with these viral licenses. They're very difficult to unwind.
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 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"
Ting did what he thought helps the Forth community.
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:
I wouldn't know what he thought besides which that's his business.
Ting did what he thought helps the Forth community.
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 theDuncan had the foresight to leave before he started typing in CAPS
belief that one’s work is terribly important"
shouting FORTH KILLER. We can only hope it'll be the same for us :)
On Saturday, 18 June 2022 at 07:48:15 UTC+1, dxforth wrote:
On 18/06/2022 16:09, Jurgen Pitaske wrote:
I wouldn't know what he thought besides which that's his business.
Ting did what he thought helps the Forth community.
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:
I wouldn't know what he thought besides which that's his business.
Ting did what he thought helps the Forth community.
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 theDuncan had the foresight to leave before he started typing in CAPS
belief that one’s work is terribly important"
shouting FORTH KILLER. We can only hope it'll be the same for us :)
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.
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!
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.
They're very difficult to unwind.
- anton
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.
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"
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.
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 toWell, if that's what irks you: Gforth is case-insensitive, up to 0.7
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).
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)
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,Gratis evaluation versions. Or do you have something else in mind?
eventually.
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.
Well, there is that slight problem when I need it to run on Windows,
isn't there?
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.
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.
I definitely don't want that, but users have the source of procedThat's not quite the answer that the user of a commercial Forth wants
and can install that themselves with little effort.
to read (especially not without any pointer where to look).
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,I don't think the situation has changed much in the last few years,
that I assumed Albert was presumably talking about, and tried
to point out how that has changed.
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,Not that I know of.
isn't there?
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 procedThat's not quite the answer that the user of a commercial Forth wants
and can install that themselves with little effort.
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 thatThe variation looks ok with my changes (IIRC without my changes it
in the past.
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 quickYes, that's horrible. I have the better experience in Linux. VFX5
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.
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 lookedOk, I thought that it was a result of my changes, and therefore did
at it in the past but I don't recall why I didn't implement it
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 haveIn C 'include <file>' searches the files in a path, so that may be
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.
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
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!
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.
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 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 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.
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.
Here are some that I irk me when dealing with iForth, lxf, sf, andciforth: check
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)ciforth: check
Pasting into the xterm does not work (lxf (not useful at all),ciforth: check
vfx (short pieces work))
No FP wordset on startup, requires arcane incantations (sf, vfx4 (fixed in vfx5))ciforth: WANT -fp-
Long and varying startup time (iForth)
I modified iForth and VFX to get rid of the screen-clearing and someI don't think relative file names is a good idea.
of iForth's startup time, but as a result iForth does not understand
relative file names.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
In article <2022Jun18.161502@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Here are some that I irk me when dealing with iForth, lxf, sf, andciforth: check
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)ciforth: check
Pasting into the xterm does not work (lxf (not useful at all),ciforth: check
vfx (short pieces work))
No FP wordset on startup, requires arcane incantations (sf, vfx4 (fixed in vfx5))ciforth: WANT -fp-
Inconvenient?
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.
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.
"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.)
"working directory" only makes sense with relative file names.
I have no idea what you mean with "project". Is this a Windows
concept?
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.
- anton--
"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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 48:26:40 |
| Calls: | 6,710 |
| Calls today: | 3 |
| Files: | 12,243 |
| Messages: | 5,354,640 |
| Posted today: | 1 |