[IronPython] Questions and Best Practices for Script Runtimeand Script Engine

[Marty Nelson]

Thanks, this is very helpful and close to what I expected.  We use
scripting as an event-based customization mechanism, so the scripts
typically need to be in the same app-domain so they can get their grubby
little hands all over the objects being manipulated.

 

Is there any code based mechanisms to add the configurations?  In a
deployed enterprise environment, updating config files is not something
our customers are excited about.  We can deal with dynamic deployed
types and assemblies via the server portion of our product, if there was
something exposed we can manipulate against the API, that would be
better. 

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday, October 08, 2008 4:00 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Questions and Best Practices for Script
Runtimeand Script Engine

 

Each ScriptRuntime is isolated from each other.  So the reasons to use
multiple ones would come down to wanting to set different global
options, have scripts belonging to different users running, have scripts
running on multiple threads which are isolated, etc...    It can also be
useful to run a ScriptRuntime in another domain so you can
deterministically unload all of the code - that might be useful for a
plug-in model where you want to have the capability to unload all of the
plugins.

 

Each ScriptRuntime will only have 1 instance of each language - so
scriptRuntime.GetEngine("py") will always return the same instance.

 

The change from ScriptRuntime.Create to Python.CreateRuntime() is all
about where the hosting APIs are heading long term.  Eventually they'll
become a part of the .NET framework and we currently have no plans to
ship IronPython w/ the framework - we tend to move faster than they do
:-).  That implies that the DLR hosting APIs shouldn't have knowledge of
Python either.  We looked at a couple of ways of solving this and we
were interested in making sure that we had a good experience for both
the single-language case as well as the multi-language case.  For the
single language case we came up with Python.CreateRuntime where Python
can return you a ScriptRuntime that is pre-configured to include just
the IronPython language configured - IronRuby has a similar method as
well.  For the multi-language case we added a configuration mechanism
built off of the standard .NET config file format.    You can do an easy
one-liner there by calling ScriptRuntime.CreateFromConfiguration() which
will read .NET config (app config, web.config, etc...).  That way you
can plug in multiple languages and users of your app can
add/remove/update languages as they so choose.   The configuration file
format looks like:

 

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <configSections>

    <section name="microsoft.scripting"
type="Microsoft.Scripting.Hosting.Configuration.Section,
Microsoft.Scripting, Version=1.0.0.5000, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" requirePermission="false" />

  </configSections>

 

  <microsoft.scripting>

    <languages>

      <language names="IronPython;Python;py" extensions=".py"
displayName="IronPython 2.0 Beta"
type="IronPython.Runtime.PythonContext, IronPython, Version=2.0.0.5000,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <language names="IronRuby;Ruby;rb" extensions=".rb"
displayName="IronRuby 1.0 Alpha" type="IronRuby.Runtime.RubyContext,
IronRuby, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />

      <language names="ManagedJScript;JScript;js" extensions=".jsx;.js"
displayName="Managed JScript" type="Microsoft.JScript.Runtime.JSContext,
Microsoft.JScript.Runtime, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />

      <language names="ToyScript;ts" extensions=".ts"
type="ToyScript.ToyLanguageContext, ToyScript, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

    </languages>

 

    <options>

      <set language="Ruby" option="LibraryPaths"
value="..\..\Languages\Ruby\libs\;..\..\..\External\Languages\Ruby\ruby-
1.8.6\lib\ruby\site_ruby\1.8\;..\..\..\External\Languages\Ruby\ruby-1.8.
6\lib\ruby\site_ruby\;..\..\..\External\Languages\Ruby\ruby-1.8.6\lib\ru
by\1.8\" />

    </options>

  </microsoft.scripting>

</configuration>

 

So coming back to the question about ScriptScopes you absolutely can
re-use them between languages.  Each language will have its own
mechanism for exposing the variables in the scope (for Python they're
globals, in Ruby Tomas tells me they're ultimately exposed via
method_missing so you can just refer to them by name or self.name).
Note though a ScriptScope can be bound to a language which is then used
for fetching variables, doing conversions, etc...

 

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Wednesday, October 08, 2008 3:10 PM
To: users at lists.ironpython.com
Subject: [IronPython] Questions and Best Practices for Script Runtime
and Script Engine

 

I have a ScriptingService static class that reuses the same
ScriptRuntime instance.  Is there any reason not to do this?  What would
be the boundary conditions at which I would want to use a different
ScriptRuntime?

 

Does the call to scriptRuntime.GetEngine("py") always return the same
engine instance?  Again, why or why not reuse the same instance?

 

Lastly, I was somewhat confused by the change from
ScriptRuntime.Create() to Python.CreateRuntime().  Are the runtimes, and
more importantly ScriptScope's, reusable with other DLR languages?  I
was expecting to be able to do something like the following:

 

ScriptScope scope = scriptRuntime.CreateScope();

 

ScriptEngine pythonEngine = scriptRuntime.GetEngine("py");

pythonEngine.CreateScriptSourceFromString(pythonScript,
SourceCodeKind.Statements).Execute(scope);

 

ScriptEngine rubyEngine = scriptRuntime.GetEngine("ruby");

pythonEngine.CreateScriptSourceFromString(rubyScript,
SourceCodeKind.Statements).Execute(scope);

 

 

Thanks,

 

- Marty Nelson

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081008/906aa347/attachment.html>