From sanxiyn at gmail.com  Wed Jul  1 10:33:52 2009
From: sanxiyn at gmail.com (Seo Sanghyeon)
Date: Wed, 1 Jul 2009 17:33:52 +0900
Subject: [IronPython] Bazaar on IronPython
In-Reply-To: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
References: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
Message-ID: <5b0248170907010133k2e1a2c5axc1189ab2dcdcbdd6@mail.gmail.com>

2009/6/30 Martin (gzlist) <gzlist at googlemail.com>:
> For anyone who is interested, I have done a little work getting the
> DVCS bazaar working on IronPython 2.0 and 2.6 - please see this
> message and attached patch:
> <https://lists.canonical.com/archives/bazaar/2009q2/060028.html>

You seem to use xmllib to get ElementTree working. If you need
pyexpat for IronPython, you can use my implementation:

http://fepy.svn.sourceforge.net/svnroot/fepy/trunk/lib/pyexpat.py

Just drop it in sys.path.

-- 
Seo Sanghyeon


From itssivaguru at gmail.com  Wed Jul  1 16:31:14 2009
From: itssivaguru at gmail.com (Sivaguru Perambalam)
Date: Wed, 1 Jul 2009 10:31:14 -0400
Subject: [IronPython] How to capture a 'Carriage Return' in a windows form ?
Message-ID: <12604cb0907010731t4761778fj610350d11bf546b8@mail.gmail.com>

Hello ,

I have a Windows form with a text box and a button.
What I want to implement it, when the user hits the 'Enter' key in the text
box, the function that's linked to the ButtonClick event has to be invoked.
Please give me like a code example of how this could be done in a simpler
way, since I am not familiar with Forms or GUI stuff .

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

From brian.curtin at gmail.com  Wed Jul  1 16:41:52 2009
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 1 Jul 2009 09:41:52 -0500
Subject: [IronPython] How to capture a 'Carriage Return' in a windows
	form ?
In-Reply-To: <12604cb0907010731t4761778fj610350d11bf546b8@mail.gmail.com>
References: <12604cb0907010731t4761778fj610350d11bf546b8@mail.gmail.com>
Message-ID: <cf9f31f20907010741u77bd36f2m30aa58cf894d72e8@mail.gmail.com>

On Wed, Jul 1, 2009 at 09:31, Sivaguru Perambalam <itssivaguru at gmail.com>wrote:

> Hello ,
>
> I have a Windows form with a text box and a button.
> What I want to implement it, when the user hits the 'Enter' key in the text
> box, the function that's linked to the ButtonClick event has to be invoked.
> Please give me like a code example of how this could be done in a simpler
> way, since I am not familiar with Forms or GUI stuff .
>
> Thanks !
>

You could check out the OnKeyDown event:
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.onkeydown(loband).aspx.
The C# example pretty easily translates to IronPython, so you could follow
that and check when the KeyEventArgs.KeyCode is equal to Keys.Return, then
call your ButtonClick method.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090701/9dd16f01/attachment.html>

From merllab at microsoft.com  Wed Jul  1 17:52:51 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Wed, 1 Jul 2009 08:52:51 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <70b2ab55-f9c2-42a1-8919-aed785f891c4@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/55800.

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/IronPythonConsole/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/IronPython/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/ExtensionAssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/IronPythonWindow/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs





From brannon at iterator.net  Wed Jul  1 19:08:31 2009
From: brannon at iterator.net (Brannon Jones)
Date: Wed, 1 Jul 2009 10:08:31 -0700
Subject: [IronPython] How to capture a 'Carriage Return' in a windows
	form ?
In-Reply-To: <cf9f31f20907010741u77bd36f2m30aa58cf894d72e8@mail.gmail.com>
References: <12604cb0907010731t4761778fj610350d11bf546b8@mail.gmail.com>
	<cf9f31f20907010741u77bd36f2m30aa58cf894d72e8@mail.gmail.com>
Message-ID: <1653092d0907011008o5b36b88ej2f7ee2762afc9fd4@mail.gmail.com>

Set the AcceptsReturn property on the TextBox:
http://msdn.microsoft.com/en-us/library/system.windows.forms.textbox.acceptsreturn.aspx

<http://msdn.microsoft.com/en-us/library/system.windows.forms.textbox.acceptsreturn.aspx>You'll
also need to set the AcceptButton property on the Form:
http://msdn.microsoft.com/en-us/library/system.windows.forms.form.acceptbutton.aspx

<http://msdn.microsoft.com/en-us/library/system.windows.forms.form.acceptbutton.aspx>
Brannon

On Wed, Jul 1, 2009 at 07:41, Brian Curtin <brian.curtin at gmail.com> wrote:

> On Wed, Jul 1, 2009 at 09:31, Sivaguru Perambalam <itssivaguru at gmail.com>wrote:
>
>> Hello ,
>>
>> I have a Windows form with a text box and a button.
>> What I want to implement it, when the user hits the 'Enter' key in the
>> text box, the function that's linked to the ButtonClick event has to be
>> invoked.
>> Please give me like a code example of how this could be done in a simpler
>> way, since I am not familiar with Forms or GUI stuff .
>>
>> Thanks !
>>
>
> You could check out the OnKeyDown event:
> http://msdn.microsoft.com/en-us/library/system.windows.forms.control.onkeydown(loband).aspx.
> The C# example pretty easily translates to IronPython, so you could follow
> that and check when the KeyEventArgs.KeyCode is equal to Keys.Return, then
> call your ButtonClick method.
>
> _______________________________________________
> 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/20090701/92bacfdf/attachment.html>

From gzlist at googlemail.com  Thu Jul  2 19:27:59 2009
From: gzlist at googlemail.com (Martin (gzlist))
Date: Thu, 2 Jul 2009 18:27:59 +0100
Subject: [IronPython] Bazaar on IronPython
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD033E93DD@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD033E93DD@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <d80792120907021027k3b03bf8ate50971fe836b3925@mail.gmail.com>

On 30/06/2009, Dino Viehland <dinov at microsoft.com> wrote:
> Good work, it's very cool to see this - if you see an existing bug or
> open a new please make sure to mention that it effects Bazaar and we'll
> treat it with a higher priority.  In general that goes for any large
> body of existing Python code.

Okay, I've written testcases for each of the changes I needed to make
to get Bazaar to run that were due to IronPython bugs. Have just had a
quick look at the IronPython source online and could submit patches
for a few of the issues.

However I don't see any information on the site about how you want
fixes provided, and messages likes this:
<http://lists.ironpython.com/pipermail/users-ironpython.com/2009-April/010114.html>
seem to imply that not only can you not take submissions, but you
can't even look at them? Perhaps an entry in the faq addressing this
would make things clearer.

Don't want to make your lives harder, so for the moment will just say
what and where:

* Even non re.RE_Pattern objects shouldn't confuse warnings filtering
(Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)

* Require the zlib module [workitem:2590] (other missing or broken
modules not as crucial)

* Making sys._getframe equal to None by default in 2.6 beta 1 lead to
a happier logging module but a sadder doctest module.

* The third argument to file should work as a keyword as well as
positionally [workitem:23347]

* The abspath function should not throw even for invalid windows
paths. Or, if it's going to throw, it shouldn't spell 'pecified'
without the 'S'. Fixed post-2.6 beta 1 by the workaround in
nt._getfullpathname? (going by the code in
IronPython_Main/Src/IronPython.Modules/nt.cs)

* Removing a read-only file should raise an error with errno set to
EACCES [workitem:23348] also related to [workitem:13702]

* Removing a open file should raise an error with errno set to EACCES
[workitem:23349] also related to [workitem:13702]

* A buffer object should be directly writable to a cStringIO object
[workitem:23350]

* Opening an existing file with the O_CREAT should succeed
[workitem:19310] (problem at FileModeFromFlags in
IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
Likewise, the O_TRUNC flag is not being correctly combined in there.

* The mbcs codec for decoding windows 'ansi' strings should exist
[workitem:23351]

Martin


From gzlist at googlemail.com  Thu Jul  2 19:28:32 2009
From: gzlist at googlemail.com (Martin (gzlist))
Date: Thu, 2 Jul 2009 18:28:32 +0100
Subject: [IronPython] Bazaar on IronPython
In-Reply-To: <5b0248170907010133k2e1a2c5axc1189ab2dcdcbdd6@mail.gmail.com>
References: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
	<5b0248170907010133k2e1a2c5axc1189ab2dcdcbdd6@mail.gmail.com>
Message-ID: <d80792120907021028u5c58deb7h2f2a9d91cb9b8776@mail.gmail.com>

On 01/07/2009, Seo Sanghyeon <sanxiyn at gmail.com> wrote:
>
> You seem to use xmllib to get ElementTree working. If you need
> pyexpat for IronPython, you can use my implementation:

Yes, and I'm aware of Jeff's subprocess module as well. Was just
trying to keep the number of extra things someone needed to download
to try out the patch to a minimum. That said, I do wonder if
implementing the ElementTree with System.Xml makes more sense than
emulating expat, bzr complains about speed unless cElementTree is
installed for instance.

Martin


From dinov at microsoft.com  Thu Jul  2 20:00:39 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 2 Jul 2009 18:00:39 +0000
Subject: [IronPython] Bazaar on IronPython
In-Reply-To: <d80792120907021027k3b03bf8ate50971fe836b3925@mail.gmail.com>
References: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD033E93DD@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<d80792120907021027k3b03bf8ate50971fe836b3925@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0340529A@TK5EX14MBXC116.redmond.corp.microsoft.com>

Martin wrote:

> However I don't see any information on the site about how you want
> fixes provided, and messages likes this:
> <http://lists.ironpython.com/pipermail/users-ironpython.com/2009-
> April/010114.html>
> seem to imply that not only can you not take submissions, but you
> can't even look at them? Perhaps an entry in the faq addressing this
> would make things clearer.

Yeah, unfortunately we can't accept changes back.  :(  Adding an entry
to the FAQ on this sounds like a good idea.  In the mean time good bug
reports like this are a tremendous help.

> Don't want to make your lives harder, so for the moment will just say
> what and where:
>
> * Even non re.RE_Pattern objects shouldn't confuse warnings filtering
> (Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)

Are you just saying that we have a bug in our re implementation which is
breaking warning filtering?

>
> * Require the zlib module [workitem:2590] (other missing or broken
> modules not as crucial)

Hopefully Jeff Hardy's zlib fills the gap here as we don't have any
immediate plans to implement this (the underlying .NET implementation
simply isn't sufficient to build upon).

>
> * Making sys._getframe equal to None by default in 2.6 beta 1 lead to
> a happier logging module but a sadder doctest module.

Yeah, we actually want to patch the std lib for handling _getframe more
consistently.  We're working w/ our lawyers to make sure we can submit
the changes back to CPython though.

>
> * The third argument to file should work as a keyword as well as
> positionally [workitem:23347]
>
> * The abspath function should not throw even for invalid windows
> paths. Or, if it's going to throw, it shouldn't spell 'pecified'
> without the 'S'. Fixed post-2.6 beta 1 by the workaround in
> nt._getfullpathname? (going by the code in
> IronPython_Main/Src/IronPython.Modules/nt.cs)
>
> * Removing a read-only file should raise an error with errno set to
> EACCES [workitem:23348] also related to [workitem:13702]
>
> * Removing a open file should raise an error with errno set to EACCES
> [workitem:23349] also related to [workitem:13702]
>
> * A buffer object should be directly writable to a cStringIO object
> [workitem:23350]
>
> * Opening an existing file with the O_CREAT should succeed
> [workitem:19310] (problem at FileModeFromFlags in
> IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
> analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
> Likewise, the O_TRUNC flag is not being correctly combined in there.

These should all be simple to fix - 19310 is the only one that has me
a little bit worried but hopefully it's not the issue I'm thinking of.
I'll probably dig into these early next week.

> * The mbcs codec for decoding windows 'ansi' strings should exist
> [workitem:23351]

I recently got started on some mbcs support so maybe this will be the
reason to finish that off.


From gzlist at googlemail.com  Thu Jul  2 21:25:58 2009
From: gzlist at googlemail.com (Martin (gzlist))
Date: Thu, 2 Jul 2009 20:25:58 +0100
Subject: [IronPython] Bazaar on IronPython
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0340529A@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD033E93DD@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<d80792120907021027k3b03bf8ate50971fe836b3925@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0340529A@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <d80792120907021225xc3736e0l4e8fa249878905d6@mail.gmail.com>

On 02/07/2009, Dino Viehland <dinov at microsoft.com> wrote:
>
>> * Even non re.RE_Pattern objects shouldn't confuse warnings filtering
>> (Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)
>
> Are you just saying that we have a bug in our re implementation which is
> breaking warning filtering?

No, it's far more obscure than that. Bazaar replaces re.compile with a
function that returns objects that behave like pattern objects but are
really wrappers. It's not exactly a common use case I think you should
be rushing to support. :)

>> * Making sys._getframe equal to None by default in 2.6 beta 1 lead to
>> a happier logging module but a sadder doctest module.
>
> Yeah, we actually want to patch the std lib for handling _getframe more
> consistently.  We're working w/ our lawyers to make sure we can submit
> the changes back to CPython though.

That sounds like the most sensible option by far.

>> * Opening an existing file with the O_CREAT should succeed
>> [workitem:19310] (problem at FileModeFromFlags in
>> IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
>> analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
>> Likewise, the O_TRUNC flag is not being correctly combined in there.

Whoops, OPEN_ALWAYS is actually OpenOrCreate in dot net speak.

> These should all be simple to fix - 19310 is the only one that has me
> a little bit worried but hopefully it's not the issue I'm thinking of.
> I'll probably dig into these early next week.

It may not be possible to get perfect emulation of the C way of
opening files with System.IO but fixing the flags looks right on the
surface.

Thanks for looking over all these little issues.

Martin


From dinov at microsoft.com  Fri Jul  3 01:45:39 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 2 Jul 2009 23:45:39 +0000
Subject: [IronPython] Exception for setting attributes of built-in type
In-Reply-To: <5b0248170906141209y4398defanacfd0bb62504e550@mail.gmail.com>
References: <5b0248170906141209y4398defanacfd0bb62504e550@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD034067D5@TK5EX14MBXC116.redmond.corp.microsoft.com>

Seo wrote:
> Exception for setting attributes of built-in type differs between
> CPython and IronPython. This is not purely theoretical, as
> zope.interface tries to set Implements declaration as __implemented__
> attribute of built-in type object, and excepts TypeError.
>
> Python 2.6.1
> >>> object.flag = True
> TypeError: can't set attributes of built-in/extension type 'object'
>
> IronPython 2.6
> >>> object.flag = True
> AttributeError: 'object' object has no attribute 'flag'
>
> I was surprised that CPython raises TypeError. Library Reference seems
> to mention it here:
>
> exception AttributeError
> Raised when an attribute reference or assignment fails. (When an
> object does not support attribute references or attribute assignments
> at all, TypeError is raised.)
> http://docs.python.org/library/exceptions.html
>
> What does it mean that "an object does not support attribute
> references or attribute assignments at all"?

Even though Guido said we didn't have to match it I've updated IronPython
so that we'll throw the same exception now.  The change will be in
tomorrow's source push to CodePlex.  We've matched specific exceptions
in the past and this one is at least documented :)


From merllab at microsoft.com  Fri Jul  3 17:52:52 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Fri, 3 Jul 2009 08:52:52 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <b5152ddc-a56b-41e0-b687-a76cc5f5fb53@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/55895.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ConversionResultKind.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/MemberRequestKind.cs

DELETED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ConvertToBinderHelper.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/GetMemberBinderHelper.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DeleteMemberBinderHelper.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/MemberBinderHelper.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/BinderHelper.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/Old
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/SetMemberBinderHelper.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ConversionResultKind.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/MemberRequestKind.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_codecs.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonOverloadResolver.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.Operations.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/Calls/OverloadResolver.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.Invoke.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.DeleteMember.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/CollectionExtensions.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.GetMember.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ActionBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.Conversions.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.SetMember.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Lib/iptest/process_util.py
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonGetMemberBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaPythonType.Members.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/NewTypeMaker.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/NameConverter.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonCompilerOptions.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/TypeInfo.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/IntOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/FloatOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/EnumOps.cs
	$/IronPython/IronPython_Main/Src/Tests/interop/net/type/test_clrtype.py
	$/IronPython/IronPython_Main/Src/Tests/interop/com/apps/excel.py
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/LanguageContext.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Generation/CompilerHelpers.cs
	$/IronPython/IronPython_Main/Src/Tests/interop/net/property/test_property.py
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/LongOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Builtin.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Importer.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/re.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/nt.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Tokenizer.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Parser.cs
	$/IronPython/IronPython_Main/Src/Tests/test_nt.py
	$/IronPython/IronPython_Main/Src/Tests/test_help.py
	$/IronPython/IronPython_Main/Src/Tests/test_function.py
	$/IronPython/IronPython_Main/Src/Tests/test_file.py
	$/IronPython/IronPython_Main/Src/Tests/test_codecs.py
	$/IronPython/IronPython_Main/Src/Tests/test_cliclass.py
	$/IronPython/IronPython_Main/Src/Tests/test_class.py
	$/IronPython/IronPython_Main/Src/Tests/test_builtinfunc.py
	$/IronPython/IronPython_Main/Src/Tests/test_threadsafety.py
	$/IronPython/IronPython_Main/Src/Tests/test_superconsole.py
	$/IronPython/IronPython_Main/Src/Tests/test_re.py
	$/IronPython/IronPython_Main/Src/Tests/test_property.py
	$/IronPython/IronPython_Main/Src/Tests/versions/python26.py
	$/IronPython/IronPython_Main/Tutorial/Tutorial.htm

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 974318
Date: 7/2/2009 4:34:21 PM

(dfugate) Extended __clrtype__ metaclass tests some more.


(Shelveset: CLRTYPE2;REDMOND\dfugate | SNAP CheckinId: 8842)
--------------------------------------------------------------------------------
Changeset Id: 974212
Date: 7/2/2009 3:33:38 PM

(dinov) 20174    1              Medium               TypeError: Scope is not callable
                Just removing an unnecessary set of the module back onto the importing module.
18614    1              Medium               Some COM errors in Ipy 2 beta 5               
                Issue appears to be fixed, we have a test for DisplayAlerts, adding test for dir()
20377    1              Medium               Tab Completion does not work with Office 2007 Primary Interop Assemblies
                Issue appears to be fixed (probably w/ the recent dir cleanup), adding test.
22131    1              Medium               PythonType.AddSystemInterfaces - COM Interop Issues ??
                We need to handle adding when interface mapping returns a null target method.  There?s several different spots we need to handle this at.  Added an IL-only test case to verify this scenario is working.
21361    1              Medium               Cannot write bytes to files
22302    1              Medium               help() on a CLR string[] fails with a stack trace
22966    1              Medium               Problem with re module/groupindex property, incompatibility with CPython
                Add filtering for the special named groups we have to insert.
23143 bin(n > System.Int32.MaxValue) broken
                We?re going through our helpers for string formatting which don?t add the ? before the value and don?t expect negative values in general.  Assert we have positive values, make the helpers which can?t handle negatives private, and define internal APIs w/ a simple signature which does it all.
3740       0              Medium               Trivial: Overloaded properties (indexers) not handled by IronPython      IronPython\2.6                 
                This works via the same get_ method that C# supports.  Adding test case to verify it keeps working.




(Shelveset: StillMoreBugs;REDMOND\dinov | SNAP CheckinId: 8840)
--------------------------------------------------------------------------------
Changeset Id: 973686
Date: 7/2/2009 10:43:08 AM

(dinov) 3730: Trivial: Add DLLs directory in the default path 
                Following Dave?s proposal in the bug to always add this
19521: 2.6: implement from __future__ import unicode_literals (PEP 3112)
                Switching to use the Unicode literal parser after this is done
19089: Implement __repr__ for enums 
                Implement an improved repr when we have an exact value
20295    1              Medium               property.__doc__ = None throws bad exception             
                Handle the null instance
20250    1              Medium               Bad exception when splatted args are None       
                Throw TypeError instead of dereferencing the null pointer
19063    1              Medium               max(tuple, none) -> nullpointer exception
                Already fixed, adding test case
22734    1              Medium               nt.system('"...') should work
                Shouldn?t throw on the imbalanced quotes instead we should imply the end quote
8202       1              Low        Trivial: gc.get_debug() returns the wrong value IronPython\2.6                 
                Return an int instead of null
15546    1              Low        codecs.charmap_encode throws TypeError for a dictionary with string values
18926    1              Low        random module is not thread safe
                Fixed, adding test case
23251 - type.__clrtype__ shouldn't exist unless the clr or System modules have been imported 
                Mark as PythonHidden, remove filtering of PythonHidden methods (in NameConverter) when defining base helper overloads 
23244 - clrtype__ implementations returning None should throw a TypeError 
                Throw ValueError if you return null

Also:
deleting all of the OldDynamicAction stuff ? this also implies updating the default binder so that we no longer flow OldDynamicAction?s in and instead now flow a MemberRequestKind enum instead.
Fixing the exception thrown when ...


(Shelveset: BugsAndRemoveOldBinders;REDMOND\dinov | SNAP CheckinId: 8835)


From narinder.claire at googlemail.com  Sat Jul  4 13:03:23 2009
From: narinder.claire at googlemail.com (Narinder Claire)
Date: Sat, 04 Jul 2009 12:03:23 +0100
Subject: [IronPython]  Python scripting on Excel spreadsheet
Message-ID: <4A4F36FB.7050308@googlemail.com>


We have been able to embed the the IronPython interpreter into an Excel 
xll addin allowing one to write Python functions straight onto a Excel 
spreadsheet which can then be used to evaluate the values of  cells.

This embedding is demonstrated in one of the 'Extra Examples' shipped 
with the free and open source software xlw.

xlw ( v4 ) can be downloaded from here :
    
http://sourceforge.net/project/showfiles.php?group_id=45222&package_id=37893&release_id=690866


The example was created as a demo of IronPython on a spreadsheet and is 
intended to be extended by the user for his/her own needs.

If anyone would like to extend the example to be more 'sexier' and 
contribute the result to xlw for shipping with next release ( 4.0.0 ) 
that would be great.





From m_tayseer82 at yahoo.com  Tue Jul  7 11:11:10 2009
From: m_tayseer82 at yahoo.com (Mohammad Tayseer)
Date: Tue, 7 Jul 2009 02:11:10 -0700 (PDT)
Subject: [IronPython] Running SPSS application from IronPython
In-Reply-To: <dfa476260906291100g4be9db74gc3f2623283f91f04@mail.gmail.com>
References: <dfa476260906290905u137d482fx5c6aec9b8733c0c5@mail.gmail.com>
	<4A7B019E-69F5-4E07-A7CA-ED9579E24C86@voidspace.org.uk>
	<dfa476260906291022j5bf5c049kdad4de7bf1d6a69c@mail.gmail.com>
	<cf9f31f20906291040u2dbb0defoe7ec5a2179d759a3@mail.gmail.com>
	<dfa476260906291100g4be9db74gc3f2623283f91f04@mail.gmail.com>
Message-ID: <722828.44645.qm@web31104.mail.mud.yahoo.com>

It depends how the spss module itself is implemented, e.g. if it's a Python module it can be imported easily, but if it's a C module you can write a wrapper around it using ctypes.

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





________________________________
From: Sarah Abdel Razak <sabdelrazak at symbyo.com>
To: Discussion of IronPython <users at lists.ironpython.com>
Sent: Monday, June 29, 2009 9:00:06 PM
Subject: Re: [IronPython] Running SPSS application from IronPython


No spss module is not  a C-extension , I believe that part of it is implemented using java.
At the begining of my module I add the following lines :

import sys

sys.path.extend([
    r'c:\Python25\Lib',
    r'c:\Python25\Lib\site-packages',
    ]) 

sys.path.append(r'c:\Python25\Lib') 
sys.path.append(r'C:\Python25\Lib\site-packages')

import spss      ----> this line that throws the exception.
I'm running the module from IronPython Studio.
  
Regards
-- 
Sarah Abdelrazak




On Mon, Jun 29, 2009 at 10:40 AM, Brian Curtin <brian.curtin at gmail.com> wrote:

On Mon, Jun 29, 2009 at 12:22, Sarah Abdel Razak <sabdelrazak at symbyo.com> wrote:
>
>Thanks for your reply I just knew that spss Python plugin has to be built for specific Python implementations.
>> Unfortunately it does not support IronPython.
>>
>>Regards
>>-- 
>>>>
>>Sarah Abdelrazak
>
>Even though they don't support it, it will probably still work. Is this SPSS module a C-extension or does it involve C-extensions? Have you tried what Michael suggested? 
>
>_______________________________________________
>>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/20090707/04581c93/attachment.html>

From merllab at microsoft.com  Tue Jul  7 17:53:02 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Tue, 7 Jul 2009 08:53:02 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <ecf677e8-394e-46d1-8d8f-278ac674143a@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56115.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonTracebackListener.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/GeneratorRewriter.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonFunction.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/Python.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaOldInstance.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/BindingHelpers.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaPythonFunction.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonProtocol.Operations.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonProtocol.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaMethod.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/ConditionalBuilder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/FunctionCode.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonFunction.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/FunctionAttributes.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Method.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonCallTargets.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/PythonExceptions.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/YieldExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/TraceBack.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Builtin.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/socket.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/gc.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WhileStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/TryStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonTracebackListener.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/DebugContext.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/DebugContext.GeneratorLoopProc.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/DebuggableLambdaBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/DebugInfoRewriter.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/RuntimeOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/sys.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldInstance.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ReturnStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/NameExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/IfStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ForStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstGenerator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Parser.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/TraceEventKind.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/TracePipeline/TracePipeline.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightCompiler.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/GeneratorRewriter.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/Instruction.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Generation/ToDiskRewriter.cs
	$/IronPython/IronPython_Main/Src/Scripts/run_interactive.py
	$/IronPython/IronPython_Main/Src/Scripts/generate_calls.py
	$/IronPython/IronPython_Main/Src/Tests/test_superconsole.py
	$/IronPython/IronPython_Main/Src/Tests/test_memory.py
	$/IronPython/IronPython_Main/Src/Tests/test_function.py
	$/IronPython/IronPython_Main/Src/Tests/test_class.py
	$/IronPython/IronPython_Main/Src/Tests/test_sys.py
	$/IronPython/IronPython_Main/Tutorial/Tutorial.htm

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 977090
Date: 7/6/2009 4:54:14 PM

(dinov) Adds sys.settrace/sys.gettrace/sys.call_tracing support.  Also adds support via the extension methods for the hosting APIs.  Enables test_trace.py with a few exceptions where we differ (due to GC, and testing some pretty extreme implementation details of CPython).

This is a pretty big change.  It alters our function implementation so that we can replace function implementations at runtime.  It updates recursion enforcement to also use this new mechanism fixing the fact that recursion enforcement currently bleeds across runtimes.  It also nearly finalizes fixing the relationship between function and function code objects so that we match CPython as we now load the delegate from the function code instead of the function.  It also means we no longer need our ?FunctionInfo? class which was basically serving the same purpose.  Another benefit is we no longer create a new function code object each time a function is created.  Finally we also get func_code.co_freevars and exec on a closure code is now disallowed like CPython.

Here?s how this works.  We now maintain a global weak list of all function code objects in the system.  Whenever we compile a function we create a new function code object and register it in this global list.  When sys.settrace/sys.setrecursionlimit are called we walk the global list and fix all of the function code delegates.  If we?re switching recursion on this is just simply wrapping the existing delegate in a recursion enforcement delegate.  This means we no longer need to check the EnforceRecursion static field when recursion isn?t enforced.  If we?re flipping on sys.settrace then we switch to the debuggable lambda ? we don?t actually initially do this as it?s a slow process instead we just switch back to the lazy delegate until the functions are called the 1st time.  Then they?ll get compiled in the debuggable form.

There?s also a bunch of tweaks to our parsing and code gen so that we match CPython when tracing is enabled.  This includes having the ending ...



(Shelveset: SysSetTraceFinal2;REDMOND\dinov | SNAP CheckinId: 8847)


From simon.segal at bigpond.com  Wed Jul  8 15:54:10 2009
From: simon.segal at bigpond.com (Simon Segal)
Date: Wed, 8 Jul 2009 23:54:10 +1000
Subject: [IronPython]  Running SPSS application from IronPython
Message-ID: <00c001c9ffd3$92073ce0$b615b6a0$@segal@bigpond.com>

Is the thread that starts from this post still the best way to facilitate
implementing tab completion and new line functionality in your own console? 

 


Regards,

	

Simon Segal


Email:

simon.segal at bigpond.com <mailto:simon.segal at internode.on.net> 


Web Site:

http://www.simonsegal.net

		

 

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

From simon.segal at bigpond.com  Wed Jul  8 15:57:47 2009
From: simon.segal at bigpond.com (Simon Segal)
Date: Wed, 8 Jul 2009 23:57:47 +1000
Subject: [IronPython]  - Custom interactive console
Message-ID: <00cb01c9ffd4$132a03c0$397e0b40$@segal@bigpond.com>

Sorry ignore my previous message it was a incorrectly given the wrong
subject.

 

My question: Is the thread that starts from this post still the best way to
facilitate implementing tab completion and new line functionality in your
own console? 

 

http://www.mail-archive.com/users at lists.ironpython.com/msg08846.html

 


Regards,

	

Simon Segal

	
	
		

Email:

 <mailto:simon.segal at internode.on.net> simon.segal at bigpond.com


Web Site:

 <http://www.simonsegal.net> http://www.simonsegal.net

		

 

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

From bruce.bromberek at gmail.com  Wed Jul  8 17:45:47 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Wed, 8 Jul 2009 10:45:47 -0500
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
Message-ID: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>

I'm stuck.

I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy console
screen )app that I have created and successfully run multiple machines under
my control.

I've given the compiled app to other users.  Half of the time it runs great,
the other half it dies right away with a System.MissingMethodException
:Method not found
void.system.reflection.emit.dynamicmethod..ctor(....)  error message.  When
I googled that string I read a post that reminded me that Ironpython
requires .Net2.0 SP1.

I had the affected users upgrade their installs to .NET framework 3.5  and
the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
Wikipedia)

The die at launch is still occuring.

Can anyone point in the right direction to solve this problem and/or tell me
what is causing it.  In case it helps, I have listed the imports I'm using
in the script in addition to standard 5 ironpython assemblies/dll

import clr
clr.AddReference('mscorlib')
clr.AddReference('System')
clr.AddReference('System.Data')
clr.AddReference('System.Windows.Forms')
clr.AddReference('System.Drawing')

import sys
import System
import System.Data
from System.IO import Directory, Path, File
from System import DateTime
from System.Windows.Forms import DialogResult, OpenFileDialog
from System.Drawing import Size
from System.Windows.Forms import Button, DockStyle, Panel, Form,
FormBorderStyle, Padding, TextBox
import time



Bruce Bromberek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090708/457e5fee/attachment.html>

From curt at hagenlocher.org  Wed Jul  8 17:55:31 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 8 Jul 2009 08:55:31 -0700
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
Message-ID: <d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>

When you run ipy.exe on these machines it starts up successfully, but when
you start your app you get the MissingMethodException for that DynamicMethod
constructor?
On Wed, Jul 8, 2009 at 8:45 AM, Bruce Bromberek
<bruce.bromberek at gmail.com>wrote:

> I'm stuck.
>
> I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy console
> screen )app that I have created and successfully run multiple machines under
> my control.
>
> I've given the compiled app to other users.  Half of the time it runs
> great, the other half it dies right away with a
> System.MissingMethodException :Method not found
> void.system.reflection.emit.dynamicmethod..ctor(....)  error message.  When
> I googled that string I read a post that reminded me that Ironpython
> requires .Net2.0 SP1.
>
> I had the affected users upgrade their installs to .NET framework 3.5  and
> the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
> Wikipedia)
>
> The die at launch is still occuring.
>
> Can anyone point in the right direction to solve this problem and/or tell
> me what is causing it.  In case it helps, I have listed the imports I'm
> using in the script in addition to standard 5 ironpython assemblies/dll
>
> import clr
> clr.AddReference('mscorlib')
> clr.AddReference('System')
> clr.AddReference('System.Data')
> clr.AddReference('System.Windows.Forms')
> clr.AddReference('System.Drawing')
>
> import sys
> import System
> import System.Data
> from System.IO import Directory, Path, File
> from System import DateTime
> from System.Windows.Forms import DialogResult, OpenFileDialog
> from System.Drawing import Size
> from System.Windows.Forms import Button, DockStyle, Panel, Form,
> FormBorderStyle, Padding, TextBox
> import time
>
>
>
> Bruce Bromberek
>
> _______________________________________________
> 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/20090708/96373e13/attachment.html>

From bruce.bromberek at gmail.com  Wed Jul  8 17:57:59 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Wed, 8 Jul 2009 10:57:59 -0500
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
	<d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
Message-ID: <58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>

I do not have IronPython installed.  I'm just distributing the compiled app
and dlls in the folder.  Script compiled using SharpDevelop 3.1

On Wed, Jul 8, 2009 at 10:55 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> When you run ipy.exe on these machines it starts up successfully, but when
> you start your app you get the MissingMethodException for that DynamicMethod
> constructor?
> On Wed, Jul 8, 2009 at 8:45 AM, Bruce Bromberek <bruce.bromberek at gmail.com
> > wrote:
>
>> I'm stuck.
>>
>> I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy
>> console screen )app that I have created and successfully run multiple
>> machines under my control.
>>
>> I've given the compiled app to other users.  Half of the time it runs
>> great, the other half it dies right away with a
>> System.MissingMethodException :Method not found
>> void.system.reflection.emit.dynamicmethod..ctor(....)  error message.
>> When I googled that string I read a post that reminded me that Ironpython
>> requires .Net2.0 SP1.
>>
>> I had the affected users upgrade their installs to .NET framework 3.5  and
>> the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
>> Wikipedia)
>>
>> The die at launch is still occuring.
>>
>> Can anyone point in the right direction to solve this problem and/or tell
>> me what is causing it.  In case it helps, I have listed the imports I'm
>> using in the script in addition to standard 5 ironpython assemblies/dll
>>
>> import clr
>> clr.AddReference('mscorlib')
>> clr.AddReference('System')
>> clr.AddReference('System.Data')
>> clr.AddReference('System.Windows.Forms')
>> clr.AddReference('System.Drawing')
>>
>> import sys
>> import System
>> import System.Data
>> from System.IO import Directory, Path, File
>> from System import DateTime
>> from System.Windows.Forms import DialogResult, OpenFileDialog
>> from System.Drawing import Size
>> from System.Windows.Forms import Button, DockStyle, Panel, Form,
>> FormBorderStyle, Padding, TextBox
>> import time
>>
>>
>>
>> Bruce Bromberek
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090708/e2a3d15d/attachment.html>

From curt at hagenlocher.org  Wed Jul  8 18:10:15 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 8 Jul 2009 09:10:15 -0700
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
	<d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
	<58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>
Message-ID: <d2155e360907080910o6b781cbp2707d9271bf5564c@mail.gmail.com>

How have you confirmed that they successfully installed SP1? One easy way is
to give them ipy.exe to put into the same folder and have them try to run
it.

On Wed, Jul 8, 2009 at 8:57 AM, Bruce Bromberek
<bruce.bromberek at gmail.com>wrote:

> I do not have IronPython installed.  I'm just distributing the compiled app
> and dlls in the folder.  Script compiled using SharpDevelop 3.1
>
>
> On Wed, Jul 8, 2009 at 10:55 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>
>> When you run ipy.exe on these machines it starts up successfully, but when
>> you start your app you get the MissingMethodException for that DynamicMethod
>> constructor?
>> On Wed, Jul 8, 2009 at 8:45 AM, Bruce Bromberek <
>> bruce.bromberek at gmail.com> wrote:
>>
>>> I'm stuck.
>>>
>>> I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy
>>> console screen )app that I have created and successfully run multiple
>>> machines under my control.
>>>
>>> I've given the compiled app to other users.  Half of the time it runs
>>> great, the other half it dies right away with a
>>> System.MissingMethodException :Method not found
>>> void.system.reflection.emit.dynamicmethod..ctor(....)  error message.
>>> When I googled that string I read a post that reminded me that Ironpython
>>> requires .Net2.0 SP1.
>>>
>>> I had the affected users upgrade their installs to .NET framework 3.5
>>> and the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
>>> Wikipedia)
>>>
>>> The die at launch is still occuring.
>>>
>>> Can anyone point in the right direction to solve this problem and/or tell
>>> me what is causing it.  In case it helps, I have listed the imports I'm
>>> using in the script in addition to standard 5 ironpython assemblies/dll
>>>
>>> import clr
>>> clr.AddReference('mscorlib')
>>> clr.AddReference('System')
>>> clr.AddReference('System.Data')
>>> clr.AddReference('System.Windows.Forms')
>>> clr.AddReference('System.Drawing')
>>>
>>> import sys
>>> import System
>>> import System.Data
>>> from System.IO import Directory, Path, File
>>> from System import DateTime
>>> from System.Windows.Forms import DialogResult, OpenFileDialog
>>> from System.Drawing import Size
>>> from System.Windows.Forms import Button, DockStyle, Panel, Form,
>>> FormBorderStyle, Padding, TextBox
>>> import time
>>>
>>>
>>>
>>> Bruce Bromberek
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090708/c40bb43a/attachment.html>

From dinov at microsoft.com  Wed Jul  8 19:09:42 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 8 Jul 2009 17:09:42 +0000
Subject: [IronPython] - Custom interactive console
In-Reply-To: <00cb01c9ffd4$132a03c0$397e0b40$@segal@bigpond.com>
References: <00cb01c9ffd4$132a03c0$397e0b40$@segal@bigpond.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0343ED20@TK5EX14MBXC116.redmond.corp.microsoft.com>

That's the best way to do this stuff via the hosting APIs.

For the 2.6 builds of the 2 bugs in that mail at least 1 of them has been fixed (22064) and it looks like 21881 has also been fixed - or at least we don't get the null object ref exception that we used to get.  I'm not sure if the InteractiveInterpreter might fall down somewhere else though.  So you might also be able to do it via pure Python code if you'd like.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Segal
Sent: Wednesday, July 08, 2009 6:58 AM
To: 'Discussion of IronPython'
Subject: [IronPython] - Custom interactive console

Sorry ignore my previous message it was a incorrectly given the wrong subject.

My question: Is the thread that starts from this post still the best way to facilitate implementing tab completion and new line functionality in your own console?

http://www.mail-archive.com/users at lists.ironpython.com/msg08846.html

Regards,


Simon Segal




Email:

simon.segal at bigpond.com<mailto:simon.segal at internode.on.net>

Web Site:

http://www.simonsegal.net



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

From bruce.bromberek at gmail.com  Wed Jul  8 21:07:29 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Wed, 8 Jul 2009 14:07:29 -0500
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <d2155e360907080910o6b781cbp2707d9271bf5564c@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
	<d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
	<58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>
	<d2155e360907080910o6b781cbp2707d9271bf5564c@mail.gmail.com>
Message-ID: <58ad4a110907081207m2c1d2005p6b33fb250dc4ab61@mail.gmail.com>

I sent them ipy.exe and it generated the same error.

I wonder, does ipy really require SP2 for .NET20.  That is the only
difference I see between my install (.NET 3.5 SP1, .NET 2.0 SP2) and their
install (.NET 3.5, .NET 2.0 SP1)?

Bruce

On Wed, Jul 8, 2009 at 11:10 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> How have you confirmed that they successfully installed SP1? One easy way
> is to give them ipy.exe to put into the same folder and have them try to run
> it.
>
>
> On Wed, Jul 8, 2009 at 8:57 AM, Bruce Bromberek <bruce.bromberek at gmail.com
> > wrote:
>
>> I do not have IronPython installed.  I'm just distributing the compiled
>> app and dlls in the folder.  Script compiled using SharpDevelop 3.1
>>
>>
>> On Wed, Jul 8, 2009 at 10:55 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>>
>>> When you run ipy.exe on these machines it starts up successfully, but
>>> when you start your app you get the MissingMethodException for that
>>> DynamicMethod constructor?
>>> On Wed, Jul 8, 2009 at 8:45 AM, Bruce Bromberek <
>>> bruce.bromberek at gmail.com> wrote:
>>>
>>>> I'm stuck.
>>>>
>>>> I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy
>>>> console screen )app that I have created and successfully run multiple
>>>> machines under my control.
>>>>
>>>> I've given the compiled app to other users.  Half of the time it runs
>>>> great, the other half it dies right away with a
>>>> System.MissingMethodException :Method not found
>>>> void.system.reflection.emit.dynamicmethod..ctor(....)  error message.
>>>> When I googled that string I read a post that reminded me that Ironpython
>>>> requires .Net2.0 SP1.
>>>>
>>>> I had the affected users upgrade their installs to .NET framework 3.5
>>>> and the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
>>>> Wikipedia)
>>>>
>>>> The die at launch is still occuring.
>>>>
>>>> Can anyone point in the right direction to solve this problem and/or
>>>> tell me what is causing it.  In case it helps, I have listed the imports I'm
>>>> using in the script in addition to standard 5 ironpython assemblies/dll
>>>>
>>>> import clr
>>>> clr.AddReference('mscorlib')
>>>> clr.AddReference('System')
>>>> clr.AddReference('System.Data')
>>>> clr.AddReference('System.Windows.Forms')
>>>> clr.AddReference('System.Drawing')
>>>>
>>>> import sys
>>>> import System
>>>> import System.Data
>>>> from System.IO import Directory, Path, File
>>>> from System import DateTime
>>>> from System.Windows.Forms import DialogResult, OpenFileDialog
>>>> from System.Drawing import Size
>>>> from System.Windows.Forms import Button, DockStyle, Panel, Form,
>>>> FormBorderStyle, Padding, TextBox
>>>> import time
>>>>
>>>>
>>>>
>>>> Bruce Bromberek
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090708/5392970a/attachment.html>

From bruce.bromberek at gmail.com  Thu Jul  9 00:03:19 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Wed, 8 Jul 2009 17:03:19 -0500
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <58ad4a110907081207m2c1d2005p6b33fb250dc4ab61@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
	<d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
	<58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>
	<d2155e360907080910o6b781cbp2707d9271bf5564c@mail.gmail.com>
	<58ad4a110907081207m2c1d2005p6b33fb250dc4ab61@mail.gmail.com>
Message-ID: <58ad4a110907081503s5f4d1229y141609540c07b03a@mail.gmail.com>

Problem resolved?

It appears that my users had copied the files to a network drive and were
running from there instead of from their PC.  Everything is working now with
.NET2.0 SP1 and the files located on their C drive.  Weird that file
location would have an effect.

Thanks for your help Curt.

Bruce

On Wed, Jul 8, 2009 at 2:07 PM, Bruce Bromberek
<bruce.bromberek at gmail.com>wrote:

> I sent them ipy.exe and it generated the same error.
>
> I wonder, does ipy really require SP2 for .NET20.  That is the only
> difference I see between my install (.NET 3.5 SP1, .NET 2.0 SP2) and their
> install (.NET 3.5, .NET 2.0 SP1)?
>
> Bruce
>
>
> On Wed, Jul 8, 2009 at 11:10 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>
>> How have you confirmed that they successfully installed SP1? One easy way
>> is to give them ipy.exe to put into the same folder and have them try to run
>> it.
>>
>>
>> On Wed, Jul 8, 2009 at 8:57 AM, Bruce Bromberek <
>> bruce.bromberek at gmail.com> wrote:
>>
>>> I do not have IronPython installed.  I'm just distributing the compiled
>>> app and dlls in the folder.  Script compiled using SharpDevelop 3.1
>>>
>>>
>>> On Wed, Jul 8, 2009 at 10:55 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>>>
>>>> When you run ipy.exe on these machines it starts up successfully, but
>>>> when you start your app you get the MissingMethodException for that
>>>> DynamicMethod constructor?
>>>> On Wed, Jul 8, 2009 at 8:45 AM, Bruce Bromberek <
>>>> bruce.bromberek at gmail.com> wrote:
>>>>
>>>>> I'm stuck.
>>>>>
>>>>> I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy
>>>>> console screen )app that I have created and successfully run multiple
>>>>> machines under my control.
>>>>>
>>>>> I've given the compiled app to other users.  Half of the time it runs
>>>>> great, the other half it dies right away with a
>>>>> System.MissingMethodException :Method not found
>>>>> void.system.reflection.emit.dynamicmethod..ctor(....)  error message.
>>>>> When I googled that string I read a post that reminded me that Ironpython
>>>>> requires .Net2.0 SP1.
>>>>>
>>>>> I had the affected users upgrade their installs to .NET framework 3.5
>>>>> and the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
>>>>> Wikipedia)
>>>>>
>>>>> The die at launch is still occuring.
>>>>>
>>>>> Can anyone point in the right direction to solve this problem and/or
>>>>> tell me what is causing it.  In case it helps, I have listed the imports I'm
>>>>> using in the script in addition to standard 5 ironpython assemblies/dll
>>>>>
>>>>> import clr
>>>>> clr.AddReference('mscorlib')
>>>>> clr.AddReference('System')
>>>>> clr.AddReference('System.Data')
>>>>> clr.AddReference('System.Windows.Forms')
>>>>> clr.AddReference('System.Drawing')
>>>>>
>>>>> import sys
>>>>> import System
>>>>> import System.Data
>>>>> from System.IO import Directory, Path, File
>>>>> from System import DateTime
>>>>> from System.Windows.Forms import DialogResult, OpenFileDialog
>>>>> from System.Drawing import Size
>>>>> from System.Windows.Forms import Button, DockStyle, Panel, Form,
>>>>> FormBorderStyle, Padding, TextBox
>>>>> import time
>>>>>
>>>>>
>>>>>
>>>>> Bruce Bromberek
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.ironpython.com
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090708/dd7d3f3d/attachment.html>

From curt at hagenlocher.org  Thu Jul  9 00:40:24 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 8 Jul 2009 15:40:24 -0700
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <58ad4a110907081503s5f4d1229y141609540c07b03a@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
	<d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
	<58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>
	<d2155e360907080910o6b781cbp2707d9271bf5564c@mail.gmail.com>
	<58ad4a110907081207m2c1d2005p6b33fb250dc4ab61@mail.gmail.com>
	<58ad4a110907081503s5f4d1229y141609540c07b03a@mail.gmail.com>
Message-ID: <d2155e360907081540u7c36608ei196b91ee3cd9164d@mail.gmail.com>

Very strange. Well, I'm glad it's working now!

On Wed, Jul 8, 2009 at 3:03 PM, Bruce Bromberek
<bruce.bromberek at gmail.com>wrote:

> Problem resolved?
>
> It appears that my users had copied the files to a network drive and were
> running from there instead of from their PC.  Everything is working now with
> .NET2.0 SP1 and the files located on their C drive.  Weird that file
> location would have an effect.
>
> Thanks for your help Curt.
>
> Bruce
>
>
> On Wed, Jul 8, 2009 at 2:07 PM, Bruce Bromberek <bruce.bromberek at gmail.com
> > wrote:
>
>> I sent them ipy.exe and it generated the same error.
>>
>> I wonder, does ipy really require SP2 for .NET20.  That is the only
>> difference I see between my install (.NET 3.5 SP1, .NET 2.0 SP2) and their
>> install (.NET 3.5, .NET 2.0 SP1)?
>>
>> Bruce
>>
>>
>> On Wed, Jul 8, 2009 at 11:10 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>>
>>> How have you confirmed that they successfully installed SP1? One easy way
>>> is to give them ipy.exe to put into the same folder and have them try to run
>>> it.
>>>
>>>
>>> On Wed, Jul 8, 2009 at 8:57 AM, Bruce Bromberek <
>>> bruce.bromberek at gmail.com> wrote:
>>>
>>>> I do not have IronPython installed.  I'm just distributing the compiled
>>>> app and dlls in the folder.  Script compiled using SharpDevelop 3.1
>>>>
>>>>
>>>> On Wed, Jul 8, 2009 at 10:55 AM, Curt Hagenlocher <curt at hagenlocher.org
>>>> > wrote:
>>>>
>>>>> When you run ipy.exe on these machines it starts up successfully, but
>>>>> when you start your app you get the MissingMethodException for that
>>>>> DynamicMethod constructor?
>>>>> On Wed, Jul 8, 2009 at 8:45 AM, Bruce Bromberek <
>>>>> bruce.bromberek at gmail.com> wrote:
>>>>>
>>>>>> I'm stuck.
>>>>>>
>>>>>> I have an Ironpython (2.0.0.0  .NET 2.0.50727.3082 according to ipy
>>>>>> console screen )app that I have created and successfully run multiple
>>>>>> machines under my control.
>>>>>>
>>>>>> I've given the compiled app to other users.  Half of the time it runs
>>>>>> great, the other half it dies right away with a
>>>>>> System.MissingMethodException :Method not found
>>>>>> void.system.reflection.emit.dynamicmethod..ctor(....)  error message.
>>>>>> When I googled that string I read a post that reminded me that Ironpython
>>>>>> requires .Net2.0 SP1.
>>>>>>
>>>>>> I had the affected users upgrade their installs to .NET framework 3.5
>>>>>> and the .NET 2.0 version is 2.0.50727.1433  (SP1 according to a table in
>>>>>> Wikipedia)
>>>>>>
>>>>>> The die at launch is still occuring.
>>>>>>
>>>>>> Can anyone point in the right direction to solve this problem and/or
>>>>>> tell me what is causing it.  In case it helps, I have listed the imports I'm
>>>>>> using in the script in addition to standard 5 ironpython assemblies/dll
>>>>>>
>>>>>> import clr
>>>>>> clr.AddReference('mscorlib')
>>>>>> clr.AddReference('System')
>>>>>> clr.AddReference('System.Data')
>>>>>> clr.AddReference('System.Windows.Forms')
>>>>>> clr.AddReference('System.Drawing')
>>>>>>
>>>>>> import sys
>>>>>> import System
>>>>>> import System.Data
>>>>>> from System.IO import Directory, Path, File
>>>>>> from System import DateTime
>>>>>> from System.Windows.Forms import DialogResult, OpenFileDialog
>>>>>> from System.Drawing import Size
>>>>>> from System.Windows.Forms import Button, DockStyle, Panel, Form,
>>>>>> FormBorderStyle, Padding, TextBox
>>>>>> import time
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bruce Bromberek
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.ironpython.com
>>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.ironpython.com
>>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.ironpython.com
>>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090708/82201be3/attachment.html>

From jdhardy at gmail.com  Thu Jul  9 16:12:40 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 9 Jul 2009 08:12:40 -0600
Subject: [IronPython] Problem Running Compiled Ironpython APP .NET Issue
In-Reply-To: <58ad4a110907081503s5f4d1229y141609540c07b03a@mail.gmail.com>
References: <58ad4a110907080845t5721fdb4x24e9e0e3fdbf7f8b@mail.gmail.com>
	<d2155e360907080855i7ffcd084t4b0610c36d373874@mail.gmail.com>
	<58ad4a110907080857y3fef7880j2fcc2c46c6e7acd4@mail.gmail.com>
	<d2155e360907080910o6b781cbp2707d9271bf5564c@mail.gmail.com>
	<58ad4a110907081207m2c1d2005p6b33fb250dc4ab61@mail.gmail.com>
	<58ad4a110907081503s5f4d1229y141609540c07b03a@mail.gmail.com>
Message-ID: <ea89d0e50907090712i381af75bmae28d7622213a7c5@mail.gmail.com>

On Wed, Jul 8, 2009 at 4:03 PM, Bruce
Bromberek<bruce.bromberek at gmail.com> wrote:
> Problem resolved?
>
> It appears that my users had copied the files to a network drive and were
> running from there instead of from their PC.? Everything is working now with
> .NET2.0 SP1 and the files located on their C drive.? Weird that file
> location would have an effect.

By default in 2.0 (IIRC) files running from a network share are run in
partial trust instead of full trust.

 - Jeff


From merllab at microsoft.com  Thu Jul  9 17:52:55 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Thu, 9 Jul 2009 08:52:55 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <ea7aef58-a2fd-4489-a757-8ef921685663@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56232.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/IronPythonTest/ClrType.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPythonTest/ClrType.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComRuntimeHelpers.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComEventSinkProxy.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/BoundDispEvent.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComEventSink.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/DispCallableMetaObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Errors.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComEventSinksContainer.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Lib/iptest/assert_util.py
	$/IronPython/IronPython_Main/Src/IronPythonTest/IronPythonTest.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LabelInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/DebugInfoGenerator.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/ILGen.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/Expression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Variant.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/IDispatchComObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/SymbolDocumentGenerator.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/ExceptionFactory.Generated.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/OffsetTrackingILGenerator.cs
	$/IronPython/IronPython_Main/Src/Scripts/generate_comdispatch.py
	$/IronPython/IronPython_Main/Src/Tests/interop/net/type/test_clrtype.py

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 981035
Date: 7/8/2009 1:05:06 PM

(dfugate) More clrtype verification:
- added missing verification to test_sanity_static_dot_net_type.  Looks like this is actually broken - see http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23426
- added test case which returns types implemented in C# as the return value of __clrtype__
- added test case where the type has multiple constructor overloads with each accepting a PythonType as the first param.  This doesn't seem to work - see  http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23419
- added test case for types providing a parameterless constructor
- added test case to ensure garbage types (e.g., those having no constructors accepting a PythonType) can't be used with __clrtype__.  Filed http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23418



(Shelveset: CLRTYPE3;REDMOND\dfugate | SNAP CheckinId: m9639)
--------------------------------------------------------------------------------
Changeset Id: 981030
Date: 7/8/2009 1:03:12 PM

(dfugate) - MS.Scripting.Debugging.dll wasn't being GAC'ed in the stress lab.  Fixed
- quite a few tests in the stress lab were failing because iptest.assert_util.load_iron_python_dll doesn't check the GAC for IronPython.dll.  Fixed


(Shelveset: STRESS01;REDMOND\dfugate | SNAP CheckinId: m9639)





From itssivaguru at gmail.com  Thu Jul  9 22:32:08 2009
From: itssivaguru at gmail.com (Summer_Intern)
Date: Thu, 9 Jul 2009 13:32:08 -0700 (PDT)
Subject: [IronPython] How to capture a 'Carriage Return' in a windows
 form ?
In-Reply-To: <cf9f31f20907010741u77bd36f2m30aa58cf894d72e8@mail.gmail.com>
References: <12604cb0907010731t4761778fj610350d11bf546b8@mail.gmail.com>
	<cf9f31f20907010741u77bd36f2m30aa58cf894d72e8@mail.gmail.com>
Message-ID: <24417356.post@talk.nabble.com>


Hello,

Thanks for the Suggestion . I set the 'AcceptsReturn = True' for the
textbox.
But the problem I found is that its not able to recognize the 'Enter'key
press .

Here is the Code :

	def OnKeyPress(self,sender,args):
		print (args.KeyChar)
		if(args.KeyChar == Keys.Return):
			print 'Enter Key Pressed'

1) I tried args.KeyCode . It returned an exception
2) I tried if(args.KeyChar == Keys. Enter) , the if condition is not passing
when I press the Enter Key . Where as a new line is printed on the console.
3) Same behavior when I have if(args.KeyChar == Keys.Return):

I think its not able to understand the enum 'Keys'.
I also tried doing 'from System.Windows.Forms import Keys'. but still no
good .

Any idea whats missing or incorrect ?

Thanks !

briancurtin wrote:
> 
> On Wed, Jul 1, 2009 at 09:31, Sivaguru Perambalam
> <itssivaguru at gmail.com>wrote:
> 
>> Hello ,
>>
>> I have a Windows form with a text box and a button.
>> What I want to implement it, when the user hits the 'Enter' key in the
>> text
>> box, the function that's linked to the ButtonClick event has to be
>> invoked.
>> Please give me like a code example of how this could be done in a simpler
>> way, since I am not familiar with Forms or GUI stuff .
>>
>> Thanks !
>>
> 
> You could check out the OnKeyDown event:
> http://msdn.microsoft.com/en-us/library/system.windows.forms.control.onkeydown(loband).aspx.
> The C# example pretty easily translates to IronPython, so you could follow
> that and check when the KeyEventArgs.KeyCode is equal to Keys.Return, then
> call your ButtonClick method.
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 

-- 
View this message in context: http://www.nabble.com/How-to-capture-a-%27Carriage-Return%27-in-a-windows-form---tp24290861p24417356.html
Sent from the IronPython mailing list archive at Nabble.com.



From curt at hagenlocher.org  Fri Jul 10 01:00:18 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 9 Jul 2009 16:00:18 -0700
Subject: [IronPython] How to capture a 'Carriage Return' in a windows
	form ?
In-Reply-To: <24417356.post@talk.nabble.com>
References: <12604cb0907010731t4761778fj610350d11bf546b8@mail.gmail.com>
	<cf9f31f20907010741u77bd36f2m30aa58cf894d72e8@mail.gmail.com>
	<24417356.post@talk.nabble.com>
Message-ID: <d2155e360907091600p3ee65041j896483e26228b929@mail.gmail.com>

It sounds like you're hooking the KeyPress event instead of the KeyDown
event. That's why you get a KeyChar instead of a KeyCode and it also might
be why the code isn't working as you expect.

I can get the Keys enumeration just fine:
IronPython 2.6 Beta 1 DEBUG (2.6.0.10) on .NET 2.0.50727.3053
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference('System.Windows.Forms')
>>> from System.Windows.Forms import Keys
>>> Keys.Enter
<System.Windows.Forms.Keys object at 0x000000000000002B [Return]>
>>>



On Thu, Jul 9, 2009 at 1:32 PM, Summer_Intern <itssivaguru at gmail.com> wrote:

>
> Hello,
>
> Thanks for the Suggestion . I set the 'AcceptsReturn = True' for the
> textbox.
> But the problem I found is that its not able to recognize the 'Enter'key
> press .
>
> Here is the Code :
>
>        def OnKeyPress(self,sender,args):
>                print (args.KeyChar)
>                if(args.KeyChar == Keys.Return):
>                        print 'Enter Key Pressed'
>
> 1) I tried args.KeyCode . It returned an exception
> 2) I tried if(args.KeyChar == Keys. Enter) , the if condition is not
> passing
> when I press the Enter Key . Where as a new line is printed on the console.
> 3) Same behavior when I have if(args.KeyChar == Keys.Return):
>
> I think its not able to understand the enum 'Keys'.
> I also tried doing 'from System.Windows.Forms import Keys'. but still no
> good .
>
> Any idea whats missing or incorrect ?
>
> Thanks !
>
> briancurtin wrote:
> >
> > On Wed, Jul 1, 2009 at 09:31, Sivaguru Perambalam
> > <itssivaguru at gmail.com>wrote:
> >
> >> Hello ,
> >>
> >> I have a Windows form with a text box and a button.
> >> What I want to implement it, when the user hits the 'Enter' key in the
> >> text
> >> box, the function that's linked to the ButtonClick event has to be
> >> invoked.
> >> Please give me like a code example of how this could be done in a
> simpler
> >> way, since I am not familiar with Forms or GUI stuff .
> >>
> >> Thanks !
> >>
> >
> > You could check out the OnKeyDown event:
> >
> http://msdn.microsoft.com/en-us/library/system.windows.forms.control.onkeydown(loband).aspx
> .
> > The C# example pretty easily translates to IronPython, so you could
> follow
> > that and check when the KeyEventArgs.KeyCode is equal to Keys.Return,
> then
> > call your ButtonClick method.
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-capture-a-%27Carriage-Return%27-in-a-windows-form---tp24290861p24417356.html
> Sent from the IronPython mailing list archive at Nabble.com.
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090709/c83da941/attachment.html>

From kf9150 at gmail.com  Fri Jul 10 08:34:26 2009
From: kf9150 at gmail.com (Kelie)
Date: Thu, 9 Jul 2009 23:34:26 -0700 (PDT)
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
Message-ID: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>

Hello,

I created a simple program with a few buttons, checkboxes, textboxes,
etc. and it worked fine. The form was created in the latest
SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
solution. In the release folder there were these files:

IronPython.dll
ManningsSolver.dll
ManningsSolver.exe
Microsoft.Scripting.Core.dll
Microsoft.Scripting.dll
Microsoft.Scripting.ExtensionAttribute.dll

When tried on two computers with IronPython installed and with the
source code files, the program worked. But it failed on another
computer that does not have these. And error message was very
generic .NET error. I don't exactly remember what it was. Is this
normal?

Btw, since I have SharpDevelop installed, do I have to install
IronPython in order to write programs in IronPython? Or does it matter
which version of IronPython I install. The answer seems to be "No"
because I see those .dll files for IronPython in this folder "C:
\Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
\PythonBinding" which are dated Feb 2009. Guess they're not the
latest.

Thanks,

Kelie



From merllab at microsoft.com  Fri Jul 10 17:53:31 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Fri, 10 Jul 2009 08:53:31 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <9a2cbaed-f804-4d18-aeca-9aecb441a515@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56281.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_locale.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapGetMemberNamesToDirAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapIEnumerableToContainsAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapIDisposableToContextManagerAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapIEnumerableToIterAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapICollectionToLenAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/imp.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/sys.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeDataSlot.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/Win32Exception.cs
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines
	$/IronPython/IronPython_Main/Src/Tests/Tools/modulediff.py
	$/IronPython/IronPython_Main/Src/Tests/Tools/logmodule.py
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/xxsubtype.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/types_only.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/time.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/thread.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/sys.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/select.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/nt.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/gc.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/datetime.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/cStringIO.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/cPickle.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/copy_reg.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/array.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_winreg.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_weakref.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_sre.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_codecs.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/__builtin__.log

DELETED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/NullImporter.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/sys.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Builtin.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Builtin.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/imp.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/locale.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_locale.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapGetMemberNamesToDirAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapIEnumerableToContainsAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapIDisposableToContextManagerAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapIEnumerableToIterAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/DontMapICollectionToLenAttribute.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/imp.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/sys.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeDataSlot.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/Win32Exception.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_codecs.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_bytesio.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_fileio.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_md5.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_sha.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/Field.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/_ctypes.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtrType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/ArrayType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/StructType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/FutureBuiltins.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/BinaryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ConditionalExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/CatchBlock.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/DynamicExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/DebugInfoExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/DefaultExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ConstantExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/BlockExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/GeneratorRewriter.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_heapq.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonGlobalVariableExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/BuiltinsDictionaryStorage.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_collections.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_warnings.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/BytesWarningException.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/NewStringFormatter.cs
	$/IronPython/IronPython_Main/Src/IronPython/Lib/iptest/assert_util.py
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_struct.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/Python.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonProtocol.Operations.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaOldClass.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/ClassMethodDescriptor.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/FunctionCode.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonFunction.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Descriptors.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Method.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/cmath.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_winreg.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/TypeInfo.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_functools.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/UnicodeWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/DeprecationWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/WarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/PythonExceptions.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/RuntimeWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/SystemExitException.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/PendingDeprecationWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/OverflowWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/ImportWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/UserWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/FutureWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/PythonExceptions.Generated.cs
	$/IronPython/IronPython_Main/Src/Tests/interop/net/type/test_clrtype.py
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MethodCallExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/CodeContextExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/SyntaxWarningException.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/xxsubtype.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeSlot.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/BuiltinFunction.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeTypeSlot.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/BuiltinMethodDescriptor.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/ReflectedEvent.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/ReflectedExtensionProperty.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonTypeOps.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/array.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonTuple.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldInstance.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/DictProxy.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/ReflectedSlotProperty.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/TypeCache.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldClass.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/ObjectOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/IntOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/StringOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/LongOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Generator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Slice.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/List.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonBuffer.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Interfaces.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/XRange.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonFile.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Importer.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Enumerate.cs
	$/IronPython/IronPython_Main/Src/IronPythonTest/EngineTest.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_weakref.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_weakref.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_sre.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_random.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/thread.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/socket.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Tutorial/Tutorial.htm
	$/IronPython/IronPython_Main/Src/Scripts/generate_exceptions.py
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/TryStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/PythonCommandLine.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/binascii.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/cPickle.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/cStringIO.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/datetime.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/errno.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/gc.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IronPython.Modules.csproj
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IterTools.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/marshal.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/math.cs
	$/IronPython/IronPython_Main/Src/Tests/test_codecs.py
	$/IronPython/IronPython_Main/Src/IronPython.Modules/nt.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/operator.cs
	$/IronPython/IronPython_Main/Src/Tests/test_cStringIO.py
	$/IronPython/IronPython_Main/Src/IronPython.Modules/select.cs
	$/IronPython/IronPython_Main/Src/Tests/test_exceptions.py
	$/IronPython/IronPython_Main/Src/Tests/test_file.py
	$/IronPython/IronPython_Main/Src/Tests/test_gc.py
	$/IronPython/IronPython_Main/Src/Tests/test_nt.py
	$/IronPython/IronPython_Main/Src/Tests/versions/python26.py
	$/IronPython/IronPython_Main/Src/Tests/interop/net/type/test_assembly.py
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/LabelExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/TryStatementBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/SwitchExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/GeneratorExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/TypeBinaryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/SwitchCase.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ParameterExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/SkipInterpretExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/UnaryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/FinallyFlowControlExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/TryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/IndexExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/InvocationExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberListBinding.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/LoopExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/NewArrayExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/NewExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/LambdaExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberMemberBinding.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/Expression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberInitExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ElementInit.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/SymbolConstantExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Generation/FieldBuilderExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/GotoExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/YieldExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LastFaultingLineExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/RuntimeVariablesExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ListInitExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberAssignment.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ExpressionVisitor.cs
	$/IronPython/IronPython_Main/Src/Tests/Tools/modulediff.py
	$/IronPython/IronPython_Main/Src/Tests/Tools/logmodule.py
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/xxsubtype.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/types_only.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/time.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/thread.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/sys.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/select.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/nt.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/gc.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/datetime.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/cStringIO.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/cPickle.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/copy_reg.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/array.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_winreg.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_weakref.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_sre.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/_codecs.log
	$/IronPython/IronPython_Main/Src/Tests/Tools/baselines/__builtin__.log

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 987915
Date: 7/9/2009 4:07:45 PM

(dinov) 23348 Removing a read-only file should raise an error with errno set to EACCES 
23349 Removing a open file should raise an error with errno set to EACCES 
16453 Trivial: Throw WindowsError with errno set to 2 when os.stat fails
                Move error conversion from nt module into the WindowsError function.  Add support for many more error conversions which are generated based upon the same error # conversions CPython is doing.  I?ve also added a Win32Exception to Silverlight so we can have parity with the desktop CLR w/o lots of divergent code paths.  I?ve also removed our own WarningException from non-Silverlight builds where we?re supposed to only be using System.ComponentModel.WarningException.  And again I?ve left WarningException around for the Silverlight builds where the System.ComponentModel.WarningException is unusable due to lack of ctors.

23350 A buffer object should be directly writable to a cStringIO object 
                Add overload that supports buffer objects, checked behavior of writelines as well.
23347 file objects need 'buffering' keyword argument 
                Rename 3rd argument to buffering from bufsize.
19310 Incompat: Open existing file with O_CREAT 
                Need to use Create instead of CreateNew flag when opening
8784 nt.open(filename,flags,mode) would throw exception while CPython works correctly
                Add a work around for the fact that .NET doesn?t allow us to create files w/ create and just read access.
23351 Implement 'mbcs' codec 
                Implement mbcs codec ? this is just the current default encoding as reported by .NET.  On US-English machines this is Windows-1252.  Tests are added that are specific to 1252.
                
Also fixing a regression in generators that was caused by the sys.settrace changes.  I accidently made generators use an inner lambda that was getting repeatedly created via Delegate.CreateDelegate.  This moves back to creating the delegate only once like we used to do it.



(Shelveset: BazaarAndGenPerf;REDMOND\dinov | SNAP CheckinId: 8880)
--------------------------------------------------------------------------------
Changeset Id: 985804
Date: 7/9/2009 12:46:52 PM

(dfugate) - test_clrtype.py now runs properly under the "multiple execute" stress test mode


(Shelveset: CLRTYPE4;REDMOND\dfugate | SNAP CheckinId: 8874)
--------------------------------------------------------------------------------
Changeset Id: 985043
Date: 7/9/2009 9:18:27 AM

(dinov) Fixes a bunch of ?Implement rest of? bugs.  Adds a new difference tool which runs much faster than the existing one.  It takes into account various core types and doesn?t include those in the differences.  The modules are processed ignoring the core types and then the core-types are processed by themselves.  There are baselines which are checked in and when the baseline is violated the generation script will need to be run again to update the baselines.  The baselines can include comments to point at the specific bug (or lack therefore if it?s an ok difference).  

Changes include:
                Adding __doc__ strings to lots of modules
                Hiding various classes which shouldn?t be exposed out under their names
                Removing some special __*__ methods which shouldn?t exist on types ? new attributes are added to suppress certain mapping patterns (e.g. IDisposable -> __enter__/__exit__, IEnumerable -> __contains__, etc?)
                Explicitly implementing interfaces on types that are unlikely to be used via their interfaces
                Removing ISequence/IMUtableSequence interfaces in preference of IList/IList<object>.  Ensuring we implement both IList/IList<object> on appropriate types.
                Add support for UTF-32 encodings
                Adding missing trivial properties/methods, removing some methods which shouldn?t exist
                Adding many missing attributes from weakref objects (we?re still missing __cmp__ but it?s tricky to add)
                Fixing cPickle to expose functions instead of types for creating new pickler objects.
                Moving modules in IronPython.dll into the IronPython.Modules namespace so all modules live there now regardless of the DLL.
                Add common base class for data descriptors and switch data descriptors to use it so they consistently have __set__ / __delete__ methods.
                Clear depreceted exc_* properties from sys after an exception is handled.



(Shelveset: ImplementRestOfFinalFinal;REDMOND\dinov | SNAP CheckinId: 8871)


From dinov at microsoft.com  Fri Jul 10 17:58:33 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 10 Jul 2009 15:58:33 +0000
Subject: [IronPython] Bazaar on IronPython
In-Reply-To: <d80792120907021027k3b03bf8ate50971fe836b3925@mail.gmail.com>
References: <d80792120906291529m47df9c64j7c5a51ed6cd6df53@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD033E93DD@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<d80792120907021027k3b03bf8ate50971fe836b3925@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0344E957@TK5EX14MBXC116.redmond.corp.microsoft.com>

Martin wrote:

> * Even non re.RE_Pattern objects shouldn't confuse warnings filtering
> (Regression in IronPython 2.6 beta 1) (too crazy for a bug entry)
>
> * Require the zlib module [workitem:2590] (other missing or broken
> modules not as crucial)
>
> * Making sys._getframe equal to None by default in 2.6 beta 1 lead to
> a happier logging module but a sadder doctest module.
>
> * The third argument to file should work as a keyword as well as
> positionally [workitem:23347]
>
> * The abspath function should not throw even for invalid windows
> paths. Or, if it's going to throw, it shouldn't spell 'pecified'
> without the 'S'. Fixed post-2.6 beta 1 by the workaround in
> nt._getfullpathname? (going by the code in
> IronPython_Main/Src/IronPython.Modules/nt.cs)
>
> * Removing a read-only file should raise an error with errno set to
> EACCES [workitem:23348] also related to [workitem:13702]
>
> * Removing a open file should raise an error with errno set to EACCES
> [workitem:23349] also related to [workitem:13702]
>
> * A buffer object should be directly writable to a cStringIO object
> [workitem:23350]
>
> * Opening an existing file with the O_CREAT should succeed
> [workitem:19310] (problem at FileModeFromFlags in
> IronPython_Main/Src/IronPython.Modules/nt.cs) CreateNew is the
> analogue of (O_CREAT | O_EXCL), just O_CREAT should be OpenAlways.
> Likewise, the O_TRUNC flag is not being correctly combined in there.
>
> * The mbcs codec for decoding windows 'ansi' strings should exist
> [workitem:23351]

With this morning's source push all of these should be fixed now except
For the zlib and re.RE_Pattern issues.


From dinov at microsoft.com  Fri Jul 10 18:03:58 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 10 Jul 2009 16:03:58 +0000
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>

In general you need IronPython to be present to run IronPython apps - even
if they're compiled.  And IronPython will need to be next to the app
unless IronPython has been installed into the GAC (which we do not
do by default).  Also you probably want to include IronPython.Modules.dll
as well in addition to the DLLs you have here.  I imagine at some point
in the future we could add some sort of tree shaking compiler support
that links in IronPython w/ the app but we're a ways off from making
that a priority.

The SharpDevelop specific question I'm less sure about.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Kelie
> Sent: Thursday, July 09, 2009 11:34 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] Problem with Creating Executable using
> SharpDevelop
>
> Hello,
>
> I created a simple program with a few buttons, checkboxes, textboxes,
> etc. and it worked fine. The form was created in the latest
> SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> solution. In the release folder there were these files:
>
> IronPython.dll
> ManningsSolver.dll
> ManningsSolver.exe
> Microsoft.Scripting.Core.dll
> Microsoft.Scripting.dll
> Microsoft.Scripting.ExtensionAttribute.dll
>
> When tried on two computers with IronPython installed and with the
> source code files, the program worked. But it failed on another
> computer that does not have these. And error message was very
> generic .NET error. I don't exactly remember what it was. Is this
> normal?
>
> Btw, since I have SharpDevelop installed, do I have to install
> IronPython in order to write programs in IronPython? Or does it matter
> which version of IronPython I install. The answer seems to be "No"
> because I see those .dll files for IronPython in this folder "C:
> \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> \PythonBinding" which are dated Feb 2009. Guess they're not the
> latest.
>
> Thanks,
>
> Kelie
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From JDM at MarchRay.net  Fri Jul 10 18:27:39 2009
From: JDM at MarchRay.net (Jonathan March)
Date: Fri, 10 Jul 2009 11:27:39 -0500
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>

Installing IP into the GAC is something apparently not much discussed in
polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".)

For us .net ignorami:
* What is the downside to installing IP into the GAC? Is it that different
apps will be dependent on different IP versions so better just to keep the
IP DLLs together with each app?
* Is installing into GAC still done by invoking gacutil twice as described
here:?
http://www.manifold.net/doc/scripts.htm

Thanks.

On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland <dinov at microsoft.com> wrote:

> In general you need IronPython to be present to run IronPython apps - even
> if they're compiled.  And IronPython will need to be next to the app
> unless IronPython has been installed into the GAC (which we do not
> do by default).  Also you probably want to include IronPython.Modules.dll
> as well in addition to the DLLs you have here.  I imagine at some point
> in the future we could add some sort of tree shaking compiler support
> that links in IronPython w/ the app but we're a ways off from making
> that a priority.
>
> The SharpDevelop specific question I'm less sure about.
>
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Kelie
> > Sent: Thursday, July 09, 2009 11:34 PM
> > To: users at lists.ironpython.com
> > Subject: [IronPython] Problem with Creating Executable using
> > SharpDevelop
> >
> > Hello,
> >
> > I created a simple program with a few buttons, checkboxes, textboxes,
> > etc. and it worked fine. The form was created in the latest
> > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> > solution. In the release folder there were these files:
> >
> > IronPython.dll
> > ManningsSolver.dll
> > ManningsSolver.exe
> > Microsoft.Scripting.Core.dll
> > Microsoft.Scripting.dll
> > Microsoft.Scripting.ExtensionAttribute.dll
> >
> > When tried on two computers with IronPython installed and with the
> > source code files, the program worked. But it failed on another
> > computer that does not have these. And error message was very
> > generic .NET error. I don't exactly remember what it was. Is this
> > normal?
> >
> > Btw, since I have SharpDevelop installed, do I have to install
> > IronPython in order to write programs in IronPython? Or does it matter
> > which version of IronPython I install. The answer seems to be "No"
> > because I see those .dll files for IronPython in this folder "C:
> > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> > \PythonBinding" which are dated Feb 2009. Guess they're not the
> > latest.
> >
> > Thanks,
> >
> > Kelie
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090710/017dd767/attachment.html>

From dinov at microsoft.com  Fri Jul 10 18:44:53 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 10 Jul 2009 16:44:53 +0000
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>

The big problem w/ installing into the GAC from our perspective is that assemblies in the GAC are fully trusted and can be loaded by anyone.  Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to our assemblies and you potentially have a recipe for disaster.  In theory we believe this is ok because we're also SecurityTransparent but we haven't had the deeper conversion w/ the CLR team about combining all 3 of these so we continue to be conservative and not install into the GAC.

We should probably look into removing APTCA though - the reason why we applied it in the 1.x time frame was due to a performance problem w/ signed non-APTCA assemblies which may now be fixed in the CLR.

As for actually doing the installation you now need to invoke gacutil 5 times - once for each DLL.  IronPython, IronPython.Modules, Microsoft.Scripting, Microsoft.Scripting.Core, and Microsoft.Scripting.ExtensionAttribute.  In 2.6 there'll be one more assembly to add to the list - Microsoft.Scripting.Debugging.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan March
Sent: Friday, July 10, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop

Installing IP into the GAC is something apparently not much discussed in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".)

For us .net ignorami:
* What is the downside to installing IP into the GAC? Is it that different apps will be dependent on different IP versions so better just to keep the IP DLLs together with each app?
* Is installing into GAC still done by invoking gacutil twice as described here:?
http://www.manifold.net/doc/scripts.htm

Thanks.
On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:
In general you need IronPython to be present to run IronPython apps - even
if they're compiled.  And IronPython will need to be next to the app
unless IronPython has been installed into the GAC (which we do not
do by default).  Also you probably want to include IronPython.Modules.dll
as well in addition to the DLLs you have here.  I imagine at some point
in the future we could add some sort of tree shaking compiler support
that links in IronPython w/ the app but we're a ways off from making
that a priority.

The SharpDevelop specific question I'm less sure about.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-<mailto:users->
> bounces at lists.ironpython.com<mailto:bounces at lists.ironpython.com>] On Behalf Of Kelie
> Sent: Thursday, July 09, 2009 11:34 PM
> To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
> Subject: [IronPython] Problem with Creating Executable using
> SharpDevelop
>
> Hello,
>
> I created a simple program with a few buttons, checkboxes, textboxes,
> etc. and it worked fine. The form was created in the latest
> SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> solution. In the release folder there were these files:
>
> IronPython.dll
> ManningsSolver.dll
> ManningsSolver.exe
> Microsoft.Scripting.Core.dll
> Microsoft.Scripting.dll
> Microsoft.Scripting.ExtensionAttribute.dll
>
> When tried on two computers with IronPython installed and with the
> source code files, the program worked. But it failed on another
> computer that does not have these. And error message was very
> generic .NET error. I don't exactly remember what it was. Is this
> normal?
>
> Btw, since I have SharpDevelop installed, do I have to install
> IronPython in order to write programs in IronPython? Or does it matter
> which version of IronPython I install. The answer seems to be "No"
> because I see those .dll files for IronPython in this folder "C:
> \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> \PythonBinding" which are dated Feb 2009. Guess they're not the
> latest.
>
> Thanks,
>
> Kelie
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

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

From jdhardy at gmail.com  Fri Jul 10 19:21:16 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 10 Jul 2009 11:21:16 -0600
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <ea89d0e50907101021n10766af7q7c829cbe17a7d493@mail.gmail.com>

On Fri, Jul 10, 2009 at 10:44 AM, Dino Viehland<dinov at microsoft.com> wrote:
> The big problem w/ installing into the GAC from our perspective is that
> assemblies in the GAC are fully trusted and can be loaded by anyone.
> Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to
> our assemblies and you potentially have a recipe for disaster.? In theory we
> believe this is ok because we?re also SecurityTransparent but we haven?t had
> the deeper conversion w/ the CLR team about combining all 3 of these so we
> continue to be conservative and not install into the GAC.

For the sake of simplifying the NWSGI usage instructions (or: think of
the children!), please reconsider :).

>
> We should probably look into removing APTCA though ? the reason why we
> applied it in the 1.x time frame was due to a performance problem w/ signed
> non-APTCA assemblies which may now be fixed in the CLR.

How would this affect partially-trusted applications? IIRC any
assemblies they reference must have APTCA. This is quite important for
web applications as they are often hosted in medium trust.

- Jeff


From dinov at microsoft.com  Fri Jul 10 19:27:18 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 10 Jul 2009 17:27:18 +0000
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <ea89d0e50907101021n10766af7q7c829cbe17a7d493@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<ea89d0e50907101021n10766af7q7c829cbe17a7d493@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0344F226@TK5EX14MBXC116.redmond.corp.microsoft.com>

Jeff wrote:

>
> How would this affect partially-trusted applications? IIRC any
> assemblies they reference must have APTCA. This is quite important for
> web applications as they are often hosted in medium trust.
>

Good point.  If we confirm that APTCA, SecurityTransparent and GAC
all mix perfectly fine then we could just leave APTCA.


From dinov at microsoft.com  Fri Jul 10 19:32:11 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 10 Jul 2009 17:32:11 +0000
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <ea89d0e50907101021n10766af7q7c829cbe17a7d493@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<ea89d0e50907101021n10766af7q7c829cbe17a7d493@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0344F293@TK5EX14MBXC116.redmond.corp.microsoft.com>

Jeff wrote:

>
> For the sake of simplifying the NWSGI usage instructions (or: think of
> the children!), please reconsider :).
>

Ok, we don't seem to have a issue on CodePlex for this so I've created
one:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23450

Feel free to vote on it - I doubt we'd do it for 2.6 but who knows...




From dinov at microsoft.com  Fri Jul 10 19:42:13 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 10 Jul 2009 17:42:13 +0000
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0344F317@TK5EX14MBXC116.redmond.corp.microsoft.com>

Ok, I just confirmed that mixing APTCA + SecurityTransparent + GAC works as expected so putting ourselves in the GAC should be perfectly fine to do.  There may be some additional internal process hurdles for us to jump over but we can look into that.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, July 10, 2009 9:45 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop

The big problem w/ installing into the GAC from our perspective is that assemblies in the GAC are fully trusted and can be loaded by anyone.  Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to our assemblies and you potentially have a recipe for disaster.  In theory we believe this is ok because we're also SecurityTransparent but we haven't had the deeper conversion w/ the CLR team about combining all 3 of these so we continue to be conservative and not install into the GAC.

We should probably look into removing APTCA though - the reason why we applied it in the 1.x time frame was due to a performance problem w/ signed non-APTCA assemblies which may now be fixed in the CLR.

As for actually doing the installation you now need to invoke gacutil 5 times - once for each DLL.  IronPython, IronPython.Modules, Microsoft.Scripting, Microsoft.Scripting.Core, and Microsoft.Scripting.ExtensionAttribute.  In 2.6 there'll be one more assembly to add to the list - Microsoft.Scripting.Debugging.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan March
Sent: Friday, July 10, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop

Installing IP into the GAC is something apparently not much discussed in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".)

For us .net ignorami:
* What is the downside to installing IP into the GAC? Is it that different apps will be dependent on different IP versions so better just to keep the IP DLLs together with each app?
* Is installing into GAC still done by invoking gacutil twice as described here:?
http://www.manifold.net/doc/scripts.htm

Thanks.
On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:
In general you need IronPython to be present to run IronPython apps - even
if they're compiled.  And IronPython will need to be next to the app
unless IronPython has been installed into the GAC (which we do not
do by default).  Also you probably want to include IronPython.Modules.dll
as well in addition to the DLLs you have here.  I imagine at some point
in the future we could add some sort of tree shaking compiler support
that links in IronPython w/ the app but we're a ways off from making
that a priority.

The SharpDevelop specific question I'm less sure about.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-<mailto:users->
> bounces at lists.ironpython.com<mailto:bounces at lists.ironpython.com>] On Behalf Of Kelie
> Sent: Thursday, July 09, 2009 11:34 PM
> To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
> Subject: [IronPython] Problem with Creating Executable using
> SharpDevelop
>
> Hello,
>
> I created a simple program with a few buttons, checkboxes, textboxes,
> etc. and it worked fine. The form was created in the latest
> SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> solution. In the release folder there were these files:
>
> IronPython.dll
> ManningsSolver.dll
> ManningsSolver.exe
> Microsoft.Scripting.Core.dll
> Microsoft.Scripting.dll
> Microsoft.Scripting.ExtensionAttribute.dll
>
> When tried on two computers with IronPython installed and with the
> source code files, the program worked. But it failed on another
> computer that does not have these. And error message was very
> generic .NET error. I don't exactly remember what it was. Is this
> normal?
>
> Btw, since I have SharpDevelop installed, do I have to install
> IronPython in order to write programs in IronPython? Or does it matter
> which version of IronPython I install. The answer seems to be "No"
> because I see those .dll files for IronPython in this folder "C:
> \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> \PythonBinding" which are dated Feb 2009. Guess they're not the
> latest.
>
> Thanks,
>
> Kelie
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

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

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

From JDM at MarchRay.net  Fri Jul 10 20:21:30 2009
From: JDM at MarchRay.net (Jonathan March)
Date: Fri, 10 Jul 2009 13:21:30 -0500
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0344F317@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<1A472770E042064698CB5ADC83A12ACD0344F317@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <b8aa56d50907101121p1255b94en749ca7d2ef9347eb@mail.gmail.com>

Thanks for the quick response and forward motion!

On Fri, Jul 10, 2009 at 12:42 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  Ok, I just confirmed that mixing APTCA + SecurityTransparent + GAC works
> as expected so putting ourselves in the GAC should be perfectly fine to do.
> There may be some additional internal process hurdles for us to jump over
> but we can look into that.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland
> *Sent:* Friday, July 10, 2009 9:45 AM
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Problem with Creating Executable using
> SharpDevelop
>
>
>
> The big problem w/ installing into the GAC from our perspective is that
> assemblies in the GAC are fully trusted and can be loaded by anyone.
> Combine this w/ the AllowPartiallyTrustedCallers attribute which we apply to
> our assemblies and you potentially have a recipe for disaster.  In theory we
> believe this is ok because we?re also SecurityTransparent but we haven?t had
> the deeper conversion w/ the CLR team about combining all 3 of these so we
> continue to be conservative and not install into the GAC.
>
>
>
> We should probably look into removing APTCA though ? the reason why we
> applied it in the 1.x time frame was due to a performance problem w/ signed
> non-APTCA assemblies which may now be fixed in the CLR.
>
>
>
> As for actually doing the installation you now need to invoke gacutil 5
> times ? once for each DLL.  IronPython, IronPython.Modules,
> Microsoft.Scripting, Microsoft.Scripting.Core, and
> Microsoft.Scripting.ExtensionAttribute.  In 2.6 there?ll be one more
> assembly to add to the list ? Microsoft.Scripting.Debugging.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Jonathan March
> *Sent:* Friday, July 10, 2009 9:28 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Problem with Creating Executable using
> SharpDevelop
>
>
>
> Installing IP into the GAC is something apparently not much discussed in
> polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".)
>
> For us .net ignorami:
> * What is the downside to installing IP into the GAC? Is it that different
> apps will be dependent on different IP versions so better just to keep the
> IP DLLs together with each app?
> * Is installing into GAC still done by invoking gacutil twice as described
> here:?
> http://www.manifold.net/doc/scripts.htm
>
> Thanks.
>
> On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland <dinov at microsoft.com>
> wrote:
>
> In general you need IronPython to be present to run IronPython apps - even
> if they're compiled.  And IronPython will need to be next to the app
> unless IronPython has been installed into the GAC (which we do not
> do by default).  Also you probably want to include IronPython.Modules.dll
> as well in addition to the DLLs you have here.  I imagine at some point
> in the future we could add some sort of tree shaking compiler support
> that links in IronPython w/ the app but we're a ways off from making
> that a priority.
>
> The SharpDevelop specific question I'm less sure about.
>
>
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Kelie
> > Sent: Thursday, July 09, 2009 11:34 PM
> > To: users at lists.ironpython.com
> > Subject: [IronPython] Problem with Creating Executable using
> > SharpDevelop
> >
> > Hello,
> >
> > I created a simple program with a few buttons, checkboxes, textboxes,
> > etc. and it worked fine. The form was created in the latest
> > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> > solution. In the release folder there were these files:
> >
> > IronPython.dll
> > ManningsSolver.dll
> > ManningsSolver.exe
> > Microsoft.Scripting.Core.dll
> > Microsoft.Scripting.dll
> > Microsoft.Scripting.ExtensionAttribute.dll
> >
> > When tried on two computers with IronPython installed and with the
> > source code files, the program worked. But it failed on another
> > computer that does not have these. And error message was very
> > generic .NET error. I don't exactly remember what it was. Is this
> > normal?
> >
> > Btw, since I have SharpDevelop installed, do I have to install
> > IronPython in order to write programs in IronPython? Or does it matter
> > which version of IronPython I install. The answer seems to be "No"
> > because I see those .dll files for IronPython in this folder "C:
> > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> > \PythonBinding" which are dated Feb 2009. Guess they're not the
> > latest.
> >
> > Thanks,
> >
> > Kelie
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090710/72bd06c1/attachment.html>

From fuzzyman at voidspace.org.uk  Fri Jul 10 20:50:32 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 10 Jul 2009 19:50:32 +0100
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A578D78.40804@voidspace.org.uk>

Are there issues around assembly versions and the GAC? I'm thinking 
particularly of where newer versions of IronPython are released as 
drop-in replacements so the version numbers are not updated. If a 
previous version is in the GAC isn't there a likelihood that an 
application that ships with a newer version will still load the GAC'd 
older version... ?

My *impression* was that adding stuff to the GAC was a recipe for DLL 
hell and therefore it was better left to individual users rather than 
being automatic on installation. This opinion may be ill-informed however...

Michael

Dino Viehland wrote:
>
> The big problem w/ installing into the GAC from our perspective is 
> that assemblies in the GAC are fully trusted and can be loaded by 
> anyone. Combine this w/ the AllowPartiallyTrustedCallers attribute 
> which we apply to our assemblies and you potentially have a recipe for 
> disaster. In theory we believe this is ok because we?re also 
> SecurityTransparent but we haven?t had the deeper conversion w/ the 
> CLR team about combining all 3 of these so we continue to be 
> conservative and not install into the GAC.
>
> We should probably look into removing APTCA though ? the reason why we 
> applied it in the 1.x time frame was due to a performance problem w/ 
> signed non-APTCA assemblies which may now be fixed in the CLR.
>
> As for actually doing the installation you now need to invoke gacutil 
> 5 times ? once for each DLL. IronPython, IronPython.Modules, 
> Microsoft.Scripting, Microsoft.Scripting.Core, and 
> Microsoft.Scripting.ExtensionAttribute. In 2.6 there?ll be one more 
> assembly to add to the list ? Microsoft.Scripting.Debugging.
>
> *From:* users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Jonathan March
> *Sent:* Friday, July 10, 2009 9:28 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Problem with Creating Executable using 
> SharpDevelop
>
> Installing IP into the GAC is something apparently not much discussed 
> in polite company (e.g. AFAICT not at all in "IP in Action" or "IP URLs".)
>
> For us .net ignorami:
> * What is the downside to installing IP into the GAC? Is it that 
> different apps will be dependent on different IP versions so better 
> just to keep the IP DLLs together with each app?
> * Is installing into GAC still done by invoking gacutil twice as 
> described here:?
> http://www.manifold.net/doc/scripts.htm
>
> Thanks.
>
> On Fri, Jul 10, 2009 at 11:03 AM, Dino Viehland <dinov at microsoft.com 
> <mailto:dinov at microsoft.com>> wrote:
>
> In general you need IronPython to be present to run IronPython apps - even
> if they're compiled. And IronPython will need to be next to the app
> unless IronPython has been installed into the GAC (which we do not
> do by default). Also you probably want to include IronPython.Modules.dll
> as well in addition to the DLLs you have here. I imagine at some point
> in the future we could add some sort of tree shaking compiler support
> that links in IronPython w/ the app but we're a ways off from making
> that a priority.
>
> The SharpDevelop specific question I'm less sure about.
>
>
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com 
> <mailto:users-bounces at lists.ironpython.com> [mailto:users- <mailto:users->
> > bounces at lists.ironpython.com <mailto:bounces at lists.ironpython.com>] 
> On Behalf Of Kelie
> > Sent: Thursday, July 09, 2009 11:34 PM
> > To: users at lists.ironpython.com <mailto:users at lists.ironpython.com>
> > Subject: [IronPython] Problem with Creating Executable using
> > SharpDevelop
> >
> > Hello,
> >
> > I created a simple program with a few buttons, checkboxes, textboxes,
> > etc. and it worked fine. The form was created in the latest
> > SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> > solution. In the release folder there were these files:
> >
> > IronPython.dll
> > ManningsSolver.dll
> > ManningsSolver.exe
> > Microsoft.Scripting.Core.dll
> > Microsoft.Scripting.dll
> > Microsoft.Scripting.ExtensionAttribute.dll
> >
> > When tried on two computers with IronPython installed and with the
> > source code files, the program worked. But it failed on another
> > computer that does not have these. And error message was very
> > generic .NET error. I don't exactly remember what it was. Is this
> > normal?
> >
> > Btw, since I have SharpDevelop installed, do I have to install
> > IronPython in order to write programs in IronPython? Or does it matter
> > which version of IronPython I install. The answer seems to be "No"
> > because I see those .dll files for IronPython in this folder "C:
> > \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> > \PythonBinding" which are dated Feb 2009. Guess they're not the
> > latest.
> >
> > Thanks,
> >
> > Kelie
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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



From slide.o.mix at gmail.com  Fri Jul 10 23:56:42 2009
From: slide.o.mix at gmail.com (Slide)
Date: Fri, 10 Jul 2009 14:56:42 -0700
Subject: [IronPython] "IronPython in Action" and "Pro IronPython"
Message-ID: <a623f7d10907101456u5b8edf65g16852ba3c5155cdf@mail.gmail.com>

I am assuming the authors of these two books are possibly on this
mailing list, so I am not sure if this is really a good question to
ask :-) , but can anyone comment on these two books, their accuracy to
the latest IronPython versions and how they do at explaining embedding
the runtime to make applications scriptable and such?

http://www.amazon.com/IronPython-Action-Michael-Foord/dp/1933988339/ref=sr_1_1?ie=UTF8&s=books&qid=1247262876&sr=8-1
http://www.amazon.com/Pro-IronPython-Alan-Harris/dp/1430219629/ref=sr_1_2?ie=UTF8&s=books&qid=1247262876&sr=8-2

Thanks,

slide

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


From stephen.p.lepisto at intel.com  Sat Jul 11 01:05:20 2009
From: stephen.p.lepisto at intel.com (Lepisto, Stephen P)
Date: Fri, 10 Jul 2009 16:05:20 -0700
Subject: [IronPython] "IronPython in Action" and "Pro IronPython"
In-Reply-To: <a623f7d10907101456u5b8edf65g16852ba3c5155cdf@mail.gmail.com>
References: <a623f7d10907101456u5b8edf65g16852ba3c5155cdf@mail.gmail.com>
Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C75ED781D@orsmsx510.amr.corp.intel.com>

"IronPython in Action" does a good job at explaining how to embed IronPython (an entire, lengthy chapter is devoted to it).  It answered several questions I had about the process.  It does not cover IronPython 2.6, but the approach is, I believe, very similar to 2.0.

I have not read "Pro IronPython".


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Slide
Sent: Friday, July 10, 2009 2:57 PM
To: Discussion of IronPython
Subject: [IronPython] "IronPython in Action" and "Pro IronPython"

I am assuming the authors of these two books are possibly on this
mailing list, so I am not sure if this is really a good question to
ask :-) , but can anyone comment on these two books, their accuracy to
the latest IronPython versions and how they do at explaining embedding
the runtime to make applications scriptable and such?

http://www.amazon.com/IronPython-Action-Michael-Foord/dp/1933988339/ref=sr_1_1?ie=UTF8&s=books&qid=1247262876&sr=8-1
http://www.amazon.com/Pro-IronPython-Alan-Harris/dp/1430219629/ref=sr_1_2?ie=UTF8&s=books&qid=1247262876&sr=8-2

Thanks,

slide

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


From kf9150 at gmail.com  Sat Jul 11 06:36:07 2009
From: kf9150 at gmail.com (Kelie)
Date: Fri, 10 Jul 2009 21:36:07 -0700 (PDT)
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <56fa314b-622f-46b8-8943-5517a5aae6e0@q11g2000yqi.googlegroups.com>

On Jul 10, 6:03?am, Dino Viehland <di... at microsoft.com> wrote:
> In general you need IronPython to be present to run IronPython apps - even
> if they're compiled. ?And IronPython will need to be next to the app
> unless IronPython has been installed into the GAC (which we do not
> do by default). ?Also you probably want to include IronPython.Modules.dll
> as well in addition to the DLLs you have here. ?I imagine at some point
> in the future we could add some sort of tree shaking compiler support
> that links in IronPython w/ the app but we're a ways off from making
> that a priority.
>
> The SharpDevelop specific question I'm less sure about.

I installed IronPython 2.01 (the same version that I have on my two
computers) on the other computer and it still didn't work. Anything
else I should try?

Btw, is there a way to post attachment to this mailing list? The
program I created is quite simple. Some of you might be able to spot
the problem if you see the code. Thanks again.


From curt at hagenlocher.org  Sat Jul 11 06:46:44 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Fri, 10 Jul 2009 21:46:44 -0700
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <56fa314b-622f-46b8-8943-5517a5aae6e0@q11g2000yqi.googlegroups.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<56fa314b-622f-46b8-8943-5517a5aae6e0@q11g2000yqi.googlegroups.com>
Message-ID: <d2155e360907102146l5ff57410w6e2d1650d66a743b@mail.gmail.com>

On Fri, Jul 10, 2009 at 9:36 PM, Kelie <kf9150 at gmail.com> wrote:
>
> Btw, is there a way to post attachment to this mailing list? The
> program I created is quite simple. Some of you might be able to spot
> the problem if you see the code. Thanks again.

It would probably be more immediately useful if you were to provide
the specific error message and a listing of the directory from which
you're trying to run the program. Given that it works on at least one
machine, it's likely to be context-related rather than code-related.

--
Curt Hagenlocher
curt at hagenlocher.org


From jdhardy at gmail.com  Mon Jul 13 03:28:33 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 12 Jul 2009 19:28:33 -0600
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <4A578D78.40804@voidspace.org.uk>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A578D78.40804@voidspace.org.uk>
Message-ID: <ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>

On Fri, Jul 10, 2009 at 12:50 PM, Michael
Foord<fuzzyman at voidspace.org.uk> wrote:
> Are there issues around assembly versions and the GAC? I'm thinking
> particularly of where newer versions of IronPython are released as drop-in
> replacements so the version numbers are not updated. If a previous version
> is in the GAC isn't there a likelihood that an application that ships with a
> newer version will still load the GAC'd older version... ?
>
> My *impression* was that adding stuff to the GAC was a recipe for DLL hell
> and therefore it was better left to individual users rather than being
> automatic on installation. This opinion may be ill-informed however...

You just have to be *really* careful with you assembly versions, and
what kinds of changes cause a rev of version numbers. However, I don't
think it should be the default, but it would be nice to have the
option during installation. I think gacutil is only included in the
SDK anyway.

- Jeff


From fuzzyman at voidspace.org.uk  Mon Jul 13 13:00:10 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 13 Jul 2009 12:00:10 +0100
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A578D78.40804@voidspace.org.uk>
	<ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>
Message-ID: <4A5B13BA.4040608@voidspace.org.uk>

Jeff Hardy wrote:
> On Fri, Jul 10, 2009 at 12:50 PM, Michael
> Foord<fuzzyman at voidspace.org.uk> wrote:
>   
>> Are there issues around assembly versions and the GAC? I'm thinking
>> particularly of where newer versions of IronPython are released as drop-in
>> replacements so the version numbers are not updated. If a previous version
>> is in the GAC isn't there a likelihood that an application that ships with a
>> newer version will still load the GAC'd older version... ?
>>
>> My *impression* was that adding stuff to the GAC was a recipe for DLL hell
>> and therefore it was better left to individual users rather than being
>> automatic on installation. This opinion may be ill-informed however...
>>     
>
> You just have to be *really* careful with you assembly versions, and
> what kinds of changes cause a rev of version numbers. However, I don't
> think it should be the default, but it would be nice to have the
> option during installation. I think gacutil is only included in the
> SDK anyway.
>
>   

Right. I think the issue of version numbering is tricky, which is why 
I'm nervous about IronPython being GAC'd.

As an example, the IronPython 2.0.1 and 2.0 assemblies have the same 
version numbers - and I understand why and don't disagree with this 
decision - but the net result is that Resolver One required 2.0.1 and 
would probably fail if the user has 2.0 in the GAC.

I certainly wouldn't object to it being an installer option, but it 
would still make me nervous... :-)

Having minor IronPython versions have new assembly versions would 
probably help - but with the disadvantage that they are no longer 
drop-in replacements.


Michael

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


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




From dfugate at microsoft.com  Mon Jul 13 18:26:01 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Mon, 13 Jul 2009 09:26:01 -0700
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <4A5B13BA.4040608@voidspace.org.uk>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A578D78.40804@voidspace.org.uk>
	<ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>
	<4A5B13BA.4040608@voidspace.org.uk>
Message-ID: <EECFB552375FDE49A23A13CE85EEC2FD1EBD3E4734@NA-EXMSG-C112.redmond.corp.microsoft.com>

On a related note, I strongly suspect we'll be using different assembly version numbers for IronPython 2.6.0/2.6.1/etc...

Dave

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, July 13, 2009 4:00 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop

Jeff Hardy wrote:
> On Fri, Jul 10, 2009 at 12:50 PM, Michael
> Foord<fuzzyman at voidspace.org.uk> wrote:
>   
>> Are there issues around assembly versions and the GAC? I'm thinking
>> particularly of where newer versions of IronPython are released as drop-in
>> replacements so the version numbers are not updated. If a previous version
>> is in the GAC isn't there a likelihood that an application that ships with a
>> newer version will still load the GAC'd older version... ?
>>
>> My *impression* was that adding stuff to the GAC was a recipe for DLL hell
>> and therefore it was better left to individual users rather than being
>> automatic on installation. This opinion may be ill-informed however...
>>     
>
> You just have to be *really* careful with you assembly versions, and
> what kinds of changes cause a rev of version numbers. However, I don't
> think it should be the default, but it would be nice to have the
> option during installation. I think gacutil is only included in the
> SDK anyway.
>
>   

Right. I think the issue of version numbering is tricky, which is why 
I'm nervous about IronPython being GAC'd.

As an example, the IronPython 2.0.1 and 2.0 assemblies have the same 
version numbers - and I understand why and don't disagree with this 
decision - but the net result is that Resolver One required 2.0.1 and 
would probably fail if the user has 2.0 in the GAC.

I certainly wouldn't object to it being an installer option, but it 
would still make me nervous... :-)

Having minor IronPython versions have new assembly versions would 
probably help - but with the disadvantage that they are no longer 
drop-in replacements.


Michael

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


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


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



From jdhardy at gmail.com  Tue Jul 14 14:51:00 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 14 Jul 2009 06:51:00 -0600
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <EECFB552375FDE49A23A13CE85EEC2FD1EBD3E4734@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A578D78.40804@voidspace.org.uk>
	<ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>
	<4A5B13BA.4040608@voidspace.org.uk>
	<EECFB552375FDE49A23A13CE85EEC2FD1EBD3E4734@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <ea89d0e50907140551q348eb261gd8598409bb1096c5@mail.gmail.com>

On Mon, Jul 13, 2009 at 10:26 AM, Dave Fugate<dfugate at microsoft.com> wrote:
> On a related note, I strongly suspect we'll be using different assembly version numbers for IronPython 2.6.0/2.6.1/etc...

I'd prefer not to have to respin NWSGI for every minor version of
IronPython. I know about assemblyBinding, and I can make it work, but
it hurts the user experience having to know exactly what version of
IronPython is installed. This isn't the case for CPython, where
extensions target the 2.6 version only, no 2.6.2.

I see it as similar to the .NET FX service packs - the assembly
versions remain the same, even though there are changes to the
assembly, and it seems to work out (mostly, anyway).

Does anyone know if there's a way, in a .config file, to tell .NET to
use a local copy instead of the GAC? Some combination of
assemblyBinding elemnts should do it, but I'm unable to try right now.

- Jeff


From simon.dahlbacka at gmail.com  Tue Jul 14 14:56:11 2009
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Tue, 14 Jul 2009 15:56:11 +0300
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <EECFB552375FDE49A23A13CE85EEC2FD1EBD3E4734@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A578D78.40804@voidspace.org.uk>
	<ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>
	<4A5B13BA.4040608@voidspace.org.uk>
	<EECFB552375FDE49A23A13CE85EEC2FD1EBD3E4734@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <57124720907140556h43ff3a8aja8aa18cc6fe7dc24@mail.gmail.com>

On Mon, Jul 13, 2009 at 7:26 PM, Dave Fugate <dfugate at microsoft.com> wrote:

> On a related note, I strongly suspect we'll be using different assembly
> version numbers for IronPython 2.6.0/2.6.1/etc...
>
>
Can't you update AssemblyFileVersion and leave AssemblyVersion or is there a
problem with that too?


>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, July 13, 2009 4:00 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Problem with Creating Executable using
> SharpDevelop
>
> Jeff Hardy wrote:
> > On Fri, Jul 10, 2009 at 12:50 PM, Michael
> > Foord<fuzzyman at voidspace.org.uk> wrote:
> >
> >> Are there issues around assembly versions and the GAC? I'm thinking
> >> particularly of where newer versions of IronPython are released as
> drop-in
> >> replacements so the version numbers are not updated. If a previous
> version
> >> is in the GAC isn't there a likelihood that an application that ships
> with a
> >> newer version will still load the GAC'd older version... ?
> >>
> >> My *impression* was that adding stuff to the GAC was a recipe for DLL
> hell
> >> and therefore it was better left to individual users rather than being
> >> automatic on installation. This opinion may be ill-informed however...
> >>
> >
> > You just have to be *really* careful with you assembly versions, and
> > what kinds of changes cause a rev of version numbers. However, I don't
> > think it should be the default, but it would be nice to have the
> > option during installation. I think gacutil is only included in the
> > SDK anyway.
> >
> >
>
> Right. I think the issue of version numbering is tricky, which is why
> I'm nervous about IronPython being GAC'd.
>
> As an example, the IronPython 2.0.1 and 2.0 assemblies have the same
> version numbers - and I understand why and don't disagree with this
> decision - but the net result is that Resolver One required 2.0.1 and
> would probably fail if the user has 2.0 in the GAC.
>
> I certainly wouldn't object to it being an installer option, but it
> would still make me nervous... :-)
>
> Having minor IronPython versions have new assembly versions would
> probably help - but with the disadvantage that they are no longer
> drop-in replacements.
>
>
> Michael
>
> > - Jeff
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090714/da53cbda/attachment.html>

From dfugate at microsoft.com  Tue Jul 14 18:54:22 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Tue, 14 Jul 2009 09:54:22 -0700
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <57124720907140556h43ff3a8aja8aa18cc6fe7dc24@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<b8aa56d50907100927k7341bd73iee176cf971d2507c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0344EDB7@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A578D78.40804@voidspace.org.uk>
	<ea89d0e50907121828pf2a4b5bueb4a7c8c1ef8d512@mail.gmail.com>
	<4A5B13BA.4040608@voidspace.org.uk>
	<EECFB552375FDE49A23A13CE85EEC2FD1EBD3E4734@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<57124720907140556h43ff3a8aja8aa18cc6fe7dc24@mail.gmail.com>
Message-ID: <EECFB552375FDE49A23A13CE85EEC2FD1EBD4EEC7F@NA-EXMSG-C112.redmond.corp.microsoft.com>

We've kept assembly version numbers the same for 2.0.x (and change the assembly file version for each patch release) so that hosted IronPython applications do not need to be rebuilt for each release.  This approach is great as it ensures binary compatibility for compiled applications built on top of IronPython but it also has one major disadvantage:  we have to be incredibly conservative in terms of bug fixing for patch releases.  This means zero changes to any method signature whether it's in the DLR or IronPython.  Also, we outright reject a number of bug fixes for patch releases based on their complexity alone which might cause instability in other areas.

Our current 2.6.x planning entails not only fixing a lot of "hard" bugs where the fixes themselves might cause new instability, but also far more bugs than any prior IronPython release series.  As such, we need the flexibility to change method signatures (without injecting public API incompatibilities in areas like hosting of course) between patch releases.  The safest way to do this for those building compiled applications with IronPython is to rev assembly version numbers for each release of 2.6.

Finally, please recall that earlier I said we "strongly suspect" we'll be using different assembly version numbers for 2.6.  This isn't set in stone yet:)  If you feel strongly on this one way or another, please let us know as this will influence the final decision.

Thanks,

Dave

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Tuesday, July 14, 2009 5:56 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop


On Mon, Jul 13, 2009 at 7:26 PM, Dave Fugate <dfugate at microsoft.com<mailto:dfugate at microsoft.com>> wrote:
On a related note, I strongly suspect we'll be using different assembly version numbers for IronPython 2.6.0/2.6.1/etc...

Can't you update AssemblyFileVersion and leave AssemblyVersion or is there a problem with that too?


-----Original Message-----
From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Michael Foord
Sent: Monday, July 13, 2009 4:00 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Creating Executable using SharpDevelop
Jeff Hardy wrote:
> On Fri, Jul 10, 2009 at 12:50 PM, Michael
> Foord<fuzzyman at voidspace.org.uk<mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>> Are there issues around assembly versions and the GAC? I'm thinking
>> particularly of where newer versions of IronPython are released as drop-in
>> replacements so the version numbers are not updated. If a previous version
>> is in the GAC isn't there a likelihood that an application that ships with a
>> newer version will still load the GAC'd older version... ?
>>
>> My *impression* was that adding stuff to the GAC was a recipe for DLL hell
>> and therefore it was better left to individual users rather than being
>> automatic on installation. This opinion may be ill-informed however...
>>
>
> You just have to be *really* careful with you assembly versions, and
> what kinds of changes cause a rev of version numbers. However, I don't
> think it should be the default, but it would be nice to have the
> option during installation. I think gacutil is only included in the
> SDK anyway.
>
>

Right. I think the issue of version numbering is tricky, which is why
I'm nervous about IronPython being GAC'd.

As an example, the IronPython 2.0.1 and 2.0 assemblies have the same
version numbers - and I understand why and don't disagree with this
decision - but the net result is that Resolver One required 2.0.1 and
would probably fail if the user has 2.0 in the GAC.

I certainly wouldn't object to it being an installer option, but it
would still make me nervous... :-)

Having minor IronPython versions have new assembly versions would
probably help - but with the disadvantage that they are no longer
drop-in replacements.


Michael

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


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


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

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

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

From merllab at microsoft.com  Wed Jul 15 01:42:22 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Tue, 14 Jul 2009 16:42:22 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <d70c7a0c-a4e2-4a16-b670-ca685aa3c283@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56486.

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/Microsoft.Scripting.Debugging.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.Core.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.ExtensionAttribute.csproj
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Microsoft.Scripting.Silverlight.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/Instruction.cs
	$/IronPython/IronPython_Main/Src/IronPythonTest/IronPythonTest.csproj
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IronPython.Modules.csproj
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/ArrayUtils.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightCompiler.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/CollectionUtils.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/ContractUtils.cs
	$/IronPython/IronPython_Main/Src/Tests/ClrAssembly/ClrAssembly.csproj





From bernd.viehmann at gmx.net  Wed Jul 15 09:31:01 2009
From: bernd.viehmann at gmx.net (Bernd Viehmann)
Date: Wed, 15 Jul 2009 09:31:01 +0200
Subject: [IronPython] Q:ASP.NET developing with IPY.Deploying on IIS or
	Apache?
Message-ID: <4A5D85B5.2000903@gmx.net>

Hello,

I have just finished reading the ASP.NET part in the book "IronPython in 
Action" which is excellent. I have played a little bit with it using 
Visual Studio and it ooks like IPY will make the job of developing 
ASP.NET websites much easier. But unfortunatly in the book is nothing 
about deploying the work to an IIS web-server. I think this should be 
fixed in the next version of the book, Micheal & Christian ;-) Even if 
it might be easy until now I am unable to get things running.

So help me please:

What must be done when taking the *.aspx.py productive? Can not find an 
config-tutorial in the web.
Is IronPython stable enough to develop larger ASP.NET applications in 
Python? Is it recommended by Microsoft, or should we wait for .net 4.0?
Can it be done on Server 2003 and what IIS version is needed?
Can Apache on windows be used also with Mono? And Linux?

A lot of questions, I know. So you don't have to answer all of them. I 
will be happy for every answer that comes :-)

Regards

 Bernd (on the border between Germany and Netherlands)







From sanxiyn at gmail.com  Wed Jul 15 09:43:07 2009
From: sanxiyn at gmail.com (Seo Sanghyeon)
Date: Wed, 15 Jul 2009 16:43:07 +0900
Subject: [IronPython] FePy status update
Message-ID: <5b0248170907150043m3241e1fcmfd48b4d2015ee581@mail.gmail.com>

Now I updated FePy's NAnt build file to include newly introduced
Microsoft.System.Debugging.dll.

I also found that I need to define CLR2 symbol to compile
Microsoft.Dynamic.dll. Without the symbol it won't compile. What is
the purpose of this symbol?

Sorry for the delay,

-- 
Seo Sanghyeon


From empirebuilder at gmail.com  Wed Jul 15 15:15:01 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Wed, 15 Jul 2009 16:15:01 +0300
Subject: [IronPython] Q:ASP.NET developing with IPY.Deploying on IIS or
	Apache?
In-Reply-To: <4A5D85B5.2000903@gmx.net>
References: <4A5D85B5.2000903@gmx.net>
Message-ID: <8cd017b80907150615k2eef18f9ia76f4af6461c438b@mail.gmail.com>

1. There is nothing special to make it work on IIS. Simply download
http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17613 and
run the example which contains all the web.config you need.2. We have been
using it extensively for the past 2 years on production. The latest version
is stable. There's no need to wait for .Net 4.0
3. It works on IIS 6.0 and 7.0 on Windows 2003 32/64 bit and Windows 2008
32/64 bit.
4. Not sure about the apache scenario.

On Wed, Jul 15, 2009 at 10:31 AM, Bernd Viehmann <bernd.viehmann at gmx.net>wrote:

> Hello,
>
> I have just finished reading the ASP.NET part in the book "IronPython in
> Action" which is excellent. I have played a little bit with it using Visual
> Studio and it ooks like IPY will make the job of developing ASP.NETwebsites much easier. But unfortunatly in the book is nothing about
> deploying the work to an IIS web-server. I think this should be fixed in the
> next version of the book, Micheal & Christian ;-) Even if it might be easy
> until now I am unable to get things running.
>
> So help me please:
>
> What must be done when taking the *.aspx.py productive? Can not find an
> config-tutorial in the web.
> Is IronPython stable enough to develop larger ASP.NET applications in
> Python? Is it recommended by Microsoft, or should we wait for .net 4.0?
> Can it be done on Server 2003 and what IIS version is needed?
> Can Apache on windows be used also with Mono? And Linux?
>
> A lot of questions, I know. So you don't have to answer all of them. I will
> be happy for every answer that comes :-)
>
> Regards
>
> Bernd (on the border between Germany and Netherlands)
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



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

From mads.weitling at gmail.com  Wed Jul 15 16:57:11 2009
From: mads.weitling at gmail.com (Mads Weitling)
Date: Wed, 15 Jul 2009 16:57:11 +0200
Subject: [IronPython] sys.builtin_module_names and embedding
Message-ID: <f9cdf5cb0907150757r1175d9a2m89ebea5e480e31d1@mail.gmail.com>

I am trying to run som IronPython code using the 2.6b1 hosting API but
cannot seem to import the basic 'builtins' defined in IronPython.Modules.dll
from my IronPython host.
When using ipy.exe, things work fine:
ipy.exe -v
>>> import sys
>>> sys.builtin_module_names
('clr', 'future_builtins', 'sys', '__builtin__', 'exceptions', '_weakref',
'_struct', '_winreg', '_warnings', '_sre', '_random', '_functools',
'xxsubtype', 'time', 'thread', '_heapq', '_ctypes_test', '_ctypes',
'socket', '_sha512', '_sha256', '_sha', 'select', 're', 'operator', 'nt',
'_md5', 'math', 'marshal', '_locale', 'itertools', 'imp', 'gc', 'errno',
'datetime', 'cStringIO', 'cPickle', 'copy_reg', '_collections', '_codecs',
'cmath', 'binascii', 'array')

Running from an embedded IronPython, I see only a few builtins:

('clr', 'future_builtins', 'sys', '__builtin__', 'exceptions')

How can I make the missing builtins available to my embedded interpreter?

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

From merllab at microsoft.com  Wed Jul 15 17:52:53 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Wed, 15 Jul 2009 08:52:53 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <e25df8e7-28cc-419a-b79c-572210d17a68@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56532.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/Tests/plans/generic_plan_template.py

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Tests/plans/generic_plan_template.py

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 996184
Date: 7/14/2009 5:59:01 PM

generic_plan_template.py, as its name would imply, is a generic test plan template written entirely in Python docstrings.






From dinov at microsoft.com  Wed Jul 15 18:06:58 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 15 Jul 2009 16:06:58 +0000
Subject: [IronPython] FePy status update
In-Reply-To: <5b0248170907150043m3241e1fcmfd48b4d2015ee581@mail.gmail.com>
References: <5b0248170907150043m3241e1fcmfd48b4d2015ee581@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03477028@TK5EX14MBXC116.redmond.corp.microsoft.com>

We recently made the call that Microsoft.Dynamic's API surface would ship in .NET 4 as all internal API surface.  It's still open source so anyone can pick it up and include it in their own languages to get COM support but C# needs it in the box somewhere so they can provide COM support as well.  But we're not really sure what we want .NET COM support to look like long term yet so we don't want to commit to shipping the API forever just yet.  The CLR2 flag allows us to build it as publicly accessible APIs on .NET 2/3/3.5 and build it as internal APIs in our internal builds for .NET 4.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Seo Sanghyeon [sanxiyn at gmail.com]
Sent: Wednesday, July 15, 2009 2:43 AM
To: Discussion of IronPython
Subject: [IronPython] FePy status update

Now I updated FePy's NAnt build file to include newly introduced
Microsoft.System.Debugging.dll.

I also found that I need to define CLR2 symbol to compile
Microsoft.Dynamic.dll. Without the symbol it won't compile. What is
the purpose of this symbol?

Sorry for the delay,

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


From dinov at microsoft.com  Wed Jul 15 18:09:26 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 15 Jul 2009 16:09:26 +0000
Subject: [IronPython] sys.builtin_module_names and embedding
In-Reply-To: <f9cdf5cb0907150757r1175d9a2m89ebea5e480e31d1@mail.gmail.com>
References: <f9cdf5cb0907150757r1175d9a2m89ebea5e480e31d1@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03477037@TK5EX14MBXC116.redmond.corp.microsoft.com>

IronPython.Modules.dll is probably not being copied for your host application.  It should be next to IronPython.dll.  If it's not available then we'll just continue to run w/o the modules available.

________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Mads Weitling [mads.weitling at gmail.com]
Sent: Wednesday, July 15, 2009 9:57 AM
To: users at lists.ironpython.com
Subject: [IronPython] sys.builtin_module_names and embedding


I am trying to run som IronPython code using the 2.6b1 hosting API but cannot seem to import the basic 'builtins' defined in IronPython.Modules.dll from my IronPython host.

When using ipy.exe, things work fine:

ipy.exe -v
>>> import sys
>>> sys.builtin_module_names
('clr', 'future_builtins', 'sys', '__builtin__', 'exceptions', '_weakref', '_struct', '_winreg', '_warnings', '_sre', '_random', '_functools', 'xxsubtype', 'time', 'thread', '_heapq', '_ctypes_test', '_ctypes', 'socket', '_sha512', '_sha256', '_sha', 'select', 're', 'operator', 'nt', '_md5', 'math', 'marshal', '_locale', 'itertools', 'imp', 'gc', 'errno', 'datetime', 'cStringIO', 'cPickle', 'copy_reg', '_collections', '_codecs', 'cmath', 'binascii', 'array')

Running from an embedded IronPython, I see only a few builtins:

('clr', 'future_builtins', 'sys', '__builtin__', 'exceptions')

How can I make the missing builtins available to my embedded interpreter?

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

From calmasy at gmail.com  Wed Jul 15 19:13:14 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Wed, 15 Jul 2009 11:13:14 -0600
Subject: [IronPython] IronPython support needed in MonoDevelop
Message-ID: <abb783b90907151013v31e470c6xe1171faa5d4fafe2@mail.gmail.com>

MonoDevelop is the IDE of choice for .NET languages on Linux. But
currently there's no IronPython support for it. There are a couple
starting points available in the svn sources, but someone would need
to take a fresh look at it and write a new IronPython binding.

Anyway, if there's any initiative to increase IronPython use on
non-Windows platforms, this might be one way to help that.

Some references--

* http://monodevelop.com/
* http://lists.ximian.com/pipermail/monodevelop-list/2009-July/009964.html

-- 
Cheers, L?szl?


From fuzzyman at voidspace.org.uk  Fri Jul 17 14:34:20 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 17 Jul 2009 13:34:20 +0100
Subject: [IronPython] Access to current Python engine in C# (Silverlight)
In-Reply-To: <4A118C55.8020502@voidspace.org.uk>
References: <4A0581F2.6010603@voidspace.org.uk>	<4A102CD2.40108@voidspace.org.uk>	<4A11811D.7010406@voidspace.org.uk>
	<4A118C55.8020502@voidspace.org.uk>
Message-ID: <4A606FCC.1050609@voidspace.org.uk>

I never got a reply to this. The C# code below throws an import error 
and I want to know if this is my fault or a problem with the IronPython 
/ Silverlight integration.

Michael

Michael Foord wrote:
> Ha - dammit, no.
>
> With Silverlight this still throws an ImportError when embedded Python 
> code executed from C# like this tries to import from the xap file. :-(
>
> Michael
>
> Michael Foord wrote:
>> Thanks to some help from William Reade, this code *seems* to work 
>> fine. I need to try it from Silverlight and check the Python code it 
>> contains is able to import:
>>
>> using System;
>> using System.Collections.Generic;
>> using System.Text;
>>
>>
>> using IronPython.Hosting;
>> using IronPython.Runtime;
>> using IronPython.Runtime.Types;
>>
>> using Microsoft.Scripting;
>> using Microsoft.Scripting.Hosting;
>> using Microsoft.Scripting.Runtime;
>>
>>
>> namespace ExecutePython
>> {
>>    public class ExecutePython
>>    {
>>        static string code = @"
>> class Foo(object):
>>    attribute = 'weeeee'
>>
>> ";
>>        public static Scope CreateModule(CodeContext context)
>>        {
>>            PythonContext python = PythonContext.GetContext(context);
>>
>>            PythonDictionary globals = new PythonDictionary();
>>            globals["__name__"] = "AModule";
>>            Scope module = new Scope(globals);
>>            SourceUnit script = python.CreateSnippet(code, 
>> SourceCodeKind.Statements);
>>            script.Execute(module);
>>            return module;
>>        }
>>    }
>> }
>>
>>
>> All the best,
>>
>>
>> Michael
>>
>>
>> Michael Foord wrote:
>>> Jimmy - did you get a chance to look at this?
>>>
>>> If the code shown below *genuinely* gets a reference to the current 
>>> engine then shouldn't the search path be setup already?
>>>
>>> Can you see what is wrong with the code below?
>>>
>>> Thanks
>>>
>>> Michael
>>>
>>> Michael Foord wrote:
>>>> Hello guys,
>>>>
>>>> I have a second use case for embedding IronPython in Silverlight. 
>>>> This is actually a dynamic application with a C# component that 
>>>> needs to programattically build a Python module.
>>>>
>>>> Again I have the same problem - imports in Python code fail. I 
>>>> would have expected that accessing the current runtime and fetching 
>>>> a Python engine would fetch the current Python engine, with the 
>>>> browser host correctly setup. Unfortunately that seems not to be 
>>>> the case. Can anyone spot problems with the following code:
>>>>
>>>>
>>>> using Microsoft.Scripting.Silverlight;
>>>> using IronPython;
>>>> using IronPython.Hosting;
>>>> using Microsoft.Scripting;
>>>> using Microsoft.Scripting.Hosting;
>>>>
>>>> namespace EmbeddedSLModule
>>>> {
>>>>    public class EmbeddedSLModule
>>>>    {
>>>>        private static string source = @"
>>>> import something
>>>> ";
>>>>        public static ScriptScope GetModule(){
>>>>            ScriptRuntime runtime = DynamicApplication.Current.Runtime;
>>>>            ScriptEngine engine = runtime.GetEngine("Python");
>>>>            ScriptScope scope = engine.CreateScope();
>>>>            ScriptSource script = 
>>>> engine.CreateScriptSourceFromString(source, 
>>>> SourceCodeKind.Statements);
>>>>            script.Execute(scope);
>>>>
>>>>            return scope;
>>>>
>>>>        }
>>>>    }
>>>> }
>>>>
>>>>
>>>> It works fine for code that doesn't import anything - but imports 
>>>> from within the xap file fail.
>>>>
>>>> Thanks
>>>>
>>>> Michael Foord
>>>>
>>>
>>>
>>
>>
>
>


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



From dfugate at microsoft.com  Fri Jul 17 20:33:09 2009
From: dfugate at microsoft.com (dfugate at microsoft.com)
Date: Fri, 17 Jul 2009 11:33:09 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <9c587447-7cca-4e8d-9546-44d1342e399a@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56669.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Settings.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicAppManifest.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserVirtualFilesystem.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicEngine.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.Generated.cs

DELETED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Extension.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Configuration.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Package.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserPAL.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Settings.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicAppManifest.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserVirtualFilesystem.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicEngine.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Repl.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_codecs.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/PointerType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtr.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/Field.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/_ctypes.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/UnionType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleCData.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/CFuncPtrType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/Array.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/INativeType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/Pointer.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/SimpleType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/ArrayType.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/StructType.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/App.config
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserScriptHost.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/AppManifestTemplate.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Microsoft.Scripting.Silverlight.csproj
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/ErrorFormatter.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/XapBuilder.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicApplication.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Chiron.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/IFastInvokable.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_collections.cs
	$/IronPython/IronPython_Main/Config/Unsigned/App.config
	$/IronPython/IronPython_Main/Config/Signed/App.config
	$/IronPython/IronPython_Main/Src/App.config
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/Python.cs
	$/IronPython/IronPython_Main/Src/AssemblyVersion.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/PythonOptionsParser.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/PythonCommandLine.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstGenerator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.Generated.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonOptions.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaPythonType.Calls.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Descriptors.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonDictionary.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/ObjectOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/StringOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/InstanceOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/List.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Set.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Readme.html
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Tests/DlrComLibrary/IndexedProp.cpp
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Math/BigInteger.cs
	$/IronPython/IronPython_Main/Src/Tests/Inputs/RemoteConsole.py
	$/IronPython/IronPython_Main/Src/Scripts/generate_calls.py
	$/IronPython/IronPython_Main/Src/Scripts/generate.py
	$/IronPython/IronPython_Main/Src/Tests/Modes/ConsoleHelp.Debug.out
	$/IronPython/IronPython_Main/Src/Tests/Modes/ConsoleHelp.Release.out
	$/IronPython/IronPython_Main/Src/Tests/Modes/ConsoleFlags.ps1
	$/IronPython/IronPython_Main/Src/Tests/test_class.py
	$/IronPython/IronPython_Main/Src/Tests/test_str.py
	$/IronPython/IronPython_Main/Src/Tests/versions/python26.py

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1001128
Date: 7/15/2009 5:31:19 PM

(dinov) Fixes:
19585 2.6: object.__init__ should not accept arbitrary arguments (http://bugs.python.org/issue1683368) 
	This adds the appropriate checks to object.__init__.  We now cache whether or not __init__ / __new__ is object.__init__ / object.__new__ in types and update it when it changes.  We don?t invalidate this cache when the values are deleted to match the current (buggy?  I?ve sent a mail to python-dev) CPython behavior.  This change also showed several different types that didn?t have their ctors defined quite right.  List/set/deque all need new?s.   Also added some overloads so that we don?t need to construct params arrays / kw dicts.   Switched to using  a shared lock when updating subtypes so traversing the subclass hierarchy can?t get into weird lock ordering issues.

23499 String Formatting Operations error
	PythonDict.TryGetValue should call __missing__ if it?s defined ? this is just moving the code from GetItem.

Also adds pre-compiled rules for creating types.  The code to support this lives in PythonType.Generated.cs and PythonType becomes IFastInvokable.  These support a subset of the full path ? basically just calling classes that only have default ctors where the type may have user defined __new__ or __init__ if they?re just simple functions.  Also making the BuiltinFunction?s used to call the base class ctor to be shared between all subtypes.  Combined this gives around a 10-15% improvement on ParrotBench which should bring is back to where we were before auto-templating was removed.



(Shelveset: TypeCtorsFinal;REDMOND\dinov | SNAP CheckinId: m9707)
--------------------------------------------------------------------------------
Changeset Id: 1001127
Date: 7/15/2009 5:29:52 PM

(dinov) Updates assembly versions for the 2.6B2 release.  Versions are rev?d to 2.6.0.20 / 0.9.6.20.

This effects IronPython, DLR (including the inner layer w/ updates to files that don?t effect the System.Core build).



(Shelveset: UpdateVersions262_Final;REDMOND\dinov | SNAP CheckinId: m9707)
--------------------------------------------------------------------------------
Changeset Id: 1000980
Date: 7/15/2009 4:17:29 PM

(dinov) Fixes a few lifetime management issues w/ ctypes and adds a ?X:GCStress command line option to help flush issues like these out.

These fixes all come from a run of test_ctypes.py under ?X:GCStress 2 mode.  This forces a full gen-2 collection for every single Python statement.  For the most part the issues are all things which test_ctypes is actually testing for but we didn?t see before due to our GC taking some time to kick in.  There?s still 1 remaining failure under ?X:GCStress mode but that is a test issue (they read from invalid memory and don?t even expect to get a valid value back).

This also fixes 64-bit ctypes by properly defining the code in a dynamic method (previously the #ifdef?s were switched so we would define it into a type).  To test 64-bit I had to add our own version of _ctypes_test.cpp because the CRT makes picking up and running w/ CPython?s _ctypes_test.pyd I huge pain.   We now pass all of the tests on 64-bit.  For one of the functions in _ctypes_test I don?t know how to implement it so it just returns the value the test is expecting for the time being.

I?ve also fixed print(None).

23132    1              High       print(None) broken        IronPython\2.6 Beta 2                   
22900    1              High       _ctypes largely broken under x64 OSes IronPython\2.6 dinov_cp             




(Shelveset: CtypesAndGCStressFinal;REDMOND\dinov | SNAP CheckinId: m9704)
--------------------------------------------------------------------------------
Changeset Id: 998550
Date: 7/15/2009 12:50:14 PM

(dfugate) Fixed a couple of PoliCheck violations, and we now run PoliCheck on (IronPython) CodePlex zips for every SNAP checkin.


(Shelveset: IP_POLI01;REDMOND\dfugate | SNAP CheckinId: 8918)
--------------------------------------------------------------------------------
Changeset Id: 996184
Date: 7/14/2009 5:59:01 PM

generic_plan_template.py, as its name would imply, is a generic test plan template written entirely in Python docstrings.

--------------------------------------------------------------------------------
Changeset Id: 1001127
Date: 7/15/2009 5:29:52 PM

(dinov) Updates assembly versions for the 2.6B2 release.  Versions are rev?d to 2.6.0.20 / 0.9.6.20.

This effects IronPython, DLR (including the inner layer w/ updates to files that don?t effect the System.Core build).



(Shelveset: UpdateVersions262_Final;REDMOND\dinov | SNAP CheckinId: m9707)
--------------------------------------------------------------------------------
Changeset Id: 997783
Date: 7/15/2009 11:39:21 AM

(dfugate) checkin_comments.py:
- adjusted get_recent_comments to look for checkin comments in multiple directories within a TFS enlistment
- added 'Hosts\Silverlight' to the list of blessed directories that trigger IronPython Mailing List changeset descriptions

Added a single whitespace to Hosts\Silverlight\README.markdown to test out the change above.


(Shelveset: SL_COMMENTS;REDMOND\dfugate | SNAP CheckinId: 8917)


From bruce.bromberek at gmail.com  Fri Jul 17 22:07:56 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Fri, 17 Jul 2009 15:07:56 -0500
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
Message-ID: <58ad4a110907171307o5db93cdcnea0ff80ba83154ff@mail.gmail.com>

Kelie-

I just went through this process recently myself.

My rules of thumb are as follows:

*When building the App:*

Look at your references to the 5 ironpython DLLs.  Decide right now:  Are
you going to use the ones that ship with SharpDevelop or the ones using that
come with IronPython.  Choose one and be consistent.

I'm still working though how to Build a WIX installer project , so I
currently ZIP up the release folder generated by SharpDevelop and make sure
everything is there.  Here's an example for a simple program I have
distributed to coworkers.

AIIMTool.dll
AIIMTool.exe
ICSharpCode.SharpZipLib.dll
IronMath.dll
IronPython.dll
IronPython.Modules.dll
IronPythonTest.dll
Microsoft.Scripting.Core.dll
Microsoft.Scripting.dll
Microsoft.Scripting.ExtensionAttribute.dll
*
Make sure the Target machine has been upgraded to .Net 3.5 SP1.  Don't take
any flack - make them upgrade.*

*Make sure they are not running on a network share.  Weird things with trust
can happen with shares.  See my recent cry for help on this list for more
info.*

-Bruce

On Fri, Jul 10, 2009 at 1:34 AM, Kelie <kf9150 at gmail.com> wrote:

> Hello,
>
> I created a simple program with a few buttons, checkboxes, textboxes,
> etc. and it worked fine. The form was created in the latest
> SharpDevelop beta version (Version : 3.1.0.4077). Then I compiled the
> solution. In the release folder there were these files:
>
> IronPython.dll
> ManningsSolver.dll
> ManningsSolver.exe
> Microsoft.Scripting.Core.dll
> Microsoft.Scripting.dll
> Microsoft.Scripting.ExtensionAttribute.dll
>
> When tried on two computers with IronPython installed and with the
> source code files, the program worked. But it failed on another
> computer that does not have these. And error message was very
> generic .NET error. I don't exactly remember what it was. Is this
> normal?
>
> Btw, since I have SharpDevelop installed, do I have to install
> IronPython in order to write programs in IronPython? Or does it matter
> which version of IronPython I install. The answer seems to be "No"
> because I see those .dll files for IronPython in this folder "C:
> \Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings
> \PythonBinding" which are dated Feb 2009. Guess they're not the
> latest.
>
> Thanks,
>
> Kelie
>
> _______________________________________________
> 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/20090717/58b228c0/attachment.html>

From fuzzyman at voidspace.org.uk  Fri Jul 17 22:55:02 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 17 Jul 2009 21:55:02 +0100
Subject: [IronPython] Issue 22239 closed as 'by design'
Message-ID: <4A60E526.1060705@voidspace.org.uk>

Issue 22239 has been closed as 'by design'.

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239&ProjectName=IronPython

Dino described this as a serious bug when it was pointed out and it is 
both extremely unintuitive and problematic - why should separate scopes 
(modules) be linked this way when used from the hosting API?

This seems like a very odd decision.

All the best,

Michael Foord

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




From Jimmy.Schementi at microsoft.com  Fri Jul 17 23:22:25 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Fri, 17 Jul 2009 21:22:25 +0000
Subject: [IronPython] Access to current Python engine in C# (Silverlight)
In-Reply-To: <4A606FCC.1050609@voidspace.org.uk>
References: <4A0581F2.6010603@voidspace.org.uk>
	<4A102CD2.40108@voidspace.org.uk>	<4A11811D.7010406@voidspace.org.uk>
	<4A118C55.8020502@voidspace.org.uk> <4A606FCC.1050609@voidspace.org.uk>
Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC18B55E18@tk5ex14mbxc105.redmond.corp.microsoft.com>

Michael,

Oh, sorry to leave you hanging. Here's a SL3 VS solution which imports a python file from C#: http://jimmy.schementi.com/silverlight/foord-repro.zip

// App.xaml.cs
public class EmbeddedSLModule {
        public static ScriptScope GetModule() {
            var pyfile = "toimport.py";
            ScriptEngine engine = new ScriptRuntime(DynamicEngine.CreateRuntimeSetup(true)).GetEngine("IronPython");
            var code = new XapVirtualFilesystem().GetFileContents(pyfile);
            ScriptScope scope = engine.CreateScope();
            ScriptSource script = engine.CreateScriptSourceFromString(code, pyfile);
            script.Execute(scope);
            return scope;
        }
}

<!-- MainPage.xaml -->
<UserControl x:Class="foord_repro.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" >
  <Grid x:Name="LayoutRoot">
        <TextBlock x:Name="Message" />
  </Grid>
</UserControl>

# toimport.py
import something

# something.py
import clr
clr.AddReference("System.Windows")
from System.Windows import Application
Application.Current.RootVisual.FindName("Message").Text = "Hi from IronPython!"

The binaries are the latest in the IronPython codeplex source tree, but are also included in the zip.

For the "CreateModule" example, where does that have to do with importing from the XAP file? If you give me an example working on the desktop, I'll see if any modifications need to be made to work in SL, but if this doesn't work in SL it would seem to be a bug in IronPython.

~js

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, July 17, 2009 5:34 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Access to current Python engine in C# (Silverlight)
>
> I never got a reply to this. The C# code below throws an import error and I
> want to know if this is my fault or a problem with the IronPython / Silverlight
> integration.
>
> Michael
>
> Michael Foord wrote:
> > Ha - dammit, no.
> >
> > With Silverlight this still throws an ImportError when embedded Python
> > code executed from C# like this tries to import from the xap file. :-(
> >
> > Michael
> >
> > Michael Foord wrote:
> >> Thanks to some help from William Reade, this code *seems* to work
> >> fine. I need to try it from Silverlight and check the Python code it
> >> contains is able to import:
> >>
> >> using System;
> >> using System.Collections.Generic;
> >> using System.Text;
> >>
> >>
> >> using IronPython.Hosting;
> >> using IronPython.Runtime;
> >> using IronPython.Runtime.Types;
> >>
> >> using Microsoft.Scripting;
> >> using Microsoft.Scripting.Hosting;
> >> using Microsoft.Scripting.Runtime;
> >>
> >>
> >> namespace ExecutePython
> >> {
> >>    public class ExecutePython
> >>    {
> >>        static string code = @"
> >> class Foo(object):
> >>    attribute = 'weeeee'
> >>
> >> ";
> >>        public static Scope CreateModule(CodeContext context)
> >>        {
> >>            PythonContext python = PythonContext.GetContext(context);
> >>
> >>            PythonDictionary globals = new PythonDictionary();
> >>            globals["__name__"] = "AModule";
> >>            Scope module = new Scope(globals);
> >>            SourceUnit script = python.CreateSnippet(code,
> >> SourceCodeKind.Statements);
> >>            script.Execute(module);
> >>            return module;
> >>        }
> >>    }
> >> }
> >>
> >>
> >> All the best,
> >>
> >>
> >> Michael
> >>
> >>
> >> Michael Foord wrote:
> >>> Jimmy - did you get a chance to look at this?
> >>>
> >>> If the code shown below *genuinely* gets a reference to the current
> >>> engine then shouldn't the search path be setup already?
> >>>
> >>> Can you see what is wrong with the code below?
> >>>
> >>> Thanks
> >>>
> >>> Michael
> >>>
> >>> Michael Foord wrote:
> >>>> Hello guys,
> >>>>
> >>>> I have a second use case for embedding IronPython in Silverlight.
> >>>> This is actually a dynamic application with a C# component that
> >>>> needs to programattically build a Python module.
> >>>>
> >>>> Again I have the same problem - imports in Python code fail. I
> >>>> would have expected that accessing the current runtime and fetching
> >>>> a Python engine would fetch the current Python engine, with the
> >>>> browser host correctly setup. Unfortunately that seems not to be
> >>>> the case. Can anyone spot problems with the following code:
> >>>>
> >>>>
> >>>> using Microsoft.Scripting.Silverlight; using IronPython; using
> >>>> IronPython.Hosting; using Microsoft.Scripting; using
> >>>> Microsoft.Scripting.Hosting;
> >>>>
> >>>> namespace EmbeddedSLModule
> >>>> {
> >>>>    public class EmbeddedSLModule
> >>>>    {
> >>>>        private static string source = @"
> >>>> import something
> >>>> ";
> >>>>        public static ScriptScope GetModule(){
> >>>>            ScriptRuntime runtime = DynamicApplication.Current.Runtime;
> >>>>            ScriptEngine engine = runtime.GetEngine("Python");
> >>>>            ScriptScope scope = engine.CreateScope();
> >>>>            ScriptSource script =
> >>>> engine.CreateScriptSourceFromString(source,
> >>>> SourceCodeKind.Statements);
> >>>>            script.Execute(scope);
> >>>>
> >>>>            return scope;
> >>>>
> >>>>        }
> >>>>    }
> >>>> }
> >>>>
> >>>>
> >>>> It works fine for code that doesn't import anything - but imports
> >>>> from within the xap file fail.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Michael Foord
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From fuzzyman at voidspace.org.uk  Fri Jul 17 23:24:27 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 17 Jul 2009 22:24:27 +0100
Subject: [IronPython] Access to current Python engine in C# (Silverlight)
In-Reply-To: <0047ECBFA2E0DF4A834AA369282A5AFC18B55E18@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <4A0581F2.6010603@voidspace.org.uk>	<4A102CD2.40108@voidspace.org.uk>	<4A11811D.7010406@voidspace.org.uk>	<4A118C55.8020502@voidspace.org.uk>
	<4A606FCC.1050609@voidspace.org.uk>
	<0047ECBFA2E0DF4A834AA369282A5AFC18B55E18@tk5ex14mbxc105.redmond.corp.microsoft.com>
Message-ID: <4A60EC0B.5020502@voidspace.org.uk>

Jimmy Schementi wrote:
> Michael,
>
> Oh, sorry to leave you hanging. Here's a SL3 VS solution which imports a python file from C#: http://jimmy.schementi.com/silverlight/foord-repro.zip
>   

Thanks - the goal is actually to import a Python module using the 
*current* Python engine without creating a new one (hence the use of the 
PythonContext).

Thanks

Michael

> // App.xaml.cs
> public class EmbeddedSLModule {
>         public static ScriptScope GetModule() {
>             var pyfile = "toimport.py";
>             ScriptEngine engine = new ScriptRuntime(DynamicEngine.CreateRuntimeSetup(true)).GetEngine("IronPython");
>             var code = new XapVirtualFilesystem().GetFileContents(pyfile);
>             ScriptScope scope = engine.CreateScope();
>             ScriptSource script = engine.CreateScriptSourceFromString(code, pyfile);
>             script.Execute(scope);
>             return scope;
>         }
> }
>
> <!-- MainPage.xaml -->
> <UserControl x:Class="foord_repro.MainPage"
>     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>     xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" >
>   <Grid x:Name="LayoutRoot">
>         <TextBlock x:Name="Message" />
>   </Grid>
> </UserControl>
>
> # toimport.py
> import something
>
> # something.py
> import clr
> clr.AddReference("System.Windows")
> from System.Windows import Application
> Application.Current.RootVisual.FindName("Message").Text = "Hi from IronPython!"
>
> The binaries are the latest in the IronPython codeplex source tree, but are also included in the zip.
>
> For the "CreateModule" example, where does that have to do with importing from the XAP file? If you give me an example working on the desktop, I'll see if any modifications need to be made to work in SL, but if this doesn't work in SL it would seem to be a bug in IronPython.
>
> ~js
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, July 17, 2009 5:34 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Access to current Python engine in C# (Silverlight)
>>
>> I never got a reply to this. The C# code below throws an import error and I
>> want to know if this is my fault or a problem with the IronPython / Silverlight
>> integration.
>>
>> Michael
>>
>> Michael Foord wrote:
>>     
>>> Ha - dammit, no.
>>>
>>> With Silverlight this still throws an ImportError when embedded Python
>>> code executed from C# like this tries to import from the xap file. :-(
>>>
>>> Michael
>>>
>>> Michael Foord wrote:
>>>       
>>>> Thanks to some help from William Reade, this code *seems* to work
>>>> fine. I need to try it from Silverlight and check the Python code it
>>>> contains is able to import:
>>>>
>>>> using System;
>>>> using System.Collections.Generic;
>>>> using System.Text;
>>>>
>>>>
>>>> using IronPython.Hosting;
>>>> using IronPython.Runtime;
>>>> using IronPython.Runtime.Types;
>>>>
>>>> using Microsoft.Scripting;
>>>> using Microsoft.Scripting.Hosting;
>>>> using Microsoft.Scripting.Runtime;
>>>>
>>>>
>>>> namespace ExecutePython
>>>> {
>>>>    public class ExecutePython
>>>>    {
>>>>        static string code = @"
>>>> class Foo(object):
>>>>    attribute = 'weeeee'
>>>>
>>>> ";
>>>>        public static Scope CreateModule(CodeContext context)
>>>>        {
>>>>            PythonContext python = PythonContext.GetContext(context);
>>>>
>>>>            PythonDictionary globals = new PythonDictionary();
>>>>            globals["__name__"] = "AModule";
>>>>            Scope module = new Scope(globals);
>>>>            SourceUnit script = python.CreateSnippet(code,
>>>> SourceCodeKind.Statements);
>>>>            script.Execute(module);
>>>>            return module;
>>>>        }
>>>>    }
>>>> }
>>>>
>>>>
>>>> All the best,
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>> Michael Foord wrote:
>>>>         
>>>>> Jimmy - did you get a chance to look at this?
>>>>>
>>>>> If the code shown below *genuinely* gets a reference to the current
>>>>> engine then shouldn't the search path be setup already?
>>>>>
>>>>> Can you see what is wrong with the code below?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Michael
>>>>>
>>>>> Michael Foord wrote:
>>>>>           
>>>>>> Hello guys,
>>>>>>
>>>>>> I have a second use case for embedding IronPython in Silverlight.
>>>>>> This is actually a dynamic application with a C# component that
>>>>>> needs to programattically build a Python module.
>>>>>>
>>>>>> Again I have the same problem - imports in Python code fail. I
>>>>>> would have expected that accessing the current runtime and fetching
>>>>>> a Python engine would fetch the current Python engine, with the
>>>>>> browser host correctly setup. Unfortunately that seems not to be
>>>>>> the case. Can anyone spot problems with the following code:
>>>>>>
>>>>>>
>>>>>> using Microsoft.Scripting.Silverlight; using IronPython; using
>>>>>> IronPython.Hosting; using Microsoft.Scripting; using
>>>>>> Microsoft.Scripting.Hosting;
>>>>>>
>>>>>> namespace EmbeddedSLModule
>>>>>> {
>>>>>>    public class EmbeddedSLModule
>>>>>>    {
>>>>>>        private static string source = @"
>>>>>> import something
>>>>>> ";
>>>>>>        public static ScriptScope GetModule(){
>>>>>>            ScriptRuntime runtime = DynamicApplication.Current.Runtime;
>>>>>>            ScriptEngine engine = runtime.GetEngine("Python");
>>>>>>            ScriptScope scope = engine.CreateScope();
>>>>>>            ScriptSource script =
>>>>>> engine.CreateScriptSourceFromString(source,
>>>>>> SourceCodeKind.Statements);
>>>>>>            script.Execute(scope);
>>>>>>
>>>>>>            return scope;
>>>>>>
>>>>>>        }
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> It works fine for code that doesn't import anything - but imports
>>>>>> from within the xap file fail.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Michael Foord
>>>>>>
>>>>>>             
>>>>>           
>>>>         
>>>       
>> --
>> http://www.ironpythoninaction.com/
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From curt at hagenlocher.org  Fri Jul 17 23:26:18 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Fri, 17 Jul 2009 14:26:18 -0700
Subject: [IronPython] Issue 22239 closed as 'by design'
In-Reply-To: <4A60E526.1060705@voidspace.org.uk>
References: <4A60E526.1060705@voidspace.org.uk>
Message-ID: <d2155e360907171426s21849b0ey21e0d23c46318234@mail.gmail.com>

I believe this was fixed for 2.6, but that the fix is too disruptive to
backport (by a long shot!)

On Fri, Jul 17, 2009 at 1:55 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> Issue 22239 has been closed as 'by design'.
>
>
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239&ProjectName=IronPython
>
> Dino described this as a serious bug when it was pointed out and it is both
> extremely unintuitive and problematic - why should separate scopes (modules)
> be linked this way when used from the hosting API?
>
> This seems like a very odd decision.
>
> All the best,
>
> Michael Foord
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090717/765a8acc/attachment.html>

From fuzzyman at voidspace.org.uk  Fri Jul 17 23:27:10 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 17 Jul 2009 22:27:10 +0100
Subject: [IronPython] Issue 22239 closed as 'by design'
In-Reply-To: <d2155e360907171426s21849b0ey21e0d23c46318234@mail.gmail.com>
References: <4A60E526.1060705@voidspace.org.uk>
	<d2155e360907171426s21849b0ey21e0d23c46318234@mail.gmail.com>
Message-ID: <4A60ECAE.801@voidspace.org.uk>

Curt Hagenlocher wrote:
> I believe this was fixed for 2.6, but that the fix is too disruptive 
> to backport (by a long shot!)
Ah - so it is just the backport that is closed. Fair enough. Sorry for 
the noise.

Michael

>
> On Fri, Jul 17, 2009 at 1:55 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Issue 22239 has been closed as 'by design'.
>
>     http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239&ProjectName=IronPython
>     <http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239&ProjectName=IronPython>
>
>     Dino described this as a serious bug when it was pointed out and
>     it is both extremely unintuitive and problematic - why should
>     separate scopes (modules) be linked this way when used from the
>     hosting API?
>
>     This seems like a very odd decision.
>
>     All the best,
>
>     Michael Foord
>
>     -- 
>     http://www.ironpythoninaction.com/
>     http://www.voidspace.org.uk/blog
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>     http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From dinov at microsoft.com  Fri Jul 17 23:32:32 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 17 Jul 2009 21:32:32 +0000
Subject: [IronPython] Issue 22239 closed as 'by design'
In-Reply-To: <4A60ECAE.801@voidspace.org.uk>
References: <4A60E526.1060705@voidspace.org.uk>
	<d2155e360907171426s21849b0ey21e0d23c46318234@mail.gmail.com>
	<4A60ECAE.801@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03487BD6@TK5EX14MBXC116.redmond.corp.microsoft.com>

Michael wrote:
> Curt Hagenlocher wrote:
> > I believe this was fixed for 2.6, but that the fix is too disruptive
> > to backport (by a long shot!)
> Ah - so it is just the backport that is closed. Fair enough. Sorry for
> the noise.

Actually the title is just wrong - this was fixed in 2.0.2 (it's a simpler
fix then what went into 2.6 which included some additional cleanup though).




From curt at hagenlocher.org  Fri Jul 17 23:32:50 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Fri, 17 Jul 2009 14:32:50 -0700
Subject: [IronPython] Issue 22239 closed as 'by design'
In-Reply-To: <d2155e360907171426s21849b0ey21e0d23c46318234@mail.gmail.com>
References: <4A60E526.1060705@voidspace.org.uk>
	<d2155e360907171426s21849b0ey21e0d23c46318234@mail.gmail.com>
Message-ID: <d2155e360907171432t38775004seb965e38a1a46a8e@mail.gmail.com>

...and here's a reference to the original thread
http://www.mail-archive.com/users at lists.ironpython.com/msg08978.html

On Fri, Jul 17, 2009 at 2:26 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> I believe this was fixed for 2.6, but that the fix is too disruptive to
> backport (by a long shot!)
>
>
> On Fri, Jul 17, 2009 at 1:55 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:
>
>> Issue 22239 has been closed as 'by design'.
>>
>>
>> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239&ProjectName=IronPython
>>
>> Dino described this as a serious bug when it was pointed out and it is
>> both extremely unintuitive and problematic - why should separate scopes
>> (modules) be linked this way when used from the hosting API?
>>
>> This seems like a very odd decision.
>>
>> All the best,
>>
>> Michael Foord
>>
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090717/c7e102cc/attachment.html>

From jwiles at webworks.com  Sat Jul 18 00:04:55 2009
From: jwiles at webworks.com (Jesse Wiles)
Date: Fri, 17 Jul 2009 17:04:55 -0500
Subject: [IronPython] How to set __name__ for scriptengine instance?
Message-ID: <6a6c05630907171504x36178aecm5ed4b80372cd202@mail.gmail.com>

Hi,
I looked in the archives a bit but nothing jumped out.  I'm trying to
figure out how to set the __name__ for an embedded engine instance.
Here's what I'm working with...

      // I'm guessing here; not sure what these options should be and
it was not obvious in tracing through the source
      //
?? ? ?Dictionary<string, object> options = new Dictionary<string, object>();
? ? ? options["ExceptionDetail"] = true;
? ? ? options["ShowClrExceptions"] = true;

? ? ? ScriptEngine engine = Python.CreateEngine(options);

      // Again, grasping at straws...
      //
? ? ? IAttributesCollection symbols = new SymbolDictionary();
? ? ? symbols[Symbols.Name] = "__main__";
? ? ? ScriptScope scope = engine.CreateScope(symbols);

? ? ? scope.SetVariable("MyFooHash", new Dictionary<string, string>());

? ? ? engine.ExecuteFile(this.mPathTextBox.Text, scope);

Thanks,
Jesse Wiles


From fuzzyman at voidspace.org.uk  Sat Jul 18 00:06:51 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 17 Jul 2009 23:06:51 +0100
Subject: [IronPython] How to set __name__ for scriptengine instance?
In-Reply-To: <6a6c05630907171504x36178aecm5ed4b80372cd202@mail.gmail.com>
References: <6a6c05630907171504x36178aecm5ed4b80372cd202@mail.gmail.com>
Message-ID: <4A60F5FB.3000901@voidspace.org.uk>

Jesse Wiles wrote:
> Hi,
> I looked in the archives a bit but nothing jumped out.  I'm trying to
> figure out how to set the __name__ for an embedded engine instance.
> Here's what I'm working with...
>   

__name__ should be set per scope. How about:

    scope.SetVariable("__name__", "__main__");

Michael
>       // I'm guessing here; not sure what these options should be and
> it was not obvious in tracing through the source
>       //
>       Dictionary<string, object> options = new Dictionary<string, object>();
>       options["ExceptionDetail"] = true;
>       options["ShowClrExceptions"] = true;
>
>       ScriptEngine engine = Python.CreateEngine(options);
>
>       // Again, grasping at straws...
>       //
>       IAttributesCollection symbols = new SymbolDictionary();
>       symbols[Symbols.Name] = "__main__";
>       ScriptScope scope = engine.CreateScope(symbols);
>
>       scope.SetVariable("MyFooHash", new Dictionary<string, string>());
>
>       engine.ExecuteFile(this.mPathTextBox.Text, scope);
>
> Thanks,
> Jesse Wiles
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From dinov at microsoft.com  Sat Jul 18 00:12:19 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 17 Jul 2009 22:12:19 +0000
Subject: [IronPython] How to set __name__ for scriptengine instance?
In-Reply-To: <4A60F5FB.3000901@voidspace.org.uk>
References: <6a6c05630907171504x36178aecm5ed4b80372cd202@mail.gmail.com>
	<4A60F5FB.3000901@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03487EC6@TK5EX14MBXC116.redmond.corp.microsoft.com>

Michael wrote:
>
> Jesse Wiles wrote:
> > Hi,
> > I looked in the archives a bit but nothing jumped out.  I'm trying to
> > figure out how to set the __name__ for an embedded engine instance.
> > Here's what I'm working with...
> >
>
> __name__ should be set per scope. How about:
>
>     scope.SetVariable("__name__", "__main__");
>

The one gotcha here is that for a SourceCodeKind of File we will set
__name__ in the generated code.  Instead creating the code like:

var code = Engine.CreateScriptSourceFromFile(filename,
                                  Encoding.Default,
                                  SourceCodeKind.Statements);

code.Execute(scope);

should result in __name__ not being overwritten.


From dfugate at microsoft.com  Sat Jul 18 00:33:44 2009
From: dfugate at microsoft.com (dfugate at microsoft.com)
Date: Fri, 17 Jul 2009 15:33:44 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <55073be0-dcae-44d3-b406-b6e66baa5be2@tk5-exsmh-c102.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/56686.

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_ctypes/NativeFunctions.cs





From freecode at cox.net  Sat Jul 18 06:34:50 2009
From: freecode at cox.net (Brian Parma)
Date: Fri, 17 Jul 2009 21:34:50 -0700
Subject: [IronPython] IronPython+Gtk#+.NET?
Message-ID: <4A6150EA.70107@cox.net>

I've been trying to make a simple IronPython+Gtk# app that draws an 
image to the screen, and I'm having trouble getting it to run in windows 
(.NET).  It's pretty simple so I attached it at the end.

It runs fine in Mono on Ubuntu and Windows, but when I try to run it on 
windows using .NET I get the following error followed by a really long 
calltrace:

Marshaling expose_event signal
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to 
handle
the exception.
System.Reflection.TargetInvocationException: Exception has been thrown 
by the ta
rget of an invocation. ---> System.NotSupportedException: The invoked 
member is
not supported in a dynamic assembly.
   at System.Reflection.Emit.AssemblyBuilder.get_Location()
   at GLib.GType.LookupType(IntPtr typeid)
   at ...


I have the latest 'Gtk# for .NET' package from the Mono site, and I've 
tried with IP 2.0.1 and IP 2.6 Beta, they give the same results. 

I rewrote the program in C# and it works fine in .NET (without Mono), 
using #Develop IDE.

Is this possible?

code:

import clr
clr.AddReference('gtk-sharp')
clr.AddReference('gdk-sharp')
import Gtk
import Gdk


class MyWindow(Gtk.Window):
    def __init__(self, title='Main Window'):
        Gtk.Window.__init__(self, title)
       
        self.pb = Gdk.Pixbuf('image.jpg').ScaleSimple(600,436, 
Gdk.InterpType.Bilinear )
        self.da = Gtk.DrawingArea()
        self.da.SetSizeRequest(self.pb.Width, self.pb.Height)
        self.Add(self.da)
        self.Decorated = False
       
        self.DeleteEvent += self.delete_event       
        self.da.ExposeEvent += self.expose_event

    def expose_event(self, *args):
        self.da.GdkWindow.DrawPixbuf( 
self.Style.BackgroundGC(self.State), self.pb, 0, 0, 0, 0,-1, -1, 
Gdk.RgbDither.None, 0, 0)
       
    def delete_event(self, *args):
        Gtk.Application.Quit()


if __name__ in ['__main__','Program']:
    Gtk.Application.Init()
    mw = MyWindow('Test')
    mw.ShowAll()
    Gtk.Application.Run()



From calmasy at gmail.com  Sat Jul 18 08:32:04 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Sat, 18 Jul 2009 00:32:04 -0600
Subject: [IronPython] Trying to set field to bool,
	get "TypeError: Argument cannot be 	null."
Message-ID: <abb783b90907172332g15ea98c4i71a03e3757bbf64f@mail.gmail.com>

I need some help understanding what I'm doing wrong here.
Settings.ALWAYS_DECODE_OBJECTS is set in C# like the following:

public bool ALWAYS_DECODE_OBJECTS = true;

But trying to set it to "True" in IPy blows up with the following traceback:

IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference("OpenMetaverse.dll")
>>> clr.AddReference("OpenMetaverseTypes.dll")
>>> from OpenMetaverse import *
>>>
>>> Settings.ALWAYS_DECODE_OBJECTS = True
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Microsoft.Scripting.Core", line unknown, in Convert
  File "Microsoft.Scripting.Core", line unknown, in Convert
  File "Microsoft.Scripting.Core", line unknown, in RequiresCanRead
TypeError: Argument cannot be null.
Parameter name: expression
>>>

-- 
Cheers, L?szl?


From Jimmy.Schementi at microsoft.com  Sat Jul 18 12:34:20 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Sat, 18 Jul 2009 10:34:20 +0000
Subject: [IronPython] [Code Review] "XAP-less" Silverlight application
	support
Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC18B56732@tk5ex14mbxc105.redmond.corp.microsoft.com>

(Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)

http://github.com/jschementi/ironruby/commit/da6b54e226adfd3a18d8ad98d618c2350ebd8351

Beginnings of "XAP-less" Silverlight application support. Note: Silverlight apps are *required* to have a XAP file, but with this change it can get down to just a container for the AppManifest.xaml file. Python/Ruby would ship with a single XAP file pointing to the .slvx files for a given release.

Adds a "downloadScripts" initParam to indicate whether paths to script files and XAML files should be resolved to the web-server (relative to the XAP), if the file is not found in the XAP. Also adds "downloadScriptsFrom" to customize what path they are based off of. Because of the opt-in nature of this change, existing DLR Silverlight apps should not break.

Files are downloaded synchronously as code runs, by having the PlatformAdaptationLayer use a new BrowserVirtualFilesystem: HttpVirtualFilesystem. So when a language's include mechanism is used (require , load, import, etc), it will download the file by using XmlHttpRequest in synchronous mode. It will also cache each downloaded file's contents, so a file will only be downloaded once, even if it is included multiple times. Note: future work will hopefully allow asynchronous includes, so this can be production-ready. For now, it should only be used for development.

Note: this change decreases the need for Chiron significantly. In this mode, Chiron only creates a XAP file with the necessary assemblies and AppManifest.xaml, if it doesn't exist already. One could imagine providing a XAP file for each language, and then Chiron wouldn't be needed for development. However, for using the latest language assemblies, and auto-detection of languages used, it's still useful for development. So some changes have been made to Chiron to support this better:

A "localApplicationRoot" appSetting has been added to Chiron to adjust where it looks for script files (when determining what languages are used). This allows you to make sure Chiron is looking in the same place your application is downloading scripts or xaml from, so it can still generate a correct XAP file for you. "application/ruby" and "application/python" mime-types have been also added to Chiron also to enable downloading of those script files.

All of Chiron's appSettings are now override-able as command-line switches: /u[rlPrefix], /e[xtUrlPrefix], /l[ocalAppRoot]

Run Merlin/Main/Hosts/SilverLight/Tests/tests/manual/test_foox/run.bat for an example of how this works (it requires a Silverlight Debug build, so if you run Merlin/Main/Languages/Ruby/Scripts/Dev.bat, just run "bsd" and that will *b*uild *s*ilverlight in *d*ebug mode)

Adds a stub for similar support through IsolatedStorage, but that will come later.

Also tweaks the DynamicEngine.CreateRuntimeSetup method to better support other DLR-hosts in Silverlight (http://lists.ironpython.com/pipermail/users-ironpython.com/2009-July/010780.html).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: da6b54e226adfd3a18d8ad98d618c2350ebd8351.patch
Type: application/octet-stream
Size: 32900 bytes
Desc: da6b54e226adfd3a18d8ad98d618c2350ebd8351.patch
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090718/0a0a27b3/attachment.obj>

From dinov at microsoft.com  Sat Jul 18 20:45:54 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 18 Jul 2009 18:45:54 +0000
Subject: [IronPython] Trying to set field to bool,
 get "TypeError: Argument cannot be 	null."
In-Reply-To: <abb783b90907172332g15ea98c4i71a03e3757bbf64f@mail.gmail.com>
References: <abb783b90907172332g15ea98c4i71a03e3757bbf64f@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0348F03C@TK5EX14MBXC116.redmond.corp.microsoft.com>

I think you need an instance of Settings - e.g. Settings().ALWAYS_DECODE_OBJECTS.

That being said the exception you're getting is a bug - it should be telling you
that you need an instance.

I've created bug 23545: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23545



> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
> Sent: Friday, July 17, 2009 11:32 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] Trying to set field to bool, get "TypeError:
> Argument cannot be null."
>
> I need some help understanding what I'm doing wrong here.
> Settings.ALWAYS_DECODE_OBJECTS is set in C# like the following:
>
> public bool ALWAYS_DECODE_OBJECTS = true;
>
> But trying to set it to "True" in IPy blows up with the following
> traceback:
>
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import clr
> >>> clr.AddReference("OpenMetaverse.dll")
> >>> clr.AddReference("OpenMetaverseTypes.dll")
> >>> from OpenMetaverse import *
> >>>
> >>> Settings.ALWAYS_DECODE_OBJECTS = True
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "Microsoft.Scripting.Core", line unknown, in Convert
>   File "Microsoft.Scripting.Core", line unknown, in Convert
>   File "Microsoft.Scripting.Core", line unknown, in RequiresCanRead
> TypeError: Argument cannot be null.
> Parameter name: expression
> >>>
>
> --
> Cheers, L?szl?
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Sat Jul 18 21:00:24 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 18 Jul 2009 19:00:24 +0000
Subject: [IronPython] IronPython+Gtk#+.NET?
In-Reply-To: <4A6150EA.70107@cox.net>
References: <4A6150EA.70107@cox.net>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0348F14B@TK5EX14MBXC116.redmond.corp.microsoft.com>

>From the stack trace this looks like it's Gtk# not interacting well
w/ dynamic defined subclasses on .NET.

My guess here is it's because IronPython defines a subclass of Gtk.Window
which lives in an AssemblyBuilder instance.  This is an in-memory only
assembly and therefore .NET throws NotSupportedException when you try
and get the location.  Mono probably returns some value - that value
may or may not make sense instead but at least it lets other code
muddle along.  Given that this works on Mono my guess is the location
isn't all that important to Gtk here or they're handling the odd value
Mono returns already.

So the correct thing would be either for Mono to throw the same exception
and Gtk# to deal w/ that, for Gtk# to deal w/ both, or for .NET to
not throw the exception and return a value like Mono does.  I'm not
sure which one of those it is but the good news is it should be easy to work
around in the latest IronPython.  That's because we have a pre-compiled
types feature that's new in IronPython 2.6.  It's primarily there for
startup perf but it should work for this too.

You can probably just do:

import clr
clr.AddReference('gtk-sharp')
import Gtk
class MyWindow(Gtk.Window): pass

clr.CompileSubclassTypes('mytypes', *clr.GetSubclassedTypes())

Then just copy mytypes.dll to the DLLs directory or clr.AddReference
it at the start of your app.  You'll then get an on-disk version
of the subclass for Gtk.Window and the call to Location should now
be fine.


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Brian Parma
> Sent: Friday, July 17, 2009 9:35 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] IronPython+Gtk#+.NET?
>
> I've been trying to make a simple IronPython+Gtk# app that draws an
> image to the screen, and I'm having trouble getting it to run in
> windows
> (.NET).  It's pretty simple so I attached it at the end.
>
> It runs fine in Mono on Ubuntu and Windows, but when I try to run it on
> windows using .NET I get the following error followed by a really long
> calltrace:
>
> Marshaling expose_event signal
> Exception in Gtk# callback delegate
>   Note: Applications can use GLib.ExceptionManager.UnhandledException
> to
> handle
> the exception.
> System.Reflection.TargetInvocationException: Exception has been thrown
> by the ta
> rget of an invocation. ---> System.NotSupportedException: The invoked
> member is
> not supported in a dynamic assembly.
>    at System.Reflection.Emit.AssemblyBuilder.get_Location()
>    at GLib.GType.LookupType(IntPtr typeid)
>    at ...
>
>
> I have the latest 'Gtk# for .NET' package from the Mono site, and I've
> tried with IP 2.0.1 and IP 2.6 Beta, they give the same results.
>
> I rewrote the program in C# and it works fine in .NET (without Mono),
> using #Develop IDE.
>
> Is this possible?
>
> code:
>
> import clr
> clr.AddReference('gtk-sharp')
> clr.AddReference('gdk-sharp')
> import Gtk
> import Gdk
>
>
> class MyWindow(Gtk.Window):
>     def __init__(self, title='Main Window'):
>         Gtk.Window.__init__(self, title)
>
>         self.pb = Gdk.Pixbuf('image.jpg').ScaleSimple(600,436,
> Gdk.InterpType.Bilinear )
>         self.da = Gtk.DrawingArea()
>         self.da.SetSizeRequest(self.pb.Width, self.pb.Height)
>         self.Add(self.da)
>         self.Decorated = False
>
>         self.DeleteEvent += self.delete_event
>         self.da.ExposeEvent += self.expose_event
>
>     def expose_event(self, *args):
>         self.da.GdkWindow.DrawPixbuf(
> self.Style.BackgroundGC(self.State), self.pb, 0, 0, 0, 0,-1, -1,
> Gdk.RgbDither.None, 0, 0)
>
>     def delete_event(self, *args):
>         Gtk.Application.Quit()
>
>
> if __name__ in ['__main__','Program']:
>     Gtk.Application.Init()
>     mw = MyWindow('Test')
>     mw.ShowAll()
>     Gtk.Application.Run()
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From calmasy at gmail.com  Sat Jul 18 22:02:29 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Sat, 18 Jul 2009 14:02:29 -0600
Subject: [IronPython] Trying to set field to bool,
	get "TypeError: 	Argument cannot be null."
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0348F03C@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <abb783b90907172332g15ea98c4i71a03e3757bbf64f@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0348F03C@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <abb783b90907181302y7ef44700tc56337be7d76ebe6@mail.gmail.com>

Thanks Dino!

On Sat, Jul 18, 2009 at 12:45 PM, Dino Viehland<dinov at microsoft.com> wrote:
> I think you need an instance of Settings - e.g. Settings().ALWAYS_DECODE_OBJECTS.
>
> That being said the exception you're getting is a bug - it should be telling you
> that you need an instance.
>
> I've created bug 23545: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23545
>
>
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
>> Sent: Friday, July 17, 2009 11:32 PM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] Trying to set field to bool, get "TypeError:
>> Argument cannot be null."
>>
>> I need some help understanding what I'm doing wrong here.
>> Settings.ALWAYS_DECODE_OBJECTS is set in C# like the following:
>>
>> public bool ALWAYS_DECODE_OBJECTS = true;
>>
>> But trying to set it to "True" in IPy blows up with the following
>> traceback:
>>
>> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import clr
>> >>> clr.AddReference("OpenMetaverse.dll")
>> >>> clr.AddReference("OpenMetaverseTypes.dll")
>> >>> from OpenMetaverse import *
>> >>>
>> >>> Settings.ALWAYS_DECODE_OBJECTS = True
>> Traceback (most recent call last):
>> ? File "<stdin>", line 1, in <module>
>> ? File "Microsoft.Scripting.Core", line unknown, in Convert
>> ? File "Microsoft.Scripting.Core", line unknown, in Convert
>> ? File "Microsoft.Scripting.Core", line unknown, in RequiresCanRead
>> TypeError: Argument cannot be null.
>> Parameter name: expression
>> >>>
>>
>> --
>> Cheers, L?szl?
>> _______________________________________________
>> 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
>



-- 
Cheers, L?szl?


From tony.meyer at gmail.com  Sun Jul 19 00:52:04 2009
From: tony.meyer at gmail.com (Tony Meyer)
Date: Sun, 19 Jul 2009 10:52:04 +1200
Subject: [IronPython] "code" module in 2.0.1 but missing in 2.6b1
Message-ID: <6c63de570907181552lf756b2bn5c33dfd6818d8625@mail.gmail.com>

Hi,

The code module (used for providing an interactive interpreter) isn't
included in IronPython 2.6b1 (it is in 2.0.1).  Copying the code (and
codeop) module from 2.0.1 to 2.6b1 seems to work fine, however.

Is this a deliberate change?  One that will be addressed by 2.6 final?

(I did try searching the web and the issue tracker, but I may have
missed something - searching for "import code" doesn't work amazingly
well).

Thanks,
Tony


From freecode at cox.net  Sun Jul 19 05:04:37 2009
From: freecode at cox.net (Brian Parma)
Date: Sat, 18 Jul 2009 20:04:37 -0700
Subject: [IronPython] IronPython+Gtk#+.NET?
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0348F14B@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A6150EA.70107@cox.net>
	<1A472770E042064698CB5ADC83A12ACD0348F14B@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A628D45.5060803@cox.net>

Cool, this made it work with 2.6 beta.

Dino Viehland wrote:
> >From the stack trace this looks like it's Gtk# not interacting well
> w/ dynamic defined subclasses on .NET.
>
> My guess here is it's because IronPython defines a subclass of Gtk.Window
> which lives in an AssemblyBuilder instance.  This is an in-memory only
> assembly and therefore .NET throws NotSupportedException when you try
> and get the location.  Mono probably returns some value - that value
> may or may not make sense instead but at least it lets other code
> muddle along.  Given that this works on Mono my guess is the location
> isn't all that important to Gtk here or they're handling the odd value
> Mono returns already.
>
> So the correct thing would be either for Mono to throw the same exception
> and Gtk# to deal w/ that, for Gtk# to deal w/ both, or for .NET to
> not throw the exception and return a value like Mono does.  I'm not
> sure which one of those it is but the good news is it should be easy to work
> around in the latest IronPython.  That's because we have a pre-compiled
> types feature that's new in IronPython 2.6.  It's primarily there for
> startup perf but it should work for this too.
>
> You can probably just do:
>
> import clr
> clr.AddReference('gtk-sharp')
> import Gtk
> class MyWindow(Gtk.Window): pass
>
> clr.CompileSubclassTypes('mytypes', *clr.GetSubclassedTypes())
>
> Then just copy mytypes.dll to the DLLs directory or clr.AddReference
> it at the start of your app.  You'll then get an on-disk version
> of the subclass for Gtk.Window and the call to Location should now
> be fine.
>
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Brian Parma
>> Sent: Friday, July 17, 2009 9:35 PM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] IronPython+Gtk#+.NET?
>>
>> I've been trying to make a simple IronPython+Gtk# app that draws an
>> image to the screen, and I'm having trouble getting it to run in
>> windows
>> (.NET).  It's pretty simple so I attached it at the end.
>>
>> It runs fine in Mono on Ubuntu and Windows, but when I try to run it on
>> windows using .NET I get the following error followed by a really long
>> calltrace:
>>
>> Marshaling expose_event signal
>> Exception in Gtk# callback delegate
>>   Note: Applications can use GLib.ExceptionManager.UnhandledException
>> to
>> handle
>> the exception.
>> System.Reflection.TargetInvocationException: Exception has been thrown
>> by the ta
>> rget of an invocation. ---> System.NotSupportedException: The invoked
>> member is
>> not supported in a dynamic assembly.
>>    at System.Reflection.Emit.AssemblyBuilder.get_Location()
>>    at GLib.GType.LookupType(IntPtr typeid)
>>    at ...
>>
>>
>> I have the latest 'Gtk# for .NET' package from the Mono site, and I've
>> tried with IP 2.0.1 and IP 2.6 Beta, they give the same results.
>>
>> I rewrote the program in C# and it works fine in .NET (without Mono),
>> using #Develop IDE.
>>
>> Is this possible?
>>
>> code:
>>
>> import clr
>> clr.AddReference('gtk-sharp')
>> clr.AddReference('gdk-sharp')
>> import Gtk
>> import Gdk
>>
>>
>> class MyWindow(Gtk.Window):
>>     def __init__(self, title='Main Window'):
>>         Gtk.Window.__init__(self, title)
>>
>>         self.pb = Gdk.Pixbuf('image.jpg').ScaleSimple(600,436,
>> Gdk.InterpType.Bilinear )
>>         self.da = Gtk.DrawingArea()
>>         self.da.SetSizeRequest(self.pb.Width, self.pb.Height)
>>         self.Add(self.da)
>>         self.Decorated = False
>>
>>         self.DeleteEvent += self.delete_event
>>         self.da.ExposeEvent += self.expose_event
>>
>>     def expose_event(self, *args):
>>         self.da.GdkWindow.DrawPixbuf(
>> self.Style.BackgroundGC(self.State), self.pb, 0, 0, 0, 0,-1, -1,
>> Gdk.RgbDither.None, 0, 0)
>>
>>     def delete_event(self, *args):
>>         Gtk.Application.Quit()
>>
>>
>> if __name__ in ['__main__','Program']:
>>     Gtk.Application.Init()
>>     mw = MyWindow('Test')
>>     mw.ShowAll()
>>     Gtk.Application.Run()
>>
>> _______________________________________________
>> 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 maxyaffe at comcast.net  Sun Jul 19 19:59:00 2009
From: maxyaffe at comcast.net (Max R. Yaffe)
Date: Sun, 19 Jul 2009 13:59:00 -0400
Subject: [IronPython] Current VS 2008 integration status
Message-ID: <000101ca089a$98a64620$6a01a8c0@Gamry.com>

I've read several posts about IronPython Studio and Visual Studio 2008.  I
need to use VS2008 since my project will utilize several .Net languages, but
the wisdom seems to be that IronPython Studio is too fragile for real use.
Is there any chance of getting a more robust version of the IronPython
integration sample or IronPython Studio, or should I get the VS 2010 beta?

Thanks in advance for your help,
Max



From fuzzyman at voidspace.org.uk  Mon Jul 20 14:48:51 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 20 Jul 2009 13:48:51 +0100
Subject: [IronPython] IronPython training in Stockholm 23-24th September
Message-ID: <4A6467B3.3080006@voidspace.org.uk>

Hello all,

September 23-24th I'll be presenting a two day training session in 
Stockholm (the training is in English) with addskills. It is aimed at 
.NET developers looking to use IronPython for application development, 
scripting, embedding, testing or just as another useful tool. It will be 
a comprehensive training session for those with .NET experience who are 
interested in making practical use of IronPython.

For more information please see:

* http://www.addskills.se/Utbildning/Kurs/?CourseID=469#
* http://www.voidspace.org.uk/python/weblog/arch_d7_2009_07_18.shtml#e1109

This course is about how to make the most of dynamic languages like 
IronPython and IronRuby on the .NET framework; with a particular focus 
on IronPython. The dynamic language runtime, which is being incorporated 
into .NET 4.0 and is the basis of IronPython and IronRuby, enables a new 
class of language to run on the .NET framework. In the last few years 
dynamic languages have gained a reputation for increased developer 
productivity and being easy to learn. These new languages for the .NET 
framework have potential applications in everything from scripting tasks 
to application development to embedding in .NET programs as ready made 
scripting engines.

Michael Foord

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




From jregele23 at gmail.com  Mon Jul 20 15:22:08 2009
From: jregele23 at gmail.com (Justin Regele)
Date: Mon, 20 Jul 2009 06:22:08 -0700
Subject: [IronPython] Current VS 2008 integration status
In-Reply-To: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
References: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
Message-ID: <8429660907200622s5fc29e52n3d65be8889729db2@mail.gmail.com>

I'm in a similar situation, where VS2008 is necessary. It definitely can
work, but I've found its best to:

1. Turn off autocompletion for IronPython
2. show whitespace
3. turn off intellisense for ironpython



On Sun, Jul 19, 2009 at 10:59 AM, Max R. Yaffe <maxyaffe at comcast.net> wrote:

> I've read several posts about IronPython Studio and Visual Studio 2008.  I
> need to use VS2008 since my project will utilize several .Net languages,
> but
> the wisdom seems to be that IronPython Studio is too fragile for real use.
> Is there any chance of getting a more robust version of the IronPython
> integration sample or IronPython Studio, or should I get the VS 2010 beta?
>
> Thanks in advance for your help,
> Max
>
> _______________________________________________
> 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/20090720/d5b920c9/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Jul 20 15:24:02 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 20 Jul 2009 14:24:02 +0100
Subject: [IronPython] Current VS 2008 integration status
In-Reply-To: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
References: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
Message-ID: <4A646FF2.8080102@voidspace.org.uk>

Max R. Yaffe wrote:
> I've read several posts about IronPython Studio and Visual Studio 2008.  I
> need to use VS2008 since my project will utilize several .Net languages, but
> the wisdom seems to be that IronPython Studio is too fragile for real use.
> Is there any chance of getting a more robust version of the IronPython
> integration sample or IronPython Studio, or should I get the VS 2010 beta?
>
>   

There is also integration under the SDK - through the experimental hive. 
Does that still work on 2008? (It used to work on 2005.)

Michael

> Thanks in advance for your help,
> Max
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From william at resolversystems.com  Mon Jul 20 18:37:47 2009
From: william at resolversystems.com (William Reade)
Date: Mon, 20 Jul 2009 17:37:47 +0100
Subject: [IronPython] object lifecycle issues
Message-ID: <4A649D5B.1020807@resolversystems.com>

Hi all

I have two problems that are at least somewhat related:

+++ Issue 1 (probably your bug):

---------------------------------------------------------------
C:\dev\ironclad - Copy>ipy y.py
real new
stub new
real init
real del

C:\dev\ironclad - Copy>python y.py
real new
stub new
stub init
real del
---------------------------------------------------------------

I freely admit that the attached code is pretty weird, but I really do 
need to do stuff like this in Ironclad. The difference in behaviour may 
or may not be responsible for certain failing numpy/scipy tests -- I'm 
not sure how to tell -- but I'd enormously appreciate a fix.

I'd report the issue on Codeplex, but trying to visit the issue tracker 
just leaves my browser spinning forever. Speaking of which: is there any 
alternative way of reporting bugs that doesn't make me feel as if I'm 
spamming the list with out-of-band noise? I'm pretty sure that a few 
bugs have just dropped off my stack in the last few months, just because 
I got tired of waiting for Codeplex to start working.

+++ Issue 2 (almost certainly my bug):

In a nearly identical* situation -- close enough that I can't say how 
it's actually different -- f will never get its __del__ method called 
(the object is destroyed -- a WeakReference to it knows it's dead -- but 
the __del__ call never happens).

For context: I have *very* similar classes, whose instances are 
constructed in exactly the weird way demonstrated in the attached file, 
and which work fine. The only difference between the cases that work and 
the cases that don't is that the broken cases multiply inherit from ipy 
types which wrap CLR types (int and float (and maybe str, although I 
haven't tested that one)), while the working cases have simple chains of 
single inheritance from user-defined types all the way up to object. 
However, the attached repro doesn't show my problem, so it's clearly not 
*just* to do with multiply inheriting from CLR types.

Does anyone have any idea what I might be doing wrong? I know this is a 
vague request, but I'm running out of ideas, and I'd really appreciate 
some input from someone who understands precisely what all those ipy 
MetaFoo classes are doing.

Cheers
william


* the attached file started life as an attempt to repro the __del__ 
issue, and I incidentally noticed the __init__ issue.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: y.py
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090720/d5adb779/attachment.ksh>

From dinov at microsoft.com  Mon Jul 20 18:57:38 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 20 Jul 2009 16:57:38 +0000
Subject: [IronPython] object lifecycle issues
In-Reply-To: <4A649D5B.1020807@resolversystems.com>
References: <4A649D5B.1020807@resolversystems.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>

#1's definitely our bug.  We're caching the lookup of __init__ from
Real and invoking that instead of doing the lookup each time.  It
should be easy enough to fix.  I've opened a bug (23555 -
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23555)

#2 I'd guess could be either that for some reason we're failing to
detect the presence of __del__ or that when we run the finalizer cleanup
that we believe it's part of cyclic trash and don't think we should cleanup.
Of those I'd think it'd be the cyclic trash detection that'd be most
likely to go wrong.

I'd suggest putting a break point or some logging in
PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer
and see what's happening there.

As for CodePlex I guess you can't even open a bug to complain to
CodePlex :(.  If you want to send us your browser/OS info we could
open a bug for you against CodePlex.  You could also try the old
heavy hammer of clearing cookies as maybe CodePlex has built up
some bad browser state.  You could also try using TeamExplorer to
open the bugs but I'm not sure if you'll have permissions there to
do that or not.


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Monday, July 20, 2009 9:38 AM
> To: Discussion of IronPython
> Subject: [IronPython] object lifecycle issues
>
> Hi all
>
> I have two problems that are at least somewhat related:
>
> +++ Issue 1 (probably your bug):
>
> ---------------------------------------------------------------
> C:\dev\ironclad - Copy>ipy y.py
> real new
> stub new
> real init
> real del
>
> C:\dev\ironclad - Copy>python y.py
> real new
> stub new
> stub init
> real del
> ---------------------------------------------------------------
>
> I freely admit that the attached code is pretty weird, but I really do
> need to do stuff like this in Ironclad. The difference in behaviour may
> or may not be responsible for certain failing numpy/scipy tests -- I'm
> not sure how to tell -- but I'd enormously appreciate a fix.
>
> I'd report the issue on Codeplex, but trying to visit the issue tracker
> just leaves my browser spinning forever. Speaking of which: is there
> any alternative way of reporting bugs that doesn't make me feel as if
> I'm spamming the list with out-of-band noise? I'm pretty sure that a
> few bugs have just dropped off my stack in the last few months, just
> because I got tired of waiting for Codeplex to start working.
>
> +++ Issue 2 (almost certainly my bug):
>
> In a nearly identical* situation -- close enough that I can't say how
> it's actually different -- f will never get its __del__ method called
> (the object is destroyed -- a WeakReference to it knows it's dead --
> but the __del__ call never happens).
>
> For context: I have *very* similar classes, whose instances are
> constructed in exactly the weird way demonstrated in the attached file,
> and which work fine. The only difference between the cases that work
> and the cases that don't is that the broken cases multiply inherit from
> ipy types which wrap CLR types (int and float (and maybe str, although
> I haven't tested that one)), while the working cases have simple chains
> of single inheritance from user-defined types all the way up to object.
> However, the attached repro doesn't show my problem, so it's clearly
> not
> *just* to do with multiply inheriting from CLR types.
>
> Does anyone have any idea what I might be doing wrong? I know this is a
> vague request, but I'm running out of ideas, and I'd really appreciate
> some input from someone who understands precisely what all those ipy
> MetaFoo classes are doing.
>
> Cheers
> william
>
>
> * the attached file started life as an attempt to repro the __del__
> issue, and I incidentally noticed the __init__ issue.


From tony.meyer at gmail.com  Mon Jul 20 22:26:39 2009
From: tony.meyer at gmail.com (Tony Meyer)
Date: Tue, 21 Jul 2009 08:26:39 +1200
Subject: [IronPython] Current VS 2008 integration status
In-Reply-To: <4A646FF2.8080102@voidspace.org.uk>
References: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
	<4A646FF2.8080102@voidspace.org.uk>
Message-ID: <6c63de570907201326j3230e03x3649eaab47fae446@mail.gmail.com>

On Tue, Jul 21, 2009 at 1:24 AM, Michael Foord<fuzzyman at voidspace.org.uk> wrote:
> There is also integration under the SDK - through the experimental hive.
> Does that still work on 2008? (It used to work on 2005.)

It worked fine for me (with the full Visual Studio - I didn't try an
Express version), although I only ran it through a few tests - I plan
to use it more frequently later on this year.

Cheers,
Tony


From dfugate at microsoft.com  Mon Jul 20 22:44:33 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Mon, 20 Jul 2009 20:44:33 +0000
Subject: [IronPython] Current VS 2008 integration status
In-Reply-To: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
References: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
Message-ID: <7CEEC335D70FFE4B957737DDE836F51B013C1C@TK5EX14MBXC125.redmond.corp.microsoft.com>

My recommendation for getting full (Iron)Python support from within Visual Studio is to submit feedback (https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=12362) that this is a feature you need.  If enough people were to request this...it might just happen for a future release=)

Dave

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Max R. Yaffe
Sent: Sunday, July 19, 2009 10:59 AM
To: users at lists.ironpython.com
Subject: [IronPython] Current VS 2008 integration status

I've read several posts about IronPython Studio and Visual Studio 2008.  I
need to use VS2008 since my project will utilize several .Net languages, but
the wisdom seems to be that IronPython Studio is too fragile for real use.
Is there any chance of getting a more robust version of the IronPython
integration sample or IronPython Studio, or should I get the VS 2010 beta?

Thanks in advance for your help,
Max

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



From Jimmy.Schementi at microsoft.com  Tue Jul 21 00:28:33 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Mon, 20 Jul 2009 22:28:33 +0000
Subject: [IronPython] object lifecycle issues
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC18B5842E@tk5ex14mbxc105.redmond.corp.microsoft.com>

WRT the Codeplex issues, http://codeplex.codeplex.com is the place to post issues about codeplex itself: http://codeplex.codeplex.com/WorkItem/List.aspx. Let us know when you open a bug so we can reinforce the complaints.

~js

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Monday, July 20, 2009 9:58 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] object lifecycle issues
>
> #1's definitely our bug.  We're caching the lookup of __init__ from Real and
> invoking that instead of doing the lookup each time.  It should be easy
> enough to fix.  I've opened a bug (23555 -
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23555)
>
> #2 I'd guess could be either that for some reason we're failing to detect the
> presence of __del__ or that when we run the finalizer cleanup that we
> believe it's part of cyclic trash and don't think we should cleanup.
> Of those I'd think it'd be the cyclic trash detection that'd be most likely to go
> wrong.
>
> I'd suggest putting a break point or some logging in
> PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer and see
> what's happening there.
>
> As for CodePlex I guess you can't even open a bug to complain to CodePlex
> :(.  If you want to send us your browser/OS info we could open a bug for you
> against CodePlex.  You could also try the old heavy hammer of clearing
> cookies as maybe CodePlex has built up some bad browser state.  You could
> also try using TeamExplorer to open the bugs but I'm not sure if you'll have
> permissions there to do that or not.
>
>
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of William Reade
> > Sent: Monday, July 20, 2009 9:38 AM
> > To: Discussion of IronPython
> > Subject: [IronPython] object lifecycle issues
> >
> > Hi all
> >
> > I have two problems that are at least somewhat related:
> >
> > +++ Issue 1 (probably your bug):
> >
> > ---------------------------------------------------------------
> > C:\dev\ironclad - Copy>ipy y.py
> > real new
> > stub new
> > real init
> > real del
> >
> > C:\dev\ironclad - Copy>python y.py
> > real new
> > stub new
> > stub init
> > real del
> > ---------------------------------------------------------------
> >
> > I freely admit that the attached code is pretty weird, but I really do
> > need to do stuff like this in Ironclad. The difference in behaviour
> > may or may not be responsible for certain failing numpy/scipy tests --
> > I'm not sure how to tell -- but I'd enormously appreciate a fix.
> >
> > I'd report the issue on Codeplex, but trying to visit the issue
> > tracker just leaves my browser spinning forever. Speaking of which: is
> > there any alternative way of reporting bugs that doesn't make me feel
> > as if I'm spamming the list with out-of-band noise? I'm pretty sure
> > that a few bugs have just dropped off my stack in the last few months,
> > just because I got tired of waiting for Codeplex to start working.
> >
> > +++ Issue 2 (almost certainly my bug):
> >
> > In a nearly identical* situation -- close enough that I can't say how
> > it's actually different -- f will never get its __del__ method called
> > (the object is destroyed -- a WeakReference to it knows it's dead --
> > but the __del__ call never happens).
> >
> > For context: I have *very* similar classes, whose instances are
> > constructed in exactly the weird way demonstrated in the attached
> > file, and which work fine. The only difference between the cases that
> > work and the cases that don't is that the broken cases multiply
> > inherit from ipy types which wrap CLR types (int and float (and maybe
> > str, although I haven't tested that one)), while the working cases
> > have simple chains of single inheritance from user-defined types all the
> way up to object.
> > However, the attached repro doesn't show my problem, so it's clearly
> > not
> > *just* to do with multiply inheriting from CLR types.
> >
> > Does anyone have any idea what I might be doing wrong? I know this is
> > a vague request, but I'm running out of ideas, and I'd really
> > appreciate some input from someone who understands precisely what all
> > those ipy MetaFoo classes are doing.
> >
> > Cheers
> > william
> >
> >
> > * the attached file started life as an attempt to repro the __del__
> > issue, and I incidentally noticed the __init__ issue.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From dinov at microsoft.com  Tue Jul 21 00:48:54 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 20 Jul 2009 22:48:54 +0000
Subject: [IronPython] object lifecycle issues
In-Reply-To: <4A649D5B.1020807@resolversystems.com>
References: <4A649D5B.1020807@resolversystems.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03499908@TK5EX14MBXC116.redmond.corp.microsoft.com>

Could this be issue 2?

class Real(object):
    def __new__(cls, *args, **kwargs):
        print 'real new'
        return object.__new__(Stub)
    #def __del__(self): pass     # uncomment me and this works as expected

class Stub(Real):
    def __del__(self):
        print "I've been finalized"

f = Real(1.0)
del f

import sys
if sys.platform == 'clr':
    import clr
    from System import GC
    for _ in range(4):
        GC.Collect()
        GC.WaitForPendingFinalizers()


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Monday, July 20, 2009 9:38 AM
> To: Discussion of IronPython
> Subject: [IronPython] object lifecycle issues
>
> Hi all
>
> I have two problems that are at least somewhat related:
>
> +++ Issue 1 (probably your bug):
>
> ---------------------------------------------------------------
> C:\dev\ironclad - Copy>ipy y.py
> real new
> stub new
> real init
> real del
>
> C:\dev\ironclad - Copy>python y.py
> real new
> stub new
> stub init
> real del
> ---------------------------------------------------------------
>
> I freely admit that the attached code is pretty weird, but I really do
> need to do stuff like this in Ironclad. The difference in behaviour may
> or may not be responsible for certain failing numpy/scipy tests -- I'm
> not sure how to tell -- but I'd enormously appreciate a fix.
>
> I'd report the issue on Codeplex, but trying to visit the issue tracker
> just leaves my browser spinning forever. Speaking of which: is there
> any alternative way of reporting bugs that doesn't make me feel as if
> I'm spamming the list with out-of-band noise? I'm pretty sure that a
> few bugs have just dropped off my stack in the last few months, just
> because I got tired of waiting for Codeplex to start working.
>
> +++ Issue 2 (almost certainly my bug):
>
> In a nearly identical* situation -- close enough that I can't say how
> it's actually different -- f will never get its __del__ method called
> (the object is destroyed -- a WeakReference to it knows it's dead --
> but the __del__ call never happens).
>
> For context: I have *very* similar classes, whose instances are
> constructed in exactly the weird way demonstrated in the attached file,
> and which work fine. The only difference between the cases that work
> and the cases that don't is that the broken cases multiply inherit from
> ipy types which wrap CLR types (int and float (and maybe str, although
> I haven't tested that one)), while the working cases have simple chains
> of single inheritance from user-defined types all the way up to object.
> However, the attached repro doesn't show my problem, so it's clearly
> not
> *just* to do with multiply inheriting from CLR types.
>
> Does anyone have any idea what I might be doing wrong? I know this is a
> vague request, but I'm running out of ideas, and I'd really appreciate
> some input from someone who understands precisely what all those ipy
> MetaFoo classes are doing.
>
> Cheers
> william
>
>
> * the attached file started life as an attempt to repro the __del__
> issue, and I incidentally noticed the __init__ issue.


From brannon at iterator.net  Tue Jul 21 01:46:12 2009
From: brannon at iterator.net (Brannon Jones)
Date: Mon, 20 Jul 2009 16:46:12 -0700
Subject: [IronPython] Current VS 2008 integration status
In-Reply-To: <7CEEC335D70FFE4B957737DDE836F51B013C1C@TK5EX14MBXC125.redmond.corp.microsoft.com>
References: <000101ca089a$98a64620$6a01a8c0@Gamry.com>
	<7CEEC335D70FFE4B957737DDE836F51B013C1C@TK5EX14MBXC125.redmond.corp.microsoft.com>
Message-ID: <1653092d0907201646p4d192033la8e1816eacb7362c@mail.gmail.com>

All,
Michael Foord opened the following feedback entry:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=475830

We should vote and comment on this one, rather than opening a flood of new
requests (I've seen several already).

Brannon

On Mon, Jul 20, 2009 at 13:44, Dave Fugate <dfugate at microsoft.com> wrote:

> My recommendation for getting full (Iron)Python support from within Visual
> Studio is to submit feedback (
> https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=12362)
> that this is a feature you need.  If enough people were to request this...it
> might just happen for a future release=)
>
> Dave
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] On Behalf Of Max R. Yaffe
> Sent: Sunday, July 19, 2009 10:59 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] Current VS 2008 integration status
>
> I've read several posts about IronPython Studio and Visual Studio 2008.  I
> need to use VS2008 since my project will utilize several .Net languages,
> but
> the wisdom seems to be that IronPython Studio is too fragile for real use.
> Is there any chance of getting a more robust version of the IronPython
> integration sample or IronPython Studio, or should I get the VS 2010 beta?
>
> Thanks in advance for your help,
> Max
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090720/485af158/attachment.html>

From kf9150 at gmail.com  Tue Jul 21 08:47:29 2009
From: kf9150 at gmail.com (Kelie)
Date: Mon, 20 Jul 2009 23:47:29 -0700 (PDT)
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <d2155e360907102146l5ff57410w6e2d1650d66a743b@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<1A472770E042064698CB5ADC83A12ACD0344E99C@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<56fa314b-622f-46b8-8943-5517a5aae6e0@q11g2000yqi.googlegroups.com> 
	<d2155e360907102146l5ff57410w6e2d1650d66a743b@mail.gmail.com>
Message-ID: <b9e8cd83-0aa2-43ce-8b21-4bc8787f67c8@v15g2000prn.googlegroups.com>

On Jul 10, 6:46?pm, Curt Hagenlocher <c... at hagenlocher.org> wrote:
> It would probably be more immediately useful if you were to provide
> the specific error message and a listing of the directory from which
> you're trying to run the program. Given that it works on at least one
> machine, it's likely to be context-related rather than code-related.
>

Thanks Curt. I'll run the program again and get back to you on this.


From kf9150 at gmail.com  Tue Jul 21 08:49:12 2009
From: kf9150 at gmail.com (Kelie)
Date: Mon, 20 Jul 2009 23:49:12 -0700 (PDT)
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <58ad4a110907171307o5db93cdcnea0ff80ba83154ff@mail.gmail.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<58ad4a110907171307o5db93cdcnea0ff80ba83154ff@mail.gmail.com>
Message-ID: <7927de91-9d1e-4a2c-887c-1eb01cbdef66@j9g2000prh.googlegroups.com>

On Jul 17, 10:07?am, Bruce Bromberek <bruce.brombe... at gmail.com>
wrote:
> Look at your references to the 5 ironpython DLLs. ?Decide right now: ?Are
> you going to use the ones that ship with SharpDevelop or the ones using that
> come with IronPython. ?Choose one and be consistent.
>
> I'm still working though how to Build a WIX installer project , so I
> currently ZIP up the release folder generated by SharpDevelop and make sure
> everything is there. ?Here's an example for a simple program I have
> distributed to coworkers.

> Make sure the Target machine has been upgraded to .Net 3.5 SP1. ?Don't take
> any flack - make them upgrade.*
>
> *Make sure they are not running on a network share. ?Weird things with trust
> can happen with shares. ?See my recent cry for help on this list for more
> info.*
>

Bruce, thanks a lot for sharing your experience. I'll try your
suggestions.




From fuzzyman at voidspace.org.uk  Tue Jul 21 11:37:12 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 21 Jul 2009 10:37:12 +0100
Subject: [IronPython] [Code Review] "XAP-less" Silverlight application
 support
In-Reply-To: <0047ECBFA2E0DF4A834AA369282A5AFC18B56732@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <0047ECBFA2E0DF4A834AA369282A5AFC18B56732@tk5ex14mbxc105.redmond.corp.microsoft.com>
Message-ID: <4A658C48.5010001@voidspace.org.uk>

Hello Jimmy,

Will xap-less be an 'alternative' deployment scenario for dynamic 
silverlight applications or the 'new and only' deployment scenario?

If it becomes the 'right' way to do it please realise that you are in 
one swoop obsoleting all the articles, tutorials, examples (and books) 
on developing Silverlight applications with IronPython / IronRuby. There 
better be a big payoff for such a hugely backwards incompatible move...

When the move to xap files happened we were told this was a big win for 
dynamic languages as all needed Python (or Ruby) files would be 
downloaded compressed - and this was *much* faster than downloading them 
synchronously on import (as the integration in Silverlight 1.1 
originally did). What is the motivation for the change?

Does this change allow the IronPython assemblies to be shared between 
applications (and cached)? I realise this can be done already (I use it 
with my examples) - but I still see the IronPython assemblies being 
re-downloaded every time you refresh the page or go to a new example, 
even though they are from the same location.

Michael


Jimmy Schementi wrote:
> (Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)
>
> http://github.com/jschementi/ironruby/commit/da6b54e226adfd3a18d8ad98d618c2350ebd8351
>
> Beginnings of "XAP-less" Silverlight application support. Note: Silverlight apps are *required* to have a XAP file, but with this change it can get down to just a container for the AppManifest.xaml file. Python/Ruby would ship with a single XAP file pointing to the .slvx files for a given release.
>
> Adds a "downloadScripts" initParam to indicate whether paths to script files and XAML files should be resolved to the web-server (relative to the XAP), if the file is not found in the XAP. Also adds "downloadScriptsFrom" to customize what path they are based off of. Because of the opt-in nature of this change, existing DLR Silverlight apps should not break.
>
> Files are downloaded synchronously as code runs, by having the PlatformAdaptationLayer use a new BrowserVirtualFilesystem: HttpVirtualFilesystem. So when a language's include mechanism is used (require , load, import, etc), it will download the file by using XmlHttpRequest in synchronous mode. It will also cache each downloaded file's contents, so a file will only be downloaded once, even if it is included multiple times. Note: future work will hopefully allow asynchronous includes, so this can be production-ready. For now, it should only be used for development.
>
> Note: this change decreases the need for Chiron significantly. In this mode, Chiron only creates a XAP file with the necessary assemblies and AppManifest.xaml, if it doesn't exist already. One could imagine providing a XAP file for each language, and then Chiron wouldn't be needed for development. However, for using the latest language assemblies, and auto-detection of languages used, it's still useful for development. So some changes have been made to Chiron to support this better:
>
> A "localApplicationRoot" appSetting has been added to Chiron to adjust where it looks for script files (when determining what languages are used). This allows you to make sure Chiron is looking in the same place your application is downloading scripts or xaml from, so it can still generate a correct XAP file for you. "application/ruby" and "application/python" mime-types have been also added to Chiron also to enable downloading of those script files.
>
> All of Chiron's appSettings are now override-able as command-line switches: /u[rlPrefix], /e[xtUrlPrefix], /l[ocalAppRoot]
>
> Run Merlin/Main/Hosts/SilverLight/Tests/tests/manual/test_foox/run.bat for an example of how this works (it requires a Silverlight Debug build, so if you run Merlin/Main/Languages/Ruby/Scripts/Dev.bat, just run "bsd" and that will *b*uild *s*ilverlight in *d*ebug mode)
>
> Adds a stub for similar support through IsolatedStorage, but that will come later.
>
> Also tweaks the DynamicEngine.CreateRuntimeSetup method to better support other DLR-hosts in Silverlight (http://lists.ironpython.com/pipermail/users-ironpython.com/2009-July/010780.html).
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


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



From william at resolversystems.com  Tue Jul 21 12:53:19 2009
From: william at resolversystems.com (William Reade)
Date: Tue, 21 Jul 2009 11:53:19 +0100
Subject: [IronPython] object lifecycle issues
In-Reply-To: <0047ECBFA2E0DF4A834AA369282A5AFC18B5842E@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<0047ECBFA2E0DF4A834AA369282A5AFC18B5842E@tk5ex14mbxc105.redmond.corp.microsoft.com>
Message-ID: <4A659E1F.4090401@resolversystems.com>

Clearing cookies worked -- thanks guys.

http://codeplex.codeplex.com/WorkItem/View.aspx?WorkItemId=23563

Jimmy Schementi wrote:
> WRT the Codeplex issues, http://codeplex.codeplex.com is the place to post issues about codeplex itself: http://codeplex.codeplex.com/WorkItem/List.aspx. Let us know when you open a bug so we can reinforce the complaints.
>
> ~js
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
>> Sent: Monday, July 20, 2009 9:58 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] object lifecycle issues
>>
>> #1's definitely our bug.  We're caching the lookup of __init__ from Real and
>> invoking that instead of doing the lookup each time.  It should be easy
>> enough to fix.  I've opened a bug (23555 -
>> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23555)
>>
>> #2 I'd guess could be either that for some reason we're failing to detect the
>> presence of __del__ or that when we run the finalizer cleanup that we
>> believe it's part of cyclic trash and don't think we should cleanup.
>> Of those I'd think it'd be the cyclic trash detection that'd be most likely to go
>> wrong.
>>
>> I'd suggest putting a break point or some logging in
>> PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer and see
>> what's happening there.
>>
>> As for CodePlex I guess you can't even open a bug to complain to CodePlex
>> :(.  If you want to send us your browser/OS info we could open a bug for you
>> against CodePlex.  You could also try the old heavy hammer of clearing
>> cookies as maybe CodePlex has built up some bad browser state.  You could
>> also try using TeamExplorer to open the bugs but I'm not sure if you'll have
>> permissions there to do that or not.
>>
>>
>>     
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-
>>> bounces at lists.ironpython.com] On Behalf Of William Reade
>>> Sent: Monday, July 20, 2009 9:38 AM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] object lifecycle issues
>>>
>>> Hi all
>>>
>>> I have two problems that are at least somewhat related:
>>>
>>> +++ Issue 1 (probably your bug):
>>>
>>> ---------------------------------------------------------------
>>> C:\dev\ironclad - Copy>ipy y.py
>>> real new
>>> stub new
>>> real init
>>> real del
>>>
>>> C:\dev\ironclad - Copy>python y.py
>>> real new
>>> stub new
>>> stub init
>>> real del
>>> ---------------------------------------------------------------
>>>
>>> I freely admit that the attached code is pretty weird, but I really do
>>> need to do stuff like this in Ironclad. The difference in behaviour
>>> may or may not be responsible for certain failing numpy/scipy tests --
>>> I'm not sure how to tell -- but I'd enormously appreciate a fix.
>>>
>>> I'd report the issue on Codeplex, but trying to visit the issue
>>> tracker just leaves my browser spinning forever. Speaking of which: is
>>> there any alternative way of reporting bugs that doesn't make me feel
>>> as if I'm spamming the list with out-of-band noise? I'm pretty sure
>>> that a few bugs have just dropped off my stack in the last few months,
>>> just because I got tired of waiting for Codeplex to start working.
>>>
>>> +++ Issue 2 (almost certainly my bug):
>>>
>>> In a nearly identical* situation -- close enough that I can't say how
>>> it's actually different -- f will never get its __del__ method called
>>> (the object is destroyed -- a WeakReference to it knows it's dead --
>>> but the __del__ call never happens).
>>>
>>> For context: I have *very* similar classes, whose instances are
>>> constructed in exactly the weird way demonstrated in the attached
>>> file, and which work fine. The only difference between the cases that
>>> work and the cases that don't is that the broken cases multiply
>>> inherit from ipy types which wrap CLR types (int and float (and maybe
>>> str, although I haven't tested that one)), while the working cases
>>> have simple chains of single inheritance from user-defined types all the
>>>       
>> way up to object.
>>     
>>> However, the attached repro doesn't show my problem, so it's clearly
>>> not
>>> *just* to do with multiply inheriting from CLR types.
>>>
>>> Does anyone have any idea what I might be doing wrong? I know this is
>>> a vague request, but I'm running out of ideas, and I'd really
>>> appreciate some input from someone who understands precisely what all
>>> those ipy MetaFoo classes are doing.
>>>
>>> Cheers
>>> william
>>>
>>>
>>> * the attached file started life as an attempt to repro the __del__
>>> issue, and I incidentally noticed the __init__ issue.
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From Jimmy.Schementi at microsoft.com  Tue Jul 21 13:21:51 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 21 Jul 2009 11:21:51 +0000
Subject: [IronPython] [Code Review] "XAP-less" Silverlight application
 support
In-Reply-To: <4A658C48.5010001@voidspace.org.uk>
References: <0047ECBFA2E0DF4A834AA369282A5AFC18B56732@tk5ex14mbxc105.redmond.corp.microsoft.com>,
	<4A658C48.5010001@voidspace.org.uk>
Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC18B5A4FA@tk5ex14mbxc105.redmond.corp.microsoft.com>

Michael,

You just had to ask now =P ... I was going to blog about this more extensively tomorrow, but here's a preview of my thinking about this:

My motivation behind xap-less is to make DLR Silverlight apps less complex, and more like how the web works. This change is just an experiment in that direction, and I'm very open to any opinions folks have about this.

First things first though, this change make xap-less completely opt-in ... you have to use the "downloadScripts=true" InitParams setting to enable it. Without this param it will behave as it used to. Also, even with this setting it will not download the file if it exists in the XAP. I was very conservative about this change, as I'm just playing around with some ideas.

Also, even if xap-less becomes the default, I'd make sure existing deployments did not break; in the xap will always be an option for deployment (and quite possibly the preferred way), but I want to get back to the place where we didn't need a XAP file and didn't need Chiron for development.

Eh, I know that was the messaging around XAP files being compressed and faster for download times, but that's because they were synchronously downloaded and the browser can only handle one of those at once. If you use gzip-compression on your web-server and download each file asynchronously, I don't think you'll see much of a difference. However, "minifying" Ruby or Python like most JavaScript is really not possible, so people could always opt for a XAP file. But I really want to give back the text-only experience, even for deployment. There are still good ways to support asynchronous downloading of files that get imported (I'll talk about that below), so we should still explore those ... especially since this is the way browsers work today.

Imagine if Ruby and Python in the browser felt not that much different than JavaScript, but allow for other deployment options if the app needs it. For example, a Python Silverlight Hello World app should just be this:

<!-- index.html -->
<script type="text/javascript" src="silverlight-dlr.js"></script>
<div id="message"></div>
<script type="application/python">
document.message.innerHTML = "Hello, World!"
</script>

Very simple and clean. No need to start a web-server or install Mono on the Mac just to make a client-side page. The JS file hosts Silverlight, and then Microsoft.Scripting.Silverlight scans the HTML page looking for <script> tags, executing them as they are encountered. Pre-packaged xap files are there so a basic app would never need to touch the XAP. There is a project being released today on http://visitmix.com/Lab which implements SL Ruby and Python apps just like this, with the intention that the ideas about making things simpler are merged back into Microsoft.Scripting.Silverlight. I'll send out links when it's live, but hopefully you'll just hear about it. =)

FWIW, I'd leave the "entryPoint" activation in there as well, so only if you didn't set entryPoint OR didn't have a valid entry point in the XAP then we'd look at the HTML page for <script> tags ... we can deprecate it if enough people stop using entryPoint. Also, it's a little strange to take a bunch of python islands and assume it's one module. Should those islands be their own modules? Also, I know there might be some standards issues with doing a <script type=""> when it's not a list of approved types. We'll have to make sure this is done in a standards-compliant way, as I'd love to see browsers support this out of the box (ha, yeah, sounds crazy I know), and this work should be a stepping stone to that. I've already reviewed the visitmix.com/Lab project and there are some standards issues that I'll blog about tomorrow, so please don't get caught up on a prototype or proposal, just imagine what things could be like. =P

This scales to bringing in other files too, as you can use <script type="application/python" src="foo.py" />. Microsoft.Scripting.Silverlight would scan the HTML file for <script> tags with the src attribute, and download the files ahead of time. But what happens if those files "import" something? The visitmix project I was referring to does not handle this case, since it's just a prototype of how browsers could support multiple languages. But we'd need to support this. And this is where it could look back the XAP. So if we ever did take away entryPoint then you'd activate your apps by just doing this:

<script type="application/python">
  import app
</script>

If an import failed against the XAP, it could look on the web-server. Though today's implementation is synchronous, that needs to change. So the guidance would be to either to put those files in the XAP, or allow the app-author to specify their dependencies up-front (like JavaScript does, it could even be with <script> tags also) so those files could be downloaded and import would just run the contents of the pre-downloaded files. Unfortunately, even if we could do import asynchronously (by making import/require/etc continuation-aware), the downloads would still happen one at a time, which is unacceptable for deployment. So it's either the up-front-list or in the XAP.

WRT sharing IronPython assemblies between apps, that change was kinda silently checked in around SL3 RTW since I wanted to test things a bit more, and find a place to host the packages. Documentation will pop up on the IronPython codeplex site in a few weeks about how this all works. And the way you host your apps should still be caching it, but you'll see a download request (in Firebug for example). Are you sure they are being fully downloaded each time? Maybe the AppManifest.xaml downloading is forcing a download each time, but I remember it going to the browser cache.

I know that was kinda long winded, but I'm pretty happy about fixing a lot of the ugliness we had to add from SL1.1 to SL2, while keeping the deployment benefits SL2 had, even if they are in a different form. Today's model is too complicated for people coming from JavaScript to get started, so lowering the bar to the <script> tag level may get the attention of more developers. Let me know if anyone has more questions about this.

~js

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Michael Foord [fuzzyman at voidspace.org.uk]
Sent: Tuesday, July 21, 2009 2:37 AM
To: Discussion of IronPython
Cc: ironruby-core at rubyforge.org
Subject: Re: [IronPython] [Code Review] "XAP-less" Silverlight application support

Hello Jimmy,

Will xap-less be an 'alternative' deployment scenario for dynamic
silverlight applications or the 'new and only' deployment scenario?

If it becomes the 'right' way to do it please realise that you are in
one swoop obsoleting all the articles, tutorials, examples (and books)
on developing Silverlight applications with IronPython / IronRuby. There
better be a big payoff for such a hugely backwards incompatible move...

When the move to xap files happened we were told this was a big win for
dynamic languages as all needed Python (or Ruby) files would be
downloaded compressed - and this was *much* faster than downloading them
synchronously on import (as the integration in Silverlight 1.1
originally did). What is the motivation for the change?

Does this change allow the IronPython assemblies to be shared between
applications (and cached)? I realise this can be done already (I use it
with my examples) - but I still see the IronPython assemblies being
re-downloaded every time you refresh the page or go to a new example,
even though they are from the same location.

Michael


Jimmy Schementi wrote:
> (Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)
>
> http://github.com/jschementi/ironruby/commit/da6b54e226adfd3a18d8ad98d618c2350ebd8351
>
> Beginnings of "XAP-less" Silverlight application support. Note: Silverlight apps are *required* to have a XAP file, but with this change it can get down to just a container for the AppManifest.xaml file. Python/Ruby would ship with a single XAP file pointing to the .slvx files for a given release.
>
> Adds a "downloadScripts" initParam to indicate whether paths to script files and XAML files should be resolved to the web-server (relative to the XAP), if the file is not found in the XAP. Also adds "downloadScriptsFrom" to customize what path they are based off of. Because of the opt-in nature of this change, existing DLR Silverlight apps should not break.
>
> Files are downloaded synchronously as code runs, by having the PlatformAdaptationLayer use a new BrowserVirtualFilesystem: HttpVirtualFilesystem. So when a language's include mechanism is used (require , load, import, etc), it will download the file by using XmlHttpRequest in synchronous mode. It will also cache each downloaded file's contents, so a file will only be downloaded once, even if it is included multiple times. Note: future work will hopefully allow asynchronous includes, so this can be production-ready. For now, it should only be used for development.
>
> Note: this change decreases the need for Chiron significantly. In this mode, Chiron only creates a XAP file with the necessary assemblies and AppManifest.xaml, if it doesn't exist already. One could imagine providing a XAP file for each language, and then Chiron wouldn't be needed for development. However, for using the latest language assemblies, and auto-detection of languages used, it's still useful for development. So some changes have been made to Chiron to support this better:
>
> A "localApplicationRoot" appSetting has been added to Chiron to adjust where it looks for script files (when determining what languages are used). This allows you to make sure Chiron is looking in the same place your application is downloading scripts or xaml from, so it can still generate a correct XAP file for you. "application/ruby" and "application/python" mime-types have been also added to Chiron also to enable downloading of those script files.
>
> All of Chiron's appSettings are now override-able as command-line switches: /u[rlPrefix], /e[xtUrlPrefix], /l[ocalAppRoot]
>
> Run Merlin/Main/Hosts/SilverLight/Tests/tests/manual/test_foox/run.bat for an example of how this works (it requires a Silverlight Debug build, so if you run Merlin/Main/Languages/Ruby/Scripts/Dev.bat, just run "bsd" and that will *b*uild *s*ilverlight in *d*ebug mode)
>
> Adds a stub for similar support through IsolatedStorage, but that will come later.
>
> Also tweaks the DynamicEngine.CreateRuntimeSetup method to better support other DLR-hosts in Silverlight (http://lists.ironpython.com/pipermail/users-ironpython.com/2009-July/010780.html).
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


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

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



From william at resolversystems.com  Tue Jul 21 14:30:53 2009
From: william at resolversystems.com (William Reade)
Date: Tue, 21 Jul 2009 13:30:53 +0100
Subject: [IronPython] object lifecycle issues
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03499908@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD03499908@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A65B4FD.9070804@resolversystems.com>

Hi Dino

I don't *think* that's the case -- the stub has a __del__ method, that 
should never get called, purely to work around that bug (or possibly a 
subtly different one: I internally characterised it as "an object won't 
get __del__ed unless the type it was created as had a __del__ method, at 
the time it was created", which doesn't *quite* match your example). I 
guess it's one of the ones that never made it onto Codeplex... it's 
there now, at 
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23564

The repro for for issue #2 -- which requires current ironclad with 
appropriate logging -- is attached as x.py. The output, which you can 
see a bit further down, shows what happens when you 
construct-then-delete instances of various numpy data types. In short, 
the int8 and float32 dtypes don't include a CLR type among their 
immediate bases, and do get deleted correctly, while the int32 and 
float64 dtypes do and don't respectively.

Anyway, I'll look into your earlier suggestions -- thank you very much!

x.py output (after a lot of noise from the numpy import)
------------------------------------------------------------
========================================

start <class 'numpy.int8'>

real new1 <class 'numpy.int8'>
fake new1 _ironclad_class_stub (<class 'numpy.signedinteger'>,)
fake new2 (object) 2107
fake init <class 'unknown._ironclad_class_stub'> 2107
real new2 <class 'numpy.int8'> 2107

constructed; id is 2107

real del 2107

finished <class 'numpy.int8'>

========================================

start <class 'numpy.int32'>

real new1 <class 'numpy.int32'>
fake new1 _ironclad_class_stub (<class 'numpy.signedinteger'>, <type 'int'>)
fake new2 (int) 2111
fake init <class 'unknown._ironclad_class_stub'> 2111
real new2 <class 'numpy.int32'> 2111

constructed; id is 2111


finished <class 'numpy.int32'>

========================================

start <class 'numpy.float32'>

real new1 <class 'numpy.float32'>
fake new1 _ironclad_class_stub (<class 'numpy.floating'>,)
fake new2 (object) 2116
fake init <class 'unknown._ironclad_class_stub'> 2116
real new2 <class 'numpy.float32'> 2116

constructed; id is 2116

real del 2116

finished <class 'numpy.float32'>

========================================

start <class 'numpy.float64'>

real new1 <class 'numpy.float64'>
fake new1 _ironclad_class_stub (<class 'numpy.floating'>, <type 'float'>)
fake new2 (float) 2121
fake init <class 'unknown._ironclad_class_stub'> 2121
real new2 <class 'numpy.float64'> 2121

constructed; id is 2121


finished <class 'numpy.float64'>
------------------------------------------------------------

...and the internal logging is as follows:

------------------------------------------------------------
        public const string CLASS_STUB_CODE = @"
def __new__(cls, *args, **kwargs):
    print 'fake new1', cls.__name__, cls.__bases__
    if issubclass(cls, int):
        result = int.__new__(cls, args[0])
        print 'fake new2 (int)', id(result)
        return result
    if issubclass(cls, float):
        result = float.__new__(cls, args[0])
        print 'fake new2 (float)', id(result)
        return result
    result = object.__new__(cls)
    print 'fake new2 (object)', id(result)
    return result

def __init__(self, *args, **kwargs):
    print 'fake init', type(self), id(self)

def __del__(self):
    print 'fake del', id(self)

def __setattr__(self, name, value):
    object.__setattr__(self, name, value)

_ironclad_class_stub = _ironclad_metaclass('_ironclad_class_stub', 
_ironclad_bases, {
    '__new__': __new__,
    '__init__': __init__,
    '__del__': __del__,
    '__setattr__': __setattr__,
})
";

        public const string CLASS_CODE = @"
def __new__(cls, *args, **kwargs):
    print 'real new1', cls
    result = cls._dispatcher.newfunc('{0}.tp_new', cls, args, kwargs)
    print 'real new2', cls, id(result)
    return result

def __del__(self):
    print 'real del', id(self)
    self._dispatcher.ic_destroy(self)

_ironclad_class_attrs['__new__'] = __new__
_ironclad_class_attrs['__del__'] = __del__

_ironclad_class = _ironclad_metaclass('{0}', _ironclad_bases, 
_ironclad_class_attrs)
_ironclad_class.__doc__ = '''{2}'''
_ironclad_class.__module__ = '{1}'
";
------------------------------------------------------------

...while the code that actually constructs ipy objects around cpy 
objects looks like this:

------------------------------------------------------------
       
        private void
        ActualiseArbitraryObject(IntPtr ptr)
        {
            IntPtr typePtr = CPyMarshal.ReadPtrField(ptr, 
typeof(PyObject), "ob_type");
            PythonType type_ = (PythonType)this.Retrieve(typePtr);

            object[] args = new object[]{};
            if (Builtin.issubclass(type_, TypeCache.Int32))
            {
                args = new object[] { CPyMarshal.ReadIntField(ptr, 
typeof(PyIntObject), "ob_ival") };
            }
            if (Builtin.issubclass(type_, TypeCache.Double))
            {
                args = new object[] { CPyMarshal.ReadDoubleField(ptr, 
typeof(PyFloatObject), "ob_fval") };
            }
            // ...
           
            object obj = PythonCalls.Call(this.classStubs[typePtr], args);
            Builtin.setattr(this.scratchContext, obj, "__class__", type_);
            // ...
        }
------------------------------------------------------------

BTW: As it happens, the stub class is now a sibling of the real class 
rather than a subclass, because it feels cleaner. Regardless, the 
behaviour is identical in each case.

Cheers
william

Dino Viehland wrote:
> Could this be issue 2?
>
> class Real(object):
>     def __new__(cls, *args, **kwargs):
>         print 'real new'
>         return object.__new__(Stub)
>     #def __del__(self): pass     # uncomment me and this works as expected
>
> class Stub(Real):
>     def __del__(self):
>         print "I've been finalized"
>
> f = Real(1.0)
> del f
>
> import sys
> if sys.platform == 'clr':
>     import clr
>     from System import GC
>     for _ in range(4):
>         GC.Collect()
>         GC.WaitForPendingFinalizers()
>
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Monday, July 20, 2009 9:38 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] object lifecycle issues
>>
>> Hi all
>>
>> I have two problems that are at least somewhat related:
>>
>> +++ Issue 1 (probably your bug):
>>
>> ---------------------------------------------------------------
>> C:\dev\ironclad - Copy>ipy y.py
>> real new
>> stub new
>> real init
>> real del
>>
>> C:\dev\ironclad - Copy>python y.py
>> real new
>> stub new
>> stub init
>> real del
>> ---------------------------------------------------------------
>>
>> I freely admit that the attached code is pretty weird, but I really do
>> need to do stuff like this in Ironclad. The difference in behaviour may
>> or may not be responsible for certain failing numpy/scipy tests -- I'm
>> not sure how to tell -- but I'd enormously appreciate a fix.
>>
>> I'd report the issue on Codeplex, but trying to visit the issue tracker
>> just leaves my browser spinning forever. Speaking of which: is there
>> any alternative way of reporting bugs that doesn't make me feel as if
>> I'm spamming the list with out-of-band noise? I'm pretty sure that a
>> few bugs have just dropped off my stack in the last few months, just
>> because I got tired of waiting for Codeplex to start working.
>>
>> +++ Issue 2 (almost certainly my bug):
>>
>> In a nearly identical* situation -- close enough that I can't say how
>> it's actually different -- f will never get its __del__ method called
>> (the object is destroyed -- a WeakReference to it knows it's dead --
>> but the __del__ call never happens).
>>
>> For context: I have *very* similar classes, whose instances are
>> constructed in exactly the weird way demonstrated in the attached file,
>> and which work fine. The only difference between the cases that work
>> and the cases that don't is that the broken cases multiply inherit from
>> ipy types which wrap CLR types (int and float (and maybe str, although
>> I haven't tested that one)), while the working cases have simple chains
>> of single inheritance from user-defined types all the way up to object.
>> However, the attached repro doesn't show my problem, so it's clearly
>> not
>> *just* to do with multiply inheriting from CLR types.
>>
>> Does anyone have any idea what I might be doing wrong? I know this is a
>> vague request, but I'm running out of ideas, and I'd really appreciate
>> some input from someone who understands precisely what all those ipy
>> MetaFoo classes are doing.
>>
>> Cheers
>> william
>>
>>
>> * the attached file started life as an attempt to repro the __del__
>> issue, and I incidentally noticed the __init__ issue.
>>     
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: x.py
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090721/2ebc1cb5/attachment.ksh>

From william at resolversystems.com  Tue Jul 21 18:19:52 2009
From: william at resolversystems.com (William Reade)
Date: Tue, 21 Jul 2009 17:19:52 +0100
Subject: [IronPython] object lifecycle issues
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A65EAA8.4000909@resolversystems.com>

Dino Viehland wrote:
> #2 I'd guess could be either that for some reason we're failing to
> detect the presence of __del__ or that when we run the finalizer cleanup
> that we believe it's part of cyclic trash and don't think we should cleanup.
> Of those I'd think it'd be the cyclic trash detection that'd be most
> likely to go wrong.
>
> I'd suggest putting a break point or some logging in
> PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer
> and see what's happening there.
>   

In PythonOps.InitializeForFinalization, I see 2 InstanceFinalizers 
created for each object; one after the stub __new__, and one after the 
real __new__. Each IF creates a WeakRefTracker as expected; in both 
cases, the second WRT (and only the second one) is subsequently 
GC.SuppressFinalized in SetFinalizerWorker. However, in the broken 
cases, the WRT finalizer just never gets called.

I'll keep hunting, but it seemed worth posting this in case it rang any 
bells.

Cheers
william




From dinov at microsoft.com  Wed Jul 22 01:09:27 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 21 Jul 2009 23:09:27 +0000
Subject: [IronPython] object lifecycle issues
In-Reply-To: <4A65EAA8.4000909@resolversystems.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD034A0D47@TK5EX14MBXC116.redmond.corp.microsoft.com>

The first 2 things that occur to me is that either there's an exception
happening when we run WeakRefTracker's finalizer (it swallows exceptions)
or the object simply isn't being collected.

But it definitely sounds like we're creating the object which will
ultimately call __del__ when it gets finalized.

Have you tried windbg + SOS and done a !DumpHeap to see if the object
could still be alive?  Another thought would be to look at the finalizer
queue and make sure it's not blocked on something (like a transition
into an STA).


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Tuesday, July 21, 2009 9:20 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] object lifecycle issues
>
> Dino Viehland wrote:
> > #2 I'd guess could be either that for some reason we're failing to
> > detect the presence of __del__ or that when we run the finalizer
> cleanup
> > that we believe it's part of cyclic trash and don't think we should
> cleanup.
> > Of those I'd think it'd be the cyclic trash detection that'd be most
> > likely to go wrong.
> >
> > I'd suggest putting a break point or some logging in
> > PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer
> > and see what's happening there.
> >
>
> In PythonOps.InitializeForFinalization, I see 2 InstanceFinalizers
> created for each object; one after the stub __new__, and one after the
> real __new__. Each IF creates a WeakRefTracker as expected; in both
> cases, the second WRT (and only the second one) is subsequently
> GC.SuppressFinalized in SetFinalizerWorker. However, in the broken
> cases, the WRT finalizer just never gets called.
>
> I'll keep hunting, but it seemed worth posting this in case it rang any
> bells.
>
> Cheers
> william
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From ddicato at microsoft.com  Wed Jul 22 05:11:02 2009
From: ddicato at microsoft.com (David DiCato)
Date: Wed, 22 Jul 2009 03:11:02 +0000
Subject: [IronPython] Announcing IronPython 2.0.2
Message-ID: <EC95D8CD3A6FC84084BEB2D76FB1AC5804B1F6@TK5EX14MBXC101.redmond.corp.microsoft.com>

Hello Python Community,

I am delighted to announce the release of IronPython 2.0.2. This release is a minor update to IronPython 2.0.1, which in turn is a CPython 2.5-compatible release running on the .NET platform. Our priority was to make IronPython 2.0.2 a bugfix release that remains backwards-compatible with IronPython 2.0.1. In particular, we focused on issues the IronPython community brought to our attention through http://www.codeplex.com/. As such, there have been important improvements on the compatibility and stability of IronPython as summarized below.

You can download IronPython 2.0.2 at: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22981

Silverlight users: A new version of Silverlight, specifically Silverlight 3, is required to build the "Silverlight Release" or "Silverlight Debug" configurations of IronPython.sln. Please update Silverlight accordingly if you intend to do so.

Detailed change summary:

Fixed specifically for 2.0.2:

*         21577 - binascii.crc32 doesn't accept one argument.

*         20616 - wrong TypeError message when invoking "str.join": implicit parameter 'self' not counted

*         19665 - 2.0.2: operator.isSequenceType(NewStyleClass) broken

*         20087 - 2.0.2: Null Value Exception in COM interop

*         21445 - DLR:  There is a dead loop in CallSite.UpdateAndExecute(), which leads to IronPython 2.0.1 hang.

*         22001 - 2.0.2:  Ngen IronPython.msi option doesn't work on 64-bit platforms?

*         22094 - 2.0.2: StringException leaked to Python via sys.exc_info()

*         22239 - 2.0.2: modules aren't isolated

Backported 2.6 fixes:

*         20634 - hex_codec needs to be imported before hex decode can happen

*         20302 - codecs.lookup errors with uppercase encoding names

*         20051 - Re-raising exception causes loss of traceback

*         4565 - Support all encodings CPython does for _codecs.encode and  _codecs.decode

*         20603 - os.walk('') doesn't work

*         21929 - os.listdir does not accept empty path

*         17235 - dir(System.ArgIterator) broken

I would especially like to thank adamilan, dungen, fuzzyman, hfoffani, hhonisch, kuno, orestis, sanxiyn, and tkamiya for raising these issues. By taking the time to share their insights, these CodePlex users have brought about tangible improvements in the quality of IronPython. Keep those bug reports coming!

- The IronPython Team

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

From Jimmy.Schementi at microsoft.com  Wed Jul 22 05:50:35 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Wed, 22 Jul 2009 03:50:35 +0000
Subject: [IronPython] [Code Review] "XAP-less" Silverlight application
 support
In-Reply-To: <0047ECBFA2E0DF4A834AA369282A5AFC18B5A4FA@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <0047ECBFA2E0DF4A834AA369282A5AFC18B56732@tk5ex14mbxc105.redmond.corp.microsoft.com>,
	<4A658C48.5010001@voidspace.org.uk>,
	<0047ECBFA2E0DF4A834AA369282A5AFC18B5A4FA@tk5ex14mbxc105.redmond.corp.microsoft.com>
Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC18B6F742@tk5ex14mbxc106.redmond.corp.microsoft.com>

"That project" is online now: http://visitmix.com/labs/gestalt/

And here's my take: http://blog.jimmy.schementi.com/2009/07/gestalt-ruby-and-python-in-browser.html
________________________________________
From: Jimmy Schementi
Sent: Tuesday, July 21, 2009 4:21 AM
To: Discussion of IronPython
Cc: ironruby-core at rubyforge.org
Subject: RE: [IronPython] [Code Review] "XAP-less" Silverlight application support

Michael,

You just had to ask now =P ... I was going to blog about this more extensively tomorrow, but here's a preview of my thinking about this:

My motivation behind xap-less is to make DLR Silverlight apps less complex, and more like how the web works. This change is just an experiment in that direction, and I'm very open to any opinions folks have about this.

First things first though, this change make xap-less completely opt-in ... you have to use the "downloadScripts=true" InitParams setting to enable it. Without this param it will behave as it used to. Also, even with this setting it will not download the file if it exists in the XAP. I was very conservative about this change, as I'm just playing around with some ideas.

Also, even if xap-less becomes the default, I'd make sure existing deployments did not break; in the xap will always be an option for deployment (and quite possibly the preferred way), but I want to get back to the place where we didn't need a XAP file and didn't need Chiron for development.

Eh, I know that was the messaging around XAP files being compressed and faster for download times, but that's because they were synchronously downloaded and the browser can only handle one of those at once. If you use gzip-compression on your web-server and download each file asynchronously, I don't think you'll see much of a difference. However, "minifying" Ruby or Python like most JavaScript is really not possible, so people could always opt for a XAP file. But I really want to give back the text-only experience, even for deployment. There are still good ways to support asynchronous downloading of files that get imported (I'll talk about that below), so we should still explore those ... especially since this is the way browsers work today.

Imagine if Ruby and Python in the browser felt not that much different than JavaScript, but allow for other deployment options if the app needs it. For example, a Python Silverlight Hello World app should just be this:

<!-- index.html -->
<script type="text/javascript" src="silverlight-dlr.js"></script>
<div id="message"></div>
<script type="application/python">
document.message.innerHTML = "Hello, World!"
</script>

Very simple and clean. No need to start a web-server or install Mono on the Mac just to make a client-side page. The JS file hosts Silverlight, and then Microsoft.Scripting.Silverlight scans the HTML page looking for <script> tags, executing them as they are encountered. Pre-packaged xap files are there so a basic app would never need to touch the XAP. There is a project being released today on http://visitmix.com/Lab which implements SL Ruby and Python apps just like this, with the intention that the ideas about making things simpler are merged back into Microsoft.Scripting.Silverlight. I'll send out links when it's live, but hopefully you'll just hear about it. =)

FWIW, I'd leave the "entryPoint" activation in there as well, so only if you didn't set entryPoint OR didn't have a valid entry point in the XAP then we'd look at the HTML page for <script> tags ... we can deprecate it if enough people stop using entryPoint. Also, it's a little strange to take a bunch of python islands and assume it's one module. Should those islands be their own modules? Also, I know there might be some standards issues with doing a <script type=""> when it's not a list of approved types. We'll have to make sure this is done in a standards-compliant way, as I'd love to see browsers support this out of the box (ha, yeah, sounds crazy I know), and this work should be a stepping stone to that. I've already reviewed the visitmix.com/Lab project and there are some standards issues that I'll blog about tomorrow, so please don't get caught up on a prototype or proposal, just imagine what things could be like. =P

This scales to bringing in other files too, as you can use <script type="application/python" src="foo.py" />. Microsoft.Scripting.Silverlight would scan the HTML file for <script> tags with the src attribute, and download the files ahead of time. But what happens if those files "import" something? The visitmix project I was referring to does not handle this case, since it's just a prototype of how browsers could support multiple languages. But we'd need to support this. And this is where it could look back the XAP. So if we ever did take away entryPoint then you'd activate your apps by just doing this:

<script type="application/python">
  import app
</script>

If an import failed against the XAP, it could look on the web-server. Though today's implementation is synchronous, that needs to change. So the guidance would be to either to put those files in the XAP, or allow the app-author to specify their dependencies up-front (like JavaScript does, it could even be with <script> tags also) so those files could be downloaded and import would just run the contents of the pre-downloaded files. Unfortunately, even if we could do import asynchronously (by making import/require/etc continuation-aware), the downloads would still happen one at a time, which is unacceptable for deployment. So it's either the up-front-list or in the XAP.

WRT sharing IronPython assemblies between apps, that change was kinda silently checked in around SL3 RTW since I wanted to test things a bit more, and find a place to host the packages. Documentation will pop up on the IronPython codeplex site in a few weeks about how this all works. And the way you host your apps should still be caching it, but you'll see a download request (in Firebug for example). Are you sure they are being fully downloaded each time? Maybe the AppManifest.xaml downloading is forcing a download each time, but I remember it going to the browser cache.

I know that was kinda long winded, but I'm pretty happy about fixing a lot of the ugliness we had to add from SL1.1 to SL2, while keeping the deployment benefits SL2 had, even if they are in a different form. Today's model is too complicated for people coming from JavaScript to get started, so lowering the bar to the <script> tag level may get the attention of more developers. Let me know if anyone has more questions about this.

~js

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Michael Foord [fuzzyman at voidspace.org.uk]
Sent: Tuesday, July 21, 2009 2:37 AM
To: Discussion of IronPython
Cc: ironruby-core at rubyforge.org
Subject: Re: [IronPython] [Code Review] "XAP-less" Silverlight application support

Hello Jimmy,

Will xap-less be an 'alternative' deployment scenario for dynamic
silverlight applications or the 'new and only' deployment scenario?

If it becomes the 'right' way to do it please realise that you are in
one swoop obsoleting all the articles, tutorials, examples (and books)
on developing Silverlight applications with IronPython / IronRuby. There
better be a big payoff for such a hugely backwards incompatible move...

When the move to xap files happened we were told this was a big win for
dynamic languages as all needed Python (or Ruby) files would be
downloaded compressed - and this was *much* faster than downloading them
synchronously on import (as the integration in Silverlight 1.1
originally did). What is the motivation for the change?

Does this change allow the IronPython assemblies to be shared between
applications (and cached)? I realise this can be done already (I use it
with my examples) - but I still see the IronPython assemblies being
re-downloaded every time you refresh the page or go to a new example,
even though they are from the same location.

Michael


Jimmy Schementi wrote:
> (Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)
>
> http://github.com/jschementi/ironruby/commit/da6b54e226adfd3a18d8ad98d618c2350ebd8351
>
> Beginnings of "XAP-less" Silverlight application support. Note: Silverlight apps are *required* to have a XAP file, but with this change it can get down to just a container for the AppManifest.xaml file. Python/Ruby would ship with a single XAP file pointing to the .slvx files for a given release.
>
> Adds a "downloadScripts" initParam to indicate whether paths to script files and XAML files should be resolved to the web-server (relative to the XAP), if the file is not found in the XAP. Also adds "downloadScriptsFrom" to customize what path they are based off of. Because of the opt-in nature of this change, existing DLR Silverlight apps should not break.
>
> Files are downloaded synchronously as code runs, by having the PlatformAdaptationLayer use a new BrowserVirtualFilesystem: HttpVirtualFilesystem. So when a language's include mechanism is used (require , load, import, etc), it will download the file by using XmlHttpRequest in synchronous mode. It will also cache each downloaded file's contents, so a file will only be downloaded once, even if it is included multiple times. Note: future work will hopefully allow asynchronous includes, so this can be production-ready. For now, it should only be used for development.
>
> Note: this change decreases the need for Chiron significantly. In this mode, Chiron only creates a XAP file with the necessary assemblies and AppManifest.xaml, if it doesn't exist already. One could imagine providing a XAP file for each language, and then Chiron wouldn't be needed for development. However, for using the latest language assemblies, and auto-detection of languages used, it's still useful for development. So some changes have been made to Chiron to support this better:
>
> A "localApplicationRoot" appSetting has been added to Chiron to adjust where it looks for script files (when determining what languages are used). This allows you to make sure Chiron is looking in the same place your application is downloading scripts or xaml from, so it can still generate a correct XAP file for you. "application/ruby" and "application/python" mime-types have been also added to Chiron also to enable downloading of those script files.
>
> All of Chiron's appSettings are now override-able as command-line switches: /u[rlPrefix], /e[xtUrlPrefix], /l[ocalAppRoot]
>
> Run Merlin/Main/Hosts/SilverLight/Tests/tests/manual/test_foox/run.bat for an example of how this works (it requires a Silverlight Debug build, so if you run Merlin/Main/Languages/Ruby/Scripts/Dev.bat, just run "bsd" and that will *b*uild *s*ilverlight in *d*ebug mode)
>
> Adds a stub for similar support through IsolatedStorage, but that will come later.
>
> Also tweaks the DynamicEngine.CreateRuntimeSetup method to better support other DLR-hosts in Silverlight (http://lists.ironpython.com/pipermail/users-ironpython.com/2009-July/010780.html).
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


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

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



From fuzzyman at voidspace.org.uk  Wed Jul 22 13:15:22 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 22 Jul 2009 12:15:22 +0100
Subject: [IronPython] [Code Review] "XAP-less" Silverlight application
 support
In-Reply-To: <0047ECBFA2E0DF4A834AA369282A5AFC18B6F742@tk5ex14mbxc106.redmond.corp.microsoft.com>
References: <0047ECBFA2E0DF4A834AA369282A5AFC18B56732@tk5ex14mbxc105.redmond.corp.microsoft.com>,
	<4A658C48.5010001@voidspace.org.uk>,
	<0047ECBFA2E0DF4A834AA369282A5AFC18B5A4FA@tk5ex14mbxc105.redmond.corp.microsoft.com>
	<0047ECBFA2E0DF4A834AA369282A5AFC18B6F742@tk5ex14mbxc106.redmond.corp.microsoft.com>
Message-ID: <4A66F4CA.1050302@voidspace.org.uk>

Jimmy Schementi wrote:
> "That project" is online now: http://visitmix.com/labs/gestalt/
>
> And here's my take: http://blog.jimmy.schementi.com/2009/07/gestalt-ruby-and-python-in-browser.html
>   

All very cool. Will take some thinking about...

Michael


> ________________________________________
> From: Jimmy Schementi
> Sent: Tuesday, July 21, 2009 4:21 AM
> To: Discussion of IronPython
> Cc: ironruby-core at rubyforge.org
> Subject: RE: [IronPython] [Code Review] "XAP-less" Silverlight application support
>
> Michael,
>
> You just had to ask now =P ... I was going to blog about this more extensively tomorrow, but here's a preview of my thinking about this:
>
> My motivation behind xap-less is to make DLR Silverlight apps less complex, and more like how the web works. This change is just an experiment in that direction, and I'm very open to any opinions folks have about this.
>
> First things first though, this change make xap-less completely opt-in ... you have to use the "downloadScripts=true" InitParams setting to enable it. Without this param it will behave as it used to. Also, even with this setting it will not download the file if it exists in the XAP. I was very conservative about this change, as I'm just playing around with some ideas.
>
> Also, even if xap-less becomes the default, I'd make sure existing deployments did not break; in the xap will always be an option for deployment (and quite possibly the preferred way), but I want to get back to the place where we didn't need a XAP file and didn't need Chiron for development.
>
> Eh, I know that was the messaging around XAP files being compressed and faster for download times, but that's because they were synchronously downloaded and the browser can only handle one of those at once. If you use gzip-compression on your web-server and download each file asynchronously, I don't think you'll see much of a difference. However, "minifying" Ruby or Python like most JavaScript is really not possible, so people could always opt for a XAP file. But I really want to give back the text-only experience, even for deployment. There are still good ways to support asynchronous downloading of files that get imported (I'll talk about that below), so we should still explore those ... especially since this is the way browsers work today.
>
> Imagine if Ruby and Python in the browser felt not that much different than JavaScript, but allow for other deployment options if the app needs it. For example, a Python Silverlight Hello World app should just be this:
>
> <!-- index.html -->
> <script type="text/javascript" src="silverlight-dlr.js"></script>
> <div id="message"></div>
> <script type="application/python">
> document.message.innerHTML = "Hello, World!"
> </script>
>
> Very simple and clean. No need to start a web-server or install Mono on the Mac just to make a client-side page. The JS file hosts Silverlight, and then Microsoft.Scripting.Silverlight scans the HTML page looking for <script> tags, executing them as they are encountered. Pre-packaged xap files are there so a basic app would never need to touch the XAP. There is a project being released today on http://visitmix.com/Lab which implements SL Ruby and Python apps just like this, with the intention that the ideas about making things simpler are merged back into Microsoft.Scripting.Silverlight. I'll send out links when it's live, but hopefully you'll just hear about it. =)
>
> FWIW, I'd leave the "entryPoint" activation in there as well, so only if you didn't set entryPoint OR didn't have a valid entry point in the XAP then we'd look at the HTML page for <script> tags ... we can deprecate it if enough people stop using entryPoint. Also, it's a little strange to take a bunch of python islands and assume it's one module. Should those islands be their own modules? Also, I know there might be some standards issues with doing a <script type=""> when it's not a list of approved types. We'll have to make sure this is done in a standards-compliant way, as I'd love to see browsers support this out of the box (ha, yeah, sounds crazy I know), and this work should be a stepping stone to that. I've already reviewed the visitmix.com/Lab project and there are some standards issues that I'll blog about tomorrow, so please don't get caught up on a prototype or proposal, just imagine what things could be like. =P
>
> This scales to bringing in other files too, as you can use <script type="application/python" src="foo.py" />. Microsoft.Scripting.Silverlight would scan the HTML file for <script> tags with the src attribute, and download the files ahead of time. But what happens if those files "import" something? The visitmix project I was referring to does not handle this case, since it's just a prototype of how browsers could support multiple languages. But we'd need to support this. And this is where it could look back the XAP. So if we ever did take away entryPoint then you'd activate your apps by just doing this:
>
> <script type="application/python">
>   import app
> </script>
>
> If an import failed against the XAP, it could look on the web-server. Though today's implementation is synchronous, that needs to change. So the guidance would be to either to put those files in the XAP, or allow the app-author to specify their dependencies up-front (like JavaScript does, it could even be with <script> tags also) so those files could be downloaded and import would just run the contents of the pre-downloaded files. Unfortunately, even if we could do import asynchronously (by making import/require/etc continuation-aware), the downloads would still happen one at a time, which is unacceptable for deployment. So it's either the up-front-list or in the XAP.
>
> WRT sharing IronPython assemblies between apps, that change was kinda silently checked in around SL3 RTW since I wanted to test things a bit more, and find a place to host the packages. Documentation will pop up on the IronPython codeplex site in a few weeks about how this all works. And the way you host your apps should still be caching it, but you'll see a download request (in Firebug for example). Are you sure they are being fully downloaded each time? Maybe the AppManifest.xaml downloading is forcing a download each time, but I remember it going to the browser cache.
>
> I know that was kinda long winded, but I'm pretty happy about fixing a lot of the ugliness we had to add from SL1.1 to SL2, while keeping the deployment benefits SL2 had, even if they are in a different form. Today's model is too complicated for people coming from JavaScript to get started, so lowering the bar to the <script> tag level may get the attention of more developers. Let me know if anyone has more questions about this.
>
> ~js
>
> ________________________________________
> From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] on behalf of Michael Foord [fuzzyman at voidspace.org.uk]
> Sent: Tuesday, July 21, 2009 2:37 AM
> To: Discussion of IronPython
> Cc: ironruby-core at rubyforge.org
> Subject: Re: [IronPython] [Code Review] "XAP-less" Silverlight application support
>
> Hello Jimmy,
>
> Will xap-less be an 'alternative' deployment scenario for dynamic
> silverlight applications or the 'new and only' deployment scenario?
>
> If it becomes the 'right' way to do it please realise that you are in
> one swoop obsoleting all the articles, tutorials, examples (and books)
> on developing Silverlight applications with IronPython / IronRuby. There
> better be a big payoff for such a hugely backwards incompatible move...
>
> When the move to xap files happened we were told this was a big win for
> dynamic languages as all needed Python (or Ruby) files would be
> downloaded compressed - and this was *much* faster than downloading them
> synchronously on import (as the integration in Silverlight 1.1
> originally did). What is the motivation for the change?
>
> Does this change allow the IronPython assemblies to be shared between
> applications (and cached)? I realise this can be done already (I use it
> with my examples) - but I still see the IronPython assemblies being
> re-downloaded every time you refresh the page or go to a new example,
> even though they are from the same location.
>
> Michael
>
>
> Jimmy Schementi wrote:
>   
>> (Sending this review broadly as it shows a new direction DLR Silverlight apps are taking)
>>
>> http://github.com/jschementi/ironruby/commit/da6b54e226adfd3a18d8ad98d618c2350ebd8351
>>
>> Beginnings of "XAP-less" Silverlight application support. Note: Silverlight apps are *required* to have a XAP file, but with this change it can get down to just a container for the AppManifest.xaml file. Python/Ruby would ship with a single XAP file pointing to the .slvx files for a given release.
>>
>> Adds a "downloadScripts" initParam to indicate whether paths to script files and XAML files should be resolved to the web-server (relative to the XAP), if the file is not found in the XAP. Also adds "downloadScriptsFrom" to customize what path they are based off of. Because of the opt-in nature of this change, existing DLR Silverlight apps should not break.
>>
>> Files are downloaded synchronously as code runs, by having the PlatformAdaptationLayer use a new BrowserVirtualFilesystem: HttpVirtualFilesystem. So when a language's include mechanism is used (require , load, import, etc), it will download the file by using XmlHttpRequest in synchronous mode. It will also cache each downloaded file's contents, so a file will only be downloaded once, even if it is included multiple times. Note: future work will hopefully allow asynchronous includes, so this can be production-ready. For now, it should only be used for development.
>>
>> Note: this change decreases the need for Chiron significantly. In this mode, Chiron only creates a XAP file with the necessary assemblies and AppManifest.xaml, if it doesn't exist already. One could imagine providing a XAP file for each language, and then Chiron wouldn't be needed for development. However, for using the latest language assemblies, and auto-detection of languages used, it's still useful for development. So some changes have been made to Chiron to support this better:
>>
>> A "localApplicationRoot" appSetting has been added to Chiron to adjust where it looks for script files (when determining what languages are used). This allows you to make sure Chiron is looking in the same place your application is downloading scripts or xaml from, so it can still generate a correct XAP file for you. "application/ruby" and "application/python" mime-types have been also added to Chiron also to enable downloading of those script files.
>>
>> All of Chiron's appSettings are now override-able as command-line switches: /u[rlPrefix], /e[xtUrlPrefix], /l[ocalAppRoot]
>>
>> Run Merlin/Main/Hosts/SilverLight/Tests/tests/manual/test_foox/run.bat for an example of how this works (it requires a Silverlight Debug build, so if you run Merlin/Main/Languages/Ruby/Scripts/Dev.bat, just run "bsd" and that will *b*uild *s*ilverlight in *d*ebug mode)
>>
>> Adds a stub for similar support through IsolatedStorage, but that will come later.
>>
>> Also tweaks the DynamicEngine.CreateRuntimeSetup method to better support other DLR-hosts in Silverlight (http://lists.ironpython.com/pipermail/users-ironpython.com/2009-July/010780.html).
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From william at resolversystems.com  Wed Jul 22 13:52:24 2009
From: william at resolversystems.com (William Reade)
Date: Wed, 22 Jul 2009 12:52:24 +0100
Subject: [IronPython] object lifecycle issues
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD034A0D47@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034A0D47@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A66FD78.7090303@resolversystems.com>

Damn, it's my problem -- sorry for the noise. It seems that 
IronPython.NewTypes.BlahBlah.ExtensibleBlah types don't handle equality 
quite how I expected... clearly, I need to learn to fire up windbg 
*before* I post. At least we rediscovered the __del__ bug ;-).

Incidentally, congratulations on 2.0.2!

Dino Viehland wrote:
> The first 2 things that occur to me is that either there's an exception
> happening when we run WeakRefTracker's finalizer (it swallows exceptions)
> or the object simply isn't being collected.
>
> But it definitely sounds like we're creating the object which will
> ultimately call __del__ when it gets finalized.
>
> Have you tried windbg + SOS and done a !DumpHeap to see if the object
> could still be alive?  Another thought would be to look at the finalizer
> queue and make sure it's not blocked on something (like a transition
> into an STA).
>
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of William Reade
>> Sent: Tuesday, July 21, 2009 9:20 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] object lifecycle issues
>>
>> Dino Viehland wrote:
>>     
>>> #2 I'd guess could be either that for some reason we're failing to
>>> detect the presence of __del__ or that when we run the finalizer
>>>       
>> cleanup
>>     
>>> that we believe it's part of cyclic trash and don't think we should
>>>       
>> cleanup.
>>     
>>> Of those I'd think it'd be the cyclic trash detection that'd be most
>>> likely to go wrong.
>>>
>>> I'd suggest putting a break point or some logging in
>>> PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer
>>> and see what's happening there.
>>>
>>>       
>> In PythonOps.InitializeForFinalization, I see 2 InstanceFinalizers
>> created for each object; one after the stub __new__, and one after the
>> real __new__. Each IF creates a WeakRefTracker as expected; in both
>> cases, the second WRT (and only the second one) is subsequently
>> GC.SuppressFinalized in SetFinalizerWorker. However, in the broken
>> cases, the WRT finalizer just never gets called.
>>
>> I'll keep hunting, but it seemed worth posting this in case it rang any
>> bells.
>>
>> Cheers
>> william
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From dinov at microsoft.com  Wed Jul 22 17:56:30 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 22 Jul 2009 15:56:30 +0000
Subject: [IronPython] object lifecycle issues
In-Reply-To: <4A66FD78.7090303@resolversystems.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034A0D47@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A66FD78.7090303@resolversystems.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD034DA361@TK5EX14MBXC120.redmond.corp.microsoft.com>

And just the __init__ bug is bad enough that it makes it all worth
it! :)

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Wednesday, July 22, 2009 4:52 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] object lifecycle issues
>
> Damn, it's my problem -- sorry for the noise. It seems that
> IronPython.NewTypes.BlahBlah.ExtensibleBlah types don't handle equality
> quite how I expected... clearly, I need to learn to fire up windbg
> *before* I post. At least we rediscovered the __del__ bug ;-).
>
> Incidentally, congratulations on 2.0.2!
>
> Dino Viehland wrote:
> > The first 2 things that occur to me is that either there's an
> exception
> > happening when we run WeakRefTracker's finalizer (it swallows
> exceptions)
> > or the object simply isn't being collected.
> >
> > But it definitely sounds like we're creating the object which will
> > ultimately call __del__ when it gets finalized.
> >
> > Have you tried windbg + SOS and done a !DumpHeap to see if the object
> > could still be alive?  Another thought would be to look at the
> finalizer
> > queue and make sure it's not blocked on something (like a transition
> > into an STA).
> >
> >
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of William Reade
> >> Sent: Tuesday, July 21, 2009 9:20 AM
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] object lifecycle issues
> >>
> >> Dino Viehland wrote:
> >>
> >>> #2 I'd guess could be either that for some reason we're failing to
> >>> detect the presence of __del__ or that when we run the finalizer
> >>>
> >> cleanup
> >>
> >>> that we believe it's part of cyclic trash and don't think we should
> >>>
> >> cleanup.
> >>
> >>> Of those I'd think it'd be the cyclic trash detection that'd be
> most
> >>> likely to go wrong.
> >>>
> >>> I'd suggest putting a break point or some logging in
> >>> PythonOps.InitializeForFinalization and in WeakRefTracker's
> finalizer
> >>> and see what's happening there.
> >>>
> >>>
> >> In PythonOps.InitializeForFinalization, I see 2 InstanceFinalizers
> >> created for each object; one after the stub __new__, and one after
> the
> >> real __new__. Each IF creates a WeakRefTracker as expected; in both
> >> cases, the second WRT (and only the second one) is subsequently
> >> GC.SuppressFinalized in SetFinalizerWorker. However, in the broken
> >> cases, the WRT finalizer just never gets called.
> >>
> >> I'll keep hunting, but it seemed worth posting this in case it rang
> any
> >> bells.
> >>
> >> Cheers
> >> william
> >>
> >>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.ironpython.com
> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From merllab at microsoft.com  Thu Jul 23 01:31:59 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Wed, 22 Jul 2009 16:31:59 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <5a79ad04-e45f-498f-a278-0f046fd46f84@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57033.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/CodeContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonDynamicStackFrame.cs

DELETED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/RuleBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/CodeContextExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/CodeContext.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserVirtualFilesystem.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicEngine.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Chiron.csproj
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/ArrayGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/SavableGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/StaticGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonDeleteMemberBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/OnDiskScriptCode.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/Python.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaOldInstance.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaUserObject.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaPythonType.Members.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/ConversionBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaOldClass.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_weakref.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IronPython.Modules.csproj
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/PythonCommandLine.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstGenerator.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Readme.html
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/CodeContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonDynamicStackFrame.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonOverloadResolver.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.Core.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.ExtensionAttribute.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ActionBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ConditionalBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.Conversions.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/DynamicMetaObjectBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/BoundMemberTracker.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Bytes.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonGetMemberBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonSetMemberBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonProtocol.Operations.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonProtocol.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonFunction.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Descriptors.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Method.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/CustomAttributeTracker.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeSlot.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/BuiltinFunction.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/ReflectedField.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/BuiltinMethodDescriptor.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/ReflectedProperty.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldInstance.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldClass.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Interfaces.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPythonTest/IronPythonTest.csproj
	$/IronPython/IronPython_Main/Src/IronPythonTest/InheritTest.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/NamespaceTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/MethodGroup.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.Operations.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/TypeTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/PropertyTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/MemberTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.DeleteMember.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/ErrorInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.GetMember.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.SetMember.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/TypeGroup.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/EventTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/MethodTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/FieldTracker.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/DefaultBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightLambda.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/LambdaBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/DefaultLanguageContext.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/BinderOps.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Generation/CompilerHelpers.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/IMembersList.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/DynamicStackFrame.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/ExceptionHelpers.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/CollectionUtils.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/ReadOnlyDictionary.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/SynchronizedDictionary.cs

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1011160
Date: 7/21/2009 9:49:14 AM

(dinov) Moves CodeContext up into IronPython.

Wherever we had CodeContext before or an Expression for flowing CodeContext it?s been replaced w/ a OverloadResolverFactory instead.
There?s lots of now we flow full MetaObjects instead of just flowing Expressions through in the DLR binding (more cleanup could be done here in the future)
Added IPythonMembersList which takes CodeContext, made IMembersList not take it.
Removed some dead code related to old-style DLR binders

Also fixing 20262 - quoting in MSBuild files


(Shelveset: MoveCodeContextFinal2;REDMOND\dinov | SNAP CheckinId: 8965)
--------------------------------------------------------------------------------
Changeset Id: 1001128
Date: 7/15/2009 5:31:19 PM

(dinov) Fixes:
19585 2.6: object.__init__ should not accept arbitrary arguments (http://bugs.python.org/issue1683368) 
	This adds the appropriate checks to object.__init__.  We now cache whether or not __init__ / __new__ is object.__init__ / object.__new__ in types and update it when it changes.  We don?t invalidate this cache when the values are deleted to match the current (buggy?  I?ve sent a mail to python-dev) CPython behavior.  This change also showed several different types that didn?t have their ctors defined quite right.  List/set/deque all need new?s.   Also added some overloads so that we don?t need to construct params arrays / kw dicts.   Switched to using  a shared lock when updating subtypes so traversing the subclass hierarchy can?t get into weird lock ordering issues.

23499 String Formatting Operations error
	PythonDict.TryGetValue should call __missing__ if it?s defined ? this is just moving the code from GetItem.

Also adds pre-compiled rules for creating types.  The code to support this lives in PythonType.Generated.cs and PythonType becomes IFastInvokable.  These support a subset of the full path ? basically just calling classes that only have default ctors where the type may have user defined __new__ or __init__ if they?re just simple functions.  Also making the BuiltinFunction?s used to call the base class ctor to be shared between all subtypes.  Combined this gives around a 10-15% improvement on ParrotBench which should bring is back to where we were before auto-templating was removed.



(Shelveset: TypeCtorsFinal;REDMOND\dinov | SNAP CheckinId: m9707)
--------------------------------------------------------------------------------
Changeset Id: 1001127
Date: 7/15/2009 5:29:52 PM

(dinov) Updates assembly versions for the 2.6B2 release.  Versions are rev?d to 2.6.0.20 / 0.9.6.20.

This effects IronPython, DLR (including the inner layer w/ updates to files that don?t effect the System.Core build).



(Shelveset: UpdateVersions262_Final;REDMOND\dinov | SNAP CheckinId: m9707)
--------------------------------------------------------------------------------
Changeset Id: 1000980
Date: 7/15/2009 4:17:29 PM

(dinov) Fixes a few lifetime management issues w/ ctypes and adds a ?X:GCStress command line option to help flush issues like these out.

These fixes all come from a run of test_ctypes.py under ?X:GCStress 2 mode.  This forces a full gen-2 collection for every single Python statement.  For the most part the issues are all things which test_ctypes is actually testing for but we didn?t see before due to our GC taking some time to kick in.  There?s still 1 remaining failure under ?X:GCStress mode but that is a test issue (they read from invalid memory and don?t even expect to get a valid value back).

This also fixes 64-bit ctypes by properly defining the code in a dynamic method (previously the #ifdef?s were switched so we would define it into a type).  To test 64-bit I had to add our own version of _ctypes_test.cpp because the CRT makes picking up and running w/ CPython?s _ctypes_test.pyd I huge pain.   We now pass all of the tests on 64-bit.  For one of the functions in _ctypes_test I don?t know how to implement it so it just returns the value the test is expecting for the time being.

I?ve also fixed print(None).

23132    1              High       print(None) broken        IronPython\2.6 Beta 2                   
22900    1              High       _ctypes largely broken under x64 OSes IronPython\2.6 dinov_cp             




(Shelveset: CtypesAndGCStressFinal;REDMOND\dinov | SNAP CheckinId: m9704)
--------------------------------------------------------------------------------
Changeset Id: 998550
Date: 7/15/2009 12:50:14 PM

(dfugate) Fixed a couple of PoliCheck violations, and we now run PoliCheck on (IronPython) CodePlex zips for every SNAP checkin.


(Shelveset: IP_POLI01;REDMOND\dfugate | SNAP CheckinId: 8918)
--------------------------------------------------------------------------------
Changeset Id: 1001127
Date: 7/15/2009 5:29:52 PM

(dinov) Updates assembly versions for the 2.6B2 release.  Versions are rev?d to 2.6.0.20 / 0.9.6.20.

This effects IronPython, DLR (including the inner layer w/ updates to files that don?t effect the System.Core build).



(Shelveset: UpdateVersions262_Final;REDMOND\dinov | SNAP CheckinId: m9707)
--------------------------------------------------------------------------------
Changeset Id: 997783
Date: 7/15/2009 11:39:21 AM

(dfugate) checkin_comments.py:
- adjusted get_recent_comments to look for checkin comments in multiple directories within a TFS enlistment
- added 'Hosts\Silverlight' to the list of blessed directories that trigger IronPython Mailing List changeset descriptions

Added a single whitespace to Hosts\Silverlight\README.markdown to test out the change above.


(Shelveset: SL_COMMENTS;REDMOND\dfugate | SNAP CheckinId: 8917)


From ivan at flanders.co.nz  Thu Jul 23 16:21:09 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 23 Jul 2009 16:21:09 +0200
Subject: [IronPython] ASP.NET MVC
Message-ID: <b1c6aabb0907230721u9b8de4dj367f446006546c85@mail.gmail.com>

Hi
I've built the ironruby integration for asp.net mvc.
The way I built it abstracts almost all ruby specific stuff to a facade.
So it would be fairly easy to implement the ironpython support.

Is that something somebody is willing to pick up?
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090723/1f5c8893/attachment.html>

From jdhardy at gmail.com  Thu Jul 23 16:25:56 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 23 Jul 2009 08:25:56 -0600
Subject: [IronPython] ASP.NET MVC
In-Reply-To: <b1c6aabb0907230721u9b8de4dj367f446006546c85@mail.gmail.com>
References: <b1c6aabb0907230721u9b8de4dj367f446006546c85@mail.gmail.com>
Message-ID: <ea89d0e50907230725g6650bc3axfcdeb1a340b642dd@mail.gmail.com>

Hi Ivan,
I'd be willing to look at it. Where is the current code available?

- Jeff

On Thu, Jul 23, 2009 at 8:21 AM, Ivan Porto Carrero<ivan at flanders.co.nz> wrote:
> Hi
> I've built the ironruby integration for asp.net mvc.
> The way I built it abstracts almost all ruby specific stuff to a facade.
> So it would be fairly easy to implement the ironpython support.
> Is that something somebody is willing to pick up?
> ---
> Met vriendelijke groeten - Best regards - Salutations
> Ivan Porto Carrero
> Blog: http://flanders.co.nz
> Twitter: http://twitter.com/casualjim
> Author of IronRuby in Action (http://manning.com/carrero)
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


From ivan at flanders.co.nz  Thu Jul 23 16:33:20 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Thu, 23 Jul 2009 16:33:20 +0200
Subject: [IronPython] ASP.NET MVC
In-Reply-To: <ea89d0e50907230725g6650bc3axfcdeb1a340b642dd@mail.gmail.com>
References: <b1c6aabb0907230721u9b8de4dj367f446006546c85@mail.gmail.com> 
	<ea89d0e50907230725g6650bc3axfcdeb1a340b642dd@mail.gmail.com>
Message-ID: <b1c6aabb0907230733v3bd65e27x4fab2ea2d159d684@mail.gmail.com>

http://github.com/casualjim/ironrubymvc
This email address is also my IM (GTalk) address in case you'd need it.

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
GSM: +32.486.787.582
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)



On Thu, Jul 23, 2009 at 4:25 PM, Jeff Hardy <jdhardy at gmail.com> wrote:

> Hi Ivan,
> I'd be willing to look at it. Where is the current code available?
>
> - Jeff
>
> On Thu, Jul 23, 2009 at 8:21 AM, Ivan Porto Carrero<ivan at flanders.co.nz>
> wrote:
> > Hi
> > I've built the ironruby integration for asp.net mvc.
> > The way I built it abstracts almost all ruby specific stuff to a facade.
> > So it would be fairly easy to implement the ironpython support.
> > Is that something somebody is willing to pick up?
> > ---
> > Met vriendelijke groeten - Best regards - Salutations
> > Ivan Porto Carrero
> > Blog: http://flanders.co.nz
> > Twitter: http://twitter.com/casualjim
> > Author of IronRuby in Action (http://manning.com/carrero)
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090723/140a2872/attachment.html>

From merllab at microsoft.com  Thu Jul 23 17:54:45 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Thu, 23 Jul 2009 08:54:45 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <e1501227-4d85-4b69-bdad-ad707de0a9ec@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57070.

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Lib/__future__.py

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1014297
Date: 7/22/2009 5:58:16 PM

(dfugate) - we were missing __future__.all_feature_names which matters to CPython's code and codeops modules
- set IRONPYTHONPATH to CPython's standard library before calling MSI generation scripts
- we should not be excluding collections.py from CPython's standard library in the MSI


(Shelveset: GOPKG_26B2_02;REDMOND\dfugate | SNAP CheckinId: 8980)





From dfugate at microsoft.com  Thu Jul 23 18:07:52 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Thu, 23 Jul 2009 16:07:52 +0000
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
Message-ID: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>

We're pleased to announce the release of IronPython 2.6 Beta 2 which can be freely downloaded at http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27350.

At this point we are essentially feature complete from a CPython 2.6 perspective, and look forward to making available IronPython 2.6 Release Candidate 1 within the next couple of months.  As such, we'd very much like everyone to try out this release and report back any major problems you may encounter so we can fix them in time for the first release candidate.  Any bugs that you find can be reported via http://ironpython.codeplex.com/WorkItem/Create.aspx.

The primary focus of Beta 2 was bug fixing:  a whopping 215 bugs were fixed in this release.  The majority of these were fixes to standard CPython built-in modules with IronPython runtime fixes coming in at a close second.  Some of the higher profile work items include:

*         The implementation of the sys module was improved so that you can now utilize CPython's pdb module in basic scenarios to debug IronPython sessions provided you pass the -X:Frames or -X:FullFrames options to ipy.exe

*         374 Implement _ctypes module

*         20051 Re-raising exception causes loss of traceback

*         18770 Support type inference on generic methods and improve function conversions - better LINQ support

*         15399 'frame' object has no attribute 'f_back'

*         17465 Implement rest of binascii module (__package__)

*         A bug was fixed in our build scripts that was leaving several working CPython standard modules out of our MSI installations.  These included a few modules under the distutils package, two modules under encodings, code, codeop, and the io modules

A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly.  That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems.  ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes.  Why this change you ask?  Quite simply put IronPython users with 64-bit OSes will see around a 33% improvement to IronPython startup time under ipy.exe!

Silverlight users:  a new version of Silverlight, namely Silverlight 3.0, is required to build the "Silverlight Release" or "Silverlight Debug" configurations of IronPython.sln.  Please update your Silverlight installation accordingly by visiting http://www.microsoft.com/silverlight<http://www.microsoft.com/silverlight/> if you intend to build IronPython from sources.

Thanks to everyone in the IronPython Community who reported bugs and provided valuable feedback.  We really do appreciate your input which helps to make each release of IronPython better than the last.

The IronPython Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090723/497fe7a1/attachment.html>

From dfugate at microsoft.com  Thu Jul 23 18:47:50 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Thu, 23 Jul 2009 16:47:50 +0000
Subject: [IronPython] "code" module in 2.0.1 but missing in 2.6b1
In-Reply-To: <6c63de570907181552lf756b2bn5c33dfd6818d8625@mail.gmail.com>
References: <6c63de570907181552lf756b2bn5c33dfd6818d8625@mail.gmail.com>
Message-ID: <7CEEC335D70FFE4B957737DDE836F51B01EAFE@TK5EX14MBXC123.redmond.corp.microsoft.com>

Thanks Tony! You reported this just in time for it to get fixed in 2.6 Beta 2.

If you're interested, here's a little background on the problem and the fix.  The code module is dependent upon codeop which in turn has a dependency on __future__.all_feature_names.  IronPython's own implementation of __future__.py (found in the binary and source zip files) does not in fact provide the all_feature_names member.  The way we determine which CPython modules/packages to include in the MSI installer is to fire up an IronPython instance and try to import each and every CPython module.  That is, if we can import a CPython module without an exception being thrown, we'll include it in the MSI.  The problem with this approach was that IronPython was picking up our own implementation of __future__.py before attempting to import any given CPython module.  This obviously breaks codeop because all_feature_names is missing from __future__.  The fix was actually quite simple => set the IRONPYTHONPATH environment variable to use CPython's standard library before starting IronPython.  This forces us to pick up CPython's __future__.py instead of our own.

Dave
http://knowbody.livejournal.com


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Meyer
Sent: Saturday, July 18, 2009 3:52 PM
To: users at lists.ironpython.com
Subject: [IronPython] "code" module in 2.0.1 but missing in 2.6b1

Hi,

The code module (used for providing an interactive interpreter) isn't
included in IronPython 2.6b1 (it is in 2.0.1).  Copying the code (and
codeop) module from 2.0.1 to 2.6b1 seems to work fine, however.

Is this a deliberate change?  One that will be addressed by 2.6 final?

(I did try searching the web and the issue tracker, but I may have
missed something - searching for "import code" doesn't work amazingly
well).

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



From daftspaniel at gmail.com  Thu Jul 23 20:29:09 2009
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Thu, 23 Jul 2009 19:29:09 +0100
Subject: [IronPython] IP B2 Issue
Message-ID: <20253b0c0907231129l7d18c549la4d187e05594fe87@mail.gmail.com>

Hi Guys,

Don't have much time to look into this right now but thought I would
share it right away as it seems low level :-)
Changes to CallTarget0?

I was just running DIE on PY and it was capturing output from a script
in the usual manner when...


Unhandled Exception: Unhandled Exception: Microsoft.Scripting.ArgumentTypeExcept
ion: unsupported operand type(s) for +: 'NoneType' and 'str'
   at CallSite.Target(Closure , CallSite , Object , String )
   at Microsoft.Scripting.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite
 site, T0 arg0, T1 arg1)
   at IronPython.Runtime.Binding.PythonBinaryOperationBinder.StringAdd(CallSite
site, Object self, String other)
   at ProcessOutputHandler$300(Closure , PythonFunction , Object , Object , Obje
ct )
   at IronPython.Runtime.PythonFunction.FunctionCaller`3.Call3(CallSite site, Co
deContext context, Object func, T0 arg0, T1 arg1, T2 arg2)
   at CallSite.Target(Closure , CallSite , Object , Object , DataReceivedEventAr
gs )
   at _Scripting_(Object[] , Object , DataReceivedEventArgs )
   at System.Diagnostics.Process.OutputReadNotifyUser(String data)
   at System.Diagnostics.AsyncStreamReader.FlushMessageQueue()
   at System.Diagnostics.AsyncStreamReader.ReadBuffer(IAsyncResult ar)
   at System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessage
msg)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMe
ssage msg, IMessageSink replySink)
   at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.DoAsyncCall()
   at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Ob
ject o)
   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state
)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, C
ontextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_Thre
adPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

--
  Davy Stuff  - http://daftspaniel.blogspot.com
  Geeky Stuff  - http://daftpython.blogspot.com
  Davy's Ironpython Editor - http://code.google.com/p/davysironpythoneditor/


From dinov at microsoft.com  Thu Jul 23 20:33:35 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 23 Jul 2009 18:33:35 +0000
Subject: [IronPython] IP B2 Issue
In-Reply-To: <20253b0c0907231129l7d18c549la4d187e05594fe87@mail.gmail.com>
References: <20253b0c0907231129l7d18c549la4d187e05594fe87@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03548CE1@TK5EX14MBXC116.redmond.corp.microsoft.com>

This looks like it's due to a bug fix and is correct behavior - we used to
allow None + "abc" but we've fixed the issue and it now throws an exception
as expected.

Note CallTarget0 is no longer used by IronPython at all.  We keep it around
though for backwards compatibility because people seem to like it :)

But I would generally recommend using Func<object> instead.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
> Sent: Thursday, July 23, 2009 11:29 AM
> To: Discussion of IronPython
> Subject: [IronPython] IP B2 Issue
>
> Hi Guys,
>
> Don't have much time to look into this right now but thought I would
> share it right away as it seems low level :-)
> Changes to CallTarget0?
>
> I was just running DIE on PY and it was capturing output from a script
> in the usual manner when...
>
>
> Unhandled Exception: Unhandled Exception:
> Microsoft.Scripting.ArgumentTypeExcept
> ion: unsupported operand type(s) for +: 'NoneType' and 'str'
>    at CallSite.Target(Closure , CallSite , Object , String )
>    at
> Microsoft.Scripting.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallS
> ite
>  site, T0 arg0, T1 arg1)
>    at
> IronPython.Runtime.Binding.PythonBinaryOperationBinder.StringAdd(CallSi
> te
> site, Object self, String other)
>    at ProcessOutputHandler$300(Closure , PythonFunction , Object ,
> Object , Obje
> ct )
>    at IronPython.Runtime.PythonFunction.FunctionCaller`3.Call3(CallSite
> site, Co
> deContext context, Object func, T0 arg0, T1 arg1, T2 arg2)
>    at CallSite.Target(Closure , CallSite , Object , Object ,
> DataReceivedEventAr
> gs )
>    at _Scripting_(Object[] , Object , DataReceivedEventArgs )
>    at System.Diagnostics.Process.OutputReadNotifyUser(String data)
>    at System.Diagnostics.AsyncStreamReader.FlushMessageQueue()
>    at System.Diagnostics.AsyncStreamReader.ReadBuffer(IAsyncResult ar)
>    at
> System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessa
> ge
> msg)
>    at
> System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(
> IMe
> ssage msg, IMessageSink replySink)
>    at
> System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.DoAsyncCall()
>    at
> System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack
> (Ob
> ject o)
>    at
> System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object
> state
> )
>    at System.Threading.ExecutionContext.Run(ExecutionContext
> executionContext, C
> ontextCallback callback, Object state)
>    at
> System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_T
> hre
> adPoolWaitCallback tpWaitCallBack)
>    at
> System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object
> state)
>
> --
>   Davy Stuff  - http://daftspaniel.blogspot.com
>   Geeky Stuff  - http://daftpython.blogspot.com
>   Davy's Ironpython Editor -
> http://code.google.com/p/davysironpythoneditor/
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From daftspaniel at gmail.com  Thu Jul 23 21:19:45 2009
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Thu, 23 Jul 2009 20:19:45 +0100
Subject: [IronPython] IP B2 Issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03548CE1@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <20253b0c0907231129l7d18c549la4d187e05594fe87@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD03548CE1@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <20253b0c0907231219p1e4d0977ic07dd9484f6bd2fc@mail.gmail.com>

Thanks Dino - will look into it.

On Thu, Jul 23, 2009 at 7:33 PM, Dino Viehland<dinov at microsoft.com> wrote:
> This looks like it's due to a bug fix and is correct behavior - we used to
> allow None + "abc" but we've fixed the issue and it now throws an exception
> as expected.
>
> Note CallTarget0 is no longer used by IronPython at all. ?We keep it around
> though for backwards compatibility because people seem to like it :)
>
> But I would generally recommend using Func<object> instead.
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Davy Mitchell
>> Sent: Thursday, July 23, 2009 11:29 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] IP B2 Issue
>>
>> Hi Guys,
>>
>> Don't have much time to look into this right now but thought I would
>> share it right away as it seems low level :-)
>> Changes to CallTarget0?
>>
>> I was just running DIE on PY and it was capturing output from a script
>> in the usual manner when...
>>
>>
>> Unhandled Exception: Unhandled Exception:
>> Microsoft.Scripting.ArgumentTypeExcept
>> ion: unsupported operand type(s) for +: 'NoneType' and 'str'
>> ? ?at CallSite.Target(Closure , CallSite , Object , String )
>> ? ?at
>> Microsoft.Scripting.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallS
>> ite
>> ?site, T0 arg0, T1 arg1)
>> ? ?at
>> IronPython.Runtime.Binding.PythonBinaryOperationBinder.StringAdd(CallSi
>> te
>> site, Object self, String other)
>> ? ?at ProcessOutputHandler$300(Closure , PythonFunction , Object ,
>> Object , Obje
>> ct )
>> ? ?at IronPython.Runtime.PythonFunction.FunctionCaller`3.Call3(CallSite
>> site, Co
>> deContext context, Object func, T0 arg0, T1 arg1, T2 arg2)
>> ? ?at CallSite.Target(Closure , CallSite , Object , Object ,
>> DataReceivedEventAr
>> gs )
>> ? ?at _Scripting_(Object[] , Object , DataReceivedEventArgs )
>> ? ?at System.Diagnostics.Process.OutputReadNotifyUser(String data)
>> ? ?at System.Diagnostics.AsyncStreamReader.FlushMessageQueue()
>> ? ?at System.Diagnostics.AsyncStreamReader.ReadBuffer(IAsyncResult ar)
>> ? ?at
>> System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessa
>> ge
>> msg)
>> ? ?at
>> System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(
>> IMe
>> ssage msg, IMessageSink replySink)
>> ? ?at
>> System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.DoAsyncCall()
>> ? ?at
>> System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack
>> (Ob
>> ject o)
>> ? ?at
>> System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object
>> state
>> )
>> ? ?at System.Threading.ExecutionContext.Run(ExecutionContext
>> executionContext, C
>> ontextCallback callback, Object state)
>> ? ?at
>> System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_T
>> hre
>> adPoolWaitCallback tpWaitCallBack)
>> ? ?at
>> System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object
>> state)
>>
>> --
>> ? Davy Stuff ?- http://daftspaniel.blogspot.com
>> ? Geeky Stuff ?- http://daftpython.blogspot.com
>> ? Davy's Ironpython Editor -
>> http://code.google.com/p/davysironpythoneditor/
>> _______________________________________________
>> 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
>



-- 
--
  Davy Stuff  - http://daftspaniel.blogspot.com
  Geeky Stuff  - http://daftpython.blogspot.com
  Davy's Ironpython Editor - http://code.google.com/p/davysironpythoneditor/


From cenovsky at bakalari.cz  Fri Jul 24 00:34:31 2009
From: cenovsky at bakalari.cz (Lukas Cenovsky)
Date: Fri, 24 Jul 2009 00:34:31 +0200
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
Message-ID: <4A68E577.5060705@bakalari.cz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090724/4a8f2842/attachment.html>

From dinov at microsoft.com  Fri Jul 24 00:43:19 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 23 Jul 2009 22:43:19 +0000
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <4A68E577.5060705@bakalari.cz>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<4A68E577.5060705@bakalari.cz>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0354A2EF@TK5EX14MBXC116.redmond.corp.microsoft.com>

The core feature (__clrtype__ on type which can be used w/ meta-classes) which enables them is present - but at this point it's all about making hard things possible, not making them easy.  The interesting parts still need to be built still - but they're all Python code.  Harry has some samples and explanation on his blog already:

http://devhawk.net/2009/06/18/clrtype+Metaclasses+Named+Attribute+Parameters.aspx
http://devhawk.net/2009/06/17/clrtype+Metaclasses+Positional+Attribute+Parameters.aspx
http://devhawk.net/2009/06/15/clrtype+Metaclasses+Simple+Custom+Attributes.aspx

And we'll probably create some more before 2.6 ships as well.  Over time we'll iterate on those and we hope other people experiment w/ building a friendly API on the low-level feature as well.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Thursday, July 23, 2009 3:35 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [ANN]: IronPython 2.6 Beta 2

Hi,
I don't see any iformation about .NET attributes in the release notes. Has been decided the way how will their usage look like in IronPython 2.6?

Anyway, thanks for the new beta!

--
-- Lukas


Dave Fugate wrote:
We're pleased to announce the release of IronPython 2.6 Beta 2 which can be freely downloaded at http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27350.

At this point we are essentially feature complete from a CPython 2.6 perspective, and look forward to making available IronPython 2.6 Release Candidate 1 within the next couple of months.  As such, we'd very much like everyone to try out this release and report back any major problems you may encounter so we can fix them in time for the first release candidate.  Any bugs that you find can be reported via http://ironpython.codeplex.com/WorkItem/Create.aspx.

The primary focus of Beta 2 was bug fixing:  a whopping 215 bugs were fixed in this release.  The majority of these were fixes to standard CPython built-in modules with IronPython runtime fixes coming in at a close second.  Some of the higher profile work items include:

The implementation of the sys module was improved so that you can now utilize CPython's pdb module in basic scenarios to debug IronPython sessions provided you pass the -X:Frames or -X:FullFrames options to ipy.exe

374 Implement _ctypes module

20051 Re-raising exception causes loss of traceback

18770 Support type inference on generic methods and improve function conversions - better LINQ support

15399 'frame' object has no attribute 'f_back'

17465 Implement rest of binascii module (__package__)

A bug was fixed in our build scripts that was leaving several working CPython standard modules out of our MSI installations.  These included a few modules under the distutils package, two modules under encodings, code, codeop, and the io modules

A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly.  That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems.  ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes.  Why this change you ask?  Quite simply put IronPython users with 64-bit OSes will see around a 33% improvement to IronPython startup time under ipy.exe!

Silverlight users:  a new version of Silverlight, namely Silverlight 3.0, is required to build the "Silverlight Release" or "Silverlight Debug" configurations of IronPython.sln.  Please update your Silverlight installation accordingly by visiting http://www.microsoft.com/silverlight<http://www.microsoft.com/silverlight/> if you intend to build IronPython from sources.

Thanks to everyone in the IronPython Community who reported bugs and provided valuable feedback.  We really do appreciate your input which helps to make each release of IronPython better than the last.

The IronPython Team






________________________________






_______________________________________________

Users mailing list

Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>

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



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

From tony.meyer at gmail.com  Fri Jul 24 01:25:42 2009
From: tony.meyer at gmail.com (Tony Meyer)
Date: Fri, 24 Jul 2009 11:25:42 +1200
Subject: [IronPython] "code" module in 2.0.1 but missing in 2.6b1
In-Reply-To: <7CEEC335D70FFE4B957737DDE836F51B01EAFE@TK5EX14MBXC123.redmond.corp.microsoft.com>
References: <6c63de570907181552lf756b2bn5c33dfd6818d8625@mail.gmail.com>
	<7CEEC335D70FFE4B957737DDE836F51B01EAFE@TK5EX14MBXC123.redmond.corp.microsoft.com>
Message-ID: <6c63de570907231625j14d26ebfq2556e4552378aa59@mail.gmail.com>

> Thanks Tony! You reported this just in time for it to get fixed in 2.6 Beta 2.

That's great!  I'll even forgive you for releasing 2.6b2 the day after
my students all installed 2.6b1 ;)

Thanks,
Tony


From jdhardy at gmail.com  Fri Jul 24 02:26:31 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 23 Jul 2009 18:26:31 -0600
Subject: [IronPython] ASP.NET MVC
In-Reply-To: <b1c6aabb0907230733v3bd65e27x4fab2ea2d159d684@mail.gmail.com>
References: <b1c6aabb0907230721u9b8de4dj367f446006546c85@mail.gmail.com>
	<ea89d0e50907230725g6650bc3axfcdeb1a340b642dd@mail.gmail.com>
	<b1c6aabb0907230733v3bd65e27x4fab2ea2d159d684@mail.gmail.com>
Message-ID: <ea89d0e50907231726l33a4d7afq1beb8d8738cdc4fa@mail.gmail.com>

My fork is at http://github.com/jdhardy/ironrubymvc. Haven't had a
chance to do anything else yet, though :)

- Jeff

On Thu, Jul 23, 2009 at 8:33 AM, Ivan Porto Carrero<ivan at flanders.co.nz> wrote:
> http://github.com/casualjim/ironrubymvc
> This email address is also my IM (GTalk) address in case you'd need it.
> ---
> Met vriendelijke groeten - Best regards - Salutations
> Ivan Porto Carrero
> GSM: +32.486.787.582
> Blog: http://flanders.co.nz
> Twitter: http://twitter.com/casualjim
> Author of IronRuby in Action (http://manning.com/carrero)
>
>
>
> On Thu, Jul 23, 2009 at 4:25 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
>>
>> Hi Ivan,
>> I'd be willing to look at it. Where is the current code available?
>>
>> - Jeff
>>
>> On Thu, Jul 23, 2009 at 8:21 AM, Ivan Porto Carrero<ivan at flanders.co.nz>
>> wrote:
>> > Hi
>> > I've built the ironruby integration for asp.net mvc.
>> > The way I built it abstracts almost all ruby specific stuff to a facade.
>> > So it would be fairly easy to implement the ironpython support.
>> > Is that something somebody is willing to pick up?
>> > ---
>> > Met vriendelijke groeten - Best regards - Salutations
>> > Ivan Porto Carrero
>> > Blog: http://flanders.co.nz
>> > Twitter: http://twitter.com/casualjim
>> > Author of IronRuby in Action (http://manning.com/carrero)
>> >
>> >
>> > _______________________________________________
>> > 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 vernondcole at gmail.com  Fri Jul 24 07:11:22 2009
From: vernondcole at gmail.com (Vernon Cole)
Date: Thu, 23 Jul 2009 23:11:22 -0600
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <4A68E577.5060705@bakalari.cz>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<4A68E577.5060705@bakalari.cz>
Message-ID: <b7eb4a700907232211n372f2cbcnbec0c81c3999ddf2@mail.gmail.com>

Guys:
  Good work on the new release, and the 215 bug fixes. As usual, as soon as
the new beta was announced I downloaded and tested it.

Somehow I got the idea that the adodbapi test had been included in the
IronPython test suite. Did you only include the tests that already pass?
Issue 18222 is still unfixed -- so adodbapi still fails, and you still
cannot pass a read-only buffer as a COM parameter.

I realize that no one has voted up this rather obscure bug. Perhaps if it
were titled "fully support DB API 2.0 compliant database access using ADO"
it would have gotten more votes. Nevertheless, this issue has been
outstanding for 11 months, and is the only remaining failure in adodbapi for
versions 2.3 thru 3.1 of python. Please try to get to it before 2.6 final.

Please !!!???
--
Vernon Cole

P.S. -- I plan to make a version of adodbapi which uses real ADO.NET, rather
than ADO via COM, but I want the current version to be solid before I start
mucking it up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090723/273c95ca/attachment.html>

From calmasy at gmail.com  Fri Jul 24 09:04:18 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Fri, 24 Jul 2009 01:04:18 -0600
Subject: [IronPython] how to use Predicates in IPy?
Message-ID: <abb783b90907240004l664a166ev9e9104aceb327a48@mail.gmail.com>

I've been unable to find any examples of how to define/use Predicates
in IPy, as for use with .NET's List(T).FindAll method. Specifically
I'm trying to use
http://lib.openmetaverse.org/docs/trunk/html/M_OpenMetaverse_InternalDictionary_2_FindAll_1.htm

Anyway, if someone could help with an example of how to do such things
in IPy I'd greatly appreciate. The one mention of it in this list's
archives is from 2006 and refers to an example url that is now broken.

-- 
Cheers, L?szl?


From merllab at microsoft.com  Fri Jul 24 17:53:13 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Fri, 24 Jul 2009 08:53:13 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <9a21e98e-76aa-4961-8158-5c9ff026fe65@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57140.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/UnboundNameException.cs

DELETED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/UnboundNameException.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Modules/imp.cs
	$/IronPython/IronPython_Main/Src/IronPython/Modules/Builtin.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/DictionaryGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonGlobalVariableExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonGlobal.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/re.cs
	$/IronPython/IronPython_Main/Src/IronPython/Hosting/PythonCommandLine.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/UnboundNameException.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/CodeContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/FutureBuiltins.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/ModuleLoader.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/ClrModule.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/ScopeOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/GlobalScopeDictionaryStorage.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/ScopeDictionaryStorage.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonModule.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/TraceBack.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/OldClass.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/InstanceOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Importer.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/ScriptScope.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/LanguageContext.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.txt
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/ScriptingRuntimeHelpers.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/AssemblyTypeNames.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/Scope.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/ScriptEngine.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/ExceptionFactory.Generated.cs
	$/IronPython/IronPython_Main/Src/Scripts/run_interactive.py
	$/IronPython/IronPython_Main/Src/Scripts/generate_exceptions.py
	$/IronPython/IronPython_Main/Src/Tests/test_help.py
	$/IronPython/IronPython_Main/Src/Tests/test_superconsole.py





From dinov at microsoft.com  Fri Jul 24 18:15:12 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 24 Jul 2009 16:15:12 +0000
Subject: [IronPython] how to use Predicates in IPy?
In-Reply-To: <abb783b90907240004l664a166ev9e9104aceb327a48@mail.gmail.com>
References: <abb783b90907240004l664a166ev9e9104aceb327a48@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035616DA@TK5EX14MBXC116.redmond.corp.microsoft.com>

You can just do:

x.FindAll(lambda inst:True)

or:

def MyPredicate(obj):
        return True

x.FindAll(MyPredicate)

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
> Sent: Friday, July 24, 2009 12:04 AM
> To: Discussion of IronPython
> Subject: [IronPython] how to use Predicates in IPy?
>
> I've been unable to find any examples of how to define/use Predicates
> in IPy, as for use with .NET's List(T).FindAll method. Specifically
> I'm trying to use
> http://lib.openmetaverse.org/docs/trunk/html/M_OpenMetaverse_InternalDi
> ctionary_2_FindAll_1.htm
>
> Anyway, if someone could help with an example of how to do such things
> in IPy I'd greatly appreciate. The one mention of it in this list's
> archives is from 2006 and refers to an example url that is now broken.
>
> --
> Cheers, L?szl?
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From calmasy at gmail.com  Fri Jul 24 22:19:04 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Fri, 24 Jul 2009 14:19:04 -0600
Subject: [IronPython] how to use Predicates in IPy?
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD035616DA@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <abb783b90907240004l664a166ev9e9104aceb327a48@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD035616DA@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <abb783b90907241319n235b8a9fv82ebb546664436cb@mail.gmail.com>

both attempts give a TypError:

>>> sim.ObjectsPrimitives.FindAll(lambda inst:True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Multiple targets could match: FindAll(Predicate[UInt32]),
FindAll(Predicate[Primitive])

On Fri, Jul 24, 2009 at 10:15 AM, Dino Viehland<dinov at microsoft.com> wrote:
> You can just do:
>
> x.FindAll(lambda inst:True)
>
> or:
>
> def MyPredicate(obj):
> ? ? ? ?return True
>
> x.FindAll(MyPredicate)
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
>> Sent: Friday, July 24, 2009 12:04 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] how to use Predicates in IPy?
>>
>> I've been unable to find any examples of how to define/use Predicates
>> in IPy, as for use with .NET's List(T).FindAll method. Specifically
>> I'm trying to use
>> http://lib.openmetaverse.org/docs/trunk/html/M_OpenMetaverse_InternalDi
>> ctionary_2_FindAll_1.htm
>>
>> Anyway, if someone could help with an example of how to do such things
>> in IPy I'd greatly appreciate. The one mention of it in this list's
>> archives is from 2006 and refers to an example url that is now broken.
>>
>> --
>> Cheers, L?szl?
>> _______________________________________________
>> 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
>



-- 
Cheers, L?szl?


From dinov at microsoft.com  Fri Jul 24 22:24:14 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 24 Jul 2009 20:24:14 +0000
Subject: [IronPython] how to use Predicates in IPy?
In-Reply-To: <abb783b90907241319n235b8a9fv82ebb546664436cb@mail.gmail.com>
References: <abb783b90907240004l664a166ev9e9104aceb327a48@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD035616DA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<abb783b90907241319n235b8a9fv82ebb546664436cb@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03562E67@TK5EX14MBXC116.redmond.corp.microsoft.com>

Is this actually a List<T> or something that just happens
to have a similar FindAll method?  It looks like List<T> only
has a single overload so it works there.

In this case you can do:

Predicate[UInt32](lambda x: True)
Or
Predicate[Primitive](lambda x: True)

To construct the delegate explicitly depending on which overload you want.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
> Sent: Friday, July 24, 2009 1:19 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] how to use Predicates in IPy?
>
> both attempts give a TypError:
>
> >>> sim.ObjectsPrimitives.FindAll(lambda inst:True)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: Multiple targets could match: FindAll(Predicate[UInt32]),
> FindAll(Predicate[Primitive])
>
> On Fri, Jul 24, 2009 at 10:15 AM, Dino Viehland<dinov at microsoft.com>
> wrote:
> > You can just do:
> >
> > x.FindAll(lambda inst:True)
> >
> > or:
> >
> > def MyPredicate(obj):
> >        return True
> >
> > x.FindAll(MyPredicate)
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
> >> Sent: Friday, July 24, 2009 12:04 AM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] how to use Predicates in IPy?
> >>
> >> I've been unable to find any examples of how to define/use
> Predicates
> >> in IPy, as for use with .NET's List(T).FindAll method. Specifically
> >> I'm trying to use
> >>
> http://lib.openmetaverse.org/docs/trunk/html/M_OpenMetaverse_InternalDi
> >> ctionary_2_FindAll_1.htm
> >>
> >> Anyway, if someone could help with an example of how to do such
> things
> >> in IPy I'd greatly appreciate. The one mention of it in this list's
> >> archives is from 2006 and refers to an example url that is now
> broken.
> >>
> >> --
> >> Cheers, L?szl?
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Cheers, L?szl?
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Fri Jul 24 22:28:30 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 24 Jul 2009 20:28:30 +0000
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <b7eb4a700907232211n372f2cbcnbec0c81c3999ddf2@mail.gmail.com>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<4A68E577.5060705@bakalari.cz>
	<b7eb4a700907232211n372f2cbcnbec0c81c3999ddf2@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03562E84@TK5EX14MBXC116.redmond.corp.microsoft.com>

I'll take a look and see what we can do.  I think we've largely been ignoring it because we don't directly own our own COM support (it comes from the DLR) but maybe there's something we can do here.

On the tests we do generally include only passing tests.  Sometimes we will add failing tests to the suite and test for the broken behavior so we know when a bug repros.  But in this case we don't have a good stand alone repro so that hasn't happened (and even if it did, it doesn't actually encourage us to fix the test, it just becomes one more test that silently 'passes').

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Thursday, July 23, 2009 10:11 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [ANN]: IronPython 2.6 Beta 2

Guys:
  Good work on the new release, and the 215 bug fixes. As usual, as soon as the new beta was announced I downloaded and tested it.

Somehow I got the idea that the adodbapi test had been included in the IronPython test suite. Did you only include the tests that already pass?  Issue 18222 is still unfixed -- so adodbapi still fails, and you still cannot pass a read-only buffer as a COM parameter.

I realize that no one has voted up this rather obscure bug. Perhaps if it were titled "fully support DB API 2.0 compliant database access using ADO" it would have gotten more votes. Nevertheless, this issue has been outstanding for 11 months, and is the only remaining failure in adodbapi for versions 2.3 thru 3.1 of python. Please try to get to it before 2.6 final.

Please !!!???
--
Vernon Cole

P.S. -- I plan to make a version of adodbapi which uses real ADO.NET<http://ADO.NET>, rather than ADO via COM, but I want the current version to be solid before I start mucking it up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090724/8d3130dd/attachment.html>

From jeffrey at extremeoptimization.com  Fri Jul 24 22:43:41 2009
From: jeffrey at extremeoptimization.com (Jeffrey Sax)
Date: Fri, 24 Jul 2009 16:43:41 -0400
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <4A65EAA8.4000909@resolversystems.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>
Message-ID: <007401ca0c9f$6e4c54b0$4ae4fe10$@com>

According to the archives, some version of sympy worked on IP 1.x at some
point in the distant past. Now, with the latest version of both (sympy 0.6.5
on IronPython 2.6.B2), I get this:

PS C:\Program Files (x86)\IronPython 2.6> .\ipy.exe
IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4918
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append(r"c:\Program Files (x86)\Python26\Lib\site-packages")
>>> from sympy import Symbol, cos
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in c:\Program
Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\__init__.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2442, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\symbol.py", line 285, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\symbol.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\sympify.py", line 200, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\sympify.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\numbers.py", line 1600, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\numbers.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\function.py", line 39, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\function.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py", line 14, in
c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\utilities\source.py", line 5, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\utilities\source.py
  File "C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py", line 950, in
C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py
AttributeError: 'module' object has no attribute '_getframe'
>>> 

Note also that when I retry the import, I get a different error message:

>>> from sympy import Symbol, cos
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in c:\Program
Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\__init__.py
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 3, in c:\Program
Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
AttributeError: 'module' object has no attribute 'mpmath'

Any idea what's going on here?

Thanks,

Jeffrey



From fuzzyman at voidspace.org.uk  Fri Jul 24 22:47:19 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 24 Jul 2009 21:47:19 +0100
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <007401ca0c9f$6e4c54b0$4ae4fe10$@com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>
	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>
Message-ID: <4A6A1DD7.50602@voidspace.org.uk>

Try running it with frames switched on:

    ipy.exe -X:Frames

or:

    ipy.exe -X:FullFrames

Perhaps Dino can explain what the difference is between these two 
modes... :-)

Michael

Jeffrey Sax wrote:
> According to the archives, some version of sympy worked on IP 1.x at some
> point in the distant past. Now, with the latest version of both (sympy 0.6.5
> on IronPython 2.6.B2), I get this:
>
> PS C:\Program Files (x86)\IronPython 2.6> .\ipy.exe
> IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4918
> Type "help", "copyright", "credits" or "license" for more information.
>   
>>>> import sys
>>>> sys.path.append(r"c:\Program Files (x86)\Python26\Lib\site-packages")
>>>> from sympy import Symbol, cos
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in c:\Program
> Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\__init__.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2442, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\symbol.py", line 285, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\symbol.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\sympify.py", line 200, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\sympify.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\numbers.py", line 1600, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\numbers.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\function.py", line 39, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\function.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py", line 14, in
> c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\utilities\source.py", line 5, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\utilities\source.py
>   File "C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py", line 950, in
> C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py
> AttributeError: 'module' object has no attribute '_getframe'
>   
>
> Note also that when I retry the import, I get a different error message:
>
>   
>>>> from sympy import Symbol, cos
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in c:\Program
> Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\__init__.py
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 3, in c:\Program
> Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
> AttributeError: 'module' object has no attribute 'mpmath'
>
> Any idea what's going on here?
>
> Thanks,
>
> Jeffrey
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From kf9150 at gmail.com  Fri Jul 24 22:48:51 2009
From: kf9150 at gmail.com (Kelie)
Date: Fri, 24 Jul 2009 13:48:51 -0700 (PDT)
Subject: [IronPython] Problem with Creating Executable using SharpDevelop
In-Reply-To: <7927de91-9d1e-4a2c-887c-1eb01cbdef66@j9g2000prh.googlegroups.com>
References: <71f63e92-aadd-4a1e-8c75-a9d19338c007@x5g2000prf.googlegroups.com>
	<58ad4a110907171307o5db93cdcnea0ff80ba83154ff@mail.gmail.com> 
	<7927de91-9d1e-4a2c-887c-1eb01cbdef66@j9g2000prh.googlegroups.com>
Message-ID: <034edffa-5cd0-4d23-b9c6-cf419fc4e91f@d15g2000prc.googlegroups.com>

> On Jul 17, 10:07?am, Bruce Bromberek <bruce.brombe... at gmail.com>
> > Make sure the Target machine has been upgraded to .Net 3.5 SP1. ?Don't take
> > any flack - make them upgrade.*

This fixed the problem. Works on both XP and Vista. Thanks again Bruce!


From dinov at microsoft.com  Fri Jul 24 22:49:38 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 24 Jul 2009 20:49:38 +0000
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <4A6A1DD7.50602@voidspace.org.uk>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>
	<4A6A1DD7.50602@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>

-X:FullFrames promotes all local variables into the heap.  So you can
always crawl the stack and look/change them for all methods.

-X:Frames only creates the frame objects and if something happens to
make us promote local variables (e.g. a closure, or a call to locals(),
exec, eval, dir(), vars()) then the local variables will be available
for that specific method.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, July 24, 2009 1:47 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] sympy on IP 2.6B2
>
> Try running it with frames switched on:
>
>     ipy.exe -X:Frames
>
> or:
>
>     ipy.exe -X:FullFrames
>
> Perhaps Dino can explain what the difference is between these two
> modes... :-)
>
> Michael
>
> Jeffrey Sax wrote:
> > According to the archives, some version of sympy worked on IP 1.x at
> some
> > point in the distant past. Now, with the latest version of both
> (sympy 0.6.5
> > on IronPython 2.6.B2), I get this:
> >
> > PS C:\Program Files (x86)\IronPython 2.6> .\ipy.exe
> > IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4918
> > Type "help", "copyright", "credits" or "license" for more
> information.
> >
> >>>> import sys
> >>>> sys.path.append(r"c:\Program Files (x86)\Python26\Lib\site-
> packages")
> >>>> from sympy import Symbol, cos
> >>>>
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in
> c:\Program
> > Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\core\__init__.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2442, in
> > c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\symbol.py", line 285, in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\core\symbol.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\sympify.py", line 200, in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\core\sympify.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\numbers.py", line 1600,
> in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\core\numbers.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\function.py", line 39, in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\core\function.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py", line
> 14, in
> > c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\utilities\source.py", line 5,
> in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\utilities\source.py
> >   File "C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py", line
> 950, in
> > C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py
> > AttributeError: 'module' object has no attribute '_getframe'
> >
> >
> > Note also that when I retry the import, I get a different error
> message:
> >
> >
> >>>> from sympy import Symbol, cos
> >>>>
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in
> c:\Program
> > Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
> > c:\Program Files (x86)\Python26\Lib\site-
> packages\sympy\core\__init__.py
> >   File "c:\Program Files
> > (x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 3, in
> c:\Program
> > Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
> > AttributeError: 'module' object has no attribute 'mpmath'
> >
> > Any idea what's going on here?
> >
> > Thanks,
> >
> > Jeffrey
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From fuzzyman at voidspace.org.uk  Fri Jul 24 22:53:25 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 24 Jul 2009 21:53:25 +0100
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A6A1F45.7080303@voidspace.org.uk>

Dino Viehland wrote:
> -X:FullFrames promotes all local variables into the heap.  So you can
> always crawl the stack and look/change them for all methods.
>
> -X:Frames only creates the frame objects and if something happens to
> make us promote local variables (e.g. a closure, or a call to locals(),
> exec, eval, dir(), vars()) then the local variables will be available
> for that specific method.
>
>   

Thanks Dino. :-)

Michael

>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, July 24, 2009 1:47 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] sympy on IP 2.6B2
>>
>> Try running it with frames switched on:
>>
>>     ipy.exe -X:Frames
>>
>> or:
>>
>>     ipy.exe -X:FullFrames
>>
>> Perhaps Dino can explain what the difference is between these two
>> modes... :-)
>>
>> Michael
>>
>> Jeffrey Sax wrote:
>>     
>>> According to the archives, some version of sympy worked on IP 1.x at
>>>       
>> some
>>     
>>> point in the distant past. Now, with the latest version of both
>>>       
>> (sympy 0.6.5
>>     
>>> on IronPython 2.6.B2), I get this:
>>>
>>> PS C:\Program Files (x86)\IronPython 2.6> .\ipy.exe
>>> IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4918
>>> Type "help", "copyright", "credits" or "license" for more
>>>       
>> information.
>>     
>>>>>> import sys
>>>>>> sys.path.append(r"c:\Program Files (x86)\Python26\Lib\site-
>>>>>>             
>> packages")
>>     
>>>>>> from sympy import Symbol, cos
>>>>>>
>>>>>>             
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in
>>>       
>> c:\Program
>>     
>>> Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\core\__init__.py
>>     
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2442, in
>>> c:\Program Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\symbol.py", line 285, in
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\core\symbol.py
>>     
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\sympify.py", line 200, in
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\core\sympify.py
>>     
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\numbers.py", line 1600,
>>>       
>> in
>>     
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\core\numbers.py
>>     
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\function.py", line 39, in
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\core\function.py
>>     
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py", line
>>>       
>> 14, in
>>     
>>> c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\utilities\__init__.py
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\utilities\source.py", line 5,
>>>       
>> in
>>     
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\utilities\source.py
>>     
>>>   File "C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py", line
>>>       
>> 950, in
>>     
>>> C:\Program Files (x86)\IronPython 2.6\Lib\inspect.py
>>> AttributeError: 'module' object has no attribute '_getframe'
>>>
>>>
>>> Note also that when I retry the import, I get a different error
>>>       
>> message:
>>     
>>>       
>>>>>> from sympy import Symbol, cos
>>>>>>
>>>>>>             
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 23, in
>>>       
>> c:\Program
>>     
>>> Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\__init__.py", line 4, in
>>> c:\Program Files (x86)\Python26\Lib\site-
>>>       
>> packages\sympy\core\__init__.py
>>     
>>>   File "c:\Program Files
>>> (x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 3, in
>>>       
>> c:\Program
>>     
>>> Files (x86)\Python26\Lib\site-packages\sympy\core\basic.py
>>> AttributeError: 'module' object has no attribute 'mpmath'
>>>
>>> Any idea what's going on here?
>>>
>>> Thanks,
>>>
>>> Jeffrey
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>       
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From calmasy at gmail.com  Sat Jul 25 01:11:46 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Fri, 24 Jul 2009 17:11:46 -0600
Subject: [IronPython] how to use Predicates in IPy?
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03562E67@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <abb783b90907240004l664a166ev9e9104aceb327a48@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD035616DA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<abb783b90907241319n235b8a9fv82ebb546664436cb@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD03562E67@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <abb783b90907241611o3bdc79b6u67faaa43c839b93a@mail.gmail.com>

Thanks Dino, i got it working. Good thread for the archive too.

On Fri, Jul 24, 2009 at 2:24 PM, Dino Viehland<dinov at microsoft.com> wrote:
> Is this actually a List<T> or something that just happens
> to have a similar FindAll method? ?It looks like List<T> only
> has a single overload so it works there.
>
> In this case you can do:
>
> Predicate[UInt32](lambda x: True)
> Or
> Predicate[Primitive](lambda x: True)
>
> To construct the delegate explicitly depending on which overload you want.
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
>> Sent: Friday, July 24, 2009 1:19 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] how to use Predicates in IPy?
>>
>> both attempts give a TypError:
>>
>> >>> sim.ObjectsPrimitives.FindAll(lambda inst:True)
>> Traceback (most recent call last):
>> ? File "<stdin>", line 1, in <module>
>> TypeError: Multiple targets could match: FindAll(Predicate[UInt32]),
>> FindAll(Predicate[Primitive])
>>
>> On Fri, Jul 24, 2009 at 10:15 AM, Dino Viehland<dinov at microsoft.com>
>> wrote:
>> > You can just do:
>> >
>> > x.FindAll(lambda inst:True)
>> >
>> > or:
>> >
>> > def MyPredicate(obj):
>> > ? ? ? ?return True
>> >
>> > x.FindAll(MyPredicate)
>> >
>> >> -----Original Message-----
>> >> From: users-bounces at lists.ironpython.com [mailto:users-
>> >> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
>> >> Sent: Friday, July 24, 2009 12:04 AM
>> >> To: Discussion of IronPython
>> >> Subject: [IronPython] how to use Predicates in IPy?
>> >>
>> >> I've been unable to find any examples of how to define/use
>> Predicates
>> >> in IPy, as for use with .NET's List(T).FindAll method. Specifically
>> >> I'm trying to use
>> >>
>> http://lib.openmetaverse.org/docs/trunk/html/M_OpenMetaverse_InternalDi
>> >> ctionary_2_FindAll_1.htm
>> >>
>> >> Anyway, if someone could help with an example of how to do such
>> things
>> >> in IPy I'd greatly appreciate. The one mention of it in this list's
>> >> archives is from 2006 and refers to an example url that is now
>> broken.
>> >>
>> >> --
>> >> Cheers, L?szl?
>> >> _______________________________________________
>> >> 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
>> >
>>
>>
>>
>> --
>> Cheers, L?szl?
>> _______________________________________________
>> 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
>



-- 
Cheers, L?szl?


From calmasy at gmail.com  Sat Jul 25 01:15:01 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Fri, 24 Jul 2009 17:15:01 -0600
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
Message-ID: <abb783b90907241615v5ea6362ued267922c9e71a6a@mail.gmail.com>

On Thu, Jul 23, 2009 at 10:07 AM, Dave Fugate<dfugate at microsoft.com> wrote:
> Quite simply put IronPython users with 64-bit OSes will see around a 33% improvement to
> IronPython startup time under ipy.exe!

Great news. I am on 64-bit Linux, and startup time is significantly
slower than CPython.

-- 
Cheers, L?szl?


From dinov at microsoft.com  Sat Jul 25 01:29:52 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 24 Jul 2009 23:29:52 +0000
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <abb783b90907241615v5ea6362ued267922c9e71a6a@mail.gmail.com>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<abb783b90907241615v5ea6362ued267922c9e71a6a@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD0356E465@TK5EX14MBXC118.redmond.corp.microsoft.com>

YMMV on Mono - their 64-bit could have different performance
characteristics than our 64-bit JIT.  On Windows it's a big win
because the 32-bit JIT is much, much faster than the 64-bit JIT.

Also does Mono have something like ngen?  If so you should
definitely use it and you'll get much improved startup that way
too.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
> Sent: Friday, July 24, 2009 4:15 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] [ANN]: IronPython 2.6 Beta 2
>
> On Thu, Jul 23, 2009 at 10:07 AM, Dave Fugate<dfugate at microsoft.com>
> wrote:
> > Quite simply put IronPython users with 64-bit OSes will see around a
> 33% improvement to
> > IronPython startup time under ipy.exe!
>
> Great news. I am on 64-bit Linux, and startup time is significantly
> slower than CPython.
>
> --
> Cheers, L?szl?
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From calmasy at gmail.com  Sat Jul 25 01:47:05 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Fri, 24 Jul 2009 17:47:05 -0600
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0356E465@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<abb783b90907241615v5ea6362ued267922c9e71a6a@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD0356E465@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <abb783b90907241647q559cd8a8sbcaeb60a3b97663c@mail.gmail.com>

i hadn't really considered that to be honest. i found this page on the
Mono runtime which is pretty interesting-
http://mono-project.com/Mono:Runtime

it mentions ngen:

"When an assembly (a Mono/.NET executable) is installed in the system,
it is then be possible to pre-compile the code, and have the JIT
compiler tune the generated code to the particular CPU on which the
software is installed.

This is done in the Microsoft.NET world with a tool called ngen.exe.

The code produced by Mono's ahead-of-time compiler is Position
Independent Code (PIC) which tends to be a bit slower than regular
JITed code, but what you loose in performance with PIC you gain by
being able to use all the available optimizations.

To compile your assemblies with this, just run this command:

 $ mono -O=all --aot program.exe

Additionally, if you want to do full static builds (and be able to run
without the JIT engine), you can use:

 $ mono -O=all --aot --full-aot program.exe"

So it appears there are some speedups i can look at. thanks.

On Fri, Jul 24, 2009 at 5:29 PM, Dino Viehland<dinov at microsoft.com> wrote:
> YMMV on Mono - their 64-bit could have different performance
> characteristics than our 64-bit JIT. ?On Windows it's a big win
> because the 32-bit JIT is much, much faster than the 64-bit JIT.
>
> Also does Mono have something like ngen? ?If so you should
> definitely use it and you'll get much improved startup that way
> too.
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Count L?szl? de Alm?sy
>> Sent: Friday, July 24, 2009 4:15 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] [ANN]: IronPython 2.6 Beta 2
>>
>> On Thu, Jul 23, 2009 at 10:07 AM, Dave Fugate<dfugate at microsoft.com>
>> wrote:
>> > Quite simply put IronPython users with 64-bit OSes will see around a
>> 33% improvement to
>> > IronPython startup time under ipy.exe!
>>
>> Great news. I am on 64-bit Linux, and startup time is significantly
>> slower than CPython.
>>
>> --
>> Cheers, L?szl?
>> _______________________________________________
>> 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
>



-- 
Cheers, L?szl?


From jdhardy at gmail.com  Sat Jul 25 02:02:29 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 24 Jul 2009 18:02:29 -0600
Subject: [IronPython] Getting function argument names from hosting
Message-ID: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>

Hi all,
>From the hosting side, is there a way to get the names of a function's
arguments? The DLR equivalent of MethodInfo.GetParamters(),
essentially, is what I'm looking for (or a way to get an actual
MethodInfo would be nice as well).

- Jeff


From dinov at microsoft.com  Sat Jul 25 02:04:24 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 25 Jul 2009 00:04:24 +0000
Subject: [IronPython] Getting function argument names from hosting
In-Reply-To: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>
References: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03571F1A@TK5EX14MBXC118.redmond.corp.microsoft.com>

ObjectOperations.GetCallSignatures:

import clr
clr.AddReference('IronPython')
from IronPython.Hosting import Python
x = Python.CreateEngine()
def f(a, b, c): pass

x.Operations.GetCallSignatures(f)

prints:
Array[str](('f(a, b, c)'))


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Friday, July 24, 2009 5:02 PM
> To: Discussion of IronPython
> Subject: [IronPython] Getting function argument names from hosting
>
> Hi all,
> >From the hosting side, is there a way to get the names of a function's
> arguments? The DLR equivalent of MethodInfo.GetParamters(),
> essentially, is what I'm looking for (or a way to get an actual
> MethodInfo would be nice as well).
>
> - Jeff
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From sanxiyn at gmail.com  Sat Jul 25 14:06:39 2009
From: sanxiyn at gmail.com (Seo Sanghyeon)
Date: Sat, 25 Jul 2009 21:06:39 +0900
Subject: [IronPython] IronPython ctypes on Linux
Message-ID: <5b0248170907250506o1f23d46bof2c7c4d8140d17b9@mail.gmail.com>

Hopefully I'm not too late on reporthing this...

If you look at ctypes/__init__.py in Python 2.6, it imports different
functions from _ctypes depending on os.name. So on Linux, it expects
dlopen to be available, instead of LoadLibrary.

-- 
Seo Sanghyeon


From fuzzyman at voidspace.org.uk  Sun Jul 26 17:02:42 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 16:02:42 +0100
Subject: [IronPython] help in IronPython 2.6
Message-ID: <4A6C7012.1080702@voidspace.org.uk>

Hello guys,

It really sucks that from a vanilla install of IronPython 2.6 'help' 
doesn't work in the interactive interpreter. :-(

Of course it works if you switch frames on - but I don't think having 
frames on by default is the right solution (perhaps only if you entering 
an interactive interpreter session where performance is less likely to 
be an issue?).

Can you patch your version of site.py to fix this?

Michael

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




From jeffrey at extremeoptimization.com  Sun Jul 26 18:13:38 2009
From: jeffrey at extremeoptimization.com (Jeffrey Sax)
Date: Sun, 26 Jul 2009 12:13:38 -0400
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <000601ca0e0c$09913c70$1cb3b550$@com>

Thanks Michael & Dino,

That gets me a step further:

>>> from sympy import Symbol
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Program Files
(x86)\Python26\Lib\site-packages\sympy\__init__.py", line 44, in c:\Program
Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
NameError: global name 'evalf' is not defined
>>> 

evalf is a module that is part of sympy.core. This works fine on CPython
2.6. I can get around the problem by commenting out the offending line,
which doesn't seem to have any breaking side-effects.

Still, given the performance degradation, it seems odd you have to turn
frames on just to import a module regardless of whether you actually need
the frames functionality.

Jeffrey


-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: July-24-09 4:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] sympy on IP 2.6B2

-X:FullFrames promotes all local variables into the heap.  So you can
always crawl the stack and look/change them for all methods.

-X:Frames only creates the frame objects and if something happens to
make us promote local variables (e.g. a closure, or a call to locals(),
exec, eval, dir(), vars()) then the local variables will be available
for that specific method.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, July 24, 2009 1:47 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] sympy on IP 2.6B2
>
> Try running it with frames switched on:
>
>     ipy.exe -X:Frames
>
> or:
>
>     ipy.exe -X:FullFrames
>
> Perhaps Dino can explain what the difference is between these two
> modes... :-)
>
> Michael
> 




From jdhardy at gmail.com  Sun Jul 26 18:18:20 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 26 Jul 2009 10:18:20 -0600
Subject: [IronPython] Getting function argument names from hosting
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03571F1A@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD03571F1A@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <ea89d0e50907260918i6d809a5bh43a2bf68beb66f@mail.gmail.com>

Thanks, Dino!

It'd be nice if I didn't have to parse the signature, but that'll do for now.

- Jeff

On Fri, Jul 24, 2009 at 6:04 PM, Dino Viehland<dinov at microsoft.com> wrote:
> ObjectOperations.GetCallSignatures:
>
> import clr
> clr.AddReference('IronPython')
> from IronPython.Hosting import Python
> x = Python.CreateEngine()
> def f(a, b, c): pass
>
> x.Operations.GetCallSignatures(f)
>
> prints:
> Array[str](('f(a, b, c)'))
>
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
>> Sent: Friday, July 24, 2009 5:02 PM
>> To: Discussion of IronPython
>> Subject: [IronPython] Getting function argument names from hosting
>>
>> Hi all,
>> >From the hosting side, is there a way to get the names of a function's
>> arguments? The DLR equivalent of MethodInfo.GetParamters(),
>> essentially, is what I'm looking for (or a way to get an actual
>> MethodInfo would be nice as well).
>>
>> - 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 fuzzyman at voidspace.org.uk  Sun Jul 26 18:18:54 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 17:18:54 +0100
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <000601ca0e0c$09913c70$1cb3b550$@com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>	<4A6A1DD7.50602@voidspace.org.uk>	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<000601ca0e0c$09913c70$1cb3b550$@com>
Message-ID: <4A6C81EE.4030802@voidspace.org.uk>

Jeffrey Sax wrote:
> Thanks Michael & Dino,
>
> That gets me a step further:
>
>   
>>>> from sympy import Symbol
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "c:\Program Files
> (x86)\Python26\Lib\site-packages\sympy\__init__.py", line 44, in c:\Program
> Files (x86)\Python26\Lib\site-packages\sympy\__init__.py
> NameError: global name 'evalf' is not defined
>   
>
>   

An undefined name is an undefined name. Sympy must be doing some magic 
somewhere to inject the name into the namespace.

> evalf is a module that is part of sympy.core. This works fine on CPython
> 2.6. I can get around the problem by commenting out the offending line,
> which doesn't seem to have any breaking side-effects.
>
> Still, given the performance degradation, it seems odd you have to turn
> frames on just to import a module regardless of whether you actually need
> the frames functionality. 
>   

The decision was to remove _getframe if frames are disabled. As Jython 
didn't used to define _getframe when it didn't have Python stack frames, 
so there is some code in standard library modules that will detect and 
workaround the absence of _getframe. Unfortunately there is a 
corresponding amount of code that assumes it is always there so it's a 
bit of a double bind.

All the best,

Michael Foord


> Jeffrey
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: July-24-09 4:50 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] sympy on IP 2.6B2
>
> -X:FullFrames promotes all local variables into the heap.  So you can
> always crawl the stack and look/change them for all methods.
>
> -X:Frames only creates the frame objects and if something happens to
> make us promote local variables (e.g. a closure, or a call to locals(),
> exec, eval, dir(), vars()) then the local variables will be available
> for that specific method.
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, July 24, 2009 1:47 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] sympy on IP 2.6B2
>>
>> Try running it with frames switched on:
>>
>>     ipy.exe -X:Frames
>>
>> or:
>>
>>     ipy.exe -X:FullFrames
>>
>> Perhaps Dino can explain what the difference is between these two
>> modes... :-)
>>
>> Michael
>>
>>     
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From fuzzyman at voidspace.org.uk  Sun Jul 26 18:19:32 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 17:19:32 +0100
Subject: [IronPython] Getting function argument names from hosting
In-Reply-To: <ea89d0e50907260918i6d809a5bh43a2bf68beb66f@mail.gmail.com>
References: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>	<1A472770E042064698CB5ADC83A12ACD03571F1A@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<ea89d0e50907260918i6d809a5bh43a2bf68beb66f@mail.gmail.com>
Message-ID: <4A6C8214.6020102@voidspace.org.uk>

Jeff Hardy wrote:
> Thanks, Dino!
>
> It'd be nice if I didn't have to parse the signature, but that'll do for now.
>   

You can always use the inspect module. (getargspec function.)

Michael

> - Jeff
>
> On Fri, Jul 24, 2009 at 6:04 PM, Dino Viehland<dinov at microsoft.com> wrote:
>   
>> ObjectOperations.GetCallSignatures:
>>
>> import clr
>> clr.AddReference('IronPython')
>> from IronPython.Hosting import Python
>> x = Python.CreateEngine()
>> def f(a, b, c): pass
>>
>> x.Operations.GetCallSignatures(f)
>>
>> prints:
>> Array[str](('f(a, b, c)'))
>>
>>
>>     
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-
>>> bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
>>> Sent: Friday, July 24, 2009 5:02 PM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] Getting function argument names from hosting
>>>
>>> Hi all,
>>> >From the hosting side, is there a way to get the names of a function's
>>> arguments? The DLR equivalent of MethodInfo.GetParamters(),
>>> essentially, is what I'm looking for (or a way to get an actual
>>> MethodInfo would be nice as well).
>>>
>>> - 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
>>
>>     
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From jdhardy at gmail.com  Sun Jul 26 18:24:37 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 26 Jul 2009 10:24:37 -0600
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <000601ca0e0c$09913c70$1cb3b550$@com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>
	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>
	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<000601ca0e0c$09913c70$1cb3b550$@com>
Message-ID: <ea89d0e50907260924t28ae29ebx669357dda6278d65@mail.gmail.com>

On Sun, Jul 26, 2009 at 10:13 AM, Jeffrey
Sax<jeffrey at extremeoptimization.com> wrote:
>
> Still, given the performance degradation, it seems odd you have to turn
> frames on just to import a module regardless of whether you actually need
> the frames functionality.

For that reason, modules should have guards similar to

if not hasattr(sys, '_getframe'):
    ...

around any code that uses frames, and disable that functionality if
they're not available. Both Jython and IronPython have the same
problem with frames causing a large performance hit, so it helps
portability.

- Jeff


From curt at hagenlocher.org  Sun Jul 26 18:26:43 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Sun, 26 Jul 2009 09:26:43 -0700
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <ea89d0e50907260924t28ae29ebx669357dda6278d65@mail.gmail.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>
	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>
	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<000601ca0e0c$09913c70$1cb3b550$@com>
	<ea89d0e50907260924t28ae29ebx669357dda6278d65@mail.gmail.com>
Message-ID: <d2155e360907260926i5b750403gbe6bd7ab3204acc2@mail.gmail.com>

On Sun, Jul 26, 2009 at 9:24 AM, Jeff Hardy<jdhardy at gmail.com> wrote:
>
> around any code that uses frames, and disable that functionality if
> they're not available. Both Jython and IronPython have the same
> problem with frames causing a large performance hit, so it helps
> portability.

And it's reasonable to assume that Unladed Swallow will (at some
point) be in the same place too.

--
Curt Hagenlocher
curt at hagenlocher.org


From fuzzyman at voidspace.org.uk  Sun Jul 26 18:26:48 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 17:26:48 +0100
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <ea89d0e50907260924t28ae29ebx669357dda6278d65@mail.gmail.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>	<4A6A1DD7.50602@voidspace.org.uk>	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>	<000601ca0e0c$09913c70$1cb3b550$@com>
	<ea89d0e50907260924t28ae29ebx669357dda6278d65@mail.gmail.com>
Message-ID: <4A6C83C8.7060908@voidspace.org.uk>

Jeff Hardy wrote:
> On Sun, Jul 26, 2009 at 10:13 AM, Jeffrey
> Sax<jeffrey at extremeoptimization.com> wrote:
>   
>> Still, given the performance degradation, it seems odd you have to turn
>> frames on just to import a module regardless of whether you actually need
>> the frames functionality.
>>     
>
> For that reason, modules should have guards similar to
>
> if not hasattr(sys, '_getframe'):
>     ...
>
> around any code that uses frames, and disable that functionality if
> they're not available. Both Jython and IronPython have the same
> problem with frames causing a large performance hit, so it helps
> portability.
>
>   

Doesn't Jython have frames now?

Anyway - yes code *should* have hasattr guards, but unfortunately a lot 
of it doesn't, which sucks.

Michael

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


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




From jdhardy at gmail.com  Sun Jul 26 18:31:16 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 26 Jul 2009 10:31:16 -0600
Subject: [IronPython] Getting function argument names from hosting
In-Reply-To: <4A6C8214.6020102@voidspace.org.uk>
References: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD03571F1A@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<ea89d0e50907260918i6d809a5bh43a2bf68beb66f@mail.gmail.com>
	<4A6C8214.6020102@voidspace.org.uk>
Message-ID: <ea89d0e50907260931r7d973f8chfa8e5d19ef1bc109@mail.gmail.com>

On Sun, Jul 26, 2009 at 10:19 AM, Michael
Foord<fuzzyman at voidspace.org.uk> wrote:
>
> You can always use the inspect module. (getargspec function.)

Too bad it's such a pain to use from C# (dynamic, please!) - but it
can't be any worse that trying to parse the signature. I'll probably
give both a try and see which one works out better.

- Jeff


>
> Michael
>
>> - Jeff
>>
>> On Fri, Jul 24, 2009 at 6:04 PM, Dino Viehland<dinov at microsoft.com> wrote:
>>
>>>
>>> ObjectOperations.GetCallSignatures:
>>>
>>> import clr
>>> clr.AddReference('IronPython')
>>> from IronPython.Hosting import Python
>>> x = Python.CreateEngine()
>>> def f(a, b, c): pass
>>>
>>> x.Operations.GetCallSignatures(f)
>>>
>>> prints:
>>> Array[str](('f(a, b, c)'))
>>>
>>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: users-bounces at lists.ironpython.com [mailto:users-
>>>> bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
>>>> Sent: Friday, July 24, 2009 5:02 PM
>>>> To: Discussion of IronPython
>>>> Subject: [IronPython] Getting function argument names from hosting
>>>>
>>>> Hi all,
>>>> >From the hosting side, is there a way to get the names of a function's
>>>> arguments? The DLR equivalent of MethodInfo.GetParamters(),
>>>> essentially, is what I'm looking for (or a way to get an actual
>>>> MethodInfo would be nice as well).
>>>>
>>>> - 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
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From dinov at microsoft.com  Sun Jul 26 18:56:37 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sun, 26 Jul 2009 16:56:37 +0000
Subject: [IronPython] Getting function argument names from hosting
In-Reply-To: <ea89d0e50907260918i6d809a5bh43a2bf68beb66f@mail.gmail.com>
References: <ea89d0e50907241702o764cf6fcj11f12a27cb05e886@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD03571F1A@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<ea89d0e50907260918i6d809a5bh43a2bf68beb66f@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035F0DC2@TK5EX14MBXC118.redmond.corp.microsoft.com>

Yeah, that thought occurred to me about 5 minutes after I sent it out :)

This API was really intended for displaying intellisense style help
but even there you probably want to have individual arg info so you
can display different help as you go from param to param.  We should
look at coming up w/ a better API here.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
> Sent: Sunday, July 26, 2009 9:18 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Getting function argument names from hosting
>
> Thanks, Dino!
>
> It'd be nice if I didn't have to parse the signature, but that'll do
> for now.
>
> - Jeff
>
> On Fri, Jul 24, 2009 at 6:04 PM, Dino Viehland<dinov at microsoft.com>
> wrote:
> > ObjectOperations.GetCallSignatures:
> >
> > import clr
> > clr.AddReference('IronPython')
> > from IronPython.Hosting import Python
> > x = Python.CreateEngine()
> > def f(a, b, c): pass
> >
> > x.Operations.GetCallSignatures(f)
> >
> > prints:
> > Array[str](('f(a, b, c)'))
> >
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
> >> Sent: Friday, July 24, 2009 5:02 PM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] Getting function argument names from hosting
> >>
> >> Hi all,
> >> >From the hosting side, is there a way to get the names of a
> function's
> >> arguments? The DLR equivalent of MethodInfo.GetParamters(),
> >> essentially, is what I'm looking for (or a way to get an actual
> >> MethodInfo would be nice as well).
> >>
> >> - 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
> >
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Sun Jul 26 18:58:10 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sun, 26 Jul 2009 16:58:10 +0000
Subject: [IronPython] help in IronPython 2.6
In-Reply-To: <4A6C7012.1080702@voidspace.org.uk>
References: <4A6C7012.1080702@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>

We could patch our site.py and if worse comes to worse we may just do
that.  But we've never re-distributed a modified version of the std
lib and we're not really wanting to start doing that.  Rather we're
trying to work through things on our side to make the changes and
submit them back to the std lib.  We hope to have this done by the
RC - but if not we'll obviously need to look at our options closely.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, July 26, 2009 8:03 AM
> To: Discussion of IronPython
> Subject: [IronPython] help in IronPython 2.6
>
> Hello guys,
>
> It really sucks that from a vanilla install of IronPython 2.6 'help'
> doesn't work in the interactive interpreter. :-(
>
> Of course it works if you switch frames on - but I don't think having
> frames on by default is the right solution (perhaps only if you
> entering
> an interactive interpreter session where performance is less likely to
> be an issue?).
>
> Can you patch your version of site.py to fix this?
>
> Michael
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From fuzzyman at voidspace.org.uk  Sun Jul 26 19:04:15 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 18:04:15 +0100
Subject: [IronPython] help in IronPython 2.6
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <4A6C7012.1080702@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <4A6C8C8F.8080105@voidspace.org.uk>

Dino Viehland wrote:
> We could patch our site.py and if worse comes to worse we may just do
> that.  But we've never re-distributed a modified version of the std
> lib and we're not really wanting to start doing that.  Rather we're
> trying to work through things on our side to make the changes and
> submit them back to the std lib.  We hope to have this done by the
> RC - but if not we'll obviously need to look at our options closely.
>   

Well I can submit a patch to site.py in Python 2.6 myself - although it 
probably won't be in a *released* version of Python by the time you RC. 
Is that helpful or not?

Michael

>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Sunday, July 26, 2009 8:03 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] help in IronPython 2.6
>>
>> Hello guys,
>>
>> It really sucks that from a vanilla install of IronPython 2.6 'help'
>> doesn't work in the interactive interpreter. :-(
>>
>> Of course it works if you switch frames on - but I don't think having
>> frames on by default is the right solution (perhaps only if you
>> entering
>> an interactive interpreter session where performance is less likely to
>> be an issue?).
>>
>> Can you patch your version of site.py to fix this?
>>
>> Michael
>>
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From dinov at microsoft.com  Sun Jul 26 19:11:28 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sun, 26 Jul 2009 17:11:28 +0000
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <4A6C81EE.4030802@voidspace.org.uk>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>
	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<000601ca0e0c$09913c70$1cb3b550$@com>
	<4A6C81EE.4030802@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035F102A@TK5EX14MBXC118.redmond.corp.microsoft.com>

Michael wrote:
> An undefined name is an undefined name. Sympy must be doing some magic
> somewhere to inject the name into the namespace.

If I had to guess that magic could be something involving imports.
There's another import bug Harry wants me to look at before 2.6 is done
so I'll try and see if this could be the same issue.  There's something
strange going on w/ circular imports and publishing back into sys.modules
during the import process.



From dinov at microsoft.com  Sun Jul 26 20:03:32 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sun, 26 Jul 2009 18:03:32 +0000
Subject: [IronPython] help in IronPython 2.6
In-Reply-To: <4A6C8C8F.8080105@voidspace.org.uk>
References: <4A6C7012.1080702@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<4A6C8C8F.8080105@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035F14F2@TK5EX14MBXC118.redmond.corp.microsoft.com>

Michael wrote:
> Well I can submit a patch to site.py in Python 2.6 myself - although it
> probably won't be in a *released* version of Python by the time you RC.
> Is that helpful or not?

Yep, that'd be very helpful.  I have a check-in ready to go Monday which
integrates SVN as of Tuesday or Wednesday so it'll be pretty easy to
integrate a more recent version now (previously we were at 2.6.0).



From cenovsky at bakalari.cz  Sun Jul 26 20:16:35 2009
From: cenovsky at bakalari.cz (Lukas Cenovsky)
Date: Sun, 26 Jul 2009 20:16:35 +0200
Subject: [IronPython] [ANN]: IronPython 2.6 Beta 2
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD0354A2EF@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <7CEEC335D70FFE4B957737DDE836F51B01EA01@TK5EX14MBXC123.redmond.corp.microsoft.com>	<4A68E577.5060705@bakalari.cz>
	<1A472770E042064698CB5ADC83A12ACD0354A2EF@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <4A6C9D83.1080409@bakalari.cz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090726/13216116/attachment.html>

From jeffrey at extremeoptimization.com  Sun Jul 26 22:08:29 2009
From: jeffrey at extremeoptimization.com (Jeffrey Sax)
Date: Sun, 26 Jul 2009 16:08:29 -0400
Subject: [IronPython] Operator resolution with implicit conversion
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD035F102A@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>	<4A6A1DD7.50602@voidspace.org.uk>	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>	<000601ca0e0c$09913c70$1cb3b550$@com>	<4A6C81EE.4030802@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035F102A@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <001701ca0e2c$d862bd60$89283820$@com>

Given the following C# code:

public class A { 
   public static A operator+(A a1, A a2) { return null; }
   public static implicit operator A(int n) { return null; }
}
public class B : A {}

In C#, I can then write:

B b = new B();
A c = b + 1;

However, in IronPython I get:

>>> b = B()
>>> c = b + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'B' and 'int'

Is there a general policy regarding this kind of .NET interop?

Thanks,

Jeffrey



From jeffrey at extremeoptimization.com  Sun Jul 26 22:12:06 2009
From: jeffrey at extremeoptimization.com (Jeffrey Sax)
Date: Sun, 26 Jul 2009 16:12:06 -0400
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
References: <4A649D5B.1020807@resolversystems.com>	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
Message-ID: <001801ca0e2d$59dd4130$0d97c390$@com>

I got sympy 0.6.5 running *without* frames by commenting out some lines:

sympy\__init__.py: line 44
# evalf._create_evalf_table()

Sympy\utilities\__init__.py: lines 14 and 18:
# from source import source
# from runtests import test, doctest

There are two more anomalies I'd like to report:


1. Performance

CPython 2.6:
>>> from time import time
>>> from sympy import Symbol, cos
>>> x = Symbol("x")
>>> a=time(); cos(x).diff(x,1000); time()-a
0.10899996757507324

IronPython 2.6b2:
>>> from time import time
>>> from sympy import Symbol, cos
>>> x = Symbol("x")
>>> a=time(); cos(x).diff(x,1000); time()-a
5.678321838378906

So IronPython is 50 times slower here on pure Python code.


2. Problem with '*' (splat operator)

Using the same setup code as above:

CPython 2.6:
>>> cos(x).series(x,0,10)
1 - x**2/2 + x**4/24 - x**6/720 + x**8/40320 + O(x**10)

IronPython 2.6b2:
>>> cos(x).series(x,0,10);
Traceback (most recent call last):
  File "C:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2139, in series
  File "C:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2206, in nseries
  File "C:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\function.py", line 308, in
_eval_nseries
  File "C:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\basic.py", line 2206, in nseries
  File "C:\Program Files
(x86)\Python26\Lib\site-packages\sympy\core\mul.py", line 753, in
_eval_nseries
  File "C:\Program Files
(x86)\Python26\Lib\site-packages\sympy\simplify\simplify.py", line 1008, in
powsimp
TypeError: __call__() argument after * must be a sequence, not generator

The offending line:
   newexpr = Mul(newexpr, Mul(*(Pow(b,e) for b, e in c_powers.items())))

Oddly enough, something like:

>>> def f(*args):
...     pass
...
>>> f(*(x for x in range(3)))

works fine, but

>>> from sympy import Mul
>>> Mul(*(x for x in range(3)))
	
does not. Mul is the type that represents a multiplication operation in
sympy.

Jeffrey

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: July-24-09 4:50 PM
To: Discussion of IronPython
Subject: Re: [IronPython] sympy on IP 2.6B2

-X:FullFrames promotes all local variables into the heap.  So you can
always crawl the stack and look/change them for all methods.

-X:Frames only creates the frame objects and if something happens to
make us promote local variables (e.g. a closure, or a call to locals(),
exec, eval, dir(), vars()) then the local variables will be available
for that specific method.



From fuzzyman at voidspace.org.uk  Sun Jul 26 22:22:20 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 21:22:20 +0100
Subject: [IronPython] help in IronPython 2.6
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD035F14F2@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <4A6C7012.1080702@voidspace.org.uk>	<1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>	<4A6C8C8F.8080105@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035F14F2@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <4A6CBAFC.6080702@voidspace.org.uk>

Dino Viehland wrote:
> Michael wrote:
>   
>> Well I can submit a patch to site.py in Python 2.6 myself - although it
>> probably won't be in a *released* version of Python by the time you RC.
>> Is that helpful or not?
>>     
>
> Yep, that'd be very helpful.  I have a check-in ready to go Monday which
> integrates SVN as of Tuesday or Wednesday so it'll be pretty easy to
> integrate a more recent version now (previously we were at 2.6.0).
>   

http://bugs.python.org/issue6581

I'll try and get this applied as soon as possible on Python 2.6 and trunk.

Michael Foord


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


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




From fuzzyman at voidspace.org.uk  Sun Jul 26 23:13:22 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sun, 26 Jul 2009 22:13:22 +0100
Subject: [IronPython] help in IronPython 2.6
In-Reply-To: <4A6CBAFC.6080702@voidspace.org.uk>
References: <4A6C7012.1080702@voidspace.org.uk>	<1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>	<4A6C8C8F.8080105@voidspace.org.uk>	<1A472770E042064698CB5ADC83A12ACD035F14F2@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<4A6CBAFC.6080702@voidspace.org.uk>
Message-ID: <4A6CC6F2.4080409@voidspace.org.uk>

Michael Foord wrote:
> Dino Viehland wrote:
>> Michael wrote:
>>  
>>> Well I can submit a patch to site.py in Python 2.6 myself - although it
>>> probably won't be in a *released* version of Python by the time you RC.
>>> Is that helpful or not?
>>>     
>>
>> Yep, that'd be very helpful.  I have a check-in ready to go Monday which
>> integrates SVN as of Tuesday or Wednesday so it'll be pretty easy to
>> integrate a more recent version now (previously we were at 2.6.0).
>>   
>
> http://bugs.python.org/issue6581
>
> I'll try and get this applied as soon as possible on Python 2.6 and 
> trunk.

Done.

Michael

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


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




From calmasy at gmail.com  Mon Jul 27 10:13:13 2009
From: calmasy at gmail.com (=?ISO-8859-1?Q?Count_L=E1szl=F3_de_Alm=E1sy?=)
Date: Mon, 27 Jul 2009 02:13:13 -0600
Subject: [IronPython] IPy is a gift from god
Message-ID: <abb783b90907270113n3a6ee50bo19dab35e8d05ca8f@mail.gmail.com>

lol. feeling thankful at the moment. having recently been forced to
work on a project where the only interface is .NET assemblies, there
was no getting around having to use .NET. during the past couple weeks
i've learned enough C# to understand the library when i need to, and
also realize *WOW* i'm so glad there's an alternative. being able to
mix Python and .NET code seems almost illegal. IPy is such a clever
invention. thanks so much for this amazingly useful tool.

-- 
Cheers, L?szl?


From fuzzyman at voidspace.org.uk  Mon Jul 27 17:35:27 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 27 Jul 2009 16:35:27 +0100
Subject: [IronPython] pdb with IronPython 2.6 beta 2
Message-ID: <4A6DC93F.2040707@voidspace.org.uk>

Hello all,

I've been trying to use the pdb module with IronPython 2.6beta2 and the
interactive interpreter (with the -X:FullFrames command line option).
I've only used pdb with the set_trace function, but I couldn't get *any*
of it to work in my brief exploration.

I've posted my interactive session below in case anyone can point out
what I'm doing wrong:

IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4016
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb
>>> def f():
...      a = 3
...      pdb.set_trace()
...
>>> f()
>>> print a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
>>> pdb.run('f()')
>>> def f():
...  a = 3
...  foo
...
>>> pdb.pm()
> <stdin>(1)<module>()
(Pdb) a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 1232, in pm
  File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 1229, in
post_mortem
  File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 194, in
interaction
  File "C:\Program Files\IronPython 2.6\Lib\cmd.py", line 142, in cmdloop
  File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 252, in onecmd
  File "C:\Program Files\IronPython 2.6\Lib\cmd.py", line 219, in onecmd
  File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 702, in do_args
SystemError: Object reference not set to an instance of an object.
>>>

For the record I tried the same with CPython and it worked as expected:

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb
>>> def f():
...  a = 3
...  pdb.set_trace()
...
>>> f()
--Return--
> <stdin>(3)f()->None
(Pdb) a
(Pdb) print a
3
(Pdb)

 >>> def f():
...  a = 6
...  foo
...
 >>> f()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 3, in f
NameError: global name 'foo' is not defined
 >>> pdb.pm()
 > <stdin>(3)f()
(Pdb) a
(Pdb) print a
6
(Pdb)



All the best,

Michael

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



From dinov at microsoft.com  Mon Jul 27 17:38:03 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 27 Jul 2009 15:38:03 +0000
Subject: [IronPython] help in IronPython 2.6
In-Reply-To: <4A6CC6F2.4080409@voidspace.org.uk>
References: <4A6C7012.1080702@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035F0F7E@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<4A6C8C8F.8080105@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035F14F2@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<4A6CBAFC.6080702@voidspace.org.uk> <4A6CC6F2.4080409@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035FC3AC@TK5EX14MBXC118.redmond.corp.microsoft.com>

Thanks Michael!

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, July 26, 2009 2:13 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] help in IronPython 2.6
>
> Michael Foord wrote:
> > Dino Viehland wrote:
> >> Michael wrote:
> >>
> >>> Well I can submit a patch to site.py in Python 2.6 myself -
> although it
> >>> probably won't be in a *released* version of Python by the time you
> RC.
> >>> Is that helpful or not?
> >>>
> >>
> >> Yep, that'd be very helpful.  I have a check-in ready to go Monday
> which
> >> integrates SVN as of Tuesday or Wednesday so it'll be pretty easy to
> >> integrate a more recent version now (previously we were at 2.6.0).
> >>
> >
> > http://bugs.python.org/issue6581
> >
> > I'll try and get this applied as soon as possible on Python 2.6 and
> > trunk.
>
> Done.
>
> Michael
>
> >
> > Michael Foord
> >
> >
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.ironpython.com
> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>
> >
> >
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Mon Jul 27 17:42:23 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 27 Jul 2009 15:42:23 +0000
Subject: [IronPython] pdb with IronPython 2.6 beta 2
In-Reply-To: <4A6DC93F.2040707@voidspace.org.uk>
References: <4A6DC93F.2040707@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035FC3DF@TK5EX14MBXC118.redmond.corp.microsoft.com>

This is what we've tested so far :)

>>> import pdb
>>> def f():
...     print 'hi'
...     print 'goodbye'
...
>>> pdb.runcall(f)
> <stdin>(2)f()
(Pdb) s
hi
> <stdin>(3)f()
(Pdb) s
goodbye
--Return--
> <stdin>(3)f()->None
(Pdb) s
>>> pdb.runcall(f)
> <stdin>(2)f()
(Pdb) ?

Unfortunately there don't seem to be pdb tests so it's hard for us
to say what works and doesn't yet.  Could you open a bug on this and
that way it won't fall off our radar?

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, July 27, 2009 8:35 AM
> To: Discussion of IronPython
> Subject: [IronPython] pdb with IronPython 2.6 beta 2
>
> Hello all,
>
> I've been trying to use the pdb module with IronPython 2.6beta2 and the
> interactive interpreter (with the -X:FullFrames command line option).
> I've only used pdb with the set_trace function, but I couldn't get
> *any*
> of it to work in my brief exploration.
>
> I've posted my interactive session below in case anyone can point out
> what I'm doing wrong:
>
> IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4016
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pdb
> >>> def f():
> ...      a = 3
> ...      pdb.set_trace()
> ...
> >>> f()
> >>> print a
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name 'a' is not defined
> >>> pdb.run('f()')
> >>> def f():
> ...  a = 3
> ...  foo
> ...
> >>> pdb.pm()
> > <stdin>(1)<module>()
> (Pdb) a
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 1232, in pm
>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 1229, in
> post_mortem
>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 194, in
> interaction
>   File "C:\Program Files\IronPython 2.6\Lib\cmd.py", line 142, in
> cmdloop
>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 252, in
> onecmd
>   File "C:\Program Files\IronPython 2.6\Lib\cmd.py", line 219, in
> onecmd
>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 702, in
> do_args
> SystemError: Object reference not set to an instance of an object.
> >>>
>
> For the record I tried the same with CPython and it worked as expected:
>
> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
> (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pdb
> >>> def f():
> ...  a = 3
> ...  pdb.set_trace()
> ...
> >>> f()
> --Return--
> > <stdin>(3)f()->None
> (Pdb) a
> (Pdb) print a
> 3
> (Pdb)
>
>  >>> def f():
> ...  a = 6
> ...  foo
> ...
>  >>> f()
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "<stdin>", line 3, in f
> NameError: global name 'foo' is not defined
>  >>> pdb.pm()
>  > <stdin>(3)f()
> (Pdb) a
> (Pdb) print a
> 6
> (Pdb)
>
>
>
> All the best,
>
> Michael
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From fuzzyman at voidspace.org.uk  Mon Jul 27 17:48:38 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 27 Jul 2009 16:48:38 +0100
Subject: [IronPython] pdb with IronPython 2.6 beta 2
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD035FC3DF@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <4A6DC93F.2040707@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD035FC3DF@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <4A6DCC56.5090905@voidspace.org.uk>

Issue 23650

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23650

Michael Foord

Dino Viehland wrote:
> This is what we've tested so far :)
>
>   
>>>> import pdb
>>>> def f():
>>>>         
> ...     print 'hi'
> ...     print 'goodbye'
> ...
>   
>>>> pdb.runcall(f)
>>>>         
>> <stdin>(2)f()
>>     
> (Pdb) s
> hi
>   
>> <stdin>(3)f()
>>     
> (Pdb) s
> goodbye
> --Return--
>   
>> <stdin>(3)f()->None
>>     
> (Pdb) s
>   
>>>> pdb.runcall(f)
>>>>         
>> <stdin>(2)f()
>>     
> (Pdb) ?
>
> Unfortunately there don't seem to be pdb tests so it's hard for us
> to say what works and doesn't yet.  Could you open a bug on this and
> that way it won't fall off our radar?
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Monday, July 27, 2009 8:35 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] pdb with IronPython 2.6 beta 2
>>
>> Hello all,
>>
>> I've been trying to use the pdb module with IronPython 2.6beta2 and the
>> interactive interpreter (with the -X:FullFrames command line option).
>> I've only used pdb with the set_trace function, but I couldn't get
>> *any*
>> of it to work in my brief exploration.
>>
>> I've posted my interactive session below in case anyone can point out
>> what I'm doing wrong:
>>
>> IronPython 2.6 Beta 2 (2.6.0.20) on .NET 2.0.50727.4016
>> Type "help", "copyright", "credits" or "license" for more information.
>>     
>>>>> import pdb
>>>>> def f():
>>>>>           
>> ...      a = 3
>> ...      pdb.set_trace()
>> ...
>>     
>>>>> f()
>>>>> print a
>>>>>           
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> NameError: name 'a' is not defined
>>     
>>>>> pdb.run('f()')
>>>>> def f():
>>>>>           
>> ...  a = 3
>> ...  foo
>> ...
>>     
>>>>> pdb.pm()
>>>>>           
>>> <stdin>(1)<module>()
>>>       
>> (Pdb) a
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 1232, in pm
>>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 1229, in
>> post_mortem
>>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 194, in
>> interaction
>>   File "C:\Program Files\IronPython 2.6\Lib\cmd.py", line 142, in
>> cmdloop
>>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 252, in
>> onecmd
>>   File "C:\Program Files\IronPython 2.6\Lib\cmd.py", line 219, in
>> onecmd
>>   File "C:\Program Files\IronPython 2.6\Lib\pdb.py", line 702, in
>> do_args
>> SystemError: Object reference not set to an instance of an object.
>>     
>> For the record I tried the same with CPython and it worked as expected:
>>
>> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
>> (Intel)] on
>> win32
>> Type "help", "copyright", "credits" or "license" for more information.
>>     
>>>>> import pdb
>>>>> def f():
>>>>>           
>> ...  a = 3
>> ...  pdb.set_trace()
>> ...
>>     
>>>>> f()
>>>>>           
>> --Return--
>>     
>>> <stdin>(3)f()->None
>>>       
>> (Pdb) a
>> (Pdb) print a
>> 3
>> (Pdb)
>>
>>  >>> def f():
>> ...  a = 6
>> ...  foo
>> ...
>>  >>> f()
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>>    File "<stdin>", line 3, in f
>> NameError: global name 'foo' is not defined
>>  >>> pdb.pm()
>>  > <stdin>(3)f()
>> (Pdb) a
>> (Pdb) print a
>> 6
>> (Pdb)
>>
>>
>>
>> All the best,
>>
>> Michael
>>
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From merllab at microsoft.com  Mon Jul 27 19:08:21 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Mon, 27 Jul 2009 10:08:21 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <d9554572-4053-4d5c-a574-c2b714cdd08e@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57254.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/BinaryExpression.Generated.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/BinaryExpression.Generated.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.Generated.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/DynamicMetaObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/CallInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/BinaryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/ExpandoObject.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/CallSiteBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/DynamicMetaObjectBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/CallSite.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/DictionaryGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonScriptCode.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/GlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/ArrayGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/SavableGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/RuntimeScriptCode.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/StaticGlobalAllocator.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_collections.cs
	$/IronPython/IronPython_Main/Config/Unsigned/App.config
	$/IronPython/IronPython_Main/Config/Signed/App.config
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Reversed.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaPythonType.Calls.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/BindingHelpers.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/PythonExceptions.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/StringOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonCalls.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Generator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/List.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Interfaces.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/XRange.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Set.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/TryStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ScopeStatement.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonOperator.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonNameBinder.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/PythonAst.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/GeneratorExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/Expression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ConstantExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/BinaryExpression.cs
	$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstGenerator.cs
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MethodCallExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/CompilerScope.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ExpressionVisitor.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberAssignment.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ListInitExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/GotoExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/DebugInfoGenerator.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/ILGen.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/TypeUtils.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/BoundConstants.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ConditionalExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ElementInit.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/Expression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/CatchBlock.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/DynamicExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberMemberBinding.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/LambdaExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/DebugInfoExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/NewExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/NewArrayExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/LoopExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/MemberListBinding.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/InvocationExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/IndexExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/TryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/UnaryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ConstantExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/BlockExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ParameterExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/TypeBinaryExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/SwitchExpression.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/ContractUtils.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/VariableBinder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.Logical.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LabelInfo.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Stubs.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/SymbolDocumentGenerator.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.Expressions.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/StackSpiller.Bindings.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/StackSpiller.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.Binary.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/Action.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/KeyedQueue.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.Unary.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/OffsetTrackingILGenerator.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Compiler/LambdaCompiler.Statements.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/DynamicInstructions.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightLambda.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/Function.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/ReadOnlyDictionary.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightLambda.Generated.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/ReadOnlyCollectionBuilder.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Ast/SkipInterpretExpression.cs
	$/IronPython/IronPython_Main/Src/Scripts/generate_calls.py
	$/IronPython/IronPython_Main/Src/Scripts/generate_dynamic_instructions.py
	$/IronPython/IronPython_Main/Src/Tests/test_class.py
	$/IronPython/IronPython_Main/Src/Scripts/generate_ops.py
	$/IronPython/IronPython_Main/Src/Scripts/generate_dynsites.py
	$/IronPython/IronPython_Main/Src/Tests/test_namebinding.py
	$/IronPython/IronPython_Main/Src/Tests/test_superconsole.py

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1020357
Date: 7/25/2009 2:43:53 PM

(dinov) Some targetted perf fixes
The changes fall into a few broad categories:
                Reducing code gen / improving one-off code gen performance:
                                This is partially just generating less code when we do our AST transform and reducing the cost of the code we do generate.  There?s some optimizations like using the right-size dynamic nodes to allocate smaller dynamic nodes, avoid / cheapen our creation of block nodes, moving some of our code that we generate into script codes (there?s more to be done here still), using ReadOnlyCollectionBuilder in a couple of spots where it?s an obvious win, avoid generating a return label + return for simple expressions ? instead just generate the expression, reduce indirection in creating generator expressions.

                                There?s also a name binding fix which improves performance of methods which contain eval/exec/etc?  along w/ some bug fixes to match CPython?s behavior.  Currently if a method includes import * or something which forces a locals directory we?ll turn var lookups into full runtime lookups.  CPython doesn?t do this so we look for a global where CPython throws a name error.  W/ the fix we can now always lookup in a local variable.

                                Also implemented a simple constant folder that supports ints/longs/doubles for all operators and strings for addition.  If eval code gets 100% constant folded we do no code gen.  

                Runtime improvements:
                                Generators:
                                                Cache the right sized data tuple so we don?t have to fish it out of the potentially larger MutableTuple.  
Move active to a real bool as we hit this flag repeatedly during generation iteration.  
Reduce to check to see if we need CanSetSysExcInfo to just one time through the generator loop.
Make generators non-finalizable.  Instead they allocate a finalizable object and re-cycle it back into a temporary when ...


(Shelveset: TargettedPerfFixesFinal;REDMOND\dinov | SNAP CheckinId: 9009)
--------------------------------------------------------------------------------
Changeset Id: 1018838
Date: 7/24/2009 12:09:33 PM

(dinov) 23555    2              High       Call incorrect __init__ when creating new instances        IronPython\2.6 dinov_cp
23564 an object's __del__ is not called unless its original type had a __del__ 

Currently when we generate the rule for calling a type we burn in a reference to __init__ and __del__ if the type defines it.  But that doesn?t work if the type looks like:

class x(object):
                def __new__(cls, toMake):
                                return object.__new__(toMake)

class subx(x):
                def __init__(self, *args):
                                print ?init?
                def __del__(self):
                                print ?del?

x(subx)

In this case we see that x has no init or del method and therefore we create a rule which will never call them.  But then __new__ turns around and returns a subtype of x which should have it?s __init__ method run.  

The fix is to create a 2nd dynamic site which specifically handles calling __new__ and creating the finalization registration code.  This dynamic site will do a type check against the type that?s actually getting created, lookup the appropriate __init__/__del__, and produce the correct rule.  The new custom binder also has pre-compiled rules for the common case to keep the recent optimization of pre-compiled rules for type creation.   We don?t use this site if the type doesn?t override __new__ (as long as the type doesn?t declare __del__ which we won?t optimize to keep things simple).

Also fixes a problem w/ AssemblyResolve event on .NET 4.0 by moving the try/catch to outside of where the method will be JITed



(Shelveset: FixInitDelFinal;REDMOND\dinov | SNAP CheckinId: 8999)


From dinov at microsoft.com  Mon Jul 27 19:41:56 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 27 Jul 2009 17:41:56 +0000
Subject: [IronPython] object lifecycle issues
In-Reply-To: <4A65B4FD.9070804@resolversystems.com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD03499908@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65B4FD.9070804@resolversystems.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035FE090@TK5EX14MBXC118.redmond.corp.microsoft.com>

Both the __init__ and __del__ issues are now fixed and pushed to CodePlex.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Tuesday, July 21, 2009 5:31 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] object lifecycle issues
>
> Hi Dino
>
> I don't *think* that's the case -- the stub has a __del__ method, that
> should never get called, purely to work around that bug (or possibly a
> subtly different one: I internally characterised it as "an object won't
> get __del__ed unless the type it was created as had a __del__ method,
> at the time it was created", which doesn't *quite* match your example).
> I guess it's one of the ones that never made it onto Codeplex... it's
> there now, at
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23564
>
> The repro for for issue #2 -- which requires current ironclad with
> appropriate logging -- is attached as x.py. The output, which you can
> see a bit further down, shows what happens when you construct-then-
> delete instances of various numpy data types. In short, the int8 and
> float32 dtypes don't include a CLR type among their immediate bases,
> and do get deleted correctly, while the int32 and
> float64 dtypes do and don't respectively.
>
> Anyway, I'll look into your earlier suggestions -- thank you very much!
>
> x.py output (after a lot of noise from the numpy import)
> ------------------------------------------------------------
> ========================================
>
> start <class 'numpy.int8'>
>
> real new1 <class 'numpy.int8'>
> fake new1 _ironclad_class_stub (<class 'numpy.signedinteger'>,) fake
> new2 (object) 2107 fake init <class 'unknown._ironclad_class_stub'>
> 2107 real new2 <class 'numpy.int8'> 2107
>
> constructed; id is 2107
>
> real del 2107
>
> finished <class 'numpy.int8'>
>
> ========================================
>
> start <class 'numpy.int32'>
>
> real new1 <class 'numpy.int32'>
> fake new1 _ironclad_class_stub (<class 'numpy.signedinteger'>, <type
> 'int'>) fake new2 (int) 2111 fake init <class
> 'unknown._ironclad_class_stub'> 2111 real new2 <class 'numpy.int32'>
> 2111
>
> constructed; id is 2111
>
>
> finished <class 'numpy.int32'>
>
> ========================================
>
> start <class 'numpy.float32'>
>
> real new1 <class 'numpy.float32'>
> fake new1 _ironclad_class_stub (<class 'numpy.floating'>,) fake new2
> (object) 2116 fake init <class 'unknown._ironclad_class_stub'> 2116
> real new2 <class 'numpy.float32'> 2116
>
> constructed; id is 2116
>
> real del 2116
>
> finished <class 'numpy.float32'>
>
> ========================================
>
> start <class 'numpy.float64'>
>
> real new1 <class 'numpy.float64'>
> fake new1 _ironclad_class_stub (<class 'numpy.floating'>, <type
> 'float'>) fake new2 (float) 2121 fake init <class
> 'unknown._ironclad_class_stub'> 2121 real new2 <class 'numpy.float64'>
> 2121
>
> constructed; id is 2121
>
>
> finished <class 'numpy.float64'>
> ------------------------------------------------------------
>
> ...and the internal logging is as follows:
>
> ------------------------------------------------------------
>         public const string CLASS_STUB_CODE = @"
> def __new__(cls, *args, **kwargs):
>     print 'fake new1', cls.__name__, cls.__bases__
>     if issubclass(cls, int):
>         result = int.__new__(cls, args[0])
>         print 'fake new2 (int)', id(result)
>         return result
>     if issubclass(cls, float):
>         result = float.__new__(cls, args[0])
>         print 'fake new2 (float)', id(result)
>         return result
>     result = object.__new__(cls)
>     print 'fake new2 (object)', id(result)
>     return result
>
> def __init__(self, *args, **kwargs):
>     print 'fake init', type(self), id(self)
>
> def __del__(self):
>     print 'fake del', id(self)
>
> def __setattr__(self, name, value):
>     object.__setattr__(self, name, value)
>
> _ironclad_class_stub = _ironclad_metaclass('_ironclad_class_stub',
> _ironclad_bases, {
>     '__new__': __new__,
>     '__init__': __init__,
>     '__del__': __del__,
>     '__setattr__': __setattr__,
> })
> ";
>
>         public const string CLASS_CODE = @"
> def __new__(cls, *args, **kwargs):
>     print 'real new1', cls
>     result = cls._dispatcher.newfunc('{0}.tp_new', cls, args, kwargs)
>     print 'real new2', cls, id(result)
>     return result
>
> def __del__(self):
>     print 'real del', id(self)
>     self._dispatcher.ic_destroy(self)
>
> _ironclad_class_attrs['__new__'] = __new__
> _ironclad_class_attrs['__del__'] = __del__
>
> _ironclad_class = _ironclad_metaclass('{0}', _ironclad_bases,
> _ironclad_class_attrs)
> _ironclad_class.__doc__ = '''{2}'''
> _ironclad_class.__module__ = '{1}'
> ";
> ------------------------------------------------------------
>
> ...while the code that actually constructs ipy objects around cpy
> objects looks like this:
>
> ------------------------------------------------------------
>
>         private void
>         ActualiseArbitraryObject(IntPtr ptr)
>         {
>             IntPtr typePtr = CPyMarshal.ReadPtrField(ptr,
> typeof(PyObject), "ob_type");
>             PythonType type_ = (PythonType)this.Retrieve(typePtr);
>
>             object[] args = new object[]{};
>             if (Builtin.issubclass(type_, TypeCache.Int32))
>             {
>                 args = new object[] { CPyMarshal.ReadIntField(ptr,
> typeof(PyIntObject), "ob_ival") };
>             }
>             if (Builtin.issubclass(type_, TypeCache.Double))
>             {
>                 args = new object[] { CPyMarshal.ReadDoubleField(ptr,
> typeof(PyFloatObject), "ob_fval") };
>             }
>             // ...
>
>             object obj = PythonCalls.Call(this.classStubs[typePtr],
> args);
>             Builtin.setattr(this.scratchContext, obj, "__class__",
> type_);
>             // ...
>         }
> ------------------------------------------------------------
>
> BTW: As it happens, the stub class is now a sibling of the real class
> rather than a subclass, because it feels cleaner. Regardless, the
> behaviour is identical in each case.
>
> Cheers
> william
>
> Dino Viehland wrote:
> > Could this be issue 2?
> >
> > class Real(object):
> >     def __new__(cls, *args, **kwargs):
> >         print 'real new'
> >         return object.__new__(Stub)
> >     #def __del__(self): pass     # uncomment me and this works as
> expected
> >
> > class Stub(Real):
> >     def __del__(self):
> >         print "I've been finalized"
> >
> > f = Real(1.0)
> > del f
> >
> > import sys
> > if sys.platform == 'clr':
> >     import clr
> >     from System import GC
> >     for _ in range(4):
> >         GC.Collect()
> >         GC.WaitForPendingFinalizers()
> >
> >
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of William Reade
> >> Sent: Monday, July 20, 2009 9:38 AM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] object lifecycle issues
> >>
> >> Hi all
> >>
> >> I have two problems that are at least somewhat related:
> >>
> >> +++ Issue 1 (probably your bug):
> >>
> >> ---------------------------------------------------------------
> >> C:\dev\ironclad - Copy>ipy y.py
> >> real new
> >> stub new
> >> real init
> >> real del
> >>
> >> C:\dev\ironclad - Copy>python y.py
> >> real new
> >> stub new
> >> stub init
> >> real del
> >> ---------------------------------------------------------------
> >>
> >> I freely admit that the attached code is pretty weird, but I really
> >> do need to do stuff like this in Ironclad. The difference in
> >> behaviour may or may not be responsible for certain failing
> >> numpy/scipy tests -- I'm not sure how to tell -- but I'd enormously
> appreciate a fix.
> >>
> >> I'd report the issue on Codeplex, but trying to visit the issue
> >> tracker just leaves my browser spinning forever. Speaking of which:
> >> is there any alternative way of reporting bugs that doesn't make me
> >> feel as if I'm spamming the list with out-of-band noise? I'm pretty
> >> sure that a few bugs have just dropped off my stack in the last few
> >> months, just because I got tired of waiting for Codeplex to start
> working.
> >>
> >> +++ Issue 2 (almost certainly my bug):
> >>
> >> In a nearly identical* situation -- close enough that I can't say
> how
> >> it's actually different -- f will never get its __del__ method
> called
> >> (the object is destroyed -- a WeakReference to it knows it's dead --
> >> but the __del__ call never happens).
> >>
> >> For context: I have *very* similar classes, whose instances are
> >> constructed in exactly the weird way demonstrated in the attached
> >> file, and which work fine. The only difference between the cases
> that
> >> work and the cases that don't is that the broken cases multiply
> >> inherit from ipy types which wrap CLR types (int and float (and
> maybe
> >> str, although I haven't tested that one)), while the working cases
> >> have simple chains of single inheritance from user-defined types all
> the way up to object.
> >> However, the attached repro doesn't show my problem, so it's clearly
> >> not
> >> *just* to do with multiply inheriting from CLR types.
> >>
> >> Does anyone have any idea what I might be doing wrong? I know this
> is
> >> a vague request, but I'm running out of ideas, and I'd really
> >> appreciate some input from someone who understands precisely what
> all
> >> those ipy MetaFoo classes are doing.
> >>
> >> Cheers
> >> william
> >>
> >>
> >> * the attached file started life as an attempt to repro the __del__
> >> issue, and I incidentally noticed the __init__ issue.
> >>
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> >



From dfugate at microsoft.com  Mon Jul 27 22:44:38 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Mon, 27 Jul 2009 20:44:38 +0000
Subject: [IronPython] Potentially changing the .NET requirement to build
	IronPython 2.6
In-Reply-To: <4B342496A3EFEB48839E10BB4BF5964C044A6D@TK5EX14MBXC131.redmond.corp.microsoft.com>
References: <7CEEC335D70FFE4B957737DDE836F51B021321@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<4B342496A3EFEB48839E10BB4BF5964C044A6D@TK5EX14MBXC131.redmond.corp.microsoft.com>
Message-ID: <7CEEC335D70FFE4B957737DDE836F51B02136F@TK5EX14MBXC123.redmond.corp.microsoft.com>

As it stands today, the .NET 3.5 version of msbuild (or Visual Studio 2008) is required to build IronPython 2.6 Beta 2 from sources.  One cannot build IronPython.sln from the latest beta of Visual Studio 2010 without irreversibly upgrading all C# project files to Visual Studio 2010.  We're hoping to change that...

.NET 3.5 Service Pack 1 introduced a new feature which allows one to build Visual Studio 2010 C# project files using .NET 3.5 SP1.  All we need to do take advantage of this is change the "ToolsVersion" attribute of C# project files from "3.5" to "4.0".  There's one unfortunate side effect we've discovered thus far - we can no longer build IronPython.sln with anything less than .NET 3.5 SP1 or Visual Studio 2008 SP1.

We understand it's a bit late in the IronPython 2.6 release cycle for this type of change, but feel it would provide a lot of value to those trying out Visual Studio 2010.  The question we have for everyone is does the benefit of being able to build IronPython under Visual Studio 2010 Betas outweigh the cost of no longer being able to build on .NET 3.5 without Service Pack 1 installed?  We'd love to hear any feedback you might have as this will strongly influence whatever decision we end up taking.

Thanks,

David Fugate
Microsoft - IronPython
http://knowbody.livejournal.com<http://knowbody.livejournal.com/>

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

From dinov at microsoft.com  Tue Jul 28 00:13:31 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 27 Jul 2009 22:13:31 +0000
Subject: [IronPython] IronPython ctypes on Linux
In-Reply-To: <5b0248170907250506o1f23d46bof2c7c4d8140d17b9@mail.gmail.com>
References: <5b0248170907250506o1f23d46bof2c7c4d8140d17b9@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035FF72D@TK5EX14MBXC118.redmond.corp.microsoft.com>

If we just aliased LoadLibrary to dlopen will that work?

My hope was that we could basically rely upon Mono's P/Invoke mapping
to handle running ctypes on Linux.  But maybe LoadLibrary/dlopen have
slightly different sigs and we need to handle that one specially.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon
> Sent: Saturday, July 25, 2009 5:07 AM
> To: Discussion of IronPython
> Subject: [IronPython] IronPython ctypes on Linux
>
> Hopefully I'm not too late on reporthing this...
>
> If you look at ctypes/__init__.py in Python 2.6, it imports different
> functions from _ctypes depending on os.name. So on Linux, it expects
> dlopen to be available, instead of LoadLibrary.
>
> --
> Seo Sanghyeon
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From slide.o.mix at gmail.com  Tue Jul 28 00:22:37 2009
From: slide.o.mix at gmail.com (Slide)
Date: Mon, 27 Jul 2009 15:22:37 -0700
Subject: [IronPython] IronPython ctypes on Linux
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD035FF72D@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <5b0248170907250506o1f23d46bof2c7c4d8140d17b9@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD035FF72D@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <a623f7d10907271522p507661c6g9384de59c5da6bbc@mail.gmail.com>

#include <dlfcn.h>

void *dlopen(const char *filename, int flag);

char *dlerror(void);

void *dlsym(void *handle, const char *symbol);

int dlclose(void *handle);

Not quite the same as LoadLibrary.

On Mon, Jul 27, 2009 at 3:13 PM, Dino Viehland<dinov at microsoft.com> wrote:
> If we just aliased LoadLibrary to dlopen will that work?
>
> My hope was that we could basically rely upon Mono's P/Invoke mapping
> to handle running ctypes on Linux. ?But maybe LoadLibrary/dlopen have
> slightly different sigs and we need to handle that one specially.
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon
>> Sent: Saturday, July 25, 2009 5:07 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] IronPython ctypes on Linux
>>
>> Hopefully I'm not too late on reporthing this...
>>
>> If you look at ctypes/__init__.py in Python 2.6, it imports different
>> functions from _ctypes depending on os.name. So on Linux, it expects
>> dlopen to be available, instead of LoadLibrary.
>>
>> --
>> 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
>



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


From dinov at microsoft.com  Tue Jul 28 00:36:19 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 27 Jul 2009 22:36:19 +0000
Subject: [IronPython] IronPython ctypes on Linux
In-Reply-To: <a623f7d10907271522p507661c6g9384de59c5da6bbc@mail.gmail.com>
References: <5b0248170907250506o1f23d46bof2c7c4d8140d17b9@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD035FF72D@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<a623f7d10907271522p507661c6g9384de59c5da6bbc@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD035FF7D9@TK5EX14MBXC118.redmond.corp.microsoft.com>

Is there one library name to rule them all on Linux, Mac OS/X, FreeBSD,
etc?  (either common on all the OSes or something coming from a Mono
mapping?)

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Slide
> Sent: Monday, July 27, 2009 3:23 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython ctypes on Linux
>
> #include <dlfcn.h>
>
> void *dlopen(const char *filename, int flag);
>
> char *dlerror(void);
>
> void *dlsym(void *handle, const char *symbol);
>
> int dlclose(void *handle);
>
> Not quite the same as LoadLibrary.
>
> On Mon, Jul 27, 2009 at 3:13 PM, Dino Viehland<dinov at microsoft.com>
> wrote:
> > If we just aliased LoadLibrary to dlopen will that work?
> >
> > My hope was that we could basically rely upon Mono's P/Invoke mapping
> > to handle running ctypes on Linux.  But maybe LoadLibrary/dlopen have
> > slightly different sigs and we need to handle that one specially.
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon
> >> Sent: Saturday, July 25, 2009 5:07 AM
> >> To: Discussion of IronPython
> >> Subject: [IronPython] IronPython ctypes on Linux
> >>
> >> Hopefully I'm not too late on reporthing this...
> >>
> >> If you look at ctypes/__init__.py in Python 2.6, it imports
> different
> >> functions from _ctypes depending on os.name. So on Linux, it expects
> >> dlopen to be available, instead of LoadLibrary.
> >>
> >> --
> >> 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
> >
>
>
>
> --
> slide-o-blog
> http://slide-o-blog.blogspot.com/
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Tue Jul 28 01:45:56 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 27 Jul 2009 23:45:56 +0000
Subject: [IronPython] sympy on IP 2.6B2
In-Reply-To: <001801ca0e2d$59dd4130$0d97c390$@com>
References: <4A649D5B.1020807@resolversystems.com>
	<1A472770E042064698CB5ADC83A12ACD034981FA@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<4A65EAA8.4000909@resolversystems.com>	<007401ca0c9f$6e4c54b0$4ae4fe10$@com>
	<4A6A1DD7.50602@voidspace.org.uk>
	<1A472770E042064698CB5ADC83A12ACD03562FE2@TK5EX14MBXC116.redmond.corp.microsoft.com>
	<001801ca0e2d$59dd4130$0d97c390$@com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD03601293@TK5EX14MBXC118.redmond.corp.microsoft.com>

Jeffrey wrote:
> 1. Performance

The bulk of this problem comes from basic.py line 804 where a closure
function is called w/ keyword argument.  Passing the argument as a
positional argument causes us to be 6-7x slower instead of 50x. This
is probably a small perf gain on CPython as well so it's probably
a good change for Sympy in general.  We may come back and optimize
this but probably not for 2.6.

Some other small changes get us a little under 2x times slower than
CPython and then it starts getting hard to get faster.

> 2. Problem with '*' (splat operator)

This looks like a general problem w/ several different types of calls -
I've opened a bug:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24031





From redmoon17 at gmail.com  Tue Jul 28 15:15:41 2009
From: redmoon17 at gmail.com (Kevin Zhu)
Date: Tue, 28 Jul 2009 06:15:41 -0700 (PDT)
Subject: [IronPython] Invitation to connect on LinkedIn
Message-ID: <2066460427.2573205.1248786941509.JavaMail.app@ech3-cdn10.prod>

LinkedIn
------------

Kevin Zhu requested to add you as a connection on LinkedIn:
------------------------------------------

Andrei,

I'd like to add you to my professional network on LinkedIn.

- Kevin

View invitation from Kevin Zhu
http://www.linkedin.com/e/EazlH1iXyR8SQ1lnS0CWuKqUyNsIQnOwSeMMjurv/blk/I1327186238_2/39ve3cOdzwNdP8PckALqnpPbOYWrSlI/svi/


 
------
(c) 2009, LinkedIn Corporation

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

From merllab at microsoft.com  Tue Jul 28 17:55:25 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Tue, 28 Jul 2009 08:55:25 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <fe7e6624-beea-444c-8ae1-e76ed1a34d0e@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57298.

ADDED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/IConvertibleMetaObject.cs

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/IConvertibleMetaObject.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonOverloadResolver.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Actions/Calls/OverloadResolver.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/Shell/ConsoleHost.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/MetaPythonFunction.cs
	$/IronPython/IronPython_Main/Src/Tests/test_methodbinder2.py
	$/IronPython/IronPython_Main/Src/IronPythonTest/BinderTest.cs
	$/IronPython/IronPython_Main/Src/IronPythonConsole/Console.cs





From bruce.bromberek at gmail.com  Tue Jul 28 18:03:02 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Tue, 28 Jul 2009 11:03:02 -0500
Subject: [IronPython] Potentially changing the .NET requirement to build
	IronPython 2.6
In-Reply-To: <7CEEC335D70FFE4B957737DDE836F51B02136F@TK5EX14MBXC123.redmond.corp.microsoft.com>
References: <7CEEC335D70FFE4B957737DDE836F51B021321@TK5EX14MBXC123.redmond.corp.microsoft.com>
	<4B342496A3EFEB48839E10BB4BF5964C044A6D@TK5EX14MBXC131.redmond.corp.microsoft.com>
	<7CEEC335D70FFE4B957737DDE836F51B02136F@TK5EX14MBXC123.redmond.corp.microsoft.com>
Message-ID: <58ad4a110907280903g652ae713k16058debfd9a7188@mail.gmail.com>

If I understand the issue correctly, the options to build IronPython from
source are

1) Build with VS 2010 Beta and/OR Build with VS 2008 SP1 and .NET 3.5 SP1
2) Build with VS 2008 and .NET 3.5

I vote for option 1

On Mon, Jul 27, 2009 at 3:44 PM, Dave Fugate <dfugate at microsoft.com> wrote:

>  As it stands today, the .NET 3.5 version of msbuild (or Visual Studio
> 2008) is required to build IronPython 2.6 Beta 2 from sources.  One cannot
> build IronPython.sln from the latest beta of Visual Studio 2010 without
> irreversibly upgrading all C# project files to Visual Studio 2010.  We?re
> hoping to change that?
>
>
>
> .NET 3.5 *Service Pack 1* introduced a new feature which allows one to
> build Visual Studio 2010 C# project files using .NET 3.5 SP1.  All we need
> to do take advantage of this is change the ?ToolsVersion? attribute of C#
> project files from ?3.5? to ?4.0?.  There?s one unfortunate side effect
> we?ve discovered thus far ? we can no longer build IronPython.sln with
> anything less than .NET 3.5 *SP1* or Visual Studio 2008 *SP1*.
>
>
>
> We understand it?s a bit late in the IronPython 2.6 release cycle for this
> type of change, but feel it would provide a lot of value to those trying out
> Visual Studio 2010.  The question we have for everyone is does the benefit
> of being able to build IronPython under Visual Studio 2010 Betas outweigh
> the cost of no longer being able to build on .NET 3.5 without Service Pack 1
> installed?  We?d love to hear any feedback you might have as this will
> strongly influence whatever decision we end up taking.
>
>
>
> Thanks,
>
>
>
> David Fugate
>
> Microsoft - IronPython
>
> http://knowbody.livejournal.com
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090728/626807f6/attachment.html>

From ivan at flanders.co.nz  Tue Jul 28 21:49:11 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Tue, 28 Jul 2009 21:49:11 +0200
Subject: [IronPython] mono package
Message-ID: <b1c6aabb0907281249o15a830dcj5c123c81c7ce19b1@mail.gmail.com>

Hi guys
As I'm creating a nightly build package for ironruby, I can do the same for
ironpython. (mono build package that is :))
For Ruby we have to include a bunch of scripts as standard library, does
ironpython also have those scripts? If so where can I find them in the
github repository of ironruby?

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090728/ad8d47c6/attachment.html>

From Jimmy.Schementi at microsoft.com  Wed Jul 29 00:51:18 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 28 Jul 2009 22:51:18 +0000
Subject: [IronPython] mono package
In-Reply-To: <b1c6aabb0907281249o15a830dcj5c123c81c7ce19b1@mail.gmail.com>
References: <b1c6aabb0907281249o15a830dcj5c123c81c7ce19b1@mail.gmail.com>
Message-ID: <0047ECBFA2E0DF4A834AA369282A5AFC19B9B22B@tk5ex14mbxc106.redmond.corp.microsoft.com>

Just a few in Merlin/Main/Languages/IronPython/IronPython/Lib<http://github.com/ironruby/ironruby/tree/bb1c90fa69cd1375db456a57e44bc45e12139416/Merlin/Main/Languages/IronPython/IronPython/Lib>. That directory should be copied to the build directory after building though ... (that probably doesn't happen with "rake compile", but it should).

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ivan Porto Carrero
Sent: Tuesday, July 28, 2009 12:49 PM
To: Discussion? of? IronPython?
Subject: [IronPython] mono package

Hi guys

As I'm creating a nightly build package for ironruby, I can do the same for ironpython. (mono build package that is :))
For Ruby we have to include a bunch of scripts as standard library, does ironpython also have those scripts? If so where can I find them in the github repository of ironruby?

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090728/935088bf/attachment.html>

From ivan at flanders.co.nz  Wed Jul 29 14:29:45 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Wed, 29 Jul 2009 14:29:45 +0200
Subject: [IronPython] mono packages for ironpython
Message-ID: <b1c6aabb0907290529y52bf5799rff6f4b89cb621819@mail.gmail.com>

Hi
I've added the ironpython mono package to the ironruby mono CI server. It is
slightly different from the windows package it doesn't have the licenses
included nor does it have the 64bit builds and the pyc.py file.  The
tutorial is also not in the github repository so I couldn't include that
either.

you can download the packages here: http://ironruby.colliertech.org/
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090729/8bdfa090/attachment.html>

From kf9150 at gmail.com  Wed Jul 29 19:51:31 2009
From: kf9150 at gmail.com (Kelie)
Date: Wed, 29 Jul 2009 10:51:31 -0700 (PDT)
Subject: [IronPython] SQLite
Message-ID: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>

Hello,

Is SQLite currently supported in IronPython? If not, is SQLite .NET
from http://sqlite.phxsoftware.com/ the best alternative?

Thanks.


From brian.curtin at gmail.com  Wed Jul 29 20:03:36 2009
From: brian.curtin at gmail.com (Brian Curtin)
Date: Wed, 29 Jul 2009 13:03:36 -0500
Subject: [IronPython] SQLite
In-Reply-To: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
References: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
Message-ID: <cf9f31f20907291103m63008b7fh89ed867ddf451077@mail.gmail.com>

On Wed, Jul 29, 2009 at 12:51, Kelie <kf9150 at gmail.com> wrote:

> Hello,
>
> Is SQLite currently supported in IronPython? If not, is SQLite .NET
> from http://sqlite.phxsoftware.com/ the best alternative?
>
> Thanks.


sqlite3 is implemented as a C extension, and as such, does not currently
work.

I've used the library you linked to in a C# application before and it worked
fine for me. I would imagine the same would be true of it in IronPython.
Give it a shot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090729/f47d24bc/attachment.html>

From Harry.Pierson at microsoft.com  Wed Jul 29 20:19:31 2009
From: Harry.Pierson at microsoft.com (Harry Pierson)
Date: Wed, 29 Jul 2009 18:19:31 +0000
Subject: [IronPython] SQLite
In-Reply-To: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
References: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
Message-ID: <6B5AE3B08809CC47A81ACBF99E2690F514A4A9B2@tk5ex14mbxc106.redmond.corp.microsoft.com>

We don't support the CPython sqlite3 module, but I would expect the System.Data.SQLite DLL to work with IronPython. I imagine it would be possible to build a sqlite3 compatible wrapper around System.Data.SQLite, but I don't know if anyone has done that.

Harry

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kelie
Sent: Wednesday, July 29, 2009 10:52 AM
To: users at lists.ironpython.com
Subject: [IronPython] SQLite

Hello,

Is SQLite currently supported in IronPython? If not, is SQLite .NET
from http://sqlite.phxsoftware.com/ the best alternative?

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



From bruce.bromberek at gmail.com  Wed Jul 29 23:04:59 2009
From: bruce.bromberek at gmail.com (Bruce Bromberek)
Date: Wed, 29 Jul 2009 16:04:59 -0500
Subject: [IronPython] SQLite
In-Reply-To: <6B5AE3B08809CC47A81ACBF99E2690F514A4A9B2@tk5ex14mbxc106.redmond.corp.microsoft.com>
References: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
	<6B5AE3B08809CC47A81ACBF99E2690F514A4A9B2@tk5ex14mbxc106.redmond.corp.microsoft.com>
Message-ID: <58ad4a110907291404k46d5452fra67dff03e4346e75@mail.gmail.com>

In Cpython I use SQLite, in Iron Python I've taken to using SQL Server
Compact Edition.  But then again I am only writing for the windows platform.

On Wed, Jul 29, 2009 at 1:19 PM, Harry Pierson
<Harry.Pierson at microsoft.com>wrote:

> We don't support the CPython sqlite3 module, but I would expect the
> System.Data.SQLite DLL to work with IronPython. I imagine it would be
> possible to build a sqlite3 compatible wrapper around System.Data.SQLite,
> but I don't know if anyone has done that.
>
> Harry
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] On Behalf Of Kelie
> Sent: Wednesday, July 29, 2009 10:52 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] SQLite
>
> Hello,
>
> Is SQLite currently supported in IronPython? If not, is SQLite .NET
> from http://sqlite.phxsoftware.com/ the best alternative?
>
> Thanks.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090729/1de88e92/attachment.html>

From empirebuilder at gmail.com  Wed Jul 29 23:54:30 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Thu, 30 Jul 2009 00:54:30 +0300
Subject: [IronPython] SQLite
In-Reply-To: <58ad4a110907291404k46d5452fra67dff03e4346e75@mail.gmail.com>
References: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
	<6B5AE3B08809CC47A81ACBF99E2690F514A4A9B2@tk5ex14mbxc106.redmond.corp.microsoft.com>
	<58ad4a110907291404k46d5452fra67dff03e4346e75@mail.gmail.com>
Message-ID: <8cd017b80907291454n51837716q1412f896e666a031@mail.gmail.com>

If not, is SQLite .NET
from http://sqlite.phxsoftware.com/ the best alternative?
Yes. That library is solid. I have used them in productions.

On Thu, Jul 30, 2009 at 12:04 AM, Bruce Bromberek <bruce.bromberek at gmail.com
> wrote:

> In Cpython I use SQLite, in Iron Python I've taken to using SQL Server
> Compact Edition.  But then again I am only writing for the windows platform.
>
>
> On Wed, Jul 29, 2009 at 1:19 PM, Harry Pierson <
> Harry.Pierson at microsoft.com> wrote:
>
>> We don't support the CPython sqlite3 module, but I would expect the
>> System.Data.SQLite DLL to work with IronPython. I imagine it would be
>> possible to build a sqlite3 compatible wrapper around System.Data.SQLite,
>> but I don't know if anyone has done that.
>>
>> Harry
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:
>> users-bounces at lists.ironpython.com] On Behalf Of Kelie
>> Sent: Wednesday, July 29, 2009 10:52 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] SQLite
>>
>> Hello,
>>
>> Is SQLite currently supported in IronPython? If not, is SQLite .NET
>> from http://sqlite.phxsoftware.com/ the best alternative?
>>
>> Thanks.
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


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

From Tomas.Matousek at microsoft.com  Thu Jul 30 01:29:36 2009
From: Tomas.Matousek at microsoft.com (Tomas Matousek)
Date: Wed, 29 Jul 2009 23:29:36 +0000
Subject: [IronPython] Project versions updated to 2010
Message-ID: <4B342496A3EFEB48839E10BB4BF5964C059D12@TK5EX14MBXC129.redmond.corp.microsoft.com>

We have just updated ToolsVersion attribute in .csproj files included in IronPython and IronRuby solutions to "4.0". This change will soon show up in CodePlex and GIT sources.

It allows to open these projects in Visual Studio 2010 (using IronPython4.sln or Ruby4.sln). The binaries produced by both builds (from VS2008 and VS2010) still have dependency only on .NET 2.0 assemblies so there is no change in that.

You'll need Service Pack 1 installed in order to build Ruby.sln or IronPython.sln from VS2008. When you build from VS2008 you'll get a bunch of msbuild warnings:

Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".

This is expected, you can ignore them.

Thanks,
Tomas




From jdhardy at gmail.com  Thu Jul 30 02:27:05 2009
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 29 Jul 2009 18:27:05 -0600
Subject: [IronPython] SQLite
In-Reply-To: <6B5AE3B08809CC47A81ACBF99E2690F514A4A9B2@tk5ex14mbxc106.redmond.corp.microsoft.com>
References: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
	<6B5AE3B08809CC47A81ACBF99E2690F514A4A9B2@tk5ex14mbxc106.redmond.corp.microsoft.com>
Message-ID: <ea89d0e50907291727ud026df1n1c848a2a8b7609f5@mail.gmail.com>

On Wed, Jul 29, 2009 at 12:19 PM, Harry
Pierson<Harry.Pierson at microsoft.com> wrote:
> We don't support the CPython sqlite3 module, but I would expect the System.Data.SQLite DLL to work with IronPython. I imagine it would be possible to build a sqlite3 compatible wrapper around System.Data.SQLite, but I don't know if anyone has done that.

You had to ask? :)

There's one available as part of FePy (http://fepy.sourceforge.net/)
or my adonet-dbapi
project(http://bitbucket.org/jdhardy/adonet-dbapi/), which is just a
fork of FePy anyway. It implements almost all of the Python sqlite
module, except for custom functions.

It depends on System.Data.SQLite (http://sqlite.phxsoftware.com/).

- Jeff


From sanxiyn at gmail.com  Thu Jul 30 02:59:06 2009
From: sanxiyn at gmail.com (Seo Sanghyeon)
Date: Thu, 30 Jul 2009 09:59:06 +0900
Subject: [IronPython] SQLite
In-Reply-To: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
References: <60fd1f09-fefe-4f02-b41b-60a09d0c4fb9@p10g2000prm.googlegroups.com>
Message-ID: <5b0248170907291759i3d1f231dr7b0bf608ee325c3f@mail.gmail.com>

2009/7/30 Kelie <kf9150 at gmail.com>:
> Is SQLite currently supported in IronPython? If not, is SQLite .NET
> from http://sqlite.phxsoftware.com/ the best alternative?

Seems so. Others have replied about this.

One alternative was not mentioned in this thread. That is, CPython's
SQLite module('s upstream), pysqlite, has been ported to ctypes
FFI in the past. Now IronPython has ctypes, in theory, this pure Python
version should work without modification.

I don't think it will work without modification :) but it certainly would
be a great stress test for IronPython's new ctypes implementation.

-- 
Seo Sanghyeon


From merllab at microsoft.com  Thu Jul 30 17:53:34 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Thu, 30 Jul 2009 08:53:34 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <c43c71a6-a3bf-45b7-a71d-2631fdceaae0@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57368.

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/IronPythonConsoleAny/IronPythonConsoleAny.csproj
	$/IronPython/IronPython_Main/Src/IronPythonWindowAny/IronPythonWindowAny.csproj
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_fileio.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/Microsoft.Scripting.Debugging.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.Core.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.ExtensionAttribute.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/ComInterop/ComTypeLibDesc.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Microsoft.Scripting.Silverlight.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/ReflectionUtils.cs
	$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Chiron.csproj
	$/IronPython/IronPython_Main/Src/Tests/interop/net/field/test_fields_inside_enum.py
	$/IronPython/IronPython_Main/Src/Tests/interop/net/field/test_literal_fields.py
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/NewStringFormatter.cs
	$/IronPython/IronPython_Main/Src/Tests/test_strformat.py
	$/IronPython/IronPython_Main/Src/Tests/regressions.py
	$/IronPython/IronPython_Main/Src/IronPython.Modules/_struct.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Descriptors.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/TypeInfo.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/ModuleDictionaryStorage.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonDictionary.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonTypeOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/ObjectOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/IntOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/FloatOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/LongOps.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/List.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonFile.cs
	$/IronPython/IronPython_Main/Src/IronPython/Runtime/Set.cs
	$/IronPython/IronPython_Main/Src/Tests/test_str.py
	$/IronPython/IronPython_Main/Src/IronPythonWindow/IronPythonWindow.csproj
	$/IronPython/IronPython_Main/Src/IronPythonTest/IronPythonTest.csproj
	$/IronPython/IronPython_Main/Src/IronPythonConsole/IronPythonConsole.csproj
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IterTools.cs
	$/IronPython/IronPython_Main/Src/IronPython.Modules/IronPython.Modules.csproj
	$/IronPython/IronPython_Main/Src/Tests/test_cliclass.py
	$/IronPython/IronPython_Main/Src/IronPython.Modules/cPickle.cs
	$/IronPython/IronPython_Main/Tutorial/Tutorial.htm
	$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1028264
Date: 7/29/2009 5:58:54 PM

(dinov) Updates the standard library to CPython?s SVN 74168 and fixes issues in IronPython related to the upgrade.  

There is 1 change which I have not accepted from the std lib ? that is a re-ordering of some attribute lookups in inspect which cause the doc tests to start working again.  I?ve opened a bug that we need to fix the dictionary we return for globals from a function.

IronPython changes include:
                Updating IterTools to support an int val > than the iterable count for permutations/combinations/product
                Adding a fd overload to _fileio and setting the resulting mode to the ?correct? value not the value the user passed in
                Updating file exceptions to include the file name (both file and _fileio)
                Updating struct marshalling so that when you pass a negative value for the unsigned int/long types that it warns and preserves the negative value in bits (previously it converted to 0)
                Fixing the recursive tuple case in CPickle
                Fixing __doc__ for subclasses of property
                Assigning None to __hash__ for List/Dict/Set ? this includes making literal/const fields show up in the type?s dictionaries as the literal instead of a ReflectedField object and a bunch of updates to IronPython tests
                Fixing the count property on built-in modules (we need to populate all of the items to get the count)
                Fixing new string formatting when you attempt to pull out a value and that value is None.
                Report the actual non-frozen set when doing set.remove(someSet) instead of the frozen set.
                Subclasses of Unicode and str should both call __float__ when doing float(someStr)
                Fixing repr of floats ? currently we can produce a value that does not successfully round trip
                Changing some string formatting error messages that CPython tests for and has changed
                Reduce protocol 0 could get an ...



(Shelveset: UpdateStdLibFinal2;REDMOND\dinov | SNAP CheckinId: 9033)


From rafael2pop at yahoo.com.ar  Thu Jul 30 19:08:44 2009
From: rafael2pop at yahoo.com.ar (rafael2pop)
Date: Thu, 30 Jul 2009 10:08:44 -0700 (PDT)
Subject: [IronPython] mis primeras preguntas.
Message-ID: <298328.85144.qm@web59202.mail.re1.yahoo.com>


Hola a todos en la lista.


Encontr? casualmente un blog de KZU y me interes? por herramientas para Python

Tengo Python en ambos OSes: Vista Basic en la notebook y Ubuntu64 en un desktop ambos con 2GB de ram.

Espero que tomen mis primeras preguntas como un 'newbie' en Python.

Lo tengo instalado como wxPython por ahora, ya desinstal? todo lo que fuera IDE.

Me falta probar el plugin Python para Netbeans solamente, idea que encontr? 'gugleando'.

PREGUNTA 1.

Existe alguna versi?n en MS alternativa a la licencia comercial ?

Recuerdo la opci?n NFR.

Pasa que hasta el 2001 fui parte del canal que por entonces se llamaba
MS Direct Acess y recuerdo haber adquirido en 200 d?lares (pesos-d?lares) BackOffice (not for resale).

No quiero pedir ninguna circumvexi?n, solamente informaci?n acerca de si puede existir alguna promo, para adquirir las herramientas.

IMHO la IDE de Aptana me gusta mas que la de Eclipse (org), pero ambas son s?lo IDEs y presumo que IronPython , podr?a ser MDA , mis disculpas por escribir apurado y no tomarme  m?s tiempo para buscar m?s especificaciones


Esto viene a relaci?n de haber le?do acerca de los pre-requisitos de IronPython:
 
    * Visual Studio 2008 (Professional / Team Suite)
    * Visual Studio 2008 SDK 1.0

Leyendo eso asum? que con VS Express no alcanza.




PREGUNTA 2

El c?digo python que genera es propio de cada plataforma (si generara ASCII) ?


Para el caso compilar, supongo que precisar?a de MONO (caso de nix) para portarlo a la nube (por razones de costo del hosting para el caso que no sea .NET, si es que asi podr?a llegar a funcionar en la pr?ctica, en base a la relaci?n costo/resultado ( o ROI como dicen los business technlogists)

Doy por sentado que comprar? el producto, tarde o temprano.

No obstante si antes, tienen alguna sugerencia , son bienvenidas

Me pregunto si las cajas VS se pueden comprar afuera (con COA y en sitios reconocidos)

Siempre est? presente con el riesg/correo, que hasta ahora toco madera ha entregado el 95% de los env?os, lo que no es poca cosa al menos en ARG.


Un saludo cordial.


Rafael





      ____________________________________________________________________________________
?Viv? la mejor experiencia en la web!
Descarg? gratis el nuevo Internet Explorer 8
http://downloads.yahoo.com/ieak8/?l=ar


From dfugate at microsoft.com  Thu Jul 30 19:17:51 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Thu, 30 Jul 2009 17:17:51 +0000
Subject: [IronPython] mis primeras preguntas.
In-Reply-To: <298328.85144.qm@web59202.mail.re1.yahoo.com>
References: <298328.85144.qm@web59202.mail.re1.yahoo.com>
Message-ID: <7CEEC335D70FFE4B957737DDE836F51B04B1B3@TK5EX14MBXC123.redmond.corp.microsoft.com>

Hola, el unico requisito para IronPython 2.0 o 2.6 es. NET 2.0 SP1, pero no hay apoyo Python en la Visual Studio.

Gracis,

Dave

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of rafael2pop
Sent: Thursday, July 30, 2009 10:09 AM
To: users at lists.ironpython.com
Subject: [IronPython] mis primeras preguntas.


Hola a todos en la lista.


Encontr? casualmente un blog de KZU y me interes? por herramientas para Python

Tengo Python en ambos OSes: Vista Basic en la notebook y Ubuntu64 en un desktop ambos con 2GB de ram.

Espero que tomen mis primeras preguntas como un 'newbie' en Python.

Lo tengo instalado como wxPython por ahora, ya desinstal? todo lo que fuera IDE.

Me falta probar el plugin Python para Netbeans solamente, idea que encontr? 'gugleando'.

PREGUNTA 1.

Existe alguna versi?n en MS alternativa a la licencia comercial ?

Recuerdo la opci?n NFR.

Pasa que hasta el 2001 fui parte del canal que por entonces se llamaba
MS Direct Acess y recuerdo haber adquirido en 200 d?lares (pesos-d?lares) BackOffice (not for resale).

No quiero pedir ninguna circumvexi?n, solamente informaci?n acerca de si puede existir alguna promo, para adquirir las herramientas.

IMHO la IDE de Aptana me gusta mas que la de Eclipse (org), pero ambas son s?lo IDEs y presumo que IronPython , podr?a ser MDA , mis disculpas por escribir apurado y no tomarme  m?s tiempo para buscar m?s especificaciones


Esto viene a relaci?n de haber le?do acerca de los pre-requisitos de IronPython:

    * Visual Studio 2008 (Professional / Team Suite)
    * Visual Studio 2008 SDK 1.0

Leyendo eso asum? que con VS Express no alcanza.




PREGUNTA 2

El c?digo python que genera es propio de cada plataforma (si generara ASCII) ?


Para el caso compilar, supongo que precisar?a de MONO (caso de nix) para portarlo a la nube (por razones de costo del hosting para el caso que no sea .NET, si es que asi podr?a llegar a funcionar en la pr?ctica, en base a la relaci?n costo/resultado ( o ROI como dicen los business technlogists)

Doy por sentado que comprar? el producto, tarde o temprano.

No obstante si antes, tienen alguna sugerencia , son bienvenidas

Me pregunto si las cajas VS se pueden comprar afuera (con COA y en sitios reconocidos)

Siempre est? presente con el riesg/correo, que hasta ahora toco madera ha entregado el 95% de los env?os, lo que no es poca cosa al menos en ARG.


Un saludo cordial.


Rafael





      ____________________________________________________________________________________
?Viv? la mejor experiencia en la web!
Descarg? gratis el nuevo Internet Explorer 8
http://downloads.yahoo.com/ieak8/?l=ar
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From fuzzyman at voidspace.org.uk  Thu Jul 30 23:58:11 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 30 Jul 2009 22:58:11 +0100
Subject: [IronPython] Interested in IronPython integration in Visual Studio
	2010?
Message-ID: <4A721773.9010209@voidspace.org.uk>

If you'd like to see IronPython integration in Visual Studio 2010 
perhaps you could rate / comment on this Microsoft Connect issue:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=475830&wa=wsignin1.0

All the best,

Michael Foord

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




From pavel.suhotjuk at gmail.com  Fri Jul 31 10:11:53 2009
From: pavel.suhotjuk at gmail.com (Pavel Suhotyuk)
Date: Fri, 31 Jul 2009 11:11:53 +0300
Subject: [IronPython] turn on -X:Frames option in DLR
Message-ID: <4A72A749.3060004@gmail.com>

Hello.

I need to use "inspect" module, that require sys._getframe() function. 
But I'm use embedded IPY through calling:

var engine = Python.CreateEngine();
ScriptSource py = engine.CreateScriptSourceFromFile(fileName);
CompiledCode code = py.Compile();
code.Execute();

At this point for ScriptScope in 'code' object not available 
sys._getframe() function. In console this resolved by -X:Frames option.

How I can enable this option for embedded Engine?

--
Best regards,
  Suhotjuk Pavel Sergeevich


From curt at hagenlocher.org  Fri Jul 31 14:09:33 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Fri, 31 Jul 2009 05:09:33 -0700
Subject: [IronPython] turn on -X:Frames option in DLR
In-Reply-To: <4A72A749.3060004@gmail.com>
References: <4A72A749.3060004@gmail.com>
Message-ID: <d2155e360907310509r771e2165qd2818f25f30fc313@mail.gmail.com>

var opts = new Dictionary<string, object>();
opts["Frames"] = ScriptingRuntimeHelpers.True;
var engine = Python.CreateEngine(opts);


On Fri, Jul 31, 2009 at 1:11 AM, Pavel Suhotyuk <pavel.suhotjuk at gmail.com>wrote:

> Hello.
>
> I need to use "inspect" module, that require sys._getframe() function. But
> I'm use embedded IPY through calling:
>
> var engine = Python.CreateEngine();
> ScriptSource py = engine.CreateScriptSourceFromFile(fileName);
> CompiledCode code = py.Compile();
> code.Execute();
>
> At this point for ScriptScope in 'code' object not available
> sys._getframe() function. In console this resolved by -X:Frames option.
>
> How I can enable this option for embedded Engine?
>
> --
> Best regards,
>  Suhotjuk Pavel Sergeevich
> _______________________________________________
> 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/20090731/f0a0a875/attachment.html>

From pavel.suhotjuk at gmail.com  Fri Jul 31 14:16:22 2009
From: pavel.suhotjuk at gmail.com (Pavel Suhotyuk)
Date: Fri, 31 Jul 2009 15:16:22 +0300
Subject: [IronPython] turn on -X:Frames option in DLR
In-Reply-To: <d2155e360907310509r771e2165qd2818f25f30fc313@mail.gmail.com>
References: <4A72A749.3060004@gmail.com>
	<d2155e360907310509r771e2165qd2818f25f30fc313@mail.gmail.com>
Message-ID: <4A72E096.4050201@gmail.com>

It works. Thank you.
Curt Hagenlocher wrote:
> var opts = new Dictionary<string, object>();
> opts["Frames"] = ScriptingRuntimeHelpers.True;
> var engine = Python.CreateEngine(opts);
> 
> 
> On Fri, Jul 31, 2009 at 1:11 AM, Pavel Suhotyuk 
> <pavel.suhotjuk at gmail.com <mailto:pavel.suhotjuk at gmail.com>> wrote:
> 
>     Hello.
> 
>     I need to use "inspect" module, that require sys._getframe()
>     function. But I'm use embedded IPY through calling:
> 
>     var engine = Python.CreateEngine();
>     ScriptSource py = engine.CreateScriptSourceFromFile(fileName);
>     CompiledCode code = py.Compile();
>     code.Execute();
> 
>     At this point for ScriptScope in 'code' object not available
>     sys._getframe() function. In console this resolved by -X:Frames option.
> 
>     How I can enable this option for embedded Engine?
> 
>     --
>     Best regards,
>      Suhotjuk Pavel Sergeevich
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>     http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From merllab at microsoft.com  Fri Jul 31 17:53:42 2009
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Fri, 31 Jul 2009 08:53:42 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <2346876c-2919-4dd0-ae5c-57ccf064b3bf@tk5-exsmh-c101.redmond.corp.microsoft.com>

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/57436.

MODIFIED SOURCES
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/ScriptRuntime.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/DlrConfiguration.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/ReflectionUtils.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/PlatformAdaptationLayer.cs
	$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Utils/CollectionUtils.cs
	$/IronPython/IronPython_Main/Tutorial/Tutorial.htm

CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1030992
Date: 7/30/2009 1:43:44 PM

(dfugate) Fixed a couple of major problems with the IronPython Tutorial:
- .NET 2.0 SP1 is required, not .NET 2.0
- The link for WPF was to a beta released years ago that has since been removed
In general, the tutorial really needs to be examined with a fine toothed comb to pick out problems like these before 2.6 RC 1.


(Shelveset: TUT;REDMOND\dfugate | SNAP CheckinId: 9038)