[IronPython] Weird Anomoly with SetStandardOutput

[Dino Viehland]

To the extent that objects can be marshaled by ref it won't be too much of a problem - unless the objects are chatty in which case it'll be the x-domain calls which would kill perf instead of serialization of a large object graph.

Thanks for the feedback, and if anyone else has other comments those are always appreciated.  It's at least good to know we should think about it some more.



-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, April 02, 2007 3:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput

Dino Viehland wrote:
> The reason why I asked about multiple engine support is that it's actually a feature we don't know if we can maintain long-term.  The problem is that it's actually impossible for us to always know what engine we were calling from.  For example if we need to call back into something that requires an engine from a .NET ToString method we cannot properly flow the context into ToString and therefore we lose what engine was calling.
>
> So this might be a feature which disappears in later versions of IronPython.  Instead we'd encourage hosting each engine in its own app domain leveraging the CLR's own isolation mechanisms.  I don't believe that decision is entirely set in stone so it'd be interesting to hear what everyone thinks about it.
>
Wouldn't there be performance implications of passing 'big' objects
between app domains ?

We're just switching to use the multiple engine feature - and keeping
code sections isolated (from trashing the calling engines globals) is a
big plus.

At some stage we'd like to move to appdomains, but have 'contexts' with
hundreds of objects to move across the boundaries.

Having some (known) limitations on multiple engine support would be
better than losing it, if possible.

Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, April 02, 2007 3:36 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput
>
> Dino Viehland wrote:
>
>> This seems to work for me:
>>
>> from IronPython.Hosting import PythonEngine
>> from System.IO import Stream
>>
>> class C(Stream):
>>     @property
>>     def CanRead(self): return False
>>     @property
>>     def CanSeek(self): return False
>>     @property
>>     def CanWrite(self): return True
>>     @property
>>     def Position(self): return 0
>>     def Write(self, chars, offset, count):
>>             from System import Console
>>             Console.WriteLine(chars)
>>     def Flush(self): pass
>>
>>
>>
> Ha - they're properties.
>
> I was implementing them as methods - and it *appeared* to work...
>
> Cool - thanks.
>
> We're only just starting to use the multiple engine support.
>
> Thanks Dino.
>
> Michael
>
>
>> py.SetStandardOutput(C())
>> py.Execute('print 3')
>>
>>
>> I stuck to Console.WriteLine just to avoid having to think about sys across engines.
>>
>> Just out of curiosity - do you use the multiple engine support extensively?
>>
>>
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Monday, April 02, 2007 3:09 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput
>>
>> Michael Foord wrote:
>>
>>
>>> Michael Foord wrote:
>>>
>>>
>>>
>>>> Hello all,
>>>>
>>>> If I create a subclass of 'Stream' from IronPython - and set it onto a
>>>> PythonEngine using 'SetStandardOutput', then it fails with the following
>>>> message:
>>>>
>>>> Traceback (most recent call last):
>>>>   File C:\Python Projects\modules in
>>>> progress\ironpython\embeddingDivert.py, lin
>>>> e 32, in Initialize
>>>>   File , line 0, in SetStandardOutput##94
>>>> TypeError: issubclass: arg 1 must be a class
>>>>
>>>> If I define an empty class, and set this then I get the expected error
>>>> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'.
>>>>
>>>> [snip...]
>>>>
>>>> Unfortunately this problem is going to block us very rapidly at
>>>> resolver. We can probably get round it by creating the stream subclass
>>>> in C# - but what is the problem with doing it from IronPython ?
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Except that I realise that you may not have anticipated your users
>>> passing .NET subclasses from one IronPython engine to another...
>>>
>>> Can this be fixed ?
>>>
>>>
>>>
>> Oh, and :
>>
>> http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml
>>
>> Embedding IronPython in IronPython.
>>
>> Michael Foord
>>
>>
>>
>>> Michael
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> users mailing list
>> users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

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