Strange package locking behaviour

Hi,

Can anyone explain the following to me?

CL-USER> (sb-ext:with-unlocked-packages (:sb-kernel)
           (sb-impl::package-lock-violation-p (find-package :sb-kernel) 'sb-kernel:type-expand))
  0: (SB-IMPL::PACKAGE-LOCK-VIOLATION-P #<PACKAGE "SB-KERNEL">
                                        SB-KERNEL:TYPE-EXPAND)
  0: SB-IMPL::PACKAGE-LOCK-VIOLATION-P returned NIL
NIL
CL-USER> (sb-ext:with-unlocked-packages (:sb-kernel)
           (defun sb-kernel::foo (form) (typexpand form)))
  0: (SB-IMPL::PACKAGE-LOCK-VIOLATION-P #<PACKAGE "SB-KERNEL"> SB-KERNEL::FOO)
  0: SB-IMPL::PACKAGE-LOCK-VIOLATION-P returned T
  0: (PACKAGE-LOCK-VIOLATION #<PACKAGE "SB-KERNEL"> :SYMBOL SB-KERNEL::FOO
                             :FORMAT-CONTROL "proclaiming ~S as a function"
                             :FORMAT-ARGUMENTS (SB-KERNEL::FOO))
; 
; compilation unit aborted
;   caught 1 fatal ERROR condition
; Evaluation aborted on #<SYMBOL-PACKAGE-LOCKED-ERROR "proclaiming ~S as a function" {C6E8429}>.

I've traced SB-IMPL::PACKAGE-LOCK-VIOLATION-P and
SB-IMPL::PACKAGE-LOCK-VIOLATION. I don't understand why I only get a
violation on the second example, since it seems to me I should have
turned them off in both.

I hope I'm not missing something obvious...

Rupert

Re: Strange package locking behaviour

On 3 January 2012 14:17, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:

> Can anyone explain the following to me?

Short version: there is a compile-time side-effect from compiling the
DEFUN, which takes place before the package has been unlocked.

Gory details:

DEFUN expands into an SB-INT:NAMED-LAMBDA, compiling of which has some
side-effects we want package-locks to protected against -- namely
proclaiming the named function and removing a pre-existing
macro-definition.

This itself is wrong, since it happens in global scope, and not only
in the lexical scope of the NAMED-LAMBDA as it should.

So package locks are working right, but at an unexpected time, because
the compiler is treating DEFUN a bit too specially.

Try this for fun:

(defmacro foo () :macro)

(foo) => :MACRO

(defvar *foo* (compile nil `(lambda () (defun foo () :function))))

(foo) =| error: undefined function FOO

Re: Strange package locking behaviour

Nikodemus Siivola <nikodemus <at> random-state.net> writes:
> On 3 January 2012 14:17, Rupert Swarbrick <rswarbrick <at> gmail.com> wrote:
>
>> Can anyone explain the following to me?
>
> Short version: there is a compile-time side-effect from compiling the
> DEFUN, which takes place before the package has been unlocked.
>
> Gory details:
>
> DEFUN expands into an SB-INT:NAMED-LAMBDA, compiling of which has some
> side-effects we want package-locks to protected against -- namely
> proclaiming the named function and removing a pre-existing
> macro-definition.
>
> This itself is wrong, since it happens in global scope, and not only
> in the lexical scope of the NAMED-LAMBDA as it should.
>
> So package locks are working right, but at an unexpected time, because
> the compiler is treating DEFUN a bit too specially.

Thank you very much: I understand what's going on now!

Rupert

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 

"never used" warning when combining &rest and &key arguments

Sometimes I find it useful to combine &rest and &key arguments in a
lambda list, especially if I want the key arguments to show up in the
editor hints, have defaults, etc, but I plan to pass them to another
function.  For example, (ignore what mosaic is, it is not relevant)

(defun make-mosaic-vector (mosaic &rest make-array-arguments 
                                  &key (element-type t) initial-element
                                       initial-contents)
  (make-mosaic-vector% :mosaic mosaic
                       :elements (apply #'make-array (mosaic-size mosaic)
                                        make-array-arguments)))

But unless I

(declare (ignore element-type initial-element initial-contents))

SBCL gives me a style-warning about these variables.  I am not
reporting this as a bug because I am not sure what the correct
behavior is (and I could not find anything about this in the HS), but
my intuition is that those variables are used, in the form of
make-array-arguments.  Am I wrong, or is this a (minor) bug?

Best,

Tamas

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 

"never used" warning when combining &rest and &keyarguments

>But unless I
>
>(declare (ignore element-type initial-element initial-contents))

I would write "ignorable", not "ignore": you want to say you supress
"unused" warning, not to promise not to use the variable.

>SBCL gives me a style-warning about these variables.  I am not
>reporting this as a bug because I am not sure what the correct
>behavior is (and I could not find anything about this in the HS), but

"
When not within the scope of a ignore or ignorable declaration, it is desirable for a compiler to issue a
warning about any var for which there is neither a for-value reference nor a special declaration, or about
any fn for which there is no for-value reference.
"

Formally, SBCL follows the spec.

>my intuition is that those variables are used, in the form of
>make-array-arguments.  Am I wrong, or is this a (minor) bug?

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

GLIBC_2.14 not found

I've installed the 1.0.55 amd64 binary distribution.
When I try to run SBCL, it fails with:

sbcl: /lib/libc.so.6: version `GLIBC_2.14' not found (required by sbcl)

running on debian 5.0.8, kernel 2.6.26-2-amd64 #1 SMP

gg

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2

Setf in macroexpansion causing warning about variable being defined but not used

Hello,

I am wondering if anyone can explain the reason for the defined
but not used variable in setf that this code is experiencing:

CL-USER> (set-macro-character  #\$
                      (lambda (stream char)
                        (declare (ignore char))
                        (let ((v (read stream)))
                          (list (get v 'setf-handler-name) v))))

(defmacro defactive (var value &key write-handler read-handler)
  (let ((setf-handler-name (gensym)))
    `(progn
       (defparameter ,var ,value)
       (defmacro ,setf-handler-name (,var)
         (let ((read-handler (gensym)))
           `(let ((,read-handler (get ',',var :read-handler)))
              (if ,read-handler
                  (funcall ,read-handler (eval ,',var))
                  ,',var))))
       (defsetf ,setf-handler-name (,var) (new-val)
         (let ((write-handler (gensym)))
           `(let ((,write-handler (get ',',var :write-handler)))
              (when ,write-handler
                (funcall ,write-handler (eval ,',var) ,new-val))
              (setf ,',var ,new-val))))
       (setf (get ',var 'setf-handler-name) ',setf-handler-name)
       (setf (get ',var :write-handler) ,write-handler)
       (setf (get ',var :read-handler) ,read-handler)

[Sbcl-devel] ELS2012 Zadar, Croatia, Call for Papers

Apologies for the multiple postings...

===========================================================================

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012
http://european-lisp-symposium.org

The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We
encourage everyone interested in Lisp to participate.

The main theme of the 2012 European Lisp Conference is
"Interoperabilty: Systems, Libraries, Workflows".  Lisp based and
functional-languages based systems have grown a variety of solutions
to become more and more integrated with the wider world of Information
and Communication Technologies in current use.  There are several
dimensions to the scope of the solutions proposed, ranging from
"embedding" of interpreters in C-based systems, to the development of
abstractions levels that facilitate the expression of complex context
dependent tasks, to the construction of exchange formats handling
libraries, to the construction of theorem-provers for the "Semantic
Web".  The European Lisp Symposium 2012 solicits the submission of
papers with this specific theme in mind, alongside the more
traditional tracks which have appeared in the past editions.

We invite submissions in the following forms:

Re: Setf in macroexpansion causing warning about variable being defined but not used

On 21 January 2012 00:46, Burton Samograd <burton.samograd <at> gmail.com> wrote:

>       (defmacro ,setf-handler-name (,var)
>         (let ((read-handler (gensym)))
>           `(let ((,read-handler (get ',',var :read-handler)))
>              (if ,read-handler
>                  (funcall ,read-handler (eval ,',var))
>                  ,',var))))

>       (defsetf ,setf-handler-name (,var) (new-val)
>         (let ((write-handler (gensym)))
>           `(let ((,write-handler (get ',',var :write-handler)))
>              (when ,write-handler
>                (funcall ,write-handler (eval ,',var) ,new-val))
>              (setf ,',var ,new-val))))

Both places where you use EVAL are wrong. You should be just splicing
in the VAR bound by the macro and defsetf. Study the macroexpansions
and you'll see it.

(defmacro defactive (var value &key write-handler read-handler)
  (let ((setf-handler-name (gensym)))
    `(progn
       (defparameter ,var ,value)
       (defmacro ,setf-handler-name (read-var)
         (let ((read-handler (gensym)))
           `(let ((,read-handler (get ',',var :read-handler)))
              (if ,read-handler
                  (funcall ,read-handler ,read-var)
                  ,read-var))))