I read the promotion of Docker. It tries to solve the problem:
"it works on my machine". Then it doesn't work on yours.

The correct solution - I think - is distributions. Debian goes to
great length to make sure that all programs cooperate.

Docker tries to pull in all possible influences in your machine
to generate a "package". Then it supposedly works.

Looking at a Forth compiler I see external influences:
- it works on a version of linux or windows. Those good folks
work hard that my program works the same on the next version.
- It observes a PATH : to find the program system wide.
Even this is not necessary, you can specify the full path.

What I do.
In ciforth there are no references to any configuration items,
not via environment variables, not via /etc files.
A library file is a necessity, but a reference to it is burned
into the executable during installation.

May one conclude that an elementary tool as a compiler, (and
say shells, utilities like dir etc.) should stay away from
this docker concept?

I see that there are several competing "package managers".
Instead of installing a program, you must start by
installing the behooved package manager before you can continue.
github invites you to select one of 6 possible packages:
Docker/ ApacheMaven / Nuget/Rubygems/npm/ Containers.

I fear for the future:
As the dust settles, and e.g. Nuget has won, you no longer
can run programs unless you pay monthly 10 euro's to Nuget
incorporated (student discounts possible.)

Ullrich Hofman has created a github archive of docker images
of forths, (including lina32 and lina64 for i86 linux. )

https://github.com/uho/docker-forth

What are the possibilities opened by this effort?

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 -

Some docker marketing bla bla:
Docker is an application encapsulation technology, as software containers,
to distribute without problems of dependencies or incompatibilities in
various operating systems (such as Windows or Linux) and local or cloud
environments such as Azure or AWS. Thus, the different files that make up
our applications and their dependencies… are transformed into a Docker
image, ready to be deployed on countless systems.
Additionally, the Docker package allows us to create, run and, if
necessary, update and stop the operation of the containers.

Next question:
Why on earth would one want such a fat encapsulated thing for tiny Forth?

In article <74df12da50f874560f03446c80983894@www.novabbs.com>,
minforth <minforth@gmx.net> wrote:
>Some docker marketing bla bla:
>Docker is an application encapsulation technology, as software containers,
>to distribute without problems of dependencies or incompatibilities in
>various operating systems (such as Windows or Linux) and local or cloud
>environments such as Azure or AWS. Thus, the different files that make up
>our applications and their dependencies… are transformed into a Docker
>image, ready to be deployed on countless systems.
>Additionally, the Docker package allows us to create, run and, if
>necessary, update and stop the operation of the containers.

I believe not a word. "countless systems" yeah right.

>
>Next question:
>Why on earth would one want such a fat encapsulated thing for tiny Forth?

That is the question I asked. Why would a well respected Forther
like Ullrich put effort in this?

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 -

albert@spenarnc.xs4all.nl wrote:

> I read the promotion of Docker. It tries to solve the problem:
> "it works on my machine". Then it doesn't work on yours.

> The correct solution - I think - is distributions. Debian goes to
> great length to make sure that all programs cooperate.

> Docker tries to pull in all possible influences in your machine
> to generate a "package". Then it supposedly works.

The package includes a complete Linux distribution at the machine
level and it all runs in a virtual machine. It's like one distributes
their software complete with a PC to run it on.

> Looking at a Forth compiler I see external influences:
> - it works on a version of linux or windows. Those good folks
> work hard that my program works the same on the next version.
> - It observes a PATH : to find the program system wide.
> Even this is not necessary, you can specify the full path.
[..]

It's like the precompiled libraries from FysForth: one is
constantly inspecting, debugging and modifying the library
sources, and recompiling stuff all of the time. After the
initial enthusiasm it became a nuisance for me.

> I see that there are several competing "package managers".
> Instead of installing a program, you must start by
> installing the behooved package manager before you can continue.
> github invites you to select one of 6 possible packages:
> Docker/ ApacheMaven / Nuget/Rubygems/npm/ Containers.

> I fear for the future:
> As the dust settles, and e.g. Nuget has won, you no longer
> can run programs unless you pay monthly 10 euro's to Nuget
> incorporated (student discounts possible.)

Those managers do lots of things that are useful for software
developers but not for users (even Forth users). Once the
VM is installed it just works like, e.g., WSL.

> Ullrich Hofman has created a github archive of docker images
> of forths, (including lina32 and lina64 for i86 linux. )

> https://github.com/uho/docker-forth

> What are the possibilities opened by this effort?

That approach allows casual users to quickly inspect all of
these Forth systems. If there (still) is a problem, it
should be trivial and can be 100% reproduced. Remove the
docker package and every trace of the Forth is gone.

What I found was that developers bound by corporate rules have
to make sure security patches are promptly applied to all
their software. So any change to the underlying Linux
distribution and any of the layered libraries has to be
applied, and then the whole system has to be unit tested
again and again.
I don't know if you realize how many, e.g. Python, libraries
there are, and how many versions of *their* libraries exist?

I have 13,388 Python related files on my Windows box,
and I don't even use Python! I'm sure that something
will break if I remove any of them.
When I recently wanted to try out something Python related,
I couldn't find out which executable I was actually running
(or was supposed to run). I was tempted to install a new
Python under my control, but even that is not safe because
the new one may inspect the system to graft upon it whatever
for its private reasons :--)

-marcel

minforth@gmx.net (minforth) writes:
>Why on earth would one want such a fat encapsulated thing for tiny Forth?

I recently tried to build kforth. There was some error in building it
(on Debian 11 on AMD64), so I gave up on that, and tried PFE instead.

PFE-0.33.71 built fine, but implements some perverse case
semi-sensitivity (without option for case insensitivity). Only 5 of
my 12 benchmarks run on it.

I also tried pfe-0.32.94, which according to the documentation
supports case insensitivity, but it fails to build:

In file included from ../../../pfe/core-sub.c:48:
.../../../pfe/../pfe/_missing.h:103:17: error: conflicting types for 'sys_errlis'
103 | extern char* sys_errlist [];
| ^~~~~~~~~~~
In file included from /usr/include/stdio.h:781,
from ../../../pfe/../pfe/def-types.h:23,
from ../../../pfe/../pfe/incl-ext.h:16,
from ../../../pfe/../pfe/pfe-base.h:19,
from ../../../pfe/core-sub.c:23:
/usr/include/x86_64-linux-gnu/bits/sys_errlist.h:27:26: note: previous declaration of 'sys_errlist' was here
27 | extern const char *const sys_errlist[];
| ^~~~~~~~~~~

You have to love C's "const" feature. So I went with pfe-0.33.71
after all.

So, it seems to me that one answer to your question is that Forth
implementors (not just those, but you asked about Forth) have problems
producing portable source code. Not sure if it's better with binary
code (at least the iforth, lxf, SwiftForth and VFX binaries work on
the platforms I use them on), but one way to avoid problems with
binary portability is to package the system in a container; don't
docker containers brodge the gap between Linux and Windows?

- 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

IOW, it's more the tool chains that cause problems. As a brute force
solution, Docker containers simply provide the entire software ecosystem.

IOW, if you want a fish, buy the whole aquarium.

On 3/05/2024 9:04 pm, albert@spenarnc.xs4all.nl wrote:
> In article <74df12da50f874560f03446c80983894@www.novabbs.com>,
> minforth <minforth@gmx.net> wrote:
>> Some docker marketing bla bla:
>> Docker is an application encapsulation technology, as software containers,
>> to distribute without problems of dependencies or incompatibilities in
>> various operating systems (such as Windows or Linux) and local or cloud
>> environments such as Azure or AWS. Thus, the different files that make up
>> our applications and their dependencies… are transformed into a Docker
>> image, ready to be deployed on countless systems.
>> Additionally, the Docker package allows us to create, run and, if
>> necessary, update and stop the operation of the containers.
>
> I believe not a word. "countless systems" yeah right.
>
>>
>> Next question:
>> Why on earth would one want such a fat encapsulated thing for tiny Forth?
>
> That is the question I asked. Why would a well respected Forther
> like Ullrich put effort in this?

Didn't know there was a 'respectable' pursuit of Forth. What could that
possibly be?

In article <6635a7f8@news.ausics.net>,

https://github.com/albertvanderhorst/ciforth

The Dockerfile should create the minimal image needed for the tooling to function correctly and speedily.
Bruce Axtens <snetxa@hotmail.com> wrote:
>Exercism.org makes extensive use of Docker as a means of making 70
>programming languages available to students. See down the bottom of
>https://exercism.org/dashboard for the full list of languages, and
>https://exercism.org/docs/building/tooling/docker for a discussion about
>their use of Docker.

A Forth enthusiast should add a docker entry for Forth.
Then I will be enclined to sign up for this side.

"
Each piece of tooling requires a Dockerfile, which specifies how the
machine is built. It should live at the root directory of your
repository and should be called Dockerfile.
"
Quite mysterious. I don't pretend to build a dockerfile.
On using it, where does the repository come from?

>
>-Bruce

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

Exercism.org makes extensive use of Docker as a means of making 70
programming languages available to students. See down the bottom of
https://exercism.org/dashboard for the full list of languages, and
https://exercism.org/docs/building/tooling/docker for a discussion about
their use of Docker.

-Bruce

In article <2024May3.162352@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>So, it seems to me that one answer to your question is that Forth
>implementors (not just those, but you asked about Forth) have problems
>producing portable source code. Not sure if it's better with binary
>code (at least the iforth, lxf, SwiftForth and VFX binaries work on
>the platforms I use them on), but one way to avoid problems with
>binary portability is to package the system in a container; don't
>docker containers brodge the gap between Linux and Windows?

What do you think about lina 5.5.0?
https://github.com/albertvanderhorst/ciforth

The binary provided only uses linux system calls, that should be
widely portable.
After unpacking you can run in the current directory,
provided . is in your PATH.
There are two assembler files for gas and for fasm.
There is not even a Makefile, instructions for compiling
are in the header. The two binaries are equivalent but
not identical.

This is how to build with gas
/tmp/ci86.lina64-9.9.9: as -64 ci86.lina64.s
/tmp/ci86.lina64-9.9.9: ld -melf_x86_64 -s -N a.out -o lina
And then fasm:
fasm ci86.lina.fas lina

>- 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 <2024May3.162352@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>So, it seems to me that one answer to your question is that Forth
>>implementors (not just those, but you asked about Forth) have problems
>>producing portable source code. Not sure if it's better with binary
>>code (at least the iforth, lxf, SwiftForth and VFX binaries work on
>>the platforms I use them on), but one way to avoid problems with
>>binary portability is to package the system in a container; don't
>>docker containers brodge the gap between Linux and Windows?
>
>What do you think about lina 5.5.0?
>https://github.com/albertvanderhorst/ciforth

So I performed

git clone https://github.com/albertvanderhorst/ciforth

>The binary provided only uses linux system calls, that should be
>widely portable.

There is no binary provided in that repo.

>After unpacking you can run in the current directory,
>provided . is in your PATH.
>There are two assembler files for gas and for fasm.
>There is not even a Makefile, instructions for compiling
>are in the header. The two binaries are equivalent but
>not identical.

I find a Makefile (called this way) as well as other makefiles, such
as lina64.mak.

Not sure what you mean by header. I find a number of README files
with a total size of 935 lines. A quick scan of README does not
reveal a way to build it. README.lina might be apropos for the Linux
version. It tells me to "tar xfz ci86.lina##-#.#.#.gz" but there is
no such file; and then it tells me that I can run lina## or lina, but
there are no such files there.

In other words: I did not find instructions on how to build lina in
the repo.

>This is how to build with gas
>/tmp/ci86.lina64-9.9.9: as -64 ci86.lina64.s
>/tmp/ci86.lina64-9.9.9: ld -melf_x86_64 -s -N a.out -o lina

[c8:~/nfstmp/ciforth:103723] as -64 ci86.lina64.s
Assembler messages:
Error: can't open ci86.lina64.s for reading: No such file or directory

I get the feeling that you left some essential part out in your
instructions.

- 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 <2024May5.173917@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
>>In article <2024May3.162352@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>So, it seems to me that one answer to your question is that Forth
>>>implementors (not just those, but you asked about Forth) have problems
>>>producing portable source code. Not sure if it's better with binary
>>>code (at least the iforth, lxf, SwiftForth and VFX binaries work on
>>>the platforms I use them on), but one way to avoid problems with
>>>binary portability is to package the system in a container; don't
>>>docker containers brodge the gap between Linux and Windows?
>>
>>What do you think about lina 5.5.0?
>>https://github.com/albertvanderhorst/ciforth
>
>So I performed
>
>git clone https://github.com/albertvanderhorst/ciforth
>
>>The binary provided only uses linux system calls, that should be
>>widely portable.
>
>There is no binary provided in that repo.

Normally the binaries are in the release, not in the source
repository. At the above site click on code. At the right side
you see "about" with miscellaneous information. Scroll down
and the releases appear ordered on most recent.

>
>>After unpacking you can run in the current directory,
>>provided . is in your PATH.
>>There are two assembler files for gas and for fasm.
>>There is not even a Makefile, instructions for compiling
>>are in the header. The two binaries are equivalent but
>>not identical.
>
>I find a Makefile (called this way) as well as other makefiles, such
>as lina64.mak.
>
>Not sure what you mean by header. I find a number of README files
>with a total size of 935 lines. A quick scan of README does not
>reveal a way to build it. README.lina might be apropos for the Linux
>version. It tells me to "tar xfz ci86.lina##-#.#.#.gz" but there is
>no such file; and then it tells me that I can run lina## or lina, but
>there are no such files there.
>
>In other words: I did not find instructions on how to build lina in
>the repo.
>
>>This is how to build with gas
>>/tmp/ci86.lina64-9.9.9: as -64 ci86.lina64.s
>>/tmp/ci86.lina64-9.9.9: ld -melf_x86_64 -s -N a.out -o lina
>
>[c8:~/nfstmp/ciforth:103723] as -64 ci86.lina64.s
>Assembler messages:
>Error: can't open ci86.lina64.s for reading: No such file or directory
>
>I get the feeling that you left some essential part out in your
>instructions.

Indeed, it was not an invitation to build, but to just download the release.
I invited you to download the latest release. 5.5.0

This is not a configure + make.

ciforth follows the fig-forth idea that you distribute an
assembler file and a documentation source file (texi).
The release contains the forth build from the assembler file and
documentation files, pertaining this Forth, for 4 different os's.

If you want to try on building the stuff yourself there is a
how_to_lina in the wiki.

The assembler files are not in the source repo, it is generated.
This git archive contains a factory that generates msdos images,
and booting images, dos protected mode images, besides
32 64 windows and linux, with the possibility to configure
the assembler used, separate text and data, stack sizes etc.
You are welcome to do that, but read the cifgen.ps documentation
to appreciate how involved that is.
You can build a msdos version from the current archive in principle,
but expect problems, that has not been done in ages.

P.S. The wiki files doesn't work, because the hcc (hosting the
Dutch chapter website) insisted to once again changing the url's.
Working on 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 -

albert@spenarnc.xs4all.nl writes:
>In article <2024May5.173917@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl writes:
>>>What do you think about lina 5.5.0?
>>>https://github.com/albertvanderhorst/ciforth
....
>Normally the binaries are in the release, not in the source
>repository. At the above site click on code. At the right side
>you see "about" with miscellaneous information. Scroll down
>and the releases appear ordered on most recent.

After switching to a browser with JavaScript, I found that apparently
you wanted me to download
<https://github.com/albertvanderhorst/ciforth/releases/download/CVS_REL-5-5-0/ci86.lina64-5.5.0.tar.gz>.
Not sure what's so hard about writing this directly.

>Indeed, it was not an invitation to build, but to just download the release.
>I invited you to download the latest release. 5.5.0

Ok, did so, unpacked it, and it runs.

Unfortunately, it is not usable for my purposes. Here's an example
session:

[c8:~/nfstmp/ci86.lina64-5.5.0:104037] ./lina64 -f '1 2 + . cr bye'
1 2 + . cr bye 3 1 2 + . cr ? ciforth ERROR # 12 : NOT RECOGNIZED

bye
bye ? ciforth ERROR # 12 : NOT RECOGNIZED
BYE

Ok, works, but is case sensitive by default. Apparently the -n flag
makes it more usable:

[c8:~/nfstmp/ci86.lina64-5.5.0:104038] ./lina64 -n
211( CASE-INSENSITIVE CASE-SENSITIVE ) \ AvdH B8feb7
210( C=-IGNORE CORA-IGNORE ~MATCH-IGNORE CI-DIGIT )\ AvdH C2jan17
... length greeting elided ...
autoload on, case insensitive
stack printing on, index lines printing on
bye

Now let's try the two together:

[c8:~/nfstmp/ci86.lina64-5.5.0:104039] ./lina64 -n -f '1 2 + . cr bye'
211( CASE-INSENSITIVE CASE-SENSITIVE ) \ AvdH B8feb7
210( C=-IGNORE CORA-IGNORE ~MATCH-IGNORE CI-DIGIT )\ AvdH C2jan17
... length greeting elided ...
autoload on, case insensitive
stack printing on, index lines printing on

No trace of the result of the -f '1 2 + . cr bye'. It seems that it
only processes one command-line option and then goes into interactive
mode. But I need at least -n and a -f option.

- 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