Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I tried to reproduce your problem: I took the files you sent,
commented out the second form in package.lisp, loaded via require,
added the the form again and reloaded via require. Both lisp files
were recompiled and reloaded without errors.
Note that the file condition.txt that you attached does not contain
the actual error output, just asdf telling you (via cerror) that there
was some problem earlier. If you send a complete transcript, starting
with the line (require :pak) entered by you at the REPL, I can have a
look - otherwise I can only say "works for me", unfortunately ...
From: Juho Snellman <jsnell@ik...> - 2007-12-27 17:10:07
Joubert Nel <joubert@...> writes:
> I received a note from Christophe mentioning that the result when
> changing a (defpackage) form inbetween evaluating successive (require)
> forms, is undefined.
> However, I'm *not* modifying the (defpackage) form itself, merely stuff
> inside the package. It seems like a subtle, but definite distinction.
It doesn't seem like a very relevant distinction though, in light of
what the spec actually says:
If defined-package-name already refers to an existing package, the
name-to-package mapping for that name is not changed. If the new
definition is at variance with the current state of that package,
the consequences are undefined; an implementation might choose to
modify the existing package to reflect the new definition.
Note that it's not a matter of modifying the defpackage form, it's a
matter of modifying the state of the package in any way, without
having it be reflected in a defpackage form that's evaluated in the