William Harold Newman wrote:
> I looked into the possibility of setting up some workarounds, but
> unfortunately ILISP seems to be confused about IN-PACKAGE forms.
> LISP-FIND-HASH-FORM and LISP-BUFFER-PACKAGE-INTERNAL look for
> IN-PACKAGE-COMMAND-STRING instead of ILISP-PACKAGE-REGEXP, so I think
> if I change IN-PACKAGE-COMMAND-STRING to something like "SETF
> *PACKAGE*", ILISP will get confused whenever it goes looking for
> IN-PACKAGE commands in a program for the purpose of figuring out what
> package applies.
Well, you'll get another mail concerning this.
I think I could set up a patch for sbcl, that would SETF *package*. I'd
have to change the internal functions, and so we'd have a seperate
function, especially for SBCL to find
the package. But I don't think this is really the right thing to do.
> IN-PACKAGE should be a quick fix, but because of the ILISP bugs, it
What patches do you have? I fixed the bug you reported.
Cheers,
Martin
--
Homepage: http://www.atzmueller.net/
Email: martin@...

On Mon, Nov 06, 2000 at 09:11:59AM +0100, martin@... wrote:
> William Harold Newman wrote:
>
> > I now think it's probably not related to bug #21, but is instead a bug
> > in the system's handling of EVAL-WHEN. Try this test file:
> Then, maybe bug#21 is not even present! :)
> I tried to test case of Fred Gilham, and got no error on that.
OK, I haven't tried that test, but it's quite possible that bug #21
actually doesn't appear in SBCL. DTC's messages about this said it was
a bug in the thread branch, and a lot of work was done in the thread
branch between the SBCL fork and the time of his messages.
> > By coincidence, I stumbled across similar EVAL-WHEN problems when
> > making DEFCONSTANT-related changes to the big patch set you (MNA)
> > submitted. Basically, the handling of EVAL-WHEN is pretty screwed up.
> > (*ALREADY-EVALED-THIS* -- yuck!) This screwed-up-ness was one reason
> Yes, seems so.
>
> > In the meantime, I'll experiment with workarounds in ILISP. My hope is
> > that it will be fairly easy to work around this in the short term by
> > using ordinary operations like SETF, instead of magical
> > EVAL-WHEN-based operations like IN-PACKAGE.
> I've integrated the patch-suggestions you sent last time. I think I'll
> commit them soon, with an explanatory comment, that this is a
> workaround.
> But working around the "eval-when in-package" issue might be a real
> problem:
>
> I tried to setf *package* after I do the in-package, and that did not
> work.
> You might try:
>
> (progn
> (defpackage :bla)
> (let ((save-package nil)) (setf save-package *package*) (prog1
> (nth-value 0 (ignore-errors (in-package :bla) (package-name *package*)))
> (setf *package* (find-package save-package)))))
>
> and this still does not work.
> The main problem is, that ILISP looks for all the defpackage- and
> in-package-forms, then sends them to the inferior lisp (all!), and then
> grabs the value of *package*!
> So, a simple "find-package" is not so easy without changing ILISP
> completely.
>
> Anyway, I hope your experiments will yield some good results, so that
> ILISP can work with SBCL much better.
I looked into the possibility of setting up some workarounds, but
unfortunately ILISP seems to be confused about IN-PACKAGE forms.
LISP-FIND-HASH-FORM and LISP-BUFFER-PACKAGE-INTERNAL look for
IN-PACKAGE-COMMAND-STRING instead of ILISP-PACKAGE-REGEXP, so I think
if I change IN-PACKAGE-COMMAND-STRING to something like "SETF
*PACKAGE*", ILISP will get confused whenever it goes looking for
IN-PACKAGE commands in a program for the purpose of figuring out what
package applies.
I'd also like SBCL to work better with ILISP, but I don't see a good
quick fix for SBCL: I don't want to dive into the IR1 problems yet. It
seems as though telling ILISP to use SETF *PACKAGE* instead of
IN-PACKAGE should be a quick fix, but because of the ILISP bugs, it
seems not to be. I think the ILISP bugs are soluble, but ILISP hasn't
been updated very often, and I don't want to try to maintain a
separate set of patches for ILISP-for-SBCL. Maybe once the ILISP
mailing list is up it will be easier to straighten this out.
> On last thing: If I do a (setf *package* 1), for example, SBCL is broken
> completely.
> Well, ok, this is really a stupid thing, but in CLISP, for example I can
> get out of this, because I can set the package to something other. CLISP
> will print "invalid package", but it will still work.
> So, what do you think about that?
> I could not find anything concerning this in the Hyperspec, so I guess
> this effect is undefined, but maybe it should be caught, nevertheless.
I had a FIXME note below "DEFVAR *PACKAGE* about this issue.
As long as I'm thinking about it, I might as well actually fix it.
It will probably be in 0.6.8.10.
--
William Harold Newman <william.newman@...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C

William Harold Newman wrote:
> I now think it's probably not related to bug #21, but is instead a bug
> in the system's handling of EVAL-WHEN. Try this test file:
Then, maybe bug#21 is not even present! :)
I tried to test case of Fred Gilham, and got no error on that.
> By coincidence, I stumbled across similar EVAL-WHEN problems when
> making DEFCONSTANT-related changes to the big patch set you (MNA)
> submitted. Basically, the handling of EVAL-WHEN is pretty screwed up.
> (*ALREADY-EVALED-THIS* -- yuck!) This screwed-up-ness was one reason
Yes, seems so.
> In the meantime, I'll experiment with workarounds in ILISP. My hope is
> that it will be fairly easy to work around this in the short term by
> using ordinary operations like SETF, instead of magical
> EVAL-WHEN-based operations like IN-PACKAGE.
I've integrated the patch-suggestions you sent last time. I think I'll
commit them soon, with an explanatory comment, that this is a
workaround.
But working around the "eval-when in-package" issue might be a real
problem:
I tried to setf *package* after I do the in-package, and that did not
work.
You might try:
(progn
(defpackage :bla)
(let ((save-package nil)) (setf save-package *package*) (prog1
(nth-value 0 (ignore-errors (in-package :bla) (package-name *package*)))
(setf *package* (find-package save-package)))))
and this still does not work.
The main problem is, that ILISP looks for all the defpackage- and
in-package-forms, then sends them to the inferior lisp (all!), and then
grabs the value of *package*!
So, a simple "find-package" is not so easy without changing ILISP
completely.
Anyway, I hope your experiments will yield some good results, so that
ILISP can work with SBCL much better.
On last thing: If I do a (setf *package* 1), for example, SBCL is broken
completely.
Well, ok, this is really a stupid thing, but in CLISP, for example I can
get out of this, because I can set the package to something other. CLISP
will print "invalid package", but it will still work.
So, what do you think about that?
I could not find anything concerning this in the Hyperspec, so I guess
this effect is undefined, but maybe it should be caught, nevertheless.
Cheers,
Martin
--
Homepage: http://www.atzmueller.net/
Email: martin@...

Hi,
I'd like to commit my recent patches to inspect.lisp.
So, since the sources were converted to UTF-8:
Do I have to use an extra conversion utility (to UTF-8) for source
files, to commit to the CVS?
Thanks,
Martin
--
Homepage: http://www.atzmueller.net/
Email: martin@...