From fuzzyman at voidspace.org.uk  Thu Nov  1 01:26:15 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 01 Nov 2007 00:26:15 +0000
Subject: [IronPython] [python] Re: Import decimal failure with Turkish
 Locale (IP 1.1)
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <4728BA9E.8040107@resolversystems.com>	<d2155e360710311115r37e54cc4y3fe2a54bfaf30ee9@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <47291D27.6030207@voidspace.org.uk>

Hello Dino (etc),

Hmm... as usual it is a harder problem than it first seems.

Curt's suggestion is helpful (and will probably get us out of a fix - so 
thanks), but patching the standard library (which we do distribute 
separately) is something we had hoped to avoid. To be honest that code 
in 'decimal.py' seems odd and a weird way of achieving what it does.

However - string literals in code should either be in ascii *or* in a 
declared encoding. Some way out of this situation would be nice... 
(Thinking subclasses of strings...)

Michael
http://www.manning.com/foord

Dino Viehland wrote:
> This would have been my suggestion - this is a tough issue - do you have an expected behavior you'd like to see?  I can imagine a few:
>         1. IronPython supports both byte-array strings and normal strings, and therefore "it just works"
>         2. IronPython never uses the current locale for string operations, effectively breaking Unicode
>         3. IronPython does a conversion into ASCII before doing attribute access, and somehow converts the upper case turkish I into an ASCII turkish I.
>
> Those 3 options are problematic at best.  An easier solution would be what Curt suggested (I'm assuming you're redistributing the standard library yourself).  I was also thinking that there should be a preexisting way to do this in Python but I don't see an upper function that lets you specify the locale or force it to do so against an invariance culture.  Maybe just a call to string.translate instead?
>
>
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
> Sent: Wednesday, October 31, 2007 11:15 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1)
>
> On 10/31/07, Michael Foord <michael.foord at resolversystems.com> wrote:
>
> The issue is because one of the method names is '_round_ceiling'. In the
> Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in
> Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the
> lookup of the corresponding global fails.
>
> In CPython the name is a byte-string, and so '.upper' just uses the
> ascii uppercase rather than the locale sensitive version - so we see
> failing to import 'decimal.py' as an IronPython bug. As this badly
> impacts Resolver we would *love* to see this fixed soon...
>
> Why not change decimal.py to use ToUpperInvariant()?  Are you sharing the file with CPython?
>
> --
> Curt Hagenlocher
> curt at hagenlocher.org
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From sanxiyn at gmail.com  Thu Nov  1 02:46:12 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 1 Nov 2007 10:46:12 +0900
Subject: [IronPython] Linux Support
In-Reply-To: <cfb58d850710310122xbac17adk32964a43b09e0378@mail.gmail.com>
References: <cfb58d850710310122xbac17adk32964a43b09e0378@mail.gmail.com>
Message-ID: <5b0248170710311846p3cda2f1q41885d5b60a7ee40@mail.gmail.com>

2007/10/31, Evan Klitzke <evan at yelp.com>:
> Then I had problems using modules in the standard library. This post
> <http://lists.ironpython.com/pipermail/users-ironpython.com/2006-July/002787.html>
> indicates that I should be able to import most modules from CPython.
> So I set my IRONPYTHONPATH using Unix path convention and nothing
> works. Eventually I figure out that I need to use the Windows
> convention and use semicolons as the path separator (which is
> inconvenient because semicolons need to be escaped in bash). After I
> running ipy.exe hangs and I get an IOError (I think it tried to import
> too many

This is definitely a bug. I reported it on the issue tracker.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13618

-- 
Seo Sanghyeon


From sanxiyn at gmail.com  Thu Nov  1 05:26:01 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 1 Nov 2007 13:26:01 +0900
Subject: [IronPython] sys.argv in the interactive console
Message-ID: <5b0248170710312126p15aea73o43ef652c3a1bbf6e@mail.gmail.com>

Using the interactive console,

$ python
>>> import sys
>>> sys.argv
['']

$ ipy # Both 1.1 and 2.0a5
>>> import sys
>>> sys.argv
[]

Believe it or not, some code depends on sys.argv[0] to be always available.

-- 
Seo Sanghyeon


From dinov at exchange.microsoft.com  Thu Nov  1 22:52:22 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 1 Nov 2007 14:52:22 -0700
Subject: [IronPython] [python] Re: Import decimal failure with Turkish
 Locale (IP 1.1)
In-Reply-To: <47291D27.6030207@voidspace.org.uk>
References: <4728BA9E.8040107@resolversystems.com>
	<d2155e360710311115r37e54cc4y3fe2a54bfaf30ee9@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<47291D27.6030207@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ECFF3@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

One option might be a non-technical solution: Instead of you redistributing the library (or modified library) we distribute it w/ IronPython - and then you're just including the combined package.  There's other reasons why it'd be good for us to do this (help, encodings, warnings, etc...).  Unfortunately there's some internal process required before we cross that hurdle that we've simply been putting off.

I'm kicking off the discussions that are necessary to see if we can get this going.  It might take a couple of weeks (or who knows, maybe longer) so a little patience might be required.  Anyway, let me know what you think of that solution.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, October 31, 2007 5:26 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Import decimal failure with Turkish Locale (IP 1.1)

Hello Dino (etc),

Hmm... as usual it is a harder problem than it first seems.

Curt's suggestion is helpful (and will probably get us out of a fix - so
thanks), but patching the standard library (which we do distribute
separately) is something we had hoped to avoid. To be honest that code
in 'decimal.py' seems odd and a weird way of achieving what it does.

However - string literals in code should either be in ascii *or* in a
declared encoding. Some way out of this situation would be nice...
(Thinking subclasses of strings...)

Michael
http://www.manning.com/foord

Dino Viehland wrote:
> This would have been my suggestion - this is a tough issue - do you have an expected behavior you'd like to see?  I can imagine a few:
>         1. IronPython supports both byte-array strings and normal strings, and therefore "it just works"
>         2. IronPython never uses the current locale for string operations, effectively breaking Unicode
>         3. IronPython does a conversion into ASCII before doing attribute access, and somehow converts the upper case turkish I into an ASCII turkish I.
>
> Those 3 options are problematic at best.  An easier solution would be what Curt suggested (I'm assuming you're redistributing the standard library yourself).  I was also thinking that there should be a preexisting way to do this in Python but I don't see an upper function that lets you specify the locale or force it to do so against an invariance culture.  Maybe just a call to string.translate instead?
>
>
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
> Sent: Wednesday, October 31, 2007 11:15 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1)
>
> On 10/31/07, Michael Foord <michael.foord at resolversystems.com> wrote:
>
> The issue is because one of the method names is '_round_ceiling'. In the
> Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in
> Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the
> lookup of the corresponding global fails.
>
> In CPython the name is a byte-string, and so '.upper' just uses the
> ascii uppercase rather than the locale sensitive version - so we see
> failing to import 'decimal.py' as an IronPython bug. As this badly
> impacts Resolver we would *love* to see this fixed soon...
>
> Why not change decimal.py to use ToUpperInvariant()?  Are you sharing the file with CPython?
>
> --
> Curt Hagenlocher
> curt at hagenlocher.org
> _______________________________________________
> 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  Thu Nov  1 22:55:05 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 01 Nov 2007 21:55:05 +0000
Subject: [IronPython] [python] Re: Import decimal failure with Turkish
 Locale (IP 1.1)
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ECFF3@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <4728BA9E.8040107@resolversystems.com>	<d2155e360710311115r37e54cc4y3fe2a54bfaf30ee9@mail.gmail.com>	<7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<47291D27.6030207@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ECFF3@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <472A4B39.10404@voidspace.org.uk>

Dino Viehland wrote:
> One option might be a non-technical solution: Instead of you redistributing the library (or modified library) we distribute it w/ IronPython - and then you're just including the combined package.  There's other reasons why it'd be good for us to do this (help, encodings, warnings, etc...).  Unfortunately there's some internal process required before we cross that hurdle that we've simply been putting off.
>
> I'm kicking off the discussions that are necessary to see if we can get this going.  It might take a couple of weeks (or who knows, maybe longer) so a little patience might be required.  Anyway, let me know what you think of that solution.
>   

Having a 'patched where necessary' distribution of the standard library 
come with IronPython would be *great*.

+1000 to that idea.

:-)

Michael
http://www.manning.com/foord


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, October 31, 2007 5:26 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Import decimal failure with Turkish Locale (IP 1.1)
>
> Hello Dino (etc),
>
> Hmm... as usual it is a harder problem than it first seems.
>
> Curt's suggestion is helpful (and will probably get us out of a fix - so
> thanks), but patching the standard library (which we do distribute
> separately) is something we had hoped to avoid. To be honest that code
> in 'decimal.py' seems odd and a weird way of achieving what it does.
>
> However - string literals in code should either be in ascii *or* in a
> declared encoding. Some way out of this situation would be nice...
> (Thinking subclasses of strings...)
>
> Michael
> http://www.manning.com/foord
>
> Dino Viehland wrote:
>   
>> This would have been my suggestion - this is a tough issue - do you have an expected behavior you'd like to see?  I can imagine a few:
>>         1. IronPython supports both byte-array strings and normal strings, and therefore "it just works"
>>         2. IronPython never uses the current locale for string operations, effectively breaking Unicode
>>         3. IronPython does a conversion into ASCII before doing attribute access, and somehow converts the upper case turkish I into an ASCII turkish I.
>>
>> Those 3 options are problematic at best.  An easier solution would be what Curt suggested (I'm assuming you're redistributing the standard library yourself).  I was also thinking that there should be a preexisting way to do this in Python but I don't see an upper function that lets you specify the locale or force it to do so against an invariance culture.  Maybe just a call to string.translate instead?
>>
>>
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
>> Sent: Wednesday, October 31, 2007 11:15 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1)
>>
>> On 10/31/07, Michael Foord <michael.foord at resolversystems.com> wrote:
>>
>> The issue is because one of the method names is '_round_ceiling'. In the
>> Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in
>> Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the
>> lookup of the corresponding global fails.
>>
>> In CPython the name is a byte-string, and so '.upper' just uses the
>> ascii uppercase rather than the locale sensitive version - so we see
>> failing to import 'decimal.py' as an IronPython bug. As this badly
>> impacts Resolver we would *love* to see this fixed soon...
>>
>> Why not change decimal.py to use ToUpperInvariant()?  Are you sharing the file with CPython?
>>
>> --
>> Curt Hagenlocher
>> curt at hagenlocher.org
>> _______________________________________________
>> 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 exchange.microsoft.com  Thu Nov  1 23:01:58 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 1 Nov 2007 15:01:58 -0700
Subject: [IronPython] [python] Re: Import decimal failure with Turkish
 Locale (IP 1.1)
In-Reply-To: <472A4B39.10404@voidspace.org.uk>
References: <4728BA9E.8040107@resolversystems.com>
	<d2155e360710311115r37e54cc4y3fe2a54bfaf30ee9@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<47291D27.6030207@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ECFF3@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<472A4B39.10404@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ECFF8@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Cool, I'll send out an update after I find out more.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, November 01, 2007 2:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Import decimal failure with Turkish Locale (IP 1.1)

Dino Viehland wrote:
> One option might be a non-technical solution: Instead of you redistributing the library (or modified library) we distribute it w/ IronPython - and then you're just including the combined package.  There's other reasons why it'd be good for us to do this (help, encodings, warnings, etc...).  Unfortunately there's some internal process required before we cross that hurdle that we've simply been putting off.
>
> I'm kicking off the discussions that are necessary to see if we can get this going.  It might take a couple of weeks (or who knows, maybe longer) so a little patience might be required.  Anyway, let me know what you think of that solution.
>

Having a 'patched where necessary' distribution of the standard library
come with IronPython would be *great*.

+1000 to that idea.

:-)

Michael
http://www.manning.com/foord


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, October 31, 2007 5:26 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Import decimal failure with Turkish Locale (IP 1.1)
>
> Hello Dino (etc),
>
> Hmm... as usual it is a harder problem than it first seems.
>
> Curt's suggestion is helpful (and will probably get us out of a fix - so
> thanks), but patching the standard library (which we do distribute
> separately) is something we had hoped to avoid. To be honest that code
> in 'decimal.py' seems odd and a weird way of achieving what it does.
>
> However - string literals in code should either be in ascii *or* in a
> declared encoding. Some way out of this situation would be nice...
> (Thinking subclasses of strings...)
>
> Michael
> http://www.manning.com/foord
>
> Dino Viehland wrote:
>
>> This would have been my suggestion - this is a tough issue - do you have an expected behavior you'd like to see?  I can imagine a few:
>>         1. IronPython supports both byte-array strings and normal strings, and therefore "it just works"
>>         2. IronPython never uses the current locale for string operations, effectively breaking Unicode
>>         3. IronPython does a conversion into ASCII before doing attribute access, and somehow converts the upper case turkish I into an ASCII turkish I.
>>
>> Those 3 options are problematic at best.  An easier solution would be what Curt suggested (I'm assuming you're redistributing the standard library yourself).  I was also thinking that there should be a preexisting way to do this in Python but I don't see an upper function that lets you specify the locale or force it to do so against an invariance culture.  Maybe just a call to string.translate instead?
>>
>>
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
>> Sent: Wednesday, October 31, 2007 11:15 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1)
>>
>> On 10/31/07, Michael Foord <michael.foord at resolversystems.com> wrote:
>>
>> The issue is because one of the method names is '_round_ceiling'. In the
>> Turkish locale, the uppercase version of this is "ROUND_CE?L?NG" (in
>> Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the
>> lookup of the corresponding global fails.
>>
>> In CPython the name is a byte-string, and so '.upper' just uses the
>> ascii uppercase rather than the locale sensitive version - so we see
>> failing to import 'decimal.py' as an IronPython bug. As this badly
>> impacts Resolver we would *love* to see this fixed soon...
>>
>> Why not change decimal.py to use ToUpperInvariant()?  Are you sharing the file with CPython?
>>
>> --
>> Curt Hagenlocher
>> curt at hagenlocher.org
>> _______________________________________________
>> 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 curt at hagenlocher.org  Thu Nov  1 23:17:12 2007
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 1 Nov 2007 15:17:12 -0700
Subject: [IronPython] [python] Re: Import decimal failure with Turkish
	Locale (IP 1.1)
In-Reply-To: <47291D27.6030207@voidspace.org.uk>
References: <4728BA9E.8040107@resolversystems.com>
	<d2155e360710311115r37e54cc4y3fe2a54bfaf30ee9@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227D8A90ECCEA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<47291D27.6030207@voidspace.org.uk>
Message-ID: <d2155e360711011517u27626262x20ac683881ea6b7@mail.gmail.com>

On 10/31/07, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>
>
> However - string literals in code should either be in ascii *or* in a
> declared encoding. Some way out of this situation would be nice...
> (Thinking subclasses of strings...)


The only place I know of that follows this kind of approach is SQL Server,
where all char fields are associated with a specific sort order.

The original code in Decimal is pretty crazy -- even without the newly
recognized dangers of the "upper" function.

To the best of my knowledge, Turkish is the only locale in which an
unaccented latin character has an upper-case value that's different from
what its uppercase value would be in en-US.

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071101/d044a127/attachment.html>

From dinov at exchange.microsoft.com  Thu Nov  1 23:38:21 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 1 Nov 2007 15:38:21 -0700
Subject: [IronPython] sys.argv in the interactive console
In-Reply-To: <5b0248170710312126p15aea73o43ef652c3a1bbf6e@mail.gmail.com>
References: <5b0248170710312126p15aea73o43ef652c3a1bbf6e@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED01A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the report Seo, I'll fix this for the next release.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Wednesday, October 31, 2007 9:26 PM
To: Discussion of IronPython
Subject: [IronPython] sys.argv in the interactive console

Using the interactive console,

$ python
>>> import sys
>>> sys.argv
['']

$ ipy # Both 1.1 and 2.0a5
>>> import sys
>>> sys.argv
[]

Believe it or not, some code depends on sys.argv[0] to be always available.

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


From dinov at exchange.microsoft.com  Thu Nov  1 23:46:39 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 1 Nov 2007 15:46:39 -0700
Subject: [IronPython] Linux Support
In-Reply-To: <5b0248170710311846p3cda2f1q41885d5b60a7ee40@mail.gmail.com>
References: <cfb58d850710310122xbac17adk32964a43b09e0378@mail.gmail.com>
	<5b0248170710311846p3cda2f1q41885d5b60a7ee40@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED027@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I'll fix this for the next release as well - thanks for the report Evan, and thanks for pointing out Path.PathSeperator in the bug Seo.  It'a always nice to learn something new :).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Wednesday, October 31, 2007 6:46 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Linux Support

2007/10/31, Evan Klitzke <evan at yelp.com>:
> Then I had problems using modules in the standard library. This post
> <http://lists.ironpython.com/pipermail/users-ironpython.com/2006-July/002787.html>
> indicates that I should be able to import most modules from CPython.
> So I set my IRONPYTHONPATH using Unix path convention and nothing
> works. Eventually I figure out that I need to use the Windows
> convention and use semicolons as the path separator (which is
> inconvenient because semicolons need to be escaped in bash). After I
> running ipy.exe hangs and I get an IOError (I think it tried to import
> too many

This is definitely a bug. I reported it on the issue tracker.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13618

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


From anakinnani at hotmail.com  Fri Nov  2 03:44:34 2007
From: anakinnani at hotmail.com (jane janet)
Date: Fri, 2 Nov 2007 02:44:34 +0000
Subject: [IronPython] Howto Create .dll file
Message-ID: <BLU110-W57E7AECAEE236825B2A10AC58D0@phx.gbl>



Hello all,
 
I wanna know how to create .dll file by IronPython.
Please teach me everything I have to do.
 
Thank you
 
All the best
 
_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071102/daddb532/attachment.html>

From sanxiyn at gmail.com  Fri Nov  2 06:50:10 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 2 Nov 2007 14:50:10 +0900
Subject: [IronPython] Importing package with imp
Message-ID: <5b0248170711012250q65acb1bbkce8348675f178e0a@mail.gmail.com>

Importing package with imp module is tested in test_imp_package()
function of test_imp.py. But sys.modules is incorrectly modified by
imp which this test misses...

Okay, if I was not working on some obscure importing hack, I guess no
one would have found this. :(

How to reproduce:

# x/__init__.py
a = 1

# test.py
import imp
imp.load_module('x', None, 'x', ('', '', imp.PKG_DIRECTORY))
import sys
print sys.modules['x'].a

-- 
Seo Sanghyeon


From kf9150 at gmail.com  Fri Nov  2 08:44:34 2007
From: kf9150 at gmail.com (Kelie)
Date: Thu, 1 Nov 2007 21:44:34 -1000
Subject: [IronPython] i thought this is odd: using Interop on Microsoft Word
Message-ID: <42b9a3ff0711020044t5e69ebbct3f398b8e4dd92286@mail.gmail.com>

Hello group,

import clr
clr.AddReference("Microsoft.Office.Interop.Word")
import Microsoft.Office.Interop.Word as Word

_progid_ = "Word.Application"

def get_active_object(progid):
    from System.Runtime.InteropServices import Marshal
    try:
        app = Marshal.GetActiveObject(progid)
    except:
        app = None
    return app
    	
def get_active_application():
	return get_active_object(_progid_)

def get_documents():
    return get_active_application().Documents

if __name__ == '__main__':
    docs = get_documents()
#    print docs[1].FullName # This line causes AttributeError:
                            # 'tuple' object has no attribute 'FullName'
    print docs[1] # returns (Microsoft.Office.Interop.Word.DocumentClass, 1)
    print docs[2] # returns (Microsoft.Office.Interop.Word.DocumentClass, 2)
    print docs[1][0].FullName

This is the code that i tested. For the last couple of lines, i was
expecting that
docs[1] and docs[2] would return the document object instead of a
tuple with the first of its item being the document. Is this the
intended behavior?

Thank you,

-- 
Kelie


From Shri.Borde at microsoft.com  Fri Nov  2 09:14:22 2007
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 2 Nov 2007 01:14:22 -0700
Subject: [IronPython] i thought this is odd: using Interop on Microsoft
 Word
In-Reply-To: <42b9a3ff0711020044t5e69ebbct3f398b8e4dd92286@mail.gmail.com>
References: <42b9a3ff0711020044t5e69ebbct3f398b8e4dd92286@mail.gmail.com>
Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EB6418A0804@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

This could be fixed in IronPython but currently its expected.

docs[1] is calling into this indexer in Microsoft.Office.Interop.Word.dll. The indexer method takes the index by-reference. Ie as "object&" instead of just "object".

.method instance class Microsoft.Office.Interop.Word.Document
        get_Item([in] object&  marshal( struct) Index)
{
} // end of method Documents::get_Item

IronPython thinks that is a ref parameter that could potentially by updated by the call. Hence, it returns it back as one of the return values.

>>> returnValues = docs[1]
>>> returnValues[0] # real return value
Microsoft.Office.Interop.Word.DocumentClass
>>> returnValues[1] # the by-ref param included in the return value.
1
>>>

In C#, you would have to use the "ref" keyword to index into docs. You can simulate this in IronPython as such

>>> docs[clr.Reference[object](1)]
Microsoft.Office.Interop.Word.DocumentClass
>>>

IronPython could fix this by paying attention to the "[in]" in the signature. It appears as a custom attribute of type System.Runtime.InteropServices.InAttribute on the parameter. I have opened http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13641 to track this.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kelie
Sent: Friday, November 02, 2007 12:45 AM
To: IronPython Users
Subject: [IronPython] i thought this is odd: using Interop on Microsoft Word

Hello group,

import clr
clr.AddReference("Microsoft.Office.Interop.Word")
import Microsoft.Office.Interop.Word as Word

_progid_ = "Word.Application"

def get_active_object(progid):
    from System.Runtime.InteropServices import Marshal
    try:
        app = Marshal.GetActiveObject(progid)
    except:
        app = None
    return app

def get_active_application():
        return get_active_object(_progid_)

def get_documents():
    return get_active_application().Documents

if __name__ == '__main__':
    docs = get_documents()
#    print docs[1].FullName # This line causes AttributeError:
                            # 'tuple' object has no attribute 'FullName'
    print docs[1] # returns (Microsoft.Office.Interop.Word.DocumentClass, 1)
    print docs[2] # returns (Microsoft.Office.Interop.Word.DocumentClass, 2)
    print docs[1][0].FullName

This is the code that i tested. For the last couple of lines, i was
expecting that
docs[1] and docs[2] would return the document object instead of a
tuple with the first of its item being the document. Is this the
intended behavior?

Thank you,

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


From sanxiyn at gmail.com  Fri Nov  2 15:56:46 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 2 Nov 2007 23:56:46 +0900
Subject: [IronPython] setattr and module
Message-ID: <5b0248170711020756x5855134bgdb8032a4dcc60acc@mail.gmail.com>

# x.py
# empty

# test.py
import x
setattr(x, 'a', 1)
print x.a

AttributeError: 'module' object has no attribute 'a'

-- 
Seo Sanghyeon


From dinov at exchange.microsoft.com  Fri Nov  2 18:08:08 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 2 Nov 2007 10:08:08 -0700
Subject: [IronPython] setattr and module
In-Reply-To: <5b0248170711020756x5855134bgdb8032a4dcc60acc@mail.gmail.com>
References: <5b0248170711020756x5855134bgdb8032a4dcc60acc@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED1A6@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the report Seo, I'll fix this for a future release (I don't think it'll make it in time for the next one).  The problem here is that we're not currently using DynamicSite's for the setattr built-in function.  Instead we go to a runtime call in PythonOps which is going to attempt to do this via interfaces and DynamicType's.  That's actually not the correct way to set attributes anymore as it doesn't work x-lang (or w/ the member access operators that are defined on ScriptModule).  Luckily get/delete were switched over a while ago so those just work.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Friday, November 02, 2007 7:57 AM
To: Discussion of IronPython
Subject: [IronPython] setattr and module

# x.py
# empty

# test.py
import x
setattr(x, 'a', 1)
print x.a

AttributeError: 'module' object has no attribute 'a'

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


From dinov at exchange.microsoft.com  Fri Nov  2 18:20:50 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 2 Nov 2007 10:20:50 -0700
Subject: [IronPython] Importing package with imp
In-Reply-To: <5b0248170711012250q65acb1bbkce8348675f178e0a@mail.gmail.com>
References: <5b0248170711012250q65acb1bbkce8348675f178e0a@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED1B8@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the report!  It looks like we're just passing the wrong name to Importer.InitializeModule (initPath instead of moduleName).  I'll check-in a fix and update test_imp_package() to check sys.modules.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Thursday, November 01, 2007 10:50 PM
To: Discussion of IronPython
Subject: [IronPython] Importing package with imp

Importing package with imp module is tested in test_imp_package()
function of test_imp.py. But sys.modules is incorrectly modified by
imp which this test misses...

Okay, if I was not working on some obscure importing hack, I guess no
one would have found this. :(

How to reproduce:

# x/__init__.py
a = 1

# test.py
import imp
imp.load_module('x', None, 'x', ('', '', imp.PKG_DIRECTORY))
import sys
print sys.modules['x'].a

--
Seo Sanghyeon
_______________________________________________
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  2 23:25:26 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 02 Nov 2007 22:25:26 +0000
Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import
	Mechanism
Message-ID: <472BA3D6.40709@voidspace.org.uk>

Hello Guys,

Not sure what is going on here, nor whether it indicates a bug in 
IronPython, but it is certainly odd. Loading a CPython interpreter 
through the Python.NET assembly seems to change the IronPython (2a5) 
import machinery.

I have a test module 'xyzz.py' that has an unused name 'wibble'. 
Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a 
name error:

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import xyzz
Traceback (most recent call last):
  File , line 0, in ##7
  File , line 0, in _stub_##2
  File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
NameError: name 'wibble' is not defined


Executing the following code, (using the 'Python.Runtime' assembly from 
Python.NET with Python 2.4):

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import clr
 >>> clr.AddReference('Python.Runtime')
 >>>
 >>> from Python.Runtime import PythonEngine
 >>> engine = PythonEngine()
 >>> engine.Initialize()
 >>>
 >>> import xyzz
Traceback (most recent call last):
  File , line 0, in ##18
  File , line 0, in _stub_##2
  File mscorlib, line unknown, in DefineDynamicAssembly
  File mscorlib, line unknown, in InternalDefineDynamicAssembly
TypeError: Unable to cast object of type 'System.Reflection.Module' to 
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.

Just importing the 'PythonEngine' isn't enough. The problem only happens 
if the PythonEngine is instantiated and initialized.

All the best,


Michael




From dinov at exchange.microsoft.com  Fri Nov  2 23:29:03 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 2 Nov 2007 15:29:03 -0700
Subject: [IronPython] Embedding CPython Messes with the IronPython 2
 Import	Mechanism
In-Reply-To: <472BA3D6.40709@voidspace.org.uk>
References: <472BA3D6.40709@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 3:25 PM
To: Discussion of IronPython
Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism

Hello Guys,

Not sure what is going on here, nor whether it indicates a bug in
IronPython, but it is certainly odd. Loading a CPython interpreter
through the Python.NET assembly seems to change the IronPython (2a5)
import machinery.

I have a test module 'xyzz.py' that has an unused name 'wibble'.
Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
name error:

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import xyzz
Traceback (most recent call last):
  File , line 0, in ##7
  File , line 0, in _stub_##2
  File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
NameError: name 'wibble' is not defined


Executing the following code, (using the 'Python.Runtime' assembly from
Python.NET with Python 2.4):

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import clr
 >>> clr.AddReference('Python.Runtime')
 >>>
 >>> from Python.Runtime import PythonEngine
 >>> engine = PythonEngine()
 >>> engine.Initialize()
 >>>
 >>> import xyzz
Traceback (most recent call last):
  File , line 0, in ##18
  File , line 0, in _stub_##2
  File mscorlib, line unknown, in DefineDynamicAssembly
  File mscorlib, line unknown, in InternalDefineDynamicAssembly
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.

Just importing the 'PythonEngine' isn't enough. The problem only happens
if the PythonEngine is instantiated and initialized.

All the best,


Michael


_______________________________________________
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  2 23:33:09 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 02 Nov 2007 22:33:09 +0000
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <472BA3D6.40709@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <472BA5A5.1000309@voidspace.org.uk>

You asked for it. :-)

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import clr
 >>> clr.AddReference('Python.Runtime')
 >>> from Python.Runtime import PythonEngine
 >>> engine = PythonEngine()
 >>> engine.Initialize()
 >>> import xyzz
Unable to cast object of type 'System.Reflection.Module' to type 
'System.Reflect
ion.Emit.ModuleBuilder'.
   at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
   at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name, 
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet 
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet 
refusedPermissions, Sta
ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
   at System.AppDomain.DefineDynamicAssembly(AssemblyName name, 
AssemblyBuilderA
ccess access)
   at Microsoft.Scripting.Generation.AssemblyGen..ctor(String 
moduleName, String
 outDir, String outFile, AssemblyGenAttributes generationAttributes, 
PortableExe
cutableKinds peKind, ImageFileMachine machine)
   at 
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
mbly(ScriptCode scriptCode)
   at 
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
y(ScriptCode scriptCode)
   at 
Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
ator(ScriptCode scriptCode)
   at 
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
ods()
   at 
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
   at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name, 
ScriptMo
duleKind kind, Scope scope, ScriptCode[] scriptCodes)
   at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name, 
ScriptM
oduleKind kind, Scope scope, CompilerOptions options, ErrorSink 
errorSink, Sourc
eUnit[] sourceUnits)
   at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name, 
SourceU
nit sourceUnit)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext 
context, Stri
ng name, String path)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context, 
String nam
e, String fullName, List path)
   at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context, 
String
name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context, 
String modNa
me, Boolean bottom)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String 
name, Ob
ject globals, Object locals, Object fromList)
   at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String 
, IAttr
ibutesCollection , IAttributesCollection , PythonTuple )
   at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext 
context, T0 a
rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
   at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext 
context, Str
ing fullName)
   at ##18(Object[] , CodeContext )
   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, 
Boolean tryEva
luate)
   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule 
module)
   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String 
code, IScri
ptModule module)
   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
TypeError: Unable to cast object of type 'System.Reflection.Module' to 
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.

 >>>


Dino Viehland wrote:
> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:25 PM
> To: Discussion of IronPython
> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> Hello Guys,
>
> Not sure what is going on here, nor whether it indicates a bug in
> IronPython, but it is certainly odd. Loading a CPython interpreter
> through the Python.NET assembly seems to change the IronPython (2a5)
> import machinery.
>
> I have a test module 'xyzz.py' that has an unused name 'wibble'.
> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
> name error:
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import xyzz
> Traceback (most recent call last):
>   File , line 0, in ##7
>   File , line 0, in _stub_##2
>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
> NameError: name 'wibble' is not defined
>
>
> Executing the following code, (using the 'Python.Runtime' assembly from
> Python.NET with Python 2.4):
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import clr
>  >>> clr.AddReference('Python.Runtime')
>  >>>
>  >>> from Python.Runtime import PythonEngine
>  >>> engine = PythonEngine()
>  >>> engine.Initialize()
>  >>>
>  >>> import xyzz
> Traceback (most recent call last):
>   File , line 0, in ##18
>   File , line 0, in _stub_##2
>   File mscorlib, line unknown, in DefineDynamicAssembly
>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
> TypeError: Unable to cast object of type 'System.Reflection.Module' to
> type 'Sys
> tem.Reflection.Emit.ModuleBuilder'.
>
> Just importing the 'PythonEngine' isn't enough. The problem only happens
> if the PythonEngine is instantiated and initialized.
>
> All the best,
>
>
> Michael
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From dinov at exchange.microsoft.com  Sat Nov  3 00:12:18 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 2 Nov 2007 16:12:18 -0700
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <472BA5A5.1000309@voidspace.org.uk>
References: <472BA3D6.40709@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<472BA5A5.1000309@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I'm not sure what's going on here - I've pinged the CLR dev who owns this feature.  In some patches (at some point) post v2.0.50727.42 there were some changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like it could be a regression related to those changes.  But I don't understand the big picture here.

As a work around you might be able to run in -X:GenerateAsSnippets mode.  In v2.0 this results in about a 10% perf degrade (last time I measured at least, and this was against Pystone) but stops us from generating types to create modules.  So ultimately we won't create an assembly and won't go down this code path.  Of course, that may just be putting off the inevitable.

Another possiblity might be grepping Python.NET to see if they're doing anything weird w/ Module or Assembly objects, although I wouldn't know exactly what to look for.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 3:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism

You asked for it. :-)

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import clr
 >>> clr.AddReference('Python.Runtime')
 >>> from Python.Runtime import PythonEngine
 >>> engine = PythonEngine()
 >>> engine.Initialize()
 >>> import xyzz
Unable to cast object of type 'System.Reflection.Module' to type
'System.Reflect
ion.Emit.ModuleBuilder'.
   at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
   at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions, Sta
ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
   at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
AssemblyBuilderA
ccess access)
   at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
moduleName, String
 outDir, String outFile, AssemblyGenAttributes generationAttributes,
PortableExe
cutableKinds peKind, ImageFileMachine machine)
   at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
mbly(ScriptCode scriptCode)
   at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
y(ScriptCode scriptCode)
   at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
ator(ScriptCode scriptCode)
   at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
ods()
   at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
   at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
ScriptMo
duleKind kind, Scope scope, ScriptCode[] scriptCodes)
   at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
ScriptM
oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
errorSink, Sourc
eUnit[] sourceUnits)
   at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
SourceU
nit sourceUnit)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, Stri
ng name, String path)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String nam
e, String fullName, List path)
   at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
String
name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context,
String modNa
me, Boolean bottom)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String
name, Ob
ject globals, Object locals, Object fromList)
   at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
, IAttr
ibutesCollection , IAttributesCollection , PythonTuple )
   at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
context, T0 a
rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
   at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
context, Str
ing fullName)
   at ##18(Object[] , CodeContext )
   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
Boolean tryEva
luate)
   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
module)
   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
code, IScri
ptModule module)
   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.

 >>>


Dino Viehland wrote:
> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:25 PM
> To: Discussion of IronPython
> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> Hello Guys,
>
> Not sure what is going on here, nor whether it indicates a bug in
> IronPython, but it is certainly odd. Loading a CPython interpreter
> through the Python.NET assembly seems to change the IronPython (2a5)
> import machinery.
>
> I have a test module 'xyzz.py' that has an unused name 'wibble'.
> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
> name error:
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import xyzz
> Traceback (most recent call last):
>   File , line 0, in ##7
>   File , line 0, in _stub_##2
>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
> NameError: name 'wibble' is not defined
>
>
> Executing the following code, (using the 'Python.Runtime' assembly from
> Python.NET with Python 2.4):
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import clr
>  >>> clr.AddReference('Python.Runtime')
>  >>>
>  >>> from Python.Runtime import PythonEngine
>  >>> engine = PythonEngine()
>  >>> engine.Initialize()
>  >>>
>  >>> import xyzz
> Traceback (most recent call last):
>   File , line 0, in ##18
>   File , line 0, in _stub_##2
>   File mscorlib, line unknown, in DefineDynamicAssembly
>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
> TypeError: Unable to cast object of type 'System.Reflection.Module' to
> type 'Sys
> tem.Reflection.Emit.ModuleBuilder'.
>
> Just importing the 'PythonEngine' isn't enough. The problem only happens
> if the PythonEngine is instantiated and initialized.
>
> All the best,
>
>
> Michael
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

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


From dinov at exchange.microsoft.com  Sat Nov  3 00:25:12 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 2 Nov 2007 16:25:12 -0700
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <472BA3D6.40709@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<472BA5A5.1000309@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED36F@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Are you running on a beta of Orcas?  It could be an Orcas bug.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, November 02, 2007 4:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism

I'm not sure what's going on here - I've pinged the CLR dev who owns this feature.  In some patches (at some point) post v2.0.50727.42 there were some changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like it could be a regression related to those changes.  But I don't understand the big picture here.

As a work around you might be able to run in -X:GenerateAsSnippets mode.  In v2.0 this results in about a 10% perf degrade (last time I measured at least, and this was against Pystone) but stops us from generating types to create modules.  So ultimately we won't create an assembly and won't go down this code path.  Of course, that may just be putting off the inevitable.

Another possiblity might be grepping Python.NET to see if they're doing anything weird w/ Module or Assembly objects, although I wouldn't know exactly what to look for.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 3:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism

You asked for it. :-)

IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> import clr
 >>> clr.AddReference('Python.Runtime')
 >>> from Python.Runtime import PythonEngine
 >>> engine = PythonEngine()
 >>> engine.Initialize()
 >>> import xyzz
Unable to cast object of type 'System.Reflection.Module' to type
'System.Reflect
ion.Emit.ModuleBuilder'.
   at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
   at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions, Sta
ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
   at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
AssemblyBuilderA
ccess access)
   at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
moduleName, String
 outDir, String outFile, AssemblyGenAttributes generationAttributes,
PortableExe
cutableKinds peKind, ImageFileMachine machine)
   at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
mbly(ScriptCode scriptCode)
   at
Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
y(ScriptCode scriptCode)
   at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
ator(ScriptCode scriptCode)
   at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
ods()
   at
Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
   at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
ScriptMo
duleKind kind, Scope scope, ScriptCode[] scriptCodes)
   at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
ScriptM
oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
errorSink, Sourc
eUnit[] sourceUnits)
   at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
SourceU
nit sourceUnit)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, Stri
ng name, String path)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String nam
e, String fullName, List path)
   at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
String
name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context,
String modNa
me, Boolean bottom)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String
name, Ob
ject globals, Object locals, Object fromList)
   at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
, IAttr
ibutesCollection , IAttributesCollection , PythonTuple )
   at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
context, T0 a
rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
   at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
context, Str
ing fullName)
   at ##18(Object[] , CodeContext )
   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
Boolean tryEva
luate)
   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
module)
   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
code, IScri
ptModule module)
   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
TypeError: Unable to cast object of type 'System.Reflection.Module' to
type 'Sys
tem.Reflection.Emit.ModuleBuilder'.

 >>>


Dino Viehland wrote:
> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:25 PM
> To: Discussion of IronPython
> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> Hello Guys,
>
> Not sure what is going on here, nor whether it indicates a bug in
> IronPython, but it is certainly odd. Loading a CPython interpreter
> through the Python.NET assembly seems to change the IronPython (2a5)
> import machinery.
>
> I have a test module 'xyzz.py' that has an unused name 'wibble'.
> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
> name error:
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import xyzz
> Traceback (most recent call last):
>   File , line 0, in ##7
>   File , line 0, in _stub_##2
>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
> NameError: name 'wibble' is not defined
>
>
> Executing the following code, (using the 'Python.Runtime' assembly from
> Python.NET with Python 2.4):
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import clr
>  >>> clr.AddReference('Python.Runtime')
>  >>>
>  >>> from Python.Runtime import PythonEngine
>  >>> engine = PythonEngine()
>  >>> engine.Initialize()
>  >>>
>  >>> import xyzz
> Traceback (most recent call last):
>   File , line 0, in ##18
>   File , line 0, in _stub_##2
>   File mscorlib, line unknown, in DefineDynamicAssembly
>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
> TypeError: Unable to cast object of type 'System.Reflection.Module' to
> type 'Sys
> tem.Reflection.Emit.ModuleBuilder'.
>
> Just importing the 'PythonEngine' isn't enough. The problem only happens
> if the PythonEngine is instantiated and initialized.
>
> All the best,
>
>
> Michael
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

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


From fuzzyman at voidspace.org.uk  Sat Nov  3 00:33:25 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 02 Nov 2007 23:33:25 +0000
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ED36F@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <472BA3D6.40709@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<472BA5A5.1000309@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<7AD436E4270DD54A94238001769C2227D8A90ED36F@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <472BB3C5.7020309@voidspace.org.uk>

Dino Viehland wrote:
> Are you running on a beta of Orcas?  It could be an Orcas bug.
>   
I have the Orcas beta installed (which I guess means yes).

I don't have it on my laptop - I can try with that.

Michael

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Friday, November 02, 2007 4:12 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> I'm not sure what's going on here - I've pinged the CLR dev who owns this feature.  In some patches (at some point) post v2.0.50727.42 there were some changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like it could be a regression related to those changes.  But I don't understand the big picture here.
>
> As a work around you might be able to run in -X:GenerateAsSnippets mode.  In v2.0 this results in about a 10% perf degrade (last time I measured at least, and this was against Pystone) but stops us from generating types to create modules.  So ultimately we won't create an assembly and won't go down this code path.  Of course, that may just be putting off the inevitable.
>
> Another possiblity might be grepping Python.NET to see if they're doing anything weird w/ Module or Assembly objects, although I wouldn't know exactly what to look for.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> You asked for it. :-)
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import clr
>  >>> clr.AddReference('Python.Runtime')
>  >>> from Python.Runtime import PythonEngine
>  >>> engine = PythonEngine()
>  >>> engine.Initialize()
>  >>> import xyzz
> Unable to cast object of type 'System.Reflection.Module' to type
> 'System.Reflect
> ion.Emit.ModuleBuilder'.
>    at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>    at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
> Assembly
> BuilderAccess access, String dir, Evidence evidence, PermissionSet
> requiredPermi
> ssions, PermissionSet optionalPermissions, PermissionSet
> refusedPermissions, Sta
> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>    at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
> AssemblyBuilderA
> ccess access)
>    at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
> moduleName, String
>  outDir, String outFile, AssemblyGenAttributes generationAttributes,
> PortableExe
> cutableKinds peKind, ImageFileMachine machine)
>    at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
> mbly(ScriptCode scriptCode)
>    at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
> y(ScriptCode scriptCode)
>    at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
> ator(ScriptCode scriptCode)
>    at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
> ods()
>    at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>    at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
> ScriptMo
> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> ScriptM
> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
> errorSink, Sourc
> eUnit[] sourceUnits)
>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> SourceU
> nit sourceUnit)
>    at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
> context, Stri
> ng name, String path)
>    at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
> String nam
> e, String fullName, List path)
>    at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
> String
> name)
>    at IronPython.Runtime.Importer.ImportModule(CodeContext context,
> String modNa
> me, Boolean bottom)
>    at IronPython.Runtime.Builtin.__import__(CodeContext context, String
> name, Ob
> ject globals, Object locals, Object fromList)
>    at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
> , IAttr
> ibutesCollection , IAttributesCollection , PythonTuple )
>    at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
> context, T0 a
> rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>    at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
> context, Str
> ing fullName)
>    at ##18(Object[] , CodeContext )
>    at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
> Boolean tryEva
> luate)
>    at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>    at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
> module)
>    at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
> code, IScri
> ptModule module)
>    at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>    at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>    at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>    at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> TypeError: Unable to cast object of type 'System.Reflection.Module' to
> type 'Sys
> tem.Reflection.Emit.ModuleBuilder'.
>
>  >>>
>
>
> Dino Viehland wrote:
>   
>> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, November 02, 2007 3:25 PM
>> To: Discussion of IronPython
>> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>>
>> Hello Guys,
>>
>> Not sure what is going on here, nor whether it indicates a bug in
>> IronPython, but it is certainly odd. Loading a CPython interpreter
>> through the Python.NET assembly seems to change the IronPython (2a5)
>> import machinery.
>>
>> I have a test module 'xyzz.py' that has an unused name 'wibble'.
>> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
>> name error:
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>  >>> import xyzz
>> Traceback (most recent call last):
>>   File , line 0, in ##7
>>   File , line 0, in _stub_##2
>>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
>> NameError: name 'wibble' is not defined
>>
>>
>> Executing the following code, (using the 'Python.Runtime' assembly from
>> Python.NET with Python 2.4):
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>  >>> import clr
>>  >>> clr.AddReference('Python.Runtime')
>>  >>>
>>  >>> from Python.Runtime import PythonEngine
>>  >>> engine = PythonEngine()
>>  >>> engine.Initialize()
>>  >>>
>>  >>> import xyzz
>> Traceback (most recent call last):
>>   File , line 0, in ##18
>>   File , line 0, in _stub_##2
>>   File mscorlib, line unknown, in DefineDynamicAssembly
>>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
>> TypeError: Unable to cast object of type 'System.Reflection.Module' to
>> type 'Sys
>> tem.Reflection.Emit.ModuleBuilder'.
>>
>> Just importing the 'PythonEngine' isn't enough. The problem only happens
>> if the PythonEngine is instantiated and initialized.
>>
>> All the best,
>>
>>
>> Michael
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From dinov at exchange.microsoft.com  Sat Nov  3 00:37:50 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 2 Nov 2007 16:37:50 -0700
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <472BB3C5.7020309@voidspace.org.uk>
References: <472BA3D6.40709@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<472BA5A5.1000309@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<7AD436E4270DD54A94238001769C2227D8A90ED36F@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<472BB3C5.7020309@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227D8A90ED38A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Cool, I suspect it'll work fine on your laptop.  Do you have Orcas beta 2 installed or something else?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, November 02, 2007 4:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism

Dino Viehland wrote:
> Are you running on a beta of Orcas?  It could be an Orcas bug.
>
I have the Orcas beta installed (which I guess means yes).

I don't have it on my laptop - I can try with that.

Michael

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Friday, November 02, 2007 4:12 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> I'm not sure what's going on here - I've pinged the CLR dev who owns this feature.  In some patches (at some point) post v2.0.50727.42 there were some changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like it could be a regression related to those changes.  But I don't understand the big picture here.
>
> As a work around you might be able to run in -X:GenerateAsSnippets mode.  In v2.0 this results in about a 10% perf degrade (last time I measured at least, and this was against Pystone) but stops us from generating types to create modules.  So ultimately we won't create an assembly and won't go down this code path.  Of course, that may just be putting off the inevitable.
>
> Another possiblity might be grepping Python.NET to see if they're doing anything weird w/ Module or Assembly objects, although I wouldn't know exactly what to look for.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 3:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> You asked for it. :-)
>
> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
> Copyright (c) Microsoft Corporation. All rights reserved.
>  >>> import clr
>  >>> clr.AddReference('Python.Runtime')
>  >>> from Python.Runtime import PythonEngine
>  >>> engine = PythonEngine()
>  >>> engine.Initialize()
>  >>> import xyzz
> Unable to cast object of type 'System.Reflection.Module' to type
> 'System.Reflect
> ion.Emit.ModuleBuilder'.
>    at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>    at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
> Assembly
> BuilderAccess access, String dir, Evidence evidence, PermissionSet
> requiredPermi
> ssions, PermissionSet optionalPermissions, PermissionSet
> refusedPermissions, Sta
> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>    at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
> AssemblyBuilderA
> ccess access)
>    at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
> moduleName, String
>  outDir, String outFile, AssemblyGenAttributes generationAttributes,
> PortableExe
> cutableKinds peKind, ImageFileMachine machine)
>    at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
> mbly(ScriptCode scriptCode)
>    at
> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
> y(ScriptCode scriptCode)
>    at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
> ator(ScriptCode scriptCode)
>    at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
> ods()
>    at
> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>    at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
> ScriptMo
> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> ScriptM
> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
> errorSink, Sourc
> eUnit[] sourceUnits)
>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
> SourceU
> nit sourceUnit)
>    at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
> context, Stri
> ng name, String path)
>    at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
> String nam
> e, String fullName, List path)
>    at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
> String
> name)
>    at IronPython.Runtime.Importer.ImportModule(CodeContext context,
> String modNa
> me, Boolean bottom)
>    at IronPython.Runtime.Builtin.__import__(CodeContext context, String
> name, Ob
> ject globals, Object locals, Object fromList)
>    at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
> , IAttr
> ibutesCollection , IAttributesCollection , PythonTuple )
>    at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
> context, T0 a
> rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>    at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
> context, Str
> ing fullName)
>    at ##18(Object[] , CodeContext )
>    at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
> Boolean tryEva
> luate)
>    at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>    at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
> module)
>    at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
> code, IScri
> ptModule module)
>    at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>    at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>    at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>    at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> TypeError: Unable to cast object of type 'System.Reflection.Module' to
> type 'Sys
> tem.Reflection.Emit.ModuleBuilder'.
>
>  >>>
>
>
> Dino Viehland wrote:
>
>> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, November 02, 2007 3:25 PM
>> To: Discussion of IronPython
>> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>>
>> Hello Guys,
>>
>> Not sure what is going on here, nor whether it indicates a bug in
>> IronPython, but it is certainly odd. Loading a CPython interpreter
>> through the Python.NET assembly seems to change the IronPython (2a5)
>> import machinery.
>>
>> I have a test module 'xyzz.py' that has an unused name 'wibble'.
>> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
>> name error:
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>  >>> import xyzz
>> Traceback (most recent call last):
>>   File , line 0, in ##7
>>   File , line 0, in _stub_##2
>>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
>> NameError: name 'wibble' is not defined
>>
>>
>> Executing the following code, (using the 'Python.Runtime' assembly from
>> Python.NET with Python 2.4):
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>  >>> import clr
>>  >>> clr.AddReference('Python.Runtime')
>>  >>>
>>  >>> from Python.Runtime import PythonEngine
>>  >>> engine = PythonEngine()
>>  >>> engine.Initialize()
>>  >>>
>>  >>> import xyzz
>> Traceback (most recent call last):
>>   File , line 0, in ##18
>>   File , line 0, in _stub_##2
>>   File mscorlib, line unknown, in DefineDynamicAssembly
>>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
>> TypeError: Unable to cast object of type 'System.Reflection.Module' to
>> type 'Sys
>> tem.Reflection.Emit.ModuleBuilder'.
>>
>> Just importing the 'PythonEngine' isn't enough. The problem only happens
>> if the PythonEngine is instantiated and initialized.
>>
>> All the best,
>>
>>
>> Michael
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

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


From fuzzyman at voidspace.org.uk  Sat Nov  3 01:26:48 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 03 Nov 2007 00:26:48 +0000
Subject: [IronPython] __getattribute__ bug
Message-ID: <472BC048.60100@voidspace.org.uk>

Hello all,

A bug in '__getattribute__' - magic methods should be fetched from the 
class and not go through '__getattribute__'.

This is making a proxy class I'm writing behave very oddly:

The following code:

def DoNothing(*args):
    pass

class Something(object):
    def __getattribute__(self, name):
        print name
        return DoNothing
       
    def __call__(self):
        print 'called'
       
    def __getitem__(self, name):
        raise Exception('w00t!')

    def __setitem__(self, name, value):
        raise Exception('w00t!')
   
s = Something()
s['fish'] = 3


Does this on CPython:

C:\compile\cext\trunk\cext>descriptors.py
Traceback (most recent call last):
  File "C:\compile\cext\trunk\cext\descriptors.py", line 20, in ?
    s['fish'] = 3
  File "C:\compile\cext\trunk\cext\descriptors.py", line 17, in __setitem__
    raise Exception('w00t!')
Exception: w00t!


And this on IronPython 2a5:

C:\compile\cext\trunk\cext>C:\compile\IronPython2\ipy.exe -D 
-X:TabCompletion -X
:ColorfulConsole descriptors.py
__setitem__


To make things odder - if the class 'Something' doesn't have a 
__setitem__ method then an attribute error is correctly raised. For 
'__call__' I am *sometimes* seeing that go through '__getattribute__' 
and sometimes not...

Michael
http://www.manning.com/foord



From fuzzyman at voidspace.org.uk  Sat Nov  3 01:59:52 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 03 Nov 2007 00:59:52 +0000
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ED38A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <472BA3D6.40709@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<472BA5A5.1000309@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<7AD436E4270DD54A94238001769C2227D8A90ED36F@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<472BB3C5.7020309@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED38A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <472BC808.3020209@voidspace.org.uk>

Dino Viehland wrote:
> Cool, I suspect it'll work fine on your laptop.  Do you have Orcas beta 2 installed or something else?
>   

Sorry - have to try this on the laptop tomorrow, time for bed now. On 
this machine I have Visual Studio 2008 beta 2.

Michael

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 4:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> Dino Viehland wrote:
>   
>> Are you running on a beta of Orcas?  It could be an Orcas bug.
>>
>>     
> I have the Orcas beta installed (which I guess means yes).
>
> I don't have it on my laptop - I can try with that.
>
> Michael
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
>> Sent: Friday, November 02, 2007 4:12 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>>
>> I'm not sure what's going on here - I've pinged the CLR dev who owns this feature.  In some patches (at some point) post v2.0.50727.42 there were some changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like it could be a regression related to those changes.  But I don't understand the big picture here.
>>
>> As a work around you might be able to run in -X:GenerateAsSnippets mode.  In v2.0 this results in about a 10% perf degrade (last time I measured at least, and this was against Pystone) but stops us from generating types to create modules.  So ultimately we won't create an assembly and won't go down this code path.  Of course, that may just be putting off the inevitable.
>>
>> Another possiblity might be grepping Python.NET to see if they're doing anything weird w/ Module or Assembly objects, although I wouldn't know exactly what to look for.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, November 02, 2007 3:33 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>>
>> You asked for it. :-)
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>  >>> import clr
>>  >>> clr.AddReference('Python.Runtime')
>>  >>> from Python.Runtime import PythonEngine
>>  >>> engine = PythonEngine()
>>  >>> engine.Initialize()
>>  >>> import xyzz
>> Unable to cast object of type 'System.Reflection.Module' to type
>> 'System.Reflect
>> ion.Emit.ModuleBuilder'.
>>    at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>>    at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
>> Assembly
>> BuilderAccess access, String dir, Evidence evidence, PermissionSet
>> requiredPermi
>> ssions, PermissionSet optionalPermissions, PermissionSet
>> refusedPermissions, Sta
>> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>>    at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
>> AssemblyBuilderA
>> ccess access)
>>    at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
>> moduleName, String
>>  outDir, String outFile, AssemblyGenAttributes generationAttributes,
>> PortableExe
>> cutableKinds peKind, ImageFileMachine machine)
>>    at
>> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
>> mbly(ScriptCode scriptCode)
>>    at
>> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
>> y(ScriptCode scriptCode)
>>    at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
>> ator(ScriptCode scriptCode)
>>    at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
>> ods()
>>    at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>>    at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
>> ScriptMo
>> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
>> ScriptM
>> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
>> errorSink, Sourc
>> eUnit[] sourceUnits)
>>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
>> SourceU
>> nit sourceUnit)
>>    at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
>> context, Stri
>> ng name, String path)
>>    at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
>> String nam
>> e, String fullName, List path)
>>    at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
>> String
>> name)
>>    at IronPython.Runtime.Importer.ImportModule(CodeContext context,
>> String modNa
>> me, Boolean bottom)
>>    at IronPython.Runtime.Builtin.__import__(CodeContext context, String
>> name, Ob
>> ject globals, Object locals, Object fromList)
>>    at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
>> , IAttr
>> ibutesCollection , IAttributesCollection , PythonTuple )
>>    at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
>> context, T0 a
>> rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>>    at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
>> context, Str
>> ing fullName)
>>    at ##18(Object[] , CodeContext )
>>    at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
>> Boolean tryEva
>> luate)
>>    at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>>    at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
>> module)
>>    at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
>> code, IScri
>> ptModule module)
>>    at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>>    at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>>    at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>>    at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
>> TypeError: Unable to cast object of type 'System.Reflection.Module' to
>> type 'Sys
>> tem.Reflection.Emit.ModuleBuilder'.
>>
>>  >>>
>>
>>
>> Dino Viehland wrote:
>>
>>     
>>> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>>> Sent: Friday, November 02, 2007 3:25 PM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>>>
>>> Hello Guys,
>>>
>>> Not sure what is going on here, nor whether it indicates a bug in
>>> IronPython, but it is certainly odd. Loading a CPython interpreter
>>> through the Python.NET assembly seems to change the IronPython (2a5)
>>> import machinery.
>>>
>>> I have a test module 'xyzz.py' that has an unused name 'wibble'.
>>> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
>>> name error:
>>>
>>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>>> Copyright (c) Microsoft Corporation. All rights reserved.
>>>  >>> import xyzz
>>> Traceback (most recent call last):
>>>   File , line 0, in ##7
>>>   File , line 0, in _stub_##2
>>>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
>>> NameError: name 'wibble' is not defined
>>>
>>>
>>> Executing the following code, (using the 'Python.Runtime' assembly from
>>> Python.NET with Python 2.4):
>>>
>>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>>> Copyright (c) Microsoft Corporation. All rights reserved.
>>>  >>> import clr
>>>  >>> clr.AddReference('Python.Runtime')
>>>  >>>
>>>  >>> from Python.Runtime import PythonEngine
>>>  >>> engine = PythonEngine()
>>>  >>> engine.Initialize()
>>>  >>>
>>>  >>> import xyzz
>>> Traceback (most recent call last):
>>>   File , line 0, in ##18
>>>   File , line 0, in _stub_##2
>>>   File mscorlib, line unknown, in DefineDynamicAssembly
>>>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
>>> TypeError: Unable to cast object of type 'System.Reflection.Module' to
>>> type 'Sys
>>> tem.Reflection.Emit.ModuleBuilder'.
>>>
>>> Just importing the 'PythonEngine' isn't enough. The problem only happens
>>> if the PythonEngine is instantiated and initialized.
>>>
>>> All the best,
>>>
>>>
>>> Michael
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From kf9150 at gmail.com  Sat Nov  3 08:32:40 2007
From: kf9150 at gmail.com (Kelie)
Date: Sat, 03 Nov 2007 07:32:40 -0000
Subject: [IronPython] i thought this is odd: using Interop on Microsoft
	Word
In-Reply-To: <50B69702CA6E6D4E849D30CD4989AB8EB6418A0804@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <42b9a3ff0711020044t5e69ebbct3f398b8e4dd92286@mail.gmail.com>
	<50B69702CA6E6D4E849D30CD4989AB8EB6418A0804@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <1194075160.736113.157560@v29g2000prd.googlegroups.com>

On Nov 1, 10:14 pm, Shri Borde <Shri.Bo... at microsoft.com> wrote:
> This could be fixed in IronPython but currently its expected.
>
> docs[1] is calling into this indexer in Microsoft.Office.Interop.Word.dll. The indexer method takes the index by-reference. Ie as "object&" instead of just "object".

Shri, thanks a lot for your detailed explanation.



From fuzzyman at voidspace.org.uk  Sat Nov  3 18:49:01 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 03 Nov 2007 17:49:01 +0000
Subject: [IronPython] [python] Re: Embedding CPython Messes with the
 IronPython 2 Import	Mechanism
In-Reply-To: <7AD436E4270DD54A94238001769C2227D8A90ED38A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <472BA3D6.40709@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227D8A90ED31E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<472BA5A5.1000309@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227D8A90ED35C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<7AD436E4270DD54A94238001769C2227D8A90ED36F@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<472BB3C5.7020309@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227D8A90ED38A@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <472CB48D.2080400@voidspace.org.uk>

Dino Viehland wrote:
> Cool, I suspect it'll work fine on your laptop.  Do you have Orcas beta 2 installed or something else?
>   

Ha, I *do* have VS 2008 on my laptop, but the code *does* work on Vista 
on my Mac (running under parallels) so looks like it is an Orcas issue.

Unfortunately this same issue stops the new import hook (that allows you 
to import CPython modules from IronPython - announcement to follow 
shortly) from working at all.

:-)

Michael
http://www.manning.com/foord

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, November 02, 2007 4:33 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>
> Dino Viehland wrote:
>   
>> Are you running on a beta of Orcas?  It could be an Orcas bug.
>>
>>     
> I have the Orcas beta installed (which I guess means yes).
>
> I don't have it on my laptop - I can try with that.
>
> Michael
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
>> Sent: Friday, November 02, 2007 4:12 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>>
>> I'm not sure what's going on here - I've pinged the CLR dev who owns this feature.  In some patches (at some point) post v2.0.50727.42 there were some changes made to Ref.Emit w.r.t. ModuleBuilder's vs. Modules - this looks like it could be a regression related to those changes.  But I don't understand the big picture here.
>>
>> As a work around you might be able to run in -X:GenerateAsSnippets mode.  In v2.0 this results in about a 10% perf degrade (last time I measured at least, and this was against Pystone) but stops us from generating types to create modules.  So ultimately we won't create an assembly and won't go down this code path.  Of course, that may just be putting off the inevitable.
>>
>> Another possiblity might be grepping Python.NET to see if they're doing anything weird w/ Module or Assembly objects, although I wouldn't know exactly what to look for.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, November 02, 2007 3:33 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Embedding CPython Messes with the IronPython 2 Import Mechanism
>>
>> You asked for it. :-)
>>
>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>> Copyright (c) Microsoft Corporation. All rights reserved.
>>  >>> import clr
>>  >>> clr.AddReference('Python.Runtime')
>>  >>> from Python.Runtime import PythonEngine
>>  >>> engine = PythonEngine()
>>  >>> engine.Initialize()
>>  >>> import xyzz
>> Unable to cast object of type 'System.Reflection.Module' to type
>> 'System.Reflect
>> ion.Emit.ModuleBuilder'.
>>    at System.Reflection.Emit.AssemblyBuilderData.GetInMemoryAssemblyModule()
>>    at System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
>> Assembly
>> BuilderAccess access, String dir, Evidence evidence, PermissionSet
>> requiredPermi
>> ssions, PermissionSet optionalPermissions, PermissionSet
>> refusedPermissions, Sta
>> ckCrawlMark& stackMark, IEnumerable`1 unsafeAssemblyAttributes)
>>    at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
>> AssemblyBuilderA
>> ccess access)
>>    at Microsoft.Scripting.Generation.AssemblyGen..ctor(String
>> moduleName, String
>>  outDir, String outFile, AssemblyGenAttributes generationAttributes,
>> PortableExe
>> cutableKinds peKind, ImageFileMachine machine)
>>    at
>> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateModuleAsse
>> mbly(ScriptCode scriptCode)
>>    at
>> Microsoft.Scripting.Generation.StaticFieldModuleGenerator.CreateSlotFactor
>> y(ScriptCode scriptCode)
>>    at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.CreateStorageAlloc
>> ator(ScriptCode scriptCode)
>>    at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScriptMeth
>> ods()
>>    at
>> Microsoft.Scripting.Generation.OptimizedModuleGenerator.GenerateScope()
>>    at Microsoft.Scripting.ScriptDomainManager.CreateModule(String name,
>> ScriptMo
>> duleKind kind, Scope scope, ScriptCode[] scriptCodes)
>>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
>> ScriptM
>> oduleKind kind, Scope scope, CompilerOptions options, ErrorSink
>> errorSink, Sourc
>> eUnit[] sourceUnits)
>>    at Microsoft.Scripting.ScriptDomainManager.CompileModule(String name,
>> SourceU
>> nit sourceUnit)
>>    at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
>> context, Stri
>> ng name, String path)
>>    at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
>> String nam
>> e, String fullName, List path)
>>    at IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext context,
>> String
>> name)
>>    at IronPython.Runtime.Importer.ImportModule(CodeContext context,
>> String modNa
>> me, Boolean bottom)
>>    at IronPython.Runtime.Builtin.__import__(CodeContext context, String
>> name, Ob
>> ject globals, Object locals, Object fromList)
>>    at _stub_##2(Object[] , DynamicSite`6 , CodeContext , Object , String
>> , IAttr
>> ibutesCollection , IAttributesCollection , PythonTuple )
>>    at Microsoft.Scripting.Actions.DynamicSite`6.Invoke(CodeContext
>> context, T0 a
>> rg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
>>    at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext
>> context, Str
>> ing fullName)
>>    at ##18(Object[] , CodeContext )
>>    at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext,
>> Boolean tryEva
>> luate)
>>    at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>>    at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule
>> module)
>>    at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String
>> code, IScri
>> ptModule module)
>>    at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>>    at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>>    at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>>    at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
>> TypeError: Unable to cast object of type 'System.Reflection.Module' to
>> type 'Sys
>> tem.Reflection.Emit.ModuleBuilder'.
>>
>>  >>>
>>
>>
>> Dino Viehland wrote:
>>
>>     
>>> Could you run with -X:ExceptionDetail and report back the stack trace?  That'll let us know where the exception is actually coming from.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>>> Sent: Friday, November 02, 2007 3:25 PM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] Embedding CPython Messes with the IronPython 2 Import Mechanism
>>>
>>> Hello Guys,
>>>
>>> Not sure what is going on here, nor whether it indicates a bug in
>>> IronPython, but it is certainly odd. Loading a CPython interpreter
>>> through the Python.NET assembly seems to change the IronPython (2a5)
>>> import machinery.
>>>
>>> I have a test module 'xyzz.py' that has an unused name 'wibble'.
>>> Unsurprisingly, attempting to import this into IronPython 2.0a5 raises a
>>> name error:
>>>
>>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>>> Copyright (c) Microsoft Corporation. All rights reserved.
>>>  >>> import xyzz
>>> Traceback (most recent call last):
>>>   File , line 0, in ##7
>>>   File , line 0, in _stub_##2
>>>   File C:\compile\cext\trunk\cext\xyzz.py, line 1, in Initialize
>>> NameError: name 'wibble' is not defined
>>>
>>>
>>> Executing the following code, (using the 'Python.Runtime' assembly from
>>> Python.NET with Python 2.4):
>>>
>>> IronPython console: IronPython 2.0A5 (2.0.11011.00) on .NET 2.0.50727.1378
>>> Copyright (c) Microsoft Corporation. All rights reserved.
>>>  >>> import clr
>>>  >>> clr.AddReference('Python.Runtime')
>>>  >>>
>>>  >>> from Python.Runtime import PythonEngine
>>>  >>> engine = PythonEngine()
>>>  >>> engine.Initialize()
>>>  >>>
>>>  >>> import xyzz
>>> Traceback (most recent call last):
>>>   File , line 0, in ##18
>>>   File , line 0, in _stub_##2
>>>   File mscorlib, line unknown, in DefineDynamicAssembly
>>>   File mscorlib, line unknown, in InternalDefineDynamicAssembly
>>> TypeError: Unable to cast object of type 'System.Reflection.Module' to
>>> type 'Sys
>>> tem.Reflection.Emit.ModuleBuilder'.
>>>
>>> Just importing the 'PythonEngine' isn't enough. The problem only happens
>>> if the PythonEngine is instantiated and initialized.
>>>
>>> All the best,
>>>
>>>
>>> Michael
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> 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  3 22:16:27 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 03 Nov 2007 21:16:27 +0000
Subject: [IronPython] Seamlessly Import CPython Modules from IronPython
Message-ID: <472CE52B.7060502@voidspace.org.uk>

Hello all,

There is a new release of the "CPython Extensions for IronPython" module 
(now called cext) I announced recently. Version 0.1.3 includes several 
small improvements, but also an import hook (created by Seo Sanghyeon) 
that allows you to import CPython binary extensions from IronPython 
using normal import statements!

* `CPython Extensions for IronPython 
<http://www.voidspace.org.uk/ironpython/cpython_extensions.shtml>`_


Michael Foord
http://www.manning.com/foord


From sanxiyn at gmail.com  Sun Nov  4 14:10:17 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Sun, 4 Nov 2007 22:10:17 +0900
Subject: [IronPython] Size of Microsoft.Scripting.dll
Message-ID: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com>

I thought this statistics may be of interest to you.

Size of Microsoft.Scripting.dll in IronPython 2.0 Alpha 2, 3, 4, 5, as
included in the binary release and compiled by Mono 1.2.5 and Mono SVN
r88800.

=========== ====== ====== ====== =======
Compiler    2.0a2  2.0a3  2.0a4  2.0a5
Binary      836960 857440 906592  959512
Mono 1.2.5  870400 892928 943104 1004032
Mono r88800 869376 891904 942592 1003008
=========== ====== ====== ====== =======

Some observations can be made.

1. In all cases, its size is less than 1 MB.
2. It is getting bigger every release. Alpha 5 is about 15% bigger than Alpha 2.
3. Binaries compiled by Microsoft compiler is about 4% smaller than
those by Mono.
4. Differences between Mono 1.2.5 and SVN (soon to be 1.2.6) are negligible.

-- 
Seo Sanghyeon


From curt at hagenlocher.org  Sun Nov  4 22:03:19 2007
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Sun, 4 Nov 2007 14:03:19 -0700
Subject: [IronPython] Tests and IronPython hosting
Message-ID: <d2155e360711041303i7f6906c4kb8c57e882dbd686f@mail.gmail.com>

I'm trying to test some IronPython-hosting code, which is proving a little
tricky because of the inability to create multiple engines.  Is there anyway
to reset the engine to a "just-initialized" state, or to destroy it and
create a new one?  Alternatively, is there a straightforward way to delete a
(published) ScriptModule through the API?  Or is engine.Execute('del
sys.modules['module_name']") my best bet in this regard?

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071104/3f41b608/attachment.html>

From sanxiyn at gmail.com  Mon Nov  5 00:09:23 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Mon, 5 Nov 2007 08:09:23 +0900
Subject: [IronPython] [Mono-dev] Size of Microsoft.Scripting.dll
In-Reply-To: <472DD7DF.3060306@seznam.cz>
References: <5b0248170711040510l4ac5cfs263078a9e4210b31@mail.gmail.com>
	<472DD7DF.3060306@seznam.cz>
Message-ID: <5b0248170711041509x435b25basaa595e7b3f62ff7a@mail.gmail.com>

2007/11/4, Marek Safar <marek.safar at seznam.cz>:
> 4% is really small difference. Is binary compiled with /o+ switch ?

I believe /o is on by default in mcs.

-- 
Seo Sanghyeon


From antont at kyperjokki.fi  Mon Nov  5 15:31:42 2007
From: antont at kyperjokki.fi (Toni Alatalo)
Date: Mon, 5 Nov 2007 16:31:42 +0200 (EET)
Subject: [IronPython] bugs with event handlers in 1.1 and 2.0 alpha 5
Message-ID: <Pine.LNX.4.63.0711051619300.31067@pallas.utanet.fi>

Greetings,

when making a scripting system with IronPython in an embedded context I 
encountered first a bug in 1.1 in re-adding event handlers that had been 
cleared in-between (I wanted that to be able to refresh the py written 
handlers on the fly) - that is reported as bug #13685 
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13685

While making the test case for that I came across a different problem in 
2.0 alpha 5: [#13687] Registering c#-written methods as event handlers 
from ironpy throws TypeError: Object is not callable. 
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13687

A minimalish test case for both is available at 
http://studio.kyperjokki.fi/engine/IronPythonEventReaddition

Curiously enough, 2.0 alpha5 did not work for me in the actual application 
that am developing - the fact that this test case does gives good hope 
that I can get it working there it too (I thought the case is similar..).

This whole GetInvocationList() seems to be a strange beast, it is only 
available in the same class where the event is defined - not to others 
even if whe event is public, nor even in subclasses (yes, not even in 
c#-written subclasses - that's why my first test case that featured a 
WinForm with buttons etc could not be completed (I could not subclass a 
Button that'd have such a method for clearing event callbacks).

The idea in the app that am developing is that user written scripts can 
register event handlers freely, so when clearing them to add new versions 
of the functions there, I don't have references to the funcs that the old 
version of the script had added. Am now using a workaround where the whole 
instance that has the handlers is re-initialized upon such a restart, but 
would like to have the initial plan of just redefining event handlers on 
the fly work too. So hopefully that'll smooth on 2.0.

~Toni


From dinov at exchange.microsoft.com  Tue Nov  6 00:34:00 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 5 Nov 2007 15:34:00 -0800
Subject: [IronPython] Anyone know what DLLs is called on Unix?
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Seo proposed this feature a while ago:

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

and I'm (finally) adding it and wondering what (if anything) we should do if the platform is Unix.   Unfortunately I don't have a Unix box handy but I'm just guessing it's not called DLLs there :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071105/1719c60b/attachment.html>

From nytrokiss at gmail.com  Tue Nov  6 00:37:11 2007
From: nytrokiss at gmail.com (James Matthews)
Date: Tue, 6 Nov 2007 00:37:11 +0100
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <8a6b8e350711051537x4f6d49dft7aee17ac74574513@mail.gmail.com>

.SO

On 11/6/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
>  Seo proposed this feature a while ago:
>
>
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
>
>
>
> and I'm (finally) adding it and wondering what (if anything) we should do
> if the platform is Unix.   Unfortunately I don't have a Unix box handy but
> I'm just guessing it's not called DLLs there J.
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


-- 
http://www.goldwatches.com/
http://www.jewelerslounge.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071106/a58a1093/attachment.html>

From dinov at exchange.microsoft.com  Tue Nov  6 00:39:31 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 5 Nov 2007 15:39:31 -0800
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <8a6b8e350711051537x4f6d49dft7aee17ac74574513@mail.gmail.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<8a6b8e350711051537x4f6d49dft7aee17ac74574513@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Sorry, maybe I wasn't clear - I know they're .so files but is that also the name of the directory where the extensino modules are stored relative to the Python installation?

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of James Matthews
Sent: Monday, November 05, 2007 3:37 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?

.SO
On 11/6/07, Dino Viehland <dinov at exchange.microsoft.com<mailto:dinov at exchange.microsoft.com>> wrote:

Seo proposed this feature a while ago:



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



and I'm (finally) adding it and wondering what (if anything) we should do if the platform is Unix.   Unfortunately I don't have a Unix box handy but I'm just guessing it's not called DLLs there :).

_______________________________________________
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.goldwatches.com/
http://www.jewelerslounge.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071105/cccf29be/attachment.html>

From mclinton at procard.com  Tue Nov  6 00:40:10 2007
From: mclinton at procard.com (Matt Clinton)
Date: Mon, 5 Nov 2007 16:40:10 -0700
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <046C79B13A2D204A9FFB87C2EA406CA702BFE117@glesexcc03.procard.local>

Courtesy of http://en.wikipedia.org/wiki/Dynamic_library,

 

GNU <http://en.wikipedia.org/wiki/GNU> /Linux
<http://en.wikipedia.org/wiki/Linux> , Solaris
<http://en.wikipedia.org/wiki/Solaris_%28operating_system%29>  and other
System V Release 4 <http://en.wikipedia.org/wiki/System_V_Release_4>
derivatives, and BSD <http://en.wikipedia.org/wiki/BSD>  variants

libfoo.a and libfoo.so files are placed in directories like /lib,
/usr/lib or /usr/local/lib. The filenames always start with lib, and end
with .a (archive, static library) or .so (shared object, dynamically
linked library), with an optional interface number. For example
libfoo.so.2 is the second major interface revision of the dynamically
linked library libfoo. Old Unix <http://en.wikipedia.org/wiki/Unix>
versions would use major and minor library revision numbers
(libfoo.so.1.2) while contemporary Unixes will only use major revision
numbers (libfoo.so.1). Dynamically loaded libraries are placed in
/usr/libexec and similar directories. The .la files sometimes found in
the library directories are libtool
<http://en.wikipedia.org/wiki/Libtool>  archives, not usable by the
system as such.

Mac OS X <http://en.wikipedia.org/wiki/Mac_OS_X>  and upwards

The system inherits static library conventions from BSD
<http://en.wikipedia.org/wiki/BSD> , with the library being in a .a
file, and can use .so-style dynamically-linked libraries (with the
.dylib suffix instead). Most libraries in Mac OS X, however, are
"frameworks", placed inside of special directories called "bundles
<http://en.wikipedia.org/wiki/Bundle_%28NEXTSTEP%29> ", which wrap the
library's required files and metadata. For example a library called "My
Neat Library" would be implemented in a bundle called "My Neat
Library.framework".

Microsoft Windows <http://en.wikipedia.org/wiki/Microsoft_Windows> 

*.DLL <http://en.wikipedia.org/wiki/Dynamic-link_library>  files are
dynamically linkable libraries
<http://en.wikipedia.org/wiki/Dynamic-link_library> . Other file name
patterns may be used for specific purpose DLLs, e.g. *.OCX for OCX
<http://en.wikipedia.org/wiki/OCX>  control libraries. The interface
revisions are either encoded in the files, or abstracted away using
COM-object <http://en.wikipedia.org/wiki/Component_object_model>
interfaces. Depending on how they are compiled, *.LIB files can be
either static libraries or representations of dynamically linkable
libraries needed only during compilation, known as "Import Libraries".
Unlike in the UNIX <http://en.wikipedia.org/wiki/UNIX>  world, where
different file extensions are used, when linking against .LIB file in
Windows <http://en.wikipedia.org/wiki/Windows>  one must first know if
it is a regular static library or an import library. In the latter case,
a .DLL <http://en.wikipedia.org/wiki/Dynamic-link_library>  file must be
present at runtime.

 

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, November 05, 2007 4:34 PM
To: users at lists.ironpython.com
Subject: [IronPython] Anyone know what DLLs is called on Unix?

 

Seo proposed this feature a while ago:

 

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

 

and I'm (finally) adding it and wondering what (if anything) we should
do if the platform is Unix.   Unfortunately I don't have a Unix box
handy but I'm just guessing it's not called DLLs there :-).

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

From mclinton at procard.com  Tue Nov  6 00:42:22 2007
From: mclinton at procard.com (Matt Clinton)
Date: Mon, 5 Nov 2007 16:42:22 -0700
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com><8a6b8e350711051537x4f6d49dft7aee17ac74574513@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <046C79B13A2D204A9FFB87C2EA406CA702BFE118@glesexcc03.procard.local>

Same source for the refined question:

Unix-like systems 

Most Unix-like <http://en.wikipedia.org/wiki/Unix-like>  systems have a
"search path" specifying file system directories
<http://en.wikipedia.org/wiki/Directory_%28file_systems%29>  in which to
look for dynamic libraries. On some systems, the default path is
specified in a configuration file
<http://en.wikipedia.org/wiki/Configuration_file> ; in others, it is
hard coded into the dynamic loader. Some executable file
<http://en.wikipedia.org/wiki/Executable>  formats can specify
additional directories in which to search for libraries for a particular
program. This can usually be overridden with an environment variable
<http://en.wikipedia.org/wiki/Environment_variable> , although it is
disabled for setuid <http://en.wikipedia.org/wiki/Setuid>  and setgid
programs, so that a user can't force such a program to run arbitrary
code. Developers of libraries are encouraged to place their dynamic
libraries in places in the default search path. On the downside, this
can make installation of new libraries problematic, and these "known"
locations quickly become home to an increasing number of library files,
making management more complex.

 

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, November 05, 2007 4:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?

 

Sorry, maybe I wasn't clear - I know they're .so files but is that also
the name of the directory where the extensino modules are stored
relative to the Python installation?

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of James Matthews
Sent: Monday, November 05, 2007 3:37 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?

 

.SO

On 11/6/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:

Seo proposed this feature a while ago:

 

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

 

and I'm (finally) adding it and wondering what (if anything) we should
do if the platform is Unix.   Unfortunately I don't have a Unix box
handy but I'm just guessing it's not called DLLs there :-).


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




-- 
http://www.goldwatches.com/
http://www.jewelerslounge.com 

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

From sanxiyn at gmail.com  Tue Nov  6 00:42:20 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 6 Nov 2007 08:42:20 +0900
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <5b0248170711051542l70050446i6e39261482a4a9c6@mail.gmail.com>

2007/11/6, Dino Viehland <dinov at exchange.microsoft.com>:
> Seo proposed this feature a while ago:
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
> and I'm (finally) adding it and wondering what (if anything) we should do if
> the platform is Unix.   Unfortunately I don't have a Unix box handy but I'm
> just guessing it's not called DLLs there J.

I think it's good as-is. For example, Jython is known to use CPython
Windows layout even on non-Windows platforms.

FYI,
C:\Python24\python.exe = /usr/bin/python2.4
C:\Python24\Lib = /usr/lib/python2.4
C:\Python24\DLLs = /usr/lib/python2.4/lib-dynload

-- 
Seo Sanghyeon


From wd at teleri.net  Tue Nov  6 00:48:48 2007
From: wd at teleri.net (Chip Norkus)
Date: Mon, 5 Nov 2007 15:48:48 -0800
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<8a6b8e350711051537x4f6d49dft7aee17ac74574513@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <20071105234848.GA13600@teleri.net>

On Mon Nov 05, 2007; 03:39PM -0800, Dino Viehland wrote:
>    Sorry, maybe I wasn't clear - I know they're .so files but is that also
>    the name of the directory where the extensino modules are stored relative
>    to the Python installation?
> 

On FreeBSD it's $pythonlibdir/lib-dynload for shared objects.  Usually:
/usr/local/lib/pythonX.Y/lib-dynload/ (2.5 for X.Y e.g.)

> 
> 
>    From: users-bounces at lists.ironpython.com
>    [mailto:users-bounces at lists.ironpython.com] On Behalf Of James Matthews
>    Sent: Monday, November 05, 2007 3:37 PM
>    To: Discussion of IronPython
>    Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?
> 
> 
> 
>    .SO
> 
>    On 11/6/07, Dino Viehland <[1]dinov at exchange.microsoft.com> wrote:
> 
>    Seo proposed this feature a while ago:
> 
> 
> 
>    [2]http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
> 
> 
> 
>    and I'm (finally) adding it and wondering what (if anything) we should do
>    if the platform is Unix.   Unfortunately I don't have a Unix box handy but
>    I'm just guessing it's not called DLLs there J.
> 
>    _______________________________________________
>    Users mailing list
>    [3]Users at lists.ironpython.com
>    [4]http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
>    --
>    [5]http://www.goldwatches.com/
>    [6]http://www.jewelerslounge.com
> 
> References
> 
>    Visible links
>    1. mailto:dinov at exchange.microsoft.com
>    2. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
>    3. mailto:Users at lists.ironpython.com
>    4. http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>    5. http://www.goldwatches.com/
>    6. http://www.jewelerslounge.com/

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

-chip
--
personal: chip norkus; irc: wd;                   wd at teleri.net
info:     finger wd at teleri.net for plan or keys;  http://telekinesis.org


From wd at teleri.net  Tue Nov  6 00:48:48 2007
From: wd at teleri.net (Chip Norkus)
Date: Mon, 5 Nov 2007 15:48:48 -0800
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<8a6b8e350711051537x4f6d49dft7aee17ac74574513@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E08770@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <20071105234848.GA13600@teleri.net>

On Mon Nov 05, 2007; 03:39PM -0800, Dino Viehland wrote:
>    Sorry, maybe I wasn't clear - I know they're .so files but is that also
>    the name of the directory where the extensino modules are stored relative
>    to the Python installation?
> 

On FreeBSD it's $pythonlibdir/lib-dynload for shared objects.  Usually:
/usr/local/lib/pythonX.Y/lib-dynload/ (2.5 for X.Y e.g.)

> 
> 
>    From: users-bounces at lists.ironpython.com
>    [mailto:users-bounces at lists.ironpython.com] On Behalf Of James Matthews
>    Sent: Monday, November 05, 2007 3:37 PM
>    To: Discussion of IronPython
>    Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?
> 
> 
> 
>    .SO
> 
>    On 11/6/07, Dino Viehland <[1]dinov at exchange.microsoft.com> wrote:
> 
>    Seo proposed this feature a while ago:
> 
> 
> 
>    [2]http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
> 
> 
> 
>    and I'm (finally) adding it and wondering what (if anything) we should do
>    if the platform is Unix.   Unfortunately I don't have a Unix box handy but
>    I'm just guessing it's not called DLLs there J.
> 
>    _______________________________________________
>    Users mailing list
>    [3]Users at lists.ironpython.com
>    [4]http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
>    --
>    [5]http://www.goldwatches.com/
>    [6]http://www.jewelerslounge.com
> 
> References
> 
>    Visible links
>    1. mailto:dinov at exchange.microsoft.com
>    2. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
>    3. mailto:Users at lists.ironpython.com
>    4. http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>    5. http://www.goldwatches.com/
>    6. http://www.jewelerslounge.com/

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

-chip
--
personal: chip norkus; irc: wd;                   wd at teleri.net
info:     finger wd at teleri.net for plan or keys;  http://telekinesis.org


From dinov at exchange.microsoft.com  Tue Nov  6 01:26:12 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 5 Nov 2007 16:26:12 -0800
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <5b0248170711051542l70050446i6e39261482a4a9c6@mail.gmail.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<5b0248170711051542l70050446i6e39261482a4a9c6@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E087B0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

So you're suggesting we should just use DLLs instead of detecting Unix and going w/ lib-dynload?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Monday, November 05, 2007 3:42 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?

2007/11/6, Dino Viehland <dinov at exchange.microsoft.com>:
> Seo proposed this feature a while ago:
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=3730
> and I'm (finally) adding it and wondering what (if anything) we should do if
> the platform is Unix.   Unfortunately I don't have a Unix box handy but I'm
> just guessing it's not called DLLs there J.

I think it's good as-is. For example, Jython is known to use CPython
Windows layout even on non-Windows platforms.

FYI,
C:\Python24\python.exe = /usr/bin/python2.4
C:\Python24\Lib = /usr/lib/python2.4
C:\Python24\DLLs = /usr/lib/python2.4/lib-dynload

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


From amaranth at ubuntu.com  Tue Nov  6 01:38:39 2007
From: amaranth at ubuntu.com (Travis Watkins)
Date: Mon, 5 Nov 2007 18:38:39 -0600
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E087B0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<5b0248170711051542l70050446i6e39261482a4a9c6@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E087B0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <adca365a0711051638x20228055s685fa0011ad63054@mail.gmail.com>

On 11/5/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> So you're suggesting we should just use DLLs instead of detecting Unix and going w/ lib-dynload?
>

All the stuff from the Mono guys uses .dll even on *nix so that would
make sense.

-- 
Travis Watkins
http://www.realistanew.com


From dinov at exchange.microsoft.com  Tue Nov  6 01:41:58 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 5 Nov 2007 16:41:58 -0800
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <adca365a0711051638x20228055s685fa0011ad63054@mail.gmail.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<5b0248170711051542l70050446i6e39261482a4a9c6@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E087B0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<adca365a0711051638x20228055s685fa0011ad63054@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E087BB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Ok, I buy that argument...  I'll just use DLLs.  Thanks for the responses.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Travis Watkins
Sent: Monday, November 05, 2007 4:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Anyone know what DLLs is called on Unix?

On 11/5/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> So you're suggesting we should just use DLLs instead of detecting Unix and going w/ lib-dynload?
>

All the stuff from the Mono guys uses .dll even on *nix so that would
make sense.

--
Travis Watkins
http://www.realistanew.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  6 13:56:09 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 06 Nov 2007 12:56:09 +0000
Subject: [IronPython] [Python.NET] What can I do with DLL?
In-Reply-To: <BLU110-W2087562BB2D3A45D300B10C5890@phx.gbl>
References: <BLU110-W2087562BB2D3A45D300B10C5890@phx.gbl>
Message-ID: <47306469.6050205@voidspace.org.uk>

Hello Jane,

It is a little difficult to answer your question because you don't 
really give enough detail about what you have and what you want to achieve.

Typically IronPython applications *can't* be packaged as DLLs, but 
instead run from Python source files.

For IronPython 1.1 though, you can use 'Pyc' (a sample available from 
the codeplex site) that will compile Python source files to assemblies. 
I *believe* those are actually 'exe' files rather than dlls (I might be 
wrong) - but they are still assemblies. Those assemblies will be 
dependent on the IronPython dlls though. See the Pyc sample for examples 
of how to use it. There is no version of Pyc for IronPython 2 though.


All the best,

Michael Foord
http://www.manning.com/foord

jane janet wrote:
>
>
> Hello all,
> I'm a student. I wanna know how to do about my project.
> I implemented aplication using Ironpython because I have to use .NET 
> library and c# code but I also have to use this application with 
> another Python implemented application. My teacher want me to create 
> DLL file of IronPython implemented application. I don't know how to 
> begin. Please help me.
> Thank you.
> All the best.
>
> ------------------------------------------------------------------------
> Boo! Scare away worms, viruses and so much more! Try Windows Live 
> OneCare! Try now! 
> <http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews> 
>
> ------------------------------------------------------------------------
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet



From miguel at novell.com  Tue Nov  6 19:23:12 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Tue, 06 Nov 2007 13:23:12 -0500
Subject: [IronPython] Anyone know what DLLs is called on Unix?
In-Reply-To: <1194322535.4068.0.camel@erandi.boston.ximian.com>
References: <7AD436E4270DD54A94238001769C2227DF52E08768@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<5b0248170711051542l70050446i6 e39261482a4a9c6@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E087B0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<adca365a 0711051638x20228055s685fa0011ad63054@mail.gmail.com>
	<1194322535.4068.0.camel@erandi.boston.ximian.com>
Message-ID: <1194373392.4068.50.camel@erandi.boston.ximian.com>

Hello,

> Ok, I buy that argument...  I'll just use DLLs.  Thanks for the responses.

We use .dll extensions for managed libraries, but the actual extension
for a shared library that contains native code is operating system
specific.

We usually just reference libraries like this:

	[DllImport ("native")]

Which maps to libnative.EXT where EXT is an operating system specific
extension (on Linux and Solaris its ".so", on OSX its ".dylib", "sl" for
HP-UX and ".a" for AIX).

-- You can stop reading here -- 

An added feature is that Unix typically versions libraries, the
"libnative.so" library for example is typically a link to the latest
version released.   It usually points to libnative.so.MAJOR.MINOR, like:
libc.so.6.1 for example.

By sticking to the basename "native" in this case, you can instruct Mono
to remap later through the .config file (or the system-wide config file)
the library to a proper version.

Miguel.


From David.Lawler at franke.com  Tue Nov  6 20:03:36 2007
From: David.Lawler at franke.com (David.Lawler at franke.com)
Date: Tue, 6 Nov 2007 14:03:36 -0500
Subject: [IronPython] New language features to support VS
In-Reply-To: <1194373392.4068.50.camel@erandi.boston.ximian.com>
Message-ID: <OF89BD5214.C2870E40-ON8525738B.00670265-8525738B.0068B211@franke.com>

I noticed some unusual things in the python source recently while playing 
with/learning about the IronPython integration in VS 2008 Beta 2:

"""type(_button1) == System.Windows.Forms.Button, type(_label1) == 
System.Windows.Forms.Label"""
__slots__ = ['_button1', '_label1']
@returns
@accepts

I understand what the __slots__ line and what the @returns & @accepts 
decorators are about.  The type 'definition' in the docstring has me 
thrown for a loss.  Is that a feature in IronPython (what the heck would 
it be called) - or is it used only by VS for the forms designer?  I am 
thinking it is actually a IronPython feature because it seems to make the 
new alpha release of the Sharpdevelop IP binding designer a lot happier as 
well as VS.  Is there somewhere (anywhere) where features like this are 
documented (yes I looked at the ironpython-differences doc).  I also 
looked through the source for IP (found the @returns and @accepts stuff), 
and the source for the VS integration sample but could not decipher where 
type definitions could be inside docstings/triple quoted strings.

Thanks,

David Lawler



From dinov at exchange.microsoft.com  Tue Nov  6 20:09:11 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 6 Nov 2007 11:09:11 -0800
Subject: [IronPython] New language features to support VS
In-Reply-To: <OF89BD5214.C2870E40-ON8525738B.00670265-8525738B.0068B211@franke.com>
References: <1194373392.4068.50.camel@erandi.boston.ximian.com>
	<OF89BD5214.C2870E40-ON8525738B.00670265-8525738B.0068B211@franke.com>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E08991@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

It's actually a feature of the IronPython CodeDom provider - it enables the CodeDom provider to successfully round trip the generated code.  But it's not actually recognized by the normal Python compiler.  You'll find all of the code for this in the CodeDom subfolder of the IronPython source tree.

For ASP.NET support in v1.0 we did play around with experimental support for static compilation and these comments will get recognized in that mode - unfortunately there's a bunch of bugs in static compilation and we've ripped that support in v2.0.  So I would encourage not using static compilation :).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David.Lawler at franke.com
Sent: Tuesday, November 06, 2007 11:04 AM
To: Discussion of IronPython
Subject: [IronPython] New language features to support VS

I noticed some unusual things in the python source recently while playing
with/learning about the IronPython integration in VS 2008 Beta 2:

"""type(_button1) == System.Windows.Forms.Button, type(_label1) ==
System.Windows.Forms.Label"""
__slots__ = ['_button1', '_label1']
@returns
@accepts

I understand what the __slots__ line and what the @returns & @accepts
decorators are about.  The type 'definition' in the docstring has me
thrown for a loss.  Is that a feature in IronPython (what the heck would
it be called) - or is it used only by VS for the forms designer?  I am
thinking it is actually a IronPython feature because it seems to make the
new alpha release of the Sharpdevelop IP binding designer a lot happier as
well as VS.  Is there somewhere (anywhere) where features like this are
documented (yes I looked at the ironpython-differences doc).  I also
looked through the source for IP (found the @returns and @accepts stuff),
and the source for the VS integration sample but could not decipher where
type definitions could be inside docstings/triple quoted strings.

Thanks,

David Lawler

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


From soroker at gmail.com  Wed Nov  7 22:32:41 2007
From: soroker at gmail.com (abs)
Date: Wed, 07 Nov 2007 21:32:41 -0000
Subject: [IronPython] new.classobj() fails with "TypeError: __bases__ items
	must be classes (got type)"
Message-ID: <1194471161.488400.203330@t8g2000prg.googlegroups.com>

Hello,

Here are two files, A.py and B.py:
(Execution details follow)

--- file A.py ---
1
2 import sys
3 import new
4 import imp
5
6 def main():
7     moduleInfo = imp.find_module('B')
8     module = imp.load_module('B', moduleInfo[0], moduleInfo[1],
moduleInfo[2])
9
10    t = new.classobj('Test1', (getattr(module, 'Test'),), {})
11    i = t()
12    i.Execute()
13
14 if __name__ == '__main__':
15     sys.exit(main())
16
--- /file A.py ---

--- file B.py ---
1
2 class Test(object):
3     def __init__(self):
4     print 'hello'
5
6 def Execute(self):
7     print 'hello'
8
--- /file B.py ---

$ c:\Python25\python.exe A.py
hello
hello

$ "c:\Program Files\IronPython-1.1\ipy.exe" A.py
Traceback (most recent call last):
File C:\A.py, line 23, in Initialize
File C:\A.py, line 18, in main
TypeError: Unable to cast object of type
'IronPython.Runtime.Types.UserType&#39; to type
'IronPython.Runtime.Types.OldClass'.

$ "c:\Program Files\IronPython-2.0A5\ipy.exe" A.py
Traceback (most recent call last):
File A.py, line 23, in Initialize
File , line 0, in _stub_##19
File A.py, line 16, in main
File , line 0, in _stub_##51
TypeError: __bases__ items must be classes (got type)

Am I doing something wrong, or is this a bug?

Thanks!



From dinov at exchange.microsoft.com  Thu Nov  8 00:16:18 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 7 Nov 2007 15:16:18 -0800
Subject: [IronPython] new.classobj() fails with "TypeError: __bases__
 items	must be classes (got type)"
In-Reply-To: <1194471161.488400.203330@t8g2000prg.googlegroups.com>
References: <1194471161.488400.203330@t8g2000prg.googlegroups.com>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E08E3D@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

This is definitely a bug in IronPython and it seems to be present in one way or another for all versions.  Thanks for the bug report.

The actual issue can be summarized as:

class foo(object): pass

class bar: pass

i = type(bar)('abc', (foo, ), {})

i()

or an alternate way of expressing it:

class foo(object): pass

class bar: pass

type(bar).__new__(type(bar), 'abc', (foo, ), {})

Both of these should apparently be the same as type('abc', (foo, ), {}).  In other words classobj.__new__ should do the whole normal type creation thing rather than just create classobj's.

I've opened a bug to track the issue on CodePlex: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13740  If this is a particularly blocking issue then I'd suggest voting on the bug.  Otherwise the simple workaround is to call type() instead of new.classobj()

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of abs
Sent: Wednesday, November 07, 2007 1:33 PM
To: users at lists.ironpython.com
Subject: [IronPython] new.classobj() fails with "TypeError: __bases__ items must be classes (got type)"

Hello,

Here are two files, A.py and B.py:
(Execution details follow)

--- file A.py ---
1
2 import sys
3 import new
4 import imp
5
6 def main():
7     moduleInfo = imp.find_module('B')
8     module = imp.load_module('B', moduleInfo[0], moduleInfo[1],
moduleInfo[2])
9
10    t = new.classobj('Test1', (getattr(module, 'Test'),), {})
11    i = t()
12    i.Execute()
13
14 if __name__ == '__main__':
15     sys.exit(main())
16
--- /file A.py ---

--- file B.py ---
1
2 class Test(object):
3     def __init__(self):
4     print 'hello'
5
6 def Execute(self):
7     print 'hello'
8
--- /file B.py ---

$ c:\Python25\python.exe A.py
hello
hello

$ "c:\Program Files\IronPython-1.1\ipy.exe" A.py
Traceback (most recent call last):
File C:\A.py, line 23, in Initialize
File C:\A.py, line 18, in main
TypeError: Unable to cast object of type
'IronPython.Runtime.Types.UserType&#39; to type
'IronPython.Runtime.Types.OldClass'.

$ "c:\Program Files\IronPython-2.0A5\ipy.exe" A.py
Traceback (most recent call last):
File A.py, line 23, in Initialize
File , line 0, in _stub_##19
File A.py, line 16, in main
File , line 0, in _stub_##51
TypeError: __bases__ items must be classes (got type)

Am I doing something wrong, or is this a bug?

Thanks!

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


From dfugate at microsoft.com  Thu Nov  8 00:32:46 2007
From: dfugate at microsoft.com (Dave Fugate)
Date: Wed, 7 Nov 2007 15:32:46 -0800
Subject: [IronPython] IronPython 2.0 Alpha 6
Message-ID: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>

Hello IronPython Community,

We have just released IronPython 2.0 Alpha 6.  As per usual, this release includes all of the changes we have made in the past month.  The most noteworthy differences include:

*         the IronPython project is now distributed under the Microsoft Public License (Ms-PL)

*         improved support of COM events under the -X:PreferComDispatch flag

*         the abstract syntax tree for IronPython is being hardened so to speak

*         we have included an updated DLR sample in the source zip file - ToyScript
It's also worth mentioning that like last month, we've been spending a great deal of time looking into active CodePlex bugs.

As many people are already aware, the Open Source Initiative (OSI) approved the Microsoft Public License last month.  As a result the IronPython project has switched from using the "Microsoft Permissive License" to the "Microsoft Public License".  The only difference between this new license and the old one is the change in the name.  By making this minor change we're extremely happy to finally be able to clearly state that IronPython ships under an approved Open Source license!  The contents of the Ms-PL can currently be found at http://www.microsoft.com/resources/sharedsource/licensingbasics/publiclicense.mspx.  Finally, this change should be reflected on http://www.codeplex.com/IronPython/Project/License.aspx later this week.

ToyScript is a small scripting language written to serve as an example of how scripting languages can be implemented on the Dynamic Language Runtime.  ToyScript's sources should give anyone interested in creating language implementations a good idea of how the DLR can make your job easier.  It would be great if anyone creating language implementations could give us feedback on the sample and/or their experiences using the DLR.  It's worth pointing out that ToyScript is merely a DLR sample and not some new scripting language Microsoft has created.

You can download IronPython 2.0A6 at: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython&ReleaseId=7663

The IronPython Team



IMPORTANT NOTES
Internally we have migrated our Visual Studio project and solution files over to a Visual Studio 2008 beta release.  While we've modified these files in the source distribution of IronPython to be compatible with Visual Studio 2005 and the msbuild tool, it's possible we may have missed something.  If you experience any problems building IronPython from VS tools please let us know.

The ToyScript sample is not intended to be distributed with IronPython on a permanent basis and will likely be released in some other fashion in the not too distant future.

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

From dinov at exchange.microsoft.com  Thu Nov  8 00:43:45 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 7 Nov 2007 15:43:45 -0800
Subject: [IronPython] bugs with event handlers in 1.1 and 2.0 alpha 5
In-Reply-To: <Pine.LNX.4.63.0711051619300.31067@pallas.utanet.fi>
References: <Pine.LNX.4.63.0711051619300.31067@pallas.utanet.fi>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E08E5E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for both of these bug reports (and sorry for the delay in responding).  I've taken a look and I'm definitely seeing the same behavior as you are on 1.1.  On current 2.0 builds things are a little different - but there's been some churn there since Alpha 5, specifically around conversions which likely fixed the problem.  I saw another issue where we couldn't create a delegate to a bound-builtin function and fixed that on my machine.  Now I see:

I am the built-in handler
i got an event, i am happy.
another one an event too, is happy too.
yet another eventhandler, this must be enough.
Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback
Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback
Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback
Removed event handler: ResetableEventcontainer.ResetableEventcontainer+MyEventCallback
removed 4 event handlers
after removal, nothing should happen here:
now we re-add a handler, it should work again:
I am the built-in handler
i got an event, i am happy.
testing adding on csharp-side, instead:
I am the built-in handler
i got an event, i am happy.
I am the built-in handler

Is that the correct output?  If so then it looks like this will be fixed in the release after Alpha 6 (which just went out today).  If you want to patch a copy of alpha 6 on your own you can just make BoundBuiltinFunction.LanguageContext return DefaultContext.Default.LanguageContext instead of throwing NotImplementedException.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Toni Alatalo
Sent: Monday, November 05, 2007 6:32 AM
To: users at lists.ironpython.com
Subject: [IronPython] bugs with event handlers in 1.1 and 2.0 alpha 5

Greetings,

when making a scripting system with IronPython in an embedded context I
encountered first a bug in 1.1 in re-adding event handlers that had been
cleared in-between (I wanted that to be able to refresh the py written
handlers on the fly) - that is reported as bug #13685
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13685

While making the test case for that I came across a different problem in
2.0 alpha 5: [#13687] Registering c#-written methods as event handlers
from ironpy throws TypeError: Object is not callable.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13687

A minimalish test case for both is available at
http://studio.kyperjokki.fi/engine/IronPythonEventReaddition

Curiously enough, 2.0 alpha5 did not work for me in the actual application
that am developing - the fact that this test case does gives good hope
that I can get it working there it too (I thought the case is similar..).

This whole GetInvocationList() seems to be a strange beast, it is only
available in the same class where the event is defined - not to others
even if whe event is public, nor even in subclasses (yes, not even in
c#-written subclasses - that's why my first test case that featured a
WinForm with buttons etc could not be completed (I could not subclass a
Button that'd have such a method for clearing event callbacks).

The idea in the app that am developing is that user written scripts can
register event handlers freely, so when clearing them to add new versions
of the functions there, I don't have references to the funcs that the old
version of the script had added. Am now using a workaround where the whole
instance that has the handlers is re-initialized upon such a restart, but
would like to have the initial plan of just redefining event handlers on
the fly work too. So hopefully that'll smooth on 2.0.

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


From fuzzyman at voidspace.org.uk  Thu Nov  8 14:53:13 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 08 Nov 2007 13:53:13 +0000
Subject: [IronPython] LINQ in IronPython?
Message-ID: <473314C9.8030601@voidspace.org.uk>

Hello all,

It would be great to have LINQ in IronPython - but I don't think it can 
be done without extending the Python syntax. Understandably the Python 
community will be concerned about this.

Fortunately Python has a built-in way of enabling (or disabling) 
language features - the __future__ imports.

If you could agree with the Python developers to get a 'reserved' flag 
for LINQ (one that CPython promises never to use) then develoeprs could 
enable LINQ by starting files with:

from __future__ import LINQ

Michael
http://www.manning.com/foord


From antont at kyperjokki.fi  Thu Nov  8 14:54:53 2007
From: antont at kyperjokki.fi (Toni Alatalo)
Date: Thu, 8 Nov 2007 15:54:53 +0200 (EET)
Subject: [IronPython] bugs with event handlers in 1.1 and 2.0 alpha 5
In-Reply-To: <7AD436E4270DD54A94238001769C2227DF52E08E5E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <Pine.LNX.4.63.0711051619300.31067@pallas.utanet.fi>
	<7AD436E4270DD54A94238001769C2227DF52E08E5E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <Pine.LNX.4.63.0711081546310.31067@pallas.utanet.fi>

On Wed, 7 Nov 2007, Dino Viehland wrote:

Thanks for looking into it, I don't think the delay was too long at all :)
Am sorry for not making the test output clearer / constructing the case as 
a proper unit test, was the last thing on a too long day it seems..

> function and fixed that on my machine.  Now I see:
> removed 4 event handlers
> after removal, nothing should happen here:
> now we re-add a handler, it should work again:
> I am the built-in handler
> i got an event, i am happy.
> Is that the correct output?
> If so then it looks like this will be fixed in the release after Alpha 6

Yep it seems to work perfectly in the build you used: after clearing event 
handlers by iterating thru the GetInvocationList(), adding event handlers 
again from ironpython works (like it did in 2.0 alpha5 but not in 1.1), 
and also adding c#-written event handlers in ironpython always works (it 
always borked for me in 2.0 alpha5, works in 1.1).

Will test alpha6 myself also soonish.

cheers,
~Toni

>
> -----Original Message-----
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13685
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13687
> http://studio.kyperjokki.fi/engine/IronPythonEventReaddition


From hfoffani at gmail.com  Thu Nov  8 17:39:45 2007
From: hfoffani at gmail.com (Hernan M Foffani)
Date: Thu, 8 Nov 2007 17:39:45 +0100
Subject: [IronPython] LINQ in IronPython?
In-Reply-To: <473314C9.8030601@voidspace.org.uk>
References: <473314C9.8030601@voidspace.org.uk>
Message-ID: <11fab4bc0711080839w7f001adai18229412cace971c@mail.gmail.com>

> It would be great to have LINQ in IronPython - but I don't think it can
> be done without extending the Python syntax. Understandably the Python
> community will be concerned about this.
>
> Fortunately Python has a built-in way of enabling (or disabling)
> language features - the __future__ imports.
>
> If you could agree with the Python developers to get a 'reserved' flag
> for LINQ (one that CPython promises never to use) then develoeprs could
> enable LINQ by starting files with:
>
> from __future__ import LINQ

Some time ago I was wondering if it would be possible to have an
object that takes a generator expression and translates its AST
into LINQ expressions (actually, not LINQ extended syntax but
the .NET 3.0 API )

With this approach, of course, you won't be able to get LINQ's
full power inside Python, but I think that staying within Python
syntax is nice.

To be honest I haven't gave it much thought to this so I don't know
if it's possible, or even worth it, at all.

Regards,
-Hern?n.


From fuzzyman at voidspace.org.uk  Thu Nov  8 17:52:45 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 08 Nov 2007 16:52:45 +0000
Subject: [IronPython] LINQ in IronPython?
In-Reply-To: <11fab4bc0711080839w7f001adai18229412cace971c@mail.gmail.com>
References: <473314C9.8030601@voidspace.org.uk>
	<11fab4bc0711080839w7f001adai18229412cace971c@mail.gmail.com>
Message-ID: <47333EDD.40805@voidspace.org.uk>

Hernan M Foffani wrote:
>> It would be great to have LINQ in IronPython - but I don't think it can
>> be done without extending the Python syntax. Understandably the Python
>> community will be concerned about this.
>>
>> Fortunately Python has a built-in way of enabling (or disabling)
>> language features - the __future__ imports.
>>
>> If you could agree with the Python developers to get a 'reserved' flag
>> for LINQ (one that CPython promises never to use) then develoeprs could
>> enable LINQ by starting files with:
>>
>> from __future__ import LINQ
>>     
>
> Some time ago I was wondering if it would be possible to have an
> object that takes a generator expression and translates its AST
> into LINQ expressions (actually, not LINQ extended syntax but
> the .NET 3.0 API )
>
> With this approach, of course, you won't be able to get LINQ's
> full power inside Python, but I think that staying within Python
> syntax is nice.
>   

I've been thinking about a similar approach - where list comprehensions 
(or generator expressions) could actually translate to API calls on the 
iterable (the data provider). Perhaps with a magic method like '__query__'.

Python (or IronPython) would have to then check for this magic method in 
every list comprehension - perhaps hitting performance. It would also 
have to *keep* the AST for the filter expression. I think this still 
amounts to an extension of Python though by adding new protocols - but 
it is a nice generalisation. Generating queries from ASTs sounds 
non-trivial, but Microsoft have done it for LINQ. I have a blog entry 
about this waiting in the wings.

Just providing a LINQ function that takes a generator expression is an 
interesting approach. IronPython would still have to do some magic to 
generate an expression tree from the filter expression.

Michael
http://www.manning.com/foord

> To be honest I haven't gave it much thought to this so I don't know
> if it's possible, or even worth it, at all.
>
> Regards,
> -Hern?n.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From sanxiyn at gmail.com  Fri Nov  9 07:25:17 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 9 Nov 2007 15:25:17 +0900
Subject: [IronPython] Invoking delegate to abstract method
Message-ID: <5b0248170711082225g53565895j15ba671fef9b4b7e@mail.gmail.com>

For whatever reasons, IronPython 2.0 Alpha 6 started to invoke
delegate to abstract method. (Previous versions didn't.) This
triggered Mono bug 317488 which is apparently hard to fix.
https://bugzilla.novell.com/show_bug.cgi?id=317488

I developed completely insane workarounds to avoid this problem. Now
you can laugh (or weep).
https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest/patch-317488

-- 
Seo Sanghyeon


From sanxiyn at gmail.com  Fri Nov  9 15:05:22 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 9 Nov 2007 23:05:22 +0900
Subject: [IronPython] Pet peeve
Message-ID: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com>

Okay, I will be blunt. Please fix
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=6805

It's not like it's difficult! It can be fixed in exact same way it was
fixed in 1.1!

IronPython/Runtime/calls/FunctionCode.cs
ArgCount property
If ArgumentList flag is set, decrease by one
If KeywordDictionary flag is set, decrease by one

Thanks.

-- 
Seo Sanghyeon


From dinov at exchange.microsoft.com  Fri Nov  9 17:20:54 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 9 Nov 2007 08:20:54 -0800
Subject: [IronPython] Pet peeve
In-Reply-To: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com>
References: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227DF52E09288@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I'll fix it today (it's actually fix trivial bugs week so it's great timing :) ).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Friday, November 09, 2007 6:05 AM
To: Discussion of IronPython
Subject: [IronPython] Pet peeve

Okay, I will be blunt. Please fix
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=6805

It's not like it's difficult! It can be fixed in exact same way it was
fixed in 1.1!

IronPython/Runtime/calls/FunctionCode.cs
ArgCount property
If ArgumentList flag is set, decrease by one
If KeywordDictionary flag is set, decrease by one

Thanks.

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


From vizcaynot at gmail.com  Sat Nov 10 00:07:03 2007
From: vizcaynot at gmail.com (Vizcayno)
Date: Fri, 09 Nov 2007 15:07:03 -0800
Subject: [IronPython] IronPython 2.0 Alpha 6
In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>
References: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>
Message-ID: <1194649623.523151.259560@v3g2000hsg.googlegroups.com>

Please, type the next:

import datetime.datetime
dir(datetime.datetime)
import datetime
dir(datetime.datetime)

The results in my winXP SP2 with python 2.5 are:

>>> import datetime.datetime
Traceback (most recent call last):
  File , line 0, in ##241
  File , line 0, in _stub_##2
ImportError: No module named datetime

>>> dir(datetime.datetime)
Traceback (most recent call last):
  File , line 0, in ##247
NameError: name 'datetime' is not defined

>>> import datetime
>>> dir(datetime.datetime)
['__add__', '__class__', '__delattr__', '__doc__', '__eq__', '__ge__',
'__getattribute__', '__getnewargs__', '__gt__', '
hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__', '__nonzero__', '__radd__', '__reduce__', '__
duce_ex__', '__repr__', '__rsub__', '__setattr__', '__str__',
'__sub__', 'astimezone', 'combine', 'ctime', 'date', 'day'
'dst', 'fromordinal', 'fromtimestamp', 'hour', 'isocalendar',
'isoformat', 'isoweekday', 'max', 'microsecond', 'min', 'm
ute', 'month', 'now', 'replace', 'resolution', 'second', 'strftime',
'time', 'timetuple', 'timetz', 'today', 'toordinal'
'tzinfo', 'tzname', 'utcfromtimestamp', 'utcnow', 'utcoffset',
'utctimetuple', 'weekday', 'year']
>>>



From dinov at exchange.microsoft.com  Sat Nov 10 00:10:40 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 9 Nov 2007 15:10:40 -0800
Subject: [IronPython] IronPython 2.0 Alpha 6
In-Reply-To: <1194649623.523151.259560@v3g2000hsg.googlegroups.com>
References: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<1194649623.523151.259560@v3g2000hsg.googlegroups.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AB99@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Are you seeing something different on Alpha 6?  I see the same behavior between CPython and Python but I am on a slightly later build - although the list of methods is slightly different (e.g. no __getnewargs__ in IronPython).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vizcayno
Sent: Friday, November 09, 2007 3:07 PM
To: users at lists.ironpython.com
Subject: Re: [IronPython] IronPython 2.0 Alpha 6

Please, type the next:

import datetime.datetime
dir(datetime.datetime)
import datetime
dir(datetime.datetime)

The results in my winXP SP2 with python 2.5 are:

>>> import datetime.datetime
Traceback (most recent call last):
  File , line 0, in ##241
  File , line 0, in _stub_##2
ImportError: No module named datetime

>>> dir(datetime.datetime)
Traceback (most recent call last):
  File , line 0, in ##247
NameError: name 'datetime' is not defined

>>> import datetime
>>> dir(datetime.datetime)
['__add__', '__class__', '__delattr__', '__doc__', '__eq__', '__ge__',
'__getattribute__', '__getnewargs__', '__gt__', '
hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
'__new__', '__nonzero__', '__radd__', '__reduce__', '__
duce_ex__', '__repr__', '__rsub__', '__setattr__', '__str__',
'__sub__', 'astimezone', 'combine', 'ctime', 'date', 'day'
'dst', 'fromordinal', 'fromtimestamp', 'hour', 'isocalendar',
'isoformat', 'isoweekday', 'max', 'microsecond', 'min', 'm
ute', 'month', 'now', 'replace', 'resolution', 'second', 'strftime',
'time', 'timetuple', 'timetz', 'today', 'toordinal'
'tzinfo', 'tzname', 'utcfromtimestamp', 'utcnow', 'utcoffset',
'utctimetuple', 'weekday', 'year']
>>>

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


From vizcaynot at gmail.com  Sat Nov 10 00:54:30 2007
From: vizcaynot at gmail.com (Vizcayno)
Date: Fri, 09 Nov 2007 15:54:30 -0800
Subject: [IronPython] IronPython 2.0 Alpha 6
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AB99@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<1194649623.523151.259560@v3g2000hsg.googlegroups.com>
	<7AD436E4270DD54A94238001769C2227E45211AB99@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <1194652470.397897.204340@o3g2000hsb.googlegroups.com>

You are right Dino!! the same behavior happens in python 2.5. I
suppose it is a bug.
I also have this problem In ipy 2.0 alpha 6, but not in ipy 2.0 alpha
4.
Very best regards.



On 9 nov, 19:10, Dino Viehland <di... at exchange.microsoft.com> wrote:
> Are you seeing something different on Alpha 6?  I see the same behavior between CPython and Python but I am on a slightly later build - although the list of methods is slightly different (e.g. no __getnewargs__ in IronPython).
>
>
>
> -----Original Message-----
> From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Vizcayno
> Sent: Friday, November 09, 2007 3:07 PM
> To: us... at lists.ironpython.com
> Subject: Re: [IronPython] IronPython 2.0 Alpha 6
>
> Please, type the next:
>
> import datetime.datetime
> dir(datetime.datetime)
> import datetime
> dir(datetime.datetime)
>
> The results in my winXP SP2 with python 2.5 are:
>
> >>> import datetime.datetime
> Traceback (most recent call last):
>   File , line 0, in ##241
>   File , line 0, in _stub_##2
> ImportError: No module named datetime
>
> >>> dir(datetime.datetime)
> Traceback (most recent call last):
>   File , line 0, in ##247
> NameError: name 'datetime' is not defined
>
> >>> import datetime
> >>> dir(datetime.datetime)
> ['__add__', '__class__', '__delattr__', '__doc__', '__eq__', '__ge__',
> '__getattribute__', '__getnewargs__', '__gt__', '
> hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
> '__new__', '__nonzero__', '__radd__', '__reduce__', '__
> duce_ex__', '__repr__', '__rsub__', '__setattr__', '__str__',
> '__sub__', 'astimezone', 'combine', 'ctime', 'date', 'day'
> 'dst', 'fromordinal', 'fromtimestamp', 'hour', 'isocalendar',
> 'isoformat', 'isoweekday', 'max', 'microsecond', 'min', 'm
> ute', 'month', 'now', 'replace', 'resolution', 'second', 'strftime',
> 'time', 'timetuple', 'timetz', 'today', 'toordinal'
> 'tzinfo', 'tzname', 'utcfromtimestamp', 'utcnow', 'utcoffset',
> 'utctimetuple', 'weekday', 'year']
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -



From dinov at exchange.microsoft.com  Sat Nov 10 00:58:45 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 9 Nov 2007 15:58:45 -0800
Subject: [IronPython] IronPython 2.0 Alpha 6
In-Reply-To: <1194652470.397897.204340@o3g2000hsb.googlegroups.com>
References: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<1194649623.523151.259560@v3g2000hsg.googlegroups.com>
	<7AD436E4270DD54A94238001769C2227E45211AB99@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<1194652470.397897.204340@o3g2000hsb.googlegroups.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211ABD0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Ahh, yes, it was a bug in IronPython that we fixed.

The import x.y syntax expects x to be a module and y to be another module inside of that.  Maybe you want to use "from datetime import datetime" instead but that's different so maybe not :).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vizcayno
Sent: Friday, November 09, 2007 3:55 PM
To: users at lists.ironpython.com
Subject: Re: [IronPython] IronPython 2.0 Alpha 6

You are right Dino!! the same behavior happens in python 2.5. I
suppose it is a bug.
I also have this problem In ipy 2.0 alpha 6, but not in ipy 2.0 alpha
4.
Very best regards.



On 9 nov, 19:10, Dino Viehland <di... at exchange.microsoft.com> wrote:
> Are you seeing something different on Alpha 6?  I see the same behavior between CPython and Python but I am on a slightly later build - although the list of methods is slightly different (e.g. no __getnewargs__ in IronPython).
>
>
>
> -----Original Message-----
> From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Vizcayno
> Sent: Friday, November 09, 2007 3:07 PM
> To: us... at lists.ironpython.com
> Subject: Re: [IronPython] IronPython 2.0 Alpha 6
>
> Please, type the next:
>
> import datetime.datetime
> dir(datetime.datetime)
> import datetime
> dir(datetime.datetime)
>
> The results in my winXP SP2 with python 2.5 are:
>
> >>> import datetime.datetime
> Traceback (most recent call last):
>   File , line 0, in ##241
>   File , line 0, in _stub_##2
> ImportError: No module named datetime
>
> >>> dir(datetime.datetime)
> Traceback (most recent call last):
>   File , line 0, in ##247
> NameError: name 'datetime' is not defined
>
> >>> import datetime
> >>> dir(datetime.datetime)
> ['__add__', '__class__', '__delattr__', '__doc__', '__eq__', '__ge__',
> '__getattribute__', '__getnewargs__', '__gt__', '
> hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
> '__new__', '__nonzero__', '__radd__', '__reduce__', '__
> duce_ex__', '__repr__', '__rsub__', '__setattr__', '__str__',
> '__sub__', 'astimezone', 'combine', 'ctime', 'date', 'day'
> 'dst', 'fromordinal', 'fromtimestamp', 'hour', 'isocalendar',
> 'isoformat', 'isoweekday', 'max', 'microsecond', 'min', 'm
> ute', 'month', 'now', 'replace', 'resolution', 'second', 'strftime',
> 'time', 'timetuple', 'timetz', 'today', 'toordinal'
> 'tzinfo', 'tzname', 'utcfromtimestamp', 'utcnow', 'utcoffset',
> 'utctimetuple', 'weekday', 'year']
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

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


From kfarmer at thuban.org  Sat Nov 10 01:19:28 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 9 Nov 2007 16:19:28 -0800
Subject: [IronPython] Pet peeve
References: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E09288@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075442CC726@meta-exchange.circle-cross.home>

"Fix Trivial Bugs Week"?
 
I like that idea.  Start a movement around it!

________________________________

From: users-bounces at lists.ironpython.com on behalf of Dino Viehland
Sent: Fri 11/9/2007 8:20 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Pet peeve



I'll fix it today (it's actually fix trivial bugs week so it's great timing :) ).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Friday, November 09, 2007 6:05 AM
To: Discussion of IronPython
Subject: [IronPython] Pet peeve

Okay, I will be blunt. Please fix
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=6805

It's not like it's difficult! It can be fixed in exact same way it was
fixed in 1.1!

IronPython/Runtime/calls/FunctionCode.cs
ArgCount property
If ArgumentList flag is set, decrease by one
If KeywordDictionary flag is set, decrease by one

Thanks.

--
Seo Sanghyeon
_______________________________________________
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 vizcaynot at gmail.com  Sat Nov 10 01:21:33 2007
From: vizcaynot at gmail.com (Vizcayno)
Date: Fri, 09 Nov 2007 16:21:33 -0800
Subject: [IronPython] IronPython 2.0 Alpha 6
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211ABD0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7346A825E148B049A9AD1D3ED46A2D9116C164F74D@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<1194649623.523151.259560@v3g2000hsg.googlegroups.com>
	<7AD436E4270DD54A94238001769C2227E45211AB99@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<1194652470.397897.204340@o3g2000hsb.googlegroups.com>
	<7AD436E4270DD54A94238001769C2227E45211ABD0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <1194654093.352152.311050@c30g2000hsa.googlegroups.com>

I really have the next line:
from datetime.datetime import now, strftime
print now()
which works well in ipy 2.0 alpha4

So, as you kindly suggest, I will do:
from datetime import datetime
print datetime.now()

Thanks for your attention and help.
Regards.




On 9 nov, 19:58, Dino Viehland <di... at exchange.microsoft.com> wrote:
> Ahh, yes, it was a bug in IronPython that we fixed.
>
> The import x.y syntax expects x to be a module and y to be another module inside of that.  Maybe you want to use "from datetime import datetime" instead but that's different so maybe not :).
>
>
>
> -----Original Message-----
> From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Vizcayno
> Sent: Friday, November 09, 2007 3:55 PM
> To: us... at lists.ironpython.com
> Subject: Re: [IronPython] IronPython 2.0 Alpha 6
>
> You are right Dino!! the same behavior happens in python 2.5. I
> suppose it is a bug.
> I also have this problem In ipy 2.0 alpha 6, but not in ipy 2.0 alpha
> 4.
> Very best regards.
>
> On 9 nov, 19:10, Dino Viehland <di... at exchange.microsoft.com> wrote:
> > Are you seeing something different on Alpha 6?  I see the same behavior between CPython and Python but I am on a slightly later build - although the list of methods is slightly different (e.g. no __getnewargs__ in IronPython).
>
> > -----Original Message-----
> > From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Vizcayno
> > Sent: Friday, November 09, 2007 3:07 PM
> > To: us... at lists.ironpython.com
> > Subject: Re: [IronPython] IronPython 2.0 Alpha 6
>
> > Please, type the next:
>
> > import datetime.datetime
> > dir(datetime.datetime)
> > import datetime
> > dir(datetime.datetime)
>
> > The results in my winXP SP2 with python 2.5 are:
>
> > >>> import datetime.datetime
> > Traceback (most recent call last):
> >   File , line 0, in ##241
> >   File , line 0, in _stub_##2
> > ImportError: No module named datetime
>
> > >>> dir(datetime.datetime)
> > Traceback (most recent call last):
> >   File , line 0, in ##247
> > NameError: name 'datetime' is not defined
>
> > >>> import datetime
> > >>> dir(datetime.datetime)
> > ['__add__', '__class__', '__delattr__', '__doc__', '__eq__', '__ge__',
> > '__getattribute__', '__getnewargs__', '__gt__', '
> > hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__',
> > '__new__', '__nonzero__', '__radd__', '__reduce__', '__
> > duce_ex__', '__repr__', '__rsub__', '__setattr__', '__str__',
> > '__sub__', 'astimezone', 'combine', 'ctime', 'date', 'day'
> > 'dst', 'fromordinal', 'fromtimestamp', 'hour', 'isocalendar',
> > 'isoformat', 'isoweekday', 'max', 'microsecond', 'min', 'm
> > ute', 'month', 'now', 'replace', 'resolution', 'second', 'strftime',
> > 'time', 'timetuple', 'timetz', 'today', 'toordinal'
> > 'tzinfo', 'tzname', 'utcfromtimestamp', 'utcnow', 'utcoffset',
> > 'utctimetuple', 'weekday', 'year']
>
> > _______________________________________________
> > Users mailing list
> > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > _______________________________________________
> > Users mailing list
> > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com-Ocultar texto de la cita -
>
> > - Mostrar texto de la cita -
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -



From jtcmurphy at gmail.com  Mon Nov 12 11:17:24 2007
From: jtcmurphy at gmail.com (James Murphy)
Date: Mon, 12 Nov 2007 10:17:24 +0000
Subject: [IronPython] Pet peeve
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC26075442CC726@meta-exchange.circle-cross.home>
References: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E09288@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<EEDCD954DD4A0D488BBDBDDCC26075442CC726@meta-exchange.circle-cross.home>
Message-ID: <b04bcd010711120217o187c2851id7e7e13485039fa@mail.gmail.com>

On 10/11/2007, Keith J. Farmer <kfarmer at thuban.org> wrote:
> "Fix Trivial Bugs Week"?
>
> I like that idea.  Start a movement around it!

Its a winner - well actually its not since there's a weight of
argument that says that the trivial ones are possibly the ones that
should get hit first, or at least most often - but out here in the
real world...

We've been doing this with a project (although some of the bugs turn
out to be not so trivial) and its been having a positive effect (-:

-- 
Murph


From fuzzyman at gmail.com  Mon Nov 12 15:08:21 2007
From: fuzzyman at gmail.com (Michael Foord)
Date: Mon, 12 Nov 2007 14:08:21 -0000
Subject: [IronPython] __getattribute__ bug
In-Reply-To: <472BC048.60100@voidspace.org.uk>
References: <472BC048.60100@voidspace.org.uk>
Message-ID: <1194876501.419337.129710@o38g2000hse.googlegroups.com>

There as no answer to this - so I have raised it as codeplex issue
13820:

Michael
http://www.manning.com/foord

On Nov 3, 12:26 am, Michael Foord <fuzzy... at voidspace.org.uk> wrote:
> Hello all,
>
> A bug in '__getattribute__' - magic methods should be fetched from the
> class and not go through '__getattribute__'.
>
> This is making a proxy class I'm writing behave very oddly:
>
> The following code:
>
> def DoNothing(*args):
>     pass
>
> class Something(object):
>     def __getattribute__(self, name):
>         print name
>         return DoNothing
>
>     def __call__(self):
>         print 'called'
>
>     def __getitem__(self, name):
>         raise Exception('w00t!')
>
>     def __setitem__(self, name, value):
>         raise Exception('w00t!')
>
> s = Something()
> s['fish'] = 3
>
> Does this on CPython:
>
> C:\compile\cext\trunk\cext>descriptors.py
> Traceback (most recent call last):
>   File "C:\compile\cext\trunk\cext\descriptors.py", line 20, in ?
>     s['fish'] = 3
>   File "C:\compile\cext\trunk\cext\descriptors.py", line 17, in __setitem__
>     raise Exception('w00t!')
> Exception: w00t!
>
> And this on IronPython 2a5:
>
> C:\compile\cext\trunk\cext>C:\compile\IronPython2\ipy.exe -D
> -X:TabCompletion -X
> :ColorfulConsole descriptors.py
> __setitem__
>
> To make things odder - if the class 'Something' doesn't have a
> __setitem__ method then an attribute error is correctly raised. For
> '__call__' I am *sometimes* seeing that go through '__getattribute__'
> and sometimes not...
>
> Michaelhttp://www.manning.com/foord
>
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From sanxiyn at gmail.com  Mon Nov 12 16:20:54 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 13 Nov 2007 00:20:54 +0900
Subject: [IronPython] Another trivial bug
Message-ID: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>

Is trivial bugs week over yet?

Please fix
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814

This came to my attention thanks to a patch by Hajime Nakagami. The
bug is nearly a year old, and can only be explained by sloppiness.
Well, we all make mistakes...

Please fix it in both 1.x and 2.x. Thanks.

-- 
Seo Sanghyeon


From dinov at exchange.microsoft.com  Mon Nov 12 18:46:18 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Nov 2007 09:46:18 -0800
Subject: [IronPython] Pet peeve
In-Reply-To: <b04bcd010711120217o187c2851id7e7e13485039fa@mail.gmail.com>
References: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227DF52E09288@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<EEDCD954DD4A0D488BBDBDDCC26075442CC726@meta-exchange.circle-cross.home>
	<b04bcd010711120217o187c2851id7e7e13485039fa@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AD41@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

There's another school of thought that we should just fix them as they come in.  But fixing them in-bulk certainly gives me a warm fuzzy feeling. :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of James Murphy
Sent: Monday, November 12, 2007 2:17 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Pet peeve

On 10/11/2007, Keith J. Farmer <kfarmer at thuban.org> wrote:
> "Fix Trivial Bugs Week"?
>
> I like that idea.  Start a movement around it!

Its a winner - well actually its not since there's a weight of
argument that says that the trivial ones are possibly the ones that
should get hit first, or at least most often - but out here in the
real world...

We've been doing this with a project (although some of the bugs turn
out to be not so trivial) and its been having a positive effect (-:

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


From dinov at exchange.microsoft.com  Mon Nov 12 19:00:27 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Nov 2007 10:00:27 -0800
Subject: [IronPython] __getattribute__ bug
In-Reply-To: <1194876501.419337.129710@o38g2000hse.googlegroups.com>
References: <472BC048.60100@voidspace.org.uk>
	<1194876501.419337.129710@o38g2000hse.googlegroups.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AD59@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the bug report, and sorry for missing the original mail.

This is a bug in a code path that will ultimately be going away - currently we still have a mix of code paths that use the new DynamicSite and Rules mechanism and the old interface / PythonType (Formerly DynamicType) / CLR type based dispatch mechanism.  As we finish the switch over to rules the bug will be fixed by re-writing that code path.  It might take a little while before we get there though :(.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, November 12, 2007 6:08 AM
To: users at lists.ironpython.com
Subject: Re: [IronPython] __getattribute__ bug

There as no answer to this - so I have raised it as codeplex issue
13820:

Michael
http://www.manning.com/foord

On Nov 3, 12:26 am, Michael Foord <fuzzy... at voidspace.org.uk> wrote:
> Hello all,
>
> A bug in '__getattribute__' - magic methods should be fetched from the
> class and not go through '__getattribute__'.
>
> This is making a proxy class I'm writing behave very oddly:
>
> The following code:
>
> def DoNothing(*args):
>     pass
>
> class Something(object):
>     def __getattribute__(self, name):
>         print name
>         return DoNothing
>
>     def __call__(self):
>         print 'called'
>
>     def __getitem__(self, name):
>         raise Exception('w00t!')
>
>     def __setitem__(self, name, value):
>         raise Exception('w00t!')
>
> s = Something()
> s['fish'] = 3
>
> Does this on CPython:
>
> C:\compile\cext\trunk\cext>descriptors.py
> Traceback (most recent call last):
>   File "C:\compile\cext\trunk\cext\descriptors.py", line 20, in ?
>     s['fish'] = 3
>   File "C:\compile\cext\trunk\cext\descriptors.py", line 17, in __setitem__
>     raise Exception('w00t!')
> Exception: w00t!
>
> And this on IronPython 2a5:
>
> C:\compile\cext\trunk\cext>C:\compile\IronPython2\ipy.exe -D
> -X:TabCompletion -X
> :ColorfulConsole descriptors.py
> __setitem__
>
> To make things odder - if the class 'Something' doesn't have a
> __setitem__ method then an attribute error is correctly raised. For
> '__call__' I am *sometimes* seeing that go through '__getattribute__'
> and sometimes not...
>
> Michaelhttp://www.manning.com/foord
>
> _______________________________________________
> 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 dinov at exchange.microsoft.com  Mon Nov 12 19:09:50 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Nov 2007 10:09:50 -0800
Subject: [IronPython] Another trivial bug
In-Reply-To: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Monday, November 12, 2007 7:21 AM
To: Discussion of IronPython
Subject: [IronPython] Another trivial bug

Is trivial bugs week over yet?

Please fix
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814

This came to my attention thanks to a patch by Hajime Nakagami. The
bug is nearly a year old, and can only be explained by sloppiness.
Well, we all make mistakes...

Please fix it in both 1.x and 2.x. Thanks.

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


From fuzzyman at voidspace.org.uk  Mon Nov 12 19:12:29 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 12 Nov 2007 18:12:29 +0000
Subject: [IronPython] Another trivial bug
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <4738978D.4050400@voidspace.org.uk>

Dino Viehland wrote:
> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>   

Ah - great. When this week is over can you freeze the API so that I can 
write about it... ;-)

Michael
http://www.manning.com/foord

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
> Sent: Monday, November 12, 2007 7:21 AM
> To: Discussion of IronPython
> Subject: [IronPython] Another trivial bug
>
> Is trivial bugs week over yet?
>
> Please fix
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>
> This came to my attention thanks to a patch by Hajime Nakagami. The
> bug is nearly a year old, and can only be explained by sloppiness.
> Well, we all make mistakes...
>
> Please fix it in both 1.x and 2.x. Thanks.
>
> --
> Seo Sanghyeon
> _______________________________________________
> 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 exchange.microsoft.com  Mon Nov 12 19:26:54 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Nov 2007 10:26:54 -0800
Subject: [IronPython] Another trivial bug
In-Reply-To: <4738978D.4050400@voidspace.org.uk>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738978D.4050400@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

It won't be this week: we have a lot more than 1 week of work to do - both Tomas and I are working on hosting this week and next, and then more in a month, and probably more still in the coming months.  But the plan is that this will be the final hosting API modulo any small tweaks based upon issues discovered during implementation or external feedback.

I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain.  I think we'll also have a spec that's in good enough shape to send out soon but I'm not quite sure when that's happening.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, November 12, 2007 10:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Another trivial bug

Dino Viehland wrote:
> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>

Ah - great. When this week is over can you freeze the API so that I can
write about it... ;-)

Michael
http://www.manning.com/foord

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
> Sent: Monday, November 12, 2007 7:21 AM
> To: Discussion of IronPython
> Subject: [IronPython] Another trivial bug
>
> Is trivial bugs week over yet?
>
> Please fix
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>
> This came to my attention thanks to a patch by Hajime Nakagami. The
> bug is nearly a year old, and can only be explained by sloppiness.
> Well, we all make mistakes...
>
> Please fix it in both 1.x and 2.x. Thanks.
>
> --
> Seo Sanghyeon
> _______________________________________________
> 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  Mon Nov 12 20:22:47 2007
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Mon, 12 Nov 2007 11:22:47 -0800
Subject: [IronPython] Another trivial bug
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738978D.4050400@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <d2155e360711121122k56e0e7caib86879904aa47e32@mail.gmail.com>

On 11/12/07, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
>
> I guess now is as good as any time to announce that we're going to support
> multiple instances of engines in a single app domain.


I'm spectacularly happy about this; thanks for letting us know! :)

--
Curt Hagenlocher
curt at hagenlocher.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071112/59b1661d/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Nov 12 23:54:36 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 12 Nov 2007 22:54:36 +0000
Subject: [IronPython] [python] Re:  Another trivial bug
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<4738978D.4050400@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <4738D9AC.3010603@voidspace.org.uk>

That's great! Once you have added static compilation back into IP 2 we 
might be able to start using it at Resolver. :-)

Michael
http://www.manning.com/foord

Dino Viehland wrote:
> It won't be this week: we have a lot more than 1 week of work to do - both Tomas and I are working on hosting this week and next, and then more in a month, and probably more still in the coming months.  But the plan is that this will be the final hosting API modulo any small tweaks based upon issues discovered during implementation or external feedback.
>
> I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain.  I think we'll also have a spec that's in good enough shape to send out soon but I'm not quite sure when that's happening.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, November 12, 2007 10:12 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Another trivial bug
>
> Dino Viehland wrote:
>   
>> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>>
>>     
>
> Ah - great. When this week is over can you freeze the API so that I can
> write about it... ;-)
>
> Michael
> http://www.manning.com/foord
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
>> Sent: Monday, November 12, 2007 7:21 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] Another trivial bug
>>
>> Is trivial bugs week over yet?
>>
>> Please fix
>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>>
>> This came to my attention thanks to a patch by Hajime Nakagami. The
>> bug is nearly a year old, and can only be explained by sloppiness.
>> Well, we all make mistakes...
>>
>> Please fix it in both 1.x and 2.x. Thanks.
>>
>> --
>> Seo Sanghyeon
>> _______________________________________________
>> 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 exchange.microsoft.com  Tue Nov 13 00:00:49 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Nov 2007 15:00:49 -0800
Subject: [IronPython] [python] Re:  Another trivial bug
In-Reply-To: <4738D9AC.3010603@voidspace.org.uk>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738978D.4050400@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738D9AC.3010603@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AEDB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Do you mean the hacky static compilation which lets you create real .NET types or the pyc pre-compile support?  Hopefully it's the latter as I'm not sure the former will ever come back.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, November 12, 2007 2:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Another trivial bug

That's great! Once you have added static compilation back into IP 2 we
might be able to start using it at Resolver. :-)

Michael
http://www.manning.com/foord

Dino Viehland wrote:
> It won't be this week: we have a lot more than 1 week of work to do - both Tomas and I are working on hosting this week and next, and then more in a month, and probably more still in the coming months.  But the plan is that this will be the final hosting API modulo any small tweaks based upon issues discovered during implementation or external feedback.
>
> I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain.  I think we'll also have a spec that's in good enough shape to send out soon but I'm not quite sure when that's happening.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, November 12, 2007 10:12 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Another trivial bug
>
> Dino Viehland wrote:
>
>> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>>
>>
>
> Ah - great. When this week is over can you freeze the API so that I can
> write about it... ;-)
>
> Michael
> http://www.manning.com/foord
>
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
>> Sent: Monday, November 12, 2007 7:21 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] Another trivial bug
>>
>> Is trivial bugs week over yet?
>>
>> Please fix
>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>>
>> This came to my attention thanks to a patch by Hajime Nakagami. The
>> bug is nearly a year old, and can only be explained by sloppiness.
>> Well, we all make mistakes...
>>
>> Please fix it in both 1.x and 2.x. Thanks.
>>
>> --
>> Seo Sanghyeon
>> _______________________________________________
>> 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  Tue Nov 13 00:09:27 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 12 Nov 2007 23:09:27 +0000
Subject: [IronPython] [python] Re:  Another trivial bug
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AEDB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<4738978D.4050400@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<4738D9AC.3010603@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AEDB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <4738DD27.10507@voidspace.org.uk>

Dino Viehland wrote:
> Do you mean the hacky static compilation which lets you create real .NET types or the pyc pre-compile support?  Hopefully it's the latter as I'm not sure the former will ever come back.
>
>   

The latter. :-)

Michael

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, November 12, 2007 2:55 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Another trivial bug
>
> That's great! Once you have added static compilation back into IP 2 we
> might be able to start using it at Resolver. :-)
>
> Michael
> http://www.manning.com/foord
>
> Dino Viehland wrote:
>   
>> It won't be this week: we have a lot more than 1 week of work to do - both Tomas and I are working on hosting this week and next, and then more in a month, and probably more still in the coming months.  But the plan is that this will be the final hosting API modulo any small tweaks based upon issues discovered during implementation or external feedback.
>>
>> I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain.  I think we'll also have a spec that's in good enough shape to send out soon but I'm not quite sure when that's happening.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Monday, November 12, 2007 10:12 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Another trivial bug
>>
>> Dino Viehland wrote:
>>
>>     
>>> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>>>
>>>
>>>       
>> Ah - great. When this week is over can you freeze the API so that I can
>> write about it... ;-)
>>
>> Michael
>> http://www.manning.com/foord
>>
>>
>>     
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
>>> Sent: Monday, November 12, 2007 7:21 AM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] Another trivial bug
>>>
>>> Is trivial bugs week over yet?
>>>
>>> Please fix
>>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>>>
>>> This came to my attention thanks to a patch by Hajime Nakagami. The
>>> bug is nearly a year old, and can only be explained by sloppiness.
>>> Well, we all make mistakes...
>>>
>>> Please fix it in both 1.x and 2.x. Thanks.
>>>
>>> --
>>> Seo Sanghyeon
>>> _______________________________________________
>>> 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 exchange.microsoft.com  Tue Nov 13 00:13:56 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 12 Nov 2007 15:13:56 -0800
Subject: [IronPython] [python] Re:  Another trivial bug
In-Reply-To: <4738DD27.10507@voidspace.org.uk>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738978D.4050400@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738D9AC.3010603@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AEDB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<4738DD27.10507@voidspace.org.uk>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211AEED@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Awesome, I have no clue exactly when we'll bring it back (unfortunately we have a lot of dependencies on not doing it right now - every occurance of RuntimeConstant needs to be removed) but it's good to know that it's a pressing need for you.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, November 12, 2007 3:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Another trivial bug

Dino Viehland wrote:
> Do you mean the hacky static compilation which lets you create real .NET types or the pyc pre-compile support?  Hopefully it's the latter as I'm not sure the former will ever come back.
>
>

The latter. :-)

Michael

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, November 12, 2007 2:55 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Another trivial bug
>
> That's great! Once you have added static compilation back into IP 2 we
> might be able to start using it at Resolver. :-)
>
> Michael
> http://www.manning.com/foord
>
> Dino Viehland wrote:
>
>> It won't be this week: we have a lot more than 1 week of work to do - both Tomas and I are working on hosting this week and next, and then more in a month, and probably more still in the coming months.  But the plan is that this will be the final hosting API modulo any small tweaks based upon issues discovered during implementation or external feedback.
>>
>> I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain.  I think we'll also have a spec that's in good enough shape to send out soon but I'm not quite sure when that's happening.
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Monday, November 12, 2007 10:12 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Another trivial bug
>>
>> Dino Viehland wrote:
>>
>>
>>> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>>>
>>>
>>>
>> Ah - great. When this week is over can you freeze the API so that I can
>> write about it... ;-)
>>
>> Michael
>> http://www.manning.com/foord
>>
>>
>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
>>> Sent: Monday, November 12, 2007 7:21 AM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] Another trivial bug
>>>
>>> Is trivial bugs week over yet?
>>>
>>> Please fix
>>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>>>
>>> This came to my attention thanks to a patch by Hajime Nakagami. The
>>> bug is nearly a year old, and can only be explained by sloppiness.
>>> Well, we all make mistakes...
>>>
>>> Please fix it in both 1.x and 2.x. Thanks.
>>>
>>> --
>>> Seo Sanghyeon
>>> _______________________________________________
>>> 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 fuzzyman at voidspace.org.uk  Tue Nov 13 00:26:18 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 12 Nov 2007 23:26:18 +0000
Subject: [IronPython] [python] Re:  Another trivial bug
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AEED@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<4738978D.4050400@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<4738D9AC.3010603@voidspace.org.uk>	<7AD436E4270DD54A94238001769C2227E45211AEDB@DF-GRTDANE-MSG.exchange.corp.microsoft.com>	<4738DD27.10507@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AEED@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <4738E11A.1010002@voidspace.org.uk>

Cool - and thanks Dino. Although we ship sources to our customers we 
distribute our betas as binaries so we are dependent on it.

Michael
http://www.manning.com/foord

Dino Viehland wrote:
> Awesome, I have no clue exactly when we'll bring it back (unfortunately we have a lot of dependencies on not doing it right now - every occurance of RuntimeConstant needs to be removed) but it's good to know that it's a pressing need for you.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, November 12, 2007 3:09 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [python] Re: Another trivial bug
>
> Dino Viehland wrote:
>   
>> Do you mean the hacky static compilation which lets you create real .NET types or the pyc pre-compile support?  Hopefully it's the latter as I'm not sure the former will ever come back.
>>
>>
>>     
>
> The latter. :-)
>
> Michael
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Monday, November 12, 2007 2:55 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [python] Re: Another trivial bug
>>
>> That's great! Once you have added static compilation back into IP 2 we
>> might be able to start using it at Resolver. :-)
>>
>> Michael
>> http://www.manning.com/foord
>>
>> Dino Viehland wrote:
>>
>>     
>>> It won't be this week: we have a lot more than 1 week of work to do - both Tomas and I are working on hosting this week and next, and then more in a month, and probably more still in the coming months.  But the plan is that this will be the final hosting API modulo any small tweaks based upon issues discovered during implementation or external feedback.
>>>
>>> I guess now is as good as any time to announce that we're going to support multiple instances of engines in a single app domain.  I think we'll also have a spec that's in good enough shape to send out soon but I'm not quite sure when that's happening.
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>>> Sent: Monday, November 12, 2007 10:12 AM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Another trivial bug
>>>
>>> Dino Viehland wrote:
>>>
>>>
>>>       
>>>> It's technically over (now it's hosting API feature development week) but I still have 2 check-ins that aren't in yet.  I'll include this in one of those.
>>>>
>>>>
>>>>
>>>>         
>>> Ah - great. When this week is over can you freeze the API so that I can
>>> write about it... ;-)
>>>
>>> Michael
>>> http://www.manning.com/foord
>>>
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
>>>> Sent: Monday, November 12, 2007 7:21 AM
>>>> To: Discussion of IronPython
>>>> Subject: [IronPython] Another trivial bug
>>>>
>>>> Is trivial bugs week over yet?
>>>>
>>>> Please fix
>>>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>>>>
>>>> This came to my attention thanks to a patch by Hajime Nakagami. The
>>>> bug is nearly a year old, and can only be explained by sloppiness.
>>>> Well, we all make mistakes...
>>>>
>>>> Please fix it in both 1.x and 2.x. Thanks.
>>>>
>>>> --
>>>> Seo Sanghyeon
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From andy.tao at freeborders.com.cn  Tue Nov 13 01:49:05 2007
From: andy.tao at freeborders.com.cn (Andy.Tao)
Date: Tue, 13 Nov 2007 08:49:05 +0800
Subject: [IronPython] Another trivial bug
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com><7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-MSG.exchange.corp.microsoft.com><4738978D.4050400@voidspace.org.uk>
	<7AD436E4270DD54A94238001769C2227E45211AD81@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <001201c8258e$fe2a7c00$3069a8c0@china.freeborders>

Hi Dino,

I'm very excite that the final hosting api will be freezed and support
multiple instances of engines, I have waited a long time, hope your work
going well.

Andy Tao

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, November 13, 2007 02:27
To: Discussion of IronPython
Subject: Re: [IronPython] Another trivial bug

It won't be this week: we have a lot more than 1 week of work to do - both
Tomas and I are working on hosting this week and next, and then more in a
month, and probably more still in the coming months.  But the plan is that
this will be the final hosting API modulo any small tweaks based upon issues
discovered during implementation or external feedback.

I guess now is as good as any time to announce that we're going to support
multiple instances of engines in a single app domain.  I think we'll also
have a spec that's in good enough shape to send out soon but I'm not quite
sure when that's happening.

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, November 12, 2007 10:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Another trivial bug

Dino Viehland wrote:
> It's technically over (now it's hosting API feature development week) but
I still have 2 check-ins that aren't in yet.  I'll include this in one of
those.
>

Ah - great. When this week is over can you freeze the API so that I can
write about it... ;-)

Michael
http://www.manning.com/foord

> -----Original Message-----
> From: users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
> Sent: Monday, November 12, 2007 7:21 AM
> To: Discussion of IronPython
> Subject: [IronPython] Another trivial bug
>
> Is trivial bugs week over yet?
>
> Please fix
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5814
>
> This came to my attention thanks to a patch by Hajime Nakagami. The 
> bug is nearly a year old, and can only be explained by sloppiness.
> Well, we all make mistakes...
>
> Please fix it in both 1.x and 2.x. Thanks.
>
> --
> Seo Sanghyeon
> _______________________________________________
> 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 sanxiyn at gmail.com  Tue Nov 13 02:15:31 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 13 Nov 2007 10:15:31 +0900
Subject: [IronPython] Invoking delegate to abstract method
In-Reply-To: <5b0248170711082225g53565895j15ba671fef9b4b7e@mail.gmail.com>
References: <5b0248170711082225g53565895j15ba671fef9b4b7e@mail.gmail.com>
Message-ID: <5b0248170711121715s2aa3c930y19c30502fbb23ee8@mail.gmail.com>

2007/11/9, Sanghyeon Seo <sanxiyn at gmail.com>:
> For whatever reasons, IronPython 2.0 Alpha 6 started to invoke
> delegate to abstract method. (Previous versions didn't.) This
> triggered Mono bug 317488 which is apparently hard to fix.
> https://bugzilla.novell.com/show_bug.cgi?id=317488

Thankfully, Mono developers resolved this bug as of SVN r89500.

-- 
Seo Sanghyeon


From kfarmer at thuban.org  Tue Nov 13 02:53:51 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Mon, 12 Nov 2007 17:53:51 -0800
Subject: [IronPython] Pet peeve
References: <5b0248170711090605te27cb21qa08450f3155b1403@mail.gmail.com><7AD436E4270DD54A94238001769C2227DF52E09288@DF-GRTDANE-MSG.exchange.corp.microsoft.com><EEDCD954DD4A0D488BBDBDDCC26075442CC726@meta-exchange.circle-cross.home><b04bcd010711120217o187c2851id7e7e13485039fa@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD41@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075442CC728@meta-exchange.circle-cross.home>

The only problem I can see arises when none of your bugs are deemed "trivial".  :)

________________________________

From: users-bounces at lists.ironpython.com on behalf of Dino Viehland
Sent: Mon 11/12/2007 9:46 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Pet peeve



There's another school of thought that we should just fix them as they come in.  But fixing them in-bulk certainly gives me a warm fuzzy feeling. :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of James Murphy
Sent: Monday, November 12, 2007 2:17 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Pet peeve

On 10/11/2007, Keith J. Farmer <kfarmer at thuban.org> wrote:
> "Fix Trivial Bugs Week"?
>
> I like that idea.  Start a movement around it!

Its a winner - well actually its not since there's a weight of
argument that says that the trivial ones are possibly the ones that
should get hit first, or at least most often - but out here in the
real world...

We've been doing this with a project (although some of the bugs turn
out to be not so trivial) and its been having a positive effect (-:

--
Murph
_______________________________________________
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 Ben.Young at sungard.com  Tue Nov 13 08:53:05 2007
From: Ben.Young at sungard.com (Ben.Young at sungard.com)
Date: Tue, 13 Nov 2007 07:53:05 -0000
Subject: [IronPython] FW: DLR question
Message-ID: <18BD1BCF9DFF5D4EA617691F26ED717916BBE9@HUB-LON-MAIL01.internal.sungard.corp>

Hi there!

 

Is this the correct forum for questions about the DLR, or is there a
separate DLR mailing list somewhere?

 

Cheers,

Ben

 

Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:  This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this email in error,
please notify the sender and delete this email from your system.  Thank
you. 

 

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

From antont at kyperjokki.fi  Tue Nov 13 14:50:03 2007
From: antont at kyperjokki.fi (Toni Alatalo)
Date: Tue, 13 Nov 2007 15:50:03 +0200 (EET)
Subject: [IronPython] creating a scope for embedded scripts to run in
Message-ID: <Pine.LNX.4.63.0711131532110.22268@pallas.utanet.fi>

Hi,

I've been struggling a lot with trying to create a scope / namespace / 
environment / something for embedded scripts to run in.

Putting in instances with (in 2.0) SetVariable is fine, but so far I've 
not managed to put classes there (I wish classes were objects like in 
Python so things would just work .. in fact I'm considering porting this 
script server thing other people have earlier started as c# to ironpy to 
perhaps get rid of these probs :)

So I hope there is either something nice in the new Microsoft.Scripting 
API that I've not found yet, or something in the .net reflection system 
that am overlooking. Have tried this kind of things:

System.Type Timer = new 
System.Threading.Timer((System.Threading.TimerCallback)this.DummyTimerCallback).GetType();

Script.SetVariable("Timer", Timer);

.. but of course that just puts the (useless?) reflection class to the 
namespace, not the actual class that could be constructed? Perhaps that 
typeinfo-type can be used to instanciate with some Invoke thing, but 
obviously I don't want to expose that to scripters. Dunno if I could hide 
that in some wrapper funcs implemented on the py side.

Previously I've used this kind of technique to expose some modules for 
completely trusted scripts: (this from 1.1, in a project where we used 
Mogre - we are not using it in this project)

Mogre.Timer t = new Mogre.Timer(); //just to get the mogre module
python.LoadAssembly(t.GetType().Assembly); //gives 'Mogre'

so after that in 1.1 'import Mogre' worked in the scripts and that was 
fine there.

but now I'd like to give the scripts Threading.Timer, but not the whole 
System assembly.

I've seen the CreateModule etc. methods in ipy, and also now the new 
CreateScope thing in Microsoft.Scripting, but did not find any 
documentation on that - and anyway the same problem seems to be there that 
I can't put references to classes as values in the scopes.

Should I indeed try porting the whole thing to IronPython to perhaps get 
rid of this prob., or is there some nice way to expose assemblies or parts 
of them? Sorry if this is FAQ stuff but I did not find this in any of the 
embedding examples etc.

patiently looking forward to be shown the right path,
~Toni


From fuzzyman at voidspace.org.uk  Tue Nov 13 14:54:17 2007
From: fuzzyman at voidspace.org.uk (Fuzzyman)
Date: Tue, 13 Nov 2007 13:54:17 +0000
Subject: [IronPython] creating a scope for embedded scripts to run in
In-Reply-To: <Pine.LNX.4.63.0711131532110.22268@pallas.utanet.fi>
References: <Pine.LNX.4.63.0711131532110.22268@pallas.utanet.fi>
Message-ID: <4739AC89.4070107@voidspace.org.uk>

Hello Toni,

I don't have the API docs to hand - but what you want to do is to 
effectively execute an import statement in your namespace.

There may be an 'Import' method on the api somewhere, or maybe you can 
just execute the corresponding snippet of code in your namespace as part 
of initialising it.

Michael
http://www.manning.com/foord

Toni Alatalo wrote:

>Hi,
>
>I've been struggling a lot with trying to create a scope / namespace / 
>environment / something for embedded scripts to run in.
>
>Putting in instances with (in 2.0) SetVariable is fine, but so far I've 
>not managed to put classes there (I wish classes were objects like in 
>Python so things would just work .. in fact I'm considering porting this 
>script server thing other people have earlier started as c# to ironpy to 
>perhaps get rid of these probs :)
>
>So I hope there is either something nice in the new Microsoft.Scripting 
>API that I've not found yet, or something in the .net reflection system 
>that am overlooking. Have tried this kind of things:
>
>System.Type Timer = new 
>System.Threading.Timer((System.Threading.TimerCallback)this.DummyTimerCallback).GetType();
>
>Script.SetVariable("Timer", Timer);
>
>.. but of course that just puts the (useless?) reflection class to the 
>namespace, not the actual class that could be constructed? Perhaps that 
>typeinfo-type can be used to instanciate with some Invoke thing, but 
>obviously I don't want to expose that to scripters. Dunno if I could hide 
>that in some wrapper funcs implemented on the py side.
>
>Previously I've used this kind of technique to expose some modules for 
>completely trusted scripts: (this from 1.1, in a project where we used 
>Mogre - we are not using it in this project)
>
>Mogre.Timer t = new Mogre.Timer(); //just to get the mogre module
>python.LoadAssembly(t.GetType().Assembly); //gives 'Mogre'
>
>so after that in 1.1 'import Mogre' worked in the scripts and that was 
>fine there.
>
>but now I'd like to give the scripts Threading.Timer, but not the whole 
>System assembly.
>
>I've seen the CreateModule etc. methods in ipy, and also now the new 
>CreateScope thing in Microsoft.Scripting, but did not find any 
>documentation on that - and anyway the same problem seems to be there that 
>I can't put references to classes as values in the scopes.
>
>Should I indeed try porting the whole thing to IronPython to perhaps get 
>rid of this prob., or is there some nice way to expose assemblies or parts 
>of them? Sorry if this is FAQ stuff but I did not find this in any of the 
>embedding examples etc.
>
>patiently looking forward to be shown the right path,
>~Toni
>_______________________________________________
>Users mailing list
>Users at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>  
>



From Ben.Young at sungard.com  Tue Nov 13 15:04:50 2007
From: Ben.Young at sungard.com (Ben.Young at sungard.com)
Date: Tue, 13 Nov 2007 14:04:50 -0000
Subject: [IronPython] FW:  FW: DLR question
Message-ID: <18BD1BCF9DFF5D4EA617691F26ED717916BCF1@HUB-LON-MAIL01.internal.sungard.corp>

>From the silence I'll assume it is :)

I'm prototyping a new language (currently implemented in Python) and I am looking at the DLR to see if it can help make it speedy. However my language has the property that it can mutate it's own AST at any point, and from reading the IronPython and ToyScript sources it looks like the AST of the "source" program needs to be static. Is there anything I can make use of in the DLR here, or should I be resigned to implementing more than I'd hoped myself?

Cheers,
Ben


________________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ben.Young at sungard.com
Sent: 13 November 2007 07:53
To: users at lists.ironpython.com
Subject: [IronPython] FW: DLR question

Hi there!

Is this the correct forum for questions about the DLR, or is there a separate DLR mailing list somewhere?

Cheers,
Ben

Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:? This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited.? If you received this email in error, please notify the sender and delete this email from your system.? Thank you. 



From fuzzyman at voidspace.org.uk  Tue Nov 13 15:08:20 2007
From: fuzzyman at voidspace.org.uk (Fuzzyman)
Date: Tue, 13 Nov 2007 14:08:20 +0000
Subject: [IronPython] FW:  FW: DLR question
In-Reply-To: <18BD1BCF9DFF5D4EA617691F26ED717916BCF1@HUB-LON-MAIL01.internal.sungard.corp>
References: <18BD1BCF9DFF5D4EA617691F26ED717916BCF1@HUB-LON-MAIL01.internal.sungard.corp>
Message-ID: <4739AFD4.20301@voidspace.org.uk>

IIRC Martin Maly recommended this list for DLR questions. It is 
certainly populated with several of those involved in the implementation...

Can't help you with your specific question though (although it sounds 
very interesting).

Michael
http://www.manning.com/foord


Ben.Young at sungard.com wrote:

>>From the silence I'll assume it is :)
>
>I'm prototyping a new language (currently implemented in Python) and I am looking at the DLR to see if it can help make it speedy. However my language has the property that it can mutate it's own AST at any point, and from reading the IronPython and ToyScript sources it looks like the AST of the "source" program needs to be static. Is there anything I can make use of in the DLR here, or should I be resigned to implementing more than I'd hoped myself?
>
>Cheers,
>Ben
>
>
>________________________________________
>From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ben.Young at sungard.com
>Sent: 13 November 2007 07:53
>To: users at lists.ironpython.com
>Subject: [IronPython] FW: DLR question
>
>Hi there!
>
>Is this the correct forum for questions about the DLR, or is there a separate DLR mailing list somewhere?
>
>Cheers,
>Ben
>
>Ben Young - Senior Software Engineer
>SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
>Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/
>
>CONFIDENTIALITY:  This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited.  If you received this email in error, please notify the sender and delete this email from your system.  Thank you. 
>
>_______________________________________________
>Users mailing list
>Users at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>  
>



From antont at kyperjokki.fi  Tue Nov 13 15:09:26 2007
From: antont at kyperjokki.fi (Toni Alatalo)
Date: Tue, 13 Nov 2007 16:09:26 +0200 (EET)
Subject: [IronPython] creating a scope for embedded scripts to run in
In-Reply-To: <4739AC89.4070107@voidspace.org.uk>
References: <Pine.LNX.4.63.0711131532110.22268@pallas.utanet.fi>
	<4739AC89.4070107@voidspace.org.uk>
Message-ID: <Pine.LNX.4.63.0711131604430.22268@pallas.utanet.fi>

On Tue, 13 Nov 2007, Fuzzyman wrote:

> I don't have the API docs to hand - but what you want to do is to
> effectively execute an import statement in your namespace.

ah - there indeed is an import call in the API - i just always assumed 
that it works like import in the scripts, meaning that it can only import 
modules that have already been exposed to the scripts somehow.

but i'll test that next.

btw, from ironpython exposing classes seems to work just fine, so porting 
would indeed solve this:

IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference("IronPython.dll")
>>> clr.AddReference("Microsoft.Scripting.dll")
>>> import IronPython
>>> import Microsoft.Scripting
>>> py = IronPython.Hosting.PythonEngine.CurrentEngine;
>>> import System.Threading
>>> from Microsoft.Scripting import Script
>>> Script.SetVariable("Timer", System.Threading.Timer)
>>> Script.Execute("python", "print Timer")
<type 'Timer'>
>>> def p(s):
...     print s
...
>>> p('hep')
hep
>>> Script.SetVariable('p', p)
>>> Script.Execute("python", "p('hep')")
hep
>>> Script.Execute("python", "t = Timer(lambda x: p('tick')); 
t.Change(2000, 0)"
)
>>> tick

.. that last tick came from the worker thread 2s later, as i intended :)
now off to test how the imports work.

~Toni


From antont at kyperjokki.fi  Tue Nov 13 15:17:51 2007
From: antont at kyperjokki.fi (Toni Alatalo)
Date: Tue, 13 Nov 2007 16:17:51 +0200 (EET)
Subject: [IronPython] creating a scope for embedded scripts to run in
In-Reply-To: <Pine.LNX.4.63.0711131604430.22268@pallas.utanet.fi>
References: <Pine.LNX.4.63.0711131532110.22268@pallas.utanet.fi>
	<4739AC89.4070107@voidspace.org.uk>
	<Pine.LNX.4.63.0711131604430.22268@pallas.utanet.fi>
Message-ID: <Pine.LNX.4.63.0711131615060.22268@pallas.utanet.fi>

On Tue, 13 Nov 2007, Toni Alatalo wrote:
> ah - there indeed is an import call in the API - i just always assumed
> that it works like import in the scripts, meaning that it can only import
> modules that have already been exposed to the scripts somehow.

yah seems my assumption there was just wrong, importing all the standard 
.net modules just works in the embedded scripts. am sorry for the noise, 
will need to study restricted contexts later but can proceed fine with 
the unrestricted environment now.

> ~Toni

same.


From fuzzyman at voidspace.org.uk  Tue Nov 13 15:41:41 2007
From: fuzzyman at voidspace.org.uk (Fuzzyman)
Date: Tue, 13 Nov 2007 14:41:41 +0000
Subject: [IronPython] FW:  FW: DLR question
In-Reply-To: <18BD1BCF9DFF5D4EA617691F26ED717916BD02@HUB-LON-MAIL01.internal.sungard.corp>
References: <18BD1BCF9DFF5D4EA617691F26ED717916BD02@HUB-LON-MAIL01.internal.sungard.corp>
Message-ID: <4739B7A5.50800@voidspace.org.uk>

Ben.Young at sungard.com wrote:

>Thanks! It's basically a very python like language, but where all
>indentation structures call functions that return the representative
>AST, instead of being hard coded (I guess it's a bit like lisp macros,
>without the separate expansion stage). This makes for a very small
>grammar, and easy addition of new functionality (i.e the "with"
>statement can be implemented in the language itself)
>  
>

Sounds like something I have been thinking of (except yours is taken to
the next level). I was thinking of using something like ANTLR as the
parser and then doing an AST transform to generate a valid Python AST -
allowing me to experiment with adding new language features as syntactic
sugar.

Your idea is better of course. :-)

Michael
http://www.manning.com/foord

>Cheers,
>Ben
>
>-----Original Message-----
>From: Michael Foord [mailto:fuzzyman at gmail.com] On Behalf Of Fuzzyman
>Sent: 13 November 2007 14:08
>To: python at theyoungfamily.co.uk; Discussion of IronPython
>Subject: Re: [IronPython] FW: FW: DLR question
>
>IIRC Martin Maly recommended this list for DLR questions. It is 
>certainly populated with several of those involved in the
>implementation...
>
>Can't help you with your specific question though (although it sounds 
>very interesting).
>
>Michael
>http://www.manning.com/foord
>
>
>Ben.Young at sungard.com wrote:
>
>  
>
>>>From the silence I'll assume it is :)
>>
>>I'm prototyping a new language (currently implemented in Python) and I
>>    
>>
>am looking at the DLR to see if it can help make it speedy. However my
>language has the property that it can mutate it's own AST at any point,
>and from reading the IronPython and ToyScript sources it looks like the
>AST of the "source" program needs to be static. Is there anything I can
>make use of in the DLR here, or should I be resigned to implementing
>more than I'd hoped myself?
>  
>
>>Cheers,
>>Ben
>>
>>
>>________________________________________
>>From: users-bounces at lists.ironpython.com
>>    
>>
>[mailto:users-bounces at lists.ironpython.com] On Behalf Of
>Ben.Young at sungard.com
>  
>
>>Sent: 13 November 2007 07:53
>>To: users at lists.ironpython.com
>>Subject: [IronPython] FW: DLR question
>>
>>Hi there!
>>
>>Is this the correct forum for questions about the DLR, or is there a
>>    
>>
>separate DLR mailing list somewhere?
>  
>
>>Cheers,
>>Ben
>>
>>Ben Young - Senior Software Engineer
>>SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
>>Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/
>>
>>CONFIDENTIALITY:  This email (including any attachments) may contain
>>    
>>
>confidential, proprietary and privileged information, and unauthorized
>disclosure or use is prohibited.  If you received this email in error,
>please notify the sender and delete this email from your system.  Thank
>you. 
>  
>
>>_______________________________________________
>>Users mailing list
>>Users at lists.ironpython.com
>>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>> 
>>
>>    
>>
>
>
>
>
>  
>




From dinov at exchange.microsoft.com  Tue Nov 13 18:07:47 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 13 Nov 2007 09:07:47 -0800
Subject: [IronPython] FW:  FW: DLR question
In-Reply-To: <18BD1BCF9DFF5D4EA617691F26ED717916BCF1@HUB-LON-MAIL01.internal.sungard.corp>
References: <18BD1BCF9DFF5D4EA617691F26ED717916BCF1@HUB-LON-MAIL01.internal.sungard.corp>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211B014@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

There's no direct support for this but it shouldn't be too hard to do.  You can carry the AST around w/ you by doing an Ast.RuntimeConstant(myAstRoot).

For example let's say that we wanted to hold onto the AST for all Python functions.  Over in FunctionDefinition.cs we call a helper method called MakeFunction to create the real Python function object.  We could add a new parameter there (because we don't have enough :)) and then do:

            MSAst.Expression ret = Ast.Call(
                typeof(PythonFunction).GetMethod("MakeFunction"),                               // method
                Ast.CodeContext(),                                                              // 1. Emit CodeContext
                Ast.Constant(SymbolTable.IdToString(_name)),                                    // 2. FunctionName
                Ast.CodeBlockExpression(code, flags != FunctionAttributes.None),                // 3. delegate
                Ast.NewArray(typeof(string[]), names),                                          // 4. parameter names
                Ast.NewArray(typeof(object[]), defaults),                                       // 5. default values
                Ast.Constant(flags),                                                            // 6. flags
                Ast.Constant(_body.Documentation, typeof(string)),                              // 7. doc string or null
                Ast.Constant(this.Start.Line),                                                  // 8. line number
                Ast.Constant(_sourceUnit.GetSymbolDocument(this.Start.Line), typeof(string))    // 9. Filename
                    Ast.Constant(code)          // or maybe code.Body ?
            );


>From there we could then use the AST to create a new AST, create a new CodeBlock, and then replace the delegate the PythonFunction instance holds onto w/ a new delegate.  Unfortunately if there's going to be lots of mutation then there's going to be lots of compilation which isn't going to be too good.  You could also try interpreted mode to reduce that overhead (also we do have some profile driven compilation features which could help make this determination for you automatically but they're very na?ve at this point).

And as a random thought: does the AST actually need to change or just the actions the code performs at runtime?  If the AST just represents the structure of the code you could insert a bunch of helper calls who's behavior changes as the AST 'mutates'.  As an aside we eventually want to support custom DynamicSite's which would enable you to do any 'operation' you care about.  Once we had that support you could turn these helper calls into dynamic sites in order to improve the perf.

That might not have been quite the answer you're looking for but hopefully it's some food for thought that will help you determine if you can do what you need.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ben.Young at sungard.com
Sent: Tuesday, November 13, 2007 6:05 AM
To: users at lists.ironpython.com
Subject: [IronPython] FW: FW: DLR question

>From the silence I'll assume it is :)

I'm prototyping a new language (currently implemented in Python) and I am looking at the DLR to see if it can help make it speedy. However my language has the property that it can mutate it's own AST at any point, and from reading the IronPython and ToyScript sources it looks like the AST of the "source" program needs to be static. Is there anything I can make use of in the DLR here, or should I be resigned to implementing more than I'd hoped myself?

Cheers,
Ben


________________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ben.Young at sungard.com
Sent: 13 November 2007 07:53
To: users at lists.ironpython.com
Subject: [IronPython] FW: DLR question

Hi there!

Is this the correct forum for questions about the DLR, or is there a separate DLR mailing list somewhere?

Cheers,
Ben

Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:  This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited.  If you received this email in error, please notify the sender and delete this email from your system.  Thank you.

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


From miguel at novell.com  Tue Nov 13 20:29:35 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Tue, 13 Nov 2007 14:29:35 -0500
Subject: [IronPython] Another trivial bug
In-Reply-To: <1194892560.4283.190.camel@erandi.boston.ximian.com>
References: <5b0248170711120720o3296651foa89d1c66cc00217b@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45211AD68@DF-GRTDANE-M
	SG.exchange.corp.microsoft.com> <4738978D.4050400@voidspace.org.uk>
	<1194892560.4283.190.camel@erandi.boston.ximian.com>
Message-ID: <1194982175.4135.60.camel@erandi.boston.ximian.com>


> I guess now is as good as any time to announce that we're going to
> support multiple instances of engines in a single app domain.  I think
> we'll also have a spec that's in good enough shape to send out soon
> but I'm not quite sure when that's happening.

This is brilliant!

Thanks for considering the implementation of this feature.

Miguel.


From jdhardy at gmail.com  Wed Nov 14 03:05:39 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 13 Nov 2007 19:05:39 -0700
Subject: [IronPython] Announcing NWSGI
Message-ID: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>

Hi all,
I've been wanting to experiment with various Python web frameworks for
a while now, but have been held up by problems getting them to run on
Windows. It's not impossible, but it sure can be tricky. I also wanted
to try running some larger Python apps against IronPython, to help
flush out bugs in IP. I decided to see if I could implement a WSGI
server as an ASP.NET HttpHandler and get some of the frameworks to run
with IronPython. The result was NWSGI.

It works, sort of. You an run very simple applications and any very
simple stuff from Paste, but moving up to larger frameworks causes it
to fall over fairly quickly. I'm not sure all of these are problems
with IronPython; without any docs on the  hosting APIs, I had to make
most of it up as I went along. I'm sure they're are better ways to do
some of the things I did, or that better ways are coming in the
hosting API rewrite.

I'm well aware that the hosting APIs are up for a rewrite soon. I'm
hoping this can serve as a test of the APIs. WSGI is simple but it
makes some interesting requirements of a non-Python host.

I'm also aware of Seo's and others' work on a similar setup for
IronPython 1.0 (included with FePy). The two major differences are
that this is a 2.0-targeted version, and that NWSGI is a pure C#
implementation (the old one uses a Python file for most of the work).

The code and some setup instructions are available at
http://www.codeplex.com/NWSGI (or should be shortly). Any feedback is
greatly appreciated.

Thanks,
Jeff Hardy


From kfarmer at thuban.org  Wed Nov 14 03:52:23 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Tue, 13 Nov 2007 18:52:23 -0800
Subject: [IronPython] Announcing NWSGI
In-Reply-To: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>
References: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075441E0B10@meta-exchange.circle-cross.home>

For those not in that particular loop, could you describe what WSGI is? :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Tuesday, November 13, 2007 6:06 PM
To: users at lists.ironpython.com
Subject: [IronPython] Announcing NWSGI

Hi all,
I've been wanting to experiment with various Python web frameworks for
a while now, but have been held up by problems getting them to run on
Windows. It's not impossible, but it sure can be tricky. I also wanted
to try running some larger Python apps against IronPython, to help
flush out bugs in IP. I decided to see if I could implement a WSGI
server as an ASP.NET HttpHandler and get some of the frameworks to run
with IronPython. The result was NWSGI.

It works, sort of. You an run very simple applications and any very
simple stuff from Paste, but moving up to larger frameworks causes it
to fall over fairly quickly. I'm not sure all of these are problems
with IronPython; without any docs on the  hosting APIs, I had to make
most of it up as I went along. I'm sure they're are better ways to do
some of the things I did, or that better ways are coming in the
hosting API rewrite.

I'm well aware that the hosting APIs are up for a rewrite soon. I'm
hoping this can serve as a test of the APIs. WSGI is simple but it
makes some interesting requirements of a non-Python host.

I'm also aware of Seo's and others' work on a similar setup for
IronPython 1.0 (included with FePy). The two major differences are
that this is a 2.0-targeted version, and that NWSGI is a pure C#
implementation (the old one uses a Python file for most of the work).

The code and some setup instructions are available at
http://www.codeplex.com/NWSGI (or should be shortly). Any feedback is
greatly appreciated.

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

From corrin.lakeland at loyalty.co.nz  Wed Nov 14 04:01:15 2007
From: corrin.lakeland at loyalty.co.nz (Corrin Lakeland)
Date: Wed, 14 Nov 2007 16:01:15 +1300
Subject: [IronPython] Announcing NWSGI
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC26075441E0B10@meta-exchange.circle-cross.home>
References: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>
	<EEDCD954DD4A0D488BBDBDDCC26075441E0B10@meta-exchange.circle-cross.home>
Message-ID: <950F61F2E4D1A74E8BBB28C50D06D1BF01044F8C@LNZLWLGSEX01.lnzl.co.nz>

http://ivory.idyll.org/articles/wsgi-intro/what-is-wsgi.html

In Brief

WSGI is a specification, laid out in PEP 333, for a standardized
interface between Web servers and Python Web frameworks/applications.

The goal is to provide a relatively simple yet comprehensive interface
capable of supporting all (or most) interactions between a Web server
and a Web framework. (Think "CGI" but programmatic rather than I/O
based.)

An additional goal is to support "middleware" components for pre- and
post-processing of requests: think gzip, recording, proxy,
load-balancing.

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Wednesday, 14 November 2007 3:52 p.m.
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing NWSGI

For those not in that particular loop, could you describe what WSGI is?
:)


______________________________________________________________________________

CAUTION: This e-mail message and accompanying data or attachments
may contain information that is confidential, proprietary and/or
subject to legal privilege. If you are not the intended recipient,
you must not directly or indirectly read, use, disseminate, distribute,
print or copy this email or attachments. If you have received this
e-mail in error, please notify us immediately and delete all material
pertaining to this e-mail. Please also note that the opinions expressed
in this document are those of the author, and not necessarily those of
Loyalty New Zealand Limited.

DISCLAIMER: To the maximum extent permitted by law, Loyalty New Zealand
Limited is not liable (including in respect for negligence) for viruses
or other defects or for changes made to this email or to any attachments.
Before opening or using attachments, check them for viruses and other defects.

______________________________________________________________________________


From sanxiyn at gmail.com  Wed Nov 14 04:29:26 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 14 Nov 2007 12:29:26 +0900
Subject: [IronPython] Announcing NWSGI
In-Reply-To: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>
References: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>
Message-ID: <5b0248170711131929i77e4c824vdc202c4c93d27eda@mail.gmail.com>

2007/11/14, Jeff Hardy <jdhardy at gmail.com>:
> I'm also aware of Seo's and others' work on a similar setup for
> IronPython 1.0 (included with FePy). The two major differences are
> that this is a 2.0-targeted version, and that NWSGI is a pure C#
> implementation (the old one uses a Python file for most of the work).

I don't understand why "written in pure C#" is an advantage (given
that you need Python engine to implement WSGI anyway), or why using
Python is an disadvantage (after all Python is a better language than
C#, isn't it? If it isn't why are you using WSGI?), but I guess it's a
matter of opinion.

Also note that writing most codes in Python neatly avoids any hosting
API issues.

I hope you best luck, but I strongly believe writing most codes in
Python is the right implementation choice.

-- 
Seo Sanghyeon


From nekomaho at gmail.com  Wed Nov 14 13:43:19 2007
From: nekomaho at gmail.com (nekomaho)
Date: Wed, 14 Nov 2007 21:43:19 +0900
Subject: [IronPython] AttributeError: '__ComObject' object has no attribute
	'Visible'
Message-ID: <473AED67.5040309@gmail.com>

Hi,

I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?

IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> from System import Type, Activator
>>> t = Type.GetTypeFromProgID('Excel.Application')
>>> e = Activator.CreateInstance(t)
>>> e.Visible = True
Traceback (most recent call last):
  File , line 0, in ##29
AttributeError: '__ComObject' object has no attribute 'Visible'

>>> 'Visible' in dir(e)
True


From m_tayseer82 at yahoo.com  Wed Nov 14 17:02:23 2007
From: m_tayseer82 at yahoo.com (Mohammad Tayseer)
Date: Wed, 14 Nov 2007 08:02:23 -0800 (PST)
Subject: [IronPython] AttributeError: '__ComObject' object has no
	attribute 'Visible'
Message-ID: <838491.95529.qm@web31102.mail.mud.yahoo.com>

It works for me. What version of Excel do you use??
 
Mohammad Tayseer
http://spellcoder.com/blogs/tayseer


----- Original Message ----
From: nekomaho <nekomaho at gmail.com>



Hi,

I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?







      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071114/2682f709/attachment.html>

From dfugate at microsoft.com  Wed Nov 14 18:58:01 2007
From: dfugate at microsoft.com (Dave Fugate)
Date: Wed, 14 Nov 2007 09:58:01 -0800
Subject: [IronPython] AttributeError: '__ComObject' object has
	no	attribute 'Visible'
In-Reply-To: <838491.95529.qm@web31102.mail.mud.yahoo.com>
References: <838491.95529.qm@web31102.mail.mud.yahoo.com>
Message-ID: <7346A825E148B049A9AD1D3ED46A2D9116C181F63E@NA-EXMSG-C106.redmond.corp.microsoft.com>

This works for me as well.  Could you please re-run your code snippet under the -X:ExceptionDetail mode and send us the output?  Also, what versions of Windows and Office are being used?

Thanks

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammad Tayseer
Sent: Wednesday, November 14, 2007 8:02 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'

It works for me. What version of Excel do you use??

Mohammad Tayseer
http://spellcoder.com/blogs/tayseer

----- Original Message ----
From: nekomaho <nekomaho at gmail.com>


Hi,

I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?


________________________________
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.<http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071114/bbab8c47/attachment.html>

From nekomaho at gmail.com  Thu Nov 15 13:45:16 2007
From: nekomaho at gmail.com (nekomaho)
Date: Thu, 15 Nov 2007 21:45:16 +0900
Subject: [IronPython] AttributeError: '__ComObject' object
 has	no	attribute 'Visible'
In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D9116C181F63E@NA-EXMSG-C106.redmond.corp.microsoft.com>
References: <838491.95529.qm@web31102.mail.mud.yahoo.com>
	<7346A825E148B049A9AD1D3ED46A2D9116C181F63E@NA-EXMSG-C106.redmond.corp.microsoft.com>
Message-ID: <473C3F5C.9050204@gmail.com>

Hi,

I use Windows XP Pro SP2 ja & Office 2007 Pro ja.

IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion -X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> from System import Type, Activator
>>> t = Type.GetTypeFromProgID('Excel.Application')
>>> e = Activator.CreateInstance(t)
>>> e.Visible = True
'__ComObject' object has no attribute 'Visible'
   ?? Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
   ?? Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
   ?? Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext callerContext, DynamicAction action, Object[] args, Object site, T& target, RuleSet`1& rules)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 arg0, T1 arg1)
   ?? ##29(Object[] , CodeContext )
   ?? Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate)
   ?? Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   ?? Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
   ?? Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScriptModule module)
   ?? Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   ?? Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   ?? IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   ?? Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'

Thanks

> This works for me as well.  Could you please re-run your code snippet under the -X:ExceptionDetail mode and send us the output?  Also, what versions of Windows and Office are being used?
> 
> Thanks
> 
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammad Tayseer
> Sent: Wednesday, November 14, 2007 8:02 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'
> 
> It works for me. What version of Excel do you use??
> 
> Mohammad Tayseer
> http://spellcoder.com/blogs/tayseer
> 
> ----- Original Message ----
> From: nekomaho <nekomaho at gmail.com>
> 
> 
> Hi,
> 
> I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?
> 
> 
> ________________________________
> Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.<http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.com/>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From jdhardy at gmail.com  Thu Nov 15 15:49:50 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 15 Nov 2007 07:49:50 -0700
Subject: [IronPython] Announcing NWSGI
In-Reply-To: <5b0248170711131929i77e4c824vdc202c4c93d27eda@mail.gmail.com>
References: <ea89d0e50711131805s275b7420oaa0590965ddaa6c9@mail.gmail.com>
	<5b0248170711131929i77e4c824vdc202c4c93d27eda@mail.gmail.com>
Message-ID: <ea89d0e50711150649w63e229b4h3eae2eff6bd97de9@mail.gmail.com>

Hi Seo,

On Nov 13, 2007 8:29 PM, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
> I don't understand why "written in pure C#" is an advantage (given
> that you need Python engine to implement WSGI anyway), or why using
> Python is an disadvantage (after all Python is a better language than
> C#, isn't it? If it isn't why are you using WSGI?), but I guess it's a
> matter of opinion.
>
> Also note that writing most codes in Python neatly avoids any hosting
> API issues.
>
> I hope you best luck, but I strongly believe writing most codes in
> Python is the right implementation choice.

I'm not 100% convinced pure C# is a huge advantage either :). It does
have a few advantages, such as simplyfying deployment (slightly) - and
if all of the necessary assemblies are in the GAC, then deployment is
as simple as creating a web.config (on IIS 7, all of the editing could
be done with the GUI - you wouldn't even need to see the web.config).
Also, I believe that if the hosting API can't handle this easily, then
there are problems with the hosting API.

That said, I'm not religious about it, which is why I've avoided
making any judgement as to which is approch is "better". It's a lot of
work to get a small advantage when deploying, and if it proves to be
too much effort I'll just give up and port yours to IP 2. I don't
think that will have to be case, based on what I've done so far.

- Jeff


From Shri.Borde at microsoft.com  Thu Nov 15 19:51:37 2007
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 15 Nov 2007 10:51:37 -0800
Subject: [IronPython] AttributeError: '__ComObject' object has no
 attribute 'Visible' with -X:PreferComDispatch
In-Reply-To: <473C3F5C.9050204@gmail.com>
References: <838491.95529.qm@web31102.mail.mud.yahoo.com>
	<7346A825E148B049A9AD1D3ED46A2D9116C181F63E@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<473C3F5C.9050204@gmail.com>
Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EC58FC5AEB7@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

The behavior currently depends on whether or not the RCW gets strongly-typed when it enters the managed world. As a workaround, the following registry script Misha provided could "fix" your machine by registering the PIA:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32]
"Assembly"="Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
"Class"="Microsoft.Office.Interop.Excel.ApplicationClass"
"RuntimeVersion"="v1.1.4322"

[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0]
"Assembly"="Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
"Class"="Microsoft.Office.Interop.Excel.ApplicationClass"
"RuntimeVersion"="v1.1.4322"

Your script should work independent of whether the PIA is registered or not. We will look into it and see what is going.

The implementation of -X:PreferComDispatch is still not complete. We are working on improving it and will enable it by default once all issues are flushed out. You are on the cutting edge and providing us with advance feedback :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of nekomaho
Sent: Thursday, November 15, 2007 4:45 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'

Hi,

I use Windows XP Pro SP2 ja & Office 2007 Pro ja.

IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion -X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> from System import Type, Activator
>>> t = Type.GetTypeFromProgID('Excel.Application')
>>> e = Activator.CreateInstance(t)
>>> e.Visible = True
'__ComObject' object has no attribute 'Visible'
   ?? Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
   ?? Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
   ?? Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext callerContext, DynamicAction action, Object[] args, Object site, T& target, RuleSet`1& rules)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 arg0, T1 arg1)
   ?? ##29(Object[] , CodeContext )
   ?? Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate)
   ?? Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   ?? Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
   ?? Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScriptModule module)
   ?? Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   ?? Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   ?? IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   ?? Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'

Thanks

> This works for me as well.  Could you please re-run your code snippet under the -X:ExceptionDetail mode and send us the output?  Also, what versions of Windows and Office are being used?
>
> Thanks
>
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammad Tayseer
> Sent: Wednesday, November 14, 2007 8:02 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'
>
> It works for me. What version of Excel do you use??
>
> Mohammad Tayseer
> http://spellcoder.com/blogs/tayseer
>
> ----- Original Message ----
> From: nekomaho <nekomaho at gmail.com>
>
>
> Hi,
>
> I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?
>
>
> ________________________________
> Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.<http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.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 nekomaho at gmail.com  Fri Nov 16 11:46:32 2007
From: nekomaho at gmail.com (nekomaho)
Date: Fri, 16 Nov 2007 19:46:32 +0900
Subject: [IronPython] AttributeError: '__ComObject' object has no
 attribute 'Visible' with -X:PreferComDispatch
In-Reply-To: <50B69702CA6E6D4E849D30CD4989AB8EC58FC5AEB7@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <838491.95529.qm@web31102.mail.mud.yahoo.com>	<7346A825E148B049A9AD1D3ED46A2D9116C181F63E@NA-EXMSG-C106.redmond.corp.microsoft.com>	<473C3F5C.9050204@gmail.com>
	<50B69702CA6E6D4E849D30CD4989AB8EC58FC5AEB7@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <473D7508.1060709@gmail.com>

Hi,

I changed registry but I get same error.

IronPython-2.0A6>reg query HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32 /s

! REG.EXE VERSION 3.0

HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32
    Class       REG_SZ  Microsoft.Office.Interop.Excel.ApplicationClass
    RuntimeVersion      REG_SZ  v1.1.4322

HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0
    Class       REG_SZ  Microsoft.Office.Interop.Excel.ApplicationClass
    RuntimeVersion      REG_SZ  v1.1.4322

IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion -X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> from System import Type, Activator
>>> t = Type.GetTypeFromProgID('Excel.Application')
>>> e = Activator.CreateInstance(t)
>>> e.Visible = True
'__ComObject' object has no attribute 'Visible'
   ?? Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
   ?? Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
   ?? Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext callerContext, DynamicAction action, Object[] args, Object site, T& target, RuleSet`1& rules)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 arg0, T1 arg1)
   ?? ##29(Object[] , CodeContext )
   ?? Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate)
   ?? Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   ?? Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
   ?? Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScriptModule module)
   ?? Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   ?? Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   ?? IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   ?? Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'

Thanks

> The behavior currently depends on whether or not the RCW gets strongly-typed when it enters the managed world. As a workaround, the following registry script Misha provided could "fix" your machine by registering the PIA:
> 
> Windows Registry Editor Version 5.00
> 
> [HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32]
> "Assembly"="Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
> "Class"="Microsoft.Office.Interop.Excel.ApplicationClass"
> "RuntimeVersion"="v1.1.4322"
> 
> [HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0]
> "Assembly"="Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
> "Class"="Microsoft.Office.Interop.Excel.ApplicationClass"
> "RuntimeVersion"="v1.1.4322"
> 
> Your script should work independent of whether the PIA is registered or not. We will look into it and see what is going.
> 
> The implementation of -X:PreferComDispatch is still not complete. We are working on improving it and will enable it by default once all issues are flushed out. You are on the cutting edge and providing us with advance feedback :)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of nekomaho
> Sent: Thursday, November 15, 2007 4:45 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'
> 
> Hi,
> 
> I use Windows XP Pro SP2 ja & Office 2007 Pro ja.
> 
> IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion -X:ExceptionDetail
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import clr
>>>> from System import Type, Activator
>>>> t = Type.GetTypeFromProgID('Excel.Application')
>>>> e = Activator.CreateInstance(t)
>>>> e.Visible = True
> '__ComObject' object has no attribute 'Visible'
>    ?? Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
>    ?? Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
>    ?? Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext callerContext, DynamicAction action, Object[] args, Object site, T& target, RuleSet`1& rules)
>    ?? Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext context, T0 arg0, T1 arg1)
>    ?? Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
>    ?? Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 arg0, T1 arg1)
>    ?? ##29(Object[] , CodeContext )
>    ?? Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate)
>    ?? Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>    ?? Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
>    ?? Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScriptModule module)
>    ?? Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>    ?? Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>    ?? IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>    ?? Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> AttributeError: '__ComObject' object has no attribute 'Visible'
> 
> Thanks
> 
>> This works for me as well.  Could you please re-run your code snippet under the -X:ExceptionDetail mode and send us the output?  Also, what versions of Windows and Office are being used?
>>
>> Thanks
>>
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammad Tayseer
>> Sent: Wednesday, November 14, 2007 8:02 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'
>>
>> It works for me. What version of Excel do you use??
>>
>> Mohammad Tayseer
>> http://spellcoder.com/blogs/tayseer
>>
>> ----- Original Message ----
>> From: nekomaho <nekomaho at gmail.com>
>>
>>
>> Hi,
>>
>> I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?
>>
>>
>> ________________________________
>> Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.<http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.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 ronnie.maor at gmail.com  Fri Nov 16 17:04:08 2007
From: ronnie.maor at gmail.com (Ronnie Maor)
Date: Fri, 16 Nov 2007 18:04:08 +0200
Subject: [IronPython] (trivial) bug in binding varargs
Message-ID: <2fd6b9d0711160804v5c90a2a7la9dce031acef20d6@mail.gmail.com>

I know "fix trivial bugs week" is over, but still...

python 2.5:
>>> def log(*a,**kw):
	print 'a=%s, kw=%s' % (a,kw)

>>> def foo(*a,**kw):
	log(a=a,kw=kw)
	
>>> foo(1,2,x=3)
a=(), kw={'a': (1, 2), 'kw': {'x': 3}}


ironpython 1.1:
>>> def log(*a,**kw):
...     print 'a=%s, kw=%s' % (a,kw)
...
>>> def foo(*a,**kw):
...     log(a=a,kw=kw)
...
>>> foo(1,2,x=3)
Traceback (most recent call last):
  File , line 0, in <stdin>##18
  File , line 0, in foo
  File , line 0, in foo
TypeError: log() got an unexpected keyword argument 'a'

workaround I used was changing "foo" to:
   log(args=a,kwargs=kw)


From dinov at exchange.microsoft.com  Fri Nov 16 18:07:36 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 16 Nov 2007 09:07:36 -0800
Subject: [IronPython] (trivial) bug in binding varargs
In-Reply-To: <2fd6b9d0711160804v5c90a2a7la9dce031acef20d6@mail.gmail.com>
References: <2fd6b9d0711160804v5c90a2a7la9dce031acef20d6@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45211B959@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Luckily this is already fixed in 2.0 (method dispatch, in particular kw-arg dispatch, is completely different now).

We're discussing v1.x servicing plans next week so I'm going to hold off on opening a bug but will follow up after that.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor
Sent: Friday, November 16, 2007 8:04 AM
To: users at lists.ironpython.com
Subject: [IronPython] (trivial) bug in binding varargs

I know "fix trivial bugs week" is over, but still...

python 2.5:
>>> def log(*a,**kw):
        print 'a=%s, kw=%s' % (a,kw)

>>> def foo(*a,**kw):
        log(a=a,kw=kw)

>>> foo(1,2,x=3)
a=(), kw={'a': (1, 2), 'kw': {'x': 3}}


ironpython 1.1:
>>> def log(*a,**kw):
...     print 'a=%s, kw=%s' % (a,kw)
...
>>> def foo(*a,**kw):
...     log(a=a,kw=kw)
...
>>> foo(1,2,x=3)
Traceback (most recent call last):
  File , line 0, in <stdin>##18
  File , line 0, in foo
  File , line 0, in foo
TypeError: log() got an unexpected keyword argument 'a'

workaround I used was changing "foo" to:
   log(args=a,kwargs=kw)
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From Shri.Borde at microsoft.com  Fri Nov 16 21:42:50 2007
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Fri, 16 Nov 2007 12:42:50 -0800
Subject: [IronPython] AttributeError: '__ComObject' object has no
 attribute 'Visible' with -X:PreferComDispatch
In-Reply-To: <473D7508.1060709@gmail.com>
References: <838491.95529.qm@web31102.mail.mud.yahoo.com>
	<7346A825E148B049A9AD1D3ED46A2D9116C181F63E@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<473C3F5C.9050204@gmail.com>
	<50B69702CA6E6D4E849D30CD4989AB8EC58FC5AEB7@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<473D7508.1060709@gmail.com>
Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EC590263C18@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Misha said - "I should add that having the registry keys alone would only help if Excel PIAs are in the GAC as well (when installing Excel - you would choose .NET Interoperability support)." You probably do not have the PIAs installed.

The problem is just a matter of initialiazation order. The IDispatch support was not initialized by the time the "e.Visible = True" statement was executed. I have a fix and have just checked it in. The next IronPython drop should have the fix. If you want a fix now, you can add the following lines at the very start of PythonBinder.GetExtensionTypes.

    // Ensure that the type is initialized. If ReflectedTypeBuilder.RegisterAlternateBuilder was used,
    // the alternate builder will get a chance to initialize the type.
    DynamicHelpers.GetPythonTypeFromType(t);

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of nekomaho
Sent: Friday, November 16, 2007 2:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible' with -X:PreferComDispatch

Hi,

I changed registry but I get same error.

IronPython-2.0A6>reg query HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32 /s

! REG.EXE VERSION 3.0

HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32
    Class       REG_SZ  Microsoft.Office.Interop.Excel.ApplicationClass
    RuntimeVersion      REG_SZ  v1.1.4322

HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0
    Class       REG_SZ  Microsoft.Office.Interop.Excel.ApplicationClass
    RuntimeVersion      REG_SZ  v1.1.4322

IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion -X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> from System import Type, Activator
>>> t = Type.GetTypeFromProgID('Excel.Application')
>>> e = Activator.CreateInstance(t)
>>> e.Visible = True
'__ComObject' object has no attribute 'Visible'
   ?? Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
   ?? Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
   ?? Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext callerContext, DynamicAction action, Object[] args, Object site, T& target, RuleSet`1& rules)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
   ?? Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 arg0, T1 arg1)
   ?? ##29(Object[] , CodeContext )
   ?? Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate)
   ?? Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   ?? Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
   ?? Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScriptModule module)
   ?? Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   ?? Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   ?? IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   ?? Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'

Thanks

> The behavior currently depends on whether or not the RCW gets strongly-typed when it enters the managed world. As a workaround, the following registry script Misha provided could "fix" your machine by registering the PIA:
>
> Windows Registry Editor Version 5.00
>
> [HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32]
> "Assembly"="Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
> "Class"="Microsoft.Office.Interop.Excel.ApplicationClass"
> "RuntimeVersion"="v1.1.4322"
>
> [HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0]
> "Assembly"="Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
> "Class"="Microsoft.Office.Interop.Excel.ApplicationClass"
> "RuntimeVersion"="v1.1.4322"
>
> Your script should work independent of whether the PIA is registered or not. We will look into it and see what is going.
>
> The implementation of -X:PreferComDispatch is still not complete. We are working on improving it and will enable it by default once all issues are flushed out. You are on the cutting edge and providing us with advance feedback :)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of nekomaho
> Sent: Thursday, November 15, 2007 4:45 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'
>
> Hi,
>
> I use Windows XP Pro SP2 ja & Office 2007 Pro ja.
>
> IronPython-2.0A6>ipy.exe -X:PreferComDispatch -X:TabCompletion -X:ExceptionDetail
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import clr
>>>> from System import Type, Activator
>>>> t = Type.GetTypeFromProgID('Excel.Application')
>>>> e = Activator.CreateInstance(t)
>>>> e.Visible = True
> '__ComObject' object has no attribute 'Visible'
>    ?? Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
>    ?? Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
>    ?? Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext callerContext, DynamicAction action, Object[] args, Object site, T& target, RuleSet`1& rules)
>    ?? Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext context, T0 arg0, T1 arg1)
>    ?? Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
>    ?? Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 arg0, T1 arg1)
>    ?? ##29(Object[] , CodeContext )
>    ?? Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate)
>    ?? Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>    ?? Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
>    ?? Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScriptModule module)
>    ?? Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>    ?? Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>    ?? IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>    ?? Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> AttributeError: '__ComObject' object has no attribute 'Visible'
>
> Thanks
>
>> This works for me as well.  Could you please re-run your code snippet under the -X:ExceptionDetail mode and send us the output?  Also, what versions of Windows and Office are being used?
>>
>> Thanks
>>
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammad Tayseer
>> Sent: Wednesday, November 14, 2007 8:02 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible'
>>
>> It works for me. What version of Excel do you use??
>>
>> Mohammad Tayseer
>> http://spellcoder.com/blogs/tayseer
>>
>> ----- Original Message ----
>> From: nekomaho <nekomaho at gmail.com>
>>
>>
>> Hi,
>>
>> I get AttributeError in IronPython 2.0A6 & A5, but 2.0A4 is ok. why?
>>
>>
>> ________________________________
>> Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.<http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.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 ronnie.maor at gmail.com  Fri Nov 16 21:48:46 2007
From: ronnie.maor at gmail.com (Ronnie Maor)
Date: Fri, 16 Nov 2007 22:48:46 +0200
Subject: [IronPython] IPy1.1 expected Nullable[int] got NoneType
Message-ID: <2fd6b9d0711161248q2815f49dx5e714c4d020844c7@mail.gmail.com>

with the following C# class:
public class A
{
    public A(int? i, string s1, string s2, string s3, string s4, string s5) { }
}

the following python code:
A(None, 'a', 'a', 'a', 'a', 'a')

fails with:
TypeError: expected Nullable[int], got NoneType

I don't know exactly when this happens. for example, reducing the
number of parameters to A (removing s5) makes the problem go away...

In IPy 2.0a5 this specific case works, so the problem might be fixed there.

the workaround I used for my code is to use some dummy non-None value
for the constructor, and then set the relevant property afterwards
with the right value, which may be None - no problems there. It's
ugly, but it works for my class.


From jdhardy at gmail.com  Sun Nov 18 00:04:52 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sat, 17 Nov 2007 16:04:52 -0700
Subject: [IronPython] Disabling optimized methods
Message-ID: <ea89d0e50711171504r1c66fce3w4fac22d4eb731d63@mail.gmail.com>

Hi,
Is there a way to disable method optimizations? I tried setting
ScriptDomainManager.Options.DebugCodeGeneration = true, but the
debugger still shows "Cannot evaluate expression because the code of
the current method is optimized." for a large number of methods. I set
the option before creating the engine, but maybe that's not enough?

-Jeff


From jdhardy at gmail.com  Sun Nov 18 21:30:53 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 18 Nov 2007 13:30:53 -0700
Subject: [IronPython] Expose a C# function as a Python function taking a
	default argument
Message-ID: <ea89d0e50711181230x7be3405fi4d29481c85cea27f@mail.gmail.com>

Hi all,
I have a function declared in C#:
void StartResponse(string status, List response_headers, Tuple exc_info);

I need to pass this to a Python function, and the Python function will
call it. Currently, the code looks like this:
object responsesObj = engine.CallObject(callable, module, environ, new
StartResponseDelegate(StartResponse));

This works fine if all three arguments are passed. However, from the
Python side start_response has this signature:
def start_response(status, response_headers, exc_info=None)

So my question is: How do I expose the C# function as a Python
function with a default argument? It looks like
Runtime.Calls.PythonFunction is what I want, but I couldn't figure out
how to call it - I tried tracing the code and ended up in the bowels
of the DLR.

Thanks,
Jeff


From dinov at exchange.microsoft.com  Mon Nov 19 18:31:12 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 19 Nov 2007 09:31:12 -0800
Subject: [IronPython] Disabling optimized methods
In-Reply-To: <ea89d0e50711171504r1c66fce3w4fac22d4eb731d63@mail.gmail.com>
References: <ea89d0e50711171504r1c66fce3w4fac22d4eb731d63@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4527833CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

This isn't actually optimization but rather dynamic methods.  You can use the -X:StaticMethods which will force all methods into types.  But the consequence of this is if methods are getting dynamically defined (e.g. exex "def foo(): pass") then we'll leak memory because the methods can never be freed.  But it will make the typical CLR-style debugging possible.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Saturday, November 17, 2007 3:05 PM
To: Discussion of IronPython
Subject: [IronPython] Disabling optimized methods

Hi,
Is there a way to disable method optimizations? I tried setting
ScriptDomainManager.Options.DebugCodeGeneration = true, but the
debugger still shows "Cannot evaluate expression because the code of
the current method is optimized." for a large number of methods. I set
the option before creating the engine, but maybe that's not enough?

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


From dinov at exchange.microsoft.com  Mon Nov 19 18:37:20 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 19 Nov 2007 09:37:20 -0800
Subject: [IronPython] Expose a C# function as a Python function taking
	a	default argument
In-Reply-To: <ea89d0e50711181230x7be3405fi4d29481c85cea27f@mail.gmail.com>
References: <ea89d0e50711181230x7be3405fi4d29481c85cea27f@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4527833D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

You can use either the [Optional] attribute or the [DefaultParameterValue(null)] attributes on the parameter in the C# signature to mark the parameter as being optional.  And if you're using a language that's more friendly to default/optional attributes (e.g. VB.NET) you could just use their native syntax which will generate one of those attributes.

The interesting difference between these is I believe if you're typed to object and do [Optional] you get Missing.Value instead of null so you can disambiguate between the two.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Sunday, November 18, 2007 12:31 PM
To: Discussion of IronPython
Subject: [IronPython] Expose a C# function as a Python function taking a default argument

Hi all,
I have a function declared in C#:
void StartResponse(string status, List response_headers, Tuple exc_info);

I need to pass this to a Python function, and the Python function will
call it. Currently, the code looks like this:
object responsesObj = engine.CallObject(callable, module, environ, new
StartResponseDelegate(StartResponse));

This works fine if all three arguments are passed. However, from the
Python side start_response has this signature:
def start_response(status, response_headers, exc_info=None)

So my question is: How do I expose the C# function as a Python
function with a default argument? It looks like
Runtime.Calls.PythonFunction is what I want, but I couldn't figure out
how to call it - I tried tracing the code and ended up in the bowels
of the DLR.

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


From dinov at exchange.microsoft.com  Tue Nov 20 01:15:31 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 19 Nov 2007 16:15:31 -0800
Subject: [IronPython] DLR Hosting Spec
Message-ID: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

As I mentioned a couple of weeks ago we've been wrapping up work on designing the hosting APIs and just this past week we've started implementing the new hosting APIs.  We'll be continuing this work off-and-on over the next few months so now is a great time to start collecting feedback on the design of the new APIs.

One thing worth mentioning is the spec is incomplete, and the text that is there is not final.  The conceptual introduction and the direction we're going is pretty solid.  However, as we review the API reference sections in detail, as implementation feeds back on the design, and as we gather external feedback, we're updating the spec and code.  The reason we're releasing this so early is to gather feedback on the design and functionality of the APIs.  Any feedback you have would be appreciated.

The new APIs will also start showing up incrementally in the next few releases of IronPython and the regular source drops of IronRuby.  So soon you'll also be test out and experiment with the bits directly.  This should give us plenty of time to take any feedback into consideration and update both the spec and code for the final DLR APIs.

We look forward to any feedback you might have!

You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf

If anyone would like a version in Word format we can send that so you can mark it up w/ track changes enabled :).



From Shri.Borde at microsoft.com  Tue Nov 20 04:39:43 2007
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Mon, 19 Nov 2007 19:39:43 -0800
Subject: [IronPython] Half the team OOF this week
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EC590264211@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Btw, half of our team is out this week for the Thanksgiving weekend. Dino is OOF starting Tuesday. So you may not get a prompt response this week.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Monday, November 19, 2007 4:16 PM
To: Discussion of IronPython
Subject: [IronPython] DLR Hosting Spec

As I mentioned a couple of weeks ago we've been wrapping up work on designing the hosting APIs and just this past week we've started implementing the new hosting APIs.  We'll be continuing this work off-and-on over the next few months so now is a great time to start collecting feedback on the design of the new APIs.

One thing worth mentioning is the spec is incomplete, and the text that is there is not final.  The conceptual introduction and the direction we're going is pretty solid.  However, as we review the API reference sections in detail, as implementation feeds back on the design, and as we gather external feedback, we're updating the spec and code.  The reason we're releasing this so early is to gather feedback on the design and functionality of the APIs.  Any feedback you have would be appreciated.

The new APIs will also start showing up incrementally in the next few releases of IronPython and the regular source drops of IronRuby.  So soon you'll also be test out and experiment with the bits directly.  This should give us plenty of time to take any feedback into consideration and update both the spec and code for the final DLR APIs.

We look forward to any feedback you might have!

You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf

If anyone would like a version in Word format we can send that so you can mark it up w/ track changes enabled :).

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


From sanxiyn at gmail.com  Tue Nov 20 07:10:39 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 20 Nov 2007 15:10:39 +0900
Subject: [IronPython] DLR Hosting Spec
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <5b0248170711192210u7e2724c6qe8c7553ac991cb67@mail.gmail.com>

2007/11/20, Dino Viehland <dinov at exchange.microsoft.com>:
> We look forward to any feedback you might have!
> You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf

I think there are a lot of things to learn from Java. Java 6
introduced javax.script hosting API.
http://java.sun.com/javase/6/docs/api/javax/script/package-summary.html

For example, ScriptRuntime corresponds to Java's ScriptEngineManager.
We can compare API to get scripting engine for the given language.

DLR
ScriptEngine GetEngine(string languageId)
ScriptEngine GetEngineByFileExtension(string extension)

javax.script
ScriptEngine getEngineByName(String shortName)
ScriptEngine getEngineByExtension(String extension)
ScriptEngine getEngineByMimeType(String mimeType)

Is getEngineByMimeType a good idea? Similar comparisons can be made
for all other APIs too.

-- 
Seo Sanghyeon


From jdhardy at gmail.com  Tue Nov 20 15:48:14 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 20 Nov 2007 07:48:14 -0700
Subject: [IronPython] Expose a C# function as a Python function taking a
	default argument
In-Reply-To: <7AD436E4270DD54A94238001769C2227E4527833D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <ea89d0e50711181230x7be3405fi4d29481c85cea27f@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E4527833D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <ea89d0e50711200648q5ea809cbw368e14153102d4a8@mail.gmail.com>

Thanks, it worked like a charm!

-Jeff

On Nov 19, 2007 10:37 AM, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> You can use either the [Optional] attribute or the [DefaultParameterValue(null)] attributes on the parameter in the C# signature to mark the parameter as being optional.  And if you're using a language that's more friendly to default/optional attributes (e.g. VB.NET) you could just use their native syntax which will generate one of those attributes.
>
> The interesting difference between these is I believe if you're typed to object and do [Optional] you get Missing.Value instead of null so you can disambiguate between the two.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Sunday, November 18, 2007 12:31 PM
> To: Discussion of IronPython
> Subject: [IronPython] Expose a C# function as a Python function taking a default argument
>
> Hi all,
> I have a function declared in C#:
> void StartResponse(string status, List response_headers, Tuple exc_info);
>
> I need to pass this to a Python function, and the Python function will
> call it. Currently, the code looks like this:
> object responsesObj = engine.CallObject(callable, module, environ, new
> StartResponseDelegate(StartResponse));
>
> This works fine if all three arguments are passed. However, from the
> Python side start_response has this signature:
> def start_response(status, response_headers, exc_info=None)
>
> So my question is: How do I expose the C# function as a Python
> function with a default argument? It looks like
> Runtime.Calls.PythonFunction is what I want, but I couldn't figure out
> how to call it - I tried tracing the code and ended up in the bowels
> of the DLR.
>
> Thanks,
> Jeff
> _______________________________________________
> 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 pdubroy at gmail.com  Wed Nov 21 21:18:30 2007
From: pdubroy at gmail.com (Patrick Dubroy)
Date: Wed, 21 Nov 2007 15:18:30 -0500
Subject: [IronPython] Problems with 8-bit strings
Message-ID: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>

Hi,

I've noticed that in the latest version of IronPython (2.0A6), I
noticed some weird behaviour with 8-bit strings:

    IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1378
    Copyright (c) Microsoft Corporation. All rights reserved.
    >>> str("\x7e")
    '~'
    >>> str("\x7f")
    u'\x7f'
    >>> str("\x80")
    u'\x80'
    >>> str("\x81")
    Traceback (most recent call last):
      File , line 0, in ##23
      File mscorlib, line unknown, in GetString
      File mscorlib, line unknown, in GetChars
      File mscorlib, line unknown, in Fallback
      File mscorlib, line unknown, in Throw
    UnicodeDecodeError: Unable to translate bytes [81] at index 0 from
specified code page to Unicode.

The first problem is that if the string contains characters 127 (0x7F)
or 128 (0x80), str() will return a Unicode string rather than an 8-bit
string. CPython, on the other hand, returns a standard 8-bit string
for both of those cases. Then, if the string contains any bytes
greater than 128, it throws an exception. CPython, on the other hand,
is happy to have bytes up to 0xFF in an 8-bit string.

Is this a known issue? Should I open a bug?

Pat


From jdhardy at gmail.com  Thu Nov 22 03:00:17 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 21 Nov 2007 19:00:17 -0700
Subject: [IronPython] TypeError: expected Tuple, got tuple
Message-ID: <ea89d0e50711211800i11a66d68pc4671da33eae2beb@mail.gmail.com>

Hi,
If I have the following C# library:
namespace TestLib
{
    public class Foo
    {
        public string Bar(Microsoft.Scripting.Tuple t)
        {
            return t.ToString();
        }
    }
}

Calling Bar from IronPython results in "TypeError: expected Tuple, got
tuple". Why are the Python tuple and Microsoft.Scripting.Tuple
different? And what is the proper type to use for Python tuples?

-Jeff

Python code:
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference("TestLib")
>>> import TestLib
>>> TestLib.Foo().Bar((1, 2, 3))
Traceback (most recent call last):
  File , line 0, in ##235
TypeError: expected Tuple, got tuple


With -X:ExceptionDetail:
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import clr
>>> clr.AddReference("TestLib")
>>> import TestLib
>>> TestLib.Foo().Bar((1, 2, 3))
expected Tuple, got tuple
   at IronPython.Runtime.Converter.Convert(Object value, Type to)
   at IronPython.Runtime.Converter.ConvertToReferenceType(Object fromObject, Run
timeTypeHandle typeHandle)
   at Microsoft.Scripting.Utils.InvokeHelper`3.Invoke(Object arg0, Object arg1)
   at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args)
   at Microsoft.Scripting.Ast.MethodCallExpression.InvokeMethod(Object instance,
 Object[] parameters)
   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
t)
   at Microsoft.Scripting.Ast.UnaryExpression.DoEvaluate(CodeContext context)
   at Microsoft.Scripting.Ast.ConditionalExpression.DoEvaluate(CodeContext conte
xt)
   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
t)
   at Microsoft.Scripting.Ast.ReturnStatement.DoExecute(CodeContext context)
   at Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
   at Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
xt callerContext, DynamicAction action, Object[] args, Object site, T& target, R
uleSet`1& rules)
   at Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeConte
xt context, T0 arg0, T1 arg1)
   at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
.Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
   at Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 a
rg0, T1 arg1)
   at ##235(Object[] , CodeContext )
   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEva
luate)
   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScri
ptModule module)
   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
TypeError: expected Tuple, got tuple


From jdhardy at gmail.com  Thu Nov 22 04:12:50 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 21 Nov 2007 20:12:50 -0700
Subject: [IronPython] TypeError: expected Tuple, got tuple
In-Reply-To: <ea89d0e50711211800i11a66d68pc4671da33eae2beb@mail.gmail.com>
References: <ea89d0e50711211800i11a66d68pc4671da33eae2beb@mail.gmail.com>
Message-ID: <ea89d0e50711211912m3bbfa73cm88098aa1b5212908@mail.gmail.com>

Hi,
Well, I found (or rather rediscovered :)) PythonTuple, but I'm still
curious as to whether they will be unified in the future.

-Jeff

On Nov 21, 2007 7:00 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> Hi,
> If I have the following C# library:
> nunified in the futureamespace TestLib
> {
>    public class Foo
>    {
>        public string Bar(Microsoft.Scripting.Tuple t)
>        {
>            return t.ToString();
>        }
>    }
> }
>
> Calling Bar from IronPython results in "TypeError: expected Tuple, got
> tuple". Why are the Python tuple and Microsoft.Scripting.Tuple
> different? And what is the proper type to use for Python tuples?
>
> -Jeff
>
> Python code:
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference("TestLib")
> >>> import TestLib
> >>> TestLib.Foo().Bar((1, 2, 3))
> Traceback (most recent call last):
>  File , line 0, in ##235
> TypeError: expected Tuple, got tuple
>
>
> With -X:ExceptionDetail:
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference("TestLib")
> >>> import TestLib
> >>> TestLib.Foo().Bar((1, 2, 3))
> expected Tuple, got tuple
>   at IronPython.Runtime.Converter.Convert(Object value, Type to)
>   at IronPython.Runtime.Converter.ConvertToReferenceType(Object fromObject, Run
> timeTypeHandle typeHandle)
>   at Microsoft.Scripting.Utils.InvokeHelper`3.Invoke(Object arg0, Object arg1)
>   at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args)
>   at Microsoft.Scripting.Ast.MethodCallExpression.InvokeMethod(Object instance,
>  Object[] parameters)
>   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> t)
>   at Microsoft.Scripting.Ast.UnaryExpression.DoEvaluate(CodeContext context)
>   at Microsoft.Scripting.Ast.ConditionalExpression.DoEvaluate(CodeContext conte
> xt)
>   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> t)
>   at Microsoft.Scripting.Ast.ReturnStatement.DoExecute(CodeContext context)
>   at Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
>   at Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
> xt callerContext, DynamicAction action, Object[] args, Object site, T& target, R
> uleSet`1& rules)
>   at Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeConte
> xt context, T0 arg0, T1 arg1)
>   at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
> .Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
>   at Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 a
> rg0, T1 arg1)
>   at ##235(Object[] , CodeContext )
>   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEva
> luate)
>   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
>   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScri
> ptModule module)
>   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> TypeError: expected Tuple, got tuple
>


From cummings.michael at gmail.com  Sat Nov 24 04:26:24 2007
From: cummings.michael at gmail.com (Michael Cummings)
Date: Fri, 23 Nov 2007 22:26:24 -0500
Subject: [IronPython] DLR Hosting Spec
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <d4e0938d0711231926j22e73190u5cd9b18b5217d4c4@mail.gmail.com>

I have a question more than feedback right now. How can I limit which
assemblies can be loaded into the hosted environment? I know I can set the
script path, but what if I don't want any scripts to load the
System.Remoting assembly?

Michael Cummings

On Nov 19, 2007 7:15 PM, Dino Viehland <dinov at exchange.microsoft.com> wrote:

> As I mentioned a couple of weeks ago we've been wrapping up work on
> designing the hosting APIs and just this past week we've started
> implementing the new hosting APIs.  We'll be continuing this work off-and-on
> over the next few months so now is a great time to start collecting feedback
> on the design of the new APIs.
>
> One thing worth mentioning is the spec is incomplete, and the text that is
> there is not final.  The conceptual introduction and the direction we're
> going is pretty solid.  However, as we review the API reference sections in
> detail, as implementation feeds back on the design, and as we gather
> external feedback, we're updating the spec and code.  The reason we're
> releasing this so early is to gather feedback on the design and
> functionality of the APIs.  Any feedback you have would be appreciated.
>
> The new APIs will also start showing up incrementally in the next few
> releases of IronPython and the regular source drops of IronRuby.  So soon
> you'll also be test out and experiment with the bits directly.  This should
> give us plenty of time to take any feedback into consideration and update
> both the spec and code for the final DLR APIs.
>
> We look forward to any feedback you might have!
>
> You can grab the spec here:
> http://www.iunknown.com/files/dlr-spec-hosting.pdf
>
> If anyone would like a version in Word format we can send that so you can
> mark it up w/ track changes enabled :).
>
> _______________________________________________
> 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/20071123/a861851e/attachment.html>

From dinov at exchange.microsoft.com  Sat Nov 24 21:52:35 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Sat, 24 Nov 2007 12:52:35 -0800
Subject: [IronPython] TypeError: expected Tuple, got tuple
In-Reply-To: <ea89d0e50711211912m3bbfa73cm88098aa1b5212908@mail.gmail.com>
References: <ea89d0e50711211800i11a66d68pc4671da33eae2beb@mail.gmail.com>,
	<ea89d0e50711211912m3bbfa73cm88098aa1b5212908@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45261D6CE@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

They're actually two rather distinct data types and there's no plans to merge them right now.  Tuple is used for creating strongly-typed fixed-sized collections and is used internally by the DLR.  We use it for creating our FunctionEnvironment's (for closures), for creating storage which back modules in collectible form, and in a couple of other places.  Basically it's a faster alternative to an array.  And of course PythonTuple is just Python's standard tuple type.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy [jdhardy at gmail.com]
Sent: Wednesday, November 21, 2007 7:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] TypeError: expected Tuple, got tuple

Hi,
Well, I found (or rather rediscovered :)) PythonTuple, but I'm still
curious as to whether they will be unified in the future.

-Jeff

On Nov 21, 2007 7:00 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> Hi,
> If I have the following C# library:
> nunified in the futureamespace TestLib
> {
>    public class Foo
>    {
>        public string Bar(Microsoft.Scripting.Tuple t)
>        {
>            return t.ToString();
>        }
>    }
> }
>
> Calling Bar from IronPython results in "TypeError: expected Tuple, got
> tuple". Why are the Python tuple and Microsoft.Scripting.Tuple
> different? And what is the proper type to use for Python tuples?
>
> -Jeff
>
> Python code:
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference("TestLib")
> >>> import TestLib
> >>> TestLib.Foo().Bar((1, 2, 3))
> Traceback (most recent call last):
>  File , line 0, in ##235
> TypeError: expected Tuple, got tuple
>
>
> With -X:ExceptionDetail:
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference("TestLib")
> >>> import TestLib
> >>> TestLib.Foo().Bar((1, 2, 3))
> expected Tuple, got tuple
>   at IronPython.Runtime.Converter.Convert(Object value, Type to)
>   at IronPython.Runtime.Converter.ConvertToReferenceType(Object fromObject, Run
> timeTypeHandle typeHandle)
>   at Microsoft.Scripting.Utils.InvokeHelper`3.Invoke(Object arg0, Object arg1)
>   at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args)
>   at Microsoft.Scripting.Ast.MethodCallExpression.InvokeMethod(Object instance,
>  Object[] parameters)
>   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> t)
>   at Microsoft.Scripting.Ast.UnaryExpression.DoEvaluate(CodeContext context)
>   at Microsoft.Scripting.Ast.ConditionalExpression.DoEvaluate(CodeContext conte
> xt)
>   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> t)
>   at Microsoft.Scripting.Ast.ReturnStatement.DoExecute(CodeContext context)
>   at Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
>   at Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
> xt callerContext, DynamicAction action, Object[] args, Object site, T& target, R
> uleSet`1& rules)
>   at Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeConte
> xt context, T0 arg0, T1 arg1)
>   at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
> .Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
>   at Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 a
> rg0, T1 arg1)
>   at ##235(Object[] , CodeContext )
>   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEva
> luate)
>   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
>   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScri
> ptModule module)
>   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> TypeError: expected Tuple, got tuple
>
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Sat Nov 24 21:54:30 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Sat, 24 Nov 2007 12:54:30 -0800
Subject: [IronPython] Problems with 8-bit strings
In-Reply-To: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>
References: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E45261D6CF@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I think the construction w/ characters > 0x80 is a bug.  But the returning of unicode vs. 8-bit strings is just a display issue.  IronPython only has unicode strings and is one of the big differences between CPython and IronPython.  If you haven't already I'll open a bug when I'm back after Thanksgiving.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Patrick Dubroy [pdubroy at gmail.com]
Sent: Wednesday, November 21, 2007 12:18 PM
To: users at lists.ironpython.com
Subject: [IronPython] Problems with 8-bit strings

Hi,

I've noticed that in the latest version of IronPython (2.0A6), I
noticed some weird behaviour with 8-bit strings:

    IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1378
    Copyright (c) Microsoft Corporation. All rights reserved.
    >>> str("\x7e")
    '~'
    >>> str("\x7f")
    u'\x7f'
    >>> str("\x80")
    u'\x80'
    >>> str("\x81")
    Traceback (most recent call last):
      File , line 0, in ##23
      File mscorlib, line unknown, in GetString
      File mscorlib, line unknown, in GetChars
      File mscorlib, line unknown, in Fallback
      File mscorlib, line unknown, in Throw
    UnicodeDecodeError: Unable to translate bytes [81] at index 0 from
specified code page to Unicode.

The first problem is that if the string contains characters 127 (0x7F)
or 128 (0x80), str() will return a Unicode string rather than an 8-bit
string. CPython, on the other hand, returns a standard 8-bit string
for both of those cases. Then, if the string contains any bytes
greater than 128, it throws an exception. CPython, on the other hand,
is happy to have bytes up to 0xFF in an 8-bit string.

Is this a known issue? Should I open a bug?

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


From jdhardy at gmail.com  Sun Nov 25 10:01:51 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 25 Nov 2007 02:01:51 -0700
Subject: [IronPython] TypeError: expected Tuple, got tuple
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45261D6CE@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <ea89d0e50711211800i11a66d68pc4671da33eae2beb@mail.gmail.com>
	<ea89d0e50711211912m3bbfa73cm88098aa1b5212908@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45261D6CE@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <ea89d0e50711250101v41a793f5u6136736d11db7bd3@mail.gmail.com>

Hi Dino,
Thanks for the explanation. You guys may want to consider renaming
some things, though, because there's a List instead of PythonList, and
that's what threw me off. I expected Tuple to work as well. I suspect
it will be less of an issue once the new API is in and there are some
docs for all of this. The joys of working with alpha software :).

-Jeff

On Nov 24, 2007 1:52 PM, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> They're actually two rather distinct data types and there's no plans to merge them right now.  Tuple is used for creating strongly-typed fixed-sized collections and is used internally by the DLR.  We use it for creating our FunctionEnvironment's (for closures), for creating storage which back modules in collectible form, and in a couple of other places.  Basically it's a faster alternative to an array.  And of course PythonTuple is just Python's standard tuple type.
>
> ________________________________________
> From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy [jdhardy at gmail.com]
> Sent: Wednesday, November 21, 2007 7:12 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] TypeError: expected Tuple, got tuple
>
>
> Hi,
> Well, I found (or rather rediscovered :)) PythonTuple, but I'm still
> curious as to whether they will be unified in the future.
>
> -Jeff
>
> On Nov 21, 2007 7:00 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> > Hi,
> > If I have the following C# library:
> > nunified in the futureamespace TestLib
> > {
> >    public class Foo
> >    {
> >        public string Bar(Microsoft.Scripting.Tuple t)
> >        {
> >            return t.ToString();
> >        }
> >    }
> > }
> >
> > Calling Bar from IronPython results in "TypeError: expected Tuple, got
> > tuple". Why are the Python tuple and Microsoft.Scripting.Tuple
> > different? And what is the proper type to use for Python tuples?
> >
> > -Jeff
> >
> > Python code:
> > IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> > Copyright (c) Microsoft Corporation. All rights reserved.
> > >>> import clr
> > >>> clr.AddReference("TestLib")
> > >>> import TestLib
> > >>> TestLib.Foo().Bar((1, 2, 3))
> > Traceback (most recent call last):
> >  File , line 0, in ##235
> > TypeError: expected Tuple, got tuple
> >
> >
> > With -X:ExceptionDetail:
> > IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> > Copyright (c) Microsoft Corporation. All rights reserved.
> > >>> import clr
> > >>> clr.AddReference("TestLib")
> > >>> import TestLib
> > >>> TestLib.Foo().Bar((1, 2, 3))
> > expected Tuple, got tuple
> >   at IronPython.Runtime.Converter.Convert(Object value, Type to)
> >   at IronPython.Runtime.Converter.ConvertToReferenceType(Object fromObject, Run
> > timeTypeHandle typeHandle)
> >   at Microsoft.Scripting.Utils.InvokeHelper`3.Invoke(Object arg0, Object arg1)
> >   at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args)
> >   at Microsoft.Scripting.Ast.MethodCallExpression.InvokeMethod(Object instance,
> >  Object[] parameters)
> >   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> > t)
> >   at Microsoft.Scripting.Ast.UnaryExpression.DoEvaluate(CodeContext context)
> >   at Microsoft.Scripting.Ast.ConditionalExpression.DoEvaluate(CodeContext conte
> > xt)
> >   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> > t)
> >   at Microsoft.Scripting.Ast.ReturnStatement.DoExecute(CodeContext context)
> >   at Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
> >   at Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
> > xt callerContext, DynamicAction action, Object[] args, Object site, T& target, R
> > uleSet`1& rules)
> >   at Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeConte
> > xt context, T0 arg0, T1 arg1)
> >   at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
> > .Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
> >   at Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 a
> > rg0, T1 arg1)
> >   at ##235(Object[] , CodeContext )
> >   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEva
> > luate)
> >   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
> >   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
> >   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScri
> > ptModule module)
> >   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
> >   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
> >   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
> >   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> > TypeError: expected Tuple, got tuple
> >
> _______________________________________________
> 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 Mahesh.Prakriya at microsoft.com  Mon Nov 26 02:41:36 2007
From: Mahesh.Prakriya at microsoft.com (Mahesh Prakriya)
Date: Sun, 25 Nov 2007 17:41:36 -0800
Subject: [IronPython] Users Digest, Vol 40, Issue 28
In-Reply-To: <mailman.1.1195941238.10581.users-ironpython.com@lists.ironpython.com>
References: <mailman.1.1195941238.10581.users-ironpython.com@lists.ironpython.com>
Message-ID: <8DD6D7B47848B24F972C23F274C6E5682381815A6A@NA-EXMSG-C112.redmond.corp.microsoft.com>

The only way to limit the assemblies loaded is by hosting CLR2.0 (or later) directly - e.g. SQL does this today.

A good book to read to get at the details of this is "Customizing the Microsoft .NET Framework Common Language Runtime" by Steven Pratschner.
http://www.amazon.com/Customizing-Microsoft-Framework-Language-Runtime/dp/0735619883/ref=sr_1_1?ie=UTF8&s=books&qid=1196041016&sr=1-1

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of users-request at lists.ironpython.com
Sent: Saturday, November 24, 2007 1:54 PM
To: users at lists.ironpython.com
Subject: Users Digest, Vol 40, Issue 28

Send Users mailing list submissions to
        users at lists.ironpython.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
or, via email, send a message with subject or body 'help' to
        users-request at lists.ironpython.com

You can reach the person managing the list at
        users-owner at lists.ironpython.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."


Today's Topics:

   1. Re: DLR Hosting Spec (Michael Cummings)
   2. Re: TypeError: expected Tuple, got tuple (Dino Viehland)
   3. Re: Problems with 8-bit strings (Dino Viehland)


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

Message: 1
Date: Fri, 23 Nov 2007 22:26:24 -0500
From: "Michael Cummings" <cummings.michael at gmail.com>
Subject: Re: [IronPython] DLR Hosting Spec
To: "Discussion of IronPython" <users at lists.ironpython.com>
Message-ID:
        <d4e0938d0711231926j22e73190u5cd9b18b5217d4c4 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I have a question more than feedback right now. How can I limit which
assemblies can be loaded into the hosted environment? I know I can set the
script path, but what if I don't want any scripts to load the
System.Remoting assembly?

Michael Cummings

On Nov 19, 2007 7:15 PM, Dino Viehland <dinov at exchange.microsoft.com> wrote:

> As I mentioned a couple of weeks ago we've been wrapping up work on
> designing the hosting APIs and just this past week we've started
> implementing the new hosting APIs.  We'll be continuing this work off-and-on
> over the next few months so now is a great time to start collecting feedback
> on the design of the new APIs.
>
> One thing worth mentioning is the spec is incomplete, and the text that is
> there is not final.  The conceptual introduction and the direction we're
> going is pretty solid.  However, as we review the API reference sections in
> detail, as implementation feeds back on the design, and as we gather
> external feedback, we're updating the spec and code.  The reason we're
> releasing this so early is to gather feedback on the design and
> functionality of the APIs.  Any feedback you have would be appreciated.
>
> The new APIs will also start showing up incrementally in the next few
> releases of IronPython and the regular source drops of IronRuby.  So soon
> you'll also be test out and experiment with the bits directly.  This should
> give us plenty of time to take any feedback into consideration and update
> both the spec and code for the final DLR APIs.
>
> We look forward to any feedback you might have!
>
> You can grab the spec here:
> http://www.iunknown.com/files/dlr-spec-hosting.pdf
>
> If anyone would like a version in Word format we can send that so you can
> mark it up w/ track changes enabled :).
>
> _______________________________________________
> 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://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20071123/a861851e/attachment-0001.html

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

Message: 2
Date: Sat, 24 Nov 2007 12:52:35 -0800
From: Dino Viehland <dinov at exchange.microsoft.com>
Subject: Re: [IronPython] TypeError: expected Tuple, got tuple
To: Discussion of IronPython <users at lists.ironpython.com>
Message-ID:
        <7AD436E4270DD54A94238001769C2227E45261D6CE at DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Content-Type: text/plain; charset="us-ascii"

They're actually two rather distinct data types and there's no plans to merge them right now.  Tuple is used for creating strongly-typed fixed-sized collections and is used internally by the DLR.  We use it for creating our FunctionEnvironment's (for closures), for creating storage which back modules in collectible form, and in a couple of other places.  Basically it's a faster alternative to an array.  And of course PythonTuple is just Python's standard tuple type.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy [jdhardy at gmail.com]
Sent: Wednesday, November 21, 2007 7:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] TypeError: expected Tuple, got tuple

Hi,
Well, I found (or rather rediscovered :)) PythonTuple, but I'm still
curious as to whether they will be unified in the future.

-Jeff

On Nov 21, 2007 7:00 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> Hi,
> If I have the following C# library:
> nunified in the futureamespace TestLib
> {
>    public class Foo
>    {
>        public string Bar(Microsoft.Scripting.Tuple t)
>        {
>            return t.ToString();
>        }
>    }
> }
>
> Calling Bar from IronPython results in "TypeError: expected Tuple, got
> tuple". Why are the Python tuple and Microsoft.Scripting.Tuple
> different? And what is the proper type to use for Python tuples?
>
> -Jeff
>
> Python code:
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference("TestLib")
> >>> import TestLib
> >>> TestLib.Foo().Bar((1, 2, 3))
> Traceback (most recent call last):
>  File , line 0, in ##235
> TypeError: expected Tuple, got tuple
>
>
> With -X:ExceptionDetail:
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import clr
> >>> clr.AddReference("TestLib")
> >>> import TestLib
> >>> TestLib.Foo().Bar((1, 2, 3))
> expected Tuple, got tuple
>   at IronPython.Runtime.Converter.Convert(Object value, Type to)
>   at IronPython.Runtime.Converter.ConvertToReferenceType(Object fromObject, Run
> timeTypeHandle typeHandle)
>   at Microsoft.Scripting.Utils.InvokeHelper`3.Invoke(Object arg0, Object arg1)
>   at Microsoft.Scripting.Utils.ReflectedCaller.Invoke(Object[] args)
>   at Microsoft.Scripting.Ast.MethodCallExpression.InvokeMethod(Object instance,
>  Object[] parameters)
>   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> t)
>   at Microsoft.Scripting.Ast.UnaryExpression.DoEvaluate(CodeContext context)
>   at Microsoft.Scripting.Ast.ConditionalExpression.DoEvaluate(CodeContext conte
> xt)
>   at Microsoft.Scripting.Ast.MethodCallExpression.DoEvaluate(CodeContext contex
> t)
>   at Microsoft.Scripting.Ast.ReturnStatement.DoExecute(CodeContext context)
>   at Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
>   at Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
> xt callerContext, DynamicAction action, Object[] args, Object site, T& target, R
> uleSet`1& rules)
>   at Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeConte
> xt context, T0 arg0, T1 arg1)
>   at Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
> .Invoke2(DynamicSite`3 site, CodeContext context, T0 arg0, T1 arg1)
>   at Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0 a
> rg0, T1 arg1)
>   at ##235(Object[] , CodeContext )
>   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEva
> luate)
>   at Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
>   at Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
>   at Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code, IScri
> ptModule module)
>   at Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
>   at Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
>   at IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
>   at Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
> TypeError: expected Tuple, got tuple
>
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


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

Message: 3
Date: Sat, 24 Nov 2007 12:54:30 -0800
From: Dino Viehland <dinov at exchange.microsoft.com>
Subject: Re: [IronPython] Problems with 8-bit strings
To: Discussion of IronPython <users at lists.ironpython.com>
Message-ID:
        <7AD436E4270DD54A94238001769C2227E45261D6CF at DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Content-Type: text/plain; charset="us-ascii"

I think the construction w/ characters > 0x80 is a bug.  But the returning of unicode vs. 8-bit strings is just a display issue.  IronPython only has unicode strings and is one of the big differences between CPython and IronPython.  If you haven't already I'll open a bug when I'm back after Thanksgiving.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Patrick Dubroy [pdubroy at gmail.com]
Sent: Wednesday, November 21, 2007 12:18 PM
To: users at lists.ironpython.com
Subject: [IronPython] Problems with 8-bit strings

Hi,

I've noticed that in the latest version of IronPython (2.0A6), I
noticed some weird behaviour with 8-bit strings:

    IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1378
    Copyright (c) Microsoft Corporation. All rights reserved.
    >>> str("\x7e")
    '~'
    >>> str("\x7f")
    u'\x7f'
    >>> str("\x80")
    u'\x80'
    >>> str("\x81")
    Traceback (most recent call last):
      File , line 0, in ##23
      File mscorlib, line unknown, in GetString
      File mscorlib, line unknown, in GetChars
      File mscorlib, line unknown, in Fallback
      File mscorlib, line unknown, in Throw
    UnicodeDecodeError: Unable to translate bytes [81] at index 0 from
specified code page to Unicode.

The first problem is that if the string contains characters 127 (0x7F)
or 128 (0x80), str() will return a Unicode string rather than an 8-bit
string. CPython, on the other hand, returns a standard 8-bit string
for both of those cases. Then, if the string contains any bytes
greater than 128, it throws an exception. CPython, on the other hand,
is happy to have bytes up to 0xFF in an 8-bit string.

Is this a known issue? Should I open a bug?

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


End of Users Digest, Vol 40, Issue 28
*************************************


From jigisbert.etra-id at grupoetra.com  Mon Nov 26 10:10:39 2007
From: jigisbert.etra-id at grupoetra.com (Jose Ignacio Gisbert)
Date: Mon, 26 Nov 2007 10:10:39 +0100
Subject: [IronPython] Doubt with C# and PythonEngine
Message-ID: <002c01c8300c$389c0930$2000a8c0@depid.local>

 Hi all,

 

I am developing an application for Pocket PC which Graphic interface is in
C#, but I want to call methods in some situations (when press certain button
for example) that are coded in Python and which use xmlrpclib library. I
have read some lines about embedding Python in C# creating a PythonEngine
and a bit more, but any clear example or tutorial of how to do it. If you
could tell me any page or tutorial I would be very pleased. Sorry for my
ignorance.

 

Thanks in advance 

_______________________________
Jos? Ignacio Gisbert Sanus

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

From fuzzyman at voidspace.org.uk  Mon Nov 26 10:48:07 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 26 Nov 2007 09:48:07 +0000
Subject: [IronPython] Doubt with C# and PythonEngine
In-Reply-To: <002c01c8300c$389c0930$2000a8c0@depid.local>
References: <002c01c8300c$389c0930$2000a8c0@depid.local>
Message-ID: <474A9657.9060501@voidspace.org.uk>

Hello Jose,

PocketPC uses the Compact framework which doesn't include the Reflect 
Emit 'stuff' necessary to run IronPython. So it just plain won't work - 
sorry. :-(

There are some examples over on the IronPython cookbook if you are still 
interested however - http://www.ironpython.info

Michael Foord
http://www.manning.com/foord

Jose Ignacio Gisbert wrote:
>
>  Hi all,
>
>  
>
> I am developing an application for Pocket PC which Graphic interface 
> is in C#, but I want to call methods in some situations (when press 
> certain button for example) that are coded in Python and which use 
> xmlrpclib library. I have read some lines about embedding Python in C# 
> creating a PythonEngine and a bit more, but any clear example or 
> tutorial of how to do it. If you could tell me any page or tutorial I 
> would be very pleased. Sorry for my ignorance.
>
>  
>
> Thanks in advance 
>
> _______________________________
> *Jos? Ignacio Gisbert Sanus*
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   



From rpehlm at btinternet.com  Mon Nov 26 11:38:07 2007
From: rpehlm at btinternet.com (Robin Lauryssen-Mitchell)
Date: Mon, 26 Nov 2007 11:38:07 +0100
Subject: [IronPython] Doubt with C# and PythonEngine
In-Reply-To: <474A9657.9060501@voidspace.org.uk>
Message-ID: <000501c83018$6fb217f0$2101a8c0@Kudu>

Does anyone have a sample of hosting IronPython in VisualBasic ([2005|2008]
[Express|Standard])?

Thanks
Robin

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: 26 November 2007 10:48
> To: Discussion of IronPython
> Subject: Re: [IronPython] Doubt with C# and PythonEngine
> 
> Hello Jose,
> 
> PocketPC uses the Compact framework which doesn't include the Reflect
> Emit 'stuff' necessary to run IronPython. So it just plain won't work -
> sorry. :-(
> 
> There are some examples over on the IronPython cookbook if you are still
> interested however - http://www.ironpython.info
> 
> Michael Foord
> http://www.manning.com/foord
> 
> Jose Ignacio Gisbert wrote:
> >
> >  Hi all,
> >
> >
> >
> > I am developing an application for Pocket PC which Graphic interface
> > is in C#, but I want to call methods in some situations (when press
> > certain button for example) that are coded in Python and which use
> > xmlrpclib library. I have read some lines about embedding Python in C#
> > creating a PythonEngine and a bit more, but any clear example or
> > tutorial of how to do it. If you could tell me any page or tutorial I
> > would be very pleased. Sorry for my ignorance.
> >
> >
> >
> > Thanks in advance
> >
> > _______________________________
> > *Jos? Ignacio Gisbert Sanus*
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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  Mon Nov 26 14:17:13 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 26 Nov 2007 13:17:13 +0000
Subject: [IronPython] Doubt with C# and PythonEngine
In-Reply-To: <000501c83018$6fb217f0$2101a8c0@Kudu>
References: <000501c83018$6fb217f0$2101a8c0@Kudu>
Message-ID: <474AC759.9000700@voidspace.org.uk>

Hello Robin,

There are various examples here:

http://www.ironpython.info/index.php/Contents#Embedding

Michael
http://www.manning.com/foord


Robin Lauryssen-Mitchell wrote:
> Does anyone have a sample of hosting IronPython in VisualBasic ([2005|2008]
> [Express|Standard])?
>
> Thanks
> Robin
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: 26 November 2007 10:48
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Doubt with C# and PythonEngine
>>
>> Hello Jose,
>>
>> PocketPC uses the Compact framework which doesn't include the Reflect
>> Emit 'stuff' necessary to run IronPython. So it just plain won't work -
>> sorry. :-(
>>
>> There are some examples over on the IronPython cookbook if you are still
>> interested however - http://www.ironpython.info
>>
>> Michael Foord
>> http://www.manning.com/foord
>>
>> Jose Ignacio Gisbert wrote:
>>     
>>>  Hi all,
>>>
>>>
>>>
>>> I am developing an application for Pocket PC which Graphic interface
>>> is in C#, but I want to call methods in some situations (when press
>>> certain button for example) that are coded in Python and which use
>>> xmlrpclib library. I have read some lines about embedding Python in C#
>>> creating a PythonEngine and a bit more, but any clear example or
>>> tutorial of how to do it. If you could tell me any page or tutorial I
>>> would be very pleased. Sorry for my ignorance.
>>>
>>>
>>>
>>> Thanks in advance
>>>
>>> _______________________________
>>> *Jos? Ignacio Gisbert Sanus*
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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 Sathish.Kaveripakam at phonak.com  Mon Nov 26 17:00:40 2007
From: Sathish.Kaveripakam at phonak.com (Kaveripakam, Sathish)
Date: Mon, 26 Nov 2007 17:00:40 +0100
Subject: [IronPython] C# and IronPython Interface.
Message-ID: <FBB055C769471C42BBAE2E206073B8ED07BE71BC@CH01SWC2.corp.ads>

HI All,
 
I have c#  code which should call a Iron Python function. I am using
Iron python 1.1 version and Visual Studio 2005. The details of my files
are as follows:
 
 
 C# code (Entry.cs):
 
using System;

using System.Collections;

using IronPython.Hosting;

public class Entry

{

            public static void Main(string[] args)

            {

                        int a= 2, b= 4;

                        // OVER HERE I WOULD LIKE TO CALL IRONPYTHON
Function: ArithmeticOperations which takes arguments a,b

                }

}

PYTHON SCRIPT(ArithmeticOperations.py):

def ArithmeticOperations( a,b):

print "I am in ArithmeticOperation functions..."

return  a+b

 

In my project setup, I gave reference to include : IronPython, IronMath
dll's

In this regard, please do let me know, how to call the python script
"Arithmetic Operations" from my Entry.cs file ? Also, please do let me
know, if I have to include any of the libraries ?

Regards,

Sathish

 

 

 


******************** 
Legal Notice: 
The information in this electronic transmission may contain confidential or
legally privileged information and is intended solely for the individual(s)
named above. If you are not an intended recipient or an authorized agent,
you are hereby notified that reading, distributing, or otherwise
disseminating, copying or taking any action based on the contents of this
transmission is strictly prohibited. Any unauthorized interception of this
transmission is illegal under law. If you have received this transmission in
error, please notify the sender by telephone [at the number indicated above/
on +41 58 928 0101] as soon as possible and then destroy all copies of this
transmission. 
********************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071126/c7e8c95f/attachment.html>

From rpehlm at btinternet.com  Mon Nov 26 16:07:30 2007
From: rpehlm at btinternet.com (Robin Lauryssen-Mitchell)
Date: Mon, 26 Nov 2007 16:07:30 +0100
Subject: [IronPython] Doubt with C# and PythonEngine
In-Reply-To: <474AC759.9000700@voidspace.org.uk>
Message-ID: <000701c8303e$114f1480$2101a8c0@Kudu>

Thanks, but as far as I can see all the embedding examples are in C#.  I'll
continue trying to rework them into VB but my knowledge of C# is pretty
pathetic.

Regards
Robin

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: 26 November 2007 14:17
> To: Discussion of IronPython
> Subject: Re: [IronPython] Doubt with C# and PythonEngine
> 
> Hello Robin,
> 
> There are various examples here:
> 
> http://www.ironpython.info/index.php/Contents#Embedding
> 
> Michael
> http://www.manning.com/foord
> 
> 
> Robin Lauryssen-Mitchell wrote:
> > Does anyone have a sample of hosting IronPython in VisualBasic
> ([2005|2008]
> > [Express|Standard])?
> >
> > Thanks
> > Robin
> >
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> >> Sent: 26 November 2007 10:48
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] Doubt with C# and PythonEngine
> >>
> >> Hello Jose,
> >>
> >> PocketPC uses the Compact framework which doesn't include the Reflect
> >> Emit 'stuff' necessary to run IronPython. So it just plain won't work -
> >> sorry. :-(
> >>
> >> There are some examples over on the IronPython cookbook if you are
> still
> >> interested however - http://www.ironpython.info
> >>
> >> Michael Foord
> >> http://www.manning.com/foord
> >>
> >> Jose Ignacio Gisbert wrote:
> >>
> >>>  Hi all,
> >>>
> >>>
> >>>
> >>> I am developing an application for Pocket PC which Graphic interface
> >>> is in C#, but I want to call methods in some situations (when press
> >>> certain button for example) that are coded in Python and which use
> >>> xmlrpclib library. I have read some lines about embedding Python in C#
> >>> creating a PythonEngine and a bit more, but any clear example or
> >>> tutorial of how to do it. If you could tell me any page or tutorial I
> >>> would be very pleased. Sorry for my ignorance.
> >>>
> >>>
> >>>
> >>> Thanks in advance
> >>>
> >>> _______________________________
> >>> *Jos? Ignacio Gisbert Sanus*
> >>>
> >>> ----------------------------------------------------------------------
> --
> >>>
> >>> _______________________________________________
> >>> 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 eyvind.axelsen at profdoc.no  Tue Nov 27 08:58:14 2007
From: eyvind.axelsen at profdoc.no (Eyvind Axelsen)
Date: Tue, 27 Nov 2007 08:58:14 +0100
Subject: [IronPython] Doubt with C# and PythonEngine
In-Reply-To: <000701c8303e$114f1480$2101a8c0@Kudu>
References: <474AC759.9000700@voidspace.org.uk>
	<000701c8303e$114f1480$2101a8c0@Kudu>
Message-ID: <E888680DB6B4764FAB5338F36FCF4BF5F5D1EE@exchangesrv.profdoc.no>

Try this: http://labs.developerfusion.co.uk/convert/csharp-to-vb.aspx

Eyvind.

-----Opprinnelig melding-----
Fra: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] P? vegne av Robin Lauryssen-Mitchell
Sendt: 26. november 2007 16:08
Til: 'Discussion of IronPython'
Emne: Re: [IronPython] Doubt with C# and PythonEngine

Thanks, but as far as I can see all the embedding examples are in C#.  I'll
continue trying to rework them into VB but my knowledge of C# is pretty
pathetic.

Regards
Robin

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: 26 November 2007 14:17
> To: Discussion of IronPython
> Subject: Re: [IronPython] Doubt with C# and PythonEngine
> 
> Hello Robin,
> 
> There are various examples here:
> 
> http://www.ironpython.info/index.php/Contents#Embedding
> 
> Michael
> http://www.manning.com/foord
> 
> 
> Robin Lauryssen-Mitchell wrote:
> > Does anyone have a sample of hosting IronPython in VisualBasic
> ([2005|2008]
> > [Express|Standard])?
> >
> > Thanks
> > Robin
> >
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> >> Sent: 26 November 2007 10:48
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] Doubt with C# and PythonEngine
> >>
> >> Hello Jose,
> >>
> >> PocketPC uses the Compact framework which doesn't include the Reflect
> >> Emit 'stuff' necessary to run IronPython. So it just plain won't work -
> >> sorry. :-(
> >>
> >> There are some examples over on the IronPython cookbook if you are
> still
> >> interested however - http://www.ironpython.info
> >>
> >> Michael Foord
> >> http://www.manning.com/foord
> >>
> >> Jose Ignacio Gisbert wrote:
> >>
> >>>  Hi all,
> >>>
> >>>
> >>>
> >>> I am developing an application for Pocket PC which Graphic interface
> >>> is in C#, but I want to call methods in some situations (when press
> >>> certain button for example) that are coded in Python and which use
> >>> xmlrpclib library. I have read some lines about embedding Python in C#
> >>> creating a PythonEngine and a bit more, but any clear example or
> >>> tutorial of how to do it. If you could tell me any page or tutorial I
> >>> would be very pleased. Sorry for my ignorance.
> >>>
> >>>
> >>>
> >>> Thanks in advance
> >>>
> >>> _______________________________
> >>> *Jos? Ignacio Gisbert Sanus*
> >>>
> >>> ----------------------------------------------------------------------
> --
> >>>
> >>> _______________________________________________
> >>> 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 exchange.microsoft.com  Tue Nov 27 18:31:51 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 27 Nov 2007 09:31:51 -0800
Subject: [IronPython] C# and IronPython Interface.
In-Reply-To: <FBB055C769471C42BBAE2E206073B8ED07BE71BC@CH01SWC2.corp.ads>
References: <FBB055C769471C42BBAE2E206073B8ED07BE71BC@CH01SWC2.corp.ads>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A4559@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

You're going to want to do something like (only compiled w/ Outlook, so there may be some small compile errors here):

PythonEngine pe = new PythonEngine();
EngineModule mod = pe.CreateModule();
pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod);
object func = mod.Globals["ArithmeticOperations"];

That gets you the function...  From there you can call it one of several ways:

Object res = Ops.Call(func, a, b);

        Or

delegate object MyDelegate(object a, object b);

MyDelegate dlg = Converter.Convert<MyDelegate>(func);
Object res = dlg(a, b);

In v1.x you can also use the CreateLambda/CreateMethod APIs if you have the body of the code.  In general we prefer the 2nd form more where you convert it to a delegate because it fits in better with .NET.  You can also do things like have the delegate take strongly typed parameters and there's the possibility that could turn into more optimized code in v2.0 at some point in the future.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam, Sathish
Sent: Monday, November 26, 2007 8:01 AM
To: users at lists.ironpython.com
Subject: [IronPython] C# and IronPython Interface.

HI All,

I have c#  code which should call a Iron Python function. I am using Iron python 1.1 version and Visual Studio 2005. The details of my files are as follows:


 C# code (Entry.cs):

using System;
using System.Collections;
using IronPython.Hosting;
public class Entry
{
            public static void Main(string[] args)
            {
                        int a= 2, b= 4;
                        // OVER HERE I WOULD LIKE TO CALL IRONPYTHON Function: ArithmeticOperations which takes arguments a,b
                }
}
PYTHON SCRIPT(ArithmeticOperations.py):
def ArithmeticOperations( a,b):
print "I am in ArithmeticOperation functions..."
return  a+b

In my project setup, I gave reference to include : IronPython, IronMath dll's
In this regard, please do let me know, how to call the python script "Arithmetic Operations" from my Entry.cs file ? Also, please do let me know, if I have to include any of the libraries ?
Regards,
Sathish



________________________________________
Legal Notice:
The information in this electronic transmission may contain confidential or legally privileged information and is intended solely for the individual(s) named above. If you are not an intended recipient or an authorized agent, you are hereby notified that reading, distributing, or otherwise disseminating, copying or taking any action based on the contents of this transmission is strictly prohibited. Any unauthorized interception of this transmission is illegal under law. If you have received this transmission in error, please notify the sender by telephone [at the number indicated above/on +41 58 928 0101] as soon as possible and then destroy all copies of this transmission.
________________________________________


From pdubroy at gmail.com  Tue Nov 27 20:29:04 2007
From: pdubroy at gmail.com (Patrick Dubroy)
Date: Tue, 27 Nov 2007 14:29:04 -0500
Subject: [IronPython] Problems with 8-bit strings
In-Reply-To: <7AD436E4270DD54A94238001769C2227E45261D6CF@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45261D6CF@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <95294eec0711271129i4f7e82d8s297a353be45c6b19@mail.gmail.com>

I didn't see a bug open, so I opened one:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14104

Thanks,

Pat

On Nov 24, 2007 3:54 PM, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> I think the construction w/ characters > 0x80 is a bug.  But the returning of unicode vs. 8-bit strings is just a display issue.  IronPython only has unicode strings and is one of the big differences between CPython and IronPython.  If you haven't already I'll open a bug when I'm back after Thanksgiving.
>
> ________________________________________
> From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Patrick Dubroy [pdubroy at gmail.com]
> Sent: Wednesday, November 21, 2007 12:18 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] Problems with 8-bit strings
>
>
> Hi,
>
> I've noticed that in the latest version of IronPython (2.0A6), I
> noticed some weird behaviour with 8-bit strings:
>
>     IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1378
>     Copyright (c) Microsoft Corporation. All rights reserved.
>     >>> str("\x7e")
>     '~'
>     >>> str("\x7f")
>     u'\x7f'
>     >>> str("\x80")
>     u'\x80'
>     >>> str("\x81")
>     Traceback (most recent call last):
>       File , line 0, in ##23
>       File mscorlib, line unknown, in GetString
>       File mscorlib, line unknown, in GetChars
>       File mscorlib, line unknown, in Fallback
>       File mscorlib, line unknown, in Throw
>     UnicodeDecodeError: Unable to translate bytes [81] at index 0 from
> specified code page to Unicode.
>
> The first problem is that if the string contains characters 127 (0x7F)
> or 128 (0x80), str() will return a Unicode string rather than an 8-bit
> string. CPython, on the other hand, returns a standard 8-bit string
> for both of those cases. Then, if the string contains any bytes
> greater than 128, it throws an exception. CPython, on the other hand,
> is happy to have bytes up to 0xFF in an 8-bit string.
>
> Is this a known issue? Should I open a bug?
>
> Pat
> _______________________________________________
> 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 exchange.microsoft.com  Tue Nov 27 21:01:34 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 27 Nov 2007 12:01:34 -0800
Subject: [IronPython] DLR Hosting Spec
In-Reply-To: <5b0248170711192210u7e2724c6qe8c7553ac991cb67@mail.gmail.com>
References: <7AD436E4270DD54A94238001769C2227E45278355C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<5b0248170711192210u7e2724c6qe8c7553ac991cb67@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A45D9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

We discussed this today and think mime type support is a good idea.  Apparently we briefly looked at the Java APIs a year ago but we'll plan to do another review to compare and contrast the two.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Monday, November 19, 2007 10:11 PM
To: Discussion of IronPython
Subject: Re: [IronPython] DLR Hosting Spec

2007/11/20, Dino Viehland <dinov at exchange.microsoft.com>:
> We look forward to any feedback you might have!
> You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf

I think there are a lot of things to learn from Java. Java 6
introduced javax.script hosting API.
http://java.sun.com/javase/6/docs/api/javax/script/package-summary.html

For example, ScriptRuntime corresponds to Java's ScriptEngineManager.
We can compare API to get scripting engine for the given language.

DLR
ScriptEngine GetEngine(string languageId)
ScriptEngine GetEngineByFileExtension(string extension)

javax.script
ScriptEngine getEngineByName(String shortName)
ScriptEngine getEngineByExtension(String extension)
ScriptEngine getEngineByMimeType(String mimeType)

Is getEngineByMimeType a good idea? Similar comparisons can be made
for all other APIs too.

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


From dinov at exchange.microsoft.com  Tue Nov 27 21:25:49 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 27 Nov 2007 12:25:49 -0800
Subject: [IronPython] Problems with 8-bit strings
In-Reply-To: <95294eec0711271129i4f7e82d8s297a353be45c6b19@mail.gmail.com>
References: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E45261D6CF@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<95294eec0711271129i4f7e82d8s297a353be45c6b19@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A45E9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks!  (I actually didn't get back until today, and lots of e-mail & meetings so far today, so I just hadn't gotten the chance yet...)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Patrick Dubroy
Sent: Tuesday, November 27, 2007 11:29 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problems with 8-bit strings

I didn't see a bug open, so I opened one:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14104

Thanks,

Pat

On Nov 24, 2007 3:54 PM, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> I think the construction w/ characters > 0x80 is a bug.  But the returning of unicode vs. 8-bit strings is just a display issue.  IronPython only has unicode strings and is one of the big differences between CPython and IronPython.  If you haven't already I'll open a bug when I'm back after Thanksgiving.
>
> ________________________________________
> From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Patrick Dubroy [pdubroy at gmail.com]
> Sent: Wednesday, November 21, 2007 12:18 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] Problems with 8-bit strings
>
>
> Hi,
>
> I've noticed that in the latest version of IronPython (2.0A6), I
> noticed some weird behaviour with 8-bit strings:
>
>     IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.1378
>     Copyright (c) Microsoft Corporation. All rights reserved.
>     >>> str("\x7e")
>     '~'
>     >>> str("\x7f")
>     u'\x7f'
>     >>> str("\x80")
>     u'\x80'
>     >>> str("\x81")
>     Traceback (most recent call last):
>       File , line 0, in ##23
>       File mscorlib, line unknown, in GetString
>       File mscorlib, line unknown, in GetChars
>       File mscorlib, line unknown, in Fallback
>       File mscorlib, line unknown, in Throw
>     UnicodeDecodeError: Unable to translate bytes [81] at index 0 from
> specified code page to Unicode.
>
> The first problem is that if the string contains characters 127 (0x7F)
> or 128 (0x80), str() will return a Unicode string rather than an 8-bit
> string. CPython, on the other hand, returns a standard 8-bit string
> for both of those cases. Then, if the string contains any bytes
> greater than 128, it throws an exception. CPython, on the other hand,
> is happy to have bytes up to 0xFF in an 8-bit string.
>
> Is this a known issue? Should I open a bug?
>
> Pat
> _______________________________________________
> 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 David.Lawler at franke.com  Tue Nov 27 22:18:48 2007
From: David.Lawler at franke.com (David.Lawler at franke.com)
Date: Tue, 27 Nov 2007 16:18:48 -0500
Subject: [IronPython] Parser is not accessible anymore in IP2A6
In-Reply-To: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>
Message-ID: <OF0E2DDEB5.CBFB0D1A-ON852573A0.00746D8B-852573A0.0075167B@franke.com>

Hello,

The example at www.ironpython.info 'The IronPython 2 Parser' does not seem 
to work anymore with IP2A6...fails with a NameError: name 'Parser' is not 
defined.  I think it fails because Parser is now 'internal'?  The question 
I have is: Is this a permanent change - or is there another way to parse 
and then have access to the ast?

Thanks,

David 


From Martin.Maly at microsoft.com  Tue Nov 27 22:42:04 2007
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Tue, 27 Nov 2007 13:42:04 -0800
Subject: [IronPython] Parser is not accessible anymore in IP2A6
In-Reply-To: <OF0E2DDEB5.CBFB0D1A-ON852573A0.00746D8B-852573A0.0075167B@franke.com>
References: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>
	<OF0E2DDEB5.CBFB0D1A-ON852573A0.00746D8B-852573A0.0075167B@franke.com>
Message-ID: <C80B82844D92F64FA5D3B4790737D18DD9346E812C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Yes, Parser being internal definitely causes the error. It is a good question whether it is a permanent change because there are pros and cons going both ways. Let me open a bug on this since it is something we need to make decision on. In the meantime, as a temporary workaround (emphasizing the temporary workaround) you can use -X:PrivateBinding flag with IronPython to get access to the internal/private classes.

The bug I opened is here:

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

Feel free to vote/comment on it and also keep an eye on it for the ultimate resolution.

Thanks for the feedback!
Martin


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David.Lawler at franke.com
Sent: Tuesday, November 27, 2007 1:19 PM
To: Discussion of IronPython
Subject: [IronPython] Parser is not accessible anymore in IP2A6

Hello,

The example at www.ironpython.info 'The IronPython 2 Parser' does not seem
to work anymore with IP2A6...fails with a NameError: name 'Parser' is not
defined.  I think it fails because Parser is now 'internal'?  The question
I have is: Is this a permanent change - or is there another way to parse
and then have access to the ast?

Thanks,

David
_______________________________________________
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 28 01:02:26 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 28 Nov 2007 00:02:26 +0000
Subject: [IronPython] [python] Re: Parser is not accessible anymore in
 IP2A6
In-Reply-To: <C80B82844D92F64FA5D3B4790737D18DD9346E812C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <95294eec0711211218x9cb6f7fod38ef38a3d89eae@mail.gmail.com>	<OF0E2DDEB5.CBFB0D1A-ON852573A0.00746D8B-852573A0.0075167B@franke.com>
	<C80B82844D92F64FA5D3B4790737D18DD9346E812C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <474CB012.8070900@voidspace.org.uk>

Martin Maly wrote:
> Yes, Parser being internal definitely causes the error. It is a good question whether it is a permanent change because there are pros and cons going both ways. Let me open a bug on this since it is something we need to make decision on. In the meantime, as a temporary workaround (emphasizing the temporary workaround) you can use -X:PrivateBinding flag with IronPython to get access to the internal/private classes.
>
> The bug I opened is here:
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14105
>
> Feel free to vote/comment on it and also keep an eye on it for the ultimate resolution.
>
>   
*Please* provide access to the parser. :-)

Michael
http://www.manning.com/foord




> Thanks for the feedback!
> Martin
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David.Lawler at franke.com
> Sent: Tuesday, November 27, 2007 1:19 PM
> To: Discussion of IronPython
> Subject: [IronPython] Parser is not accessible anymore in IP2A6
>
> Hello,
>
> The example at www.ironpython.info 'The IronPython 2 Parser' does not seem
> to work anymore with IP2A6...fails with a NameError: name 'Parser' is not
> defined.  I think it fails because Parser is now 'internal'?  The question
> I have is: Is this a permanent change - or is there another way to parse
> and then have access to the ast?
>
> Thanks,
>
> David
> _______________________________________________
> 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 jdhardy at gmail.com  Wed Nov 28 04:40:23 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 27 Nov 2007 20:40:23 -0700
Subject: [IronPython]  Issues with Silly Module Tricks
Message-ID: <ea89d0e50711271940s7d24ce23j6bd44b356d2db48@mail.gmail.com>

Hi,
The following code is adapted from the Pygments library:

automod_test.py
import types

class _automodule(types.ModuleType):
    """Automatically import lexers."""

    def __getattr__(self, name):
        return "blah"

import sys
oldmod = sys.modules['automod_test']
newmod = _automodule('automod_test')
newmod.__dict__.update(oldmod.__dict__)
sys.modules['automod_test'] = newmod
del newmod.newmod, newmod.oldmod, newmod.sys, newmod.types

When run, I get the following results:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import automod_test
>>> automod_test.blah
'blah'

IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import automod_test
>>> automod_test.blah
Traceback (most recent call last):
  File , line 0, in ##268
AttributeError: 'module' object has no attribute 'blah'

I'm not sure whether the issue is with replacing sys.modules, or if it
is related to the __getattr__ issues that were reported a while back.
Either way, it prevents Pygments from getting past even the first
round of tests.

-Jeff


From Sathish.Kaveripakam at phonak.com  Wed Nov 28 11:30:23 2007
From: Sathish.Kaveripakam at phonak.com (Kaveripakam, Sathish)
Date: Wed, 28 Nov 2007 11:30:23 +0100
Subject: [IronPython] C# and IronPython Interface.
In-Reply-To: <7AD436E4270DD54A94238001769C2227E4539A4559@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <FBB055C769471C42BBAE2E206073B8ED07BE71BC@CH01SWC2.corp.ads>
	<7AD436E4270DD54A94238001769C2227E4539A4559@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <FBB055C769471C42BBAE2E206073B8ED07C257FF@CH01SWC2.corp.ads>

Hi All,

Please find my updated Entry.cs and ArithmeticOperations.py files:

Entry.cs :

using System;
using System.Collections;
using System.IO;
using System.Text;
using IronPython.Compiler;
using IronPython.Hosting;
using IronPython.Runtime;
using IronPython.Runtime.Exceptions;
using IronPython.Runtime.Operations;


public class Entry
{
    public static void Main(string[] args)
    {
        int a = 2, b = 2, x = 3;

        PythonEngine pe = new PythonEngine();
        EngineModule mod = pe.CreateModule();              

        pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod);
        object func = mod.Globals["ArithmeticOperations"];

        Object res = Ops.Call(func, a, b);
        Console.WriteLine(res);

    }
}

ArithmeticOperations.py:


def ArithmeticOperations(a,b):		
		return 


When I executed the above project (which includes IronMath and
IronPython dll's for V1.1), I find the run time exception, when it is
trying to execute the line

	
"pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod);" 

The trace for the above problem is as follows:

System.IO.IOException was unhandled
  Message="Could not add reference to assembly Microsoft.Scripting"
  Source="IronPython"
  StackTrace:
       at IronPython.Modules.ClrModule.AddReference(String name)
       at IronPython.Modules.ClrModule.AddReference(Object reference)
       at IronPython.Modules.ClrModule.AddReference(Object[] references)
       at AddReference##11(Object , Object )
       at IronPython.Runtime.Calls.CallTarget2.Invoke(Object arg0,
Object arg1)
       at IronPython.Runtime.Calls.FastCallable2.Call(ICallerContext
context, Object arg0, Object arg1)
       at IronPython.Runtime.Calls.FastCallable2.Call(ICallerContext
context, Object[] args)
       at
IronPython.Compiler.MethodBinder.MethodTarget.Call(ICallerContext
context, Object[] args)
       at IronPython.Compiler.MethodBinder.TargetSet.Call(ICallerContext
context, CallType callType, Object[] args)
       at
IronPython.Compiler.MethodBinder.TargetSet.Call2(ICallerContext context,
Object arg0, Object arg1)
       at
IronPython.Runtime.Calls.FastCallableWithContextAny.CallInstance(ICaller
Context context, Object arg0, Object arg1)
       at
IronPython.Runtime.Calls.BoundBuiltinFunction.Call(ICallerContext
context, Object arg0)
       at
IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext
context, Object func, Object arg0)
       at <string>##1(ModuleScope )
       at IronPython.Hosting.CompiledCodeDelegate.Invoke(ModuleScope
moduleScope)
       at IronPython.Hosting.CompiledCode.Run(ModuleScope moduleScope)
       at IronPython.Hosting.CompiledCode.Execute(EngineModule
engineModule, IDictionary`2 locals)
       at IronPython.Hosting.PythonEngine.Execute(String scriptCode,
String fileName, EngineModule engineModule, IDictionary`2 locals)
       at IronPython.Hosting.PythonEngine.Execute(String scriptCode,
EngineModule engineModule)
       at Entry.Main(String[] args) in
C:\TESTPROJS\Project3\Project1\Entry.cs:line 53
       at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence
assemblySecurity, String[] args)
       at
Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object
state)
       at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()


In this regard, I wanted to know am I missing something primitive in the
Project Settings ?

Regards

 

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Dienstag, 27. November 2007 18:32
To: Discussion of IronPython
Subject: Re: [IronPython] C# and IronPython Interface.

You're going to want to do something like (only compiled w/ Outlook, so
there may be some small compile errors here):

PythonEngine pe = new PythonEngine();
EngineModule mod = pe.CreateModule();
pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod); object
func = mod.Globals["ArithmeticOperations"];

That gets you the function...  From there you can call it one of several
ways:

Object res = Ops.Call(func, a, b);

        Or

delegate object MyDelegate(object a, object b);

MyDelegate dlg = Converter.Convert<MyDelegate>(func);
Object res = dlg(a, b);

In v1.x you can also use the CreateLambda/CreateMethod APIs if you have
the body of the code.  In general we prefer the 2nd form more where you
convert it to a delegate because it fits in better with .NET.  You can
also do things like have the delegate take strongly typed parameters and
there's the possibility that could turn into more optimized code in v2.0
at some point in the future.

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam,
Sathish
Sent: Monday, November 26, 2007 8:01 AM
To: users at lists.ironpython.com
Subject: [IronPython] C# and IronPython Interface.

HI All,

I have c#  code which should call a Iron Python function. I am using
Iron python 1.1 version and Visual Studio 2005. The details of my files
are as follows:


 C# code (Entry.cs):

using System;
using System.Collections;
using IronPython.Hosting;
public class Entry
{
            public static void Main(string[] args)
            {
                        int a= 2, b= 4;
                        // OVER HERE I WOULD LIKE TO CALL IRONPYTHON
Function: ArithmeticOperations which takes arguments a,b
                }
}
PYTHON SCRIPT(ArithmeticOperations.py):
def ArithmeticOperations( a,b):
print "I am in ArithmeticOperation functions..."
return  a+b

In my project setup, I gave reference to include : IronPython, IronMath
dll's In this regard, please do let me know, how to call the python
script "Arithmetic Operations" from my Entry.cs file ? Also, please do
let me know, if I have to include any of the libraries ?
Regards,
Sathish



________________________________________
Legal Notice:
The information in this electronic transmission may contain confidential
or legally privileged information and is intended solely for the
individual(s) named above. If you are not an intended recipient or an
authorized agent, you are hereby notified that reading, distributing, or
otherwise disseminating, copying or taking any action based on the
contents of this transmission is strictly prohibited. Any unauthorized
interception of this transmission is illegal under law. If you have
received this transmission in error, please notify the sender by
telephone [at the number indicated above/on +41 58 928 0101] as soon as
possible and then destroy all copies of this transmission.
________________________________________
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
******************** 
Legal Notice: 
The information in this electronic transmission may contain confidential or
legally privileged information and is intended solely for the individual(s)
named above. If you are not an intended recipient or an authorized agent,
you are hereby notified that reading, distributing, or otherwise
disseminating, copying or taking any action based on the contents of this
transmission is strictly prohibited. Any unauthorized interception of this
transmission is illegal under law. If you have received this transmission in
error, please notify the sender by telephone [at the number indicated above/
on +41 58 928 0101] as soon as possible and then destroy all copies of this
transmission. 
********************


From Sathish.Kaveripakam at phonak.com  Wed Nov 28 16:18:01 2007
From: Sathish.Kaveripakam at phonak.com (Kaveripakam, Sathish)
Date: Wed, 28 Nov 2007 16:18:01 +0100
Subject: [IronPython] Interfacing multiple Iron python scripts
Message-ID: <FBB055C769471C42BBAE2E206073B8ED07C25D21@CH01SWC2.corp.ads>

Hi All,
 
I am trying to integrate the C# code with multiple Iron Python scripts. 
 
The idea is:                    C# code: main.cs calls the main function
in mainpyfile.py. The mainpyfile.py has a call a function SetUP which is
present in an  another ironpython script called Patch1. 
 
The working behavior is:  C# code calls the mainpyfile.py as expected,
but when mainpyfile.py tries to call the function in Patch1.py, I
encountered a run time error saying Patch1 is not found. I have used
"import Patch1" in mainpyfile.py file for the visibility of SetUp
function in mainpyfile 
 
Please do let me know, if there are any concerns in interfacing multiple
Iron Python  files with C# code using .NET frame work? I am using Iron
python 1.1 version using Visual Studio 2K.
 
Please find the description of the files:
 
 
main.cs:
 
static void Main(string[] rawArgs)
{
 
 PythonEngine engine = new PythonEngine();
 engine.Sys.argv = List.Make("C:/TESTPROJS/Project3/Project1/");
 EngineModule engineModule = engine.CreateModule(
  "__main__", new Dictionary<string, object>(), true);
 
 engine.DefaultModule = engineModule;
 
 string path =
Path.Combine("C:/TESTPROJS/Project3/Project1/","mainpyfile.py" );
 
  engine.ExecuteFile(path);
}

mainpyfile.py:

import Patch1

def main():
        print 'IN MAIN FUNCTION'
        Patch1.SetUp()

if __name__ == "__main__":
       main()

Patch1.py:

def SetUp:
      print 'PATCH-1'


Regards


******************** 
Legal Notice: 
The information in this electronic transmission may contain confidential or
legally privileged information and is intended solely for the individual(s)
named above. If you are not an intended recipient or an authorized agent,
you are hereby notified that reading, distributing, or otherwise
disseminating, copying or taking any action based on the contents of this
transmission is strictly prohibited. Any unauthorized interception of this
transmission is illegal under law. If you have received this transmission in
error, please notify the sender by telephone [at the number indicated above/
on +41 58 928 0101] as soon as possible and then destroy all copies of this
transmission. 
********************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071128/174c4720/attachment.html>

From dinov at exchange.microsoft.com  Wed Nov 28 17:39:22 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 28 Nov 2007 08:39:22 -0800
Subject: [IronPython] C# and IronPython Interface.
In-Reply-To: <FBB055C769471C42BBAE2E206073B8ED07C257FF@CH01SWC2.corp.ads>
References: <FBB055C769471C42BBAE2E206073B8ED07BE71BC@CH01SWC2.corp.ads>
	<7AD436E4270DD54A94238001769C2227E4539A4559@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<FBB055C769471C42BBAE2E206073B8ED07C257FF@CH01SWC2.corp.ads>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A477D@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Microsoft.Scripting is part of IronPython v2.0 - are you somehow mixing and matching v1 and v2?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam, Sathish
Sent: Wednesday, November 28, 2007 2:30 AM
To: Discussion of IronPython
Subject: Re: [IronPython] C# and IronPython Interface.

Hi All,

Please find my updated Entry.cs and ArithmeticOperations.py files:

Entry.cs :

using System;
using System.Collections;
using System.IO;
using System.Text;
using IronPython.Compiler;
using IronPython.Hosting;
using IronPython.Runtime;
using IronPython.Runtime.Exceptions;
using IronPython.Runtime.Operations;


public class Entry
{
    public static void Main(string[] args)
    {
        int a = 2, b = 2, x = 3;

        PythonEngine pe = new PythonEngine();
        EngineModule mod = pe.CreateModule();

        pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod);
        object func = mod.Globals["ArithmeticOperations"];

        Object res = Ops.Call(func, a, b);
        Console.WriteLine(res);

    }
}

ArithmeticOperations.py:


def ArithmeticOperations(a,b):
                return


When I executed the above project (which includes IronMath and
IronPython dll's for V1.1), I find the run time exception, when it is
trying to execute the line


"pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod);"

The trace for the above problem is as follows:

System.IO.IOException was unhandled
  Message="Could not add reference to assembly Microsoft.Scripting"
  Source="IronPython"
  StackTrace:
       at IronPython.Modules.ClrModule.AddReference(String name)
       at IronPython.Modules.ClrModule.AddReference(Object reference)
       at IronPython.Modules.ClrModule.AddReference(Object[] references)
       at AddReference##11(Object , Object )
       at IronPython.Runtime.Calls.CallTarget2.Invoke(Object arg0,
Object arg1)
       at IronPython.Runtime.Calls.FastCallable2.Call(ICallerContext
context, Object arg0, Object arg1)
       at IronPython.Runtime.Calls.FastCallable2.Call(ICallerContext
context, Object[] args)
       at
IronPython.Compiler.MethodBinder.MethodTarget.Call(ICallerContext
context, Object[] args)
       at IronPython.Compiler.MethodBinder.TargetSet.Call(ICallerContext
context, CallType callType, Object[] args)
       at
IronPython.Compiler.MethodBinder.TargetSet.Call2(ICallerContext context,
Object arg0, Object arg1)
       at
IronPython.Runtime.Calls.FastCallableWithContextAny.CallInstance(ICaller
Context context, Object arg0, Object arg1)
       at
IronPython.Runtime.Calls.BoundBuiltinFunction.Call(ICallerContext
context, Object arg0)
       at
IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext
context, Object func, Object arg0)
       at <string>##1(ModuleScope )
       at IronPython.Hosting.CompiledCodeDelegate.Invoke(ModuleScope
moduleScope)
       at IronPython.Hosting.CompiledCode.Run(ModuleScope moduleScope)
       at IronPython.Hosting.CompiledCode.Execute(EngineModule
engineModule, IDictionary`2 locals)
       at IronPython.Hosting.PythonEngine.Execute(String scriptCode,
String fileName, EngineModule engineModule, IDictionary`2 locals)
       at IronPython.Hosting.PythonEngine.Execute(String scriptCode,
EngineModule engineModule)
       at Entry.Main(String[] args) in
C:\TESTPROJS\Project3\Project1\Entry.cs:line 53
       at System.AppDomain.nExecuteAssembly(Assembly assembly, String[]
args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence
assemblySecurity, String[] args)
       at
Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object
state)
       at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()


In this regard, I wanted to know am I missing something primitive in the
Project Settings ?

Regards



-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Dienstag, 27. November 2007 18:32
To: Discussion of IronPython
Subject: Re: [IronPython] C# and IronPython Interface.

You're going to want to do something like (only compiled w/ Outlook, so
there may be some small compile errors here):

PythonEngine pe = new PythonEngine();
EngineModule mod = pe.CreateModule();
pe.Execute(File.ReadAllText("ArithmeticOperations.py"), mod); object
func = mod.Globals["ArithmeticOperations"];

That gets you the function...  From there you can call it one of several
ways:

Object res = Ops.Call(func, a, b);

        Or

delegate object MyDelegate(object a, object b);

MyDelegate dlg = Converter.Convert<MyDelegate>(func);
Object res = dlg(a, b);

In v1.x you can also use the CreateLambda/CreateMethod APIs if you have
the body of the code.  In general we prefer the 2nd form more where you
convert it to a delegate because it fits in better with .NET.  You can
also do things like have the delegate take strongly typed parameters and
there's the possibility that could turn into more optimized code in v2.0
at some point in the future.

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam,
Sathish
Sent: Monday, November 26, 2007 8:01 AM
To: users at lists.ironpython.com
Subject: [IronPython] C# and IronPython Interface.

HI All,

I have c#  code which should call a Iron Python function. I am using
Iron python 1.1 version and Visual Studio 2005. The details of my files
are as follows:


 C# code (Entry.cs):

using System;
using System.Collections;
using IronPython.Hosting;
public class Entry
{
            public static void Main(string[] args)
            {
                        int a= 2, b= 4;
                        // OVER HERE I WOULD LIKE TO CALL IRONPYTHON
Function: ArithmeticOperations which takes arguments a,b
                }
}
PYTHON SCRIPT(ArithmeticOperations.py):
def ArithmeticOperations( a,b):
print "I am in ArithmeticOperation functions..."
return  a+b

In my project setup, I gave reference to include : IronPython, IronMath
dll's In this regard, please do let me know, how to call the python
script "Arithmetic Operations" from my Entry.cs file ? Also, please do
let me know, if I have to include any of the libraries ?
Regards,
Sathish



________________________________________
Legal Notice:
The information in this electronic transmission may contain confidential
or legally privileged information and is intended solely for the
individual(s) named above. If you are not an intended recipient or an
authorized agent, you are hereby notified that reading, distributing, or
otherwise disseminating, copying or taking any action based on the
contents of this transmission is strictly prohibited. Any unauthorized
interception of this transmission is illegal under law. If you have
received this transmission in error, please notify the sender by
telephone [at the number indicated above/on +41 58 928 0101] as soon as
possible and then destroy all copies of this transmission.
________________________________________
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
********************
Legal Notice:
The information in this electronic transmission may contain confidential or
legally privileged information and is intended solely for the individual(s)
named above. If you are not an intended recipient or an authorized agent,
you are hereby notified that reading, distributing, or otherwise
disseminating, copying or taking any action based on the contents of this
transmission is strictly prohibited. Any unauthorized interception of this
transmission is illegal under law. If you have received this transmission in
error, please notify the sender by telephone [at the number indicated above/
on +41 58 928 0101] as soon as possible and then destroy all copies of this
transmission.
********************
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Wed Nov 28 17:42:37 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 28 Nov 2007 08:42:37 -0800
Subject: [IronPython] Interfacing multiple Iron python scripts
In-Reply-To: <FBB055C769471C42BBAE2E206073B8ED07C25D21@CH01SWC2.corp.ads>
References: <FBB055C769471C42BBAE2E206073B8ED07C25D21@CH01SWC2.corp.ads>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A4780@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

You'll need to put C:/TESTPROJS/Project3/Project1/ into Sys.path using PythonEngine.AddToPath.  That will then allow the import machinery to search in the right place to find the file to import.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam, Sathish
Sent: Wednesday, November 28, 2007 7:18 AM
To: users at lists.ironpython.com
Subject: [IronPython] Interfacing multiple Iron python scripts

Hi All,

I am trying to integrate the C# code with multiple Iron Python scripts.

The idea is:                    C# code: main.cs calls the main function in mainpyfile.py. The mainpyfile.py has a call a function SetUP which is present in an  another ironpython script called Patch1.

The working behavior is:  C# code calls the mainpyfile.py as expected, but when mainpyfile.py tries to call the function in Patch1.py, I encountered a run time error saying Patch1 is not found. I have used "import Patch1" in mainpyfile.py file for the visibility of SetUp function in mainpyfile

Please do let me know, if there are any concerns in interfacing multiple Iron Python  files with C# code using .NET frame work? I am using Iron python 1.1 version using Visual Studio 2K.

Please find the description of the files:


main.cs:

static void Main(string[] rawArgs)
{

 PythonEngine engine = new PythonEngine();
 engine.Sys.argv = List.Make("C:/TESTPROJS/Project3/Project1/");
 EngineModule engineModule = engine.CreateModule(
  "__main__", new Dictionary<string, object>(), true);

 engine.DefaultModule = engineModule;

 string path = Path.Combine("C:/TESTPROJS/Project3/Project1/","mainpyfile.py" );

  engine.ExecuteFile(path);
}

mainpyfile.py:

import Patch1

def main():
        print 'IN MAIN FUNCTION'
        Patch1.SetUp()

if __name__ == "__main__":
       main()

Patch1.py:

def SetUp:
      print 'PATCH-1'

Regards

________________________________
Legal Notice:
The information in this electronic transmission may contain confidential or legally privileged information and is intended solely for the individual(s) named above. If you are not an intended recipient or an authorized agent, you are hereby notified that reading, distributing, or otherwise disseminating, copying or taking any action based on the contents of this transmission is strictly prohibited. Any unauthorized interception of this transmission is illegal under law. If you have received this transmission in error, please notify the sender by telephone [at the number indicated above/on +41 58 928 0101] as soon as possible and then destroy all copies of this transmission.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071128/c0ea01e8/attachment.html>

From dfugate at microsoft.com  Wed Nov 28 18:09:32 2007
From: dfugate at microsoft.com (Dave Fugate)
Date: Wed, 28 Nov 2007 09:09:32 -0800
Subject: [IronPython] IronPython.sln and .NET 3.5/Visual Studio 2008
Message-ID: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>

Hello IronPython Community, a couple months ago we began using the beta versions of .NET 3.5 and Visual Studio 2008 for IronPython development.  With respect to the IronPython sources this means that we had to upgrade the Visual Studio 2005 solution file, IronPython.sln, to Visual Studio 2008.  We are *not* using any new C# 3.0 features at this time and actually pass a flag to the msbuild tool ensuring that we're building and testing against .NET 2.0.

Since this change occurred, we've been backporting solution file modifications to the 2005 version and testing the 2008 version as well for the 2.0 Alpha releases.  Now that .NET 3.5 and Visual Studio 2008 have been officially released, we'd like to begin distributing only the 2008 solution file.  The major reason for wanting to do this is so that we can get IP releases out more quickly (i.e., no need to rerun all of our tests on sources built under VS2005 or manually modify the 2005 solution file).

The impact on Windows users who build IronPython from sources would be:
* It will be necessary to install .NET 3.5 or Visual Studio 2008 to get the new version of msbuild
* When building IronPython.sln from the command-line, you'll need to pass in an extra argument - "/ToolsVersion:2.0" - to msbuild

We felt it would be best get feedback from users who build IP from sources before making this change.  Ideally we'd like to make the switch for the next Alpha release (which should be available around the third week of December), but the change could be delayed if there are many objections.  All comments are welcome!

The IronPython Team


From rpehlm at btinternet.com  Wed Nov 28 18:30:46 2007
From: rpehlm at btinternet.com (Robin Lauryssen-Mitchell)
Date: Wed, 28 Nov 2007 18:30:46 +0100
Subject: [IronPython] [Bulk] IronPython.sln and .NET 3.5/Visual Studio
	2008
In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>
Message-ID: <000901c831e4$69c4f880$2101a8c0@Kudu>

No problem for lil 'ol me :)

Robin

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dave Fugate
> Sent: 28 November 2007 18:10
> To: Discussion of IronPython
> Subject: [Bulk] [IronPython] IronPython.sln and .NET 3.5/Visual Studio
> 2008
> 
> Hello IronPython Community, a couple months ago we began using the beta
> versions of .NET 3.5 and Visual Studio 2008 for IronPython development.
> With respect to the IronPython sources this means that we had to upgrade
> the Visual Studio 2005 solution file, IronPython.sln, to Visual Studio
> 2008.  We are *not* using any new C# 3.0 features at this time and
> actually pass a flag to the msbuild tool ensuring that we're building and
> testing against .NET 2.0.
> 
> Since this change occurred, we've been backporting solution file
> modifications to the 2005 version and testing the 2008 version as well for
> the 2.0 Alpha releases.  Now that .NET 3.5 and Visual Studio 2008 have
> been officially released, we'd like to begin distributing only the 2008
> solution file.  The major reason for wanting to do this is so that we can
> get IP releases out more quickly (i.e., no need to rerun all of our tests
> on sources built under VS2005 or manually modify the 2005 solution file).
> 
> The impact on Windows users who build IronPython from sources would be:
> * It will be necessary to install .NET 3.5 or Visual Studio 2008 to get
> the new version of msbuild
> * When building IronPython.sln from the command-line, you'll need to pass
> in an extra argument - "/ToolsVersion:2.0" - to msbuild
> 
> We felt it would be best get feedback from users who build IP from sources
> before making this change.  Ideally we'd like to make the switch for the
> next Alpha release (which should be available around the third week of
> December), but the change could be delayed if there are many objections.
> All comments are welcome!
> 
> The IronPython Team
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From kfarmer at thuban.org  Wed Nov 28 18:42:23 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 28 Nov 2007 09:42:23 -0800
Subject: [IronPython] [Bulk] IronPython.sln and .NET 3.5/Visual
	Studio2008
In-Reply-To: <000901c831e4$69c4f880$2101a8c0@Kudu>
References: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<000901c831e4$69c4f880$2101a8c0@Kudu>
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075441E0B42@meta-exchange.circle-cross.home>

You mean someone *hasn't* downloaded .NET 3.5? :)

The only impediment I can think of would be whether Mono's tools can handle it.  I haven't touched Mono in ages, so I don't know one way or the other.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Robin Lauryssen-Mitchell
Sent: Wednesday, November 28, 2007 9:31 AM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] [Bulk] IronPython.sln and .NET 3.5/Visual Studio2008

No problem for lil 'ol me :)

Robin

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dave Fugate
> Sent: 28 November 2007 18:10
> To: Discussion of IronPython
> Subject: [Bulk] [IronPython] IronPython.sln and .NET 3.5/Visual Studio
> 2008
> 
> Hello IronPython Community, a couple months ago we began using the beta
> versions of .NET 3.5 and Visual Studio 2008 for IronPython development.
> With respect to the IronPython sources this means that we had to upgrade
> the Visual Studio 2005 solution file, IronPython.sln, to Visual Studio
> 2008.  We are *not* using any new C# 3.0 features at this time and
> actually pass a flag to the msbuild tool ensuring that we're building and
> testing against .NET 2.0.
> 
> Since this change occurred, we've been backporting solution file
> modifications to the 2005 version and testing the 2008 version as well for
> the 2.0 Alpha releases.  Now that .NET 3.5 and Visual Studio 2008 have
> been officially released, we'd like to begin distributing only the 2008
> solution file.  The major reason for wanting to do this is so that we can
> get IP releases out more quickly (i.e., no need to rerun all of our tests
> on sources built under VS2005 or manually modify the 2005 solution file).
> 
> The impact on Windows users who build IronPython from sources would be:
> * It will be necessary to install .NET 3.5 or Visual Studio 2008 to get
> the new version of msbuild
> * When building IronPython.sln from the command-line, you'll need to pass
> in an extra argument - "/ToolsVersion:2.0" - to msbuild
> 
> We felt it would be best get feedback from users who build IP from sources
> before making this change.  Ideally we'd like to make the switch for the
> next Alpha release (which should be available around the third week of
> December), but the change could be delayed if there are many objections.
> All comments are welcome!
> 
> The IronPython Team
> _______________________________________________
> 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  Wed Nov 28 18:46:35 2007
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 28 Nov 2007 17:46:35 +0000
Subject: [IronPython] [Bulk] IronPython.sln and .NET
	3.5/Visual	Studio2008
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC26075441E0B42@meta-exchange.circle-cross.home>
References: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>	<000901c831e4$69c4f880$2101a8c0@Kudu>
	<EEDCD954DD4A0D488BBDBDDCC26075441E0B42@meta-exchange.circle-cross.home>
Message-ID: <474DA97B.1000309@voidspace.org.uk>

Keith J. Farmer wrote:
> You mean someone *hasn't* downloaded .NET 3.5? :)
>
> The only impediment I can think of would be whether Mono's tools can handle it.  I haven't touched Mono in ages, so I don't know one way or the other.
>   

A lot of our customers are banks and the like. *Most* of them (but by no 
means all) have upgraded to .NET 2, few if any will have progressed to 
3. That isn't really relevant for this question (none of them will be 
building IronPython from source) - but just a reminder that us geeks 
live in a world far removed from 'the real one' (whatever that might be...).

My only concern would be that IronPython remains buildable with both 
Express 2005 and Express 2008 (plus Mono tools of course).

Michael
http://www.manning.com/foord



> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Robin Lauryssen-Mitchell
> Sent: Wednesday, November 28, 2007 9:31 AM
> To: 'Discussion of IronPython'
> Subject: Re: [IronPython] [Bulk] IronPython.sln and .NET 3.5/Visual Studio2008
>
> No problem for lil 'ol me :)
>
> Robin
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Dave Fugate
>> Sent: 28 November 2007 18:10
>> To: Discussion of IronPython
>> Subject: [Bulk] [IronPython] IronPython.sln and .NET 3.5/Visual Studio
>> 2008
>>
>> Hello IronPython Community, a couple months ago we began using the beta
>> versions of .NET 3.5 and Visual Studio 2008 for IronPython development.
>> With respect to the IronPython sources this means that we had to upgrade
>> the Visual Studio 2005 solution file, IronPython.sln, to Visual Studio
>> 2008.  We are *not* using any new C# 3.0 features at this time and
>> actually pass a flag to the msbuild tool ensuring that we're building and
>> testing against .NET 2.0.
>>
>> Since this change occurred, we've been backporting solution file
>> modifications to the 2005 version and testing the 2008 version as well for
>> the 2.0 Alpha releases.  Now that .NET 3.5 and Visual Studio 2008 have
>> been officially released, we'd like to begin distributing only the 2008
>> solution file.  The major reason for wanting to do this is so that we can
>> get IP releases out more quickly (i.e., no need to rerun all of our tests
>> on sources built under VS2005 or manually modify the 2005 solution file).
>>
>> The impact on Windows users who build IronPython from sources would be:
>> * It will be necessary to install .NET 3.5 or Visual Studio 2008 to get
>> the new version of msbuild
>> * When building IronPython.sln from the command-line, you'll need to pass
>> in an extra argument - "/ToolsVersion:2.0" - to msbuild
>>
>> We felt it would be best get feedback from users who build IP from sources
>> before making this change.  Ideally we'd like to make the switch for the
>> next Alpha release (which should be available around the third week of
>> December), but the change could be delayed if there are many objections.
>> All comments are welcome!
>>
>> The IronPython Team
>> _______________________________________________
>> 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 steve at mcneel.com  Wed Nov 28 19:06:11 2007
From: steve at mcneel.com (Steve Baer)
Date: Wed, 28 Nov 2007 10:06:11 -0800
Subject: [IronPython] IronPython.sln and .NET 3.5/Visual Studio 2008
In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>
References: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>
Message-ID: <001701c831e9$5b7e3d40$127ab7c0$@com>

Hi Dave,
I have no problem with the sln being based on VS2008. I would be concerned
if this project stops building against .NET 2.0, but that doesn't sound like
it is the case.

Thanks,
-Steve

Steve Baer
Robert McNeel & Associates
www.rhino3d.com
www.mcneel.com

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Wednesday, November 28, 2007 9:10 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython.sln and .NET 3.5/Visual Studio 2008

Hello IronPython Community, a couple months ago we began using the beta
versions of .NET 3.5 and Visual Studio 2008 for IronPython development.
With respect to the IronPython sources this means that we had to upgrade the
Visual Studio 2005 solution file, IronPython.sln, to Visual Studio 2008.  We
are *not* using any new C# 3.0 features at this time and actually pass a
flag to the msbuild tool ensuring that we're building and testing against
.NET 2.0.

Since this change occurred, we've been backporting solution file
modifications to the 2005 version and testing the 2008 version as well for
the 2.0 Alpha releases.  Now that .NET 3.5 and Visual Studio 2008 have been
officially released, we'd like to begin distributing only the 2008 solution
file.  The major reason for wanting to do this is so that we can get IP
releases out more quickly (i.e., no need to rerun all of our tests on
sources built under VS2005 or manually modify the 2005 solution file).

The impact on Windows users who build IronPython from sources would be:
* It will be necessary to install .NET 3.5 or Visual Studio 2008 to get the
new version of msbuild
* When building IronPython.sln from the command-line, you'll need to pass in
an extra argument - "/ToolsVersion:2.0" - to msbuild

We felt it would be best get feedback from users who build IP from sources
before making this change.  Ideally we'd like to make the switch for the
next Alpha release (which should be available around the third week of
December), but the change could be delayed if there are many objections.
All comments are welcome!

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




From dinov at exchange.microsoft.com  Wed Nov 28 19:49:55 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 28 Nov 2007 10:49:55 -0800
Subject: [IronPython] Issues with Silly Module Tricks
In-Reply-To: <ea89d0e50711271940s7d24ce23j6bd44b356d2db48@mail.gmail.com>
References: <ea89d0e50711271940s7d24ce23j6bd44b356d2db48@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A47FD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Thanks for the bug report.  There's actually a few issues here:

        types.ModuleType is actually SystemState (you can see this by doing import clr; clr.GetClrType(types.ModuleType))
        ScriptModule (the type we use to represent module's currently) is currently sealed, so you can't inherit from it if you were getting the right type
        We don't support __getattr__ / __getattribute__ on types that implement ICustomMembers (which SystemState does).

If you want the nitty gritty details:

The 1st problem is a long-lived problem where we do type impersonation on the SystemState to make it look like a module.  SystemState then implements ICustomMembers so that arbitrary things can be get/set on it which brings us to the 3rd problem.  Before v2.0 is done I suspect that this is going to change and "sys" will be just a normal module.  ICustomMembers will also be going away and get replaced with operators used for lookup - the operators will actually compose correctly and your __getattr__ should get called.

The 2nd problem is currently a DLR problem.  Currently we have a concept of modules in the DLR but that's going away soon.  When that happens ScriptModule (in the most recent code it's not ScriptScope) will be PythonModule and we'll enable inheritance again.

I've opened bug #14147 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14147) to track the issue until all of this gets fixed but unfortunately it's going to take a little time.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Tuesday, November 27, 2007 7:40 PM
To: Discussion of IronPython
Subject: [IronPython] Issues with Silly Module Tricks

Hi,
The following code is adapted from the Pygments library:

automod_test.py
import types

class _automodule(types.ModuleType):
    """Automatically import lexers."""

    def __getattr__(self, name):
        return "blah"

import sys
oldmod = sys.modules['automod_test']
newmod = _automodule('automod_test')
newmod.__dict__.update(oldmod.__dict__)
sys.modules['automod_test'] = newmod
del newmod.newmod, newmod.oldmod, newmod.sys, newmod.types

When run, I get the following results:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import automod_test
>>> automod_test.blah
'blah'

IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import automod_test
>>> automod_test.blah
Traceback (most recent call last):
  File , line 0, in ##268
AttributeError: 'module' object has no attribute 'blah'

I'm not sure whether the issue is with replacing sys.modules, or if it
is related to the __getattr__ issues that were reported a while back.
Either way, it prevents Pygments from getting past even the first
round of tests.

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


From David.Lawler at franke.com  Wed Nov 28 22:45:31 2007
From: David.Lawler at franke.com (David.Lawler at franke.com)
Date: Wed, 28 Nov 2007 16:45:31 -0500
Subject: [IronPython] Parser is not accessible anymore in IP2A6
In-Reply-To: <C80B82844D92F64FA5D3B4790737D18DD9346E812C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <OF19378EB2.48DB6C97-ON852573A1.00756A10-852573A1.0077863C@franke.com>

> Yes, Parser being internal definitely causes the error. It is a good
> question whether it is a permanent change because there are pros and
> cons going both ways. Let me open a bug on this since it is 
> something we need to make decision on. In the meantime, as a 
> temporary workaround (emphasizing the temporary workaround) you can 
> use -X:PrivateBinding flag with IronPython to get access to the 
> internal/private classes.
> 
> The bug I opened is here:
> 
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14105
> 
> Feel free to vote/comment on it and also keep an eye on it for the 
> ultimate resolution.
> 
> Thanks for the feedback!
> Martin
> 

Well - that SHOULD work - but does not.  If you take the following example 
program:

import clr

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

from System.Text import Encoding
import IronPython
import Microsoft.Scripting

path = "PythonParserTest.py"
pe = IronPython.Hosting.PythonEngine.CurrentEngine
enc = Encoding.Default
s = Microsoft.Scripting.Hosting.SourceUnit.CreateFileUnit(pe, path, enc)
c = Microsoft.Scripting.CompilerContext(s)

p = IronPython.Compiler.Parser.CreateParser(c, 
IronPython.PythonEngineOptions())

ast = p.ParseFile(True)

print "all done"

save it as PythonParserTest.py and run it you get this:

ipy -X:PrivateBinding -X:ExceptionDetail PythonParserTest.py
Value cannot be null.
Parameter name: expression
   at Microsoft.Scripting.Ast.Ast.ConvertHelper(Expression expression, 
Type type
)
   at 
Microsoft.Scripting.Generation.MethodTarget.MakeExpression(ActionBinder bi
nder, StandardRule rule, Expression[] parameters)
   at 
Microsoft.Scripting.Generation.MethodTarget.MakeExpression(ActionBinder bi
nder, StandardRule rule, Expression[] parameters, Type[] knownTypes)
   at 
Microsoft.Scripting.Actions.CallBinderHelper`2.MakeMethodBaseRule(MethodBa
se[] targets)
   at Microsoft.Scripting.Actions.CallBinderHelper`2.MakeRule()
   at IronPython.Runtime.Types.BuiltinFunction.MakeCallRule[T](CallAction 
action
, CodeContext context, Object[] args)
   at 
IronPython.Runtime.Types.BuiltinFunction.Microsoft.Scripting.IDynamicObjec
t.GetRule[T](DynamicAction action, CodeContext context, Object[] args)
   at 
Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
xt callerContext, DynamicAction action, Object[] args, Object site, T& 
target, R
uleSet`1& rules)
   at 
Microsoft.Scripting.Actions.FastDynamicSite`4.UpdateBindingAndInvoke(T0 ar
g0, T1 arg1, T2 arg2)
   at 
Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
.FastInvoke3(FastDynamicSite`4 site, T0 arg0, T1 arg1, T2 arg2)
   at Microsoft.Scripting.Actions.FastDynamicSite`4.Invoke(T0 arg0, T1 
arg1, T2
arg2)
   at __main__$mod_1.Initialize(CodeContext ) in PythonParserTest.py:line 
16
   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean 
tryEva
luate)
   at Microsoft.Scripting.ScriptModule.Execute()
   at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
   at IronPython.Hosting.PythonCommandLine.RunFile(String filename)

if you make your own version of IronPython 2A6 with Parser set to public 
rather
than internal, then the above example works.  The problem appears to be in 
MethodTarget.cs
around line 150 or so:

                // Private binding, invoke via reflection
                if (mi != null) {
                    Expression instance = mi.IsStatic ? null : 
_instanceBuilder.ToExpression(context, parameters);
                    call = Ast.Call(
                        Ast.RuntimeConstant(mi),
                        typeof(MethodInfo).GetMethod("Invoke", new Type[] 
{ typeof(object), typeof(object[]) }),
                        Ast.ConvertHelper(instance, typeof(object)),
                        Ast.NewArrayHelper(typeof(object[]), args)
                    );
                } else {
                    call = Ast.Call(
                        Ast.RuntimeConstant((ConstructorInfo)Method),
                        typeof(ConstructorInfo).GetMethod("Invoke", new 
Type[] { typeof(object[]) }), 
                        Ast.NewArrayHelper(typeof(object[]), args)
                    ); 
                }

where it seems that the 'invoke via reflection for private bindings' has 
issues in
Ast.ConvertHelper.  However, as I tried to understand the problem further 
I developed
an enormous brain cramp.  I am so happy that I mostly write business 
software and not compilers!
This is not of huge importance to me but I would think that you would want 
to solve this
for the poor souls out there who are (or will be) trying to produce 
editors/IDEs or other
tools for IronPython (think Intellisense and/or code completion).

Regards,

David


From kfarmer at thuban.org  Wed Nov 28 23:20:41 2007
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Wed, 28 Nov 2007 14:20:41 -0800
Subject: [IronPython] [Bulk] IronPython.sln and .NET3.5/Visual	Studio2008
References: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>	<000901c831e4$69c4f880$2101a8c0@Kudu><EEDCD954DD4A0D488BBDBDDCC26075441E0B42@meta-exchange.circle-cross.home>
	<474DA97B.1000309@voidspace.org.uk>
Message-ID: <EEDCD954DD4A0D488BBDBDDCC26075442CC740@meta-exchange.circle-cross.home>

Having dealt with certain non-US banks over the last couple years, I know that at least some of them have yet to upgrade to doing wire transfers via some mechanism other than paper.  I suspect we geeks are closer to the "real" world than they are.  ;)
 
The retargetting feature in Orcas is pretty neat, though.  I used it on one project recently to make sure I didn't have any framework version dependencies beyond those the software I was targetting had.

________________________________

From: users-bounces at lists.ironpython.com on behalf of Michael Foord
Sent: Wed 11/28/2007 9:46 AM
To: Discussion of IronPython
Subject: Re: [IronPython] [Bulk] IronPython.sln and .NET3.5/Visual Studio2008



Keith J. Farmer wrote:
> You mean someone *hasn't* downloaded .NET 3.5? :)
>
> The only impediment I can think of would be whether Mono's tools can handle it.  I haven't touched Mono in ages, so I don't know one way or the other.
>  

A lot of our customers are banks and the like. *Most* of them (but by no
means all) have upgraded to .NET 2, few if any will have progressed to
3. That isn't really relevant for this question (none of them will be
building IronPython from source) - but just a reminder that us geeks
live in a world far removed from 'the real one' (whatever that might be...).

My only concern would be that IronPython remains buildable with both
Express 2005 and Express 2008 (plus Mono tools of course).

Michael
http://www.manning.com/foord



> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Robin Lauryssen-Mitchell
> Sent: Wednesday, November 28, 2007 9:31 AM
> To: 'Discussion of IronPython'
> Subject: Re: [IronPython] [Bulk] IronPython.sln and .NET 3.5/Visual Studio2008
>
> No problem for lil 'ol me :)
>
> Robin
>
>  
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Dave Fugate
>> Sent: 28 November 2007 18:10
>> To: Discussion of IronPython
>> Subject: [Bulk] [IronPython] IronPython.sln and .NET 3.5/Visual Studio
>> 2008
>>
>> Hello IronPython Community, a couple months ago we began using the beta
>> versions of .NET 3.5 and Visual Studio 2008 for IronPython development.
>> With respect to the IronPython sources this means that we had to upgrade
>> the Visual Studio 2005 solution file, IronPython.sln, to Visual Studio
>> 2008.  We are *not* using any new C# 3.0 features at this time and
>> actually pass a flag to the msbuild tool ensuring that we're building and
>> testing against .NET 2.0.
>>
>> Since this change occurred, we've been backporting solution file
>> modifications to the 2005 version and testing the 2008 version as well for
>> the 2.0 Alpha releases.  Now that .NET 3.5 and Visual Studio 2008 have
>> been officially released, we'd like to begin distributing only the 2008
>> solution file.  The major reason for wanting to do this is so that we can
>> get IP releases out more quickly (i.e., no need to rerun all of our tests
>> on sources built under VS2005 or manually modify the 2005 solution file).
>>
>> The impact on Windows users who build IronPython from sources would be:
>> * It will be necessary to install .NET 3.5 or Visual Studio 2008 to get
>> the new version of msbuild
>> * When building IronPython.sln from the command-line, you'll need to pass
>> in an extra argument - "/ToolsVersion:2.0" - to msbuild
>>
>> We felt it would be best get feedback from users who build IP from sources
>> before making this change.  Ideally we'd like to make the switch for the
>> next Alpha release (which should be available around the third week of
>> December), but the change could be delayed if there are many objections.
>> All comments are welcome!
>>
>> The IronPython Team
>> _______________________________________________
>> 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 jpardy at esri.com  Thu Nov 29 01:02:02 2007
From: jpardy at esri.com (Jason Pardy)
Date: Wed, 28 Nov 2007 16:02:02 -0800
Subject: [IronPython] Intefaces
In-Reply-To: <536FA8D75A73B9449931E9C876D2C9B002BD937B@barbwire.esri.com>
References: <536FA8D75A73B9449931E9C876D2C9B002BD937B@barbwire.esri.com>
Message-ID: <5583F32168AFAF4D8298CBB3AAB30D24046EA454@livewire.esri.com>

Has there been any work on documenting the calling of explicitly
implemented interfaces and
getting/setting properties through interfaces? If so, is there a
location where I can get this information?
 
Much Thanks,

Jason
 
2006/10/19, Jason Pardy <jpardy at esri.com
<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com> >:
> However, when I try to retrieve the value from a read only property, I
get
> an error.
> 
> Is this supposed to work?
> 
> IGeoProcessorResult.ReturnValue(result)
 
Yes, but the correct syntax is:
 
IGeoProcessorResult.ReturnValue.GetValue(result)
IGeoProcessorResult.ReturnValue.SetValue(result, value)
 
It kinda makes sense, if you think about it.
 
All in all, calling explicitly implemented interfaces and
getting/setting properties through interfaces, could be better
documented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071128/36c35322/attachment.html>

From dinov at exchange.microsoft.com  Thu Nov 29 01:07:56 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 28 Nov 2007 16:07:56 -0800
Subject: [IronPython] Intefaces
In-Reply-To: <5583F32168AFAF4D8298CBB3AAB30D24046EA454@livewire.esri.com>
References: <536FA8D75A73B9449931E9C876D2C9B002BD937B@barbwire.esri.com>
	<5583F32168AFAF4D8298CBB3AAB30D24046EA454@livewire.esri.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A48F9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

I don't think there's any great documentation on this, but you can do interface.property.GetValue(instance) or interface.property.SetValue(instance, value).

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jason Pardy
Sent: Wednesday, November 28, 2007 4:02 PM
To: users at lists.ironpython.com
Subject: Re: [IronPython] Intefaces


Has there been any work on documenting the calling of explicitly implemented interfaces and

getting/setting properties through interfaces? If so, is there a location where I can get this information?



Much Thanks,





Jason



2006/10/19, Jason Pardy <jpardy at esri.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>>:

> However, when I try to retrieve the value from a read only property, I get

> an error.

>

> Is this supposed to work?

>

> IGeoProcessorResult.ReturnValue(result)



Yes, but the correct syntax is:



IGeoProcessorResult.ReturnValue.GetValue(result)

IGeoProcessorResult.ReturnValue.SetValue(result, value)



It kinda makes sense, if you think about it.



All in all, calling explicitly implemented interfaces and

getting/setting properties through interfaces, could be better

documented.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071128/127cbb90/attachment.html>

From dinov at exchange.microsoft.com  Thu Nov 29 01:09:35 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 28 Nov 2007 16:09:35 -0800
Subject: [IronPython] Intefaces
In-Reply-To: <7AD436E4270DD54A94238001769C2227E4539A48F9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <536FA8D75A73B9449931E9C876D2C9B002BD937B@barbwire.esri.com>
	<5583F32168AFAF4D8298CBB3AAB30D24046EA454@livewire.esri.com>
	<7AD436E4270DD54A94238001769C2227E4539A48F9@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A48FD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Oh, now that I read the entire thread I see that that part was known :)  We haven't actually gotten around to documenting this unfortunately.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday, November 28, 2007 4:08 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Intefaces

I don't think there's any great documentation on this, but you can do interface.property.GetValue(instance) or interface.property.SetValue(instance, value).

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jason Pardy
Sent: Wednesday, November 28, 2007 4:02 PM
To: users at lists.ironpython.com
Subject: Re: [IronPython] Intefaces


Has there been any work on documenting the calling of explicitly implemented interfaces and

getting/setting properties through interfaces? If so, is there a location where I can get this information?



Much Thanks,












Jason



2006/10/19, Jason Pardy <jpardy at esri.com<http://lists.ironpython.com/listinfo.cgi/users-ironpython.com>>:

> However, when I try to retrieve the value from a read only property, I get

> an error.

>

> Is this supposed to work?

>

> IGeoProcessorResult.ReturnValue(result)



Yes, but the correct syntax is:



IGeoProcessorResult.ReturnValue.GetValue(result)

IGeoProcessorResult.ReturnValue.SetValue(result, value)



It kinda makes sense, if you think about it.



All in all, calling explicitly implemented interfaces and

getting/setting properties through interfaces, could be better

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

From sanxiyn at gmail.com  Thu Nov 29 01:10:53 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 29 Nov 2007 09:10:53 +0900
Subject: [IronPython] [Bulk] IronPython.sln and .NET 3.5/Visual
	Studio2008
In-Reply-To: <EEDCD954DD4A0D488BBDBDDCC26075441E0B42@meta-exchange.circle-cross.home>
References: <7346A825E148B049A9AD1D3ED46A2D9116C21AD3E8@NA-EXMSG-C106.redmond.corp.microsoft.com>
	<000901c831e4$69c4f880$2101a8c0@Kudu>
	<EEDCD954DD4A0D488BBDBDDCC26075441E0B42@meta-exchange.circle-cross.home>
Message-ID: <5b0248170711281610n3045affejfa9c4e75e40a9b22@mail.gmail.com>

2007/11/29, Keith J. Farmer <kfarmer at thuban.org>:
> The only impediment I can think of would be whether Mono's tools can handle it.  I haven't touched Mono in ages, so I don't know one way or the other.

This is okay, since I use NAnt to build on Mono, not xbuild (Mono's
counterpart to msbuild).

-- 
Seo Sanghyeon


From raymondyee at mashupguide.net  Thu Nov 29 01:46:14 2007
From: raymondyee at mashupguide.net (Raymond Yee)
Date: Wed, 28 Nov 2007 16:46:14 -0800
Subject: [IronPython] problem accessing/import System.IO.Packaging using
	IronPython
Message-ID: <474E0BD6.3050802@mashupguide.net>

I've not been able to figure out how to import Package from 
System.IO.Packaging.  Below is some code to illustrate my problem.   
(I've run this code in  IronPython 2.0A6 and 1.1.  I  have .NET 3.0 
installed.)   Basically,

from System.IO import Packaging

gives me the error

ImportError: Cannot import name Packaging

whereas something like

from System.IO import FileStream, FileMode, FileAccess

works fine.

Part of the issue is that System.IO.Packaging is part of .NET 3.0 but 
not .NET 2.0 -- but I can certainly access other libraries (assemblies?  
I'm new to .NET) -- such as System.Speech -- as show below.    Is the 
problem that there is no System.Speech at all in .NET 2.0 but there is 
already a System.IO in .NET 2.0  -- so IronPython can't pick up the .NET 
3.0 parts of System.IO?  I know that System.IO.Packaging is on my system 
-- I have some C# code that uses it.

Thanks in advance for any help!

-Raymond Yee

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

Here's the code:

# documenting my problem with getting System.IO.Packaging to work in ipy

import clr

# I can't figure out how to load System.IO.Packaging -- which is part of 
.NET 3.0
# 
http://msdn2.microsoft.com/en-us/library/system.io.packaging.package.aspx 
is part of .NET 3.0

try:
  from System.IO import Packaging
  print "success:  from System.IO import Packaging"
except:
  print "error: from System.IO import Packaging"

# 
http://www.ironpython.info/index.php/SHA1Managed_from_System.Security.Cryptography
# shows that we can access System.IO.{FileStream, FileMode, FileAccess}

from System.IO import FileStream, FileMode, FileAccess
print "success:  from System.IO import FileStream, FileMode, FileAccess"

# I can get at other assemblies that are .NET 3.0
# e.g., 
http://msdn2.microsoft.com/en-us/library/system.speech.synthesis.aspx

try:
  clr.AddReference('System.Speech')
  from System.Speech.Synthesis import SpeechSynthesizer
  print "success: adding System.Speech"
except:
  print "error:  adding System.Speech"

 
# print out why System.IO doesn't contain Packaging

import System
print "dir(System.IO): \n" , dir(System.IO), "\n"

# print out the references that are available

print "clr.References:"
for r in clr.References:
  print r
 
# Is the problem that there is no System.Speech at all in .NET 2.0 but 
there is already a System.IO in .NET 2.0 -- so
# IronPython can't pick up the .NET 3.0 parts of System.IO?
 
-----------------

Here's the output I get:

error: from System.IO import Packaging
success:  from System.IO import FileStream, FileMode, FileAccess
success: adding System.Speech
dir(System.IO):
['BinaryReader', 'BinaryWriter', 'BufferedStream', 'Compression', 
'Directory', 'DirectoryInfo', 'DirectoryNotFoundException', 'DriveInfo', 
'DriveNotFoundException', 'DriveType', 'EndOfStreamException', 
'ErrorEventArgs', 'ErrorEventHandler', 'File', 'FileAccess', 
'FileAttributes', 'FileInfo', 'FileLoadException', 'FileMode', 
'FileNotFoundException', 'FileOptions', 'FileShare', 'FileStream', 
'FileSystemEventArgs', 'FileSystemEventHandler', 'FileSystemInfo', 
'FileSystemWatcher', 'IODescriptionAttribute', 'IOException', 
'InternalBufferOverflowException', 'InvalidDataException', 
'IsolatedStorage', 'MemoryStream', 'NotifyFilters', 'Path', 
'PathTooLongException', 'Ports', 'RenamedEventArgs', 
'RenamedEventHandler', 'SearchOption', 'SeekOrigin', 'Stream', 
'StreamReader', 'StreamWriter', 'StringReader', 'StringWriter', 
'TextReader', 'TextWriter', 'UnmanagedMemoryStream', 
'WaitForChangedResult', 'WatcherChangeTypes']

clr.References:
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Speech, Version=3.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35



From dinov at exchange.microsoft.com  Thu Nov 29 01:53:40 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 28 Nov 2007 16:53:40 -0800
Subject: [IronPython] problem accessing/import System.IO.Packaging
	using	IronPython
In-Reply-To: <474E0BD6.3050802@mashupguide.net>
References: <474E0BD6.3050802@mashupguide.net>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A4922@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

System.IO.Packaging is in WindowsBase.dll so you need to add a reference to that DLL:

import clr
clr.AddReference('WindowsBase')
from System.IO import Packaging
print dir(Packaging)
['CertificateEmbeddingOption', 'CompressionOption', 'EncryptedPackageEnvelope', 'EncryptionOption', 'InvalidSignatureEventHandler', 'PackUriHelper', 'Package',
'PackageDigitalSignature', 'PackageDigitalSignatureManager', 'PackagePart', 'PackagePartCollection', 'PackageProperties', 'PackageRelationship', 'PackageRelatio
nshipCollection', 'PackageRelationshipSelector', 'PackageRelationshipSelectorType', 'RightsManagementInformation', 'SignatureVerificationEventArgs', 'StorageInf
o', 'StreamInfo', 'TargetMode', 'VerifyResult', 'ZipPackage', 'ZipPackagePart']

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Raymond Yee
Sent: Wednesday, November 28, 2007 4:46 PM
To: users at lists.ironpython.com
Subject: [IronPython] problem accessing/import System.IO.Packaging using IronPython

I've not been able to figure out how to import Package from
System.IO.Packaging.  Below is some code to illustrate my problem.
(I've run this code in  IronPython 2.0A6 and 1.1.  I  have .NET 3.0
installed.)   Basically,

from System.IO import Packaging

gives me the error

ImportError: Cannot import name Packaging

whereas something like

from System.IO import FileStream, FileMode, FileAccess

works fine.

Part of the issue is that System.IO.Packaging is part of .NET 3.0 but
not .NET 2.0 -- but I can certainly access other libraries (assemblies?
I'm new to .NET) -- such as System.Speech -- as show below.    Is the
problem that there is no System.Speech at all in .NET 2.0 but there is
already a System.IO in .NET 2.0  -- so IronPython can't pick up the .NET
3.0 parts of System.IO?  I know that System.IO.Packaging is on my system
-- I have some C# code that uses it.

Thanks in advance for any help!

-Raymond Yee

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

Here's the code:

# documenting my problem with getting System.IO.Packaging to work in ipy

import clr

# I can't figure out how to load System.IO.Packaging -- which is part of
.NET 3.0
#
http://msdn2.microsoft.com/en-us/library/system.io.packaging.package.aspx
is part of .NET 3.0

try:
  from System.IO import Packaging
  print "success:  from System.IO import Packaging"
except:
  print "error: from System.IO import Packaging"

#
http://www.ironpython.info/index.php/SHA1Managed_from_System.Security.Cryptography
# shows that we can access System.IO.{FileStream, FileMode, FileAccess}

from System.IO import FileStream, FileMode, FileAccess
print "success:  from System.IO import FileStream, FileMode, FileAccess"

# I can get at other assemblies that are .NET 3.0
# e.g.,
http://msdn2.microsoft.com/en-us/library/system.speech.synthesis.aspx

try:
  clr.AddReference('System.Speech')
  from System.Speech.Synthesis import SpeechSynthesizer
  print "success: adding System.Speech"
except:
  print "error:  adding System.Speech"


# print out why System.IO doesn't contain Packaging

import System
print "dir(System.IO): \n" , dir(System.IO), "\n"

# print out the references that are available

print "clr.References:"
for r in clr.References:
  print r

# Is the problem that there is no System.Speech at all in .NET 2.0 but
there is already a System.IO in .NET 2.0 -- so
# IronPython can't pick up the .NET 3.0 parts of System.IO?

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

Here's the output I get:

error: from System.IO import Packaging
success:  from System.IO import FileStream, FileMode, FileAccess
success: adding System.Speech
dir(System.IO):
['BinaryReader', 'BinaryWriter', 'BufferedStream', 'Compression',
'Directory', 'DirectoryInfo', 'DirectoryNotFoundException', 'DriveInfo',
'DriveNotFoundException', 'DriveType', 'EndOfStreamException',
'ErrorEventArgs', 'ErrorEventHandler', 'File', 'FileAccess',
'FileAttributes', 'FileInfo', 'FileLoadException', 'FileMode',
'FileNotFoundException', 'FileOptions', 'FileShare', 'FileStream',
'FileSystemEventArgs', 'FileSystemEventHandler', 'FileSystemInfo',
'FileSystemWatcher', 'IODescriptionAttribute', 'IOException',
'InternalBufferOverflowException', 'InvalidDataException',
'IsolatedStorage', 'MemoryStream', 'NotifyFilters', 'Path',
'PathTooLongException', 'Ports', 'RenamedEventArgs',
'RenamedEventHandler', 'SearchOption', 'SeekOrigin', 'Stream',
'StreamReader', 'StreamWriter', 'StringReader', 'StringWriter',
'TextReader', 'TextWriter', 'UnmanagedMemoryStream',
'WaitForChangedResult', 'WatcherChangeTypes']

clr.References:
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Speech, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35

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


From sanxiyn at gmail.com  Thu Nov 29 01:58:03 2007
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 29 Nov 2007 09:58:03 +0900
Subject: [IronPython] problem accessing/import System.IO.Packaging using
	IronPython
In-Reply-To: <474E0BD6.3050802@mashupguide.net>
References: <474E0BD6.3050802@mashupguide.net>
Message-ID: <5b0248170711281658l77d6bbfek96cc093827634298@mail.gmail.com>

2007/11/29, Raymond Yee <raymondyee at mashupguide.net>:
> # I can't figure out how to load System.IO.Packaging -- which is part of
> .NET 3.0
> #
> http://msdn2.microsoft.com/en-us/library/system.io.packaging.package.aspx
> is part of .NET 3.0

The MSDN page you linked says:

Package Class
Namespace: System.IO.Packaging
Assembly: WindowsBase

This should work:

import clr
clr.AddReference('WindowsBase')
from System.IO.Packaging import Package

So, when you read MSDN, pay attention to which assembly the class is from.

-- 
Seo Sanghyeon


From jdhardy at gmail.com  Thu Nov 29 02:56:01 2007
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 28 Nov 2007 18:56:01 -0700
Subject: [IronPython] Issues with Silly Module Tricks
In-Reply-To: <7AD436E4270DD54A94238001769C2227E4539A47FD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
References: <ea89d0e50711271940s7d24ce23j6bd44b356d2db48@mail.gmail.com>
	<7AD436E4270DD54A94238001769C2227E4539A47FD@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Message-ID: <ea89d0e50711281756x5315bd3fu9d8f23aa749c3072@mail.gmail.com>

Hi Dino,
Thanks for the gory details. I'll try again in a couple of releases.

-Jeff

On Nov 28, 2007 11:49 AM, Dino Viehland <dinov at exchange.microsoft.com> wrote:
> Thanks for the bug report.  There's actually a few issues here:
>
>        types.ModuleType is actually SystemState (you can see this by doing import clr; clr.GetClrType(types.ModuleType))
>        ScriptModule (the type we use to represent module's currently) is currently sealed, so you can't inherit from it if you were getting the right type
>        We don't support __getattr__ / __getattribute__ on types that implement ICustomMembers (which SystemState does).
>
> If you want the nitty gritty details:
>
> The 1st problem is a long-lived problem where we do type impersonation on the SystemState to make it look like a module.  SystemState then implements ICustomMembers so that arbitrary things can be get/set on it which brings us to the 3rd problem.  Before v2.0 is done I suspect that this is going to change and "sys" will be just a normal module.  ICustomMembers will also be going away and get replaced with operators used for lookup - the operators will actually compose correctly and your __getattr__ should get called.
>
> The 2nd problem is currently a DLR problem.  Currently we have a concept of modules in the DLR but that's going away soon.  When that happens ScriptModule (in the most recent code it's not ScriptScope) will be PythonModule and we'll enable inheritance again.
>
> I've opened bug #14147 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14147) to track the issue until all of this gets fixed but unfortunately it's going to take a little time.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Tuesday, November 27, 2007 7:40 PM
> To: Discussion of IronPython
> Subject: [IronPython] Issues with Silly Module Tricks
>
> Hi,
> The following code is adapted from the Pygments library:
>
> automod_test.py
> import types
>
> class _automodule(types.ModuleType):
>    """Automatically import lexers."""
>
>    def __getattr__(self, name):
>        return "blah"
>
> import sys
> oldmod = sys.modules['automod_test']
> newmod = _automodule('automod_test')
> newmod.__dict__.update(oldmod.__dict__)
> sys.modules['automod_test'] = newmod
> del newmod.newmod, newmod.oldmod, newmod.sys, newmod.types
>
> When run, I get the following results:
> Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import automod_test
> >>> automod_test.blah
> 'blah'
>
> IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.312
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> import automod_test
> >>> automod_test.blah
> Traceback (most recent call last):
>  File , line 0, in ##268
> AttributeError: 'module' object has no attribute 'blah'
>
> I'm not sure whether the issue is with replacing sys.modules, or if it
> is related to the __getattr__ issues that were reported a while back.
> Either way, it prevents Pygments from getting past even the first
> round of tests.
>
> -Jeff
> _______________________________________________
> 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 dave.niesman at ieee.org  Fri Nov 30 03:43:40 2007
From: dave.niesman at ieee.org (Dave Niesman)
Date: Thu, 29 Nov 2007 20:43:40 -0600
Subject: [IronPython] ipy crashes from vs2008 command window
Message-ID: <d0d2bc400711291843n58e34ddwb32cf8998a8aa20a@mail.gmail.com>

Hi,

Can anyone else confirm this behavior?

I can run ipy.exe fine from a command line. However, if I start a
Visual Studio 2008 command window, (this is just %comspec% /k
""C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat""
x86), and then "import os" ipy.exe crashes. Furthermore, all future
invocations of ipy.exe crash until the machine is rebooted! This is
repeatable on my machine.


Environment: .net35, Vista, VS2008 ipy 2.0a6.

Thanks,

Dave


From Sathish.Kaveripakam at phonak.com  Fri Nov 30 15:58:36 2007
From: Sathish.Kaveripakam at phonak.com (Kaveripakam, Sathish)
Date: Fri, 30 Nov 2007 15:58:36 +0100
Subject: [IronPython] Variable sharing between C# and iron python
Message-ID: <FBB055C769471C42BBAE2E206073B8ED07CD4F34@CH01SWC2.corp.ads>

Hi All,
 
I am using C# code and iron python V1.1 version of dll's using Visual
Studio. In this context, I would like to read the value of the variables
manipulated/defined in iron python files in C# and vice versa.
Any example is highly appreciated.
 
Regards

******************** 
Legal Notice: 
The information in this electronic transmission may contain confidential or
legally privileged information and is intended solely for the individual(s)
named above. If you are not an intended recipient or an authorized agent,
you are hereby notified that reading, distributing, or otherwise
disseminating, copying or taking any action based on the contents of this
transmission is strictly prohibited. Any unauthorized interception of this
transmission is illegal under law. If you have received this transmission in
error, please notify the sender by telephone [at the number indicated above/
on +41 58 928 0101] as soon as possible and then destroy all copies of this
transmission. 
********************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071130/1ea590d5/attachment.html>

From dave.niesman at ieee.org  Fri Nov 30 16:22:40 2007
From: dave.niesman at ieee.org (Dave Niesman)
Date: Fri, 30 Nov 2007 09:22:40 -0600
Subject: [IronPython] ipy.exe crashes after attempting import in VS 2008
	command window
Message-ID: <d0d2bc400711300722h7186f0far8971669333729c27@mail.gmail.com>

Hi,

Can anyone else confirm this behavior?

I can run ipy.exe fine from a command line. However, if I start a
Visual Studio 2008 command window, (this is just %comspec% /k
""C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat""
x86), and then "import os" ipy.exe crashes. Furthermore, all future
invocations of ipy.exe crash until the machine is rebooted! This is
repeatable on my machine.


Environment: .net35, Vista, VS2008 ipy 2.0a6.

Thanks,

Dave


From Martin.Maly at microsoft.com  Fri Nov 30 18:20:29 2007
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Fri, 30 Nov 2007 09:20:29 -0800
Subject: [IronPython] Parser is not accessible anymore in IP2A6
In-Reply-To: <OF19378EB2.48DB6C97-ON852573A1.00756A10-852573A1.0077863C@franke.com>
References: <C80B82844D92F64FA5D3B4790737D18DD9346E812C@DF-GRTDANE-MSG.exchange.corp.microsoft.com>
	<OF19378EB2.48DB6C97-ON852573A1.00756A10-852573A1.0077863C@franke.com>
Message-ID: <C80B82844D92F64FA5D3B4790737D18DD9346E893E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Hi David,

This is actually a bug in the DLR code. What is happening, and what made your brain hurt, was the code which creates instructions for DLR how to do a given operation, in this case how to call the CreateParser method. Since it is not a public method, we have to invoke it through reflection. And because it is a static method, the instance must be null. Here's where the problem lies. The null at execution time is expressed via Ast.Null() expression node at code generation time. So to fix this on your machine, you can replace line 156 in MethodTarget.cs which reads:

Expression instance = mi.IsStatic ? null : _instanceBuilder.ToExpression(context, parameters);

With:

Expression instance = mi.IsStatic ? Ast.Null() : _instanceBuilder.ToExpression(context, parameters);

I'll check the fix soon (after due testing) so it should be on codeplex in matter of days and also in the next release.

Thanks for a great repro!

Martin

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of David.Lawler at franke.com
Sent: Wednesday, November 28, 2007 1:46 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Parser is not accessible anymore in IP2A6

> Yes, Parser being internal definitely causes the error. It is a good
> question whether it is a permanent change because there are pros and
> cons going both ways. Let me open a bug on this since it is
> something we need to make decision on. In the meantime, as a
> temporary workaround (emphasizing the temporary workaround) you can
> use -X:PrivateBinding flag with IronPython to get access to the
> internal/private classes.
>
> The bug I opened is here:
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14105
>
> Feel free to vote/comment on it and also keep an eye on it for the
> ultimate resolution.
>
> Thanks for the feedback!
> Martin
>

Well - that SHOULD work - but does not.  If you take the following example
program:

import clr

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

from System.Text import Encoding
import IronPython
import Microsoft.Scripting

path = "PythonParserTest.py"
pe = IronPython.Hosting.PythonEngine.CurrentEngine
enc = Encoding.Default
s = Microsoft.Scripting.Hosting.SourceUnit.CreateFileUnit(pe, path, enc)
c = Microsoft.Scripting.CompilerContext(s)

p = IronPython.Compiler.Parser.CreateParser(c,
IronPython.PythonEngineOptions())

ast = p.ParseFile(True)

print "all done"

save it as PythonParserTest.py and run it you get this:

ipy -X:PrivateBinding -X:ExceptionDetail PythonParserTest.py
Value cannot be null.
Parameter name: expression
   at Microsoft.Scripting.Ast.Ast.ConvertHelper(Expression expression,
Type type
)
   at
Microsoft.Scripting.Generation.MethodTarget.MakeExpression(ActionBinder bi
nder, StandardRule rule, Expression[] parameters)
   at
Microsoft.Scripting.Generation.MethodTarget.MakeExpression(ActionBinder bi
nder, StandardRule rule, Expression[] parameters, Type[] knownTypes)
   at
Microsoft.Scripting.Actions.CallBinderHelper`2.MakeMethodBaseRule(MethodBa
se[] targets)
   at Microsoft.Scripting.Actions.CallBinderHelper`2.MakeRule()
   at IronPython.Runtime.Types.BuiltinFunction.MakeCallRule[T](CallAction
action
, CodeContext context, Object[] args)
   at
IronPython.Runtime.Types.BuiltinFunction.Microsoft.Scripting.IDynamicObjec
t.GetRule[T](DynamicAction action, CodeContext context, Object[] args)
   at
Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeConte
xt callerContext, DynamicAction action, Object[] args, Object site, T&
target, R
uleSet`1& rules)
   at
Microsoft.Scripting.Actions.FastDynamicSite`4.UpdateBindingAndInvoke(T0 ar
g0, T1 arg1, T2 arg2)
   at
Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7
.FastInvoke3(FastDynamicSite`4 site, T0 arg0, T1 arg1, T2 arg2)
   at Microsoft.Scripting.Actions.FastDynamicSite`4.Invoke(T0 arg0, T1
arg1, T2
arg2)
   at __main__$mod_1.Initialize(CodeContext ) in PythonParserTest.py:line
16
   at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean
tryEva
luate)
   at Microsoft.Scripting.ScriptModule.Execute()
   at IronPython.Hosting.PythonCommandLine.RunFileWorker(String fileName)
   at IronPython.Hosting.PythonCommandLine.RunFile(String filename)

if you make your own version of IronPython 2A6 with Parser set to public
rather
than internal, then the above example works.  The problem appears to be in
MethodTarget.cs
around line 150 or so:

                // Private binding, invoke via reflection
                if (mi != null) {
                    Expression instance = mi.IsStatic ? null :
_instanceBuilder.ToExpression(context, parameters);
                    call = Ast.Call(
                        Ast.RuntimeConstant(mi),
                        typeof(MethodInfo).GetMethod("Invoke", new Type[]
{ typeof(object), typeof(object[]) }),
                        Ast.ConvertHelper(instance, typeof(object)),
                        Ast.NewArrayHelper(typeof(object[]), args)
                    );
                } else {
                    call = Ast.Call(
                        Ast.RuntimeConstant((ConstructorInfo)Method),
                        typeof(ConstructorInfo).GetMethod("Invoke", new
Type[] { typeof(object[]) }),
                        Ast.NewArrayHelper(typeof(object[]), args)
                    );
                }

where it seems that the 'invoke via reflection for private bindings' has
issues in
Ast.ConvertHelper.  However, as I tried to understand the problem further
I developed
an enormous brain cramp.  I am so happy that I mostly write business
software and not compilers!
This is not of huge importance to me but I would think that you would want
to solve this
for the poor souls out there who are (or will be) trying to produce
editors/IDEs or other
tools for IronPython (think Intellisense and/or code completion).

Regards,

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


From dinov at exchange.microsoft.com  Fri Nov 30 18:41:34 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 30 Nov 2007 09:41:34 -0800
Subject: [IronPython] ipy.exe crashes after attempting import in VS
	2008	command window
In-Reply-To: <d0d2bc400711300722h7186f0far8971669333729c27@mail.gmail.com>
References: <d0d2bc400711300722h7186f0far8971669333729c27@mail.gmail.com>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A4C19@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

This seems to work fine for me (same config apparently unless you're on 64-bit Vista - Vista, VS2008 RTM, .NET 3.5).  Do you get an exception outputted or do you just get the Watson UI saying an application has crashed?

One option might be to run under cordbg to see what the problem is, e.g.: cordbg .\ipy.exe -c "import os"

If you can let us know what exception it seems to be crashing on then it'll help us repro it or fix it :).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Niesman
Sent: Friday, November 30, 2007 7:23 AM
To: Iron Python Mailing List
Subject: [IronPython] ipy.exe crashes after attempting import in VS 2008 command window

Hi,

Can anyone else confirm this behavior?

I can run ipy.exe fine from a command line. However, if I start a
Visual Studio 2008 command window, (this is just %comspec% /k
""C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat""
x86), and then "import os" ipy.exe crashes. Furthermore, all future
invocations of ipy.exe crash until the machine is rebooted! This is
repeatable on my machine.


Environment: .net35, Vista, VS2008 ipy 2.0a6.

Thanks,

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


From rdawson at exchange.microsoft.com  Fri Nov 30 18:42:38 2007
From: rdawson at exchange.microsoft.com (Ryan Dawson)
Date: Fri, 30 Nov 2007 09:42:38 -0800
Subject: [IronPython] Variable sharing between C# and iron python
In-Reply-To: <FBB055C769471C42BBAE2E206073B8ED07CD4F34@CH01SWC2.corp.ads>
References: <FBB055C769471C42BBAE2E206073B8ED07CD4F34@CH01SWC2.corp.ads>
Message-ID: <50B69702CA6E6D4E849D30CD4989AB8EC8C74131EC@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

Here is a blog post I wrote recently covering this topic: http://blogs.msdn.com/rdawson/archive/2007/11/28/hosting-ironpython-1-1.aspx.

Let me know if you have further questions.
                -Ryan



From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam, Sathish
Sent: Friday, November 30, 2007 6:59 AM
To: users at lists.ironpython.com
Subject: [IronPython] Variable sharing between C# and iron python

Hi All,

I am using C# code and iron python V1.1 version of dll's using Visual Studio. In this context, I would like to read the value of the variables manipulated/defined in iron python files in C# and vice versa.
Any example is highly appreciated.

Regards
________________________________
Legal Notice:
The information in this electronic transmission may contain confidential or legally privileged information and is intended solely for the individual(s) named above. If you are not an intended recipient or an authorized agent, you are hereby notified that reading, distributing, or otherwise disseminating, copying or taking any action based on the contents of this transmission is strictly prohibited. Any unauthorized interception of this transmission is illegal under law. If you have received this transmission in error, please notify the sender by telephone [at the number indicated above/on +41 58 928 0101] as soon as possible and then destroy all copies of this transmission.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071130/628bfe95/attachment.html>

From dinov at exchange.microsoft.com  Fri Nov 30 18:48:01 2007
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 30 Nov 2007 09:48:01 -0800
Subject: [IronPython] Variable sharing between C# and iron python
In-Reply-To: <FBB055C769471C42BBAE2E206073B8ED07CD4F34@CH01SWC2.corp.ads>
References: <FBB055C769471C42BBAE2E206073B8ED07CD4F34@CH01SWC2.corp.ads>
Message-ID: <7AD436E4270DD54A94238001769C2227E4539A4C20@DF-GRTDANE-MSG.exchange.corp.microsoft.com>

There's two ways to do this: One is to expose a static (or even an instance) class to Python code which your C# code accesses, the other is to access the EngineModule and pull variables out that Python code has set.

The first can be done by:

PythonEngine pe = new PythonEngine();
EngineModule em = pe.CreateModule();

DynamicType dt = Ops.GetDynamicTypeFromType(typeof(MyType));
em.Globals["Foo"] = dt;

now Python code executed in this module can do Foo.Xyz = 3 and so on...  Or using an instance class:

em.Globals["Foo"] = new MyDataPasser();

The other way is to set/get from Globals directly:

em.Globals["SomeValue"] = 23;
pe.ExecuteFile("C:\\foo.py", em);
Console.WriteLine(em.Globals["SomeValue"]);



From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kaveripakam, Sathish
Sent: Friday, November 30, 2007 6:59 AM
To: users at lists.ironpython.com
Subject: [IronPython] Variable sharing between C# and iron python

Hi All,

I am using C# code and iron python V1.1 version of dll's using Visual Studio. In this context, I would like to read the value of the variables manipulated/defined in iron python files in C# and vice versa.
Any example is highly appreciated.

Regards
________________________________
Legal Notice:
The information in this electronic transmission may contain confidential or legally privileged information and is intended solely for the individual(s) named above. If you are not an intended recipient or an authorized agent, you are hereby notified that reading, distributing, or otherwise disseminating, copying or taking any action based on the contents of this transmission is strictly prohibited. Any unauthorized interception of this transmission is illegal under law. If you have received this transmission in error, please notify the sender by telephone [at the number indicated above/on +41 58 928 0101] as soon as possible and then destroy all copies of this transmission.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071130/7cf0e503/attachment.html>