Hi,
while using cl-gd I faced a problem concerning packages. When I load
cl-gd and evaluate:
(cl-gd:with-image* (200 200)
)
I get NIL. When I do:
(use-package :cl-gd)
(with-image* (200 200)
)
I get the same. But when trying
(in-package :cl-gd)
(with-image* (200 200)
)
I get the error message
; In: WITH-IMAGE* (200 200)
; (200 200)
; Error: Illegal function call.
; ;
; Warning: This function is undefined:
; WITH-IMAGE*
Error in KERNEL:%COERCE-TO-FUNCTION: the function WITH-IMAGE* is undefined.
[Condition of type UNDEFINED-FUNCTION]
I thought after (in-package :cl-gd) the symbols defined in cl-gd are
visible to the lisp-system. Am I wrong?
Besides this I have another question concerning packages and symbols.
What is the difference in using (defpackage #:package1 ...) instead of
(defpackage :package1 ...)?
Thanks in advance
Rolf Wester
On Wed, 15 Oct 2003 12:06:47 +0200, Rolf Wester <······@ilt.fraunhofer.de> wrote:
> while using cl-gd I faced a problem concerning packages. When I load
> cl-gd and evaluate:
>
> (cl-gd:with-image* (200 200)
> )
>
> I get NIL. When I do:
>
> (use-package :cl-gd)
> (with-image* (200 200)
> )
>
> I get the same. But when trying
>
> (in-package :cl-gd)
> (with-image* (200 200)
> )
>
> I get the error message
>
> ; In: WITH-IMAGE* (200 200)
>
> ; (200 200)
> ; Error: Illegal function call.
> ; ;
>
> ; Warning: This function is undefined:
> ; WITH-IMAGE*
>
>
> Error in KERNEL:%COERCE-TO-FUNCTION: the function WITH-IMAGE* is undefined.
> [Condition of type UNDEFINED-FUNCTION]
>
> I thought after (in-package :cl-gd) the symbols defined in cl-gd are
> visible to the lisp-system. Am I wrong?
No, you're right. Are you sure you don't have a typo in there? It
works fine for me:
···@bird:~ > cmucl
; Loading #p"/home/edi/.cmucl-init".
CMU Common Lisp 18e, running on bird.agharta.de
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2003-04-03 15:47:12+02:00 on orion
Send questions and bug reports to your local CMUCL maintainer,
or see <http://www.cons.org/cmucl/support.html>.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS 18e (based on PCL September 16 92 PCL (f))
* (asdf:oos 'asdf:load-op :cl-gd)
; loading system definition from /usr/local/lisp/Registry/cl-gd.asd into
; #<The ASDF1017 package, 0/9 internal, 0/9 external>
; registering #<SYSTEM #:CL-GD {48516CCD}> as CL-GD
; loading system definition from /usr/local/lisp/Registry/uffi.asd into
; #<The ASDF1020 package, 0/9 internal, 0/9 external>
; registering #<SYSTEM UFFI {48540FC5}> as UFFI
#p"/usr/local/lisp/source/gd/cl-gd-glue.so"
NIL
* (in-package :cl-gd)
#<The CL-GD package, 259/390 internal, 66/66 external>
* (with-image* (200 200))
NIL
> Besides this I have another question concerning packages and symbols.
> What is the difference in using (defpackage #:package1 ...) instead of
> (defpackage :package1 ...)?
That's a very subtle issue probably not worth thinking about.
* (apropos "foobar")
* '#:foobar
#:FOOBAR
* (apropos "foobar")
* :foobar
:FOOBAR
* (apropos "foobar")
:FOOBAR [constant] value: :FOOBAR
See? With #:FOOBAR you have a "throw-away" symbol, kind of. It isn't
interned in any package. The :FOOBAR symbol is interned (in the
keyword package).
You could also use (DEFPACKAGE "PACKAGE1") which also wouldn't intern
a symbol. But this wouldn't play nicely with AllegroCL's "modern"
mode. Some people think this is a feature... :)
Edi.
Thank you very much for your reply.
Edi Weitz wrote:
> On Wed, 15 Oct 2003 12:06:47 +0200, Rolf Wester <······@ilt.fraunhofer.de> wrote:
>
>
> No, you're right. Are you sure you don't have a typo in there?
It's not a typo but it seems to be a problem with ILISP. When I start
CMUCL within XEmacs and type directly into the CMCUL REPL
(in-package :cl-gd)
(with-image* (200 200) )
I get no error message. When I have this two forms within a lisp-file
and evaluate them with C-C C-E I get the error message.
>
>
>>Besides this I have another question concerning packages and symbols.
>>What is the difference in using (defpackage #:package1 ...) instead of
>>(defpackage :package1 ...)?
>
>
> That's a very subtle issue probably not worth thinking about.
>
> * (apropos "foobar")
>
> * '#:foobar
>
> #:FOOBAR
> * (apropos "foobar")
>
> * :foobar
>
> :FOOBAR
> * (apropos "foobar")
>
> :FOOBAR [constant] value: :FOOBAR
>
> See? With #:FOOBAR you have a "throw-away" symbol, kind of. It isn't
> interned in any package. The :FOOBAR symbol is interned (in the
> keyword package).
>
> You could also use (DEFPACKAGE "PACKAGE1") which also wouldn't intern
> a symbol. But this wouldn't play nicely with AllegroCL's "modern"
> mode. Some people think this is a feature... :)
>
I think I got it now: (defpackage #:cl-gd ...) means that the package
cl-gd is created but the symbol cl-gd is not interned into the
current package.
Thanks again
Rolf Wester
On Thu, 16 Oct 2003 09:54:19 +0200, Rolf Wester <······@ilt.fraunhofer.de> wrote:
> It's not a typo but it seems to be a problem with ILISP. When I
> start CMUCL within XEmacs and type directly into the CMCUL REPL
>
> (in-package :cl-gd)
> (with-image* (200 200) )
>
> I get no error message. When I have this two forms within a
> lisp-file and evaluate them with C-C C-E I get the error message.
This may be related to the way ILISP tries to be helpful when
evaluating a form. Basically it temporarily changes the current
package while evaluating a form with C-c C-e. It looks like in your
case it uses a wrong package when evaluating the WITH-IMAGE* form. The
mechanism is described in the ILISP info docs:
The first time an inferior Lisp mode command is executed in a
Lisp Mode buffer, the package will be determined by using the
regular expression `ilisp-hash-form-regexp' to find a package sexp
and then passing that sexp to the inferior Lisp through
`ilisp-package-command'. For the `common-lisp' dialect, this will
find the first `(in-package PACKAGE)' form in the file. A buffer's
package will be displayed in the mode line. If a buffer has no
specification, forms will be evaluated in the current inferior Lisp
package.
Buffer package caching can be turned off by setting the variable
`lisp-dont-cache-package' to `T'. This will force ILISP to search
for the closest previous "in-package" form corresponding to
`ilisp-hash-form-regexp' in the buffer each time an inferior Lisp
mode command is executed.
`<C-z> P (set-package-lisp)'
Set the inferior Lisp package to the current buffer's package
or with a prefix to a manually entered package.
`<C-z> p (set-buffer-package-lisp)'
Set the buffer's package from the buffer. If it is called with
a prefix, the package can be set manually.
So you should try if the same thing still happens if you set
lisp-dont-cache-package to t. If that's the case you might want to
report this as a bug to the ILISP mailing list.
Cheers,
Edi.
Edi Weitz wrote:
>
> So you should try if the same thing still happens if you set
> lisp-dont-cache-package to t. If that's the case you might want to
> report this as a bug to the ILISP mailing list.
>
> Cheers,
> Edi.
Thanks Edi. (setq lisp-dont-cache-package t) solves the problem.
Regards
Rolf
From: james anderson
Subject: Re: A package related problem / What is difference between Defpackage Vs MakePackage....
Date:
Message-ID: <3F8D2E10.1FBA667D@setf.de>
Rolf Wester wrote:
>
> [already handled elsewhere]
>
> I thought after (in-package :cl-gd) the symbols defined in cl-gd are
> visible to the [reader]. Am I wrong?
the external symbols are.
>
> Besides this I have another question concerning packages and symbols.
> What is the difference in using (defpackage #:package1 ...) instead of
> (defpackage :package1 ...)?
>
···············@yahoo.com (Raghuram) writes:
> Could anybody tell me what is the difference between defpackage Vs
> Makepackage? Both the methods are used to create a new package. I
> found no difference in both of them, in usage and in parameters.
defpackage is a macro, which means it does not evaluate its arguments.
make-package is a function, which means that it does.
one of the consequences is that many macro expansions for defpackage take the
opportunity to constant-fold the argument values to strings. which, while not
standardized, does mean that, in practice, a distinction between the original
designators, like :asdf and #:asdf, cannot be found in compiled code.
...