SRFI 176: Version flag Arthur A. Gleckler (07 Oct 2019 05:01 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 18:43 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 20:26 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 20:50 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 21:42 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 22:49 UTC)
Re: SRFI 176: Version flag Lassi Kortela (11 Oct 2019 23:40 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 03:40 UTC)
Re: SRFI 176: Version flag John Cowan (13 Oct 2019 04:23 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 04:53 UTC)
Re: SRFI 176: Version flag John Cowan (15 Oct 2019 12:20 UTC)
Storing manual pages and other data in executables Lassi Kortela (16 Oct 2019 20:39 UTC)
Re: Storing manual pages and other data in executables John Cowan (16 Oct 2019 21:36 UTC)
Re: SRFI 176: Version flag Shiro Kawai (13 Oct 2019 05:24 UTC)
Storing manual pages and other data in executables Lassi Kortela (14 Oct 2019 11:56 UTC)
Re: Storing manual pages and other data in executables John Cowan (14 Oct 2019 16:33 UTC)
Re: Storing manual pages and other data in executables Lassi Kortela (17 Oct 2019 17:06 UTC)
Gory details of parsing Lassi Kortela (07 Oct 2019 21:04 UTC)
Re: Gory details of parsing John Cowan (07 Oct 2019 23:05 UTC)
Re: Gory details of parsing Lassi Kortela (11 Oct 2019 23:50 UTC)
Re: Gory details of parsing John Cowan (15 Oct 2019 01:52 UTC)
Working out the platform and compiler info Lassi Kortela (14 Oct 2019 16:52 UTC)
Clarification of tuples Lassi Kortela (14 Oct 2019 17:09 UTC)
Re: Working out the platform and compiler info John Cowan (14 Oct 2019 18:07 UTC)

Working out the platform and compiler info Lassi Kortela 14 Oct 2019 16:52 UTC

> 1) Allow a running program to retrieve this same information as a Scheme
> object by calling a procedure, which allows the program to customize
> itself.

Implemented this as:

(import (srfi 176))
(version-alist) => returns the same alist as in the -V output

In light testing it seems convenient enough that nothing more complex is
probably needed.

> 7) Platform support is kind of a mess.  I'd get rid of plain "platform" and
> add "platform-userland".  The number of bits in a platform doesn't really
> tell you enough because different fundamental types can have different
> sizes: I'd go with platform-(memory-)model a la the features list: lp64,
> llp64, ilp32, etc.

> 8) For the sake of unambiguity, private properties should use / or
> something besides - to connect the name(space) with the property name:
> fantastic-scheme/POM.

Here's what I have so far:

$ upscheme -V
(command "upscheme")
(scheme-id upscheme)
(language scheme r7rs)
(features 64-bit little-endian r7rs)
(platform (kernel openbsd) (userland openbsd) (computer x86-64) (endian
little))
(c-type-bits (int 32) (long 64) (float 32) (double 64) (pointer 64)
(size_t 64) (value_t 64))
(c-compiler-version "GCC" "4.2.1 Compatible OpenBSD Clang 5.0.1
(tags/RELEASE_501/final)")
(c-compiler-command "clang")
(c-compiler-flags "-Wall -Werror -Wextra -O2 -D NDEBUG -D
USE_COMPUTED_GOTO -std=gnu99 -Wno-strict-aliasing")
(c-linker-flags "-lm")
(revision "unknown")
(build-date "2019-10-14")
(release "0.0.0")
(release-date "1970-01-01")
(upscheme/stable-specs)
(upscheme/unstable-spec "2019")

The platform 4-tuple is stolen from
<https://wiki.debian.org/Multiarch/Tuples> as faithfully as possible
(currently, not very). If you go to that page, they have done an
excellent job mapping loads of 4-tuples covering numerous platforms. We
should probably just adopt their approach.

So their 4-tuple is (kernel userland computer endian) as above.

The precise CPU/OS ID's are harder. We could start with the ones on that
page, and mapping BSD equivalents to them. That should cover a very
large part of the IDs people will run into in `uname` output and such.

Another indispensable survey site is <http://predef.sf.net/> which lists
tons of C preprocessor macros defined by compilers, CPUs, OSes, etc.

Comments on the above format? The most controversial thing is the added
nesting on the platform tuples and the c-type-bits.

For JVM Schemes like Kawa, there could probably be an equivalent
(java-type-bits ...). I don't know how stable the Java int, long etc.
sizes are.

Based on
<https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html>
you can switch "int" between signed and unsigned in some situations! In
C, the signedness of "char" is famously undefined; I don't know whether
that is useful information for Scheme. I can't think of any use for it.
"int" signedness may be more useful to know because it says something
about the value range it can store. "char" stores such small values that
nobody uses that type to get any kind of range. It's mainly a synonym
for "byte" and people ignore the signedness.