Hi Dan,<br><br>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.<br><br>(compile-script 'some-symbol)
<br><br>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.
<br><br>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.<br><br><div><span class="gmail_quote">On 7/31/07, <b class="gmail_sendername">Vladimir Sedach</b> <<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Fixed. *default-compilation-environment* is now initialized with a<br>basic compilation environment (via make-basic-compilation-environment)<br>when its declared.</blockquote><div><br>This might cause some unexpected behavior since it creates a lingering, universal compilation environment.  Package definitions will persist across all compilations, for example.
<br><br>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.
<br><br>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.
<br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Vladimir</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Dan<br>></blockquote><div><br><br>Red <br></div></div>