The index for the Allegro CL Documentation is in index.htm. The documentation is described in introduction.htm.
This document contains the following sections:
1.0 IntroductionThis document provides the release Notes for release 6.0 of Allegro Common Lisp and related products. The sections describe the release notes for the various components (Allegro CL and related products). Each section is divided into non-backward-compatible changes (that produce different behavior in release 6.0 compared to release 5.0.1) 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.
This document is very long, with many chnages, major and minor, described. Please look particularly at these sections:
If you notice changed or unexpected behavior with an operator, variable, or facility, search for its name in this document to see whether there is an entry concerning it.
We have added a number of new capabilities to Allegro CL, incuding some that improve networking functionality. Here we give links to the documentation of the new features.
*pprint-gravity* has been defined and
techniques are recommended for not paying the overhead when it is not
necessary. Please see Speed and pretty printing in
implementation.htm for details.
*print-startup-message* has its
initial value).
Therefore, in release 6.0, an additional keyword argument,
partial-fill, is added to the lambda-list for
read-sequence. If nil (the default)
read-sequence will block. If true
read-sequence will block for the first element, but will
not block for any elements after the first, and so may return prior
to the request being completed. In all cases,
read-sequence returns
the index in the sequence of the next element not read.
Because read-sequence did not block for buffered bivalent
streams in most (but not all cases), some 5.0.1 users may be relying
on the non-standard not-always-blocking behavior and will therefore
need to modify their code (by adding :partial-fill
t to the read-sequence calls) in order to get the
behavior they expect.
The not-always-blocking behavior was seen when read-sequence was applied to a buffered bivalent stream except when
In those cases, the behavior of read-sequence was standard (blocking). read-sequence always had standard behavior on streams that were not buffered bivalent streams.
The Allegro CL implementation of read-sequence is described in Implementation of Common Lisp Functions for Simple-Streams in streams.htm
The locale used by iacl will be looked up by calling setlocale(), which is typical for internationalized applications. A user can override the default locale by specifying "-locale <name>" in the acl command line, or by setting the ACL_LOCALE environment variable.
The internal format used for characters is unicode. This is a superset of ascii (and latin1), but incompatible with jis/process-code that was used in the previous unix iacl. It is also incompatible with other 8-bit character sets other than latin1. Users of standard acl might be affected by this. Users depending on values of char-code and code-char for international characters may notice this change. Also, euc-specific functionality from previous iacl which defines "types" of characters is being deprecated, but available through an autoload module called "euc.fasl".
The load function now takes an :external-format argument, as does compile-file. The open function already had an :external-format argument.
#\newline is now being handled as defined by ANSI CL. In other words, a single character with name #\newline is returned by read-char when the stream position is at the end of a line. This functionality is implemented using external-formats. By default, MSwindows uses the crlf external-format, and unix does not. A new command-line option, "-compat-crlf" is available to provide compatibility with earlier releases of Allegro CL (see #\newline Discussion in iacl.htm). Also, as a result of this new feature, the :mode option to open is now deprecated, as described in :mode Option Removal in iacl.htm.
Beta customers: there have been changes since the release of the beta version of Allegro CL 6.0. Stream code written for the beta version may have to be modified.
fasl-casemode-mismatch is signaled,
so the new error behavior can be overridden by using the condition
system. The blocking is done to avoid multiple symbols (uppercase and
lowercase) intended to be identical from being created.
nil.
*require-search-list* only looks for fasls
and in the Allegro directory and its subdirectories. In previous
releases, it looked in the current directory, and as a result often
loaded user fasls which happened to have the same name as a system
fasl (build.fasl, for example). Any users who depended on the wider
search should modify *require-search-list*. The old value is
given (in a form which is ignored) in the file <Allegro
directory>/custom.cl.
nil. When it is specified true,
digit-char-p returns lowercase
alphabetical characters rather than uppercase. Thus
(digit-char 12 16 t) returns #\c,
not #\C.
excl:*clos-package*,
excl:*compiler-package*,
excl:*keyword-package*,
excl:*excl-package*,
excl:*lisp-package*,
excl:*system-package*,
excl:*user-package* no longer exist. In earlier
versions their values were the named package objects (thus the value
of, say, excl:*compiler-package* was the value
returned by (find-package :excl)). They were
deprecated for several releases and are gone in 6.0.
:pan for an object in newspace that is marked so it
will never be tenured. In earlier releases, such objects existed but
pointer-storage-type
returned :new on them.
-Q was specified as the first
command-line argument. In 6.0, this information is not printed so
-Q is ignored. See Command line arguments in
startup.htm for information on command-line
arguments.
*print*, if not nil, must be a function that will do the job of
cl:print. In earlier releases, this function was passed one
argument only (the object to print). In release 6.0, it is passed
two arguments, the object to print and the stream to print to. If you
have a print function used in earlier releases, we recommend making
the second argument optional when you modify it, as then it will run
in both the old and new releases. Thus:
(defun my-print (val &optional (stream *standard-output*))
...)
*read*, if not nil, must be a function that will do the job of
cl:read. In earlier releases, this function was passed no
arguments. In release 6.0, it is passed
one argument, the stream to read from. If you
have a read function used in earlier releases, we recommend making
the argument optional when you modify it, as then it will run
in both the old and new releases. Thus:
(defun my-read (&optional (stream *standard-input*))
...)
Note: *read* was incorrectly documented in
release 5.0.1 (and earlier). That documentation said a non-nil value must be a function that would be passed one
argument when in fact it had to be a function that would be passed no
arguments. In release 6.0, a non-nil value
must be a function that will be passed one argument. (So the
documentation of *read* in 6.0 is the same as in 5.0.1,
but is now correct.)
c:\\. In release 6.0, it is the value of the HOME
environment variable if that variable is set and
c:\\ if that variable is not set. This change
affects where [.]clinit.cl is looked for (see
Initialization and the
sys:siteinit.cl and [.]clinit.cl files in
startup.htm), and the functions username-to-home-directory and user-homedir-pathname.
*print-startup-message* now includes
(:case t) so that the current case mode is printed
when Lisp starts up. print-startup-info now accepts
:case as a type of information.
:signed-long to
:signed-natural. If a user has pre-6.0 code that
explicitly specifies :signed-long, it is likely not
to work on 64-bit ports, because :signed-long
always specifies 32 bit values. If the user instead takes the default
argument type, then the code will work in all 6.0 and pre-6.0
versions. If 32-bits is explicitly desired, however, then the
:signed-long (or :unsigned-long)
should be explicitly specified.
:step nil followed by :over.
See :step and
:sover.
New closed old areas gc feature.
Old areas are now numbered, starting with 0 as the oldest old
area. The new (sys:gsgc-parameter
:open-old-area-fence) (see gsgc-parameter) always returns a
non-negative integer which is the number of the oldest old area that
is open (not closed). This parameter is setfable, either with the
number of the old-area that is desired to be the first open-old-area,
or with a negative number, for which the old-areas are counted
backward to set the fence. For example, (setf
(sys:gsgc-parameter :open-old-area-fence) -1) will close all
old areas except for the newest one, no matter how many old areas
exist. Restrictions: At least one old area will be open at any time.
Attempts to set the fence to a higher or lower number than can be set
will result in silent saturation (setting the fence to the nearest
possibility), however the return value from such a setf will always
indicate the actual open-old-area-fence. Obviously from these
restrictions, one must have at least two old-areas in order to close
one.
When an old area is closed, setf is not restricted, but no objects are newly tenured into a closed old-area; it is as if the area is full. Also, no dead object in a closed old area is collected while the area is closed, and data pointed to by that object is also not collected.
The intended usage model for closing old areas is this: a VAR will load up their application, perform a global-gc and possibly a resize-areas, and then close most of the old-areas, leaving room for their users' data models to be loaded into the open-areas. When the user is done with the data model, it can be thrown away and a fast global-gc performed, making way for the next data model.
There were a number of complaints about Allegro CL 5.0.1 (and some earlier releases) that incorrect calls to various sequence functions caused serious errors. The forms were incorrect usually because arguments were of the wrong type or indexes pointed outside the sequence). Note that correct code did not have problems (or, if there were problems, a patch was provided).
The problem was, of course, balancing safety and speed. Exhaustive argument checking significantly slows down execution.
In 6.0, there are two modules for sequence functions,
:safeseq and :fastseq. Either
can be require'd at any time,
and they each define or redefine the same operators, and thus loading
one cancels the effect of the other. :safeseq does
argument checking but causes Lisp to run more
slowly. :fastseq is faster but less safe. The
images delivered with Allegro CL are build with
:fastseq.
It should be noted that functions in the safeseq module are not better per se than those in fastseq, and for correct code each module's functions operate correctly. Rather, the functions in safeseq behave better for poor coding behavior, as is required by the spec for "safe" code.
The current list of functions which are affected by these modules include (but are not limited to, possibly by indirection): elt, length, make-list, and all of the map functions, e.g. mapc, mapcar, etc., and butlast.
t a bundle file named files.bu will be
placed in the application directory. This file contains the modules
allowable in a runtime image. This means that such modules need not be
loaded into the application image during the application build. See
"Including all
desired modules in delivery.htmnil. If you want the single form
nil (in, for example, :around advice to not
call the function and return nil), specify
(progn nil) instead. See
fwrappers-and-advice.htm and advise, advise-1, and defadvice.
*require-search-list*. Note
that all code is commented out or suppressed with a #+ignore reader
macro. If you want any of the code evaluated when you build an image,
you must edit the file.
:recurse and
:file-type.
*zoom-print-level* and tpl:*zoom-print-length*.
+RR command-line argument, which
controls whether to put the ACL icon on the system tray (and can
override resource values). See Command line arguments in
startup.htm.
*tenured-bytes-limit* has been
changed; on 32-bit versions the default is 8 Mb (8 * 1024 * 1024) and
on 64-bit versions the default is 16 Mb (16 * 1024 * 1024).
excl
package. Those with links name defined objects. file-read-only-p, file-hidden-p, file-system-p, file-archive-p, file-normal-p, file-temporary-p, file-attributes, ef-composer-ef, ef-composee-ef, composed-external-format-p, no-external-format-error
and oc-eof-macro. The last is used to name
macros defined during the execution of octets-to-char.
(* :char) specification is tightened up a little. Previously,
a foreign definition like
(ff:def-foreign-call foo ((x (* :char))) ... )
would assign a lisp type of :foreign-address, because of the extreme overloading of the char* type in C (char* is typedeffed to many types, and is routinely cast to pointers of different type such as int* or struct x *). But this causes the runtime type-checking to be circumvented, since anything at all satisfies a :foreign-address type, and :foreign-address is not even a lisp type at all. A problem with this old specification is in the passing of non-simple strings (e.g. strings with fill-pointers) in a call-direct situation: it is the array-header that is passed to the foreign call, rather than the string data address, as is usually expected.
Now, the (* :char) specification causes the default
lisp type to be string. This causes the compilation
of a direct-call specification to fail to compile directly, because
the specification is not a simple-string. You can cause the
direct-call to occur again by changing the specification to
(ff:def-foreign-call foo ((x (* :char) simple-string)) ... )
(* :char) as a value for the
returning keyword argument to def-foreign-call is now accepted and converts
the return value automatically to a Lisp string using native-to-string.
The intention of the strings-convert warning is to alert the user to potential performance and correctness problems in the face of new international character set issues, without generating spurious warnings when unnecessary.
Swap allocation on HP is incredibly complex. If you are having trouble using all of the swap that you think you've allocated, contact Franz Inc. for advice (Franz Inc. will likely refer you to HP Support after suggesting what to ask.)
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 User Guide. That document which includes material formerly in the (printed) CLIM Release Notes.
The reason for this is that HP's default locales seem to specify that the HP-ROMAN8 codeset must be available in X. For non-HP X servers it typically is not available, and thus this error occurs.
There are two solutions (apart from displaying on an HP X server):
<x>.iso88591. So, for instance, rather than
using the C locale, you should be able to use the
C.iso88591 locale. You can specify a locale at
startup with the -locale environment variable:
-locale C.iso88591
(See Command line arguments in startup.htm.) Or by specifying the ACL_LOCALE environment variable (see Locales in iacl.htm).
You can also change the locale once started with by getting a locale
object with find-locale and
setting the value of *locale* to that object. (The locale
shell command tells you what locale you are in. The locale -a
shell command lists all available locales.
hp-roman8-encoded fonts available to the X
server. This could be done by running a font server on the HP
machine, or by physically copying the fonts from the HP machine to the
machine with the X server. The details of how to do this are not
covered here.
*restart-init-function*. A -e form can be used
to modify that variable, if desired.
*error-output* to itself, and not
to one of the frame panes. This is an incompatible change, which was
made to stop problems when Lisp messages (unrelated to the CLIM
application) were getting printed to CLIM panes. This is at best
annoying, and at worst can cause errors in incremental redisplay.
Rather than hard-wire this change, it is controlled by an argument
to make-application-frame or make-instance of
standard-application-frame:
(make-application-frame ... :non-frame-stream-names <name list>)
Will cause the default top-level loop to rebind the values of the standard streams named in <name list> to themselves, not to CLIM panes, even when there are suitable panes available. The default case is as if you said:
(make-application-frame ... :non-frame-stream-names '(*error-output*))
And you can inhibit the new behaviour by saying:
(make-application-frame ... :non-frame-stream-names '())
or providing this as a default-initarg in a frame class definition.
Note that this behaviour is controlled in terms of stream names
not streams, and in fact it is more general than just
*error-output*. The names that make sense in the
list are *standard-output*,
*standard-input*,
*error-output*, *query-io*, and
*pointer-documentation-output*.
The behavior of the generic functions frame-standard-output,
frame-standard-input, frame-query-io,
frame-error-output, and
frame-pointer-documentation-output are altered by this
change. If the corresponding stream will be rebound to its old value
in the frame, the methods defined on
standard-application-frame for these generic
functions will return nil rather than a
stream.
:scroll-to-bottom-callback (a scroll-bar initarg)
specifies a callback that is called on scroll to bottom.
The callback should be a function of one argument, the scrollbar.
nil if
none is defined. This corresponds to the value of the
:scroll-to-bottom-callback initarg.
Similar sets of initargs and functions exist for
...to-top... -- scroll to top...down-line... -- scroll down single line...up-line... -- scroll up single line...down-page... -- scroll down page...up-page... -- scroll up page.
Note the behavior of these functions is that, for instance, the
default method on scroll-to-bottom-callback will call the value
of (scroll-bar-scroll-to-bottom-callback
<scrollbar>) on the scrollbar if it is non-nil.
On Windows the names exist but the functions are not called.
<machine-name>:<display-number>.<screen-number>
enter the command
% printenv DISPLAY
to a Unix shell prompt. machine-name should identify the machine at
a screen of which CLIM should display. The
display-number is usually 0 and the
screen-number is often omitted altogether.
If the user has no DISPLAY environment variable or the user's DISPLAY environment variable is inappropriate for this purpose and there is reason not to modify it, enter the following in Lisp before attempting to display anything from CLIM:
(setf clim:*default-server-path*<
'(:motif :display "<machine-name>:<display-number>")
The initial value of clim:*default-server-path* is
currently (:motif).
Warning: Xt:
Name:
Class: XmRowColumn
Illegal mnemonic character; Could not convert X KEYSYM to a keycode
This occurs when you are using a keyboard that does not have an F10 key. If you modify the file misc/dot-motifbind so it does not refer to F10 (make it refer to a key you do have), this warning should go away.
(require :climdemo)
Then, the simplest way to start the demo is to evaluate:
(clim-demo:start-demo)
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 6.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.
There are three appendices about Common Graphics and the IDE. The first deals with a change where functions passed a frame-with-single-child window as an argument no longer automatically operate on the child window. The second lists classes and functions affected by the change to drawing functionality, where it is no longer possible to create objects corresponding to shapes (like circles and ellipses) and then draw those shapes with draw. The third lists minor bug fixes and enhancements, many fixed or made available by 5.0.1 patches.
frame-with-single-child arguments no longer redirected to
pane. Functions called on a frame-with-single-child are no
longer redirected to the frame-child. This is
a backward-incompatible change. In earlier releases, if you called
copy-pixmap (for
example) on a frame-with-single-child window such as a
non-refreshing-window, then the pixmap would actually be drawn on the
frame-child pane of the frame-with-single-child instead of on the
frame window itself. This redirection was done whenever CG regarded
the particular operation as not being useful on the frame. In the
copy-pixmap case, the pixmap would never be seen on the frame because
the frame's interior is completely covered by the frame-child pane
that is automatically created when a frame-with-single-child class is
instantiated. (Drawing CAN be done on any window, though, including a
frame-window.) Approximately 160
methods that specialized on frame-with-single-child performed
this redirection, each checking
for the existence of a frame-child pane and simply calling the
same generic function on the frame-child if it existed.
This automatic redirection to the frame-child has now been removed from Common Graphics. This feature is no longer considered worthwhile because (1) if it is desirable to really call one of these generic functions on a frame-with-single-child frame window itself, there is no way to do so, (2) it was not obvious that this behavior was an explicit feature, or which generic functions it affected, and so could lead to confusion over whether a frame-with-single-child frame window and child pane are really one window or two, and it required a significant amount of code (the 160 methods) which is not necessary since it is easy for an application to call frame-child on a frame-with-single-child window to find the auto-instantiated child pane (even if there are additional child windows such as a toolbar and status-bar). The policy now is that the programmer should understand that two windows are involved, and to call functions on the appropriate one explicitly.
If an application relies on this feature by calling functions on a frame-with-single-child frame window when the frame-child pane is the actual target, then calls to frame-child will need to be inserted in the application source code to redirect the action as needed.
See below for a complete description and list of affected functions.
(setf state) is called whenever the state of a window is changed (expanded, iconified, etc.) Also changes to state and (setf state). (setf state) is now always called when the state of a window is changed, either programmatically by calling other exported functions such as shrink-window, or interactively when the user clicks the shrink, maximize, or restore buttons on a window frame. shrink-window, expand-window, and zoom-window are now regular (non-generic) functions that call (setf state); if an application has added methods on any of these three former generic functions then these need to be changed to (setf state) methods instead.
This change was made in order to provide a single generic function that can be guaranteed to be called whenever a window state changes, so that applications will need to modify only one generic function to hook into state changes. In earlier releases, (setf state) called the other three functions instead, and was not called for interactive state changes except when a window was iconized.
When expand-window is called on a window whose state is :shrunk or :icon, the window is returned to either :normal or :maximized state, depending on which of these two states the window most recently had. If it has not yet had either of these states, then it is put into :normal state. For iconized windows, this emulates clicking on the restore button of the icon. Alternately, the new-state argument to (setf state) can be passed as :expanded to achieve the same result; expand-window itself calls (setf state) in this way. (:expanded is not a true state, so the resulting state of the window will be either :normal or :maximized.)
A (setf state) :around method prevents any other non-:around (setf state) methods from being called if the state would not actually be changed by the call. Therefore any methods added by an application do not need to handle this efficiency consideration. This around method also coerces the special :expanded state to either :normal or :maximized and passes that value to the other (setf state) methods that it calls, so any primary, :before, or :after (setf state) methods added by an application will not receive the :expanded state.
The generic functions state and (setf state) may be called on dialog-items or windows, while the other three functions apply only to windows.
The generic function state returns a new second value for the "expanded state" of the window. This value is always either :normal or :maximized. If the current state of the window is :shrunk or :icon, then the value is the state into which the window will be placed if expand-window is called on it or if (setf state) is called on it with the :expanded state. This is also the most recent expanded state that the window was in, or :normal if it has never been expanded. If the current state of the window is :normal or :maximized, the value is the state to which the window was most recently expanded from :shrunk or :icon state.
Here is an example of an added (setf state) :around method that looks at both the old and new states of any frame-window whose state may be changing, and reports any change. Typcially several custom methods on shrink-window, expand-window, and so on in 5.0.1 could be collapsed into such a single (setf state) method. A simpler :after method could be used instead if the old state is not of interest.
The without-package-locks is needed here in a source code file that's not in the CG package only because it specializes a CG method on a built-in CG class; normally an application would specialize on its own subclass instead.
The requested-state argument is ignored because it may be :expanded, and we are interested here in the resulting :normal or :maximized state instead. Similarly, some other (setf state) method could coerce the requested state to something else.
Eval-in-listener-thread is used to make sure that the printed output always goes to the selected IDE listener pane (and so this method is suitable only for the IDE and not for a generated application). Otherwise, the message will go to the *terminal-io* of whatever thread changed the window state; for example, clicking the minimize button of an IDE window would iconize the window in the IDE GUI thread, for which *terminal-io* is bound to the console, and so the output would appear there.
The prog1 is used to ensure that this (setf state) method returns whatever the next called method returns, though that would normally be the requested-state.
(without-package-locks
(defmethod (setf state) :around (requested-state (window frame-window))
(declare (ignore requested-state))
(let* ((old-state (state window))
new-state)
(prog1 (call-next-method)
(setq new-state (state window))
(unless (eq old-state new-state)
(eval-in-listener-thread
`(format t "~&State of ~s changed from ~s to ~s.~%"
(name ,window) ,old-state ,new-state)))))))
window. Windows no longer change
class when they are closed, so this change is needed to maintain the
usefulness of this function to check whether an object is currently
valid for operating on as a window. Note that Common Graphics might
not know when a window has gone away (been closed) because the thread
that created the window has gone away, and so windowp also checks that the
process that created the window is still in the *all-processes* list, and returns
true only if it is.
Function dirty-p removed. The function dirty-p has been removed from CG. It was used primarily internally to avoid ejecting blank pages from printers, but should not be necessary for this.
If an application called this function directly, it should now instead maintain its own flag for whether it has drawn anything on the current page.
More typically, an application may have relied on Common Graphics itself to avoid ejecting blank printer pages. If unwanted blank pages begin to appear in this release, the application should avoid producing these pages itself. In cases where no printed output at all should be produced, such as when opening a printer stream simply to query its attributes or when the user cancels a print operation, the application should pass the ABORT flag when closing the printer, which will avoid ejecting any pages. In cases where an extra blank page appears after the printed pages, the application should avoid calling new-page until it is about to print something that belongs on the next page.
range and visible-portion of scroll-bar controls modified. The
range and visible-portion of a
standalone scroll-bar controls (horizontal-scroll-bar and vertical-scroll-bar) have
changed their meaning. The range now excludes the visible-portion. This
is a backward incompatibility.
In 5.0.1 (and earlier), the range of standalone scroll-bar controls included the visible-portion of the scroll-bar, which made it similar to the whole "page" of a scrollable window rather than the scrolling range (which is the page minus the visible portion of the page). This was an inconsistent usage of the CG scroll-range concept. It also meant, for example, if the range of a standalone scroll-bar control was 0 to 100 and the visible-portion was 20, then the possible values of the scrollbar actually ranged from 0 to 80 rather than the alleged range of 0 to 100.
In 5.0.1 and earlier, one way to disable a scroll-bar dialog-item had been to set its visible-portion greater than or equal to the range. In 6.0, this no longer makes sense since the scrollable range is independent of the thumb length. The corresponding new way to disable a scroll-bar control is to set the range with the min value equal to the max value, such as (0 0). (As with other widgets, a scroll-bar may also be disabled by setting its available property to nil.
dialog-mixin instances. The
exception was deemed more confusing than useful. Note: if your
5.0.1 application creates dialogs without passing the :pop-up initarg
to make-window,
and then calls pop-up-modal-dialog on these
dialogs, then the code should be modified so that it either passes
":pop-up t" to make-window or passes
":child-p nil". See pop-up).
common-graphics package as
well as the devel package.
common-graphics package as well
as the windows package.
excl package as well as the
aclwin package.
common-graphics package. The unexported items were
considered not useful for user code, but the functionality remains in
the release.
code-file: now
devel::code-file, with the same functionality.event-handling-processes: removed. In 5.0.1,
described as a placeholder for later development, but a different
development path was chosen.main-event-handler: removed. In 5.0.1,
described as a placeholder for later development, but a different
development path was chosen.hiword:
unexported but has same functionality. It is a
functional version of the following form (the argument was an integer
n): (logand #xffff (ash n -16))read-only-p: unexported but has same
functionality.marker-char: removed. This
function returned the character used in the Debug window prompt, but
in 6.0, that is the same as all Allegro CL prompts.reinitialize-system: unexported but has same
functionality.simple-stream-p:
removed. In 5.0.1, simple-stream had a different meaning.texture-array-ref: unexported but has same
functionality and see contents-ref.texture-array-set: unexported but has same
functionality and see contents-set.user-close-primary-window: removed. See user-close.widget-tab-control: unexported but has same
functionality.mouse-in:
no longer has a value (i.e. not a constant) but symbol still
exists naming a generic function.mouse-out:
no longer has a value (i.e. not a constant) but symbol still
exists naming a generic function.do-streams:
removed.#.(MAKE-POSITION 1
1). In 6.0, it is #<position 1 1>. The
former is machine readable and the latter is not. The problem is that
the old representation created a position constant which could
(despite technically being a constant) be modified (with setf of
position-x, for
example). Such constants are very dangerous in multi-threaded code
because they can be changed simultaneously by two threads. To avoid
such problems, printed representations are no longer machine readable.
The same applies to the printed representation of a box, formerly
#.(MAKE-BOX 1 2 4) and now
#<box 1 2 3 4>.
(in-package ...) form and sets the package of the
editor appropriately. See the description of the Editor Workbook
dialog.
The :parent argument should be replaced with
:owner. The preferred initarg to make-window to specify the parent
and/or owner of the window is now :owner rather than :parent, though
:parent will still work for backward compatibility. The reasoning is
that formerly when creating a top-level window, one would pass a
window as the value of the :parent initarg even though that window
became the owner of the window and not the parent. But since a parent
window is now always also the owner window, the window that is passed
as the :owner (or :parent) initarg is now always really the owner, and
in addition is also the parent if the child-p property of the new window
is true.
The :device argument should be replaced with
:class. The preferred initarg to make-window for specifying the name
of the class to instantiate is now :class rather than :device, though
:device continues to work for backward compatibility. This change is
to make the initarg name easier to remember. The corresponding
property of form windows is now called class,
though its accessor function is still device, due to the presence of the
existing Common Lisp symbols class and
class-name.
The :widgets argument should be replaced with
:dialog-items. The preferred initarg to make-window for the list
of dialog-items (also known as controls or widgets) to place on the
new window is now :dialog-items rather than :widgets. This change is
to make the initarg match the name of the associated accessor function
and property (dialog-items). :widgets will still
work for backward compatibility.
lisp-text
and multi-line-lisp-text
classes/controls, removed from Common Graphics, in release 5.0, have
now been restored.
widget-window and
lisp-widget-window.
list-view control now allows an icon
to be displayed in each row, and can do all four list-view layout
styles (as in the Windows File Explorer).
horizontal-scroll-bar and vertical-scroll-bar
pages.
windows-screen-device is now
exported and is the type-of the screen object.
windows-graphics is now exported,
and names the class of all streams that can be drawn on.
radio-button groups of
contiguous items on a menu.
bitmap-pane
and the drawable control allow copying and
pasting pixmaps between these streams and the clipboard. (For the
drawable control, the use-bitmap-stream property must
first be turned on.) The new setfable function clipboard-object can be used in
place of the separate clipboard-string and clipboard-pixmap
functions. The new generic function clipboard-changed could be wrapped
by applications to catch whenever the clipboard's contents have
changed.
When opening a printer stream with the no-dialog-p option, the stream was not defaulting to the values most recently chosen by the user on the Page Setup or Print dialogs, such as the orientation and which printer to print to.
The multicolor, paper-source, print-quality, and scale printer properties contained arbitrary (and often incorrect) values when the printer driver did not support multiple options for these properties; the properties will now be nil in this case.
pop-up-printer-setup-dialog (for the Page Setup dialog) returns four additional values: paper-source, port-name, printer-name, and driver-name.
There is a new paper-source printer property.
The new function printer-names returns a list of available printers; one of these may be passed as the :printer-name initarg to open-stream, along with the :no-dialog-p option, to programmatically specify the printer for a print job.
;; The finder-function, which returns the window if it already
;; exists, and otherwise creates and returns it.
;; Call this function if you need only one copy of this window,
;; and that window is a non-owned top-level window.
(defun form1 () (find-or-make-application-window :form1 'make-form1))
;; The maker-function, which always creates a new window.
;; Call this function if you need more than one copy,
;; or the single copy should have a parent or owner window.
;; (Pass :owner to this function; :parent is for compatibility.)
(defun make-form1
(&key parent (owner (or parent (screen *system*)))
(exterior (make-box 358 180 1024 550)) (name :form1)
(title "Form1") (border :frame) (child-p t) form-p)
static-text widget now has a
wrapping property
to optionally prevent its text from wrapping.
*restart-app-function* set to
a function which starts the IDE. If you call build-lisp-image or generate-application in such an image, be
aware that the value of the restart-app-function
argument is inherited from the running image, so be sure to specify a
value for that argument (specify nil if you
want none) unless you want the IDE to start in the new image.
*starting-ide* is set to nil after
the IDE has finished coming up.
Most of the changes to AllegroStore involve enhancements that support large databases efficiently. The one non-backward-compatible change, other than supporting new versions of ObjectStore (the underlying database used by AllegroStore) is the channel facility has been removed, replaced by the new notification facility.
There is a new version of the AllegroStore manual. In 6.0, it is a PDF file (allegrostore.pdf).
New version of ObjectStore on certain platforms: YOU MUST DUMP YOUR DATABASE BEFORE USING THE NEW VERSION. On the Windows, Solaris, and Irix platforms (but not on HP's), AllegroStore uses the new ObjectStore 6.0 major release. Since ObjectStore 5.x databases are not compatible with ObjectStore 6.0, users on these platforms must convert their existing databases. Before installing Ostore 6.0/Astore 2.0, create a dump file for each database using asdump. Be sure to use the latest Astore 1.3 asdump version available at the Franz ftp site.
Wed Apr 19 15:22:28 PDT 2000
Patch: asdump
asverify
Allegrostore patch: asdump now correctly identifies and discards
stale pointers. asverify will no longer crash when encountering
stale pointers.
Impact: Recommended.
After installing Ostore 6.0/Astore 2.0, create Astore databases with asrestore. We recommend that you do the dump prior to installing the new version.
The major benefit that Ostore 6.0 provides Astore users is an increased ability to create very large databases.
The current OS version/Ostore release version information:
Solaris:: Solaris 2.7 is supported, Solaris 2.8 is not supported. Uses Ostore 6.0 SP4.
Windows: Windows 95, 98, NT, and 2000 are all supported. Uses Ostore 6.0 SP4. See 6.2.2 Special note for users on Windows.
Irix: Irix 6.5 is supported. Uses Ostore 6.0 SP4.
Linux: Redhat 6.0 is supported. Redhat 5.x is not supported. Uses Ostore 5.0 SP5 Beta. See 6.2.1 Special note for users on Linux for more information on AllegroStore on Linux.
HP: HP/UX 10.20 and 11.0 are supported. Uses Ostore 5.1 SP3. (Note that the HP/UX 11.0 Astore 2.0 release uses a custom Lisp executable, aslisp, as did the HP/UX 10.20 Astore 1.3 release. However, the HP/UX 10.20 Astore 2.0 release does not include an aslisp custom Lisp executable because Astore 2.0 runs with the usual Lisp executable under HP/UX 10.20.)
HP 64: HP/UX 11.0 is supported. Uses Ostore 6.0SP4. A supplied custom Lisp executable, aslisp, is required when running AllegroStore.
persistent-ftype-array class is now available that
allows allocating, setting, and accessing persistent memory without
creating a parallel lisp object in the lisp heap. Persistent ftype
(foreign type) arrays are more powerful than the
blob class because persistent ftype array data may
contain pointers to persistent addresses. See section 6.9 of the
AllegroStore Manual.
Astore 2.0 on Linux is based on the Ostore 6.0 SP5 Beta release, which is the first Linux ObjectStore release. Here are issues related to the ObjectStore Beta version status:
chmod o+w /tmp/ostore/*One Windows 98 beta tester reported problems that were related to using Windows file dialogs: if a Windows file dialog is popped up before ObjectStore is initialized, a hard crash or hung process can occur after the dialog is destroyed.
To prevent this, call
(astore::ensure-objectstore-initted) before doing
any activity that causes a Windows file dialog to pop up.
Windows VAR customers should take note: if your application includes
functionality that uses Windows file dialogs, you should call
(astore::ensure-objectstore-initted)
in your application
initialization function. This will prevent problems on customers'
machines even if you don't see a problem on your development machine.
As said above, functions called on a frame-with-single-child are no longer redirected to the frame-child.
In earlier releases, if you called copy-pixmap (for example) on a frame-with-single-child window such as a non-refreshing-window, then the pixmap would actually be drawn on the frame-child pane of the frame-with-single-child instead of on the frame window itself. This redirection was done whenever CG regarded the particular operation as not being useful on the frame. In the copy-pixmap-case, the pixmap would never be seen on the frame because the frame's interior is completely covered by the frame-child pane that is automatically created when a frame-with-single-child class is instantiated. (Drawing CAN be done on any window, though, including a frame-window.) This redirection was effected by approximately 160 methods that specialized on frame-with-single-child, each of which checked for the existence of the frame-child pane and simply called the same generic function on the frame-child if it existed.
This automatic redirection to the frame-child has now been removed from Common Graphics. This feature is no longer considered worthwhile because (1) if it is desirable to really call one of these generic functions on a frame-with-single-child frame window itself, there is no way to do so, (2) it was not obvious that this behavior was an explicit feature, or which generic functions it affected, and so could lead to confusion over whether a frame-with-single-child frame window and child pane are really one window or two, and it required a significant amount of code (the 160 methods) which is not necessary since it is easy for an application to call frame-child on a frame-with-single-child window to find the auto-instantiated child pane (even if there are additional child windows such as a toolbar and status-bar). The policy now is that the programmer should understand that two windows are involved, and to call functions on the appropriate one explicitly.
If an application relies on this feature by calling functions on a frame-with-single-child frame window when the frame-child pane is the actual target, then calls to frame-child will need to be inserted in the application source code to redirect the action as needed.
Frame-with-single-child methods that have been removed from the following generic functions, as well as from some corresponding setf functions. Functions that call these functions may be affected as well (for example, copy-pixmap did not have such a method, but it calls copy-pixels-to-stream, which did have such a method). Application calls to these functions where a frame-with-single-child frame window is passed probably should pass the frame-child in almost all cases.
animate-color-number, background-color, background-texture, bottom-margin, char-from-line-number, clipping-box, close-palette, color-number, copy-pixels-to-stream, copy-stream-area, create-pixmap-handle, current-line-number, current-text-column, cursorcursor-position, default-background-color, default-foreground-color, draw-box, draw-circle, draw-circle-arc, draw-circle-sector, draw-ellipse, draw-ellipse-arc, draw-ellipse-sector, draw-icon, draw-polygon, draw-polyline, draw-rounded-box, draw-string-in-box, draw-to, fill-box, fill-circle, fill-circle-sector, fill-ellipse, fill-ellipse-sector, fill-polygon, fill-rounded-box, fill-texture, fill-texture-size, first-visible-line, font, font-faces, font-handle, font-sizes, foreground-color, get-selection, get-texture, get-texture-info, invalidate-window, invert-box, left-margin, line-dashing, line-end, line-height, line-join, line-number-from-char, line-texture, line-width, move-to, nclipping-box, ncurrent-position, ncursor-position, nfill-texture-origin, nfontmetrics, nget-box, nget-fixed-box, nget-line, nget-position, nget-shape-box, nget-shape-fixed-box, nget-shape-line, nscroll-position, nstream-origin, nstream-string-corners, nstream-string-size, number-of-text-lines, nvisible-box, open-palette, page-height, page-width, paint-operation, palette, palette-size, pixel, pop-up-printer-job-dialog, property-default-value-p, realize-palette, release-mouse, right-margin, scroll-box, scroll-range, scroll-to, scrollbars, set-first-visible-line, set-graphics-context, set-page-size, set-scroll-range, set-selection, stream-char-width, stream-string-width, stream-units-per-inch, text-line, top-margin, transparent-character-background.
Drawing using graphic objects is no longer supported. This is a backwardly incompatible change.
As an alternative to functions such as draw-line or draw-ellipse, where all coordinates are