Great feedback, thanks for the detailed
explanation. It sounds like the level of isolation that
you need is to simply support multiple sys instances, and each engine would
then see its own system state. This is actually the original path we took
with this, but we didn’t quite get it working 100% L. What this would
imply is that everything else is shared (e.g. id(str) would always be the same
between multiple engines) but because all of the built-in types are read-only
this should be a non-issue. This is one of our remaining open design
issues for 1.0 so we’ll make sure to let you know what way we end up
landing with this. Unfortunately for now it seems like you’ll be
stuck using a single engine unless you wanted to start running your scripts in
a separate app domain (which may or may not even be possible depending on what
else you’re doing). If you really wanted to get wacky you could try
making Ops.systemState [ThreadStatic] but I would expect to get some nasty side
effects from that. I’m in a 100% agreement about the
confusion by allowing you to make multiple engines. Do
you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans I’m thinking of using IronPython as
a scripting language inside a future WPF application. (I’m just
experimenting; there’s nothing planned at the moment.) Here’s an example of what I would
like to do. I have a data object that’s data bound to the user interface.
When the user changes a property (or it’s changed programmatically) I
would like to run a custom script. This script gets a reference (SetVariable)
to the changed object. It can now calculate and set a different property on the
data object (or on some other object or send an e-mail or whatever). Setting
the property can trigger a new script to run while the previous one isn’t
finished executing yet. The new script should run in a clean environment to
exclude unwanted interactions: it could use the same variables or have
conflicting functions defined. Is there a way to keep the script
environments separated? With a single PythonEngine you also wouldn’t have
to pay the startup cost each time. This could give unacceptable delays while
running the application anyway. I think that some form of sharing is unavoidable.
It would still be nice to have separate instances though, maybe one
PythonEngine per separate task that the user starts. I would also like to include inside the
application an interactive console. I have a prototype working. It
doesn’t run in a blocking loop anymore: the application’s UI keeps
running normally. Multiple of these interactive sessions could be opened at the
same time. I need the output of each engine to go to the correct console. This
is how I stumbled across the problem. In my main window I used the console to
create a new instance of the same window (which also contained an instance of
my PythonConsole). But all the output of the first console suddenly showed up
in the second console, which was a bit surprising. If you can’t make the changes to
have multiple PythonEngine’s running at the same time it would be safest
to make it impossible to create them. It wouldn’t surprise me if other
people run into the same problem if they integrate IronPython into their
applications. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dino Viehland Yes, right now we unfortunately have some
shared state between them. We’re not entirely certain where
we’ll land w/ this for V1 yet – whether we’ll attempt to keep
them separated entirely, or make it obvious (e.g. a static class) that there’s
only one engine available. If we end up w/ just one then our isolation
story would be app domain isolation. If you’ve got feedback on which one
is better for you (I’m guessing having them be independent) we’d
love to hear it. Do
you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans I’ve created two PythonEngine instances and set the
Stdout for each instance to its own custom stream class (PythonStream) to
capture the output. This stream class takes a delegate to specify the function
to receive the response. class Tester { public void
Test() {
PythonEngine pythonEngine1 = new PythonEngine();
pythonEngine1.SetStdout(new PythonStream(ResponsePythonEngine1));
Console.WriteLine("pythonEngine1.Execute(\"'p1'\") ->
");
pythonEngine1.Execute("'p1'");
Console.WriteLine("");
PythonEngine pythonEngine2 = new PythonEngine();
pythonEngine2.SetStdout(new
PythonStream(ResponsePythonEngine2));
Console.WriteLine("pythonEngine2.Execute(\"'p2'\") ->
");
pythonEngine2.Execute("'p2'");
Console.WriteLine("");
Console.WriteLine("pythonEngine1.Execute(\"'p1'\") ->
");
pythonEngine1.Execute("'p1'");
Console.WriteLine("");
Console.ReadLine(); } void
ResponsePythonEngine1(string text) {
if (!string.IsNullOrEmpty(text.Trim()))
{
Console.WriteLine(" ResponsePythonEngine1 -> " + text);
} } void
ResponsePythonEngine2(string text) {
if (!string.IsNullOrEmpty(text.Trim()))
{
Console.WriteLine(" ResponsePythonEngine2 -> " + text);
} } } After pythonEngine2 is created I receive the responses from
commands executed on pythonEngine1 on the output of pythonEngine2. pythonEngine1.Execute("'p1'") -> ResponsePythonEngine1 -> 'p1' pythonEngine2.Execute("'p2'") -> ResponsePythonEngine2 -> 'p2' pythonEngine1.Execute("'p1'") -> ResponsePythonEngine2 -> 'p1' You can find my test application here: http://users.telenet.be/kristof.wagemans/PythonEngineConnected.zip |
_______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com