Support questions of general interest

From time to time, we report on customer questions and problem reports which might be of interest to users in general. Here are some things that came up during 2010.

The standard readtable is now read-only

A big change in 8.2 compared to earlier releases is the standard Lisp readtable is now read-only. Previously, it could be modified, but that was actually illegal according to the ANS, so in 8.2, we came into compliance on this point. Many users had been modifying the standard readtable in their init files, which would cause their changes to be automatically propagated to later readtable copies made with (copy-readtable nil). That will no longer work, and creating a suitable readtable for general use became quite difficult. This is what we recommend for setting up a readtable in the init file.

The following code in your init file will define your own readtable and make the initial listener make a copy of your readtable when it starts rather than a copy of the standard readtable:

(defvar *myreadtable* (copy-readtable nil))

;; make changes as desired to *myreadtable*

(tpl:setq-default *readtable* (copy-readtable *myreadtable*))

There are other situations where the fact that the standard readtable is read-only requires recoding and users who run into those situations should contact for assistance.

Right ALT key is remapped in Common Graphics

Initially in Common Graphics, keystrokes with the right hand ALT key down are passed directly back to the Windows operating system. This is needed with some keyboards for entering characters for which the keyboard does not have dedicated keys. If you want to change this, so right hand ALT is the same as left hand ALT (displaying menus and making menu choices), see reserve-righthand-alt-key. You can change the value and save options using the Tools menu and the setting is put in your prefs file.

Compilation of certain files can suddenly be very slow.

Files which compiled quickly in version 8.1 in some cases compiled very slowly (by factors of 1000 or more) in 8.2. This happened when the compiler optimization values were such that the comp:save-source-level-debug-info-switch was true, so the compiler was annotating the fasl files with information needed for source-level stepping. The compiled code was not changed by this switch, so there was no effect on how fast the compiled code runs. But in some cases, the annotation process takes a long, perhaps very long time. We are interested in hearing about these as we are making improvements, but the immediate fix is to turn off the compiler switch for the compilation of affected files. You can turn off the switch by setting it to nil

(setq comp:save-source-level-debug-info-switch nil)

and turn it off for a specific compilation using the undocumented excl::compiler-let:

(excl::compiler-let ((comp:save-source-level-debug-info-switch nil))

  (compile-file ""))  ;; or (compile 'foo)

asdf issues

asdf is a defsystem module (see which we recommend. There are two issues which we occasionally get problem reports about. First, several symbols in the asdf package (defsystem, run-shell-command, source-file, compile-system, find-system, and load-system) which are also symbols in the excl package, so when you do (use-package :asdf) you get a continuable error. You can shadow these symbols in the usual way (and thus have the unqualified symbol refer to whichever you desire) but we recommend that you do not do (use-package :asdf) and instead package-qualify asdf symbols.

The other issue is shown by this transcript:

cl-user(6): (asdf:operate 'asdf:load-op :mysys)

; loading system definition from /users/lisp/asdf/mysys.asd into

; [...]

;;; Compiling file

;;;   /usr/share/common-lisp/source/mysys/foreign-array.lisp

; While compiling (:top-level-form "foreign-array.lisp" 1361):

Warning: compile-file found "export" at the top-level --  see the

         documentation for


;;; Writing fasl file

;;; Fasl write complete

Warning: COMPILE-FILE warned while performing

         #<compile-op nil @ #x2088a66a> on

         #<cl-source-file "foreign-array" @ #x207cf1e2>.

Warning: COMPILE-FILE failed while performing

         #<compile-op nil @ #x2088a66a> on

         #<cl-source-file "foreign-array" @ #x207cf1e2>.

Note it says COMPILE-FILE failed. So why did it write a fasl file? Because asdf reports a failure if there is an error or if there is a warning. In this case, there was only a warning (about using export at the top level not wrapped in an eval-when). compile-file completes when there are only warnings, but the asdf message may be confusing.

RANDR missing

Sometimes when a GTK (non-Windows) Common Graphics starts up, people report that the system prints a message saying:

Xlib:  extension "RANDR" missing on display [...]

This is completely harmless, and rather frustrating to us and our users. GTK is checking for features in Xlib and finding RANDR missing, so reports it (out of our control). RANDR is not in fact used or needed.

excl.osi:command-output differences

A user noticed that on UNIX, using excl.osi:command-output on UNIX to call a non-existent executable, a message was printed but no error signaled:

cl-user(65): (excl.osi:command-output "blarg")


("blarg: Command not found")



But on Windows, an error is signaled:

cg-user(1): (excl.osi:command-output "blarg")

Error: "starting shell command" resulted in error "No such file or directory"

[condition type: syscall-error]


The difference is how shell programs are run. On UNIX, the argument is given to your $SHELL and run from there. On Windows, it is executed directly. Because the command on Windows doesn't exist, you get an error. On Windows, you can get the UNIX behavior by modifying the command:

cg-user(2): (excl.osi:command-output "cmd /c blarg")


("'blarg' is not recognized as an internal or external command," 

  "operable program or batch file.")



Whether to error when encountering incorrect forms

A user noted that this form:

(search "asdf" nil :end1 4 :end2 4)

returned 0 rather than signaling an error or returning nil. This caused problems later because 0 is a bogus value which his program used as valid. He wondered why we did not signal an error.

Now that form is illegal: The :end2 value must be less than or equal to the length of the second sequence, and nil has length 0. The question is whether we should test for this error. The problem is this: we would have to check the length of sequence2, which when it is a list is a fairly expensive operation. And we would have to do this for every valid form as well as every invalid one, so every correct form would be slower. Checking versus speed is always a problem. In this case, we come down on the side of speed.

Handle leak on Windows

A user (running on Windows) who was creating lots of processes as his application ran found his application was failing because the system ran out of handles. He provided this test code:

(loop repeat 1000 collect 

   (progn (mp:process-run-function "foo" (constantly t)) (sleep 1)))

Handles in use are shown on the Performance tab of the Windows task manager, and indeed when we ran that code, the number of handles increased by about 1000, which would stay around as long as Allegro CL was running and disappear as soon as it exited. For this user, their application would fail after a while because they would exceed the number of handles the system would allocate.

We investigated and soon found that there was a bug where Allegro CL was not freeing handles, which was fixed by the shared library patch released on November 19, 2010.

We mention this for three reasons:

  1. This is an obscure bug which most users will not see because they do not create many, many processes, but it might affect you unexpedtedly so updating regularly is a good idea.
  2. This is the kind of bug that our own testing is likely to miss. Until the system runs out of handles, there is no indication of a problem, and even if one is looking at the handles statistics you might not notice it, since the number bounces around in general and seeing a trend involves watching over a period of time.
  3. We were able to find and fix this bug quickly because of the example code sent by the user. We cannot recommend too strongly that an example which we can run showing the problem greatly shortens the support process!
Copyright © 2019 Franz Inc., All Rights Reserved | Privacy Statement Twitter Google+