Note that where I say "it would be nice to add/change/whatever" something, if you agree I'll be happy to provide sample text.
Date: Friday, July 05, 2019 5:46 PM
Here are my initial comments using the above. In the Abstract:
The host environment is the set of resources, such as the filesystem, network and processes, that are managed by the operating system within which a Scheme program is executing.
I prefer "on top of" instead of "within which a Scheme program is executing". "on top" is also in the Rationale in this sense, and it avoids possible confusion with the use of "within" which immediately follows:
This SRFI specifies how the host environment can be accessed from within a Scheme program. It does so by leveraging widespread support for POSIX, the Portable Operating System Interface standardized by the IEEE.
Maybe work in the IEEE standard number 1003 in the above, or in the Rationale?
Not all the functions of this SRFI are available on all operating systems.
Maybe change to "Not all of the functions in this SRFI..." to flow better?
In the Rationale:
It is even possible to implement it in part on top of the JVM or CLR virtual machines.
A bit awkward, perhaps "It is even possible to partly implement it on top of the JVM or CLR virtual machines." And maybe "partly" is too weak for the kitchen sink JVM + JDK?
There is an updated version on Github, which has been patched to work with the latest (2006) version of Scheme 48.
The latest Scheme 48 is 1.9.2, released in April 2014
according to the home page. It's scsh that was last officially released in 2006, 0.6.7 according to
its home page, which is linked on the Scheme 48 home page.
https://github.com/scheme/scsh would appear to be the above mentioned patched version, 0.7. It appears to build without failure on x86-64 Ubuntu 18.04 TLS Bionic Beaver using that distribution's stock scheme48, but the "go" binary errors with the stock Ubuntu scheme48. Which appears to be 1.9 vs. the 1.9.2 for which the GitHub repository is patched; starting by building scheme48 1.9.2 from scratch works. In either case building scsh works with the following warnings:
gcc -g -O2 -fPIC -I/usr/local/include -rdynamic -shared -rdynamic -o c/syscalls.so c/syscalls.c -lutil
c/syscalls.c: In function ‘sleep_until’:
c/syscalls.c:711:18: warning: implicit declaration of function ‘time’; did you mean ‘utime’? [-Wimplicit-function-declaration]
time_t now = time(0);
^~~~
utime
gcc -g -O2 -fPIC -I/usr/local/include -rdynamic -shared -rdynamic -o c/tty.so c/tty.c -lutil
c/tty.c: In function ‘allocate_master’:
c/tty.c:398:14: warning: implicit declaration of function ‘openpty’; did you mean ‘openat’? [-Wimplicit-function-declaration]
rc = openpty (&master_fd, &slave_fd, NULL, NULL, NULL);
^~~~~~~
openat
And make test ends with:
Testing process-state:with-umask ... OK
#{Unspecific}
>
Note to people trying this out: be very sure to read the "Implementation" section at the bottom of this SRFI before e.g. trying to use open-directory which is open-directory-stream in scsh, which works just fine along with the read and close procedures....
(port-fdes port) → exact integer (procedure)
This procedure exposes the file descriptor of a port, effectively exporting it from the Scheme world. Alternatively, #f is returned if port does not have a file descriptor (a string port, e.g.),
The description sentence ends in a comma.
In 3.3 File System, at the beginning:
(create-directory fname [perms override?]) → undefined (procedure)
(create-fifo fname [perms override?]) → undefined (procedure)
(create-hard-link oldname newname [override?]) → undefined (procedure)
(create-symlink oldname newname [override?]) → undefined (procedure)
These procedures create objects of various kinds in the file system.
The override? argument controls the action if there is already an object in the file system with the new name. If it is #f, which is the default, then an error is signaled. If it is #t, the old object is deleted with R7RS-small delete-file or delete-directory as appropriate before creating the new object. The effect of passing any other value is implementation-dependent.
Should the type of *name be specified?
What is gained by allowing override? implementation options other than #t and #f to balance the loss in portability? Scsh has 'query to ask the user which sounds useful, but should a SRFI-170 implementation be required to signal an error if an option is not implemented?
Should the two immediately following sentences:
Perms defaults to #o777 (but is masked by the current umask).
If you try to create a hard or symbolic link and oldname and newname refer to the same file, it is an error (and your file may be destroyed).
be indented to match the two preceding paragraphs?
The caveat of umask masking is sufficiently major I don't think it should be parenthesized.
Should the type(s) of perms be specified, and while this increases implementation complexity, should the non-octal symbolic string variety be a required option?
While it's not hard to search for the details using "umask", a pointer or a bit of description of the octal version would be nice. That they are the same as
mode in the following
set-file-mode definition could be mentioned. Ditto defining the types of
mode, uid and gid for it and
set-file-owner and
set-file-group. Allowing, or requiring for portability, strings for symbolic changes for
set-file-mode in the fashion of chmod would be nice. OpenBSD's man page is much better than the Linux (Gnu?) one:
https://man.openbsd.org/chmod.1
In the description for (sync-file port) and (sync-file-system) you might parenthetically note how thoroughly modern systems and hardware lie, maybe add that researching an existing serious database like SQLite3 would be worthwhile. And/or change the language to weasel with something like "directs the (POSIX) system to". Or something like "... eventually, and maybe asynchronously with these calls".
- rdev, the device ID if the file is a character or block special
- blksize, the filesystem-specific preferred I/O block size
- blocks, the number of blocks allocated for the object
I would really like adding
blocks, which may be significantly less than indicated by size if the file has holes. It appears to usually be in 512B units, this appears to be the case for FreeBSD, Linux, and OpenBSD.
This implies it has visibility in the Windows Subsystem for Linux. (
set-port-position! (
lseek) from the above mentioned and linked in progress FilesAdvanceCowan allows Scheme to create and manipulate sparse files.)
The last sentence in the description of directory-files:
To use the files in returned list, the programmer can either manually prepend the directory, change to the directory before using the file names.
would read better as something like "To use the files in the returned list, the programmer can either manually prepend the directory, or change to the directory before using the file names."
The description inconsistently refers to the returned strings as "files" and "file names".
The description for open/read/close-directory should mention that like directory-files, it does not return "." or ".." (or at least scsh doesn't).
Why does temp-file-prefix return /var/tmp/pid if TMPDIR is not set in the environment? I can't think of any scenario where that would be preferred by default to the cleaned after every reboot, is more likely to be and should be stickied, optimized for true temp files /tmp/pid. This should also get around the issue of others having access to files created with create-temp-file, but the security note should remain if the user chooses to use a temp directory without the sticky bit set.
In the example code for temp-file-iterate, ".#temp." looks "magical" to my eyes, particularly the use of '#', it makes me wonder if this has meaning to temp-file-iterate, and I would expect this to be even more so to a non-Gnu Emacs user. Something like ".temp." would be better.
(real-path path) is also silent on what type path is.
- Harold