anton@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++.

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?

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.

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.

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

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

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

albert@cherry.(none) (albert) writes:
>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, 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
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 18 Jun 2022 at 18:30:06 CEST, "Marcel Hendrix" <mhx@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, stephen@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

In article <2022Jun20.090804@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@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
--
"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 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