| Allegro CL version 7.0 Significantly revised from 6.2. | |||||||
This document contains the following sections:
1.0 IntroductionThis 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:
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.
This section is a placeholder for material added in documentation updates after the 7.0 release.
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.
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.
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.
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.
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 Compaq 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
dflssiz 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.
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.
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:
The default stack size limit on a Mac OS X machine (apparently 512 Kbytes) 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 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.
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.
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.
| Operating System | Lisp base | C base |
| Tru64 32-bit | 0x30000000 | 0x54000000 |
| Tru64 64-bit | 0x1000000000 | 0x2000000000 |
| FreeBSD | 0x10000000 | 0x64000000 |
| HP-UX 32-bit | 0x10000000 | 0x64000000 |
| HP-UX 64-bit | 0x8000001000000000 | 0x8000002000000000 |
| Linux (x86) | 0x71000000 | 0xa0000000 |
| Linux (PPC) | 0x40000000 | 0x74000000 |
| Mac OS X | 0x5008000 | 0x64000000 |
| Windows | 0x20000000 | 0x54000000 |
| AIX 32-bit | 0x30000000 | 0x64000000 |
| AIX 64-bit | 0x700001000000000 | 0x700002000000000 |
| Solaris 32-bit | 0x4000000 | 0x54000000 |
| Solaris 64-bit | 0x1000000000 | 0x10000000000 |
| AMD 64-bit | 0x1000000000 | 0x2000000000 |
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).
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.
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.
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.
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.
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):
: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.
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).
Allegro CL/SOAP now supports WSDL 1.1 and WSDL generation. Please see soap.htm for more information on Allegro CL and SOAP.
SOAP was released in Allegro CL 6.2 in stages. The release with 7.0 includes various things not in the 6.2 releases. See Section 10.0 Release notes for SOAP for deyails.
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.
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 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 is a dynamic web page generator facility designed to be used with AllegroServe. Please see webactions.html and using-webactions.html.
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.
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.
*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.
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.
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.
+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.
*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.
: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.
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.
The following functions are no longer defined:
mp:*general-wait-delay*
*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).
mp:process).
nil, or if the process is an
immigrant. The latter can only happen in a native-threads lisp.
(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.
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.
: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.
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.
*pathname-customary-case*.
(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.
: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.
-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.
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).
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.
t, meaning case-insensitive matching be
default. (In earlier releases, case-insensitive
defaulted to nil.)
"./" instead of ".".
: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
(directory "*/*.cl") will no longer, in the face of
`foo' symlink to a directory, would descend into `foo'.
(eval-when (compile load eval)
...) form.
It is likely the most common whange will invlove defvar and defparameter, because the associated special declamation which previously persisted no longer does. Thus the compilation of the file foo1.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 is 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.
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 to 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 in compiling.htm for further
details on optimizing floating-point code.
*load-search-list*
and *require-search-list*. See Search lists in
loading.htm for information about search lists.
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 argument
which are passed to md5-update. md5-string and md5-update now accept (unsigned-byte 8)
vectors as well as strings as arguments.
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.
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.
*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.
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.
: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.
file-error condition, with proper errno information
when an error occurs.
nil. On Windows where
signal information is not available, the third return value is always
nil. See reap-os-subprocess for details.
: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 in compiling.htm for more information.
(:explain :types) also now provides environment
information. See Explain types and calls in
compiling.htm.
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.
*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.
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.
The function stat-type returns a keyword describing the type of file object returned by functions like stat.
*trace-output* went to the
console.
nil if the second starts with the
first. The rturn value, when true, is the index in tyhe 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.
nil, the conetns 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.
There are no entries at this time. Information may be placed here in documentation updates after the initial Allegro CL 7.0 release.
The CLIM manual has been updated for the 7.0 release. These changes should be noted:
: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.
(Repeated 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 wokr when displaying on a monitor over the network. As of this writing, there is no fix for the problem.
Common Graphics and the Integrated Development Environment have been significantly revised in release 7.0. The main revisions are as follows:
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.
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 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.
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.
os-widget. Now it is.
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-windows-session has been renamed to os-exit-request to avoid a Windows-specific name.
dialog to frame-window. This change was made because the
dialog class is not defined in the now-smaller base cg module (and
because frame-window is a more fundamental type of window). Any call
to make-window that did
not pass a :class (or :device) keyword argument and that depended on
the window being a dialog should now specify ":class 'dialog".
common-graphics package to the
ide package). See
Appendix B Details of Common Graphics/IDE package reorganization for details of
the move of symbols naming IDE-specific functions from the
common-graphics package to the
ide package.
cg:*edit-allowed-types* has been removed. In the
IDE, use the new ide configuration option ide:file-dialog-source-types instead. That
variable used to supply the default for the allowed-types keyword
argument to ask-user-for-new-pathname or
ask-user-for-existing-pathname. Now
a suitable default for that argument is supplied in the definitions of
those functions. A value other than the default must be supplied as a
value to that argument in the function calls.
When the Save All dialog appears in a situation where the current project is about to be closed (usually because you are opening another project or creating a new one), then the second button on the Save All dialog will say Discard instead of No, and selecting that choice will result in unsaved changes to the old project being lost. The button will also say Discard at IDE exit time to similarly warn that choosing it will discard all unsaved changes.
*check-cg-args* and the menu command Run | CG
Argument Checking no longer exist. The IDE image used to contain
a special version of Common Graphics that differed in various ways
from the runtime Common Graphics fasl files, with one of the
differences being extra code for checking argument types (when
enabled). Now that a single version of Common Graphics is used, we
decided against embedding this debugging code to avoid making
standalone Common Graphics apps larger.
:editor-mode option/argument to defproperties, defcomponent, and define-property is now
called :editor-type. The corresponding generic
function property-editor-mode is now called property-editor-type. This was to
remove confusion with the IDE configuration option editor-mode (and to resolve a package conflict
with a corresponding internal symbol).
*text-edit-comtab*, which could
be modified to enhance the editor.
windows package but which were also exported from
the common-graphics package. (These were documented
with other common-graphics operators.) Starting in
release 7.0, they are no longer exported from the
common-graphics package. They are: memory-status, os-version-info, file-systems, file-system-type, file-system-info, and file-systems-info.
windows package (in earlier releases, it was the
common-graphics package). The symbols are not
exported from the common-graphcs package (as was
done in earlier releases for windows package
functions). The functions are: network-machines, network-shares, and directory-subdirectories.
directory-subdirectories has also been modified to accept a pathname namestring as well as a pathname object.
dropping-outline widget has changed
from nil to t. (The
value nil provides a speedup, but one that is
likely unnoticeable on modern machines.)
*clipboard*. The value of this
variable is the stack of lisp clipboard values that had been returned
by the function, which was an accessor of the *system* object.
po-erase, po-fill, po-invert (or po-xor), po-paint, and
po-replace
instead. The symbols erase,
invert, and paint have been
removed. (fill and replace are
common-lisp symbols and still exist, of course.)
(defun my-check-fixnums (&rest args)
(dolist (i args)
(if (null (fixnump i))
(error "Non fixnum ~S passed to my-check-fixnums" i))))
ide:*ide-startup-hook* instead.
cg:port-name has been removed.
cg:*show-dde-warnings* has been removed, replaced
by the variable *generate-dde-messages*. DDE messages are now
passed to the new overridable generic function dde-message, allowing an application to handle
or display the messages as desired. The DDE module has been separated
from Common Graphics. See
Appendix D Details of separating DDE code from Common Graphics.
load-project will work only in the IDE, not in a standalone CG application. To load code in a standalone app, simply use load to load fasl files.
*starting-ide*
is deprecated in favor of the more generally useful variable *ide-is-running*. *ide-is-running* is set to
t when the IDE has started.
cg instead of
common-graphics so that its new child packages such
as cg.list-view will not have overly long names.
common-graphics is retained as a nickname of the
package for backward compatibility reasons, but its use is deprecated.
It is recommended that common-graphics: package
qualifiers in user code be changed to cg: in case
the deprecated nickname is removed in the future.
Cut and paste methods have also been added for item-list widgets.
However, these functions no longer pass the action down to the bottommost selected-window. These functions now instead act directly on the window or widget that is passed to the function. The former behavior was not documented, and it is not clear that all applications would want this particular indirection. (The convenience functions copy-command, cut-command, and paste-command do still pass the action in this way though.)
The functions copy-selection and cut-selection no longer return the window in which the copy or cut was done as the first returned value, since this is now always the window that was passed in (as noted above). Instead, the value that was copied or cut is now the first value returned instead of the second. And a new second value is returned, which is the clipboard format of the value that was copied or cut.
paste-command,
paste-selection,
insert-command,
and insert-selection now return the
pasted object and its clipboard format rather than undefined values.
insert-command is
new. delete-selection returns true if a
deletion was done, and nil otherwise, rather
than undefined values. delete-command is now deprecated
because it simply calls delete-selection.
When cut-selection is called on a
rich-edit-pane
where no text is selected, nil is now
returned rather than a rich text string that contains no actual
(visible) text.
initial-pixmap-color-vector is identical to initial-palette-vector. However, both default-pixmap-color-vector and default-gray-pixmap-color-vector take no arguments while both default-palette-vector and default-gray-palette-vector take a single (system) argument. In fact, that argument is not needed and has for some time been ignored. The old functions still take that single argument. The new functions do not take any argument.
:palette-size and the palette-size method for pixmaps no
longer exist; for pixmaps, use the :bits-per-pixel
initarg and the bits-per-pixel generic function
instead. The function palette-size now applies only to
cg-streams, to
return the number of colors in the stream's palette.
lisp-widget, you create a window class
for the window holding the widget. In earlier releases, this window
class should be a subclass of both lisp-widget-window and lisp-widget-top-window. In
7.0, the only superclass should be lisp-widget-top-window (which is now a
subclass of lisp-widget-window).
bitmap-stream rather than a bitmap-pane. This serves the
same purpose without using a window that would not get shown anyway.
excl:*ignore-package-name-case*. The variable
should be set directly. The symbol
ignore-package-name-case was in the cg package but
has been moved to the ide package. The symbol still has a function
definition, but it is a no-op.
*cg-is-initialized*. And the
documentation for standalone-application has been
rewritten.
*default-cg-bindings* and a call to
event-loop. It
is particularly handy for testing Common Graphics code in a Lisp that
does not have the IDE loaded.
dialog-item
and timer
should not be needed by applications, and name should be used instead for
header-info
and tab-info.
tray-item
class and the new generic functions add-tray-item, remove-tray-item, in-tray-p, tray-item-icon, tray-item-tooltip, and tray-item-message allow a
Common Graphics app to add one or more icons to the system tray, with
custom mouse behavior.
The new generic functions reindent-region and reindent-single-line redisplay Lisp source text following Lisp indentation rules.
button widgets.
picture-button and multi-picture-button
property unpress-automatically will cause
any button that was pressed interactively to be unpressed just after
the widget's on-change function (if any) has
run. This is clearer than the obscure technique of returning nil from the on-change function to "reject" a
button press, causing the button press to be undone.
:after methods on button-info property setters.)
up-down-control increments by
different amounts as the mouse button is held down. See increment, where the
alternate value accepted for up-down-controls is discussed.
text-edit-panes and rich-edit-panes for a
specified string and return its location (string-search) or replace it with a
different string (string-replace).
server-port
class has been exported. It and client-port are the instantiable
dde port classes. dde-port is the superclass for the
dde port classes. You do not instantiate a server-port instance; this is done
by open-server. open-server now has a
server-port-class keyword argument allowing you
to specify the server-port class to open. It is often useful to
subclass client-port and server-port to allow
specialized dde-message methods.
:default to
use whatever is the default mouse cursor for that object. This is
also now the default value for windows.
nil when any of the coordinates were bignums. This
is fixed.
mci-wave-audio
device. mci-set-wave-options, a new
function, allows setting the audio quality and other options when
recording a wave file. There is a new example on the mci-record page which uses the new
operators.
tab-control.
*locale*
bound to an object's individual locale.
menu-item may now be a
pixmap in order to display an image rather than a string in the menu.
outline widgets is provided by the
new functions select-outline-item, selected-outline-item,
and focused-outline-item. The function
outline-item-parent may now be
passed an outline-item for efficiency rather
than the item's value. And the generic functions
first-visible-line, set-first-visible-line,
and number-of-text-lines now apply to
outlines.
grid-widget
class has been rewritten and expanded.
text-edit-pane or a rich-edit-pane; the
related (and already defined) character-index-at-position gives
the index given the position. Note that character-index-at-position returns
nil when the position is not visible in the
pane, as there is no way to determine the position in that case.
nil while the body of the without-on-change macro
executes. This change is backward compatible. (Previously, only one
widget could be specified.)
:centered argument to make-window allow specifying that a
window be centered over its parent or owner on creation, while center-window causes an
existing window to be centered over its parent or owner.
t rather than nil, so that the IDE's help facility will not reuse a
browser that you were using for something else. (The symbol naming
that function is now in the ide package, moved from
the cg package. See See
Appendix B Details of Common Graphics/IDE package reorganization for more
details on the package changes.)
dialog-item object for an os-widget but on the associated widget-window object instead for a
lisp-widget (or on both for
an os-widget on which
subclass-widget had been
called). Now these functions are called on both the dialog-item and the widget-window for any type of
widget, so an application could add methods for either type of object.
Actually, the "up" functions had not been called at all for os-widgets.
hotspot class.
The hotspot accessor that returns or sets the active region of the
hotspot has been renamed from box to hotspot-region, to reflect the fact that the
active region of a hotspot no longer need be a simple box. For
compatibility, the now-deprecated box and (setf box) methods for hotspots still exist, and
the :box initarg still works. The new generic
function region-box returns
the smallest rectangle containing a hotspot region. This rectangle is
suitable as the area to invalidate when a hotspot area should be
residplayed.
The cursor property now
applies to hotspots, so (setf cursor) or the :cursor
initarg may be used to associate a mouse cursor with a hotspot, which
removes the need for an application to change the hotspot dynamically
via mouse-in and mouse-out methods on the hotspot when
a different cursor is desired over the hotspot.
The generic function highlight-hotspot has an added keyword parameter
named off that indicates whether the highlighting
is being turned on or off. Custom methods that do not draw in po-xor mode can use this
argument to know whether to draw or erase the hotspot highlighting.
Any existing custom methods defined in applications must add the new
parameter.
Finally, the documentation for hotspot and various hotspot related functions,
including invalidate, has been
expanded and the bug has been fixed where a hotspot could be left
highlighted if you move the mouse cursor out of the hotspot and also
out of its parent window without any mouse-moved messages happening on the parent
window in the meantime.
prof:*granularity*. The
Max Samples widget sets the value of prof:*maxsamples*. See the description of
the Runtime
Analyzer Control dialog for details.
tab-control.
group-box, tab-control, all instantiable subclasses of
text-widget (static-text, editable-text, multi-line-editable-text, lisp-text, multi-line-lisp-text, and rich-edit), and combo-box. Note for a combo-box, an on-double-click function is useful
only when the typable property
of the combo-box is true, since otherwise the two clicks would simply
drop and undrop the drop-down list.
header-control.
nil, equivalent to zero) specifies that text will be
drawn horizontally, as usual. A non-negative integer value specifs the
nagle which the text will be rotated counterclockwise about the
upper-left corenr of the string when horizontal (thus 90 is vertical,
first letter lowest, 180 is upside down and 270 is vertical, first
letter highest). The new function font-angle returns the angle of a font. If a
font has a non-zero angle, draw-string-in-box should not be used to draw a
string in the font as the rotating may move the text out of the box;
standard Common Lisp output functions like format and princ should be used instead.
nil (the
default, preserving the old behavior), the menu command has
precedence. When non-nil, the comtab
command. In the IDE, this property is true, so comtab command override
menu shortcuts. See *text-edit-comtab*.
The bullets in this section discuss general changes. The subsections Section 8.3.1 The console window and tray icon in applications and Section 8.3.2 Opening projects from releases prior to 7.0 discuss more involved topics. See also Appendix B Details of Common Graphics/IDE package reorganization.
*standard-output* to the currently selected
IDE listener rather than the console. Any information that the IDE
had printed to the console, such as the generate-application call that
is made by File | Build Project
Distribution, will now appear in an IDE
listener instead.
Turning off the Enable Debugging of Runtime Errors (previously
called Allow Runtime Debugging) option for a project (see the
Build tab of the Project Manager
Dialog) had not actually removed the system tray icon for the
Allegro console window in the standalone app as claimed in earlier
releases. This is now fixed by internally passing the
+c command line argument to avoid creating the
console window at all in the standalone app.
If a project uses a custom icon for its standalone application, then that icon will also be used for the console window of the generated application and for the console's icon in the system tray (though these items typically are not present in a delivered application). Previously the Franz bust icon was used for the console.
The +t command line argument is no longer used in a special way by a Common Graphics app. A project had defaulted the +t command line argument for the console's title in its standalone application to "Initializing", and then Common Graphics had replaced that title with "Console" after the app finished starting up, to avoid a problem where the console title had appeared momentarily in the taskbar button for the app as it started up. This was actually not necessary when using the +cx argument to keep the console window hidden completely, or when using +c to avoid creating the console window at all, as is now done for projects, and so this hack has been removed.
When you open a project in the IDE for further development, and the project was most recently saved in a pre-7.0 release of the IDE, then a few project options will not be preserved, though these can easily be updated if needed on the Project Manager dialog. These options are:
:suppress-systray-icon to
:allow-runtime-debug, and has the opposite meaning
as before. The system tray icon will still appear when this option
is on, but that is no longer the significant feature of this option,
since the console will now automatically appear for debugging a
runtime error when this option is on, and so the system tray icon is
no longer needed for this purpose.
:allow-debug to
:allow-build-debug. When this option is selected,
it will now pass the build-debug keyword argument
to generate-application as
:interactive rather than as t. This allows actually debugging a build error that
has occurred, rather than simply seeing the error message in the
leftover console window after the lisp that builds the standalone
image has exited. This is more useful, but also entails leaving the
build console up on every build, even if no build error occurred. To
avoid confusion when the console does not exit, this option will no
longer be turned on initially when a project from an earlier release
is opened, and the option is no longer on by default for a new
project. The check-box widget also mentions that the console will not
exit, as a reminder.
Also, the new include-flags
value :debugger determines whether the debugger is
included in the standalone app, and there is a check-box for it on the
new Include tab of the
Project
Manager. It is included by default. In earlier releases the
project system always included the debugger. There are also
individual check-boxes for including the compiler and the top-level,
which had been mixed in with the list of CG modules. And a new
check-box for saving local name info.
There is a new Startup Action dialog that appears by default when the IDE starts up. It asks whether to open a recently-used project, open some other project, create a new project, or proceed without a current project. (This dialog may be disabled with the check-box near the bottom of the dialog, or on the Options dialog.)
It is now possible to run the IDE without a current project at all, which is what happens if the new startup dialog is disabled or canceled. A project may still be opened or created any time later in the usual way (with, for example the File | Open Project menu command). There is also a new toolbar button on the Project Manager dialog to close the current project without opening another one. You can tell whether there is a current project by checking whether a project name appears at the left end of the main IDE title-bar.
When creating a new project, the directory-choosing dialog first appears asking for a default directory for the project's files. A project's files do not have to placed into this directory, but having a default directory helps the IDE later to default the file-selection dialog to a directory that is appropriate for the project.
Additionally, the first time a project is created there will be an earlier invocation of the directory dialog asking for a default parent directory for all new IDE projects. This default parent directory is simply used as the initially-selected parent directory whenever a new project asks for a default directory for that particular project. This dialog will not reappear as long as the prefs.cl file is created and retained as usual, though the value could still be changed by setting the new project-parent-directory configuration option.
When creating a new form, the New Form dialog that asks for the window class to instantiate now has two additional widgets. One widget asks for an optional new subclass of the selected existing class, and the other asks for a name for the form. The name is used for the default filename for the form module, and so naming the form at creation time helps to avoid saving the form to a randomly-named file. This name is also used for the finder-function and maker-function that are generated for the form; if the dialog name is "foo", then the finder-function will be named foo and the maker-function will be named make-foo.
When a new form is created, an editor buffer is now always created immediately for the .cl file for user-written code for the form. Previously, this buffer was created lazily only when the first event-handler skeleton function was generated for a widget on the form (by clicking on an event-handler button in the inspector). This may have been confusing if you had decided to write some code for the form before this time. If you specify a new subclass for the form on the New Form dialog, then a defclass expression for the new form class is written into this buffer. Some new comments are also added to the top of this buffer to explain what it is for.
The new configuration option new-project-create-form will automatically create a form module when creating a new project; this replaces the no-longer-used option new-project-show-form, which still exists for compatibility but now does nothing; this option is no longer on by default. In earlier releases, a form window was always created when a new project was created, but the dialog asking for the window class to instantiate was not shown, and so the "dialog" class was always used. Now the dialog asking for the window class to instantiate will always appear when a new form is created.
The new-project-show-project-manager option is now true by default, since there is an option to not create or open a project at all, in which case the project manager will never appear.
The new configuration option open-project-show-files-in-editor will automatically show all of the source code files of a project in the IDE editor when the project is opened. The new option close-project-close-editor-buffers will close any unmodified editor buffers from a project when the project is closed. Those options are disabled by default, but may be enabled on the Project tab of the Options dialog (displayed with Tools | Options). The new option open-project-show-project-manager will show the Project Manager dialog whenever a project is opened. That option is enabled by default.
When a project is opened, the Inspector is now shown if and only if any of the project's forms are visible, in which case the first such form is inspected. Previously the Inspector was always shown when opening a project. When creating a new project, the Inspector is shown only if the new-project-create-form option is enabled; creating a new form always shows the inspector in order to inspect that form.
When the IDE is started up with an initial project to open, such as by clicking on a .lpr file in the Windows File Explorer, the IDE will no longer exit if an error occurs while initially compiling or loading the project. This also applies to the new functionality for selecting a project to open at startup time.
When changing the name of the current project on the Options tab of the Project Manager dialog, and the .lpr project definition file has already been written, a modal dialog will ask if you also want to rename the .lpr file to match the new project name. These names are the same initially, and so it may reduce confusion to keep them in sync.
When typing a package name into the package widget on the Options tab of the Project Manager dialog, the package no longer needs to exist beforehand. If a new package name is entered, the package will now be created automatically, and a minimal defpackage form for the package will be written to the generated .lpr project definition file for the project (as before) to ensure that the package is created when the project is opened or loaded into a later lisp session or standalone application. Also, the drop-down list of package choices for this widget no longer includes packages that exist when the IDE is starting up (except for cg-user); this is done to exclude built-in packages that aren't appropriate for user code.
When a source code file is added to the current project either with the Project Manager's "Add File" button or the editor's "Add File to Project" command on its right-button menu, and the file is not currently in the project's default directory (or some descendent directory of it), then a yes-or-no dialog will ask whether you want to move the file into the project's default directory. The file will be moved there automatically if you answer yes.
When saving a new IDE editor buffer for the first time, a yes-or-no dialog will first ask whether you want to add the new file to the current project. (This dialog will NOT appear if there is no current project, or for a form's editor buffer since that is already in the project.) If you answer yes, then the Save File dialog will default to the project's default directory, and the file will be added to the project after it is saved. If you answer no, then the Save File dialog will default as it otherwise would, which is generally to the directory in which a file was last selected in this dialog, and the file will not be added to the current project.
When clicking on the Components toolbar, then the frontmost visible form (if any) is brought all the way to the front. If there are no visible forms, then a dialog will tell you to first create or open a project.
The AllegroStore manual is available online in PDF format, allegrostore.pdf. A printed copy is available.
AllegroStore 2.8 requires a new version of ObjectStore (as described in Installation instructions and information for AllegroStore users in installation.htm).
The version of AllegroStore shipped with Allegro CL 7.0 is 2.8. The underlyingObjectStore database is "ObjectStore Release 6.1 Service Pack 1".
All 32-bit platforms should now be fully interoperable ("homogeneous") e.g. they can simultaneously share a database on a single server. There is no homogeneity with the HPUX 64-bit platforms because 32-bit and 64-bit platforms have different data representations. Databases can only be transferred between 32- and 64-bit platforms by using asdump and asrestore. Contact Franz Inc. support at support@franz.com if you need to do this.
There were various releases of the SOAP interface in Allegro CL 6.2. This section lists the changes from the two most recent SOAP updates.
soap-connector class: soap-port-name, soap-binding-name,
soap-service-name.
soap-connector class: soap-port-name, soap-binding-name,
soap-service-name.
*soap-client-debug* and *soap-server-debug*.
The jLinker java-Lisp interface tool has been made more efficient. The most important changes are these:
javatools.jlinker:query-handler is
no longer exported. Use javatools.jlinker:jquery-handler
instead.
jLinker documentation is in jlinker.htm.
AllegroServe is continually updated. A snapshot of the documentation is available at aserve/aserve.html but later versions may be available (the latest version is always available at http://opensource.franz.com/aserve/, scroll down for links to the documentation). Recent changes include:
New Imap macros and functions. with-imap-connection and with-pop-connection open a connection to execute body forms and then close the connection. with-fetch-letter-sequence reads a pop interface letter in parts. fetch-letter-sequence and end-of-letter-p are generic functions used by with-fetch-letter-sequence. Also new is reset-mailbox which removes any delete or has been read markers from letters in a pop mailbox.
New functionality for smtp mail servers that require authentication. Authentication is provided by providing a login name and a password. send-letter has new keyword arguments login and password. The new function send-smtp-auth is like the existing send-smtp except it has two additional required arguments login and password.The authentication support is new. It works in our tests and with our mail servers, but, for whatever reason, may not work for everyone. If you experience problems with authentication, please send us a bug report.
All changes since 6.2 have been released as patches. In phtml (see phtml.htm):
In pxml (see pxml.htm):
As said in Section 6.1.1 Features added to Allegro CL 6.2 after the initial release of Allegro CL 6.2, there was a major upgrade to the Emacs-Lisp Interface released as a 6.2 patch. See the section Significant changes in the interface in eli.htm for more information.
In this section we list some minor changes and bug fixes.
excl:*print-nickname* non-nil. Also symbol completion of keywords, and other
obscure completion problems have been fixed.
fi:user-env-vars. It is an
alist containing environment variable/value pairs to add to the
environment of the Lisp started with fi:common-lisp.
(#-blah no-blah #+blah yes-blah (blah blah blah) t)
instead of like this:
(#-blah no-blah
#+blah yes-blah
(blah blah blah)
t)
The format of the documentation in 7.0 is similar to that of 6.2.
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 (www.franz.com), at the location ftp://ftp.franz.com/pub/clx/.
wchar and wstring types are now
supported in Orblink. wstring maps to Lisp string;
wchar maps to Lisp character. It is an error,
however, to use wstring/wchar in an 8-bit character Lisp.
The POA documentationis now documented with the rest of Orblink.
Working with Paul Dietz, a user of Allegro CL who has been developing an extensive test suite for ANSI Common Lisp, we have corrected a large number of non conformances uncovered in Allegro CL. While Franz Inc. has always corrected non-conformances as they have been discovered by users or internally (the fix being either supplied at once as a patch or in a subsequent release), Paul Dietz's project (a comprehensive test suite for ANSI CL) has resulted in an unusually large number of changes.
Prior to Paul's test, newly uncovered non-conformances were identified by problems in running code: a user or a Franz developer would write what he or she believed to be conforming code but found that the code did not work as expected. Discussions with the relevant Franz developer would on occasion reveal that Allegro CL had a bug or that Franz had misinterpreted the specification.
Allegro CL 7.0 contains fixes for many of the non-conformances. In the large majority of cases, the fix will not affect existing code. In a few cases, code which previously worked will now fail. We list those cases next. Then we list the (few) cases where the bug is not fixed in the 7.0 release. Finally, we list the other fixes.
nil. Allegro CL prior to release
7.0, the null block was inside the initialization forms of the
do-style form. In 7.0, it is outside. This means that calls to return within the
initialization forms of a do-style form which previously returned from
an outer null block will now return from the do-style form. The
difference can be seen in the following example:
;; 6.2 behavior (block nil (dotimes (i (return 11) 5)) 0) RETURNS 11 ;; 7.0 behavior (block nil (dotimes (i (return 11) 5)) 0) RETURNS 0
*print-readably* were true:
cl-user(1): (make-array 10 :element-type 'single-float :initial-element 1.0) #(1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0) cl-user(2): (let ((*print-readably* t)) (print *)) #(1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0) #(1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0) cl-user(3):
This was a nonconformance, because when the array is read back in, the
resultan array will not be similar to the printed array (it will be an
unspecialized array with element-type t).
Starting in release 7.0, an error of type
print-not-readable will be signaled in this case:
cl-user(2): (let ((*print-readably* t)) (print *))
Error: Unable to print #(1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0)
readably and *print-readably* is true.
[condition type: print-not-readable]
A program which counts on the nonconformant behavior will break in
7.0. It may be possible to work around the compatibility issue by
binding *print-readably* to nil before printing the array. This will cause the
array to be printed in #( format, which will then allow it to be read
in as before, though the resultant array will, as before, not be of
the same element-type as the original.
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.) fboundp now signals an error when passed an
invalid argument. 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.
Note that Allegro CL allows lists other than (setf
symbol) to name functions. See def-function-spec-handler. function-name-p returns true when passed a
valid spec defined by def-function-spec-handler. fboundp does not signal an error when
passed such a function spec. (This makes fboundp arguably out of conformance.)
nil (meaning act on
all instances). Such values are now (correctly) treated as equivalent
to specifying 0 (meaning act on no values).
(make-pathname :directory '(:absolute
:back)) returned #p"/" (i.e. the same as
(make-pathname :directory '(:absolute)), so :back
from / was ignored). Following from that, (merge-pathnames
"../a/" "/") returned #p"/a/" (i.e. back from / was /, and
then the subdirectory a/ was merged in). This behavior was
incorrect. Allegro CL now signals a file-error in this (and similar)
cases.
(setq num 121694457621910027047283135086593) (setq den 121694457621910022543683507716096) (= (/ num den) 1.0d0) -> nil
In earlier releases, that comparison returned true as the difference
of the ratio (/ num den) from 1 was smaller than
double-float-epsilon so (coerce (/ num den) 1.0d0)
returned 1.0d0. Also any numerator value between den and
num will also float to 1.0d0, and so also equaled 1.0d0 in
pre-7.0 and does not (with the exception of the numerator equaling
den) now.
While it is unlikely that any code depended on the results of
comparisons of such numbers, the older (coerce [rational]
'float) behavior can be obtained by changing (op fl
rat) to (op (- fl rat) 0) (and vice
versa), where op is one of the numeric comparisons =,
/=, <, >, <=, or >=.
(loop named foo ... ... (return res))
must be changed to
(loop named foo ... ... (return-from foo res))
(defstruct (foo (:constructor make-foo-boa (&key bar bas))) (bar 10) (bas 'bye)) (defstruct (bar (:constructor make-bar-boa (&key ((:foo bas))))) (bas 10))
In pre-7.0, we had the following results:
(make-foo-boa) -> #S(foo :bar nil :bas nil) (make-bar-boa :foo 20) -> #S(bar :bas 10) (make-bar-boa) -> #S(bar :bas 10)
In 7.0, we have:
(make-foo-boa) -> #S(foo :bar 10 :bas bye) (make-bar-boa :foo 20) -> #S(bar :bas 20) (make-bar-boa) -> #S(bar :bas nil)
;; In Allegro CL 6.2: cl-user(1): (make-pathname :directory '(:absolute :back)) #p"/" cl-user(2): (merge-pathnames "../a/" "/") #p"/a/" cl-user(3): ;; In 7.0 cl-user(2): (make-pathname :directory '(:absolute :back)) Error: :absolute followed by :back in directory component. [condition type: file-error] Restart actions (select using :continue): ... [1] cl-user(3): :pop cl-user(4): (merge-pathnames "../a/" "/") Error: :absolute followed by :back in directory component. [condition type: file-error] Restart actions (select using :continue): ... [1] cl-user(5):
nil
rather than signaling an error. The variable *strict-probe-file* now controls the behavior
of probe-file in this
case. When nil, probe-file returns nil,
and when non-nil, probe-file signals an error (and reports access
problems). The initial value is nil.
The Common Graphics and Integrated Development Environment (IDE) code has undergone an extensive reorganization for release 7.0. Among the reasons for the changes are:
Achieving these purposes has required an unusually large number of backwardly incompatible changes. On the other hand, the large majority of these changes involve relatively obscure functionality (to which less attention is usually paid), and most other incompatibilities consist of symbol-name or package changes that should be straightforward to address in application code. Nevertheless, we hope that the volume of release notes is not overwhelming.
The IDE has been cleanly separated from Common Graphics for this
release. As part of that, some symbols that were exported from the
cg package are now exported from the new
ide package instead. Also, the cg:*system* object
has been divided into cg:*system* and ide:*ide-system*, and there are
separate configuration objects for CG and the IDE, returned by the
expressions (cg:configuration cg:*system*) and
(cg:configuration ide:*ide-system*). Most of the
configuration properties have moved to the IDE configuration object,
and so programmatic calls to return or set these properties need to be
changed to retrieve the configuration object from ide:*ide-system*
rather than from cg:*system*. For example, code that uses a form such
as:
(setf (scroll-while-tracing (configuration *system*)) t)
must change it to:
(setf (scroll-while-tracing (configuration *ide-system*)) t)
While there are more IDE then CG configuration options, the CG options are the ones that were kept backwardly compatible because they are the ones that may be used in a standalone application, and therefore are the ones that are more likely to appear in existing user code. IDE options are typically changed interactively only.
The following lists identify the symbols that have been moved from the
cg package to the ide
package. The first list is configuration options, with some special
notes. The second list is other symbols. Finally, there is a list of
new symbols in the new ide package.
Below are the other symbols that had been exported from the
cg package and that are now exported from the
ide package instead. Most pertain to projects or
form windows, which exist only in the IDE.
In general, application code would not have called these functions since they were already unavailable in a standalone app. An exception to this rule may be finder-function and maker-function, where the documentation implies their use by applications. Since the project from which a standalone app is generated no longer exists in the standalone app (for size and general design reasons), these functions may no longer be called in the application code to find the function to call to make a module's window. Instead, the application code should directly call the finder function or maker function. (The new function main-window-maker may be called in a standalone app though.)
Some classes have been removed, some renamed, and some new ones have been provided. Applications are unlikely to have used the renamed or removed classes as they were all non-instantiable. The details of the changes are as follows:
widget-window has been renamed to os-widget-window. And a new class
has been named widget-window. So the widget-window class is now the class of windows
for all widgets, and its subclasses are os-widget-window and lisp-widget-window. The formerly unexported
symbol windows-widget has been renamed to os-widget and is exported.
To repeat something said in
Section 8.1 Non-backward-compatible changes in Common Graphics, when defining a custom
lisp-widget, you
create a window class for the window holding the widget. In earlier
releases, this window class should be a subclass of both lisp-widget-window and
lisp-widget-top-window. In 7.0, the
only superclass should be lisp-widget-top-window (which is now a
subclass of lisp-widget-window).
os-widget is the non-instantiable superclass of
dialog items provided by the underlying window system or operating
system.
window
has been removed: it was just a mixin to group basic-pane and menu together, though those classes are not
significantly related.
windows-screen-device no longer names a
class. The new name is screen.
screen-stream class groups together all streams
that display on the screen, which includes all windows (see basic-pane) and the screen itself.
lisp-edit-window class is a frame-with-single-child class similar to the
existing text-edit-window
class, except that the frame-child window will be a lisp-edit-pane rather than a
text-edit-pane.
dialog-item and widget-window classes, and it may
be helpful to document the meaning of each class. These include
scroll-bar-mixin, scroll-bar-pane-mixin, scroll-bar, scroll-bar-pane, text-widget, text-widget-pane, item-list, item-list-pane, toggling-widget, toggling-widget-pane, picture-widget, and picture-widget-pane.
One of the significant changes in Common Graphics from 6.2 to 7.0 is the separation of DDE code from the rest of Common Graphics. There was no logical connection between DDE and Common Graphics, other than both are available on Windows only. Common Graphics thus served as the module for most Windows-specific functionality. With the general reorganization of Common Graphics in release 7.0, DDE is now separate.
An application may now use the new "dde" module without loading any of
Common Graphics. This means that the exported symbols are no longer
exported from the cg package, and are now exported
only from the dde package.
If you have code which uses DDE, make sure of the following:
cg:, you must change the qualification to
dde:.
cg package, and
you refer to DDE symbols while it is the current package, you must
either have your package also use the dde package
or you must package qualify the symbols with dde:
(using the dde package is the expected thing to
do).
(require :dde). If you build images
with build-lisp-image or
generate-application, be
sure :dde is included in the list of files to
include in the application.
The name of the document that describes the DDE facility has also been changed. It was cg-dde.htm and was in the doc/cg/ directory. It is now dde.htm and is in the doc/ directory.
Several symbols have been added, naming new functionality, as
described below. The symbol *show-dde-warnings*
has been removed. It has been replaced by *generate-dde-messages*.
The symbols moved from the cg to the dde package are:
*case-sensitive-dde*
|
*service-name*
|
*service-topics*
|
*sysitems*
|
client-port
|
dde-info
|
These symbols have been added in release 7.0:
The following Common Graphics functionality is no longer supported. All items are operators unless otherwise noted. We do not list symbols moved from one package to another (from cg to dde or from cg to ide). There are individual release notes (in Section 8.1 Non-backward-compatible changes in Common Graphics) for most of the items listed here.
dde:*generate-dde-messages*)
There is no longer a compatibility module for the old Common Graphics function names from the 3.0.2 release of Allegro CL on Windows. This module had supplied stub functions that automatically translated calls to the old functions into calls to the current functions, which mostly were given shorter names in the 5.0 release. If your application still calls any of the 3.0.2 functions, the source code must now be converted to use the current function names.
The file cg-obsolete.cl (in the main Allegro directory) contains an association list with several hundred entries that map from the old names to the new; you could either search this file textually for Common Graphics function names from your code that are no longer fbound, or perhaps do a lisp read on the file in order to search the list programmatically. Each entry in the alist is a list of an obsolete symbol followed by the corresponding current symbol or form; in most cases the new symbol or form will substitute in directly, though in some cases the new symbol must be used somewhat differently, as described in the current documentation for that symbol. A few of the entries have a third member, in which case the second member corresponds directly to the old symbol, and the third member is something that is preferable to that.
Also, the backward compatibility that allowed creating an IDE project from interactively-built dialogs that were last saved in aclpc version 3.0.2 or before has been removed.
Common Graphics no longer uses the aclwin and aclwffi modules, which exist for backward compatibility with the 3.0.2 base lisp on Windows. A Common Graphics application that calls functions in those deprecated modules directly would need to either load the module(s) explicitly or (preferably) convert the calls to current equivalents. In particular, calls to the aclwffi functions cref, cset, and csets should be converted to fslot-value and (setf fslot-value), and callocate and ccallocate calls should be converted to allocate-fobject. Symbols from the aclwin module that an application may have used include win32p (no longer needed since Allegro has not run on 16-bit Windows for some time) and the for macro (use the loop macro instead, which is similar but not identical).
The new array implementation is discussed in the Arrays and short arrays section in implementation.htm. In brief, standard Common Lisp arrays now can be significantly larger than in earlier releases, while the new short arrays implement the old arrays (the same size limitations but also the same type codes and structure).
In this discussion, `array' refers to the newly-implemented arrays, while `short-array' refers to the old implementation, preserved as short arrays in 7.0.
short-array is not a subtype of
array. Therefore, it is possible there may be
problems when the system expects an array and receives a
short-array. In this appendix, we discuss these problems as they
affect def-foreign-call and
def-foreign-type.
Foreign calls are made with arrays as arguments by passing the address of the first value. In the new implementation, simple-arrays always have exactly the same first element offset (but some short-arrays are aligned to the next higher word boundary so that the elements within are naturally aligned). This sometimes-difference between arrays and short-arrays poses an extra burden on the foreign function interface, in that the arrays must be distinguished between themselves at runtime.
It is now possible to declare an argument to be passed to a foreign
function (in def-foreign-call) to be a
(short-simple-array ... (*)) and the interface will
generate code as it did before for normal arrays, passing the address
of the first argument.
For 7.0, a declaration of (simple-array
... (*)) actually generates code that tests at runtime
whether the argument is a short-array or a normal array. So in
effect, a short-simple-array passed in as if it were a normal
simple-array will be properly passed.
Note that with this setup, if argument checking is specified and a short-array is passed in, the check will fail, because a short-array is not a subtype of simple-array. But, if you suppress this argument checking, the interface will pass either array correctly.
However, programmers are urged to provide correct declarations and
pass the correct type of array even though 7.0 allows sloppiness. (In
a future release, we anticipate adding a (dual-simple-array
... (*)) declaration to the direct-call foreign interface,
telling the system that either a short-array or a regular array will
be passed in.)
With the advent of the long array implementation, the foreign types system makes a distinction between regular vectors and short-vectors. It must do so, because the layout of each is different.
All foreign-type interface functions which accept the
:lisp allocation type (such as allocate-fobject, fslot-value-typed and its inverse, fslot-address-typed, describe-fobject, and def-foreign-type) have now been enhanced to
accept a :lisp-short value for the allocation
type. Since the basic simple-array type has changed its
implementation, the :lisp allocation type now
describes the regular arrays, and the new
:lisp-short allocation type describes short-arrays.
If the allocation is not given, and can be figured out (e.g. a null
allocation argument to fslot-value-typed, or a call to fslot-value) then the object is tested
to see if it is a long or a short vector, and the allocation type is
set based on the test.
Because of the change in layout between the older short-vector types and the new (long) vector types, the foreign type allocation must match the object. This is not likely to be a problem, if nothing special is done to make short-arrays.
Copyright (c) 1998-2004, Franz Inc. Oakland, CA., USA. All rights reserved.
Documentation for Allegro CL version 7.0. This page has had significant revisions compared to the 6.2 page.
Created 2004.8.21.
| Allegro CL version 7.0 Significantly revised from 6.2. | |||||||