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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
