Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-09 Thread Markus Schaber
Hi, > Von: Jeff Hardy > On Fri, Jul 6, 2012 at 11:40 AM, Dino Viehland > wrote: > > The use case for __clrtype__ is that sometimes a .NET class expects a > > real type - either because there need to be attributes placed on it, > > or it needs a normal constructor which doesn't take a PythonType >

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-07 Thread Jeff Hardy
On Fri, Jul 6, 2012 at 7:50 PM, Alex Earl wrote: > Is there interest in moving to IKVM for more of the internal stuff? > Mono seems to have had quite a bit of success. > I'd prefer not to for the core, just to avoid another deployment dependency. I'm fine with it for the compiler though, since i

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Alex Earl
Is there interest in moving to IKVM for more of the internal stuff? Mono seems to have had quite a bit of success. Sent from my Windows Phone From: Dino Viehland Sent: 7/6/2012 7:34 PM To: Jeff Hardy Cc: Slide; [email protected] Subject: RE: [Ironpython-users] pyc port to

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Dino Viehland
Jeff wrote: > The full explanation is at > http://docs.xamarin.com/android/about/limitations and > http://docs.xamarin.com/android/advanced_topics/architecture/android_ca > llable_wrappers. > It's similar to .NET's CCW support. Oh, awesome, and of course! Somehow I was just totally missing the co

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Jeff Hardy
On Fri, Jul 6, 2012 at 12:34 PM, Dino Viehland wrote: > Jeff wrote: >> Android has some limitations around what you can inherit from. It requires >> some AOT steps to inherit from Java classes ... which includes all of the UI >> widgets. I was hand-crafting the wrappers that just forward to Python

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Dino Viehland
Jeff wrote: > Android has some limitations around what you can inherit from. It requires > some AOT steps to inherit from Java classes ... which includes all of the UI > widgets. I was hand-crafting the wrappers that just forward to Python code, > but I figured there had to be an easier way, and py

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Jeff Hardy
On Fri, Jul 6, 2012 at 11:40 AM, Dino Viehland wrote: > The use case for __clrtype__ is that sometimes a .NET class expects a real > type - > either because there need to be attributes placed on it, or it needs a normal > constructor which doesn't take a PythonType object, or for some other oddit

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Dino Viehland
---Original Message- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Jeff Hardy > Sent: Friday, July 06, 2012 8:24 AM > To: Slide > Cc: [email protected] > Subject

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Jimmy Schementi
> One limitation with pyc.py is that it doesn't generate assemblies that > can be consumed from other .NET languages directly. Using __clrtype__ > IronPython can generate assemblies at runtime that can be consumed, > but not ahead of time (to be honest, I don't really understand the use > case for

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Jeff Hardy
On Fri, Jul 6, 2012 at 9:40 AM, Slide wrote: > I'm assuming this is the latest and greatest? > > https://github.com/IronLanguages/main/blob/master/Languages/IronPython/Samples/ClrType/clrtype.py I believe so. The latest I've found, anyway. - Jeff ___ I

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Slide
I'm assuming this is the latest and greatest? https://github.com/IronLanguages/main/blob/master/Languages/IronPython/Samples/ClrType/clrtype.py On Fri, Jul 6, 2012 at 8:24 AM, Jeff Hardy wrote: > Apparently I should think out loud on the issue tracker more often :) > I haven't looked, but I'm gl

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Slide
To be honest, some of the stuff in pyc would be a little easier in C# (which is strange I know), so creating IronPython.Compiler (or something similar) would be pretty nice for upkeep reasons. I would recommend we stick with the nomenclature that exists and have something like ipyc.exe for the exec

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Jeff Hardy
NAL as well, but I'm pretty sure Mono includes it in their repo, so we should be OK. - Jeff On Fri, Jul 6, 2012 at 7:35 AM, Slide wrote: > As a quick follow-up, here is the license for IKVM, I think we can > safely include it and distribute it, but IANAL > > Copyright (C) 2002-2012 Jeroen Frijte

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Jeff Hardy
Apparently I should think out loud on the issue tracker more often :) I haven't looked, but I'm glad to hear it was easy. I'm going to think out loud for a bit, but I promise it's related :). One limitation with pyc.py is that it doesn't generate assemblies that can be consumed from other .NET lan

Re: [Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Slide
As a quick follow-up, here is the license for IKVM, I think we can safely include it and distribute it, but IANAL Copyright (C) 2002-2012 Jeroen Frijters This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising

[Ironpython-users] pyc port to IKVM.Reflection

2012-07-06 Thread Slide
I ported the pyc.py script to use IKVM.Reflection instead of System.Reflection.Emit. It turns out some of the things (win32icon) are MUCH easier to do with IKVM.Reflection. I attached the ported version to [1] if people would like to give it a try. Let me know if you see any issues and if not, I'll