Basic error on CCL

[Eric]

Hi,

I'm running CCL 1.4 on Mac OSX (PPC), and the basic weblocks demo
breaks for me out of the box. When I run (weblocks:start-weblocks) it
blows up like so:

value CCL::*NX-CURRENT-CODE-NOTE* is not of the expected type (MEMBER
SETF

LAMBDA).

Hunchentoot runs fine on my machine – is there something going on with
weblocks here, or have I done something wrong?

Any hints appreciated! Here's the full backtrace:

Backtrace:
0: (#<Anonymous Function #x90B8EBE> #'(CCL::*NX-CURRENT-CODE-NOTE*
NIL) (LAMBDA (&OPTIONAL #1=#:G120862 &REST #2=#:G120863) ..)
#<CCL::LEXICAL-ENVIRONMENT #x9EDB86E>)
1: (CL-CONT::APPLICATION->CPS CL-CONT::FUNCALL/CC (#'COMPILER-LET
((CCL::*NX-CURRENT-CODE-NOTE* NIL)) ..)) (LAMBDA (&OPTIONAL
#1=#:G120715 &REST #2=#:G120716) ..) NIL #<CCL::LEXICAL-ENVIRONMENT
#x9E626D6..
2: (CL-CONT:EXPR-SEQUENCE->CPS ("Presents 'callee' to the user in a
modal dialog, saves the\ncontinuation, and returns from the delimited
computation. When\n'callee' answers, removes the modal interface ..
3: (#<Anonymous Function #x90BE886> (BLOCK WEBLOCKS::DO-DIALOG ..)
#:G120711 #<CCL::LEXICAL-ENVIRONMENT #x9E626D6>)
4: (CL-CONT::LAMBDA-EXPR->CPS (LAMBDA (WEBLOCKS::TITLE
WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS CLOSE) ..) NIL
#<CCL::LEXICAL-ENVIRONMENT #x9E626D6>)
5: (#<Anonymous Function #x9A2F65E> (DEFUN WEBLOCKS::DO-DIALOG
(WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS CLOSE) ..)
#'VALUES #<CCL::LEXICAL-ENVIRONMENT #x9E626D6>)
6: (NIL #<Unknown Arguments>)
7: (CL-CONT:WITH-CALL/CC (CL-CONT:WITH-CALL/CC (DEFUN WEBLOCKS::DO-
DIALOG (WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS
CLOSE) ..)) #<CCL::LEXICAL-ENVIRONMENT #x9E626D6>)
8: (NIL #<Unknown Arguments>)
9: (FUNCALL #<Compiled-function CL-CONT:WITH-CALL/CC Macroexpander
#x9A2E8DE> (CL-CONT:WITH-CALL/CC (DEFUN WEBLOCKS::DO-DIALOG
(WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS CLOSE) ..))
#<CCL..
10: (MACROEXPAND-1 (CL-CONT:WITH-CALL/CC (DEFUN WEBLOCKS::DO-DIALOG
(WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS CLOSE) ..))
#<CCL::LEXICAL-ENVIRONMENT #x9E626D6>)
11: (NIL #<Unknown Arguments>)
12: (CCL::FCOMP-MACROEXPAND-1 (CL-CONT:WITH-CALL/CC (DEFUN
WEBLOCKS::DO-DIALOG (WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY
WEBLOCKS::CSS-CLASS CLOSE) ..)) #<CCL::LEXICAL-ENVIRONMENT #x9E626D6>)
13: (NIL #<Unknown Arguments>)
14: (CCL::FCOMP-FORM-1 (CL-CONT:WITH-CALL/CC (DEFUN WEBLOCKS::DO-
DIALOG (WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS
CLOSE) ..)) #<CCL::LEXICAL-ENVIRONMENT #x9E626D6> :NOT-COMPILE-TIME)
15: (NIL #<Unknown Arguments>)
16: (CCL::FCOMP-FORM (CL-CONT:WITH-CALL/CC (DEFUN WEBLOCKS::DO-DIALOG
(WEBLOCKS::TITLE WEBLOCKS::CALLEE &KEY WEBLOCKS::CSS-CLASS CLOSE) ..))
#<CCL::LEXICAL-ENVIRONMENT #x9E626D6> :NOT-COMPILE-TIME)
17: (NIL #<Unknown Arguments>)
18: (CCL::FCOMP-FORM (CL-CONT:DEFUN/CC WEBLOCKS::DO-DIALOG ..)
#<CCL::LEXICAL-ENVIRONMENT #x9E626D6> :NOT-COMPILE-TIME)
19: (CCL::FCOMP-READ-LOOP "/Users/eric/.asdf-install-dir/site/
weblocks-stable/src/control-flow/dialog.lisp" "home:.asdf-install-
dir;site;weblocks-stable;src;control-flow;dialog.lisp.newest" 0
#<CCL::LEXIC..
--more--

[Leslie P. Polzer]

Hi Eric,

> I'm running CCL 1.4 on Mac OSX (PPC), and the basic weblocks demo
> breaks for me out of the box. When I run (weblocks:start-weblocks) it
> blows up like so:
>
> value CCL::*NX-CURRENT-CODE-NOTE* is not of the expected type (MEMBER
> SETF
>
> LAMBDA).
>
> Hunchentoot runs fine on my machine – is there something going on with
> weblocks here, or have I done something wrong?

Neither, I think.

This looks like a newly introduced compiler bug in CCL.

Send it to the CCL guys, maybe they can fix it right away.

If not report back here and I'll try to come up with an
isolated test case.

Leslie

[Raymond Wiker]

Not a new error - I saw that quite some time back. I got round this by
the following simple patch:

diff -r efc83a14156b src/control-flow/dialog.lisp
--- a/src/control-flow/dialog.lisp Wed Jul 15 18:01:35 2009 +0200
+++ b/src/control-flow/dialog.lisp Thu Aug 27 18:42:41 2009 +0200
@@ -68,7 +68,7 @@
'callee' answers, removes the modal interface and reactives the
computation. If the modal interface isn't available, automatically
scales down to 'do-modal' instead."
- (assert (stringp title))
+ ; (assert (stringp title))
(if (ajax-request-p)
(prog2
(when (current-dialog)

[Eric]

On Aug 28, 12:43 am, Raymond Wiker <rwi...@gmail.com> wrote:
> On Aug 27, 2009, at 18:30 , Leslie P. Polzer wrote:
>
>
>
>
>
>
>
> > Hi Eric,
>
> >> I'm running CCL 1.4 on Mac OSX (PPC), and the basic weblocks demo
> >> breaks for me out of the box. When I run (weblocks:start-weblocks) it
> >> blows up like so:
>
> >> value CCL::*NX-CURRENT-CODE-NOTE* is not of the expected type (MEMBER
> >>                                                               SETF
>
> >> LAMBDA).
>
> >> Hunchentoot runs fine on my machine – is there something going on  
> >> with
> >> weblocks here, or have I done something wrong?
>
> > Neither, I think.
>
> > This looks like a newly introduced compiler bug in CCL.
>
> > Send it to the CCL guys, maybe they can fix it right away.
>
> > If not report back here and I'll try to come up with an
> > isolated test case.
>
> Not a new error - I saw that quite some time back. I got round this by  
> the following simple patch:

Thanks Raymond, that did the trick, though I hope that won't cause
further problems in the future! Let me know if something should still
be said to the CCL folks.

Thanks again,
Eric

[Leslie P. Polzer]

On Aug 28, 2:57 am, Eric <gir...@gmail.com> wrote:

> Thanks Raymond, that did the trick, though I hope that won't cause
> further problems in the future! Let me know if something should still
> be said to the CCL folks.

Yes, definitely. There's some bug in their compiler.

[John Fremlin]

I ran across this at work but was doing something else so didn't dive
in.

The problem I think is that cl-cont doesn't understand ccl's
compiler-let. Another example where macroexpand-dammit should step in
:-)

Perhaps the most practical solution is to make assert not be call/cc
transformed.

[...]

[Leslie P. Polzer]

On Aug 29, 4:02 am, John Fremlin <j...@fremlin.org> wrote:

> The problem I think is that cl-cont doesn't understand ccl's
> compiler-let.

You're probably right, but CCL's compiler wants to handle that
more gracefully I bet.

> Another example where macroexpand-dammit should step in
> :-)

Since you mention it, where have we left off discussing this?

> Perhaps the most practical solution is to make assert not be call/cc
> transformed.

Got patch? :)

Leslie

[John Fremlin]

Leslie P. Polzer wrote:
> On Aug 29, 4:02 am, John Fremlin <j...@fremlin.org> wrote:
>
>> The problem I think is that cl-cont doesn't understand ccl's
>> compiler-let.
>
> You're probably right, but CCL's compiler wants to handle that
> more gracefully I bet.

compiler-let is a special form that doesn't exist in the ANSI standard
and so it is a bit dodgy to have things expand to it (clearly a
violation of ANSI). However, Lispworks uses it too for things like
defmethod, so teaching cl-cont about it seems like a good idea (if it's

>> Another example where macroexpand-dammit should step in
>> :-)
>
> Since you mention it, where have we left off discussing this?

I thought the problem was not so much the absence of discussion but the
absence of a finished and tested version of macroexpand-dammit ;-)

I fixed a few bugs (http://john.freml.in/macroexpand-dammit) but haven't
got the testsuite together. One issue that is wrong is the handling of
type declarations for symbol-macrolets, but I'm not sure whether it is
possible to handle that correctly at all as one isn't allowed to affect
the macroexpansion. (Declarations are generally a nuisance --
http://john.freml.in/declare-and-parsing-common-lisp.)

>> Perhaps the most practical solution is to make assert not be call/cc
>> transformed.
>
> Got patch? :)

In teepeedee2 there are a bunch of macros IIRC for easily explicitly
declaring forms not to be transformed by cl-cont. . . Or at least I
think so :-)

PS. To complicate matters further, it turns out that cl-cont implements
delimited continuations, but the call/cc is actually more like Scheme's
return/cc -- it has quite different semantics.

[R. Matthew Emerson]

COMPILER-LET started showing up in certain macro expansions (CHECK-
TYPE, ASSERT) at r12345 of CCL.

Looks like there's a patch to CL-CONT attached to the following
ticket:

http://weblocks.lighthouseapp.com/projects/20431/tickets/8-new-clozure-special-form-compiler-let#ticket-8-4

On Aug 29, 3:33 am, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> On Aug 29, 4:02 am, John Fremlin <j...@fremlin.org> wrote:
>
> > The problem I think is that cl-cont doesn't understand ccl's
> > compiler-let.
>
> You're probably right, but CCL's compiler wants to handle that
> more gracefully I bet.

[...]

[John Fremlin]

"R. Matthew Emerson" <r...@clozure.com> writes:

> COMPILER-LET started showing up in certain macro expansions (CHECK-
> TYPE, ASSERT) at r12345 of CCL.

[I find it rather unfortunate that compiler-let is being
resurrected. The modern (ANSI) way of doing it is slightly less
convenient and involves macrolets, but at least it doesn't cause these
problems.]

> Looks like there's a patch to CL-CONT attached to the following
> ticket:
>
> http://weblocks.lighthouseapp.com/projects/20431/tickets/8-new-clozure-special-form-compiler-let#ticket-8-4

Looks good.

This same treatment should be applied to #+lispworks
lispworks:compiler-let and possibly #+allegro excl::compiler-let, and
#+sbcl sb-cltl2:compiler-let (this one is a bit more of a puzzler
because it is only present after (require 'sb-cltl2))

[...]