Is there a good cross-platform method for determining the number of processors a machine has in elisp? I'm trying to make my config auto detect some build options, and would like to have it automatically use the number of processors + 1. Grepping /proc/cpuinfo isn't a solution for me because it won't work on Windows.
Emacs 24.3 Lisp doesn't have access to that information. Your options would seem to include:
writing an Elisp library which uses the value of SYSTEM-TYPE to choose a system-specific method for getting the processor count;
modifying the Emacs C source and rebuilding it so that it can, for each potentially multiprocessor platform on which Emacs builds, expose the processor count at the Lisp level.
At least, that was true four hours ago, when I first started writing this answer. But then I got interested in the problem, and now you have a third option:
downloading my system-cores.el library, which implements the first of the two options above, and calling (system-cores :physical) to get the number of physical processors, (system-cores :logical) to get the number of logical cores, or just plain (system-cores) to get an alist containing both.
Caveats include:
This library relies strongly on the PROCESS-LINES function. If that function can't do anything sensible in the context where you need to call SYSTEM-CORES, then SYSTEM-CORES can't either. (For example, if you're on Darwin and (getenv "PATH") doesn't contain /usr/sbin, PROCESS-LINES will bomb out with "Searching for program: no such file or directory, system_profiler".)
The systems currently known to be supported are GNU/Linux (anything with /proc/cpuinfo, more or less), Windows NT (and its derivatives, including 2000, XP, and all subsequent versions), and Darwin (OS X, at least 10.8, theoretically as far back as 10.2). Not coincidentally, these are also the systems to which I have access.
I've also included a delegate which should work properly on at least some flavors of BSD, but I don't have a BSD box on which to test it, so there's no telling whether or not it'll really work -- at the very least, you'll almost certainly need to modify the list of sysctls examined by the SYSTEM-CORES-SYSCTL delegate.
If you're using a modern variety of Linux, Windows, or OS X, great! You should be good to go, right out of the box. If not, and if your platform includes a command-line utility which provides the requisite information in its results, then it shouldn't be hard to write a delegate for your system. Or, if you don't want to write a delegate yourself, then email me all of:
the proper invocation for the command-line utility in question
a sample of the output it produces on your system
the output of M-: system-type in Emacs
the output of M-: system-configuration in Emacs
and I'll be able to write a delegate myself and add it to the library.
Edit: The :cores and :processors keywords have been replaced with :physical and :logical, respectively; I couldn't keep them straight, and I don't see why I should expect anyone else to, either.
Edit: Per #lunaryorn, replaced (split-string (shell-command-to-string ...)) with (process-lines ...). This saves invoking a shell, which might make the library more reliable, and certainly makes its code easier to read.
Related
I work on computational music. I have found the ps13 pitch spelling algorithm implemented in Lisp in 2003, precisely "Digitool MCL 4.3". I would like to run this code, preferably on a Linux x86 machine, to compare its results with other similar codes.
I am new to Lisp, but so far my research led me to think that Digitool MCL is no longer available. I thought of two ways which may help me:
a virtual environment (Docker or else) which would emulate a machine from 2003…
a code translation tool which would transform the 2003 source code into something executable today
I have not succeeded in finding one of these two options, nor running it directly with sbcl (but, as a newbie, I may have missed a small modification to make it run easily).
May someone help me?
Summary
This code is very close to being portable CL: you won't need something emulating an antique Mac to run it. I ran it on three implementations (SBCL, LispWorks, CCL) within a few minutes. However if you're not a Lisp person (and don't want to become one) it will be somewhat more fiddly to do that.
However I can't just send you a fixed version, both because this isn't the right forum for that, and also because we'd need to get the author's permission to do so. I have asked him if he would be interested in a portabalised version, and if he is, I will send him one in due course. You could also get in touch and ask to be notified.
(Meta-summary: while I think the question is fine, any reasonable answer probably doesn't fit on SO.)
Details
One initial problem with this code is that the file uses old Mac line end conventions (I think: not Unix anyway): unless whatever Lisp you're using is smart enough to spot this (some are, SBCL seems not to be although I am sure there are options to tell it) you'll need to convert it.
Given that, the code that implements this algorithm is very, very close to being portable Common Lisp. It has four dependencies on non-standard things:
two global variables, *save-local-symbols* and *verbose-eval-selection*;
two functions: choose-file-dialog and choose-directory-dialog.
The global variables can probably be safely commented out as I think they are just controls for the compiler, probably. The functions have fairly obvious specifications: they're obviously meant to pop up file / directory choosers.
However you can just not use the bits of the code that use these functions, so you can compile it, get a few compiler warnings about undefined functions, and then it's fine.
But it gets better than that in fact: the latter-day descendant of MCL is Clozure CL: CCL is free, and open source. CCL has both choose-file-dialog and choose-directory-dialog already and both of the globals exist although one is no longer exported.
Unfortunately there are then some hidden portability problems to do with assumptions about what pathnames look like as strings: it's making some assumption about what things looked like on pre-OSX Macs I think. This kind of problem is easy but often a bit fiddly to fix (I think in this case it would be easy). So, again, the answer to that is just not call the things that are doing a lot of pathname munging:
> (ps13-test-from-file-list (directory "~/Downloads/d/*.opnd"))
[... much output ...]
Total number of errors = 81.
Total number of notes = 41544.
Percentage correct = 99.81%
nil
Note that the above output came from LispWorks, not CCL: CCL works just as well though, as will any CL probably.
SBCL has one additional problem: the CL-USER package in SBCL already uses a package which exports int which is defined in this code. So you need to compile it in some other package. But given that, it's fine in SBCL as well.
I am using a few simple script-fus written in GIMP's scheme. (And that is the most I've used of scheme...)
I use them on machines running either Windows or Linux. Most times that is not a problem, but sometimes it is, namely when dealing with '\' vs. '/' on file paths.
Is there a simple way to detect on which operating system GIMP is running, from a Scheme script-fu? I haven't found anything on "Revised^5 Report on the Algorithmic Language Scheme" (but I may have not looked in the correct place)
One trick I can do is to check for the existence of a given file, e.g., the following works just fine
(define (script-fu-operating-system)
(let* ((the-os "windows"))
(if (= 1 (car (file-glob "/usr/bin/gimp" 0)))
(set! the-os "linux"))
(gimp-message the-os)))
As suggested by Michael Schumacher, I tried using both '/' and '\'.
On Windows it worked as expected, e.g. for (file-jpeg-load), with ...
... backslashes (only needs to escape them):
(file-jpeg-load RUN-INTERACTIVE "C:\\Users\\my.user\\Pictures\\test.jpg" "")
... slashes:
(file-jpeg-load RUN-INTERACTIVE "C:/Users/my.user/Pictures/test.jpg" "")
... even works with mixed (back)slashes !!
(file-jpeg-load RUN-INTERACTIVE "C:/Users\\my.user/Pictures\\test.jpg" "")
Yet for (file-glob) it only works with the proper backslashes:
(file-glob "C:\\Users\\my.user\\Pictures\\*.jpg" 1) => OK (the file list)
(file-glob "C:/Users/my.user/Pictures/*.jpg" 1) => NOK (empty list)
Tricks like what you describe are all you gonna get using scheme (script-fu). If you intend to write full-fledged, multi-platform scripts, I suggest you to write your GIMP scripts in Python instead. (Detecting the O.S. is a matter of e import sys and the O.S. name is available in the variable sys.platform.
- but them, you would not actually need the system for this spefic case, since for file access the language automatically translates "/" to "\" as needed under Windows.
Moreover, scheme is generally harder to learn, write and maintain, besides having a standard library which is a fraction of the one used in a standard Python install. The only cases I could recommend Script-fu instead of scheme are: if you are already proficient in scheme/lisp and not in Python at all, or, if you are just adapting/fixing an existing script.
I am using emacs 23 on two computers.
On both, dpkg -s emacs outputs the following version number.
However one has window.el and the other not. This make some function such as split-window behave differently. The help page of this function on the computer that apparently has not window.el installed reads that it comes from C source code instead.
Where does this difference comes from?
I prefer the behaviour of the one that says that split-window comes from window.el: it allows to specify the SIDE when splitting window and provide additional function such as window-resize.
I suppose this is the most recent one but I do not know how to check it nor how to upgrade the other to this state.
Library window.el is as old as the hills. Perhaps you meant that one of your Emacs installlations has window.elc but not window.el?
More likely, you are referring only to function split-window. Yes, it used to be a built-in function (i.e., defined in C), and now it is defined in window.el (which file exists also for the older Emacs versions where that function is a built-in).
FYI, lots of window and buffer-display stuff was changed around the same time as split-window was rewritten in Lisp. Lots of behaviors changed, in minor or major ways.
What is not at all clear is what the problem is that you are reporting. You ask, "Where does this difference comes from? How to fix it?" I've explained a bit about the difference. As for how to fix it -- what is the "it" that needs fixing, and what would the fixed behavior be like?
IOW, your question is, so far, unanswerable. If you specify things more exactly, perhaps we can help more.
I'm not certain what's going on with your debian packages, but if memory serves the readable .el(.gz) files are not supplied in the basic package, but in a separate package. This is because all you strictly need is the byte-compiled .elc files, so they can reduce the base package filesize by omitting them (at the expense of enabling you to read the elisp code).
Is M-x load-library RET window RET successful?
Note that Emacs 24 is the current stable version. You might want to upgrade.
Edit:
M-x emacs-version tells you which version of Emacs you're running, which will always give you a definitive answer.
(And if the versions are identical, then run emacs -Q to eliminate and site- and user-specific config files from the picture, as those are always a likely culprit for differing behaviours.)
Christian Queinnec has written a masterpiece called LISP In Small Pieces, which features eleven Lisp Interpreters and two Lisp compilers.
When you go to download the code from the website here - it has the comment:
The programs of this book are available on the net.
These programs used to run with some Scheme systems around 1994.
Any idea:
(a) What Scheme systems these ran on at the time, and more importantly;
(b) What Scheme systems these would run on today?
There's a lot of programs in there. I did a few tests to see how well I could answer this without having to try them individually. There are 131 files in the tarball with extension ".scm". However there appear to be Scheme programs with other extensions such as .bgl. So I did a search for files containing 'L i S P' in the first five lines. That yields 173 files. I tried running all of these on my preferred Scheme implementation. 31 of these run without error. Almost all of these are in the "src" directory. So the language-specific programs really do seem language-specific. Let's look at one of the src/ files that failed, "chap9z.scm". It's choking on define-abbreviation. I don't know the origin of this symbol, but it's not defined anywhere in guile. But all of its uses could be performed by guile's syntax-rules.
Some Scheme implementations that existed in 1994 still are still around and maintained: Scheme 48, Chez Scheme, Gambit, Bigloo, MIT Scheme and SCM.
Probably the code from LiSP will run in other modern Scheme systems such as Guile or Larceny.
Personally, I would recommend using Racket. Most likely, much of the code will run in #lang racket with no changes, and there's no requirement to use [] (but your code may be easier to read :). Things that don't work are probably easy to fix, and you can also use the R5RS language implementation provided by Racket which will likely work for all of the code.
(a) What Scheme systems these ran on at the time
The Makefile in the source tarball from the author's website has targets for running the code under bigloo, elk, gambit, mit-scheme, scheme2c, and scm.
The Makefile mentions SCM 4e1 and Bigloo 1.9d as known working versions, though I haven't tested them myself. I didn't find any mention of specific versions for the other schemes.
(b) What Scheme systems these would run on today?
The code in this github repo has been updated so that almost all of the tests in the included test suite pass with current (as of 06/2014) versions of bigloo, gambit, and mit-scheme.
If you just want to be able to run the code and follow along with the book, one of those schemes should work for you.
[full disclosure: I'm the owner of the repo and I'm a Scheme noob. The code in the repo is WOMM certified, but your mileage may vary.]
If, on the other hand, you're not content to use bigloo / gambit / mit-scheme, it shouldn't be too hard to add support for guile / racket / insert-favorite-scheme-here. Use one of the book.* files as a starting point, e.g. gambit/book.scm or mitscheme/book.mit. If you can get a version of book.scm to load in your favorite scheme, then have a look at the test.interpreters make target, and finally the grand.test target to verify things are working as expected.
The included README file states:
These files were tested with a Scheme interpreter augmented with
a test-suite driver (tester.scm),
the define-syntax and define-abbreviation macros (using
Dybvig's syntax-case package),
and an object system: Meroonet (meroonet.scm).
Bigloo, Scheme->C, Gambit, Elk or SCM can be used. The first three are
better since a specialized interpreter may be built that contains a
compiled Meroonet and compiled hygienic macros.
Apparently Appleby has posted an updated version of the source code. Racket is missing though )=
See https://github.com/appleby/Lisp-In-Small-Pieces
I have been using Emacs since version 18. Emacs Lisp isn't my routine programming language, but years ago I invested some time studying it to the point of creating a .emacs that's better (for me) than any GUI IDE to date.
That was a one-time effort and since then, I forgot completely how to program in lisp.
Alas, every time I upgrade my Emacs (18 > 19 > 20 > 21 > 22 > 23), something in my .emacs breaks, and I end up spending way too many hours (sometimes days) fixing these.
In many other languages I program routinely, it is possible to write code that never becomes obsolete. In emacs, on the other hand, I can never predict how things will change. For example [M-TAB] that used to work up until version 21.4.1, no longer works in version 23 and must be replaced with "\M-\t". Another example is dired-omit-toggle that used to work in version 21 but stopped working in version 22, being replaced by dired-omit-mode.
Now, I know that if a .emacs doesn't do much, it's possible to write "an almost empty" .emacs that can (probably) stay compatible with future versions.
But my .emacs is huge, designed to run on many different operating systems (and their different flavors, editions and versions, including non-GUI systems) without a single change. I wish there was a core-API or subset that is guaranteed to always work.
Is there really such a way to write a .emacs that will always stay upward compatible?
If so, where can I find a "cook book" or authoritative guidelines for accomplishing this?
Use (when (boundp 'some-variable) …) or (when (fboundp 'some-function) …) around any piece of code that relies on a specific feature. (While you're at it, start with (require 'cl) for those older versions that don't have when built-in.)
When all else fails, discriminate on emacs-major-version, emacs-minor-version and running-xemacs (defined as (string-match "XEmacs\\|Lucid" emacs-version)).
Avoid syntax and library functions that are only supported in newer versions.
It's rare that something breaks when you stick to documented interfaces. So try to look for a way to do things that's mentioned in the manual, and only fall back to modifying some random non-customizable variable if you see no other way. In my experience there is always a reasonably easy way to get something to work in all versions (at least with GNU Emacs, XEmacs is sometimes harder to please) if you allow the occasional conditional.
For example, "\e\t" has always worked for M-TAB. With dired-omit-mode, fall back to dired-omit-toggle if the former does not exist:
(set (if boundp 'dired-omit-mode 'dired-omit-mode 'dired-omit-toggle) t)
Yes, it's slightly painful, but not as dramatic as you make it out to be. I maintain a .emacs that works with anything since 19.23 (IIRC, it's been a while since I tested with anything older than 19.34) on all of DOS, Windows and unix. Compatibility with Windows is in fact more of a burden than keeping up with GNU Emacs version changes.
As for a cookbook, well, most differences between versions have to do with features that aren't very widely used (otherwise the maintainers would give more importance to strict upward compatibility). Since Emacs is big, there's undoubtedly plenty of it that you use but the cookbook writer wouldn't have heard of. You'll have to play it by ear. Fortunately it's not too hard.
Since Its impossible to predict future changes of anything, no one can guarantee the future compatibility.
I think the following points are few of many general ways to make it easy to maintain .emacs or init.el (which I am practicing right now.)
put .emacs.d/ version control (MUST one)
split init file into several small files.
use when to load specific customizations for a version of emacs.
for eg:
(when (= emacs-major-version 24)
;;load my settings for 24
)
I sympathize, and I share your pain. The answer is no, there is no such holy grail, I'm afraid. As you said, if your init file is simple enough then you might not need to change anything. Actually, even that's not true: the init file name and where Emacs looks for it have both changed over time.