This page is part of the web mail archives of SRFI 112 from before July 7th, 2015. The new archives for SRFI 112 contain all messages, not just those from before July 7th, 2015.
I've failed to respond to this email in a timely manner, but for completness's sake I'm replying now, FYI. Quoting John Cowan <cowan@xxxxxxxxxxxxxxxx>: > > 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, >> etc. > > 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`. Ok, but then I would suggest you make it clear what exactly the function is supposed to return. E.g., in a C++ based implementation, "memory model" could be details about stuff like atomicity and such (the "C++11 memory model" is exactly about concurrency issues, not sizes of ints and longs). *I* was, at least, confused by the description. (I also admit that I am bike-shedding; this is by far one of the most straight-forward SRFIs :) >> 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. Fine, but please consider my above comments (if it's not too late). >> 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! I began to work on this but there is too much to categorize on and too inconsistent APIs on the various OSes and too hard to choose what would be fitting to include in the SRFI. >> 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. You are right. It's been *proposed* for a future standard, though, but that's not good enough for R7RS. >> 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 >> interested. > > Please do. Don't forget to take Windows into account. See my above comments. If anything wortwhile and cross-platform comes out of my tinkering with sysconf/proc-fs then I'll let the scheme community know. -- Christian Stigen Larsen