egallesio/stklos

STklos Scheme

stklos's Issues

Cannot find GTK+ library file "libgobject-2.0"

I can't install some packages on Debian Linux using stklos-pkg. I did this:

sudo stklos-pkg --install stklos-gtklos

and i get this error:

(cd stklos-gtk-base; stklos-compile -c -L .. -o ../stklos-gtk-base.ostk stklos-gtk-base.spi)
**** Error while executing file "/usr/local/bin/stklos-compile"
Where: in error
Reason: Cannot find GTK+ library file "libgobject-2.0"

• error
• find-gtk-library
• #[closure 55f84fdf7600]
• <<let/call>>
• compile
• #[closure 55f84fd4cac0]
• <<let/call>>
• include-file
• cdr
• compile-with-handler
• ...
  Set shell variable STKLOS_FRAMES to set visible frames
  EXIT
  Makefile:31: recipe for target 'stklos-gtk-base.ostk' failed
  make: *** [stklos-gtk-base.ostk] Error 70

Also for installing some other packages like:
$ stklos-pkg --install stklos-posix-1.00.2
$ stklos-pkg --install soundex-0.2.0

i have these problem:

make: *** No rule to make target 'stklos-posix-1.00.2/stklos-posix-1.00.2.spi', needed by 'stklos-posix-1.00.2.ostk'. Stop.

make: *** No rule to make target 'soundex-0.2.0/soundex-0.2.0.spi', needed by 'soundex-0.2.0.ostk'. Stop.

Docker containers

Re: commit b5c8b34

The Scheme containers project publishes stable and unstable ("latest" and "head") containers of STklos here: https://hub.docker.com/r/schemers/stklos/tags

Our Dockerfiles here: https://github.com/scheme-containers/stklos

Our containers are based on Debian Linux. I see that your etc/Docker/Dockerfile.latest is based on Alpine and the build instructions are nice and simple.

What are your wishes regarding the containers - would you like to merge our work somehow?

We have 45 Scheme implementations running in an identical manner at https://hub.docker.com/u/schemers. Our aim is to be comprehensive and offer a uniform interface to people using the containers so it is easy to try out different Scheme implementations, compare them, and run the same code in different ones.

PORTING-NOTES

It seems that PORTING-NOTES is also outdated...
Maybe it would be nice to re-check it?

I have two suggestions:

1. it runs on Banana Pi, and quite probably on the Raspberry Pi, running armbian.
2. it runs on OpenWRT (ARM and MIPS), and I have tested this on a few platforms.

I can open a pull request with that information, but if you are willing to revamp the file, maybe adding or removing fields in the entries, I can wait and make the pull request after that.

Un-hygienic macros problem

stklos> (define-macro m (lambda () form))
;; m
stklos> (m)
;; loops forever

If I don't use the identifier "form" in the macro, it works as expected.

This seems to be because of the way expanders are defined in the compiler:

(let ((...
       ...
      (expander `(lambda (form e) (apply ,proc (cdr form)))))

SRFI 115: Scheme Regular Expressions

https://srfi.schemers.org/srfi-115/srfi-115.html

How hard would this be to implement using PCRE?

Information on download page

Hi @egallesio !

On the download page, 1.31 is still listed as the latest version, although 1.40 is out. And the link to "source distribution" also points to 1.31.

One other thing: there are also two links, one to gitlab and one to github. Is one of those preferred? If so, maybe it would be nice to mention it there.

SRFI 180 (JSON)

Hi,
JSON is quite important these days, and SRF 180 has an example implementation. It would be nice to have it in STklos!
J.

[post-1.50] Split installation of non-essential modules / SRFIs

It would be nice if it was possible to do things like these:

make install-core
make install-modules srfi-13 srfi-151
make uninstall-modules srfi-35

so one could have a very small installation of STklos without effort.

This shouldn't be too hard to implement.

STklos does support parallel compilation! (But this is not documented)

I;m not sure where to document this, but STklos does support parallel compilation. I have been running make -j10 everytime I build STklos, and it never failed because of that.

I see that STklos uses the standard GNU autotools INSALL file; I'm not sure if it would be better to change it or to write different instructions.

syntax rules implementation issues

STklos introduces identical symbols in different phases of macro expansion using syntax rules:

(define-syntax f
  (syntax-rules (k)
    ((f) #f)
    ((f k) 'K)
    ((f k x ...) (a (f x ...)))))

Here's the STklos expansion:

stklos> (macro-expand* '(f k k k))
(a (a 'K))

some other implementations will return

(a.0 (a.1 'K))

I rewrote some macros for SRFI-156 and SRFI-41 using define-macro, but it feels like the wrong way to go... As far as I could see, SRFI-86 would also need some macro rewriting (and its implementation is quite large).

Compiling on Android (it almost works)

Hello.
Since I seem to like putting Scheme on all kinds of embedded devices, I tried compiling STklos on Android.
What follows is a draft of what could be a INSTALL-android.md file (but it doesn't work yet).

I'd like to start working on this, if there is interest.

Installing STklos on Android

Instead of cross-compiling, compile in Termux, which has all build tools available.
This means the following is needed:

• The user must have developer access and enable ADB debugging
• The Termux package must be installed on the device

The steps to install STklos are described below.

Install adb on the build machine

The compilation is done on a different machine, which we'll call the build machine.

apt install adb

You will need to enable debugging in the Android device.

Test with a USB cable or Wifi (if you enabled ADB debugging
via Wifi):

• adb devices should list your Android device (you will need to authorize the connection on the device screen)
• adb shell gives you a shell on the device.

Set sshd in Termux

Open Termux in the Android device and prepare it to accept
ssh connections:

pkg install openssh
mkdir .ssh
cat > .ssh/authorized_keys

Paste your public ssh key there.

Now fix the permissions on .ssh and .ssh/authorized_keys:

chmod 600 .ssh/authorized_keys
chmod 700 .ssh

Termux does not start anything automatically, so every time we connect,
we need to call sshd:

sshd

From the host:

ADB can forward the TCP port 8022 to the devices' 8022 port (which is where Termux's sshd listens by default):

adb forward tcp:8022 tcp:8022
ssh localhost -p 8022

And you should be in a Termux shell, via ADB.

Back to Tmux now

After ssh'ing into the device, install the build tools (This will install Perl and other large packages as dependencies!)
Termux does not have gcc, only clang.

pkg install libgc make clang git autoconf automake

Configure: we need STklos' own copy of PCRE; using the system version
doesn't seem to work, and not use threads, because clang doesn't seem to find pthread_cancel:

./configure --with-provided-regexp --threads=none
make

Problems

• In process.c, the macro NOFILES is used, but it is not recognized by the compiler (Clang 9).
  It seems to not be standard, and at least one header file mentions that "users should not use NOFILE". An alternative seems to be RLIMIT_NOFILE; changed this.

• Build doesn't finish, although the stklos binary is
  produced in src/:

Making all in pkgman
make[1]: Entering directory '/data/data/com.termux/files/home/STklos/pkgman'
../utils/tmpgenlex lang-bigloo.l lang-bigloo.inc lang-bigloo
**** Error while executing file "../utils/stklos-genlex"
	 Where: in open-output-file
	Reason: could not open file `"/tmp/stklos08849-00000"'

It semes that STklos has the temp dir hardcoded (?)
On Termux, the variable TMPDIR is this:

$ echo $TMPDIR
/data/data/com.termux/files/usr/tmp

• FFI tests fail:

$ cd tests
$ make test
...
==== Testing FFI  ...                                            **** Error while executing file "do-test.stk"
	 Where: in %make-ext-func
	Reason: cannot find symbol `rindex' in `'

  - %make-ext-func
  - #[closure 7c5c073a40]
  - %execute
  - #[closure 7c5bdb5700]
  - call-with-values
  - #[closure 7c5c105100]
  - try-load
  - %try-load
  - %load
  - load-tests
  - ...

But if the FFI tests are commented out, all other tests pass.

R7RS define-library support

I see you have quite a few R7RS features already. That's great! Do you plan to support (define-library ...) eventually? If so, I can volunteer to be a beta tester.

The de facto standard for R7RS libraries is to put the (define-library ...) form in foo.sld and the library implementation in foo.scm. The define-library contains (include "foo.scm") to load the implementation. cond-expand is also often used inside define-library but you have that already :)

Update needed to manual bibliography

Hello!
Just a few things I noticed in STklos bibliography in the manual:

• Chris Hanson -- The SOS Reference Manual, version 1.5 -- March, 1993. This points to http://groups.csail.mit.edu/mac/projects/scheme/documentation/sos.html which seems to be broken. It looks like MIT Scheme, for example, ships the SOS manual with MIT Scheme itself: https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-sos.pdf
• Gregor Kickzales -- Tiny-Clos -- December, 1992. Looks like this one is also broken (the web ser ver does not respond)
• R5RS is mentioned in the references, but not R7RS...

SRFI 193: Command lines

SRFI 193 is due to be finalized soon. Would you be interested in having it in STklos?

Can't cross-compile

Hello.
I am trying to cross-compile STKlos so it runs on a MIPS machine, running Linux (it's a wireless router, runs OpenWRT).

Compilation is done inside the OpenWRT buildroot, which does a lot of things automatically. i have set the configure step as this:

CONFIGURE_ARGS += --host=mipsel-openwrt-linux-musl --build=x86_64-unknown-linux-gnu --with-provided-bignum --with-provided-ffi --with-provided-regexp --with-provided-gc

define Build/Configure
        (cd $(PKG_BUILD_DIR) && ./configure $(CONFIGURE_ARGS))
endef

However, the configure arguments are ignored when the GC configure script runs.

*****
***** GC support
*****
checking for GC_malloc in -lgc... no
... Configuring libgc
configure: loading site script /home/jeronimo/pkg/openwrt-18.06.2/include/site/mipsel
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking GC version numbers... major=8 minor=0                 micro=4
checking for a BSD-compatible install... /usr/bin/install -c

The host and target systems should not be x86_64-unknown-linux-gnu, but mipsel-openwrt-linux-musl instead. The STKlos configure script itself got the right parameters.

I have tried forcing the script to run configure on the gc subdir first,

define Build/Configure
	(cd $(PKG_BUILD_DIR)/gc && ./configure $(CONFIGURE_ARGS) --with-libatomic-ops=none)
	(cd $(PKG_BUILD_DIR) && ./configure $(CONFIGURE_ARGS) --with-libatomic-ops=none)
endef

but then it will enter the gc directory, run configure properly, get out of it, and then run the STKlos configure, which will call the gc configure again -- this time without the correct options.

Maybe the configure script is not passing options to the other scripts (in gc, ffi, pcre, gmp directories)?

Makefile in lib/ uses ld instead of expanding the loader macro

After a while I tried again to compile STklos on OpenWRT, and it seems that the C part of SRFI-175 won't compile. This is because the compiler (CC) part of the Mkaefile is correct, but the linker (LD) is not:

.c.so :
         mips-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlink-mips16 -fmacro-prefix-map=/home/jeronimo/pkg/openwrt-19.07/build_di    r/target-mips_24kc_musl/STklos-4ab30686b5c6b634abb36eef3c53e90abfda2073=STklos-4ab30686b5c6b634abb36eef3c53e90abfda2073 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro  -fpic -nostdlib -I../src -I../gc/include -c  -o $*.o $*.c
         ld -shared -o  $*.so $*.o
         /bin/rm -f $*.o

If correctly expanded $CC fo mips-openwrt-..., but kept ld from the host machine. Of course, ld will complain that I am trying to mix two architectures!

This really should be no problem, since the linker is already used in the src directory for the core of STklos... Not sure why ld was used instead of $LD in lib/.

The .c.@SH_SUFFIX@ suffix in Makefile.am seems to be correct, but I am no autotools expert...

Segfault in print.c

I was experimenting with alexpander, the macro expander by Al Petrofsky, to see if it could be incorporated into STklos, and got a segfault.

stklos> (write-pretty-quotes #f)
stklos> (load "alexpander-experiment.scm")
stklos> null-store

works, but when write-pretty-quotes is the default #t#, STklos segfaults in print.c:

CFLAGS="-O0 -g" make

$ gdb stklos
(gdb) run -d
...
stklos> (load "alexpander-experiment.scm")
stklos> null-store
((quasiquote . #0=((syntax-rules () ((_ template) (let () (qq template () template)))) (#1=(qq . 38) (let . 29)))) (35 . _map_35) (34 . _list->vector_34) (33 . _vector_33) (32 . _list_32) (31 . _append_31) (30 . _cons_30) (36 . #0#) (38 (#(syntax-rules 10) (unquote unquote-splicing quasiquote) ((_ ,x () . #(tail 11)) (do-next x . #(tail 11))) ((_ (,@x . y) () . #(tail 11)) (qq y () make-splice x . #(tail 11))) ((_ `x depth . #(tail 11)) (qq x (depth) make-list 'quasiquote . #(tail 11))) ((_ ,x (depth) . #(tail 11)) (qq x depth make-list 'unquote . #(tail 11))) ((_ (,x . y) (depth) . #(tail 11)) (qq-nested-unquote (,x . y) (depth) . #(tail 11))) ((_ (,@x . y) (depth) . #(tail 11)) (qq-nested-unquote (,@x . y) (depth) . #(tail 11))) ((_ ,@x depth . #(tail 11)) (unquote-splicing-error ,@x . #(tail 11))) ((_ (x . y) depth . #(tail 11)) (qq x depth qq-cdr y depth make-pair . #(tail 11))) ((_ #((x y ...)) depth . #(tail 11)) (qq (x) depth qq-cdr #((y ...)) depth make-vector-splice . #(tail 11))) ((_ x depth . #(tail 11)) (do-next 'x . #(tail 11)))) (#2=(make-vector-splice . 47) #3=(make-pair . 44) #4=(qq-cdr . 41) #5=(unquote-splicing-error . 40) (qq-nested-unquote . 42) #6=
Thread 1 "stklos" received signal SIGSEGV, Segmentation fault.
0x00005555555908a7 in printlist_star (exp=0x7ffff3c9f5e0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:348
348	    if (s && !NULLP(CDR(exp)) && NULLP(CDR(CDR(exp)))) {
(gdb) where
#0  0x00005555555908a7 in printlist_star (exp=0x7ffff3c9f5e0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:348
#1  0x0000555555590caf in pass2 (exp=0x7ffff3c9f5e0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:427
#2  0x0000555555590853 in print_cycle (exp=0x7ffff3c9f5e0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:336
#3  0x0000555555590914 in printlist_star (exp=0x7ffff3ac3820, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:358
#4  0x0000555555590caf in pass2 (exp=0x7ffff3ac4f40, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:427
#5  0x0000555555590853 in print_cycle (exp=0x7ffff3ac4f40, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:336
#6  0x0000555555590914 in printlist_star (exp=0x7ffff3ac4e40, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:358
#7  0x0000555555590caf in pass2 (exp=0x7ffff3ac5fc0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:427
#8  0x0000555555590853 in print_cycle (exp=0x7ffff3ac5fc0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:336
#9  0x0000555555590914 in printlist_star (exp=0x7ffff3a8d0a0, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:358
#10 0x0000555555590caf in pass2 (exp=0x7ffff3c04f20, port=0x7ffff3fdfdc0, mode=1, c=0x7fffffffd150) at print.c:427
#11 0x0000555555590d62 in STk_print_star (exp=0x7ffff3c04f20, port=0x7ffff3fdfdc0, mode=1) at print.c:447
#12 0x000055555558db6c in STk_write_star (expr=0x7ffff3c04f20, port=0x7ffff3fdfdc0) at port.c:672
#13 0x00005555555a8782 in run_vm (vm=0x7ffff7f96f00) at vm.c:1798
...
(gdb) print exp
$2 = (SCM) 0x7ffff3c9f5e0
(gdb) print ((struct cons_obj*)exp)->car
$3 = (SCM) 0x7ffff3ed8940
(gdb) print ((struct cons_obj*)exp)->cdr
$4 = (SCM) 0x71
(gdb) print ((struct cons_obj*)exp)->header
$5 = {type = 0, cell_info = 0}

So, exp's CDR is 0x71, 1000111, which should be a smal constant, did I get it right?

But print.c is trying to access CDR(CDR(exp)), so this will of course not work.

By the way, the element it couldn't print was #6# below. Doesn't seem to be anything special in it...

#5=(unquote-splicing-error . 40) (qq-nested-unquote . 42) #6=(quote . 28) (make-list . 45) #7=(make-splice . 46) #1#

I'll attach alexpander-experiment.scm.

disassemble-expr does not disassemble if

Neither if nor cond...

stklos> (disassemble-expr '(if 1 2 3))
**** Error:
car: wrong type of argument `()'
	(type ",help" for more information)
stklos> (disassemble-expr '(cond (1 2) (else 3)))
**** Error:
car: wrong type of argument `()'
	(type ",help" for more information)

How to include a part of SLIB which is also a SRFI?

SRFI-95, for example, is part of SLIB, and STklos users do have access to SLIB.
But it would be nice to have SRFIs working in a uniform way, no? So the user could just (require "srfi-95")?

In this case, would it be OK to duplicate the code from SLIB?

I see one problem -- if SLIB is updated, then the code in STklos could lag behind.
If SLIB was hosted in a git server, STklos could have it as a git submodule, but... SLIB still uses cvs!

Build fails when not connected to a terminal

I'm trying to make a Docker container from the latest STklos release. make does not work if I have no terminal (i.e. running the Linux shell command tty says not a tty). docker build cannot provide a terminal, so would it be OK to change the build to work without one?

I tried running make as ptyrun make (the ptyrun command comes from the ptyget package and allocates a pseudo-tty) but that produces the following error:

Making all in utils
make[1]: Entering directory '/build/stklos/utils'
./tmpcomp stklos-compile.stk stklos-compile
#[condition &error-message 94734647094464]: bad string `#f'
**** FATAL ERROR: no handler present!
ABORT
make[1]: *** [Makefile:521: stklos-compile] Error 1
make[1]: Leaving directory '/build/stklos/utils'

In every configuration I tried, it's the stklos-compile command that fails.

duplicate parameter raises an uncatchable error?

Hi,

If I try to use the wrong number of parameters in a procedure call, STklos signals an error, which I can catch (this is useful in test procedures):

stklos> (with-handler (lambda (x) #f) (sqrt 1 2 3))
#f

But... Specifically for duplicate parameters, it won't be catchable:

stklos> (with-handler (lambda (x) #f) (lambda (x x) 1))
**** Error:
error: duplicate parameter x
	(type ",help" for more information)

Why? Is this intentional?

thread-sleep! complains about bad timeout

Hello,
I am using the master git branch, and for some reason thread-sleep! doesn't accept the usual arguments:

stklos> (require-extension (srfi 18))
stklos> (thread-sleep! 1)
**** Error:
%thread-sleep!: bad timeout `1580822074714986597/1000000000'
	(type ",help" for more information)
stklos> (thread-sleep! (seconds->time 1))
**** Error:
%thread-sleep!: bad timeout `1'
	(type ",help" for more information)

However, the alternative implementation contained in SRFI-18 works:

stklos> (define (sleep! timeout)
      (let ((m (make-mutex)))
        (mutex-lock! m #f #f)
        (mutex-lock! m timeout #f)))
;; sleep!
stklos> (sleep! 1)
#f

gtk-canvas installation

I was trying to install the gtk-canvas package, but stklos-pkg said I don't have goocanvas installed. However, I do...

What happens is that the configure.in in stklos-gtk-canvas searches for goocanvas, and in Debian pkg-config has it with the name goocanvas-2.0 (ouch!)

Is it possible to make the "goocanvas" text in configure.in configurable? Something like a variable GOOCANVAS_PKG, which is "goocanvas" by default, but can be overriden?

if pkg-config --exists $(GOOCANVAS_PKG) 2> /dev/null

Also - is the source of those packages (which are downloadable with stklos-pkg) available in a git repository somewhere?
Of course I can open the tarball that is downloaded, but it would be easier if I could track them from git (and send pull requests! :) :)

Mention IDEs in the documentation?

There is old Quack by Neil van Dyke, which still works fine, but it's not being updated... And there is Geiser, and it just got basic support for STklos (https://gitlab.com/emacs-geiser/stklos/)!

disassemble is not documented

I got used to disassembling code a lot when I programmed in Common Lisp (with SBCL).
I just found that STklos has a disassemble procedure! But it isn't mentioned in the manual...

Need an R7RS module system... :)

For example, SRFI-13shadoes some R7RS procedures. So, in the tests, when we (require "srfi-13"), those procedures are gone. but then STklos, without restarting, will go on and do other tests, and when it gets to R7RS tests, the string-map fails.

The workaround I found was to "put back" the original string-map after testing SRFI-13, but this could become hard to manage.

R7RS modules would help keeping everything more isolated.

How do I help with this?

Behavior of delay

Hello,

According to R7RS, delay is supposed to be used to implement lazy evaluation - but it doesn't say it "must not" evaluate its argument... In page 19, it is said that implementations may do "implicit forcing" when "the value of a promise is forced by procedures that operate only on arguments of a certain type, like cdr and *. However, procedure that operate uniformly on their arguments, like list, must not force them"

Then the example is given:

(+ (delay (* 3 7)) 13)   ==> unspecified
(car (list (delay (* 3 7)) 13)) ==>  a promise

In STklos,

stklos> (delay (+ 1 "a"))
#[promise 7f303a221f20]

stklos> (+ (delay (* 3 7)) 13)
**** Error:
+: `#[promise 7f984ec18920]' is a bad number
	(type ",help" for more information)

Ok, so far it seems fine. Now,

stklos> (delay (/ 1  0))
**** Error:
/: cannot make rational with null denominator
	(type ",help" for more information)

stklos> (car (list (delay (/ 1 0)) 2))
**** Error:
/: cannot make rational with null denominator
	(type ",help" for more information)

stklos> (car (list (delay (* 3 7)) 13))
#[promise 7f9852d644a0]

I suppose this is an optimization, that would use a constant where there was a (/ 1 0), right?
It seems to not be in line with the spec, because the expression substituted was inside a delay...

Or did I get something wrong?

(The same happens if I require SRFI-45 first)

This affects the implementation of SRFI-41.

How to implement modules that have several parts?

Is there a rpeferred way to implement modules, or SRFIs which are broken into different parts? For example, SRFI-41 has two parts, "primitive" and "derived". SRFI-159 has several submodules.

I thought that, for example, SRFI-41 could be implemented as two STklos modules, "streams-primitive" and "streams-deived", and then one third module "srfi-41" which requires the other two. Is this OK? (That would probably make it easier to implement it as R7RS modules when STklos gets the R7RS module system).
Or is some other way preferred?

SRFI-175 not listed in *all-features*

I don't understand.

stklos> (features)
(stklos STklos STklos-1.40 id-5b7feb4 almost-r7rs exact-complex ieee-float full-unicode utf-8 UTF-8 ratios unix little-endian srfi-0 srfi-1 lists srfi-2 and-let* srfi-4 hvectors srfi-6 srfi-7 program srfi-8 srfi-9 records srfi-10 srfi-11 srfi-13 strings srfi-14 charsets srfi-16 case-lambda srfi-17 srfi-18 srfi-22 srfi-23 error srfi-26 srfi-27 random srfi-28 srfi-30 srfi-31 srfi-34 srfi-35 srfi-36 conditions srfi-37 args-fold srfi-38 srfi-39 parameters srfi-45 srfi-48 srfi-51 rest-list srfi-54 formatting srfi-55 srfi-59 srfi-60 srfi-62 srfi-66 srfi-69 hash-tables srfi-70 srfi-74 srfi-87 srfi-88 srfi-89 srfi-96 srfi-98 srfi-100 srfi-111 boxes srfi-112 srfi-117 queues-as-lists srfi-129 titlecase srfi-141 integer-division srfi-145 srfi-151 bitwise-ops srfi-156 srfi-158 srfi-161 srfi-169 srfi-171 transducers srfi-173 hooks srfi-174 posix-timespecs srfi-176 srfi-180 JSON json srfi-190 generators)

But it is there:

stklos> (require "srfi-175")
"srfi-175"
stklos> ascii-string-ci<=?
#[primitive ascii-string-ci<=?]

And it is listed in *all-features*, in srfi-0.stk:

 ...
    ((srfi-173 hooks) "srfi-173")       ; Hooks
    ((srfi-174 posix-timespecs) "srfi-174")
                                        ; POSIX Timespecs
    ((srfi-175 ascii) "srfi-175")       ; ASCII character library
    srfi-176                            ; Version flag
    ;; srfi-177                         ; Portable keyword arguments (draft)
 ...

What could be happening?

I did make uninstall, make distclean, autoreconf, and installed again, just to be sure, but it doesn't seem to be listed...

SRFI-1 x STklos make-list behavior

Hello.
It seems that STklos make-list is not consistent with SRFI-1's make-list:

stklos> (make-list 3)
(#void #void #void)
stklos> (load "srfi-1")
stklos> (make-list 3)
(#f #f #f)
stklos>

Not a problem for most practical purposes. But... I have ported SRFI-51 to STklos (still did not make the pull request, but it's mostly ready) -- and then there is this problem:

• since SRFI-51 uses append-reverse, which is in SRFI-1, but not in plain STklos, I required "srfi-1" in SRFI-51;
• but when I run the tests, all SRFI-51 tests pass, but the R7RS tests fail:

==== Testing R7RS  ...                                           failed
Errors found in this section:
test make-list.1 on (make-list 3) expected (#void #void #void) but got (#f #f #f)

So... What would be the best thing to do?

• change STklos behavior, so (make-list k) returns (#f #f ... #f)
• change the R7RS tests
• avoid adding SRFI-51 for now

(R7RS) current-{output,input,error}-port should be parameter objects

Hello,

According to R7RS, current-output-port should be a parameter object, so this:

(define f (open-output-file "oo"))
(parameterize ((current-output-port f)) (display "hey"))
(close-output-port f)

should write "hey" to the file "oo". But STklos does not let me do that:

stklos> (define f (open-output-file "oo"))
;; f
stklos> (parameterize ((current-output-port f)) (display "hey"))
**** Error:
%parameter-dynenv-pop!: bad parameter `#[primitive current-output-port]'
	(type ",help" for more information)

I see that these are implemented as primitives in port.c.

Anyway -- the current STklos documentation on current-output-port says it returns the current output port, and doesn't mention parameterize, but it is listed with an argument "`obj'" in the documentation (but it will refuse taking an argument).

ANSI color codes - repeated escape sequences

Hi,

It looks like the ansi-color procedure produces repeated color escape codes, and this confuses at least one terminal emulator (terminology, the one which comes with Enlightenment).

(string->list (string-append (ansi-color  'normal "aaa" 'clear) (do-color (get-repl-color :prompt) "bbb" 'clear  (get-repl-color :input) " -")
))
(#\escape #\[ #\0 #\m #\a #\a #\a #\escape #\[ #\m #\escape #\[ #\1 #\; #\3 #\5 #\m #\b #\b #\b #\escape #\[ #\escape #\[ #\0 #\; #\1 #\m #\space #\-)

The opening of the color code right after "bbb" is repeated, \e[\e[.

A bach script with this single line,

echo -e "\e[m\e[1;35mHello\e[\e[0;1m!!!\e[0m"

for example, produces

Hello0;1m!!!

because the escape opening before "!!!" is repeated.

So, Terminology prints the prompt with the correct color, but also prints 0;1m between the prompt and the input. This also complicates readline, since the number of characters from cursor to the beginning of editable area is wrongly computed:

stklos>0;1m

As far as I could see, this happens when two adjacent color codes are passed to do-color.
For the prompt, I removed the 'clear between prompt and input, and it worked fine:

(define (make-prompt module)
  (let ((str1 (if (> repl-level 1) (format "[~A] " repl-level) ""))
        (str2 (format "~A>" (module-name module))))
    (repl-prompt (if (repl-prompt-use-color?)
                     (string-append
                        (do-color (get-repl-color :repl-level) str1 'clear)
                        (do-color (get-repl-color :prompt) str2 ;'clear   <== here, commented out
                                  (get-repl-color :input))
                        " ")
                     (string-append str1 str2 " ")))))

For the initial banner, I see that either adding an empty string,

      (display (do-color 'normal "" col1 "  \\    " col2 line1 'clear))

or not using the initial normal,

      (display (do-color 'normal "" col1 "  \\    " col2 line1 'clear))

also works. But these are workarounds...

I don;t know what the ANSI escape code spec says about those (and wether the fault is Stklos' or Terminology's), but it would be nice anyway to not output repeated or non-closed codes.

Where does the STklos name come from?

STklos is a continuation (no pun intended) of STk, and the STk name comes from Scheme and the Tk GUI toolkit. The STKlos name obviously derives from STk, but where does the los suffix come from?

Cannot install stklos-gtk-base

Hello,
I am running a Debian system, and tried to run the GTK example on the website.

$ stklos-pkg -s
Synchronizing server "main"
   "http://www.stklos.net/ScmPkg/main" ... done
Synchronizing server "stklos"
   "http://www.stklos.net/ScmPkg/stklos" ... done

Ok, so the repository is up to date. Now,

$ stklos-pkg --install stklos-gtk-base
(cd stklos-gtk-base; stklos-compile -c -L .. -o ../stklos-gtk-base.ostk stklos-gtk-base.spi)
**** Error while executing file "/usr/local/bin/stklos-compile"
	 Where: in error
	Reason: Cannot find GTK+ library file "libgobject-2.0"

  - error
  - find-gtk-library
  - #[closure 7fb90abb9380]
  - <<let/call>>
  - compile
  - #[closure 7fb90acc4880]
  - <<let/call>>
  - include-file
  - cdr
  - compile-with-handler
  - ...
Set shell variable STKLOS_FRAMES to set visible frames
EXIT
make: *** [Makefile:29: stklos-gtk-base.ostk] Error 70

That library is provided by Debian package libglib2.0-dev, which is installed, and the files are in place:

$ ll /usr/lib/x86_64-linux-gnu/|grep libgobject
-rw-r--r-- 1 root root    728178 May 29 16:24 libgobject-2.0.a
lrwxrwxrwx 1 root root        19 May 29 16:24 libgobject-2.0.so -> libgobject-2.0.so.0
lrwxrwxrwx 1 root root        26 May 29 16:24 libgobject-2.0.so.0 -> libgobject-2.0.so.0.6400.3
-rw-r--r-- 1 root root    383192 May 29 16:24 libgobject-2.0.so.0.6400.3

Is it a path issue? Do I need to tell stklos-pkg where to find the libraries?

stklos-compile cannot find module `stklos-compiler`

On a standard installation, I can use stklos-compile, which produces byte-compiled code perfectly.

But when I compile it, install on a temporary directory, then move the directorywith the full installation to another machine (a wireless router), then stklos works, but stklos-compiler does not.

On my desktop:

$ stklos-compile
Usage: stklos-compile [options] file
Compile a stklos file to byte codes

Input options
  --case-sensitive, -c                 Be case sensitive on symbols
Output options
  --output=<file>, -o <file>           Output compiled code in <file>
  --C-code, -C                         Produce C code
Compiling options
  --evaluate=<expr>, -e <expr>         Evaluate <expr> before compiling file
  --line-info, -l                      Insert line numbers in generated file
  --show-instructions, -S              Show instructions in generated file
Path options
  --prepend-load-path=<dir>, -L <dir>  Prepend <dir> to the loading path
  --append-load-path=<dir>             Append <dir> to the loading path
Misc. options
  --no-time                            Don't display compilation time
  --help, -h                           This help

On the other machine:

# stklos-compile
**** Error while executing file "/usr/bin/stklos-compile"
	 Where: in error
	Reason: module `stklos-compiler' does not exist

  - error
  - #[closure 77bec758]
  - try-load
  - %try-load
  - eval
EXIT

All files were put in their places, just as in a default installation (they were just installed in another machine, then copied). What are the steps stklos-compile would execute, and what could cause it to fail to find the stklos-compiler module?

Thanks a lot!

SUPPORTED-SRFIS

The file SUPPORTED-SRFIS seems to not have been modified in a long time.

Perhaps it would be nice to have a single source for the list of supported SRFIs? The webpage could perhaps point to an updated version of that file?

Unicode strings

Hello,

I was going to port SRFIs 129 and130, but their tests fail. It seems that string-length does not work for Unicode strings:

stklos>
(define ABC
                (list->string (map integer->char
                                   '(#x3b1 #x3b2 #x3b3))))

stklos> (string-length ABC)
6

(By the way, there is a srfi-130 branch in my copy of your repository on github)

Hash tables with equality predicate string-ci=? give wrong result

Something strange is happening with hash tables with equality predicates:

stklos> (define h (make-hash-table string-ci=?))
;; h
stklos> (hash-table-set! h "Aa" 10)
stklos> (hash-table-ref h "Aa")
10
stklos> (hash-table-ref h "aa")
10
stklos> (hash-table-ref h "AA")
**** Error:
hash-table-ref: entry not defined for key `"AA"' in table `#[hash-table 7faa9be531e0]'
	(type ",help" for more information)

Requiring SRFI-69 and repeating the above gives the same result.

Anyway, string-ci=? seems to be fine:

stklos> (string-ci=? "Aa" "AA")
#t

The problem would be in hash.c, I suppose?

Broken links in STklos website

In the Screeshots/GUI page, there is the sentence "This model is described in the JFP and ISOTAS papers."
Both links are broken.

raise-continuable does not raise an exception?

In STklos, raise-continuable doesn't seem to raise an exception:

stklos> (raise-continuable 'a)
a

This is relevant for SRFI-189 (which went final today) -- since STklos does not raise an exception, two of the tests fail.

Webpage: SRFI has wrong title

SRFI 45, "Primitives for Expressing Iterative Lazy Algorithms", is listed on the webpage as
"Optional positional and named parameters"

'ffi.h' file not found

I'm installing on macOS Mojave version 10.14.6, and when I try to make, I'm getting the following error:

ffi.c:31:12: fatal error: 'ffi.h' file not found
# include <ffi.h>

Text typed into REPL can be almost invisible

Are you hard-coding a blue or black color for text typed into the REPL when running stklos from a terminal? That color is almost invisible on the terminal emulators I use (in general, blue and black text colors are notorious for causing problems on many terminals).

All of the other text (prompt, errors, evaluation results) is clearly visible. The banner (the text with version and copyright at the start) is also quite easy to read.

STklos tests crash on some big-endian machines

This is a separate issue from #10 so I opened this new one.

I have ran the STklos tests on some machines:

machine		end	mem	stklos-compile	test results
qemu arm	L	256	fail		OK
qemu malta be	B	256	fail		segf call/cc
			128	fail		segf call/cc
qemu malta le	L	256	fail		OK
Archer c7v4	B	128+64	fail		segf call/cc
DIR-505		B	64	fail		segf call/cc,circular (*)
Asus RT-AC51U	L	64+32	fail		OK
			64	fail		OK
x86_64		L	huge	OK		OK

(*) I don't know why this one segfaults the circular structures test.
It is an old router, running with the root filesystem on a pendrive,
and low on memory. Maybe it had not enough memory to finish.

Memory is in Mb.
"malta" is emulated MIPS.
In the memory column, "128+64" means "128Mb RAM plus 64 swap-on-compressed-ram". Tested with different amounts of memory to see if it made a difference in the call/cc test
I wanted to test the qemu MIPS be version with 64Mb, but it's not enough for it to boot.

On little-endian machines, all runs well. On big-endian ones,

# stklos --no-init-file --utf8-encoding=yes -f do-test.stk
==== Testing Numbers  ...                                        passed
==== Testing Keywords  ...                                       passed
==== Testing call/cc & dynamic-wind  ...                         Segmentation fault

If I comment out the call/cc tests, the rest runs fine.

The test logs end like this:

==== Testing call/cc & dynamic-wind  ==================================
call/cc =========================================================
  testing foo.1 expects 1200 ==> OK.
  testing foo.1 expects 120 ==> OK.
  testing Al Petrofsky, 15 June 2002 expects 1 ==> OK.

So it seems that the test that failed is the one right after Al Petrofsky.

I have ran gdb, it seems to happen when cloning an environment:

# gdb stklos
...
(gdb) run --no-init-file --utf8-encoding=yes -f do-test.stk
Starting program: /usr/bin/stklos --no-init-file --utf8-encoding=yes -f do-test.stk
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
==== Testing Numbers  ...                                        passed
==== Testing Keywords  ...                                       passed
==== Testing call/cc & dynamic-wind  ...                         
Program received signal SIGSEGV, Segmentation fault.
0x00426c83 in clone_env (e=0x1b0004, vm=0x77da3f78) at vm.c:345
345	vm.c: No such file or directory.
(gdb) where
#0  0x00426c83 in clone_env (e=0x1b0004, vm=0x77da3f78) at vm.c:345
#1  0x00426d9b in patch_environment (vm=0x77da3f78) at vm.c:382
#2  STk_make_continuation () at vm.c:1967
#3  0x004294cd in run_vm (vm=vm@entry=0x77da3f78) at vm.c:1787
#4  0x004298f7 in STk_C_apply (func=func@entry=0x77c9d5f0, nargs=<optimized out>, nargs@entry=0) at vm.c:530
#5  0x00429941 in STk_call_with_values (prod=<optimized out>, con=0x77c9d528) at vm.c:649
#6  0x004295c7 in run_vm (vm=vm@entry=0x77da3f78) at vm.c:1823
#7  0x0042978f in STk_execute (code=<optimized out>, consts=<optimized out>, envt=0x77d98fa0) at vm.c:577
#8  0x00429535 in run_vm (vm=vm@entry=0x77da3f78) at vm.c:1820
#9  0x004298f7 in STk_C_apply (func=func@entry=0x77c9dca8, nargs=<optimized out>, nargs@entry=0) at vm.c:530
#10 0x00429941 in STk_call_with_values (prod=<optimized out>, con=0x77c9dc08) at vm.c:649
#11 0x004295c7 in run_vm (vm=vm@entry=0x77da3f78) at vm.c:1823
#12 0x004298f7 in STk_C_apply (func=<optimized out>, nargs=<optimized out>, nargs@entry=1) at vm.c:530
#13 0x00414587 in STk_load_source_file (f=f@entry=0x77d845a0) at fport.c:787
#14 0x004145cd in load_file (filename=filename@entry=0x77baef60) at fport.c:806
#15 0x00414639 in STk_scheme_try_load (filename=0x77baef60) at fport.c:853
#16 0x004294fd in run_vm (vm=vm@entry=0x77da3f78) at vm.c:1790
#17 0x00429cbd in STk_boot_from_C () at vm.c:2218
#18 0x0041065d in main (argc=<optimized out>, argv=<optimized out>) at stklos.c:213
warning: GDB can't find the start of the function at 0x77f70f2b.

    GDB is unable to find the start of the function at 0x77f70f2b
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x77f70f2b for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.

I see that in vm.c there are some uses of >> and & 0xff, in the definition of FIRST_BYTE and SECOND_BYTE, but those don't seem to make a difference (I suppose).

I also tried valgrind, but it didn't help:

valgrind  stklos --no-init-file --utf8-encoding=yes -f do-test.stk
==18334== Memcheck, a memory error detector
==18334== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18334== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==18334== Command: stklos --no-init-file --utf8-encoding=yes -f do-test.stk
==18334== 
==18334== Conditional jump or move depends on uninitialised value(s)
==18334==    at 0x4074504: ??? (in /lib/libc.so)
==18334==    by 0x408594C: ??? (in /lib/libc.so)
==18334== 
==18334== Conditional jump or move depends on uninitialised value(s)
==18334==    at 0x4073970: ??? (in /lib/libc.so)
==18334==    by 0x4073F38: ??? (in /lib/libc.so)
==18334== 
vex mips->IR: unhandled instruction bytes: 0x40 0x1A 0x0 0x5C

vex: priv/guest_mips_toIR.c:1304 (jmp_lit32): Assertion `dres->whatNext == Dis_Continue' failed.
vex storage: T total 34819232 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==18334==    at 0x5803DB88: ??? (in /usr/lib/valgrind/memcheck-mips32-linux)
==18334==    by 0x5803DB74: ??? (in /usr/lib/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 18334)
==18334==    at 0x410301: main (stklos.c:168)
client stack range: [0x7E87F000 0x7E87FFFF] client SP: 0x7E87FCA8
valgrind stack range: [0x426F8000 0x427F7FFF] top usage: 5552 of 1048576

Git information in -V output

Would there be simple way to add the Git properties from SRFI 176 into the -V output?

(build.git.tag string)
(build.git.branch string)
(build.git.commit string)
(build.git.modified string…​)

Tag: git describe --tags --abbrev=0 2>/dev/null || true
Branch: git rev-parse --abbrev-ref HEAD 2>/dev/null || true
Commit: git rev-parse --short HEAD 2>/dev/null || true
List of files with uncommitted changes:

printf '(build.git.modified';
git diff-index --name-only HEAD 2>/dev/null | head | xargs -n 1 printf ' "%s"';
echo ')'

Git information cannot be retrieved by the ./configure script, since all kinds of Git operations can be done between ./configure and make. The information would have to be computed by make somehow.

SRFI-13: string-prefix? and string-suffix? seems to always answer #f

Isn't this strange?

stklos> (require "srfi-13")
"srfi-13"
stklos> (string-prefix? "ab" "abc")
#f
stklos> (string-prefix? "abc" "ab")
#f
stklos> (string-prefix? "a" "ab")
#f
stklos> (string-prefix? "" "ab")
#f

stklos> (string-suffix? "" "ab")
#f
stklos> (string-suffix? "b" "ab")
#f

Small problems in the manual

These refer to the PDF manual, in doc/pdf

---

The example for vector-copy, on page 66, uses "string" when it should be "vector":

(vector-copy string start)
(vector-copy string start stop)

A leftover from copy/paste, I guess. :)

---

In the example for socket-accept, on page 128, the paragraph that starts with "The following example is a simple server" says the port used will be 12345, but the code uses port 13345.

---

Maybe it would also be nice to mention that the ports returned by the socket API are text ports, and not binary (of course the user can find out using a predicate, or deduce from the examples, but wouldn't it be better to be explicit?)

Small typo in documentation

In the manual and SUPPORTED-SRFIs, "Transducers" is missing the "a":

$ grep -r Trn *
doc/html/stklos-ref-14.html: <tr><td valign="top" align="left"></td><td colspan="4" width="100%"><a href="stklos-ref-14.html#SRFI-171----Trnsducers">SRFI-171 -- Trnsducers</td></tr>
doc/html/stklos-ref-14.html:<p>in your code or uses the <code>cond-expand</code> special form.</p></div></div><a name="--index-entry-51209"></a><div class="sectiondiv"><div class="sectiontitle"><a name="SRFI-171----Trnsducers"></a>
doc/html/stklos-ref-14.html:<h3 id="SRFI-171----Trnsducers">SRFI-171 -- Trnsducers</h3>
SUPPORTED-SRFIS:    - SRFI-171: Trnsducers

But I don't know how to fix it (I was hoping that the grep command above would show me where in the source it was typed wrong, so I could fix it, but it only detects SUPPORTED-SRFIS and stklos-ref-14.html.)

make sometimes does not rebuild the Scheme image

Continuing from #83:

Sometimes make builds a version of STklos using the old Scheme image even when changes have been made to the Scheme source code in lib. A manual workaround is touch lib/boot.stk; make but it would be great to find a way to automate this.

Question on optimizing code in SRFI reference implementations

Is it a goal?

For example, SRFI-133 (see pull request #73) recommends some optimization, but there are some Scheme implementations that do not do that (Chicken, for example - which is not a slow Scheme).

I was checking SRFI-132, Sort Libraries, and there is the same recommendation,

_You could speed up the vector code a lot by error-checking the procedure parameters and then shifting over to fixnum-specific arithmetic and dangerous vector-indexing and vector-setting primitives. The comments in the code indicate where the initial error checks would have to be added. There are several (quotient n 2) calls that could be changed to a fixnum right-shift, as well, in both the list and vector code. The code is designed to enable this — each file usually exports one or two "safe" procedures that end up calling an internal "dangerous" primitive. The little exported cover procedures are where you move the error checks.

This should provide big speedups. In fact, all the code bumming in the source pretty much disappears in the noise unless you have a good compiler and also can dump the vector-index checks and generic arithmetic — so it's really set up for optimization rather than fully optimized._

So, do I optimize when submitting? I'd then write some new procedures in C.