[IronPython] Weird Anomoly with SetStandardOutput

Michael Foord fuzzyman at voidspace.org.uk
Tue Apr 3 00:44:48 CEST 2007


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
>
>   




More information about the Ironpython-users mailing list