Custom Query (1030 matches)
Results (694 - 696 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #949 | fixed | RESTART-CASE with :TEST & :INTERACTIVE broken | ||
| Description |
There seems to be some odd behavior in RESTART-CASE when a restart clause has both test and interactive expressions. In the attached file, the only difference between TEST-BROKEN-RESTART and TEST-WORKING-RESTART is that the latter’s restart clause has no test expression. ./dx86cl64 --no-init Welcome to Clozure Common Lisp Version 1.9-dev-r15272M-trunk (DarwinX8664)! ? (load "~/broken-restart.lisp") #P"/Users/greg/broken-restart.lisp" This case behaves correctly – the test fails, so the restart is not offered. ? (test-broken-restart 'non-restartable-error) > Error: Condition #<NON-RESTARTABLE-ERROR #x30200072ED8D> 1 > :r > Type (:C <n>) to invoke one of the following restarts: 0. Return to break level 1. 1. #<RESTART ABORT-BREAK #x7EBECD> 2. Return to toplevel. 3. #<RESTART ABORT-BREAK #x7EC5AD> 4. Reset this thread 5. Kill this thread 1 > :pop This case fails – the test passes and the restart is offered, but when the restart is selected, rather than calling the interactive expression, some anonymous restart is used, and another error is signaled. ? (test-broken-restart 'restartable-error) > Error: Condition #<RESTARTABLE-ERROR #x302000726B1D> 1 > :r > Type (:C <n>) to invoke one of the following restarts: 2. #<RESTART BROKEN #x7EC16D> 1 > :c 2 Invoking restart: NIL 432345564230164480 is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed 1 > :pop This is the same as the previous case, but with the test expression removed. This time it works – the restart is selected, then it interactively asks for a value. ? (test-working-restart 'restartable-error) > Error: Condition #<RESTARTABLE-ERROR #x302000721A6D> 1 > :r > Type (:C <n>) to invoke one of the following restarts: 2. #<RESTART WORKING #x7EC16D> 1 > :c 2 Invoking restart: #<RESTART WORKING #x7EC16D> Enter a value: 5 5 ? |
|||
| #1018 | fixed | congruent lambda-lists | ||
| Description |
CCL currently doesn’t accept the following form: (defgeneric foo (&key bar &allow-other-keys)
(:method (&key)
nil))
complaining that `Lambda list of method #<STANDARD-METHOD FOO NIL> is incompatible with that of the generic function FOO.` However, section 7.6.4.5 of the spec says “The use of &allow-other-keys need not be consistent across lambda lists. If &allow-other-keys is mentioned in the lambda list of any applicable method or of the generic function, any keyword arguments may be mentioned in the call to the generic function,” which means that the former example should behave the same as (defgeneric foo (&key bar &allow-other-keys)
(:method (&key &allow-other-keys)
nil))
which works.
(The |
|||
| #4 | fixed | Problem loading additional frameworks in 070408 snapshot | ||
| Description |
Not sure if this is a bug or changes required on my end due to bridge changes re: framework loading as the error message isn't telling me anything helpful (I've attached the backtrace as Trac seems to want to wrap everything making it very difficult to read) |
|||
