[IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)

[Dino Viehland]

Well the good news is redirecting stdout seems to be the most common scenario :)

In v2.0 by default all output is done via the current stream on Console.  You could change this stream in the handler which is sending the command to the engine before executing each request.  Each window would send the request to the same engine but output to a different stream.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kristof Wagemans
Sent: Wednesday, May 02, 2007 10:47 AM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)

Is the following scenario supported in v2.0?

You have a Windows MDI application with two child windows open. Each window
contains a textbox and a label. No extra threads. No extra app domains.
You enter a command in the textbox on child window 1 and send it to the
engine for execution. The output of the command is displayed in the label on
window 1. Then you do the same thing for child window 2. Is the output of
the second command displayed in the label on window 2?


-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday 2 May 2007 19:17
To: Discussion of IronPython
Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond
(was IronPython 2.0 Alpha 1 Released)

Thanks for the info...  Darn, it sounds like you actually want sys to be
isolated...

We're going to do a review over the hosting APIs internally next week.
That should result in the last large set of changes.  One thought that has
occurred to me is the ability to provide management of the current sys
instance.  This is where most of the state is tracked.  That would
presumably be something like allowing you to create a new system state and
provide the current system state at runtime.  You could then switch system
states before running a new script code.  In the multi-threaded case you
could store the system state in a thread local variable.  Therefore rather
than tracking a set of engines you'd track a list of SystemState objects (or
in DLR speak they may be some opaque state object).

The one interesting thing here is how this plays w/ console output.  In v2.0
that's separate from SystemState so you'd also need to update those at the
same time.

Any feedback on that proposal?


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com