Release Notes for Allegro CL 7.0

This document contains the following sections:

1.0 Introduction

This document provides the release notes for release 7.0 of Allegro Common Lisp and related products. Many sections are divided into non-backward-compatible changes (that produce different behavior in release 7.0 compared to release 6.2) 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 6.2 Release Notes, included in this distribution as the file version-62-release-notes.htm.

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

• Section 6.1 New features in the base Lisp: this section describes new features.
• Section 6.2 Non-backward-compatible changes in the base Lisp: this very important section describes changes to Allegro CL which are not backward compatible. You may have to modify your source code in light of these changes.
• Section 8.1 Non-backward-compatible changes in Common Graphics: [Windows customers only] this section describes changes to Common Graphics which are not backward compatible. You may have to modify your source code in light of these changes.
• Section 9.1 Non-backward-compatible changes in AllegroStore: [AllegroStore customers only] this section describes changes to AllegroStore which are not backward compatible. You may have to modify your source code in light of these changes.
• Section 2.0 Information on changes and new stuff since the 7.0 release: this section describes material added after the initial Allegro CL 7.0 release, along with other post-7.0 changes.

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 7.0 release

There have been numerous documentation updates. See http://www.franz.com/support/documentation/.

A 7.0 Trial edition was released around August 8, 2005. This version is similar to the 6.2 Trial (in that it is a limited version of a full-featured Allegro CL). 7.0 Trial requires monthly rather than bi-monthly license renewal.

These changes have been made with updates or patches released around the date indicated in the item. Patches can be downloaded with sys:update-allegro.

1. sys:update-allegro now allows specifying proxy username and password. This change is made in a June, 2006 update. There has long been a proxy keyword argument to sys:update-allegro, the function that downloads updates and patches for Allegro CL. This argument allows downloading when using a proxy. However, sometimes the proxy also needs a username and passowrd. A new keyword argument, proxy-basic-authorization, allows these to be specified as well. See sys:update-allegro.
2. ntservice facility provided: an update released in early June, 2006 allows you to make your application a service on Windows. See Turning your application into a Windows Service in delivery.htm. There is an example (after the update is complete) in examples/ntservice/.
3. A jLinker release in early June, 2006. This update makes jLinker identical in Allegro CL 7.0 and 8.0. There are changes in jlinker-listen (new :abort value for the stop argument); jlinker-init (new report keyword argument); def-java-class (new possible value for the name); def-java-constructor (documentation clarification); jlinker-slot (new value for the key argument); and a new variable *jlinker-deprecated-warnings*. (Also minor changes in jarray-set, jdo-call, jmake-new, jcons, jmeth, jget-cons, jget-meth, and jarray-set.)
4. A SOAP update was released in late February, 2006. It makes minor changes and corrections to the SOAP update listed below. One documentation correction should be noted: the default for the :nillable option (to operators like soap-message-client) is :ignore (making it compatible with earlier versions). The earlier documentation update incorrectly said the default was :accept.
5. New SOAP update make 7.0 and 8.0 compatible. A SOAP update around 2/3/06 makes SOAP in Allegro CL 7.0 the same as SOAP in Allegro CL 8.0. See the Allegro CL version 8.0 Release Notes for SOAP (www.franz.com/support/documentation/8.0/doc/release-notes.htm#soap-release-1) for a description of the changes in the new update (equivalent to the changes moving to release 8.0).
6. New support for constructing MIME messages. See MIME support in imap.htm for more information. See particularly the new function make-mime-part. send-letter, send-smtp, and send-smtp-auth have been enhanced to allow files or streams (as well as a string) as the value of the message argument. send-letter also now accepts an attachments keyword argument.
7. New support for pipe streams: See make-pipe-stream, make-function-input-stream, and with-function-input-stream. (The new pipe streams are somewhat more flexible than the one provided by pipe.)
8. New function base64-encode-stream. See the description of base64-encode-stream and see Base64 Support in miscellaneous.htm for information on Base64 and Base64 support in Allegro CL.
9. New OLE/OCX interface: a new, high-level interface to OLE/OCX on Windows was released in early September, 2005. The documentation is in the revised ole.htm.
10. Blowfish encryption update: released approximately 8/28/05. The update (1) allows specifying the external format to be used when encrypting and decrypting; (2) adds support for CBC encrypting, for PKCS#5 padding, and zero (or null) padding for plaintext with no nulls; and (3) also adds new auxilliary functions hex-string-to-usb8-array and usb8-array-to-hex-string. See Support for Blowfish encryption in miscellaneous.htm.
11. New prolog release: released approximately 8/28/05, with new documentation prolog.html.
12. Update to an Allegro CL/SOAP API. There was a significant new SOAP release by a patch (named the soap.002 patch) around July 18, 2005. This update included the following enhancements:
    • CLOS wrappers for SOAP structures
    • built-in definitions for many Schema types
    • new warning hierarchy
    • new condition hierarchy
    • access to element attributes in SOAP messages
    • attribute values may be computed when message is composed
    • top-level multiRef handling
    • multiple SOAP Body elements
    • access to encoding and content-type headers
    • complete access to all the message components
    • user extensions to WSDL code generators
13. New functionality for retrieving DNS TXT records. The function socket:dns-query now accepts :txt as a value for the type keyword argument. When :txt is specified, the answer provided by socket:dns-query will be a list of one or more strings (because TXT records can be composed of multiple strings), or nil if there are no TXT records. See also dns.htm. This functionality was added by a patch released approximately June 15, 2005.
14. ftp-stream-file-mod-time and ftp-file-mod-time now convert the remote-path argument to Unix syntax pathname naming; map-over-ftp-directory now works on Windows. ftp-file-mod-time and ftp-stream-file-mod-time both take a remote-path argument which is a pathname namestring. ftp functions only understand Unix pathname syntax, using forward slashes to delimit directories. Windows uses backward slashes to delimit directories and functions like cl:directory called on Windows returns pathnames with backward slashes in their namestrings. ftp-file-mod-time and ftp-stream-file-mod-time now convert those namestrings to Unix syntax using the new syntax keyword argument to cl:namestring (see cl:namestring in implementation.htm). Functions such as map-over-ftp-directory, which call ftp-stream-file-mod-time, now also work correctly on Windows. (Patch release around November 5, 2004.)
15. New :syntax keyword argument to cl:namestring converts backslashes into forward slashes. The cl:namestring function has a new keyword argument, syntax. The argument is ignored on Unix and Unix-like platforms. On Windows, when nil (the default), cl:namestring behaves as always and when :unix, cl:namestring converts back slashes in the namestring to forward slashes.

    This feature is useful for ftp functions since ftp only understands Unix pathname syntax (using forward slashes). Functions like map-over-ftp-directory called on Windows generates pathnames of the files in an ftp directory, but these generated pathnames use Windows syntax (with backward slashes delimiting directories). In order for these pathnames to be used in calls to other ftp functions, such as ftp-stream-file-mod-time, they must be first converted to Unix syntax. Users writing their own mapping functions for ftp directories may find this added feature of cl:namestring useful. See cl:namestring in implementation.htm. (Patch release around November 5, 2004.)

16. Aodbc update: an update released early in 2005 provided the ability to set the non-blocking flag in a database. See connect and db-non-blocking.
17. Oracle-direct update: an update released early in 2005 provided some additional functionality for the Oracle Direct interface. See oracle-interface.htm.

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

3.1 All pre-7.0 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 7.0 (including 7.0 Beta) will not load into Allegro CL 7.0. All such files, including all 7.0 Beta 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:

• the architecture (hardware) is the same
• the calling convention is the same (that is, the method of calling functions and the registers they use for arguments are the same)
• the method for generating signals can be made compatible (this cannot be done for Windows and UNIX, so they are incompatible for this reason)

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 7.0 uses the 6.2 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

Allegro CL 7.0 is known to work with the following minimal operating system versions. Allegro CL 7.0 runs on all operating system versions released (not in beta or pre-release form) as of October 15, 2004. See below for places to obtain information on operating systems released after that date.

32-bit platforms

• HP Tru64 UNIX 5.1 -- see Section 5.3 HP Alpha running Tru64: default stack size should be increased
• HP-UX 11.00 -- see Section 5.4 Notes of increasing the default maximum stack size on HP-UX 11 machines
• FreeBSD 5.2
• Linux (x86), glibc 2.2
• Linux (PPC), glibc 2.3
• Apple Mac OS X 10.3 -- see Section 5.5 Mac OS X notes
• Microsoft Windows 98/Me and 2000/XP/Server 2003
• IBM AIX 5.1
• Sun Solaris 2.8 -- see Section 5.2 OS patch needed for Solaris 2.8 on Sparcs

64-bit platforms

• HP Tru64 UNIX 5.1 -- see Section 5.3 HP Alpha running Tru64: default stack size should be increased
• HP-UX 11.00 -- see Section 5.4 Notes of increasing the default maximum stack size on HP-UX 11 machines
• Linux (AMD64), glibc 2.3 -- note: runtime analyzer does not work, see Section 5.1 Runtime Analyzer does not work on AMD 64-bit processors: Solaris 10 or Linux
• IBM AIX 5.1
• Sun Solaris 2.8 -- see Section 5.2 OS patch needed for Solaris 2.8 on Sparcs
• Sun Solaris 10 on AMD 64, Release 8/30/05 -- note: runtime analyzer does not work, see Section 5.1 Runtime Analyzer does not work on AMD 64-bit processors: Solaris 10 or Linux

Franz Inc. cannot maintain the same release schedule as the many operating system providers on the many platforms we support. Usually Allegro Common Lisp and all of its component parts will work on new Operating System versions that become available after release. But sometimes Allegro CL patches or operating-system patches, or installation tweaks, will be required before Lisp will run on an updated system.

Franz Inc. usually finds out about any such issues soon after new operating system releases appear and devises any necessary patches or compatibility procedures. We maintain current information about operating system versions on this web page: http://www.franz.com/support/osinfo.lhtml. We strongly advise you to check that page before updating your operating system. If we know that the new operating system is compatible, or is compatible with certain patches, you will find the information there. Similarly if it is known to be incompatible. If the new operating system is not yet listed it may be that it has not yet been tested.

5.1 Runtime Analyzer does not work on AMD 64-bit processors: Solaris 10 or Linux

The Runtime Analyzer (see runtime-analyzer.htm) does not work on AMD 64-bit processors. This is the processor used for 64-bit Allegro CL on Linux (released when Allegro CL 7.0 was released) and 64-bit Allegro CL on Solaris 10 (released 8/30/05).

There seems to be an incompatibility with the runtime analyzer algorithm and the AMD 64 hardware. There is no solution at this time.

5.2 OS patch needed for Solaris 2.8 on Sparcs

A problem with Solaris 2.8 where calls to run-shell-command can cause Lisp to hang is fixed by operating system patch 108993-18 (which supersedes the earlier patch 108827-36 for this problem). On Solaris 8, it can also be fixed by adding /usr/lib/lwp to the front of your LD_LIBRARY_PATH environment variable. No fix is necessary for Solaris 2.9. (The problem also affects Solaris 2.6, where an OS upgrade is needed and Solaris 2.7, fixed by patch 106980-21, but Allegro CL 7.0 is not supported on Solaris 2.6 or 2.7.)

The patch can be obtained from this Sun website: http://sunsolve.sun.com/search/document.do?assetkey=1-26-49843-1.

5.3 HP Alpha running Tru64: default stack size should be increased

The default stack size limit on an Alpha is 2 Megabytes, which is too low for normal stack overflow handling. Doing

 limit stacksize unlimited

in a csh shell seems to allow up to 16 or 32 Mb, and users can run that command before running Allegro CL. (That command could be put into a .cshrc file.)

However, that only solves the problem for Allegro CL processes that are started from within that shell. You can also change the default for the machine as a whole by doing something like the following. (This procedure is provided as an example of what might work. Please check your Tru64 system documentation or contact your HP service representative for the precise instructions.)

The procedure described here is best performed by a system administrator or similarly trained person. The vmunix file created and copied at the end is the UNIX kernel. Modifying it incorrectly or corrupting it can have serious consequences.

1. Log in as root. You must be root (or have superuser privileges) to perform most of the following operations.

2. Change into the /sys/conf/ directory.

  prompt# cd /sys/conf

3. Edit the file whose name is the machine name, which we will call MACHINE_NAME, as follows. (Such a file typically exists after normal Tru64 Unix install. If the file does not exist, the System Administrator will have to create one.

Change the line 

           dfssiz         2097152
to
           dflssiz         8388608
or
           dflssiz         16777216

The value of dflssiz may already be different than 2097152, which is 2 megabytes -- (* 2 (expt 2 20)). The new suggested values are 8388608, which is 8 megabytes and a good value for 32-bit Lisps, or 16777216, 16 megabytes and a good value for 64-bit Lisps.

4. Run /usr/sbin/doconfig as follows (recall that MACHINE_NAME is the file in /sys/conf whose name is the machine name):

 prompt# /usr/sbin/doconfig -c MACHINE_NAME

You should see output similar to:

*** KERNEL CONFIGURATION AND BUILD PROCEDURE ***

Saving /sys/conf/MACHINE_NAME as /sys/conf/MACHINE_NAME.bck

Do you want to edit the configuration file? (y/n) [n]: n


*** PERFORMING KERNEL BUILD ***
	Working....Thu Oct  4 09:58:16 PDT 2001

The new kernel is /sys/MACHINE_NAME/vmunix

5. Copy the new kernel to / with a command like the following

prompt# mv /sys/MACHINE_NAME/vmunix /

6. Reboot the system.

5.4 Notes of increasing the default maximum stack size on HP-UX 11 machines

Increasing the default maximum stack size on HPUX 11 requires modifying kernel configuration parameters, then rebuilding the kernel. This process should be done by the systems administrator.

The file /stand/system is the kernel configuration file. The maxssiz and maxssiz_64bit tunable parameters need to be increased to at least 32MB each. If you don't have any references to maxssiz or maxssiz_64bit in your /stand/system file, then you can simply add these lines to the bottom of the file:

maxssiz         (32*1024*1024)
maxssiz_64bit   (32*1024*1024)

Otherwise, you'll need to modify the existing parameters so that they express a value >= 32MB.

After modifying /stand/system, the kernel needs to be rebuilt using the following command:

/usr/sbin/config -u /stand/system

The system will have to be rebooted for the changes to take effect.

5.5 Mac OS X notes

Allegro CL 7.0 is not supported on Mac OS X version 10.0. You must use version 10.3.

There are two other issues:

1. Section 5.5.1 Increasing stack size on Mac OS X version pre-10.4
2. Section 5.5.2 Building shared libraries on Mac OS X

5.5.1 Increasing stack size on Mac OS X version pre-10.4

In versions of Mac OS X prior to 10.4, the default stack size limit on (apparently 512 Kbytes) is too low for normal stack overflow handling. This is not a problem on Mac OS X version 10.4 or later.

In earlier version, doing

limit stacksize unlimited

in a csh shell seems to allow up to 16 or 32 Mb, and users can run that command before running Allegro CL. (That command could be put into a .cshrc file.)

However, that only solves the problem for Allegro CL processes that are started from within that shell. You can also change the default for the machine as a whole by doing something like the following. (This procedure is provided as an example of what might work. Please check your Mac OS X system documentation or contact your Apple service representative for the precise instructions.)

The procedure described here is best performed by a system administrator or similarly trained person. The /etc/rc file edited during the procedure is key to correct operation of the Operating System. Modifying it incorrectly or corrupting it can have serious consequences.

1. Log in as root. You must be root (or have superuser privileges) to perform most of the following operations.

2. Get access to the command line shell on the computer. This can be accomplished by launching the Terminal application.

3. Open up the file /etc/rc with a text editor.

4. Add the following lines near the top of the file (the values shown, 8m and 10m, should be suitable for Allegro CL applications):

 
limit stacksize 8m
limit datasize 10m

The actual contents of the file differ on different machines and setups. Here is an example of a suitable location: just before the following lines:

    ##
    # Handle arguments passed from init.
    ##

    BootType=$1; shift;

    if [ -z "${BootType}" ]; then BootType="multiuser"; fi

5. Save the file /etc/rc.

6. Reboot the machine.

5.5.2 Building shared libraries on Mac OS X

Building shared libraries

Building shared libraries on Mac OS X 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.6 Heap start locations

When building large new images, it is often useful to specify Lisp Heap and C-heap start locations. See the discussion of the lisp-heap-start and c-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 7.0 as delivered. Values are Hexadecimal integers.

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

We have added a number of new capabilities to Allegro CL. Here we give links to the documentation of the new features.

The features described in Section 6.1.1 Features added to Allegro CL 6.2 after the initial release of Allegro CL 6.2 were released originally as patches to Allegro CL 6.2, but after the initial release of Allegro CL 6.2. The features described in Section 6.1.2 Major new features in Allegro CL 7.0 are new in the Allegro CL 7.0 release.

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

New shell module

The shell module is intended to provide UNIX shell-like commands, such as you find on a modern UNIX system, and in addition short cuts for some common Perl idioms. This module does not provide functionality to spawn a shell (as older functions like run-shell-command and shell and newer ones like command-output do). Instead, many commands that are available in a shell are available in this module. These commands are available on UNIX and Windows and work in a uniform fashion whatever the actual operating system. No external programs are used to implement the functions in this module, and as a result security issues associated with executing external programs by spawning shells are finessed.

Associated with the shell module is a new implementation of system:with-command-line-arguments. The new implementation is backward compatible, so current calls to the macro will work as before. The new implementation provides more options and the ability ro use long form options.

See also Pathname wildcard syntax in pathnames.htm. This newly added section provides information on how wildcard characters (like * and ?) in pathnames are handled.

Allegro FTP Client

The Allegro FTP Client module has been improved. Various versions of this software have been previously available (as described in the documentation, ftp.htm). The module can be used to communicate with an FTP server. See ftp.htm for more information.

Allegro MySQL

MySQL is a powerful, efficient, production ready open-source database that runs on all popular platforms. There are language bindings for most popular languages. A new module, described in mysql.htm provides an interface from Allegro CL to MySQL.

Note that the module has undergone changes since its original release and there are additional changes in the 7.0 release. One change provides improved handling of external formats. connect now has an external-format keyword argument and the function mysql-external-format polls (and with setf sets) the current external format for a connection.

New OSI (Operating System Interface) Module

A new module, :osi provides more connections to Operating System functionality. The new module is described in The Operating System Interface (OSI) module in os-interface.htm. The goal of the OSI module is to provide a Lisp layer for operating system services available on the platforms on which ACL runs. The operators, constants, and classes of the new module are not described (in this documentation release) on individual documentation pages. Instead, the descriptions are in Operating System Interface Functionality in os-interface.htm.

As part of the changes introduced by the new OSI module, the following functions have been changed (by adding new keyword arguments, so current calls are unaffected):

• copy-file (new remove-destination and force keyword arguments)
• delete-directory-and-files (new force keyword argument)
• run-shell-command (new directory keyword argument).
• cl:open now accepts :always-append as the value of the if-exists and if-does-not-exist. This value means that concurrent writes by any number of programs will always write to the end of the file. This is useful for writing to log files. Be warned, however, that changing the file position of a stream opened with :if-exists :always-append or :if-does-not-exist :always-append will have no effect. See the description of the implementation of cl:open in Extensions to cl:make-package, cl:disassemble, cl:open, cl:apropos in implementation.htm.

Modification to acl-socket:dns-query

acl-socket:dns-query has been modified. There are two modifications: one causes a fourth value to be returned. That value is a list of the flags returned by the dns server that replied to the query. The second modification allows the value :any as a value for the type keyword argument (see the description of acl-socket:dns-query for further information). The change is essentially backward compatible (unless your code depends for some reason on exactly three values being returned by acl-socket:dns-query).

Also, the documentation of acl-socket:dns-query has been clarified to make clear when the type is :ptr, name can be an integer IP address or a string containing a dotted IP address (the documentation previously incorrectly said name could only be an integer IP address when type is :ptr).

An Allegro CL/SOAP API

SOAP was released in Allegro CL 6.2 in stages. The initial release with 7.0 includes various things not in the 6.2 releases. See Section 10.0 Release notes for SOAP for details.

An upgrade to the Emacs-Lisp Interface

There is a new version of the Emacs-Lisp interface. Among others things, the patch improves menus for Emacs 21 and later, and offers the option of complying with the major mode conventions outlined in the GNU Emacs Lisp Reference Manual, edition 2.5. See the new section Significant changes in the interface in eli.htm for more information. Some miscellaneous fixes are listed in Section 14.0 Release notes for The Emacs/Lisp interface.

A validating parser for XML 1.0 and XML 1.1 in the new SAX module.

The new sax module, described in sax.htm, provides a validating parser for XML 1.0 and XML 1.1. The interface to the parser based on the SAX (Simple API for XML) specification. Users provide methods for the various generic functions that implement the parser.

The asdf system definition facility now included with Allegro CL

The popular system definition facility, asdf, is now included with Allegro CL. Evaluate (require :asdf) to load it into a running Lisp. See [Allegro directory]/code/asdf.readme for more information, [Allegro directory]/code/asdf.license for the license, and [Allegro directory]/src/asdf.lisp for the source code.

Allegro Webactions

Allegro Webactions is a dynamic web page generator facility designed to be used with AllegroServe. Please see webactions.html and using-webactions.html.

6.1.2 Major new features in Allegro CL 7.0

The most significant addition in Allegro CL 7.0 is a new model for multiprocessing. See Section 6.1.4 The new model for multiprocessing and OS threads in Allegro CL for more information.

Other new capabilities to Allegro CL are listed here, with links to the documentation of the new features. Some of these features have also been released as patches to Allegro CL 6.2.

1. Environments functionality: the document environments.htm describes the environments functionality added to Allegro CL in release 7.0. Based on the environments proposal described in section 8.5 of Common Lisp: the Language 2nd ed. (but not in the event adopted by the X3J13 standards committee), the environments functionality allows programmers to better define the current environment (or the environment that will be in effect when an application is fully loaded) to the compiler.

   7.0 note: environment support was added as a patch to Allegro CL 6.2. There have been some changes in the 7.0 release, particularly to function-information and augment-environment. 7.0 user familiar with the 6.2 version should look at the new descriptions.

2. Maximum array sizes are larger, new short array type allows using the old arrays as well. See Arrays and short arrays in implementation.htm for a definition of short arrays and a discussion of the array implementation in Allegro CL. The change means that type codes and the internal structure of arrays are now different. If your code depended on the old structure (if, for example, foreign code accessed and worked with Lisp arrays), your code may not work with the new arrays. In that case you can use the short arrays provided for this purpose. Also, the new larger (limit) arrays use an additional word of memory per array. If you are creating a very, very large number of (presumably small) arrays, this may be important and you may wish to use short arrays. Otherwise, there is no reason to worry about short arrays: just use the standard Common Lisp array functionality as always. Note that if you do use short arrays, most standard Common Lisp array functions will not work (aref, arrayp, and vectorp are exceptions); you use the newly-provided short array functionality. Read Arrays and short arrays in implementation.htm carefully to understand how array code must be modified when using short arrays. Also see Appendix G The effects of the new, longer array implementation on def-foreign-call and def-foreign-type for important information on def-foreign-type.
3. New Regular Expression API: the regexp2 module. A new, fast, PERL-compatible regular expression matcher has been added to Allegro CL 7.0. It uses PERL syntax and is 30% faster than PERL on the CL-CCPRE test suite. Regular expressions can use the Unicode character set (UCS-2). The older regexp module remains available. You may use both at the same time in the same running Lisp. Both modules are described in regexp.htm. The section The new regexp2 module describes the new API. (The older module, which has been available for some time, is described in section The older regexp API.)
4. Allegro Prolog: an implementation of Prolog within Allegro CL. Prolog is a backward-chaining, logical programming language. It is now implemented within Allegro CL. The file prolog.html provides the documentation. (The documentation does not describe Prolog iteslf: users are assumed to be familiar with Prolog.)
5. New interface to Oracle databases. A new interface to Oracle databases has been added to Allegro CL 7.0. The interface is described in oracle-interface.htm. The interface is similar to the Allegro ODBC interface (see aodbc.htm) and the MySQL interface (see mysql.htm), but is specialized for Oracle databases. While you must use the Oracle C Interface Libraries, no ODBC library is necessary.
6. Support for the Document Object Model. The Document Object Module (DOM) provides a progammatic interface to XML. The DOM implementation is connected to the SAX implementation mentioned above (both are part of the sax.fasl module). The DOM implementation is described in dom.htm.
7. New encoding functions in addition to the existing MD5 facility. For some time Allegro CL has supported MD5 encoding. In release 7.0, support for HMAC, RC4, and SHA1 encodings has been added. See MD5, SHA1, HMAC, and RC4 support in miscellaneous.htm. Note that the interface to the MD5 support function has been changed in release 7.0.
8. Additions to SWIG provided by Franz Inc. allow automatic generation of def-foreign-call forms. SWIG is a software development tool that reads C/C++ header files and generates the wrapper code needed to make C and C++ code accessible from other languages. See http://www.swig.org. See http://www.franz.com/support/tech_corner/swig042804.lhtml for specific information on the interface to Allegro CL and information on downloading the software. (The SWIG software is not included with the distribution because it is regularly updated. Users should always get the latest update.)
9. DBM support in Allegro CL. The :ndbm module defines various operators in the dbi.ndbm package providing support to the DBM database tools provided on UNIX machines. This is a simple database tool designed for simple, generally static data. The tools in Allgro CL access and manipulate these data, and have iterators to traverse the whole datbase. See ndbm.htm for more information. (This facility is not supported on Windows and currently does not work on HP 64-bit. It may be fixed on HP 64-bit with a later patch.)
10. Automatically inflating gzip-compressed files. The inflate module contains tools for creating a stream class which will automatically inflate gzip-compressed streams as they are read. See Support for gzip decompression in miscellaneous.htm for details.
11. New interface to OpenGL. OpenGL is an open graphics library. An interface to OpenGL from Allegro CL was generated by SWIG. Layered upon this interface are a GTK and Common Graphics (Windows-only) veneer. ../opengl/readme.txt has a brief introduction to the interface. More information is in these files: on the Common Graphics veneer: ../opengl/cggl/doc.txt (Windows only). More information is in these files: on the GTK veneer: ../opengl/gtkgl/doc.txt. (We also have an interface to GTK, mentioned above -- see ../gtk/readme.txt. The GTK veneer on OpenGL provides OpenGL additions in GTK style.)

6.1.3 Other new features in Allegro CL 7.0

1. Hash code may be larger in 7.0. The hash table implementation has been enhanced in Allegro CL 7.0 to allow for more bits of hash-code (24 on a 32-bit lisp, up from 16 bits, and 32 bits on a 64-bit lisp, also up from 16 bits). If you use the :hash-function extended option to cl:make-hash-table, you should note that instead of 16 bits, the hash-code generation may now be 24 bits on 32-bit architectures and 32 bits on 64-bit architectures. (This release notes entry was added after the initial Allegro CL 7.0 documenttaion release.)
2. *additional-logical-pathname-name-chars* allows arbitrary characters in logical pathname namestrings. As specified by the ANSI spec, words in logical pathnames must consist of alphabetic characters, decimal digits, and the minus sign. Not allowed are characters such as underscore (#\_). Users have found this restriction onerous and unnecessary. The value of a new variable, *additional-logical-pathname-name-chars* should be a list of character objects. These characters will then be allowed in logical pathname words. (Logical pathnames containing characters in *additional-logical-pathname-name-chars* which are not alphabetic characters, decimal digits, or the minus sign will not be portable, of course.) The initial value of *additional-logical-pathname-name-chars* is nil. See the description of *additional-logical-pathname-name-chars* and Logical pathnames: general implementation details in pathnames.htm for more information.
3. New condition syscall-error, now parent of file-error. syscall-error is a subclass of error. An error of type syscall-error might be signaled when there are problems with functions that interact with the operating system such as run-shell-command, shell, and chdir. syscall-error has one slot, errno, with accessor syscall-error-errno.

   As part of this change, the file-error is now a direct subclass of syscall-error, and only a subclass (but not direct) of error.

4. New condition winapi-error. winapi-error is a subclass of error. An error of type winapi-error might be signaled when there is a problem with the Windows API on Windows.
5. setf method for file-write-date. A setf method has been provided for file-write-date. It sets the modification time (the mtime in UNIX and the equivalent on Windows). See cl:file-write-date in implementation.htm.
6. New setf'able function excl:file-access-date. The new function file-access-date returns (or with setf, sets) the last access (read or write, including write-like utilities like touch) time of the file.
7. New command-line arguments +N and +Ti (on Windows) allow customization of tray menu items. +Ti removes Interrupt Lisp from the tray menu. +N  appname uses appname rather than Lisp in tray menu items. Thus +N Myapp will cause the menu item that is normally Interrupting Lisp to be Interrupting Myapp (and +Ti removes that item). See Command line arguments in startup.htm for information on command line arguments.
8. New command-line arguments +Cx and +Tx (on Windows) make it harder for users to accidentally close a running application. +Cx disables the Close button on the console window and +Tx disables the "Exit Lisp" menu on the system tray. These arguments are useful for applications that run in the background (an NT service application) and perform some useful function (e.g. implementing an NFS server). See Command line arguments in startup.htm for information on command line arguments.
9. New variable *system-messages* controls where load and autoload are sent. The value of the new variable *system-messages* should be an output stream, t, or nil. It controls where messages generated by load and by system autoloading are sent. Autoloading messages are now controlled by *load-verbose*, just as load messages are. If *load-verbose* is nil, no messages are generated by successful loads or by autoloads. (In earlier releases, it was difficult to suppress autoloading messages.) See Autoloading in implementation.htm for more information on autoloading.
10. New function console-control (Windows only) allows control over the console, system tray icon, and certain gestures. The function console-control only works if Lisp or a Lisp application is started with the Lisp console (i.e. the +c command-line argument is not specified). The function will display or minimize or hide the console, display or hide the system tray icon, and specify the action taken when the console close button is clicked.
11. New variable *pathname-customary-case* specifies the customary case for pathname functions. When the :case keyword argument to make-pathname, pathname-host, pathname-device, pathname-directory, pathname-name, and pathname-type is specified :common, the case of components is converted according to the value of *pathname-customary-case*. We recommend that users not specify a value for :case. If :case is unspecified, Allegro CL behaves as it did in previous versions.

6.1.4 The new model for multiprocessing and OS threads in Allegro CL

Processes within Lisp are now instances of a CLOS class that can be specialized to get customized behavior. Process objects mediate the programmer's access to threads. The programmer creates an instance of the process class (or of a subclass of the process class) in order to start a parallel computation. The computation's state can be inspected and modified through the use of functions that receive the process object as an argument.

Because processes are CLOS instances, the programmer can create specialized process classes whose instances contain application-specific attributes or behaviors. A server application, for example, could add slots to hold request queues or sockets or transaction-status data structures. After methods defined on initialize-instance and process-terminate could perform application-specific startup and shutdown actions.

This new model allows greatly simplified system design and implementation. It allows the programmer to treat the process and the server instance as a single object, instead of forcing a program structure in which they are two distinct things, one of which owns the other.

Stack groups no longer supported

The following functions are no longer defined:

• make-stack-group
• profile-stack-group-p
• stack-group-funcall
• stack-group-name
• stack-group-p
• stack-group-preset
• stack-group-resume
• stack-group-resumer
• stack-group-return
• stack-group-state
• process-stack-group: use process-thread.
• symeval-in-stack-group

Other removed functionality

• make-immigrant-process
• process-implementation: this macro expanded into a call to process-thread on :os-threads implementations and process-stack-group on non-:os-threads implementations. In 7.0, process-thread can be used in either model. Calls to process-implementation can be changed to calls to process-thread.
• process-flush. Use process-kill.
• excl:lisp-sleep. cl:sleep is now effectively mp:process-sleep always, making the process whostate "sleeping".

New functionality

• process-alive-p
• process-cpu-msec-used
• process-cpu-msec-used-delta
• process-keeps-lisp-alive-p
• process-os-id
• process-progn
• find-process
• process-terminate
• process-times-resumed
• process-times-resumed-delta
• mp:*general-wait-delay*
• process-message-interrupt-function

Other notes

• There can be only 350 simultaneously running processes. See The maximum number of simultaneous processes in multiprocessing.htm.
• *current-process* will be non-nil if the process code has been loaded, either during the build of the lisp image or by (require :process).
• start-scheduler now simply initializes some mp structures in both models. In the native-thread model, it opens the doors to immigrant threads.
• make-process now accepts a keyword argument :class to specify the class of the process to be created. This defaults to mp:process, but may be specified as an application-defined subclass of process.
• process-resume-hook/process-suspend-hook: note that in the native-threads model, a process can release the heap for another process to run even though the first process is not truly suspending. A foreign call can release the heap, after which it may block, e.g., in a GetMessage call in windows, or continue to process in the background outside the lisp heap. In the native-threads model the suspend-hook is called whenever a process releases the heap and the resume-hook is called whenever it reacquires the heap.
• process-run-function and process-run-restartable-function accept a keyword :class in the name-or-keywords argument to specify the process class to create (default being mp:process).
• process-reset function will signal an error if the kill argument is non-nil, or if the process is an immigrant. The latter can only happen in a native-threads lisp.
• process-kill now accepts a keyword argument :wait. If non-nil, the calling process waits until the killed process is really gone. process-kill signals an error if the process to be killed is an active immigrant. An inactive immigrant is one that was created to handle a lisp call from a foreign thread, and has returned from the topmost lisp call back into the foreign regime. The thread may still be processing, but it has no lisp state. This will kill the lisp process associated with that foreign thread, but will not kill the foreign thread itself. If it later calls into lisp, a new immigrant process will be created for it.
• process-interrupt: processing an interrupt function can be interrupted by additional process interrupts that occur before the current one has finished executing.
• start-customs: Should be replaced by a call to start-scheduler. The current version warns and calls start-scheduler when it is called unless the scheduler is already running. This function is here for compatability and will be going away some day.
• with-timeout: This is now also sys:with-timeout, and is available even when the process module is not loaded.
• process-allow-schedule: the optional process argument is ignored.

6.2 Non-backward-compatible changes in the base Lisp

1. simple-string, single-float, and double-float functions removed. These symbols, which name classes in Common Lisp, also named functions in earlier releases of Allegro CL (essentially doing (coerce x '[name]) or (string x)). Using these names for non-standard CL functions was never legal according to the Common Lisp standard. These functions have now been removed. Calls to the single-float or double-float functions should be replaced with calls to coerce, as in this example:

   (double-float 3) should be changed to (coerce 3 'double-float)
   (single-float val) should be changed to (coerce val 'single-float)
   

   If the compiler encounters calls to these function while compiling code, a warning of class incompatible-conformance-change-warning is signaled.

2. extloop.cl and oldloop.cl removed from the distribution. In releases prior to 7.0, the files extloop.cl and oldloop.cl were provided in the src/ subdirectory of the distribution directory. These provided compatibility with older versions of the loop macro. They have been removed in release 7.0.
3. Allegro Presto facility removed. This facility, which was a space-saving option in earlier releases is no longer supported. Since use of Allegro Presto was transparent (code worked the same whether or not the facility was enabled), its demise should not affect user code. However, in certain cases specifying the use of Allegro Presto (for example, to load or to build-lisp-image) will cause a waring to be signaled. See The Allegro Presto facility has been removed in loading.htm for more information.
4. The profiler has been renamed the runtime analyzer. Runtime analyzer more accurately describes what it does. The interface and API remain the same, except that the names of various IDE dialog and menu items have been changed.
5. Command-line argument functions ignore + arguments. This has in fact always been true but was not previously correctly documented. The functions that retrieve command-line arguments in a running image, command-line-argument, command-line-arguments, and command-line-argument-count, ignore + arguments and return no information about them. The + arguments are for Windows only and modify the Windows startup behavior of Allegro CL and generated applications. These arguments are transient in nature (e.g., one calls for the program to start minimized, while another suppresses the splash screen) and as such are not reflected in the command line arguments available from Lisp. Command line arguments in startup.htm lists all command-line arguments accepted by Allegro CL, including the + arguments.
6. Wait functions used by mp:process-wait may be called many times and may be called after they have already returned true. mp:process-wait determines when it should stop waiting by calling the wait function specified in the mp:process-wait form. This wait function may be called an arbitrary number of times and may be called after it has returned non-nil (that is, after it has already indicated that the waiting should stop). Because of this, wait functions with side effects should be coded very carefully.

   It has always been true that wait functions could be called oten and called after returning non-nil. However, multiprocessing changes in 7.0 mean that calling after returning non-nil is much more common, so wait functions with side effects that seemed to work okay in earlier releases may now cause problems.

   See the description of mp:process-wait for more discussion of wait functions and suggestions for efficient ones.

7. Format of value for :application-administration argument to generate-application changed. The value of the :application-administration keyword argument to generate-application (actually fully documented in Creating the deliverable in delivery.htm) is a list of elements of the form (type-keyword ...), where (type-keyword ...) could be (in earlier versions) (:resource-command-line "... command-line args ..."), which worked on UNIX only. Now (type-keyword ...) can be of the form (:resource-command-line "arg1" "arg2" "arg3" ...) (i.e. each argument in its own string) and this works on both UNIX and Windows.
8. New function function-name-p tests whether argument is a suitable argument for fboundp. As described in Appendix A.1 Conformance fixes which might break existing code, Allegro CL 7.0 has a number of changes compared to earlier releases to bring it into compliance with the ANSI specification in various areas. Some of these changes cause Allegro CL to signal errors where before no error would be signaled. One such change is that only valid function names are accepted as arguments to fboundp. In earlier releases, fboundp returned nil rather than signaling an error when passed an argument which was not a valid function name or specification. (Thus, e.g., (fboundp 3) returned nil rather than signaling an error.) The new function function-name-p returns true if its argument is a valid function spec (and thus a suitable argument to fboundp) and returns nil otherwise. (if (function-name-p spec) (fboundp spec)) thus behaves in release 7.0 as (fboundp spec) did in earlier releases.
9. :case argument to certain pathname functions no longer ignored. In releases before 7.0, Allegro CL did not implement pathname case, and the :case keyword argument to the make-pathname, pathname-host, pathname-device, pathname-directory, pathname-name, and pathname-type was accepted but ignored. Now :case is no longer ignored. See *pathname-customary-case*.
10. Fix to subseq means it will now signal error where it did not before. The form (subseq "a" 0 4) asks for a subsequence containing the first four elements of the sequence (string) "a", which, of course, has only one element. In earlier releases of Allegro CL, no error was typically signaled when the argument was a vector. Instead, a vector with garbage elements was returned. Now in 7.0 (and in 6.2 with a patch), an error is signaled. This may break code which improperly relied on the no-error behavior. The condition associated with the error is simple-error. The error message says Error: In subseq, `end' (4) is beyond the end of the sequence (1)., with (4) -- the value of end, and (1) -- the length of the sequence -- being replaced with the correct values for the call. See subseq.
11. Potential problems with foreign functions returning :int. def-foreign-call is defined to default its :returning keyword argument (specifying the expected type of value returned by the foreign call) to :int. :int corresponds to C's int type. However, if the foreign function does not actually return an int, subtle bugs could be introduced in programs, particularly if the C function returns a long, an unsigned long, or a pointer of some sort. In 32-bit Lisps, returning those values is not a problem (when :returning :int is specified or defaulted to) because int is always 32 bits on every architecture we support. But on 64-bit Lisps, if a 64 bit value is returned, the upper 32 bits are lost. If the value was not correctly sign-extended by the foreign code, a negative value in the foreign code could be seen by Lisp as a large positive value. A bug fixed by a patch in release 6.2 makes Lisp sign-extend values returned by foreign code in 64-bit Lisps, and thus values expected by the pre-patch behavior in 6.2 will now be different. So, on 64-bit Lisp, use :returning :unsigned-long when the return value is some kind of pointer. When it is an integer value, be sure to use the correct type and be sure that the foreign code actually produces that type.
12. Modified example in add-signal-handler makes clear signal() should never be called directly. The example in the description of add-signal-handler in earlier releases called the signal() function. This was a mistake and following the example could cause Lisp to fail on some platforms. User code should never call signal() but should call lisp_signal() instead. The corrected example calls lisp_signal().
13. When Lisp is started with a script: initialization files are not read; scripts that signal an error will exit with a non-zero exit status; new -#T command-line argument. As described in Starting on UNIX using a shell script in startup.htm, you can on UNIX start Lisp with a shell script. When you do this, no initialization files are read, as if Lisp was started with the -qq command-line argument. In earlier releases, initialization files were read and there was no way to prevent them from being read.

    Now when a script run using #! signals an error, it will exit with a non-zero exit status.

    The new -#T command-line argument for scripts is like the existing -#C argument in that the script is compiled, but the compiled script is placed in /tmp rather than the directory containing the script, and so the user need not have write permission in that directory.

14. New compiler style warnings. compiler-inconsistent-name-usage-warning is signaled when a tag or variable is unused (and the variable is not delared ignorable) or a variable is declared ignore but used. compiler-unreachable-code-warning is signaled when code cannot be reached (i.e. a clause after the t or otherwise in cond clause or a case).
15. New compiler switch verify-funcalls-switch. If verify-funcalls-switch is false, compiled code will be faster because the jump will be directly to the funcall'ed function's start address. Debugging and runtime analysis will be impaired, however.
16. The -H command-line argument removed. This argument was supposed to allow you to specify a directory to be the translation of the sys: logical host (the directory containing the Lisp executable is used by default). However, the argument did not work consistently and has been removed. See Command line arguments in startup.htm for a list of command-line arguments accepted by Allegro CL.
17. apropos now does case-insensitive search by default. apropos finds string pattern embedded in symbol names. Allegro CL has for some time supported an additional optional argument, case-insensitive, which controlled whether the matching was case-insensitive or not. That argument now defaults to t, meaning case-insensitive matching by default. (In earlier releases, case-insensitive defaulted to nil.)
18. equal on pathnames on Windows ignores case.
19. Minor change in (namestring (pathname ".")): it returns "./" instead of ".".
20. open, probe-file, truename, and rename-file-raw have new follow-symlinks argument, (delete-file (truename p)) deletes the actual file rather than the symbolic link when p is a symbolic link. truename now resolves symbolic links to the canonical filename. In earlier releases (until a 6.2 patch), it returned the symbolic link when presented with an argument that evaluated to a symbolic link. probe-file and open (when called with :direction :probe) return the truename when their file argument exists. The new argument (which defaults to t for truename, open, and probe-file and to nil for rename-file-raw) causes truename and the functions that call it (as all the others do) to resolve the symbolic link when true and to return the symbolic link when nil. This means that (delete-file (truename p)) deletes the actual file (prior to the 6.2 patch, it deleted the symbolic link only). (delete-file (truename p :follow-symlinks nil)) deletes the symbolic link. See rename-file-raw and Extensions to cl:make-package, cl:disassemble, cl:truename, cl:probe-file, cl:open, cl:apropos in implementation.htm
21. ipc module removed. Use the socket interface instead (see socket.htm).
22. directory given wildcards like */*.cl will ignore files which are symbolic links that point to other directories. This prevents directory from recursing into these symbolically named directories. For example, (directory "*/*.cl") will no longer, in the face of a `foo' symlink to a directory, would descend into `foo'.
23. Various defining forms no longer persistent after compile file. Defining forms like defmacro and defstruct can appear in a file compiled by compile-file. The question is, do the definitions persist in the running image after file compilation completes (absent eval-when instructions). In earlier releases, the persistence behavior was inconsistent (declaim, defpackage, defsetf, define-symbol-macro, persisted and defvar and defparameter partially persisted, but other defining forms did not). In 7.0, only defpackage persists. This means that code which depended on persistence of particular defining forms (typically in a second file to be compiled) will have to be modified. The typical modification is to wrap the defining forms which need to persist in a (eval-when (compile load eval) ...) form.

    It is likely the most common changes will invlove defvar and defparameter, because the associated special declamation which previously persisted no longer does. Thus the compilation of the file foo2.cl after compilation of foo1.cl signals a warning in 7.0 but did not in earlier releases:

    ;; file foo1.cl begin
    (in-package :user)
    
    (defvar *foo1* nil)
    ;; file foo1.cl end
    
    ;; file foo2.cl begin
    (in-package :user)
    
    (defvar *foo2* nil)
    
    (defun bar ()
      *foo1*)
    ;; file foo2.cl end
    
    cl-user(1): :cf foo1
    ;;; Compiling file foo1.cl
    ;;; Writing fasl file foo1.fasl
    ;;; Fasl write complete
    cl-user(2): :cf foo2
    ;;; Compiling file foo2.cl
    ; While compiling bar:
    Warning: Free reference to undeclared variable *foo1* assumed special.
    ;;; Writing fasl file foo2.fasl
    ;;; Fasl write complete
    

    The warning will not occur if either the defvar is wrapped in an eval-when -- (eval-when (compile load eval) (defvar *foo1* nil)) -- or a declaim form is added and wrapped in an eval-when -- (eval-when (compile load eval) (declaim (special *foo1*))).

    See Persistence of defining forms encountered by compile-file in compiling.htm for further details.

24. device-open now has three required arguments instead of two. In release 6.2, device-open had two required arguments, simple-stream and options. In 7.0, it has three. The initargs argument is essentially a new name for the old options argument. device-open now is similar to shared-initialize. (Programmers write methods for device-open when doing advanced stream work, so your code sees the arguments passed. Programmers do not call device-open directly. device-open methods must be modified because of the change in the number of required arguments.)
25. device-extend is no longer supported. Methods on device-extend should be changed to methods on device-read or device-write. See the description of device-extend to see how to ensure your application does not have any lingering device-extend methods.
26. New simple-stream strategy functions j-read-byte and j-write-byte. See Strategy descriptions necessary for encapsulation in streams.htm.
27. float-declaration-used-warning condition removed. The condition class named by the symbol excl:float-declaration-used-warning has been removed. In earlier releases, a warning was signaled when a variable was declared a float, rather than a single-float or a double-float. Because Allegro CL supports two floating-point types, declaring a variable to be a float could result in less than optimal code, because inlining of mathematical routines was not possible. However, there are other reasons to declare a variable to be a float, for example when methods are written on the float class and the program is telling the compiler that those methods apply to a variable. Warnings are inappropriate in that case, but (except for inconvenient additional programming) cannot be avoided. The :explain declaration can be used to ensure floating-point code is properly optimized. See Help with declarations: the :explain declaration in compiling.htm for further details on optimizing floating-point code.
28. Functions called by the :call option to search lists are now passed five rather than four arguments. The new fifth argument is check-lower-case, which will be non-nil if there are no lowercase characters in the target filename (in which case, trying the lowercase version of the target might be desirable). Code which uses functions and the :call option to search lists must be revised so these functions accept a fifth argument. The two supplied search lists are *load-search-list* and *require-search-list*. See Search lists in loading.htm for information about search lists.
29. MD5 functions have changed interface. The functions md5-update, md5-final, md5-string, and md5-file all have new argument lists. md5-update now accepts keyword arguments rather than a single optional argument (the optional argument was len, specifying how many characters from a string to operate on, the keyword arguments are start, end, and external-format). A three-argument call to md5-update is still accepted, with a warning.

    md5-final, md5-string, and md5-file all had a keyword argument :usb8-result added with a 6.2 patch. The argument has been changed to :result (with values :integer, equivalent to ':usb8-result nil'; :usb8, equivalent to ':usb8-result t'; and :hex, causing a string with a hex representation of the result to be returned). The :usb8-result argument is no longer accepted. md5-final now has additional keyword arguments which are passed to md5-update. md5-string and md5-update now accept (unsigned-byte 8) vectors as well as strings as arguments.

    See MD5, SHA1, HMAC, and RC4 support in miscellaneous.htm.

30. new-start-emacs-lisp-interface now start the interface on the Lisp side. The Lisp connection to the emacs-lisp interface is now made by the function new-start-emacs-lisp-interface. The obsolete older function start-emacs-lisp-interface is still supported to handle starting the connection with an old version of the interface. The change only affects the situation where you are starting the interface after the Lisp itself has started. (The usual way of starting the interface, with the emacs function fi:common-lisp, uses the correct Lisp-side function automatically.) If you are making the connection in such a fashion, you must use the new function instead of the old except in one anomalous situation: you are running Allegro CL 7.0 but using the 6.2 interface.

6.3 Other changes to and notes about the base Lisp

1. New pprint inspector option. The :istep top-level command (for navigating through inspected objects once the inspector has started) now has the option pprint. It causes the current object to be pretty printed. It is useful when multiple options are specified in a single :istep command, since intermediate is not printed. Interspersing pprint's among the specified options causes intermediate values to be printed.
2. dns-query now accepts a search keyword argument. (This change was introduced as an Allegro CL 6.2 patch.) dns-query now accepts a search keyword argument. It defaults to nil. If specified true, *dns-domain* and *domain-search-list* will be used to fully qualify the name argument before doing the query. dns-lookup-hostname (which simply calls dns-query) accepts the search keyword arguments since it accepts all dns-query keyword arguments.
3. New variable controls what kind of socket is created for the Emacs-Lisp interface. The value of the newly exported variable *eli-daemon-socket-hook* should be a function that accepts one argument and will initialize the socket that is used to communicate with Emacs when the Emacs-Lisp interface is started. See the description of *eli-daemon-socket-hook* for details.
4. Changes to delete-directory-and-files. This change was made in an OSI patch released for 6.2. excl:delete-directory-and-files changes: (1) add force keyword which causes read-only files on Windows to be forcibly removed (this is the default behavior on UNIX), (2) change the default of the quiet keyword to t, (3) change the default of the if-does-not-exist argument to :error, and (4) have the files removed in the proper order, so that subdirectories are emptied before their parents.
5. New :always-append value for :if-exists and :if-does-not-exist arguments to open. This change was made in an OSI patch released for 6.2. The if-exists and if-does-not-exist keyword arguments of cl:open now accept the value :always-append, which causes O_APPEND to be used when opening the file. (This only has meaning for if-does-not-exist when the file is opened for output.) This means that concurrent writes by any number of programs will always write to the end of the file. This is useful for writing to log files. Be warned, however, that changing the file position of a stream opened with :if-exists :always-append or :if-does-not-exist :always-append will have no effect. See the description of the implementation of cl:open in Extensions to cl:make-package, cl:disassemble, cl:open, cl:apropos in implementation.htm.
6. Changes to run-shell-command. excl:run-shell-command now accepts a directory keyword argument, the directory in which the command is run. It also accepts uid, gid, effective, and initgroups-user arguments on UNIX platforms.
7. Changes to copy-file. This change was made in an OSI patch released for 6.2. sys:copy-file changes: (1) add force keyword which causes the file to be removed if there is an error opening it, and (2) add remove-destination keyword argument, which causes all files to be removed, if they exist, before the copy is performed. A new verbose keyword argument has also been added.
8. excl:make-directory error reporting. This change was made in an OSI patch released for 6.2. excl:make-directory now properly reports a file-error condition, with proper errno information when an error occurs.
9. reap-os-subprocess now returns a third value: the number of the signal that caused the process to exit on UNIX/Linux platforms and nil on Windows platforms. When a process is reaped, the first two returned values are the exit status and the pid. An exit status of 0 does not by itself mean the process exited normally: the number of the signal must also be checked. This third return value allows this on UNIX and Linux. In cases where no process was actually reaped, the third returned value is nil. On Windows where signal information is not available, the third return value is always nil. See reap-os-subprocess for details.
10. New apropos-regexp function allows using regular expressions in apropos. apropos-regexp is an extension of apropos that interprets its first argument as a regular expression and uses it to perform the search of symbols.
11. New :force-compile defsystem long form module option. Specifying this option forces compilation by compile-system. See Long form module-specifications in defsystem.htm for a list of the long form module options.
12. Defsystem functions named by excl symbols have names exported from defsystem as well. Various defsystem functions have always been named by symbols in the excl package. These have now also been exported from the defsystem package. They include load-system, compile-system, map-system, show-system, concatenate-system, touch-system, and clean-system.
13. New format for the :explain declaration; new :tailmerging :explain quality. The format of the :explain declaration in earlier releases was (:explain :quality | :noquality), thus (declare (:explain :boxing :nocalls :notypes :variables)) enabled explaining for boxing and variables and disabled it for types and calls. That format is still supported, but its use is deprecated. Instead, use of the new format, (:explain :quality | (:quality t) | (:quality nil)) is recommended. (declare (:explain :boxing (:calls nil) (:types nil) (:variables t))) has the same effect as the old-style form above.

    There is a new :tailmerging quality for :explain. It explains why a function in the tail position is or is not tail merged.

    See Help with declarations: the :explain declaration in compiling.htm for more information.

    (:explain :types) also now provides environment information. See Explain types and calls in compiling.htm.

14. New +<number> command-line argument for Windows allows specifying the maximum console size. The size essentially controls the amount of text that can be displayed in the console. The argument is ignored on Windows 98 and Me, where the maximum size is 25,000 bytes and cannot be changed. On other Windows platforms, the default size is 100,000 bytes and this argument can specify a diffeerent value. On those platforms, the value can also be changed after startup with console-control. See Command line arguments in startup.htm for a list of command-line arguments accepted by Allegro CL.
15. The new function normalize-type takes a type specifier and returns a usually simpler type specifier. The function normalize-type is useful when specifying types for, say, arguments, when the argument may be one of various possible types.
16. Various function for determining locations, malloc'ing space, and freeing space. lispval-to-aligned-malloc-address and lispval-to-address provide information about the location of lisp values. aclmalloc-aligned and aclfree-aligned allocate and free space in the C heap but use alligned addresses.

    The new functions excl:malloc and excl:free are direct links to the system malloc() and free(). Note that space allocated with aclmalloc cannot be freed with free (you must use aclfree or aclfree-aligned) and space allocated with malloc cannot be freed with aclfree or aclfree-aligned (you must use free). Note further that malloc and free are different from the functions named by the symbols excl::malloc and excl::free in earlier releases. Those calls, if any exist in your code, must be changed to calls to aclmalloc and aclfree.

17. Some functions with an address argument now have an aligned optional or keyword argument indicating address is an aligned address. char*-strlen and short*-wcslen have an aligned optional argument. string-to-native, native-to-string, octets-to-native, and native-to-octets now have an aligned keyword argument. Functions like lispval-to-aligned-malloc-address return aligned addresses.
18. Backward-compatible change to add-stream-instance-flags: flags can be zeroed as well as set. If the first flag-name provided to add-stream-instance-flags is a list rather than a flag name, it should be a list of flag names and those are zeroed out before the remaining flag names, if any, are set. In earlier releases, this function could only set flags.
19. Changes to room output: pure space information now included. See the discussion of cl:room in Getting information on memory management using cl:room in gc.htm.
20. Variable *load-foreign-types* lists suitable type extensions for foreign files; new :foreign keyword argument to load. When a file has an extension listed in the value of *load-foreign-types*, then load will treat is as a foreign code file and act appropriately. The value is different on different platforms. To see the value of a platform you are using, evaluate this variable in a running Allegro CL image. The value should not be changed. You can, however, force a foreign load of a file with an extension not included in *load-foreign-types* by specifying a true value for the new (and non-standard) :foreign keyword argument to load. See Using the load function in loading.htm for details of the Allegro CL implementation to load.
21. Information about user-defined top-level aliases now included in :help output. Top-level alias definition can include a documentation string (like defun), and that string will be used by the :help top-level command when describing the new alias. :help will also list the alias along with system-defined top-level commands. See tpl:alias.
22. New conditions file-does-not-exist-error and autoload-file-does-not-exist-error. file-does-not-exist-error is signaled when load tries to load a file that does not exist and the :if-does-not-exist keyword argument to load is true. autoload-file-does-not-exist-error is signaled when the system tries to autoload a file that does not exist.
23. Install wizard now detects whether user has correct privileges to install the application. The install wizard is a tool useful for delivering applications on Windows. See Installation of your application on Windows using the Install Wizard in delivery.htm.
24. On Windows, sys:update-allegro now asks if you want to reboot immediately when a reboot is necessary. See sys:update-allegro.
25. Bug in chdir fixed. A bug where chdir did not accept a pathname argument has been fixed. The argument to chdir can be a pathname or a string.
26. Use of pathname-sans-file is deprecated; use path-pathname. path-pathname and pathname-sans-file do essenitially the same thing. Programmers should use path-pathname.
27. New OSI module functions with-os-open-file and stat-type. The with-os-open-file macro works like cl:with-open-file except it uses os-open instead of cl:open to open the file.

    The function stat-type returns a keyword describing the type of file object returned by functions like stat.

28. generate-application bug fixed. generate-application now properly replaces old Allegro CL shared libraries, and other files, if an existing directory is used.
29. :ssl-support is on *features* for platforms that support SSL. SSL is discussed in Secure Socket Layer (SSL) in socket.htm.
30. Emacs-lisp interface changes. There is better support for multiple emacs/lisp instances on Windows (see How to run two Emacs's connected to two different Lisps in eli.htm; ELI startup on Windows no longer uses hardwired port ranges; and start-emacs-lisp-interface no longer ignores the announce-to-file argument on Windows.
31. Trace output on Windows goes to the Emacs/Lisp interface listener if there is one. In previous versions, output sent to *trace-output* went to the console.
32. fasl files can be appended to #! scripts. See Starting on UNIX using a shell script in startup.htm for information on using scripts to start Allegro CL.
33. New functions string-to-base64-string and base64-string-to-string. The functions string-to-base64-string and base64-string-to-string add to the base64 support described in Base64 Support in miscellaneous.htm.
34. New function sys:lispval-storage-type replaces sys:pointer-storage-type. Calls to pointer-storage-type can be changed to calls to lispval-storage-type simply by changing the operator name. lispval-storage-type returns more specific information. It also accepts an optional argument which allows a list of suitable types to be returned.
35. Unadvising a fmakunbound'ed symbol is an error. This entry just notes that it is en error to unadvise functions named by symbols that have been fmakunbound. The consequences of doing so are undefined (but in some circumstances the result may be the symbol-function of the symbol is re-established). The fwrapper facility signals an error in this case. See fwrappers-and-advice.htm.
36. New function prefixp. prefixp takes two sequences as arguments and returns non-nil if the second starts with the first. The rturn value, when true, is the index in the second where the first ends (so (prefixp "foo" "foobar") returns 3). regular-expression matching (see regexp.htm) can do similar testing, this function is easier to use for very simple cases.
37. New functions install-string-input-character-strategy and install-string-ouput-character-strategy. The functions install-string-input-character-strategy and install-string-output-character-strategy replace the now-deprecated install-string-character-strategy.
38. New :include-locales argument to generate-application. If this argument is non-nil, the contents of the locales/ directory in the Allegro CL distribution are copied to the application directory. The size of the locales/ subdirectory is about 2 Mbytes. The argument is described in Creating the deliverable in delivery.htm, where generate-application is fully described.

6.4 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 7.0 release.

7.0 Release Notes for CLIM

The CLIM manual has been updated for the 7.0 release. These changes should be noted:

• clim-utils::dovector now evaluates :from-end argument at run-time in all cases. In earlier releases, the :from-end to argument internal CLIM function clim-utils::dovector was evaluated at compile-time, and so correct code was generated only in the case where the :from-end argument was a compile-time constant. In 7.0, the argument is always evaluated at run-time. Because this function is internal, it is not supported and may be changed without notice. However, it is unlikely to change and CLIM users are known to use it. If you do use it, please be sure to note that fact in comments to your code so you know to ask if additional changes have been made if there seems to be a problem.
• Only the region subclass of designs can be transformed, not the pattern subclass. The introduction to section 7.4 of the CLIM manual talked, in earlier releases, about transforming designs. The actual implementation can only transform regions. Regions are a sub-class of design and pattern is another disjoint sub-class of design. There are no methods implemented to transform patterns. The documentation has been corrected.
• postscript-prologue will emit integers for %%BoundingBox.
• use-line-style allows any line thickness.
• On Windows, a problem where selecting the menu-bar could causes text-field input to be lost has been fixed.
• On Windows, a problem where a text-editor pane sometimes failed to recognize the ENTER keystroke when typing very fast has been fixed.
• On Windows, make-pattern-from-pixmap has been implemented.
• On Windows, a menu accelerator can be any keystroke, not just a letter.
• On Windows, all cursor shapes are supported.
• :echo-character functionality has been added to text-fields.

(Repeated in part from 7.0 Release Notes.) The documentation for CLIM is in an online PDF file, clim-ug.pdf. It has been updated since release 2.0 and is called The CLIM 2.2.2 User Guide. That document includes material formerly in the (printed) CLIM Release Notes.

On Linux and FreeBSD, Allegro CLIM works with Open Motif 2.1 and 2.2 (2.2 was released in early 2002). Open Motif 2.2 is available at no charge from www.openmotif.org. Allegro CL 7.0/Allegro CLIM will work with either version. Redhat Linux 7.2 is supplied with Lesstif, a version of Motif that does not work with CLIM. See this faq item for information on how to install Redhat Linux 7.2 without lesstif and how to uninstall lesstif if already present.

On Mac OS X 10.3, OpenMotif Motif 2.2.2 is required. CLIM will not work with version 2.2.0.

Certain CLIM demos on Solaris 64 bit give segv or otherwise fail when displaying over the network, language environment must be set to C. This is a problem when running any Sun GUI (such as the CDE environment or the Gnome 2.0 interface) on a Solaris64 machine. When bringing up the environment, set the language/locale to "C". (On the login screen, there's an "Options" button, which displays a menu that has a "Languages" submenu. Choose "C". Note: the default value is typically "en_US".) The "C" setting can process all of the 64-bit font sets. However, difficulties arise when displaying over the network. If you are displaying on the monitor of the machine running Allegro CL (and CLIM), the demos work as long as the language/locale is "C". They typically do not work when displaying on a monitor over the network. As of this writing, there is no fix for the problem.

8.0 Release Notes for Common Graphics and the IDE (Windows only)

Common Graphics and the Integrated Development Environment have been significantly revised in release 7.0. The main revisions are as follows:

• New dialogs on startup: when you start the IDE for the first time, you are asked about where you want project files to be stored. There are several dialogs that appear.
• Splitting off the dde and the ide packages from the common-graphics package. DDE functionality has been moved to the dde module and the dde package. This allows you to use the DDE facility in an application without Common Graphics. See Appendix D Details of separating DDE code from Common Graphics for more details.

  IDE functionality (that is, that part of Common Graphics used to develop applications and design components used in those applications) has been moved to the ide module and the ide package. The ide module will not be loaded into applications. See Appendix B Details of Common Graphics/IDE package reorganization for more details.

• The CG classes have been reorganized. Some have been renamed, some removed, and some new ones have been provided. See Appendix C The reorganization of the CG class structure for details.
• Many obsolete functions etc. removed; others renamed. Some of the removed functionality was deprecated in earlier releases. Some was never in fact implemented or was not useful in user code. A list of removed and renamed functionality can be found in Appendix E Functionality/symbols removed or renamed in Common Graphics.
• Finely dividing Common Graphics into independent modules. This change is less user-visible: Common Graphics functionality has been dividied into several dozen modules. Only those needed for an application have to be loaded in, thus saving space in the application. Whenever a module is loaded, all other modules on which it depends are also loaded. As part of this change, most every module has associated with it a specific package. These have names like cg.icon and cg.tab-control. All symbols are also exported from the cg package (and so there is no need to use any of the new packages). You will occasionally see the packages referred to in descriptive output. cg is the parent package (in the sense of the Allegro CL hierarchical package naming scheme, described in Hierarchical Packages in packages.htm) of all the new packages. Note that cg is the proper name for what was previously called the common-graphics package. common-graphics is now a nickname.
• The compatibility module for the old Common Graphics function names from the 3.0.2 release of Allegro CL on Windows is no longer supported. Further, the aclwin and aclffi compatibility modules are no longer loaded by Common Graphics. See Appendix F Common Graphics compatibility with aclpc 3.0.2 has been removed for more details.

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 in release 7.0.

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), but note that certain function and argument names have been deprecated in favor of new names, and that new code should reflect these changes, and old code should be revised at some point.

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

8.1 Non-backward-compatible changes in Common Graphics

1. Use of subclass-widget and unsubclass-widget unnecessary. CG now internally calls subclass-widget on every os-widget instance. Applications can remove any calls to this function. Any leftover calls will now simply do nothing. unsubclass-widget is also unnecessary and should also be removed; calls to it too are now no-ops.
2. set-focus now properly called in all cases. We document that set-focus is always called when a window receives the keyboard focus, so that an application could add wrapper methods to track all focus movement. In fact set-focus was not called when interactively moving the focus to an os-widget. Now it is.
3. A function now loads CG source file information, rather than a file. In earlier releases, after obtaining the Common Graphics sources, you loaded the file src/cg/loadsfi.cl so the system would know where definitions of particular functions resided. In the new release, the file src/cg/loadsfi.cl has been removed and instead you call the new function load-cg-source-file-info. Also, IDE sources are now in src/ide/. CG sources are still in src/cg/. Source files are available to paying licensed customers, but you must sign a special license to get the key to decode the file provided on the distribution CD. Contact your Franz Inc. account manager for details.
4. cursor-size returns only two values. In previous releases, it returned four values but the third and fourth values were not useful.
5. The IDE no longer prompts for exit confirmation by default when the operating system is being shut down and there are no unsaved changes, since this was unusual behavior for an application and may have been annoying. The new IDE configuration option query-os-exit allows returning to the old behavior.

   Methods may be added to the new generic function os-exit-request to determine whether an attempted shutdown of the operating system (or logoff of the current user) is allowed to proceed. The related function query-end-windo