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
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 search
Thanks Dino!
On Sat, Jul 18, 2009 at 12:45 PM, Dino Viehland 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
>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 NotSupport
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
> -Orig
(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