[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (c-memory-model) and more
Christian Stigen Larsen scripsit:
> I think you should add example return values for the (c-memory-model)
> procedure. The ones in R7RS, appendix B, should do: ilp32, lp64, ilp64,
Remember that this is primarily a reporting/logging API, so there's no
reason to standardize what it outputs. If you want to conditionalize your
code on the C memory model, you should be using `cond-expand`.
> Not a big deal, but is "memory model" the correct term to use? It looks
> like the terms (64-bit) "data model" and "programming model" are more common
> and give better web searches.
All these terms are heavily overloaded.
> I would also like to know what you think about more types of queries. Why
> not include some single-valued stuff from the sysconf, sysctl, /proc and
> /sys facilities on Linux/BSD systems?
Well, sysconf is a Posix standard, and I'll look at that. But there is
nothing standardized about /proc or /sys (sysctl just retrieves stuff in
the /proc/sys directory) and there are literally thousands of entries.
On my 32-bit Linux system, /proc and /sys, even excluding the transient
/proc/<pid> and /proc/self subtrees, have almost 4500 files. This is the
large language, but not the enormous language!
> E.g., on a multi-threaded implementation I'd like to know how many CPU cores
> I've got to distribute my workload on.
Alas, that does not seem to be a standardized sysconf variable.
> There are many things that would be great to know that are quite trivial to
> get on most systems. I could make a list of suggestions, if anyone are
Please do. Don't forget to take Windows into account.
> I've implemented SRFI-112 in Mickey:
All Gaul is divided into three parts: the part John Cowan
that cooks with lard and goose fat, the part http://ccil.org/~cowan
that cooks with olive oil, and the part that cowan@xxxxxxxx
cooks with butter. --David Chessler