ToCDocOverviewCGDocRelNotesFAQIndexPermutedIndex
Allegro CL version 10.1
Significantly revised from 10.0.
10.0 version

Release Notes for Allegro CL 10.1

This document contains the following sections:

1.0 Introduction
2.0 Information on changes and new stuff since the 10.1 release
3.0 Fasl files are not-compatible between versions and operating systems
   3.1 All pre-10.1 Lisp compiled files must be recompiled (old fasl files will not load)
   3.2 Fasl files may be incompatible in different Lisps on same hardware
4.0 Release Notes for installation
5.0 Release notes for specific platforms
   5.1 Required versions of OpenSSL needed for the :ssl module
   5.2 The ARM-64 (aka ARMv8 and Aarch64) platform
   5.3 macOS notes
      5.3.1 Updating macOS may break X11
      5.3.2 Installing Mountain Lion OS (macOS 10.8) may uninstall X11
   5.4 Heap start locations
6.0 Release Notes for the base Lisp
   6.1 New features in the base Lisp
      6.1.1 Features added to Allegro CL 10.0 after the initial release of Allegro CL 10.0
   6.2 Non-backward-compatible changes in the base Lisp
   6.3 Other changes to and notes about the base Lisp
   6.4 Multiprocessing and SMP release notes
   6.5 Base Lisp platform-specific information
7.0 Release Notes for CLIM
8.0 Release Notes for Common Graphics and the IDE
   8.1 Significant changes in Common Graphics
   8.2 Non-backward-compatible changes in Common Graphics
   8.3 Other changes in Common Graphics
      8.3.1 Miscellaneous bug fixes in Common Graphics
   8.4 IDE release notes
      8.4.1 Miscellaneous bug fixes in the IDE
      8.4.2 Opening projects from releases prior to 10.1
   8.5 Common Graphics and the IDE on the Mac
   8.6 Functionality to handle differences between Windows and GTK
   8.7 Release notes for the winapi module
9.0 Release notes for AllegroServe
10.0 Release notes for The Emacs/Lisp interface
11.0 Availability of CLX for Allegro CL
12.0 Release notes for Orblink
Appendix A. ANSI Conformance in Allegro CL


1.0 Introduction

This document provides the release notes for release 10.1 of Allegro Common Lisp and related products. Many sections are divided into non-backward-compatible changes (that produce different behavior in release 10.1 compared to release 10.0) and changes unrelated to backward-compatibility. Note that a bug fix is not considered a backward-incompatible change even if it does result in changed behavior because the previous behavior was erroneous.

You may wish to look at the 10.0 Release Notes, included in this distribution as the file version-100-release-notes.htm.

This document describes the changes, major and minor, from 10.0 to 10.1. Please look particularly at these sections:

If you notice changed or unexpected behavior with an operator, variable, class, or facility, search for its name in this document to see whether there is an entry concerning it.



2.0 Information on changes and new stuff since the 10.1 release

The following changes have been implemented by patches and/or updates since the initial release of Allegro CL 10.0. See sys:update-allegro for information on getting patches and updates.

  1. Items to be added as necessary after the 10.1 release.


3.0 Fasl files are not-compatible between versions and operating systems


3.1 All pre-10.1 Lisp compiled files must be recompiled (old fasl files will not load)

fasl files (compiled Lisp files) created by releases of Allegro CL prior to 10.1 will not load into Allegro CL 10.1. All such files must be recreated by compiling the associated Lisp source files. An error will be signaled if Lisp attempts to load an older, incompatible fasl file.


3.2 Fasl files may be incompatible in different Lisps on same hardware

Fasl files created on Windows x86 cannot be loaded into Linux or FreeBSD x86 Lisps

The Windows and UNIX operating systems are too different. However, FASL files (for the same Lisp version) can generally be shared between different UNIX operating systems on the same hardware. The general principles are as follows. Note that incompatibility may creep in for reasons outside our control. If fasl files are incompatible, recompile on the target machine.

Fasl files will usually be compatible between platforms when:

It is up to the user to ensure that there are no os-specific dependencies, or that features (i.e. #+/#- ) did not cause essential code to be excluded or extraneous code introduced that would cause a problem on the crossed architecture.



4.0 Release Notes for installation

  1. Version 10.1 uses the 10.0 installation procedure: Installation is described in installation.htm.
  2. The distribution includes 8 bit and 16 bit character images (this information is repeated from earlier Release Notes). Allegro CL has images that support 8 bit characters only, or 16 bit characters only. It is our expectation that most users will use the 16 bit images. Executables supplied with the distribution either have or do not have `8' in the name. Those with 8 in the name (mlisp8 and alisp8, e.g.) support 8 bit characters. Those without a number in the name support 16 bit characters. Image (dxl) files also come in 8 and 16 varieties. Again, 8 in the name means 8 bit character support. Character support for images and executables must match. Trying to start an executable with the wrong type of image fails.
  3. No prebuilt Allegro Composer images in the distribution (this information is repeated from earlier Release Notes). To create an Allegro Composer image, start Allegro CL and load buildcomposer.cl. That will produce composer and composer.dxl, or composer8 and composer8.dxl. Allegro Composer is available on Unix only.
  4. No prebuilt Allegro CLIM images in the distribution (this information is repeated from earlier Release Notes). To create a CLIM image, start Allegro CL and load buildclim.cl. That will produce clim and clim.dxl, or clim8 and clim8.dxl.


5.0 Release notes for specific platforms

See Installation sizes and supported Operating System versions in installation.htm for a list of supported platforms and minimal Operating System versions. Allegro CL is tested with new OS versions as they are released (but not pre-release or beta versions). In general, Allegro CL can be assumed to work on newer versions, including those released after Allegro CL 10.1 itself was released.


5.1 Required versions of OpenSSL needed for the :ssl module

The :ssl module, when loaded, finds the newest installed version of OpenSSL libraries on your machine and loads them. See Secure Socket Layer (SSL) in socket.htm for information on how OpenSSL libraries are found and loaded.

If you load foreign libraries which themselves use OpenSSL, either in a development image or in a delivery (application) image, those libraries must be compatible with the version of OpenSSL used by the :ssl module. If they are not, the :ssl module cannot be used.

The current supported version of OpenSSL is 1.0.1. We understand there are plans to end support for version 1.0.1 on December 31, 2016. By that time, support for version 1.0.2 will be available.


5.2 The ARM-64 (aka ARMv8 and Aarch64) platform

Allegro CL is now available on the ARM-64 platform. The ARM-64 is also called the ARM64, the ARMv8, and the Aarch64

The ARM-64 processor (see the Wikipedia description here and the designer website here) is a RISC processor particularly suited to smaller devices.

Only 64-bit Allegro CL runs on the ARM-64, with SMP and non-SMP versions (there is no 32-bit Lisp on the ARM-64). Common Graphics and the IDE (see cgide.htm) are supported in the non-SMP ARM-64 version.

Installation on the ARM-64 is similar to installation on other Linux platforms. See installation.htm. See the Installation sizes and supported Operating System versions in that document for information on minimal operating system versions needed by Allegro CL.


5.3 macOS notes

Allegro CL 10.1 is only supported on macOS version 10.11 or later. It is not supported on versions 10.10 or earlier.

Common Graphics and the IDE are now supported on macOS but are not supported on the SMP version on the Mac. See Section 8.5 Common Graphics and the IDE on the Mac for more information. Both the IDE and CLIM require certain tools (X11, GTK, Open Motif) which may have to be installed separately. See Installation on macOS in installation.htm for details.

The Runtime Analyzer (see runtime-analyzer.htm) does not work properly on the 64-bit macOS port (there is no problem on the 32-bit port).

Building shared libraries on macOS

Building shared libraries on macOS in foreign-functions.htm describes how to create a shared library suitable for loading into Allegro CL. We have determined that the -flat_namespace to the ld used to create the shared library is necessary, as shown in the linked section.


5.3.1 Updating macOS may break X11

We have had reports that updating macOS may cause X11 to be stop working properly. The symptom is blank rectangles in Common Graphics applications (including Gruff). X11 is necessary for the IDE, CLIM, and Allegro Composer. To fix the problem, install the latest version of XQuartz (available from http://xquartz.macosforge.org/landing/) after updating the macOS.


5.3.2 Installing Mountain Lion OS (macOS 10.8) may uninstall X11

We have had reports that installing the Mountain Lion OS on Macs (Mountain Lion is macOS 10.8) causes X11 to be uninstalled, and does not itself include X11. X11 is necessary for the IDE, CLIM, and Allegro Composer. If you find X11 uninstalled (so it is no longer in the Utilities sub-folder of the Applications folder, you can reinstall it by downloading and installing XQuartz.

If you have an older version of macOS and need to install/reinstall X11, install it from your installation medium.


5.4 Heap start locations

When building large new images, it is often useful to specify Lisp heap and ACLmalloc heap start locations. See the discussion of the lisp-heap-start and aclmalloc-heap-start keyword arguments in Arguments to build-lisp-image 2: defaults not inherited from the running image in building-images.htm. Here are the initial locations (called `bases') in Allegro CL 10.1 as delivered. Values are Hexadecimal integers.

Operating System Lisp base C base
ARM 64-bit #x1000000000 #x6000000000
ARM 64-bit SMP #x1000000000 #x6000000000
FreeBSD 32-bit #x40000000 #xa0000000
FreeBSD 64-bit SMP #x10000000000 #x80000000000
Linux (x86) 32-bit #x20000000 #xa0000000
Linux (x86) 32-bit SMP #x20000000 #xa0000000
Linux (AMD64) 64-bit #x10000000000 #x80000000000
Linux (AMD64) 64-bit SMP #x10000000000 #x80000000000
macOS 32-bit #x20000000 #x74000000
macOS 64-bit #x1000000000 #x80000000000
macOS 64-bit SMP #x1000000000 #x80000000000
Windows 32-bit #x20000000 #x54000000
Windows 32-bit SMP #x20000000 #x54000000
Windows 64-bit #x200000000 #x8000000000
Windows 64-bit SMP #x200000000 #x8000000000
Solaris 32-bit #x4000000 #x54000000
Solaris 64-bit #x1000000000 #x80000000000
Solaris (AMD64) 64-bit #x1000000000 #x80000000000


6.0 Release Notes for the base Lisp

This main section contains three subsections (which have additional subsections): one on new features (Section 6.1 New features in the base Lisp), one on changes which are not backwards compatible and so may require code changes, (Section 6.2 Non-backward-compatible changes in the base Lisp), and one on miscellaneous changes (Section 6.3 Other changes to and notes about the base Lisp).


6.1 New features in the base Lisp

Version 10.1 is a maintenance release of Allegro CL. It contains bug fixes and optimizations and other improvements but does not have major new capabilities.

Major changes

There is now support for the ARM processor. See Section 5.2 The ARM-64 (aka ARMv8 and Aarch64) platform for more information.

Other new features

  1. Improved support for UTF-16 characters. A number of functions associated with UTF-16 characters have been added. See Appendix 1: Operators, Symbols, Variables Documentation in iacl.htm for links to the new functionality.
  2. Support for the GB18030 external-format. See the list of external formats and the table notes in the section Basic External-Format Types in iacl.htm for more information.

6.1.1 Features added to Allegro CL 10.0 after the initial release of Allegro CL 10.0

The following items were included by patches in Allegro CL 10.0 (and some in earlier releases of Allegro CL) after the release of 10.0 and therefore were not in the original 10.0 documentation. All are part of 10.1 and the 10.1 documentation. Some changes to 10.1 may also be backported to 10.0 and/or 9.0, and thus added to the release notes for those products, but those changes are documented in other sections of this document.

  1. sys:lispval-storage-type has new :stack-allocated type. Objects which reside on the stack are identified as :stack-allocated by sys:lispval-storage-type. Note that on a non-os-threads Lisp the value may be seen as :stack-allocated even if it is outside of the stack it resides and should have been called :static.
  2. OpenSSL libraries must be installed in order to use OpenSSL in socket communication. Except on Windows, prior to a patch released in June, 2016, Allegro CL included the necessary OpenSSL libraries with its SSL module. This meant that users did not have to obtain those libraries themselves but it also meant that users could not use the latest OpenSSL version until the Allegro CL module was updated. (Note that not all Allegro CL versions support SSL.) With the patch released in June, 2016, this has changed. OpenSSL libraries must be installed on all platforms. These will be linked to when the Allegro CL SSL module is loaded. An error will be signaled if the needed OpenSSL library files cannot be found. See Secure Socket Layer (SSL) in socket.htm for more infrmation on the new scheme. Note that some operating systems include OpenSSL libraries with their standard OS updates. On those platforms (which include the Mac and some versions of Linux), Allegro CL users will likely have to take no action: the OpenSSL libraries will be found in the standard location for the platform. Also, as said above, there is no change in Windows, where users have always downloaded the OpenSSL library files, other than the change to the API described in Secure Socket Layer (SSL) in socket.htm.
  3. Some compiler switches obsolete. The compiler switches comp:peephole-optimize-switch, and comp:save-arglist-switch are no longer used. The variables still exist and can be set (so existing code will not beak) but the values are ignored. Peephole optimizations are now always done during compilation and arguments are always saved. It was determined that any possible savings were too small to be worth doing. This change was made in the initial 9.0 release but was not properly documented.
  4. New types keyword argument to dbi:run-prepared-sql. This new argument to dbi:run-prepared-sql allows specifying the return type.
  5. New EC2 implementation: an updated interface to the Amazon Elastic Compute Cloud (EC2) has been released in a patch dated November 4, 2014. The API version support is moved to version 2014-09-01. See ec2.htm for further information.
  6. A new for-as-in-sequence subclause for the loop macro. The loop macro now supports a for-as-in-sequence subclause which iterates over a list or a simple, general vector. Existing (standard) subclauses include for-as-in-list and for-as-across (for vector) and this new subclause combines them, as so allows the sequence operated on to be a list or a simple vector at runtime. See cl:loop and the for-as-in-sequence subclause for looping over sequences in implementation.htm. This new subclause was added in a patch in May, 2014.
  7. New universal date parser. New functions string-to-universal-time and universal-time-to-string convert strings denoting times in various standard formats to universal times and universal times to strings in various formats. Converting durations to strings is also supported. This is not part of the date-time module described in date-time.htm but since the functionality is related, the General date to universal time parsers section in that document describes the new facility. These functions were added in a patch released in May, 2014.
  8. jLinker update: a patch released in April, 2014 made a number of changes to the jLinker module. There are now several calling models, including a new calling style where Lisp functions are generated by analyzing Java jar files or classes. The names of the Lisp functions are systematically derived from the Java names and mimic the overloading style used in Java; in most cases, the Lisp name is easily deduced from the Java name so that perusing a translation table is rarely needed. The correct Java method to call is determined at run time by comparing the Lisp argument types to Java signatures. See Calling Style from Lisp to Java in jlinker.htm.
  9. Major update to SSL socket module. (This change is not related to the Heartbleed problem described in the next item.) The interface to SSL sockets has been upgraded. SSL contexts, re-usable objects which contain configuration values for SSL server and client streams, are now supported. Contexts are created with make-ssl-server-context and make-ssl-client-context. make-ssl-server-stream and make-ssl-client-stream now have context keyword arguments which take an SSL context as a value. Also, the default value for the method argument to make-ssl-server-stream and make-ssl-client-stream is :tlsv1+. These modifications were added in a patch released in April, 2014.
  10. Fix for OpenSSL Heartbleed bug available. The OpenSSL Heartbleed bug (see https://www.openssl.org/news/secadv_20140407.txt) requires new library files and application rebuilds. See the Tech Corner Article at http://franz.com/support/tech_corner/heartbleed040914.lhtml for instructions. Users are strongly recommended to apply this fix.
  11. The list value of *global-gc-behavior* should not be used in an SMP Lisp. The variable *global-gc-behavior* controls when and how often global garbage collections happen. On possible value for this variable is a list of a positive integer (specifying a number of seconds), and a real greater than or equal to 1.0 (and optionally a boolean specifying verbosity). This value is designed to trigger global gc's after a specified amount of idle time. But idle time is ill-defined in an SMP Lisp. The list value for *global-gc-behavior* uses sys:funcall-after-idle-timeout, which, as the next item notes, should not be used in SMP Lisps.
  12. sys:funcall-after-idle-timeout should not be used in an SMP Lisp. In an SMP Lisp, idle time is ill-defined. The function sys:funcall-after-idle-timeout, which calls a function after a specified idle time, should not be used.
  13. Documentation for load-compiled corrected. The function load-compiled, when first implemented, compiled a file but did not write a fasl file. That was changed some time ago so load-compiled is a roughly equivalent to the :cload top-level command (compiling and loading file). The documentation has been corrected.
  14. Enhancement to net.post-office:send-letter. The first argument to net.post-office:send-letter, the server specification, can now specify an alternate transport mechanism, instead of the usual SMTP network protocol. See net.post-office:send-letter for details. The patch implementing this cahange was released in early November, 2013.
  15. Some MySQL changes. A new client-flags keyword argument to connect was added to 8.2 in a patch but was not documented in either the 8.2 or 9.0 documentation until now. A patch released in early August, 2013, modified the behavior of the host keyword argument to connect, which can now be a list. insert-db now has an on-dup-keys keyword argument improves handling when the insert tries to insert a row with the same values in key columns as an existing row. Also, some support for stored procedures has been added. See MySQL and stored procedures in mysql.htm.
  16. A patch released in late Jult, 2013 implements a major jLinker upgrade. A major patch release of jlinker (version 7.1) adds several new features. The patch consists of Lisp code in a new fasl file and Java code in a new jar file. New features include connection pooling, better socket handling, and improved error hierarchy. A number of functions have been modified, but all modifications are backward compatible. See jlinker.htm for a complete discussion of the patch. The patch is for version 9.0 only. It does not apply to earlier releases.
  17. New regexp patch fixes some replace-re behavior and enhances match-re. A bug in replace-re caused handling of BOS and EOS markers incorrectly. So (replace-re "abc abc bc" "^abc\\s+" "_") would return "__bc" rather than "_abc bc". Also, (replace-re "abc def " "def$" "_" :end 7) would return "abc _ " rather than "abc def ". This has been fixed and the correct values are now returned. As part of the change, match-re has additional keyword arguments start-unbounded and end-unbounded. The behavior of match-re is unchanged if the new arguments are not specified.
  18. Better control over proxies in Aserve. If you allow proxies in AllegroServe, you may open a security hole. Proxies, which before were general, can now be restruicted to specific machines using the new proxy-control object, if desired. See the Proxy section of the the AllegroServe documentation for details.
  19. The profiler may now be included in runtime images (except those created by Allegro Express).
  20. New jlinker-init keyword argument: :end-function. The value of the end-function keyword argument to jlinker-init should be a function called when a jlinker connection is terminated. The function gets a single argument, the jlinker connection instance. Added by a pacth released May 1, 2013.
  21. All nicknames removed for the excl package. This was done when 9.0 was released but we neglected to document it. The nicknames were excl, franz, and stream. In fact, it is illegal for a package nickname to be the package name (so excl was removed). The other two names (which were added when the symbols in those packages were merged into the excl package) were removed so that they would not appear as qualifiers to excl symbols when excl:*print-nickname* is true. This is a backward incompatible change. Users who depend on stream or franz as nicknames can add them back using rename-package if desired. This item is repeated below in Section 6.2 Non-backward-compatible changes in the base Lisp.
  22. regexp patch fixes some bugs, changes split-re behavior. WARNING: some changes result in changed behavior (nil might be returned instead of (""); some forms no longer signal errors).. A patch released in February, 2013 fixes some regexp bugs and changes the behavior of split-re to match PERL behavior. split-re now has a limit keyword argument; it not longer errors when the regexp argument matches the empty string; and trailing empty fields are removed. See regexp.htm and also the description of split-re, where we have examples of the changes.
  23. New ability to dump virtual images on Windows. See Virtual dumplisp: for very large images and pseudo-forks on Windows
  24. We have revised the regexp.htm and have removed the discussion of the older regexp module (which is still maintained for backward compatibility, and individual functions are still documented in the operators pages)). All new code should use the regexp2 module described in regexp.htm.
  25. text-line does not work on file streams. The common-graphics:text-line function only works on text-edit-panes and multi-line-editable-text widgets. It does not work on file streams. The documentation has been updated to make that clear.

6.2 Non-backward-compatible changes in the base Lisp

The following changes result in different behavior in Lisp compared to earlier releases.

  1. build-lisp-image arguments :c-heap-start and :c-heap-size are no longer supported. These arguments to build-lisp-image and generate-application were replaced some time ago with aclmalloc-heap-start and acl-malloc-heap-size but were still accepted (with a warning) for several releases. They have now been removed and should not be used. Use :acl-malloc-heap-start and :acl-malloc-heap-size instead.
  2. The macro excl:atomic-read-modify-write no longer supported. The macro was never documented and has now been removed.
  3. sys:resize-areas warns when :old argument is unspecified. sys:resize-areas will signal a warning when no value is given for the old keyword argument. old defaults to 0, meaning there will be as little free space as possible in the old area after the function returns. That is rarely what is desired. If that is what you want, specify a value of 0 to avoid the warning.
  4. :redhat10 is no longer on *features* on Linux versions.

6.3 Other changes to and notes about the base Lisp

Listed are other changes to and notes about Allegro CL.

  1. vcredist_*.exe executables copied to application directory on Windows. Allegro CL applications on Windows may need to run vcredist_x86.exe or vcredist_x64.exe during installation in order to work properly. The generate-application program now copies the appropriate one of these files to the application's destination directory. See the Windows specific information section in delivery.htm for more information.
  2. New function nice-signal-name. nice-signal-name takes a signal number (an integer) as its argument and returns a string which is a meaningful and easy to interpret description of the associated signal. nil is returned when the signal number is unknown. The function strsignal (which is the name of the UNIX library function that does the same thing) is a synonym of nice-signal-name. Both work on all platforms. This function is available with a patch in Allegro CL 10.0.
  3. New variable *script-name*. The variable *script-name* is bound to the name of the script file being run when Allegro CL is being executed by a UNIX script file. See Starting on UNIX using a shell script in startup.htm for more information on running Lisp using a script on Unix.
  4. On Windows, starting Allegro CL causes the PATH environment variable to include the Allegro CL directory. PATH is modified because loading DLLs on Windows from the directory in which the Allegro CL executable otherwise will not work. See What Lisp does when it starts up in startup.htm for information on the startup sequence.
  5. sys:with-command-line-arguments does nothing when the :command-line-arguments argument is specified nil. When the :command-line-arguments argument to sys:with-command-line-arguments is unspecified, its value is replaced with the actual command-line arguments used to start Lisp. If, however, its value is specified nil, it is assumed you want the sys:with-command-line-arguments form to do nothing, and that is what now happens.
  6. New variable *unicode-version*. The variable *unicode-version* is bound to a string containing the version number for the Unicode Character Database used to build the Allegro CL character name table and collation rules.
  7. script keyword argument to compile-file allows compilation of UNIX scripts. compile-file (whose implementation in Allegro CL is described here) has an additional script keyword argument which, when true (the default) allows the initial lines which start with #! to be ignored by the compiler, so that Lisp code after those initial lines can be compiled. See compile-file in compiling.htm for more information.
  8. print-type-counts prints information about open and closed old areas. print-type-counts prints information about Lisp objects in the heap. It has always printed information about old areas. Now information about just open old areas and just closed old areas (those that are and are not gc'ed during a global gc) can be requested.
  9. sniff-for-unicode has new return-bom keyword argument. If specified non-nil, sniff-for-unicode returns a third value with information on BOMs (Byte Order Markers) in the argument stream.
  10. Unicode external formats handles BOMs. The :unicode external-format detects BOMS for UTF-8 UTF-16BE and UTF-16LE. The :unicode-be external-format is like :unicode, but input is assumed big-endian if no BOM is detected. The :unicode-le external-format is like :unicode, but output is always little-endian with BOM. See The unicode and fat External-Format Types; the unicode BOM is iacl.htm for more information.
  11. sys:lispval-storage-type has new :pure type and new function sys:purep exists as a predicate.. Objects which are stored in pure space, and are thus read-only and shareable, will have this storage type returned by sys:lispval-storage-type. See pll-file (and links from there) and also Getting information on memory management using cl:room in gc.htm for more information on pure space. The new function sys:purep returns true when applied to objects which reside in pure space.
  12. New generic function mp:process-sequence returns unique process id. The default method for the generic function mp:process-sequence returns an integer identifier unique to the argument process. This identifier can be used in various places, in particular in many top-level commands that take processes as arguments. This value is displayed in the output of the :processes top-level command.
  13. Top-level commands dealing with processes can take a process sequence number as arguments. The new generic function mp:process-sequence returns an integer identifier of a process. This value can be passed as the process argument to top-level command like :processes, :focus, :arrest, :unarrest, and :kill. See Argument processing for :processes, :focus, :arrest, :unarrest and :kill in top-level.htm for more information.
  14. Top-level commands dealing with processes have their argument processing regularized. The commands are :processes, :focus, :arrest, :unarrest, and :kill.
  15. New on-error argument to map-over-directory. map-over-directory now has an on-error keyword argument which specifies what it should do when it encounters an unreadable directory. When this argument has its default value, :ignore, the unreadable directory is skipped without notice. The skipping without notice behavior is what was done in earlier releases so the default behavior has not changed. When on-error has any other value, calling programs will see the errors that occur from accessing unreadable directories.
  16. MOP class redefinitions and SMP. An application that updates a class definition while it is running should be designed to ensure that none of the objects are accessed, even for generic-function dispatch, until the redefinition is complete. A new section in smp.htm makes this point.
  17. New arguments to build-lisp-image: initial-oldspace and initial-newspace. Two new argument to build-lisp-image (actually described in building-images.htm) are :initial-newspace and :initial-oldspace. They specify the sizes of newspace and oldspace when an image is first created at the start of building a final image. initial-newspace is rarely important and is included for completeness and rare cases. But initial-oldspace can be important. If the final built image has too many oldspaces, global gc's can take longer and compressing them (with sys:resize-areas) can be difficult. If you notice that the final image has many oldspaces, try a larger value for initial-oldspace to reduce that number. Like other size arguments to build-lisp-image, these argument value can be specified with environment variables, ACL_BUILD_INITIAL_NEWSPACE and ACL_BUILD_INITIAL_OLDSPACE. If these environment variables have values, they override values specified in the call to build-lisp-image.
  18. Sizes in build-lisp-image argument can be specified with strings ending in #\g or #\G to indicate gigabytes. Various arguments which specify sizes in calls to build-lisp-image (actually described in building-images.htm), such a :aclmalloc-heap-size and :lisp-heap-start, etc. #\k and #\m (and their uppercase analogs) have been accepted for some time to mean kilobytes and megabytes. See Table Note 3: specifying starts and sizes for heaps and old and new space in building-images.htm for more information.
  19. :regexp2 added to modules loaded by develenv.cl and :regexp removed. develenv.cl is a file with require statments for modules which are useful to include in Allegro CL development and delivery images. See Creating a runtime application in runtime.htm. This file used to include the :regexp module. That has now been replaced with the :regexp2 module. The :regexp2 module is described in regexp.htm.
  20. SIGPIPE signlas are not handled. See add-signal-handler if you want a signal handled.
  21. Applications are built in application mode. When an Allegro CL application is built with generate-application, generate-executable, or using the project system in the IDE, the image will be built in application mode. In this mode, certain variables have different initial values and signal handling is different (particularly with respect to messages reporting signals). See Application mode in delivery.htm for more information.
  22. New multiprocessing macro with-locked-queue. mp:with-locked-queue macro has been added to facilitate specializing enqueue and dequeue methods for subclasses of mp:queue. (This macro was also added as a patch to version 10.0.)
  23. New function gcpath:find-gcpath and new macro gcpath:collected-newstuff. gcpath:find-gcpath and gcpath:collected-newstuff, both documented in Functions for finding gc paths and new objects in gc.htm, allow for finding a path of object references that shows why an object is not garbage and for determining what non-transient objects are created by evaluating a form.
  24. The special operator named-annotated-function documented. The special-operator named-function was incorrected labeled a macro in earlier releases. The special operator named-annotated-function was not documented (although it existed) and now is.
  25. Allegro CL 32-bit distributions including Express contain a script which installs Ubuntu 32-bit libraries.. The 32-bit ACL distributions, Express included, now contain a script, ubuntu32.sh, which will install 32-bit Ubuntu libraries (which are not included with Ubuntu distributions, see Getting 32-bit Allegro CL to run on 64-bit Ubuntu).

6.4 Multiprocessing and SMP release notes

The following are multiprocessing and SMP-related changes.

  1. An SMP Lisp will fail if there is a thread which prevents garbage collections. In an SMP Lisp, code that runs atomically, with interrupt checks optimized out, could block the gc indefinitely. This represents a bug in the Lisp program that cannot be debugged in Lisp. When the garbage collector recognizes such a situation, it will print some diagnostic information and kill the entire Lisp process. A message will say which process(es) are blocking gc's.
  2. New with-virtual-timeout macro. The new mp:with-virtual-timeout macro is similar to sys:with-timeout except only non-gc cpu time is counted toward the timeout, not real time. In an SMP Lisp, time can be further resticted to a single thread.
  3. New macro memtrace-def allows definition of memtrace wrapper. memtrace-def defines the wrapper but does not perform any fwrap operations. This allows memtrace to be used in runtime code.

6.5 Base Lisp platform-specific information

There are no entries at this time. Information may be placed here in documentation updates after the initial Allegro CL 10.1 release.



7.0 Release Notes for CLIM

The CLIM manual has not been updated (other than minor corrections) for the 10.1 release. There have been no significant changes to CLIM functionality compared to 10.0.



8.0 Release Notes for Common Graphics and the IDE

Common Graphics and the IDE are supported on Windows SMP Lisp but are not supported in SMP Lisps on the Mac and Linux. They are supported in the non-SMP Lisps on Windows, Linux, and the Mac.

The first subsection describes changes to Common Graphics and the IDE that are non backward-compatible. Please review this section and make whatever necessary changes to your code to obtain the desired behavior.

The second subsection describes other changes to Common Graphics and the IDE. These should not require code changes (please tell us if any do, because that may indicate a bug).

The section Section 8.4 IDE release notes and its subsections provide information about the IDE.


8.1 Significant changes in Common Graphics

Most changes to Common Graphics in Allegro CL 10.1 are bug fixes and incremental improvements. There is also the following change which assists in identifying the causes of compiler warnings.

  1. New tools for identifying code that causes compiler warnings. The dialog that shows compilation warnings has a new button for showing one of the functions that has warnings in the editor. And when source debugging information was compiled in (see the compiler switch save-source-level-debug-info-switch), you can select an individual warning and then the form inside the function that triggered the warning will be selected in the editor. Also, when a runtime error is signaled for a call in a function whose source code location is known, the restarts dialog will include a restart for showing the calling function in the editor, and it will also select the form for the erroring call if source debug info is present.

    Here is an example of the pop-up window followed by a picture of the editor. There are two functions whose compilation signaled warnings, the first because the argument was unused and the other (the third definition) because an unbound, undeclared variable (y) is used.


8.2 Non-backward-compatible changes in Common Graphics

There are no non-backward compatible changes in release 10.1.


8.3 Other changes in Common Graphics

  1. New arguments to add-toolbar and remove-toolbar. Additional optional arguments to add-toolbar and remove-toolbar control whether existing toolbars and child-windows are rezied (for add-toolbar) and existing child-windows are resized (for remove-toolbar). These arguments have in fact been present for several releases but not documented until now.
  2. New function monitor-info. The function monitor-info returns information about all the monitors that are present. This function returns a list whose length is the number of monitors. For Common Graphics on GTK, the list elements are each a single-element list containing a box specifting the coordinate range of the monitor. On Windows, the list elements are four element lists with the same first element and additional information in the remaining elements.
  3. The clipboard on Windows can contain items at custom locations. See clipboard-object for a discussion of clipboard locations passed as the value of the (required) clipboard-format argument. Examples show how such items can be accessed by the Lisp application that posted them and by other Lisp applications.
  4. On the Mac, the Common Graphics "Alt" is now the Mac's Option/Alt key rather than the Command key as before. This is more consistent with other applications, and reduces conflicts with global Mac keyboard shortcuts that use the Command key. If you needed to revert to the old behavior, you could do so by setting the internal global variable cg.gtk::*use-option-key-for-alt* to nil, though we hope that that is not needed.
  5. On the Mac, the Command key (sometimes along with the Option key) can now be used with the arrow keys to scroll by pages and to move to the start and end. This applies to the text-editing control as well as to widgets that are implemented in Common Graphics (rather than supplied by the underlying windowing system). This takes the place of the PageUp/PageDown/Home/End keys found on other platforms, when not using something like Emacs that provides the needed keystrokes.

8.3.1 Miscellaneous bug fixes in Common Graphics

  1. Fixed: The function fill-circle drew in the wrong place when *antialiasing* is true and the window is scrolled.
  2. Fixed: Drawing with a fill-texture did not align textures properly when the window is scrolled.
  3. Fixed: Keypresses on non-English keyboards that produced multi-byte characters were not handled correctly by Common Graphics. (Patched for 10.0.)
  4. Fixed: Common Graphics reversed the behavior of the commands on the Microsoft Windows right-click pop-up menu on a window scrollbar to scroll to either the top or the bottom of the window. (Patched for 10.0.)
  5. The file dialog on Windows could crash when no :default-extension argument is passed. (Patched in 10.0.)
  6. Fixed: setf'ing stream-origin failed within with-delayed-redraw.
  7. Fixed: in grid-widgets, keystrokes such as Alt-O to invoke the "OK" default-button still work while editing text in a grid cell.
  8. Fixed: in grid-widgets, hangs could occur when dragging a grid row or column past the end of its section to cause the section to auto-scroll, especially for a larger grid that's drawing lots of stuff.
  9. Fixed: in grid-widgets, when the edit-start-trigger of a grid cell is :get-focus, the text editing will begin whenever the cell gets the keyboard focus, including when selecting the dialog that the grid-widget is on or alt-tabbing back to the application. Previously it required tabbing to the cell or pressing the Enter key.
  10. Fixed: on Linux and Mac, configuring a second monitor to the left of the primary monitor led to improper placement of IDE windows as well as modal dialogs in applications.
  11. Fixed: programmatically moving a top-level window on the Mac to a different monitor left the window invisible in the Mac's default mode where it uses a separate "space" for each monitor. You will probably still need to turn off that Mission Control option if you want to turn off the IDE's option to use a single parent window and then place different IDE windows on different monitors, because the separate IDE windows are still on a single owner window. Leaving the IDE on a secondary monitor and unplugging that monitor and plugging it back in could still leave the IDE invisible as well unless you turn off that Mission Control option.
  12. Fixed: In generated Common Graphics applications on Mac and Linux, using the macro in-cg-process could lead to severe failure due to accidentally causing multiple lisp processes to handle events from the single GTK event queue.
  13. Fixed: on Windows, if *antialiasing* is true then the functions draw-to and draw-to-x-y did not update the current drawing position.
  14. Fixed: on Linux and Mac, the functions ask-user-for-existing-pathname and ask-user-for-new-pathname broke if the :initial-directory argument is the root directory.
  15. Fixed: on Windows, clipboard-object can now write and read back text from multiple "locations" on the system clipboard.
  16. Fixed: sometimes a fill-texture could simply stop being drawn when using it to fill areas.

8.4 IDE release notes

The IDE is supported on the Windows SMP Lisp. It is not supported in the Mac or Linux SMP versions of Allegro CL 10.1. It is supported in the non-SMP version of those platforms.

The non-SMP version runs on one hardware processor at a time, and corresponds to earlier versions of Allegro CL.

  1. New option show-quick-symbol-info-on-space. The option ide:show-quick-symbol-info-on-space, if enabled (as it is by default) will display information about a symbol in the status bar when a space is typed after a symbol name in the listener or in an editor buffer. This option may interfere with some input methods that use multiple keystrokes for typing some characters, if one of the keys in such a sequence is the spacebar. If this happens, you can turn this option off, as described on the documentation page, to avoid the problem.
  2. New option find-in-files-search-subprojects-later. The option ide:find-in-files-search-subprojects-later specifies the initial value of the Search Subprojects Later checkbox on the Find In Files dialog. The value is remembered in the options file so it will be the same in the next invocation of the IDE.
  3. New option use-ide-debugger-on-all-processes: the ide:use-ide-debugger-on-all-processes configuration option controls controls whether the IDE's debugger will be used for all non-IDE processes when they signal errors, rather than using the base Lisp's debugger.
  4. The trace dialog now shows elapsed time for each traced call. See the Trace Dialog.
  5. Moving the mouse over a local variable in the stepper's definition pane shows the current variable value. See the Stepper Dialog.

8.4.1 Miscellaneous bug fixes in the IDE

  1. Fixed: On the Windows platform, invoking the user's preferred third-party web browser for IDE help failed if Internet Explorer has been explicitly disabled. This includes showing Franz news when the Express version starts up.
  2. Fixed: The Processes dialog could fail to show some processes in an SMP lisp, due to unpardonably sorting the global sys:*all-processes* list. (Patched for 10.0).
  3. Fixed: In the runtime analyzer results dialog, keyboard shortcuts that were intended only for the main outline tab could break when used on other tabs. The shortcuts also prevented typing some characters to move to list items that begin with those characters.
  4. Fixed: When using the incremental-search option in the IDE's editor, and the warn-on-no-action-taken option is also on, then a warning dialog awkwardly appeared while typing the search string when there is no match for a further typed character. The font in the small window for the search string is now a fixed-width font as well.
  5. Fixed: On Linux and Mac, the IDE's source code editor sometimes did not read in the correct package, and so compilation of individual definitions failed.

8.4.2 Opening projects from releases prior to 10.1

Allegro CL 10.0 projects should open without problem in Allegro CL 10.1.


8.5 Common Graphics and the IDE on the Mac

Common Graphics and the IDE and available on the Mac but only on the non-SMP Lisp. You must run X11 (it is in the /Applications directory and comes with recent versions of macOS and is usually installed by default on 10.1, but see Installation on macOS in installation.htm for full details). Usage is like that on Linux. See cgide.htm for details.

These are known problems using CG and the IDE on the Mac:

  1. Parenthesis-matching marks are drawn on pop-up windows. They cannot be drawn directly on a lisp-edit-pane, so instead a pop-up window (which otherwise looks like it is drawn directly on the pane) is displayed. See *show-parenthesis-matches-as-pop-up-window*, which must be set to true, as it is initially on macOS, and also *parenthesis-match-pop-up-milliseconds*.
  2. No annotations in form windows when designing dialogs. The annotations include widget resizing handles and alignment lines.

8.6 Functionality to handle differences between Windows and GTK

For complete information on the differences between Windows and GTK, please see cggtk-relnotes.html.

This section is repeated from the 10.0 release notes.

Common Graphics and the IDE run on Windows and Linux with GTK. Certain differences between the two operating systems and windowing systems mean that some things do not work the same in Windows as in GTK and vice versa. The functionality listed here tries to handle the differences. Some of the variables/operators/etc. are only available on one of the two platforms.

Known bug with menu-items and buttons

GTK Only: all-black menu-items and half-black buttons. There is still a mystery on the GTK platform where all button widgets can turn half black along a diagonal line, and all menu-items on some platforms will be totally black. This seems to happen only when opening a project from the Startup Action dialog, though, so a workaround is to not reopen a project from that dialog and instead to use the Recent menu or File | Open Project just afterward. We have tracked the problem down to the use of transparent-pane windows such as the frame-child of a form window, but beyond that it is a total mystery.

Event handler processes

Because Linux currently does not use native threads and Windows does, on Windows, all windows handle events in their own thread associated with the window while on Linux/GTK, there is one event-handling thread. default-application-window-subkey, *use-single-cg-event-handling-process*, and *single-cg-event-handling-process* allow distinguishing behavior when necessary. cg-process-wait should be used on GTK instead of process-wait in event handlers. See also process-pending-events-if-event-handler.

Miscellaneous

The with-message-window window is now a frameless-topmost-p window on the GTK platforms to avoid problems that it had otherwise. This means that deselecting the owner window will close the message window, and so it may be a good idea to display the message in an additional place such as a status bar.


8.7 Release notes for the winapi module

The winapi module contains certain functions, in the windows package, that perform OS-related tasks. See The Windows API and a Windows API program with windows but without CG in cgide.htm for more information.

  1. no entries


9.0 Release notes for AllegroServe



10.0 Release notes for The Emacs/Lisp interface



11.0 Availability of CLX for Allegro CL

CLX (Common Lisp X) provides an interface between Common Lisp and the X window system. All versions of Allegro CL include a compiled version of CLX with the distribution. The fasl file is code/clx.fasl, loaded by evaluating (require :clx). The Allegro CL products CLIM and Allegro Composer use CLX. Users wanting low-level access to an X server in Lisp may also want to use CLX. CLX is not supported by Franz Inc.

The sources to CLX are supplied with the regular Allegro CL distributions in the contrib/clx/ directory. Note that during installation, you are asked whether you wish to install the contrib/ directory and the default is not to install it. The contrib/ directory is not included in the Trial distribution, but Trial users can download the CLX sources from the Franz Inc. website as described next.

The sources to CLX are also available on the Franz Inc. web site (franz.com), at the location ftp://ftp.franz.com/pub/clx/.



12.0 Release notes for Orblink

No significant changes.



Appendix A: ANSI Conformance in Allegro CL

We discuss ANSI conformance in Conformance with the ANSI specification in implementation.htm. Elsewhere in implementation.htm we discuss specifics of our implementation of certain Common Lisp functionality.


Copyright (c) 1998-2017, Franz Inc. Oakland, CA., USA. All rights reserved.
This page has had significant revisions compared to the 10.0 page.
Created 2017.2.15.

ToCDocOverviewCGDocRelNotesFAQIndexPermutedIndex
Allegro CL version 10.1
Significantly revised from 10.0.
10.0 version