subject:"\[IronPython\] Exporting Python code as an assembly"

Re: [IronPython] Exporting Python code as an assembly (Curt Hagenlocher)

2008-03-05 Thread Curt Hagenlocher

On 3/3/08, Suma Talya <[EMAIL PROTECTED]> wrote:
>
> Do we need to have py file also in the same directory along with dll?
>

Yes, that is correct.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly (Curt Hagenlocher)

2008-03-03 Thread Suma Talya


Hi,
I am having 2.0 alpha 8 of IronPython Binaries. I downloaded the wrapper 
changes with comment "Fixed constructor to call __init__" version no. 
7386 
 
from

http://www.codeplex.com/coils/SourceControl/ListDownloadableCommits.aspx
As soon as I create .dll file using MakeModule.py, I m renaming the py 
file. Now from ironpython interpreter i m trying to import dll file and 
create instance.

It is failing to create instance,

>>> import clr
>>> clr.AddReference('IronPythonDLL.dll')
>>> import IronPythonDLL
>>> IronPythonDLL.IronPythonClass

>>> o=IronPythonDLL.IronPythonClass()
Traceback (most recent call last):
 File IronPythonDLL, line unknown, in .ctor
 File IronPythonDLL, line unknown, in InitClass
 File , line unknown, in ##26
TypeError: Value cannot be null.
Parameter name: scriptSource

Do we need to have py file also in the same directory along with dll?

Thanks,
-Suma.

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-26 Thread Curt Hagenlocher

On Tue, Feb 26, 2008 at 9:04 AM, Dino Viehland <[EMAIL PROTECTED]>
wrote:

> What's MakeModule.py?


That's from the project I started at http://www.codeplex.com/coils.

Suma, you might consider getting a copy of the Codeplex tools and using them
to download the most recent changes; I know I've fixed some things since the
original version.  Also, make sure you're using 2.0 Alpha 8 of IronPython.
Unfortunately, I'm leaving on an email-less vacation in a few hours and
don't have the time to offer any further assistance.  I'll be back in three
weeks and you can feel free to contact me then.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-26 Thread Sanghyeon Seo

2008/2/27, Dino Viehland <[EMAIL PROTECTED]>:
> What's MakeModule.py?

Curt Hagenlocher's work-in-progress tool which was discussed on this list.
http://hagenlocher.org/software/ClrWrapper.zip

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

Re: [IronPython] Exporting Python code as an assembly

2008-02-26 Thread Dino Viehland

What's MakeModule.py?

Normally in v1.x if you do -X:SaveAssemblies or you use the pyc sample to 
compile a .py file you'll just be able to import it (like a .pyc file in 
Cpython).  AddReference is used for normal .NET assemblies.

But from the exception this looks like 2.0 - and I don't know how you're 
compiling in that case.  It could be that MakeModule.py is working against an 
older version of the hosting APIs and needs to be updated.  If you want more 
information about the exception I suggest running w/ -X:ExceptionDetail and 
we'll give you the full .NET stack trace.

But as of now IronPython 2.0 doesn't support compiling to an assembly it's self 
although we're currently looking into doing that.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Suma Talya
Sent: Tuesday, February 26, 2008 3:47 AM
To: users@lists.ironpython.com
Subject: Re: [IronPython] Exporting Python code as an assembly

Hi,

I have a py file by name IronPythonDLL.py containing
---
import clr
import System
import sys
from ClrWrapper import ClrAttribute, ClrAccepts, ClrReturns

class IronPythonClass:
clr_namespace = 'IronPythonDLL'

@ClrReturns(System.String)
def IPyMethod(self):
return "IronPython Method"
---
I have created IronPythonDLL.dll using MakeModule.py
Now through ironpython interpreter i tried creating an instance of the
above class and got an error,

 >>> import clr
 >>> clr.AddReference('IronPythonDLL.dll')
 >>> import IronPythonDLL
 >>> o=IronPythonDLL.IronPythonClass()
Traceback (most recent call last):
  File IronPythonDLL, line unknown, in .ctor
  File IronPythonDLL, line unknown, in InitClass
  File , line unknown, in ##26
TypeError: Value cannot be null.
Parameter name: scriptSource


Any help on this will be useful

Thanks,
-Suma.

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-26 Thread Suma Talya

Hi,

I have a py file by name IronPythonDLL.py containing
---
import clr
import System
import sys
from ClrWrapper import ClrAttribute, ClrAccepts, ClrReturns

class IronPythonClass:
clr_namespace = 'IronPythonDLL'
   
@ClrReturns(System.String)   
def IPyMethod(self):
return "IronPython Method"
---
I have created IronPythonDLL.dll using MakeModule.py
Now through ironpython interpreter i tried creating an instance of the 
above class and got an error,

 >>> import clr
 >>> clr.AddReference('IronPythonDLL.dll')
 >>> import IronPythonDLL
 >>> o=IronPythonDLL.IronPythonClass()
Traceback (most recent call last):
  File IronPythonDLL, line unknown, in .ctor
  File IronPythonDLL, line unknown, in InitClass
  File , line unknown, in ##26
TypeError: Value cannot be null.
Parameter name: scriptSource


Any help on this will be useful

Thanks,
-Suma.

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-11 Thread Raju Sivalingam

Hi

When i run MakeModule, i am getting this error "AttributeError: 
'NoneType' object has no attribute 'GetGetMethod' ".
For testing just i was running this command. *.\ipy.exe MakeModule.py 
Xtest.py

-Thanks
Raju***


Curt Hagenlocher wrote:
> You can download my work-in-progress from 
> http://hagenlocher.org/software/ClrWrapper.zip
>  
> The source consists of the three files ClrBuilder.py, ClrWrapper.py 
> and MakeModule.py. There are also two "demo" files: Xtest.py and 
> WcfServer.py.  The program can currently be run as follows:
>  
> PS F:\IronPython-2.0A8> *.\ipy.exe MakeModule.py Xtest.py*
>  
> This will produce a file called Xtest.dll.
>  
> At this point, the application doesn't require any of the standard 
> Python library files.  It's only been tried with the Alpha 8 binaries 
> -- and in fact, the hosting interfaces for IronPython still aren't 
> entirely stable so there's no guarantee that the DLLs produced will 
> work with Alpha 9.
>  
> Xtest.py is a trivial application that implements a single 
> xunit-compatible unit test
> PS F:\IronPython-2.0A8> *.\xunit.console.exe Xtest.dll /noshadow*
> .
> Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds
> WcfServer.py theoretically implements a WCF server, though I haven't 
> gotten as far as actually testing the output yet.  (The generated 
> code passes the eyeball compiler.)
>  
> Code quality is unimpressive; your mileage may vary.  And I've got to 
> get back to my "day job" for a few hours now :).
>  
> --
> Curt Hagenlocher
> [EMAIL PROTECTED] 
> 
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-07 Thread Dino Viehland

We're planning on shipping 2.0 RTM sometime in the 2nd half of this year - but 
we don't have a firm date quite yet.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Thursday, February 07, 2008 6:56 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

Dino,

Thanks for the insight.  That helpls a lot.  Too bad that we still won't be 
able to create IP types with the DLR in 2.0.  I was hoping that that would be a 
feature.

By the way, do you guys have an idea of when 2.0 final will be released?  Or at 
least an idea of what stages it has left to go through (how many more alpha 
stages, beta releases, RC's)?   I couldn't find this on CodePlex.

Thanks,

Rocco

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, February 06, 2008 3:54 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
The extra __'s are expected.  When we enabled this in 1.1.1 we didn't want to 
significantly alter the experience between 1.1 and 1.1.1.  The problem with 1.1 
was that if the caller passed in an attribute to filter by (DataGridView passes 
in BrowsableAttribute) we would say "attributes?  We don't have attributes, so 
you'll get an empty collection".  In 1.1.1 we'll return just about anything if 
browsable is set.  In 2.0, where we have a little more leeway to change things, 
we're more aggressive about filtering out things you probably don't want to 
see.  You can always not auto-generate the columns and you'll get the columns 
you presumably want.

The AllowNew is going to be an unfortunate limitation - Python type instances 
can't (easily) be created by anyone except for the Python runtime.  The reason 
is we need to pass a PythonType object into the contructor so the object knows 
it's type in the Python world.  So we probably can't do much about this one :(.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Wednesday, February 06, 2008 12:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

Dino,

Ah ha!  Well, it didn't work under 1.1, but under 1.1.1, it worked nearly right 
out of the box.  When I used a static interface under 1.1, I only got the 
static properties in the DataGridView.  However, under 1.1.1, I am getting a 
whole extra slew of information in my Grids (__weakref__, __doc__, the hidden 
values, the properties themselves, every function in the type) when I turn on 
AutoColumnGenerate.  Is this what I should be expecting?

Also, it seems that if I turn on user creation of new elements 
(BindingList.AllowNew = True), then the component crashes with an error stating 
that it cannot find the constructor for my type, whether or not I have defined 
it.  Is this also to be expected or not?

Thank you,

Rocco Pigneri

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, February 05, 2008 4:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Data binding isn't working for you?  We have support for this via 
CustomTypeDescriptors which describe the Python objects and we have some test 
cases to verify it works.  Note it was broken before 1.1.1 although it's been 
working in 2.0 for a little while now.  For example:

import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age < 13: return 'young'
if instance.Age < 20: return 'teen'
if instance.Age < 30: return 'twenties'
if instance.Age < 40: return 'thirties'
if instance.Age < 50: return 'forties'
return 'old'

SAMPLE_DATA = [('Joe', 23, 'twenties'),  ('Bob', 8, 'young'),  ('Thomas', 32, 
'thirties'),  ('Patrick', 41, 'forties'),  ('Kathy', 19, 'teen'),  ('Sue' , 77, 
'old'),]

class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()

class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(

Re: [IronPython] Exporting Python code as an assembly

2008-02-07 Thread Pigneri, Rocco

Michael,

>Pigneri, Rocco wrote:
>> Dino,
>> Thanks for the insight. That helpls a lot. Too bad that we still
won't 
>> be able to create IP types with the DLR in 2.0. I was hoping that
that 
>> would be a feature.
>>
>Did you see this article on future CLR/DLR integration?
>
>http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx

I actually had, and I saw this written in the last paragraph of the
Scenarios section:

"C# developers can currently use reflection to instantiate classes and
call arbitrary methods that are not known at compile time. The dynamic
extensions to the C# language will make it much easier to make such
calls."

It sounded like this would allow C# developers to "new up" an instance
of an IPy object, but this contradicts everything that I had heard on
this list.  So I just assumed that I misread this statement :-).  Then
when I found out that IPY 1.1.1 supports "staticizing" properties for
data binding, I thought that maybe I was wrong and that it could also
support the AllowNew option.  I was wrong :-).

>> By the way, do you guys have an idea of when 2.0 final will be 
>> released? Or at least an idea of what stages it has left to go
through 
>> (how many more alpha stages, beta releases, RC's)? I couldn't find 
>> this on CodePlex.
>'They' did say, not long ago, that IP 2 final would be sometime around
the end of this year and *hopefully* coincide with a DLR 1.0 final. 

You know what, they probably did, and I probably don't remember :-)!  I
have been learning so much in the last month and a half (IPY, Python
itself, IPY Studio, DLR, CLR) that it probably got crowded out by all
the other things running through my mind :-).

Thank you,

Rocco

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, February 07, 2008 10:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

Pigneri, Rocco wrote:
> Dino,
> Thanks for the insight. That helpls a lot. Too bad that we still won't

> be able to create IP types with the DLR in 2.0. I was hoping that that

> would be a feature.
>
Did you see this article on future CLR/DLR integration?

http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx

> By the way, do you guys have an idea of when 2.0 final will be 
> released? Or at least an idea of what stages it has left to go through

> (how many more alpha stages, beta releases, RC's)? I couldn't find 
> this on CodePlex.
'They' did say, not long ago, that IP 2 final would be sometime around
the end of this year and *hopefully* coincide with a DLR 1.0 final.

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

> Thanks,
> Rocco
>
> --
> --
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Dino 
> Viehland
> *Sent:* Wednesday, February 06, 2008 3:54 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> The extra __'s are expected. When we enabled this in 1.1.1 we didn't 
> want to significantly alter the experience between 1.1 and 1.1.1. The 
> problem with 1.1 was that if the caller passed in an attribute to 
> filter by (DataGridView passes in BrowsableAttribute) we would say 
> "attributes? We don't have attributes, so you'll get an empty 
> collection". In 1.1.1 we'll return just about anything if browsable is

> set. In 2.0, where we have a little more leeway to change things, 
> we're more aggressive about filtering out things you probably don't 
> want to see. You can always not auto-generate the columns and you'll 
> get the columns you presumably want.
>
> The AllowNew is going to be an unfortunate limitation - Python type 
> instances can't (easily) be created by anyone except for the Python 
> runtime. The reason is we need to pass a PythonType object into the 
> contructor so the object knows it's type in the Python world. So we 
> probably can't do much about this one L.
>
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Pigneri, 
> Rocco
> *Sent:* Wednesday, February 06, 2008 12:47 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> Dino,
>
> Ah ha! Well, it didn't work under 1.1, but under 1.1.1, it worked 
> nearly right out of the box. When I used a static interface under 1.1,

> I only got the static properties in the DataGridView. However, under 
> 1.1.1, I am getting a whole extra slew of information in my Grids 
> (__weakref__, __doc__, the hidden values, the properties the

Re: [IronPython] Exporting Python code as an assembly

2008-02-07 Thread Michael Foord

Pigneri, Rocco wrote:
> Dino,
> Thanks for the insight. That helpls a lot. Too bad that we still won't 
> be able to create IP types with the DLR in 2.0. I was hoping that that 
> would be a feature.
>
Did you see this article on future CLR/DLR integration?

http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx

> By the way, do you guys have an idea of when 2.0 final will be 
> released? Or at least an idea of what stages it has left to go through 
> (how many more alpha stages, beta releases, RC's)? I couldn't find 
> this on CodePlex.
'They' did say, not long ago, that IP 2 final would be sometime around 
the end of this year and *hopefully* coincide with a DLR 1.0 final.

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

> Thanks,
> Rocco
>
> 
> *From:* [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Dino Viehland
> *Sent:* Wednesday, February 06, 2008 3:54 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> The extra __’s are expected. When we enabled this in 1.1.1 we didn’t 
> want to significantly alter the experience between 1.1 and 1.1.1. The 
> problem with 1.1 was that if the caller passed in an attribute to 
> filter by (DataGridView passes in BrowsableAttribute) we would say 
> “attributes? We don’t have attributes, so you’ll get an empty 
> collection”. In 1.1.1 we’ll return just about anything if browsable is 
> set. In 2.0, where we have a little more leeway to change things, 
> we’re more aggressive about filtering out things you probably don’t 
> want to see. You can always not auto-generate the columns and you’ll 
> get the columns you presumably want.
>
> The AllowNew is going to be an unfortunate limitation – Python type 
> instances can’t (easily) be created by anyone except for the Python 
> runtime. The reason is we need to pass a PythonType object into the 
> contructor so the object knows it’s type in the Python world. So we 
> probably can’t do much about this one L.
>
> *From:* [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Pigneri, Rocco
> *Sent:* Wednesday, February 06, 2008 12:47 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> Dino,
>
> Ah ha! Well, it didn't work under 1.1, but under 1.1.1, it worked 
> nearly right out of the box. When I used a static interface under 1.1, 
> I only got the static properties in the DataGridView. However, under 
> 1.1.1, I am getting a whole extra slew of information in my Grids 
> (__weakref__, __doc__, the hidden values, the properties themselves, 
> every function in the type) when I turn on AutoColumnGenerate. Is this 
> what I should be expecting?
>
> Also, it seems that if I turn on user creation of new elements 
> (BindingList.AllowNew = True), then the component crashes with an 
> error stating that it cannot find the constructor for my type, whether 
> or not I have defined it. Is this also to be expected or not?
>
> Thank you,
>
> Rocco Pigneri
>
> ------------
>
> *From:* [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Dino Viehland
> *Sent:* Tuesday, February 05, 2008 4:55 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Exporting Python code as an assembly
>
> Data binding isn’t working for you? We have support for this via 
> CustomTypeDescriptors which describe the Python objects and we have 
> some test cases to verify it works. Note it was broken before 1.1.1 
> although it’s been working in 2.0 for a little while now. For example:
>
> import clr
>
> clr.AddReference('System.Windows.Forms')
>
> import System.Windows.Forms as SWF
>
> import System
>
> class AgeQualifier(object):
>
> def __get__(self, instance, ctx):
>
> if instance.Age < 13: return 'young'
>
> if instance.Age < 20: return 'teen'
>
> if instance.Age < 30: return 'twenties'
>
> if instance.Age < 40: return 'thirties'
>
> if instance.Age < 50: return 'forties'
>
> return 'old'
>
> SAMPLE_DATA = [('Joe', 23, 'twenties'), ('Bob', 8, 'young'), 
> ('Thomas', 32, 'thirties'), ('Patrick', 41, 'forties'), ('Kathy', 19, 
> 'teen'), ('Sue' , 77, 'old'),]
>
> class Person(System.Object):
>
> def __init__(self, name, age):
>
> self._name = name
>
> self._age = age
>
> def get_name(self):
>
> retu

Re: [IronPython] Exporting Python code as an assembly

2008-02-07 Thread Pigneri, Rocco

Dino,
 
Thanks for the insight.  That helpls a lot.  Too bad that we still won't
be able to create IP types with the DLR in 2.0.  I was hoping that that
would be a feature.
 
By the way, do you guys have an idea of when 2.0 final will be released?
Or at least an idea of what stages it has left to go through (how many
more alpha stages, beta releases, RC's)?   I couldn't find this on
CodePlex.
 
Thanks,
 
Rocco



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, February 06, 2008 3:54 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly



The extra __'s are expected.  When we enabled this in 1.1.1 we didn't
want to significantly alter the experience between 1.1 and 1.1.1.  The
problem with 1.1 was that if the caller passed in an attribute to filter
by (DataGridView passes in BrowsableAttribute) we would say "attributes?
We don't have attributes, so you'll get an empty collection".  In 1.1.1
we'll return just about anything if browsable is set.  In 2.0, where we
have a little more leeway to change things, we're more aggressive about
filtering out things you probably don't want to see.  You can always not
auto-generate the columns and you'll get the columns you presumably
want.

 

The AllowNew is going to be an unfortunate limitation - Python type
instances can't (easily) be created by anyone except for the Python
runtime.  The reason is we need to pass a PythonType object into the
contructor so the object knows it's type in the Python world.  So we
probably can't do much about this one L.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Wednesday, February 06, 2008 12:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

 

Dino,

 

Ah ha!  Well, it didn't work under 1.1, but under 1.1.1, it worked
nearly right out of the box.  When I used a static interface under 1.1,
I only got the static properties in the DataGridView.  However, under
1.1.1, I am getting a whole extra slew of information in my Grids
(__weakref__, __doc__, the hidden values, the properties themselves,
every function in the type) when I turn on AutoColumnGenerate.  Is this
what I should be expecting?

 

Also, it seems that if I turn on user creation of new elements
(BindingList.AllowNew = True), then the component crashes with an error
stating that it cannot find the constructor for my type, whether or not
I have defined it.  Is this also to be expected or not?

 

Thank you,

 

Rocco Pigneri

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, February 05, 2008 4:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

Data binding isn't working for you?  We have support for this via
CustomTypeDescriptors which describe the Python objects and we have some
test cases to verify it works.  Note it was broken before 1.1.1 although
it's been working in 2.0 for a little while now.  For example:

 

import clr

clr.AddReference('System.Windows.Forms')

import System.Windows.Forms as SWF

import System

class AgeQualifier(object):

def __get__(self, instance, ctx):

if instance.Age < 13: return 'young'

if instance.Age < 20: return 'teen'

if instance.Age < 30: return 'twenties'

if instance.Age < 40: return 'thirties'

if instance.Age < 50: return 'forties'

return 'old'

 

SAMPLE_DATA = [('Joe', 23, 'twenties'),  ('Bob', 8, 'young'),
('Thomas', 32, 'thirties'),  ('Patrick', 41, 'forties'),  ('Kathy', 19,
'teen'),  ('Sue' , 77, 'old'),]

 

class Person(System.Object):

def __init__(self, name, age):

self._name = name

self._age = age

def get_name(self):

return self._name

def set_name(self, value):

self._name = value

Name = property(get_name, set_name)

def get_age(self):

return self._age

def set_age(self, value):

self._age = value

Age = property(get_age, set_age)

AgeDescription = AgeQualifier()

 

class Form(SWF.Form):

def __init__(self):

SWF.Form.__init__(self)

self._people = people = []

for name, age, ignored in SAMPLE_DATA:

people.append(Person(name, age))

grid = SWF.DataGridView()

grid.AutoGenerateColumns = True

grid.DataSource = people

grid.Dock = SWF.DockStyle.Fill

    self.grid = grid

self.Controls.Add(grid)

 

form = Form()

 

SWF.Application.Run(form)

 

From: [EMAIL PROTECTED]
[mai

Re: [IronPython] Exporting Python code as an assembly

2008-02-07 Thread Curt Hagenlocher

I've created a project on CodePlex now. It's still in setup mode; send me
email and I'll add you to the project there.

The only real change I've made since the Feb 5 version are support for
static and class methods.  And if the class defines a static or class method
named "Main", I set that as the entry point.

On Feb 5, 2008 12:00 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:

> You can download my work-in-progress from
> http://hagenlocher.org/software/ClrWrapper.zip
>
> The source consists of the three files ClrBuilder.py, ClrWrapper.py and
> MakeModule.py. There are also two "demo" files: Xtest.py and WcfServer.py.
> The program can currently be run as follows:
>
> PS F:\IronPython-2.0A8> *.\ipy.exe MakeModule.py Xtest.py*
>
> This will produce a file called Xtest.dll.
>
> At this point, the application doesn't require any of the standard Python
> library files.  It's only been tried with the Alpha 8 binaries -- and in
> fact, the hosting interfaces for IronPython still aren't entirely stable so
> there's no guarantee that the DLLs produced will work with Alpha 9.
>
> Xtest.py is a trivial application that implements a single
> xunit-compatible unit test
> PS F:\IronPython-2.0A8> *.\xunit.console.exe Xtest.dll /noshadow*
> .
> Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds
> WcfServer.py theoretically implements a WCF server, though I haven't
> gotten as far as actually testing the output yet.  (The generated
> code passes the eyeball compiler.)
>
> Code quality is unimpressive; your mileage may vary.  And I've got to get
> back to my "day job" for a few hours now :).
>
> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-06 Thread Dino Viehland

The extra __'s are expected.  When we enabled this in 1.1.1 we didn't want to 
significantly alter the experience between 1.1 and 1.1.1.  The problem with 1.1 
was that if the caller passed in an attribute to filter by (DataGridView passes 
in BrowsableAttribute) we would say "attributes?  We don't have attributes, so 
you'll get an empty collection".  In 1.1.1 we'll return just about anything if 
browsable is set.  In 2.0, where we have a little more leeway to change things, 
we're more aggressive about filtering out things you probably don't want to 
see.  You can always not auto-generate the columns and you'll get the columns 
you presumably want.

The AllowNew is going to be an unfortunate limitation - Python type instances 
can't (easily) be created by anyone except for the Python runtime.  The reason 
is we need to pass a PythonType object into the contructor so the object knows 
it's type in the Python world.  So we probably can't do much about this one :(.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Wednesday, February 06, 2008 12:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

Dino,

Ah ha!  Well, it didn't work under 1.1, but under 1.1.1, it worked nearly right 
out of the box.  When I used a static interface under 1.1, I only got the 
static properties in the DataGridView.  However, under 1.1.1, I am getting a 
whole extra slew of information in my Grids (__weakref__, __doc__, the hidden 
values, the properties themselves, every function in the type) when I turn on 
AutoColumnGenerate.  Is this what I should be expecting?

Also, it seems that if I turn on user creation of new elements 
(BindingList.AllowNew = True), then the component crashes with an error stating 
that it cannot find the constructor for my type, whether or not I have defined 
it.  Is this also to be expected or not?

Thank you,

Rocco Pigneri


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, February 05, 2008 4:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Data binding isn't working for you?  We have support for this via 
CustomTypeDescriptors which describe the Python objects and we have some test 
cases to verify it works.  Note it was broken before 1.1.1 although it's been 
working in 2.0 for a little while now.  For example:

import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age < 13: return 'young'
if instance.Age < 20: return 'teen'
if instance.Age < 30: return 'twenties'
if instance.Age < 40: return 'thirties'
if instance.Age < 50: return 'forties'
return 'old'

SAMPLE_DATA = [('Joe', 23, 'twenties'),  ('Bob', 8, 'young'),  ('Thomas', 32, 
'thirties'),  ('Patrick', 41, 'forties'),  ('Kathy', 19, 'teen'),  ('Sue' , 77, 
'old'),]

class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()

class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(name, age))
grid = SWF.DataGridView()
grid.AutoGenerateColumns = True
grid.DataSource = people
grid.Dock = SWF.DockStyle.Fill
    self.grid = grid
self.Controls.Add(grid)

form = Form()

SWF.Application.Run(form)

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Tuesday, February 05, 2008 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly


Curt,

This is a great feature and was one of the first features that I investigated 
when I first got my hands on IP.

I see an immediate need for this feature in using data binding with Windows 
Forms controls. Many controls (such as DataGridView and ListView) reflect over 
the properties of bound objects in order to display this data dynamically with 
no programmer setup. Because IP types are dynamic, WinForms cannot find any 
properties to bind and creates an "empty" object. In order to use these 
features now, I must create sta

Re: [IronPython] Exporting Python code as an assembly

2008-02-06 Thread Pigneri, Rocco

Dino,
 
Ah ha!  Well, it didn't work under 1.1, but under 1.1.1, it worked
nearly right out of the box.  When I used a static interface under 1.1,
I only got the static properties in the DataGridView.  However, under
1.1.1, I am getting a whole extra slew of information in my Grids
(__weakref__, __doc__, the hidden values, the properties themselves,
every function in the type) when I turn on AutoColumnGenerate.  Is this
what I should be expecting?
 
Also, it seems that if I turn on user creation of new elements
(BindingList.AllowNew = True), then the component crashes with an error
stating that it cannot find the constructor for my type, whether or not
I have defined it.  Is this also to be expected or not?
 
Thank you,
 
Rocco Pigneri



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, February 05, 2008 4:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly



Data binding isn't working for you?  We have support for this via
CustomTypeDescriptors which describe the Python objects and we have some
test cases to verify it works.  Note it was broken before 1.1.1 although
it's been working in 2.0 for a little while now.  For example:

 

import clr

clr.AddReference('System.Windows.Forms')

import System.Windows.Forms as SWF

import System

class AgeQualifier(object):

def __get__(self, instance, ctx):

if instance.Age < 13: return 'young'

if instance.Age < 20: return 'teen'

if instance.Age < 30: return 'twenties'

if instance.Age < 40: return 'thirties'

if instance.Age < 50: return 'forties'

return 'old'

 

SAMPLE_DATA = [('Joe', 23, 'twenties'),  ('Bob', 8, 'young'),
('Thomas', 32, 'thirties'),  ('Patrick', 41, 'forties'),  ('Kathy', 19,
'teen'),  ('Sue' , 77, 'old'),]

 

class Person(System.Object):

def __init__(self, name, age):

self._name = name

self._age = age

def get_name(self):

return self._name

def set_name(self, value):

self._name = value

Name = property(get_name, set_name)

def get_age(self):

return self._age

def set_age(self, value):

self._age = value

Age = property(get_age, set_age)

AgeDescription = AgeQualifier()

 

class Form(SWF.Form):

def __init__(self):

SWF.Form.__init__(self)

self._people = people = []

for name, age, ignored in SAMPLE_DATA:

people.append(Person(name, age))

grid = SWF.DataGridView()

grid.AutoGenerateColumns = True

grid.DataSource = people

grid.Dock = SWF.DockStyle.Fill

self.grid = grid

self.Controls.Add(grid)

 

form = Form()

 

SWF.Application.Run(form)

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Tuesday, February 05, 2008 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly

 

Curt,

This is a great feature and was one of the first features that I
investigated when I first got my hands on IP.

I see an immediate need for this feature in using data binding with
Windows Forms controls. Many controls (such as DataGridView and
ListView) reflect over the properties of bound objects in order to
display this data dynamically with no programmer setup. Because IP types
are dynamic, WinForms cannot find any properties to bind and creates an
"empty" object. In order to use these features now, I must create static
interfaces with the required properties in a separate assembly and then
inherit that interface whenever I bind to business objects.

To make using these UI controls easier, it would be great if property
statements could be turned into static properties either automatically
or via a flag. It seems that IP already matches properties to the
correct static getter/setter as defined in the interfaces so this should
be a reasonable request. This staticization would remove the need for
the separate static interface.

Another situation in which this would be really helpful--although less
critical--involves situations where I want to use a static tool on an IP
assembly (for example, I want to use NUnit to test my IP classes). I say
that this is not critical as a lot of tools already have Python-specific
versions available--PyUnit is a good example.

Finally, would there be a way to simplify programmer work by providing
"standard" static creators that are turned on and off at a high level?
For example, programmers could use a "compiler" switch to turn all
functions into "void func(object, . . .)" and "object func(obj. . . )".
I see this being useful in situati

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Tim Riley

Well don't I feel like a moron. I should have spotted that. I
apologize for posting before thinking.


On Feb 5, 2008 4:29 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> On Feb 5, 2008 1:24 PM, Tim Riley <[EMAIL PROTECTED]> wrote:
> > I was testing out the code provided and when I tested it using the
> > example I got the following error.
> >
> > [snip]
> > IOError: Could not add reference to assembly xunit.dll
>
> Sorry, you need xunit for that -- it's not part of IronPython.  Xunit
> is a kind of "next generation NUnit" for unit testing, and I recommend
> it highly.  You can find it at http://www.codeplex.com/xunit
>
>
>
> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Dino Viehland

Data binding isn't working for you?  We have support for this via 
CustomTypeDescriptors which describe the Python objects and we have some test 
cases to verify it works.  Note it was broken before 1.1.1 although it's been 
working in 2.0 for a little while now.  For example:

import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age < 13: return 'young'
if instance.Age < 20: return 'teen'
if instance.Age < 30: return 'twenties'
if instance.Age < 40: return 'thirties'
if instance.Age < 50: return 'forties'
return 'old'

SAMPLE_DATA = [('Joe', 23, 'twenties'),  ('Bob', 8, 'young'),  ('Thomas', 32, 
'thirties'),  ('Patrick', 41, 'forties'),  ('Kathy', 19, 'teen'),  ('Sue' , 77, 
'old'),]

class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()

class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(name, age))
grid = SWF.DataGridView()
grid.AutoGenerateColumns = True
grid.DataSource = people
grid.Dock = SWF.DockStyle.Fill
self.grid = grid
self.Controls.Add(grid)

form = Form()

SWF.Application.Run(form)

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Tuesday, February 05, 2008 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly


Curt,

This is a great feature and was one of the first features that I investigated 
when I first got my hands on IP.

I see an immediate need for this feature in using data binding with Windows 
Forms controls. Many controls (such as DataGridView and ListView) reflect over 
the properties of bound objects in order to display this data dynamically with 
no programmer setup. Because IP types are dynamic, WinForms cannot find any 
properties to bind and creates an "empty" object. In order to use these 
features now, I must create static interfaces with the required properties in a 
separate assembly and then inherit that interface whenever I bind to business 
objects.

To make using these UI controls easier, it would be great if property 
statements could be turned into static properties either automatically or via a 
flag. It seems that IP already matches properties to the correct static 
getter/setter as defined in the interfaces so this should be a reasonable 
request. This staticization would remove the need for the separate static 
interface.

Another situation in which this would be really helpful--although less 
critical--involves situations where I want to use a static tool on an IP 
assembly (for example, I want to use NUnit to test my IP classes). I say that 
this is not critical as a lot of tools already have Python-specific versions 
available--PyUnit is a good example.

Finally, would there be a way to simplify programmer work by providing 
"standard" static creators that are turned on and off at a high level? For 
example, programmers could use a "compiler" switch to turn all functions into 
"void func(object, . . .)" and "object func(obj. . . )". I see this being 
useful in situations such as using NUnit because all that is really needed is 
the proper number of arguments and the right function name (all of which are 
already known in Python).  If things then work the way that I think they work, 
you could then just pass the objects into the correct comparators, and if they 
are the right type, then the tests will run.  Otherwise, you'll get an 
exception.

Hope that helps,

Rocco


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, February 04, 2008 1:31 PM
To: Discussion of IronPython
Subject: [IronPython] Exporting Python code as an assembly
After a bit of spare-time hacking this weekend, I've got a "proof-of-concept" 
program that takes a Python class and exports it as a (statically-defined) 
assembly.  It uses Pythonic function annotations to signal attributes and input 
and output types to the wrapper generator.  You end up with something like this

def Test(object):
@ClrAttribute(Xunit.Fact

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Curt Hagenlocher

On Feb 5, 2008 1:24 PM, Tim Riley <[EMAIL PROTECTED]> wrote:
> I was testing out the code provided and when I tested it using the
> example I got the following error.
>
> [snip]
> IOError: Could not add reference to assembly xunit.dll

Sorry, you need xunit for that -- it's not part of IronPython.  Xunit
is a kind of "next generation NUnit" for unit testing, and I recommend
it highly.  You can find it at http://www.codeplex.com/xunit

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Tim Riley

I was testing out the code provided and when I tested it using the
example I got the following error.

Note: I'm using IronPython 2.0 Alpha (2.0.0.800) on .NET 2.0.50727.1433


C:\Documents and Settings\TJRiley\Desktop\ClrWrapper>ipy.exe
MakeModule.py Xtest.py

Traceback (most recent call last):
  File , line unknown, in _stub_##2
  File C:\Documents and Settings\TJRiley\Desktop\ClrWrapper\Xtest.py,
line 4, in Initialize
  File MakeModule.py, line 331, in Initialize
  File MakeModule.py, line 39, in GetExportedClasses
IOError: Could not add reference to assembly xunit.dll

On Feb 5, 2008 3:00 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> You can download my work-in-progress from
> http://hagenlocher.org/software/ClrWrapper.zip
>
> The source consists of the three files ClrBuilder.py, ClrWrapper.py and
> MakeModule.py. There are also two "demo" files: Xtest.py and WcfServer.py.
> The program can currently be run as follows:
>
> PS F:\IronPython-2.0A8> .\ipy.exe MakeModule.py Xtest.py
>
> This will produce a file called Xtest.dll.
>
> At this point, the application doesn't require any of the standard Python
> library files.  It's only been tried with the Alpha 8 binaries -- and in
> fact, the hosting interfaces for IronPython still aren't entirely stable so
> there's no guarantee that the DLLs produced will work with Alpha 9.
>
> Xtest.py is a trivial application that implements a single xunit-compatible
> unit test
> PS F:\IronPython-2.0A8> .\xunit.console.exe Xtest.dll /noshadow
> .
> Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds
>
> WcfServer.py theoretically implements a WCF server, though I haven't gotten
> as far as actually testing the output yet.  (The generated code passes the
> eyeball compiler.)
>
> Code quality is unimpressive; your mileage may vary.  And I've got to get
> back to my "day job" for a few hours now :).
>
>
>
> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Curt Hagenlocher

You can download my work-in-progress from
http://hagenlocher.org/software/ClrWrapper.zip

The source consists of the three files ClrBuilder.py, ClrWrapper.py and
MakeModule.py. There are also two "demo" files: Xtest.py and WcfServer.py.
The program can currently be run as follows:

PS F:\IronPython-2.0A8> *.\ipy.exe MakeModule.py Xtest.py*

This will produce a file called Xtest.dll.

At this point, the application doesn't require any of the standard Python
library files.  It's only been tried with the Alpha 8 binaries -- and in
fact, the hosting interfaces for IronPython still aren't entirely stable so
there's no guarantee that the DLLs produced will work with Alpha 9.

Xtest.py is a trivial application that implements a single xunit-compatible
unit test
PS F:\IronPython-2.0A8> *.\xunit.console.exe Xtest.dll /noshadow*
.
Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds
WcfServer.py theoretically implements a WCF server, though I haven't gotten
as far as actually testing the output yet.  (The generated code passes the
eyeball compiler.)

Code quality is unimpressive; your mileage may vary.  And I've got to get
back to my "day job" for a few hours now :).

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Giles Thomas

Curt Hagenlocher wrote:
> I can't imagine that this would be a problem.  It's been a while since
> I played with the hosting-level interfaces of 1.1, but I seem to
> recall that (at the level in question) they're largely isomorphic with
> what's currently in 2.0.
Excellent - that's what I thought.  I'd love to add that once it's online.


Cheers,

Giles

-- 
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

Try out Resolver One! 
(Free registration required)

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Curt Hagenlocher

On Feb 5, 2008 9:15 AM, Pigneri, Rocco <[EMAIL PROTECTED]> wrote:
>
> To make using these UI controls easier, it would be great if property
> statements could be turned into static properties either automatically or
> via a flag.

Yes, one of the thoughts I had was that you should be able to run such
a tool in a "greedy" mode (which tries to wrap everything) and a
"precision" mode (which only wraps what you tell it to).

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Curt Hagenlocher

On Feb 5, 2008 5:50 AM, Giles Thomas <[EMAIL PROTECTED]> wrote:
>
> Would it be hugely tricky to get it working in IP 1.1 as well as 2.0, do you 
> think?
> I'm imagining some kind of "--target:1.1" flag to the tool.

I can't imagine that this would be a problem.  It's been a while since
I played with the hosting-level interfaces of 1.1, but I seem to
recall that (at the level in question) they're largely isomorphic with
what's currently in 2.0.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Pigneri, Rocco

Curt,

This is a great feature and was one of the first features that I
investigated when I first got my hands on IP.

I see an immediate need for this feature in using data binding with
Windows Forms controls. Many controls (such as DataGridView and
ListView) reflect over the properties of bound objects in order to
display this data dynamically with no programmer setup. Because IP types
are dynamic, WinForms cannot find any properties to bind and creates an
"empty" object. In order to use these features now, I must create static
interfaces with the required properties in a separate assembly and then
inherit that interface whenever I bind to business objects.

To make using these UI controls easier, it would be great if property
statements could be turned into static properties either automatically
or via a flag. It seems that IP already matches properties to the
correct static getter/setter as defined in the interfaces so this should
be a reasonable request. This staticization would remove the need for
the separate static interface.

Another situation in which this would be really helpful--although less
critical--involves situations where I want to use a static tool on an IP
assembly (for example, I want to use NUnit to test my IP classes). I say
that this is not critical as a lot of tools already have Python-specific
versions available--PyUnit is a good example.

Finally, would there be a way to simplify programmer work by providing
"standard" static creators that are turned on and off at a high level?
For example, programmers could use a "compiler" switch to turn all
functions into "void func(object, . . .)" and "object func(obj. . . )".
I see this being useful in situations such as using NUnit because all
that is really needed is the proper number of arguments and the right
function name (all of which are already known in Python).  If things
then work the way that I think they work, you could then just pass the
objects into the correct comparators, and if they are the right type,
then the tests will run.  Otherwise, you'll get an exception.

Hope that helps,

Rocco




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curt
Hagenlocher
Sent: Monday, February 04, 2008 1:31 PM
To: Discussion of IronPython
Subject: [IronPython] Exporting Python code as an assembly


After a bit of spare-time hacking this weekend, I've got a
"proof-of-concept" program that takes a Python class and exports it as a
(statically-defined) assembly.  It uses Pythonic function annotations to
signal attributes and input and output types to the wrapper generator.
You end up with something like this
 
def Test(object):
@ClrAttribute(Xunit.FactAttribute)
def WorthlessTest(self):
Xunit.Assert.Equal[type(1)](1, 1)
 
@ClrAccepts(System.String, System.Int32)
@ClrReturns(System.Int32)
def CalculateValue(self, s, i):
return len(s) + i
 
The program takes this source and spits out a DLL containing the class
"Test" which implements "WorthlessTest" and "CalculateValue".  The class
itself contains a reference to the actual Python object, and each of the
public functions simply delegates to the Pythonic implementation.
 
I'm still working on cleaning up the source a little before releasing
it, but was wondering if anyone had some feedback on the design as
described so far.  What should be changed or implemented in order for
this to be more useful to you?
 
Thanks,
-Curt
 
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-05 Thread Giles Thomas

Would it be hugely tricky to get it working in IP 1.1 as well as 2.0, do 
you think?  I'm imagining some kind of "--target:1.1" flag to the tool.





Michael Foord wrote:

Curt Hagenlocher wrote:
  

On Feb 4, 2008 11:07 AM, Michael Foord <[EMAIL PROTECTED]> wrote:
  


Curt Hagenlocher wrote:

  

The assemblies call into the IronPython engine (version 2) to load and
execute the script.  Currently, the script is loaded from the file
system, but I'd eventually like to support embedding any
required scripts as resources in the assembly, so that the whole thing
can be distributed as a single neat package.
  


Great - you beat me to it. :-)

If you make this open source then I'll be happy to help on it.

  

I'm thinking of putting it on Codeplex.  Be warned that I prefer ILGenerator to
CodeDOM, probably because I'm reliving the glory years of assembly language
programming. "6502 4eva!" :)
  



Ouch. :-)

Although in my case it was 68000 forever (truly beautiful CPU - based 
appreciated inside an Amiga). I'd love to learn more about generating IL 
- although it does make the learning curve steeper (I have tinkered but 
nothing more).


  

The current implementation is written in Python.
  

I would recommend leaving it in Python unless you have compelling 
reasons to rewrite...


I'm sure you will - but when you get it up on CodeDOM post an 
announcement here so that I can blog about it.


This is great news as it fills one 'missing piece of the puzzle' when it 
comes to integrating IronPython with other .NET languages.


Michael

  

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

  



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
Giles Thomas
MD & CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372

Try out Resolver One! 
(Free registration required)

17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 
Registered in England and Wales as company number 5467329.

Registered address: 843 Finchley Road, London NW11 8NA, UK


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-04 Thread Michael Foord

Curt Hagenlocher wrote:
> On Feb 4, 2008 11:07 AM, Michael Foord <[EMAIL PROTECTED]> wrote:
>   
>> Curt Hagenlocher wrote:
>> 
>>> The assemblies call into the IronPython engine (version 2) to load and
>>> execute the script.  Currently, the script is loaded from the file
>>> system, but I'd eventually like to support embedding any
>>> required scripts as resources in the assembly, so that the whole thing
>>> can be distributed as a single neat package.
>>>   
>> Great - you beat me to it. :-)
>>
>> If you make this open source then I'll be happy to help on it.
>> 
>
> I'm thinking of putting it on Codeplex.  Be warned that I prefer ILGenerator 
> to
> CodeDOM, probably because I'm reliving the glory years of assembly language
> programming. "6502 4eva!" :)
>   

Ouch. :-)

Although in my case it was 68000 forever (truly beautiful CPU - based 
appreciated inside an Amiga). I'd love to learn more about generating IL 
- although it does make the learning curve steeper (I have tinkered but 
nothing more).

> The current implementation is written in Python.
>   
I would recommend leaving it in Python unless you have compelling 
reasons to rewrite...

I'm sure you will - but when you get it up on CodeDOM post an 
announcement here so that I can blog about it.

This is great news as it fills one 'missing piece of the puzzle' when it 
comes to integrating IronPython with other .NET languages.

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-04 Thread Curt Hagenlocher

On Feb 4, 2008 11:07 AM, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>Curt Hagenlocher wrote:
>> The assemblies call into the IronPython engine (version 2) to load and
>> execute the script.  Currently, the script is loaded from the file
>> system, but I'd eventually like to support embedding any
>> required scripts as resources in the assembly, so that the whole thing
>> can be distributed as a single neat package.
>
> Great - you beat me to it. :-)
>
> If you make this open source then I'll be happy to help on it.

I'm thinking of putting it on Codeplex.  Be warned that I prefer ILGenerator to
CodeDOM, probably because I'm reliving the glory years of assembly language
programming. "6502 4eva!" :)

The current implementation is written in Python.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-04 Thread Michael Foord

Curt Hagenlocher wrote:
> The assemblies call into the IronPython engine (version 2) to load and 
> execute the script.  Currently, the script is loaded from the file 
> system, but I'd eventually like to support embedding any 
> required scripts as resources in the assembly, so that the whole thing 
> can be distributed as a single neat package.

Great - you beat me to it. :-)

If you make this open source then I'll be happy to help on it.

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

>
> On Feb 4, 2008 10:55 AM, Michael Foord <[EMAIL PROTECTED] 
> > wrote:
>
> The interface is pretty much exactly what I had in mind for a similar
> system.
>
> What do the statically defined assemblies do - do they call into the
> IronPython engine - and if so, for IronPython 1 or 2? If not then are
> you just compiling Python to static assemblies?
>
> To my mind the former is more interesting than the latter... (Although
> both are interesting of course...)
>
> Michael
> http://www.manning.com/foord
>
>
> Curt Hagenlocher wrote:
> > After a bit of spare-time hacking this weekend, I've got a
> > "proof-of-concept" program that takes a Python class and exports
> it as
> > a (statically-defined) assembly.  It uses Pythonic function
> > annotations to signal attributes and input and output types to the
> > wrapper generator.  You end up with something like this
> >
> > def Test(object):
> > @ClrAttribute(Xunit.FactAttribute)
> > def WorthlessTest(self):
> > Xunit.Assert.Equal[type(1)](1, 1)
> >
> > @ClrAccepts(System.String, System.Int32)
> > @ClrReturns(System.Int32)
> > def CalculateValue(self, s, i):
> > return len(s) + i
> >
> > The program takes this source and spits out a DLL containing the
> class
> > "Test" which implements "WorthlessTest" and "CalculateValue".  The
> > class itself contains a reference to the actual Python object, and
> > each of the public functions simply delegates to the Pythonic
> > implementation.
> >
> > I'm still working on cleaning up the source a little before
> releasing
> > it, but was wondering if anyone had some feedback on the design as
> > described so far.  What should be changed or implemented in
> order for
> > this to be more useful to you?
> >
> > Thanks,
> > -Curt
> >
> > --
> > Curt Hagenlocher
> > [EMAIL PROTECTED] 
> >
> >
> 
> >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com 
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
> ___
> Users mailing list
> Users@lists.ironpython.com 
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> 
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-04 Thread Curt Hagenlocher

The assemblies call into the IronPython engine (version 2) to load and
execute the script.  Currently, the script is loaded from the file system,
but I'd eventually like to support embedding any required scripts
as resources in the assembly, so that the whole thing can be distributed as
a single neat package.

On Feb 4, 2008 10:55 AM, Michael Foord <[EMAIL PROTECTED]> wrote:

> The interface is pretty much exactly what I had in mind for a similar
> system.
>
> What do the statically defined assemblies do - do they call into the
> IronPython engine - and if so, for IronPython 1 or 2? If not then are
> you just compiling Python to static assemblies?
>
> To my mind the former is more interesting than the latter... (Although
> both are interesting of course...)
>
> Michael
> http://www.manning.com/foord
>
>
> Curt Hagenlocher wrote:
> > After a bit of spare-time hacking this weekend, I've got a
> > "proof-of-concept" program that takes a Python class and exports it as
> > a (statically-defined) assembly.  It uses Pythonic function
> > annotations to signal attributes and input and output types to the
> > wrapper generator.  You end up with something like this
> >
> > def Test(object):
> > @ClrAttribute(Xunit.FactAttribute)
> > def WorthlessTest(self):
> > Xunit.Assert.Equal[type(1)](1, 1)
> >
> > @ClrAccepts(System.String, System.Int32)
> > @ClrReturns(System.Int32)
> > def CalculateValue(self, s, i):
> > return len(s) + i
> >
> > The program takes this source and spits out a DLL containing the class
> > "Test" which implements "WorthlessTest" and "CalculateValue".  The
> > class itself contains a reference to the actual Python object, and
> > each of the public functions simply delegates to the Pythonic
> > implementation.
> >
> > I'm still working on cleaning up the source a little before releasing
> > it, but was wondering if anyone had some feedback on the design as
> > described so far.  What should be changed or implemented in order for
> > this to be more useful to you?
> >
> > Thanks,
> > -Curt
> >
> > --
> > Curt Hagenlocher
> > [EMAIL PROTECTED] 
> > 
> >
> > ___
> > Users mailing list
> > Users@lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly

2008-02-04 Thread Michael Foord

The interface is pretty much exactly what I had in mind for a similar 
system.

What do the statically defined assemblies do - do they call into the 
IronPython engine - and if so, for IronPython 1 or 2? If not then are 
you just compiling Python to static assemblies?

To my mind the former is more interesting than the latter... (Although 
both are interesting of course...)

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


Curt Hagenlocher wrote:
> After a bit of spare-time hacking this weekend, I've got a 
> "proof-of-concept" program that takes a Python class and exports it as 
> a (statically-defined) assembly.  It uses Pythonic function 
> annotations to signal attributes and input and output types to the 
> wrapper generator.  You end up with something like this
>  
> def Test(object):
> @ClrAttribute(Xunit.FactAttribute)
> def WorthlessTest(self):
> Xunit.Assert.Equal[type(1)](1, 1)
> 
> @ClrAccepts(System.String, System.Int32)
> @ClrReturns(System.Int32)
> def CalculateValue(self, s, i):
> return len(s) + i
>  
> The program takes this source and spits out a DLL containing the class 
> "Test" which implements "WorthlessTest" and "CalculateValue".  The 
> class itself contains a reference to the actual Python object, and 
> each of the public functions simply delegates to the Pythonic 
> implementation.
>  
> I'm still working on cleaning up the source a little before releasing 
> it, but was wondering if anyone had some feedback on the design as 
> described so far.  What should be changed or implemented in order for 
> this to be more useful to you?
>  
> Thanks,
> -Curt
>  
> --
> Curt Hagenlocher
> [EMAIL PROTECTED] 
> 
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Exporting Python code as an assembly

2008-02-04 Thread Curt Hagenlocher

After a bit of spare-time hacking this weekend, I've got a
"proof-of-concept" program that takes a Python class and exports it as a
(statically-defined) assembly.  It uses Pythonic function annotations to
signal attributes and input and output types to the wrapper generator.  You
end up with something like this

def Test(object):
@ClrAttribute(Xunit.FactAttribute)
def WorthlessTest(self):
Xunit.Assert.Equal[type(1)](1, 1)

@ClrAccepts(System.String, System.Int32)
 @ClrReturns(System.Int32)
 def CalculateValue(self, s, i):
return len(s) + i

The program takes this source and spits out a DLL containing the class
"Test" which implements "WorthlessTest" and "CalculateValue".  The class
itself contains a reference to the actual Python object, and each of the
public functions simply delegates to the Pythonic implementation.

I'm still working on cleaning up the source a little before releasing it,
but was wondering if anyone had some feedback on the design as described so
far.  What should be changed or implemented in order for this to be more
useful to you?

Thanks,
-Curt

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Exporting Python code as an assembly (Curt Hagenlocher)

Re: [IronPython] Exporting Python code as an assembly (Curt Hagenlocher)

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

Re: [IronPython] Exporting Python code as an assembly

[IronPython] Exporting Python code as an assembly

30 matches

Site Navigation

Mail list logo

Footer information