rufig / spf

SP-Forth

Some useful links

• A set of documentaion files in /docs/, particularly:
  • readme.en.md - Overview
  • intro.en.md - SP-Forth specifics
• The documentation online at https://spf.sourceforge.net/
• Some additional hints in Wiki
• The sources in UTF-8 encoding in the repository spf4-utf8 (since some files in the spf repository are shown incorrectly via the GitHub online viewer)
• https://github.com/yarus23/SPF.JS

How to build from the sources

Clone the sources into your spf4 working tree root directory, as

git clone https://github.com/rufig/spf/ ~/spf4 && cd ~/spf4/src/

or download the ZIP archive and unpack it into your arbitrary spf4 working tree root forlder.

In Windows

Run src/compile.bat — it will build spf4.exe in the spf4 working tree root.

Prerequisites: powershell to download the initial binary.

In Linux

In the sub-directory src/ run make — it will build spf4 in the spf4 working tree root (near to the directorory src).

Prerequisites (in Debian or Ubuntu, as an example):

dpkg --add-architecture i386
apt update
apt install  coreutils ca-certificates git wget build-essential gcc-multilib

spf's Issues

Problem with "[COMPILE]" word

[COMPILE] EXIT works incorrectly. See also the comments at forth-standard.org.

A test case:

:NONAME ." TEST" [COMPILE] EXIT ."  FAILS, it should not be printed" ; CR EXECUTE CR

A possible solution: remove the obsolescent [COMPILE] word from the system at all.

Skip shebang

Skip shebang #! at the start of a source file (if any).

---

See also

• SkipBomUtf8 in src/compiler/spf_translate.f.
• The choice of Gforth.

non-uniform Russian encodings in the sourcefiles

The .f files and the .txt files don't have the same Russian encoding. Some of them use cp866, while others use windws-1251. I tried to convert them using iconv and it almost worked... unfortunately iconv deleted random parts of the code and even though it looked to me that it converted the files well to UTF-8 (I ran it manually on each on them, and specified the right encoding after I opened each of them inside a text editor to see what the right encoding is), the code was unfortunately broken.
The only reliable way would be to convert them manually (open in text editor, select the right encoding under which the Russian texts shows up correctly, copy the text, switch to UTF-8 encoding, paste the whole content, save ). I did that for a lot of files actually, but iconv broke the other part which was processed semi-automatically with iconv and some scripting, so I gave up.
Also there is at leaast 1 file which has two mixed encodings... the first half is cp866 and the second half is windows-1251.
So this is very troublesome because one can't read the commentaries in the sourcecode, one has to switch the encoding in the many times. It would be very good if you could convert them all to utf-8.

Added .S inside WM_CREATE crashes spf4wc

Steps to reproduce:
edit spf4wc.f

WM_CREATE :M { lpar wpar hwnd \ hdc -- 0 }
.S  \ insert this line

now executing the word CONSOLE or compiling spf4wc.exe and running it will make it crash...

0 TO H-STDOUT \ получает стандартные хэндлы
If I comment this line then I can see in the terminal that .S enters an infinite loop

Q1: I would like to know the reason why this is happening and how to avoid it. Sometimes I need to debug WM_CREATE ... messages so I need to print the stack to the terminal

Q2: is there any IRC channel dedicated to sp-forth ?

Makefile

Is there a Makefile for the linux version ?

on Linux HELP doesn't find any word definition/help description

On Linux there is a bug in the HELP system, it doesn't find the definition of any word
lib/ext/help.f
(I tried 4.20 and also 4.21 the latest version from sourceforge)
Type HELP for help
Ok
HELP HELP
В справке не найдено...
HELP +
В справке не найдено...

automated testing does not work

AppVeyor continuous integration service should be either properly configured or turned off for a while due to a permanent error:

The build phase is set to "MSBuild" mode (default), but no Visual Studio project or solution files were found in the root directory. If you are not building Visual Studio project switch build mode to "Script" and provide your custom build command.

mixed high and low caps filenames

The filenames are not uniform, some of them are in HIGH CAPS, while others are in low caps. On windows it doesn't matter very much but on Linux this could be problematic, so it would be good to convert all the filenames to low caps.
At the moment they're really mixed up for: some filenames are in lowcaps, some are in high caps, some are in both low and high, some only have the extension (.F ) in high caps

It looks very inconsistent that sp-forth is case sensitive by default, but when it comes to file names, it's insensitive.

S" string.f" INCLUDED
S" string.F" INCLUDED
S" STRING.f" INCLUDED

are all equally valid...

CRLF in UNIX-LINES mode

If CRLF-terminated lines are passed into the interpreter in UNIX-LINES mode, 0xD (CR) character becomes a part of the parse area at the end of the input buffer. So, the last lexeme in the input buffer can be terminated by this 0xD character. And in such case BL WORD counts this 0xD as a part of the lexeme. By comparison, PARSE-NAME treats 0xD as a delimiter.

This situation can arise in Windows console (or a CRLF-file) when you work with LF-lines in working directory and use UNIX-LINES mode for that.

Possible solution

Let WORD treat the control characters as delimiters in case of the given delimiter is BL — according to 3.4.1.1 Delimiters: "If the delimiter is the space character, hex 20 (BL), control characters may be treated as delimiters".

Running on Linux

First I want to thank you for this wonderful piece of work, sp-forth is a very nice forth, and it comes with so many win32 examples!
Secondly I would like to acknowledge you about a few issues which I think are easily fixable by the authors:
On Linux there is a bug in the HELP system, it doesn't find the definition of any word
lib/ext/help.f
(I tried 4.20 and also 4.21 the latest version from sourceforge)
Type HELP for help
Ok
HELP HELP
В справке не найдено...
HELP +
В справке не найдено...

The second issue is that spf4.ini should be tuned for both Linux and Windows (so it should use slashes instead of backslashes)

Now the biggest problem: the .f files and the .txt files don't have the same Russian encoding. Some of them use cp866, while others use windws-1251. I tried to convert them using iconv and it almost worked... unfortunately iconv deleted random parts of the code and even though it looked to me that it converted the files well to UTF-8 (I ran it manually on each on them, and specified the right encoding after I opened each of them inside a text editor to see what the right encoding is), the code was unfortunately broken.
The only reliable way would be to convert them manually (open in text editor, select the right encoding under which the Russian texts shows up correctly, copy the text, switch to UTF-8 encoding, paste the whole content, save ). I did that for a lot of files actually, but iconv broke the other part which was processed semi-automatically with iconv and some scripting, so I gave up.
There is at leaast 1 file which has two mixed encodings... the first half is cp866 and the second half is windows-1251

Another problem is that the filenames are not uniform, some of them are in HIGH CAPS, while others are in low caps.

I would have loved to fix these issues myself and send you a fixed packaged but I am new to spf and you can do it much better than I can. (I already tried)

Linux: corrupted build

After building, spf4 crashes with segfault
“./spf4” terminated by signal SIGSEGV (Address boundary error)

SAVE does not work in Linux

Please see below (the executable is generated, but throws segmentation fault) :

SP-FORTH - ANS FORTH 94 for Linux
Open source project at http://spf.sf.net
Russian FIG at http://www.forth.org.ru ; Started by A.Cherezov
Version 4.21 Build 001 at 10.Jan.2022

: a 2 2 + ;
 Ok
' a TO <MAIN>
 Ok
S" /tmp/f" SAVE 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC) 
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-m32' '-v' '-o' '/tmp/f' '-mtune=generic' '-march=x86-64' '-dumpdir' '/tmp/f.'
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/collect2 -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccqOLtlJ.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -o /tmp/f /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../.. /tmp/f.o /tmp/f.ld -ldl -lpthread -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib32/crtn.o
/usr/sbin/ld: warning: /tmp/f.ld contains output sections; did you forget -T?
COLLECT_GCC_OPTIONS='-m32' '-v' '-o' '/tmp/f' '-mtune=generic' '-march=x86-64' '-dumpdir' '/tmp/f.'
 Ok
BYE


$ /tmp/f                 
[1]    33944 segmentation fault (core dumped)  /tmp/f