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

[Dino Viehland]

Absolutely - you can create a ScriptRuntimeSetup and pass that to the ScriptRuntime constructor.  That's basically:

ScriptRuntimeSetup setup = new ScriptRuntimeSetup();
Setup.LanguageSetups.Add(new LanguageSetup(assembly_qualified_name, displayName, languageNames, fileExtensions);

If you want a more detailed example you can look at the Python class in IronPython which does this and a little more...  Using that you can develop any alternate configuration mechanism that you'd like.

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

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\ruby\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/c023099f/attachment.html>