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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marty Nelson
Sent: Wednesday, October 08, 2008 3:10 PM
To: users@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.
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
