From vernondcole at gmail.com  Sat Nov  1 02:01:32 2008
From: vernondcole at gmail.com (Vernon Cole)
Date: Fri, 31 Oct 2008 19:01:32 -0600
Subject: [IronPython] 2.1 Branch in Codeplex Sources
In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <490AF8C7.7080103@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>

"IronPython 3k"... does that mean that IPy 2.1 is targeted to be compatible
with CPython 2.6?
(Please say "yes"!)
--
Vernon Cole

On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland <dinov at microsoft.com> wrote:

> Just one other comment on top of what Curt said.  You might more properly
> think of Main as IronPython 3k.  Main includes a ton of renames and other
> breaking made in Microsoft.Scripting.Core/System.Core that will end up in
> .NET 4.0.  We're still working on what we want to do for 2.1 (and input is
> always welcome of course) but our current thinking is that it will be API
> compatible w/ 2.0.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081031/455daa17/attachment.html>

From Tomas.Matousek at microsoft.com  Sat Nov  1 18:01:36 2008
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sat, 1 Nov 2008 10:01:36 -0700
Subject: [IronPython] IronPython 2: Oddity with Hosting API from	within
 IronPython
In-Reply-To: <490B3B94.5010902@voidspace.org.uk>
References: <490B0DE9.2020707@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<490B34CC.1020607@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<490B3806.3090100@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23554FF7266AD0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<490B3B94.5010902@voidspace.org.uk>
Message-ID: <F58FE69873E2D5459B72C347DE1582412ADBA722FD@NA-EXMSG-C112.redmond.corp.microsoft.com>

I think nobody answered this question yet:

>>> As a minor supplementary question, how do I get a reference to the
>>> default ScriptScope on an engine? Is there any performance advantage in
>>> using the default one, can I replace it, and does replacing it remove
>>> any performance benefits we might have got? (OK, so strictly speaking
>>> that wasn't just one question...)

There is no default scope associated with an engine (other than Global scope on ScriptRuntime).
All methods that operate on a scope yet don't take one create a new empty scope each time called.

Tomas


From dinov at microsoft.com  Sat Nov  1 21:38:28 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 1 Nov 2008 13:38:28 -0700
Subject: [IronPython] 2.1 Branch in Codeplex Sources
In-Reply-To: <b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>
References: <490AF8C7.7080103@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF7266DF7@NA-EXMSG-C102.redmond.corp.microsoft.com>

There will certainly be some 2.6 features.  But we still haven't quite figured out what "2.1" is yet.  So if there's a particular 2.6 feature, or if you'd just like us to see us do them all, let us know - same goes for other features, fixes, misc improvements, etc...

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Friday, October 31, 2008 6:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] 2.1 Branch in Codeplex Sources

"IronPython 3k"... does that mean that IPy 2.1 is targeted to be compatible with CPython 2.6?
(Please say "yes"!)
--
Vernon Cole
On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:
Just one other comment on top of what Curt said.  You might more properly think of Main as IronPython 3k.  Main includes a ton of renames and other breaking made in Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0.  We're still working on what we want to do for 2.1 (and input is always welcome of course) but our current thinking is that it will be API compatible w/ 2.0.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081101/4f71d3a0/attachment.html>

From fuzzyman at voidspace.org.uk  Sat Nov  1 21:58:48 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 01 Nov 2008 20:58:48 +0000
Subject: [IronPython] 2.1 Branch in Codeplex Sources
In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266DF7@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <490AF8C7.7080103@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>	<b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>
	<350E7D38B6D819428718949920EC23554FF7266DF7@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <490CC308.6030807@voidspace.org.uk>

Dino Viehland wrote:
>
> There will certainly be some 2.6 features. But we still haven?t quite 
> figured out what ?2.1? is yet. So if there?s a particular 2.6 feature, 
> or if you?d just like us to see us do them all, let us know ? same 
> goes for other features, fixes, misc improvements, etc?
>
+1 for with statement available without future import
+1 for new syntax for exception handling
+1 for class decorators (+1000 for using them to provide attribute support)
+1 for hasattr not discarding all exceptions
+1 for being able to provide keyword arguments after *args
+1 for getter, setter and deleter on properties (damn useful)
+1 for __dir__ support

+lots for implementing ctypes (not really related but thought I would 
throw it in)

Abstract Base Classes are nice, not sure if I'll use them for a while 
though.

New string formatting can blow.

Michael
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Vernon Cole
> *Sent:* Friday, October 31, 2008 6:02 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] 2.1 Branch in Codeplex Sources
>
> "IronPython 3k"... does that mean that IPy 2.1 is targeted to be 
> compatible with CPython 2.6?
> (Please say "yes"!)
> --
> Vernon Cole
>
> On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland <dinov at microsoft.com 
> <mailto:dinov at microsoft.com>> wrote:
>
> Just one other comment on top of what Curt said. You might more 
> properly think of Main as IronPython 3k. Main includes a ton of 
> renames and other breaking made in 
> Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0. 
> We're still working on what we want to do for 2.1 (and input is always 
> welcome of course) but our current thinking is that it will be API 
> compatible w/ 2.0.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From fuzzyman at voidspace.org.uk  Sat Nov  1 22:01:02 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 01 Nov 2008 21:01:02 +0000
Subject: [IronPython] IronPython 2: Oddity with Hosting API from	within
 IronPython
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412ADBA722FD@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <490B0DE9.2020707@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com>	<490B34CC.1020607@voidspace.org.uk>	<350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com>	<490B3806.3090100@voidspace.org.uk>	<350E7D38B6D819428718949920EC23554FF7266AD0@NA-EXMSG-C102.redmond.corp.microsoft.com>	<490B3B94.5010902@voidspace.org.uk>
	<F58FE69873E2D5459B72C347DE1582412ADBA722FD@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <490CC38E.5020300@voidspace.org.uk>

Tomas Matousek wrote:
> I think nobody answered this question yet:
>
>   
>>>> As a minor supplementary question, how do I get a reference to the
>>>> default ScriptScope on an engine? Is there any performance advantage in
>>>> using the default one, can I replace it, and does replacing it remove
>>>> any performance benefits we might have got? (OK, so strictly speaking
>>>> that wasn't just one question...)
>>>>         
>
> There is no default scope associated with an engine (other than Global scope on ScriptRuntime).
> All methods that operate on a scope yet don't take one create a new empty scope each time called.
>   

Thanks. It turns out I was talking about the default scope on a compiled 
code object. We need to execute a lot of code in the same scope. Looks 
like we lose *some* of the advantage of compiling by not executing in 
the default scope of the compiled code.

All the best,

Michael

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


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From dinov at microsoft.com  Sat Nov  1 23:14:09 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 1 Nov 2008 15:14:09 -0700
Subject: [IronPython] 2.1 Branch in Codeplex Sources
In-Reply-To: <490CC308.6030807@voidspace.org.uk>
References: <490AF8C7.7080103@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>
	<350E7D38B6D819428718949920EC23554FF7266DF7@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<490CC308.6030807@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC23554FF7266DFB@NA-EXMSG-C102.redmond.corp.microsoft.com>

FYI __dir__ support works in 2.0 already:

IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3053
Type "help", "copyright", "credits" or "license" for more information.
>>> class x(object):
...     def __dir__(self):
...             return ['abc']
...
>>> a = x()
>>> dir(a)
['abc']

I implemented it so that the "GetMemberNames" specially named .NET method we use for the same purpose would have something to map onto in Python.  So one 2.6 feature down, tons to go :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, November 01, 2008 1:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] 2.1 Branch in Codeplex Sources

Dino Viehland wrote:
>
> There will certainly be some 2.6 features. But we still haven't quite
> figured out what "2.1" is yet. So if there's a particular 2.6 feature,
> or if you'd just like us to see us do them all, let us know - same
> goes for other features, fixes, misc improvements, etc...
>
+1 for with statement available without future import
+1 for new syntax for exception handling
+1 for class decorators (+1000 for using them to provide attribute support)
+1 for hasattr not discarding all exceptions
+1 for being able to provide keyword arguments after *args
+1 for getter, setter and deleter on properties (damn useful)
+1 for __dir__ support

+lots for implementing ctypes (not really related but thought I would
throw it in)

Abstract Base Classes are nice, not sure if I'll use them for a while
though.

New string formatting can blow.

Michael
>
> *From:* users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Vernon Cole
> *Sent:* Friday, October 31, 2008 6:02 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] 2.1 Branch in Codeplex Sources
>
> "IronPython 3k"... does that mean that IPy 2.1 is targeted to be
> compatible with CPython 2.6?
> (Please say "yes"!)
> --
> Vernon Cole
>
> On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland <dinov at microsoft.com
> <mailto:dinov at microsoft.com>> wrote:
>
> Just one other comment on top of what Curt said. You might more
> properly think of Main as IronPython 3k. Main includes a ton of
> renames and other breaking made in
> Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0.
> We're still working on what we want to do for 2.1 (and input is always
> welcome of course) but our current thinking is that it will be API
> compatible w/ 2.0.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


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


From dinov at microsoft.com  Sat Nov  1 23:17:32 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 1 Nov 2008 15:17:32 -0700
Subject: [IronPython] Oddity with Setting Output Stream
In-Reply-To: <490B179C.5040608@voidspace.org.uk>
References: <490B179C.5040608@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC23554FF7266DFC@NA-EXMSG-C102.redmond.corp.microsoft.com>

I pinged Tomas on this and he thinks this is by design and I'm tending to agree (even though it is just a side effect of us using a StreamWriter).  You can always pass a Stream and a TextWriter instead to get full control over this behavior.

Good test though and I'll follow up w/ Bill to make sure this behavior gets spec'd.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, October 31, 2008 7:35 AM
To: Discussion of IronPython
Subject: [IronPython] Oddity with Setting Output Stream

Hello guys,

Another oddity with the IronPython 2 hosting API. This one may be the
correct behaviour, but it is different from IronPython 1.

When we set a UTF8 output stream on a runtime we see a UTF8 BOM being
written with the first output. I'm sure this didn't happen with
IronPython 1 because I now have failing tests!

The following code that traps standard out using a custom stream prints:

out: u'\ufeff'
out: 'foobar'
out: '\r\n'
out: 'foobar'
out: '\r\n'

import sys
import clr
clr.AddReference('IronPython')
clr.AddReference('Microsoft.Scripting')

from IronPython.Hosting import Python
from Microsoft.Scripting import SourceCodeKind
from System.Text import Encoding
from System.IO import MemoryStream

class CustomStream(MemoryStream):
    def __new__(cls, prefix):
        return MemoryStream.__new__(cls)

    def __init__(self, prefix):
        self._prefix = prefix

    def Write(self, buffer, offset, count):
        print self._prefix,
        print repr(Encoding.UTF8.GetString(buffer, offset, count))

engine = Python.CreateEngine()
engine.Runtime.IO.SetOutput(CustomStream('out:'), Encoding.UTF8)

source = engine.CreateScriptSourceFromString('print "foobar"\r\n',
SourceCodeKind.Statements)
scope = engine.CreateScope()
code = source.Compile()

code.Execute(scope)
code.Execute(scope)

All the best,

Michael Foord

--
http://www.ironpythoninaction.com/

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


From fuzzyman at voidspace.org.uk  Sat Nov  1 23:22:19 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 01 Nov 2008 22:22:19 +0000
Subject: [IronPython] 2.1 Branch in Codeplex Sources
In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266DFB@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <490AF8C7.7080103@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>	<b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>	<350E7D38B6D819428718949920EC23554FF7266DF7@NA-EXMSG-C102.redmond.corp.microsoft.com>	<490CC308.6030807@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23554FF7266DFB@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <490CD69B.3040707@voidspace.org.uk>

Dino Viehland wrote:
> FYI __dir__ support works in 2.0 already:
>
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3053
> Type "help", "copyright", "credits" or "license" for more information.
>   
>>>> class x(object):
>>>>         
> ...     def __dir__(self):
> ...             return ['abc']
> ...
>   
>>>> a = x()
>>>> dir(a)
>>>>         
> ['abc']
>
> I implemented it so that the "GetMemberNames" specially named .NET method we use for the same purpose would have something to map onto in Python.  So one 2.6 feature down, tons to go :)
>
>   

Cool. I think we can make goof use of this in Resolver One.

Michael

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Saturday, November 01, 2008 1:59 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] 2.1 Branch in Codeplex Sources
>
> Dino Viehland wrote:
>   
>> There will certainly be some 2.6 features. But we still haven't quite
>> figured out what "2.1" is yet. So if there's a particular 2.6 feature,
>> or if you'd just like us to see us do them all, let us know - same
>> goes for other features, fixes, misc improvements, etc...
>>
>>     
> +1 for with statement available without future import
> +1 for new syntax for exception handling
> +1 for class decorators (+1000 for using them to provide attribute support)
> +1 for hasattr not discarding all exceptions
> +1 for being able to provide keyword arguments after *args
> +1 for getter, setter and deleter on properties (damn useful)
> +1 for __dir__ support
>
> +lots for implementing ctypes (not really related but thought I would
> throw it in)
>
> Abstract Base Classes are nice, not sure if I'll use them for a while
> though.
>
> New string formatting can blow.
>
> Michael
>   
>> *From:* users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Vernon Cole
>> *Sent:* Friday, October 31, 2008 6:02 PM
>> *To:* Discussion of IronPython
>> *Subject:* Re: [IronPython] 2.1 Branch in Codeplex Sources
>>
>> "IronPython 3k"... does that mean that IPy 2.1 is targeted to be
>> compatible with CPython 2.6?
>> (Please say "yes"!)
>> --
>> Vernon Cole
>>
>> On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland <dinov at microsoft.com
>> <mailto:dinov at microsoft.com>> wrote:
>>
>> Just one other comment on top of what Curt said. You might more
>> properly think of Main as IronPython 3k. Main includes a ton of
>> renames and other breaking made in
>> Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0.
>> We're still working on what we want to do for 2.1 (and input is always
>> welcome of course) but our current thinking is that it will be API
>> compatible w/ 2.0.
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>     
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> 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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From fuzzyman at voidspace.org.uk  Sat Nov  1 23:23:49 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 01 Nov 2008 22:23:49 +0000
Subject: [IronPython] 2.1 Branch in Codeplex Sources
In-Reply-To: <490CD69B.3040707@voidspace.org.uk>
References: <490AF8C7.7080103@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com>	<b7eb4a700810311801s31f013d2n9fda34e2de1fc08d@mail.gmail.com>	<350E7D38B6D819428718949920EC23554FF7266DF7@NA-EXMSG-C102.redmond.corp.microsoft.com>	<490CC308.6030807@voidspace.org.uk>	<350E7D38B6D819428718949920EC23554FF7266DFB@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<490CD69B.3040707@voidspace.org.uk>
Message-ID: <490CD6F5.4020401@voidspace.org.uk>

Michael Foord wrote:
> Dino Viehland wrote:
>> FYI __dir__ support works in 2.0 already:
>>
>> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3053
>> Type "help", "copyright", "credits" or "license" for more information.
>>  
>>>>> class x(object):
>>>>>         
>> ...     def __dir__(self):
>> ...             return ['abc']
>> ...
>>  
>>>>> a = x()
>>>>> dir(a)
>>>>>         
>> ['abc']
>>
>> I implemented it so that the "GetMemberNames" specially named .NET 
>> method we use for the same purpose would have something to map onto 
>> in Python.  So one 2.6 feature down, tons to go :)
>>
>>   
>
> Cool. I think we can make goof use of this in Resolver One.

Well, good use - but that too.

Michael
>
> Michael
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com 
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Saturday, November 01, 2008 1:59 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] 2.1 Branch in Codeplex Sources
>>
>> Dino Viehland wrote:
>>  
>>> There will certainly be some 2.6 features. But we still haven't quite
>>> figured out what "2.1" is yet. So if there's a particular 2.6 feature,
>>> or if you'd just like us to see us do them all, let us know - same
>>> goes for other features, fixes, misc improvements, etc...
>>>
>>>     
>> +1 for with statement available without future import
>> +1 for new syntax for exception handling
>> +1 for class decorators (+1000 for using them to provide attribute 
>> support)
>> +1 for hasattr not discarding all exceptions
>> +1 for being able to provide keyword arguments after *args
>> +1 for getter, setter and deleter on properties (damn useful)
>> +1 for __dir__ support
>>
>> +lots for implementing ctypes (not really related but thought I would
>> throw it in)
>>
>> Abstract Base Classes are nice, not sure if I'll use them for a while
>> though.
>>
>> New string formatting can blow.
>>
>> Michael
>>  
>>> *From:* users-bounces at lists.ironpython.com
>>> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Vernon Cole
>>> *Sent:* Friday, October 31, 2008 6:02 PM
>>> *To:* Discussion of IronPython
>>> *Subject:* Re: [IronPython] 2.1 Branch in Codeplex Sources
>>>
>>> "IronPython 3k"... does that mean that IPy 2.1 is targeted to be
>>> compatible with CPython 2.6?
>>> (Please say "yes"!)
>>> -- 
>>> Vernon Cole
>>>
>>> On Fri, Oct 31, 2008 at 10:30 AM, Dino Viehland <dinov at microsoft.com
>>> <mailto:dinov at microsoft.com>> wrote:
>>>
>>> Just one other comment on top of what Curt said. You might more
>>> properly think of Main as IronPython 3k. Main includes a ton of
>>> renames and other breaking made in
>>> Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0.
>>> We're still working on what we want to do for 2.1 (and input is always
>>> welcome of course) but our current thinking is that it will be API
>>> compatible w/ 2.0.
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>     
>>
>>
>> -- 
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> 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
>>   
>
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From Tomas.Matousek at microsoft.com  Sun Nov  2 06:29:40 2008
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sat, 1 Nov 2008 22:29:40 -0700
Subject: [IronPython] Oddity with Setting Output Stream
In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266DFC@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <490B179C.5040608@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23554FF7266DFC@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412ADBA72317@NA-EXMSG-C112.redmond.corp.microsoft.com>

You can also pass new UTF8Encoding(false) instead of Encoding.UTF8.

Tomas

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Saturday, November 01, 2008 3:18 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Oddity with Setting Output Stream

I pinged Tomas on this and he thinks this is by design and I'm tending to agree (even though it is just a side effect of us using a StreamWriter).  You can always pass a Stream and a TextWriter instead to get full control over this behavior.

Good test though and I'll follow up w/ Bill to make sure this behavior gets spec'd.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, October 31, 2008 7:35 AM
To: Discussion of IronPython
Subject: [IronPython] Oddity with Setting Output Stream

Hello guys,

Another oddity with the IronPython 2 hosting API. This one may be the
correct behaviour, but it is different from IronPython 1.

When we set a UTF8 output stream on a runtime we see a UTF8 BOM being
written with the first output. I'm sure this didn't happen with
IronPython 1 because I now have failing tests!

The following code that traps standard out using a custom stream prints:

out: u'\ufeff'
out: 'foobar'
out: '\r\n'
out: 'foobar'
out: '\r\n'

import sys
import clr
clr.AddReference('IronPython')
clr.AddReference('Microsoft.Scripting')

from IronPython.Hosting import Python
from Microsoft.Scripting import SourceCodeKind
from System.Text import Encoding
from System.IO import MemoryStream

class CustomStream(MemoryStream):
    def __new__(cls, prefix):
        return MemoryStream.__new__(cls)

    def __init__(self, prefix):
        self._prefix = prefix

    def Write(self, buffer, offset, count):
        print self._prefix,
        print repr(Encoding.UTF8.GetString(buffer, offset, count))

engine = Python.CreateEngine()
engine.Runtime.IO.SetOutput(CustomStream('out:'), Encoding.UTF8)

source = engine.CreateScriptSourceFromString('print "foobar"\r\n',
SourceCodeKind.Statements)
scope = engine.CreateScope()
code = source.Compile()

code.Execute(scope)
code.Execute(scope)

All the best,

Michael Foord

--
http://www.ironpythoninaction.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



From fuzzyman at voidspace.org.uk  Sun Nov  2 13:36:06 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 02 Nov 2008 12:36:06 +0000
Subject: [IronPython] Oddity with Setting Output Stream
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412ADBA72317@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <490B179C.5040608@voidspace.org.uk>	<350E7D38B6D819428718949920EC23554FF7266DFC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412ADBA72317@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <490D9EB6.5000306@voidspace.org.uk>

Tomas Matousek wrote:
> You can also pass new UTF8Encoding(false) instead of Encoding.UTF8.
>   

OK, thanks.

Michael

> Tomas
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Saturday, November 01, 2008 3:18 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Oddity with Setting Output Stream
>
> I pinged Tomas on this and he thinks this is by design and I'm tending to agree (even though it is just a side effect of us using a StreamWriter).  You can always pass a Stream and a TextWriter instead to get full control over this behavior.
>
> Good test though and I'll follow up w/ Bill to make sure this behavior gets spec'd.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, October 31, 2008 7:35 AM
> To: Discussion of IronPython
> Subject: [IronPython] Oddity with Setting Output Stream
>
> Hello guys,
>
> Another oddity with the IronPython 2 hosting API. This one may be the
> correct behaviour, but it is different from IronPython 1.
>
> When we set a UTF8 output stream on a runtime we see a UTF8 BOM being
> written with the first output. I'm sure this didn't happen with
> IronPython 1 because I now have failing tests!
>
> The following code that traps standard out using a custom stream prints:
>
> out: u'\ufeff'
> out: 'foobar'
> out: '\r\n'
> out: 'foobar'
> out: '\r\n'
>
> import sys
> import clr
> clr.AddReference('IronPython')
> clr.AddReference('Microsoft.Scripting')
>
> from IronPython.Hosting import Python
> from Microsoft.Scripting import SourceCodeKind
> from System.Text import Encoding
> from System.IO import MemoryStream
>
> class CustomStream(MemoryStream):
>     def __new__(cls, prefix):
>         return MemoryStream.__new__(cls)
>
>     def __init__(self, prefix):
>         self._prefix = prefix
>
>     def Write(self, buffer, offset, count):
>         print self._prefix,
>         print repr(Encoding.UTF8.GetString(buffer, offset, count))
>
> engine = Python.CreateEngine()
> engine.Runtime.IO.SetOutput(CustomStream('out:'), Encoding.UTF8)
>
> source = engine.CreateScriptSourceFromString('print "foobar"\r\n',
> SourceCodeKind.Statements)
> scope = engine.CreateScope()
> code = source.Compile()
>
> code.Execute(scope)
> code.Execute(scope)
>
> All the best,
>
> Michael Foord
>
> --
> http://www.ironpythoninaction.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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From dan.eloff at gmail.com  Sun Nov  2 18:10:39 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Sun, 2 Nov 2008 12:10:39 -0500
Subject: [IronPython] Oddity with Setting Output Stream
In-Reply-To: <490D9EB6.5000306@voidspace.org.uk>
References: <490B179C.5040608@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23554FF7266DFC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412ADBA72317@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<490D9EB6.5000306@voidspace.org.uk>
Message-ID: <4817b6fc0811020910p5801c1bdta60aa6b3169eb443@mail.gmail.com>

Speaking of oddities involving utf-8 bom, why might this happen?

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19005

-Dan


From dinov at microsoft.com  Sun Nov  2 20:18:24 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Sun, 2 Nov 2008 11:18:24 -0800
Subject: [IronPython] Oddity with Setting Output Stream
In-Reply-To: <4817b6fc0811020910p5801c1bdta60aa6b3169eb443@mail.gmail.com>
References: <490B179C.5040608@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23554FF7266DFC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<F58FE69873E2D5459B72C347DE1582412ADBA72317@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<490D9EB6.5000306@voidspace.org.uk>
	<4817b6fc0811020910p5801c1bdta60aa6b3169eb443@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF7266E3F@NA-EXMSG-C102.redmond.corp.microsoft.com>

Ultimately it's because we don't have Unicode and byte strings - we get little incompatibilities like this popping up every now and then due to that.

I'm guessing this particular one could come back to behavior in the str.decode w/ raw_unicode_escape or unicode_escape.  I say that because the parsing there is shared with the parsing the tokenizer uses and it has a hack to remove the BOM.  But there are a few other paths there as well...

Unfortunately Unicode fixes are always a little risky and could break something else - and worse yet some are simply unresolvable.  But I suspect this one is fixable.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Sunday, November 02, 2008 9:11 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Oddity with Setting Output Stream

Speaking of oddities involving utf-8 bom, why might this happen?

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19005

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


From curt at hagenlocher.org  Mon Nov  3 05:58:59 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Sun, 2 Nov 2008 20:58:59 -0800
Subject: [IronPython] IronPython on Intellipad
In-Reply-To: <d2155e360810281513x2ddf2100t9bf61416d9d077fd@mail.gmail.com>
References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com>
	<490778DA.9010901@voidspace.org.uk>
	<d2155e360810281351u4d12c8b1n1949f1d00f1ba992@mail.gmail.com>
	<49077B99.5040001@voidspace.org.uk>
	<8cd017b80810281401h3e35ed25hac87956a82438298@mail.gmail.com>
	<4907882E.4000906@voidspace.org.uk>
	<8cd017b80810281454r5d5224eawb5c8760a98bc2466@mail.gmail.com>
	<d2155e360810281513x2ddf2100t9bf61416d9d077fd@mail.gmail.com>
Message-ID: <d2155e360811022058n50f67bc2yd251ccc9848f251c@mail.gmail.com>

And also
http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,92ec6f1f-45e5-4b7d-b675-548be5131a07.aspx


On Tue, Oct 28, 2008 at 2:13 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> See also http://blogs.msdn.com/intellipad
>
>
> On Tue, Oct 28, 2008 at 2:54 PM, Dody Gunawinata <empirebuilder at gmail.com>wrote:
>
>>
>> http://code.msdn.microsoft.com/oslo/Release/ProjectReleases.aspx?ReleaseId=1707
>>
>>
>> On Tue, Oct 28, 2008 at 11:46 PM, Michael Foord <
>> fuzzyman at voidspace.org.uk> wrote:
>>
>>> Do you have a link?
>>>
>>> Michael
>>>
>>> Dody Gunawinata wrote:
>>>
>>>> It's a WPF editor with IronPython crack :)
>>>> >From the readme
>>>>
>>>> "Customizing commands
>>>> --------------------
>>>> Almost all commands that are available in Intellipad have been written
>>>> in Python using
>>>> the object model exposed by the application.  The Python files are
>>>> scattered inside the
>>>> Settings directory.
>>>> Commands.py contains most of the commands for Intellipad.  Configuration
>>>> specific commands
>>>> are placed in their respective directories (Emacs or VI or
>>>> VisualStudio).
>>>> A command definition consists of three parts.  - A "Executed" function
>>>> definition, that acts as the command handler and provides the  logic for the
>>>> command
>>>> - An optional "CanExecute" function definition, that determines when the
>>>> command is  enabled
>>>> - A command wireup, that is done by calling the Common.Command function.
>>>>  This is the  where the Executed and CanExecute are wired together along
>>>> with the Command Name and
>>>>  default key binding
>>>>
>>>> For the moment, a restart is required for the changes to take effect."
>>>>
>>>> It's worth downloading. It's 'only' 15MB.
>>>>
>>>> Dody G.
>>>>
>>>>  On Tue, Oct 28, 2008 at 10:52 PM, Michael Foord <
>>>> fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>>>
>>>>    Curt Hagenlocher wrote:
>>>>
>>>>        That's what the "Connected Systems Division" was publicly
>>>>        calling Intellipad before it had a "real" name.
>>>>
>>>>        Intellipad is an extensible text editor inspired by Emacs
>>>>        which uses IronPython as its extension language.
>>>>
>>>>
>>>>    Thanks!
>>>>
>>>>    Michael
>>>>
>>>>
>>>>        On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord
>>>>        <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>
>>>>        <mailto:fuzzyman at voidspace.org.uk
>>>>        <mailto:fuzzyman at voidspace.org.uk>>> wrote:
>>>>
>>>>           Dody Gunawinata wrote:
>>>>
>>>>               The new Oslo technology "Emacs.Net" editor relies on
>>>>               IronPython to do the job that Lisp do for Emacs.
>>>>
>>>>
>>>>           What is Emacs.NET ?
>>>>
>>>>           Michael
>>>>
>>>>
>>>>               "Error Executing Command: 'setmode(MMode)'.
>>>>               Microsoft.Scripting.Runtime.UnboundNameException: name
>>>>               'setmode' is not defined
>>>>                 at
>>>>        IronPython.Runtime.PythonContext.MissingName(SymbolId name)
>>>>                 at
>>>>
>>>> Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext
>>>>               context, SymbolId name)
>>>>                 at
>>>>
>>>> Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext
>>>>               context, SymbolId name)
>>>>                 at Initialize##97(Closure , CodeContext )
>>>>                 at Microsoft.Scripting.ScriptCode.Run(CodeContext
>>>>               codeContext, Boolean tryEvaluate)
>>>>                 at Microsoft.Scripting.ScriptCode.Run(Scope scope)
>>>>                 at Microsoft.Scripting.SourceUnit.Execute(Scope scope,
>>>>               ErrorSink errorSink)
>>>>                 at
>>>>
>>>> Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope
>>>>               scope)
>>>>                 at
>>>>
>>>> Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String
>>>>               commandText)
>>>>               "
>>>>
>>>>               --        nomadlife.org <http://nomadlife.org>
>>>>        <http://nomadlife.org> <http://nomadlife.org>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>               _______________________________________________
>>>>               Users mailing list
>>>>               Users at lists.ironpython.com
>>>>        <mailto:Users at lists.ironpython.com>
>>>>        <mailto:Users at lists.ironpython.com
>>>>        <mailto:Users at lists.ironpython.com>>
>>>>
>>>>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>           --    http://www.ironpythoninaction.com/
>>>>           http://www.voidspace.org.uk/blog
>>>>
>>>>
>>>>           _______________________________________________
>>>>           Users mailing list
>>>>           Users at lists.ironpython.com
>>>>        <mailto:Users at lists.ironpython.com>
>>>>        <mailto:Users at lists.ironpython.com
>>>>        <mailto:Users at lists.ironpython.com>>
>>>>
>>>>           http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>  ------------------------------------------------------------------------
>>>>
>>>>        _______________________________________________
>>>>        Users mailing list
>>>>        Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>        http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>    --    http://www.ironpythoninaction.com/
>>>>    http://www.voidspace.org.uk/blog
>>>>
>>>>
>>>>    _______________________________________________
>>>>    Users mailing list
>>>>    Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> nomadlife.org <http://nomadlife.org>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>
>>>
>>> --
>>> http://www.ironpythoninaction.com/
>>> http://www.voidspace.org.uk/blog
>>>
>>>
>>>
>>
>>
>> --
>> nomadlife.org
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081102/e0a939c0/attachment.html>

From rob.s.oakes at gmail.com  Mon Nov  3 06:00:56 2008
From: rob.s.oakes at gmail.com (Rob Oakes)
Date: Sun, 2 Nov 2008 22:00:56 -0700
Subject: [IronPython] Question Regarding WPF : DataBinding,
	DataTemplates and C# Extensions
Message-ID: <490e858b.20038e0a.0f2e.ffffba9a@mx.google.com>

Dear Group,

 

I have a rather involved question (more accurately series of questions)
regarding WPF, particularly how it relates to DataBinding and DataTemplates.
I will do my best to keep this posting to a reasonable length, but ... well
... I guess this serves somewhat as a warning ;)  If you will spare me a bit
of background, I recently began trying to learn IronPython after hearing an
enthusiastic endorsement from a friend and colleague.  While not a
programmer or computer scientist by training (on the opposite of the
spectrum, actually, my degree is in biomedical engineering); I have found
myself increasing needing to work with programming tools in the past few
years.  This friend pointed me toward the .Net framework, and IronPython in
particular as a potential solution to several major issues we have been
facing with our primary data processing tool: Matlab.

 

As a trial test, I therefore decided to create a small program in
IronPython, namely, a Podcast Aggregator.  I purchased a Manning Early
Access Program copy of Michael Foord's (excellent BTW) book, IronPython in
Action and started trying to work toward my small test project.  As I also
wanted to learn WPF (not to mention make my little program as pretty as
possible), I decided to write the user interface for my aggregator in .xaml.

 

So, with that background out of the way, I arrive at a few questions.  The
first of these is somewhat of a follow-up to a topic addressed in May on
this very list somewhat recently (reference:
http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004912.h
tml).  In the original post, the author (Bish Bosh) asked what the best
method of referring to Python types in Xaml was.  Later in the discussion,
Dino Viehland offered that it might be best to:

 

"Declare an interface in C# (or find an existing one which has what you
want) and inherit and implement the interfaces in Python.  Then the
interface will be the bridge between the static and dynamic worlds"
(reference:
http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004913.h
tml).

 

So, my first question: After reading all the material I have been able to
find on the subject, I have not been able to locate a good tutorial or
example of how this might be done.  Might it be possible to get some
additional information on how this can be accomplished?  A simple example of
how it can then be integrated into IronPython code would be extremely
appreciated.

 

I have made an effort using the information available in the IronPython
tutorial and a relatively simple XAML example (reference:
http://blah.winsmarts.com/2007-3-WPF__The_DataTemplate,_choosing_how_your_da
ta_will_look_like.aspx), but I have had no luck in creating a test
application that will successfully load and perform as advertised.

 

Using the xaml, C# and mainWindow.py file below, I receive the error:

 

SystemError: Type reference cannot find public type named 'LocalTimes'

 

I am at the end of my rope and am not sure what I should try next.  Are
there any ideas on how I might successfully implement a custom C# interface?

 

Sincerely,

 

Rob Oakes

 

PS, Here is the source code for the simple test case I have been working
with.

 

<< Main IPY script, called from command line with ipy TestApp.py

 

import clr

import os

import WindowsRSS

clr.AddReference("PresentationFramework")

clr.AddReference("PresentationCore")

clr.AddReferenceToFile("IFancyData.dll")

 

import LocalTimes, LocalTime

 

from System.IO import File

from System.Windows.Markup import XamlReader from System.ComponentModel
import INotifyPropertyChanged from System.ComponentModel import
PropertyChangedEventArgs from System.Windows import Application, Window

 

class TestApp(object):

 

    def __init__(self):

        xamlStream = File.OpenRead('DataBinding_20081102.xaml')

        self.Root = XamlReader.Load(xamlStream)

        self.LocalTimes = LocalTimes()

 

mainWin = TestApp()

app = Application()

app.Resources.Add('collection', LocalTimes())

app.Run(mainWin.Root)

 

>> 

 

<< DataBinding_20081102.xaml - GUI Window

 

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Hello World!" Height="300" Width="300">

      <Window.Resources>

            <ObjectDataProvider x:Key="localTimes" ObjectType="{x:Type
LocalTimes}"/>

      </Window.Resources>

      <Grid>

      </Grid>

</Window>

 

>> 

 

<< LocalTimes.cs - Custom C# Class - LocalTimes

 

using System;

using System.Collections;

using System.Collections.Generic;

 

public class LocalTimes : List<LocalTime> {

 

      public LocalTimes() {

            this.Add(new LocalTime("New York", DateTime.Now));

            this.Add(new LocalTime("Chicago", DateTime.Now.AddHours(-1)));

            this.Add(new LocalTime("Denver", DateTime.Now.AddHours(-2)));

            this.Add(new LocalTime("Los Angeles",
DateTime.Now.AddHours(-3)));

      }

}

 

public class LocalTime {

 

      private string place;

      private DateTime time;

      

      public LocalTime(string _place, DateTime _time) {

      

            place = _place;

            time = _time;

      }

      

      public DateTime Time {

            get { return time; }

            set { time = value; }

      }

      

      public string Place {

      

            get { return place; }

      }

}

 

>> 

 

Interpreter Output from the above files:

 

  File C:\Users\Rob
Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line 23, in
Initialize

  File C:\Users\Rob
Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line 20, in
__init__

  File , line 0, in Load##106

  File PresentationFramework, line unknown, in Load

  File PresentationFramework, line unknown, in XmlTreeBuildDefault

  File PresentationFramework, line unknown, in Parse

  File PresentationFramework, line unknown, in ParseFragment

  File PresentationFramework, line unknown, in _Parse

  File PresentationFramework, line unknown, in ReadXaml

  File PresentationFramework, line unknown, in Read

SystemError: Type reference cannot find public type named 'LocalTimes'.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081102/15d888b8/attachment.html>

From dinov at microsoft.com  Mon Nov  3 17:08:43 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 3 Nov 2008 08:08:43 -0800
Subject: [IronPython] Question Regarding WPF : DataBinding,
	DataTemplates and C# Extensions
In-Reply-To: <490e858b.20038e0a.0f2e.ffffba9a@mx.google.com>
References: <490e858b.20038e0a.0f2e.ffffba9a@mx.google.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF7266F14@NA-EXMSG-C102.redmond.corp.microsoft.com>

Declaring an interface from Python is easy:

import System
class MyComparer(System.IComparable):
    def CompareTo(self, other):
        print 'compared'
        return -1

a = MyComparer()
b = MyComparer()
c = MyComparer()
l = System.Collections.ArrayList([a,b,c])
l.Sort()

prints:

compared
compared
compared
compared
compared

Unfortunately I don't know enough about WPF to know why you'd get the exception you're seeing.  One thing that might help would be running with -X:ExceptionDetail so you get the full .NET stack trace as well.  That might help someone else on the list identify what's going on.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rob Oakes
Sent: Sunday, November 02, 2008 9:01 PM
To: users at lists.ironpython.com
Subject: [IronPython] Question Regarding WPF : DataBinding, DataTemplates and C# Extensions


Dear Group,



I have a rather involved question (more accurately series of questions) regarding WPF, particularly how it relates to DataBinding and DataTemplates.  I will do my best to keep this posting to a reasonable length, but ... well ... I guess this serves somewhat as a warning ;)  If you will spare me a bit of background, I recently began trying to learn IronPython after hearing an enthusiastic endorsement from a friend and colleague.  While not a programmer or computer scientist by training (on the opposite of the spectrum, actually, my degree is in biomedical engineering); I have found myself increasing needing to work with programming tools in the past few years.  This friend pointed me toward the .Net framework, and IronPython in particular as a potential solution to several major issues we have been facing with our primary data processing tool: Matlab.



As a trial test, I therefore decided to create a small program in IronPython, namely, a Podcast Aggregator.  I purchased a Manning Early Access Program copy of Michael Foord's (excellent BTW) book, IronPython in Action and started trying to work toward my small test project.  As I also wanted to learn WPF (not to mention make my little program as pretty as possible), I decided to write the user interface for my aggregator in .xaml.



So, with that background out of the way, I arrive at a few questions.  The first of these is somewhat of a follow-up to a topic addressed in May on this very list somewhat recently (reference: http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004912.html).  In the original post, the author (Bish Bosh) asked what the best method of referring to Python types in Xaml was.  Later in the discussion, Dino Viehland offered that it might be best to:



"Declare an interface in C# (or find an existing one which has what you want) and inherit and implement the interfaces in Python.  Then the interface will be the bridge between the static and dynamic worlds" (reference: http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004913.html).



So, my first question: After reading all the material I have been able to find on the subject, I have not been able to locate a good tutorial or example of how this might be done.  Might it be possible to get some additional information on how this can be accomplished?  A simple example of how it can then be integrated into IronPython code would be extremely appreciated.



I have made an effort using the information available in the IronPython tutorial and a relatively simple XAML example (reference: http://blah.winsmarts.com/2007-3-WPF__The_DataTemplate,_choosing_how_your_data_will_look_like.aspx), but I have had no luck in creating a test application that will successfully load and perform as advertised.



Using the xaml, C# and mainWindow.py file below, I receive the error:



SystemError: Type reference cannot find public type named 'LocalTimes'



I am at the end of my rope and am not sure what I should try next.  Are there any ideas on how I might successfully implement a custom C# interface?



Sincerely,



Rob Oakes



PS, Here is the source code for the simple test case I have been working with.



<< Main IPY script, called from command line with ipy TestApp.py



import clr

import os

import WindowsRSS

clr.AddReference("PresentationFramework")

clr.AddReference("PresentationCore")

clr.AddReferenceToFile("IFancyData.dll")



import LocalTimes, LocalTime



from System.IO import File

from System.Windows.Markup import XamlReader from System.ComponentModel import INotifyPropertyChanged from System.ComponentModel import PropertyChangedEventArgs from System.Windows import Application, Window



class TestApp(object):



    def __init__(self):

        xamlStream = File.OpenRead('DataBinding_20081102.xaml')

        self.Root = XamlReader.Load(xamlStream)

        self.LocalTimes = LocalTimes()



mainWin = TestApp()

app = Application()

app.Resources.Add('collection', LocalTimes())

app.Run(mainWin.Root)



>>



<< DataBinding_20081102.xaml - GUI Window



<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Hello World!" Height="300" Width="300">

      <Window.Resources>

            <ObjectDataProvider x:Key="localTimes" ObjectType="{x:Type LocalTimes}"/>

      </Window.Resources>

      <Grid>

      </Grid>

</Window>



>>



<< LocalTimes.cs - Custom C# Class - LocalTimes



using System;

using System.Collections;

using System.Collections.Generic;



public class LocalTimes : List<LocalTime> {



      public LocalTimes() {

            this.Add(new LocalTime("New York", DateTime.Now));

            this.Add(new LocalTime("Chicago", DateTime.Now.AddHours(-1)));

            this.Add(new LocalTime("Denver", DateTime.Now.AddHours(-2)));

            this.Add(new LocalTime("Los Angeles", DateTime.Now.AddHours(-3)));

      }

}



public class LocalTime {



      private string place;

      private DateTime time;



      public LocalTime(string _place, DateTime _time) {



            place = _place;

            time = _time;

      }



      public DateTime Time {

            get { return time; }

            set { time = value; }

      }



      public string Place {



            get { return place; }

      }

}



>>



Interpreter Output from the above files:



  File C:\Users\Rob Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line 23, in Initialize

  File C:\Users\Rob Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line 20, in __init__

  File , line 0, in Load##106

  File PresentationFramework, line unknown, in Load

  File PresentationFramework, line unknown, in XmlTreeBuildDefault

  File PresentationFramework, line unknown, in Parse

  File PresentationFramework, line unknown, in ParseFragment

  File PresentationFramework, line unknown, in _Parse

  File PresentationFramework, line unknown, in ReadXaml

  File PresentationFramework, line unknown, in Read

SystemError: Type reference cannot find public type named 'LocalTimes'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081103/2669c5fd/attachment.html>

From simon.dahlbacka at gmail.com  Mon Nov  3 17:17:05 2008
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Mon, 3 Nov 2008 18:17:05 +0200
Subject: [IronPython] Question Regarding WPF : DataBinding,
	DataTemplates and C# Extensions
In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266F14@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <490e858b.20038e0a.0f2e.ffffba9a@mx.google.com>
	<350E7D38B6D819428718949920EC23554FF7266F14@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <57124720811030817k5637f024wd08a19a1c7e30b9b@mail.gmail.com>

As the error message says, it cannot find the type LocalTimes.

Normally you have to map an xml namespace into the corresponding clr
namespace by adding something along the lines of

xmlns:src="clr-namespace:Whatever.Namespace;assembly=TheAssemblyName"

to the xaml file

and then you would declare the objectDataProvider like this instead

            <ObjectDataProvider x:Key="localTimes" ObjectType="{x:Type
src:LocalTimes}"/>

However, I'm not sure how it works if you don't put LocalTimes in a
namespace




On Mon, Nov 3, 2008 at 6:08 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  Declaring an interface from Python is easy:
>
>
>
> import System
>
> class MyComparer(System.IComparable):
>
>     def CompareTo(self, other):
>
>         print 'compared'
>
>         return -1
>
>
>
> a = MyComparer()
>
> b = MyComparer()
>
> c = MyComparer()
>
> l = System.Collections.ArrayList([a,b,c])
>
> l.Sort()
>
>
>
> prints:
>
>
>
> compared
>
> compared
>
> compared
>
> compared
>
> compared
>
>
>
> Unfortunately I don't know enough about WPF to know why you'd get the
> exception you're seeing.  One thing that might help would be running with
> ?X:ExceptionDetail so you get the full .NET stack trace as well.  That might
> help someone else on the list identify what's going on.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Rob Oakes
> *Sent:* Sunday, November 02, 2008 9:01 PM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] Question Regarding WPF : DataBinding,
> DataTemplates and C# Extensions
>
>
>
> Dear Group,
>
>
>
> I have a rather involved question (more accurately series of questions)
> regarding WPF, particularly how it relates to DataBinding and
> DataTemplates.  I will do my best to keep this posting to a reasonable
> length, but ... well ... I guess this serves somewhat as a warning ;)  If
> you will spare me a bit of background, I recently began trying to learn
> IronPython after hearing an enthusiastic endorsement from a friend and
> colleague.  While not a programmer or computer scientist by training (on the
> opposite of the spectrum, actually, my degree is in biomedical engineering);
> I have found myself increasing needing to work with programming tools in the
> past few years.  This friend pointed me toward the .Net framework, and
> IronPython in particular as a potential solution to several major issues we
> have been facing with our primary data processing tool: Matlab.
>
>
>
> As a trial test, I therefore decided to create a small program in
> IronPython, namely, a Podcast Aggregator.  I purchased a Manning Early
> Access Program copy of Michael Foord's (excellent BTW) book, IronPython in
> Action and started trying to work toward my small test project.  As I also
> wanted to learn WPF (not to mention make my little program as pretty as
> possible), I decided to write the user interface for my aggregator in .xaml.
>
>
>
> So, with that background out of the way, I arrive at a few questions.  The
> first of these is somewhat of a follow-up to a topic addressed in May on
> this very list somewhat recently (reference:
> http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004912.html).
> In the original post, the author (Bish Bosh) asked what the best method of
> referring to Python types in Xaml was.  Later in the discussion, Dino
> Viehland offered that it might be best to:
>
>
>
> "Declare an interface in C# (or find an existing one which has what you
> want) and inherit and implement the interfaces in Python.  Then the
> interface will be the bridge between the static and dynamic worlds"
> (reference:
> http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004913.html
> ).
>
>
>
> So, my first question: After reading all the material I have been able to
> find on the subject, I have not been able to locate a good tutorial or
> example of how this might be done.  Might it be possible to get some
> additional information on how this can be accomplished?  A simple example of
> how it can then be integrated into IronPython code would be extremely
> appreciated.
>
>
>
> I have made an effort using the information available in the IronPython
> tutorial and a relatively simple XAML example (reference:
> http://blah.winsmarts.com/2007-3-WPF__The_DataTemplate,_choosing_how_your_data_will_look_like.aspx),
> but I have had no luck in creating a test application that will successfully
> load and perform as advertised.
>
>
>
> Using the xaml, C# and mainWindow.py file below, I receive the error:
>
>
>
> SystemError: Type reference cannot find public type named 'LocalTimes'
>
>
>
> I am at the end of my rope and am not sure what I should try next.  Are
> there any ideas on how I might successfully implement a custom C# interface?
>
>
>
> Sincerely,
>
>
>
> Rob Oakes
>
>
>
> PS, Here is the source code for the simple test case I have been working
> with.
>
>
>
> << Main IPY script, called from command line with ipy TestApp.py
>
>
>
> import clr
>
> import os
>
> import WindowsRSS
>
> clr.AddReference("PresentationFramework")
>
> clr.AddReference("PresentationCore")
>
> clr.AddReferenceToFile("IFancyData.dll")
>
>
>
> import LocalTimes, LocalTime
>
>
>
> from System.IO import File
>
> from System.Windows.Markup import XamlReader from System.ComponentModel
> import INotifyPropertyChanged from System.ComponentModel import
> PropertyChangedEventArgs from System.Windows import Application, Window
>
>
>
> class TestApp(object):
>
>
>
>     def __init__(self):
>
>         xamlStream = File.OpenRead('DataBinding_20081102.xaml')
>
>         self.Root = XamlReader.Load(xamlStream)
>
>         self.LocalTimes = LocalTimes()
>
>
>
> mainWin = TestApp()
>
> app = Application()
>
> app.Resources.Add('collection', LocalTimes())
>
> app.Run(mainWin.Root)
>
>
>
> >>
>
>
>
> << DataBinding_20081102.xaml - GUI Window
>
>
>
> <Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>
>     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
>     Title="Hello World!" Height="300" Width="300">
>
>       <Window.Resources>
>
>             <ObjectDataProvider x:Key="localTimes" ObjectType="{x:Type
> LocalTimes}"/>
>
>       </Window.Resources>
>
>       <Grid>
>
>       </Grid>
>
> </Window>
>
>
>
> >>
>
>
>
> << LocalTimes.cs - Custom C# Class - LocalTimes
>
>
>
> using System;
>
> using System.Collections;
>
> using System.Collections.Generic;
>
>
>
> public class LocalTimes : List<LocalTime> {
>
>
>
>       public LocalTimes() {
>
>             this.Add(new LocalTime("New York", DateTime.Now));
>
>             this.Add(new LocalTime("Chicago", DateTime.Now.AddHours(-1)));
>
>             this.Add(new LocalTime("Denver", DateTime.Now.AddHours(-2)));
>
>             this.Add(new LocalTime("Los Angeles",
> DateTime.Now.AddHours(-3)));
>
>       }
>
> }
>
>
>
> public class LocalTime {
>
>
>
>       private string place;
>
>       private DateTime time;
>
>
>
>       public LocalTime(string _place, DateTime _time) {
>
>
>
>             place = _place;
>
>             time = _time;
>
>       }
>
>
>
>       public DateTime Time {
>
>             get { return time; }
>
>             set { time = value; }
>
>       }
>
>
>
>       public string Place {
>
>
>
>             get { return place; }
>
>       }
>
> }
>
>
>
> >>
>
>
>
> Interpreter Output from the above files:
>
>
>
>   File C:\Users\Rob
> Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line 23, in
> Initialize
>
>   File C:\Users\Rob
> Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line 20, in
> __init__
>
>   File , line 0, in Load##106
>
>   File PresentationFramework, line unknown, in Load
>
>   File PresentationFramework, line unknown, in XmlTreeBuildDefault
>
>   File PresentationFramework, line unknown, in Parse
>
>   File PresentationFramework, line unknown, in ParseFragment
>
>   File PresentationFramework, line unknown, in _Parse
>
>   File PresentationFramework, line unknown, in ReadXaml
>
>   File PresentationFramework, line unknown, in Read
>
> SystemError: Type reference cannot find public type named 'LocalTimes'.
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081103/a8356554/attachment.html>

From xkenneth at gmail.com  Tue Nov  4 07:40:07 2008
From: xkenneth at gmail.com (Kenneth Miller)
Date: Tue, 4 Nov 2008 00:40:07 -0600
Subject: [IronPython] Loading Python modules from Silverlight Isolated
	Storage
Message-ID: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>

All,

    Is it possible to have python load modules from the silverlight  
isolated storage? My app needs to dynamically generate and import  
python code to run.

Regards,
Ken


From curt at hagenlocher.org  Tue Nov  4 07:45:19 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Mon, 3 Nov 2008 23:45:19 -0700
Subject: [IronPython] Loading Python modules from Silverlight Isolated
	Storage
In-Reply-To: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>
Message-ID: <d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>

You should be able to do this all in-memory:

>>> import sys
>>> foo = type(sys)('foo')
>>> sys.modules['foo'] = foo
>>> exec 'a = 1' in foo.__dict__
>>> foo.a
1
>>>

There's probably a better ("more Pythonic") way to do this, but I'm
sleepy...

On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com> wrote:

> All,
>
>   Is it possible to have python load modules from the silverlight isolated
> storage? My app needs to dynamically generate and import python code to run.
>
> Regards,
> Ken
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081103/046d400a/attachment.html>

From dinov at microsoft.com  Tue Nov  4 07:51:26 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 3 Nov 2008 22:51:26 -0800
Subject: [IronPython] Loading Python modules from Silverlight
	Isolated	Storage
In-Reply-To: <d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>
	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF726743B@NA-EXMSG-C102.redmond.corp.microsoft.com>

...
import imp
foo = imp.new_module('foo')
...

is a step in the right direction.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Monday, November 03, 2008 10:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Loading Python modules from Silverlight Isolated Storage

You should be able to do this all in-memory:

>>> import sys
>>> foo = type(sys)('foo')
>>> sys.modules['foo'] = foo
>>> exec 'a = 1' in foo.__dict__
>>> foo.a
1
>>>

There's probably a better ("more Pythonic") way to do this, but I'm sleepy...
On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com<mailto:xkenneth at gmail.com>> wrote:
All,

  Is it possible to have python load modules from the silverlight isolated storage? My app needs to dynamically generate and import python code to run.

Regards,
Ken
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081103/1e5edbf0/attachment.html>

From xkenneth at gmail.com  Tue Nov  4 07:52:30 2008
From: xkenneth at gmail.com (Kenneth Miller)
Date: Tue, 4 Nov 2008 00:52:30 -0600
Subject: [IronPython] Loading Python modules from Silverlight Isolated
	Storage
In-Reply-To: <d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>
	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
Message-ID: <1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>

It was proven to me that while exec might work for simple cases, more  
advanced usage (declaring a lambda function inside an exec) can be  
problematic. It was advised that I generate python modules and  
dynamically import them. If memory served me, it's not possible to  
import a module from a string object.

Thanks.

- Ken

On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher" <curt at hagenlocher.org>  
wrote:

> You should be able to do this all in-memory:
>
> >>> import sys
> >>> foo = type(sys)('foo')
> >>> sys.modules['foo'] = foo
> >>> exec 'a = 1' in foo.__dict__
> >>> foo.a
> 1
> >>>
>
> There's probably a better ("more Pythonic") way to do this, but I'm  
> sleepy...
>
> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com>  
> wrote:
> All,
>
>   Is it possible to have python load modules from the silverlight  
> isolated storage? My app needs to dynamically generate and import  
> python code to run.
>
> Regards,
> Ken
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081104/eed2fffb/attachment.html>

From dinov at microsoft.com  Tue Nov  4 07:59:25 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 3 Nov 2008 22:59:25 -0800
Subject: [IronPython] Loading Python modules from Silverlight
	Isolated	Storage
In-Reply-To: <1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>
	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF726743E@NA-EXMSG-C102.redmond.corp.microsoft.com>

What?s the problem w/ declaring a lambda inside an exec?

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kenneth Miller
Sent: Monday, November 03, 2008 10:53 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Loading Python modules from Silverlight Isolated Storage

It was proven to me that while exec might work for simple cases, more advanced usage (declaring a lambda function inside an exec) can be problematic. It was advised that I generate python modules and dynamically import them. If memory served me, it's not possible to import a module from a string object.

Thanks.

- Ken

On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher" <curt at hagenlocher.org<mailto:curt at hagenlocher.org>> wrote:
You should be able to do this all in-memory:

>>> import sys
>>> foo = type(sys)('foo')
>>> sys.modules['foo'] = foo
>>> exec 'a = 1' in foo.__dict__
>>> foo.a
1
>>>

There's probably a better ("more Pythonic") way to do this, but I'm sleepy...
On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com<mailto:xkenneth at gmail.com>> wrote:
All,

  Is it possible to have python load modules from the silverlight isolated storage? My app needs to dynamically generate and import python code to run.

Regards,
Ken
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081103/33322a88/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov  4 11:42:13 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 04 Nov 2008 10:42:13 +0000
Subject: [IronPython] Loading Python modules from Silverlight Isolated
 Storage
In-Reply-To: <1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>
Message-ID: <49102705.9020305@voidspace.org.uk>

Kenneth Miller wrote:
> It was proven to me that while exec might work for simple cases, more 
> advanced usage (declaring a lambda function inside an exec) can be 
> problematic. It was advised that I generate python modules and 
> dynamically import them. If memory served me, it's not possible to 
> import a module from a string object.
>
I have often generated (or loaded code into a string) and then exec'd it 
into a module dict to create modules at runtime. It is a relatively 
normal technique in Python.

Michael

> Thanks.
>
> - Ken
>
> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher" <curt at hagenlocher.org 
> <mailto:curt at hagenlocher.org>> wrote:
>
>> You should be able to do this all in-memory:
>>
>> >>> import sys
>> >>> foo = type(sys)('foo')
>> >>> sys.modules['foo'] = foo
>> >>> exec 'a = 1' in foo.__dict__
>> >>> foo.a
>> 1
>> >>>
>>
>> There's probably a better ("more Pythonic") way to do this, but I'm 
>> sleepy...
>>
>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com 
>> <mailto:xkenneth at gmail.com>> wrote:
>>
>>     All,
>>
>>       Is it possible to have python load modules from the silverlight
>>     isolated storage? My app needs to dynamically generate and import
>>     python code to run.
>>
>>     Regards,
>>     Ken
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>     http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com <mailto: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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From fuzzyman at voidspace.org.uk  Tue Nov  4 12:02:48 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 04 Nov 2008 11:02:48 +0000
Subject: [IronPython] Question Regarding WPF : DataBinding,
 DataTemplates and C# Extensions
In-Reply-To: <57124720811030817k5637f024wd08a19a1c7e30b9b@mail.gmail.com>
References: <490e858b.20038e0a.0f2e.ffffba9a@mx.google.com>	<350E7D38B6D819428718949920EC23554FF7266F14@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<57124720811030817k5637f024wd08a19a1c7e30b9b@mail.gmail.com>
Message-ID: <49102BD8.6080108@voidspace.org.uk>

Simon Dahlbacka wrote:
> As the error message says, it cannot find the type LocalTimes.
>


You may be interested in DynamicScriptControl:

http://www.codeplex.com/dynamicscriptcontrol

It needs a bit (but not much) work to get it working with IronPython.

 From the project page:

We created a control that can be used with WPF or Silverlight to 
integrate DLR based controls into the xaml so that they can participate 
a little better into XAML based applications..


At this moment the control only supports IronRuby but that will soon change.

This project on codeplex will only hold releases if you're interested in 
the source code or contributing look for us at:
http://code.google.com/p/dynamic-script-control

I blogged about its usage: 
http://flanders.co.nz/2008/06/12/dynamic-script-control/

Michael

> Normally you have to map an xml namespace into the corresponding clr 
> namespace by adding something along the lines of
>
> xmlns:src="clr-namespace:Whatever.Namespace;assembly=TheAssemblyName"
>
> to the xaml file
>
> and then you would declare the objectDataProvider like this instead
>
>             <ObjectDataProvider x:Key="localTimes" ObjectType="{x:Type 
> src:LocalTimes}"/>
>
> However, I'm not sure how it works if you don't put LocalTimes in a 
> namespace
>
>
>
>
> On Mon, Nov 3, 2008 at 6:08 PM, Dino Viehland <dinov at microsoft.com 
> <mailto:dinov at microsoft.com>> wrote:
>
>     Declaring an interface from Python is easy:
>
>      
>
>     import System
>
>     class MyComparer(System.IComparable):
>
>         def CompareTo(self, other):
>
>             print 'compared'
>
>             return -1
>
>      
>
>     a = MyComparer()
>
>     b = MyComparer()
>
>     c = MyComparer()
>
>     l = System.Collections.ArrayList([a,b,c])
>
>     l.Sort()
>
>      
>
>     prints:
>
>      
>
>     compared
>
>     compared
>
>     compared
>
>     compared
>
>     compared
>
>      
>
>     Unfortunately I don't know enough about WPF to know why you'd get
>     the exception you're seeing.  One thing that might help would be
>     running with ?X:ExceptionDetail so you get the full .NET stack
>     trace as well.  That might help someone else on the list identify
>     what's going on.
>
>      
>
>     *From:* users-bounces at lists.ironpython.com
>     <mailto:users-bounces at lists.ironpython.com>
>     [mailto:users-bounces at lists.ironpython.com
>     <mailto:users-bounces at lists.ironpython.com>] *On Behalf Of *Rob Oakes
>     *Sent:* Sunday, November 02, 2008 9:01 PM
>     *To:* users at lists.ironpython.com <mailto:users at lists.ironpython.com>
>     *Subject:* [IronPython] Question Regarding WPF : DataBinding,
>     DataTemplates and C# Extensions
>
>      
>
>     Dear Group,
>
>      
>
>     I have a rather involved question (more accurately series of
>     questions) regarding WPF, particularly how it relates to
>     DataBinding and DataTemplates.  I will do my best to keep this
>     posting to a reasonable length, but ... well ... I guess this
>     serves somewhat as a warning ;)  If you will spare me a bit of
>     background, I recently began trying to learn IronPython after
>     hearing an enthusiastic endorsement from a friend and colleague. 
>     While not a programmer or computer scientist by training (on the
>     opposite of the spectrum, actually, my degree is in biomedical
>     engineering); I have found myself increasing needing to work with
>     programming tools in the past few years.  This friend pointed me
>     toward the .Net framework, and IronPython in particular as a
>     potential solution to several major issues we have been facing
>     with our primary data processing tool: Matlab.
>
>      
>
>     As a trial test, I therefore decided to create a small program in
>     IronPython, namely, a Podcast Aggregator.  I purchased a Manning
>     Early Access Program copy of Michael Foord's (excellent BTW) book,
>     IronPython in Action and started trying to work toward my small
>     test project.  As I also wanted to learn WPF (not to mention make
>     my little program as pretty as possible), I decided to write the
>     user interface for my aggregator in .xaml.
>
>      
>
>     So, with that background out of the way, I arrive at a few
>     questions.  The first of these is somewhat of a follow-up to a
>     topic addressed in May on this very list somewhat recently
>     (reference:
>     http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004912.html). 
>     In the original post, the author (Bish Bosh) asked what the best
>     method of referring to Python types in Xaml was.  Later in the
>     discussion, Dino Viehland offered that it might be best to:
>
>      
>
>     "Declare an interface in C# (or find an existing one which has
>     what you want) and inherit and implement the interfaces in
>     Python.  Then the interface will be the bridge between the static
>     and dynamic worlds" (reference:
>     http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004913.html).
>
>      
>
>     So, my first question: After reading all the material I have been
>     able to find on the subject, I have not been able to locate a good
>     tutorial or example of how this might be done.  Might it be
>     possible to get some additional information on how this can be
>     accomplished?  A simple example of how it can then be integrated
>     into IronPython code would be extremely appreciated.
>
>      
>
>     I have made an effort using the information available in the
>     IronPython tutorial and a relatively simple XAML example
>     (reference:
>     http://blah.winsmarts.com/2007-3-WPF__The_DataTemplate,_choosing_how_your_data_will_look_like.aspx),
>     but I have had no luck in creating a test application that will
>     successfully load and perform as advertised.
>
>      
>
>     Using the xaml, C# and mainWindow.py file below, I receive the error:
>
>      
>
>     SystemError: Type reference cannot find public type named 'LocalTimes'
>
>      
>
>     I am at the end of my rope and am not sure what I should try
>     next.  Are there any ideas on how I might successfully implement a
>     custom C# interface?
>
>      
>
>     Sincerely,
>
>      
>
>     Rob Oakes
>
>      
>
>     PS, Here is the source code for the simple test case I have been
>     working with.
>
>      
>
>     << Main IPY script, called from command line with ipy TestApp.py
>
>      
>
>     import clr
>
>     import os
>
>     import WindowsRSS
>
>     clr.AddReference("PresentationFramework")
>
>     clr.AddReference("PresentationCore")
>
>     clr.AddReferenceToFile("IFancyData.dll")
>
>      
>
>     import LocalTimes, LocalTime
>
>      
>
>     from System.IO import File
>
>     from System.Windows.Markup import XamlReader from
>     System.ComponentModel import INotifyPropertyChanged from
>     System.ComponentModel import PropertyChangedEventArgs from
>     System.Windows import Application, Window
>
>      
>
>     class TestApp(object):
>
>      
>
>         def __init__(self):
>
>             xamlStream = File.OpenRead('DataBinding_20081102.xaml')
>
>             self.Root = XamlReader.Load(xamlStream)
>
>             self.LocalTimes = LocalTimes()
>
>      
>
>     mainWin = TestApp()
>
>     app = Application()
>
>     app.Resources.Add('collection', LocalTimes())
>
>     app.Run(mainWin.Root)
>
>      
>
>     >> 
>
>      
>
>     << DataBinding_20081102.xaml - GUI Window
>
>      
>
>     <Window
>     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>
>         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
>         Title="Hello World!" Height="300" Width="300">
>
>           <Window.Resources>
>
>                 <ObjectDataProvider x:Key="localTimes"
>     ObjectType="{x:Type LocalTimes}"/>
>
>           </Window.Resources>
>
>           <Grid>
>
>           </Grid>
>
>     </Window>
>
>      
>
>     >> 
>
>      
>
>     << LocalTimes.cs - Custom C# Class - LocalTimes
>
>      
>
>     using System;
>
>     using System.Collections;
>
>     using System.Collections.Generic;
>
>      
>
>     public class LocalTimes : List<LocalTime> {
>
>      
>
>           public LocalTimes() {
>
>                 this.Add(new LocalTime("New York", DateTime.Now));
>
>                 this.Add(new LocalTime("Chicago",
>     DateTime.Now.AddHours(-1)));
>
>                 this.Add(new LocalTime("Denver",
>     DateTime.Now.AddHours(-2)));
>
>                 this.Add(new LocalTime("Los Angeles",
>     DateTime.Now.AddHours(-3)));
>
>           }
>
>     }
>
>      
>
>     public class LocalTime {
>
>      
>
>           private string place;
>
>           private DateTime time;
>
>          
>
>           public LocalTime(string _place, DateTime _time) {
>
>          
>
>                 place = _place;
>
>                 time = _time;
>
>           }
>
>          
>
>           public DateTime Time {
>
>                 get { return time; }
>
>                 set { time = value; }
>
>           }
>
>          
>
>           public string Place {
>
>          
>
>                 get { return place; }
>
>           }
>
>     }
>
>      
>
>     >> 
>
>      
>
>     Interpreter Output from the above files:
>
>      
>
>       File C:\Users\Rob
>     Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line
>     23, in Initialize
>
>       File C:\Users\Rob
>     Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line
>     20, in __init__
>
>       File , line 0, in Load##106
>
>       File PresentationFramework, line unknown, in Load
>
>       File PresentationFramework, line unknown, in XmlTreeBuildDefault
>
>       File PresentationFramework, line unknown, in Parse
>
>       File PresentationFramework, line unknown, in ParseFragment
>
>       File PresentationFramework, line unknown, in _Parse
>
>       File PresentationFramework, line unknown, in ReadXaml
>
>       File PresentationFramework, line unknown, in Read
>
>     SystemError: Type reference cannot find public type named
>     'LocalTimes'.
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From ivan at flanders.co.nz  Tue Nov  4 12:16:06 2008
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Tue, 4 Nov 2008 12:16:06 +0100
Subject: [IronPython] Question Regarding WPF : DataBinding,
	DataTemplates and C# Extensions
In-Reply-To: <49102BD8.6080108@voidspace.org.uk>
References: <490e858b.20038e0a.0f2e.ffffba9a@mx.google.com>
	<350E7D38B6D819428718949920EC23554FF7266F14@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<57124720811030817k5637f024wd08a19a1c7e30b9b@mail.gmail.com>
	<49102BD8.6080108@voidspace.org.uk>
Message-ID: <b1c6aabb0811040316u3770d6c7xac1b7993de24585a@mail.gmail.com>

Michael is right.

The control still does have some limitations. When I finish my IronRuby book
I'll look at changing some of the implementation.
At this moment you would need a create a formatter for ironpython

You can view the RubyFormatter here:
http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/Formatters/RubyFormatter.cs?r=22

Then all that is left to do is to replace the notimplementedexception on the
converter
http://code.google.com/p/dynamic-script-control/source/browse/trunk/src/DynamicScriptControl/ScriptConverter.cs?r=22
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim



On Tue, Nov 4, 2008 at 12:02 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> Simon Dahlbacka wrote:
>
>> As the error message says, it cannot find the type LocalTimes.
>>
>>
>
> You may be interested in DynamicScriptControl:
>
> http://www.codeplex.com/dynamicscriptcontrol
>
> It needs a bit (but not much) work to get it working with IronPython.
>
> From the project page:
>
> We created a control that can be used with WPF or Silverlight to integrate
> DLR based controls into the xaml so that they can participate a little
> better into XAML based applications..
>
>
> At this moment the control only supports IronRuby but that will soon
> change.
>
> This project on codeplex will only hold releases if you're interested in
> the source code or contributing look for us at:
> http://code.google.com/p/dynamic-script-control
>
> I blogged about its usage:
> http://flanders.co.nz/2008/06/12/dynamic-script-control/
>
> Michael
>
>  Normally you have to map an xml namespace into the corresponding clr
>> namespace by adding something along the lines of
>>
>> xmlns:src="clr-namespace:Whatever.Namespace;assembly=TheAssemblyName"
>>
>> to the xaml file
>>
>> and then you would declare the objectDataProvider like this instead
>>
>>            <ObjectDataProvider x:Key="localTimes" ObjectType="{x:Type
>> src:LocalTimes}"/>
>>
>> However, I'm not sure how it works if you don't put LocalTimes in a
>> namespace
>>
>>
>>
>>
>> On Mon, Nov 3, 2008 at 6:08 PM, Dino Viehland <dinov at microsoft.com<mailto:
>> dinov at microsoft.com>> wrote:
>>
>>    Declaring an interface from Python is easy:
>>
>>
>>    import System
>>
>>    class MyComparer(System.IComparable):
>>
>>        def CompareTo(self, other):
>>
>>            print 'compared'
>>
>>            return -1
>>
>>
>>    a = MyComparer()
>>
>>    b = MyComparer()
>>
>>    c = MyComparer()
>>
>>    l = System.Collections.ArrayList([a,b,c])
>>
>>    l.Sort()
>>
>>
>>    prints:
>>
>>
>>    compared
>>
>>    compared
>>
>>    compared
>>
>>    compared
>>
>>    compared
>>
>>
>>    Unfortunately I don't know enough about WPF to know why you'd get
>>    the exception you're seeing.  One thing that might help would be
>>    running with ?X:ExceptionDetail so you get the full .NET stack
>>    trace as well.  That might help someone else on the list identify
>>    what's going on.
>>
>>
>>    *From:* users-bounces at lists.ironpython.com
>>    <mailto:users-bounces at lists.ironpython.com>
>>    [mailto:users-bounces at lists.ironpython.com
>>    <mailto:users-bounces at lists.ironpython.com>] *On Behalf Of *Rob Oakes
>>    *Sent:* Sunday, November 02, 2008 9:01 PM
>>    *To:* users at lists.ironpython.com <mailto:users at lists.ironpython.com>
>>    *Subject:* [IronPython] Question Regarding WPF : DataBinding,
>>    DataTemplates and C# Extensions
>>
>>
>>    Dear Group,
>>
>>
>>    I have a rather involved question (more accurately series of
>>    questions) regarding WPF, particularly how it relates to
>>    DataBinding and DataTemplates.  I will do my best to keep this
>>    posting to a reasonable length, but ... well ... I guess this
>>    serves somewhat as a warning ;)  If you will spare me a bit of
>>    background, I recently began trying to learn IronPython after
>>    hearing an enthusiastic endorsement from a friend and colleague.
>>  While not a programmer or computer scientist by training (on the
>>    opposite of the spectrum, actually, my degree is in biomedical
>>    engineering); I have found myself increasing needing to work with
>>    programming tools in the past few years.  This friend pointed me
>>    toward the .Net framework, and IronPython in particular as a
>>    potential solution to several major issues we have been facing
>>    with our primary data processing tool: Matlab.
>>
>>
>>    As a trial test, I therefore decided to create a small program in
>>    IronPython, namely, a Podcast Aggregator.  I purchased a Manning
>>    Early Access Program copy of Michael Foord's (excellent BTW) book,
>>    IronPython in Action and started trying to work toward my small
>>    test project.  As I also wanted to learn WPF (not to mention make
>>    my little program as pretty as possible), I decided to write the
>>    user interface for my aggregator in .xaml.
>>
>>
>>    So, with that background out of the way, I arrive at a few
>>    questions.  The first of these is somewhat of a follow-up to a
>>    topic addressed in May on this very list somewhat recently
>>    (reference:
>>
>> http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004912.html).
>>    In the original post, the author (Bish Bosh) asked what the best
>>    method of referring to Python types in Xaml was.  Later in the
>>    discussion, Dino Viehland offered that it might be best to:
>>
>>
>>    "Declare an interface in C# (or find an existing one which has
>>    what you want) and inherit and implement the interfaces in
>>    Python.  Then the interface will be the bridge between the static
>>    and dynamic worlds" (reference:
>>
>> http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004913.html
>> ).
>>
>>
>>    So, my first question: After reading all the material I have been
>>    able to find on the subject, I have not been able to locate a good
>>    tutorial or example of how this might be done.  Might it be
>>    possible to get some additional information on how this can be
>>    accomplished?  A simple example of how it can then be integrated
>>    into IronPython code would be extremely appreciated.
>>
>>
>>    I have made an effort using the information available in the
>>    IronPython tutorial and a relatively simple XAML example
>>    (reference:
>>
>> http://blah.winsmarts.com/2007-3-WPF__The_DataTemplate,_choosing_how_your_data_will_look_like.aspx
>> ),
>>    but I have had no luck in creating a test application that will
>>    successfully load and perform as advertised.
>>
>>
>>    Using the xaml, C# and mainWindow.py file below, I receive the error:
>>
>>
>>    SystemError: Type reference cannot find public type named 'LocalTimes'
>>
>>
>>    I am at the end of my rope and am not sure what I should try
>>    next.  Are there any ideas on how I might successfully implement a
>>    custom C# interface?
>>
>>
>>    Sincerely,
>>
>>
>>    Rob Oakes
>>
>>
>>    PS, Here is the source code for the simple test case I have been
>>    working with.
>>
>>
>>    << Main IPY script, called from command line with ipy TestApp.py
>>
>>
>>    import clr
>>
>>    import os
>>
>>    import WindowsRSS
>>
>>    clr.AddReference("PresentationFramework")
>>
>>    clr.AddReference("PresentationCore")
>>
>>    clr.AddReferenceToFile("IFancyData.dll")
>>
>>
>>    import LocalTimes, LocalTime
>>
>>
>>    from System.IO import File
>>
>>    from System.Windows.Markup import XamlReader from
>>    System.ComponentModel import INotifyPropertyChanged from
>>    System.ComponentModel import PropertyChangedEventArgs from
>>    System.Windows import Application, Window
>>
>>
>>    class TestApp(object):
>>
>>
>>        def __init__(self):
>>
>>            xamlStream = File.OpenRead('DataBinding_20081102.xaml')
>>
>>            self.Root = XamlReader.Load(xamlStream)
>>
>>            self.LocalTimes = LocalTimes()
>>
>>
>>    mainWin = TestApp()
>>
>>    app = Application()
>>
>>    app.Resources.Add('collection', LocalTimes())
>>
>>    app.Run(mainWin.Root)
>>
>>
>>    >>
>>
>>    << DataBinding_20081102.xaml - GUI Window
>>
>>
>>    <Window
>>    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>>
>>        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>>
>>        Title="Hello World!" Height="300" Width="300">
>>
>>          <Window.Resources>
>>
>>                <ObjectDataProvider x:Key="localTimes"
>>    ObjectType="{x:Type LocalTimes}"/>
>>
>>          </Window.Resources>
>>
>>          <Grid>
>>
>>          </Grid>
>>
>>    </Window>
>>
>>
>>    >>
>>
>>    << LocalTimes.cs - Custom C# Class - LocalTimes
>>
>>
>>    using System;
>>
>>    using System.Collections;
>>
>>    using System.Collections.Generic;
>>
>>
>>    public class LocalTimes : List<LocalTime> {
>>
>>
>>          public LocalTimes() {
>>
>>                this.Add(new LocalTime("New York", DateTime.Now));
>>
>>                this.Add(new LocalTime("Chicago",
>>    DateTime.Now.AddHours(-1)));
>>
>>                this.Add(new LocalTime("Denver",
>>    DateTime.Now.AddHours(-2)));
>>
>>                this.Add(new LocalTime("Los Angeles",
>>    DateTime.Now.AddHours(-3)));
>>
>>          }
>>
>>    }
>>
>>
>>    public class LocalTime {
>>
>>
>>          private string place;
>>
>>          private DateTime time;
>>
>>
>>          public LocalTime(string _place, DateTime _time) {
>>
>>
>>                place = _place;
>>
>>                time = _time;
>>
>>          }
>>
>>
>>          public DateTime Time {
>>
>>                get { return time; }
>>
>>                set { time = value; }
>>
>>          }
>>
>>
>>          public string Place {
>>
>>
>>                get { return place; }
>>
>>          }
>>
>>    }
>>
>>
>>    >>
>>
>>    Interpreter Output from the above files:
>>
>>
>>      File C:\Users\Rob
>>    Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line
>>    23, in Initialize
>>
>>      File C:\Users\Rob
>>    Oakes\AppData\IronPython\IPy-Tutorial\TestApp_20081102.py, line
>>    20, in __init__
>>
>>      File , line 0, in Load##106
>>
>>      File PresentationFramework, line unknown, in Load
>>
>>      File PresentationFramework, line unknown, in XmlTreeBuildDefault
>>
>>      File PresentationFramework, line unknown, in Parse
>>
>>      File PresentationFramework, line unknown, in ParseFragment
>>
>>      File PresentationFramework, line unknown, in _Parse
>>
>>      File PresentationFramework, line unknown, in ReadXaml
>>
>>      File PresentationFramework, line unknown, in Read
>>
>>    SystemError: Type reference cannot find public type named
>>    'LocalTimes'.
>>
>>
>>    _______________________________________________
>>    Users mailing list
>>    Users at lists.ironpython.com <mailto: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
>>
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081104/478a9c9b/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov  4 14:35:44 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 04 Nov 2008 13:35:44 +0000
Subject: [IronPython] [Python-Dev] Fwd: Removal of GIL through
	refcounting removal.
In-Reply-To: <e6511dbf0811031811i7d18fa2w7782a9d99666e3b4@mail.gmail.com>
References: <392528d30810300855g33b8130flc3098f81700bab08@mail.gmail.com>	<gedmtg$eop$1@ger.gmane.org>
	<490AA4B9.5060307@gmail.com>	<76fd5acf0810310459v625e4b48u1e9a64a7057309e5@mail.gmail.com>	<490B0584.7080006@voidspace.org.uk>	<4222a8490810310703i6058fbf1j1b4f9dea511d3b77@mail.gmail.com>	<loom.20081102T180853-494@post.gmane.org>	<18702.15638.223872.706216@montanaro-dyndns-org.local>	<e6511dbf0811031050w3383d56dgc110377a801f333d@mail.gmail.com>	<d2155e360811031059x26245c8ei7c0fe96e53deffaa@mail.gmail.com>
	<e6511dbf0811031811i7d18fa2w7782a9d99666e3b4@mail.gmail.com>
Message-ID: <49104FB0.6090502@voidspace.org.uk>

Josiah Carlson wrote:
> On Mon, Nov 3, 2008 at 10:59 AM, Curt Hagenlocher 
> <curt at hagenlocher.org <mailto:curt at hagenlocher.org>> wrote:
>
>     On Mon, Nov 3, 2008 at 11:50 AM, Josiah Carlson
>     <josiah.carlson at gmail.com <mailto:josiah.carlson at gmail.com>> wrote:
>
>         On Sun, Nov 2, 2008 at 3:51 PM, <skip at pobox.com
>         <mailto:skip at pobox.com>> wrote:
>
>
>                Antoine> I think it is important to remind that the GIL
>             doesn't prevent
>                Antoine> (almost) true multithreading. The only thing
>             it prevents is
>                Antoine> full use of multi-CPU resources in a single
>             process.
>
>             I believe everyone here knows that.  I believe what most
>             people are
>             clamoring for is to make "full use of their multi-CPU
>             resources in a single
>             process".
>
>
>         Which is, arguably, silly.  As we've seen in the last 2 months
>         with Chrome, multiple processes for a single "program" is
>         actually a pretty good idea.  With the multiprocessing module
>         in the standard library offering a threading-like interface,
>         people no longer have any excuses for not fully exploiting
>         their multiple cores in Python.
>
>      
>     There is no shortage of algorithms (such as matrix multiplication)
>     that are parallelizable but not particularly good candidates for
>     an IPC-based multiprocessing paradigm.
>
>
> Ahh, but those algorithms aren't going to be written in Python; they 
> are going to be written in C, and are going to manipulate memory 
> directly.  With such things, you can use standard Python threads, call 
> into your C runtime, and release the GIL.  Alternatively, you can use 
> the mmap module to store your data, shared across multiple processes, 
> using the same direct-memory access as you would with multiple threads 
> and GIL release.

That's only one example of an algorithm where IPC isn't suitable. And 
you're right, anyone with this kind of use case is just not going to use 
Python. That isn't a good thing.

Michael Foord

>
> Also, most local-only communications primitives (named pipes, 
> anonymous pipes, unix domain sockets, ...) use zero/one copy 
> implementations, so as long as your RPC isn't slow, you can do pretty 
> well even on the Python side (especially if you pre-allocate your 
> receive buffer, and fill in the data as you receive it; this is pretty 
> much what mutablebytes was created for, now we just need a proper 
> memoryview).
>
> So again, I claim that not using multiple processes for your 
> multi-core machine in order to use your multiple cores to their full 
> extent is silly.  As an aside, Python array.array() instances have a 
> char* and length, so if you are careful, you can create an array.array 
> object from an mmap pointer, and get fairly decent performance even in 
> Python with shared memory.  Someone should probably look into allowing 
> array.array() to take a read/readwrite memoryview as an argument to 
> support such things, as well as allowing mmaps to be passed via 
> multiprocessing (if they aren't already supported).
>
>  - Josiah 
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From xkenneth at gmail.com  Tue Nov  4 15:45:30 2008
From: xkenneth at gmail.com (Kenneth Miller)
Date: Tue, 4 Nov 2008 08:45:30 -0600
Subject: [IronPython] Loading Python modules from Silverlight Isolated
	Storage
In-Reply-To: <49102705.9020305@voidspace.org.uk>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>
	<49102705.9020305@voidspace.org.uk>
Message-ID: <24BA5F35-652B-400C-89E1-61A4B969D716@gmail.com>

All,

The problem is illustrated here:

This code will work properly:

http://paste.pocoo.org/show/90071/

This code produces an error:

http://paste.pocoo.org/show/90072/

Regards,
Ken

On Nov 4, 2008, at 4:42 AM, Michael Foord wrote:

> Kenneth Miller wrote:
>> It was proven to me that while exec might work for simple cases,  
>> more advanced usage (declaring a lambda function inside an exec)  
>> can be problematic. It was advised that I generate python modules  
>> and dynamically import them. If memory served me, it's not possible  
>> to import a module from a string object.
>>
> I have often generated (or loaded code into a string) and then  
> exec'd it into a module dict to create modules at runtime. It is a  
> relatively normal technique in Python.
>
> Michael
>
>> Thanks.
>>
>> - Ken
>>
>> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher"  
>> <curt at hagenlocher.org <mailto:curt at hagenlocher.org>> wrote:
>>
>>> You should be able to do this all in-memory:
>>>
>>> >>> import sys
>>> >>> foo = type(sys)('foo')
>>> >>> sys.modules['foo'] = foo
>>> >>> exec 'a = 1' in foo.__dict__
>>> >>> foo.a
>>> 1
>>> >>>
>>>
>>> There's probably a better ("more Pythonic") way to do this, but  
>>> I'm sleepy...
>>>
>>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller  
>>> <xkenneth at gmail.com <mailto:xkenneth at gmail.com>> wrote:
>>>
>>>    All,
>>>
>>>      Is it possible to have python load modules from the silverlight
>>>    isolated storage? My app needs to dynamically generate and import
>>>    python code to run.
>>>
>>>    Regards,
>>>    Ken
>>>    _______________________________________________
>>>    Users mailing list
>>>    Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com <mailto: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
>>
>
>
> -- 
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081104/a954e797/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov  4 15:47:28 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 04 Nov 2008 14:47:28 +0000
Subject: [IronPython] Loading Python modules from Silverlight Isolated
 Storage
In-Reply-To: <24BA5F35-652B-400C-89E1-61A4B969D716@gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>	<49102705.9020305@voidspace.org.uk>
	<24BA5F35-652B-400C-89E1-61A4B969D716@gmail.com>
Message-ID: <49106080.3040104@voidspace.org.uk>

Kenneth Miller wrote:
> All,
>
> The problem is illustrated here:
>
> This code will work properly:
>
> http://paste.pocoo.org/show/90071/
>
> This code produces an error:
>
> http://paste.pocoo.org/show/90072/

Different issue. Exec'ing explicitly inside a namespace avoids that 
problem altogether.

Michael

>
> Regards,
> Ken
>
> On Nov 4, 2008, at 4:42 AM, Michael Foord wrote:
>
>> Kenneth Miller wrote:
>>> It was proven to me that while exec might work for simple cases, 
>>> more advanced usage (declaring a lambda function inside an exec) can 
>>> be problematic. It was advised that I generate python modules and 
>>> dynamically import them. If memory served me, it's not possible to 
>>> import a module from a string object.
>>>
>> I have often generated (or loaded code into a string) and then exec'd 
>> it into a module dict to create modules at runtime. It is a 
>> relatively normal technique in Python.
>>
>> Michael
>>
>>> Thanks.
>>>
>>> - Ken
>>>
>>> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher" 
>>> <curt at hagenlocher.org <mailto:curt at hagenlocher.org> 
>>> <mailto:curt at hagenlocher.org>> wrote:
>>>
>>>> You should be able to do this all in-memory:
>>>>
>>>> >>> import sys
>>>> >>> foo = type(sys)('foo')
>>>> >>> sys.modules['foo'] = foo
>>>> >>> exec 'a = 1' in foo.__dict__
>>>> >>> foo.a
>>>> 1
>>>> >>>
>>>>
>>>> There's probably a better ("more Pythonic") way to do this, but I'm 
>>>> sleepy...
>>>>
>>>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com 
>>>> <mailto:xkenneth at gmail.com> <mailto:xkenneth at gmail.com>> wrote:
>>>>
>>>>    All,
>>>>
>>>>      Is it possible to have python load modules from the silverlight
>>>>    isolated storage? My app needs to dynamically generate and import
>>>>    python code to run.
>>>>
>>>>    Regards,
>>>>    Ken
>>>>    _______________________________________________
>>>>    Users mailing list
>>>>    Users at lists.ironpython.com <mailto:Users at lists.ironpython.com> 
>>>> <mailto:Users at lists.ironpython.com>
>>>>    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com> 
>>>> <mailto:Users at lists.ironpython.com>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>  
>>
>>
>> -- 
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> 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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From xkenneth at gmail.com  Tue Nov  4 15:53:23 2008
From: xkenneth at gmail.com (Kenneth Miller)
Date: Tue, 4 Nov 2008 08:53:23 -0600
Subject: [IronPython] Loading Python modules from Silverlight Isolated
	Storage
In-Reply-To: <49106080.3040104@voidspace.org.uk>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>	<49102705.9020305@voidspace.org.uk>
	<24BA5F35-652B-400C-89E1-61A4B969D716@gmail.com>
	<49106080.3040104@voidspace.org.uk>
Message-ID: <03080830-52F4-4E3E-92C3-98CA00EE14A9@gmail.com>

Thanks for the reply.

Would you mind elaborating?

Regards,
Ken

On Nov 4, 2008, at 8:47 AM, Michael Foord wrote:

> Kenneth Miller wrote:
>> All,
>>
>> The problem is illustrated here:
>>
>> This code will work properly:
>>
>> http://paste.pocoo.org/show/90071/
>>
>> This code produces an error:
>>
>> http://paste.pocoo.org/show/90072/
>
> Different issue. Exec'ing explicitly inside a namespace avoids that  
> problem altogether.
>
> Michael
>
>>
>> Regards,
>> Ken
>>
>> On Nov 4, 2008, at 4:42 AM, Michael Foord wrote:
>>
>>> Kenneth Miller wrote:
>>>> It was proven to me that while exec might work for simple cases,  
>>>> more advanced usage (declaring a lambda function inside an exec)  
>>>> can be problematic. It was advised that I generate python modules  
>>>> and dynamically import them. If memory served me, it's not  
>>>> possible to import a module from a string object.
>>>>
>>> I have often generated (or loaded code into a string) and then  
>>> exec'd it into a module dict to create modules at runtime. It is a  
>>> relatively normal technique in Python.
>>>
>>> Michael
>>>
>>>> Thanks.
>>>>
>>>> - Ken
>>>>
>>>> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher" <curt at hagenlocher.org 
>>>>  <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org>>  
>>>> wrote:
>>>>
>>>>> You should be able to do this all in-memory:
>>>>>
>>>>> >>> import sys
>>>>> >>> foo = type(sys)('foo')
>>>>> >>> sys.modules['foo'] = foo
>>>>> >>> exec 'a = 1' in foo.__dict__
>>>>> >>> foo.a
>>>>> 1
>>>>> >>>
>>>>>
>>>>> There's probably a better ("more Pythonic") way to do this, but  
>>>>> I'm sleepy...
>>>>>
>>>>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller <xkenneth at gmail.com 
>>>>>  <mailto:xkenneth at gmail.com> <mailto:xkenneth at gmail.com>> wrote:
>>>>>
>>>>>   All,
>>>>>
>>>>>     Is it possible to have python load modules from the  
>>>>> silverlight
>>>>>   isolated storage? My app needs to dynamically generate and  
>>>>> import
>>>>>   python code to run.
>>>>>
>>>>>   Regards,
>>>>>   Ken
>>>>>   _______________________________________________
>>>>>   Users mailing list
>>>>>   Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>  
>>>>> <mailto:Users at lists.ironpython.com>
>>>>>   http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com> <mailto:Users at lists.ironpython.com 
>>>>> >
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>
>>>
>>> -- 
>>> http://www.ironpythoninaction.com/
>>> http://www.voidspace.org.uk/blog
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> -- 
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081104/2e43618e/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov  4 16:11:40 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 04 Nov 2008 15:11:40 +0000
Subject: [IronPython] Loading Python modules from Silverlight Isolated
 Storage
In-Reply-To: <03080830-52F4-4E3E-92C3-98CA00EE14A9@gmail.com>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>	<49102705.9020305@voidspace.org.uk>	<24BA5F35-652B-400C-89E1-61A4B969D716@gmail.com>	<49106080.3040104@voidspace.org.uk>
	<03080830-52F4-4E3E-92C3-98CA00EE14A9@gmail.com>
Message-ID: <4910662C.6020404@voidspace.org.uk>

Kenneth Miller wrote:
> Thanks for the reply.
>
> Would you mind elaborating?
Execing explicitly in locals solves the problem for Python 2.6:

 >>> def f():
...   a = 1
...   exec 'g = lambda: a' in locals()
...   return g
...
 >>> g = f()
 >>> g()
1
 >>>

I don't think this would work in Python 3.0 though.

See this discussion on Python-dev for some of the issues:

http://mail.python.org/pipermail/python-dev/2008-October/082938.html

Michael

>
> Regards,
> Ken
>
> On Nov 4, 2008, at 8:47 AM, Michael Foord wrote:
>
>> Kenneth Miller wrote:
>>> All,
>>>
>>> The problem is illustrated here:
>>>
>>> This code will work properly:
>>>
>>> http://paste.pocoo.org/show/90071/
>>>
>>> This code produces an error:
>>>
>>> http://paste.pocoo.org/show/90072/
>>
>> Different issue. Exec'ing explicitly inside a namespace avoids that 
>> problem altogether.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Ken
>>>
>>> On Nov 4, 2008, at 4:42 AM, Michael Foord wrote:
>>>
>>>> Kenneth Miller wrote:
>>>>> It was proven to me that while exec might work for simple cases, 
>>>>> more advanced usage (declaring a lambda function inside an exec) 
>>>>> can be problematic. It was advised that I generate python modules 
>>>>> and dynamically import them. If memory served me, it's not 
>>>>> possible to import a module from a string object.
>>>>>
>>>> I have often generated (or loaded code into a string) and then 
>>>> exec'd it into a module dict to create modules at runtime. It is a 
>>>> relatively normal technique in Python.
>>>>
>>>> Michael
>>>>
>>>>> Thanks.
>>>>>
>>>>> - Ken
>>>>>
>>>>> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher" 
>>>>> <curt at hagenlocher.org <mailto:curt at hagenlocher.org> 
>>>>> <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org>> wrote:
>>>>>
>>>>>> You should be able to do this all in-memory:
>>>>>>
>>>>>> >>> import sys
>>>>>> >>> foo = type(sys)('foo')
>>>>>> >>> sys.modules['foo'] = foo
>>>>>> >>> exec 'a = 1' in foo.__dict__
>>>>>> >>> foo.a
>>>>>> 1
>>>>>> >>>
>>>>>>
>>>>>> There's probably a better ("more Pythonic") way to do this, but 
>>>>>> I'm sleepy...
>>>>>>
>>>>>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller 
>>>>>> <xkenneth at gmail.com <mailto:xkenneth at gmail.com> 
>>>>>> <mailto:xkenneth at gmail.com> <mailto:xkenneth at gmail.com>> wrote:
>>>>>>
>>>>>>   All,
>>>>>>
>>>>>>     Is it possible to have python load modules from the silverlight
>>>>>>   isolated storage? My app needs to dynamically generate and import
>>>>>>   python code to run.
>>>>>>
>>>>>>   Regards,
>>>>>>   Ken
>>>>>>   _______________________________________________
>>>>>>   Users mailing list
>>>>>>   Users at lists.ironpython.com <mailto:Users at lists.ironpython.com> 
>>>>>> <mailto:Users at lists.ironpython.com> 
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>>   http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com> 
>>>>>> <mailto:Users at lists.ironpython.com> 
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com> 
>>>>> <mailto:Users at lists.ironpython.com>
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>>
>>>>
>>>> -- 
>>>> http://www.ironpythoninaction.com/
>>>> http://www.voidspace.org.uk/blog
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>  
>>
>>
>> -- 
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> 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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From dinov at microsoft.com  Tue Nov  4 18:24:40 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 4 Nov 2008 09:24:40 -0800
Subject: [IronPython] Loading Python modules from Silverlight Isolated
 Storage
In-Reply-To: <4910662C.6020404@voidspace.org.uk>
References: <1760EAC0-917E-476A-A777-1DBF188AA6AD@gmail.com>
	<d2155e360811032245i266dfe7u9c962689db42af2c@mail.gmail.com>
	<1E6C3093-AFB0-4B81-B12F-660D5B24E92D@gmail.com>
	<49102705.9020305@voidspace.org.uk>
	<24BA5F35-652B-400C-89E1-61A4B969D716@gmail.com>
	<49106080.3040104@voidspace.org.uk>
	<03080830-52F4-4E3E-92C3-98CA00EE14A9@gmail.com>
	<4910662C.6020404@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC23554FF72675B1@NA-EXMSG-C102.redmond.corp.microsoft.com>

Another option, assuming it's possible, would be to exec the function definition as well as the lambda.

Also I would expect exec ... in locals() would work the same as "in dict(locals())".  Which might also be problematic if you expect to see changes in the closure:

def f():
    a = 1
    d = dict(locals())
    g = lambda: a
    #exec 'g = lambda: a' in d
    #print d['g']()
    print g()
    a = 2
    #print d['g']()
    print g()

But bringing this back to the original problem - trying to provide storage for modules.  There I don't think this should be a problem.  Modules don't have an outer function body to mess up the closure semantics so if you really want just plain old module semantics creating a module and execing some code in its dictionary should always give you the right behavior.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, November 04, 2008 7:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Loading Python modules from Silverlight Isolated Storage

Kenneth Miller wrote:
> Thanks for the reply.
>
> Would you mind elaborating?
Execing explicitly in locals solves the problem for Python 2.6:

 >>> def f():
...   a = 1
...   exec 'g = lambda: a' in locals()
...   return g
...
 >>> g = f()
 >>> g()
1
 >>>

I don't think this would work in Python 3.0 though.

See this discussion on Python-dev for some of the issues:

http://mail.python.org/pipermail/python-dev/2008-October/082938.html

Michael

>
> Regards,
> Ken
>
> On Nov 4, 2008, at 8:47 AM, Michael Foord wrote:
>
>> Kenneth Miller wrote:
>>> All,
>>>
>>> The problem is illustrated here:
>>>
>>> This code will work properly:
>>>
>>> http://paste.pocoo.org/show/90071/
>>>
>>> This code produces an error:
>>>
>>> http://paste.pocoo.org/show/90072/
>>
>> Different issue. Exec'ing explicitly inside a namespace avoids that
>> problem altogether.
>>
>> Michael
>>
>>>
>>> Regards,
>>> Ken
>>>
>>> On Nov 4, 2008, at 4:42 AM, Michael Foord wrote:
>>>
>>>> Kenneth Miller wrote:
>>>>> It was proven to me that while exec might work for simple cases,
>>>>> more advanced usage (declaring a lambda function inside an exec)
>>>>> can be problematic. It was advised that I generate python modules
>>>>> and dynamically import them. If memory served me, it's not
>>>>> possible to import a module from a string object.
>>>>>
>>>> I have often generated (or loaded code into a string) and then
>>>> exec'd it into a module dict to create modules at runtime. It is a
>>>> relatively normal technique in Python.
>>>>
>>>> Michael
>>>>
>>>>> Thanks.
>>>>>
>>>>> - Ken
>>>>>
>>>>> On Nov 4, 2008, at 12:45 AM, "Curt Hagenlocher"
>>>>> <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>>>> <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org>> wrote:
>>>>>
>>>>>> You should be able to do this all in-memory:
>>>>>>
>>>>>> >>> import sys
>>>>>> >>> foo = type(sys)('foo')
>>>>>> >>> sys.modules['foo'] = foo
>>>>>> >>> exec 'a = 1' in foo.__dict__
>>>>>> >>> foo.a
>>>>>> 1
>>>>>> >>>
>>>>>>
>>>>>> There's probably a better ("more Pythonic") way to do this, but
>>>>>> I'm sleepy...
>>>>>>
>>>>>> On Mon, Nov 3, 2008 at 11:40 PM, Kenneth Miller
>>>>>> <xkenneth at gmail.com <mailto:xkenneth at gmail.com>
>>>>>> <mailto:xkenneth at gmail.com> <mailto:xkenneth at gmail.com>> wrote:
>>>>>>
>>>>>>   All,
>>>>>>
>>>>>>     Is it possible to have python load modules from the silverlight
>>>>>>   isolated storage? My app needs to dynamically generate and import
>>>>>>   python code to run.
>>>>>>
>>>>>>   Regards,
>>>>>>   Ken
>>>>>>   _______________________________________________
>>>>>>   Users mailing list
>>>>>>   Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>>   http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> <mailto:Users at lists.ironpython.com>
>>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>> <mailto:Users at lists.ironpython.com>
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.ironpythoninaction.com/
>>>> http://www.voidspace.org.uk/blog
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>
>>
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> 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
>


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


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


From Marty.Nelson at symyx.com  Tue Nov  4 21:02:03 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Tue, 4 Nov 2008 12:02:03 -0800
Subject: [IronPython] How do I test if a variable is defined?
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>


How do I test in Iron Python (in python) if a variable is defined?



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081104/fd16d025/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov  4 21:06:19 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 04 Nov 2008 20:06:19 +0000
Subject: [IronPython] How do I test if a variable is defined?
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <4910AB3B.6020708@voidspace.org.uk>

Marty Nelson wrote:
>
> How do I test in Iron Python (in python) if a variable is defined?
>
'name' in locals() or 'name' in globals()


try:
    name
except NameError:
    # variable 'name' is not defined

The second idiom is actually fairly common.

All the best,

Michael

> =======
> Notice: This e-mail message, together with any attachments, contains
> information of Symyx Technologies, Inc. or any of its affiliates or
> subsidiaries that may be confidential, proprietary, copyrighted,
> privileged and/or protected work product, and is meant solely for
> the intended recipient. If you are not the intended recipient, and
> have received this message in error, please contact the sender
> immediately, permanently delete the original and any copies of this
> email and any attachments thereto.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From tony.meyer at gmail.com  Wed Nov  5 00:32:45 2008
From: tony.meyer at gmail.com (Tony Meyer)
Date: Wed, 5 Nov 2008 11:32:45 +1200
Subject: [IronPython] How do I test if a variable is defined?
In-Reply-To: <4910AB3B.6020708@voidspace.org.uk>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>
	<4910AB3B.6020708@voidspace.org.uk>
Message-ID: <6c63de570811041532p1d893e7x4302abc3b18b96a8@mail.gmail.com>

On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Marty Nelson wrote:
>>
>> How do I test in Iron Python (in python) if a variable is defined?
>>
[...]
> try:
>   name
> except NameError:
>   # variable 'name' is not defined

If you're running some sort of checker (pylint, pychecker) over this,
you might get a warning about the "name" line not doing anything.  To
avoid that, you'll sometimes see a variant like this:

try:
    unused = name
except NameError:
    # variable 'name' is not defined.

Cheers,
Tony


From fuzzyman at voidspace.org.uk  Wed Nov  5 11:07:51 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 05 Nov 2008 10:07:51 +0000
Subject: [IronPython] How do I test if a variable is defined?
In-Reply-To: <6c63de570811041532p1d893e7x4302abc3b18b96a8@mail.gmail.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>	<4910AB3B.6020708@voidspace.org.uk>
	<6c63de570811041532p1d893e7x4302abc3b18b96a8@mail.gmail.com>
Message-ID: <49117077.3090102@voidspace.org.uk>

Tony Meyer wrote:
> On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>   
>> Marty Nelson wrote:
>>     
>>> How do I test in Iron Python (in python) if a variable is defined?
>>>
>>>       
> [...]
>   
>> try:
>>   name
>> except NameError:
>>   # variable 'name' is not defined
>>     
>
> If you're running some sort of checker (pylint, pychecker) over this,
> you might get a warning about the "name" line not doing anything.  To
> avoid that, you'll sometimes see a variant like this:
>
> try:
>     unused = name
> except NameError:
>     # variable 'name' is not defined.
>   

Except then PyLint will complain that 'unused' is unused, plus you code 
no longer accurately conveys its intent.

I prefer to filter (or disable) that particular warning rather than 
change the code.

Michael

> Cheers,
> Tony
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/



From william at resolversystems.com  Wed Nov  5 13:57:37 2008
From: william at resolversystems.com (William Reade)
Date: Wed, 05 Nov 2008 12:57:37 +0000
Subject: [IronPython] Ironclad problem,
	with which someone here may be able to help
Message-ID: <49119841.3000304@resolversystems.com>

Hi all

While running the numpy tests, I've come across a situation which, to 
the best of my knowledge, is simply impossible. I'm hoping that one of 
the local .NET gurus will be able to tell me what I'm missing, or point 
me somewhere I can get more insight.

The 4 methods involved are as follows:
-----------------------
        public int GetThreadId()
        {
            return Thread.CurrentThread.ManagedThreadId;
        }

        public void WriteFlush(string info)
        {
            Console.WriteLine(info);
            Console.Out.Flush();
        }

        public void EnsureGIL()
        {
            Monitor.Enter(this.dispatcherLock);
            this.WriteFlush(String.Format(
                "EnsureGIL ({1}) {0}", this.GetThreadId(), 
Builtin.id(this.dispatcherLock)));
        }

        public void ReleaseGIL()
        {
            this.WriteFlush(String.Format(
                "ReleaseGIL ({1}) {0}\n", this.GetThreadId(), 
Builtin.id(this.dispatcherLock)));
            Monitor.Exit(this.dispatcherLock);
        }
-----------------------
...and they can, and do, occasionally produce output as follows:
-----------------------
EnsureGIL (443) 2
EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
ReleaseGIL (443) 2

EnsureGIL (443) 2
ReleaseGIL (443) 1

ReleaseGIL (443) 2
-----------------------
When this happens, the process continues happily for a short time and 
then falls over in a later call to ReleaseGIL (after successfully 
calling it several times). The error is " Object synchronization method 
was called from an unsynchronized block of code", which I understand to 
mean "you can't release this lock because you don't hold it".

It doesn't happen very often, but I can usually reproduce it by running 
test_multiarray.TestFromToFile.test_malformed a few hundred times. It 
may be relevant to note that thread 2 is the GC thread, and thread 1 is 
the main thread. I have considered the following possibilities:

(1) That I'm locking on the wrong object. I believe that isn't the case, 
because it's constructed only once, as a "new Object()" (ie, a reference 
type), and is only subsequently used for locking; and, because it keeps 
the same ipy id throughout.

(2) That Monitor.Enter occasionally allows two different threads to 
acquire the same lock. I consider this extremely unlikely, because... 
well, how many multithreaded .NET apps already exist? If Monitor really 
were broken, I think we'd probably know about it by now.

(3) That calling Flush() on a SyncTextWriter (the type of Console.Out) 
doesn't actually do anything, and the output is somehow wrongly ordered 
(although I can't imagine how this could actually be: if the locking is 
really working, then my console writes are strictly sequential). I don't 
have access to the code, so I have no idea how it's implemented, but 
even if this is the case it doesn't help much with the fundamental 
problem (the synchronisation error which follows).

Apart from the above, I'm out of ideas. Can anyone suggest what I've missed?

William


From william at resolversystems.com  Wed Nov  5 15:38:59 2008
From: william at resolversystems.com (William Reade)
Date: Wed, 05 Nov 2008 14:38:59 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <49119841.3000304@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
Message-ID: <4911B003.1020300@resolversystems.com>

Incidentally, logging a Stopwatch timestamp in WriteFlush reveals that, 
yes, the calls really are happening in the order they appear to be. So, 
option (3) appears to be a red herring, and options (1) and (2) remain 
unchanged.

William Reade wrote:
> Hi all
>
> While running the numpy tests, I've come across a situation which, to 
> the best of my knowledge, is simply impossible. I'm hoping that one of 
> the local .NET gurus will be able to tell me what I'm missing, or 
> point me somewhere I can get more insight.
>
> The 4 methods involved are as follows:
> -----------------------
>        public int GetThreadId()
>        {
>            return Thread.CurrentThread.ManagedThreadId;
>        }
>
>        public void WriteFlush(string info)
>        {
>            Console.WriteLine(info);
>            Console.Out.Flush();
>        }
>
>        public void EnsureGIL()
>        {
>            Monitor.Enter(this.dispatcherLock);
>            this.WriteFlush(String.Format(
>                "EnsureGIL ({1}) {0}", this.GetThreadId(), 
> Builtin.id(this.dispatcherLock)));
>        }
>
>        public void ReleaseGIL()
>        {
>            this.WriteFlush(String.Format(
>                "ReleaseGIL ({1}) {0}\n", this.GetThreadId(), 
> Builtin.id(this.dispatcherLock)));
>            Monitor.Exit(this.dispatcherLock);
>        }
> -----------------------
> ...and they can, and do, occasionally produce output as follows:
> -----------------------
> EnsureGIL (443) 2
> EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
> ReleaseGIL (443) 2
>
> EnsureGIL (443) 2
> ReleaseGIL (443) 1
>
> ReleaseGIL (443) 2
> -----------------------
> When this happens, the process continues happily for a short time and 
> then falls over in a later call to ReleaseGIL (after successfully 
> calling it several times). The error is " Object synchronization 
> method was called from an unsynchronized block of code", which I 
> understand to mean "you can't release this lock because you don't hold 
> it".
>
> It doesn't happen very often, but I can usually reproduce it by 
> running test_multiarray.TestFromToFile.test_malformed a few hundred 
> times. It may be relevant to note that thread 2 is the GC thread, and 
> thread 1 is the main thread. I have considered the following 
> possibilities:
>
> (1) That I'm locking on the wrong object. I believe that isn't the 
> case, because it's constructed only once, as a "new Object()" (ie, a 
> reference type), and is only subsequently used for locking; and, 
> because it keeps the same ipy id throughout.
>
> (2) That Monitor.Enter occasionally allows two different threads to 
> acquire the same lock. I consider this extremely unlikely, because... 
> well, how many multithreaded .NET apps already exist? If Monitor 
> really were broken, I think we'd probably know about it by now.
>
> (3) That calling Flush() on a SyncTextWriter (the type of Console.Out) 
> doesn't actually do anything, and the output is somehow wrongly 
> ordered (although I can't imagine how this could actually be: if the 
> locking is really working, then my console writes are strictly 
> sequential). I don't have access to the code, so I have no idea how 
> it's implemented, but even if this is the case it doesn't help much 
> with the fundamental problem (the synchronisation error which follows).
>
> Apart from the above, I'm out of ideas. Can anyone suggest what I've 
> missed?
>
> William
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



From xkenneth at gmail.com  Wed Nov  5 16:46:28 2008
From: xkenneth at gmail.com (Kenneth Miller)
Date: Wed, 5 Nov 2008 09:46:28 -0600
Subject: [IronPython] How do I test if a variable is defined?
In-Reply-To: <49117077.3090102@voidspace.org.uk>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>	<4910AB3B.6020708@voidspace.org.uk>
	<6c63de570811041532p1d893e7x4302abc3b18b96a8@mail.gmail.com>
	<49117077.3090102@voidspace.org.uk>
Message-ID: <1EA7F3E8-F917-411F-99F3-901A8A0ABE7E@gmail.com>

Can't you just do..

'variable_name' in locals()

or

'variable_name' in dir()

Regards,
Ken

On Nov 5, 2008, at 4:07 AM, Michael Foord wrote:

> Tony Meyer wrote:
>> On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord <fuzzyman at voidspace.org.uk 
>> > wrote:
>>
>>> Marty Nelson wrote:
>>>
>>>> How do I test in Iron Python (in python) if a variable is defined?
>>>>
>>>>
>> [...]
>>
>>> try:
>>>  name
>>> except NameError:
>>>  # variable 'name' is not defined
>>>
>>
>> If you're running some sort of checker (pylint, pychecker) over this,
>> you might get a warning about the "name" line not doing anything.  To
>> avoid that, you'll sometimes see a variant like this:
>>
>> try:
>>    unused = name
>> except NameError:
>>    # variable 'name' is not defined.
>>
>
> Except then PyLint will complain that 'unused' is unused, plus you  
> code no longer accurately conveys its intent.
>
> I prefer to filter (or disable) that particular warning rather than  
> change the code.
>
> Michael
>
>> Cheers,
>> Tony
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
> -- 
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/b8bb94de/attachment.html>

From michael.foord at resolversystems.com  Wed Nov  5 17:03:25 2008
From: michael.foord at resolversystems.com (Michael Foord)
Date: Wed, 05 Nov 2008 16:03:25 +0000
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)
Message-ID: <4911C3CD.8010805@resolversystems.com>

Hello Guys,

Discovered a bug in indexing Python objects in IronPython 2.

The following code:

class X(object):
    def __setitem__(self, key, value):
        print repr(key)

def f(a, b):
    X()[a, b] = object()
   
f(1, 2)
f('one', 'two')

Produces the following exception:

Traceback (most recent call last):
  File "bugtest.py", line 9, in bugtest.py
  File "bugtest.py", line 6, in f
TypeError: Specified cast is not valid.

It looks like IronPython has a call site that is now expecting integers 
the second time round.

Switching to using explicit tuples for indexing works around the problem:

    X()[(a, b)] = object()

However this kind of indexing is an *extremely* common way to use our 
spreadsheet API from user code, so we couldn't release with this bug in 
place.

(Doing the indexing outside of the function also avoids the problem 
interestingly enough.)

All the best,

Michael Foord

-- 

Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
michael.foord at resolversystems.com
+44 (0) 20 7253 6372

Try out Resolver One! <http://www.resolversystems.com/get-it/>

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK 



From curt at hagenlocher.org  Wed Nov  5 17:37:11 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 5 Nov 2008 09:37:11 -0700
Subject: [IronPython] Ironclad problem,
	with which someone here may be able to help
In-Reply-To: <49119841.3000304@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
Message-ID: <d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>

So, the obvious question for me is whether or not you're using any
finalizers.

On Wed, Nov 5, 2008 at 5:57 AM, William Reade
<william at resolversystems.com>wrote:

> Hi all
>
> While running the numpy tests, I've come across a situation which, to the
> best of my knowledge, is simply impossible. I'm hoping that one of the local
> .NET gurus will be able to tell me what I'm missing, or point me somewhere I
> can get more insight.
>
> The 4 methods involved are as follows:
> -----------------------
>       public int GetThreadId()
>       {
>           return Thread.CurrentThread.ManagedThreadId;
>       }
>
>       public void WriteFlush(string info)
>       {
>           Console.WriteLine(info);
>           Console.Out.Flush();
>       }
>
>       public void EnsureGIL()
>       {
>           Monitor.Enter(this.dispatcherLock);
>           this.WriteFlush(String.Format(
>               "EnsureGIL ({1}) {0}", this.GetThreadId(),
> Builtin.id(this.dispatcherLock)));
>       }
>
>       public void ReleaseGIL()
>       {
>           this.WriteFlush(String.Format(
>               "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
> Builtin.id(this.dispatcherLock)));
>           Monitor.Exit(this.dispatcherLock);
>       }
> -----------------------
> ...and they can, and do, occasionally produce output as follows:
> -----------------------
> EnsureGIL (443) 2
> EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
> ReleaseGIL (443) 2
>
> EnsureGIL (443) 2
> ReleaseGIL (443) 1
>
> ReleaseGIL (443) 2
> -----------------------
> When this happens, the process continues happily for a short time and then
> falls over in a later call to ReleaseGIL (after successfully calling it
> several times). The error is " Object synchronization method was called from
> an unsynchronized block of code", which I understand to mean "you can't
> release this lock because you don't hold it".
>
> It doesn't happen very often, but I can usually reproduce it by running
> test_multiarray.TestFromToFile.test_malformed a few hundred times. It may be
> relevant to note that thread 2 is the GC thread, and thread 1 is the main
> thread. I have considered the following possibilities:
>
> (1) That I'm locking on the wrong object. I believe that isn't the case,
> because it's constructed only once, as a "new Object()" (ie, a reference
> type), and is only subsequently used for locking; and, because it keeps the
> same ipy id throughout.
>
> (2) That Monitor.Enter occasionally allows two different threads to acquire
> the same lock. I consider this extremely unlikely, because... well, how many
> multithreaded .NET apps already exist? If Monitor really were broken, I
> think we'd probably know about it by now.
>
> (3) That calling Flush() on a SyncTextWriter (the type of Console.Out)
> doesn't actually do anything, and the output is somehow wrongly ordered
> (although I can't imagine how this could actually be: if the locking is
> really working, then my console writes are strictly sequential). I don't
> have access to the code, so I have no idea how it's implemented, but even if
> this is the case it doesn't help much with the fundamental problem (the
> synchronisation error which follows).
>
> Apart from the above, I'm out of ideas. Can anyone suggest what I've
> missed?
>
> William
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/768df06c/attachment.html>

From curt at hagenlocher.org  Wed Nov  5 17:40:29 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 5 Nov 2008 09:40:29 -0700
Subject: [IronPython] Ironclad problem,
	with which someone here may be able to help
In-Reply-To: <d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
Message-ID: <d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>

...or, for that matter, any __del__ methods from within Python -- which
ultimately are handled by finalization.

On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> So, the obvious question for me is whether or not you're using any
> finalizers.
>
>
> On Wed, Nov 5, 2008 at 5:57 AM, William Reade <william at resolversystems.com
> > wrote:
>
>> Hi all
>>
>> While running the numpy tests, I've come across a situation which, to the
>> best of my knowledge, is simply impossible. I'm hoping that one of the local
>> .NET gurus will be able to tell me what I'm missing, or point me somewhere I
>> can get more insight.
>>
>> The 4 methods involved are as follows:
>> -----------------------
>>       public int GetThreadId()
>>       {
>>           return Thread.CurrentThread.ManagedThreadId;
>>       }
>>
>>       public void WriteFlush(string info)
>>       {
>>           Console.WriteLine(info);
>>           Console.Out.Flush();
>>       }
>>
>>       public void EnsureGIL()
>>       {
>>           Monitor.Enter(this.dispatcherLock);
>>           this.WriteFlush(String.Format(
>>               "EnsureGIL ({1}) {0}", this.GetThreadId(),
>> Builtin.id(this.dispatcherLock)));
>>       }
>>
>>       public void ReleaseGIL()
>>       {
>>           this.WriteFlush(String.Format(
>>               "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>> Builtin.id(this.dispatcherLock)));
>>           Monitor.Exit(this.dispatcherLock);
>>       }
>> -----------------------
>> ...and they can, and do, occasionally produce output as follows:
>> -----------------------
>> EnsureGIL (443) 2
>> EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>> ReleaseGIL (443) 2
>>
>> EnsureGIL (443) 2
>> ReleaseGIL (443) 1
>>
>> ReleaseGIL (443) 2
>> -----------------------
>> When this happens, the process continues happily for a short time and then
>> falls over in a later call to ReleaseGIL (after successfully calling it
>> several times). The error is " Object synchronization method was called from
>> an unsynchronized block of code", which I understand to mean "you can't
>> release this lock because you don't hold it".
>>
>> It doesn't happen very often, but I can usually reproduce it by running
>> test_multiarray.TestFromToFile.test_malformed a few hundred times. It may be
>> relevant to note that thread 2 is the GC thread, and thread 1 is the main
>> thread. I have considered the following possibilities:
>>
>> (1) That I'm locking on the wrong object. I believe that isn't the case,
>> because it's constructed only once, as a "new Object()" (ie, a reference
>> type), and is only subsequently used for locking; and, because it keeps the
>> same ipy id throughout.
>>
>> (2) That Monitor.Enter occasionally allows two different threads to
>> acquire the same lock. I consider this extremely unlikely, because... well,
>> how many multithreaded .NET apps already exist? If Monitor really were
>> broken, I think we'd probably know about it by now.
>>
>> (3) That calling Flush() on a SyncTextWriter (the type of Console.Out)
>> doesn't actually do anything, and the output is somehow wrongly ordered
>> (although I can't imagine how this could actually be: if the locking is
>> really working, then my console writes are strictly sequential). I don't
>> have access to the code, so I have no idea how it's implemented, but even if
>> this is the case it doesn't help much with the fundamental problem (the
>> synchronisation error which follows).
>>
>> Apart from the above, I'm out of ideas. Can anyone suggest what I've
>> missed?
>>
>> William
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/5f0110fd/attachment.html>

From william at resolversystems.com  Wed Nov  5 18:15:08 2008
From: william at resolversystems.com (William Reade)
Date: Wed, 05 Nov 2008 17:15:08 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
Message-ID: <4911D49C.4050308@resolversystems.com>

Hi Curt

I am indeed; that's how I know thread 2 is the GC thread. Is locking 
during GC forbidden?

William

Curt Hagenlocher wrote:
> ...or, for that matter, any __del__ methods from within Python -- 
> which ultimately are handled by finalization.
>
> On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher <curt at hagenlocher.org 
> <mailto:curt at hagenlocher.org>> wrote:
>
>     So, the obvious question for me is whether or not you're using any
>     finalizers.
>
>
>     On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>     <william at resolversystems.com <mailto:william at resolversystems.com>>
>     wrote:
>
>         Hi all
>
>         While running the numpy tests, I've come across a situation
>         which, to the best of my knowledge, is simply impossible. I'm
>         hoping that one of the local .NET gurus will be able to tell
>         me what I'm missing, or point me somewhere I can get more insight.
>
>         The 4 methods involved are as follows:
>         -----------------------
>               public int GetThreadId()
>               {
>                   return Thread.CurrentThread.ManagedThreadId;
>               }
>
>               public void WriteFlush(string info)
>               {
>                   Console.WriteLine(info);
>                   Console.Out.Flush();
>               }
>
>               public void EnsureGIL()
>               {
>                   Monitor.Enter(this.dispatcherLock);
>                   this.WriteFlush(String.Format(
>                       "EnsureGIL ({1}) {0}", this.GetThreadId(),
>         Builtin.id(this.dispatcherLock)));
>               }
>
>               public void ReleaseGIL()
>               {
>                   this.WriteFlush(String.Format(
>                       "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>         Builtin.id(this.dispatcherLock)));
>                   Monitor.Exit(this.dispatcherLock);
>               }
>         -----------------------
>         ...and they can, and do, occasionally produce output as follows:
>         -----------------------
>         EnsureGIL (443) 2
>         EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>         ReleaseGIL (443) 2
>
>         EnsureGIL (443) 2
>         ReleaseGIL (443) 1
>
>         ReleaseGIL (443) 2
>         -----------------------
>         When this happens, the process continues happily for a short
>         time and then falls over in a later call to ReleaseGIL (after
>         successfully calling it several times). The error is " Object
>         synchronization method was called from an unsynchronized block
>         of code", which I understand to mean "you can't release this
>         lock because you don't hold it".
>
>         It doesn't happen very often, but I can usually reproduce it
>         by running test_multiarray.TestFromToFile.test_malformed a few
>         hundred times. It may be relevant to note that thread 2 is the
>         GC thread, and thread 1 is the main thread. I have considered
>         the following possibilities:
>
>         (1) That I'm locking on the wrong object. I believe that isn't
>         the case, because it's constructed only once, as a "new
>         Object()" (ie, a reference type), and is only subsequently
>         used for locking; and, because it keeps the same ipy id
>         throughout.
>
>         (2) That Monitor.Enter occasionally allows two different
>         threads to acquire the same lock. I consider this extremely
>         unlikely, because... well, how many multithreaded .NET apps
>         already exist? If Monitor really were broken, I think we'd
>         probably know about it by now.
>
>         (3) That calling Flush() on a SyncTextWriter (the type of
>         Console.Out) doesn't actually do anything, and the output is
>         somehow wrongly ordered (although I can't imagine how this
>         could actually be: if the locking is really working, then my
>         console writes are strictly sequential). I don't have access
>         to the code, so I have no idea how it's implemented, but even
>         if this is the case it doesn't help much with the fundamental
>         problem (the synchronisation error which follows).
>
>         Apart from the above, I'm out of ideas. Can anyone suggest
>         what I've missed?
>
>         William
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto: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
>   



From curt at hagenlocher.org  Wed Nov  5 18:34:27 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 5 Nov 2008 10:34:27 -0700
Subject: [IronPython] Ironclad problem,
	with which someone here may be able to help
In-Reply-To: <4911D49C.4050308@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
	<4911D49C.4050308@resolversystems.com>
Message-ID: <d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>

Locking during finalization is often considered to be a bad idea.  In
particular, locking without a timeout introduces the possibility that you
will hang the finalization thread, preventing further objects from being
finalized.  But clearly, that's not what's happening here.

Other questions that probably don't matter but might be interesting to know:

Can we assume that the finalization thread isn't the first place where this
lock is required?  That your log starts somewhere in the middle?

Is this under x86 or x64 or both?

Are you creating any additional AppDomains in the process?


On Wed, Nov 5, 2008 at 10:15 AM, William Reade
<william at resolversystems.com>wrote:

> Hi Curt
>
> I am indeed; that's how I know thread 2 is the GC thread. Is locking during
> GC forbidden?
>
> William
>
> Curt Hagenlocher wrote:
>
>> ...or, for that matter, any __del__ methods from within Python -- which
>> ultimately are handled by finalization.
>>
>> On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher <curt at hagenlocher.org<mailto:
>> curt at hagenlocher.org>> wrote:
>>
>>    So, the obvious question for me is whether or not you're using any
>>    finalizers.
>>
>>
>>    On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>    <william at resolversystems.com <mailto:william at resolversystems.com>>
>>
>>    wrote:
>>
>>        Hi all
>>
>>        While running the numpy tests, I've come across a situation
>>        which, to the best of my knowledge, is simply impossible. I'm
>>        hoping that one of the local .NET gurus will be able to tell
>>        me what I'm missing, or point me somewhere I can get more insight.
>>
>>        The 4 methods involved are as follows:
>>        -----------------------
>>              public int GetThreadId()
>>              {
>>                  return Thread.CurrentThread.ManagedThreadId;
>>              }
>>
>>              public void WriteFlush(string info)
>>              {
>>                  Console.WriteLine(info);
>>                  Console.Out.Flush();
>>              }
>>
>>              public void EnsureGIL()
>>              {
>>                  Monitor.Enter(this.dispatcherLock);
>>                  this.WriteFlush(String.Format(
>>                      "EnsureGIL ({1}) {0}", this.GetThreadId(),
>>        Builtin.id(this.dispatcherLock)));
>>              }
>>
>>              public void ReleaseGIL()
>>              {
>>                  this.WriteFlush(String.Format(
>>                      "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>>        Builtin.id(this.dispatcherLock)));
>>                  Monitor.Exit(this.dispatcherLock);
>>              }
>>        -----------------------
>>        ...and they can, and do, occasionally produce output as follows:
>>        -----------------------
>>        EnsureGIL (443) 2
>>        EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>        ReleaseGIL (443) 2
>>
>>        EnsureGIL (443) 2
>>        ReleaseGIL (443) 1
>>
>>        ReleaseGIL (443) 2
>>        -----------------------
>>        When this happens, the process continues happily for a short
>>        time and then falls over in a later call to ReleaseGIL (after
>>        successfully calling it several times). The error is " Object
>>        synchronization method was called from an unsynchronized block
>>        of code", which I understand to mean "you can't release this
>>        lock because you don't hold it".
>>
>>        It doesn't happen very often, but I can usually reproduce it
>>        by running test_multiarray.TestFromToFile.test_malformed a few
>>        hundred times. It may be relevant to note that thread 2 is the
>>        GC thread, and thread 1 is the main thread. I have considered
>>        the following possibilities:
>>
>>        (1) That I'm locking on the wrong object. I believe that isn't
>>        the case, because it's constructed only once, as a "new
>>        Object()" (ie, a reference type), and is only subsequently
>>        used for locking; and, because it keeps the same ipy id
>>        throughout.
>>
>>        (2) That Monitor.Enter occasionally allows two different
>>        threads to acquire the same lock. I consider this extremely
>>        unlikely, because... well, how many multithreaded .NET apps
>>        already exist? If Monitor really were broken, I think we'd
>>        probably know about it by now.
>>
>>        (3) That calling Flush() on a SyncTextWriter (the type of
>>        Console.Out) doesn't actually do anything, and the output is
>>        somehow wrongly ordered (although I can't imagine how this
>>        could actually be: if the locking is really working, then my
>>        console writes are strictly sequential). I don't have access
>>        to the code, so I have no idea how it's implemented, but even
>>        if this is the case it doesn't help much with the fundamental
>>        problem (the synchronisation error which follows).
>>
>>        Apart from the above, I'm out of ideas. Can anyone suggest
>>        what I've missed?
>>
>>        William
>>        _______________________________________________
>>        Users mailing list
>>        Users at lists.ironpython.com <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/acd3a091/attachment.html>

From william at resolversystems.com  Wed Nov  5 19:00:39 2008
From: william at resolversystems.com (William Reade)
Date: Wed, 05 Nov 2008 18:00:39 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>	<4911D49C.4050308@resolversystems.com>
	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
Message-ID: <4911DF47.3020708@resolversystems.com>

The log starts in the middle (after many lock/unlocks, some from each 
thread); I'm running on x86; and I have no additional AppDomains.

I don't think it would be safe for me to entirely avoid locking during 
finalization, but I could probably cut it down to a quick lock, on a 
separate object, to enqueue pointers for cleanup and deallocation on the 
main thread. However, I'm reluctant to do that until I'm sure that the 
problem is specifically related to GC, otherwise it'll just come back as 
soon as anyone tries any serious multithreading :).

Curt Hagenlocher wrote:
> Locking during finalization is often considered to be a bad idea.  In 
> particular, locking without a timeout introduces the possibility that 
> you will hang the finalization thread, preventing further objects from 
> being finalized.  But clearly, that's not what's happening here.
>
> Other questions that probably don't matter but might be interesting to 
> know:
>
> Can we assume that the finalization thread isn't the first place where 
> this lock is required?  That your log starts somewhere in the middle?
>
> Is this under x86 or x64 or both?
>
> Are you creating any additional AppDomains in the process?
>
>
> On Wed, Nov 5, 2008 at 10:15 AM, William Reade 
> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>
>     Hi Curt
>
>     I am indeed; that's how I know thread 2 is the GC thread. Is
>     locking during GC forbidden?
>
>     William
>
>     Curt Hagenlocher wrote:
>
>         ...or, for that matter, any __del__ methods from within Python
>         -- which ultimately are handled by finalization.
>
>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>         wrote:
>
>            So, the obvious question for me is whether or not you're
>         using any
>            finalizers.
>
>
>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>            <william at resolversystems.com
>         <mailto:william at resolversystems.com>
>         <mailto:william at resolversystems.com
>         <mailto:william at resolversystems.com>>>
>
>            wrote:
>
>                Hi all
>
>                While running the numpy tests, I've come across a situation
>                which, to the best of my knowledge, is simply
>         impossible. I'm
>                hoping that one of the local .NET gurus will be able to
>         tell
>                me what I'm missing, or point me somewhere I can get
>         more insight.
>
>                The 4 methods involved are as follows:
>                -----------------------
>                      public int GetThreadId()
>                      {
>                          return Thread.CurrentThread.ManagedThreadId;
>                      }
>
>                      public void WriteFlush(string info)
>                      {
>                          Console.WriteLine(info);
>                          Console.Out.Flush();
>                      }
>
>                      public void EnsureGIL()
>                      {
>                          Monitor.Enter(this.dispatcherLock);
>                          this.WriteFlush(String.Format(
>                              "EnsureGIL ({1}) {0}", this.GetThreadId(),
>                Builtin.id(this.dispatcherLock)));
>                      }
>
>                      public void ReleaseGIL()
>                      {
>                          this.WriteFlush(String.Format(
>                              "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>                Builtin.id(this.dispatcherLock)));
>                          Monitor.Exit(this.dispatcherLock);
>                      }
>                -----------------------
>                ...and they can, and do, occasionally produce output as
>         follows:
>                -----------------------
>                EnsureGIL (443) 2
>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>                ReleaseGIL (443) 2
>
>                EnsureGIL (443) 2
>                ReleaseGIL (443) 1
>
>                ReleaseGIL (443) 2
>                -----------------------
>                When this happens, the process continues happily for a
>         short
>                time and then falls over in a later call to ReleaseGIL
>         (after
>                successfully calling it several times). The error is "
>         Object
>                synchronization method was called from an
>         unsynchronized block
>                of code", which I understand to mean "you can't release
>         this
>                lock because you don't hold it".
>
>                It doesn't happen very often, but I can usually
>         reproduce it
>                by running
>         test_multiarray.TestFromToFile.test_malformed a few
>                hundred times. It may be relevant to note that thread 2
>         is the
>                GC thread, and thread 1 is the main thread. I have
>         considered
>                the following possibilities:
>
>                (1) That I'm locking on the wrong object. I believe
>         that isn't
>                the case, because it's constructed only once, as a "new
>                Object()" (ie, a reference type), and is only subsequently
>                used for locking; and, because it keeps the same ipy id
>                throughout.
>
>                (2) That Monitor.Enter occasionally allows two different
>                threads to acquire the same lock. I consider this extremely
>                unlikely, because... well, how many multithreaded .NET apps
>                already exist? If Monitor really were broken, I think we'd
>                probably know about it by now.
>
>                (3) That calling Flush() on a SyncTextWriter (the type of
>                Console.Out) doesn't actually do anything, and the
>         output is
>                somehow wrongly ordered (although I can't imagine how this
>                could actually be: if the locking is really working,
>         then my
>                console writes are strictly sequential). I don't have
>         access
>                to the code, so I have no idea how it's implemented,
>         but even
>                if this is the case it doesn't help much with the
>         fundamental
>                problem (the synchronisation error which follows).
>
>                Apart from the above, I'm out of ideas. Can anyone suggest
>                what I've missed?
>
>                William
>                _______________________________________________
>                Users mailing list
>                Users at lists.ironpython.com
>         <mailto:Users at lists.ironpython.com>
>         <mailto:Users at lists.ironpython.com
>         <mailto:Users at lists.ironpython.com>>
>
>              
>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>         ------------------------------------------------------------------------
>
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>          
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>   



From dinov at microsoft.com  Wed Nov  5 22:23:18 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 5 Nov 2008 13:23:18 -0800
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)
In-Reply-To: <4911C3CD.8010805@resolversystems.com>
References: <4911C3CD.8010805@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735F65B@NA-EXMSG-C102.redmond.corp.microsoft.com>

Thanks for the report.  I've opened CodePlex bug #19350 to track this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19350).

I believe the fix is actually pretty simple and we'll discuss whether we'll take it for 2.0 final at our Friday team meeting.  If you want to try out the fix either to unblock yourself or just see if there's other issues lurking behind it you can do this change:

                          return new MetaObject[] {
                        arguments[0],
                        new MetaObject(
                            Ast.Call(
                                typeof(PythonOps).GetMethod("MakeTuple"),
                                Ast.NewArrayInit(typeof(object), tupleArgs)
                            ),
-                           Restrictions.Empty
+                           Restrictions.Combine(arguments)
                        ),
                        arguments[arguments.Length-1]
                    };

If you just search for "return new MetaObject[]" in PythonProtocol.Operations.cs you'll get to the right spot.  There's a 2nd spot about 20 lines later for the getter case which has the same issue & fix.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, November 05, 2008 8:03 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)

Hello Guys,

Discovered a bug in indexing Python objects in IronPython 2.

The following code:

class X(object):
    def __setitem__(self, key, value):
        print repr(key)

def f(a, b):
    X()[a, b] = object()

f(1, 2)
f('one', 'two')

Produces the following exception:

Traceback (most recent call last):
  File "bugtest.py", line 9, in bugtest.py
  File "bugtest.py", line 6, in f
TypeError: Specified cast is not valid.

It looks like IronPython has a call site that is now expecting integers
the second time round.

Switching to using explicit tuples for indexing works around the problem:

    X()[(a, b)] = object()

However this kind of indexing is an *extremely* common way to use our
spreadsheet API from user code, so we couldn't release with this bug in
place.

(Doing the indexing outside of the function also avoids the problem
interestingly enough.)

All the best,

Michael Foord

--

Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
michael.foord at resolversystems.com
+44 (0) 20 7253 6372

Try out Resolver One! <http://www.resolversystems.com/get-it/>

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK

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


From Marty.Nelson at symyx.com  Wed Nov  5 22:48:49 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Wed, 5 Nov 2008 13:48:49 -0800
Subject: [IronPython] How do I test if a variable is defined?
In-Reply-To: <1EA7F3E8-F917-411F-99F3-901A8A0ABE7E@gmail.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>	<4910AB3B.6020708@voidspace.org.uk><6c63de570811041532p1d893e7x4302abc3b18b96a8@mail.gmail.com><49117077.3090102@voidspace.org.uk>
	<1EA7F3E8-F917-411F-99F3-901A8A0ABE7E@gmail.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03AD7015@srv-be-101.Symyx-IC.symyx.com>


That worked great, thanks.

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Kenneth Miller
Sent: Wednesday, November 05, 2008 7:46 AM
To: Discussion of IronPython
Subject: Re: [IronPython] How do I test if a variable is defined?

 

Can't you just do..

 

'variable_name' in locals()

 

or

 

'variable_name' in dir()

 

Regards,

Ken

 

On Nov 5, 2008, at 4:07 AM, Michael Foord wrote:





Tony Meyer wrote:



On Wed, Nov 5, 2008 at 8:06 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:

	 

		Marty Nelson wrote:

		   

			How do I test in Iron Python (in python) if a
variable is defined?

			 

			     

	[...]

	 

		try:

		 name

		except NameError:

		 # variable 'name' is not defined

		   

	 

	If you're running some sort of checker (pylint, pychecker) over
this,

	you might get a warning about the "name" line not doing
anything.  To

	avoid that, you'll sometimes see a variant like this:

	 

	try:

	   unused = name

	except NameError:

	   # variable 'name' is not defined.

	 


Except then PyLint will complain that 'unused' is unused, plus you code
no longer accurately conveys its intent.

I prefer to filter (or disable) that particular warning rather than
change the code.

Michael




Cheers,

	Tony

	_______________________________________________

	Users mailing list

	Users at lists.ironpython.com

	http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

	 



-- 
http://www.ironpythoninaction.com/

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

 



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/81118bf4/attachment.html>

From Marty.Nelson at symyx.com  Wed Nov  5 22:50:20 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Wed, 5 Nov 2008 13:50:20 -0800
Subject: [IronPython] Extension methods in python
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>


Is there the equivalent of extension method in python?  I want to put a
variable into the script scope and create extension methods for it.
Does this make sense and is it possible?



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/e4a839f7/attachment.html>

From dinov at microsoft.com  Wed Nov  5 23:10:56 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 5 Nov 2008 14:10:56 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735F6EC@NA-EXMSG-C102.redmond.corp.microsoft.com>

If it's an object defined in Python you can usually attach methods directly to the object or it's Python type.  But otherwise we have no support for automatically adding .NET extension methods to existing types currently.  It is a frequent request and we will probably get to it at some point.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Wednesday, November 05, 2008 1:50 PM
To: Discussion of IronPython
Subject: [IronPython] Extension methods in python

Is there the equivalent of extension method in python?  I want to put a variable into the script scope and create extension methods for it.  Does this make sense and is it possible?
=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/0aca627f/attachment.html>

From Marty.Nelson at symyx.com  Thu Nov  6 00:58:58 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Wed, 5 Nov 2008 15:58:58 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735F6EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC23554FF735F6EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03AD7091@srv-be-101.Symyx-IC.symyx.com>


>> If it's an object defined in Python you can usually attach methods
directly to the object or it's Python type. 

 

So how would this work?

 

Let's say I had injested a variable into the scope from c#:
scope.SetVarialble("widget", "hello world")

 

Can I do something in python so that I can then type:

 

print widget.ToFoo()

 

print widget.ToBar()

 

That would theoretically output:

 

hello worldFoo

hello worldBar

 

 

 But otherwise we have no support for automatically adding .NET
extension methods to existing types currently.  It is a frequent request
and we will probably get to it at some point.

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Wednesday, November 05, 2008 1:50 PM
To: Discussion of IronPython
Subject: [IronPython] Extension methods in python

 

Is there the equivalent of extension method in python?  I want to put a
variable into the script scope and create extension methods for it.
Does this make sense and is it possible?

 



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/be556dda/attachment.html>

From dinov at microsoft.com  Thu Nov  6 01:30:52 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 5 Nov 2008 16:30:52 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03AD7091@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC23554FF735F6EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<515335F32AA04440B3DE6FEA1993E9AD03AD7091@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735F80B@NA-EXMSG-C102.redmond.corp.microsoft.com>

In this case widget is the string "hello world" so it won't work.  If it was instead something like:

class x(object): pass
a = x()

...
Then in C# you could do:

widget = scope.GetVariable("a")

then you could do engine.Operations.SetMember(widget, "foo", () => "hello world");

and then back in Python:

a.foo()

prints hello world.

Probably not what you're looking for but it's all that is there today :(

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Wednesday, November 05, 2008 3:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

>> If it's an object defined in Python you can usually attach methods directly to the object or it's Python type.

So how would this work?

Let's say I had injested a variable into the scope from c#:  scope.SetVarialble("widget", "hello world")

Can I do something in python so that I can then type:

print widget.ToFoo()

print widget.ToBar()

That would theoretically output:

hello worldFoo
hello worldBar


 But otherwise we have no support for automatically adding .NET extension methods to existing types currently.  It is a frequent request and we will probably get to it at some point.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Wednesday, November 05, 2008 1:50 PM
To: Discussion of IronPython
Subject: [IronPython] Extension methods in python

Is there the equivalent of extension method in python?  I want to put a variable into the script scope and create extension methods for it.  Does this make sense and is it possible?

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081105/4a83e61a/attachment.html>

From jdhardy at gmail.com  Thu Nov  6 01:42:46 2008
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 5 Nov 2008 17:42:46 -0700
Subject: [IronPython] _WindowsError and errno
Message-ID: <ea89d0e50811051642q7d8388fahc4be7348c06b9416@mail.gmail.com>

Hi IronPython team,
Is there any reason why _WindowsError sets errno to 22 in all cases?
There's some code in Django that checks if e.errno = errno.EEXIST. The
exception that gets thrown by IronPython has winerror = 17 (and the
message string says "[Errno 17]..."!), but e.errno is 22 (EINVAL).

Fixing #19310 would avoid the problem in this case (it's the same
chunk of code), but I'm curious in general what the reason is.

- Jeff


From dinov at microsoft.com  Thu Nov  6 01:50:36 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 5 Nov 2008 16:50:36 -0800
Subject: [IronPython] _WindowsError and errno
In-Reply-To: <ea89d0e50811051642q7d8388fahc4be7348c06b9416@mail.gmail.com>
References: <ea89d0e50811051642q7d8388fahc4be7348c06b9416@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735F821@NA-EXMSG-C102.redmond.corp.microsoft.com>

It's because when I initially looked at WindowsError it sure seemed like 22 was the error code that was always used :).  If you do:

for i in xrange(100):
    print WindowsError(i, i).errno

on CPython You'll see a large amount of the errno's are set to 22 (including 0 and 1) - apparently I didn't test enough combinations initially :(  I think we have another bug on this somewhere too and we just need to spend the time to get the mapping right.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Wednesday, November 05, 2008 4:43 PM
To: Discussion of IronPython
Subject: [IronPython] _WindowsError and errno

Hi IronPython team,
Is there any reason why _WindowsError sets errno to 22 in all cases?
There's some code in Django that checks if e.errno = errno.EEXIST. The
exception that gets thrown by IronPython has winerror = 17 (and the
message string says "[Errno 17]..."!), but e.errno is 22 (EINVAL).

Fixing #19310 would avoid the problem in this case (it's the same
chunk of code), but I'm curious in general what the reason is.

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



From dinov at microsoft.com  Thu Nov  6 06:30:15 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 5 Nov 2008 21:30:15 -0800
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <4911DF47.3020708@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
	<4911D49C.4050308@resolversystems.com>
	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
	<4911DF47.3020708@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>

I would suggest getting a snap shot of the call stacks when this is happening if that's possible.  I can't pin anything down but I wonder if you could have an STA object or something that otherwise requires message pumping.  That message pumping could happen while you're doing a Monitor.Enter call.  If that was happening maybe there is some subtle CLR bug or a surprise feature?  It is surprising that Monitor.Enter can go re-entrant but it can...

So it'd be interesting to get thread snapshots and see if

>                EnsureGIL (443) 2
>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.

Could be happening because Thread 1 experiences contention, blocks and pumps messages, causing the finalizer thread (2) to run, the lock is acquired and ... ?

Only other thing I could think of is does it repro on other machines?  Maybe it's a hardware bug as unlikely as that seems?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Wednesday, November 05, 2008 10:01 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help

The log starts in the middle (after many lock/unlocks, some from each
thread); I'm running on x86; and I have no additional AppDomains.

I don't think it would be safe for me to entirely avoid locking during
finalization, but I could probably cut it down to a quick lock, on a
separate object, to enqueue pointers for cleanup and deallocation on the
main thread. However, I'm reluctant to do that until I'm sure that the
problem is specifically related to GC, otherwise it'll just come back as
soon as anyone tries any serious multithreading :).

Curt Hagenlocher wrote:
> Locking during finalization is often considered to be a bad idea.  In
> particular, locking without a timeout introduces the possibility that
> you will hang the finalization thread, preventing further objects from
> being finalized.  But clearly, that's not what's happening here.
>
> Other questions that probably don't matter but might be interesting to
> know:
>
> Can we assume that the finalization thread isn't the first place where
> this lock is required?  That your log starts somewhere in the middle?
>
> Is this under x86 or x64 or both?
>
> Are you creating any additional AppDomains in the process?
>
>
> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>
>     Hi Curt
>
>     I am indeed; that's how I know thread 2 is the GC thread. Is
>     locking during GC forbidden?
>
>     William
>
>     Curt Hagenlocher wrote:
>
>         ...or, for that matter, any __del__ methods from within Python
>         -- which ultimately are handled by finalization.
>
>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>         wrote:
>
>            So, the obvious question for me is whether or not you're
>         using any
>            finalizers.
>
>
>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>            <william at resolversystems.com
>         <mailto:william at resolversystems.com>
>         <mailto:william at resolversystems.com
>         <mailto:william at resolversystems.com>>>
>
>            wrote:
>
>                Hi all
>
>                While running the numpy tests, I've come across a situation
>                which, to the best of my knowledge, is simply
>         impossible. I'm
>                hoping that one of the local .NET gurus will be able to
>         tell
>                me what I'm missing, or point me somewhere I can get
>         more insight.
>
>                The 4 methods involved are as follows:
>                -----------------------
>                      public int GetThreadId()
>                      {
>                          return Thread.CurrentThread.ManagedThreadId;
>                      }
>
>                      public void WriteFlush(string info)
>                      {
>                          Console.WriteLine(info);
>                          Console.Out.Flush();
>                      }
>
>                      public void EnsureGIL()
>                      {
>                          Monitor.Enter(this.dispatcherLock);
>                          this.WriteFlush(String.Format(
>                              "EnsureGIL ({1}) {0}", this.GetThreadId(),
>                Builtin.id(this.dispatcherLock)));
>                      }
>
>                      public void ReleaseGIL()
>                      {
>                          this.WriteFlush(String.Format(
>                              "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>                Builtin.id(this.dispatcherLock)));
>                          Monitor.Exit(this.dispatcherLock);
>                      }
>                -----------------------
>                ...and they can, and do, occasionally produce output as
>         follows:
>                -----------------------
>                EnsureGIL (443) 2
>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>                ReleaseGIL (443) 2
>
>                EnsureGIL (443) 2
>                ReleaseGIL (443) 1
>
>                ReleaseGIL (443) 2
>                -----------------------
>                When this happens, the process continues happily for a
>         short
>                time and then falls over in a later call to ReleaseGIL
>         (after
>                successfully calling it several times). The error is "
>         Object
>                synchronization method was called from an
>         unsynchronized block
>                of code", which I understand to mean "you can't release
>         this
>                lock because you don't hold it".
>
>                It doesn't happen very often, but I can usually
>         reproduce it
>                by running
>         test_multiarray.TestFromToFile.test_malformed a few
>                hundred times. It may be relevant to note that thread 2
>         is the
>                GC thread, and thread 1 is the main thread. I have
>         considered
>                the following possibilities:
>
>                (1) That I'm locking on the wrong object. I believe
>         that isn't
>                the case, because it's constructed only once, as a "new
>                Object()" (ie, a reference type), and is only subsequently
>                used for locking; and, because it keeps the same ipy id
>                throughout.
>
>                (2) That Monitor.Enter occasionally allows two different
>                threads to acquire the same lock. I consider this extremely
>                unlikely, because... well, how many multithreaded .NET apps
>                already exist? If Monitor really were broken, I think we'd
>                probably know about it by now.
>
>                (3) That calling Flush() on a SyncTextWriter (the type of
>                Console.Out) doesn't actually do anything, and the
>         output is
>                somehow wrongly ordered (although I can't imagine how this
>                could actually be: if the locking is really working,
>         then my
>                console writes are strictly sequential). I don't have
>         access
>                to the code, so I have no idea how it's implemented,
>         but even
>                if this is the case it doesn't help much with the
>         fundamental
>                problem (the synchronisation error which follows).
>
>                Apart from the above, I'm out of ideas. Can anyone suggest
>                what I've missed?
>
>                William
>                _______________________________________________
>                Users mailing list
>                Users at lists.ironpython.com
>         <mailto:Users at lists.ironpython.com>
>         <mailto:Users at lists.ironpython.com
>         <mailto:Users at lists.ironpython.com>>
>
>
>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>         ------------------------------------------------------------------------
>
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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



From tony.meyer at gmail.com  Thu Nov  6 10:48:28 2008
From: tony.meyer at gmail.com (Tony Meyer)
Date: Thu, 6 Nov 2008 22:48:28 +1300
Subject: [IronPython] How do I test if a variable is defined?
In-Reply-To: <49117077.3090102@voidspace.org.uk>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD6CBF@srv-be-101.Symyx-IC.symyx.com>
	<4910AB3B.6020708@voidspace.org.uk>
	<6c63de570811041532p1d893e7x4302abc3b18b96a8@mail.gmail.com>
	<49117077.3090102@voidspace.org.uk>
Message-ID: <6c63de570811060148n96252ebka488ce61fe3609f3@mail.gmail.com>

>> If you're running some sort of checker (pylint, pychecker) over this,
>> you might get a warning about the "name" line not doing anything.  To
>> avoid that, you'll sometimes see a variant like this:
>>
>> try:
>>    unused = name
>> except NameError:
>>    # variable 'name' is not defined.
>>
>
> Except then PyLint will complain that 'unused' is unused, plus you code no
> longer accurately conveys its intent.

Well pychecker ignores variables called "unused" (and _, but that
clashes with the gettext usage).  I figured pylint did too, but that
was only a guess.  IMO this code does accurately convey its intent - I
have seen this idiom in a lot of Python code.

Cheers,
Tony


From fuzzyman at voidspace.org.uk  Thu Nov  6 13:33:12 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 06 Nov 2008 12:33:12 +0000
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735F65B@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4911C3CD.8010805@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735F65B@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4912E408.7030601@voidspace.org.uk>

Dino Viehland wrote:
> Thanks for the report.  I've opened CodePlex bug #19350 to track this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19350).
>
> I believe the fix is actually pretty simple and we'll discuss whether we'll take it for 2.0 final at our Friday team meeting.  If you want to try out the fix either to unblock yourself or just see if there's other issues lurking behind it you can do this change:
>   

Thanks Dino - that fix certainly fixes the specific issue and means I 
have less failing tests in my Worksheet test (and no new ones as far as 
I can tell).

Although Resolver One now runs on IronPython 2 I'm still in a position 
where there are a stack of failing tests (we have 6000 tests in total 
and I'm gradually moving through them working out whether failures are 
because we are testing against the old API, failures that indicate bugs 
in IronPython, failures due to moving to Python 2.5, or anything else...)

Although aspects of Resolver One on IronPython 2 are just as fast as 
they are on IronPython 1 there are still some specific performance 
issues. We anticipate that the hardest part of the port will be 
identifying and fixing those issues (thankfully we have a bunch of 
performance tests to help us). If we find anything specific we will 
report it back of course.

We would appreciate this fix being in 2.0 final as it is our goal to do 
a new Resolver One release based on it as soon as humanly possible, and 
we would prefer not to have to rely on a patched version.

Anyway - thanks for identifying a fix so quickly.

All the best,

Michael

>                           return new MetaObject[] {
>                         arguments[0],
>                         new MetaObject(
>                             Ast.Call(
>                                 typeof(PythonOps).GetMethod("MakeTuple"),
>                                 Ast.NewArrayInit(typeof(object), tupleArgs)
>                             ),
> -                           Restrictions.Empty
> +                           Restrictions.Combine(arguments)
>                         ),
>                         arguments[arguments.Length-1]
>                     };
>
> If you just search for "return new MetaObject[]" in PythonProtocol.Operations.cs you'll get to the right spot.  There's a 2nd spot about 20 lines later for the getter case which has the same issue & fix.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, November 05, 2008 8:03 AM
> To: Discussion of IronPython
> Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)
>
> Hello Guys,
>
> Discovered a bug in indexing Python objects in IronPython 2.
>
> The following code:
>
> class X(object):
>     def __setitem__(self, key, value):
>         print repr(key)
>
> def f(a, b):
>     X()[a, b] = object()
>
> f(1, 2)
> f('one', 'two')
>
> Produces the following exception:
>
> Traceback (most recent call last):
>   File "bugtest.py", line 9, in bugtest.py
>   File "bugtest.py", line 6, in f
> TypeError: Specified cast is not valid.
>
> It looks like IronPython has a call site that is now expecting integers
> the second time round.
>
> Switching to using explicit tuples for indexing works around the problem:
>
>     X()[(a, b)] = object()
>
> However this kind of indexing is an *extremely* common way to use our
> spreadsheet API from user code, so we couldn't release with this bug in
> place.
>
> (Doing the indexing outside of the function also avoids the problem
> interestingly enough.)
>
> All the best,
>
> Michael Foord
>
> --
>
> Michael Foord
> Senior Software Engineer, Resolver Systems Ltd.
> michael.foord at resolversystems.com
> +44 (0) 20 7253 6372
>
> Try out Resolver One! <http://www.resolversystems.com/get-it/>
>
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
>
> _______________________________________________
> 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
>   


-- 
http://www.ironpythoninaction.com/



From slide.o.mix at gmail.com  Thu Nov  6 13:41:38 2008
From: slide.o.mix at gmail.com (Slide)
Date: Thu, 6 Nov 2008 05:41:38 -0700
Subject: [IronPython] Latest Hosting Documentation
Message-ID: <a623f7d10811060441k1b506a1dr2c230071d199d852@mail.gmail.com>

Can someone point me to the latest hosting docs?

Thanks,

slide

-- 
slide-o-blog
http://slide-o-blog.blogspot.com/


From curt at hagenlocher.org  Thu Nov  6 14:19:25 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 6 Nov 2008 06:19:25 -0700
Subject: [IronPython] Latest Hosting Documentation
In-Reply-To: <a623f7d10811060441k1b506a1dr2c230071d199d852@mail.gmail.com>
References: <a623f7d10811060441k1b506a1dr2c230071d199d852@mail.gmail.com>
Message-ID: <d2155e360811060519n1cefe30bl48cbed602210ed2f@mail.gmail.com>

http://compilerlab.members.winisp.net/dlr-spec-hosting.pdf (PDF) or
http://compilerlab.members.winisp.net/dlr-spec-hosting.doc (Word)

On Thu, Nov 6, 2008 at 5:41 AM, Slide <slide.o.mix at gmail.com> wrote:

> Can someone point me to the latest hosting docs?
>
> Thanks,
>
> slide
>
> --
> slide-o-blog
> http://slide-o-blog.blogspot.com/
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/e655b967/attachment.html>

From william at resolversystems.com  Thu Nov  6 15:01:18 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 06 Nov 2008 14:01:18 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>	<4911D49C.4050308@resolversystems.com>	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>	<4911DF47.3020708@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4912F8AE.2020400@resolversystems.com>

Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer 
reproduce the problem. However, this bothers me a bit: I'm not competent 
to follow all the consequences here, but this situation seems to imply 
that Ironclad won't be usable safely from any STA thread. Is this an 
intended restriction or a bug?

Incidentally, tracking down the call stacks proved to be hard work: the 
timing changed enough that I only got a single failure over dozens of 
runs, and it turned out I'd got the logging wrong, so I didn't find out 
anything useful :(.

Dino Viehland wrote:
> I would suggest getting a snap shot of the call stacks when this is happening if that's possible.  I can't pin anything down but I wonder if you could have an STA object or something that otherwise requires message pumping.  That message pumping could happen while you're doing a Monitor.Enter call.  If that was happening maybe there is some subtle CLR bug or a surprise feature?  It is surprising that Monitor.Enter can go re-entrant but it can...
>
> So it'd be interesting to get thread snapshots and see if
>
>   
>>                EnsureGIL (443) 2
>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>     
>
> Could be happening because Thread 1 experiences contention, blocks and pumps messages, causing the finalizer thread (2) to run, the lock is acquired and ... ?
>
> Only other thing I could think of is does it repro on other machines?  Maybe it's a hardware bug as unlikely as that seems?
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Wednesday, November 05, 2008 10:01 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help
>
> The log starts in the middle (after many lock/unlocks, some from each
> thread); I'm running on x86; and I have no additional AppDomains.
>
> I don't think it would be safe for me to entirely avoid locking during
> finalization, but I could probably cut it down to a quick lock, on a
> separate object, to enqueue pointers for cleanup and deallocation on the
> main thread. However, I'm reluctant to do that until I'm sure that the
> problem is specifically related to GC, otherwise it'll just come back as
> soon as anyone tries any serious multithreading :).
>
> Curt Hagenlocher wrote:
>   
>> Locking during finalization is often considered to be a bad idea.  In
>> particular, locking without a timeout introduces the possibility that
>> you will hang the finalization thread, preventing further objects from
>> being finalized.  But clearly, that's not what's happening here.
>>
>> Other questions that probably don't matter but might be interesting to
>> know:
>>
>> Can we assume that the finalization thread isn't the first place where
>> this lock is required?  That your log starts somewhere in the middle?
>>
>> Is this under x86 or x64 or both?
>>
>> Are you creating any additional AppDomains in the process?
>>
>>
>> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>>
>>     Hi Curt
>>
>>     I am indeed; that's how I know thread 2 is the GC thread. Is
>>     locking during GC forbidden?
>>
>>     William
>>
>>     Curt Hagenlocher wrote:
>>
>>         ...or, for that matter, any __del__ methods from within Python
>>         -- which ultimately are handled by finalization.
>>
>>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>>         wrote:
>>
>>            So, the obvious question for me is whether or not you're
>>         using any
>>            finalizers.
>>
>>
>>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>            <william at resolversystems.com
>>         <mailto:william at resolversystems.com>
>>         <mailto:william at resolversystems.com
>>         <mailto:william at resolversystems.com>>>
>>
>>            wrote:
>>
>>                Hi all
>>
>>                While running the numpy tests, I've come across a situation
>>                which, to the best of my knowledge, is simply
>>         impossible. I'm
>>                hoping that one of the local .NET gurus will be able to
>>         tell
>>                me what I'm missing, or point me somewhere I can get
>>         more insight.
>>
>>                The 4 methods involved are as follows:
>>                -----------------------
>>                      public int GetThreadId()
>>                      {
>>                          return Thread.CurrentThread.ManagedThreadId;
>>                      }
>>
>>                      public void WriteFlush(string info)
>>                      {
>>                          Console.WriteLine(info);
>>                          Console.Out.Flush();
>>                      }
>>
>>                      public void EnsureGIL()
>>                      {
>>                          Monitor.Enter(this.dispatcherLock);
>>                          this.WriteFlush(String.Format(
>>                              "EnsureGIL ({1}) {0}", this.GetThreadId(),
>>                Builtin.id(this.dispatcherLock)));
>>                      }
>>
>>                      public void ReleaseGIL()
>>                      {
>>                          this.WriteFlush(String.Format(
>>                              "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>>                Builtin.id(this.dispatcherLock)));
>>                          Monitor.Exit(this.dispatcherLock);
>>                      }
>>                -----------------------
>>                ...and they can, and do, occasionally produce output as
>>         follows:
>>                -----------------------
>>                EnsureGIL (443) 2
>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>                ReleaseGIL (443) 2
>>
>>                EnsureGIL (443) 2
>>                ReleaseGIL (443) 1
>>
>>                ReleaseGIL (443) 2
>>                -----------------------
>>                When this happens, the process continues happily for a
>>         short
>>                time and then falls over in a later call to ReleaseGIL
>>         (after
>>                successfully calling it several times). The error is "
>>         Object
>>                synchronization method was called from an
>>         unsynchronized block
>>                of code", which I understand to mean "you can't release
>>         this
>>                lock because you don't hold it".
>>
>>                It doesn't happen very often, but I can usually
>>         reproduce it
>>                by running
>>         test_multiarray.TestFromToFile.test_malformed a few
>>                hundred times. It may be relevant to note that thread 2
>>         is the
>>                GC thread, and thread 1 is the main thread. I have
>>         considered
>>                the following possibilities:
>>
>>                (1) That I'm locking on the wrong object. I believe
>>         that isn't
>>                the case, because it's constructed only once, as a "new
>>                Object()" (ie, a reference type), and is only subsequently
>>                used for locking; and, because it keeps the same ipy id
>>                throughout.
>>
>>                (2) That Monitor.Enter occasionally allows two different
>>                threads to acquire the same lock. I consider this extremely
>>                unlikely, because... well, how many multithreaded .NET apps
>>                already exist? If Monitor really were broken, I think we'd
>>                probably know about it by now.
>>
>>                (3) That calling Flush() on a SyncTextWriter (the type of
>>                Console.Out) doesn't actually do anything, and the
>>         output is
>>                somehow wrongly ordered (although I can't imagine how this
>>                could actually be: if the locking is really working,
>>         then my
>>                console writes are strictly sequential). I don't have
>>         access
>>                to the code, so I have no idea how it's implemented,
>>         but even
>>                if this is the case it doesn't help much with the
>>         fundamental
>>                problem (the synchronisation error which follows).
>>
>>                Apart from the above, I'm out of ideas. Can anyone suggest
>>                what I've missed?
>>
>>                William
>>                _______________________________________________
>>                Users mailing list
>>                Users at lists.ironpython.com
>>         <mailto:Users at lists.ironpython.com>
>>         <mailto:Users at lists.ironpython.com
>>         <mailto:Users at lists.ironpython.com>>
>>
>>
>>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>         ------------------------------------------------------------------------
>>
>>
>>
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.ironpython.com <mailto: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
>
>   



From curt at hagenlocher.org  Thu Nov  6 15:22:53 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 6 Nov 2008 07:22:53 -0700
Subject: [IronPython] Ironclad problem,
	with which someone here may be able to help
In-Reply-To: <4912F8AE.2020400@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
	<4911D49C.4050308@resolversystems.com>
	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
	<4911DF47.3020708@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4912F8AE.2020400@resolversystems.com>
Message-ID: <d2155e360811060622w5380696dl8bd15bfcc21a9445@mail.gmail.com>

When you run with -X:MTA, is the object now being finalized on a thread
other than thread #2?

On Thu, Nov 6, 2008 at 7:01 AM, William Reade
<william at resolversystems.com>wrote:

> Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
> reproduce the problem. However, this bothers me a bit: I'm not competent to
> follow all the consequences here, but this situation seems to imply that
> Ironclad won't be usable safely from any STA thread. Is this an intended
> restriction or a bug?
>
> Incidentally, tracking down the call stacks proved to be hard work: the
> timing changed enough that I only got a single failure over dozens of runs,
> and it turned out I'd got the logging wrong, so I didn't find out anything
> useful :(.
>
>
> Dino Viehland wrote:
>
>> I would suggest getting a snap shot of the call stacks when this is
>> happening if that's possible.  I can't pin anything down but I wonder if you
>> could have an STA object or something that otherwise requires message
>> pumping.  That message pumping could happen while you're doing a
>> Monitor.Enter call.  If that was happening maybe there is some subtle CLR
>> bug or a surprise feature?  It is surprising that Monitor.Enter can go
>> re-entrant but it can...
>>
>> So it'd be interesting to get thread snapshots and see if
>>
>>
>>
>>>               EnsureGIL (443) 2
>>>               EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>
>>>
>>
>> Could be happening because Thread 1 experiences contention, blocks and
>> pumps messages, causing the finalizer thread (2) to run, the lock is
>> acquired and ... ?
>>
>> Only other thing I could think of is does it repro on other machines?
>>  Maybe it's a hardware bug as unlikely as that seems?
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Wednesday, November 05, 2008 10:01 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Ironclad problem, with which someone here may be
>> able to help
>>
>> The log starts in the middle (after many lock/unlocks, some from each
>> thread); I'm running on x86; and I have no additional AppDomains.
>>
>> I don't think it would be safe for me to entirely avoid locking during
>> finalization, but I could probably cut it down to a quick lock, on a
>> separate object, to enqueue pointers for cleanup and deallocation on the
>> main thread. However, I'm reluctant to do that until I'm sure that the
>> problem is specifically related to GC, otherwise it'll just come back as
>> soon as anyone tries any serious multithreading :).
>>
>> Curt Hagenlocher wrote:
>>
>>
>>> Locking during finalization is often considered to be a bad idea.  In
>>> particular, locking without a timeout introduces the possibility that
>>> you will hang the finalization thread, preventing further objects from
>>> being finalized.  But clearly, that's not what's happening here.
>>>
>>> Other questions that probably don't matter but might be interesting to
>>> know:
>>>
>>> Can we assume that the finalization thread isn't the first place where
>>> this lock is required?  That your log starts somewhere in the middle?
>>>
>>> Is this under x86 or x64 or both?
>>>
>>> Are you creating any additional AppDomains in the process?
>>>
>>>
>>> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>>> <william at resolversystems.com <mailto:william at resolversystems.com>>
>>> wrote:
>>>
>>>    Hi Curt
>>>
>>>    I am indeed; that's how I know thread 2 is the GC thread. Is
>>>    locking during GC forbidden?
>>>
>>>    William
>>>
>>>    Curt Hagenlocher wrote:
>>>
>>>        ...or, for that matter, any __del__ methods from within Python
>>>        -- which ultimately are handled by finalization.
>>>
>>>        On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>>        <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>>        <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>>>        wrote:
>>>
>>>           So, the obvious question for me is whether or not you're
>>>        using any
>>>           finalizers.
>>>
>>>
>>>           On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>>           <william at resolversystems.com
>>>        <mailto:william at resolversystems.com>
>>>        <mailto:william at resolversystems.com
>>>        <mailto:william at resolversystems.com>>>
>>>
>>>           wrote:
>>>
>>>               Hi all
>>>
>>>               While running the numpy tests, I've come across a situation
>>>               which, to the best of my knowledge, is simply
>>>        impossible. I'm
>>>               hoping that one of the local .NET gurus will be able to
>>>        tell
>>>               me what I'm missing, or point me somewhere I can get
>>>        more insight.
>>>
>>>               The 4 methods involved are as follows:
>>>               -----------------------
>>>                     public int GetThreadId()
>>>                     {
>>>                         return Thread.CurrentThread.ManagedThreadId;
>>>                     }
>>>
>>>                     public void WriteFlush(string info)
>>>                     {
>>>                         Console.WriteLine(info);
>>>                         Console.Out.Flush();
>>>                     }
>>>
>>>                     public void EnsureGIL()
>>>                     {
>>>                         Monitor.Enter(this.dispatcherLock);
>>>                         this.WriteFlush(String.Format(
>>>                             "EnsureGIL ({1}) {0}", this.GetThreadId(),
>>>               Builtin.id(this.dispatcherLock)));
>>>                     }
>>>
>>>                     public void ReleaseGIL()
>>>                     {
>>>                         this.WriteFlush(String.Format(
>>>                             "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>>>               Builtin.id(this.dispatcherLock)));
>>>                         Monitor.Exit(this.dispatcherLock);
>>>                     }
>>>               -----------------------
>>>               ...and they can, and do, occasionally produce output as
>>>        follows:
>>>               -----------------------
>>>               EnsureGIL (443) 2
>>>               EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>               ReleaseGIL (443) 2
>>>
>>>               EnsureGIL (443) 2
>>>               ReleaseGIL (443) 1
>>>
>>>               ReleaseGIL (443) 2
>>>               -----------------------
>>>               When this happens, the process continues happily for a
>>>        short
>>>               time and then falls over in a later call to ReleaseGIL
>>>        (after
>>>               successfully calling it several times). The error is "
>>>        Object
>>>               synchronization method was called from an
>>>        unsynchronized block
>>>               of code", which I understand to mean "you can't release
>>>        this
>>>               lock because you don't hold it".
>>>
>>>               It doesn't happen very often, but I can usually
>>>        reproduce it
>>>               by running
>>>        test_multiarray.TestFromToFile.test_malformed a few
>>>               hundred times. It may be relevant to note that thread 2
>>>        is the
>>>               GC thread, and thread 1 is the main thread. I have
>>>        considered
>>>               the following possibilities:
>>>
>>>               (1) That I'm locking on the wrong object. I believe
>>>        that isn't
>>>               the case, because it's constructed only once, as a "new
>>>               Object()" (ie, a reference type), and is only subsequently
>>>               used for locking; and, because it keeps the same ipy id
>>>               throughout.
>>>
>>>               (2) That Monitor.Enter occasionally allows two different
>>>               threads to acquire the same lock. I consider this extremely
>>>               unlikely, because... well, how many multithreaded .NET apps
>>>               already exist? If Monitor really were broken, I think we'd
>>>               probably know about it by now.
>>>
>>>               (3) That calling Flush() on a SyncTextWriter (the type of
>>>               Console.Out) doesn't actually do anything, and the
>>>        output is
>>>               somehow wrongly ordered (although I can't imagine how this
>>>               could actually be: if the locking is really working,
>>>        then my
>>>               console writes are strictly sequential). I don't have
>>>        access
>>>               to the code, so I have no idea how it's implemented,
>>>        but even
>>>               if this is the case it doesn't help much with the
>>>        fundamental
>>>               problem (the synchronisation error which follows).
>>>
>>>               Apart from the above, I'm out of ideas. Can anyone suggest
>>>               what I've missed?
>>>
>>>               William
>>>               _______________________________________________
>>>               Users mailing list
>>>               Users at lists.ironpython.com
>>>        <mailto:Users at lists.ironpython.com>
>>>        <mailto:Users at lists.ironpython.com
>>>        <mailto:Users at lists.ironpython.com>>
>>>
>>>
>>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>
>>>  ------------------------------------------------------------------------
>>>
>>>
>>>
>>>        _______________________________________________
>>>        Users mailing list
>>>        Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>        http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>    _______________________________________________
>>>    Users mailing list
>>>    Users at lists.ironpython.com <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/dfdea92b/attachment.html>

From william at resolversystems.com  Thu Nov  6 16:29:17 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 06 Nov 2008 15:29:17 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <d2155e360811060622w5380696dl8bd15bfcc21a9445@mail.gmail.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>	<4911D49C.4050308@resolversystems.com>	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>	<4911DF47.3020708@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4912F8AE.2020400@resolversystems.com>
	<d2155e360811060622w5380696dl8bd15bfcc21a9445@mail.gmail.com>
Message-ID: <49130D4D.4050103@resolversystems.com>

Finalization still happens on thread 2, and I see no evidence of thread 
1 any more; my main thread now appears to have id 3.

Curt Hagenlocher wrote:
> When you run with -X:MTA, is the object now being finalized on a 
> thread other than thread #2?
>
> On Thu, Nov 6, 2008 at 7:01 AM, William Reade 
> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>
>     Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no
>     longer reproduce the problem. However, this bothers me a bit: I'm
>     not competent to follow all the consequences here, but this
>     situation seems to imply that Ironclad won't be usable safely from
>     any STA thread. Is this an intended restriction or a bug?
>
>     Incidentally, tracking down the call stacks proved to be hard
>     work: the timing changed enough that I only got a single failure
>     over dozens of runs, and it turned out I'd got the logging wrong,
>     so I didn't find out anything useful :(.
>
>
>     Dino Viehland wrote:
>
>         I would suggest getting a snap shot of the call stacks when
>         this is happening if that's possible.  I can't pin anything
>         down but I wonder if you could have an STA object or something
>         that otherwise requires message pumping.  That message pumping
>         could happen while you're doing a Monitor.Enter call.  If that
>         was happening maybe there is some subtle CLR bug or a surprise
>         feature?  It is surprising that Monitor.Enter can go
>         re-entrant but it can...
>
>         So it'd be interesting to get thread snapshots and see if
>
>          
>
>                           EnsureGIL (443) 2
>                           EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>                
>
>
>         Could be happening because Thread 1 experiences contention,
>         blocks and pumps messages, causing the finalizer thread (2) to
>         run, the lock is acquired and ... ?
>
>         Only other thing I could think of is does it repro on other
>         machines?  Maybe it's a hardware bug as unlikely as that seems?
>
>         -----Original Message-----
>         From: users-bounces at lists.ironpython.com
>         <mailto:users-bounces at lists.ironpython.com>
>         [mailto:users-bounces at lists.ironpython.com
>         <mailto:users-bounces at lists.ironpython.com>] On Behalf Of
>         William Reade
>         Sent: Wednesday, November 05, 2008 10:01 AM
>         To: Discussion of IronPython
>         Subject: Re: [IronPython] Ironclad problem, with which someone
>         here may be able to help
>
>         The log starts in the middle (after many lock/unlocks, some
>         from each
>         thread); I'm running on x86; and I have no additional AppDomains.
>
>         I don't think it would be safe for me to entirely avoid
>         locking during
>         finalization, but I could probably cut it down to a quick
>         lock, on a
>         separate object, to enqueue pointers for cleanup and
>         deallocation on the
>         main thread. However, I'm reluctant to do that until I'm sure
>         that the
>         problem is specifically related to GC, otherwise it'll just
>         come back as
>         soon as anyone tries any serious multithreading :).
>
>         Curt Hagenlocher wrote:
>          
>
>             Locking during finalization is often considered to be a
>             bad idea.  In
>             particular, locking without a timeout introduces the
>             possibility that
>             you will hang the finalization thread, preventing further
>             objects from
>             being finalized.  But clearly, that's not what's happening
>             here.
>
>             Other questions that probably don't matter but might be
>             interesting to
>             know:
>
>             Can we assume that the finalization thread isn't the first
>             place where
>             this lock is required?  That your log starts somewhere in
>             the middle?
>
>             Is this under x86 or x64 or both?
>
>             Are you creating any additional AppDomains in the process?
>
>
>             On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>             <william at resolversystems.com
>             <mailto:william at resolversystems.com>
>             <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>>> wrote:
>
>                Hi Curt
>
>                I am indeed; that's how I know thread 2 is the GC
>             thread. Is
>                locking during GC forbidden?
>
>                William
>
>                Curt Hagenlocher wrote:
>
>                    ...or, for that matter, any __del__ methods from
>             within Python
>                    -- which ultimately are handled by finalization.
>
>                    On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>                    <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>             <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>
>                    <mailto:curt at hagenlocher.org
>             <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org
>             <mailto:curt at hagenlocher.org>>>>
>                    wrote:
>
>                       So, the obvious question for me is whether or
>             not you're
>                    using any
>                       finalizers.
>
>
>                       On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>                       <william at resolversystems.com
>             <mailto:william at resolversystems.com>
>                    <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>>
>                    <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>
>                    <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>>>>
>
>                       wrote:
>
>                           Hi all
>
>                           While running the numpy tests, I've come
>             across a situation
>                           which, to the best of my knowledge, is simply
>                    impossible. I'm
>                           hoping that one of the local .NET gurus will
>             be able to
>                    tell
>                           me what I'm missing, or point me somewhere I
>             can get
>                    more insight.
>
>                           The 4 methods involved are as follows:
>                           -----------------------
>                                 public int GetThreadId()
>                                 {
>                                     return
>             Thread.CurrentThread.ManagedThreadId;
>                                 }
>
>                                 public void WriteFlush(string info)
>                                 {
>                                     Console.WriteLine(info);
>                                     Console.Out.Flush();
>                                 }
>
>                                 public void EnsureGIL()
>                                 {
>                                     Monitor.Enter(this.dispatcherLock);
>                                     this.WriteFlush(String.Format(
>                                         "EnsureGIL ({1}) {0}",
>             this.GetThreadId(),
>                           Builtin.id(this.dispatcherLock)));
>                                 }
>
>                                 public void ReleaseGIL()
>                                 {
>                                     this.WriteFlush(String.Format(
>                                         "ReleaseGIL ({1}) {0}\n",
>             this.GetThreadId(),
>                           Builtin.id(this.dispatcherLock)));
>                                     Monitor.Exit(this.dispatcherLock);
>                                 }
>                           -----------------------
>                           ...and they can, and do, occasionally
>             produce output as
>                    follows:
>                           -----------------------
>                           EnsureGIL (443) 2
>                           EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>                           ReleaseGIL (443) 2
>
>                           EnsureGIL (443) 2
>                           ReleaseGIL (443) 1
>
>                           ReleaseGIL (443) 2
>                           -----------------------
>                           When this happens, the process continues
>             happily for a
>                    short
>                           time and then falls over in a later call to
>             ReleaseGIL
>                    (after
>                           successfully calling it several times). The
>             error is "
>                    Object
>                           synchronization method was called from an
>                    unsynchronized block
>                           of code", which I understand to mean "you
>             can't release
>                    this
>                           lock because you don't hold it".
>
>                           It doesn't happen very often, but I can usually
>                    reproduce it
>                           by running
>                    test_multiarray.TestFromToFile.test_malformed a few
>                           hundred times. It may be relevant to note
>             that thread 2
>                    is the
>                           GC thread, and thread 1 is the main thread.
>             I have
>                    considered
>                           the following possibilities:
>
>                           (1) That I'm locking on the wrong object. I
>             believe
>                    that isn't
>                           the case, because it's constructed only
>             once, as a "new
>                           Object()" (ie, a reference type), and is
>             only subsequently
>                           used for locking; and, because it keeps the
>             same ipy id
>                           throughout.
>
>                           (2) That Monitor.Enter occasionally allows
>             two different
>                           threads to acquire the same lock. I consider
>             this extremely
>                           unlikely, because... well, how many
>             multithreaded .NET apps
>                           already exist? If Monitor really were
>             broken, I think we'd
>                           probably know about it by now.
>
>                           (3) That calling Flush() on a SyncTextWriter
>             (the type of
>                           Console.Out) doesn't actually do anything,
>             and the
>                    output is
>                           somehow wrongly ordered (although I can't
>             imagine how this
>                           could actually be: if the locking is really
>             working,
>                    then my
>                           console writes are strictly sequential). I
>             don't have
>                    access
>                           to the code, so I have no idea how it's
>             implemented,
>                    but even
>                           if this is the case it doesn't help much
>             with the
>                    fundamental
>                           problem (the synchronisation error which
>             follows).
>
>                           Apart from the above, I'm out of ideas. Can
>             anyone suggest
>                           what I've missed?
>
>                           William
>                           _______________________________________________
>                           Users mailing list
>                           Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>                    <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>
>                    <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>                    <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>>
>
>
>                    
>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>                  
>              ------------------------------------------------------------------------
>
>
>
>                    _______________________________________________
>                    Users mailing list
>                    Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>             <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>
>                  
>              http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>                _______________________________________________
>                Users mailing list
>                Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>             <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>
>              
>              http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>             ------------------------------------------------------------------------
>
>             _______________________________________________
>             Users mailing list
>             Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>                
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>          
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>   



From william at resolversystems.com  Thu Nov  6 17:58:10 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 06 Nov 2008 16:58:10 +0000
Subject: [IronPython] trivial long() bug
Message-ID: <49132222.3030806@resolversystems.com>

CPy:
 >>> long('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for long() with base 10: ''

IPy:
 >>> long('')
0L


From miha.valencic at gmail.com  Thu Nov  6 18:07:57 2008
From: miha.valencic at gmail.com (Miha Valencic)
Date: Thu, 6 Nov 2008 18:07:57 +0100
Subject: [IronPython] Extension methods in python
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <233dfa1d0811060907n35eeb6f1p987f02df6cc573a9@mail.gmail.com>

Marty, from what I understand you are passing a variable into python engine
and want extension methods there? You can use something like that:

import clr
import System

class MyString(System.String):
  pass;

  def ToFoo(self):
    return self.upper()+' FooBarBaz'


a = MyString("Hello world!");
print a.ToFoo();



That would print "HELLO WORLD! FooBarBaz.

You can't put methods on System.String though, but you can create new object
from System.String...

Miha

2008/11/5 Marty Nelson <Marty.Nelson at symyx.com>

>  Is there the equivalent of extension method in python?  I want to put a
> variable into the script scope and create extension methods for it.  Does
> this make sense and is it possible?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/04fadd0c/attachment.html>

From dinov at microsoft.com  Thu Nov  6 19:36:32 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 6 Nov 2008 10:36:32 -0800
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <49130D4D.4050103@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
	<4911D49C.4050308@resolversystems.com>
	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
	<4911DF47.3020708@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4912F8AE.2020400@resolversystems.com>
	<d2155e360811060622w5380696dl8bd15bfcc21a9445@mail.gmail.com>
	<49130D4D.4050103@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FAC8@NA-EXMSG-C102.redmond.corp.microsoft.com>

In MTA mode we'll create a new thread which is thread 3 - thread 1 will just be hanging around waiting for it to exit.  Unfortunately w/o a separate EXE we can't avoid the separate thread.

I've pinged the CLR dev who owns interop these days to see if he's ever seen anything like this.  Unfortunately he's OOF until the 10th.  My best suggestion for the time being is to avoid using Monitor for this lock so that you don't pump messages.  That's probably going to mean writing your own lock and then P/Invoking to WaitForSingleObject when you experience contention and need to block the thread.  Using an AutoResetEvent or ManualResetEvent directly won't work because we'll pump messages there too!

I would also suggest looking at what CPython does here.  Dumpbin /imports python.exe shows no imports from ole32 so I'm guessing they don't do anything to spin up COM - which makes sense.  I would therefore assume when acquiring the GIL CPython will never pump messages and therefore programs don't expect possible re-entrancy - it'd probably be a good idea to mimic that behavior :).  Unfortunately there are other places where we use Monitor in IronPython - list.append comes to mind.  It'll be interesting to see if that turns out to be a problem eventually as well.

Anyway, I'll let you know when I hear back.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Thursday, November 06, 2008 7:29 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help

Finalization still happens on thread 2, and I see no evidence of thread
1 any more; my main thread now appears to have id 3.

Curt Hagenlocher wrote:
> When you run with -X:MTA, is the object now being finalized on a
> thread other than thread #2?
>
> On Thu, Nov 6, 2008 at 7:01 AM, William Reade
> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>
>     Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no
>     longer reproduce the problem. However, this bothers me a bit: I'm
>     not competent to follow all the consequences here, but this
>     situation seems to imply that Ironclad won't be usable safely from
>     any STA thread. Is this an intended restriction or a bug?
>
>     Incidentally, tracking down the call stacks proved to be hard
>     work: the timing changed enough that I only got a single failure
>     over dozens of runs, and it turned out I'd got the logging wrong,
>     so I didn't find out anything useful :(.
>
>
>     Dino Viehland wrote:
>
>         I would suggest getting a snap shot of the call stacks when
>         this is happening if that's possible.  I can't pin anything
>         down but I wonder if you could have an STA object or something
>         that otherwise requires message pumping.  That message pumping
>         could happen while you're doing a Monitor.Enter call.  If that
>         was happening maybe there is some subtle CLR bug or a surprise
>         feature?  It is surprising that Monitor.Enter can go
>         re-entrant but it can...
>
>         So it'd be interesting to get thread snapshots and see if
>
>
>
>                           EnsureGIL (443) 2
>                           EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>
>
>
>         Could be happening because Thread 1 experiences contention,
>         blocks and pumps messages, causing the finalizer thread (2) to
>         run, the lock is acquired and ... ?
>
>         Only other thing I could think of is does it repro on other
>         machines?  Maybe it's a hardware bug as unlikely as that seems?
>
>         -----Original Message-----
>         From: users-bounces at lists.ironpython.com
>         <mailto:users-bounces at lists.ironpython.com>
>         [mailto:users-bounces at lists.ironpython.com
>         <mailto:users-bounces at lists.ironpython.com>] On Behalf Of
>         William Reade
>         Sent: Wednesday, November 05, 2008 10:01 AM
>         To: Discussion of IronPython
>         Subject: Re: [IronPython] Ironclad problem, with which someone
>         here may be able to help
>
>         The log starts in the middle (after many lock/unlocks, some
>         from each
>         thread); I'm running on x86; and I have no additional AppDomains.
>
>         I don't think it would be safe for me to entirely avoid
>         locking during
>         finalization, but I could probably cut it down to a quick
>         lock, on a
>         separate object, to enqueue pointers for cleanup and
>         deallocation on the
>         main thread. However, I'm reluctant to do that until I'm sure
>         that the
>         problem is specifically related to GC, otherwise it'll just
>         come back as
>         soon as anyone tries any serious multithreading :).
>
>         Curt Hagenlocher wrote:
>
>
>             Locking during finalization is often considered to be a
>             bad idea.  In
>             particular, locking without a timeout introduces the
>             possibility that
>             you will hang the finalization thread, preventing further
>             objects from
>             being finalized.  But clearly, that's not what's happening
>             here.
>
>             Other questions that probably don't matter but might be
>             interesting to
>             know:
>
>             Can we assume that the finalization thread isn't the first
>             place where
>             this lock is required?  That your log starts somewhere in
>             the middle?
>
>             Is this under x86 or x64 or both?
>
>             Are you creating any additional AppDomains in the process?
>
>
>             On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>             <william at resolversystems.com
>             <mailto:william at resolversystems.com>
>             <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>>> wrote:
>
>                Hi Curt
>
>                I am indeed; that's how I know thread 2 is the GC
>             thread. Is
>                locking during GC forbidden?
>
>                William
>
>                Curt Hagenlocher wrote:
>
>                    ...or, for that matter, any __del__ methods from
>             within Python
>                    -- which ultimately are handled by finalization.
>
>                    On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>                    <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>             <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>
>                    <mailto:curt at hagenlocher.org
>             <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org
>             <mailto:curt at hagenlocher.org>>>>
>                    wrote:
>
>                       So, the obvious question for me is whether or
>             not you're
>                    using any
>                       finalizers.
>
>
>                       On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>                       <william at resolversystems.com
>             <mailto:william at resolversystems.com>
>                    <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>>
>                    <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>
>                    <mailto:william at resolversystems.com
>             <mailto:william at resolversystems.com>>>>
>
>                       wrote:
>
>                           Hi all
>
>                           While running the numpy tests, I've come
>             across a situation
>                           which, to the best of my knowledge, is simply
>                    impossible. I'm
>                           hoping that one of the local .NET gurus will
>             be able to
>                    tell
>                           me what I'm missing, or point me somewhere I
>             can get
>                    more insight.
>
>                           The 4 methods involved are as follows:
>                           -----------------------
>                                 public int GetThreadId()
>                                 {
>                                     return
>             Thread.CurrentThread.ManagedThreadId;
>                                 }
>
>                                 public void WriteFlush(string info)
>                                 {
>                                     Console.WriteLine(info);
>                                     Console.Out.Flush();
>                                 }
>
>                                 public void EnsureGIL()
>                                 {
>                                     Monitor.Enter(this.dispatcherLock);
>                                     this.WriteFlush(String.Format(
>                                         "EnsureGIL ({1}) {0}",
>             this.GetThreadId(),
>                           Builtin.id(this.dispatcherLock)));
>                                 }
>
>                                 public void ReleaseGIL()
>                                 {
>                                     this.WriteFlush(String.Format(
>                                         "ReleaseGIL ({1}) {0}\n",
>             this.GetThreadId(),
>                           Builtin.id(this.dispatcherLock)));
>                                     Monitor.Exit(this.dispatcherLock);
>                                 }
>                           -----------------------
>                           ...and they can, and do, occasionally
>             produce output as
>                    follows:
>                           -----------------------
>                           EnsureGIL (443) 2
>                           EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>                           ReleaseGIL (443) 2
>
>                           EnsureGIL (443) 2
>                           ReleaseGIL (443) 1
>
>                           ReleaseGIL (443) 2
>                           -----------------------
>                           When this happens, the process continues
>             happily for a
>                    short
>                           time and then falls over in a later call to
>             ReleaseGIL
>                    (after
>                           successfully calling it several times). The
>             error is "
>                    Object
>                           synchronization method was called from an
>                    unsynchronized block
>                           of code", which I understand to mean "you
>             can't release
>                    this
>                           lock because you don't hold it".
>
>                           It doesn't happen very often, but I can usually
>                    reproduce it
>                           by running
>                    test_multiarray.TestFromToFile.test_malformed a few
>                           hundred times. It may be relevant to note
>             that thread 2
>                    is the
>                           GC thread, and thread 1 is the main thread.
>             I have
>                    considered
>                           the following possibilities:
>
>                           (1) That I'm locking on the wrong object. I
>             believe
>                    that isn't
>                           the case, because it's constructed only
>             once, as a "new
>                           Object()" (ie, a reference type), and is
>             only subsequently
>                           used for locking; and, because it keeps the
>             same ipy id
>                           throughout.
>
>                           (2) That Monitor.Enter occasionally allows
>             two different
>                           threads to acquire the same lock. I consider
>             this extremely
>                           unlikely, because... well, how many
>             multithreaded .NET apps
>                           already exist? If Monitor really were
>             broken, I think we'd
>                           probably know about it by now.
>
>                           (3) That calling Flush() on a SyncTextWriter
>             (the type of
>                           Console.Out) doesn't actually do anything,
>             and the
>                    output is
>                           somehow wrongly ordered (although I can't
>             imagine how this
>                           could actually be: if the locking is really
>             working,
>                    then my
>                           console writes are strictly sequential). I
>             don't have
>                    access
>                           to the code, so I have no idea how it's
>             implemented,
>                    but even
>                           if this is the case it doesn't help much
>             with the
>                    fundamental
>                           problem (the synchronisation error which
>             follows).
>
>                           Apart from the above, I'm out of ideas. Can
>             anyone suggest
>                           what I've missed?
>
>                           William
>                           _______________________________________________
>                           Users mailing list
>                           Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>                    <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>
>                    <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>                    <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>>
>
>
>
>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
>              ------------------------------------------------------------------------
>
>
>
>                    _______________________________________________
>                    Users mailing list
>                    Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>             <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>
>
>              http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>                _______________________________________________
>                Users mailing list
>                Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>
>             <mailto:Users at lists.ironpython.com
>             <mailto:Users at lists.ironpython.com>>
>
>              http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>             ------------------------------------------------------------------------
>
>             _______________________________________________
>             Users mailing list
>             Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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


From dinov at microsoft.com  Thu Nov  6 19:43:56 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 6 Nov 2008 10:43:56 -0800
Subject: [IronPython] trivial long() bug
In-Reply-To: <49132222.3030806@resolversystems.com>
References: <49132222.3030806@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FAD4@NA-EXMSG-C102.redmond.corp.microsoft.com>

Thanks, I've filed this as CodePlex #19363 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19363)


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Thursday, November 06, 2008 8:58 AM
To: Discussion of IronPython
Subject: [IronPython] trivial long() bug

CPy:
 >>> long('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for long() with base 10: ''

IPy:
 >>> long('')
0L
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From oripel at gmail.com  Thu Nov  6 23:27:05 2008
From: oripel at gmail.com (Ori Peleg)
Date: Fri, 7 Nov 2008 00:27:05 +0200
Subject: [IronPython] Porting from CPython: Figuring out the calling code's
	directory
In-Reply-To: <620765220811060643w681ee9dap924500cde40c4c61@mail.gmail.com>
References: <620765220811060643w681ee9dap924500cde40c4c61@mail.gmail.com>
Message-ID: <620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com>

Hi,

I'm porting Testoob to IronPython and have a module function that needs to
know the filename where the code calling it is defined.

In CPython I get the current frame with sys._getframe(), then climb
the stack with frame.f_back until I find a different file:

def _first_external_frame():
   import sys

   # find the first frame with a filename different than this one
   frame = sys._getframe()
   while frame.f_globals["__file__"] == __file__:
       frame = frame.f_back

   return frame

def _calling_module_directory():
   from os.path import dirname, normpath
   return normpath(dirname(_first_external_frame().f_globals["__file__"]))

I know I can't climb the stack in IronPython, but is there another way
to do it? Maybe some available .NET assembly metadata?

BTW - the use case is for building test suites: you can have a
subpackage of tests and define __init__.py like this:

def suite():
   import testoob
   return testoob.collecting.collect_from_files("test_*.py")

Thanks,
orip.

-- 
Check out my blog: http://orip.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081107/b64b13d3/attachment.html>

From dinov at microsoft.com  Fri Nov  7 00:24:13 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 6 Nov 2008 15:24:13 -0800
Subject: [IronPython] Porting from CPython: Figuring out the calling
 code's	directory
In-Reply-To: <620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com>
References: <620765220811060643w681ee9dap924500cde40c4c61@mail.gmail.com>
	<620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FD1B@NA-EXMSG-C102.redmond.corp.microsoft.com>

The short answer is no ? we realize frames is a common request and I do have a prototype implementation of them.  We?re still working on our 2.1 planning  but it might be available there w/ a command line option or it might be something we could port to 2.0.1.

The longer answer would be potentially with a lot of work and it could be quite slow.  You could walk every module, every function, every class and attempt to gather up all the function objects in the world.  Then you could call PythonOps.FunctionGetTarget on each one of them.  Finally you could do a full .NET stack trace (new System.Diagnostics.StackTrace()) and attempt to figure your caller by filtering out any IronPython/DLR frames.  Finally once you have that method you could see if that method is == the .Method property of any of the delegates you got from FunctionGetTarget calls.  And I?m not even 100% sure if that?d work ? the delegates for a PythonFunction might have a different MethodInfo then the one in the stack trace but I?m not certain (if this is the case it?d be due to the way CLR hides DynamicMethod MethodInfo?s so only the creator has access to them ? you might be able to use some hack like a name comparison heuristic or private reflection or something to bring it all together).

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ori Peleg
Sent: Thursday, November 06, 2008 2:27 PM
To: users at lists.ironpython.com
Subject: [IronPython] Porting from CPython: Figuring out the calling code's directory

Hi,

I'm porting Testoob to IronPython and have a module function that needs to know the filename where the code calling it is defined.

In CPython I get the current frame with sys._getframe(), then climb
the stack with frame.f_back until I find a different file:

def _first_external_frame():
   import sys

   # find the first frame with a filename different than this one
   frame = sys._getframe()
   while frame.f_globals["__file__"] == __file__:
       frame = frame.f_back

   return frame

def _calling_module_directory():
   from os.path import dirname, normpath
   return normpath(dirname(_first_external_frame().f_globals["__file__"]))

I know I can't climb the stack in IronPython, but is there another way
to do it? Maybe some available .NET assembly metadata?

BTW - the use case is for building test suites: you can have a
subpackage of tests and define __init__.py like this:

def suite():
   import testoob
   return testoob.collecting.collect_from_files("test_*.py")

Thanks,
orip.

--
Check out my blog: http://orip.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/66c14bf3/attachment.html>

From dinov at microsoft.com  Fri Nov  7 03:56:15 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 6 Nov 2008 18:56:15 -0800
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <4912F8AE.2020400@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
	<4911D49C.4050308@resolversystems.com>
	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
	<4911DF47.3020708@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4912F8AE.2020400@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FDDA@NA-EXMSG-C102.redmond.corp.microsoft.com>

Do you know if numpy is using COM anywhere?  Or does Ironclad use COM for any of its interop?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Thursday, November 06, 2008 6:01 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help

Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
reproduce the problem. However, this bothers me a bit: I'm not competent
to follow all the consequences here, but this situation seems to imply
that Ironclad won't be usable safely from any STA thread. Is this an
intended restriction or a bug?

Incidentally, tracking down the call stacks proved to be hard work: the
timing changed enough that I only got a single failure over dozens of
runs, and it turned out I'd got the logging wrong, so I didn't find out
anything useful :(.

Dino Viehland wrote:
> I would suggest getting a snap shot of the call stacks when this is happening if that's possible.  I can't pin anything down but I wonder if you could have an STA object or something that otherwise requires message pumping.  That message pumping could happen while you're doing a Monitor.Enter call.  If that was happening maybe there is some subtle CLR bug or a surprise feature?  It is surprising that Monitor.Enter can go re-entrant but it can...
>
> So it'd be interesting to get thread snapshots and see if
>
>
>>                EnsureGIL (443) 2
>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>
>
> Could be happening because Thread 1 experiences contention, blocks and pumps messages, causing the finalizer thread (2) to run, the lock is acquired and ... ?
>
> Only other thing I could think of is does it repro on other machines?  Maybe it's a hardware bug as unlikely as that seems?
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Wednesday, November 05, 2008 10:01 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help
>
> The log starts in the middle (after many lock/unlocks, some from each
> thread); I'm running on x86; and I have no additional AppDomains.
>
> I don't think it would be safe for me to entirely avoid locking during
> finalization, but I could probably cut it down to a quick lock, on a
> separate object, to enqueue pointers for cleanup and deallocation on the
> main thread. However, I'm reluctant to do that until I'm sure that the
> problem is specifically related to GC, otherwise it'll just come back as
> soon as anyone tries any serious multithreading :).
>
> Curt Hagenlocher wrote:
>
>> Locking during finalization is often considered to be a bad idea.  In
>> particular, locking without a timeout introduces the possibility that
>> you will hang the finalization thread, preventing further objects from
>> being finalized.  But clearly, that's not what's happening here.
>>
>> Other questions that probably don't matter but might be interesting to
>> know:
>>
>> Can we assume that the finalization thread isn't the first place where
>> this lock is required?  That your log starts somewhere in the middle?
>>
>> Is this under x86 or x64 or both?
>>
>> Are you creating any additional AppDomains in the process?
>>
>>
>> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>>
>>     Hi Curt
>>
>>     I am indeed; that's how I know thread 2 is the GC thread. Is
>>     locking during GC forbidden?
>>
>>     William
>>
>>     Curt Hagenlocher wrote:
>>
>>         ...or, for that matter, any __del__ methods from within Python
>>         -- which ultimately are handled by finalization.
>>
>>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>>         wrote:
>>
>>            So, the obvious question for me is whether or not you're
>>         using any
>>            finalizers.
>>
>>
>>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>            <william at resolversystems.com
>>         <mailto:william at resolversystems.com>
>>         <mailto:william at resolversystems.com
>>         <mailto:william at resolversystems.com>>>
>>
>>            wrote:
>>
>>                Hi all
>>
>>                While running the numpy tests, I've come across a situation
>>                which, to the best of my knowledge, is simply
>>         impossible. I'm
>>                hoping that one of the local .NET gurus will be able to
>>         tell
>>                me what I'm missing, or point me somewhere I can get
>>         more insight.
>>
>>                The 4 methods involved are as follows:
>>                -----------------------
>>                      public int GetThreadId()
>>                      {
>>                          return Thread.CurrentThread.ManagedThreadId;
>>                      }
>>
>>                      public void WriteFlush(string info)
>>                      {
>>                          Console.WriteLine(info);
>>                          Console.Out.Flush();
>>                      }
>>
>>                      public void EnsureGIL()
>>                      {
>>                          Monitor.Enter(this.dispatcherLock);
>>                          this.WriteFlush(String.Format(
>>                              "EnsureGIL ({1}) {0}", this.GetThreadId(),
>>                Builtin.id(this.dispatcherLock)));
>>                      }
>>
>>                      public void ReleaseGIL()
>>                      {
>>                          this.WriteFlush(String.Format(
>>                              "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>>                Builtin.id(this.dispatcherLock)));
>>                          Monitor.Exit(this.dispatcherLock);
>>                      }
>>                -----------------------
>>                ...and they can, and do, occasionally produce output as
>>         follows:
>>                -----------------------
>>                EnsureGIL (443) 2
>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>                ReleaseGIL (443) 2
>>
>>                EnsureGIL (443) 2
>>                ReleaseGIL (443) 1
>>
>>                ReleaseGIL (443) 2
>>                -----------------------
>>                When this happens, the process continues happily for a
>>         short
>>                time and then falls over in a later call to ReleaseGIL
>>         (after
>>                successfully calling it several times). The error is "
>>         Object
>>                synchronization method was called from an
>>         unsynchronized block
>>                of code", which I understand to mean "you can't release
>>         this
>>                lock because you don't hold it".
>>
>>                It doesn't happen very often, but I can usually
>>         reproduce it
>>                by running
>>         test_multiarray.TestFromToFile.test_malformed a few
>>                hundred times. It may be relevant to note that thread 2
>>         is the
>>                GC thread, and thread 1 is the main thread. I have
>>         considered
>>                the following possibilities:
>>
>>                (1) That I'm locking on the wrong object. I believe
>>         that isn't
>>                the case, because it's constructed only once, as a "new
>>                Object()" (ie, a reference type), and is only subsequently
>>                used for locking; and, because it keeps the same ipy id
>>                throughout.
>>
>>                (2) That Monitor.Enter occasionally allows two different
>>                threads to acquire the same lock. I consider this extremely
>>                unlikely, because... well, how many multithreaded .NET apps
>>                already exist? If Monitor really were broken, I think we'd
>>                probably know about it by now.
>>
>>                (3) That calling Flush() on a SyncTextWriter (the type of
>>                Console.Out) doesn't actually do anything, and the
>>         output is
>>                somehow wrongly ordered (although I can't imagine how this
>>                could actually be: if the locking is really working,
>>         then my
>>                console writes are strictly sequential). I don't have
>>         access
>>                to the code, so I have no idea how it's implemented,
>>         but even
>>                if this is the case it doesn't help much with the
>>         fundamental
>>                problem (the synchronisation error which follows).
>>
>>                Apart from the above, I'm out of ideas. Can anyone suggest
>>                what I've missed?
>>
>>                William
>>                _______________________________________________
>>                Users mailing list
>>                Users at lists.ironpython.com
>>         <mailto:Users at lists.ironpython.com>
>>         <mailto:Users at lists.ironpython.com
>>         <mailto:Users at lists.ironpython.com>>
>>
>>
>>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>         ------------------------------------------------------------------------
>>
>>
>>
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.ironpython.com <mailto: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


From Marty.Nelson at symyx.com  Fri Nov  7 04:18:25 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Thu, 6 Nov 2008 19:18:25 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <233dfa1d0811060907n35eeb6f1p987f02df6cc573a9@mail.gmail.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
	<233dfa1d0811060907n35eeb6f1p987f02df6cc573a9@mail.gmail.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03B31E57@srv-be-101.Symyx-IC.symyx.com>


I actually want to use an object instance of a .NET custom class that I
pass in before the script is invoked from c#.  Our current scripts look
something like:

 

row.PropertySet["Foo"]["Bar"].Value = x

 

and it would be much better if script authors could write:

 

row.Foo.Bar = x

 

So I'm looking to have an on the fly function read the metadata of
expected keys and then code generated python class wrapper for the
script author to consume. 

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Miha Valencic
Sent: Thursday, November 06, 2008 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

 

Marty, from what I understand you are passing a variable into python
engine and want extension methods there? You can use something like
that:

import clr
import System

class MyString(System.String):
  pass;

  def ToFoo(self):
    return self.upper()+' FooBarBaz'


a = MyString("Hello world!");
print a.ToFoo();



That would print "HELLO WORLD! FooBarBaz.

You can't put methods on System.String though, but you can create new
object from System.String...

Miha

2008/11/5 Marty Nelson <Marty.Nelson at symyx.com>

Is there the equivalent of extension method in python?  I want to put a
variable into the script scope and create extension methods for it.
Does this make sense and is it possible?

 



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/80d982b8/attachment.html>

From dinov at microsoft.com  Fri Nov  7 04:20:23 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 6 Nov 2008 19:20:23 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03B31E57@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com>
	<233dfa1d0811060907n35eeb6f1p987f02df6cc573a9@mail.gmail.com>
	<515335F32AA04440B3DE6FEA1993E9AD03B31E57@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FDE4@NA-EXMSG-C102.redmond.corp.microsoft.com>

By custom class you mean a class you've written?  And then you want it to "light up" with dynamic languages?

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Thursday, November 06, 2008 7:18 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

I actually want to use an object instance of a .NET custom class that I pass in before the script is invoked from c#.  Our current scripts look something like:

row.PropertySet["Foo"]["Bar"].Value = x

and it would be much better if script authors could write:

row.Foo.Bar = x

So I'm looking to have an on the fly function read the metadata of expected keys and then code generated python class wrapper for the script author to consume.

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Miha Valencic
Sent: Thursday, November 06, 2008 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

Marty, from what I understand you are passing a variable into python engine and want extension methods there? You can use something like that:

import clr
import System

class MyString(System.String):
  pass;

  def ToFoo(self):
    return self.upper()+' FooBarBaz'


a = MyString("Hello world!");
print a.ToFoo();



That would print "HELLO WORLD! FooBarBaz.

You can't put methods on System.String though, but you can create new object from System.String...

Miha
2008/11/5 Marty Nelson <Marty.Nelson at symyx.com<mailto:Marty.Nelson at symyx.com>>

Is there the equivalent of extension method in python?  I want to put a variable into the script scope and create extension methods for it.  Does this make sense and is it possible?

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/820b1745/attachment.html>

From Marty.Nelson at symyx.com  Fri Nov  7 05:02:13 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Thu, 6 Nov 2008 20:02:13 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735FDE4@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com><233dfa1d0811060907n35eeb6f1p987f02df6cc573a9@mail.gmail.com><515335F32AA04440B3DE6FEA1993E9AD03B31E57@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC23554FF735FDE4@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03B31E6A@srv-be-101.Symyx-IC.symyx.com>

Like a Christmas tree.

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, November 06, 2008 7:20 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

 

By custom class you mean a class you've written?  And then you want it
to "light up" with dynamic languages?

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Thursday, November 06, 2008 7:18 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

 

I actually want to use an object instance of a .NET custom class that I
pass in before the script is invoked from c#.  Our current scripts look
something like:

 

row.PropertySet["Foo"]["Bar"].Value = x

 

and it would be much better if script authors could write:

 

row.Foo.Bar = x

 

So I'm looking to have an on the fly function read the metadata of
expected keys and then code generated python class wrapper for the
script author to consume. 

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Miha Valencic
Sent: Thursday, November 06, 2008 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

 

Marty, from what I understand you are passing a variable into python
engine and want extension methods there? You can use something like
that:

import clr
import System

class MyString(System.String):
  pass;

  def ToFoo(self):
    return self.upper()+' FooBarBaz'


a = MyString("Hello world!");
print a.ToFoo();



That would print "HELLO WORLD! FooBarBaz.

You can't put methods on System.String though, but you can create new
object from System.String...

Miha

2008/11/5 Marty Nelson <Marty.Nelson at symyx.com>

Is there the equivalent of extension method in python?  I want to put a
variable into the script scope and create extension methods for it.
Does this make sense and is it possible?

 

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081106/68c6432e/attachment.html>

From dinov at microsoft.com  Fri Nov  7 05:26:08 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 6 Nov 2008 20:26:08 -0800
Subject: [IronPython] Extension methods in python
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03B31E6A@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03AD701C@srv-be-101.Symyx-IC.symyx.com><233dfa1d0811060907n35eeb6f1p987f02df6cc573a9@mail.gmail.com><515335F32AA04440B3DE6FEA1993E9AD03B31E57@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC23554FF735FDE4@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<515335F32AA04440B3DE6FEA1993E9AD03B31E6A@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FDFE@NA-EXMSG-C102.redmond.corp.microsoft.com>

Ok, you don?t want extension methods, you want a dynamic object, and the good and bad news is there are a few options ?

Let's start with the "correct" options first.  If you can change the base class the easiest thing to do would be to subclass Microsoft.Scripting.Actions.Dynamic.  Then you can override GetMember and return another subclass of Dynamic which overrides SetMember and enables .Bar = value to work.

If you can?t change the subclass then you need to implement IDynamicObject.  There?s only one method to implement and all it does is return a new MetaObject.  That MetaObject is a subclass of MetaObject that you define for your type and it can then override methods like GetMember or SetMember (there's many more) and instead of returning the values it returns a new MetaObject.  It?s hard to give you exact sample code because I don?t know if PropertySet is an indexed property defined in VB, or if it returns a Dictionary<string, ??>, etc?  But in general you just want to look at the Expression class and use its factories - and if you're familiar with .NET reflection you might find it straight forward.  But the general idea is you'll want to do something like:

            return new MetaObject(
                Expression.Call(
                    Expression.Property(Expression, Value.GetType().GetProperty("PropertySet")),
                    typeof(Dictionary<string, Dictionary<string, object>>).GetMethod("get_Item"),
                    Expression.Constant(action.Name)
                ),
                Restrictions.TypeRestriction(Expression, Value.GetType())
            );

And something similar for SetMember exception for you'll have an extra MetaObject coming in as value there, so you'd end up with something similar like:

            return new MetaObject(
                Expression.AssignProperty(
                    Expression.Call(Expression, Value.GetType().GetMethod("get_Item")),
                    typeof(Whatever).GetProperty("Value"),
                    value.Expression
                ),
                Restrictions.TypeRestriction(Expression, Value.GetType())
            );

The non-correct way (long-term) is that you can make it work with IronPython but not necessarily other languages (e.g. C# dynamic) but the flip side is it's really easy and straight forward.  There you can define a couple of methods like this:

        [SpecialName]
        public object GetCustomMember(string name) {
          return row.PropertySet[name];
      }


And in whatever type row.PropertySet["Foo"] returns:

        [SpecialName]
        public void SetMember(string name, object value) {
                this[name] = value;
      }




From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Thursday, November 06, 2008 8:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

Like a Christmas tree.

________________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, November 06, 2008 7:20 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

By custom class you mean a class you?ve written?  And then you want it to ?light up? with dynamic languages?

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Thursday, November 06, 2008 7:18 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

I actually want to use an object instance of a .NET custom class that I pass in before the script is invoked from c#.  Our current scripts look something like:

row.PropertySet[?Foo?][?Bar?].Value = x

and it would be much better if script authors could write:

row.Foo.Bar = x

So I?m looking to have an on the fly function read the metadata of expected keys and then code generated python class wrapper for the script author to consume.

________________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Miha Valencic
Sent: Thursday, November 06, 2008 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Extension methods in python

Marty, from what I understand you are passing a variable into python engine and want extension methods there? You can use something like that:

import clr
import System

class MyString(System.String):
  pass;

  def ToFoo(self):
    return self.upper()+' FooBarBaz'


a = MyString("Hello world!");
print a.ToFoo();



That would print "HELLO WORLD! FooBarBaz.

You can't put methods on System.String though, but you can create new object from System.String...

Miha
2008/11/5 Marty Nelson <Marty.Nelson at symyx.com>
Is there the equivalent of extension method in python?  I want to put a variable into the script scope and create extension methods for it.  Does this make sense and is it possible?

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


From william at resolversystems.com  Fri Nov  7 11:22:25 2008
From: william at resolversystems.com (William Reade)
Date: Fri, 07 Nov 2008 10:22:25 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735FAC8@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>	<4911D49C.4050308@resolversystems.com>	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>	<4911DF47.3020708@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4912F8AE.2020400@resolversystems.com>	<d2155e360811060622w5380696dl8bd15bfcc21a9445@mail.gmail.com>	<49130D4D.4050103@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735FAC8@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <491416E1.9030003@resolversystems.com>

Thanks Dino -- you've given me plenty to be going on with until you hear 
back from the CLR dev.

Dino Viehland wrote:
> In MTA mode we'll create a new thread which is thread 3 - thread 1 will just be hanging around waiting for it to exit.  Unfortunately w/o a separate EXE we can't avoid the separate thread.
>
> I've pinged the CLR dev who owns interop these days to see if he's ever seen anything like this.  Unfortunately he's OOF until the 10th.  My best suggestion for the time being is to avoid using Monitor for this lock so that you don't pump messages.  That's probably going to mean writing your own lock and then P/Invoking to WaitForSingleObject when you experience contention and need to block the thread.  Using an AutoResetEvent or ManualResetEvent directly won't work because we'll pump messages there too!
>
> I would also suggest looking at what CPython does here.  Dumpbin /imports python.exe shows no imports from ole32 so I'm guessing they don't do anything to spin up COM - which makes sense.  I would therefore assume when acquiring the GIL CPython will never pump messages and therefore programs don't expect possible re-entrancy - it'd probably be a good idea to mimic that behavior :).  Unfortunately there are other places where we use Monitor in IronPython - list.append comes to mind.  It'll be interesting to see if that turns out to be a problem eventually as well.
>
> Anyway, I'll let you know when I hear back.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Thursday, November 06, 2008 7:29 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help
>
> Finalization still happens on thread 2, and I see no evidence of thread
> 1 any more; my main thread now appears to have id 3.
>
> Curt Hagenlocher wrote:
>   
>> When you run with -X:MTA, is the object now being finalized on a
>> thread other than thread #2?
>>
>> On Thu, Nov 6, 2008 at 7:01 AM, William Reade
>> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>>
>>     Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no
>>     longer reproduce the problem. However, this bothers me a bit: I'm
>>     not competent to follow all the consequences here, but this
>>     situation seems to imply that Ironclad won't be usable safely from
>>     any STA thread. Is this an intended restriction or a bug?
>>
>>     Incidentally, tracking down the call stacks proved to be hard
>>     work: the timing changed enough that I only got a single failure
>>     over dozens of runs, and it turned out I'd got the logging wrong,
>>     so I didn't find out anything useful :(.
>>
>>
>>     Dino Viehland wrote:
>>
>>         I would suggest getting a snap shot of the call stacks when
>>         this is happening if that's possible.  I can't pin anything
>>         down but I wonder if you could have an STA object or something
>>         that otherwise requires message pumping.  That message pumping
>>         could happen while you're doing a Monitor.Enter call.  If that
>>         was happening maybe there is some subtle CLR bug or a surprise
>>         feature?  It is surprising that Monitor.Enter can go
>>         re-entrant but it can...
>>
>>         So it'd be interesting to get thread snapshots and see if
>>
>>
>>
>>                           EnsureGIL (443) 2
>>                           EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>
>>
>>
>>         Could be happening because Thread 1 experiences contention,
>>         blocks and pumps messages, causing the finalizer thread (2) to
>>         run, the lock is acquired and ... ?
>>
>>         Only other thing I could think of is does it repro on other
>>         machines?  Maybe it's a hardware bug as unlikely as that seems?
>>
>>         -----Original Message-----
>>         From: users-bounces at lists.ironpython.com
>>         <mailto:users-bounces at lists.ironpython.com>
>>         [mailto:users-bounces at lists.ironpython.com
>>         <mailto:users-bounces at lists.ironpython.com>] On Behalf Of
>>         William Reade
>>         Sent: Wednesday, November 05, 2008 10:01 AM
>>         To: Discussion of IronPython
>>         Subject: Re: [IronPython] Ironclad problem, with which someone
>>         here may be able to help
>>
>>         The log starts in the middle (after many lock/unlocks, some
>>         from each
>>         thread); I'm running on x86; and I have no additional AppDomains.
>>
>>         I don't think it would be safe for me to entirely avoid
>>         locking during
>>         finalization, but I could probably cut it down to a quick
>>         lock, on a
>>         separate object, to enqueue pointers for cleanup and
>>         deallocation on the
>>         main thread. However, I'm reluctant to do that until I'm sure
>>         that the
>>         problem is specifically related to GC, otherwise it'll just
>>         come back as
>>         soon as anyone tries any serious multithreading :).
>>
>>         Curt Hagenlocher wrote:
>>
>>
>>             Locking during finalization is often considered to be a
>>             bad idea.  In
>>             particular, locking without a timeout introduces the
>>             possibility that
>>             you will hang the finalization thread, preventing further
>>             objects from
>>             being finalized.  But clearly, that's not what's happening
>>             here.
>>
>>             Other questions that probably don't matter but might be
>>             interesting to
>>             know:
>>
>>             Can we assume that the finalization thread isn't the first
>>             place where
>>             this lock is required?  That your log starts somewhere in
>>             the middle?
>>
>>             Is this under x86 or x64 or both?
>>
>>             Are you creating any additional AppDomains in the process?
>>
>>
>>             On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>>             <william at resolversystems.com
>>             <mailto:william at resolversystems.com>
>>             <mailto:william at resolversystems.com
>>             <mailto:william at resolversystems.com>>> wrote:
>>
>>                Hi Curt
>>
>>                I am indeed; that's how I know thread 2 is the GC
>>             thread. Is
>>                locking during GC forbidden?
>>
>>                William
>>
>>                Curt Hagenlocher wrote:
>>
>>                    ...or, for that matter, any __del__ methods from
>>             within Python
>>                    -- which ultimately are handled by finalization.
>>
>>                    On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>                    <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>             <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>
>>                    <mailto:curt at hagenlocher.org
>>             <mailto:curt at hagenlocher.org> <mailto:curt at hagenlocher.org
>>             <mailto:curt at hagenlocher.org>>>>
>>                    wrote:
>>
>>                       So, the obvious question for me is whether or
>>             not you're
>>                    using any
>>                       finalizers.
>>
>>
>>                       On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>                       <william at resolversystems.com
>>             <mailto:william at resolversystems.com>
>>                    <mailto:william at resolversystems.com
>>             <mailto:william at resolversystems.com>>
>>                    <mailto:william at resolversystems.com
>>             <mailto:william at resolversystems.com>
>>                    <mailto:william at resolversystems.com
>>             <mailto:william at resolversystems.com>>>>
>>
>>                       wrote:
>>
>>                           Hi all
>>
>>                           While running the numpy tests, I've come
>>             across a situation
>>                           which, to the best of my knowledge, is simply
>>                    impossible. I'm
>>                           hoping that one of the local .NET gurus will
>>             be able to
>>                    tell
>>                           me what I'm missing, or point me somewhere I
>>             can get
>>                    more insight.
>>
>>                           The 4 methods involved are as follows:
>>                           -----------------------
>>                                 public int GetThreadId()
>>                                 {
>>                                     return
>>             Thread.CurrentThread.ManagedThreadId;
>>                                 }
>>
>>                                 public void WriteFlush(string info)
>>                                 {
>>                                     Console.WriteLine(info);
>>                                     Console.Out.Flush();
>>                                 }
>>
>>                                 public void EnsureGIL()
>>                                 {
>>                                     Monitor.Enter(this.dispatcherLock);
>>                                     this.WriteFlush(String.Format(
>>                                         "EnsureGIL ({1}) {0}",
>>             this.GetThreadId(),
>>                           Builtin.id(this.dispatcherLock)));
>>                                 }
>>
>>                                 public void ReleaseGIL()
>>                                 {
>>                                     this.WriteFlush(String.Format(
>>                                         "ReleaseGIL ({1}) {0}\n",
>>             this.GetThreadId(),
>>                           Builtin.id(this.dispatcherLock)));
>>                                     Monitor.Exit(this.dispatcherLock);
>>                                 }
>>                           -----------------------
>>                           ...and they can, and do, occasionally
>>             produce output as
>>                    follows:
>>                           -----------------------
>>                           EnsureGIL (443) 2
>>                           EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>                           ReleaseGIL (443) 2
>>
>>                           EnsureGIL (443) 2
>>                           ReleaseGIL (443) 1
>>
>>                           ReleaseGIL (443) 2
>>                           -----------------------
>>                           When this happens, the process continues
>>             happily for a
>>                    short
>>                           time and then falls over in a later call to
>>             ReleaseGIL
>>                    (after
>>                           successfully calling it several times). The
>>             error is "
>>                    Object
>>                           synchronization method was called from an
>>                    unsynchronized block
>>                           of code", which I understand to mean "you
>>             can't release
>>                    this
>>                           lock because you don't hold it".
>>
>>                           It doesn't happen very often, but I can usually
>>                    reproduce it
>>                           by running
>>                    test_multiarray.TestFromToFile.test_malformed a few
>>                           hundred times. It may be relevant to note
>>             that thread 2
>>                    is the
>>                           GC thread, and thread 1 is the main thread.
>>             I have
>>                    considered
>>                           the following possibilities:
>>
>>                           (1) That I'm locking on the wrong object. I
>>             believe
>>                    that isn't
>>                           the case, because it's constructed only
>>             once, as a "new
>>                           Object()" (ie, a reference type), and is
>>             only subsequently
>>                           used for locking; and, because it keeps the
>>             same ipy id
>>                           throughout.
>>
>>                           (2) That Monitor.Enter occasionally allows
>>             two different
>>                           threads to acquire the same lock. I consider
>>             this extremely
>>                           unlikely, because... well, how many
>>             multithreaded .NET apps
>>                           already exist? If Monitor really were
>>             broken, I think we'd
>>                           probably know about it by now.
>>
>>                           (3) That calling Flush() on a SyncTextWriter
>>             (the type of
>>                           Console.Out) doesn't actually do anything,
>>             and the
>>                    output is
>>                           somehow wrongly ordered (although I can't
>>             imagine how this
>>                           could actually be: if the locking is really
>>             working,
>>                    then my
>>                           console writes are strictly sequential). I
>>             don't have
>>                    access
>>                           to the code, so I have no idea how it's
>>             implemented,
>>                    but even
>>                           if this is the case it doesn't help much
>>             with the
>>                    fundamental
>>                           problem (the synchronisation error which
>>             follows).
>>
>>                           Apart from the above, I'm out of ideas. Can
>>             anyone suggest
>>                           what I've missed?
>>
>>                           William
>>                           _______________________________________________
>>                           Users mailing list
>>                           Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>
>>                    <mailto:Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>>
>>                    <mailto:Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>
>>                    <mailto:Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>>>
>>
>>
>>
>>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>
>>              ------------------------------------------------------------------------
>>
>>
>>
>>                    _______________________________________________
>>                    Users mailing list
>>                    Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>
>>             <mailto:Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>>
>>
>>              http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>                _______________________________________________
>>                Users mailing list
>>                Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>
>>             <mailto:Users at lists.ironpython.com
>>             <mailto:Users at lists.ironpython.com>>
>>
>>              http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>             ------------------------------------------------------------------------
>>
>>             _______________________________________________
>>             Users mailing list
>>             Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.ironpython.com <mailto: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
>
>   



From william at resolversystems.com  Fri Nov  7 12:02:27 2008
From: william at resolversystems.com (William Reade)
Date: Fri, 07 Nov 2008 11:02:27 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735FDDA@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>	<4911D49C.4050308@resolversystems.com>	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>	<4911DF47.3020708@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4912F8AE.2020400@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735FDDA@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <49142043.1060905@resolversystems.com>

I'll look into that along with everything else :).

Dino Viehland wrote:
> Do you know if numpy is using COM anywhere?  Or does Ironclad use COM for any of its interop?
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Thursday, November 06, 2008 6:01 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help
>
> Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
> reproduce the problem. However, this bothers me a bit: I'm not competent
> to follow all the consequences here, but this situation seems to imply
> that Ironclad won't be usable safely from any STA thread. Is this an
> intended restriction or a bug?
>
> Incidentally, tracking down the call stacks proved to be hard work: the
> timing changed enough that I only got a single failure over dozens of
> runs, and it turned out I'd got the logging wrong, so I didn't find out
> anything useful :(.
>
> Dino Viehland wrote:
>   
>> I would suggest getting a snap shot of the call stacks when this is happening if that's possible.  I can't pin anything down but I wonder if you could have an STA object or something that otherwise requires message pumping.  That message pumping could happen while you're doing a Monitor.Enter call.  If that was happening maybe there is some subtle CLR bug or a surprise feature?  It is surprising that Monitor.Enter can go re-entrant but it can...
>>
>> So it'd be interesting to get thread snapshots and see if
>>
>>
>>     
>>>                EnsureGIL (443) 2
>>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>
>>>       
>> Could be happening because Thread 1 experiences contention, blocks and pumps messages, causing the finalizer thread (2) to run, the lock is acquired and ... ?
>>
>> Only other thing I could think of is does it repro on other machines?  Maybe it's a hardware bug as unlikely as that seems?
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Wednesday, November 05, 2008 10:01 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help
>>
>> The log starts in the middle (after many lock/unlocks, some from each
>> thread); I'm running on x86; and I have no additional AppDomains.
>>
>> I don't think it would be safe for me to entirely avoid locking during
>> finalization, but I could probably cut it down to a quick lock, on a
>> separate object, to enqueue pointers for cleanup and deallocation on the
>> main thread. However, I'm reluctant to do that until I'm sure that the
>> problem is specifically related to GC, otherwise it'll just come back as
>> soon as anyone tries any serious multithreading :).
>>
>> Curt Hagenlocher wrote:
>>
>>     
>>> Locking during finalization is often considered to be a bad idea.  In
>>> particular, locking without a timeout introduces the possibility that
>>> you will hang the finalization thread, preventing further objects from
>>> being finalized.  But clearly, that's not what's happening here.
>>>
>>> Other questions that probably don't matter but might be interesting to
>>> know:
>>>
>>> Can we assume that the finalization thread isn't the first place where
>>> this lock is required?  That your log starts somewhere in the middle?
>>>
>>> Is this under x86 or x64 or both?
>>>
>>> Are you creating any additional AppDomains in the process?
>>>
>>>
>>> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>>> <william at resolversystems.com <mailto:william at resolversystems.com>> wrote:
>>>
>>>     Hi Curt
>>>
>>>     I am indeed; that's how I know thread 2 is the GC thread. Is
>>>     locking during GC forbidden?
>>>
>>>     William
>>>
>>>     Curt Hagenlocher wrote:
>>>
>>>         ...or, for that matter, any __del__ methods from within Python
>>>         -- which ultimately are handled by finalization.
>>>
>>>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>>>         wrote:
>>>
>>>            So, the obvious question for me is whether or not you're
>>>         using any
>>>            finalizers.
>>>
>>>
>>>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>>            <william at resolversystems.com
>>>         <mailto:william at resolversystems.com>
>>>         <mailto:william at resolversystems.com
>>>         <mailto:william at resolversystems.com>>>
>>>
>>>            wrote:
>>>
>>>                Hi all
>>>
>>>                While running the numpy tests, I've come across a situation
>>>                which, to the best of my knowledge, is simply
>>>         impossible. I'm
>>>                hoping that one of the local .NET gurus will be able to
>>>         tell
>>>                me what I'm missing, or point me somewhere I can get
>>>         more insight.
>>>
>>>                The 4 methods involved are as follows:
>>>                -----------------------
>>>                      public int GetThreadId()
>>>                      {
>>>                          return Thread.CurrentThread.ManagedThreadId;
>>>                      }
>>>
>>>                      public void WriteFlush(string info)
>>>                      {
>>>                          Console.WriteLine(info);
>>>                          Console.Out.Flush();
>>>                      }
>>>
>>>                      public void EnsureGIL()
>>>                      {
>>>                          Monitor.Enter(this.dispatcherLock);
>>>                          this.WriteFlush(String.Format(
>>>                              "EnsureGIL ({1}) {0}", this.GetThreadId(),
>>>                Builtin.id(this.dispatcherLock)));
>>>                      }
>>>
>>>                      public void ReleaseGIL()
>>>                      {
>>>                          this.WriteFlush(String.Format(
>>>                              "ReleaseGIL ({1}) {0}\n", this.GetThreadId(),
>>>                Builtin.id(this.dispatcherLock)));
>>>                          Monitor.Exit(this.dispatcherLock);
>>>                      }
>>>                -----------------------
>>>                ...and they can, and do, occasionally produce output as
>>>         follows:
>>>                -----------------------
>>>                EnsureGIL (443) 2
>>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>                ReleaseGIL (443) 2
>>>
>>>                EnsureGIL (443) 2
>>>                ReleaseGIL (443) 1
>>>
>>>                ReleaseGIL (443) 2
>>>                -----------------------
>>>                When this happens, the process continues happily for a
>>>         short
>>>                time and then falls over in a later call to ReleaseGIL
>>>         (after
>>>                successfully calling it several times). The error is "
>>>         Object
>>>                synchronization method was called from an
>>>         unsynchronized block
>>>                of code", which I understand to mean "you can't release
>>>         this
>>>                lock because you don't hold it".
>>>
>>>                It doesn't happen very often, but I can usually
>>>         reproduce it
>>>                by running
>>>         test_multiarray.TestFromToFile.test_malformed a few
>>>                hundred times. It may be relevant to note that thread 2
>>>         is the
>>>                GC thread, and thread 1 is the main thread. I have
>>>         considered
>>>                the following possibilities:
>>>
>>>                (1) That I'm locking on the wrong object. I believe
>>>         that isn't
>>>                the case, because it's constructed only once, as a "new
>>>                Object()" (ie, a reference type), and is only subsequently
>>>                used for locking; and, because it keeps the same ipy id
>>>                throughout.
>>>
>>>                (2) That Monitor.Enter occasionally allows two different
>>>                threads to acquire the same lock. I consider this extremely
>>>                unlikely, because... well, how many multithreaded .NET apps
>>>                already exist? If Monitor really were broken, I think we'd
>>>                probably know about it by now.
>>>
>>>                (3) That calling Flush() on a SyncTextWriter (the type of
>>>                Console.Out) doesn't actually do anything, and the
>>>         output is
>>>                somehow wrongly ordered (although I can't imagine how this
>>>                could actually be: if the locking is really working,
>>>         then my
>>>                console writes are strictly sequential). I don't have
>>>         access
>>>                to the code, so I have no idea how it's implemented,
>>>         but even
>>>                if this is the case it doesn't help much with the
>>>         fundamental
>>>                problem (the synchronisation error which follows).
>>>
>>>                Apart from the above, I'm out of ideas. Can anyone suggest
>>>                what I've missed?
>>>
>>>                William
>>>                _______________________________________________
>>>                Users mailing list
>>>                Users at lists.ironpython.com
>>>         <mailto:Users at lists.ironpython.com>
>>>         <mailto:Users at lists.ironpython.com
>>>         <mailto:Users at lists.ironpython.com>>
>>>
>>>
>>>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>         ------------------------------------------------------------------------
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Users mailing list
>>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Users mailing list
>>>     Users at lists.ironpython.com <mailto: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
>
>   



From fuzzyman at voidspace.org.uk  Fri Nov  7 12:21:50 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 07 Nov 2008 11:21:50 +0000
Subject: [IronPython] Porting from CPython: Figuring out the calling
 code's directory
In-Reply-To: <620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com>
References: <620765220811060643w681ee9dap924500cde40c4c61@mail.gmail.com>
	<620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com>
Message-ID: <491424CE.3070908@voidspace.org.uk>

Ori Peleg wrote:
[snip...]
>
> BTW - the use case is for building test suites: you can have a
> subpackage of tests and define __init__.py like this:
>
> def suite():
>    import testoob
>    return testoob.collecting.collect_from_files("test_*.py")
>

Why not change the API to:

   return testoob.collecting.collect_from_files("test_*.py", __file__)

Michael

> Thanks,
> orip.
>
> -- 
> Check out my blog: http://orip.org
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From william at resolversystems.com  Fri Nov  7 13:02:37 2008
From: william at resolversystems.com (William Reade)
Date: Fri, 07 Nov 2008 12:02:37 +0000
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <49142043.1060905@resolversystems.com>
References: <49119841.3000304@resolversystems.com>	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>	<4911D49C.4050308@resolversystems.com>	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>	<4911DF47.3020708@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4912F8AE.2020400@resolversystems.com>	<350E7D38B6D819428718949920EC23554FF735FDDA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49142043.1060905@resolversystems.com>
Message-ID: <49142E5D.7020207@resolversystems.com>

So far as I can tell, CPython ctypes and installers (neither of which 
are currently relevant) use COM, and numpy doesn't use it at all. 
However, my search wasn't very sophisticated -- I just looked for 
CoInitialize, CoCreateInstance, and lpVtbl, which is all the COM I can 
remember*. Was that actually a sensible way of checking?

Ironclad doesn't use any of the COM-related methods on Marshal, and only 
uses a handful of unmanaged functions (from kernel32 and msvcr71), so if 
it does use COM it's doing so secretly and without my knowledge :).

Running ipy on its own does appear to load ole32, but I haven't worked 
out what, if anything, it's doing with it.

* I had to work with faked-up COM interfaces while working on mac game 
ports a few years ago  -- that's the full extent of my experience.

William Reade wrote:
> I'll look into that along with everything else :).
>
> Dino Viehland wrote:
>> Do you know if numpy is using COM anywhere?  Or does Ironclad use COM 
>> for any of its interop?
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com 
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Thursday, November 06, 2008 6:01 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Ironclad problem, with which someone here 
>> may be able to help
>>
>> Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
>> reproduce the problem. However, this bothers me a bit: I'm not competent
>> to follow all the consequences here, but this situation seems to imply
>> that Ironclad won't be usable safely from any STA thread. Is this an
>> intended restriction or a bug?
>>
>> Incidentally, tracking down the call stacks proved to be hard work: the
>> timing changed enough that I only got a single failure over dozens of
>> runs, and it turned out I'd got the logging wrong, so I didn't find out
>> anything useful :(.
>>
>> Dino Viehland wrote:
>>  
>>> I would suggest getting a snap shot of the call stacks when this is 
>>> happening if that's possible.  I can't pin anything down but I 
>>> wonder if you could have an STA object or something that otherwise 
>>> requires message pumping.  That message pumping could happen while 
>>> you're doing a Monitor.Enter call.  If that was happening maybe 
>>> there is some subtle CLR bug or a surprise feature?  It is 
>>> surprising that Monitor.Enter can go re-entrant but it can...
>>>
>>> So it'd be interesting to get thread snapshots and see if
>>>
>>>
>>>    
>>>>                EnsureGIL (443) 2
>>>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>>
>>>>       
>>> Could be happening because Thread 1 experiences contention, blocks 
>>> and pumps messages, causing the finalizer thread (2) to run, the 
>>> lock is acquired and ... ?
>>>
>>> Only other thing I could think of is does it repro on other 
>>> machines?  Maybe it's a hardware bug as unlikely as that seems?
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com 
>>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>>> Sent: Wednesday, November 05, 2008 10:01 AM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Ironclad problem, with which someone here 
>>> may be able to help
>>>
>>> The log starts in the middle (after many lock/unlocks, some from each
>>> thread); I'm running on x86; and I have no additional AppDomains.
>>>
>>> I don't think it would be safe for me to entirely avoid locking during
>>> finalization, but I could probably cut it down to a quick lock, on a
>>> separate object, to enqueue pointers for cleanup and deallocation on 
>>> the
>>> main thread. However, I'm reluctant to do that until I'm sure that the
>>> problem is specifically related to GC, otherwise it'll just come 
>>> back as
>>> soon as anyone tries any serious multithreading :).
>>>
>>> Curt Hagenlocher wrote:
>>>
>>>    
>>>> Locking during finalization is often considered to be a bad idea.  In
>>>> particular, locking without a timeout introduces the possibility that
>>>> you will hang the finalization thread, preventing further objects from
>>>> being finalized.  But clearly, that's not what's happening here.
>>>>
>>>> Other questions that probably don't matter but might be interesting to
>>>> know:
>>>>
>>>> Can we assume that the finalization thread isn't the first place where
>>>> this lock is required?  That your log starts somewhere in the middle?
>>>>
>>>> Is this under x86 or x64 or both?
>>>>
>>>> Are you creating any additional AppDomains in the process?
>>>>
>>>>
>>>> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>>>> <william at resolversystems.com <mailto:william at resolversystems.com>> 
>>>> wrote:
>>>>
>>>>     Hi Curt
>>>>
>>>>     I am indeed; that's how I know thread 2 is the GC thread. Is
>>>>     locking during GC forbidden?
>>>>
>>>>     William
>>>>
>>>>     Curt Hagenlocher wrote:
>>>>
>>>>         ...or, for that matter, any __del__ methods from within Python
>>>>         -- which ultimately are handled by finalization.
>>>>
>>>>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>>>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>>>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>>>>         wrote:
>>>>
>>>>            So, the obvious question for me is whether or not you're
>>>>         using any
>>>>            finalizers.
>>>>
>>>>
>>>>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>>>            <william at resolversystems.com
>>>>         <mailto:william at resolversystems.com>
>>>>         <mailto:william at resolversystems.com
>>>>         <mailto:william at resolversystems.com>>>
>>>>
>>>>            wrote:
>>>>
>>>>                Hi all
>>>>
>>>>                While running the numpy tests, I've come across a 
>>>> situation
>>>>                which, to the best of my knowledge, is simply
>>>>         impossible. I'm
>>>>                hoping that one of the local .NET gurus will be able to
>>>>         tell
>>>>                me what I'm missing, or point me somewhere I can get
>>>>         more insight.
>>>>
>>>>                The 4 methods involved are as follows:
>>>>                -----------------------
>>>>                      public int GetThreadId()
>>>>                      {
>>>>                          return Thread.CurrentThread.ManagedThreadId;
>>>>                      }
>>>>
>>>>                      public void WriteFlush(string info)
>>>>                      {
>>>>                          Console.WriteLine(info);
>>>>                          Console.Out.Flush();
>>>>                      }
>>>>
>>>>                      public void EnsureGIL()
>>>>                      {
>>>>                          Monitor.Enter(this.dispatcherLock);
>>>>                          this.WriteFlush(String.Format(
>>>>                              "EnsureGIL ({1}) {0}", 
>>>> this.GetThreadId(),
>>>>                Builtin.id(this.dispatcherLock)));
>>>>                      }
>>>>
>>>>                      public void ReleaseGIL()
>>>>                      {
>>>>                          this.WriteFlush(String.Format(
>>>>                              "ReleaseGIL ({1}) {0}\n", 
>>>> this.GetThreadId(),
>>>>                Builtin.id(this.dispatcherLock)));
>>>>                          Monitor.Exit(this.dispatcherLock);
>>>>                      }
>>>>                -----------------------
>>>>                ...and they can, and do, occasionally produce output as
>>>>         follows:
>>>>                -----------------------
>>>>                EnsureGIL (443) 2
>>>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>>                ReleaseGIL (443) 2
>>>>
>>>>                EnsureGIL (443) 2
>>>>                ReleaseGIL (443) 1
>>>>
>>>>                ReleaseGIL (443) 2
>>>>                -----------------------
>>>>                When this happens, the process continues happily for a
>>>>         short
>>>>                time and then falls over in a later call to ReleaseGIL
>>>>         (after
>>>>                successfully calling it several times). The error is "
>>>>         Object
>>>>                synchronization method was called from an
>>>>         unsynchronized block
>>>>                of code", which I understand to mean "you can't release
>>>>         this
>>>>                lock because you don't hold it".
>>>>
>>>>                It doesn't happen very often, but I can usually
>>>>         reproduce it
>>>>                by running
>>>>         test_multiarray.TestFromToFile.test_malformed a few
>>>>                hundred times. It may be relevant to note that thread 2
>>>>         is the
>>>>                GC thread, and thread 1 is the main thread. I have
>>>>         considered
>>>>                the following possibilities:
>>>>
>>>>                (1) That I'm locking on the wrong object. I believe
>>>>         that isn't
>>>>                the case, because it's constructed only once, as a "new
>>>>                Object()" (ie, a reference type), and is only 
>>>> subsequently
>>>>                used for locking; and, because it keeps the same ipy id
>>>>                throughout.
>>>>
>>>>                (2) That Monitor.Enter occasionally allows two 
>>>> different
>>>>                threads to acquire the same lock. I consider this 
>>>> extremely
>>>>                unlikely, because... well, how many multithreaded 
>>>> .NET apps
>>>>                already exist? If Monitor really were broken, I 
>>>> think we'd
>>>>                probably know about it by now.
>>>>
>>>>                (3) That calling Flush() on a SyncTextWriter (the 
>>>> type of
>>>>                Console.Out) doesn't actually do anything, and the
>>>>         output is
>>>>                somehow wrongly ordered (although I can't imagine 
>>>> how this
>>>>                could actually be: if the locking is really working,
>>>>         then my
>>>>                console writes are strictly sequential). I don't have
>>>>         access
>>>>                to the code, so I have no idea how it's implemented,
>>>>         but even
>>>>                if this is the case it doesn't help much with the
>>>>         fundamental
>>>>                problem (the synchronisation error which follows).
>>>>
>>>>                Apart from the above, I'm out of ideas. Can anyone 
>>>> suggest
>>>>                what I've missed?
>>>>
>>>>                William
>>>>                _______________________________________________
>>>>                Users mailing list
>>>>                Users at lists.ironpython.com
>>>>         <mailto:Users at lists.ironpython.com>
>>>>         <mailto:Users at lists.ironpython.com
>>>>         <mailto:Users at lists.ironpython.com>>
>>>>
>>>>
>>>>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>         
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         Users mailing list
>>>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Users mailing list
>>>>     Users at lists.ironpython.com <mailto: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
>>
>>   
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



From dinov at microsoft.com  Fri Nov  7 18:10:26 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 7 Nov 2008 09:10:26 -0800
Subject: [IronPython] Ironclad problem,
 with which someone here may be able to help
In-Reply-To: <49142E5D.7020207@resolversystems.com>
References: <49119841.3000304@resolversystems.com>
	<d2155e360811050837v74eee6bw199ff4bce4eeaa42@mail.gmail.com>
	<d2155e360811050840x714fe1edvab6127a01f16ad74@mail.gmail.com>
	<4911D49C.4050308@resolversystems.com>
	<d2155e360811050934h476e5d36l8da9bf56326e6da6@mail.gmail.com>
	<4911DF47.3020708@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735F8A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4912F8AE.2020400@resolversystems.com>
	<350E7D38B6D819428718949920EC23554FF735FDDA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49142043.1060905@resolversystems.com>
	<49142E5D.7020207@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC23554FF735FF3E@NA-EXMSG-C102.redmond.corp.microsoft.com>

The CLR always loads up ole32 at startup and will even if it didn't it'd need to for the [STAThread] attribute.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Friday, November 07, 2008 4:03 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Ironclad problem, with which someone here may be able to help

So far as I can tell, CPython ctypes and installers (neither of which
are currently relevant) use COM, and numpy doesn't use it at all.
However, my search wasn't very sophisticated -- I just looked for
CoInitialize, CoCreateInstance, and lpVtbl, which is all the COM I can
remember*. Was that actually a sensible way of checking?

Ironclad doesn't use any of the COM-related methods on Marshal, and only
uses a handful of unmanaged functions (from kernel32 and msvcr71), so if
it does use COM it's doing so secretly and without my knowledge :).

Running ipy on its own does appear to load ole32, but I haven't worked
out what, if anything, it's doing with it.

* I had to work with faked-up COM interfaces while working on mac game
ports a few years ago  -- that's the full extent of my experience.

William Reade wrote:
> I'll look into that along with everything else :).
>
> Dino Viehland wrote:
>> Do you know if numpy is using COM anywhere?  Or does Ironclad use COM
>> for any of its interop?
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Thursday, November 06, 2008 6:01 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Ironclad problem, with which someone here
>> may be able to help
>>
>> Thanks Dino -- it seems that if I use ipy with -X:MTA, I can no longer
>> reproduce the problem. However, this bothers me a bit: I'm not competent
>> to follow all the consequences here, but this situation seems to imply
>> that Ironclad won't be usable safely from any STA thread. Is this an
>> intended restriction or a bug?
>>
>> Incidentally, tracking down the call stacks proved to be hard work: the
>> timing changed enough that I only got a single failure over dozens of
>> runs, and it turned out I'd got the logging wrong, so I didn't find out
>> anything useful :(.
>>
>> Dino Viehland wrote:
>>
>>> I would suggest getting a snap shot of the call stacks when this is
>>> happening if that's possible.  I can't pin anything down but I
>>> wonder if you could have an STA object or something that otherwise
>>> requires message pumping.  That message pumping could happen while
>>> you're doing a Monitor.Enter call.  If that was happening maybe
>>> there is some subtle CLR bug or a surprise feature?  It is
>>> surprising that Monitor.Enter can go re-entrant but it can...
>>>
>>> So it'd be interesting to get thread snapshots and see if
>>>
>>>
>>>
>>>>                EnsureGIL (443) 2
>>>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>>
>>>>
>>> Could be happening because Thread 1 experiences contention, blocks
>>> and pumps messages, causing the finalizer thread (2) to run, the
>>> lock is acquired and ... ?
>>>
>>> Only other thing I could think of is does it repro on other
>>> machines?  Maybe it's a hardware bug as unlikely as that seems?
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com
>>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>>> Sent: Wednesday, November 05, 2008 10:01 AM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Ironclad problem, with which someone here
>>> may be able to help
>>>
>>> The log starts in the middle (after many lock/unlocks, some from each
>>> thread); I'm running on x86; and I have no additional AppDomains.
>>>
>>> I don't think it would be safe for me to entirely avoid locking during
>>> finalization, but I could probably cut it down to a quick lock, on a
>>> separate object, to enqueue pointers for cleanup and deallocation on
>>> the
>>> main thread. However, I'm reluctant to do that until I'm sure that the
>>> problem is specifically related to GC, otherwise it'll just come
>>> back as
>>> soon as anyone tries any serious multithreading :).
>>>
>>> Curt Hagenlocher wrote:
>>>
>>>
>>>> Locking during finalization is often considered to be a bad idea.  In
>>>> particular, locking without a timeout introduces the possibility that
>>>> you will hang the finalization thread, preventing further objects from
>>>> being finalized.  But clearly, that's not what's happening here.
>>>>
>>>> Other questions that probably don't matter but might be interesting to
>>>> know:
>>>>
>>>> Can we assume that the finalization thread isn't the first place where
>>>> this lock is required?  That your log starts somewhere in the middle?
>>>>
>>>> Is this under x86 or x64 or both?
>>>>
>>>> Are you creating any additional AppDomains in the process?
>>>>
>>>>
>>>> On Wed, Nov 5, 2008 at 10:15 AM, William Reade
>>>> <william at resolversystems.com <mailto:william at resolversystems.com>>
>>>> wrote:
>>>>
>>>>     Hi Curt
>>>>
>>>>     I am indeed; that's how I know thread 2 is the GC thread. Is
>>>>     locking during GC forbidden?
>>>>
>>>>     William
>>>>
>>>>     Curt Hagenlocher wrote:
>>>>
>>>>         ...or, for that matter, any __del__ methods from within Python
>>>>         -- which ultimately are handled by finalization.
>>>>
>>>>         On Wed, Nov 5, 2008 at 9:37 AM, Curt Hagenlocher
>>>>         <curt at hagenlocher.org <mailto:curt at hagenlocher.org>
>>>>         <mailto:curt at hagenlocher.org <mailto:curt at hagenlocher.org>>>
>>>>         wrote:
>>>>
>>>>            So, the obvious question for me is whether or not you're
>>>>         using any
>>>>            finalizers.
>>>>
>>>>
>>>>            On Wed, Nov 5, 2008 at 5:57 AM, William Reade
>>>>            <william at resolversystems.com
>>>>         <mailto:william at resolversystems.com>
>>>>         <mailto:william at resolversystems.com
>>>>         <mailto:william at resolversystems.com>>>
>>>>
>>>>            wrote:
>>>>
>>>>                Hi all
>>>>
>>>>                While running the numpy tests, I've come across a
>>>> situation
>>>>                which, to the best of my knowledge, is simply
>>>>         impossible. I'm
>>>>                hoping that one of the local .NET gurus will be able to
>>>>         tell
>>>>                me what I'm missing, or point me somewhere I can get
>>>>         more insight.
>>>>
>>>>                The 4 methods involved are as follows:
>>>>                -----------------------
>>>>                      public int GetThreadId()
>>>>                      {
>>>>                          return Thread.CurrentThread.ManagedThreadId;
>>>>                      }
>>>>
>>>>                      public void WriteFlush(string info)
>>>>                      {
>>>>                          Console.WriteLine(info);
>>>>                          Console.Out.Flush();
>>>>                      }
>>>>
>>>>                      public void EnsureGIL()
>>>>                      {
>>>>                          Monitor.Enter(this.dispatcherLock);
>>>>                          this.WriteFlush(String.Format(
>>>>                              "EnsureGIL ({1}) {0}",
>>>> this.GetThreadId(),
>>>>                Builtin.id(this.dispatcherLock)));
>>>>                      }
>>>>
>>>>                      public void ReleaseGIL()
>>>>                      {
>>>>                          this.WriteFlush(String.Format(
>>>>                              "ReleaseGIL ({1}) {0}\n",
>>>> this.GetThreadId(),
>>>>                Builtin.id(this.dispatcherLock)));
>>>>                          Monitor.Exit(this.dispatcherLock);
>>>>                      }
>>>>                -----------------------
>>>>                ...and they can, and do, occasionally produce output as
>>>>         follows:
>>>>                -----------------------
>>>>                EnsureGIL (443) 2
>>>>                EnsureGIL (443) 1      <- omg, wtf, bbq, etc.
>>>>                ReleaseGIL (443) 2
>>>>
>>>>                EnsureGIL (443) 2
>>>>                ReleaseGIL (443) 1
>>>>
>>>>                ReleaseGIL (443) 2
>>>>                -----------------------
>>>>                When this happens, the process continues happily for a
>>>>         short
>>>>                time and then falls over in a later call to ReleaseGIL
>>>>         (after
>>>>                successfully calling it several times). The error is "
>>>>         Object
>>>>                synchronization method was called from an
>>>>         unsynchronized block
>>>>                of code", which I understand to mean "you can't release
>>>>         this
>>>>                lock because you don't hold it".
>>>>
>>>>                It doesn't happen very often, but I can usually
>>>>         reproduce it
>>>>                by running
>>>>         test_multiarray.TestFromToFile.test_malformed a few
>>>>                hundred times. It may be relevant to note that thread 2
>>>>         is the
>>>>                GC thread, and thread 1 is the main thread. I have
>>>>         considered
>>>>                the following possibilities:
>>>>
>>>>                (1) That I'm locking on the wrong object. I believe
>>>>         that isn't
>>>>                the case, because it's constructed only once, as a "new
>>>>                Object()" (ie, a reference type), and is only
>>>> subsequently
>>>>                used for locking; and, because it keeps the same ipy id
>>>>                throughout.
>>>>
>>>>                (2) That Monitor.Enter occasionally allows two
>>>> different
>>>>                threads to acquire the same lock. I consider this
>>>> extremely
>>>>                unlikely, because... well, how many multithreaded
>>>> .NET apps
>>>>                already exist? If Monitor really were broken, I
>>>> think we'd
>>>>                probably know about it by now.
>>>>
>>>>                (3) That calling Flush() on a SyncTextWriter (the
>>>> type of
>>>>                Console.Out) doesn't actually do anything, and the
>>>>         output is
>>>>                somehow wrongly ordered (although I can't imagine
>>>> how this
>>>>                could actually be: if the locking is really working,
>>>>         then my
>>>>                console writes are strictly sequential). I don't have
>>>>         access
>>>>                to the code, so I have no idea how it's implemented,
>>>>         but even
>>>>                if this is the case it doesn't help much with the
>>>>         fundamental
>>>>                problem (the synchronisation error which follows).
>>>>
>>>>                Apart from the above, I'm out of ideas. Can anyone
>>>> suggest
>>>>                what I've missed?
>>>>
>>>>                William
>>>>                _______________________________________________
>>>>                Users mailing list
>>>>                Users at lists.ironpython.com
>>>>         <mailto:Users at lists.ironpython.com>
>>>>         <mailto:Users at lists.ironpython.com
>>>>         <mailto:Users at lists.ironpython.com>>
>>>>
>>>>
>>>>          http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         Users mailing list
>>>>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Users mailing list
>>>>     Users at lists.ironpython.com <mailto: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
>>
>>
>
> _______________________________________________
> 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



From daftspaniel at gmail.com  Sat Nov  8 13:10:16 2008
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Sat, 8 Nov 2008 12:10:16 +0000
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
Message-ID: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>

IPY 2.0 RC1

ActiveX Issue in a pyc compiled Winforms EXE which uses the WebBrowser
control.

Unhandled Exception: System.Threading.ThreadStateException: ActiveX control
'8856f961-340a-11d0-a96b-00c04fd705a2' cannot be instantiated because the
current thread is not in a single-threaded apartment.
   at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
   at System.Windows.Forms.WebBrowser..ctor()
   at _stub_$643##332(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
target, C

Help!! :-)

Any thoughts before I delve further into this?

Thanks
Davy Mitchell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081108/925c88bf/attachment.html>

From fuzzyman at gmail.com  Sat Nov  8 13:22:41 2008
From: fuzzyman at gmail.com (Michael)
Date: Sat, 8 Nov 2008 12:22:41 +0000
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
In-Reply-To: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
References: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
Message-ID: <7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>

Are you doing this from a separate thread? I assume it works fine when  
run uncompiled?


Michael

http://www.ironpythoninaction.com

On 8 Nov 2008, at 12:10, "Davy Mitchell" <daftspaniel at gmail.com> wrote:

> IPY 2.0 RC1
>
>
> ActiveX Issue in a pyc compiled Winforms EXE which uses the  
> WebBrowser control.
>
> Unhandled Exception: System.Threading.ThreadStateException: ActiveX  
> control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be  
> instantiated because the current thread is not in a single-threaded  
> apartment.
>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
>    at System.Windows.Forms.WebBrowser..ctor()
>    at _stub_$643##332(Closure , CallSite , CodeContext , Object )
>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet] 
> (Func`4 target, C
>
> Help!! :-)
>
> Any thoughts before I delve further into this?
>
> Thanks
> Davy Mitchell
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From daftspaniel at gmail.com  Sat Nov  8 15:19:22 2008
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Sat, 8 Nov 2008 14:19:22 +0000
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
In-Reply-To: <7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>
References: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
	<7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>
Message-ID: <20253b0c0811080619vca0bf40r7ffe512204021ccf@mail.gmail.com>

Hi Michael

>Are you doing this from a separate thread?

No.

It's a couple of modules deep from the 'main' script. Was going to try
a single py file to repro.

> I assume it works fine when run uncompiled?

Yep, runs great.
Cheers,
Davy


On 11/8/08, Michael <fuzzyman at gmail.com> wrote:
> Are you doing this from a separate thread? I assume it works fine when
> run uncompiled?
>
>
> Michael
>
> http://www.ironpythoninaction.com
>
> On 8 Nov 2008, at 12:10, "Davy Mitchell" <daftspaniel at gmail.com> wrote:
>
>> IPY 2.0 RC1
>>
>>
>> ActiveX Issue in a pyc compiled Winforms EXE which uses the
>> WebBrowser control.
>>
>> Unhandled Exception: System.Threading.ThreadStateException: ActiveX
>> control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be
>> instantiated because the current thread is not in a single-threaded
>> apartment.
>>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
>>    at System.Windows.Forms.WebBrowser..ctor()
>>    at _stub_$643##332(Closure , CallSite , CodeContext , Object )
>>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet]
>> (Func`4 target, C
>>
>> Help!! :-)
>>
>> Any thoughts before I delve further into this?
>>
>> Thanks
>> Davy Mitchell
>> _______________________________________________
>> 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
>


From dinov at microsoft.com  Sat Nov  8 18:39:57 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 8 Nov 2008 09:39:57 -0800
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
In-Reply-To: <20253b0c0811080619vca0bf40r7ffe512204021ccf@mail.gmail.com>
References: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
	<7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>
	<20253b0c0811080619vca0bf40r7ffe512204021ccf@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355516948C3EC@NA-EXMSG-C102.redmond.corp.microsoft.com>

I'd start w/ -X:ExceptionDetail to get the full stack trace.  Presumably there's something higher up the stack then the MatchCaller on the stack.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
Sent: Saturday, November 08, 2008 6:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] ActiveX STA Issue in compiled Winforms EXE

Hi Michael

>Are you doing this from a separate thread?

No.

It's a couple of modules deep from the 'main' script. Was going to try
a single py file to repro.

> I assume it works fine when run uncompiled?

Yep, runs great.
Cheers,
Davy


On 11/8/08, Michael <fuzzyman at gmail.com> wrote:
> Are you doing this from a separate thread? I assume it works fine when
> run uncompiled?
>
>
> Michael
>
> http://www.ironpythoninaction.com
>
> On 8 Nov 2008, at 12:10, "Davy Mitchell" <daftspaniel at gmail.com> wrote:
>
>> IPY 2.0 RC1
>>
>>
>> ActiveX Issue in a pyc compiled Winforms EXE which uses the
>> WebBrowser control.
>>
>> Unhandled Exception: System.Threading.ThreadStateException: ActiveX
>> control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be
>> instantiated because the current thread is not in a single-threaded
>> apartment.
>>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
>>    at System.Windows.Forms.WebBrowser..ctor()
>>    at _stub_$643##332(Closure , CallSite , CodeContext , Object )
>>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet]
>> (Func`4 target, C
>>
>> Help!! :-)
>>
>> Any thoughts before I delve further into this?
>>
>> Thanks
>> Davy Mitchell
>> _______________________________________________
>> 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



From oripel at gmail.com  Sat Nov  8 21:36:03 2008
From: oripel at gmail.com (orip)
Date: Sat, 8 Nov 2008 12:36:03 -0800 (PST)
Subject: [IronPython] Porting from CPython: Figuring out the calling
	code's directory
In-Reply-To: <350E7D38B6D819428718949920EC23554FF735FD1B@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <620765220811060643w681ee9dap924500cde40c4c61@mail.gmail.com> 
	<620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com> 
	<350E7D38B6D819428718949920EC23554FF735FD1B@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <f92ab1f6-8951-4a42-b459-a3c86f5c8962@w39g2000prb.googlegroups.com>

Thanks Dino!
I guess I'll try a workaround.

On Nov 7, 1:24?am, Dino Viehland <di... at microsoft.com> wrote:
> The short answer is no ? we realize frames is a common request and I do have a prototype implementation of them. ?We?re still working on our 2.1 planning ?but it might be available there w/ a command line option or it might be something we could port to 2.0.1.
>
> The longer answer would be potentially with a lot of work and it could be quite slow. ?You could walk every module, every function, every class and attempt to gather up all the function objects in the world. ?Then you could call PythonOps.FunctionGetTarget on each one of them. ?Finally you could do a full .NET stack trace (new System.Diagnostics.StackTrace()) and attempt to figure your caller by filtering out any IronPython/DLR frames. ?Finally once you have that method you could see if that method is == the .Method property of any of the delegates you got from FunctionGetTarget calls. ?And I?m not even 100% sure if that?d work ? the delegates for a PythonFunction might have a different MethodInfo then the one in the stack trace but I?m not certain (if this is the case it?d be due to the way CLR hides DynamicMethod MethodInfo?s so only the creator has access to them ? you might be able to use some hack like a name comparison heuristic or private reflection or something to bring it all together).
>
> From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Ori Peleg
> Sent: Thursday, November 06, 2008 2:27 PM
> To: us... at lists.ironpython.com
> Subject: [IronPython] Porting from CPython: Figuring out the calling code's directory
>
> Hi,
>
> I'm porting Testoob to IronPython and have a module function that needs to know the filename where the code calling it is defined.
>
> In CPython I get the current frame with sys._getframe(), then climb
> the stack with frame.f_back until I find a different file:
>
> def _first_external_frame():
> ? ?import sys
>
> ? ?# find the first frame with a filename different than this one
> ? ?frame = sys._getframe()
> ? ?while frame.f_globals["__file__"] == __file__:
> ? ? ? ?frame = frame.f_back
>
> ? ?return frame
>
> def _calling_module_directory():
> ? ?from os.path import dirname, normpath
> ? ?return normpath(dirname(_first_external_frame().f_globals["__file__"]))
>
> I know I can't climb the stack in IronPython, but is there another way
> to do it? Maybe some available .NET assembly metadata?
>
> BTW - the use case is for building test suites: you can have a
> subpackage of tests and define __init__.py like this:
>
> def suite():
> ? ?import testoob
> ? ?return testoob.collecting.collect_from_files("test_*.py")
>
> Thanks,
> orip.
>
> --
> Check out my blog:http://orip.org
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From oripel at gmail.com  Sat Nov  8 21:38:51 2008
From: oripel at gmail.com (orip)
Date: Sat, 8 Nov 2008 12:38:51 -0800 (PST)
Subject: [IronPython] Porting from CPython: Figuring out the calling
	code's directory
In-Reply-To: <491424CE.3070908@voidspace.org.uk>
References: <620765220811060643w681ee9dap924500cde40c4c61@mail.gmail.com> 
	<620765220811061427t34c87bd8g28bca638f8d94f77@mail.gmail.com> 
	<491424CE.3070908@voidspace.org.uk>
Message-ID: <0c52f9ee-4c53-4cf2-9f11-9b59ffc0a03e@a17g2000prm.googlegroups.com>

Great idea Michael, thanks! A small price to pay to make it work with
IronPython.
I'll probably make it optional (affect only IronPython users).

On Nov 7, 1:21?pm, Michael Foord <fuzzy... at voidspace.org.uk> wrote:
> Why not change the API to:
>
> ? ?return testoob.collecting.collect_from_files("test_*.py", __file__)


From oripel at gmail.com  Sat Nov  8 21:44:40 2008
From: oripel at gmail.com (orip)
Date: Sat, 8 Nov 2008 12:44:40 -0800 (PST)
Subject: [IronPython] Cross-python development: detecting IronPython
Message-ID: <a6c61af8-eb4f-4c8b-be88-552449a57b1a@v13g2000pro.googlegroups.com>

I'm sorry if this is a repeat (my search abilities failed me), but
what's the standard way to detect whether the current Python platform
is IronPython?

I usually prefer to check for abilities instead of platforms, but
sometimes it's inevitable.

Thanks, orip.


From curt at hagenlocher.org  Sat Nov  8 21:47:35 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Sat, 8 Nov 2008 12:47:35 -0800
Subject: [IronPython] Cross-python development: detecting IronPython
In-Reply-To: <a6c61af8-eb4f-4c8b-be88-552449a57b1a@v13g2000pro.googlegroups.com>
References: <a6c61af8-eb4f-4c8b-be88-552449a57b1a@v13g2000pro.googlegroups.com>
Message-ID: <d2155e360811081247x5a5706f5k7e3523946374ba2e@mail.gmail.com>

>>> import sys
>>> sys.platform
'cli'
>>>

On Sat, Nov 8, 2008 at 12:44 PM, orip <oripel at gmail.com> wrote:

> I'm sorry if this is a repeat (my search abilities failed me), but
> what's the standard way to detect whether the current Python platform
> is IronPython?
>
> I usually prefer to check for abilities instead of platforms, but
> sometimes it's inevitable.
>
> Thanks, orip.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081108/2fefd194/attachment.html>

From oripel at gmail.com  Sat Nov  8 21:51:31 2008
From: oripel at gmail.com (orip)
Date: Sat, 8 Nov 2008 12:51:31 -0800 (PST)
Subject: [IronPython] Cross-python development: detecting IronPython
In-Reply-To: <d2155e360811081247x5a5706f5k7e3523946374ba2e@mail.gmail.com>
References: <a6c61af8-eb4f-4c8b-be88-552449a57b1a@v13g2000pro.googlegroups.com>
	<d2155e360811081247x5a5706f5k7e3523946374ba2e@mail.gmail.com>
Message-ID: <4bdbd9cb-edf6-486f-8513-020d273e6cab@o40g2000prn.googlegroups.com>

Thanks!

On Nov 8, 10:47?pm, "Curt Hagenlocher" <c... at hagenlocher.org> wrote:
> >>> import sys
> >>> sys.platform
> 'cli'
>
> On Sat, Nov 8, 2008 at 12:44 PM, orip <ori... at gmail.com> wrote:
> > I'm sorry if this is a repeat (my search abilities failed me), but
> > what's the standard way to detect whether the current Python platform
> > is IronPython?
>
> > I usually prefer to check for abilities instead of platforms, but
> > sometimes it's inevitable.
>
> > Thanks, orip.
> > _______________________________________________
> > Users mailing list
> > Us... at lists.ironpython.com
> >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From daftspaniel at gmail.com  Sat Nov  8 22:58:32 2008
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Sat, 8 Nov 2008 21:58:32 +0000
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
In-Reply-To: <350E7D38B6D819428718949920EC2355516948C3EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
	<7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>
	<20253b0c0811080619vca0bf40r7ffe512204021ccf@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355516948C3EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <20253b0c0811081358w105ddd3at370d968493b92630@mail.gmail.com>

Thanks Dino - here's the info:
Unhandled Exception: System.Threading.ThreadStateException: ActiveX control
'8856f961-340a-11d0-a96b-00c04fd705a2' cannot be instantiated because the
current thread is not in a single-threaded apartment.
   at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
   at System.Windows.Forms.WebBrowser..ctor()
   at _stub_$24##21(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at
Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
site, T0 arg0, T1 arg1)
   at S$1.__init__$7(Closure , Object self)
   at _stub_$18##15(Closure , CallSite , CodeContext , Object , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call3[T0,T1,T2,TRet](Func`5
target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at
Microsoft.Scripting.Actions.UpdateDelegates.Update3[T,T0,T1,T2,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2)
   at _stub_$17##14(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at
Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
site, T0 arg0, T1 arg1)
   at _stub_$16##13(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at
Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
site, T0 arg0, T1 arg1)
   at S$1.Initialize(Scope $scope, LanguageContext $language)
   at
Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression
code, Scope scope)
   at Microsoft.Scripting.ScriptCode.Run(Scope scope)
   at IronPython.Runtime.PythonContext.CreateModule(String fileName, Scope
scope, ScriptCode scriptCode, ModuleOptions options)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName, String
moduleName, SourceUnit sourceCode, ModuleOptions options, ScriptCode&
scriptCode)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName, String
moduleName, SourceUnit sourceCode, ModuleOptions options)
   at IronPython.Runtime.Importer.LoadFromSourceUnit(CodeContext context,
SourceUnit sourceCode, String name, String path)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext context,
String name, String path)
   at IronPython.Runtime.Importer.LoadFromDisk(CodeContext context, String
name, String fullName, String str)
   at IronPython.Runtime.Importer.ImportFromPathHook(CodeContext context,
String name, String fullName, List path, Func`5 defaultLoader)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context, String
name, String fullName, List path)
   at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
String name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context, Object
globals, String modName, Boolean bottom, Int32 level)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String
name, Object globals, Object locals, Object fromlist, Int32 level)
   at _stub_$1##1(Closure , CallSite , CodeContext , Object , String ,
IAttributesCollection , IAttributesCollection , PythonTuple , Int32 )
   at
Microsoft.Scripting.Actions.MatchCaller.Call7[T0,T1,T2,T3,T4,T5,T6,TRet](Func`9
target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at
Microsoft.Scripting.Actions.UpdateDelegates.Update7[T,T0,T1,T2,T3,T4,T5,T6,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6
rg6)
   at IronPython.Runtime.Importer.Import(CodeContext context, String
fullName, PythonTuple from, Int32 level)
   at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly
precompiled, String main, String[] references)
   at PythonMain.Main()

Repro code is:

import clr
clr.AddReference('System.Windows.Forms')
from System.Windows.Forms import *

class MainForm(Form):
    def __init__(self):
        self.Dock = DockStyle.Fill
        self.Controls.Add(WebBrowser())
form = MainForm()
Application.Run(form)

Compiled with:
ipy pyc.py /out:wf /target:winexe /main:repro.py

-X:ExceptionDetail didn't alter the output from the exe. Run from ipy there
was no issue.

Cheers,
Davy

On Sat, Nov 8, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com> wrote:

> I'd start w/ -X:ExceptionDetail to get the full stack trace.  Presumably
> there's something higher up the stack then the MatchCaller on the stack.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
> Sent: Saturday, November 08, 2008 6:19 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] ActiveX STA Issue in compiled Winforms EXE
>
> Hi Michael
>
> >Are you doing this from a separate thread?
>
> No.
>
> It's a couple of modules deep from the 'main' script. Was going to try
> a single py file to repro.
>
> > I assume it works fine when run uncompiled?
>
> Yep, runs great.
> Cheers,
> Davy
>
>
> On 11/8/08, Michael <fuzzyman at gmail.com> wrote:
> > Are you doing this from a separate thread? I assume it works fine when
> > run uncompiled?
> >
> >
> > Michael
> >
> > http://www.ironpythoninaction.com
> >
> > On 8 Nov 2008, at 12:10, "Davy Mitchell" <daftspaniel at gmail.com> wrote:
> >
> >> IPY 2.0 RC1
> >>
> >>
> >> ActiveX Issue in a pyc compiled Winforms EXE which uses the
> >> WebBrowser control.
> >>
> >> Unhandled Exception: System.Threading.ThreadStateException: ActiveX
> >> control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be
> >> instantiated because the current thread is not in a single-threaded
> >> apartment.
> >>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
> >>    at System.Windows.Forms.WebBrowser..ctor()
> >>    at _stub_$643##332(Closure , CallSite , CodeContext , Object )
> >>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet]
> >> (Func`4 target, C
> >>
> >> Help!! :-)
> >>
> >> Any thoughts before I delve further into this?
> >>
> >> Thanks
> >> Davy Mitchell
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081108/47e5e6c2/attachment.html>

From dinov at microsoft.com  Sat Nov  8 23:13:58 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 8 Nov 2008 14:13:58 -0800
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
In-Reply-To: <20253b0c0811081358w105ddd3at370d968493b92630@mail.gmail.com>
References: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
	<7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>
	<20253b0c0811080619vca0bf40r7ffe512204021ccf@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355516948C3EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<20253b0c0811081358w105ddd3at370d968493b92630@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355516948C400@NA-EXMSG-C102.redmond.corp.microsoft.com>

Oh, the problem is that pyc.py doesn't mark the thread as STA.  You can add this line to pyc.py right after mainMethod = ...

mainMethod.SetCustomAttribute(clr.GetClrType(System.STAThreadAttribute).GetConstructor(()), System.Array[System.Byte](()))

and it should work.  We should do that by default for winexe's and probably offer an option to control STA/MTA for non-WinEXEs.

Thanks for reporting this.  I've opened a bug (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19409) and we can probably refresh the sample.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
Sent: Saturday, November 08, 2008 1:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] ActiveX STA Issue in compiled Winforms EXE

Thanks Dino - here's the info:

Unhandled Exception: System.Threading.ThreadStateException: ActiveX control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be instantiated because the current thread is not in a single-threaded apartment.
   at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
   at System.Windows.Forms.WebBrowser..ctor()
   at _stub_$24##21(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4 target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
   at S$1.__init__$7(Closure , Object self)
   at _stub_$18##15(Closure , CallSite , CodeContext , Object , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call3[T0,T1,T2,TRet](Func`5 target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at Microsoft.Scripting.Actions.UpdateDelegates.Update3[T,T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
   at _stub_$17##14(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4 target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
   at _stub_$16##13(Closure , CallSite , CodeContext , Object )
   at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4 target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
   at S$1.Initialize(Scope $scope, LanguageContext $language)
   at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope)
   at Microsoft.Scripting.ScriptCode.Run(Scope scope)
   at IronPython.Runtime.PythonContext.CreateModule(String fileName, Scope scope, ScriptCode scriptCode, ModuleOptions options)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName, String moduleName, SourceUnit sourceCode, ModuleOptions options, ScriptCode& scriptCode)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName, String moduleName, SourceUnit sourceCode, ModuleOptions options)
   at IronPython.Runtime.Importer.LoadFromSourceUnit(CodeContext context, SourceUnit sourceCode, String name, String path)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext context, String name, String path)
   at IronPython.Runtime.Importer.LoadFromDisk(CodeContext context, String name, String fullName, String str)
   at IronPython.Runtime.Importer.ImportFromPathHook(CodeContext context, String name, String fullName, List path, Func`5 defaultLoader)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context, String name, String fullName, List path)
   at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context, String name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context, Object globals, String modName, Boolean bottom, Int32 level)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String name, Object globals, Object locals, Object fromlist, Int32 level)
   at _stub_$1##1(Closure , CallSite , CodeContext , Object , String , IAttributesCollection , IAttributesCollection , PythonTuple , Int32 )
   at Microsoft.Scripting.Actions.MatchCaller.Call7[T0,T1,T2,T3,T4,T5,T6,TRet](Func`9 target, CallSite site, Object[] args)
   at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args)
   at Microsoft.Scripting.Actions.UpdateDelegates.Update7[T,T0,T1,T2,T3,T4,T5,T6,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6
rg6)
   at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level)
   at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly precompiled, String main, String[] references)
   at PythonMain.Main()

Repro code is:

import clr
clr.AddReference('System.Windows.Forms')
from System.Windows.Forms import *

class MainForm(Form):
    def __init__(self):
        self.Dock = DockStyle.Fill
        self.Controls.Add(WebBrowser())
form = MainForm()
Application.Run(form)

Compiled with:
ipy pyc.py /out:wf /target:winexe /main:repro.py

-X:ExceptionDetail didn't alter the output from the exe. Run from ipy there was no issue.

Cheers,
Davy
On Sat, Nov 8, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:
I'd start w/ -X:ExceptionDetail to get the full stack trace.  Presumably there's something higher up the stack then the MatchCaller on the stack.

-----Original Message-----
From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Davy Mitchell
Sent: Saturday, November 08, 2008 6:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] ActiveX STA Issue in compiled Winforms EXE

Hi Michael

>Are you doing this from a separate thread?

No.

It's a couple of modules deep from the 'main' script. Was going to try
a single py file to repro.

> I assume it works fine when run uncompiled?

Yep, runs great.
Cheers,
Davy


On 11/8/08, Michael <fuzzyman at gmail.com<mailto:fuzzyman at gmail.com>> wrote:
> Are you doing this from a separate thread? I assume it works fine when
> run uncompiled?
>
>
> Michael
>
> http://www.ironpythoninaction.com
>
> On 8 Nov 2008, at 12:10, "Davy Mitchell" <daftspaniel at gmail.com<mailto:daftspaniel at gmail.com>> wrote:
>
>> IPY 2.0 RC1
>>
>>
>> ActiveX Issue in a pyc compiled Winforms EXE which uses the
>> WebBrowser control.
>>
>> Unhandled Exception: System.Threading.ThreadStateException: ActiveX
>> control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be
>> instantiated because the current thread is not in a single-threaded
>> apartment.
>>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
>>    at System.Windows.Forms.WebBrowser..ctor()
>>    at _stub_$643##332(Closure , CallSite , CodeContext , Object )
>>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet]
>> (Func`4 target, C
>>
>> Help!! :-)
>>
>> Any thoughts before I delve further into this?
>>
>> Thanks
>> Davy Mitchell
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081108/f05e7ca2/attachment.html>

From dan.eloff at gmail.com  Sat Nov  8 23:18:45 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Sat, 8 Nov 2008 17:18:45 -0500
Subject: [IronPython] Cross-python development: detecting IronPython
In-Reply-To: <a6c61af8-eb4f-4c8b-be88-552449a57b1a@v13g2000pro.googlegroups.com>
References: <a6c61af8-eb4f-4c8b-be88-552449a57b1a@v13g2000pro.googlegroups.com>
Message-ID: <4817b6fc0811081418x357cb97ax3fd2fc69cb28f18@mail.gmail.com>

I always use sys.platform in ('cli', 'silverlight') because I do a lot
of silverlight stuff, but it depends on your scenario.

On Sat, Nov 8, 2008 at 3:44 PM, orip <oripel at gmail.com> wrote:
> I'm sorry if this is a repeat (my search abilities failed me), but
> what's the standard way to detect whether the current Python platform
> is IronPython?
>
> I usually prefer to check for abilities instead of platforms, but
> sometimes it's inevitable.
>
> Thanks, orip.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From daftspaniel at gmail.com  Sun Nov  9 08:42:11 2008
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Sun, 9 Nov 2008 07:42:11 +0000
Subject: [IronPython] ActiveX STA Issue in compiled Winforms EXE
In-Reply-To: <350E7D38B6D819428718949920EC2355516948C400@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <20253b0c0811080410m171c165fo51c0cde7c5557d4@mail.gmail.com>
	<7BD553EC-C9E8-4D7B-8D56-FF65E2D32C81@gmail.com>
	<20253b0c0811080619vca0bf40r7ffe512204021ccf@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355516948C3EC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<20253b0c0811081358w105ddd3at370d968493b92630@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355516948C400@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <20253b0c0811082342y22a06bdmb0f55ed74cee9baf@mail.gmail.com>

Thanks Dino - works great now. Runtime speed is much snappier when compiled.

One other thing I spotted is that pyc always builds a console app if /main
is specified.

        elif arg.startswith("/main:"):
            main_name = main = arg[6:]
            target = System.Reflection.Emit.PEFileKinds.ConsoleApplication

Confused me for a bit :-) Have added this to Codeplex issue.

Cheers,Davy Mitchell

On Sat, Nov 8, 2008 at 10:13 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  Oh, the problem is that pyc.py doesn't mark the thread as STA.  You can
> add this line to pyc.py right after mainMethod = ?
>
>
>
> mainMethod.SetCustomAttribute(clr.GetClrType(System.STAThreadAttribute).GetConstructor(()),
> System.Array[System.Byte](()))
>
>
>
> and it should work.  We should do that by default for winexe's and probably
> offer an option to control STA/MTA for non-WinEXEs.
>
>
>
> Thanks for reporting this.  I've opened a bug (
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19409)
> and we can probably refresh the sample.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Davy Mitchell
> *Sent:* Saturday, November 08, 2008 1:59 PM
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] ActiveX STA Issue in compiled Winforms EXE
>
>
>
> Thanks Dino - here's the info:
>
>
>
> Unhandled Exception: System.Threading.ThreadStateException: ActiveX control
> '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be instantiated because the
> current thread is not in a single-threaded apartment.
>
>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
>
>    at System.Windows.Forms.WebBrowser..ctor()
>
>    at _stub_$24##21(Closure , CallSite , CodeContext , Object )
>
>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
> target, CallSite site, Object[] args)
>
>    at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[]
> args)
>
>    at
> Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
>
>    at S$1.__init__$7(Closure , Object self)
>
>    at _stub_$18##15(Closure , CallSite , CodeContext , Object , Object )
>
>    at Microsoft.Scripting.Actions.MatchCaller.Call3[T0,T1,T2,TRet](Func`5
> target, CallSite site, Object[] args)
>
>    at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[]
> args)
>
>    at
> Microsoft.Scripting.Actions.UpdateDelegates.Update3[T,T0,T1,T2,TRet](CallSite
> site, T0 arg0, T1 arg1, T2 arg2)
>
>    at _stub_$17##14(Closure , CallSite , CodeContext , Object )
>
>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
> target, CallSite site, Object[] args)
>
>    at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[]
> args)
>
>    at
> Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
>
>    at _stub_$16##13(Closure , CallSite , CodeContext , Object )
>
>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet](Func`4
> target, CallSite site, Object[] args)
>
>    at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[]
> args)
>
>    at
> Microsoft.Scripting.Actions.UpdateDelegates.Update2[T,T0,T1,TRet](CallSite
> site, T0 arg0, T1 arg1)
>
>    at S$1.Initialize(Scope $scope, LanguageContext $language)
>
>    at
> Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression
> code, Scope scope)
>
>    at Microsoft.Scripting.ScriptCode.Run(Scope scope)
>
>    at IronPython.Runtime.PythonContext.CreateModule(String fileName, Scope
> scope, ScriptCode scriptCode, ModuleOptions options)
>
>    at IronPython.Runtime.PythonContext.CompileModule(String fileName,
> String moduleName, SourceUnit sourceCode, ModuleOptions options, ScriptCode&
> scriptCode)
>
>    at IronPython.Runtime.PythonContext.CompileModule(String fileName,
> String moduleName, SourceUnit sourceCode, ModuleOptions options)
>
>    at IronPython.Runtime.Importer.LoadFromSourceUnit(CodeContext context,
> SourceUnit sourceCode, String name, String path)
>
>    at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext context,
> String name, String path)
>
>    at IronPython.Runtime.Importer.LoadFromDisk(CodeContext context, String
> name, String fullName, String str)
>
>    at IronPython.Runtime.Importer.ImportFromPathHook(CodeContext context,
> String name, String fullName, List path, Func`5 defaultLoader)
>
>    at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
> String name, String fullName, List path)
>
>    at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
> String name)
>
>    at IronPython.Runtime.Importer.ImportModule(CodeContext context, Object
> globals, String modName, Boolean bottom, Int32 level)
>
>    at IronPython.Runtime.Builtin.__import__(CodeContext context, String
> name, Object globals, Object locals, Object fromlist, Int32 level)
>
>    at _stub_$1##1(Closure , CallSite , CodeContext , Object , String ,
> IAttributesCollection , IAttributesCollection , PythonTuple , Int32 )
>
>    at
> Microsoft.Scripting.Actions.MatchCaller.Call7[T0,T1,T2,T3,T4,T5,T6,TRet](Func`9
> target, CallSite site, Object[] args)
>
>    at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[]
> args)
>
>    at
> Microsoft.Scripting.Actions.UpdateDelegates.Update7[T,T0,T1,T2,T3,T4,T5,T6,TRet](CallSite
> site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6
>
> rg6)
>
>    at IronPython.Runtime.Importer.Import(CodeContext context, String
> fullName, PythonTuple from, Int32 level)
>
>    at IronPython.Runtime.Operations.PythonOps.InitializeModule(Assembly
> precompiled, String main, String[] references)
>
>    at PythonMain.Main()
>
>
>
> Repro code is:
>
>
>
> import clr
>
> clr.AddReference('System.Windows.Forms')
>
> from System.Windows.Forms import *
>
>
>
> class MainForm(Form):
>
>     def __init__(self):
>
>         self.Dock = DockStyle.Fill
>
>         self.Controls.Add(WebBrowser())
>
> form = MainForm()
>
> Application.Run(form)
>
>
>
> Compiled with:
>
> ipy pyc.py /out:wf /target:winexe /main:repro.py
>
>
>
> -X:ExceptionDetail didn't alter the output from the exe. Run from ipy there
> was no issue.
>
>
>
> Cheers,
>
> Davy
>
> On Sat, Nov 8, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com> wrote:
>
> I'd start w/ -X:ExceptionDetail to get the full stack trace.  Presumably
> there's something higher up the stack then the MatchCaller on the stack.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
> Sent: Saturday, November 08, 2008 6:19 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] ActiveX STA Issue in compiled Winforms EXE
>
> Hi Michael
>
> >Are you doing this from a separate thread?
>
> No.
>
> It's a couple of modules deep from the 'main' script. Was going to try
> a single py file to repro.
>
> > I assume it works fine when run uncompiled?
>
> Yep, runs great.
> Cheers,
> Davy
>
>
> On 11/8/08, Michael <fuzzyman at gmail.com> wrote:
> > Are you doing this from a separate thread? I assume it works fine when
> > run uncompiled?
> >
> >
> > Michael
> >
> > http://www.ironpythoninaction.com
> >
> > On 8 Nov 2008, at 12:10, "Davy Mitchell" <daftspaniel at gmail.com> wrote:
> >
> >> IPY 2.0 RC1
> >>
> >>
> >> ActiveX Issue in a pyc compiled Winforms EXE which uses the
> >> WebBrowser control.
> >>
> >> Unhandled Exception: System.Threading.ThreadStateException: ActiveX
> >> control '8856f961-340a-11d0-a96b-00c04fd705a2' cannot be
> >> instantiated because the current thread is not in a single-threaded
> >> apartment.
> >>    at System.Windows.Forms.WebBrowserBase..ctor(String clsidString)
> >>    at System.Windows.Forms.WebBrowser..ctor()
> >>    at _stub_$643##332(Closure , CallSite , CodeContext , Object )
> >>    at Microsoft.Scripting.Actions.MatchCaller.Call2[T0,T1,TRet]
> >> (Func`4 target, C
> >>
> >> Help!! :-)
> >>
> >> Any thoughts before I delve further into this?
> >>
> >> Thanks
> >> Davy Mitchell
> >> _______________________________________________
> >> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081109/5a52c57f/attachment.html>

From glenn.k.jones+ipy at gmail.com  Mon Nov 10 12:00:08 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Mon, 10 Nov 2008 11:00:08 +0000
Subject: [IronPython] namespaces and modules in IP2
Message-ID: <2679f6510811100300y134636fek92fd7034c798b18@mail.gmail.com>

Hi all,

We are working on porting our application from IP1 to IP2. We have reached a
bit of code where we relied on System.Windows.Forms being a module (we were
monkey patching it) and in IP2 it is now a namespace and we cannot set
attributes on it.

We can probably work around the change, but we're not sure whether we should
if the change is a regression and a fix is forthcoming.

Is this a regression or an intentional change?

Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081110/36ebaa49/attachment.html>

From dinov at microsoft.com  Mon Nov 10 17:49:08 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 10 Nov 2008 08:49:08 -0800
Subject: [IronPython] namespaces and modules in IP2
In-Reply-To: <2679f6510811100300y134636fek92fd7034c798b18@mail.gmail.com>
References: <2679f6510811100300y134636fek92fd7034c798b18@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355539D6BD0A4@NA-EXMSG-C102.redmond.corp.microsoft.com>

I think it's largely intentional.  In v1 we exposed namespaces as modules and also did ugly things like supported merging of namespaces and modules.  In V2 we did a bunch of cleanup there and moved the former Python code into the outer layer of the DLR.  That involved also making the namespaces read-only just like other .NET objects.  If there was significant interest we could make them mutable again - if you really would like to see it come back I'd suggest opening a feature on CodePlex and encourage people to vote on it.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Monday, November 10, 2008 3:00 AM
To: users at lists.ironpython.com
Subject: [IronPython] namespaces and modules in IP2

Hi all,

We are working on porting our application from IP1 to IP2. We have reached a bit of code where we relied on System.Windows.Forms being a module (we were monkey patching it) and in IP2 it is now a namespace and we cannot set attributes on it.

We can probably work around the change, but we're not sure whether we should if the change is a regression and a fix is forthcoming.

Is this a regression or an intentional change?

Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081110/b6728832/attachment.html>

From dan.eloff at gmail.com  Mon Nov 10 21:56:20 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Mon, 10 Nov 2008 14:56:20 -0600
Subject: [IronPython] namespaces and modules in IP2
In-Reply-To: <350E7D38B6D819428718949920EC2355539D6BD0A4@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <2679f6510811100300y134636fek92fd7034c798b18@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355539D6BD0A4@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0811101256s1dbb487apb2aa0760bbad5246@mail.gmail.com>

I'm curious about the specific use case, there's probably many ways to
accomplish the task for which you were monkey patching the windows
forms namespace. Is such a feature useful, or is there a reasonable
alternative?

-Dan


From fuzzyman at voidspace.org.uk  Mon Nov 10 22:25:30 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 10 Nov 2008 21:25:30 +0000
Subject: [IronPython] namespaces and modules in IP2
In-Reply-To: <4817b6fc0811101256s1dbb487apb2aa0760bbad5246@mail.gmail.com>
References: <2679f6510811100300y134636fek92fd7034c798b18@mail.gmail.com>	<350E7D38B6D819428718949920EC2355539D6BD0A4@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811101256s1dbb487apb2aa0760bbad5246@mail.gmail.com>
Message-ID: <4918A6CA.7060906@voidspace.org.uk>

Dan Eloff wrote:
> I'm curious about the specific use case, there's probably many ways to
> accomplish the task for which you were monkey patching the windows
> forms namespace. Is such a feature useful, or is there a reasonable
> alternative?
>   
The actual use case is to test a code path that imports windows forms 
inside the body of a method.

It is part of our startup code and we don't need to unconditionally 
import Windows Forms for the whole module (and need to import as little 
as possible at that point). Possibly moving that code into a support 
module where is can be more easily tested on its own would resolve this 
specific situation.

Michael Foord

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


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From paul.eric.felix at gmail.com  Tue Nov 11 21:31:42 2008
From: paul.eric.felix at gmail.com (Paul Felix)
Date: Tue, 11 Nov 2008 15:31:42 -0500
Subject: [IronPython] IronPython 2.0 RC1 and Mono
Message-ID: <c63b34ec0811111231k19f19d2dqaa1d479a50f728d4@mail.gmail.com>

Hi,

The following Mono patches will allow IronPython 2.0 RC1 to run on Mono 2.0:

http://go-mono.com/forums/#nabble-to20363627
http://go-mono.com/forums/#nabble-to20389995

Paul


From jtgalyon at gmail.com  Wed Nov 12 02:42:56 2008
From: jtgalyon at gmail.com (Jason Galyon)
Date: Tue, 11 Nov 2008 19:42:56 -0600
Subject: [IronPython] IronPython 1.1.2 and overloaded or generic methods
Message-ID: <491A34A0.1020609@gmail.com>

Howdy,
I am new to IronPython with absolutely no knowledge yet of .NET/CLR.
I am trying to use IronPython with a new API from a particular system 
where the methods are overloaded as you can see below from the 
interactive prompt.
How do I call a particular method with the signature I want?

Secondary question is whether there will ever be a more Pythonic way of 
dealing with these?

Thanks in advance for any information!
Jason

IronPython 1.1.2 (1.1.2) on .NET 2.0.50727.3053
Copyright (c) Microsoft Corporation. All rights reserved.
... add reference and importing ...
 >>> rancore.Repository.ElementRepository.CreateAdapterForPath.Overloads
<IronPython.Runtime.Calls.BuiltinFunctionOverloadMapper object at 
0x000000000000
0030 [{'T CreateAdapterForPath[T](str path)': <built-in function 
CreateAdapterFo
rPath>, 'T CreateAdapterForPath[T](str path, int timeout)': <built-in 
function C
reateAdapterForPath>}]>
 >>> 
rancore.Repository.ElementRepository.CreateAdapterForPath[str].Overloads[str
]('/form[@title="System\ Requirements\ -\ Mozilla')
Traceback (most recent call last):
  File , line 0, in <stdin>##79
ValueError: GenericArguments[0], 'System.String', on 'T 
CreateAdapterForPath[T](
System.String)' violates the constraint of type 'T'.


From dinov at microsoft.com  Wed Nov 12 03:35:49 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 11 Nov 2008 18:35:49 -0800
Subject: [IronPython] IronPython 1.1.2 and overloaded or generic methods
In-Reply-To: <491A34A0.1020609@gmail.com>
References: <491A34A0.1020609@gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441C9A5@NA-EXMSG-C102.redmond.corp.microsoft.com>

I think you want to do:

rancore.Repository.ElementRepository.CreateAdapterForPath[str][str](...)
  or:
rancore.Repository.ElementRepository.CreateAdapterForPath[str].Overloads[str][str](...)
  or:
rancore.Repository.ElementRepository.CreateAdapterForPath[str][str].Overloads[str](...)


I think the 2nd two will be equivalent but just perform the operations in a different order.  The 1st should give you a generic method which has both overloads.

Overloads is for selecting one of the various methods.  So you have 3 things to index into:
        The generic type, to provide it's type parameters
        The generic method, to provide the method's type parameters
        The Overloads, to select an individual method out of the set of overloaded methods.

There still might be a generic constraint that you're violating though.  Looking at the API my guess would be that there is a constraint that the object must implement new.   You might try:

rancore.Repository.ElementRepository.CreateAdapterForPath[str][object](...)

as object contains a default constructor.  If that doesn't work then you'll need to get the constraints which should be in the docs or you could open the assembly with reflector.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jason Galyon
Sent: Tuesday, November 11, 2008 5:43 PM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython 1.1.2 and overloaded or generic methods

Howdy,
I am new to IronPython with absolutely no knowledge yet of .NET/CLR.
I am trying to use IronPython with a new API from a particular system
where the methods are overloaded as you can see below from the
interactive prompt.
How do I call a particular method with the signature I want?

Secondary question is whether there will ever be a more Pythonic way of
dealing with these?

Thanks in advance for any information!
Jason

IronPython 1.1.2 (1.1.2) on .NET 2.0.50727.3053
Copyright (c) Microsoft Corporation. All rights reserved.
... add reference and importing ...
 >>> rancore.Repository.ElementRepository.CreateAdapterForPath.Overloads
<IronPython.Runtime.Calls.BuiltinFunctionOverloadMapper object at
0x000000000000
0030 [{'T CreateAdapterForPath[T](str path)': <built-in function
CreateAdapterFo
rPath>, 'T CreateAdapterForPath[T](str path, int timeout)': <built-in
function C
reateAdapterForPath>}]>
 >>>
rancore.Repository.ElementRepository.CreateAdapterForPath[str].Overloads[str
]('/form[@title="System\ Requirements\ -\ Mozilla')
Traceback (most recent call last):
  File , line 0, in <stdin>##79
ValueError: GenericArguments[0], 'System.String', on 'T
CreateAdapterForPath[T](
System.String)' violates the constraint of type 'T'.
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From fuzzyman at voidspace.org.uk  Wed Nov 12 08:24:10 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 12 Nov 2008 07:24:10 +0000
Subject: [IronPython] Codeplex Issue:
Message-ID: <491A849A.3030807@voidspace.org.uk>

Hello guys,

Sorry to do this by email, but I'm travelling (anyone on list going to 
be at PyWorks?)  and the internet connection is too ropey for me to 
comment directly on Codeplex.

I wanted to make a (minor!) comment regarding Codeplex issue 19488.

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19488

In general it is great - IronPython samples *should* follow PEP 8 as 
much as possible (how come Ruby guys got nice method aliasing and we 
didn't by the way? Hmm... maybe excessive aliasing isn't Pythonic).

*However* I'd just like to clarify the use of the double underscore 
prefix on class member names.

The issue states:

"there's a class in formv8.py that has named members such as 
"self._button1". I think what was actually intended here was 
"self.__button1" to make button1 a pseudo-private member. We need to fix 
this so new Python developers don't get confused"

Using a single underscore prefix is the *correct* way to indicate that a 
member is private in Python. The purpose of the double underscore name 
mangling is actually an admitted hack to avoid name collisions in 
inheritance - not to provide private members.

(Today's lesson is *never* use double underscore prefix member names 
unless you really have to - and even then you or someone else will still 
regret it. :-) That's all - nit-pick over.

Michael

-- 
http://www.ironpythoninaction.com/



From sanxiyn at gmail.com  Wed Nov 12 12:21:15 2008
From: sanxiyn at gmail.com (Seo Sanghyeon)
Date: Wed, 12 Nov 2008 20:21:15 +0900
Subject: [IronPython] Codeplex Issue:
In-Reply-To: <491A849A.3030807@voidspace.org.uk>
References: <491A849A.3030807@voidspace.org.uk>
Message-ID: <5b0248170811120321o1e6d3641mbcfde715091ba62d@mail.gmail.com>

2008/11/12 Michael Foord <fuzzyman at voidspace.org.uk>:
> In general it is great - IronPython samples *should* follow PEP 8 as much as
> possible (how come Ruby guys got nice method aliasing and we didn't by the
> way? Hmm... maybe excessive aliasing isn't Pythonic).

I agree. IronRuby's "rubification" of method name is on too "magic" side for me,
and hopefully not Pythonic. :)

-- 
Seo Sanghyeon


From wilfredo.lugo at gmail.com  Wed Nov 12 17:31:57 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Wed, 12 Nov 2008 12:31:57 -0400
Subject: [IronPython] Performance Issue
Message-ID: <8aac47860811120831v5b07453eo9b51fd16b6cab49@mail.gmail.com>

Hi All,

I have a Python interpolation script which basically reads data from a file
and perform a linear interpolation of the data present on the file.  I have
been using this script for some time.  Right now I am working on a C#
application that also performs linear interpolation, so I decided to use
IronPython to call my script.  However, I am havving a huge performance
difference from running the script on common python and running it on
IronPython.

Here is an output of the following command using normal python (Cygwin under
windows Vista):

$ date +%M:%S;python interpolate.py;date +%M:%S
15:27
WARNING: desired starting time (Tue Jan  1 00:00:21 2008) prior to time of
first
 data point (Tue Jan  1 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
15:31
-----------------------------------------------------------------------------

It basically took 4 seconds to complete.  Now if I run it on IronPython
using VS and C# (Release mode) here is the output:

11/12/2008 12:16:34 PM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/12/2008 12:19:07 PM
-----------------------------------------------------------------------------

The same script is taking more than 3 minutes and a half.

Here is the C# Code:
-----------------------------------------------------------------------------
static void Main(string[] args)
        {
            ScriptRuntime runtime = Python.CreateRuntime();
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source =
engine.CreateScriptSourceFromFile("interpolate.py");
            ScriptScope scope = engine.CreateScope();
            Console.WriteLine(DateTime.Now);
            source.Execute(scope);
            Microsoft.Func<string, string, string, string, int, int> func =
scope.GetVariable<Microsoft.Func<string, string, string, string, int,
int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
"2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }

I am using IronPython 2.0B5 and Visual Studio 2003 running on .Net3.0
Windows Vista.  The script and the C# code were run on the same machine.

If there is something I am doing wrong?  I really don't understand the
performance difference.

regards,

wilfredo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/4c0e718a/attachment.html>

From dfugate at microsoft.com  Wed Nov 12 17:43:30 2008
From: dfugate at microsoft.com (Dave Fugate)
Date: Wed, 12 Nov 2008 08:43:30 -0800
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811120831v5b07453eo9b51fd16b6cab49@mail.gmail.com>
References: <8aac47860811120831v5b07453eo9b51fd16b6cab49@mail.gmail.com>
Message-ID: <EECFB552375FDE49A23A13CE85EEC2FD1E94F05DA4@NA-EXMSG-C112.redmond.corp.microsoft.com>

How does python.exe compare directly to ipy.exe?  That is, try running "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting APIs.

Thanks,

Dave
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 8:32 AM
To: users at lists.ironpython.com
Subject: [IronPython] Performance Issue


Hi All,

I have a Python interpolation script which basically reads data from a file and perform a linear interpolation of the data present on the file.  I have been using this script for some time.  Right now I am working on a C# application that also performs linear interpolation, so I decided to use IronPython to call my script.  However, I am havving a huge performance difference from running the script on common python and running it on IronPython.

Here is an output of the following command using normal python (Cygwin under windows Vista):

$ date +%M:%S;python interpolate.py;date +%M:%S
15:27
WARNING: desired starting time (Tue Jan  1 00:00:21 2008) prior to time of first
 data point (Tue Jan  1 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
15:31
-----------------------------------------------------------------------------

It basically took 4 seconds to complete.  Now if I run it on IronPython using VS and C# (Release mode) here is the output:

11/12/2008 12:16:34 PM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/12/2008 12:19:07 PM
-----------------------------------------------------------------------------

The same script is taking more than 3 minutes and a half.

Here is the C# Code:
-----------------------------------------------------------------------------
static void Main(string[] args)
        {
            ScriptRuntime runtime = Python.CreateRuntime();
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source = engine.CreateScriptSourceFromFile("interpolate.py");
            ScriptScope scope = engine.CreateScope();
            Console.WriteLine(DateTime.Now);
            source.Execute(scope);
            Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt", "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }

I am using IronPython 2.0B5 and Visual Studio 2003 running on .Net3.0 Windows Vista.  The script and the C# code were run on the same machine.

If there is something I am doing wrong?  I really don't understand the performance difference.

regards,

wilfredo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/4fd95946/attachment.html>

From wilfredo.lugo at gmail.com  Wed Nov 12 18:29:10 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Wed, 12 Nov 2008 13:29:10 -0400
Subject: [IronPython] Performance Issue
Message-ID: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>

I run the script directly from ipy.exe and it basically behaves pretty
similar to python.exe (it always took one second more, but I could live with
that).  Here is the output:

$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
17:36
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
17:41

So, the problem is on the DLR side.  Any clues?

-------------------------------------------------------------------------
How does python.exe compare directly to ipy.exe? That is, try running "date
+%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting
APIs.

Thanks,

Dave
From: users-bounces at lists.ironpython.com
<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
[mailto:users-bounces at lists.ironpython.com
<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On
Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 8:32 AM
To: users at lists.ironpython.com
<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
Subject: [IronPython] Performance Issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/2009e5da/attachment.html>

From dinov at microsoft.com  Wed Nov 12 19:01:18 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 10:01:18 -0800
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>

Instead of doing:

            ScriptScope scope = engine.CreateScope();
            Console.WriteLine(DateTime.Now);
            source.Execute(scope);

do:

                source.Compile().Execute()

and your code should then run in an optimized default scope for the code - just like it does at the command line.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 9:29 AM
To: users at lists.ironpython.com
Subject: Re: [IronPython] Performance Issue


I run the script directly from ipy.exe and it basically behaves pretty similar to python.exe (it always took one second more, but I could live with that).  Here is the output:

$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
17:36
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
17:41

So, the problem is on the DLR side.  Any clues?

-------------------------------------------------------------------------
How does python.exe compare directly to ipy.exe?  That is, try running "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting APIs.

Thanks,



Dave

From: users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo

Sent: Wednesday, November 12, 2008 8:32 AM

To: users at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>

Subject: [IronPython] Performance Issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/73bc93d0/attachment.html>

From dan.eloff at gmail.com  Wed Nov 12 19:06:08 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Wed, 12 Nov 2008 12:06:08 -0600
Subject: [IronPython] clr.AddReference and derivatives
Message-ID: <4817b6fc0811121006i1fec459es7d4703b67b2b934d@mail.gmail.com>

There's half a dozen add reference methods in the clr module, I'm
guessing they all have their differences, but I'm not really sure why
you would use one over the other. I generally try AddReference first,
if that doesn't work I try it using the strong name, failing that I
fall back to AddReferenceToFile. Could someone please shed some light
on these methods?

I've got a .NET assembly that wroks great with IronPython, but I've
been having difficulty building it for silverlight. Using reflector
I've managed to verify that I'm building it with all the correct
references for silverlight. However, it still won't load. All the add
reference methods fail: IOError: Assembly could not be loaded.
(paraphrasing as this is not a development pc.) I'm guessing that
descriptive error is the fault of the CLR assembly loading code, not
IronPython. If anyone has any idea why this might happen, or something
I could try in pursuit of knowledge of the same, I'd be grateful.

Thanks,
-Dan


From wilfredo.lugo at gmail.com  Wed Nov 12 19:24:53 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Wed, 12 Nov 2008 14:24:53 -0400
Subject: [IronPython] Performance Issue
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>

Thanks.
But then If I don't use my defined scope, how I could fill my function
delegate?

Right now I am using :

Microsoft.Func<string, string, string, string, int, int> func =
scope.GetVariable<Microsoft.Func<string, string, string, string, int,
int>>("interpolate_start");

If I use engine.GetVariables<Func<....>() I still need to pass a ScriptScope
to it.  How do I get the default scope (from ScriptEngine or ScriptSource)
to be able to get the delegate?

regards,

wilfredo

On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  Instead of doing:
>
>
>
>             ScriptScope scope = engine.CreateScope();
>
>             Console.WriteLine(DateTime.Now);
>
>             source.Execute(scope);
>
>
>
> do:
>
>
>
>                 source.Compile().Execute()
>
>
>
> and your code should then run in an optimized default scope for the code ?
> just like it does at the command line.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 9:29 AM
> *To:* users at lists.ironpython.com
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
>
>
> I run the script directly from ipy.exe and it basically behaves pretty
> similar to python.exe (it always took one second more, but I could live with
> that).  Here is the output:
>
>
>
> $ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
>
> 17:36
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 17:41
>
>
>
> So, the problem is on the DLR side.  Any clues?
>
>
>
> -------------------------------------------------------------------------
>
> How does python.exe compare directly to ipy.exe?  That is, try running
> "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR
> hosting APIs.
>
> Thanks,
>
>
>
> Dave
>
> From: users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo
>
> Sent: Wednesday, November 12, 2008 8:32 AM
>
> To: users at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
>
> Subject: [IronPython] Performance Issue
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/ce742173/attachment.html>

From dinov at microsoft.com  Wed Nov 12 19:56:52 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 10:56:52 -0800
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>

CompiledCode exposes the default scope it executes in via the DefaultScope property.  So hold onto the result of source.Compile and after executing the code you can grab the scope and use it to get your variable.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 10:25 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue

Thanks.

But then If I don't use my defined scope, how I could fill my function delegate?

Right now I am using :

Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");

If I use engine.GetVariables<Func<....>() I still need to pass a ScriptScope to it.  How do I get the default scope (from ScriptEngine or ScriptSource) to be able to get the delegate?

regards,

wilfredo
On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

Instead of doing:



            ScriptScope scope = engine.CreateScope();

            Console.WriteLine(DateTime.Now);

            source.Execute(scope);



do:



                source.Compile().Execute()



and your code should then run in an optimized default scope for the code - just like it does at the command line.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 9:29 AM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: Re: [IronPython] Performance Issue





I run the script directly from ipy.exe and it basically behaves pretty similar to python.exe (it always took one second more, but I could live with that).  Here is the output:



$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S

17:36

WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

 data point (Tue Jan 01 00:00:32 2008), current line: 9411

 series: 3D

force==False, exiting..

17:41



So, the problem is on the DLR side.  Any clues?



-------------------------------------------------------------------------

How does python.exe compare directly to ipy.exe?  That is, try running "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting APIs.

Thanks,



Dave

From: users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo

Sent: Wednesday, November 12, 2008 8:32 AM

To: users at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>

Subject: [IronPython] Performance Issue

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/08e492f9/attachment.html>

From dinov at microsoft.com  Wed Nov 12 20:06:11 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 11:06:11 -0800
Subject: [IronPython] clr.AddReference and derivatives
In-Reply-To: <4817b6fc0811121006i1fec459es7d4703b67b2b934d@mail.gmail.com>
References: <4817b6fc0811121006i1fec459es7d4703b67b2b934d@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CC51@NA-EXMSG-C102.redmond.corp.microsoft.com>

AddReference(str) will first try Assembly.Load and then try Assembly.LoadWithPartialName - this should mean that trying w/ the strong name won't do anything because LoadWithPartialName will do that for you.  This is kind of the one-stop shopping for loading assemblies in the GAC or the app base.  If those don't work it will also ultimately search sys.path when the load fails.

AddReference(asm) will just add the assembly that you've already loaded - this is useful if you can load the assembly using some other mechanism (e.g. Assembly.LoadFrom or loading from byte array or whatever)

AddReferenceToFile(str) will search sys.path for the file and load it from there using Assembly.LoadFile.  This is good to not have the normal Assembly.Load/LoadWithPartialName mechanisms get in the way.

AddReferenceToFileAndPath(str) will take a fully qualified path, append it to sys.path, and then do Assembly.LoadFile with the path.  This is just convenience for quickly adding a fully qualified assembly.

There's also Load* variations which return the assembly object which you can dot through without altering what you can import.

Usually when debugging assembly load failures I use fuslogvw - but I don't know that it works for Silverlight.  I've pinged a CLR loader dev to see if there's an equivalent that's publicly available.  Otherwise you might try attaching windbg to iexplore and stopping on all exceptions.  With .symfix pointing to the public MS servers you *might* see enough useful data when the load fails.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Wednesday, November 12, 2008 10:06 AM
To: Discussion of IronPython
Subject: [IronPython] clr.AddReference and derivatives

There's half a dozen add reference methods in the clr module, I'm
guessing they all have their differences, but I'm not really sure why
you would use one over the other. I generally try AddReference first,
if that doesn't work I try it using the strong name, failing that I
fall back to AddReferenceToFile. Could someone please shed some light
on these methods?

I've got a .NET assembly that wroks great with IronPython, but I've
been having difficulty building it for silverlight. Using reflector
I've managed to verify that I'm building it with all the correct
references for silverlight. However, it still won't load. All the add
reference methods fail: IOError: Assembly could not be loaded.
(paraphrasing as this is not a development pc.) I'm guessing that
descriptive error is the fault of the CLR assembly loading code, not
IronPython. If anyone has any idea why this might happen, or something
I could try in pursuit of knowledge of the same, I'd be grateful.

Thanks,
-Dan
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From wilfredo.lugo at gmail.com  Wed Nov 12 20:44:32 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Wed, 12 Nov 2008 15:44:32 -0400
Subject: [IronPython] Performance Issue
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>

Thanks!.
I was able to get the default scope from CompiledCode, but I am still
getting the same performance.  Here is the latest code :
        static void Main(string[] args)
        {
            ScriptRuntime runtime = Python.CreateRuntime();
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source =
engine.CreateScriptSourceFromFile("interpolate.py");
            Console.WriteLine(DateTime.Now);
            CompiledCode compiled = source.Compile();
            compiled.Execute();
            ScriptScope scope = compiled.DefaultScope;
            Microsoft.Func<string, string, string, string, int, int> func =
scope.GetVariable<Microsoft.Func<string, string, string, string, int,
int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
"2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }

This is the latest output :
   11/12/2008 3:13:01 PM
   WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time
of first
    data point (Tue Jan 01 00:00:32 2008), current line: 9411
    series: 3D
    force==False, exiting..
    0
11/12/2008 3:16:41 PM

Is there could be a problem on how I am calling the interpolation function?
 I mean from python.exe I do something like this:

if __name__ == '__main__':
   Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01
00:00:
21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True, stackedCol
= 2
, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()

To be able to call the script from the DLR I have something like this:

def interpolate_start(inFile, outFile, startDate, endDate, intvl):
   Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked
= Tr
ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
   return 0

That's the only difference I found on how the script is called from python
and DLR.

Any comments?

regards,

wilfredo

On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  CompiledCode exposes the default scope it executes in via the
> DefaultScope property.  So hold onto the result of source.Compile and after
> executing the code you can grab the scope and use it to get your variable.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 10:25 AM
> *To:* Discussion of IronPython
>
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks.
>
>
>
> But then If I don't use my defined scope, how I could fill my function
> delegate?
>
>
>
> Right now I am using :
>
>
>
> Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>
>
> If I use engine.GetVariables<Func<....>() I still need to pass a
> ScriptScope to it.  How do I get the default scope (from ScriptEngine or
> ScriptSource) to be able to get the delegate?
>
>
>
> regards,
>
>
>
> wilfredo
>
> On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> Instead of doing:
>
>
>
>             ScriptScope scope = engine.CreateScope();
>
>             Console.WriteLine(DateTime.Now);
>
>             source.Execute(scope);
>
>
>
> do:
>
>
>
>                 source.Compile().Execute()
>
>
>
> and your code should then run in an optimized default scope for the code ?
> just like it does at the command line.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 9:29 AM
> *To:* users at lists.ironpython.com
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
>
>
> I run the script directly from ipy.exe and it basically behaves pretty
> similar to python.exe (it always took one second more, but I could live with
> that).  Here is the output:
>
>
>
> $ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
>
> 17:36
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 17:41
>
>
>
> So, the problem is on the DLR side.  Any clues?
>
>
>
> -------------------------------------------------------------------------
>
> How does python.exe compare directly to ipy.exe?  That is, try running
> "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR
> hosting APIs.
>
> Thanks,
>
>
>
> Dave
>
> From: users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo
>
> Sent: Wednesday, November 12, 2008 8:32 AM
>
> To: users at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
>
> Subject: [IronPython] Performance Issue
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/9b3b987e/attachment.html>

From dinov at microsoft.com  Wed Nov 12 21:01:19 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 12:01:19 -0800
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>

Oh, sorry, I missed a step...  You'll need to call ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions, and then do options.Module |= ModuleOptions.Optimized;  Finally do source.Compile(options) and then it should give you the optimized code.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 11:45 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue

Thanks!.

I was able to get the default scope from CompiledCode, but I am still getting the same performance.  Here is the latest code :
        static void Main(string[] args)
        {
            ScriptRuntime runtime = Python.CreateRuntime();
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source = engine.CreateScriptSourceFromFile("interpolate.py");
            Console.WriteLine(DateTime.Now);
            CompiledCode compiled = source.Compile();
            compiled.Execute();
            ScriptScope scope = compiled.DefaultScope;
            Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt", "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }

This is the latest output :
   11/12/2008 3:13:01 PM
   WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first
    data point (Tue Jan 01 00:00:32 2008), current line: 9411
    series: 3D
    force==False, exiting..
    0
11/12/2008 3:16:41 PM

Is there could be a problem on how I am calling the interpolation function?  I mean from python.exe I do something like this:

if __name__ == '__main__':
   Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01 00:00:
21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True, stackedCol = 2
, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()

To be able to call the script from the DLR I have something like this:

def interpolate_start(inFile, outFile, startDate, endDate, intvl):
   Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked = Tr
ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
   return 0

That's the only difference I found on how the script is called from python and DLR.

Any comments?

regards,

wilfredo

On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

CompiledCode exposes the default scope it executes in via the DefaultScope property.  So hold onto the result of source.Compile and after executing the code you can grab the scope and use it to get your variable.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 10:25 AM
To: Discussion of IronPython

Subject: Re: [IronPython] Performance Issue



Thanks.



But then If I don't use my defined scope, how I could fill my function delegate?



Right now I am using :



Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");



If I use engine.GetVariables<Func<....>() I still need to pass a ScriptScope to it.  How do I get the default scope (from ScriptEngine or ScriptSource) to be able to get the delegate?



regards,



wilfredo

On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

Instead of doing:



            ScriptScope scope = engine.CreateScope();

            Console.WriteLine(DateTime.Now);

            source.Execute(scope);



do:



                source.Compile().Execute()



and your code should then run in an optimized default scope for the code - just like it does at the command line.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 9:29 AM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: Re: [IronPython] Performance Issue





I run the script directly from ipy.exe and it basically behaves pretty similar to python.exe (it always took one second more, but I could live with that).  Here is the output:



$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S

17:36

WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

 data point (Tue Jan 01 00:00:32 2008), current line: 9411

 series: 3D

force==False, exiting..

17:41



So, the problem is on the DLR side.  Any clues?



-------------------------------------------------------------------------

How does python.exe compare directly to ipy.exe?  That is, try running "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting APIs.

Thanks,



Dave

From: users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo

Sent: Wednesday, November 12, 2008 8:32 AM

To: users at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>

Subject: [IronPython] Performance Issue

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/5cd0979a/attachment.html>

From wilfredo.lugo at gmail.com  Wed Nov 12 21:15:49 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Wed, 12 Nov 2008 16:15:49 -0400
Subject: [IronPython] Performance Issue
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>

Thanks.  Performance improved, but still over two minutes.  Here is the
latest code:
        static void Main(string[] args)
        {
            ScriptRuntime runtime = Python.CreateRuntime();
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source =
engine.CreateScriptSourceFromFile("interpolate.py");
            PythonCompilerOptions options = (PythonCompilerOptions)
engine.GetCompilerOptions();
            options.Module |= ModuleOptions.Optimized;
            Console.WriteLine(DateTime.Now);
            CompiledCode compiled = source.Compile(options);
            compiled.Execute();
            ScriptScope scope = compiled.DefaultScope;
            Microsoft.Func<string, string, string, string, int, int> func =
scope.GetVariable<Microsoft.Func<string, string, string, string, int,
int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
"2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }

Output :
11/12/2008 4:10:10 PM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/12/2008 4:12:45 PM



On Wed, Nov 12, 2008 at 4:01 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  Oh, sorry, I missed a step?  You'll need to call
> ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions,
> and then do options.Module |= ModuleOptions.Optimized;  Finally do
> source.Compile(options) and then it should give you the optimized code.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 11:45 AM
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks!.
>
>
>
> I was able to get the default scope from CompiledCode, but I am still
> getting the same performance.  Here is the latest code :
>
>         static void Main(string[] args)
>
>         {
>
>             ScriptRuntime runtime = Python.CreateRuntime();
>
>             ScriptEngine engine = Python.CreateEngine();
>
>             ScriptSource source =
> engine.CreateScriptSourceFromFile("interpolate.py");
>
>             Console.WriteLine(DateTime.Now);
>
>             CompiledCode compiled = source.Compile();
>
>             compiled.Execute();
>
>             ScriptScope scope = compiled.DefaultScope;
>
>             Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>
>             Console.WriteLine(DateTime.Now);
>
>             Console.ReadLine();
>
>         }
>
>
>
> This is the latest output :
>
>    11/12/2008 3:13:01 PM
>
>    WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time
> of first
>
>     data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>     series: 3D
>
>     force==False, exiting..
>
>     0
>
> 11/12/2008 3:16:41 PM
>
>
>
> Is there could be a problem on how I am calling the interpolation function?
>  I mean from python.exe I do something like this:
>
>
>
> if __name__ == '__main__':
>
>    Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01
> 00:00:
>
> 21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True,
> stackedCol = 2
>
> , tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>
>
>
> To be able to call the script from the DLR I have something like this:
>
>
>
> def interpolate_start(inFile, outFile, startDate, endDate, intvl):
>
>    Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked
> = Tr
>
> ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>
>    return 0
>
>
>
> That's the only difference I found on how the script is called from python
> and DLR.
>
>
>
> Any comments?
>
>
>
> regards,
>
>
>
> wilfredo
>
>
>
> On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> CompiledCode exposes the default scope it executes in via the DefaultScope
> property.  So hold onto the result of source.Compile and after executing the
> code you can grab the scope and use it to get your variable.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 10:25 AM
> *To:* Discussion of IronPython
>
>
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks.
>
>
>
> But then If I don't use my defined scope, how I could fill my function
> delegate?
>
>
>
> Right now I am using :
>
>
>
> Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>
>
> If I use engine.GetVariables<Func<....>() I still need to pass a
> ScriptScope to it.  How do I get the default scope (from ScriptEngine or
> ScriptSource) to be able to get the delegate?
>
>
>
> regards,
>
>
>
> wilfredo
>
> On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> Instead of doing:
>
>
>
>             ScriptScope scope = engine.CreateScope();
>
>             Console.WriteLine(DateTime.Now);
>
>             source.Execute(scope);
>
>
>
> do:
>
>
>
>                 source.Compile().Execute()
>
>
>
> and your code should then run in an optimized default scope for the code ?
> just like it does at the command line.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 9:29 AM
> *To:* users at lists.ironpython.com
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
>
>
> I run the script directly from ipy.exe and it basically behaves pretty
> similar to python.exe (it always took one second more, but I could live with
> that).  Here is the output:
>
>
>
> $ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
>
> 17:36
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 17:41
>
>
>
> So, the problem is on the DLR side.  Any clues?
>
>
>
> -------------------------------------------------------------------------
>
> How does python.exe compare directly to ipy.exe?  That is, try running
> "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR
> hosting APIs.
>
> Thanks,
>
>
>
> Dave
>
> From: users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo
>
> Sent: Wednesday, November 12, 2008 8:32 AM
>
> To: users at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
>
> Subject: [IronPython] Performance Issue
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/d4454974/attachment.html>

From dinov at microsoft.com  Wed Nov 12 22:39:28 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 13:39:28 -0800
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CDA7@NA-EXMSG-C102.redmond.corp.microsoft.com>

The only thing that immediately pops out at me as being different is we also set ModuleOptions.ModuleBuiltins in the command line case - but I wouldn't expect it to make such a large difference.  But try setting that option as well and let's see what happens.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 12:16 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue

Thanks.  Performance improved, but still over two minutes.  Here is the latest code:

        static void Main(string[] args)
        {
            ScriptRuntime runtime = Python.CreateRuntime();
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source = engine.CreateScriptSourceFromFile("interpolate.py");
            PythonCompilerOptions options = (PythonCompilerOptions) engine.GetCompilerOptions();
            options.Module |= ModuleOptions.Optimized;
            Console.WriteLine(DateTime.Now);
            CompiledCode compiled = source.Compile(options);
            compiled.Execute();
            ScriptScope scope = compiled.DefaultScope;
            Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt", "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }

Output :
11/12/2008 4:10:10 PM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/12/2008 4:12:45 PM


On Wed, Nov 12, 2008 at 4:01 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

Oh, sorry, I missed a step...  You'll need to call ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions, and then do options.Module |= ModuleOptions.Optimized;  Finally do source.Compile(options) and then it should give you the optimized code.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 11:45 AM

To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue



Thanks!.



I was able to get the default scope from CompiledCode, but I am still getting the same performance.  Here is the latest code :

        static void Main(string[] args)

        {

            ScriptRuntime runtime = Python.CreateRuntime();

            ScriptEngine engine = Python.CreateEngine();

            ScriptSource source = engine.CreateScriptSourceFromFile("interpolate.py");

            Console.WriteLine(DateTime.Now);

            CompiledCode compiled = source.Compile();

            compiled.Execute();

            ScriptScope scope = compiled.DefaultScope;

            Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");

            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt", "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());

            Console.WriteLine(DateTime.Now);

            Console.ReadLine();

        }



This is the latest output :

   11/12/2008 3:13:01 PM

   WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

    data point (Tue Jan 01 00:00:32 2008), current line: 9411

    series: 3D

    force==False, exiting..

    0

11/12/2008 3:16:41 PM



Is there could be a problem on how I am calling the interpolation function?  I mean from python.exe I do something like this:



if __name__ == '__main__':

   Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01 00:00:

21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True, stackedCol = 2

, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()



To be able to call the script from the DLR I have something like this:



def interpolate_start(inFile, outFile, startDate, endDate, intvl):

   Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked = Tr

ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()

   return 0



That's the only difference I found on how the script is called from python and DLR.



Any comments?



regards,



wilfredo



On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

CompiledCode exposes the default scope it executes in via the DefaultScope property.  So hold onto the result of source.Compile and after executing the code you can grab the scope and use it to get your variable.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 10:25 AM
To: Discussion of IronPython

Subject: Re: [IronPython] Performance Issue



Thanks.



But then If I don't use my defined scope, how I could fill my function delegate?



Right now I am using :



Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");



If I use engine.GetVariables<Func<....>() I still need to pass a ScriptScope to it.  How do I get the default scope (from ScriptEngine or ScriptSource) to be able to get the delegate?



regards,



wilfredo

On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

Instead of doing:



            ScriptScope scope = engine.CreateScope();

            Console.WriteLine(DateTime.Now);

            source.Execute(scope);



do:



                source.Compile().Execute()



and your code should then run in an optimized default scope for the code - just like it does at the command line.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 9:29 AM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: Re: [IronPython] Performance Issue





I run the script directly from ipy.exe and it basically behaves pretty similar to python.exe (it always took one second more, but I could live with that).  Here is the output:



$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S

17:36

WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

 data point (Tue Jan 01 00:00:32 2008), current line: 9411

 series: 3D

force==False, exiting..

17:41



So, the problem is on the DLR side.  Any clues?



-------------------------------------------------------------------------

How does python.exe compare directly to ipy.exe?  That is, try running "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting APIs.

Thanks,



Dave

From: users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo

Sent: Wednesday, November 12, 2008 8:32 AM

To: users at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>

Subject: [IronPython] Performance Issue

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/5b202678/attachment.html>

From dan.eloff at gmail.com  Wed Nov 12 22:48:52 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Wed, 12 Nov 2008 15:48:52 -0600
Subject: [IronPython] clr.AddReference and derivatives
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CC51@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4817b6fc0811121006i1fec459es7d4703b67b2b934d@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC51@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0811121348s26e45117ob39e9de3103ccae@mail.gmail.com>

Thanks Dino, that's a great explanation. Now I know where to use each
of the AddReference methods. Thanks also for the debugging tips, I
managed to figure out what the problem was, I specified x86 platform
(thinking silverlight is exclusively 32bit) but you have to leave it
as Any CPU or the assembly will not be loaded.

Many thanks,
-Dan


From dan.eloff at gmail.com  Wed Nov 12 23:12:12 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Wed, 12 Nov 2008 16:12:12 -0600
Subject: [IronPython] Some thoughts on namespaces, extension methods
Message-ID: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>

I was doing some cross WPF/Silverlight work, and invariably I had to
pepper the code with if sys.platform == 'silverlight' use silverlight
api, else use different wpf api for the same task. That approach goes
back to C and beyond, and is unpythonic. Refactoring to create a
common api for dealing with such things works, but mostly just moves
the ugliness into one file.

It occurs to me that in all of these cases I want to access either a
silverlight or wpf api unmodified, and simulate it on the other
platform. The most pythonic way to resolve this would be if namespaces
and CLR classes could be modified. Mutable namespaces and support for
extension methods would allow most of this. I think that in C# there
is no such thing as static extension methods, but it may be possible
that the CLR allows this. Anyway, I do not know how difficult or
practical this is, but it is certainly pythonic.

-Dan

if sys.platform == 'silverlight':
    def read_all_bytes(path):
        ...
    File.ReadAllBytes = read_all_bytes

if sys.platform == 'cli':
    def load_xaml_from_string(s):
        ...
    XamlReader.LoadXaml = load_xaml_from_string


From dinov at microsoft.com  Wed Nov 12 23:19:19 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 14:19:19 -0800
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>

Actually I'd say modifying built-in types is unpythonic - for example you can't do object.xyz = 42.  We could choose to break this rule for types we don't share between Python & .NET, and it probably wouldn't be a lot of work, but I'm hesitant to have the two sets of types treated differently.

I do have a lot of sympathy for being able to modify the namespaces (and maybe static types) though which are more like modules - and that would be Pythonic.  It's interesting that this is the 2nd time in the past week or so that it's come up.  So I'd say feel free to file a feature request for modifying namespaces if you think that alone would be as useful.  But unless there was overwhelming demand for monkey patching .NET types and no disagreement I think that won't happen.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Wednesday, November 12, 2008 2:12 PM
To: Discussion of IronPython
Subject: [IronPython] Some thoughts on namespaces, extension methods

I was doing some cross WPF/Silverlight work, and invariably I had to
pepper the code with if sys.platform == 'silverlight' use silverlight
api, else use different wpf api for the same task. That approach goes
back to C and beyond, and is unpythonic. Refactoring to create a
common api for dealing with such things works, but mostly just moves
the ugliness into one file.

It occurs to me that in all of these cases I want to access either a
silverlight or wpf api unmodified, and simulate it on the other
platform. The most pythonic way to resolve this would be if namespaces
and CLR classes could be modified. Mutable namespaces and support for
extension methods would allow most of this. I think that in C# there
is no such thing as static extension methods, but it may be possible
that the CLR allows this. Anyway, I do not know how difficult or
practical this is, but it is certainly pythonic.

-Dan

if sys.platform == 'silverlight':
    def read_all_bytes(path):
        ...
    File.ReadAllBytes = read_all_bytes

if sys.platform == 'cli':
    def load_xaml_from_string(s):
        ...
    XamlReader.LoadXaml = load_xaml_from_string
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From wilfredo.lugo at gmail.com  Thu Nov 13 00:24:11 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Wed, 12 Nov 2008 19:24:11 -0400
Subject: [IronPython] Performance Issue
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CDA7@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CDA7@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8aac47860811121524q6a337998va5c565b6c7ba49f5@mail.gmail.com>

I set the ModuleBuiltins compiler option but the behavior is the same.  The
only difference from the command line is that I am calling a python function
from the DLR, and on the command line I am just calling the method from
__main__.  Do you think could be an issue?  The other thing is that the
python script relies heavily on I/O, input file is in the range of 18Mb and
the data is stored on another file.  Does the DLR handles I/O differently
than the command line?
regards,

wilfredo

On Wed, Nov 12, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  The only thing that immediately pops out at me as being different is we
> also set ModuleOptions.ModuleBuiltins in the command line case ? but I
> wouldn't expect it to make such a large difference.  But try setting that
> option as well and let's see what happens.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 12:16 PM
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks.  Performance improved, but still over two minutes.  Here is the
> latest code:
>
>
>
>         static void Main(string[] args)
>
>         {
>
>             ScriptRuntime runtime = Python.CreateRuntime();
>
>             ScriptEngine engine = Python.CreateEngine();
>
>             ScriptSource source =
> engine.CreateScriptSourceFromFile("interpolate.py");
>
>             PythonCompilerOptions options = (PythonCompilerOptions)
> engine.GetCompilerOptions();
>
>             options.Module |= ModuleOptions.Optimized;
>
>             Console.WriteLine(DateTime.Now);
>
>             CompiledCode compiled = source.Compile(options);
>
>             compiled.Execute();
>
>             ScriptScope scope = compiled.DefaultScope;
>
>             Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>
>             Console.WriteLine(DateTime.Now);
>
>             Console.ReadLine();
>
>         }
>
>
>
> Output :
>
> 11/12/2008 4:10:10 PM
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 0
>
> 11/12/2008 4:12:45 PM
>
>
>
>
>
> On Wed, Nov 12, 2008 at 4:01 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> Oh, sorry, I missed a step?  You'll need to call
> ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions,
> and then do options.Module |= ModuleOptions.Optimized;  Finally do
> source.Compile(options) and then it should give you the optimized code.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 11:45 AM
>
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks!.
>
>
>
> I was able to get the default scope from CompiledCode, but I am still
> getting the same performance.  Here is the latest code :
>
>         static void Main(string[] args)
>
>         {
>
>             ScriptRuntime runtime = Python.CreateRuntime();
>
>             ScriptEngine engine = Python.CreateEngine();
>
>             ScriptSource source =
> engine.CreateScriptSourceFromFile("interpolate.py");
>
>             Console.WriteLine(DateTime.Now);
>
>             CompiledCode compiled = source.Compile();
>
>             compiled.Execute();
>
>             ScriptScope scope = compiled.DefaultScope;
>
>             Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>
>             Console.WriteLine(DateTime.Now);
>
>             Console.ReadLine();
>
>         }
>
>
>
> This is the latest output :
>
>    11/12/2008 3:13:01 PM
>
>    WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time
> of first
>
>     data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>     series: 3D
>
>     force==False, exiting..
>
>     0
>
> 11/12/2008 3:16:41 PM
>
>
>
> Is there could be a problem on how I am calling the interpolation function?
>  I mean from python.exe I do something like this:
>
>
>
> if __name__ == '__main__':
>
>    Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01
> 00:00:
>
> 21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True,
> stackedCol = 2
>
> , tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>
>
>
> To be able to call the script from the DLR I have something like this:
>
>
>
> def interpolate_start(inFile, outFile, startDate, endDate, intvl):
>
>    Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked
> = Tr
>
> ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>
>    return 0
>
>
>
> That's the only difference I found on how the script is called from python
> and DLR.
>
>
>
> Any comments?
>
>
>
> regards,
>
>
>
> wilfredo
>
>
>
> On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> CompiledCode exposes the default scope it executes in via the DefaultScope
> property.  So hold onto the result of source.Compile and after executing the
> code you can grab the scope and use it to get your variable.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 10:25 AM
> *To:* Discussion of IronPython
>
>
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks.
>
>
>
> But then If I don't use my defined scope, how I could fill my function
> delegate?
>
>
>
> Right now I am using :
>
>
>
> Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>
>
> If I use engine.GetVariables<Func<....>() I still need to pass a
> ScriptScope to it.  How do I get the default scope (from ScriptEngine or
> ScriptSource) to be able to get the delegate?
>
>
>
> regards,
>
>
>
> wilfredo
>
> On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> Instead of doing:
>
>
>
>             ScriptScope scope = engine.CreateScope();
>
>             Console.WriteLine(DateTime.Now);
>
>             source.Execute(scope);
>
>
>
> do:
>
>
>
>                 source.Compile().Execute()
>
>
>
> and your code should then run in an optimized default scope for the code ?
> just like it does at the command line.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 9:29 AM
> *To:* users at lists.ironpython.com
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
>
>
> I run the script directly from ipy.exe and it basically behaves pretty
> similar to python.exe (it always took one second more, but I could live with
> that).  Here is the output:
>
>
>
> $ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
>
> 17:36
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 17:41
>
>
>
> So, the problem is on the DLR side.  Any clues?
>
>
>
> -------------------------------------------------------------------------
>
> How does python.exe compare directly to ipy.exe?  That is, try running
> "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR
> hosting APIs.
>
> Thanks,
>
>
>
> Dave
>
> From: users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo
>
> Sent: Wednesday, November 12, 2008 8:32 AM
>
> To: users at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
>
> Subject: [IronPython] Performance Issue
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/51b68436/attachment.html>

From dan.eloff at gmail.com  Thu Nov 13 00:40:03 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Wed, 12 Nov 2008 17:40:03 -0600
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>

On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Actually I'd say modifying built-in types is unpythonic - for example you can't do object.xyz = 42.  We could choose to break this rule for types we don't share between Python & .NET, and it probably wouldn't be a lot of work, but I'm hesitant to have the two sets of types treated differently.

I'm going to be contrary here and say that modifying built-in types is
not allowed by the current C implementation, but is compatible with
the language and principles that define pythonic. To paraphrase Guido,
there are two main reasons why modifying builtins is disallowed. 1) To
prevent accidental breaking of unrelated code in unexpected ways. 2)
Since builtins are shared between interpreters running in the same
address space, making them mutable would allow code in one interpreter
to affect the other.

The first seems to me an extension of the ancient argument that you
should not be trusted with fire because you might burn yourself. It's
a fud appeal, not an argument. The second is a very real concern.
Would changes to namespaces, static classes, monkey patching types etc
be visible across what should be isolated script engines? It doesn't
have to be that way, but like CPython we might well decide the
perfomance/complexity tradeoff involved in isolating mutable types is
not worth it.

Essentially this is an implementation artifact of CPython, and like
reference counting or the GIL, it is not something that IronPython has
to copy.

I'm interested what people have to say about this.

-Dan


From dinov at microsoft.com  Thu Nov 13 01:27:22 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 16:27:22 -0800
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CEEF@NA-EXMSG-C102.redmond.corp.microsoft.com>

Interesting points...  we do currently share types for built-in types between objects.  But we could still have per-ScriptRuntime extensions for them.  We actually support this today w/ our ExtensionTypeAttribute (which you could use to do this but you'd need to write the extensions in C#).  But doing it for user defined members would be a bit different but certainly not out of the question.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Wednesday, November 12, 2008 3:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Some thoughts on namespaces, extension methods

On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Actually I'd say modifying built-in types is unpythonic - for example you can't do object.xyz = 42.  We could choose to break this rule for types we don't share between Python & .NET, and it probably wouldn't be a lot of work, but I'm hesitant to have the two sets of types treated differently.

I'm going to be contrary here and say that modifying built-in types is
not allowed by the current C implementation, but is compatible with
the language and principles that define pythonic. To paraphrase Guido,
there are two main reasons why modifying builtins is disallowed. 1) To
prevent accidental breaking of unrelated code in unexpected ways. 2)
Since builtins are shared between interpreters running in the same
address space, making them mutable would allow code in one interpreter
to affect the other.

The first seems to me an extension of the ancient argument that you
should not be trusted with fire because you might burn yourself. It's
a fud appeal, not an argument. The second is a very real concern.
Would changes to namespaces, static classes, monkey patching types etc
be visible across what should be isolated script engines? It doesn't
have to be that way, but like CPython we might well decide the
perfomance/complexity tradeoff involved in isolating mutable types is
not worth it.

Essentially this is an implementation artifact of CPython, and like
reference counting or the GIL, it is not something that IronPython has
to copy.

I'm interested what people have to say about this.

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


From vernondcole at gmail.com  Thu Nov 13 03:32:33 2008
From: vernondcole at gmail.com (Vernon Cole)
Date: Wed, 12 Nov 2008 19:32:33 -0700
Subject: [IronPython] Wishlist for next version: from __future__ import
	print_function
Message-ID: <b7eb4a700811121832r5ceabad2hda11cdd467eff631@mail.gmail.com>

Some time back contributors to this forum were invited to suggest which
Python3k and Python 2.6 functions were most important to implement in the
next IronPython.

I downloaded Python 2.6 and Python3.0RC2 today and started hacking at making
adodbapi work in Python 3.  (Now that it works in Iron, py3k seems like the
next logical thing.)  Conversion to Python2.6 is the first baby step.  Roger
Upole has already done some of the work, so I picked up his branch off CVS.

I quickly discovered that the first thing I need for each module is to add:

from __future__ import print_function
from __future__ import unicode_literals

This makes IronPython immediatly error out, of course.

The unicode_literals would be a simple "pass" statement for IronPython,
which already defaults that way.
The convertion of "print" from a statement to a function affects every
Python program down to "Hello, World". IMHO it would be the most important
thing to implement.
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/4bcbfa6e/attachment.html>

From dinov at microsoft.com  Thu Nov 13 04:16:03 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 12 Nov 2008 19:16:03 -0800
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811121524q6a337998va5c565b6c7ba49f5@mail.gmail.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CDA7@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121524q6a337998va5c565b6c7ba49f5@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441CF67@NA-EXMSG-C102.redmond.corp.microsoft.com>

I don't think either of those would cause such a large difference.  I/O should be the same.  Two other differences I've noticed but again I wouldn't expect them to matter.  The first is a lack of [STAThread] attribute on Main.  The 2nd is you don't need the ScriptRuntime runtime = Python.CreateRuntime(); call.  CreateEngine will create a runtime and return you the Python engine associated with it.

I'll try and take a look at the differences between the code we generate for the two scenarios tomorrow to see if I can see anything that is different.  If that doesn't I might need a repro or if you have a profiler that would work well.  Given the huge difference in the runtimes 10-20 random stack traces during the running of the program might be enough to figure it out.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 3:24 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue

I set the ModuleBuiltins compiler option but the behavior is the same.  The only difference from the command line is that I am calling a python function from the DLR, and on the command line I am just calling the method from __main__.  Do you think could be an issue?  The other thing is that the python script relies heavily on I/O, input file is in the range of 18Mb and the data is stored on another file.  Does the DLR handles I/O differently than the command line?

regards,

wilfredo
On Wed, Nov 12, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

The only thing that immediately pops out at me as being different is we also set ModuleOptions.ModuleBuiltins in the command line case - but I wouldn't expect it to make such a large difference.  But try setting that option as well and let's see what happens.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 12:16 PM

To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue



Thanks.  Performance improved, but still over two minutes.  Here is the latest code:



        static void Main(string[] args)

        {

            ScriptRuntime runtime = Python.CreateRuntime();

            ScriptEngine engine = Python.CreateEngine();

            ScriptSource source = engine.CreateScriptSourceFromFile("interpolate.py");

            PythonCompilerOptions options = (PythonCompilerOptions) engine.GetCompilerOptions();

            options.Module |= ModuleOptions.Optimized;

            Console.WriteLine(DateTime.Now);

            CompiledCode compiled = source.Compile(options);

            compiled.Execute();

            ScriptScope scope = compiled.DefaultScope;

            Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");

            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt", "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());

            Console.WriteLine(DateTime.Now);

            Console.ReadLine();

        }



Output :

11/12/2008 4:10:10 PM

WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

 data point (Tue Jan 01 00:00:32 2008), current line: 9411

 series: 3D

force==False, exiting..

0

11/12/2008 4:12:45 PM





On Wed, Nov 12, 2008 at 4:01 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

Oh, sorry, I missed a step...  You'll need to call ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions, and then do options.Module |= ModuleOptions.Optimized;  Finally do source.Compile(options) and then it should give you the optimized code.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 11:45 AM

To: Discussion of IronPython
Subject: Re: [IronPython] Performance Issue



Thanks!.



I was able to get the default scope from CompiledCode, but I am still getting the same performance.  Here is the latest code :

        static void Main(string[] args)

        {

            ScriptRuntime runtime = Python.CreateRuntime();

            ScriptEngine engine = Python.CreateEngine();

            ScriptSource source = engine.CreateScriptSourceFromFile("interpolate.py");

            Console.WriteLine(DateTime.Now);

            CompiledCode compiled = source.Compile();

            compiled.Execute();

            ScriptScope scope = compiled.DefaultScope;

            Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");

            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt", "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());

            Console.WriteLine(DateTime.Now);

            Console.ReadLine();

        }



This is the latest output :

   11/12/2008 3:13:01 PM

   WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

    data point (Tue Jan 01 00:00:32 2008), current line: 9411

    series: 3D

    force==False, exiting..

    0

11/12/2008 3:16:41 PM



Is there could be a problem on how I am calling the interpolation function?  I mean from python.exe I do something like this:



if __name__ == '__main__':

   Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01 00:00:

21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True, stackedCol = 2

, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()



To be able to call the script from the DLR I have something like this:



def interpolate_start(inFile, outFile, startDate, endDate, intvl):

   Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked = Tr

ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()

   return 0



That's the only difference I found on how the script is called from python and DLR.



Any comments?



regards,



wilfredo



On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

CompiledCode exposes the default scope it executes in via the DefaultScope property.  So hold onto the result of source.Compile and after executing the code you can grab the scope and use it to get your variable.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 10:25 AM
To: Discussion of IronPython

Subject: Re: [IronPython] Performance Issue



Thanks.



But then If I don't use my defined scope, how I could fill my function delegate?



Right now I am using :



Microsoft.Func<string, string, string, string, int, int> func = scope.GetVariable<Microsoft.Func<string, string, string, string, int, int>>("interpolate_start");



If I use engine.GetVariables<Func<....>() I still need to pass a ScriptScope to it.  How do I get the default scope (from ScriptEngine or ScriptSource) to be able to get the delegate?



regards,



wilfredo

On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

Instead of doing:



            ScriptScope scope = engine.CreateScope();

            Console.WriteLine(DateTime.Now);

            source.Execute(scope);



do:



                source.Compile().Execute()



and your code should then run in an optimized default scope for the code - just like it does at the command line.



From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 9:29 AM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: Re: [IronPython] Performance Issue





I run the script directly from ipy.exe and it basically behaves pretty similar to python.exe (it always took one second more, but I could live with that).  Here is the output:



$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S

17:36

WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of first

 data point (Tue Jan 01 00:00:32 2008), current line: 9411

 series: 3D

force==False, exiting..

17:41



So, the problem is on the DLR side.  Any clues?



-------------------------------------------------------------------------

How does python.exe compare directly to ipy.exe?  That is, try running "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting APIs.

Thanks,



Dave

From: users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo

Sent: Wednesday, November 12, 2008 8:32 AM

To: users at lists.ironpython.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>

Subject: [IronPython] Performance Issue

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081112/b9550c6d/attachment.html>

From curt at hagenlocher.org  Thu Nov 13 08:30:26 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 13 Nov 2008 08:30:26 +0100
Subject: [IronPython] Wishlist for next version: from __future__ import
	print_function
In-Reply-To: <b7eb4a700811121832r5ceabad2hda11cdd467eff631@mail.gmail.com>
References: <b7eb4a700811121832r5ceabad2hda11cdd467eff631@mail.gmail.com>
Message-ID: <d2155e360811122330o2732093ax2904a5c1495d27a@mail.gmail.com>

These sound good.  Can you file them on CodePlex, please?

On Thu, Nov 13, 2008 at 3:32 AM, Vernon Cole <vernondcole at gmail.com> wrote:

> Some time back contributors to this forum were invited to suggest which
> Python3k and Python 2.6 functions were most important to implement in the
> next IronPython.
>
> I downloaded Python 2.6 and Python3.0RC2 today and started hacking at
> making adodbapi work in Python 3.  (Now that it works in Iron, py3k seems
> like the next logical thing.)  Conversion to Python2.6 is the first baby
> step.  Roger Upole has already done some of the work, so I picked up his
> branch off CVS.
>
> I quickly discovered that the first thing I need for each module is to add:
>
> from __future__ import print_function
> from __future__ import unicode_literals
>
> This makes IronPython immediatly error out, of course.
>
> The unicode_literals would be a simple "pass" statement for IronPython,
> which already defaults that way.
> The convertion of "print" from a statement to a function affects every
> Python program down to "Hello, World". IMHO it would be the most important
> thing to implement.
> --
> Vernon Cole
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/47ad651f/attachment.html>

From curt at hagenlocher.org  Thu Nov 13 08:40:48 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 13 Nov 2008 08:40:48 +0100
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
Message-ID: <d2155e360811122340k338d7a2bu202a3fb59457796@mail.gmail.com>

On Thu, Nov 13, 2008 at 12:40 AM, Dan Eloff <dan.eloff at gmail.com> wrote:
>
> The first seems to me an extension of the ancient argument that you
> should not be trusted with fire because you might burn yourself. It's
> a fud appeal, not an argument.

Ever used Ruby? ;)

Although I was very skeptical at first, I've really grown to
appreciate the way that C# and VB implement extension methods. By
using an explicit opt-in to the ones you want, you avoid the hell of
everyone trying to add their favorite overlapping extensions to
"string".

Of course, you can generally modify non-C-based classes in the Python
standard library, but this seems to be much less interesting to the
average Python dev.  Or at least there's no Pythonic culture of insane
monkey-patching.

If it were someday possible to add methods to the Python string class,
I would hope that such a change would not be introduced without some
kind of scoping mechanism to limit visibility.

--
Curt Hagenlocher
curt at hagenlocher.org


From oren at held.org.il  Thu Nov 13 10:39:14 2008
From: oren at held.org.il (oren at held.org.il)
Date: Thu, 13 Nov 2008 11:39:14 +0200 (IST)
Subject: [IronPython] compiled "builtin" modules (os, sys, etc)
Message-ID: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>

Hi,

This question is regarding IronPythong *compiled* code (I use pyc.py):

It seems that I have to "compile" even the "builtin" modules such as sys,
os, if my script imports them.

1. Aren't they supposed to be included in IronPython.dll? Am I doing
something wrong? :)
2. Do you know of any "make" script that follows all the imported modules
recursively and compiles them as well?

Thanks!

 - Oren



From curt at hagenlocher.org  Thu Nov 13 13:43:39 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 13 Nov 2008 13:43:39 +0100
Subject: [IronPython] compiled "builtin" modules (os, sys, etc)
In-Reply-To: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>
References: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>
Message-ID: <d2155e360811130443m2b0303f5uabfb533549db9216@mail.gmail.com>

"os" is not a builtin module at all -- it's an external .py file that loads
the internal "nt" module.  I don't know why you'd need to include sys, but I
imagine Dino will answer. :)

On Thu, Nov 13, 2008 at 10:39 AM, <oren at held.org.il> wrote:

> Hi,
>
> This question is regarding IronPythong *compiled* code (I use pyc.py):
>
> It seems that I have to "compile" even the "builtin" modules such as sys,
> os, if my script imports them.
>
> 1. Aren't they supposed to be included in IronPython.dll? Am I doing
> something wrong? :)
> 2. Do you know of any "make" script that follows all the imported modules
> recursively and compiles them as well?
>
> Thanks!
>
>  - Oren
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/419f8c0c/attachment.html>

From wilfredo.lugo at gmail.com  Thu Nov 13 14:59:33 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Thu, 13 Nov 2008 09:59:33 -0400
Subject: [IronPython] Performance Issue
In-Reply-To: <350E7D38B6D819428718949920EC2355564441CF67@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CBB1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CDA7@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121524q6a337998va5c565b6c7ba49f5@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CF67@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8aac47860811130559w499fdba3x894e2f2ec0bc32a8@mail.gmail.com>

Interesting thing.
When I run the program on release mode without the profile the performance
issue remains:
11/13/2008 9:50:19 AM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/13/2008 9:53:07 AM

However, when I run the program using the VS profiler, this is what I get:

11/13/2008 9:55:31 AM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
firs
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/13/2008 9:55:35 AM

Inside the profiler, the code is executed as in ipy.exe (near 4 seconds).
 Why the execution using the profiler will run faster than in Release mode?
 Since the profiler execution is normal, I don't think there is not much
information I could provide.

This is the latest code:

        [STAThread]
        static void Main(string[] args)
        {
            ScriptEngine engine = Python.CreateEngine();
            ScriptSource source =
engine.CreateScriptSourceFromFile("interpolate.py");
            PythonCompilerOptions options = (PythonCompilerOptions)
engine.GetCompilerOptions();
            options.Module |= ModuleOptions.Optimized;
            options.Module |= ModuleOptions.ModuleBuiltins;
            Console.WriteLine(DateTime.Now);
            CompiledCode compiled = source.Compile(options);
            compiled.Execute();
            ScriptScope scope = compiled.DefaultScope;
            Microsoft.Func<string, string, string, string, int, int> func =
scope.GetVariable<Microsoft.Func<string, string, string, string, int,
int>>("interpolate_start");
            Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
"2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
            Console.WriteLine(DateTime.Now);
            Console.ReadLine();
        }


On Wed, Nov 12, 2008 at 11:16 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  I don't think either of those would cause such a large difference.  I/O
> should be the same.  Two other differences I've noticed but again I wouldn't
> expect them to matter.  The first is a lack of [STAThread] attribute on
> Main.  The 2nd is you don't need the ScriptRuntime runtime =
> Python.CreateRuntime(); call.  CreateEngine will create a runtime and return
> you the Python engine associated with it.
>
>
>
> I'll try and take a look at the differences between the code we generate
> for the two scenarios tomorrow to see if I can see anything that is
> different.  If that doesn't I might need a repro or if you have a profiler
> that would work well.  Given the huge difference in the runtimes 10-20
> random stack traces during the running of the program might be enough to
> figure it out.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 3:24 PM
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> I set the ModuleBuiltins compiler option but the behavior is the same.  The
> only difference from the command line is that I am calling a python function
> from the DLR, and on the command line I am just calling the method from
> __main__.  Do you think could be an issue?  The other thing is that the
> python script relies heavily on I/O, input file is in the range of 18Mb and
> the data is stored on another file.  Does the DLR handles I/O differently
> than the command line?
>
>
>
> regards,
>
>
>
> wilfredo
>
> On Wed, Nov 12, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> The only thing that immediately pops out at me as being different is we
> also set ModuleOptions.ModuleBuiltins in the command line case ? but I
> wouldn't expect it to make such a large difference.  But try setting that
> option as well and let's see what happens.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 12:16 PM
>
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks.  Performance improved, but still over two minutes.  Here is the
> latest code:
>
>
>
>         static void Main(string[] args)
>
>         {
>
>             ScriptRuntime runtime = Python.CreateRuntime();
>
>             ScriptEngine engine = Python.CreateEngine();
>
>             ScriptSource source =
> engine.CreateScriptSourceFromFile("interpolate.py");
>
>             PythonCompilerOptions options = (PythonCompilerOptions)
> engine.GetCompilerOptions();
>
>             options.Module |= ModuleOptions.Optimized;
>
>             Console.WriteLine(DateTime.Now);
>
>             CompiledCode compiled = source.Compile(options);
>
>             compiled.Execute();
>
>             ScriptScope scope = compiled.DefaultScope;
>
>             Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>
>             Console.WriteLine(DateTime.Now);
>
>             Console.ReadLine();
>
>         }
>
>
>
> Output :
>
> 11/12/2008 4:10:10 PM
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 0
>
> 11/12/2008 4:12:45 PM
>
>
>
>
>
> On Wed, Nov 12, 2008 at 4:01 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> Oh, sorry, I missed a step?  You'll need to call
> ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions,
> and then do options.Module |= ModuleOptions.Optimized;  Finally do
> source.Compile(options) and then it should give you the optimized code.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 11:45 AM
>
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks!.
>
>
>
> I was able to get the default scope from CompiledCode, but I am still
> getting the same performance.  Here is the latest code :
>
>         static void Main(string[] args)
>
>         {
>
>             ScriptRuntime runtime = Python.CreateRuntime();
>
>             ScriptEngine engine = Python.CreateEngine();
>
>             ScriptSource source =
> engine.CreateScriptSourceFromFile("interpolate.py");
>
>             Console.WriteLine(DateTime.Now);
>
>             CompiledCode compiled = source.Compile();
>
>             compiled.Execute();
>
>             ScriptScope scope = compiled.DefaultScope;
>
>             Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>
>             Console.WriteLine(DateTime.Now);
>
>             Console.ReadLine();
>
>         }
>
>
>
> This is the latest output :
>
>    11/12/2008 3:13:01 PM
>
>    WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time
> of first
>
>     data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>     series: 3D
>
>     force==False, exiting..
>
>     0
>
> 11/12/2008 3:16:41 PM
>
>
>
> Is there could be a problem on how I am calling the interpolation function?
>  I mean from python.exe I do something like this:
>
>
>
> if __name__ == '__main__':
>
>    Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01
> 00:00:
>
> 21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True,
> stackedCol = 2
>
> , tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>
>
>
> To be able to call the script from the DLR I have something like this:
>
>
>
> def interpolate_start(inFile, outFile, startDate, endDate, intvl):
>
>    Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5, stacked
> = Tr
>
> ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>
>    return 0
>
>
>
> That's the only difference I found on how the script is called from python
> and DLR.
>
>
>
> Any comments?
>
>
>
> regards,
>
>
>
> wilfredo
>
>
>
> On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> CompiledCode exposes the default scope it executes in via the DefaultScope
> property.  So hold onto the result of source.Compile and after executing the
> code you can grab the scope and use it to get your variable.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 10:25 AM
> *To:* Discussion of IronPython
>
>
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
> Thanks.
>
>
>
> But then If I don't use my defined scope, how I could fill my function
> delegate?
>
>
>
> Right now I am using :
>
>
>
> Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>
>
>
> If I use engine.GetVariables<Func<....>() I still need to pass a
> ScriptScope to it.  How do I get the default scope (from ScriptEngine or
> ScriptSource) to be able to get the delegate?
>
>
>
> regards,
>
>
>
> wilfredo
>
> On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> Instead of doing:
>
>
>
>             ScriptScope scope = engine.CreateScope();
>
>             Console.WriteLine(DateTime.Now);
>
>             source.Execute(scope);
>
>
>
> do:
>
>
>
>                 source.Compile().Execute()
>
>
>
> and your code should then run in an optimized default scope for the code ?
> just like it does at the command line.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
> *Sent:* Wednesday, November 12, 2008 9:29 AM
> *To:* users at lists.ironpython.com
> *Subject:* Re: [IronPython] Performance Issue
>
>
>
>
>
> I run the script directly from ipy.exe and it basically behaves pretty
> similar to python.exe (it always took one second more, but I could live with
> that).  Here is the output:
>
>
>
> $ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
>
> 17:36
>
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>
>  series: 3D
>
> force==False, exiting..
>
> 17:41
>
>
>
> So, the problem is on the DLR side.  Any clues?
>
>
>
> -------------------------------------------------------------------------
>
> How does python.exe compare directly to ipy.exe?  That is, try running
> "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR
> hosting APIs.
>
> Thanks,
>
>
>
> Dave
>
> From: users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo
>
> Sent: Wednesday, November 12, 2008 8:32 AM
>
> To: users at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
>
> Subject: [IronPython] Performance Issue
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/85eeae78/attachment.html>

From wilfredo.lugo at gmail.com  Thu Nov 13 15:12:13 2008
From: wilfredo.lugo at gmail.com (Wilfredo Lugo)
Date: Thu, 13 Nov 2008 10:12:13 -0400
Subject: [IronPython] Performance Issue
In-Reply-To: <8aac47860811130559w499fdba3x894e2f2ec0bc32a8@mail.gmail.com>
References: <8aac47860811120929w3405d94ch21a6d110212028e8@mail.gmail.com>
	<8aac47860811121024y5c0117foc5af86ec0eb8276e@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CC34@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121144q4bc59dfbn975ad673cb8e7953@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CCC3@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121215x1826da1k895b3fbe5a55ad7a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CDA7@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811121524q6a337998va5c565b6c7ba49f5@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CF67@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8aac47860811130559w499fdba3x894e2f2ec0bc32a8@mail.gmail.com>
Message-ID: <8aac47860811130612s2c03801fg6b1650e88175a69c@mail.gmail.com>

Definitely is something on VS.  If I run the created application from
command line (inside the release folder) here is the output:
11/13/2008 10:08:26 AM
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
first
 data point (Tue Jan 01 00:00:32 2008), current line: 9411
 series: 3D
force==False, exiting..
0
11/13/2008 10:08:31 AM

Since the issue is not with IronPython itself, I will look for answers on
other places.  Thanks for all your help.

regards,

Wilfredo

On Thu, Nov 13, 2008 at 9:59 AM, Wilfredo Lugo <wilfredo.lugo at gmail.com>wrote:

> Interesting thing.
> When I run the program on release mode without the profile the performance
> issue remains:
> 11/13/2008 9:50:19 AM
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> first
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>  series: 3D
> force==False, exiting..
> 0
> 11/13/2008 9:53:07 AM
>
> However, when I run the program using the VS profiler, this is what I get:
>
> 11/13/2008 9:55:31 AM
> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
> firs
>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>  series: 3D
> force==False, exiting..
> 0
> 11/13/2008 9:55:35 AM
>
> Inside the profiler, the code is executed as in ipy.exe (near 4 seconds).
>  Why the execution using the profiler will run faster than in Release mode?
>  Since the profiler execution is normal, I don't think there is not much
> information I could provide.
>
> This is the latest code:
>
>         [STAThread]
>         static void Main(string[] args)
>         {
>             ScriptEngine engine = Python.CreateEngine();
>             ScriptSource source =
> engine.CreateScriptSourceFromFile("interpolate.py");
>             PythonCompilerOptions options = (PythonCompilerOptions)
> engine.GetCompilerOptions();
>             options.Module |= ModuleOptions.Optimized;
>             options.Module |= ModuleOptions.ModuleBuiltins;
>             Console.WriteLine(DateTime.Now);
>             CompiledCode compiled = source.Compile(options);
>             compiled.Execute();
>             ScriptScope scope = compiled.DefaultScope;
>             Microsoft.Func<string, string, string, string, int, int> func =
> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
> int>>("interpolate_start");
>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>             Console.WriteLine(DateTime.Now);
>             Console.ReadLine();
>         }
>
>
> On Wed, Nov 12, 2008 at 11:16 PM, Dino Viehland <dinov at microsoft.com>wrote:
>
>>  I don't think either of those would cause such a large difference.  I/O
>> should be the same.  Two other differences I've noticed but again I wouldn't
>> expect them to matter.  The first is a lack of [STAThread] attribute on
>> Main.  The 2nd is you don't need the ScriptRuntime runtime =
>> Python.CreateRuntime(); call.  CreateEngine will create a runtime and return
>> you the Python engine associated with it.
>>
>>
>>
>> I'll try and take a look at the differences between the code we generate
>> for the two scenarios tomorrow to see if I can see anything that is
>> different.  If that doesn't I might need a repro or if you have a profiler
>> that would work well.  Given the huge difference in the runtimes 10-20
>> random stack traces during the running of the program might be enough to
>> figure it out.
>>
>>
>>
>> *From:* users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
>> *Sent:* Wednesday, November 12, 2008 3:24 PM
>>
>> *To:* Discussion of IronPython
>> *Subject:* Re: [IronPython] Performance Issue
>>
>>
>>
>> I set the ModuleBuiltins compiler option but the behavior is the same.
>>  The only difference from the command line is that I am calling a python
>> function from the DLR, and on the command line I am just calling the method
>> from __main__.  Do you think could be an issue?  The other thing is that the
>> python script relies heavily on I/O, input file is in the range of 18Mb and
>> the data is stored on another file.  Does the DLR handles I/O differently
>> than the command line?
>>
>>
>>
>> regards,
>>
>>
>>
>> wilfredo
>>
>> On Wed, Nov 12, 2008 at 5:39 PM, Dino Viehland <dinov at microsoft.com>
>> wrote:
>>
>> The only thing that immediately pops out at me as being different is we
>> also set ModuleOptions.ModuleBuiltins in the command line case ? but I
>> wouldn't expect it to make such a large difference.  But try setting that
>> option as well and let's see what happens.
>>
>>
>>
>> *From:* users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
>> *Sent:* Wednesday, November 12, 2008 12:16 PM
>>
>>
>> *To:* Discussion of IronPython
>> *Subject:* Re: [IronPython] Performance Issue
>>
>>
>>
>> Thanks.  Performance improved, but still over two minutes.  Here is the
>> latest code:
>>
>>
>>
>>         static void Main(string[] args)
>>
>>         {
>>
>>             ScriptRuntime runtime = Python.CreateRuntime();
>>
>>             ScriptEngine engine = Python.CreateEngine();
>>
>>             ScriptSource source =
>> engine.CreateScriptSourceFromFile("interpolate.py");
>>
>>             PythonCompilerOptions options = (PythonCompilerOptions)
>> engine.GetCompilerOptions();
>>
>>             options.Module |= ModuleOptions.Optimized;
>>
>>             Console.WriteLine(DateTime.Now);
>>
>>             CompiledCode compiled = source.Compile(options);
>>
>>             compiled.Execute();
>>
>>             ScriptScope scope = compiled.DefaultScope;
>>
>>             Microsoft.Func<string, string, string, string, int, int> func
>> = scope.GetVariable<Microsoft.Func<string, string, string, string, int,
>> int>>("interpolate_start");
>>
>>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
>> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>>
>>             Console.WriteLine(DateTime.Now);
>>
>>             Console.ReadLine();
>>
>>         }
>>
>>
>>
>> Output :
>>
>> 11/12/2008 4:10:10 PM
>>
>> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
>> first
>>
>>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>>
>>  series: 3D
>>
>> force==False, exiting..
>>
>> 0
>>
>> 11/12/2008 4:12:45 PM
>>
>>
>>
>>
>>
>> On Wed, Nov 12, 2008 at 4:01 PM, Dino Viehland <dinov at microsoft.com>
>> wrote:
>>
>> Oh, sorry, I missed a step?  You'll need to call
>> ScriptEngine.GetCompilerOptions().  Cast that to a PythonCompilerOptions,
>> and then do options.Module |= ModuleOptions.Optimized;  Finally do
>> source.Compile(options) and then it should give you the optimized code.
>>
>>
>>
>> *From:* users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
>> *Sent:* Wednesday, November 12, 2008 11:45 AM
>>
>>
>> *To:* Discussion of IronPython
>> *Subject:* Re: [IronPython] Performance Issue
>>
>>
>>
>> Thanks!.
>>
>>
>>
>> I was able to get the default scope from CompiledCode, but I am still
>> getting the same performance.  Here is the latest code :
>>
>>         static void Main(string[] args)
>>
>>         {
>>
>>             ScriptRuntime runtime = Python.CreateRuntime();
>>
>>             ScriptEngine engine = Python.CreateEngine();
>>
>>             ScriptSource source =
>> engine.CreateScriptSourceFromFile("interpolate.py");
>>
>>             Console.WriteLine(DateTime.Now);
>>
>>             CompiledCode compiled = source.Compile();
>>
>>             compiled.Execute();
>>
>>             ScriptScope scope = compiled.DefaultScope;
>>
>>             Microsoft.Func<string, string, string, string, int, int> func
>> = scope.GetVariable<Microsoft.Func<string, string, string, string, int,
>> int>>("interpolate_start");
>>
>>             Console.WriteLine(func("3-day-data.txt", "3-day-output.txt",
>> "2008-01-01 00:00:21","2008-01-03 23:59:08",60).ToString());
>>
>>             Console.WriteLine(DateTime.Now);
>>
>>             Console.ReadLine();
>>
>>         }
>>
>>
>>
>> This is the latest output :
>>
>>    11/12/2008 3:13:01 PM
>>
>>    WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time
>> of first
>>
>>     data point (Tue Jan 01 00:00:32 2008), current line: 9411
>>
>>     series: 3D
>>
>>     force==False, exiting..
>>
>>     0
>>
>> 11/12/2008 3:16:41 PM
>>
>>
>>
>> Is there could be a problem on how I am calling the interpolation
>> function?  I mean from python.exe I do something like this:
>>
>>
>>
>> if __name__ == '__main__':
>>
>>    Interpolate('3-day-data.txt', '3-day-output-original.txt', '2008-01-01
>> 00:00:
>>
>> 21', '2008-01-03 23:59:08', intvl=60, maxgap = 5, stacked = True,
>> stackedCol = 2
>>
>> , tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>>
>>
>>
>> To be able to call the script from the DLR I have something like this:
>>
>>
>>
>> def interpolate_start(inFile, outFile, startDate, endDate, intvl):
>>
>>    Interpolate(inFile, outFile,startDate,endDate,intvl, maxgap = 5,
>> stacked = Tr
>>
>> ue, stackedCol = 2, tformat = '%Y-%m-%d %H:%M:%S', debug = False).start()
>>
>>    return 0
>>
>>
>>
>> That's the only difference I found on how the script is called from python
>> and DLR.
>>
>>
>>
>> Any comments?
>>
>>
>>
>> regards,
>>
>>
>>
>> wilfredo
>>
>>
>>
>> On Wed, Nov 12, 2008 at 2:56 PM, Dino Viehland <dinov at microsoft.com>
>> wrote:
>>
>> CompiledCode exposes the default scope it executes in via the DefaultScope
>> property.  So hold onto the result of source.Compile and after executing the
>> code you can grab the scope and use it to get your variable.
>>
>>
>>
>> *From:* users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
>> *Sent:* Wednesday, November 12, 2008 10:25 AM
>> *To:* Discussion of IronPython
>>
>>
>> *Subject:* Re: [IronPython] Performance Issue
>>
>>
>>
>> Thanks.
>>
>>
>>
>> But then If I don't use my defined scope, how I could fill my function
>> delegate?
>>
>>
>>
>> Right now I am using :
>>
>>
>>
>> Microsoft.Func<string, string, string, string, int, int> func =
>> scope.GetVariable<Microsoft.Func<string, string, string, string, int,
>> int>>("interpolate_start");
>>
>>
>>
>> If I use engine.GetVariables<Func<....>() I still need to pass a
>> ScriptScope to it.  How do I get the default scope (from ScriptEngine or
>> ScriptSource) to be able to get the delegate?
>>
>>
>>
>> regards,
>>
>>
>>
>> wilfredo
>>
>> On Wed, Nov 12, 2008 at 2:01 PM, Dino Viehland <dinov at microsoft.com>
>> wrote:
>>
>> Instead of doing:
>>
>>
>>
>>             ScriptScope scope = engine.CreateScope();
>>
>>             Console.WriteLine(DateTime.Now);
>>
>>             source.Execute(scope);
>>
>>
>>
>> do:
>>
>>
>>
>>                 source.Compile().Execute()
>>
>>
>>
>> and your code should then run in an optimized default scope for the code ?
>> just like it does at the command line.
>>
>>
>>
>> *From:* users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] *On Behalf Of *Wilfredo Lugo
>> *Sent:* Wednesday, November 12, 2008 9:29 AM
>> *To:* users at lists.ironpython.com
>> *Subject:* Re: [IronPython] Performance Issue
>>
>>
>>
>>
>>
>> I run the script directly from ipy.exe and it basically behaves pretty
>> similar to python.exe (it always took one second more, but I could live with
>> that).  Here is the output:
>>
>>
>>
>> $ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
>>
>> 17:36
>>
>> WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior to time of
>> first
>>
>>  data point (Tue Jan 01 00:00:32 2008), current line: 9411
>>
>>  series: 3D
>>
>> force==False, exiting..
>>
>> 17:41
>>
>>
>>
>> So, the problem is on the DLR side.  Any clues?
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> How does python.exe compare directly to ipy.exe?  That is, try running
>> "date +%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR
>> hosting APIs.
>>
>> Thanks,
>>
>>
>>
>> Dave
>>
>> From: users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> [mailto:users-bounces at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>] On Behalf Of Wilfredo Lugo
>>
>> Sent: Wednesday, November 12, 2008 8:32 AM
>>
>> To: users at lists.ironpython.com <http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>
>>
>> Subject: [IronPython] Performance Issue
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/08f814f0/attachment.html>

From vernondcole at gmail.com  Thu Nov 13 15:13:13 2008
From: vernondcole at gmail.com (Vernon Cole)
Date: Thu, 13 Nov 2008 07:13:13 -0700
Subject: [IronPython] Wishlist for next version: from __future__ import
	print_function
In-Reply-To: <d2155e360811122330o2732093ax2904a5c1495d27a@mail.gmail.com>
References: <b7eb4a700811121832r5ceabad2hda11cdd467eff631@mail.gmail.com>
	<d2155e360811122330o2732093ax2904a5c1495d27a@mail.gmail.com>
Message-ID: <b7eb4a700811130613w6094f2adnd2a4db29aa17d6de@mail.gmail.com>

Done.
Everyone go vote:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19521
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19522
--
Vernon

On Thu, Nov 13, 2008 at 12:30 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> These sound good.  Can you file them on CodePlex, please?
>
> On Thu, Nov 13, 2008 at 3:32 AM, Vernon Cole <vernondcole at gmail.com>wrote:
>
>> Some time back contributors to this forum were invited to suggest which
>> Python3k and Python 2.6 functions were most important to implement in the
>> next IronPython.
>>
>> I downloaded Python 2.6 and Python3.0RC2 today and started hacking at
>> making adodbapi work in Python 3.  (Now that it works in Iron, py3k seems
>> like the next logical thing.)  Conversion to Python2.6 is the first baby
>> step.  Roger Upole has already done some of the work, so I picked up his
>> branch off CVS.
>>
>> I quickly discovered that the first thing I need for each module is to
>> add:
>>
>> from __future__ import print_function
>> from __future__ import unicode_literals
>>
>> This makes IronPython immediatly error out, of course.
>>
>> The unicode_literals would be a simple "pass" statement for IronPython,
>> which already defaults that way.
>> The convertion of "print" from a statement to a function affects every
>> Python program down to "Hello, World". IMHO it would be the most important
>> thing to implement.
>> --
>> Vernon Cole
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/165071bb/attachment.html>

From seob at gmx.ch  Thu Nov 13 17:05:17 2008
From: seob at gmx.ch (Severin)
Date: Thu, 13 Nov 2008 17:05:17 +0100
Subject: [IronPython] compiled "builtin" modules (os, sys, etc)
In-Reply-To: <d2155e360811130443m2b0303f5uabfb533549db9216@mail.gmail.com>
References: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>
	<d2155e360811130443m2b0303f5uabfb533549db9216@mail.gmail.com>
Message-ID: <a3ea99f80811130805k3de4d181n340953dbf577cd6c@mail.gmail.com>

I have similar problems. I import 'treading' for example and running the
application I get a 'no module named threading' exception.

On Thu, Nov 13, 2008 at 1:43 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> "os" is not a builtin module at all -- it's an external .py file that loads
> the internal "nt" module.  I don't know why you'd need to include sys, but I
> imagine Dino will answer. :)
>
>
> On Thu, Nov 13, 2008 at 10:39 AM, <oren at held.org.il> wrote:
>
>> Hi,
>>
>> This question is regarding IronPythong *compiled* code (I use pyc.py):
>>
>> It seems that I have to "compile" even the "builtin" modules such as sys,
>> os, if my script imports them.
>>
>> 1. Aren't they supposed to be included in IronPython.dll? Am I doing
>> something wrong? :)
>> 2. Do you know of any "make" script that follows all the imported modules
>> recursively and compiles them as well?
>>
>> Thanks!
>>
>>  - Oren
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/6587806e/attachment.html>

From seob at gmx.ch  Thu Nov 13 17:08:47 2008
From: seob at gmx.ch (Severin)
Date: Thu, 13 Nov 2008 17:08:47 +0100
Subject: [IronPython] profiling ironpython application
Message-ID: <a3ea99f80811130808w11acdf13nf19d4df1dda436c5@mail.gmail.com>

Hello,

how do I profile a ironpython application? profile in a similar way as
'cProfile' with CPython.

my idea was to compile the application and then run it using a .net
profiler.

is that the way to go? has anyone some experience with this? or any
suggestion for a good profiler.

thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/b8405983/attachment.html>

From curt at hagenlocher.org  Thu Nov 13 17:18:15 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 13 Nov 2008 17:18:15 +0100
Subject: [IronPython] compiled "builtin" modules (os, sys, etc)
In-Reply-To: <a3ea99f80811130805k3de4d181n340953dbf577cd6c@mail.gmail.com>
References: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>
	<d2155e360811130443m2b0303f5uabfb533549db9216@mail.gmail.com>
	<a3ea99f80811130805k3de4d181n340953dbf577cd6c@mail.gmail.com>
Message-ID: <d2155e360811130818o1d0dcb5esdf2473a9202ec3da@mail.gmail.com>

"threading" is also a .py-based library file.  To get these you either need
to get IronPython via the MSI file (for 2.0RC1) or you need to download
CPython and use its libraries.  Information on the latter is in the
IronPython tutorial that's in the "tutorial" directory of the distribution.

If you're not sure whether or not a module is builtin or an external file,
you can check its "__file__" attribute:

>>> threading.__file__
'c:\\Python25\\lib\\threading.py'
>>> import clr
>>> clr.__file__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute '__file__'
>>>

On Thu, Nov 13, 2008 at 5:05 PM, Severin <seob at gmx.ch> wrote:

> I have similar problems. I import 'treading' for example and running the
> application I get a 'no module named threading' exception.
>
>
> On Thu, Nov 13, 2008 at 1:43 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>
>> "os" is not a builtin module at all -- it's an external .py file that
>> loads the internal "nt" module.  I don't know why you'd need to include sys,
>> but I imagine Dino will answer. :)
>>
>>
>> On Thu, Nov 13, 2008 at 10:39 AM, <oren at held.org.il> wrote:
>>
>>> Hi,
>>>
>>> This question is regarding IronPythong *compiled* code (I use pyc.py):
>>>
>>> It seems that I have to "compile" even the "builtin" modules such as sys,
>>> os, if my script imports them.
>>>
>>> 1. Aren't they supposed to be included in IronPython.dll? Am I doing
>>> something wrong? :)
>>> 2. Do you know of any "make" script that follows all the imported modules
>>> recursively and compiles them as well?
>>>
>>> Thanks!
>>>
>>>  - Oren
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/35df1752/attachment.html>

From dinov at microsoft.com  Thu Nov 13 18:08:19 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 13 Nov 2008 09:08:19 -0800
Subject: [IronPython] compiled "builtin" modules (os, sys, etc)
In-Reply-To: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>
References: <f25d14f78d437b32c93a0a17e83ba969.squirrel@held.org.il>
Message-ID: <350E7D38B6D819428718949920EC2355564441D0E9@NA-EXMSG-C102.redmond.corp.microsoft.com>

This is the script I used for compiling the standard library:

import clr
import System


def get_files(dir):
    if 'lib-tk' in dir: return ()
    if '.\\test' in dir: return ()

    res = [file for file in System.IO.Directory.GetFiles(dir, '*.py')]
    dirs = System.IO.Directory.GetDirectories(dir)
    if dirs:
        for dir in dirs:
            res += get_files(dir)
    return res

files = get_files('.')

clr.CompileModules('all.dll', *files)

Note you'll also want to exclude socket.py or rename it in the standard library dir (we're not going to ship socket w/ the final version of IronPython as we have a built-in socket).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of oren at held.org.il
Sent: Thursday, November 13, 2008 1:39 AM
To: users at lists.ironpython.com
Subject: [IronPython] compiled "builtin" modules (os, sys, etc)

Hi,

This question is regarding IronPythong *compiled* code (I use pyc.py):

It seems that I have to "compile" even the "builtin" modules such as sys,
os, if my script imports them.

1. Aren't they supposed to be included in IronPython.dll? Am I doing
something wrong? :)
2. Do you know of any "make" script that follows all the imported modules
recursively and compiles them as well?

Thanks!

 - Oren

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



From dan.eloff at gmail.com  Thu Nov 13 20:26:21 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Thu, 13 Nov 2008 13:26:21 -0600
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <d2155e360811122340k338d7a2bu202a3fb59457796@mail.gmail.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
	<d2155e360811122340k338d7a2bu202a3fb59457796@mail.gmail.com>
Message-ID: <4817b6fc0811131126n38844b5eoaf6b3b25f7f87bd2@mail.gmail.com>

On Thu, Nov 13, 2008 at 1:40 AM, Curt Hagenlocher <curt at hagenlocher.org> wrote:
> On Thu, Nov 13, 2008 at 12:40 AM, Dan Eloff <dan.eloff at gmail.com> wrote:
>>
>> The first seems to me an extension of the ancient argument that you
>> should not be trusted with fire because you might burn yourself. It's
>> a fud appeal, not an argument.
>
> Ever used Ruby? ;)

To extend my metaphor, there are, however, good reasons to not be
trusted with napalm.

>
> Although I was very skeptical at first, I've really grown to
> appreciate the way that C# and VB implement extension methods. By
> using an explicit opt-in to the ones you want, you avoid the hell of
> everyone trying to add their favorite overlapping extensions to
> "string".

That is true. Imagine importing a third party package in Python to
discover it added a dozen new methods to str. Yech.

> Of course, you can generally modify non-C-based classes in the Python
> standard library, but this seems to be much less interesting to the
> average Python dev.  Or at least there's no Pythonic culture of insane
> monkey-patching.

No, because in general it's a bad idea. It is, however, commonly used
in testing situations, and sometimes, after careful thought, by
packages that build on stdlib functionality. Used right, such
functionality is harmless, and it makes some tasks easier. Used wrong,
such functionality is downright evil.

Namespaces and static classes are really like modules, and should be
mutable to be in keeping with Python. But as for monkey patching
types, I don't know that the use cases justify it. If somebody is
having a problem with your library, it's nice to not even have to
consider that it's because he changed list.append to add items to the
front of the list (or worse yet some other idiot did that in another
library that he uses)

Still there may be a way to tackle this from the .NET side rather than
the Python side of things. There is some value to be able to define
extension methods C# style from IronPython, and if implemented in a
similar fashion, it should be harmless.

-Dan


From dinov at microsoft.com  Thu Nov 13 21:22:35 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 13 Nov 2008 12:22:35 -0800
Subject: [IronPython] Vote for 2.6 features (was Wishlist for next
	version...)
In-Reply-To: <b7eb4a700811130613w6094f2adnd2a4db29aa17d6de@mail.gmail.com>
References: <b7eb4a700811121832r5ceabad2hda11cdd467eff631@mail.gmail.com>
	<d2155e360811122330o2732093ax2904a5c1495d27a@mail.gmail.com>
	<b7eb4a700811130613w6094f2adnd2a4db29aa17d6de@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441D29D@NA-EXMSG-C102.redmond.corp.microsoft.com>

Thanks for opening those initial bugs Vernon!  I've gone ahead and created the full list of 2.6 feature based upon the 2.6 what's new document.  If anyone sees anything I missed feel free to open the bug and/or respond to this thread.  And please vote on your favorite issues.

19522: 2.6: from __future__ import print_function (PEP 3105)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19522

19521: 2.6: from __future__ import unicode_literals (PEP 3112)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19521

19534: 2.6: with statement available by default
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19534

19535: 2.6: exception handling, "except TypeError as ex" (PEP 3110)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19535

19536: 2.6: Class decorators (PEP 3129)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19536

19537: 2.6: hasattr shouldn't catch all errors, shouldn't catch KeyboardInterrupt / SystemExit
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19537

19538: 2.6: make it legal to provide keyword arguments after a *args argument to a function call.
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19538

19539: 2.6: add getter, setter, deleter to properties
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19539

19540: 2.6: Abstract Base Classes (collections renamed _collections, __subclasscheck__, __instancecheck__) (PEP 3119)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19540

19541: 2.6: add __package__ attribute to modules
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19541

19542: 2.6: implement _multiprocessing
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19542

19543: 2.6: Advanced string formatting (PEP 3101)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19543

19544: 2.6: Byte literals, bytearray (PEP 3112)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19544

19545: 2.6: New io module (implement _fileio module) (PEP 3116)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19545

19546: 2.6: Integer literal support & syntax (support for 0b or 0B binary numbers) (PEP 3127)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19546

19547: 2.6: **kw splatting should support any mapping object
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19547

19548: 2.6: new built-in next(iterator, [default]) returns next item from an iterator
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19548

19551: 2.6: add index, count methods to tuple
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19551

19550: 2.6: improve slicing support for built-in types
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19550

19549: 2.6: update set methods to accept multiple iterables: intersection(), intersection_update(), union(), update(), difference() and difference_update()
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19549

19552: 2.6: floating point features (http://bugs.python.org/issue1635)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19552

19553: 2.6: math module updated for NaN support (http://bugs.python.org/issue1640)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19553

19554: 2.6: floating point to hex support (http://bugs.python.org/issue3008)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19554

19557: 2.6: __hash__ = None support to hide parents hash
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19557

19555: 2.6: deprecate message on Exception objects in favor of args according to PEP 352
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19555

19556: 2.6: GeneratorExit should be a subclass of BaseException
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19556

19558: 2.6: Add gi_code to generator objects pointing to their code object
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19558

19559: 2.6: compile should support keyword arguments
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19559

19560: 2.6: complex(repr(cplx)) should round trip values
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19560

19561: 2.6: str.translate can accept None and do identity translation
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19561

19562: 2.6: __self__ and __func__ on method in addition to im_self and im_func
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19562

19563: 2.6: locals() in class no longer returns free variables
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19563

19564: 2.6: Implement new warnings module (no longer written in Python)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19564

19565: 2.6: implement members of struct that used to be written in Python
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19565

19566: 2.6: Support IRONPYTHONIOENCODING environment variable
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19566

19567: 2.6: Support new functions in cmath (polar, rect, phase, isnan, isinf)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19567

19568: 2.6: support maxlen on deque object
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19568

19569: 2.6: datetime.strftime supports %f format code for microseconds zero padded left to six places
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19569

19571: 2.6: reduce is available in functools
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19571

19572: 2.6: Implement itertools izip_longest, product, combinations, permutations, chain.from_iterable
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19572

19570: 2.6: implement operator.methodcaller
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19570

19574: 2.6: operator.attrgetter accepts dotted names
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19574

19573: 2.6: implement nt.closerange
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19573

19575: 2.6: nt.environ.clear should use unsetenv in addition to clearing the keys
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19575

19576: 2.6: support pickling of random objects
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19576

19577: 2.6: struct support for C99 _Bool type
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19577

19578: 2.6: add sys.float_info, sys.flags, getsizeof, getprofile, gettrace
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19578

19579: 2.6: warnings.formatwarning / showwarning get line optional arg, add warnings.catch_warnings
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19579

19580: 2.6: add future_builtins module
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19580

19581: 2.6: implement _json module (encode_basestring_ascii, scanstring)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19581

19582: 2.6: add ioctl to socket objects
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19582

19583: 2.6: add _winreg.ExpandEnvironmentStrings, DisableReflectionKey(), EnableReflectionKey(), and QueryReflectionKey()
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19583

19584: 2.6: collections.deque.__init__ clears existing contents
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19584

19585: 2.6: object.__init__ should not accept arbitrary arguments (http://bugs.python.org/issue1683368)
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19585

19586: 2.6: __import__ shouldn't allow filenames
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19586

19587: 2.6: socket.error should inherit from IOError
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19587

19588: 2.6: Exception class should warn when accessed using slicing or indexing
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19588

19589: 2.6: warn when comparing objects which don't implement comparisons
    http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19589



From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Thursday, November 13, 2008 6:13 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Wishlist for next version: from __future__ import print_function

Done.
Everyone go vote:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19521
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19522
--
Vernon
On Thu, Nov 13, 2008 at 12:30 AM, Curt Hagenlocher <curt at hagenlocher.org<mailto:curt at hagenlocher.org>> wrote:
These sound good.  Can you file them on CodePlex, please?
On Thu, Nov 13, 2008 at 3:32 AM, Vernon Cole <vernondcole at gmail.com<mailto:vernondcole at gmail.com>> wrote:
Some time back contributors to this forum were invited to suggest which Python3k and Python 2.6 functions were most important to implement in the next IronPython.

I downloaded Python 2.6 and Python3.0RC2 today and started hacking at making adodbapi work in Python 3.  (Now that it works in Iron, py3k seems like the next logical thing.)  Conversion to Python2.6 is the first baby step.  Roger Upole has already done some of the work, so I picked up his branch off CVS.

I quickly discovered that the first thing I need for each module is to add:

from __future__ import print_function
from __future__ import unicode_literals

This makes IronPython immediatly error out, of course.

The unicode_literals would be a simple "pass" statement for IronPython, which already defaults that way.
The convertion of "print" from a statement to a function affects every Python program down to "Hello, World". IMHO it would be the most important thing to implement.
--
Vernon Cole

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081113/3c92e217/attachment.html>

From oripel at gmail.com  Thu Nov 13 22:47:47 2008
From: oripel at gmail.com (orip)
Date: Thu, 13 Nov 2008 13:47:47 -0800 (PST)
Subject: [IronPython] profiling ironpython application
In-Reply-To: <a3ea99f80811130808w11acdf13nf19d4df1dda436c5@mail.gmail.com>
References: <a3ea99f80811130808w11acdf13nf19d4df1dda436c5@mail.gmail.com>
Message-ID: <41ce7856-2868-4bcc-b894-1085d940f4c9@c2g2000pra.googlegroups.com>

I'm interested in this as well - the last time a colleague tried this
I think the .NET profiler didn't help.

On Nov 13, 6:08?pm, Severin <s... at gmx.ch> wrote:
> Hello,
>
> how do I profile a ironpython application? profile in a similar way as
> 'cProfile' with CPython.
>
> my idea was to compile the application and then run it using a .net
> profiler.
>
> is that the way to go? has anyone some experience with this? or any
> suggestion for a good profiler.
>
> thanks
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dan.eloff at gmail.com  Fri Nov 14 18:18:01 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Fri, 14 Nov 2008 11:18:01 -0600
Subject: [IronPython] Interlocked methods and IronPython
Message-ID: <4817b6fc0811140918x5f3272d2qb2669c53ba5d203f@mail.gmail.com>

I've often wondered if the CLR Interlocked methods work with
IronPython. It seems that Interlocked.Increment works fine with module
globals (see attached script.) Whether it works fine in general I
don't know. Does anybody know anything about this?

-Dan

>ipy interlockedinc.py
UnsafeCount: -32081
SafeCount: 0

>ipy interlockedinc.py
UnsafeCount: -27749
SafeCount: 0

>ipy interlockedinc.py
UnsafeCount: -37339
SafeCount: 0

>ipy interlockedinc.py
UnsafeCount: -39461
SafeCount: 0

>ipy interlockedinc.py
UnsafeCount: 23175
SafeCount: 0
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: interlockedinc.py
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081114/292c23c2/attachment.ksh>

From dan.eloff at gmail.com  Fri Nov 14 18:34:39 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Fri, 14 Nov 2008 11:34:39 -0600
Subject: [IronPython] Interlocked methods and IronPython
In-Reply-To: <4817b6fc0811140918x5f3272d2qb2669c53ba5d203f@mail.gmail.com>
References: <4817b6fc0811140918x5f3272d2qb2669c53ba5d203f@mail.gmail.com>
Message-ID: <4817b6fc0811140934w4ca610a0r7571abe9890ba551@mail.gmail.com>

... sometimes. The reason it seems to work is that python integers are
immutable and the safe count is always zero :) You could assign back
to SafeCount the result of the increment, but the assignment isn't
necessarily safe. I guess these kinds of things either need to be
written in C#, or use a Monitor or Lock as always in Python.

-Dan

On Fri, Nov 14, 2008 at 11:18 AM, Dan Eloff <dan.eloff at gmail.com> wrote:
> I've often wondered if the CLR Interlocked methods work with
> IronPython. It seems that Interlocked.Increment works fine with module
> globals (see attached script.) Whether it works fine in general I
> don't know. Does anybody know anything about this?
>
> -Dan
>
>>ipy interlockedinc.py
> UnsafeCount: -32081
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: -27749
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: -37339
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: -39461
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: 23175
> SafeCount: 0
>


From Marty.Nelson at symyx.com  Fri Nov 14 18:37:32 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Fri, 14 Nov 2008 09:37:32 -0800
Subject: [IronPython] Looking for Iron Python presenter/trainer
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03B982A6@srv-be-101.Symyx-IC.symyx.com>


Now that we have integrated Iron Python as a major extension point for
our products, I'm looking to up the IP IQ of our developers, QA,
support, and services people.

 

Most people are coming from C# background.  I'd like to bring someone in
for a day or so session that would cover:

1.	Introduce basic Python syntax, concepts and best practices.
2.	Cover issues around creating and access .NET objects in Python.
3.	Cover any other .NET/IP integration points that would be
relevant to our situation.

 

We have 3-4 different sites around the US/Europe were I was looking to
run this session.

 

I would also be interested in someone who could review our current
implementation and offer feedback and suggestions.

 

- Marty Nelson

Symyx Technologies Inc.



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081114/1aed1c6b/attachment.html>

From dinov at microsoft.com  Fri Nov 14 18:39:49 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 14 Nov 2008 09:39:49 -0800
Subject: [IronPython] Interlocked methods and IronPython
In-Reply-To: <4817b6fc0811140934w4ca610a0r7571abe9890ba551@mail.gmail.com>
References: <4817b6fc0811140918x5f3272d2qb2669c53ba5d203f@mail.gmail.com>
	<4817b6fc0811140934w4ca610a0r7571abe9890ba551@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564441D60C@NA-EXMSG-C102.redmond.corp.microsoft.com>

You could store the value in a clr.StrongBox[int] and pass that instead and it should work.  The way you're calling increment now it's always passing in the value and returning a tuple of prevValue, newValue.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Friday, November 14, 2008 9:35 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Interlocked methods and IronPython

... sometimes. The reason it seems to work is that python integers are
immutable and the safe count is always zero :) You could assign back
to SafeCount the result of the increment, but the assignment isn't
necessarily safe. I guess these kinds of things either need to be
written in C#, or use a Monitor or Lock as always in Python.

-Dan

On Fri, Nov 14, 2008 at 11:18 AM, Dan Eloff <dan.eloff at gmail.com> wrote:
> I've often wondered if the CLR Interlocked methods work with
> IronPython. It seems that Interlocked.Increment works fine with module
> globals (see attached script.) Whether it works fine in general I
> don't know. Does anybody know anything about this?
>
> -Dan
>
>>ipy interlockedinc.py
> UnsafeCount: -32081
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: -27749
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: -37339
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: -39461
> SafeCount: 0
>
>>ipy interlockedinc.py
> UnsafeCount: 23175
> SafeCount: 0
>
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From slide.o.mix at gmail.com  Fri Nov 14 18:50:30 2008
From: slide.o.mix at gmail.com (Slide)
Date: Fri, 14 Nov 2008 10:50:30 -0700
Subject: [IronPython] ASP.NET futures
Message-ID: <a623f7d10811140950n2cabeb92i13526d31f3b56da1@mail.gmail.com>

Can anyone tell me what version of IP is included in the July 2007
ASP.NET Futures? I'd like to pull the Managed JScript into my app as
well to provide either IP or MJS scripting support (and in the future
IronRuby) and would like to know if pulling the assemblies from the
ASP.NET Futures would provide me with a good version of IP.

Thanks

-- 
slide-o-blog
http://slide-o-blog.blogspot.com/


From vernondcole at gmail.com  Fri Nov 14 20:32:11 2008
From: vernondcole at gmail.com (Vernon Cole)
Date: Fri, 14 Nov 2008 12:32:11 -0700
Subject: [IronPython] Please use IPy, not IP.
Message-ID: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>

I am having trouble reading "subject" lines recently...
IP is Internet Protocol as in TCP/IP.
To keep simple folks like me from being confused, *IPy *would be a better
acronym.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081114/617c2e3f/attachment.html>

From empirebuilder at gmail.com  Sat Nov 15 09:13:05 2008
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Sat, 15 Nov 2008 10:13:05 +0200
Subject: [IronPython] ASP.NET futures
In-Reply-To: <a623f7d10811140950n2cabeb92i13526d31f3b56da1@mail.gmail.com>
References: <a623f7d10811140950n2cabeb92i13526d31f3b56da1@mail.gmail.com>
Message-ID: <8cd017b80811150013i49460105k9b9c82fa7f4eb5e9@mail.gmail.com>

The July 2007 is an early IronPython 2 assembly (Alpha one or two) - It
requires Microsoft.Scripting.Vestigial and some other temporary assemblies.
I'd say wait for the next drop of ASP.Net for Iron Python for an up to date
IronPython 2 support. There was an update two months ago with IronPython
Beta 4, but that version didn't support .Net 3.5 assemblies scenario.

Dody G.

On Fri, Nov 14, 2008 at 7:50 PM, Slide <slide.o.mix at gmail.com> wrote:

> Can anyone tell me what version of IP is included in the July 2007
> ASP.NET Futures? I'd like to pull the Managed JScript into my app as
> well to provide either IP or MJS scripting support (and in the future
> IronRuby) and would like to know if pulling the assemblies from the
> ASP.NET Futures would provide me with a good version of IP.
>
> Thanks
>
> --
> slide-o-blog
> http://slide-o-blog.blogspot.com/
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
nomadlife.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081115/bbfa1f04/attachment.html>

From kamil at dworakowski.name  Sat Nov 15 11:36:56 2008
From: kamil at dworakowski.name (Kamil Dworakowski)
Date: Sat, 15 Nov 2008 10:36:56 +0000
Subject: [IronPython] profiling ironpython application
In-Reply-To: <a3ea99f80811130808w11acdf13nf19d4df1dda436c5@mail.gmail.com>
References: <a3ea99f80811130808w11acdf13nf19d4df1dda436c5@mail.gmail.com>
Message-ID: <93fc29d60811150236y221595evd683d1e0e56205ad@mail.gmail.com>

I once tried redgate's profiler, they have a trial version. Along with
your methods it would also display the times for all the methods in
IronPython itself (can be filtered out for the most part if I remember
correctly). Anyway, I prefer pritlining.

On Thu, Nov 13, 2008 at 4:08 PM, Severin <seob at gmx.ch> wrote:
> Hello,
>
> how do I profile a ironpython application? profile in a similar way as
> 'cProfile' with CPython.
>
> my idea was to compile the application and then run it using a .net
> profiler.
>
> is that the way to go? has anyone some experience with this? or any
> suggestion for a good profiler.
>
> thanks
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


From fuzzyman at voidspace.org.uk  Sat Nov 15 18:17:14 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 15 Nov 2008 17:17:14 +0000
Subject: [IronPython] Feature Request: Zipimport builtin module
Message-ID: <6f4025010811150917i3c6fae9ek863a9e1adcc805b8@mail.gmail.com>

Hello guys,

In order to use projects like Turbogears with IronPython (I'm at a
Turbogears sprint) we need setuptools to work. In order for setuptools to
work we need zipimport - which is a builtin module in Python.

The Jython guys have setuptools working... (only the Genshi package is
blocking Turbogears from working on Jython.)

Having setuptools working on IronPython is becoming increasingly important
as it becomes the standard distribution and installation mechanism for
Python packages.

I'm looking at a pure Python version of zipimport (provided by Guido for use
on the AppEngine). It doesn't work unmodified but should be easy enough to
get working as a stopgap measure. I've added a comment to codeplex issue
391:

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=391

Michael Foord

-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081115/2d051b00/attachment.html>

From jdhardy at gmail.com  Sun Nov 16 00:11:40 2008
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sat, 15 Nov 2008 16:11:40 -0700
Subject: [IronPython] Feature Request: Zipimport builtin module
In-Reply-To: <6f4025010811150917i3c6fae9ek863a9e1adcc805b8@mail.gmail.com>
References: <6f4025010811150917i3c6fae9ek863a9e1adcc805b8@mail.gmail.com>
Message-ID: <ea89d0e50811151511h44e4493dk9555d778fc62592@mail.gmail.com>

I believe there also needs to be a complete implementation of zlib as
well, but that might just be for easy_install (which is still pretty
important). The zlib from FePy is missing decompressobj, which is
nasty to get working with a DeflateStream.

-Jeff

On Sat, Nov 15, 2008 at 10:17 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Hello guys,
>
> In order to use projects like Turbogears with IronPython (I'm at a
> Turbogears sprint) we need setuptools to work. In order for setuptools to
> work we need zipimport - which is a builtin module in Python.
>
> The Jython guys have setuptools working... (only the Genshi package is
> blocking Turbogears from working on Jython.)
>
> Having setuptools working on IronPython is becoming increasingly important
> as it becomes the standard distribution and installation mechanism for
> Python packages.
>
> I'm looking at a pure Python version of zipimport (provided by Guido for use
> on the AppEngine). It doesn't work unmodified but should be easy enough to
> get working as a stopgap measure. I've added a comment to codeplex issue
> 391:
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=391
>
> Michael Foord
>
> --
> http://www.ironpythoninaction.com/
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


From seob at gmx.ch  Sun Nov 16 08:47:36 2008
From: seob at gmx.ch (Severin)
Date: Sun, 16 Nov 2008 08:47:36 +0100
Subject: [IronPython] profiling ironpython application
In-Reply-To: <93fc29d60811150236y221595evd683d1e0e56205ad@mail.gmail.com>
References: <a3ea99f80811130808w11acdf13nf19d4df1dda436c5@mail.gmail.com>
	<93fc29d60811150236y221595evd683d1e0e56205ad@mail.gmail.com>
Message-ID: <a3ea99f80811152347v529f325ck3f94023ed94b8f22@mail.gmail.com>

Thanks for the answer.
How would you display the times for ALL the methods?

On Sat, Nov 15, 2008 at 11:36 AM, Kamil Dworakowski
<kamil at dworakowski.name>wrote:

> I once tried redgate's profiler, they have a trial version. Along with
> your methods it would also display the times for all the methods in
> IronPython itself (can be filtered out for the most part if I remember
> correctly). Anyway, I prefer pritlining.
>
> On Thu, Nov 13, 2008 at 4:08 PM, Severin <seob at gmx.ch> wrote:
> > Hello,
> >
> > how do I profile a ironpython application? profile in a similar way as
> > 'cProfile' with CPython.
> >
> > my idea was to compile the application and then run it using a .net
> > profiler.
> >
> > is that the way to go? has anyone some experience with this? or any
> > suggestion for a good profiler.
> >
> > thanks
> >
> >
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081116/51ea8d13/attachment.html>

From fuzzyman at voidspace.org.uk  Sun Nov 16 16:59:08 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 16 Nov 2008 15:59:08 +0000
Subject: [IronPython] Feature Request: Zipimport builtin module
In-Reply-To: <ea89d0e50811151511h44e4493dk9555d778fc62592@mail.gmail.com>
References: <6f4025010811150917i3c6fae9ek863a9e1adcc805b8@mail.gmail.com>
	<ea89d0e50811151511h44e4493dk9555d778fc62592@mail.gmail.com>
Message-ID: <4920434C.8030402@voidspace.org.uk>

Jeff Hardy wrote:
> I believe there also needs to be a complete implementation of zlib as
> well, but that might just be for easy_install (which is still pretty
> important). The zlib from FePy is missing decompressobj, which is
> nasty to get working with a DeflateStream.
>   

Yep. I have a 'mostly complete' implementation of zipimport in pure 
Python (would need some work as the caching is not compatible with 
setuptools but should be easy to fix). This depends on zipfile, which as 
you say uses zlib.decompressobj.

It should be possible to replace the use of zipfile with direct use of 
the .NET APIs. Both zlib and zipimport should really be available for 
IronPython though... :-)

Michael

> -Jeff
>
> On Sat, Nov 15, 2008 at 10:17 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>> Hello guys,
>>
>> In order to use projects like Turbogears with IronPython (I'm at a
>> Turbogears sprint) we need setuptools to work. In order for setuptools to
>> work we need zipimport - which is a builtin module in Python.
>>
>> The Jython guys have setuptools working... (only the Genshi package is
>> blocking Turbogears from working on Jython.)
>>
>> Having setuptools working on IronPython is becoming increasingly important
>> as it becomes the standard distribution and installation mechanism for
>> Python packages.
>>
>> I'm looking at a pure Python version of zipimport (provided by Guido for use
>> on the AppEngine). It doesn't work unmodified but should be easy enough to
>> get working as a stopgap measure. I've added a comment to codeplex issue
>> 391:
>>
>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=391
>>
>> Michael Foord
>>
>> --
>> http://www.ironpythoninaction.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
>   


-- 
http://www.ironpythoninaction.com/



From fuzzyman at voidspace.org.uk  Sun Nov 16 18:39:30 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 16 Nov 2008 17:39:30 +0000
Subject: [IronPython] getframe and __file__
Message-ID: <49205AD2.70408@voidspace.org.uk>

Hello guys,

Around 90% of the uses for sys._getframe that I've seen are to find out 
the calling module, by accessing __file__ in the calling frame globals. 
I just wondered if it would be any cheaper to just track this 
information and fake out the frame objects so that this use case is met?

The answer is probably no as it basically requires tracking the same 
information (and I guess that the performance hit comes mainly from the 
thread locals and frame tracking rather than from building the Python 
stack frame objects) - but on the off-chance that it might be cheaper 
(obviously only the tracking needs to be implemented - everything else 
can be built on demand) I thought I would throw it out there.

Michael

-- 
http://www.ironpythoninaction.com/



From oripel at gmail.com  Mon Nov 17 08:53:02 2008
From: oripel at gmail.com (orip)
Date: Sun, 16 Nov 2008 23:53:02 -0800 (PST)
Subject: [IronPython] getframe and __file__
In-Reply-To: <49205AD2.70408@voidspace.org.uk>
References: <49205AD2.70408@voidspace.org.uk>
Message-ID: <4dc0e24b-33cf-4316-8fef-7acabd7b58e5@a26g2000prf.googlegroups.com>

That certainly fits my use case.
It would be cool to check for an "IronPython Extensions" module and
use it if available.

On Nov 16, 7:39?pm, Michael Foord <fuzzy... at voidspace.org.uk> wrote:
> Hello guys,
>
> Around 90% of the uses for sys._getframe that I've seen are to find out
> the calling module, by accessing __file__ in the calling frame globals.
> I just wondered if it would be any cheaper to just track this
> information and fake out the frame objects so that this use case is met?
>
> The answer is probably no as it basically requires tracking the same
> information (and I guess that the performance hit comes mainly from the
> thread locals and frame tracking rather than from building the Python
> stack frame objects) - but on the off-chance that it might be cheaper
> (obviously only the tracking needs to be implemented - everything else
> can be built on demand) I thought I would throw it out there.
>
> Michael
>
> --http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From chenrong2003 at gmail.com  Mon Nov 17 17:38:18 2008
From: chenrong2003 at gmail.com (=?ISO-2022-JP?B?TmVpbCgbJEJMWkxuOFEbKEIp?=)
Date: Tue, 18 Nov 2008 00:38:18 +0800
Subject: [IronPython] Please use IPy, not IP.
In-Reply-To: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
References: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
Message-ID: <26756bf60811170838y7eac296at5ec7235e5f3d8168@mail.gmail.com>

That's actually a good suggestion, Agree.

On Sat, Nov 15, 2008 at 3:32 AM, Vernon Cole <vernondcole at gmail.com> wrote:
> I am having trouble reading "subject" lines recently...
> IP is Internet Protocol as in TCP/IP.
> To keep simple folks like me from being confused, IPy would be a better
> acronym.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


From graham.bloice at trihedral.com  Mon Nov 17 17:44:53 2008
From: graham.bloice at trihedral.com (Graham Bloice)
Date: Mon, 17 Nov 2008 16:44:53 +0000
Subject: [IronPython] Please use IPy, not IP.
In-Reply-To: <26756bf60811170838y7eac296at5ec7235e5f3d8168@mail.gmail.com>
References: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
	<26756bf60811170838y7eac296at5ec7235e5f3d8168@mail.gmail.com>
Message-ID: <49219F85.3040405@trihedral.com>

Neil(???) wrote:
> That's actually a good suggestion, Agree.
>
> On Sat, Nov 15, 2008 at 3:32 AM, Vernon Cole <vernondcole at gmail.com> wrote:
>   
>> I am having trouble reading "subject" lines recently...
>> IP is Internet Protocol as in TCP/IP.
>> To keep simple folks like me from being confused, IPy would be a better
>> acronym.
>>     
Unfortunately "IPy" seems to be in use for exactly the reason Vernon
stated.  See http://software.inl.fr/trac/wiki/IPy

-- 
Regards,

Graham Bloice

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081117/39108a8b/attachment.html>

From dinov at microsoft.com  Mon Nov 17 18:40:16 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 17 Nov 2008 09:40:16 -0800
Subject: [IronPython] getframe and __file__
In-Reply-To: <4dc0e24b-33cf-4316-8fef-7acabd7b58e5@a26g2000prf.googlegroups.com>
References: <49205AD2.70408@voidspace.org.uk>
	<4dc0e24b-33cf-4316-8fef-7acabd7b58e5@a26g2000prf.googlegroups.com>
Message-ID: <350E7D38B6D819428718949920EC235556448135AB@NA-EXMSG-C102.redmond.corp.microsoft.com>

This is definitely possible but it'd be a hack and would have some odd corner cases.  In terms of Python the problem here is we could find out the func_code (MethodInfo's in .NET speak) but not the actual function object.  We could maintain a mapping which would let us get back to function objects but there'd be some cases where we'd pick the wrong one.  It'd also be really slow because .NET stack traces are slow.  If we maintain this at runtime it won't be much different than my existing frame prototype.

As for IronPython extensions module...  If you mean on startup if there was a way you could add your own built-in modules you can.  Just drop any DLL into a directory called DLLs below ipy.exe and we'll do a clr.AddReference to all of those DLLs.  If any of those DLLs have one or more PythonModuleAttribute's defined we'll add those to the list of built-in modules.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of orip
Sent: Sunday, November 16, 2008 11:53 PM
To: users at lists.ironpython.com
Subject: Re: [IronPython] getframe and __file__

That certainly fits my use case.
It would be cool to check for an "IronPython Extensions" module and
use it if available.

On Nov 16, 7:39 pm, Michael Foord <fuzzy... at voidspace.org.uk> wrote:
> Hello guys,
>
> Around 90% of the uses for sys._getframe that I've seen are to find out
> the calling module, by accessing __file__ in the calling frame globals.
> I just wondered if it would be any cheaper to just track this
> information and fake out the frame objects so that this use case is met?
>
> The answer is probably no as it basically requires tracking the same
> information (and I guess that the performance hit comes mainly from the
> thread locals and frame tracking rather than from building the Python
> stack frame objects) - but on the off-chance that it might be cheaper
> (obviously only the tracking needs to be implemented - everything else
> can be built on demand) I thought I would throw it out there.
>
> Michael
>
> --http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://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


From kfarmer at thuban.org  Tue Nov 18 10:27:12 2008
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 18 Nov 2008 01:27:12 -0800
Subject: [IronPython] Please use IPy, not IP.
In-Reply-To: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
References: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
Message-ID: <EEDCD954DD4A0D488BBDBDDCC260754466FB34@meta-exchange.circle-cross.home>

Respectfully: it would be less trouble overall if you made the effort to
adapt to the group's jargon, rather than expect everyone else to adapt
to your (temporary) state of confusion.

 

After all, I've never met a "simple" programmer.  I'm sure you're
capable of learning the language J

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Friday, November 14, 2008 11:32 AM
To: Discussion of IronPython
Subject: [IronPython] Please use IPy, not IP.

 

I am having trouble reading "subject" lines recently...
IP is Internet Protocol as in TCP/IP.
To keep simple folks like me from being confused, IPy would be a better
acronym.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081118/8f656eb0/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov 18 11:28:19 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 18 Nov 2008 10:28:19 +0000
Subject: [IronPython] Please use IPy, not IP.
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC260754466FB34@meta-exchange.circle-cross.home>
References: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
	<EEDCD954DD4A0D488BBDBDDCC260754466FB34@meta-exchange.circle-cross.home>
Message-ID: <492298C3.3020002@voidspace.org.uk>

Keith J. Farmer wrote:
>
> Respectfully: it would be less trouble overall if you made the effort 
> to adapt to the group?s jargon, rather than expect everyone else to 
> adapt to your (temporary) state of confusion.
>

+1 (I'm afraid)

 From context it should be reasonably straightforward to tell whether an 
acronym refers to TCP/IP or IronPython. Try finding any TLA that isn't 
overloaded with multiple meanings in the computer world...

Michael

> After all, I?ve never met a ?simple? programmer. I?m sure you?re 
> capable of learning the language J
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Vernon Cole
> *Sent:* Friday, November 14, 2008 11:32 AM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] Please use IPy, not IP.
>
> I am having trouble reading "subject" lines recently...
> IP is Internet Protocol as in TCP/IP.
> To keep simple folks like me from being confused, *IPy *would be a 
> better acronym.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/



From oren at held.org.il  Tue Nov 18 11:29:00 2008
From: oren at held.org.il (Oren Held)
Date: Tue, 18 Nov 2008 12:29:00 +0200 (IST)
Subject: [IronPython] sys.argv is empty after compilation
Message-ID: <c9d970015ec51f06a9e12818dedea14b.squirrel@held.org.il>

Hi,

sys.argv works well under the interpreter, but gets empty after compiling.

I've encountered this message from 2006:
http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2006-February/001712.html

However this interpreter-executable inconsistency still occurs to me with
2.0RC1.


10x

 - Oren



From empirebuilder at gmail.com  Tue Nov 18 11:32:18 2008
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Tue, 18 Nov 2008 12:32:18 +0200
Subject: [IronPython] Please use IPy, not IP.
In-Reply-To: <492298C3.3020002@voidspace.org.uk>
References: <b7eb4a700811141132i3fae21b9hf1f8b03d94450972@mail.gmail.com>
	<EEDCD954DD4A0D488BBDBDDCC260754466FB34@meta-exchange.circle-cross.home>
	<492298C3.3020002@voidspace.org.uk>
Message-ID: <8cd017b80811180232g46afbe22ja1a2e987646c5512@mail.gmail.com>

IronPython is going to be called "Dynamic Language Foundation Whitespace
Sensitive Edition", so we are not going to have this IP acronym confusion.

On Tue, Nov 18, 2008 at 12:28 PM, Michael Foord
<fuzzyman at voidspace.org.uk>wrote:

> Keith J. Farmer wrote:
>
>>
>> Respectfully: it would be less trouble overall if you made the effort to
>> adapt to the group's jargon, rather than expect everyone else to adapt to
>> your (temporary) state of confusion.
>>
>>
> +1 (I'm afraid)
>
> From context it should be reasonably straightforward to tell whether an
> acronym refers to TCP/IP or IronPython. Try finding any TLA that isn't
> overloaded with multiple meanings in the computer world...
>
> Michael
>
>  After all, I've never met a "simple" programmer. I'm sure you're capable
>> of learning the language J
>>
>> *From:* users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] *On Behalf Of *Vernon Cole
>> *Sent:* Friday, November 14, 2008 11:32 AM
>> *To:* Discussion of IronPython
>> *Subject:* [IronPython] Please use IPy, not IP.
>>
>> I am having trouble reading "subject" lines recently...
>> IP is Internet Protocol as in TCP/IP.
>> To keep simple folks like me from being confused, *IPy *would be a better
>> acronym.
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
nomadlife.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081118/087bcd5e/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Nov 18 12:55:14 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 18 Nov 2008 11:55:14 +0000
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
Message-ID: <4922AD22.2010100@voidspace.org.uk>

Dan Eloff wrote:
> On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland <dinov at microsoft.com> wrote:
>   
>> Actually I'd say modifying built-in types is unpythonic - for example you can't do object.xyz = 42.  We could choose to break this rule for types we don't share between Python & .NET, and it probably wouldn't be a lot of work, but I'm hesitant to have the two sets of types treated differently.
>>     
>
> I'm going to be contrary here and say that modifying built-in types is
> not allowed by the current C implementation, but is compatible with
> the language and principles that define pythonic. To paraphrase Guido,
> there are two main reasons why modifying builtins is disallowed. 1) To
> prevent accidental breaking of unrelated code in unexpected ways. 2)
> Since builtins are shared between interpreters running in the same
> address space, making them mutable would allow code in one interpreter
> to affect the other.
>
> The first seems to me an extension of the ancient argument that you
> should not be trusted with fire because you might burn yourself. It's
> a fud appeal, not an argument. 
Hmmm... the topic has been discussed by the Python developers in the 
past, and there is a pretty solid consensus that being able to modify 
the built-in types is 'crazy'. I think you would find that a significant 
proportion of the community would believe that allowing the modification 
of built-in types is not Pythonic and that IronPython was changing 
Python if it allowed this.

Brushing aside Guido's concerns as FUD (even if you disagree - and I'm 
agnostic on this particular topic) is unlikely to be seen as a valid 
argument either... I don't think that this is an implementation detail 
of CPython but a conscious decision (although performance of attribute 
lookup and memory savings for the built-in types as each instance 
doesn't require an instance dictionary are likely to be part of the 
reason for this implementation decision in CPython - but by no means the 
only reason).

Although monkey patching has been beloved in the Ruby community there 
has been interesting push-back in recent months.

Extension methods in C# are an interesting language feature. This is one 
area where static-typing is helpful as you can get early warning of 
incompatible extensions (and with method overloading can even multiple 
extension methods with the same name but different signatures I guess). 
It would still be a *problem* if you wanted to use two libraries that 
both tried to extend types using the same extension method names, but at 
least you would get warned about it rather than simply having runtime 
madness.

Michael

> The second is a very real concern.
> Would changes to namespaces, static classes, monkey patching types etc
> be visible across what should be isolated script engines? It doesn't
> have to be that way, but like CPython we might well decide the
> perfomance/complexity tradeoff involved in isolating mutable types is
> not worth it.
>
> Essentially this is an implementation artifact of CPython, and like
> reference counting or the GIL, it is not something that IronPython has
> to copy.
>
> I'm interested what people have to say about this.
>
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/



From dan.eloff at gmail.com  Tue Nov 18 20:46:40 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Tue, 18 Nov 2008 14:46:40 -0500
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <4922AD22.2010100@voidspace.org.uk>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>
	<4922AD22.2010100@voidspace.org.uk>
Message-ID: <4817b6fc0811181146h4f506ddfxdd6dbd42f472faf8@mail.gmail.com>

On Tue, Nov 18, 2008 at 6:55 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Hmmm... the topic has been discussed by the Python developers in the past,
> and there is a pretty solid consensus that being able to modify the built-in
> types is 'crazy'. I think you would find that a significant proportion of
> the community would believe that allowing the modification of built-in types
> is not Pythonic and that IronPython was changing Python if it allowed this.
>
> Brushing aside Guido's concerns as FUD (even if you disagree - and I'm
> agnostic on this particular topic) is unlikely to be seen as a valid
> argument either...
> I don't think that this is an implementation detail of
> CPython but a conscious decision (although performance of attribute lookup
> and memory savings for the built-in types as each instance doesn't require
> an instance dictionary are likely to be part of the reason for this
> implementation decision in CPython - but by no means the only reason).
>
> Although monkey patching has been beloved in the Ruby community there has
> been interesting push-back in recent months.
>
> Extension methods in C# are an interesting language feature. This is one
> area where static-typing is helpful as you can get early warning of
> incompatible extensions (and with method overloading can even multiple
> extension methods with the same name but different signatures I guess). It
> would still be a *problem* if you wanted to use two libraries that both
> tried to extend types using the same extension method names, but at least
> you would get warned about it rather than simply having runtime madness.
>
> Michael

All good valid points.

It seems to me that there's little harm in allowing ruby style
modifying of builtin types in a given project, provided the code (or
more specifically the modifications) are not visible outside of the
project. If you want to add an index() method to tuple, in your own
codebase, go ahead. On small projects where developers can all
interact with each other, they will work out what should be added to
the builtins and what should stay as seperate methods. It also makes
some test scenarios easier where it's difficult to use mock objects.
I'd argue that here the potential for good outweighs the bad. Nobody
but the developers are exposed to any harmful side effects, and the
developers will act in their own self-interest to ensure the
extensions have a net positive impact. Resolver, or at least the parts
that are isolated from user's code, is a good example of this kind of
project.

Currently I think most of this (excluding testing usage) is possible
if you write the extensions in C#. Perhaps that is the way it should
stay. CPython has often taken the approach that "advanced"
functionality should stay in the C API, and if developers really need
it, then having to write C won't be an unreasonable hurdle.

However, library code should not use these kinds of extensions at all.
It would be a mess if a library's extensions could be visible to other
python code and or libraries. I don't think the typical Python's
gentlemans agreement is enough to prevent this kind of nightmare. This
scenario should not be allowed, period.

Perhaps one way this could be accomplished is to introduce an option
-X:MutableBuiltins to enable this. Libraries, which are not
executable, cannot rely on having that option present, and so cannot
modify builtins. Developers can on an individiual project basis, and
only if it is deemed "a good idea", turn the feature on.

Again, if extending builtins from C# is possible (I haven't tried this
yet), then this would be very low priority. There are so many things
I'd rather see in IronPython.

-Dan









>
>> The second is a very real concern.
>> Would changes to namespaces, static classes, monkey patching types etc
>> be visible across what should be isolated script engines? It doesn't
>> have to be that way, but like CPython we might well decide the
>> perfomance/complexity tradeoff involved in isolating mutable types is
>> not worth it.
>>
>> Essentially this is an implementation artifact of CPython, and like
>> reference counting or the GIL, it is not something that IronPython has
>> to copy.
>>
>> I'm interested what people have to say about this.
>>
>> -Dan
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From fuzzyman at voidspace.org.uk  Tue Nov 18 21:05:29 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 18 Nov 2008 20:05:29 +0000
Subject: [IronPython] Some thoughts on namespaces, extension methods
In-Reply-To: <4817b6fc0811181146h4f506ddfxdd6dbd42f472faf8@mail.gmail.com>
References: <4817b6fc0811121412m3d8f68a7j407e18afe2b745ae@mail.gmail.com>	<350E7D38B6D819428718949920EC2355564441CE1D@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4817b6fc0811121540g1814b2a8q6ec5ffe4af2c9a21@mail.gmail.com>	<4922AD22.2010100@voidspace.org.uk>
	<4817b6fc0811181146h4f506ddfxdd6dbd42f472faf8@mail.gmail.com>
Message-ID: <49232009.3050507@voidspace.org.uk>

Dan Eloff wrote:
> On Tue, Nov 18, 2008 at 6:55 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>> Hmmm... the topic has been discussed by the Python developers in the past,
>> and there is a pretty solid consensus that being able to modify the built-in
>> types is 'crazy'. I think you would find that a significant proportion of
>> the community would believe that allowing the modification of built-in types
>> is not Pythonic and that IronPython was changing Python if it allowed this.
>>
>> Brushing aside Guido's concerns as FUD (even if you disagree - and I'm
>> agnostic on this particular topic) is unlikely to be seen as a valid
>> argument either...
>> I don't think that this is an implementation detail of
>> CPython but a conscious decision (although performance of attribute lookup
>> and memory savings for the built-in types as each instance doesn't require
>> an instance dictionary are likely to be part of the reason for this
>> implementation decision in CPython - but by no means the only reason).
>>
>> Although monkey patching has been beloved in the Ruby community there has
>> been interesting push-back in recent months.
>>
>> Extension methods in C# are an interesting language feature. This is one
>> area where static-typing is helpful as you can get early warning of
>> incompatible extensions (and with method overloading can even multiple
>> extension methods with the same name but different signatures I guess). It
>> would still be a *problem* if you wanted to use two libraries that both
>> tried to extend types using the same extension method names, but at least
>> you would get warned about it rather than simply having runtime madness.
>>
>> Michael
>>     
>
> All good valid points.
>
> It seems to me that there's little harm in allowing ruby style
> modifying of builtin types in a given project, provided the code (or
> more specifically the modifications) are not visible outside of the
> project. If you want to add an index() method to tuple, in your own
> codebase, go ahead. On small projects where developers can all
> interact with each other, they will work out what should be added to
> the builtins and what should stay as seperate methods. It also makes
> some test scenarios easier where it's difficult to use mock objects.
> I'd argue that here the potential for good outweighs the bad. Nobody
> but the developers are exposed to any harmful side effects, and the
> developers will act in their own self-interest to ensure the
> extensions have a net positive impact. Resolver, or at least the parts
> that are isolated from user's code, is a good example of this kind of
> project.
>
> Currently I think most of this (excluding testing usage) is possible
> if you write the extensions in C#. Perhaps that is the way it should
> stay. CPython has often taken the approach that "advanced"
> functionality should stay in the C API, and if developers really need
> it, then having to write C won't be an unreasonable hurdle.
>
> However, library code should not use these kinds of extensions at all.
> It would be a mess if a library's extensions could be visible to other
> python code and or libraries. I don't think the typical Python's
> gentlemans agreement is enough to prevent this kind of nightmare. This
> scenario should not be allowed, period.
>
> Perhaps one way this could be accomplished is to introduce an option
> -X:MutableBuiltins to enable this. Libraries, which are not
> executable, cannot rely on having that option present, and so cannot
> modify builtins. Developers can on an individiual project basis, and
> only if it is deemed "a good idea", turn the feature on.
>   
Hmmm... specifying in a project that extension methods from this library 
I use are ok but from the other library aren't sounds like a recipe for 
complexity.

> Again, if extending builtins from C# is possible (I haven't tried this
> yet), then this would be very low priority. There are so many things
> I'd rather see in IronPython.
>
>   
Agreed, I'd much rather see zipimport and zlib support for example.

Michael
> -Dan
>
>
>
>
>
>
>
>
>
>   
>>> The second is a very real concern.
>>> Would changes to namespaces, static classes, monkey patching types etc
>>> be visible across what should be isolated script engines? It doesn't
>>> have to be that way, but like CPython we might well decide the
>>> perfomance/complexity tradeoff involved in isolating mutable types is
>>> not worth it.
>>>
>>> Essentially this is an implementation artifact of CPython, and like
>>> reference counting or the GIL, it is not something that IronPython has
>>> to copy.
>>>
>>> I'm interested what people have to say about this.
>>>
>>> -Dan
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>       
>> --
>> http://www.ironpythoninaction.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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From timr at probo.com  Tue Nov 18 21:53:29 2008
From: timr at probo.com (Tim Roberts)
Date: Tue, 18 Nov 2008 12:53:29 -0800
Subject: [IronPython] Please use IPy, not IP.
In-Reply-To: <mailman.18302.1227037602.20699.users-ironpython.com@lists.ironpython.com>
References: <mailman.18302.1227037602.20699.users-ironpython.com@lists.ironpython.com>
Message-ID: <49232B49.3000703@probo.com>

On Tue, 18 Nov 2008 12:32:18 +0200, "Dody Gunawinata"
<empirebuilder at gmail.com> joked:
> IronPython is going to be called "Dynamic Language Foundation Whitespace
> Sensitive Edition", so we are not going to have this IP acronym confusion.
>   

I just about busted a gut at this.  It is made even more funny by the
fact that it's not completely impossible.

You did, however, forget "Live" and ".NET", and probably "Studio".

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.



From Jimmy.Schementi at microsoft.com  Wed Nov 19 00:35:34 2008
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 18 Nov 2008 15:35:34 -0800
Subject: [IronPython] Python Standard Library in IronPython
In-Reply-To: <4817b6fc0810311406y363a20a3u689dc900993eb286@mail.gmail.com>
References: <CABCA1FA-22EA-47F8-B82B-84E07358263D@gmail.com>
	<9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com>
	<5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com>
	<EEDD8E95-3C1E-4051-BABE-6DA9E8D7FB75@gmail.com>
	<4909FAE7.4000309@voidspace.org.uk>
	<5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com>
	<490A1DAA.3010200@voidspace.org.uk>
	<97764E78-94CA-429C-BE01-3006D2244573@gmail.com>
	<4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com>
	<17CF84DE-2B94-4711-878C-B1D0E2C6CDDA@gmail.com>
	<4817b6fc0810311406y363a20a3u689dc900993eb286@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABBD8@NA-EXMSG-C116.redmond.corp.microsoft.com>

Getting on this thread late ...

I've been working on a way to load Python/Ruby libraries from either a external XAP file or Isolated Storage. I should have something checked into github.com/jschementi/agdlr shortly.

Kenneth: wrappers around the Python stdlib out definitely be interesting, though possibly very difficult to produce the exact behaviors of the python libraries. .NET APIs don't map exactly to Python's, or Ruby's, so there will always be special-casing, and those can be the hardest to detect. I'd much rather find a good way to load external libraries once and only once. But, I'm not going to be the guy to stop you. =)

~js

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dan Eloff
> Sent: Friday, October 31, 2008 2:06 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Python Standard Library in IronPython
>
> On Fri, Oct 31, 2008 at 3:05 PM, Kenneth Miller <xkenneth at gmail.com>
> wrote:
> > Dan,
> >     Thanks for the encouragement, it's much appreciated. If you don't
> mind
> > discussing off the list, I'd love to ask you some questions about
> > silverlight and see what you're doing with it.
> > Regards,
> > Ken
>
> Nothing I'm working on is top secret. Since January I've been working
> full time on a massively multiplayer turn-based strategy game.
> Initially I was using html/ajax for the client and CPython/django for
> the backend. In May I discovered the silverlight 2 beta, grabbed an
> early IronPython 2 alpha, and started porting the client. It was a
> gamble that set me back, but it's paying off now. Having Python on
> server and client means I can share code, and I can very efficiently
> transfer python data structures in binary format between server and
> client over HTTP. This makes new things possible. For example, at
> startup I send 100K of binary data to the client, that's the
> equivalent of almost 2mb of JSON.
>
> The real product is not the game itself, but the game engine as a
> platform for creating other games. I already have a group of fans very
> serious about building a Star Wars game on the engine. If they follow
> through on their plans it could be more visually impressive than my
> game.
>
> If you have any questions, just ask.
>
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From Jimmy.Schementi at microsoft.com  Wed Nov 19 00:38:12 2008
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 18 Nov 2008 15:38:12 -0800
Subject: [IronPython] Current working directory in Silverlight?
In-Reply-To: <4906F19A.6000500@voidspace.org.uk>
References: <ED058583-71A9-4AAA-87C8-37C9331AEC22@gmail.com>
	<4906F19A.6000500@voidspace.org.uk>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABBDC@NA-EXMSG-C116.redmond.corp.microsoft.com>

I treat the XAP file as a read-only filesystem today, which is why import works for files inside the XAP. In that case Directory.GetCurrentDirectory() "maybe" should give you the root of the XAP file, but I'm not sure how that would look. It would be interesting to see where the filesystem->XAP metaphor falls over.

Also, extending this metaphor to isolated storage is a better suited match. I'd like to support this first-class in Silverlight+DLR, so let me know if you want to write it =)

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Tuesday, October 28, 2008 4:04 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Current working directory in Silverlight?
>
> Kenneth Miller wrote:
> > All,
> >
> >
> >     Trying to execute this code in Silverlight:
> >
> > from System.IO import Directory
> > Directory.GetCurrentDirectory()
> >
>
> What happens when you execute this code?
>
> >     How do I handle directories in silveright? I know it's a bit
> > different since they're packaged. I need to be able to keep track of
> a
> > file's location inside the package.
>
> As you don't have a filesystem in Silverlight I doubt it has a concept
> of current working directory - this means that you will probably need
> to
> track it yourself. Being able to access resources inside the xap file
> using files is just a convenience.
>
> You can also use IsolatedStorage for filesystem like access in browser
> storage.
>
> Michael
>
> >
> > Thanks for your time.
> >
> > Regards,
> > Ken
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From xkenneth at gmail.com  Wed Nov 19 01:00:14 2008
From: xkenneth at gmail.com (Kenneth Miller)
Date: Tue, 18 Nov 2008 18:00:14 -0600
Subject: [IronPython] Python Standard Library in IronPython
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABBD8@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <CABCA1FA-22EA-47F8-B82B-84E07358263D@gmail.com>
	<9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com>
	<5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com>
	<EEDD8E95-3C1E-4051-BABE-6DA9E8D7FB75@gmail.com>
	<4909FAE7.4000309@voidspace.org.uk>
	<5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com>
	<490A1DAA.3010200@voidspace.org.uk>
	<97764E78-94CA-429C-BE01-3006D2244573@gmail.com>
	<4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com>
	<17CF84DE-2B94-4711-878C-B1D0E2C6CDDA@gmail.com>
	<4817b6fc0810311406y363a20a3u689dc900993eb286@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABBD8@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <D5878601-126E-44EA-8389-23E9F3E6AF32@gmail.com>

Jimmy,

        I'm really interested in being able to load python modules  
from isolated storage, please let me know how this works out.

Regards,
Ken

On Nov 18, 2008, at 5:35 PM, Jimmy Schementi wrote:

> Getting on this thread late ...
>
> I've been working on a way to load Python/Ruby libraries from either  
> a external XAP file or Isolated Storage. I should have something  
> checked into github.com/jschementi/agdlr shortly.
>
> Kenneth: wrappers around the Python stdlib out definitely be  
> interesting, though possibly very difficult to produce the exact  
> behaviors of the python libraries. .NET APIs don't map exactly to  
> Python's, or Ruby's, so there will always be special-casing, and  
> those can be the hardest to detect. I'd much rather find a good way  
> to load external libraries once and only once. But, I'm not going to  
> be the guy to stop you. =)
>
> ~js
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Dan Eloff
>> Sent: Friday, October 31, 2008 2:06 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Python Standard Library in IronPython
>>
>> On Fri, Oct 31, 2008 at 3:05 PM, Kenneth Miller <xkenneth at gmail.com>
>> wrote:
>>> Dan,
>>>    Thanks for the encouragement, it's much appreciated. If you don't
>> mind
>>> discussing off the list, I'd love to ask you some questions about
>>> silverlight and see what you're doing with it.
>>> Regards,
>>> Ken
>>
>> Nothing I'm working on is top secret. Since January I've been working
>> full time on a massively multiplayer turn-based strategy game.
>> Initially I was using html/ajax for the client and CPython/django for
>> the backend. In May I discovered the silverlight 2 beta, grabbed an
>> early IronPython 2 alpha, and started porting the client. It was a
>> gamble that set me back, but it's paying off now. Having Python on
>> server and client means I can share code, and I can very efficiently
>> transfer python data structures in binary format between server and
>> client over HTTP. This makes new things possible. For example, at
>> startup I send 100K of binary data to the client, that's the
>> equivalent of almost 2mb of JSON.
>>
>> The real product is not the game itself, but the game engine as a
>> platform for creating other games. I already have a group of fans  
>> very
>> serious about building a Star Wars game on the engine. If they follow
>> through on their plans it could be more visually impressive than my
>> game.
>>
>> If you have any questions, just ask.
>>
>> -Dan
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081118/a1ac70f2/attachment.html>

From Jimmy.Schementi at microsoft.com  Wed Nov 19 06:12:08 2008
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 18 Nov 2008 21:12:08 -0800
Subject: [IronPython] Python Standard Library in IronPython
In-Reply-To: <D5878601-126E-44EA-8389-23E9F3E6AF32@gmail.com>
References: <CABCA1FA-22EA-47F8-B82B-84E07358263D@gmail.com>
	<9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com>
	<5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com>
	<EEDD8E95-3C1E-4051-BABE-6DA9E8D7FB75@gmail.com>
	<4909FAE7.4000309@voidspace.org.uk>
	<5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com>
	<490A1DAA.3010200@voidspace.org.uk>
	<97764E78-94CA-429C-BE01-3006D2244573@gmail.com>
	<4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com>
	<17CF84DE-2B94-4711-878C-B1D0E2C6CDDA@gmail.com>
	<4817b6fc0810311406y363a20a3u689dc900993eb286@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABBD8@NA-EXMSG-C116.redmond.corp.microsoft.com>
	<D5878601-126E-44EA-8389-23E9F3E6AF32@gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABD19@NA-EXMSG-C116.redmond.corp.microsoft.com>

Will do, but you can just keep an eye on http://github.com/jschementi/agdlr ...

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kenneth Miller
Sent: Tuesday, November 18, 2008 4:00 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Python Standard Library in IronPython

Jimmy,

       I'm really interested in being able to load python modules from isolated storage, please let me know how this works out.

Regards,
Ken

On Nov 18, 2008, at 5:35 PM, Jimmy Schementi wrote:


Getting on this thread late ...

I've been working on a way to load Python/Ruby libraries from either a external XAP file or Isolated Storage. I should have something checked into github.com/jschementi/agdlr shortly.

Kenneth: wrappers around the Python stdlib out definitely be interesting, though possibly very difficult to produce the exact behaviors of the python libraries. .NET APIs don't map exactly to Python's, or Ruby's, so there will always be special-casing, and those can be the hardest to detect. I'd much rather find a good way to load external libraries once and only once. But, I'm not going to be the guy to stop you. =)

~js


-----Original Message-----
From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-
bounces at lists.ironpython.com<mailto:bounces at lists.ironpython.com>] On Behalf Of Dan Eloff
Sent: Friday, October 31, 2008 2:06 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Python Standard Library in IronPython

On Fri, Oct 31, 2008 at 3:05 PM, Kenneth Miller <xkenneth at gmail.com<mailto:xkenneth at gmail.com>>
wrote:
Dan,
   Thanks for the encouragement, it's much appreciated. If you don't
mind
discussing off the list, I'd love to ask you some questions about
silverlight and see what you're doing with it.
Regards,
Ken

Nothing I'm working on is top secret. Since January I've been working
full time on a massively multiplayer turn-based strategy game.
Initially I was using html/ajax for the client and CPython/django for
the backend. In May I discovered the silverlight 2 beta, grabbed an
early IronPython 2 alpha, and started porting the client. It was a
gamble that set me back, but it's paying off now. Having Python on
server and client means I can share code, and I can very efficiently
transfer python data structures in binary format between server and
client over HTTP. This makes new things possible. For example, at
startup I send 100K of binary data to the client, that's the
equivalent of almost 2mb of JSON.

The real product is not the game itself, but the game engine as a
platform for creating other games. I already have a group of fans very
serious about building a Star Wars game on the engine. If they follow
through on their plans it could be more visually impressive than my
game.

If you have any questions, just ask.

-Dan
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081118/9214e7cf/attachment.html>

From Jimmy.Schementi at microsoft.com  Wed Nov 19 06:22:08 2008
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 18 Nov 2008 21:22:08 -0800
Subject: [IronPython] AgDLR: Silverlight + DLR + Open Source
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8AABD1D@NA-EXMSG-C116.redmond.corp.microsoft.com>

(Thought I sent this to both IronRuby and IronPython mailing lists, but I mistyped the IPy one ... so here it is).

All,

First and foremost, I want to thank anyone who has used the bits on http://codeplex.com/sdlsdk, and accepting my bullshit version of open-source. While getting monthly binaries/sources is nice, it should be about working on the project together ... not just me throwing stuff over the wall to you. That's changing, now ...

Oh, and remember me complaining about the crappy "sdlsdk" name ... well, I'm trying to get rid of that acronym ...

http://github.com/jschementi/agdlr

Above the public repository for the DLR integration in Silverlight. The following post explains what's in there, what's not, what's git, and how to contribute: http://blog.jimmy.schementi.com/2008/11/agdlr-silverlight-dlr-open-source.html

My first order of collaboration is this simple new feature, "console=true": http://blog.jimmy.schementi.com/2008/11/repls-in-silverlight.html. If you like this, please feel free to look at what's been done, and if you want to fix something that doesn't yet work correctly, I won't stop you.

Also, as I mentioned in a previous mail, I want to make the filesystem->XAP/isolatedstorage metaphor stronger, so feel free to experiment with that as well. Over the next week I'll get some website-presence/wiki/etc, and we can run this project up and running. There are still some hurdles I need to clear with getting contributed code back into our internal codebase, and shipping on Codeplex, but there are no problems with keeping things on GitHub for now.

Let me know if there are any question. I know I've been a bit silent on the Silverlight front, but take this as me making it up to you. ;)

~Jimmy


From Sheetal.Pawar at lntinfotech.com  Wed Nov 19 06:41:00 2008
From: Sheetal.Pawar at lntinfotech.com (Sheetal.Pawar at lntinfotech.com)
Date: Wed, 19 Nov 2008 11:11:00 +0530
Subject: [IronPython] Serial Port Commn: unhandled ObjectDisposedException
 though exception handler provided
Message-ID: <OF9B0A2FEF.D43488C6-ON65257506.001E1D91-65257506.001F15CB@lntinfotech.com>

Hi,
I am writing a serial port communication application using Iron Python. 
Following is a sample code:
         try:
            BaudRate = 9600
            DataBits = 8           
           
#create a serial port instance for the desired port as specified
            serialPort = System.IO.Ports.SerialPort( "COM1")
           
            serialPort.BaudRate = BaudRate 

            serialPort.DataBits = DataBits 
#open the port
            serialPort.Close()
            serialPort.Open()
            serialPort.ReadTimeout = 30000
            returnValue = serialPort.ReadTo( "xx" )
        except:
            print "error"
            returnValue = ""
        serialPort.Close()
        serialPort.Dispose()
 
Here if i abort my application using Cntrl + C on the iron python console, 
then i get ObjectDisposedException unhandled though i have provided an 
exception handler.
I tried to abort the application while it was waiting for some data to be 
read and the timeout had not occured. The application exits and I get the 
exception after it exits.
Stack Trace: 

   at Microsoft.Win32.Win32Native.SetEvent(SafeWaitHandle handle)
   at System.Threading.EventWaitHandle.Set()
   at System.IO.Ports.SerialStream.AsyncFSCallback(UInt32 errorCode, 
UInt32 numBytes, NativeOverlapped* pOverlapped)
   at 
System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 
errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

Please let me know what can be the issue.

Thanks & regards,
Sheetal





______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/c1db59b7/attachment.html>

From fuzzyman at voidspace.org.uk  Wed Nov 19 13:55:46 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 12:55:46 +0000
Subject: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
Message-ID: <49240CD2.8020003@voidspace.org.uk>

Hello guys,

It looks like in source code drop 43712 module name lookup is broken if 
the name is also a .NET member name (presumably of Script or 
ScriptScope) and clr has not been imported.

To reproduce have a pure python module called 'check.py' containing:

def check(module):
    print module.Keys

If you also have a 'stuff.py' module containing:

Keys = 3

You get the following exception:

 >>> import stuff
 >>> from check import check
 >>> check(stuff)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Dev\buildshare\Ipy2-43712-binaries\check.py", line 2, in check
AttributeError: 'module' object has no attribute 'Keys'

(Interestingly 'Keys' does appear in the dir of the module.)

This is causing us problems in the use of unittest that does module 
introspection. It isn't blocking us as adding 'import clr' causes the 
problem to go away, but could well cause us other problems (we are still 
working our way through our last remaining 50 unit test failures in our 
IronPython 2 port.)

I have raised this as issue number 19656 on Codeplex:

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656

All the best,

Michael Foord & Glenn Jones
Resolver Systems

-- 
http://www.ironpythoninaction.com/



From curt at hagenlocher.org  Wed Nov 19 13:58:36 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 19 Nov 2008 04:58:36 -0800
Subject: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
In-Reply-To: <49240CD2.8020003@voidspace.org.uk>
References: <49240CD2.8020003@voidspace.org.uk>
Message-ID: <d2155e360811190458t76861c5ft79753c1b80133122@mail.gmail.com>

You're using the version in the IronPython_2_0 folder, yes?

On Wed, Nov 19, 2008 at 4:55 AM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> Hello guys,
>
> It looks like in source code drop 43712 module name lookup is broken if the
> name is also a .NET member name (presumably of Script or ScriptScope) and
> clr has not been imported.
>
> To reproduce have a pure python module called 'check.py' containing:
>
> def check(module):
>   print module.Keys
>
> If you also have a 'stuff.py' module containing:
>
> Keys = 3
>
> You get the following exception:
>
> >>> import stuff
> >>> from check import check
> >>> check(stuff)
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File "C:\Dev\buildshare\Ipy2-43712-binaries\check.py", line 2, in check
> AttributeError: 'module' object has no attribute 'Keys'
>
> (Interestingly 'Keys' does appear in the dir of the module.)
>
> This is causing us problems in the use of unittest that does module
> introspection. It isn't blocking us as adding 'import clr' causes the
> problem to go away, but could well cause us other problems (we are still
> working our way through our last remaining 50 unit test failures in our
> IronPython 2 port.)
>
> I have raised this as issue number 19656 on Codeplex:
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656
>
> All the best,
>
> Michael Foord & Glenn Jones
> Resolver Systems
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/64a1bb8b/attachment.html>

From fuzzyman at voidspace.org.uk  Wed Nov 19 14:00:14 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 13:00:14 +0000
Subject: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
In-Reply-To: <d2155e360811190458t76861c5ft79753c1b80133122@mail.gmail.com>
References: <49240CD2.8020003@voidspace.org.uk>
	<d2155e360811190458t76861c5ft79753c1b80133122@mail.gmail.com>
Message-ID: <49240DDE.5020304@voidspace.org.uk>

Curt Hagenlocher wrote:
> You're using the version in the IronPython_2_0 folder, yes?
Yes.

Michael
>
> On Wed, Nov 19, 2008 at 4:55 AM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Hello guys,
>
>     It looks like in source code drop 43712 module name lookup is
>     broken if the name is also a .NET member name (presumably of
>     Script or ScriptScope) and clr has not been imported.
>
>     To reproduce have a pure python module called 'check.py' containing:
>
>     def check(module):
>       print module.Keys
>
>     If you also have a 'stuff.py' module containing:
>
>     Keys = 3
>
>     You get the following exception:
>
>     >>> import stuff
>     >>> from check import check
>     >>> check(stuff)
>     Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>      File "C:\Dev\buildshare\Ipy2-43712-binaries\check.py", line 2, in
>     check
>     AttributeError: 'module' object has no attribute 'Keys'
>
>     (Interestingly 'Keys' does appear in the dir of the module.)
>
>     This is causing us problems in the use of unittest that does
>     module introspection. It isn't blocking us as adding 'import clr'
>     causes the problem to go away, but could well cause us other
>     problems (we are still working our way through our last remaining
>     50 unit test failures in our IronPython 2 port.)
>
>     I have raised this as issue number 19656 on Codeplex:
>
>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656
>
>     All the best,
>
>     Michael Foord & Glenn Jones
>     Resolver Systems
>
>     -- 
>     http://www.ironpythoninaction.com/
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>   


-- 
http://www.ironpythoninaction.com/



From fuzzyman at voidspace.org.uk  Wed Nov 19 16:19:38 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 15:19:38 +0000
Subject: [IronPython] Serial Port Commn: unhandled
 ObjectDisposedException though exception handler provided
In-Reply-To: <OF9B0A2FEF.D43488C6-ON65257506.001E1D91-65257506.001F15CB@lntinfotech.com>
References: <OF9B0A2FEF.D43488C6-ON65257506.001E1D91-65257506.001F15CB@lntinfotech.com>
Message-ID: <49242E8A.2030404@voidspace.org.uk>

Well... I know nothing about these APIs and am guessing, but the 
traceback is in an AsyncCallback happening on another thread - so an 
exception handler in this thread isn't going to catch it.

Why do you close the port before opening it?

ReadTo doesn't look like an Async API [1]. You snipped the top line of 
the traceback which includes any mention of the line number where it was 
raised. Have you put a print in to confirm that your exception handling 
block is never entered?

Michael

http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readto.aspx

Sheetal.Pawar at lntinfotech.com wrote:
>
>
> Hi,
>
> I am writing a serial port communication application using Iron 
> Python. Following is a sample code:
>
>          try:
>
>             BaudRate = 9600
>             DataBits = 8           
>           
> #create a serial port instance for the desired port as specified
>             serialPort = System.IO.Ports.SerialPort( "COM1")
>           
>             serialPort.BaudRate = BaudRate 
>
>             serialPort.DataBits = DataBits
>
> #open the port
>             serialPort.Close()
>             serialPort.Open()
>
>             serialPort.ReadTimeout = 30000
>
>             returnValue = serialPort.ReadTo( "xx" )
>         except:
>             print "error"
>             returnValue = ""
>
>         serialPort.Close()
>         serialPort.Dispose()
>
>  
>
> Here if i abort my application using Cntrl + C on the iron python 
> console, then i get ObjectDisposedException unhandled though i have 
> provided an exception handler.
>
> I tried to abort the application while it was waiting for some data to 
> be read and the timeout had not occured. The application exits and I 
> get the exception after it exits.
>
> Stack Trace:
>
>    at Microsoft.Win32.Win32Native.SetEvent(SafeWaitHandle handle)
>    at System.Threading.EventWaitHandle.Set()
>    at System.IO.Ports.SerialStream.AsyncFSCallback(UInt32 errorCode, 
> UInt32 numBytes, NativeOverlapped* pOverlapped)
>    at 
> System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 
> errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
>
> Please let me know what can be the issue.
>
> Thanks & regards,
> Sheetal
>
>
>
>
>
>
> ______________________________________________________________________
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/



From glenn.k.jones+ipy at gmail.com  Wed Nov 19 17:10:24 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Wed, 19 Nov 2008 16:10:24 +0000
Subject: [IronPython] List slicing in IPy 2
Message-ID: <2679f6510811190810i5e9a8c47i64571f8f440bbb1e@mail.gmail.com>

Hi all,

Further discoveries from our update to use Ipy 2:
In Ipy1:
>>> from System import Int64
>>> i = Int64(3)
>>> range(1, 100)[i:20]
[4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]

in IPy2:
>>> from System import Int64
>>> i = Int64(5)
>>> range(1, 100)[i:20]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected index value, got Int64


It's not a major issue for us, but it's still a little strange.

Thanks
Glenn & Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/c0e4a1c0/attachment.html>

From dinov at microsoft.com  Wed Nov 19 17:34:43 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 19 Nov 2008 08:34:43 -0800
Subject: [IronPython] sys.argv is empty after compilation
In-Reply-To: <c9d970015ec51f06a9e12818dedea14b.squirrel@held.org.il>
References: <c9d970015ec51f06a9e12818dedea14b.squirrel@held.org.il>
Message-ID: <350E7D38B6D819428718949920EC23555644813F8B@NA-EXMSG-C102.redmond.corp.microsoft.com>

Yep, we missed this again when we re-wrote precompilation support :(  I have another pyc update I need to make and I'll update it to set sys.argv as well.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Oren Held
Sent: Tuesday, November 18, 2008 2:29 AM
To: users at lists.ironpython.com
Subject: [IronPython] sys.argv is empty after compilation

Hi,

sys.argv works well under the interpreter, but gets empty after compiling.

I've encountered this message from 2006:
http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2006-February/001712.html

However this interpreter-executable inconsistency still occurs to me with
2.0RC1.


10x

 - Oren

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


From glenn.k.jones+ipy at gmail.com  Wed Nov 19 17:42:49 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Wed, 19 Nov 2008 16:42:49 +0000
Subject: [IronPython] IPy2: Problem inheriting from .Net object
Message-ID: <2679f6510811190842v58225168o1c3cd8015623168f@mail.gmail.com>

Hi all,

It's us again!
With this object:
from System.IO import MemoryStream

class MockStream(MemoryStream):
    def __init__(self):
        MemoryStream.__init__(self)
        self.closed = False

    def Close(self):
        print 'Into close'
        MemoryStream.Close(self)
        print 'Past close'
        self.closed = True

IronPython 1.1:
>>> import mockstream
>>> m = mockstream.MockStream()
>>> m.Close()
Into close
Past close
>>>

IronPython 2.0 latest code drop:
>>> import mockstream
>>> m = mockstream.MockStream()
>>> m.Close()
Into close
....
repeated to StackOverflowException

We'll raise this one and the issue we reported earlier as soon as codeplex
starts behaving itself again.

Thanks
Glenn & Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/8b3f3abb/attachment.html>

From dinov at microsoft.com  Wed Nov 19 17:44:28 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 19 Nov 2008 08:44:28 -0800
Subject: [IronPython] List slicing in IPy 2
In-Reply-To: <2679f6510811190810i5e9a8c47i64571f8f440bbb1e@mail.gmail.com>
References: <2679f6510811190810i5e9a8c47i64571f8f440bbb1e@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23555644813F96@NA-EXMSG-C102.redmond.corp.microsoft.com>

Thanks for the report.  We should be defining __index__ on the .NET primitive numeric types as well.  Filed as 19657 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19657


From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Wednesday, November 19, 2008 8:10 AM
To: users at lists.ironpython.com
Subject: [IronPython] List slicing in IPy 2

Hi all,

Further discoveries from our update to use Ipy 2:
In Ipy1:
>>> from System import Int64
>>> i = Int64(3)
>>> range(1, 100)[i:20]
[4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]

in IPy2:
>>> from System import Int64
>>> i = Int64(5)
>>> range(1, 100)[i:20]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected index value, got Int64


It's not a major issue for us, but it's still a little strange.

Thanks
Glenn & Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/fbc03afe/attachment.html>

From dinov at microsoft.com  Wed Nov 19 17:46:41 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 19 Nov 2008 08:46:41 -0800
Subject: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
In-Reply-To: <49240DDE.5020304@voidspace.org.uk>
References: <49240CD2.8020003@voidspace.org.uk>
	<d2155e360811190458t76861c5ft79753c1b80133122@mail.gmail.com>
	<49240DDE.5020304@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC23555644813F9B@NA-EXMSG-C102.redmond.corp.microsoft.com>

Yeah, that's pretty bad...  I've filed this as 19658 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19658.  Thanks for reporting this.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, November 19, 2008 5:00 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2 Bug: Module Name Lookup Broken

Curt Hagenlocher wrote:
> You're using the version in the IronPython_2_0 folder, yes?
Yes.

Michael
>
> On Wed, Nov 19, 2008 at 4:55 AM, Michael Foord
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Hello guys,
>
>     It looks like in source code drop 43712 module name lookup is
>     broken if the name is also a .NET member name (presumably of
>     Script or ScriptScope) and clr has not been imported.
>
>     To reproduce have a pure python module called 'check.py' containing:
>
>     def check(module):
>       print module.Keys
>
>     If you also have a 'stuff.py' module containing:
>
>     Keys = 3
>
>     You get the following exception:
>
>     >>> import stuff
>     >>> from check import check
>     >>> check(stuff)
>     Traceback (most recent call last):
>      File "<stdin>", line 1, in <module>
>      File "C:\Dev\buildshare\Ipy2-43712-binaries\check.py", line 2, in
>     check
>     AttributeError: 'module' object has no attribute 'Keys'
>
>     (Interestingly 'Keys' does appear in the dir of the module.)
>
>     This is causing us problems in the use of unittest that does
>     module introspection. It isn't blocking us as adding 'import clr'
>     causes the problem to go away, but could well cause us other
>     problems (we are still working our way through our last remaining
>     50 unit test failures in our IronPython 2 port.)
>
>     I have raised this as issue number 19656 on Codeplex:
>
>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656
>
>     All the best,
>
>     Michael Foord & Glenn Jones
>     Resolver Systems
>
>     --
>     http://www.ironpythoninaction.com/
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>


--
http://www.ironpythoninaction.com/

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



From fuzzyman at voidspace.org.uk  Wed Nov 19 17:48:58 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 16:48:58 +0000
Subject: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
In-Reply-To: <350E7D38B6D819428718949920EC23555644813F9B@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49240CD2.8020003@voidspace.org.uk>	<d2155e360811190458t76861c5ft79753c1b80133122@mail.gmail.com>	<49240DDE.5020304@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23555644813F9B@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4924437A.4080503@voidspace.org.uk>

Dino Viehland wrote:
> Yeah, that's pretty bad...  I've filed this as 19658 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19658.  Thanks for reporting this.
>   

As well as 19656 that I reported it as. ;-)
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656

Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, November 19, 2008 5:00 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
>
> Curt Hagenlocher wrote:
>   
>> You're using the version in the IronPython_2_0 folder, yes?
>>     
> Yes.
>
> Michael
>   
>> On Wed, Nov 19, 2008 at 4:55 AM, Michael Foord
>> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>
>>     Hello guys,
>>
>>     It looks like in source code drop 43712 module name lookup is
>>     broken if the name is also a .NET member name (presumably of
>>     Script or ScriptScope) and clr has not been imported.
>>
>>     To reproduce have a pure python module called 'check.py' containing:
>>
>>     def check(module):
>>       print module.Keys
>>
>>     If you also have a 'stuff.py' module containing:
>>
>>     Keys = 3
>>
>>     You get the following exception:
>>
>>     >>> import stuff
>>     >>> from check import check
>>     >>> check(stuff)
>>     Traceback (most recent call last):
>>      File "<stdin>", line 1, in <module>
>>      File "C:\Dev\buildshare\Ipy2-43712-binaries\check.py", line 2, in
>>     check
>>     AttributeError: 'module' object has no attribute 'Keys'
>>
>>     (Interestingly 'Keys' does appear in the dir of the module.)
>>
>>     This is causing us problems in the use of unittest that does
>>     module introspection. It isn't blocking us as adding 'import clr'
>>     causes the problem to go away, but could well cause us other
>>     problems (we are still working our way through our last remaining
>>     50 unit test failures in our IronPython 2 port.)
>>
>>     I have raised this as issue number 19656 on Codeplex:
>>
>>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656
>>
>>     All the best,
>>
>>     Michael Foord & Glenn Jones
>>     Resolver Systems
>>
>>     --
>>     http://www.ironpythoninaction.com/
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.ironpython.com <mailto: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
>>
>>     
>
>
> --
> http://www.ironpythoninaction.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
>   


-- 
http://www.ironpythoninaction.com/



From curt at hagenlocher.org  Wed Nov 19 17:52:03 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 19 Nov 2008 08:52:03 -0800
Subject: [IronPython] IPy2: Problem inheriting from .Net object
In-Reply-To: <2679f6510811190842v58225168o1c3cd8015623168f@mail.gmail.com>
References: <2679f6510811190842v58225168o1c3cd8015623168f@mail.gmail.com>
Message-ID: <d2155e360811190852o2f0e03cfwdb96819f5d4ad656@mail.gmail.com>

This looks like it's equivalent to 19434:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19434

On Wed, Nov 19, 2008 at 8:42 AM, Glenn Jones
<glenn.k.jones+ipy at gmail.com<glenn.k.jones%2Bipy at gmail.com>
> wrote:

> Hi all,
>
> It's us again!
> With this object:
> from System.IO import MemoryStream
>
> class MockStream(MemoryStream):
>     def __init__(self):
>         MemoryStream.__init__(self)
>         self.closed = False
>
>     def Close(self):
>         print 'Into close'
>         MemoryStream.Close(self)
>         print 'Past close'
>         self.closed = True
>
> IronPython 1.1:
> >>> import mockstream
> >>> m = mockstream.MockStream()
> >>> m.Close()
> Into close
> Past close
> >>>
>
> IronPython 2.0 latest code drop:
> >>> import mockstream
> >>> m = mockstream.MockStream()
> >>> m.Close()
> Into close
> ....
> repeated to StackOverflowException
>
> We'll raise this one and the issue we reported earlier as soon as codeplex
> starts behaving itself again.
>
> Thanks
> Glenn & Michael
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/7561c033/attachment.html>

From dinov at microsoft.com  Wed Nov 19 18:02:42 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 19 Nov 2008 09:02:42 -0800
Subject: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
In-Reply-To: <4924437A.4080503@voidspace.org.uk>
References: <49240CD2.8020003@voidspace.org.uk>
	<d2155e360811190458t76861c5ft79753c1b80133122@mail.gmail.com>
	<49240DDE.5020304@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23555644813F9B@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4924437A.4080503@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC23555644813FB4@NA-EXMSG-C102.redmond.corp.microsoft.com>

Ok in that case I've closed mine :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, November 19, 2008 8:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2 Bug: Module Name Lookup Broken

Dino Viehland wrote:
> Yeah, that's pretty bad...  I've filed this as 19658 - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19658.  Thanks for reporting this.
>

As well as 19656 that I reported it as. ;-)
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656

Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, November 19, 2008 5:00 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython 2 Bug: Module Name Lookup Broken
>
> Curt Hagenlocher wrote:
>
>> You're using the version in the IronPython_2_0 folder, yes?
>>
> Yes.
>
> Michael
>
>> On Wed, Nov 19, 2008 at 4:55 AM, Michael Foord
>> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>
>>     Hello guys,
>>
>>     It looks like in source code drop 43712 module name lookup is
>>     broken if the name is also a .NET member name (presumably of
>>     Script or ScriptScope) and clr has not been imported.
>>
>>     To reproduce have a pure python module called 'check.py' containing:
>>
>>     def check(module):
>>       print module.Keys
>>
>>     If you also have a 'stuff.py' module containing:
>>
>>     Keys = 3
>>
>>     You get the following exception:
>>
>>     >>> import stuff
>>     >>> from check import check
>>     >>> check(stuff)
>>     Traceback (most recent call last):
>>      File "<stdin>", line 1, in <module>
>>      File "C:\Dev\buildshare\Ipy2-43712-binaries\check.py", line 2, in
>>     check
>>     AttributeError: 'module' object has no attribute 'Keys'
>>
>>     (Interestingly 'Keys' does appear in the dir of the module.)
>>
>>     This is causing us problems in the use of unittest that does
>>     module introspection. It isn't blocking us as adding 'import clr'
>>     causes the problem to go away, but could well cause us other
>>     problems (we are still working our way through our last remaining
>>     50 unit test failures in our IronPython 2 port.)
>>
>>     I have raised this as issue number 19656 on Codeplex:
>>
>>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19656
>>
>>     All the best,
>>
>>     Michael Foord & Glenn Jones
>>     Resolver Systems
>>
>>     --
>>     http://www.ironpythoninaction.com/
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.ironpython.com <mailto: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
>>
>>
>
>
> --
> http://www.ironpythoninaction.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
>


--
http://www.ironpythoninaction.com/

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


From fuzzyman at voidspace.org.uk  Wed Nov 19 18:29:02 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 17:29:02 +0000
Subject: [IronPython] IPy2: Problem inheriting from .Net object
In-Reply-To: <d2155e360811190852o2f0e03cfwdb96819f5d4ad656@mail.gmail.com>
References: <2679f6510811190842v58225168o1c3cd8015623168f@mail.gmail.com>
	<d2155e360811190852o2f0e03cfwdb96819f5d4ad656@mail.gmail.com>
Message-ID: <49244CDE.6030800@voidspace.org.uk>

Curt Hagenlocher wrote:
> This looks like it's equivalent to 19434:
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19434

It does look to be the same issue - although that is marked for 2.1 and 
it does 'impinge upon subclassing' substantially.

(The workaround, whilst not always going to be a solution, is a stroke 
of pure evil genius by the way.)

Michael

>
> On Wed, Nov 19, 2008 at 8:42 AM, Glenn Jones 
> <glenn.k.jones+ipy at gmail.com <mailto:glenn.k.jones%2Bipy at gmail.com>> 
> wrote:
>
>     Hi all,
>
>     It's us again!
>     With this object:
>     from System.IO import MemoryStream
>
>     class MockStream(MemoryStream):
>         def __init__(self):
>             MemoryStream.__init__(self)
>             self.closed = False
>
>         def Close(self):
>             print 'Into close'
>             MemoryStream.Close(self)
>             print 'Past close'
>             self.closed = True
>
>     IronPython 1.1:
>     >>> import mockstream
>     >>> m = mockstream.MockStream()
>     >>> m.Close()
>     Into close
>     Past close
>     >>>
>
>     IronPython 2.0 latest code drop:
>     >>> import mockstream
>     >>> m = mockstream.MockStream()
>     >>> m.Close()
>     Into close
>     ....
>     repeated to StackOverflowException
>
>     We'll raise this one and the issue we reported earlier as soon as
>     codeplex starts behaving itself again.
>
>     Thanks
>     Glenn & Michael
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>   


-- 
http://www.ironpythoninaction.com/



From Marty.Nelson at symyx.com  Wed Nov 19 21:19:27 2008
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Wed, 19 Nov 2008 12:19:27 -0800
Subject: [IronPython] Use of sys.exit
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03269EB0@srv-be-101.Symyx-IC.symyx.com>


We have users writing extension scripts that execute from C#, and may be
called multiple times (for example, hooked up to a Change event of some
object or event in the main application)

 

Is sys.exit(1) an acceptable way for them to exit the script (used like
an early return in C#)?  Is there a better way?  Does it do anything to
the ScriptScope that is reused?

 

Thanks!

 

 



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081119/39c92340/attachment.html>

From fuzzyman at voidspace.org.uk  Wed Nov 19 21:25:43 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 20:25:43 +0000
Subject: [IronPython] Use of sys.exit
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03269EB0@srv-be-101.Symyx-IC.symyx.com>
References: <515335F32AA04440B3DE6FEA1993E9AD03269EB0@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <49247647.8000108@voidspace.org.uk>

Marty Nelson wrote:
>
> We have users writing extension scripts that execute from C#, and may 
> be called multiple times (for example, hooked up to a Change event of 
> some object or event in the main application)
>
>  
>
> Is sys.exit(1) an acceptable way for them to exit the script (used 
> like an early return in C#)?  Is there a better way?  Does it do 
> anything to the ScriptScope that is reused?
>
It would seem acceptable - it raises the SystemExit exception which your 
hosting application would need to catch and ignore.

A better structured way (in my opinion) would be to use a procedural or 
object oriented approach in the scripts and allow them to terminate 
normally.

Michael Foord

>  
>
> Thanks!
>
>  
>
>  
>
> =======
> Notice: This e-mail message, together with any attachments, contains
> information of Symyx Technologies, Inc. or any of its affiliates or
> subsidiaries that may be confidential, proprietary, copyrighted,
> privileged and/or protected work product, and is meant solely for
> the intended recipient. If you are not the intended recipient, and
> have received this message in error, please contact the sender
> immediately, permanently delete the original and any copies of this
> email and any attachments thereto.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From fuzzyman at voidspace.org.uk  Wed Nov 19 22:45:56 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 19 Nov 2008 21:45:56 +0000
Subject: [IronPython] Use of sys.exit
In-Reply-To: <49247647.8000108@voidspace.org.uk>
References: <515335F32AA04440B3DE6FEA1993E9AD03269EB0@srv-be-101.Symyx-IC.symyx.com>
	<49247647.8000108@voidspace.org.uk>
Message-ID: <49248914.3090502@voidspace.org.uk>

Michael Foord wrote:
> Marty Nelson wrote:
>>
>> We have users writing extension scripts that execute from C#, and may 
>> be called multiple times (for example, hooked up to a Change event of 
>> some object or event in the main application)
>>
>>  
>>
>> Is sys.exit(1) an acceptable way for them to exit the script (used 
>> like an early return in C#)?  Is there a better way?  Does it do 
>> anything to the ScriptScope that is reused?
>>
> It would seem acceptable - it raises the SystemExit exception which 
> your hosting application would need to catch and ignore.
>

In fact I suggested a while back that Resolver One could use sys.exit to 
signify an early exit from a user code block. :-)

Michael

> A better structured way (in my opinion) would be to use a procedural 
> or object oriented approach in the scripts and allow them to terminate 
> normally.
>
> Michael Foord
>
>>  
>>
>> Thanks!
>>
>>  
>>
>>  
>>
>> =======
>> Notice: This e-mail message, together with any attachments, contains
>> information of Symyx Technologies, Inc. or any of its affiliates or
>> subsidiaries that may be confidential, proprietary, copyrighted,
>> privileged and/or protected work product, and is meant solely for
>> the intended recipient. If you are not the intended recipient, and
>> have received this message in error, please contact the sender
>> immediately, permanently delete the original and any copies of this
>> email and any attachments thereto.
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>   
>
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From Sheetal.Pawar at lntinfotech.com  Thu Nov 20 04:21:58 2008
From: Sheetal.Pawar at lntinfotech.com (Sheetal.Pawar at lntinfotech.com)
Date: Thu, 20 Nov 2008 08:51:58 +0530
Subject: [IronPython] Serial Port Commn: unhandled
 ObjectDisposedException though exception handler provided
In-Reply-To: <49242E8A.2030404@voidspace.org.uk>
Message-ID: <OF930579EB.C9D8BC9C-ON65257507.00110DF0-65257507.00125B14@lntinfotech.com>

That close is kept just to ensure that the open call does not fail saying 
"port already open". It was just for testing purpose.

Yes ReadTo is not an asynch API. The program execution is blocked at 
ReadTo till the timeout occurs. But the problem occurs when I try to abort 
the read operation in between before the timeout.

Yes I had put a print in the exception handler. The problem is I get that 
print and get "Keyboard Interrupt" as the error message but still I am 
getting the ObjectDisposedException.

This is the message which i get when i try to print the error using 
except Exception, e:
    print "error   :  " + e.message:

Output:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\IronPython 2.0 Beta4\test.py", line 21, in 
C:\Program Files\IronPython 2.0 Beta4\test.py
KeyboardInterrupt
>>>



Thanks & regards,
Sheetal Pawar





Michael Foord <fuzzyman at voidspace.org.uk> 
Sent by: users-bounces at lists.ironpython.com
11/19/2008 08:49 PM
Please respond to
Discussion of IronPython <users at lists.ironpython.com>


To
Discussion of IronPython <users at lists.ironpython.com>
cc

Subject
Re: [IronPython] Serial Port Commn: unhandled ObjectDisposedException 
though exception handler provided






Well... I know nothing about these APIs and am guessing, but the 
traceback is in an AsyncCallback happening on another thread - so an 
exception handler in this thread isn't going to catch it.

Why do you close the port before opening it?

ReadTo doesn't look like an Async API [1]. You snipped the top line of 
the traceback which includes any mention of the line number where it was 
raised. Have you put a print in to confirm that your exception handling 
block is never entered?

Michael

http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readto.aspx


Sheetal.Pawar at lntinfotech.com wrote:
>
>
> Hi,
>
> I am writing a serial port communication application using Iron 
> Python. Following is a sample code:
>
>          try:
>
>             BaudRate = 9600
>             DataBits = 8 
> 
> #create a serial port instance for the desired port as specified
>             serialPort = System.IO.Ports.SerialPort( "COM1")
> 
>             serialPort.BaudRate = BaudRate 
>
>             serialPort.DataBits = DataBits
>
> #open the port
>             serialPort.Close()
>             serialPort.Open()
>
>             serialPort.ReadTimeout = 30000
>
>             returnValue = serialPort.ReadTo( "xx" )
>         except:
>             print "error"
>             returnValue = ""
>
>         serialPort.Close()
>         serialPort.Dispose()
>
> 
>
> Here if i abort my application using Cntrl + C on the iron python 
> console, then i get ObjectDisposedException unhandled though i have 
> provided an exception handler.
>
> I tried to abort the application while it was waiting for some data to 
> be read and the timeout had not occured. The application exits and I 
> get the exception after it exits.
>
> Stack Trace:
>
>    at Microsoft.Win32.Win32Native.SetEvent(SafeWaitHandle handle)
>    at System.Threading.EventWaitHandle.Set()
>    at System.IO.Ports.SerialStream.AsyncFSCallback(UInt32 errorCode, 
> UInt32 numBytes, NativeOverlapped* pOverlapped)
>    at 
> 
System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 
> errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
>
> Please let me know what can be the issue.
>
> Thanks & regards,
> Sheetal
>
>
>
>
>
>
> ______________________________________________________________________
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 


-- 
http://www.ironpythoninaction.com/

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

______________________________________________________________________



______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081120/13f38a74/attachment.html>

From rob.s.oakes at gmail.com  Thu Nov 20 05:16:12 2008
From: rob.s.oakes at gmail.com (Rob Oakes)
Date: Wed, 19 Nov 2008 21:16:12 -0700
Subject: [IronPython] A few shameless plugs
Message-ID: <4924e496.1e068e0a.1dcb.5891@mx.google.com>

Dear Group,

I wanted to take a minute and bring a really cool series of articles to the
groups attention.  Over on DevHawk, Harry Pierson has been been writing
about IronPython and WPF.  He is currently up to article 4 in the series and
I have found them to be really helpful.  It also happens that I tend to be
fighting with a project in both WPF and IronPython, so I am devouring
anything I can find on the subject.  For those interested, the Url is:

http://devhawk.net/default.aspx

Which leads me to the second (and far more shameless) plug.  Some members of
my lab are also trying to learn IronPython and have asked me to write up
some of my experiences.  I recently posted a little tutorial on
multithreading and the BackgroundWorker class.  I thought I would pass the
Url along as there may be some here who find it interesting.

http://robertsoakes.brinkster.net/blog/?p=75

If you take drop by, please leave a comment to let me know what you think.
If you see something that can be improved, also please leave a comment.  I
am REALLY new to IronPython and I would greatly appreciate any feedback that
you might have.

Best,

Rob Oakes
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3623 (20081118) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 



From fuzzyman at voidspace.org.uk  Thu Nov 20 11:01:39 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 20 Nov 2008 10:01:39 +0000
Subject: [IronPython] Serial Port Commn: unhandled
 ObjectDisposedException though exception handler provided
In-Reply-To: <OF930579EB.C9D8BC9C-ON65257507.00110DF0-65257507.00125B14@lntinfotech.com>
References: <OF930579EB.C9D8BC9C-ON65257507.00110DF0-65257507.00125B14@lntinfotech.com>
Message-ID: <49253583.6020600@voidspace.org.uk>

Sheetal.Pawar at lntinfotech.com wrote:
>
> That close is kept just to ensure that the open call does not fail 
> saying "port already open". It was just for testing purpose.
>
> Yes ReadTo is not an asynch API. The program execution is blocked at 
> ReadTo till the timeout occurs. But the problem occurs when I try to 
> abort the read operation in between before the timeout.
>

The ObjectDisposedException (which you still haven't posted a full 
traceback for) indicates that under the hood it is an async API.

> Yes I had put a print in the exception handler. The problem is I get 
> that print and get "Keyboard Interrupt" as the error message but still 
> I am getting the ObjectDisposedException.
>
> This is the message which i get when i try to print the error using
> except Exception, e:
>     print "error   :  " + e.message:
>
> Output:
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "C:\Program Files\IronPython 2.0 Beta4\test.py", line 21, in 
> C:\Program Files\IronPython 2.0 Beta4\test.py
> KeyboardInterrupt
> >>>

This shows that your exception handling block is being used. I guess the 
problem is that you are closing the port after interrupting it whilst 
there is still an active callback with data waiting to come in. When 
this happens it tries to use a disposed object.

I don't think interrupting the 'ReadTo' with a KeyboardInterrupt is a 
very good pattern - but I'm not sure what the correct pattern is for 
this case. Maybe experiment with some of the async APIs (there are 
examples on the MSDN docs) so that you can explicitly provide for an 
interruption if you need it.

Michael Foord


>
>
> Thanks & regards,
> Sheetal Pawar
> *
> *
>
>
> *Michael Foord <fuzzyman at voidspace.org.uk>*
> Sent by: users-bounces at lists.ironpython.com
>
> 11/19/2008 08:49 PM
> Please respond to
> Discussion of IronPython <users at lists.ironpython.com>
>
>
> 	
> To
> 	Discussion of IronPython <users at lists.ironpython.com>
> cc
> 	
> Subject
> 	Re: [IronPython] Serial Port Commn: unhandled ObjectDisposedException 
> though exception handler provided
>
>
>
> 	
>
>
>
>
>
> Well... I know nothing about these APIs and am guessing, but the
> traceback is in an AsyncCallback happening on another thread - so an
> exception handler in this thread isn't going to catch it.
>
> Why do you close the port before opening it?
>
> ReadTo doesn't look like an Async API [1]. You snipped the top line of
> the traceback which includes any mention of the line number where it was
> raised. Have you put a print in to confirm that your exception handling
> block is never entered?
>
> Michael
>
> http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readto.aspx
>
> Sheetal.Pawar at lntinfotech.com wrote:
> >
> >
> > Hi,
> >
> > I am writing a serial port communication application using Iron
> > Python. Following is a sample code:
> >
> >          try:
> >
> >             BaudRate = 9600
> >             DataBits = 8          
> >          
> > #create a serial port instance for the desired port as specified
> >             serialPort = System.IO.Ports.SerialPort( "COM1")
> >          
> >             serialPort.BaudRate = BaudRate
> >
> >             serialPort.DataBits = DataBits
> >
> > #open the port
> >             serialPort.Close()
> >             serialPort.Open()
> >
> >             serialPort.ReadTimeout = 30000
> >
> >             returnValue = serialPort.ReadTo( "xx" )
> >         except:
> >             print "error"
> >             returnValue = ""
> >
> >         serialPort.Close()
> >         serialPort.Dispose()
> >
> >  
> >
> > Here if i abort my application using Cntrl + C on the iron python
> > console, then i get ObjectDisposedException unhandled though i have
> > provided an exception handler.
> >
> > I tried to abort the application while it was waiting for some data to
> > be read and the timeout had not occured. The application exits and I
> > get the exception after it exits.
> >
> > Stack Trace:
> >
> >    at Microsoft.Win32.Win32Native.SetEvent(SafeWaitHandle handle)
> >    at System.Threading.EventWaitHandle.Set()
> >    at System.IO.Ports.SerialStream.AsyncFSCallback(UInt32 errorCode,
> > UInt32 numBytes, NativeOverlapped* pOverlapped)
> >    at
> > 
> System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32
> > errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
> >
> > Please let me know what can be the issue.
> >
> > Thanks & regards,
> > Sheetal
> >
> >
> >
> >
> >
> >
> > ______________________________________________________________________
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >  
>
>
> -- 
> http://www.ironpythoninaction.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
>   


-- 
http://www.ironpythoninaction.com/



From glenn.k.jones+ipy at gmail.com  Thu Nov 20 13:33:01 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Thu, 20 Nov 2008 12:33:01 +0000
Subject: [IronPython] Blocker: subclasses of float have trouble with __int__
	and __str__
Message-ID: <2679f6510811200433q1822466at5b45d2c4bddd88d8@mail.gmail.com>

Hello guys,

On the latest code drop (43741) it seems that something is broken in
subclasses of floats.

class MyFloatType(float):
  def __new__(cls):
    return float.__new__(cls, 0.0)

  def __repr__(self):
    return "MyFloat"

  __str__ = __repr__

>>>MyFloat = MyFloatType()
>>>int(MyFloat)
TypeError: expected int, got p

This is one can be worked around by having an __int__ defined. However,

>>>str(MyFloat)
'0.0'
>>>repr(MyFloat)
'MyFloat'


Subclassing longs and ints in a similar way has the correct behaviour.

This is nasty and a blocker for us.

We've raised this as Issue 19675



Glenn & Orestis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081120/d4d21685/attachment.html>

From william at resolversystems.com  Thu Nov 20 14:36:19 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 20 Nov 2008 13:36:19 +0000
Subject: [IronPython] (ironclad) is it possible to get the current
	ScriptEngine?
Message-ID: <492567D3.9060907@resolversystems.com>

Hi all

At the moment, when a user types 'import ironclad', I create a new 
ScriptEngine and set that up to allow .pyd imports; I then abuse 
path_hooks to use the new engine to do the imports, and copy them into 
the original engine's sys.modules. Clearly, this is evil and wrong on 
any number of levels, but so far it's been (just barely) good enough.

However, if I can find out which ScriptEngine is executing the code (so 
I can pass that into the Python25Mapper), I can greatly simplify 
ironclad.py and, hopefully, solve another user's problem (which, I 
believe, is related to sys.path not being shared between the two engines 
(quite rightly so, ofc ;))).

So: is there any way I can get a reference to the executing engine from 
within IronPython code? It feels as if it should be possible, but 
whenever I look into it I end up chasing my tail...

William


From glenn.k.jones+ipy at gmail.com  Thu Nov 20 16:23:23 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Thu, 20 Nov 2008 15:23:23 +0000
Subject: [IronPython] in operator calls __getitem__ on class that has
	__len__ and __iter__ defined
Message-ID: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>

Yet another weirdness, but not a blocker for us:

With this object:

class o(object):
  def __iter__(self):
    print "iter"
    return iter([1, 2, 3])
  def __getitem__(self, index):
    print "getitem"
    return [1, 2, 3][index]
  def __len__(self):
    print "len"
    return 3

CPython:
>>> p = o()
>>> 1 in p
iter
True

IronPython 2 source drop 43741:
>>> p = o()
>>> 1 in p
getitem
True

It looks like CPython is treating it like a sequence and IronPython 2 is
treating it like a dict.

We have worked around this by implementing __contains__

Raised as Issue 19678 on CodePlex.


PS: How can we format code blocks on CodePlex?

Glenn & Orestis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081120/aa873af9/attachment.html>

From dinov at microsoft.com  Thu Nov 20 17:22:35 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 08:22:35 -0800
Subject: [IronPython] (ironclad) is it possible to get the
	current	ScriptEngine?
In-Reply-To: <492567D3.9060907@resolversystems.com>
References: <492567D3.9060907@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>

It's not really possible to get back to the ScriptEngine - but you also probably don't need to.  You probably want to get back to the LanguageContext(PythonContext)/ScriptDomainManager and work with those directly.  ScriptEngine/ScriptRuntime are wrappers around those which expose the friendly API and provide the easy remoting features.

You can get to the LanguageContext via a CodeContext.  You can get a CodeContext by just defining it as the 1st parameter on a .NET method which we'll be calling at some point.

For example our ModuleLoader class for pre-compiled code has a load_module method which receives a CodeContext.  It then uses it to call back into the current PythonContext and create a new module.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Thursday, November 20, 2008 5:36 AM
To: Discussion of IronPython
Subject: [IronPython] (ironclad) is it possible to get the current ScriptEngine?

Hi all

At the moment, when a user types 'import ironclad', I create a new
ScriptEngine and set that up to allow .pyd imports; I then abuse
path_hooks to use the new engine to do the imports, and copy them into
the original engine's sys.modules. Clearly, this is evil and wrong on
any number of levels, but so far it's been (just barely) good enough.

However, if I can find out which ScriptEngine is executing the code (so
I can pass that into the Python25Mapper), I can greatly simplify
ironclad.py and, hopefully, solve another user's problem (which, I
believe, is related to sys.path not being shared between the two engines
(quite rightly so, ofc ;))).

So: is there any way I can get a reference to the executing engine from
within IronPython code? It feels as if it should be possible, but
whenever I look into it I end up chasing my tail...

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


From dinov at microsoft.com  Thu Nov 20 17:30:49 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 08:30:49 -0800
Subject: [IronPython] in operator calls __getitem__ on class that
	has	__len__ and __iter__ defined
In-Reply-To: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>
References: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CF86B@NA-EXMSG-C102.redmond.corp.microsoft.com>

Interesting, the docs would seem to indicate our behavior is correct:

For user-defined classes which do not define __contains__() and do define __getitem__(), x in y is true if and only if there is a non-negative integer index i such that x == y[i], and all lower integer indices do not raise IndexError exception. (If any other exception is raised, it is as if in raised that exception).

If and only if is pretty strong language ?  But we can start looking for __iter__ after looking for __contains__.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Thursday, November 20, 2008 7:23 AM
To: users at lists.ironpython.com
Subject: [IronPython] in operator calls __getitem__ on class that has __len__ and __iter__ defined

Yet another weirdness, but not a blocker for us:

With this object:

class o(object):
  def __iter__(self):
    print "iter"
    return iter([1, 2, 3])
  def __getitem__(self, index):
    print "getitem"
    return [1, 2, 3][index]
  def __len__(self):
    print "len"
    return 3

CPython:
>>> p = o()
>>> 1 in p
iter
True

IronPython 2 source drop 43741:
>>> p = o()
>>> 1 in p
getitem
True

It looks like CPython is treating it like a sequence and IronPython 2 is treating it like a dict.

We have worked around this by implementing __contains__

Raised as Issue 19678 on CodePlex.


PS: How can we format code blocks on CodePlex?

Glenn & Orestis

From fuzzyman at voidspace.org.uk  Thu Nov 20 17:34:18 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 20 Nov 2008 16:34:18 +0000
Subject: [IronPython] in operator calls __getitem__ on class that	has
 __len__ and __iter__ defined
In-Reply-To: <350E7D38B6D819428718949920EC235556486CF86B@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>
	<350E7D38B6D819428718949920EC235556486CF86B@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4925918A.3050708@voidspace.org.uk>

Dino Viehland wrote:
> Interesting, the docs would seem to indicate our behavior is correct:
>
> For user-defined classes which do not define __contains__() and do define __getitem__(), x in y is true if and only if there is a non-negative integer index i such that x == y[i], and all lower integer indices do not raise IndexError exception. (If any other exception is raised, it is as if in raised that exception).
>
> If and only if is pretty strong language ?  But we can start looking for __iter__ after looking for __contains__.
>   

It sounds like a doc bug then.

'in' has different meanings for mapping type containers (in refers to 
keys) and sequences (in refers to values). For a sequence 'in' naturally 
and obviously means 'is a value contained in the sequence', and passing 
the value to __getitem__ clearly gives the wrong behaviour.

For mapping types, passing the value to __getitem__ would be correct - 
unfortunately there is no way to tell the types of containers apart if 
they are pure Python classes (except in Python 2.6 where we have 
Abstract Base Classes). Explicitly implementing __contains__ is always 
better than relying on the fallback.

Michael

> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
> Sent: Thursday, November 20, 2008 7:23 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] in operator calls __getitem__ on class that has __len__ and __iter__ defined
>
> Yet another weirdness, but not a blocker for us:
>
> With this object:
>
> class o(object):
>   def __iter__(self):
>     print "iter"
>     return iter([1, 2, 3])
>   def __getitem__(self, index):
>     print "getitem"
>     return [1, 2, 3][index]
>   def __len__(self):
>     print "len"
>     return 3
>
> CPython:
>   
>>>> p = o()
>>>> 1 in p
>>>>         
> iter
> True
>
> IronPython 2 source drop 43741:
>   
>>>> p = o()
>>>> 1 in p
>>>>         
> getitem
> True
>
> It looks like CPython is treating it like a sequence and IronPython 2 is treating it like a dict.
>
> We have worked around this by implementing __contains__
>
> Raised as Issue 19678 on CodePlex.
>
>
> PS: How can we format code blocks on CodePlex?
>
> Glenn & Orestis
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/



From william at resolversystems.com  Thu Nov 20 18:07:15 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 20 Nov 2008 17:07:15 +0000
Subject: [IronPython] (ironclad) is it possible to get
	the	current	ScriptEngine?
In-Reply-To: <350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <492567D3.9060907@resolversystems.com>
	<350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <49259943.2000108@resolversystems.com>

Thanks Dino -- I'll see what I can do with that :)

Dino Viehland wrote:
> It's not really possible to get back to the ScriptEngine - but you also probably don't need to.  You probably want to get back to the LanguageContext(PythonContext)/ScriptDomainManager and work with those directly.  ScriptEngine/ScriptRuntime are wrappers around those which expose the friendly API and provide the easy remoting features.
>
> You can get to the LanguageContext via a CodeContext.  You can get a CodeContext by just defining it as the 1st parameter on a .NET method which we'll be calling at some point.
>
> For example our ModuleLoader class for pre-compiled code has a load_module method which receives a CodeContext.  It then uses it to call back into the current PythonContext and create a new module.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Thursday, November 20, 2008 5:36 AM
> To: Discussion of IronPython
> Subject: [IronPython] (ironclad) is it possible to get the current ScriptEngine?
>
> Hi all
>
> At the moment, when a user types 'import ironclad', I create a new
> ScriptEngine and set that up to allow .pyd imports; I then abuse
> path_hooks to use the new engine to do the imports, and copy them into
> the original engine's sys.modules. Clearly, this is evil and wrong on
> any number of levels, but so far it's been (just barely) good enough.
>
> However, if I can find out which ScriptEngine is executing the code (so
> I can pass that into the Python25Mapper), I can greatly simplify
> ironclad.py and, hopefully, solve another user's problem (which, I
> believe, is related to sys.path not being shared between the two engines
> (quite rightly so, ofc ;))).
>
> So: is there any way I can get a reference to the executing engine from
> within IronPython code? It feels as if it should be possible, but
> whenever I look into it I end up chasing my tail...
>
> William
> _______________________________________________
> 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
>
>   



From dinov at microsoft.com  Thu Nov 20 18:13:14 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 09:13:14 -0800
Subject: [IronPython] in operator calls __getitem__ on class that
	has	__len__ and __iter__ defined
In-Reply-To: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>
References: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CF8DB@NA-EXMSG-C102.redmond.corp.microsoft.com>

Oh, on the formatting - CodePlex actually preserves the white space it just doesn't display it.  It's annoying but I'm not aware of a way to make it actually display other than clicking Edit which I think only we can do :(.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Thursday, November 20, 2008 7:23 AM
To: users at lists.ironpython.com
Subject: [IronPython] in operator calls __getitem__ on class that has __len__ and __iter__ defined

Yet another weirdness, but not a blocker for us:

With this object:

class o(object):
  def __iter__(self):
    print "iter"
    return iter([1, 2, 3])
  def __getitem__(self, index):
    print "getitem"
    return [1, 2, 3][index]
  def __len__(self):
    print "len"
    return 3

CPython:
>>> p = o()
>>> 1 in p
iter
True

IronPython 2 source drop 43741:
>>> p = o()
>>> 1 in p
getitem
True

It looks like CPython is treating it like a sequence and IronPython 2 is treating it like a dict.

We have worked around this by implementing __contains__

Raised as Issue 19678 on CodePlex.


PS: How can we format code blocks on CodePlex?

Glenn & Orestis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081120/d82b99f2/attachment.html>

From william at resolversystems.com  Thu Nov 20 18:49:42 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 20 Nov 2008 17:49:42 +0000
Subject: [IronPython] (ironclad) is it possible to
	get	the	current	ScriptEngine?
In-Reply-To: <49259943.2000108@resolversystems.com>
References: <492567D3.9060907@resolversystems.com>	<350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49259943.2000108@resolversystems.com>
Message-ID: <4925A336.1010309@resolversystems.com>

It seems I don't actually use the engine for very much, so this sounds 
pretty plausible -- context.SystemState can replace Python.GetSysModule, 
and HostingHelpers.GetLanguageContext goes away entirely :).

However, I can't see any obvious way to create a ScriptScope 
(engine.CreateScope) or a ScriptSource 
(engine.CreateScriptSourceFromString) -- even if I just dupe IronPython 
code, it seems I'll still need an actual PythonEngine to construct them. 
Am I missing something obvious?

William Reade wrote:
> Thanks Dino -- I'll see what I can do with that :)
>
> Dino Viehland wrote:
>> It's not really possible to get back to the ScriptEngine - but you 
>> also probably don't need to.  You probably want to get back to the 
>> LanguageContext(PythonContext)/ScriptDomainManager and work with 
>> those directly.  ScriptEngine/ScriptRuntime are wrappers around those 
>> which expose the friendly API and provide the easy remoting features.
>>
>> You can get to the LanguageContext via a CodeContext.  You can get a 
>> CodeContext by just defining it as the 1st parameter on a .NET method 
>> which we'll be calling at some point.
>>
>> For example our ModuleLoader class for pre-compiled code has a 
>> load_module method which receives a CodeContext.  It then uses it to 
>> call back into the current PythonContext and create a new module.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com 
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Thursday, November 20, 2008 5:36 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] (ironclad) is it possible to get the current 
>> ScriptEngine?
>>
>> Hi all
>>
>> At the moment, when a user types 'import ironclad', I create a new
>> ScriptEngine and set that up to allow .pyd imports; I then abuse
>> path_hooks to use the new engine to do the imports, and copy them into
>> the original engine's sys.modules. Clearly, this is evil and wrong on
>> any number of levels, but so far it's been (just barely) good enough.
>>
>> However, if I can find out which ScriptEngine is executing the code (so
>> I can pass that into the Python25Mapper), I can greatly simplify
>> ironclad.py and, hopefully, solve another user's problem (which, I
>> believe, is related to sys.path not being shared between the two engines
>> (quite rightly so, ofc ;))).
>>
>> So: is there any way I can get a reference to the executing engine from
>> within IronPython code? It feels as if it should be possible, but
>> whenever I look into it I end up chasing my tail...
>>
>> William
>> _______________________________________________
>> 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
>



From dan.eloff at gmail.com  Thu Nov 20 22:20:39 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Thu, 20 Nov 2008 16:20:39 -0500
Subject: [IronPython] More fun with delegates
Message-ID: <4817b6fc0811201320s4e892a10u575bde2ba8dcbdbf@mail.gmail.com>

This is not a blocker, but In RC1 and the 2.1 branch of 43741 the
following happens:

>>> import clr
>>> clr.AddReference('PresentationFramework')
>>> clr.AddReference('WindowsBase')
>>> from System.Windows import Window
>>> d = Window().Dispatcher
>>> def echo(x):
...     print x
...
>>> d.BeginInvoke(echo, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected Delegate, got function
>>> d.BeginInvoke(lambda: echo(2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected Delegate, got function

However, in Silverlight, for some odd reason, it works fine.

>>> from System import Action
>>> def foo(): pass
>>> Action(foo)

Will crash the interpreter/browser. But this will work:

>>> def foo(i):
...     pass
...
>>> from System import Action
>>> Action[int](foo)
<System.Action`1[[System.Int32, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089]] object at
0x000000000000002B [System.Action`1[System.Int32]]>

So a workaround for now is to do:
>>> d.BeginInvoke(Action[object](echo), 2)

-Dan


From srivatsn at microsoft.com  Thu Nov 20 22:33:30 2008
From: srivatsn at microsoft.com (Srivatsn Narayanan)
Date: Thu, 20 Nov 2008 13:33:30 -0800
Subject: [IronPython] More fun with delegates
In-Reply-To: <4817b6fc0811201320s4e892a10u575bde2ba8dcbdbf@mail.gmail.com>
References: <4817b6fc0811201320s4e892a10u575bde2ba8dcbdbf@mail.gmail.com>
Message-ID: <B0F32F33670C5D47BB6D5D315C32CD6621EEC70E5A@NA-EXMSG-C108.redmond.corp.microsoft.com>

Hi Dan,

  The parameterless Action is actually defined in System.Core.dll so you need to reference that. The crash ofcourse needs to be fixed. There is already a bug on that - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19133



-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Thursday, November 20, 2008 1:21 PM
To: Discussion of IronPython
Subject: [IronPython] More fun with delegates

This is not a blocker, but In RC1 and the 2.1 branch of 43741 the
following happens:

>>> import clr
>>> clr.AddReference('PresentationFramework')
>>> clr.AddReference('WindowsBase')
>>> from System.Windows import Window
>>> d = Window().Dispatcher
>>> def echo(x):
...     print x
...
>>> d.BeginInvoke(echo, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected Delegate, got function
>>> d.BeginInvoke(lambda: echo(2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected Delegate, got function

However, in Silverlight, for some odd reason, it works fine.

>>> from System import Action
>>> def foo(): pass
>>> Action(foo)

Will crash the interpreter/browser. But this will work:

>>> def foo(i):
...     pass
...
>>> from System import Action
>>> Action[int](foo)
<System.Action`1[[System.Int32, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089]] object at
0x000000000000002B [System.Action`1[System.Int32]]>

So a workaround for now is to do:
>>> d.BeginInvoke(Action[object](echo), 2)

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



From dinov at microsoft.com  Thu Nov 20 22:45:46 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 13:45:46 -0800
Subject: [IronPython] (ironclad) is it possible
	to	get	the	current	ScriptEngine?
In-Reply-To: <4925A336.1010309@resolversystems.com>
References: <492567D3.9060907@resolversystems.com>
	<350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49259943.2000108@resolversystems.com>
	<4925A336.1010309@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CFB3E@NA-EXMSG-C102.redmond.corp.microsoft.com>

Just create Scope objects instead of ScriptScope's.  Scope's are what we actually expose as modules directly to Python programs.  Generally only hosting APIs see the ScriptScope's.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Thursday, November 20, 2008 9:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] (ironclad) is it possible to get the current ScriptEngine?

It seems I don't actually use the engine for very much, so this sounds
pretty plausible -- context.SystemState can replace Python.GetSysModule,
and HostingHelpers.GetLanguageContext goes away entirely :).

However, I can't see any obvious way to create a ScriptScope
(engine.CreateScope) or a ScriptSource
(engine.CreateScriptSourceFromString) -- even if I just dupe IronPython
code, it seems I'll still need an actual PythonEngine to construct them.
Am I missing something obvious?

William Reade wrote:
> Thanks Dino -- I'll see what I can do with that :)
>
> Dino Viehland wrote:
>> It's not really possible to get back to the ScriptEngine - but you
>> also probably don't need to.  You probably want to get back to the
>> LanguageContext(PythonContext)/ScriptDomainManager and work with
>> those directly.  ScriptEngine/ScriptRuntime are wrappers around those
>> which expose the friendly API and provide the easy remoting features.
>>
>> You can get to the LanguageContext via a CodeContext.  You can get a
>> CodeContext by just defining it as the 1st parameter on a .NET method
>> which we'll be calling at some point.
>>
>> For example our ModuleLoader class for pre-compiled code has a
>> load_module method which receives a CodeContext.  It then uses it to
>> call back into the current PythonContext and create a new module.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Thursday, November 20, 2008 5:36 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] (ironclad) is it possible to get the current
>> ScriptEngine?
>>
>> Hi all
>>
>> At the moment, when a user types 'import ironclad', I create a new
>> ScriptEngine and set that up to allow .pyd imports; I then abuse
>> path_hooks to use the new engine to do the imports, and copy them into
>> the original engine's sys.modules. Clearly, this is evil and wrong on
>> any number of levels, but so far it's been (just barely) good enough.
>>
>> However, if I can find out which ScriptEngine is executing the code (so
>> I can pass that into the Python25Mapper), I can greatly simplify
>> ironclad.py and, hopefully, solve another user's problem (which, I
>> believe, is related to sys.path not being shared between the two engines
>> (quite rightly so, ofc ;))).
>>
>> So: is there any way I can get a reference to the executing engine from
>> within IronPython code? It feels as if it should be possible, but
>> whenever I look into it I end up chasing my tail...
>>
>> William
>> _______________________________________________
>> 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


From fuzzyman at voidspace.org.uk  Fri Nov 21 00:34:11 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 20 Nov 2008 23:34:11 +0000
Subject: [IronPython] in operator calls __getitem__ on class that	has
 __len__ and __iter__ defined
In-Reply-To: <4925918A.3050708@voidspace.org.uk>
References: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>	<350E7D38B6D819428718949920EC235556486CF86B@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4925918A.3050708@voidspace.org.uk>
Message-ID: <4925F3F3.6080003@voidspace.org.uk>

Michael Foord wrote:
> Dino Viehland wrote:
>> Interesting, the docs would seem to indicate our behavior is correct:
>>
>> For user-defined classes which do not define __contains__() and do 
>> define __getitem__(), x in y is true if and only if there is a 
>> non-negative integer index i such that x == y[i], and all lower 
>> integer indices do not raise IndexError exception. (If any other 
>> exception is raised, it is as if in raised that exception).
>>
>> If and only if is pretty strong language ?  But we can start looking 
>> for __iter__ after looking for __contains__.
>>   
>

Wait. The definition above defines the conditions for 'in' with 
sequences (integer indexes) when __getitem__ is defined and __contains__ 
isn't. And in fact, the value 'x' is not passed to __getitem__ at all - 
but is *returned* from __getiem__ for an integer index 'i'. Passing 'x' 
to __getitem__ is definitely incorrect. :-)

If a class defines __getitem__ and neither __iter__ nor __contains__ 
then Python will start calling __getitem__ with integers until x is 
returned or an IndexError is raised.

Michael

> It sounds like a doc bug then.
>
> 'in' has different meanings for mapping type containers (in refers to 
> keys) and sequences (in refers to values). For a sequence 'in' 
> naturally and obviously means 'is a value contained in the sequence', 
> and passing the value to __getitem__ clearly gives the wrong behaviour.
>
> For mapping types, passing the value to __getitem__ would be correct - 
> unfortunately there is no way to tell the types of containers apart if 
> they are pure Python classes (except in Python 2.6 where we have 
> Abstract Base Classes). Explicitly implementing __contains__ is always 
> better than relying on the fallback.
>
> Michael
>
>> From: users-bounces at lists.ironpython.com 
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
>> Sent: Thursday, November 20, 2008 7:23 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] in operator calls __getitem__ on class that has 
>> __len__ and __iter__ defined
>>
>> Yet another weirdness, but not a blocker for us:
>>
>> With this object:
>>
>> class o(object):
>>   def __iter__(self):
>>     print "iter"
>>     return iter([1, 2, 3])
>>   def __getitem__(self, index):
>>     print "getitem"
>>     return [1, 2, 3][index]
>>   def __len__(self):
>>     print "len"
>>     return 3
>>
>> CPython:
>>  
>>>>> p = o()
>>>>> 1 in p
>>>>>         
>> iter
>> True
>>
>> IronPython 2 source drop 43741:
>>  
>>>>> p = o()
>>>>> 1 in p
>>>>>         
>> getitem
>> True
>>
>> It looks like CPython is treating it like a sequence and IronPython 2 
>> is treating it like a dict.
>>
>> We have worked around this by implementing __contains__
>>
>> Raised as Issue 19678 on CodePlex.
>>
>>
>> PS: How can we format code blocks on CodePlex?
>>
>> Glenn & Orestis
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>   
>
>


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From dinov at microsoft.com  Fri Nov 21 00:43:58 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 15:43:58 -0800
Subject: [IronPython] in operator calls __getitem__ on class that	has
 __len__ and __iter__ defined
In-Reply-To: <4925F3F3.6080003@voidspace.org.uk>
References: <2679f6510811200723t1f2a397ete28454fdec98c121@mail.gmail.com>
	<350E7D38B6D819428718949920EC235556486CF86B@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4925918A.3050708@voidspace.org.uk> <4925F3F3.6080003@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC235556486CFBF4@NA-EXMSG-C102.redmond.corp.microsoft.com>

Which is exactly what we're doing here.  If you change your __getitem__ impl to return [0, 1, 2, 3][index] you'll see we call __getitem__ twice.  We're just looking for __getitem__ before __iter__.  Obviously CPython is doing it in the other order so we just need to switch that around.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, November 20, 2008 3:34 PM
To: Discussion of IronPython
Subject: Re: [IronPython] in operator calls __getitem__ on class that has __len__ and __iter__ defined

Michael Foord wrote:
> Dino Viehland wrote:
>> Interesting, the docs would seem to indicate our behavior is correct:
>>
>> For user-defined classes which do not define __contains__() and do
>> define __getitem__(), x in y is true if and only if there is a
>> non-negative integer index i such that x == y[i], and all lower
>> integer indices do not raise IndexError exception. (If any other
>> exception is raised, it is as if in raised that exception).
>>
>> If and only if is pretty strong language ?  But we can start looking
>> for __iter__ after looking for __contains__.
>>
>

Wait. The definition above defines the conditions for 'in' with
sequences (integer indexes) when __getitem__ is defined and __contains__
isn't. And in fact, the value 'x' is not passed to __getitem__ at all -
but is *returned* from __getiem__ for an integer index 'i'. Passing 'x'
to __getitem__ is definitely incorrect. :-)

If a class defines __getitem__ and neither __iter__ nor __contains__
then Python will start calling __getitem__ with integers until x is
returned or an IndexError is raised.

Michael

> It sounds like a doc bug then.
>
> 'in' has different meanings for mapping type containers (in refers to
> keys) and sequences (in refers to values). For a sequence 'in'
> naturally and obviously means 'is a value contained in the sequence',
> and passing the value to __getitem__ clearly gives the wrong behaviour.
>
> For mapping types, passing the value to __getitem__ would be correct -
> unfortunately there is no way to tell the types of containers apart if
> they are pure Python classes (except in Python 2.6 where we have
> Abstract Base Classes). Explicitly implementing __contains__ is always
> better than relying on the fallback.
>
> Michael
>
>> From: users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
>> Sent: Thursday, November 20, 2008 7:23 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] in operator calls __getitem__ on class that has
>> __len__ and __iter__ defined
>>
>> Yet another weirdness, but not a blocker for us:
>>
>> With this object:
>>
>> class o(object):
>>   def __iter__(self):
>>     print "iter"
>>     return iter([1, 2, 3])
>>   def __getitem__(self, index):
>>     print "getitem"
>>     return [1, 2, 3][index]
>>   def __len__(self):
>>     print "len"
>>     return 3
>>
>> CPython:
>>
>>>>> p = o()
>>>>> 1 in p
>>>>>
>> iter
>> True
>>
>> IronPython 2 source drop 43741:
>>
>>>>> p = o()
>>>>> 1 in p
>>>>>
>> getitem
>> True
>>
>> It looks like CPython is treating it like a sequence and IronPython 2
>> is treating it like a dict.
>>
>> We have worked around this by implementing __contains__
>>
>> Raised as Issue 19678 on CodePlex.
>>
>>
>> PS: How can we format code blocks on CodePlex?
>>
>> Glenn & Orestis
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


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

From dinov at microsoft.com  Fri Nov 21 05:11:34 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 20:11:34 -0800
Subject: [IronPython] (ironclad) is it possible
	to	get	the	current	ScriptEngine?
In-Reply-To: <4925A336.1010309@resolversystems.com>
References: <492567D3.9060907@resolversystems.com>
	<350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49259943.2000108@resolversystems.com>
	<4925A336.1010309@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CFC89@NA-EXMSG-C102.redmond.corp.microsoft.com>

Oh, and instead of ScriptSource you can use SourceUnit.  You might find there's too much stuff marked internal w/ SourceUnit so any issues you run into here would be interesting to hear.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
Sent: Thursday, November 20, 2008 9:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] (ironclad) is it possible to get the current ScriptEngine?

It seems I don't actually use the engine for very much, so this sounds
pretty plausible -- context.SystemState can replace Python.GetSysModule,
and HostingHelpers.GetLanguageContext goes away entirely :).

However, I can't see any obvious way to create a ScriptScope
(engine.CreateScope) or a ScriptSource
(engine.CreateScriptSourceFromString) -- even if I just dupe IronPython
code, it seems I'll still need an actual PythonEngine to construct them.
Am I missing something obvious?

William Reade wrote:
> Thanks Dino -- I'll see what I can do with that :)
>
> Dino Viehland wrote:
>> It's not really possible to get back to the ScriptEngine - but you
>> also probably don't need to.  You probably want to get back to the
>> LanguageContext(PythonContext)/ScriptDomainManager and work with
>> those directly.  ScriptEngine/ScriptRuntime are wrappers around those
>> which expose the friendly API and provide the easy remoting features.
>>
>> You can get to the LanguageContext via a CodeContext.  You can get a
>> CodeContext by just defining it as the 1st parameter on a .NET method
>> which we'll be calling at some point.
>>
>> For example our ModuleLoader class for pre-compiled code has a
>> load_module method which receives a CodeContext.  It then uses it to
>> call back into the current PythonContext and create a new module.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Thursday, November 20, 2008 5:36 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] (ironclad) is it possible to get the current
>> ScriptEngine?
>>
>> Hi all
>>
>> At the moment, when a user types 'import ironclad', I create a new
>> ScriptEngine and set that up to allow .pyd imports; I then abuse
>> path_hooks to use the new engine to do the imports, and copy them into
>> the original engine's sys.modules. Clearly, this is evil and wrong on
>> any number of levels, but so far it's been (just barely) good enough.
>>
>> However, if I can find out which ScriptEngine is executing the code (so
>> I can pass that into the Python25Mapper), I can greatly simplify
>> ironclad.py and, hopefully, solve another user's problem (which, I
>> believe, is related to sys.path not being shared between the two engines
>> (quite rightly so, ofc ;))).
>>
>> So: is there any way I can get a reference to the executing engine from
>> within IronPython code? It feels as if it should be possible, but
>> whenever I look into it I end up chasing my tail...
>>
>> William
>> _______________________________________________
>> 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


From dan.eloff at gmail.com  Fri Nov 21 05:12:24 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Thu, 20 Nov 2008 23:12:24 -0500
Subject: [IronPython] More fun with delegates
In-Reply-To: <B0F32F33670C5D47BB6D5D315C32CD6621EEC70E5A@NA-EXMSG-C108.redmond.corp.microsoft.com>
References: <4817b6fc0811201320s4e892a10u575bde2ba8dcbdbf@mail.gmail.com>
	<B0F32F33670C5D47BB6D5D315C32CD6621EEC70E5A@NA-EXMSG-C108.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0811202012n4e61811av408b40cd658fb994@mail.gmail.com>

On Thu, Nov 20, 2008 at 4:33 PM, Srivatsn Narayanan
<srivatsn at microsoft.com> wrote:
> Hi Dan,
>
>  The parameterless Action is actually defined in System.Core.dll so you need to reference that. The crash ofcourse needs to be fixed. There is already a bug on that - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19133
>

Ok, I understand that now. But what about this?

>>> def echo(x):
...     print x
...
>>> d.BeginInvoke(echo, 2)
TypeError: expected Delegate, got function

It works fine on Silverlight.

Thanks,
-Dan


From dinov at microsoft.com  Fri Nov 21 05:21:33 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 20 Nov 2008 20:21:33 -0800
Subject: [IronPython] More fun with delegates
In-Reply-To: <4817b6fc0811202012n4e61811av408b40cd658fb994@mail.gmail.com>
References: <4817b6fc0811201320s4e892a10u575bde2ba8dcbdbf@mail.gmail.com>
	<B0F32F33670C5D47BB6D5D315C32CD6621EEC70E5A@NA-EXMSG-C108.redmond.corp.microsoft.com>
	<4817b6fc0811202012n4e61811av408b40cd658fb994@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CFC8F@NA-EXMSG-C102.redmond.corp.microsoft.com>

System.Windows.Threading.Dispatcher.BeginInvoke in Silverlight has an overload which takes a System.Action.  In .NET 3.5 it seems to only have overloads which take Delegate.  So on the desktop CLR we don't have any idea of what type of delegate to convert it to vs. Silverlight we know to go to Action.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Thursday, November 20, 2008 8:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] More fun with delegates

On Thu, Nov 20, 2008 at 4:33 PM, Srivatsn Narayanan
<srivatsn at microsoft.com> wrote:
> Hi Dan,
>
>  The parameterless Action is actually defined in System.Core.dll so you need to reference that. The crash ofcourse needs to be fixed. There is already a bug on that - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19133
>

Ok, I understand that now. But what about this?

>>> def echo(x):
...     print x
...
>>> d.BeginInvoke(echo, 2)
TypeError: expected Delegate, got function

It works fine on Silverlight.

Thanks,
-Dan
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From orestis at resolversystems.com  Fri Nov 21 14:24:03 2008
From: orestis at resolversystems.com (Orestis Markou)
Date: Fri, 21 Nov 2008 13:24:03 +0000
Subject: [IronPython] SystemExitException ?
Message-ID: <4926B673.5000007@resolversystems.com>

Hello,

In Resolver, we have our own RSIronPython.exe that sets up the 
environment (PATH and other things) and executes a program. It's not 
interactive - just a wrapper aroung ExecuteProgram, really.

We used to do this:

try
{
     ScriptSource source = 
engine.CreateScriptSourceFromFile(Path.Combine(currentDir, 
(string)args[0]));
     source.ExecuteProgram();
}
catch (SystemExitException e)
{
     object o;
     return e.GetExitCode(out o);
}
catch (Exception e)
{
     ExceptionOperations eo = engine.GetService<ExceptionOperations>();
     Console.Write(eo.FormatException(e));
     return 1;
}
return 0;

But then we realised that we always returned 0, because 
SystemExitException was never raised, even if a PythonScript did an 
exlicit sys.exit or raised SystemExit. So we now return the result of 
source.ExecuteProgram().

I'm just wondering if we should care about SystemExitException (a quick 
grep of the source is indicating that it's only used in 
PythonCommandLine), or if it's handled for us at a lower level.

Thanks,
Orestis
-- 
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
orestis at resolversystems.com
+44 (0) 20 7253 6372



From Tomas.Matousek at microsoft.com  Fri Nov 21 17:31:27 2008
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Fri, 21 Nov 2008 08:31:27 -0800
Subject: [IronPython] SystemExitException ?
In-Reply-To: <4926B673.5000007@resolversystems.com>
References: <4926B673.5000007@resolversystems.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B1FD38269@NA-EXMSG-C112.redmond.corp.microsoft.com>

It's handled for you in ExecuteProgram and the exit code is returned. It's this handling that makes the difference between Execute and ExecuteProgram. ExecuteProgram is designed to process any program exit mechanism that the language has so that the host doesn't need to care and could be language independent.

Tomas

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou
Sent: Friday, November 21, 2008 5:24 AM
To: Discussion of IronPython
Subject: [IronPython] SystemExitException ?

Hello,

In Resolver, we have our own RSIronPython.exe that sets up the
environment (PATH and other things) and executes a program. It's not
interactive - just a wrapper aroung ExecuteProgram, really.

We used to do this:

try
{
     ScriptSource source =
engine.CreateScriptSourceFromFile(Path.Combine(currentDir,
(string)args[0]));
     source.ExecuteProgram();
}
catch (SystemExitException e)
{
     object o;
     return e.GetExitCode(out o);
}
catch (Exception e)
{
     ExceptionOperations eo = engine.GetService<ExceptionOperations>();
     Console.Write(eo.FormatException(e));
     return 1;
}
return 0;

But then we realised that we always returned 0, because
SystemExitException was never raised, even if a PythonScript did an
exlicit sys.exit or raised SystemExit. So we now return the result of
source.ExecuteProgram().

I'm just wondering if we should care about SystemExitException (a quick
grep of the source is indicating that it's only used in
PythonCommandLine), or if it's handled for us at a lower level.

Thanks,
Orestis
--
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
orestis at resolversystems.com
+44 (0) 20 7253 6372

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



From william at resolversystems.com  Fri Nov 21 18:42:07 2008
From: william at resolversystems.com (William Reade)
Date: Fri, 21 Nov 2008 17:42:07 +0000
Subject: [IronPython] (ironclad) is it
	possible	to	get	the	current	ScriptEngine?
In-Reply-To: <350E7D38B6D819428718949920EC235556486CFC89@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <492567D3.9060907@resolversystems.com>	<350E7D38B6D819428718949920EC235556486CF863@NA-EXMSG-C102.redmond.corp.microsoft.com>	<49259943.2000108@resolversystems.com>	<4925A336.1010309@resolversystems.com>
	<350E7D38B6D819428718949920EC235556486CFC89@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4926F2EF.1050503@resolversystems.com>

Thanks again Dino: it's all working and checked in, and it was all much 
easier than I expected. No problems with SourceUnits, but I don't try to 
do anything remotely complex with them, so others' mileage may vary.

Dino Viehland wrote:
> Oh, and instead of ScriptSource you can use SourceUnit.  You might find there's too much stuff marked internal w/ SourceUnit so any issues you run into here would be interesting to hear.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Thursday, November 20, 2008 9:50 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] (ironclad) is it possible to get the current ScriptEngine?
>
> It seems I don't actually use the engine for very much, so this sounds
> pretty plausible -- context.SystemState can replace Python.GetSysModule,
> and HostingHelpers.GetLanguageContext goes away entirely :).
>
> However, I can't see any obvious way to create a ScriptScope
> (engine.CreateScope) or a ScriptSource
> (engine.CreateScriptSourceFromString) -- even if I just dupe IronPython
> code, it seems I'll still need an actual PythonEngine to construct them.
> Am I missing something obvious?
>
> William Reade wrote:
>   
>> Thanks Dino -- I'll see what I can do with that :)
>>
>> Dino Viehland wrote:
>>     
>>> It's not really possible to get back to the ScriptEngine - but you
>>> also probably don't need to.  You probably want to get back to the
>>> LanguageContext(PythonContext)/ScriptDomainManager and work with
>>> those directly.  ScriptEngine/ScriptRuntime are wrappers around those
>>> which expose the friendly API and provide the easy remoting features.
>>>
>>> You can get to the LanguageContext via a CodeContext.  You can get a
>>> CodeContext by just defining it as the 1st parameter on a .NET method
>>> which we'll be calling at some point.
>>>
>>> For example our ModuleLoader class for pre-compiled code has a
>>> load_module method which receives a CodeContext.  It then uses it to
>>> call back into the current PythonContext and create a new module.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com
>>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of William Reade
>>> Sent: Thursday, November 20, 2008 5:36 AM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] (ironclad) is it possible to get the current
>>> ScriptEngine?
>>>
>>> Hi all
>>>
>>> At the moment, when a user types 'import ironclad', I create a new
>>> ScriptEngine and set that up to allow .pyd imports; I then abuse
>>> path_hooks to use the new engine to do the imports, and copy them into
>>> the original engine's sys.modules. Clearly, this is evil and wrong on
>>> any number of levels, but so far it's been (just barely) good enough.
>>>
>>> However, if I can find out which ScriptEngine is executing the code (so
>>> I can pass that into the Python25Mapper), I can greatly simplify
>>> ironclad.py and, hopefully, solve another user's problem (which, I
>>> believe, is related to sys.path not being shared between the two engines
>>> (quite rightly so, ofc ;))).
>>>
>>> So: is there any way I can get a reference to the executing engine from
>>> within IronPython code? It feels as if it should be possible, but
>>> whenever I look into it I end up chasing my tail...
>>>
>>> William
>>> _______________________________________________
>>> 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
>
>   



From orestis at resolversystems.com  Fri Nov 21 19:07:47 2008
From: orestis at resolversystems.com (Orestis Markou)
Date: Fri, 21 Nov 2008 18:07:47 +0000
Subject: [IronPython] SystemExitException ?
In-Reply-To: <F58FE69873E2D5459B72C347DE1582412B1FD38269@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <4926B673.5000007@resolversystems.com>
	<F58FE69873E2D5459B72C347DE1582412B1FD38269@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <4926F8F3.4000307@resolversystems.com>

Thanks! So we'll remove SystemExitException handling.

Tomas Matousek wrote:
> It's handled for you in ExecuteProgram and the exit code is returned. It's this handling that makes the difference between Execute and ExecuteProgram. ExecuteProgram is designed to process any program exit mechanism that the language has so that the host doesn't need to care and could be language independent.
> 
> Tomas
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou
> Sent: Friday, November 21, 2008 5:24 AM
> To: Discussion of IronPython
> Subject: [IronPython] SystemExitException ?
> 
> Hello,
> 
> In Resolver, we have our own RSIronPython.exe that sets up the
> environment (PATH and other things) and executes a program. It's not
> interactive - just a wrapper aroung ExecuteProgram, really.
> 
> We used to do this:
> 
> try
> {
>      ScriptSource source =
> engine.CreateScriptSourceFromFile(Path.Combine(currentDir,
> (string)args[0]));
>      source.ExecuteProgram();
> }
> catch (SystemExitException e)
> {
>      object o;
>      return e.GetExitCode(out o);
> }
> catch (Exception e)
> {
>      ExceptionOperations eo = engine.GetService<ExceptionOperations>();
>      Console.Write(eo.FormatException(e));
>      return 1;
> }
> return 0;
> 
> But then we realised that we always returned 0, because
> SystemExitException was never raised, even if a PythonScript did an
> exlicit sys.exit or raised SystemExit. So we now return the result of
> source.ExecuteProgram().
> 
> I'm just wondering if we should care about SystemExitException (a quick
> grep of the source is indicating that it's only used in
> PythonCommandLine), or if it's handled for us at a lower level.
> 
> Thanks,
> Orestis
> --
> Orestis Markou
> Software Engineer,
> Resolver Systems Ltd.
> orestis at resolversystems.com
> +44 (0) 20 7253 6372
> 
> _______________________________________________
> 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

-- 
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
orestis at resolversystems.com
+44 (0) 20 7253 6372



From dinov at microsoft.com  Fri Nov 21 19:52:43 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 21 Nov 2008 10:52:43 -0800
Subject: [IronPython] Blocker: subclasses of float have trouble with
 __int__	and __str__
In-Reply-To: <2679f6510811200433q1822466at5b45d2c4bddd88d8@mail.gmail.com>
References: <2679f6510811200433q1822466at5b45d2c4bddd88d8@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235556486CFE4F@NA-EXMSG-C102.redmond.corp.microsoft.com>

We're going to fix this bug a couple of others (in addition to the couple fixed in the current sources) and release an RC2.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Thursday, November 20, 2008 4:33 AM
To: users at lists.ironpython.com
Subject: [IronPython] Blocker: subclasses of float have trouble with __int__ and __str__

Hello guys,

On the latest code drop (43741) it seems that something is broken in subclasses of floats.

class MyFloatType(float):
  def __new__(cls):
    return float.__new__(cls, 0.0)

  def __repr__(self):
    return "MyFloat"

  __str__ = __repr__

>>>MyFloat = MyFloatType()
>>>int(MyFloat)
TypeError: expected int, got p

This is one can be worked around by having an __int__ defined. However,

>>>str(MyFloat)
'0.0'
>>>repr(MyFloat)
'MyFloat'


Subclassing longs and ints in a similar way has the correct behaviour.

This is nasty and a blocker for us.

We've raised this as Issue 19675



Glenn & Orestis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081121/d29a4b99/attachment.html>

From dan.eloff at gmail.com  Sat Nov 22 04:01:33 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Fri, 21 Nov 2008 22:01:33 -0500
Subject: [IronPython] Importing in a background thread
Message-ID: <4817b6fc0811211901g5936be72vcd44a624cc2a0725@mail.gmail.com>

I'm curious why importing in a background thread fails completely in
Silverlight (well anything builtin and anything already loaded works).
There seems to be many ways of hacking together a crude working import
function using exec, imp, or the hosting api. This would lead me to
believe that there's nothing blocking import from working in threads
on Silverlight.

I've been hacking all day with Kamil's parallel importer, and using
some crude hacks, I've managed to get quite far with it. Most every
obstacle being an incompatibility between my import function and
Python import semantics (which are not simple, especially with regard
to nested packages!) So I've given up for now, but I'd like to be able
to revisit this later if __import__ works. There seems to be no other
optimization I can do that would give as much speedup to load time.

-Dan


From dinov at microsoft.com  Sat Nov 22 04:09:44 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 21 Nov 2008 19:09:44 -0800
Subject: [IronPython] Importing in a background thread
In-Reply-To: <4817b6fc0811211901g5936be72vcd44a624cc2a0725@mail.gmail.com>
References: <4817b6fc0811211901g5936be72vcd44a624cc2a0725@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235556486D00BA@NA-EXMSG-C102.redmond.corp.microsoft.com>

If you're getting crazy and are willing to experiment you could also look at IL rewriting compiled modules so they target Silverlight.  In theory it's just updating what assembly name we're targeting.

Maybe I've just not been following the Silverlight threads close enough but what do you mean by "if __import__ works"?  And how does importing in a background thread fail?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Friday, November 21, 2008 7:02 PM
To: Discussion of IronPython
Subject: [IronPython] Importing in a background thread

I'm curious why importing in a background thread fails completely in
Silverlight (well anything builtin and anything already loaded works).
There seems to be many ways of hacking together a crude working import
function using exec, imp, or the hosting api. This would lead me to
believe that there's nothing blocking import from working in threads
on Silverlight.

I've been hacking all day with Kamil's parallel importer, and using
some crude hacks, I've managed to get quite far with it. Most every
obstacle being an incompatibility between my import function and
Python import semantics (which are not simple, especially with regard
to nested packages!) So I've given up for now, but I'd like to be able
to revisit this later if __import__ works. There seems to be no other
optimization I can do that would give as much speedup to load time.

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


From dan.eloff at gmail.com  Sat Nov 22 17:00:33 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Sat, 22 Nov 2008 11:00:33 -0500
Subject: [IronPython] Importing in a background thread
In-Reply-To: <350E7D38B6D819428718949920EC235556486D00BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4817b6fc0811211901g5936be72vcd44a624cc2a0725@mail.gmail.com>
	<350E7D38B6D819428718949920EC235556486D00BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0811220800u796d00aer9046e0e08c55ce6b@mail.gmail.com>

On Fri, Nov 21, 2008 at 10:09 PM, Dino Viehland <dinov at microsoft.com> wrote:
> If you're getting crazy and are willing to experiment you could also look at IL rewriting compiled modules so they target Silverlight.  In theory it's just updating what assembly name we're targeting.

I've been seriously considering that. Better still is if I can do the
parallel import optimization on top of compiled modules.

> Maybe I've just not been following the Silverlight threads close enough but what do you mean by "if __import__ works"?  And how does importing in a background thread fail?

Here's a look at the problem in the soon to be released 0.6 version of
SilverShell:

IronPython 2.0 (2.0.5.0) on SILVERLIGHT (.NET 2.0.31005.0)
Switching execution to background thread.
>>> import datetime # builtins work
>>> import a
ImportError: No module named a
>>> __import__('a')
ImportError: No module named a
Switching execution to main user-interface thread.
>>> import a # works
Switching execution to background thread.
>>> import a # works now

There is no problem when running this on the desktop version of SilverShell.

IronPython 2.0 (2.0.0.0) on CLI (.NET 2.0.50727.3053)
Switching execution to background thread.
>>> import datetime
>>> import a

This does go through exec or eval, but the problem exists when run
without that as well. This is in RC1, I haven't tested anything newer
against this problem.

-Dan


From jdhardy at gmail.com  Sat Nov 22 19:33:54 2008
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sat, 22 Nov 2008 11:33:54 -0700
Subject: [IronPython] [Hosting] Cannot convert callable class to delegate
Message-ID: <ea89d0e50811221033v9409e07l25868ebccbdcccdc@mail.gmail.com>

Hi,
Attempting to convert a class with a __call__() member to a delagte
causes an ArgumentNullException; presumably it should create a
delegate, as it is a valid callable object. It can be worked around be
using a function that forwards to the class, but it's an annoyance to
have to do that.

I have opened #19724
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19724);
I mention it here because I would really like to see it fixed for 2.0.

-Jeff


From Jimmy.Schementi at microsoft.com  Sun Nov 23 00:40:54 2008
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Sat, 22 Nov 2008 15:40:54 -0800
Subject: [IronPython] Importing in a background thread
In-Reply-To: <4817b6fc0811220800u796d00aer9046e0e08c55ce6b@mail.gmail.com>
References: <4817b6fc0811211901g5936be72vcd44a624cc2a0725@mail.gmail.com>
	<350E7D38B6D819428718949920EC235556486D00BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811220800u796d00aer9046e0e08c55ce6b@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8BEF883@NA-EXMSG-C116.redmond.corp.microsoft.com>

Is it a PAL issue? Are you using the BrowserPAL: http://github.com/jschementi/agdlr/tree/master/src/Microsoft.Scripting.Silverlight/BrowserPAL.cs:

public override bool FileExists(string path) {
    if (!DynamicApplication.InUIThread) {
        return false; // Application.GetResourceStream will throw if called from a non-UI thread
    }
    return Package.GetFile(path) != null;
}

When Microsoft.Scripting.Silverlight was written, accessing the XAP from a non-UI thread threw. I don't believe that limitation is there anymore. If this is what's blocking you, feel free to try getting it to work, and send me a pull request when you've got it working.

~js

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dan Eloff
> Sent: Saturday, November 22, 2008 8:01 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Importing in a background thread
>
> On Fri, Nov 21, 2008 at 10:09 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
> > If you're getting crazy and are willing to experiment you could also
> look at IL rewriting compiled modules so they target Silverlight.  In
> theory it's just updating what assembly name we're targeting.
>
> I've been seriously considering that. Better still is if I can do the
> parallel import optimization on top of compiled modules.
>
> > Maybe I've just not been following the Silverlight threads close
> enough but what do you mean by "if __import__ works"?  And how does
> importing in a background thread fail?
>
> Here's a look at the problem in the soon to be released 0.6 version of
> SilverShell:
>
> IronPython 2.0 (2.0.5.0) on SILVERLIGHT (.NET 2.0.31005.0)
> Switching execution to background thread.
> >>> import datetime # builtins work
> >>> import a
> ImportError: No module named a
> >>> __import__('a')
> ImportError: No module named a
> Switching execution to main user-interface thread.
> >>> import a # works
> Switching execution to background thread.
> >>> import a # works now
>
> There is no problem when running this on the desktop version of
> SilverShell.
>
> IronPython 2.0 (2.0.0.0) on CLI (.NET 2.0.50727.3053)
> Switching execution to background thread.
> >>> import datetime
> >>> import a
>
> This does go through exec or eval, but the problem exists when run
> without that as well. This is in RC1, I haven't tested anything newer
> against this problem.
>
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From sidnei.da.silva at gmail.com  Sun Nov 23 23:06:58 2008
From: sidnei.da.silva at gmail.com (Sidnei da Silva)
Date: Sun, 23 Nov 2008 20:06:58 -0200
Subject: [IronPython] Fwd: Code import ironpython/trunk status: Reviewed
In-Reply-To: <20081123205920.19277.56858.launchpad@gandwana.canonical.com>
References: <20081123205920.19277.56858.launchpad@gandwana.canonical.com>
Message-ID: <a7a2b76b0811231406g594cdd00l174ddd23aa81c776@mail.gmail.com>

Great news, for anyone intending to use Bazaar to develop IronPython.

---------- Forwarded message ----------
From: Michael Hudson <michael.hudson at canonical.com>
Date: Sun, Nov 23, 2008 at 6:59 PM
Subject: Code import ironpython/trunk status: Reviewed
To: sidnei.da.silva at gmail.com


Hello,

The import has been approved and an import will start shortly.

--
https://code.edge.launchpad.net/~vcs-imports/ironpython/trunk
You are receiving this email as you are subscribed to the branch.
To unsubscribe from this branch go to
https://code.edge.launchpad.net/~vcs-imports/ironpython/trunk/+edit-subscription.



-- 
Sidnei da Silva
Enfold Systems
http://enfoldsystems.com
Fax +1 832 201 8856
Office +1 713 942 2377 Ext 214
Skype zopedc


From fuzzyman at voidspace.org.uk  Mon Nov 24 00:38:20 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 23 Nov 2008 23:38:20 +0000
Subject: [IronPython] Fwd: Code import ironpython/trunk status: Reviewed
In-Reply-To: <a7a2b76b0811231406g594cdd00l174ddd23aa81c776@mail.gmail.com>
References: <20081123205920.19277.56858.launchpad@gandwana.canonical.com>
	<a7a2b76b0811231406g594cdd00l174ddd23aa81c776@mail.gmail.com>
Message-ID: <4929E96C.1040807@voidspace.org.uk>

Sidnei da Silva wrote:
> Great news, for anyone intending to use Bazaar to develop IronPython.
>   

This is great news.

Michael

> ---------- Forwarded message ----------
> From: Michael Hudson <michael.hudson at canonical.com>
> Date: Sun, Nov 23, 2008 at 6:59 PM
> Subject: Code import ironpython/trunk status: Reviewed
> To: sidnei.da.silva at gmail.com
>
>
> Hello,
>
> The import has been approved and an import will start shortly.
>
> --
> https://code.edge.launchpad.net/~vcs-imports/ironpython/trunk
> You are receiving this email as you are subscribed to the branch.
> To unsubscribe from this branch go to
> https://code.edge.launchpad.net/~vcs-imports/ironpython/trunk/+edit-subscription.
>
>
>
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From kar at musc.edu  Mon Nov 24 23:03:05 2008
From: kar at musc.edu (Kar, Sujit)
Date: Mon, 24 Nov 2008 17:03:05 -0500
Subject: [IronPython] [Hosting] Cannot convert callable class to delegate
Message-ID: <C3C47765BDE06740BD2E48C88EBB2EE2817C2D58A7@EVS5.clinlan.local>



----- Original Message -----
From: users-bounces at lists.ironpython.com <users-bounces at lists.ironpython.com>
To: Discussion of IronPython <users at lists.ironpython.com>
Sent: Sat Nov 22 13:33:54 2008
Subject: [IronPython] [Hosting] Cannot convert callable class to delegate

Hi,
Attempting to convert a class with a __call__() member to a delagte
causes an ArgumentNullException; presumably it should create a
delegate, as it is a valid callable object. It can be worked around be
using a function that forwards to the class, but it's an annoyance to
have to do that.

I have opened #19724
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19724);
I mention it here because I would really like to see it fixed for 2.0.

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

From dan.eloff at gmail.com  Tue Nov 25 04:24:14 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Mon, 24 Nov 2008 22:24:14 -0500
Subject: [IronPython] Importing in a background thread
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BD8BEF883@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <4817b6fc0811211901g5936be72vcd44a624cc2a0725@mail.gmail.com>
	<350E7D38B6D819428718949920EC235556486D00BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0811220800u796d00aer9046e0e08c55ce6b@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BD8BEF883@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0811241924q144ad7a2l9ee02486b01804fe@mail.gmail.com>

On Sat, Nov 22, 2008 at 6:40 PM, Jimmy Schementi
<Jimmy.Schementi at microsoft.com> wrote:
> Is it a PAL issue? Are you using the BrowserPAL

Yes, good call. I fixed that and all appears to be in order. I don't
really want to submit the change myself in case that presents a legal
obstacle in getting this fix out there soon. All that needs to be done
is the if statement must go. I could not find any more uses of
DynamicApplication.InUIThread.

Thanks,
-Dan


From glenn.k.jones+ipy at gmail.com  Tue Nov 25 16:47:01 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Tue, 25 Nov 2008 15:47:01 +0000
Subject: [IronPython] Question about Control.Invoke and CallTargets
Message-ID: <2679f6510811250747n610a4165v88e604bd24cf3145@mail.gmail.com>

Hello guys,

We're seeing some strange behaviour when doing cross-thread invoking in
Resolver. Unfortunately, we can't get a minimal repro for this, so I'll just
describe what's going on and hopefully something will be obvious.

We do our recalcs in a background thread, to avoid blocking the GUI. When a
recalc finishes, it has to update the UI with the results of the
calculations. We do that with:


    form.Invoke(self._synchroniseUI.Target, self, startedTime, aborted,
state)

where 'form' is our main form, 'self' is a Document instance that holds the
sub-engine and all the results, `startedTime` is a DateTime, `aborted` is a
ManualResetEvent, and `state` is an object with some state extracted from
the recalculations.

We have instrumented the execution of this, and we find this weird pattern:
While _synchroniseUI takes say 500ms, form.Invoke takes 5000ms, but only the
first time it's called. Subsequent updates behave normally. Our guess would
be that some kind of overhead is created lazily once, and comes for free
after that, but it's hard to see what's going on.

We've tried the same Invoke call with CallTarget0 and a lambda with the
arguments and with CallTarget5 with the same results.

Is there something potentially expensive that involves CallTargets and
cross-thread invocations? This was fine in IronPython 1.1.

Thanks
Glenn & Orestis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081125/e9e45a8f/attachment.html>

From curt at hagenlocher.org  Tue Nov 25 16:57:13 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Tue, 25 Nov 2008 07:57:13 -0800
Subject: [IronPython] Question about Control.Invoke and CallTargets
In-Reply-To: <2679f6510811250747n610a4165v88e604bd24cf3145@mail.gmail.com>
References: <2679f6510811250747n610a4165v88e604bd24cf3145@mail.gmail.com>
Message-ID: <d2155e360811250757t33f0361amc2a47585f522d3a9@mail.gmail.com>

Is this something that changed between 1.1 and 2.0 or do you see the same
behavior in both?

On Tue, Nov 25, 2008 at 7:47 AM, Glenn Jones
<glenn.k.jones+ipy at gmail.com<glenn.k.jones%2Bipy at gmail.com>
> wrote:

> Hello guys,
>
> We're seeing some strange behaviour when doing cross-thread invoking in
> Resolver. Unfortunately, we can't get a minimal repro for this, so I'll just
> describe what's going on and hopefully something will be obvious.
>
> We do our recalcs in a background thread, to avoid blocking the GUI. When a
> recalc finishes, it has to update the UI with the results of the
> calculations. We do that with:
>
>
>     form.Invoke(self._synchroniseUI.Target, self, startedTime, aborted,
> state)
>
> where 'form' is our main form, 'self' is a Document instance that holds the
> sub-engine and all the results, `startedTime` is a DateTime, `aborted` is a
> ManualResetEvent, and `state` is an object with some state extracted from
> the recalculations.
>
> We have instrumented the execution of this, and we find this weird pattern:
> While _synchroniseUI takes say 500ms, form.Invoke takes 5000ms, but only the
> first time it's called. Subsequent updates behave normally. Our guess would
> be that some kind of overhead is created lazily once, and comes for free
> after that, but it's hard to see what's going on.
>
> We've tried the same Invoke call with CallTarget0 and a lambda with the
> arguments and with CallTarget5 with the same results.
>
> Is there something potentially expensive that involves CallTargets and
> cross-thread invocations? This was fine in IronPython 1.1.
>
> Thanks
> Glenn & Orestis
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081125/dfc0b537/attachment.html>

From glenn.k.jones+ipy at gmail.com  Tue Nov 25 17:40:55 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Tue, 25 Nov 2008 16:40:55 +0000
Subject: [IronPython] Question about Control.Invoke and CallTargets
In-Reply-To: <d2155e360811250757t33f0361amc2a47585f522d3a9@mail.gmail.com>
References: <2679f6510811250747n610a4165v88e604bd24cf3145@mail.gmail.com>
	<d2155e360811250757t33f0361amc2a47585f522d3a9@mail.gmail.com>
Message-ID: <2679f6510811250840p5deef430idce023c0819b14a4@mail.gmail.com>

We only see the long pause in IP2. To give a feeling of magnitude:

* The first recalc of Resolver (without user input) takes ~3500ms, almost
the same as IP1
* The first recalc with user input that hits this issue takes ~5000ms
* Recalcs after that take ~400ms, which is on par with IP1

Interestingly, removing the form.Invoke and calling it directly (as a test),
removed the pause from that place, but it introduced it at a later stage,
where we ask our grid component to refresh itself, which probably uses a
cross thread invocation itself.

CheckForIllegalCrossThreadCalls is turned off, but we enable it when running
tests, so we know we don't actually do any (except that experiment above).

Glenn & Orestis


On Tue, Nov 25, 2008 at 3:57 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> Is this something that changed between 1.1 and 2.0 or do you see the same
> behavior in both?
>
> On Tue, Nov 25, 2008 at 7:47 AM, Glenn Jones <glenn.k.jones+ipy at gmail.com<glenn.k.jones%2Bipy at gmail.com>
> > wrote:
>
>> Hello guys,
>>
>> We're seeing some strange behaviour when doing cross-thread invoking in
>> Resolver. Unfortunately, we can't get a minimal repro for this, so I'll just
>> describe what's going on and hopefully something will be obvious.
>>
>> We do our recalcs in a background thread, to avoid blocking the GUI. When
>> a recalc finishes, it has to update the UI with the results of the
>> calculations. We do that with:
>>
>>
>>     form.Invoke(self._synchroniseUI.Target, self, startedTime, aborted,
>> state)
>>
>> where 'form' is our main form, 'self' is a Document instance that holds
>> the sub-engine and all the results, `startedTime` is a DateTime, `aborted`
>> is a ManualResetEvent, and `state` is an object with some state extracted
>> from the recalculations.
>>
>> We have instrumented the execution of this, and we find this weird
>> pattern: While _synchroniseUI takes say 500ms, form.Invoke takes 5000ms, but
>> only the first time it's called. Subsequent updates behave normally. Our
>> guess would be that some kind of overhead is created lazily once, and comes
>> for free after that, but it's hard to see what's going on.
>>
>> We've tried the same Invoke call with CallTarget0 and a lambda with the
>> arguments and with CallTarget5 with the same results.
>>
>> Is there something potentially expensive that involves CallTargets and
>> cross-thread invocations? This was fine in IronPython 1.1.
>>
>> Thanks
>> Glenn & Orestis
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081125/3ec44a5d/attachment.html>

From dan.eloff at gmail.com  Wed Nov 26 00:55:04 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Tue, 25 Nov 2008 18:55:04 -0500
Subject: [IronPython] Some observations about parallel import and Silverlight
Message-ID: <4817b6fc0811251555y3122a946l480388cd689b6340@mail.gmail.com>

Thanks to the excellent work of Kamil
(http://github.com/luntain/ipy-parallel-import/tree/master), and the
help of Jimmy I now have importing being done in parallel in 4 threads
in Silverlight.

I had to restructure my code a little to reduce circular imports (not
a bad thing to do anyway) and I had to hand-tweak the dependency graph
to deal with conditional imports and other difficult to track
dependencies.

The result was better than I could have hoped for. I'm seeing 43%
faster loading on my dual-core development pc. I used to have blank
screen at start that made you wonder if the browser has frozen. But
now the browser is responsive and I have a nice working progress bar.
But that's not the best news.

The kicker is that the benefit is even larger on slow single core
machines with dialup internet. I posted a while back on this list that
IE does not immediately send an asynchronous request. It waits until
it's UI thread is idle (which doesn't happen if your importing modules
like crazy on it.) So the net effect was the application loads (about
28 seconds on a P4 2ghz) and then it sends the request, waits for the
response (which is big in my case), and processes it - all in order.
So if that takes another 30 seconds, you have nearly 1 minute of load
time. With the UI thread mostly idle now, this happens in parallel to
the importing, and the overall load time drops by a whopping 45%.

In the words of my generation - w00t!

-Dan


From D.Moor at sim-soft.co.uk  Wed Nov 26 09:38:25 2008
From: D.Moor at sim-soft.co.uk (Dave Moor)
Date: Wed, 26 Nov 2008 08:38:25 +0000
Subject: [IronPython] Keyword Arguments For C# Functions
Message-ID: <WorldClient-F200811260838.AA38250018@sim-soft.co.uk>

Hi Everyone

I am developing a C# application using VS2005 and IronPython v1.1.0 
(currently). I am trying to add a function to a C# class that will be 
callable from IronPython which will take a keyword argument list mimicking:

def fred(self, name, **kwargs):

I found this link 
http://blogs.msdn.com/srivatsn/archive/2008/09/09/passing-keyword-args-to-c-methods-from-ironpython.aspx 
but I don't have Microsoft.Scripting available.

However IronPython allows kwargs on contructors of standard clr classes like 
System.Windows.Forms.TextBox etc., can I use the same magic as that?

I looked in the source of v1.1.2, do I need to do 'something' with 
IronPython.Runtime.Calls.KwArgBinder and if so what?  Is there a sample 
somewhere I've missed?  Or is it covered in IronPython in Action, if so I 
guess I'd better stick my hand in my pocket :)

Thanks in advance

Dave


--
Registered Office
Mill House, Hawksworth Road, Horsforth, Leeds, LS18 4JP  England.
Reg No. 1311728 Eng.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/73c0b723/attachment.html>

From szport at gmail.com  Wed Nov 26 10:50:53 2008
From: szport at gmail.com (Zaur Shibzoukhov)
Date: Wed, 26 Nov 2008 12:50:53 +0300
Subject: [IronPython] COM Object Issue
In-Reply-To: <350E7D38B6D819428718949920EC23554FF6DC08FE@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <e2a7590810270050w30120cb0r5acb66925ea722a7@mail.gmail.com>
	<350E7D38B6D819428718949920EC23554FF6DC08FB@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<350E7D38B6D819428718949920EC23554FF6DC08FE@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <e2a7590811260150u2244de65o4ebe7651e4b166b7@mail.gmail.com>

What will happen with the item-like access to COM objects in IP 2.0?

Whether it will return to []-like access (as in RC 1) or it will
remain .Item(...)?
IMHO RC 1 way is more preferred.

Best regards,
Zaur

2008/10/27 Dino Viehland <dinov at microsoft.com>:
> Oh, and I'm not sure if this is by design or not (I'll need to ping the DLR team), but it seems you can do:
>
> wd.Variables.Item('foo')
>
> instead.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Monday, October 27, 2008 7:44 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] COM Object Issue
>
> Is the exception you're seeing "Error while invoking Item"?  Just want to make sure I'm seeing the same thing and the actual exception is cut off in your snippet below.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Zaur Shibzoukhov
> Sent: Monday, October 27, 2008 12:51 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] COM Object Issue
>
> There is an error in RC 1:
>
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import System
>>>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application"))
>>>> wd = wa.Documents.Add()
>>>> wd.Variables.Add("foo")
> <System.__ComObject (Variable) object at 0x000000000000002B>
>>>> wd.Variables["foo"]
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>
> In IronPython Beta 5 it worked as expected:
>
> IronPython 2.0 Beta (2.0.0.5000) on .NET 2.0.50727.1433
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import System
>>>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application"))
>>>> wd = wa.Documents.Add()
>>>> wd.Variables.Add("foo")
> <System.__ComObject (Variable) object at 0x000000000000002B>
>>>> wd.Variables["foo"]
> <System.__ComObject (Variable) object at 0x000000000000002C>
>
> Best regards,
> Zaur
> _______________________________________________
> 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
>


From curt at hagenlocher.org  Wed Nov 26 13:33:31 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 26 Nov 2008 04:33:31 -0800
Subject: [IronPython] Keyword Arguments For C# Functions
In-Reply-To: <WorldClient-F200811260838.AA38250018@sim-soft.co.uk>
References: <WorldClient-F200811260838.AA38250018@sim-soft.co.uk>
Message-ID: <d2155e360811260433l13410296x16bd88d1fc521354@mail.gmail.com>

The keyword arguments you've seen used on CLR classes are actually using
properties as initializers.  That is,

tb = System.Windows.Forms.TextBox(Text = 'Hello')

is exactly equivalent to

tb = System.Windows.Forms.TextBox()
tb.Text = 'Hello'

On Wed, Nov 26, 2008 at 12:38 AM, Dave Moor <D.Moor at sim-soft.co.uk> wrote:

> Hi Everyone
>
> I am developing a C# application using VS2005 and IronPython v1.1.0
> (currently). I am trying to add a function to a C# class that will be
> callable from IronPython which will take a keyword argument list mimicking:
>
> def fred(self, name, **kwargs):
>
> I found this link
> http://blogs.msdn.com/srivatsn/archive/2008/09/09/passing-keyword-args-to-c-methods-from-ironpython.aspxbut I don't have Microsoft.Scripting
> available.
>
> However IronPython allows kwargs on contructors of standard clr classes
> like System.Windows.Forms.TextBox etc., can I use the same magic as that?
>
> I looked in the source of v1.1.2, do I need to do 'something' with
> IronPython.Runtime.Calls.KwArgBinder and if so what?  Is there a sample
> somewhere I've missed?  Or is it covered in IronPython in Action, if so I
> guess I'd better stick my hand in my pocket :)
>
> Thanks in advance
>
> Dave
>
>
> --
> Registered Office
> Mill House, Hawksworth Road, Horsforth, Leeds, LS18 4JP England.
> Reg No. 1311728 Eng.
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/b7412a6a/attachment.html>

From curt at hagenlocher.org  Wed Nov 26 13:37:48 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 26 Nov 2008 04:37:48 -0800
Subject: [IronPython] Keyword Arguments For C# Functions
In-Reply-To: <d2155e360811260433l13410296x16bd88d1fc521354@mail.gmail.com>
References: <WorldClient-F200811260838.AA38250018@sim-soft.co.uk>
	<d2155e360811260433l13410296x16bd88d1fc521354@mail.gmail.com>
Message-ID: <d2155e360811260437m503ade25s1c96969e19686db2@mail.gmail.com>

Oh, and I think the 1.1-equivalent of ParamDictionaryAttribute is
ParamDictAttribute.

On Wed, Nov 26, 2008 at 4:33 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> The keyword arguments you've seen used on CLR classes are actually using
> properties as initializers.  That is,
>
> tb = System.Windows.Forms.TextBox(Text = 'Hello')
>
> is exactly equivalent to
>
> tb = System.Windows.Forms.TextBox()
> tb.Text = 'Hello'
>
> On Wed, Nov 26, 2008 at 12:38 AM, Dave Moor <D.Moor at sim-soft.co.uk> wrote:
>
>> Hi Everyone
>>
>> I am developing a C# application using VS2005 and IronPython v1.1.0
>> (currently). I am trying to add a function to a C# class that will be
>> callable from IronPython which will take a keyword argument list mimicking:
>>
>> def fred(self, name, **kwargs):
>>
>> I found this link
>> http://blogs.msdn.com/srivatsn/archive/2008/09/09/passing-keyword-args-to-c-methods-from-ironpython.aspxbut I don't have Microsoft.Scripting
>> available.
>>
>> However IronPython allows kwargs on contructors of standard clr classes
>> like System.Windows.Forms.TextBox etc., can I use the same magic as that?
>>
>> I looked in the source of v1.1.2, do I need to do 'something' with
>> IronPython.Runtime.Calls.KwArgBinder and if so what?  Is there a sample
>> somewhere I've missed?  Or is it covered in IronPython in Action, if so I
>> guess I'd better stick my hand in my pocket :)
>>
>> Thanks in advance
>>
>> Dave
>>
>>
>> --
>> Registered Office
>> Mill House, Hawksworth Road, Horsforth, Leeds, LS18 4JP England.
>> Reg No. 1311728 Eng.
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/2b448302/attachment.html>

From vernondcole at gmail.com  Wed Nov 26 14:51:38 2008
From: vernondcole at gmail.com (Vernon Cole)
Date: Wed, 26 Nov 2008 06:51:38 -0700
Subject: [IronPython] COM Object Issue
In-Reply-To: <e2a7590811260150u2244de65o4ebe7651e4b166b7@mail.gmail.com>
References: <e2a7590810270050w30120cb0r5acb66925ea722a7@mail.gmail.com>
	<350E7D38B6D819428718949920EC23554FF6DC08FB@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<350E7D38B6D819428718949920EC23554FF6DC08FE@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<e2a7590811260150u2244de65o4ebe7651e4b166b7@mail.gmail.com>
Message-ID: <b7eb4a700811260551sa53daf1t19e7680c427417b5@mail.gmail.com>

That's a really fine question. I had to change all of my COM item access
twice now in adodbapi. I finally ended up using a function, because iron
python and c python are so different in this area. My current code is:
if onIronPython:
    def getIndexedValue(obj,index):
        return obj.Item[index]
else: #pywin32
   def getIndexedValue(obj,index):
        return obj(index)

So I can (for example, reading the field definitions of an ADO recordset):

            nOfFields=rs.Fields.Count
            for i in range(nOfFields):
                f=getIndexedValue(rs.Fields,i)

Question: Will this continue to work in future versions of IronPython?
--
Vernon Cole

On Wed, Nov 26, 2008 at 2:50 AM, Zaur Shibzoukhov <szport at gmail.com> wrote:

> What will happen with the item-like access to COM objects in IP 2.0?
>
> Whether it will return to []-like access (as in RC 1) or it will
> remain .Item(...)?
> IMHO RC 1 way is more preferred.
>
> Best regards,
> Zaur
>
> 2008/10/27 Dino Viehland <dinov at microsoft.com>:
> > Oh, and I'm not sure if this is by design or not (I'll need to ping the
> DLR team), but it seems you can do:
> >
> > wd.Variables.Item('foo')
> >
> > instead.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/42dc03a8/attachment.html>

From dinov at microsoft.com  Wed Nov 26 20:11:07 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 26 Nov 2008 11:11:07 -0800
Subject: [IronPython] COM Object Issue
In-Reply-To: <b7eb4a700811260551sa53daf1t19e7680c427417b5@mail.gmail.com>
References: <e2a7590810270050w30120cb0r5acb66925ea722a7@mail.gmail.com>
	<350E7D38B6D819428718949920EC23554FF6DC08FB@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<350E7D38B6D819428718949920EC23554FF6DC08FE@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<e2a7590811260150u2244de65o4ebe7651e4b166b7@mail.gmail.com>,
	<b7eb4a700811260551sa53daf1t19e7680c427417b5@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564A4DF775@NA-EXMSG-C102.redmond.corp.microsoft.com>

I wouldn't expect any breaking changes in COM until IronPython 3.0 at the earliest.  That being said our COM binding logic is actually owned by the DLR team.  They have been and will continue working on fixing bugs in the COM binding logic.  Therefore you might see us integrate in small bug fixes but nothing that would break your code.

I think ideally we'd all love to see us match pywin32 as closely as possible so we might at some point revisit the way we currently are doing the binding (and recent changes in the DLR should make this much easier than it was before).  I think we'd approach this by enabling both behaviors so .Item works as well as calling, eventually start issuing warnings on .Item, and then finally remove .Item in Ipy 3k or later.
________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole [vernondcole at gmail.com]
Sent: Wednesday, November 26, 2008 7:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] COM Object Issue

That's a really fine question. I had to change all of my COM item access twice now in adodbapi. I finally ended up using a function, because iron python and c python are so different in this area. My current code is:
if onIronPython:
    def getIndexedValue(obj,index):
        return obj.Item[index]
else: #pywin32
   def getIndexedValue(obj,index):
        return obj(index)

So I can (for example, reading the field definitions of an ADO recordset):

            nOfFields=rs.Fields.Count
            for i in range(nOfFields):
                f=getIndexedValue(rs.Fields,i)

Question: Will this continue to work in future versions of IronPython?
--
Vernon Cole

On Wed, Nov 26, 2008 at 2:50 AM, Zaur Shibzoukhov <szport at gmail.com<mailto:szport at gmail.com>> wrote:
What will happen with the item-like access to COM objects in IP 2.0?

Whether it will return to []-like access (as in RC 1) or it will
remain .Item(...)?
IMHO RC 1 way is more preferred.

Best regards,
Zaur

2008/10/27 Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>>:
> Oh, and I'm not sure if this is by design or not (I'll need to ping the DLR team), but it seems you can do:
>
> wd.Variables.Item('foo')
>
> instead.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/e372025f/attachment.html>

From dinov at microsoft.com  Thu Nov 27 00:52:16 2008
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 26 Nov 2008 15:52:16 -0800
Subject: [IronPython] Question about Control.Invoke and CallTargets
In-Reply-To: <2679f6510811250840p5deef430idce023c0819b14a4@mail.gmail.com>
References: <2679f6510811250747n610a4165v88e604bd24cf3145@mail.gmail.com>
	<d2155e360811250757t33f0361amc2a47585f522d3a9@mail.gmail.com>,
	<2679f6510811250840p5deef430idce023c0819b14a4@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355564A4DF777@NA-EXMSG-C102.redmond.corp.microsoft.com>

Does it also repro under a debugger?  Given it's a full 5 seconds could you pause the app when this is happening to see what the actual stacks are?

________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones [glenn.k.jones+ipy at gmail.com]
Sent: Tuesday, November 25, 2008 10:40 AM
To: Curt Hagenlocher
Cc: Discussion of IronPython
Subject: Re: [IronPython] Question about Control.Invoke and CallTargets

We only see the long pause in IP2. To give a feeling of magnitude:

* The first recalc of Resolver (without user input) takes ~3500ms, almost the same as IP1
* The first recalc with user input that hits this issue takes ~5000ms
* Recalcs after that take ~400ms, which is on par with IP1

Interestingly, removing the form.Invoke and calling it directly (as a test), removed the pause from that place, but it introduced it at a later stage, where we ask our grid component to refresh itself, which probably uses a cross thread invocation itself.

CheckForIllegalCrossThreadCalls is turned off, but we enable it when running tests, so we know we don't actually do any (except that experiment above).

Glenn & Orestis


On Tue, Nov 25, 2008 at 3:57 PM, Curt Hagenlocher <curt at hagenlocher.org<mailto:curt at hagenlocher.org>> wrote:
Is this something that changed between 1.1 and 2.0 or do you see the same behavior in both?

On Tue, Nov 25, 2008 at 7:47 AM, Glenn Jones <glenn.k.jones+ipy at gmail.com<mailto:glenn.k.jones%2Bipy at gmail.com>> wrote:
Hello guys,

We're seeing some strange behaviour when doing cross-thread invoking in Resolver. Unfortunately, we can't get a minimal repro for this, so I'll just describe what's going on and hopefully something will be obvious.

We do our recalcs in a background thread, to avoid blocking the GUI. When a recalc finishes, it has to update the UI with the results of the calculations. We do that with:


    form.Invoke(self._synchroniseUI.Target, self, startedTime, aborted, state)

where 'form' is our main form, 'self' is a Document instance that holds the sub-engine and all the results, `startedTime` is a DateTime, `aborted` is a ManualResetEvent, and `state` is an object with some state extracted from the recalculations.

We have instrumented the execution of this, and we find this weird pattern: While _synchroniseUI takes say 500ms, form.Invoke takes 5000ms, but only the first time it's called. Subsequent updates behave normally. Our guess would be that some kind of overhead is created lazily once, and comes for free after that, but it's hard to see what's going on.

We've tried the same Invoke call with CallTarget0 and a lambda with the arguments and with CallTarget5 with the same results.

Is there something potentially expensive that involves CallTargets and cross-thread invocations? This was fine in IronPython 1.1.

Thanks
Glenn & Orestis



_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/93e94ab2/attachment.html>

From srivatsn at microsoft.com  Thu Nov 27 01:06:36 2008
From: srivatsn at microsoft.com (Srivatsn Narayanan)
Date: Wed, 26 Nov 2008 16:06:36 -0800
Subject: [IronPython] Announcing IronPython 2.0 RC2
Message-ID: <B0F32F33670C5D47BB6D5D315C32CD66221E44FD61@NA-EXMSG-C108.redmond.corp.microsoft.com>

Hello IronPython community,

Since we released IronPython 2.0 RC1, there have been some major blocking bugs reported in the mailing list. We have fixed 7 of them and are releasing IronPython 2.0 RC2.  We expect to release the final version in less than two weeks barring any more major blocking bugs. So please do try out RC2 and let us know of any issues as soon as you can.

Please note that there is a new codeplex project for DLR<http://www.codeplex.com/dlr> and ToyScript will now ship as part of the DLR project.

List of bugs fixed for this release:

-          19350: Missing restrictions on index operation against user defined type

-          11733: time.timezone has different semantic than in cpython

-          19675: subclasses of float have trouble with __int__ and __str__

-          19656: Module Name Lookup Broken Title is required

-          19678: in operator calls __getitem__ on class that has __len__ and __iter__ defined

-          19665: operator.isSequenceType(NewStyleClass) broken

-          19130: One hour error in IPY implementation of time.mktime and time.gmtime

We'd like to thank gjones, fuzzyman, dubnerm and vernondcole for reporting these bugs.

You can download IronPython 2.0 RC2 at:
 http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=19841

The IronPython Team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/b77d7aac/attachment.html>

From danummer at gmail.com  Thu Nov 27 06:35:23 2008
From: danummer at gmail.com (Nummers)
Date: Thu, 27 Nov 2008 00:35:23 -0500
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight (but
	works in ipy)
Message-ID: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>

Just getting going on Ipy / Silverlight and hit a roadblock.

This works on ipy but gives an error w/ Ipy in Silverlight (IOError: Could
not add reference to assembly API.dll).

import clr
clr.AddReference('API.dll')
from OEC.API import *
from OEC.DATA import *

same kind of error with:
clr.AddReference("API, Version=3.2.0.0, Culture=neutral,
PublicKeyToken=b6b45f27e2749b17")
and with:
clr.LoadAssemblyByName("API, Version=3.2.0.0, Culture=neutral,
PublicKeyToken=b6b45f27e2749b17")

Now, this gives no error:
clr.AddReferenceToFile("API.dll")
However the imports fail (ImportError: No module named OEC.API

Not too much experience loading assemblies but, as I said, all is well in
ipy.

Hope I'm just doing something stooopid.

Very much appreciate any help!

Dano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/00302493/attachment.html>

From curt at hagenlocher.org  Thu Nov 27 06:37:49 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 26 Nov 2008 21:37:49 -0800
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight
	(but works in ipy)
In-Reply-To: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
References: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
Message-ID: <d2155e360811262137m769c8ac0u3b68c4d6c47342e7@mail.gmail.com>

You've built two different versions of API.dll -- one for the desktop CLR
and one for Silverlight -- yes?

On Wed, Nov 26, 2008 at 9:35 PM, Nummers <danummer at gmail.com> wrote:

> Just getting going on Ipy / Silverlight and hit a roadblock.
>
> This works on ipy but gives an error w/ Ipy in Silverlight (IOError: Could
> not add reference to assembly API.dll).
>
> import clr
> clr.AddReference('API.dll')
> from OEC.API import *
> from OEC.DATA import *
>
> same kind of error with:
> clr.AddReference("API, Version=3.2.0.0, Culture=neutral,
> PublicKeyToken=b6b45f27e2749b17")
> and with:
> clr.LoadAssemblyByName("API, Version=3.2.0.0, Culture=neutral,
> PublicKeyToken=b6b45f27e2749b17")
>
> Now, this gives no error:
> clr.AddReferenceToFile("API.dll")
> However the imports fail (ImportError: No module named OEC.API
>
> Not too much experience loading assemblies but, as I said, all is well in
> ipy.
>
> Hope I'm just doing something stooopid.
>
> Very much appreciate any help!
>
> Dano
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/5c049c39/attachment.html>

From danummer at gmail.com  Thu Nov 27 06:44:31 2008
From: danummer at gmail.com (Nummers)
Date: Thu, 27 Nov 2008 00:44:31 -0500
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight
	(but works in ipy)
In-Reply-To: <d2155e360811262137m769c8ac0u3b68c4d6c47342e7@mail.gmail.com>
References: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
	<d2155e360811262137m769c8ac0u3b68c4d6c47342e7@mail.gmail.com>
Message-ID: <20ab7c020811262144r17b9e8e5sb0b7fe5cf2f78667@mail.gmail.com>

Wow , that was fast...

Anyway no I did not / can not, this is a third party dll. From the docs
"Technically, it is a .NET 2.0 assembly (DLL library), ..."

On Thu, Nov 27, 2008 at 12:37 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> You've built two different versions of API.dll -- one for the desktop CLR
> and one for Silverlight -- yes?
>
>   On Wed, Nov 26, 2008 at 9:35 PM, Nummers <danummer at gmail.com> wrote:
>
>>  Just getting going on Ipy / Silverlight and hit a roadblock.
>>
>> This works on ipy but gives an error w/ Ipy in Silverlight (IOError: Could
>> not add reference to assembly API.dll).
>>
>> import clr
>> clr.AddReference('API.dll')
>> from OEC.API import *
>> from OEC.DATA import *
>>
>> same kind of error with:
>> clr.AddReference("API, Version=3.2.0.0, Culture=neutral,
>> PublicKeyToken=b6b45f27e2749b17")
>> and with:
>> clr.LoadAssemblyByName("API, Version=3.2.0.0, Culture=neutral,
>> PublicKeyToken=b6b45f27e2749b17")
>>
>> Now, this gives no error:
>> clr.AddReferenceToFile("API.dll")
>> However the imports fail (ImportError: No module named OEC.API
>>
>> Not too much experience loading assemblies but, as I said, all is well in
>> ipy.
>>
>> Hope I'm just doing something stooopid.
>>
>> Very much appreciate any help!
>>
>> Dano
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/6387d1a3/attachment.html>

From curt at hagenlocher.org  Thu Nov 27 06:50:06 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 26 Nov 2008 21:50:06 -0800
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight
	(but works in ipy)
In-Reply-To: <20ab7c020811262144r17b9e8e5sb0b7fe5cf2f78667@mail.gmail.com>
References: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
	<d2155e360811262137m769c8ac0u3b68c4d6c47342e7@mail.gmail.com>
	<20ab7c020811262144r17b9e8e5sb0b7fe5cf2f78667@mail.gmail.com>
Message-ID: <d2155e360811262150r7df0a959g3b4f019096d006e8@mail.gmail.com>

Unfortunately, the Silverlight and desktop CLRs aren't binary-compatible --
you're basically linking against a different set of strongly-named
assemblies when you're building a Silverlight version.  You'll almost
certainly need to contact the vendor and ask them to provide support for
Silverlight in order for it to be usable there.  This may not require much
more work than a simple rebuild, but if they've used any APIs that aren't
supported under Silverlight (like .NET serialization or the original
collection classes) then they'd need to modify the source code as well.

On Wed, Nov 26, 2008 at 9:44 PM, Nummers <danummer at gmail.com> wrote:

> Wow , that was fast...
>
> Anyway no I did not / can not, this is a third party dll. From the docs
> "Technically, it is a .NET 2.0 assembly (DLL library), ..."
>
> On Thu, Nov 27, 2008 at 12:37 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>
>> You've built two different versions of API.dll -- one for the desktop CLR
>> and one for Silverlight -- yes?
>>
>>   On Wed, Nov 26, 2008 at 9:35 PM, Nummers <danummer at gmail.com> wrote:
>>
>>>  Just getting going on Ipy / Silverlight and hit a roadblock.
>>>
>>> This works on ipy but gives an error w/ Ipy in Silverlight (IOError:
>>> Could not add reference to assembly API.dll).
>>>
>>> import clr
>>> clr.AddReference('API.dll')
>>> from OEC.API import *
>>> from OEC.DATA import *
>>>
>>> same kind of error with:
>>> clr.AddReference("API, Version=3.2.0.0, Culture=neutral,
>>> PublicKeyToken=b6b45f27e2749b17")
>>> and with:
>>> clr.LoadAssemblyByName("API, Version=3.2.0.0, Culture=neutral,
>>> PublicKeyToken=b6b45f27e2749b17")
>>>
>>> Now, this gives no error:
>>> clr.AddReferenceToFile("API.dll")
>>> However the imports fail (ImportError: No module named OEC.API
>>>
>>> Not too much experience loading assemblies but, as I said, all is well in
>>> ipy.
>>>
>>> Hope I'm just doing something stooopid.
>>>
>>> Very much appreciate any help!
>>>
>>> Dano
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/d8789ae2/attachment.html>

From danummer at gmail.com  Thu Nov 27 07:07:49 2008
From: danummer at gmail.com (Nummers)
Date: Thu, 27 Nov 2008 01:07:49 -0500
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight
	(but works in ipy)
In-Reply-To: <d2155e360811262150r7df0a959g3b4f019096d006e8@mail.gmail.com>
References: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
	<d2155e360811262137m769c8ac0u3b68c4d6c47342e7@mail.gmail.com>
	<20ab7c020811262144r17b9e8e5sb0b7fe5cf2f78667@mail.gmail.com>
	<d2155e360811262150r7df0a959g3b4f019096d006e8@mail.gmail.com>
Message-ID: <20ab7c020811262207u757ab3cfvd8489282c762e79e@mail.gmail.com>

ok I think that makes sense, thanks

Just so I understand, this is really an issue of different .NET frameworks
between the desktop and Silverlight?  So, I would face this issue even if I
did not use DLR and went with C#?

On Thu, Nov 27, 2008 at 12:50 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> Unfortunately, the Silverlight and desktop CLRs aren't binary-compatible --
> you're basically linking against a different set of strongly-named
> assemblies when you're building a Silverlight version.  You'll almost
> certainly need to contact the vendor and ask them to provide support for
> Silverlight in order for it to be usable there.  This may not require much
> more work than a simple rebuild, but if they've used any APIs that aren't
> supported under Silverlight (like .NET serialization or the original
> collection classes) then they'd need to modify the source code as well.
>
>
> On Wed, Nov 26, 2008 at 9:44 PM, Nummers <danummer at gmail.com> wrote:
>
>> Wow , that was fast...
>>
>> Anyway no I did not / can not, this is a third party dll. From the docs
>> "Technically, it is a .NET 2.0 assembly (DLL library), ..."
>>
>>   On Thu, Nov 27, 2008 at 12:37 AM, Curt Hagenlocher <
>> curt at hagenlocher.org> wrote:
>>
>>> You've built two different versions of API.dll -- one for the desktop CLR
>>> and one for Silverlight -- yes?
>>>
>>>   On Wed, Nov 26, 2008 at 9:35 PM, Nummers <danummer at gmail.com> wrote:
>>>
>>>>  Just getting going on Ipy / Silverlight and hit a roadblock.
>>>>
>>>> This works on ipy but gives an error w/ Ipy in Silverlight (IOError:
>>>> Could not add reference to assembly API.dll).
>>>>
>>>> import clr
>>>> clr.AddReference('API.dll')
>>>> from OEC.API import *
>>>> from OEC.DATA import *
>>>>
>>>> same kind of error with:
>>>> clr.AddReference("API, Version=3.2.0.0, Culture=neutral,
>>>> PublicKeyToken=b6b45f27e2749b17")
>>>> and with:
>>>> clr.LoadAssemblyByName("API, Version=3.2.0.0, Culture=neutral,
>>>> PublicKeyToken=b6b45f27e2749b17")
>>>>
>>>> Now, this gives no error:
>>>> clr.AddReferenceToFile("API.dll")
>>>> However the imports fail (ImportError: No module named OEC.API
>>>>
>>>> Not too much experience loading assemblies but, as I said, all is well
>>>> in ipy.
>>>>
>>>> Hope I'm just doing something stooopid.
>>>>
>>>> Very much appreciate any help!
>>>>
>>>> Dano
>>>> _______________________________________________
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/e985e228/attachment.html>

From billchi at microsoft.com  Thu Nov 27 08:37:47 2008
From: billchi at microsoft.com (Bill Chiles)
Date: Wed, 26 Nov 2008 23:37:47 -0800
Subject: [IronPython] DLR Codeplex Project Goes Live!
Message-ID: <8DD7BECAEB597D4782F7C9CEFDCA6B9284FA66E097@NA-EXMSG-C125.redmond.corp.microsoft.com>


Today we're excited to announce the release of the Dynamic Language Runtime (DLR) as a separate Codeplex project.  This release is a beta because we want our v0.9 to be the same sources and bits as IronPython v2.0.  Due to a couple of good customer bugs, they wanted to release v2 RC2 in NOV and hopefully RTW v2 in DEC.

The DLR project provides one-stop shopping for folks who want to:
*       implement a language on .NET using the DLR
*       add dynamic features to their existing language like C#'s 'dynamic' (http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=csharpfuture&DownloadId=3550 )
*       add scripting to their applications.
*       create .NET libraries with dynamic objects
This Codeplex project includes the DLR sources as well as sources for IronPython, IronRuby, and samples (such as ToyScript).  This is a classic open source version 0.9 release with high quality code through much of the system.  We're shipping some of this in the .NET 4.0 release coming up.  Some parts are still open to design changes as we solidify those parts for post .NET 4.0, and we'll continue to add more docs and samples.   We will have coordinated releases or sync points across IronPython and IronRuby sites for major releases so that if you're not pulling from the DLR project, you can still see which sources or releases are consistent across our projects.

Jim Hugunin did a great talk at PDC 08 on DLR architecture, concepts, and coding with the .NET 4.0 functionality (http://channel9.msdn.com/pdc2008/TL10/ ).  In his talk, he also outlines what's in .NET 4.0:
*       fast dynamic dispatch with polymorphic inline caching
*       dynamic object interoperability across languages and libraries (including C# 'dynamic' consuming IronPython and IronRuby objects naturally, including any language whose objects participate in the DLR's dynamic object protocol)
*       support for library authors to easily make their model objects consumable with nice looking and lightweight code in languages that support the DLR dynamic object protocol (for example, with C#'s 'dynamic', you can write xml.Customer.Name instead of xml.GetChild("Customer").GetChild("Name")
*       ability to mix binding logic from various languages and library objects in a single dynamic call site cache
*       Expression Trees v2 with support for control flow, assignments, etc.
*       COM IDispatch binding as DLR dynamic objects
The following highlights the support shipping only on Codeplex until a future .NET release:
*       common hosting model for languages built on or supporting the DLR hosting model
*       helpers such as a default .NET binder, complex numbers, tuples
*       more Expression Tree support, such as globals access in hosted scenarios and iterator/generator functions.

All the code is available for what the DLR Team is shipping in .NET 4.0.  Furthermore, we're releasing all the code for LINQ Expression Trees v1 since the DLR merged its ASTs with LINQ trees.  Some of you have noticed this code has been on the IronPython site for a couple of months now.  We will continue indefinitely shipping all of our code open source through .NET 4.0 shipping and future releases of .NET as we move more and more of the DLR into .NET (for example, the common hosting APIs and language implementer APIs).  We have no plan in place at this time for source take back from the community.

It is worth noting that the sources and binaries in the .zip files are circa mid-October, and the daily source tree pushes have several small but pervasive cleanups to the API (name changes), perf improvements, and so on.  We're busy here solidifying final design changes for the DLR parts going into .NET 4.0.  We wanted to have our release match IronPython 2.0, and they had to lock down sources before we did.  The documents in the release speak to the latest sources.  Some of the documents are our internal working specs, but in general we prefer you know where we're planning to end up with the code.  There are no significant cognitive changes in the APIs, so you'll easily map from the docs to the actual code.

For a consistent IronPython release, go to www.codeplex.com/ironpython<http://www.codeplex.com/ironpython> and get their v2.0 RC2.  We won't normally have consistent release across all projects for RCs, betas, etc., and we don't have one for IronRuby today.  When we RTW IPy v2 and DLR v0.9 shortly, we'll have consistent releases for all three projects.

If you want to read some documents without downloading sources or bits, go to http://www.codeplex.com/dlr/Wiki/View.aspx?title=Docs%20and%20specs :
*       dlr-overview.doc
*       sites-binders-dyn-objs-spec.doc
*       expr-tree-spec.doc
*       dlr-spec-hosting.doc

There is a discussion list at http://www.codeplex.com/dlr/Thread/List.aspx (click on the "get email notifications" link).  All mail there goes to dlr at microsoft.com<mailto:dlr at microsoft.com> which has all the folks working on the DLR and our languages on it.

Thanks,
Bill


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081126/16dc6ffe/attachment.html>

From dans at houmus.org  Thu Nov 27 09:45:38 2008
From: dans at houmus.org (Dan Shechter)
Date: Thu, 27 Nov 2008 10:45:38 +0200
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight
	(but works in ipy)
In-Reply-To: <20ab7c020811262207u757ab3cfvd8489282c762e79e@mail.gmail.com>
References: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
	<d2155e360811262137m769c8ac0u3b68c4d6c47342e7@mail.gmail.com>
	<20ab7c020811262144r17b9e8e5sb0b7fe5cf2f78667@mail.gmail.com>
	<d2155e360811262150r7df0a959g3b4f019096d006e8@mail.gmail.com>
	<20ab7c020811262207u757ab3cfvd8489282c762e79e@mail.gmail.com>
Message-ID: <009601c9506c$87497c80$95dc7580$@org>

Yeap.

That's the case.

 

You can always try and disassemble OEC's API assembly with ildasm (which I
did 2 years back) just to 

recompile (ilasm) it with a different CLR (Silverlight in your case)

 

In my case I wanted to call their API from Mono on Linux and their assembly
had some dependency on some Win32 Interop to access the registry

IIRC.

 

Alternatively you could get down on your knees and beg them to support
Silverlight :)

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Nummers
Sent: Thursday, November 27, 2008 8:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] clr assembly reference error in Ipy / Silverlight
(but works in ipy)

 

ok I think that makes sense, thanks

 

Just so I understand, this is really an issue of different .NET frameworks
between the desktop and Silverlight?  So, I would face this issue even if I
did not use DLR and went with C#? 

On Thu, Nov 27, 2008 at 12:50 AM, Curt Hagenlocher <curt at hagenlocher.org>
wrote:

Unfortunately, the Silverlight and desktop CLRs aren't binary-compatible --
you're basically linking against a different set of strongly-named
assemblies when you're building a Silverlight version.  You'll almost
certainly need to contact the vendor and ask them to provide support for
Silverlight in order for it to be usable there.  This may not require much
more work than a simple rebuild, but if they've used any APIs that aren't
supported under Silverlight (like .NET serialization or the original
collection classes) then they'd need to modify the source code as well. 

 

On Wed, Nov 26, 2008 at 9:44 PM, Nummers <danummer at gmail.com> wrote:

Wow , that was fast...

 

Anyway no I did not / can not, this is a third party dll. From the docs
"Technically, it is a .NET 2.0 assembly (DLL library), ..."

On Thu, Nov 27, 2008 at 12:37 AM, Curt Hagenlocher <curt at hagenlocher.org>
wrote:

You've built two different versions of API.dll -- one for the desktop CLR
and one for Silverlight -- yes?

On Wed, Nov 26, 2008 at 9:35 PM, Nummers <danummer at gmail.com> wrote:

Just getting going on Ipy / Silverlight and hit a roadblock.
 
This works on ipy but gives an error w/ Ipy in Silverlight (IOError: Could
not add reference to assembly API.dll).
 
import clr
clr.AddReference('API.dll')
from OEC.API import *
from OEC.DATA import *
 
same kind of error with:
clr.AddReference("API, Version=3.2.0.0 <http://3.2.0.0/> , Culture=neutral,
PublicKeyToken=b6b45f27e2749b17")
and with:
clr.LoadAssemblyByName("API, Version=3.2.0.0 <http://3.2.0.0/> ,
Culture=neutral, PublicKeyToken=b6b45f27e2749b17")
 
Now, this gives no error:
clr.AddReferenceToFile("API.dll")
However the imports fail (ImportError: No module named OEC.API
 
Not too much experience loading assemblies but, as I said, all is well in
ipy.
 
Hope I'm just doing something stooopid.
 
Very much appreciate any help!
 
Dano 

_______________________________________________
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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/e2e1fd46/attachment.html>

From glenn.k.jones+ipy at gmail.com  Thu Nov 27 12:40:11 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Thu, 27 Nov 2008 11:40:11 +0000
Subject: [IronPython] Question about Control.Invoke and CallTargets
In-Reply-To: <350E7D38B6D819428718949920EC2355564A4DF777@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <2679f6510811250747n610a4165v88e604bd24cf3145@mail.gmail.com>
	<d2155e360811250757t33f0361amc2a47585f522d3a9@mail.gmail.com>
	<2679f6510811250840p5deef430idce023c0819b14a4@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355564A4DF777@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <2679f6510811270340h214f4634gc90543d9995e91b2@mail.gmail.com>

Doh! It wasn't the invoke. We had a late import on the gui thread which was
blocking, and the invoke was waiting for that to complete.

Sorry about the false alarm and thanks for all the help.

Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/5252a34a/attachment.html>

From william at resolversystems.com  Thu Nov 27 18:22:48 2008
From: william at resolversystems.com (William Reade)
Date: Thu, 27 Nov 2008 17:22:48 +0000
Subject: [IronPython] Ironclad v0.7 released
Message-ID: <492ED768.1070403@resolversystems.com>

Hi all

I'm delighted to announce the release of Ironclad v0.7, which is now 
available from http://code.google.com/p/ironclad/downloads/list . This 
release is a major step forward:

* Runs transparently on vanilla IronPython 2.0RC2, without creating 
extra PythonEngines or breaking .NET namespace imports
* Many numpy 1.2 tests (from the core, fft, lib, linalg and random 
subpackages) now reliably pass (run "ipy numpytests.py" from the build 
directory)
* Significant performance improvements (by several orders of magnitude 
in some places :D)

So... if you want to use numpy (or other C extension modules) with 
IronPython on Win32, please download it and try it out; I'm very keen to 
hear your experiences, and to know which neglected features will be most 
useful to you.

Cheers
William


From toolsack at gmail.com  Thu Nov 27 22:22:39 2008
From: toolsack at gmail.com (Richard Bowen)
Date: Thu, 27 Nov 2008 21:22:39 +0000
Subject: [IronPython] Startup scripts
Message-ID: <8759213f0811271322v3eb158bfr39005634385869eb@mail.gmail.com>

Hi

I have a simple question that I'm hoping has an answer I'm looking for. I'd
like to have a startup script to seamlessly run before running a
specified script.

Eg I can have a script/module that defines foo() and call on startup

IRONPYTHONSTARTUP=start.py

then when I run ipy I can call foo() straight on the command line.

However when running a command or script I have to re-import the module:

ipy.exe  -c "import start; from start import *;foo()"

what I'd like to be able to do is:

ipy.exe -c "foo()"

is that possible? (I have a .bat file that makes it work, but I'd like
to avoid if possible)

thanks
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/4b62e492/attachment.html>

From curt at hagenlocher.org  Fri Nov 28 03:48:04 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 27 Nov 2008 18:48:04 -0800
Subject: [IronPython] Startup scripts
In-Reply-To: <8759213f0811271322v3eb158bfr39005634385869eb@mail.gmail.com>
References: <8759213f0811271322v3eb158bfr39005634385869eb@mail.gmail.com>
Message-ID: <d2155e360811271848n336c5ac0rb72fd914f884b3d1@mail.gmail.com>

The Python standard is to use "site.py" to load custom startup code; this
file is run automatically at startup.  It's located in the Lib subdirectory
of the directory containing the interpreter exe.  This works under both
CPython and IronPython.

On Thu, Nov 27, 2008 at 1:22 PM, Richard Bowen <toolsack at gmail.com> wrote:

> Hi
>
> I have a simple question that I'm hoping has an answer I'm looking for. I'd
> like to have a startup script to seamlessly run before running a
> specified script.
>
> Eg I can have a script/module that defines foo() and call on startup
>
> IRONPYTHONSTARTUP=start.py
>
> then when I run ipy I can call foo() straight on the command line.
>
> However when running a command or script I have to re-import the module:
>
> ipy.exe  -c "import start; from start import *;foo()"
>
> what I'd like to be able to do is:
>
> ipy.exe -c "foo()"
>
> is that possible? (I have a .bat file that makes it work, but I'd like
> to avoid if possible)
>
> thanks
> Richard
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081127/bc9881d4/attachment.html>

From chenrong2003 at gmail.com  Fri Nov 28 08:07:36 2008
From: chenrong2003 at gmail.com (=?ISO-2022-JP?B?TmVpbCgbJEJMWkxuOFEbKEIp?=)
Date: Fri, 28 Nov 2008 15:07:36 +0800
Subject: [IronPython] clr assembly reference error in Ipy / Silverlight
	(but works in ipy)
In-Reply-To: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
References: <20ab7c020811262135r719b2755j827ee1c821af994d@mail.gmail.com>
Message-ID: <26756bf60811272307s4dd27572hb1af1066c348c003@mail.gmail.com>

Well, I guess there is another issue which will possibly cause your
error message.

With chiron, if you need to reference an additional assembly, you also
need to modify the AppManifest.xaml file by hand and add an entry to
it, like this:

  <Deployment.Parts>
    <!-- Add additional assemblies here -->
    <AssemblyPart Source="Microsoft.Scripting.Silverlight.dll" />
    <AssemblyPart Source="Microsoft.Scripting.ExtensionAttribute.dll" />
    <AssemblyPart Source="Microsoft.Scripting.Core.dll" />
    <AssemblyPart Source="Microsoft.Scripting.dll" />
    <AssemblyPart Source="IronPython.dll" />
    <AssemblyPart Source="IronPython.Modules.dll" />
    <AssemblyPart Source="System.Windows.Controls.Data.dll" />
  </Deployment.Parts>

Best Regards,
Neil Chen

On Thu, Nov 27, 2008 at 1:35 PM, Nummers <danummer at gmail.com> wrote:
> Just getting going on Ipy / Silverlight and hit a roadblock.
>
> This works on ipy but gives an error w/ Ipy in Silverlight (IOError: Could
> not add reference to assembly API.dll).
>
> import clr
> clr.AddReference('API.dll')
> from OEC.API import *
> from OEC.DATA import *
>
> same kind of error with:
> clr.AddReference("API, Version=3.2.0.0, Culture=neutral,
> PublicKeyToken=b6b45f27e2749b17")
> and with:
> clr.LoadAssemblyByName("API, Version=3.2.0.0, Culture=neutral,
> PublicKeyToken=b6b45f27e2749b17")
>
> Now, this gives no error:
> clr.AddReferenceToFile("API.dll")
> However the imports fail (ImportError: No module named OEC.API
>
> Not too much experience loading assemblies but, as I said, all is well in
> ipy.
>
> Hope I'm just doing something stooopid.
>
> Very much appreciate any help!
>
> Dano
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


From glenn.k.jones+ipy at gmail.com  Fri Nov 28 12:36:13 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Fri, 28 Nov 2008 11:36:13 +0000
Subject: [IronPython] Event unhooking and IPy2
Message-ID: <2679f6510811280336t2aaca6b7pcdce1b206aa8f4a9@mail.gmail.com>

In Resolver One on IronPython 1, we have code to unhook events that uses an
object that is equal to everything like this:
e = EqualToAll()
for _ in range(100):
    event -= e

What we have discovered when we run under IPy2, is that the __eq__ method on
EqualToAll is only called when the target of the event is a lambda, a
function or a callable object but not when it's a method.

Is there a better way to unhook all events or get a list of currently
subscribed targets? For the moment, we're going to wrap our event targets in
lambdas as a way to move forward, but the whole EqualToAll and arbitrary
looping seems a little dirty anyway.

Thanks
Glenn & Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081128/4064120b/attachment.html>

From fuzzyman at voidspace.org.uk  Fri Nov 28 12:39:35 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 28 Nov 2008 11:39:35 +0000
Subject: [IronPython] Event unhooking and IPy2
In-Reply-To: <2679f6510811280336t2aaca6b7pcdce1b206aa8f4a9@mail.gmail.com>
References: <2679f6510811280336t2aaca6b7pcdce1b206aa8f4a9@mail.gmail.com>
Message-ID: <492FD877.2040108@voidspace.org.uk>

Just as a follow up to this - the reason for the hack below is that 
subscribing to events from IronPython is still causing our UI objects 
(and their whole object graphs) to not be garbage collected. This was a 
brute force way of clearing out subscribed events so that unneeded UI 
components can then be garbage collected.

A 'RemoveAll' trick for event handlers, or IronPython's cache of 
handlers to delegates, would save us a lot of work.

Michael Foord

Glenn Jones wrote:
> In Resolver One on IronPython 1, we have code to unhook events that 
> uses an object that is equal to everything like this:
> e = EqualToAll()
> for _ in range(100):
>     event -= e
>
> What we have discovered when we run under IPy2, is that the __eq__ 
> method on EqualToAll is only called when the target of the event is a 
> lambda, a function or a callable object but not when it's a method.
>
> Is there a better way to unhook all events or get a list of currently 
> subscribed targets? For the moment, we're going to wrap our event 
> targets in lambdas as a way to move forward, but the whole EqualToAll 
> and arbitrary looping seems a little dirty anyway.
>
> Thanks
> Glenn & Will
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/



From glenn.k.jones+ipy at gmail.com  Fri Nov 28 14:00:47 2008
From: glenn.k.jones+ipy at gmail.com (Glenn Jones)
Date: Fri, 28 Nov 2008 13:00:47 +0000
Subject: [IronPython] Blocker: ProcessDialogKey on TextBox subclass
Message-ID: <2679f6510811280500s55133e6fv7156b5f04aaac8af@mail.gmail.com>

Hi All,

Here is a little app that illustrates an issue that we've just discovered:
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------
import clr
clr.AddReference('System.Windows.Forms')
clr.AddReference('IronPython')

from System.Windows.Forms import Form, Application, TextBox

class MyTextBox(TextBox):
    def ProcessDialogKey(self, key):
        print key
        #super(MyTextBox, self).ProcessDialogKey(key) # Fails with a stack
overflow
        #TextBox.ProcessDialogKey(self, key) # Fails with:
Microsoft.Scripting.ArgumentTypeException: cannot access protected member
ProcessDialogKey without a python subclass of TextBoxBase

class ThisApp(Form):

    def __init__(self):
        Form.__init__(self)
        tb = MyTextBox()
        self.Controls.Add(tb)
        Application.Run(self)


def main():
    f = ThisApp()


if __name__ == '__main__':
    main()
---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------

Uncommenting either of the two commented lines produces the results on that
line when a key is pressed in the text box. The second method of calling
ProcessDialogKey worked in IPy 1.

This is likely to block our progress on porting Resolver One to IPy2 unless
there is a different way of accomplishing the same thing.

Thanks
Glenn & Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081128/0a405734/attachment.html>

From dan.eloff at gmail.com  Fri Nov 28 16:56:34 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Fri, 28 Nov 2008 10:56:34 -0500
Subject: [IronPython] Blocker: ProcessDialogKey on TextBox subclass
In-Reply-To: <2679f6510811280500s55133e6fv7156b5f04aaac8af@mail.gmail.com>
References: <2679f6510811280500s55133e6fv7156b5f04aaac8af@mail.gmail.com>
Message-ID: <4817b6fc0811280756p3c4d89f6v8e8afe62d941a9d0@mail.gmail.com>

On Fri, Nov 28, 2008 at 8:00 AM, Glenn Jones
<glenn.k.jones+ipy at gmail.com> wrote:
> This is likely to block our progress on porting Resolver One to IPy2 unless
> there is a different way of accomplishing the same thing.
>

How about clr.StrongBox[TextBox](self).ProcessDialogKey(key) ? I
really have no idea what StrongBox does or how it works, but this
seems to call TextBox.ProcessDialogKey.

-Dan


From toolsack at gmail.com  Fri Nov 28 21:47:16 2008
From: toolsack at gmail.com (Richard Bowen)
Date: Fri, 28 Nov 2008 20:47:16 +0000
Subject: [IronPython] Startup scripts
In-Reply-To: <d2155e360811271848n336c5ac0rb72fd914f884b3d1@mail.gmail.com>
References: <8759213f0811271322v3eb158bfr39005634385869eb@mail.gmail.com>
	<d2155e360811271848n336c5ac0rb72fd914f884b3d1@mail.gmail.com>
Message-ID: <8759213f0811281247p3d9a2b1eld3489e477e36a239@mail.gmail.com>

thanks. I knew about site.py, but it wont work for me as don't want to touch
peoples global library, and I have lots of different versions of the lib on
any one box, installed by xcopy.

Is there any other way?

Richard



On Fri, Nov 28, 2008 at 2:48 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> The Python standard is to use "site.py" to load custom startup code; this
> file is run automatically at startup.  It's located in the Lib subdirectory
> of the directory containing the interpreter exe.  This works under both
> CPython and IronPython.
>
>   On Thu, Nov 27, 2008 at 1:22 PM, Richard Bowen <toolsack at gmail.com>wrote:
>
>>   Hi
>>
>> I have a simple question that I'm hoping has an answer I'm looking for.
>> I'd
>> like to have a startup script to seamlessly run before running a
>> specified script.
>>
>> Eg I can have a script/module that defines foo() and call on startup
>>
>> IRONPYTHONSTARTUP=start.py
>>
>> then when I run ipy I can call foo() straight on the command line.
>>
>> However when running a command or script I have to re-import the module:
>>
>> ipy.exe  -c "import start; from start import *;foo()"
>>
>> what I'd like to be able to do is:
>>
>> ipy.exe -c "foo()"
>>
>> is that possible? (I have a .bat file that makes it work, but I'd like
>> to avoid if possible)
>>
>> thanks
>> Richard
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081128/dd1cc3eb/attachment.html>

From fuzzyman at voidspace.org.uk  Fri Nov 28 22:53:16 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 28 Nov 2008 21:53:16 +0000
Subject: [IronPython] Startup scripts
In-Reply-To: <8759213f0811281247p3d9a2b1eld3489e477e36a239@mail.gmail.com>
References: <8759213f0811271322v3eb158bfr39005634385869eb@mail.gmail.com>	<d2155e360811271848n336c5ac0rb72fd914f884b3d1@mail.gmail.com>
	<8759213f0811281247p3d9a2b1eld3489e477e36a239@mail.gmail.com>
Message-ID: <4930684C.3000701@voidspace.org.uk>

Richard Bowen wrote:
>  
> thanks. I knew about site.py, but it wont work for me as don't want to 
> touch peoples global library, and I have lots of different versions of 
> the lib on any one box, installed by xcopy.
>  
> Is there any other way?
>  

To be honest your needs are pretty custom. site.py *is* the mechanism 
that Python provides for that kind of situation. Why not create a custom 
executable (instead of ipy.exe) that does what you need?

Michael Foord

> Richard
>
>
>  
> On Fri, Nov 28, 2008 at 2:48 AM, Curt Hagenlocher 
> <curt at hagenlocher.org <mailto:curt at hagenlocher.org>> wrote:
>
>     The Python standard is to use "site.py" to load custom startup
>     code; this file is run automatically at startup.  It's located in
>     the Lib subdirectory of the directory containing the interpreter
>     exe.  This works under both CPython and IronPython.
>
>     On Thu, Nov 27, 2008 at 1:22 PM, Richard Bowen <toolsack at gmail.com
>     <mailto:toolsack at gmail.com>> wrote:
>
>         Hi
>
>         I have a simple question that I'm hoping has an answer I'm
>         looking for. I'd
>         like to have a startup script to seamlessly run before running a
>         specified script.
>
>         Eg I can have a script/module that defines foo() and call on
>         startup
>
>         IRONPYTHONSTARTUP=start.py
>
>         then when I run ipy I can call foo() straight on the command line.
>
>         However when running a command or script I have to re-import
>         the module:
>
>         ipy.exe  -c "import start; from start import *;foo()"
>
>         what I'd like to be able to do is:
>
>         ipy.exe -c "foo()"
>
>         is that possible? (I have a .bat file that makes it work, but
>         I'd like
>         to avoid if possible)
>
>         thanks
>
>         Richard
>          
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From kamil at dworakowski.name  Sat Nov 29 22:07:12 2008
From: kamil at dworakowski.name (Kamil Dworakowski)
Date: Sat, 29 Nov 2008 21:07:12 +0000
Subject: [IronPython] Some observations about parallel import and
	Silverlight
In-Reply-To: <4817b6fc0811251555y3122a946l480388cd689b6340@mail.gmail.com>
References: <4817b6fc0811251555y3122a946l480388cd689b6340@mail.gmail.com>
Message-ID: <93fc29d60811291307l3d8406c9te6d43fe3cbde30ef@mail.gmail.com>

Awesome news!  Resolver One is currently being ported to IronPython
2.0 and I can't wait to try parallel importing again.

Do you remember what tweak did you have to make to the dependency
graph? Dependency finder should ignore imports that are inside if
statements.

I remember that you can pass list of modules to ignore, was it not enough?

On Tue, Nov 25, 2008 at 11:55 PM, Dan Eloff <dan.eloff at gmail.com> wrote:
> Thanks to the excellent work of Kamil
> (http://github.com/luntain/ipy-parallel-import/tree/master), and the
> help of Jimmy I now have importing being done in parallel in 4 threads
> in Silverlight.
>
> I had to restructure my code a little to reduce circular imports (not
> a bad thing to do anyway) and I had to hand-tweak the dependency graph
> to deal with conditional imports and other difficult to track
> dependencies.
>
> The result was better than I could have hoped for. I'm seeing 43%
> faster loading on my dual-core development pc. I used to have blank
> screen at start that made you wonder if the browser has frozen. But
> now the browser is responsive and I have a nice working progress bar.
> But that's not the best news.
>
> The kicker is that the benefit is even larger on slow single core
> machines with dialup internet. I posted a while back on this list that
> IE does not immediately send an asynchronous request. It waits until
> it's UI thread is idle (which doesn't happen if your importing modules
> like crazy on it.) So the net effect was the application loads (about
> 28 seconds on a P4 2ghz) and then it sends the request, waits for the
> response (which is big in my case), and processes it - all in order.
> So if that takes another 30 seconds, you have nearly 1 minute of load
> time. With the UI thread mostly idle now, this happens in parallel to
> the importing, and the overall load time drops by a whopping 45%.
>
> In the words of my generation - w00t!
>
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From kamil at dworakowski.name  Sat Nov 29 22:15:43 2008
From: kamil at dworakowski.name (Kamil Dworakowski)
Date: Sat, 29 Nov 2008 21:15:43 +0000
Subject: [IronPython] Event unhooking and IPy2
In-Reply-To: <492FD877.2040108@voidspace.org.uk>
References: <2679f6510811280336t2aaca6b7pcdce1b206aa8f4a9@mail.gmail.com>
	<492FD877.2040108@voidspace.org.uk>
Message-ID: <93fc29d60811291315r17da962avc82789baabc75029@mail.gmail.com>

On Fri, Nov 28, 2008 at 11:39 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Just as a follow up to this - the reason for the hack below is that
> subscribing to events from IronPython is still causing our UI objects (and
> their whole object graphs) to not be garbage collected.

To be fair, we have no reason to belive it is IronPython's fault. The
bug that event handlers would prevent garbage collection was fixed,
and we were able to remove *some* of the event nuking.


From pavloutefkros at gmail.com  Sun Nov 30 00:55:00 2008
From: pavloutefkros at gmail.com (Tefkros)
Date: Sun, 30 Nov 2008 01:55:00 +0200
Subject: [IronPython] Ironpython and Compact .Net
Message-ID: <4931D654.2020106@gmail.com>

Hello,

Please forgive my ignorance but I would like to know if it's possible 
and if it is, how, to use compact .net framework with ironpython.
I 'd like to write applications for windows mobiles and since the make 
use of .net, ironpython seems to fit in. I 'm well aware of the fact that
not all .net libraries are available but i guess there is a work-around. 
I also suspect that speed would be a problem.
Truth be told I'm not really into ironpython but i'm into cpython and 
I'm more than willing to give ipy a try.
So... anyone?

Thanks!



From dan.eloff at gmail.com  Sun Nov 30 01:33:35 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Sat, 29 Nov 2008 19:33:35 -0500
Subject: [IronPython] Some observations about parallel import and
	Silverlight
In-Reply-To: <93fc29d60811291307l3d8406c9te6d43fe3cbde30ef@mail.gmail.com>
References: <4817b6fc0811251555y3122a946l480388cd689b6340@mail.gmail.com>
	<93fc29d60811291307l3d8406c9te6d43fe3cbde30ef@mail.gmail.com>
Message-ID: <4817b6fc0811291633j3cb8a3bek77bb659aa16c5d98@mail.gmail.com>

On Sat, Nov 29, 2008 at 4:07 PM, Kamil Dworakowski
<kamil at dworakowski.name> wrote:
> Awesome news!  Resolver One is currently being ported to IronPython
> 2.0 and I can't wait to try parallel importing again.
>
> Do you remember what tweak did you have to make to the dependency
> graph? Dependency finder should ignore imports that are inside if
> statements.
>

I think that was the trouble, I had to add dependencies for the
imports that were conditional (but always executed). There were also
some circular dependencies that were too difficult to break, so I
removed some dependencies in a few cases. But overall it worked great.

-Dan


From curt at hagenlocher.org  Sun Nov 30 01:53:34 2008
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Sat, 29 Nov 2008 16:53:34 -0800
Subject: [IronPython] Ironpython and Compact .Net
In-Reply-To: <4931D654.2020106@gmail.com>
References: <4931D654.2020106@gmail.com>
Message-ID: <d2155e360811291653l454a4256hbb904d94cb76a2f2@mail.gmail.com>

Alas, IronPython currently requires the use of the "Reflection.Emit"
library, and the .NET compact framework doesn't yet support this.

On Sat, Nov 29, 2008 at 3:55 PM, Tefkros <pavloutefkros at gmail.com> wrote:

> Hello,
>
> Please forgive my ignorance but I would like to know if it's possible and
> if it is, how, to use compact .net framework with ironpython.
> I 'd like to write applications for windows mobiles and since the make use
> of .net, ironpython seems to fit in. I 'm well aware of the fact that
> not all .net libraries are available but i guess there is a work-around. I
> also suspect that speed would be a problem.
> Truth be told I'm not really into ironpython but i'm into cpython and I'm
> more than willing to give ipy a try.
> So... anyone?
>
> Thanks!
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081129/006e8cc6/attachment.html>

From dan.eloff at gmail.com  Sun Nov 30 04:04:06 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Sat, 29 Nov 2008 22:04:06 -0500
Subject: [IronPython] __init__ ignored in favor of base class constructor? -
	blocker
Message-ID: <4817b6fc0811291904v4c284026o3fa7093096a056b@mail.gmail.com>

In the 2.1 branch of 43741, it seems there is trouble subclassing a
CLR class that has protected constructors.

# Silverlight Toolkit
import clr
clr.AddReferenceToFile('Microsoft.Windows.Controls.Theming.dll')
from Microsoft.Windows.Controls.Theming import Theme

class MyTheme(Theme):
    def __init__(self):
        raise ValueError

MyTheme()

TypeError: MyTheme() takes at least 2 arguments (1 given)

In fact you can try MyTheme(1,2,3) and get the same error. You can
also not define an __init__ on MyTheme and get the same error.

This would lead me to suspect it's trying the whole time to call the
protected 2 argument constructor, and is ignoring the Python __init__
method. This is a blocker as I've not found any way around it that
will work in silverlight.

By the way, should I should I be using the 2.0 branch rather? I expect
2.1 will be released long before I make my first release, so I thought
that's probably the way to go.

Thanks,
-Dan


From yashgt at gmail.com  Sun Nov 30 12:59:39 2008
From: yashgt at gmail.com (Yash Ganthe)
Date: Sun, 30 Nov 2008 17:29:39 +0530
Subject: [IronPython] app.config for ipy script?
Message-ID: <4f428e7b0811300359r2b51f838y81e8f9adb612ea34@mail.gmail.com>

I would like to invoke WCF service and hence would like to define the
endpoints in a config file. If I am running the python script as :
C:\Mytests>ipy program.py
Where should the app.config file be placed?

Thanks,
Yash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081130/0b12529a/attachment.html>

From fuzzyman at voidspace.org.uk  Sun Nov 30 14:30:13 2008
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 30 Nov 2008 13:30:13 +0000
Subject: [IronPython] __init__ ignored in favor of base class
 constructor? -	blocker
In-Reply-To: <4817b6fc0811291904v4c284026o3fa7093096a056b@mail.gmail.com>
References: <4817b6fc0811291904v4c284026o3fa7093096a056b@mail.gmail.com>
Message-ID: <49329565.8030301@voidspace.org.uk>

Dan Eloff wrote:
> In the 2.1 branch of 43741, it seems there is trouble subclassing a
> CLR class that has protected constructors.
>
> # Silverlight Toolkit
> import clr
> clr.AddReferenceToFile('Microsoft.Windows.Controls.Theming.dll')
> from Microsoft.Windows.Controls.Theming import Theme
>
> class MyTheme(Theme):
>     def __init__(self):
>         raise ValueError
>
> MyTheme()
>
> TypeError: MyTheme() takes at least 2 arguments (1 given)
>
> In fact you can try MyTheme(1,2,3) and get the same error. You can
> also not define an __init__ on MyTheme and get the same error.
>
> This would lead me to suspect it's trying the whole time to call the
> protected 2 argument constructor, and is ignoring the Python __init__
> method. This is a blocker as I've not found any way around it that
> will work in silverlight.
>   

Hello Dan,

I can't find this assembly to experiment - but when you subclass a .NET 
type in IronPython you override the constructor by overriding '__new__' 
and not '__init__'. Perhaps this is the cause of your problem? (If the 
default constructor takes two arguments then merely supplying an 
__init__ method that only takes one won't stop the default two argument 
constructor being called.)

Michael

> By the way, should I should I be using the 2.0 branch rather? I expect
> 2.1 will be released long before I make my first release, so I thought
> that's probably the way to go.
>
> Thanks,
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog




From dan.eloff at gmail.com  Sun Nov 30 16:42:51 2008
From: dan.eloff at gmail.com (Dan Eloff)
Date: Sun, 30 Nov 2008 10:42:51 -0500
Subject: [IronPython] __init__ ignored in favor of base class
	constructor? - blocker
In-Reply-To: <49329565.8030301@voidspace.org.uk>
References: <4817b6fc0811291904v4c284026o3fa7093096a056b@mail.gmail.com>
	<49329565.8030301@voidspace.org.uk>
Message-ID: <4817b6fc0811300742i210e9a0at834b57803dd2e899@mail.gmail.com>

On Sun, Nov 30, 2008 at 8:30 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Hello Dan,
>
> I can't find this assembly to experiment - but when you subclass a .NET type
> in IronPython you override the constructor by overriding '__new__' and not
> '__init__'. Perhaps this is the cause of your problem? (If the default
> constructor takes two arguments then merely supplying an __init__ method
> that only takes one won't stop the default two argument constructor being
> called.)
>

I don't think I've ever subclassed a .NET type that has a default
constructor taking an argument, hopefully the problem here is with me
and not IronPython :) I thought __new__ might be the one to use, but I
got these errors with __new__:

class MyTheme(Theme):
    def __new__(cls):
        return Theme.__new__(cls,
Application.GetResourceStream(Uri('theme.xaml', UriKind.Relative)))

TypeError: default __new__ does not take parameters.

If I use:

class MyTheme(Theme):
    def __new__(cls):
        return Theme.__new__(cls)

TypeError: MyTheme() takes at least 2 arguments (1 given)

Back to square one. Do you have some idea what I'm doing wrong here?
The assembly is from the Silverlight Toolkit:
http://www.codeplex.com/Silverlight

-Dan


From Tomas.Matousek at microsoft.com  Sun Nov 30 23:27:32 2008
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Sun, 30 Nov 2008 14:27:32 -0800
Subject: [IronPython] app.config for ipy script?
In-Reply-To: <4f428e7b0811300359r2b51f838y81e8f9adb612ea34@mail.gmail.com>
References: <4f428e7b0811300359r2b51f838y81e8f9adb612ea34@mail.gmail.com>
Message-ID: <F58FE69873E2D5459B72C347DE1582412B2216D953@NA-EXMSG-C112.redmond.corp.microsoft.com>

You need to edit ipy.exe.config next to ipy.exe.

Tomas

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Yash Ganthe
Sent: Sunday, November 30, 2008 4:00 AM
To: users at lists.ironpython.com
Subject: [IronPython] app.config for ipy script?

I would like to invoke WCF service and hence would like to define the endpoints in a config file. If I am running the python script as :
C:\Mytests>ipy program.py
Where should the app.config file be placed?

Thanks,
Yash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20081130/187b8556/attachment.html>