[Openmcl-devel] "leaking" call-method

Marco Baringer mb at bese.it
Wed Jun 1 17:21:45 UTC 2005


i'm attempting to create a method combination so that my call/cc
implementation (which is nothing more thas a cps transformer) does the
right thing with before and after methods. This requires me to be bale
to, inside the body of a particular method, be it a primary or after
method, get at a closure which wraps up all the remaning methods to
call. here's my current attempt:

--------------------------------
(in-package :common-lisp-user)

(define-method-combination test-combination ()
  ((after (:after))
   (primary () :required t))
  `(let ((*after* ,(when after
                     `(lambda ()
                        (call-method ,(first after))))))
     (declare (special *after*))
     (call-method ,(first primary))))

(defgeneric foo (a)
  (:method-combination test-combination)
  (:method (a)
    (declare (special *after*))
    *after*)
  (:method :after (a)
    'after))

(funcall (foo 4))
--------------------------------

and here's what happens when i run it:

--------------------------------
Can't construct argument list from (-528351542 . -528351540).
   [Condition of type CCL::CANT-CONSTRUCT-ARGLIST]

Restarts:
  0: [ABORT] Abort handling SLIME request.
  1: [ABORT-BREAK] Reset this process
  2: [ABORT] Kill this process

Backtrace:
  0: (CCL::%%CALL-METHOD* #<STANDARD-METHOD FOO :AFTER (T)> 'NIL #<CONNECTION  #x66C6B46>)
      Locals:
        METHOD = #<STANDARD-METHOD FOO :AFTER (T)>
        CCL::NEXT-METHODS = NIL
        CCL::BITS = 276824321
      [No catch-tags]
  1: (FUNCALL #<COMPILED-LEXICAL-CLOSURE #x67EFBDE>)
      Locals:
        CCL::FN = #<COMPILED-LEXICAL-CLOSURE #x67EFBDE>
        CCL::ARGS = NIL
      [No catch-tags]
  2: (CCL::CALL-CHECK-REGS 'FUNCALL)
  3: (#<Anonymous Function #x652809E> "(funcall (foo 4))
")
--------------------------------

the exact values of the cons cell in cant-construct-arglist vary from
one invocation to the next. this make me think something which has
been declared dynamic-extent shouldn't be, but i'm unable to figure
out what.

p.s. - i'm pretty sure this is unspecified behaviour so openmcl is
correct is barfing up, but it would be convenient.

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen



More information about the Openmcl-devel mailing list