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).
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?
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).
- anton--
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?
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
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).
- anton
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 onlyAbsolute file names is a boon for simple Forth's.
works for absolute file names, and you wrote that that's the
intention.
- anton
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 50:07:45 |
Calls: | 6,711 |
Calls today: | 4 |
Files: | 12,243 |
Messages: | 5,354,920 |
Posted today: | 1 |