You can download the new version at the old place:

http://www.complang.tuwien.ac.at/forth/appbench.zip

Appbench is a set of Forth application benchmarks, in contrast to the
small benchmarks that are usually used for benchmarking Forth systems.

This is version 1.4 of the benchmark suite. The benchmarks are the
same. I have fixed a few bugs and portability problems, but nothing
that should have a significant influence on the execution time. I
have also tested the benchmarks on more recent systems, in particular
development Gforth, iforth-5.1-mini, and recent SwiftForth and VFX
versions.

Most of these applications (except cross and vmgen, which are not run
by default) should be portable between Forth systems, but a test with
Gforth (several versions), bigForth 2.3.1, iforth 2.1.2541, SwiftForth
i386-Linux 3.2.1 (sf), SP-Forth 4.20 Build 001 and vfxlin 4.40 [build
0404] showed the following systems to be working:

Most of these applications (except cross and vmgen, which are not run
by default) should be portable between Forth systems, but a test with
Gforth (several versions), bigForth 2.3.1, iforth 2.1.2541, SwiftForth
i386-Linux 3.2.1 (sf), SP-Forth 4.20 Build 001 and vfxlin 4.40 [build
0404], SwiftForth x64-Linux 4.0.0-RC87 (sf64) and VFX Forth 64 5.43
(vfx64) showed the following systems to be working:

Benchmark Systems
benchgc bigforth gforth iforth2 sf sf64 vfxlin
brainless bigforth gforth sf sf64 vfxlin vfx64
brew bigforth gforth*
cd16sim bigforth gforth iforth2 spf4 sf sf64 vfxlin vfx64
fcp bigforth gforth spf4 sf sf64 vfxlin vfx64
lexex bigforth gforth sf sf64 vfxlin vfx64

* gforth-7.9 occasionally stops after a part of brew (even with the
same parameters); I'll have to investigate this.

iForth-5.1-mini does not occur in the table, because not a single
benchmark runs on it, because this system does not support relative
file names, not even in the working-directory-relative way that other
commercial systems support (at least in my installation, and my
impression when I asked about that is that this is the way Marcel
Hendrix intends it to be).

Unfortunately, the support of these programs by commercial Forth
systems has not improved since appbench-1.2in 2010, even though they
have been available as a benchmark suite for 15 years. I guess that
paying customers will have to ask for appbench results before that
changes.

DOWNLOADING AND INSTALLING

You can download this package from
http://www.complang.tuwien.ac.at/forth/appbench.zip

Just unpack it anywhere, then cd into the appbench-1.4 directory, look
at the README and benchmark away.

- 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 2023: https://euro.theforth.net/2023

Anton Ertl wrote:
[..]
> iForth-5.1-mini does not occur in the table, because not a single
> benchmark runs on it, because this system does not support relative
> file names, not even in the working-directory-relative way that other
> commercial systems support (at least in my installation, and my
> impression when I asked about that is that this is the way Marcel
> Hendrix intends it to be).

Can you refresh my memory, and/or define "working-directory-relative"
file naming?

-marcel

mhx@iae.nl (mhx) writes:
>Anton Ertl wrote:
>[..]
>> iForth-5.1-mini does not occur in the table, because not a single
>> benchmark runs on it, because this system does not support relative
>> file names, not even in the working-directory-relative way that other
>> commercial systems support (at least in my installation, and my
>> impression when I asked about that is that this is the way Marcel
>> Hendrix intends it to be).
>
>Can you refresh my memory, and/or define "working-directory-relative"
>file naming?

A relative file name is not absolute, i.e., does not start with "/"
(or, on DOS-derived OSs, with stuff like "C:\").

What is it relative to? In some cases, it's relative to the working
directory (the thing you change with cd or chdir). However, this
means that when you INCLUDE/REQUIRE from within a file, you either
have to specify an absolute file name or your INCLUDE is only correct
if the working directory is in a specific directory; so for specifying
other source files from a source file, it's better to make relative
filenames mean relative to the (directory immediately containing) the
source file. Unfortunately, the Forth community could not agree even
on the most basic things about portable file names, such as directory
separators.

Anyway, some years ago I reported that iForth-5.1-mini INCLUDEing only
works for absolute file names, and you wrote that that's the
intention.

- 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 2023: https://euro.theforth.net/2023

In article <2024Apr20.170147@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>iForth-5.1-mini does not occur in the table, because not a single
>benchmark runs on it, because this system does not support relative
>file names, not even in the working-directory-relative way that other
>commercial systems support (at least in my installation, and my
>impression when I asked about that is that this is the way Marcel
>Hendrix intends it to be).

Are working directory relative file names mentionned in the standard?
Naive stand:
If you can type a file name from where you stand (working directory)
you can INCLUDE it.
If they are not, they must not appear in benchmarks.

This is what I mean:
A>
A>cat junk/hellow.frt
: hw "Goodbye, cruel world!" TYPE CR ;
A> lina
..
INCLUDE junk/hellow.frt
hw
"Goodbye, cruel world!"
OK
BYE
A>

If you start up a Forth by clicking on it in the file browser,
assuming this is a reasonable action, a section is to
be devoted in the documentation to explain what is supposed
to happen.

Groetjes Albert

>- anton
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

albert@spenarnc.xs4all.nl writes:
>In article <2024Apr20.170147@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>iForth-5.1-mini does not occur in the table, because not a single
>>benchmark runs on it, because this system does not support relative
>>file names, not even in the working-directory-relative way that other
>>commercial systems support (at least in my installation, and my
>>impression when I asked about that is that this is the way Marcel
>>Hendrix intends it to be).
>
>Are working directory relative file names mentionned in the standard?

Forth-94 and Forth-2012 do not give any guarantees with respect to
file names. I.e., a system is allowed to produce, e.g., an ior of -37
(File I/O exception) when you call OPEN-FILE with every name, and
produce an Error -37 on every INCLUDE. I wanted to change this, but
one person actively opposed my proposals. I tried to cut down my
proposal to a minimum (just defining directory separators and valid
file names), but the opposition was still there, while the support
that existed for my larger proposal evaporated.

So this is not about standards requirements, this is about whether a
system behaves in a useful way. Working-directory-relative filenames
are a low bar, and appbench has been designed to cope with Forth
systems that provide only that. In particular, the shell scripts for
running the benchmarks always "cd" into the directory of the
individual benchmark, because otherwise the INCLUDEs in the benchmarks
would fail on VFX, SwiftForth, and iforth-2.1.

But iForth-5.1-mini does not meet even this low bar:

[c8:~/nfstmp/gforth-amd64:103150] /bin/pwd
/nfs/nfstmp/anton/gforth-amd64
[c8:~/nfstmp/gforth-amd64:103151] ls -l siev.fs
-rw-r--r-- 1 anton 29015 572 Feb 13 2023 siev.fs
[c8:~/nfstmp/gforth-amd64:103152] iforth
AMD Ryzen 7 5800X 8-Core Processor x16 , TICKS-GET uses os time & PROCESSOR-CLOC
K 3000Mhz
Do: < n TO PROCESSOR-CLOCK RECALIBRATE>

FORTH> include siev.fs
No such file or directory `siev.fs'
Error -37
can't open ?

At least using an absolute file name works:

FORTH> include /nfs/nfstmp/anton/gforth-amd64/siev.fs ok

When I asked about that a while ago, IIRC the answer was that I should
always be using absolute file names in iForth. As a result, I don't
run any Forth programs consisting of more than one file on iForth (and
often not Forth programs consisting of one file; if it's more than I
usually cut and paste, iForth is too cumbersome).

- 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 2023: https://euro.theforth.net/2023

On 4/20/24 16:26, Anton Ertl wrote:
> mhx@iae.nl (mhx) writes:
>> Anton Ertl wrote:
>> [..]
>>> iForth-5.1-mini does not occur in the table, because not a single
>>> benchmark runs on it, because this system does not support relative
>>> file names, not even in the working-directory-relative way that other
>>> commercial systems support (at least in my installation, and my
>>> impression when I asked about that is that this is the way Marcel
>>> Hendrix intends it to be).
>>
>> Can you refresh my memory, and/or define "working-directory-relative"
>> file naming?
>
> A relative file name is not absolute, i.e., does not start with "/"
> (or, on DOS-derived OSs, with stuff like "C:\").
>
> What is it relative to? In some cases, it's relative to the working
> directory (the thing you change with cd or chdir). However, this
> means that when you INCLUDE/REQUIRE from within a file, you either
> have to specify an absolute file name or your INCLUDE is only correct
> if the working directory is in a specific directory; so for specifying
> other source files from a source file, it's better to make relative
> filenames mean relative to the (directory immediately containing) the
> source file. Unfortunately, the Forth community could not agree even
> on the most basic things about portable file names, such as directory
> separators.
>
> Anyway, some years ago I reported that iForth-5.1-mini INCLUDEing only
> works for absolute file names, and you wrote that that's the
> intention.
>
> - anton

In kForth, a filename parsed by INCLUDE or given to INCLUDED is always
treated a relative filename to the current working directory. If the
file is not found, then it is taken to be relative to a directory
specified by an environment variable, KFORTH_DIR.

$ echo $KFORTH_DIR
/home/krishna/kforth

As an example, the folder above contains

ans-words.4th
games/ ( subdirectory )
games/tscp.4th
games/chessboard.4th
games/tscp-tgfx.4th

The Forth program, tsc-tgfx.4th, which executes the following statements
looks for each file relative to the current directory, individually. If
each one is not found, it will include the one relative to KFORTH_DIR

include ans-words
include games/tscp
include games/chessboard

From any working directory, I can use a different chessboard by placing
a modified chessboard.4th in ./games/

and performing

include games/tscp-tgfx

which will include files in the following order.

$KFORTH_DIR/games/tscp-tgfx.4th
$KFORTH_DIR/ans-words.4th
$KFORTH_DIR/games/tscp.4th
../games/chessboard.4th

This assumes that the ./games/ directory in my working directory does
not contain tscp-tgfx.4th or tscp.4th.

--
Krishna

In article <2024Apr20.232643@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>mhx@iae.nl (mhx) writes:
>>Anton Ertl wrote:
>>[..]
>>> iForth-5.1-mini does not occur in the table, because not a single
>>> benchmark runs on it, because this system does not support relative
>>> file names, not even in the working-directory-relative way that other
>>> commercial systems support (at least in my installation, and my
>>> impression when I asked about that is that this is the way Marcel
>>> Hendrix intends it to be).
>>
>>Can you refresh my memory, and/or define "working-directory-relative"
>>file naming?
>
>A relative file name is not absolute, i.e., does not start with "/"
>(or, on DOS-derived OSs, with stuff like "C:\").
>
>What is it relative to? In some cases, it's relative to the working
>directory (the thing you change with cd or chdir). However, this
>means that when you INCLUDE/REQUIRE from within a file, you either
>have to specify an absolute file name or your INCLUDE is only correct
>if the working directory is in a specific directory; so for specifying
>other source files from a source file, it's better to make relative
>filenames mean relative to the (directory immediately containing) the
>source file. Unfortunately, the Forth community could not agree even
>on the most basic things about portable file names, such as directory
>separators.

The Forth community has no business with directory separators.
If I sit in a directory with a subdirectory junk containing hello.frt
I expect to do
INCLUDE junk/hello.frt
in linux and
INCLUDE junk\hello.frt
on ms-windows.
Who is the Forth community to force compatibility between Bill Gates
and Linus Torvalds?
How could possibly solve the problem with 8.3 filenames or case
insensitive filenames?

The solution for benchmarks is not to mess with directories.

>Anyway, some years ago I reported that iForth-5.1-mini INCLUDEing only
>works for absolute file names, and you wrote that that's the
>intention.
Absolute file names is a boon for simple Forth's.
If I install lina , at the same time I burn the absolute path
of the library file into it.

>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

In article <2024Apr21.130030@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
<SNIP>
>>Are working directory relative file names mentionned in the standard?
>
>Forth-94 and Forth-2012 do not give any guarantees with respect to
>file names. I.e., a system is allowed to produce, e.g., an ior of -37
>(File I/O exception) when you call OPEN-FILE with every name, and
>produce an Error -37 on every INCLUDE. I wanted to change this, but
>one person actively opposed my proposals. I tried to cut down my
>proposal to a minimum (just defining directory separators and valid
>file names), but the opposition was still there, while the support
>that existed for my larger proposal evaporated.
>
>So this is not about standards requirements, this is about whether a
>system behaves in a useful way. Working-directory-relative filenames
>are a low bar, and appbench has been designed to cope with Forth
>systems that provide only that. In particular, the shell scripts for
>running the benchmarks always "cd" into the directory of the
>individual benchmark, because otherwise the INCLUDEs in the benchmarks
>would fail on VFX, SwiftForth, and iforth-2.1.
>
>But iForth-5.1-mini does not meet even this low bar:
>
>[c8:~/nfstmp/gforth-amd64:103150] /bin/pwd
>/nfs/nfstmp/anton/gforth-amd64
>[c8:~/nfstmp/gforth-amd64:103151] ls -l siev.fs
>-rw-r--r-- 1 anton 29015 572 Feb 13 2023 siev.fs
>[c8:~/nfstmp/gforth-amd64:103152] iforth
>AMD Ryzen 7 5800X 8-Core Processor x16 , TICKS-GET uses os time & PROCESSOR-CLOC
>K 3000Mhz
> Do: < n TO PROCESSOR-CLOCK RECALIBRATE>
>
>FORTH> include siev.fs
>No such file or directory `siev.fs'
>Error -37
>can't open ?
>
>At least using an absolute file name works:
>
>FORTH> include /nfs/nfstmp/anton/gforth-amd64/siev.fs ok
>
>When I asked about that a while ago, IIRC the answer was that I should
>always be using absolute file names in iForth. As a result, I don't
>run any Forth programs consisting of more than one file on iForth (and
>often not Forth programs consisting of one file; if it's more than I
>usually cut and paste, iForth is too cumbersome).

That is astonishing.
My most simplistic OPEN-FILE works in the example you give.

>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Anton Ertl wrote:

> mhx@iae.nl (mhx) writes:
>>Anton Ertl wrote:
>>[..]
>>> iForth-5.1-mini does not occur in the table, because not a single
>>> benchmark runs on it, because this system does not support relative
>>> file names, not even in the working-directory-relative way that other
>>> commercial systems support (at least in my installation, and my
>>> impression when I asked about that is that this is the way Marcel
>>> Hendrix intends it to be).
>>
>>Can you refresh my memory, and/or define "working-directory-relative"
>>file naming?

> A relative file name is not absolute, i.e., does not start with "/"
> (or, on DOS-derived OSs, with stuff like "C:\").

> What is it relative to? In some cases, it's relative to the working
> directory (the thing you change with cd or chdir). However, this
> means that when you INCLUDE/REQUIRE from within a file, you either
> have to specify an absolute file name or your INCLUDE is only correct
> if the working directory is in a specific directory; so for specifying
> other source files from a source file, [***] it's better to make relative
> filenames mean relative to the (directory immediately containing) the
> source file. [***] Unfortunately, the Forth community could not agree even
> on the most basic things about portable file names, such as directory
> separators.

The option between [***]'s is NOT supported by the bare kernel. Its
added it with special words the last time you described the option (I
just now remembered). IOW, INCLUDE from within INCLUDE within ...
does not work with relative filenames as iForths reference is the
boot/launch directory.

However, a simple INCLUDE file or INCLUDE dir/dir/dir/file should
work just fine.

This must be a bug. The only one that comes to mind is that you opt
to not use the iforth.prf file. This would hamper the optimizer but
*should* have no effect on INCLUDE.

> Anyway, some years ago I reported that iForth-5.1-mini INCLUDEing only
> works for absolute file names, and you wrote that that's the
> intention.

That's amazing, given your definition of absolute filenames.

-marcel