I am using SBCL 0.9.8 on a Pentium-IV with a slime from 20 January
2006.
Suppose, in package foo, I have an exported function bar. When I'm in
common-lisp-user, after having executed (use-package :foo), a call to
bar fails with a CLOS related error --- sometimes it's a no applicable
method, sometimes it's undefined variables in make-instance. I
execute (in-package: foo), and the call to bar succeeds. Then I
execute (in-package :common-lisp-user) to go back, and future calls to
bar succeed also. What sorts of things should I be looking for for
this? I feel quite confused...
Cheers,
rif
rif <···@mit.edu> writes:
> I am using SBCL 0.9.8 on a Pentium-IV with a slime from 20 January
> 2006.
>
> Suppose, in package foo, I have an exported function bar. When I'm in
> common-lisp-user, after having executed (use-package :foo), a call to
> bar fails with a CLOS related error --- sometimes it's a no applicable
> method, sometimes it's undefined variables in make-instance. I
> execute (in-package: foo), and the call to bar succeeds. Then I
> execute (in-package :common-lisp-user) to go back, and future calls to
> bar succeed also. What sorts of things should I be looking for for
> this? I feel quite confused...
My telepathic debugger is pointing at *PACKAGE*. Try
(let ((*package* (find-package :foo)))
(bar))
and if that works, start looking for where you used INTERN.
rif wrote:
> I am using SBCL 0.9.8 on a Pentium-IV with a slime from 20 January
> 2006.
>
> Suppose, in package foo, I have an exported function bar. When I'm in
> common-lisp-user, after having executed (use-package :foo), a call to
> bar fails with a CLOS related error --- sometimes it's a no applicable
> method, sometimes it's undefined variables in make-instance. I
> execute (in-package: foo), and the call to bar succeeds. Then I
> execute (in-package :common-lisp-user) to go back, and future calls to
> bar succeed also. What sorts of things should I be looking for for
> this? I feel quite confused...
This sounds like you haven't exported everything from :foo that is
needed. Can you show us an example invocation of bar (with arguments)?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
> This sounds like you haven't exported everything from :foo that is
> needed. Can you show us an example invocation of bar (with arguments)?
>
>
> Pascal
I certainly agree it sounds like that. Unfortunately, the code is
fairly complex and very proprietary, so I can't really show it, and
this bug seems hard to reproduce (it doesn't always happen), so I'm
not sure I'll be able to come up with a simplified example that
reproduces it.
I guess I'm unclear what other kinds of things I should need to export
from package foo. I'd thought that if I exported the function bar
could make use of things that were internal to package foo, and I am
exporting bar (the call to bar is happening). That's always been my
experience in the past. I don't yet understand how it can make a
difference whether I'm in package common-lisp-user or package foo when
I call bar, or what else I might have to export.
I know that since I can't post my code, it's hard to diagnose
completely, but I don't even understand what sorts of things I ought
to be looking for. Any suggestions are appreciated.
Cheers,
rif
+ rif <···@mit.edu>:
| I guess I'm unclear what other kinds of things I should need to export
| from package foo. I'd thought that if I exported the function bar
There is a terminology problem here that just might mask a problem in
understanding which might further be the source of your problem: You
cannot export a function from a package, for the simple reason that
packages don't contain functions. Packages contain /symbols/.
| could make use of things that were internal to package foo, and I am
| exporting bar (the call to bar is happening).
Okay, that says you are not only exporting bar, but you're in a
package that is using package foo, or else you have explicitly
imported foo:bar, or you actually refer to it as foo:bar. Be that as
it may, the question now is with what /other/ symbols that you are
using in the same form where you're calling foo:bar. If you are
referring to any other symbol from package foo you may need to import
it, or use the foo: prefix in referring to it. Otherwise, it
shouldn't matter what package you're in when calling foo:bar. That
is, unless foo:bar explicitly or implicitly does something that
depends on the current value of *package*, such as calling INTERN
without a package argument or reading symbols from a string or a
file.
The thing to remember is that only the Lisp reader (function READ) and
a few other functions like INTERN and LOAD care about the value of
*package*. The way you phrase your questions makes me wonder whether
you realize that.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
rif wrote:
>> This sounds like you haven't exported everything from :foo that is
>> needed. Can you show us an example invocation of bar (with arguments)?
>>
>>
>> Pascal
>
> I certainly agree it sounds like that. Unfortunately, the code is
> fairly complex and very proprietary, so I can't really show it, and
> this bug seems hard to reproduce (it doesn't always happen), so I'm
> not sure I'll be able to come up with a simplified example that
> reproduces it.
>
> I guess I'm unclear what other kinds of things I should need to export
> from package foo. I'd thought that if I exported the function bar
> could make use of things that were internal to package foo, and I am
> exporting bar (the call to bar is happening). That's always been my
> experience in the past. I don't yet understand how it can make a
> difference whether I'm in package common-lisp-user or package foo when
> I call bar, or what else I might have to export.
It can't make a difference. The difference is very likely because of the
arguments that you pass to bar. My guess would be that some of the
arguments need to be constructed by a macro, or so, and that something
goes wrong there. Seeing an argument list would help.
What you could try is to macroexpand the arguments to bar both in
common-lisp-user and in bar and see whether that makes a difference.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> rif wrote:
> >> This sounds like you haven't exported everything from :foo that is
> >> needed. Can you show us an example invocation of bar (with arguments)?
> >>
> >>
> >> Pascal
> > I certainly agree it sounds like that. Unfortunately, the code is
> > fairly complex and very proprietary, so I can't really show it, and
> > this bug seems hard to reproduce (it doesn't always happen), so I'm
> > not sure I'll be able to come up with a simplified example that
> > reproduces it.
> > I guess I'm unclear what other kinds of things I should need to
> > export
> > from package foo. I'd thought that if I exported the function bar
> > could make use of things that were internal to package foo, and I am
> > exporting bar (the call to bar is happening). That's always been my
> > experience in the past. I don't yet understand how it can make a
> > difference whether I'm in package common-lisp-user or package foo when
> > I call bar, or what else I might have to export.
>
> It can't make a difference. The difference is very likely because of
> the arguments that you pass to bar. My guess would be that some of the
> arguments need to be constructed by a macro, or so, and that something
> goes wrong there. Seeing an argument list would help.
>
> What you could try is to macroexpand the arguments to bar both in
> common-lisp-user and in bar and see whether that makes a difference.
>
None of the arguments to bar are constructed by macro. The arguments
are a symbol, a string and an integer, all of which I just type.
There *is* a call to read inside bar, which I thought was the problem
(although I don't actually see how it could be), but when I pulled it
up to do more analysis, I couldn't reproduce the problem. I'll see if
it comes back.
Thanks for the suggestions so far.
rif
rif wrote:
> None of the arguments to bar are constructed by macro. The arguments
> are a symbol, a string and an integer, all of which I just type.
>
> There *is* a call to read inside bar, which I thought was the problem
> (although I don't actually see how it could be), but when I pulled it
> up to do more analysis, I couldn't reproduce the problem. I'll see if
> it comes back.
I would closely follow what happens to the string argument. If you
indeed intern it or read it, it could happen that "inside" package foo,
it gets properly interned, and afterwards calling bar would also work in
common-lisp-user. This could also be the reason why you cannot reproduce
the problem. (This is still just a guess.)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> rif wrote:
>
> > None of the arguments to bar are constructed by macro. The arguments
> > are a symbol, a string and an integer, all of which I just type.
> > There *is* a call to read inside bar, which I thought was the problem
> > (although I don't actually see how it could be), but when I pulled it
> > up to do more analysis, I couldn't reproduce the problem. I'll see if
> > it comes back.
>
> I would closely follow what happens to the string argument. If you
> indeed intern it or read it, it could happen that "inside" package
> foo, it gets properly interned, and afterwards calling bar would also
> work in common-lisp-user. This could also be the reason why you cannot
> reproduce the problem. (This is still just a guess.)
>
>
> Pascal
Yeah, it must be something *like* that. Although I don't think it's
quite that, basically, all the arguments get turned into strings and
turned into a directory name, and the file in that directory is read
from. But I'm sure it's some read-related problem.
rif
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> If you're calling READ, you need to care about the bindings of the
> read-related variables, and *package*. Generally, you should do
> something like:
>
> (with-standard-io-syntax
> (let ((*package* (find-package :something-reasonable)))
> (read foo)))
>
Not to mention, if FOO has any possibility of coming from
outside your direct control, binding *READ-EVAL* to NIL.