[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MACL bugs

Attached is a list of bugs I've found in MACL, AID, and the Examples.
If I am mistaken or there or work arounds, please email me.



;;common lisp bugs

count-if & count-if-not return nil instead of zero when passed nil lists

(count-if #'fixnump nil)
(count-if-not #'fixnump nil)

Simple work around by using equivalent forms:

(count-if #'foo bar) <=> (count t bar :key #'foo)
(count-if-not #'foo bar) <=> (count nil bar :key #'foo)


The :conc-name keyword to defstruct does not supress creation of
the default accessor functions.

(defstruct (activation-record (:conc-name AR-))
  (name nil)
  (bindings nil)
  (cur-inst nil)

both activation-record-name & AR-name are created as accessor funtions.
The way I read Steele, only the latter should be created.

;;AID bugs

using Undo resize causes acl to exit

set item font causes an error

AID doesn't handle items that need to do something special when removed (like
de-allocate storage) When you switch from design mode to use mode
the palette removes its items and then expects to be able to use them
again later without creating them again.

;;Example's bugs

Bugs in the icon-dialog-items
  1) The highlighting routine assumes that the icons are always 32x32 even
  though the class allows for arbitrary sized icons.
  2) The error message in plot-icon, "no icon resource with id ~s" supplies
  icon for ~s, however, icon was just set to nil (that's what triggered the
  error message). Thus, the error message always prints nil for the resource id.

;;Toolbox interface bugs/issues

Records.Lisp's definition of Rect has a field bottomRight instead of botRight

I tried using
	(_GetHandleSize :check-error :a0 iconHandle :d0)
It doesn't work with the :check-error keyword. It works fine if I
remove it. I believe this is register trap that does the kind of
error signalling the :check-error is designed for. What's wrong.

Using rref and rset with handles doesn't seem to be allowed unless the
handle is locked. Is this correct? If so, why not change rref and rset
to automatically lock/restore the handles.

Passing :ostype argument to traps is a bit devious. Defining a function
like: (defun foo (arg1 arg2)
	(_SomeTrap :word arg1 :ostype arg2 :word))
doesn't quite work because arg2 is expected to be an ostype when the
macro is expanded (i.e. when the function is compiled) not when the
macro's code get's evaluated.  The work around I've been using is to
make functions like these into macros.

This was a really subtle problem to detect, especially since this only
happens for :ostype args (first inclination is to assume :ostype isn't
implemented properly) Since ostype args can be keywords I understand
why this works the way it does. It seems to me that it would be simpler
to only allow 4-char strings as ostype keywords and then this
restriction could be removed. At the very least, this section of
documentation in the manual needs to be improved.

I've been adding background pictures to my dialog boxes by specializing
view-draw-contents to first draw the background and then call the
usual. It works pretty well, except that all the text (static text
items, check/radion button titles) have rectangular which backgrounds.
I've tried setting the txMode of the dialog box, and of the text edit
record of the dialog box to SrcOr but it doesn't seem to do the trick
(they must keep resetting it).  How can I control the transfer mode of
these items.