I believe this used to work:
(ps-to-string 'some-symbol)
Now it doesn't:
No methods applicable for generic function #<STANDARD-GENERIC-FUNCTION PARENSCRIPT::COMPILE-PARENSCRIPT-FORM> with args (NIL SOME-SYMBOL) of classes (NULL SYMBOL) [Condition of type PROGRAM-ERROR]
... apparently because of the lack of an implicitly expected compilation environment.
Dan
Fixed. *default-compilation-environment* is now initialized with a basic compilation environment (via make-basic-compilation-environment) when its declared.
Vladimir
On 7/31/07, Daniel Gackle danielgackle@gmail.com wrote:
I believe this used to work:
(ps-to-string 'some-symbol)
Now it doesn't:
No methods applicable for generic function #<STANDARD-GENERIC-FUNCTION PARENSCRIPT::COMPILE-PARENSCRIPT-FORM> with args (NIL SOME-SYMBOL) of classes (NULL SYMBOL) [Condition of type PROGRAM-ERROR]
... apparently because of the lack of an implicitly expected compilation environment.
Dan
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Hi Dan,
In what context are you trying to translate a symbol? In general, you should now use COMPILE-SCRIPT to get Javascript output from Parenscript forms. It ensures a bound compilation environment.
(compile-script 'some-symbol)
Sorry to break your code, but since the last release we have been making some changes to the Parenscript interface. compile-script, compile-script-file, compile-script-system are the preferred functions for compilation. More documentation is coming up.
Some additional information about symbol translation: If you want the camel-cased version of a Parenscript symbol you might want to call "ps::symbol-to-js." However, this ignores anything about the current compilation environment, which may have some bearing on how a symbol is translated when the package system is enabled. During compilation, js-translate-symbol right now provides a correct Javascript serialization of the symbol.
On 7/31/07, Vladimir Sedach vsedach@gmail.com wrote:
Fixed. *default-compilation-environment* is now initialized with a basic compilation environment (via make-basic-compilation-environment) when its declared.
This might cause some unexpected behavior since it creates a lingering, universal compilation environment. Package definitions will persist across all compilations, for example.
The revised compilation interface will ensure that *compilation-environment* is bound to a compilation environment before compiling (see compilation-interface.lisp and "non-nil-comp-env"). I think the functions provided in compilation-interface are sufficient for all compilation/translation needs. We might want to unexport some other functions.
A compilation environment is generally supposed to be initialized before and die after a logical compilation process. For example, consider an HTML page with a inlined script in a <script> tag, some external script in a <script src="...">, and script function calls embedded in onMouseClick attributes in the HTML page. The compilation environment will be created. The compiler will then be invoked on the inline script, the script files, and the script embedded in HTML. After all this, the compilation environment can be thrown away, along with all the Parenscript package definitions and other local compilation rules.
This intended use requires the user to manage a compilation environment to some degree. Before long we should figure out the public interface for dealing with a compilation environment. I also have no problem writing up the documentation. Before I do this, however, I would like to use the package system extensively for a real application so I can see how it is best used in practice.
Vladimir
Dan
Red
This might cause some unexpected behavior since it creates a lingering, universal compilation environment. Package definitions will persist across all compilations, for example.
You're absolutely right, it does. I undid the patch that bound *compilation-environment*, and the one that was affected by it. Thank you for the lucid explanation. I also unexported ps-to-string. 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), 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*).
Vladimir
The revised compilation interface will ensure that *compilation-environment* is bound to a compilation environment before compiling (see compilation-interface.lisp and "non-nil-comp-env"). I think the functions provided in compilation-interface are sufficient for all compilation/translation needs. We might want to unexport some other functions.
A compilation environment is generally supposed to be initialized before and die after a logical compilation process. For example, consider an HTML page with a inlined script in a <script> tag, some external script in a <script src="...">, and script function calls embedded in onMouseClick attributes in the HTML page. The compilation environment will be created. The compiler will then be invoked on the inline script, the script files, and the script embedded in HTML. After all this, the compilation environment can be thrown away, along with all the Parenscript package definitions and other local compilation rules.
This intended use requires the user to manage a compilation environment to some degree. Before long we should figure out the public interface for dealing with a compilation environment. I also have no problem writing up the documentation. Before I do this, however, I would like to use the package system extensively for a real application so I can see how it is best used in practice.
Vladimir
Dan
Red
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On 7/31/07, Vladimir Sedach vsedach@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
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@gmail.com wrote:
On 7/31/07, Vladimir Sedach vsedach@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Ah, ps::symbol-to-js was what I wanted. Thanks.
On 7/31/07, Red Daly reddaly@gmail.com wrote:
Hi Dan,
In what context are you trying to translate a symbol? In general, you should now use COMPILE-SCRIPT to get Javascript output from Parenscript forms. It ensures a bound compilation environment.
(compile-script 'some-symbol)
Sorry to break your code, but since the last release we have been making some changes to the Parenscript interface. compile-script, compile-script-file, compile-script-system are the preferred functions for compilation. More documentation is coming up.
Some additional information about symbol translation: If you want the camel-cased version of a Parenscript symbol you might want to call "ps::symbol-to-js." However, this ignores anything about the current compilation environment, which may have some bearing on how a symbol is translated when the package system is enabled. During compilation, js-translate-symbol right now provides a correct Javascript serialization of the symbol.
On 7/31/07, Vladimir Sedach vsedach@gmail.com wrote:
Fixed. *default-compilation-environment* is now initialized with a basic compilation environment (via make-basic-compilation-environment) when its declared.
This might cause some unexpected behavior since it creates a lingering, universal compilation environment. Package definitions will persist across all compilations, for example.
The revised compilation interface will ensure that *compilation-environment* is bound to a compilation environment before compiling (see compilation-interface.lisp and "non-nil-comp-env"). I think the functions provided in compilation-interface are sufficient for all compilation/translation needs. We might want to unexport some other functions.
A compilation environment is generally supposed to be initialized before and die after a logical compilation process. For example, consider an HTML page with a inlined script in a <script> tag, some external script in a
<script src="...">, and script function calls embedded in onMouseClick attributes in the HTML page. The compilation environment will be created. The compiler will then be invoked on the inline script, the script files, and the script embedded in HTML. After all this, the compilation environment can be thrown away, along with all the Parenscript package definitions and other local compilation rules. This intended use requires the user to manage a compilation environment to some degree. Before long we should figure out the public interface for dealing with a compilation environment. I also have no problem writing up the documentation. Before I do this, however, I would like to use the package system extensively for a real application so I can see how it is best used in practice. Vladimir > Dan > > Red _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Daniel Gackle -
Red Daly -
Vladimir Sedach