[parenscript-devel] Bug: can't call ps-to-string directly

[Vladimir Sedach]

You're right - this was a bug in the way our script-caching system
interacted with the compiler (basically some scripts were getting
compiled in the wrong order and were getting cached, and setting
*compilation-environment* to a basic environment masked that problem).
I reverted the patch with the complation environment interface.

Vladimir

On 7/31/07, Red Daly <reddaly at gmail.com> wrote:
>
>
> On 7/31/07, Vladimir Sedach <vsedach at gmail.com> wrote:
> > > This might cause some unexpected behavior since it creates a lingering,
> > > universal compilation environment.  Package definitions will persist
> across
> > > all compilations, for example.
> >
> > However, it turns out that in the code I'm working on, we do take
> > advantage of a persistent compilation environment in other ways
> > (specifically, I want macro definitions to persist across several
> > parenscript compilations),
>
>
> Macro definitions specifically will always persist across many compilations.
>  Don't worry about making your macros persist as this will be transparent.
>
> The way macro definitions work right now is by a global macro definition
> table that makes EQL lookups based on the symbol used as the macro name;
> these persist when a compilation environment is no longer in use.  There is
> a bug with this, however, since different packages may define a macro with
> the same name:
>
> (in-package :paren-psos)
>
> (defpsmacro defclass ...)
>
> (in-package :other-class-system)
>
> (defpsmacro defclass ..)
>
> assuming both paren-psos and other-class-system use the CL package, DEFCLASS
> will be the same symbol (common-lisp::defclass).  the effective macro will
> then be whichever was last defined.  this is a bug.  the solution is to
> store macros in a multi-dimensional table by *package* at the time of macro
> definition and the symbol that names the macro.
>
>
> > so I've added a function
> > setup-persistent-compilation-environment to the
> deprecated file which
> > sets *compilation-environment* to such a value (and also a function to
> > clear *compilation-environment*).
>
> I have no problem with that hack as we flesh out how compilation
> environments will be manipulated by the user.  Don't depend too much on it,
> however, as more advanced compilation features may require some
> environmental care.
>
> > Vladimir
>
> Red
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>