hanks,
Rob Oakes
__ Information from ESET NOD32 Antivirus, version of virus signature
database 3655 (20081201) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
Users mailing list
Users@lists.ironpython.com
http://
On Mon, Dec 1, 2008 at 12:26 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Thanks for reporting & opening the bug. The fix for this is likely fairly
> easy but I don't think we'd spin a new 2.0 build for just this issue because
> it isn't really blocking anything as you have a work around.
>
>
Correction: the AppManifest.xaml is only for assemblies you want to load when
the application starts. Doing clr.AddReference will currently look in the XAP
and load the assembly at any time in the program's execution, without needing
to have it listed in the AppManifest.xaml.
> -Original Me
You would face this issue even if you used the assembly from C#.
Silverlight has a subset of the .NET framework, so like Curt said, it might be
as simple as recompiling, or as hard as changing the code to not depend on
missing APIs.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf O
This is awesome! Thanks for looking into this.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:users-
> [EMAIL PROTECTED] On Behalf Of Dan Eloff
> Sent: Tuesday, November 25, 2008 3:55 PM
> To: Discussion of IronPython
> Subject: [IronPython] Some observations about parallel import
My guess is that's actually a different bug (possibly the same as 19434 & 19218
which might be dups of each other). That's actually what I'm trying to look at
fixing right now.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Monday,
Dino Viehland wrote:
It looks like protected ctor's are completely broken:
We've had issues calling other protected methods as well - see the bug
reports we posted on Friday.
Michael Foord
import clr
clr.AddReference('test')
from Xyz import Foo
class x(Foo):
def __new__(cls):
It looks like protected ctor's are completely broken:
import clr
clr.AddReference('test')
from Xyz import Foo
class x(Foo):
def __new__(cls):
return Foo.__new__(cls, object())
x()
TypeError: default __new__ does not take parameters
test.cs:
using System;
namespace Xyz {
pu
On Mon, Dec 1, 2008 at 2:43 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Ok, I think the problem here is two-fold. First there's no public default
> constructor - only a private one. So you need to pick between the Stream
> overload or the StreamResourceInfo, Uri overload. You're apparently
Congratulations and "Well Done" to the Iron Python team!
This release has taken Iron Python from an experimental curiosity to a
viable work engine (IMHO).
I ran my test suite and found only one remaining restriction -- Binary data
cannot be passed as a parameter. (The same error shows up four time
Ok, I think the problem here is two-fold. First there's no public default
constructor - only a private one. So you need to pick between the Stream
overload or the StreamResourceInfo, Uri overload. You're apparently trying to
choose the Stream overload.
Which brings me to the 2nd problem. Qu
Thanks for reporting & opening the bug. The fix for this is likely fairly easy
but I don't think we'd spin a new 2.0 build for just this issue because it
isn't really blocking anything as you have a work around.
That being said it would certainly be something we'd fix for 2.0.1 and we don't
ex
Thanks for opening this - I'm going to look at this and the other subclassing
issues and see how scary the fix(es) are.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff
Sent: Monday, December 01, 2008 11:15 AM
To: Discussion of IronPython
Subject
On Mon, Dec 1, 2008 at 10:41 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
>
> Looks like the subclassing bug *again*. :-)
>
> (i.e. it looks like Theme.__new__(...) is actually being diverted back to
> MyTheme.__new__(...))
>
> Michael
>
I suspect this is the same bug you resolver guys have been
Dan Eloff wrote:
On Sun, Nov 30, 2008 at 8:30 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
Hello Dan,
I can't find this assembly to experiment - but when you subclass a .NET type
in IronPython you override the constructor by overriding '__new__' and not
'__init__'. Perhaps this is the cause
Hello guys,
In some of our Resolver One installer tests we do some COM interop to
check that the targets of the shortcuts the installer creates are correct.
It looks like the way COM interop is done in IronPython 2 has changed a
bit. We are now getting an exception thrown when previously None
16 matches
Mail list logo
