From christian2.schmidt at gmx.de  Sun Feb  1 18:49:11 2009
From: christian2.schmidt at gmx.de (Christian Schmidt)
Date: Sun, 01 Feb 2009 18:49:11 +0100
Subject: [IronPython] GetBoundMember for functions and properties
Message-ID: <4985E097.2040209@gmx.de>

Hi,

I'm embedding IP2 in an C# application. The user can extend objects by 
entering expressions based on the object's properties and expressions 
defined so far. That means an expression is evaluated in the object's 
"scope".
Now I want to allow expressions that reuse other expressions, but 
override the scope in which these referenced expressions are evaluated. 
For that the user should use the name of an expression and give the 
properties to override as keyword arguments.

Example:
class Transport {
   public double Distance { get; set; }
   public double Weight { get; set; }
   // ...
}
Expression "Freight" is defined by the user as:
 >>> Transport.Freight = "Distance * 1.1 * Math.Sqrt(Weight / 24000)"

 >>> t = Transport(Distance=100, Weight=6000)
 >>> print t.Freight
55

 >>> Transport.FreightFTL = "0.8 * Freight(Weight=24000)"
 >>> print t.FreightFTL
88

So when the expression Freight is evaluated the Weight property is 
overriden with 24000 and Distance is used normally from the object's scope.

I see 3 possible directions to achieve this:

1. Using GetBoundMember/GetCustomMember and somehow identify, if
the requested property is expected to be a function or a regular return 
type.

2. Accessing expression-properties returns an object that has a Call 
SpecialMethod with ParamDictionary args and a "default property" that 
returns the expression's value.

3. Parsing the expression and determine if the expression uses other 
expression in a functional context or normally as a property.


Does anyone have an idea how to achieve this or improve the design?

Thanks
Christian


From vernondcole at gmail.com  Mon Feb  2 05:37:18 2009
From: vernondcole at gmail.com (Vernon Cole)
Date: Sun, 1 Feb 2009 21:37:18 -0700
Subject: [IronPython] Problem with time module in IronPython 2.0
In-Reply-To: <4984A801.3080405@voidspace.org.uk>
References: <49845FBA.1090306@voidspace.org.uk>
	<49847569.0506d00a.2a96.0ab7@mx.google.com>
	<4984A801.3080405@voidspace.org.uk>
Message-ID: <b7eb4a700902012037h23c77b34r6e08d40e5b93b337@mail.gmail.com>

But... time is already in the IronPython standard library -- no special path
stuff is needed...

C:\Users\vernon>"c:\program files\Ironpython 2.0\ipy.exe"
IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3053
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.sleep(3)
>>>
--
Vernon Cole

On Sat, Jan 31, 2009 at 12:35 PM, Michael Foord
<fuzzyman at voidspace.org.uk>wrote:

> Ant?nio Piteira wrote:
>
>> Hello Michael,
>>
>> Thank you for your reply.
>>
>> I've done sys.path.append("c:\CPython26\lib")... shouldn't this work?
>>
>>
>
> I think you have solved your problem now - but for IronPython 2 you should
> be using the standard library for Python 2.5 and *not* the 2.6 one, and if
> you have strings with backslashes in them you must make them raw strings or
> use double backslashes.
>
> All the best,
>
> Michael
>
> ----------------------------------------------------------------------------
>> ----------------------
>>
>> Hello Antonio,
>>
>> I've used the time module fine from IronPython 2 (you can confirm this by
>> installing IP 2 from the msi installer). I suspect you have not correctly
>> set sys.path for your hosted code. Print sys.path from inside the hosted
>> environment and confirm that the directory containing the time module is
>> there.
>>
>> All the best,
>>
>> Michael Foord
>>
>> Ant?nio Piteira wrote:
>>
>>
>>> *http://www.wtvision.com/Mail/2007/logo_wTVision.gif* <
>>> http://www.wtvision.com/>**
>>>
>>>
>>>
>>>
>>> *www.wtvision.com <http://www.wtvision.com>**
>>> Tel: +351 21 831 06 86
>>> Fax: +351 21 831 06 81
>>> email: **info at wtvision.com <mailto:info at wtvision.com>***
>>>
>>>
>>>
>>> *Est?dios Grupo TV
>>>
>>>
>> <
>> http://maps.google.com/maps?f=d&hl=en&geocode=2727134586203630395,38.937584
>>
>> ,-9.230719&saddr=Unknown+road+%4038.937584,+-9.230719&daddr=&mra=mr&sll=38.9
>>
>> 35778,-9.226456&sspn=0.033849,0.080338&ie=UTF8&ll=38.935778,-9.226456&spn=0.
>> 033849,0.080338&t=h&z=14>
>>
>>
>>
>>> Travessa da Fonte de Cima, n? 2
>>> Asseiceira Grande
>>> 2665 **?618 Venda do Pinheiro** *
>>>
>>> * *
>>>
>>> * *
>>>
>>> * *
>>>
>>>
>>>
>>> Hi,
>>>
>>> In Ironpython 1.x I could easily import time and do stuff like
>>> time.sleep(x), but since I've changed to IronPython 2.0 I'm unable to do
>>> this. I always get "No module named time".
>>>
>>> I have IronPython hosted in an application and I've already tried to
>>> append python libs path too.
>>>
>>> Any ideas?!
>>>
>>> * *
>>>
>>> * *
>>>
>>>
>>>
>>>
>>> **
>>>
>>>
>>> * *
>>>
>>>
>>>
>>>
>>> *Ant?nio Piteira**
>>> Project Development
>>> Director
>>> email: antonio.piteira at wtvision.com <mailto:antonio.piteira at wtvision.com
>>> >
>>> mobile: +351 93 449 19 74 *
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090201/1e1a6103/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Feb  2 11:10:21 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Feb 2009 10:10:21 +0000
Subject: [IronPython] Problem with time module in IronPython 2.0
In-Reply-To: <b7eb4a700902012037h23c77b34r6e08d40e5b93b337@mail.gmail.com>
References: <49845FBA.1090306@voidspace.org.uk>	<49847569.0506d00a.2a96.0ab7@mx.google.com>	<4984A801.3080405@voidspace.org.uk>
	<b7eb4a700902012037h23c77b34r6e08d40e5b93b337@mail.gmail.com>
Message-ID: <4986C68D.5070001@voidspace.org.uk>

Vernon Cole wrote:
> But... time is already in the IronPython standard library -- no 
> special path stuff is needed...

He is embedding IronPython into another application and not using ipy.exe.

Michael
>
> C:\Users\vernon>"c:\program files\Ironpython 2.0\ipy.exe"
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3053
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time
> >>> time.sleep(3)
> >>>
> --
> Vernon Cole
>
> On Sat, Jan 31, 2009 at 12:35 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Ant?nio Piteira wrote:
>
>         Hello Michael,
>
>         Thank you for your reply.
>
>         I've done sys.path.append("c:\CPython26\lib")... shouldn't
>         this work?
>          
>
>
>     I think you have solved your problem now - but for IronPython 2
>     you should be using the standard library for Python 2.5 and *not*
>     the 2.6 one, and if you have strings with backslashes in them you
>     must make them raw strings or use double backslashes.
>
>     All the best,
>
>     Michael
>
>         ----------------------------------------------------------------------------
>         ----------------------
>
>         Hello Antonio,
>
>         I've used the time module fine from IronPython 2 (you can
>         confirm this by installing IP 2 from the msi installer). I
>         suspect you have not correctly set sys.path for your hosted
>         code. Print sys.path from inside the hosted environment and
>         confirm that the directory containing the time module is there.
>
>         All the best,
>
>         Michael Foord
>
>         Ant?nio Piteira wrote:
>          
>
>             *http://www.wtvision.com/Mail/2007/logo_wTVision.gif*
>             <http://www.wtvision.com/>**
>
>                    
>                    
>
>             *www.wtvision.com <http://www.wtvision.com>
>             <http://www.wtvision.com>**
>             Tel: +351 21 831 06 86
>             Fax: +351 21 831 06 81
>             email: **info at wtvision.com <mailto:info at wtvision.com>
>             <mailto:info at wtvision.com <mailto:info at wtvision.com>>***
>
>                    
>
>             *Est?dios Grupo TV
>                
>
>         <http://maps.google.com/maps?f=d&hl=en&geocode=2727134586203630395,38.937584
>         <http://maps.google.com/maps?f=d&hl=en&geocode=2727134586203630395,38.937584>
>         ,-9.230719&saddr=Unknown+road+%4038.937584,+-9.230719&daddr=&mra=mr&sll=38.9
>         35778,-9.226456&sspn=0.033849,0.080338&ie=UTF8&ll=38.935778,-9.226456&spn=0.
>         033849,0.080338&t=h&z=14>
>
>          
>
>             Travessa da Fonte de Cima, n? 2
>             Asseiceira Grande
>             2665 **?618 Venda do Pinheiro** *
>
>             * *
>
>             * *
>
>             * *
>
>                    
>
>             Hi,
>
>             In Ironpython 1.x I could easily import time and do stuff
>             like time.sleep(x), but since I've changed to IronPython
>             2.0 I'm unable to do this. I always get "No module named
>             time".
>
>             I have IronPython hosted in an application and I've
>             already tried to append python libs path too.
>
>             Any ideas?!
>
>             * *
>
>             * *
>
>
>                    
>
>             **
>
>
>             * *
>
>
>                    
>
>             *Ant?nio Piteira**
>             Project Development
>             Director
>             email: antonio.piteira at wtvision.com
>             <mailto:antonio.piteira at wtvision.com>
>             <mailto:antonio.piteira at wtvision.com
>             <mailto:antonio.piteira at wtvision.com>>
>             mobile: +351 93 449 19 74 *
>
>             ------------------------------------------------------------------------
>
>             _______________________________________________
>             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
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


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




From antonio.piteira at wtvision.com  Mon Feb  2 11:59:50 2009
From: antonio.piteira at wtvision.com (=?iso-8859-1?Q?Ant=F3nio_Piteira?=)
Date: Mon, 2 Feb 2009 10:59:50 -0000
Subject: [IronPython] Problem with time module in IronPython 2.0
In-Reply-To: <4986C68D.5070001@voidspace.org.uk>
References: <49845FBA.1090306@voidspace.org.uk>	<49847569.0506d00a.2a96.0ab7@mx.google.com>	<4984A801.3080405@voidspace.org.uk>	<b7eb4a700902012037h23c77b34r6e08d40e5b93b337@mail.gmail.com>
	<4986C68D.5070001@voidspace.org.uk>
Message-ID: <4986d22f.09ff300a.1583.1dd9@mx.google.com>

That is correct, I'm embedding Ironpython in an application, that?s why I
had to redirect my paths.
Anyway what you said ( Vernon ) is correct but I wasn't pointing to the
right paths.

Thanks...

----------------------------------------------------------------------------
---------

Vernon Cole wrote:
> But... time is already in the IronPython standard library -- no 
> special path stuff is needed...

He is embedding IronPython into another application and not using ipy.exe.

Michael
>
> C:\Users\vernon>"c:\program files\Ironpython 2.0\ipy.exe"
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3053
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time
> >>> time.sleep(3)
> >>>
> --
> Vernon Cole
>
> On Sat, Jan 31, 2009 at 12:35 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Ant?nio Piteira wrote:
>
>         Hello Michael,
>
>         Thank you for your reply.
>
>         I've done sys.path.append("c:\CPython26\lib")... shouldn't
>         this work?
>          
>
>
>     I think you have solved your problem now - but for IronPython 2
>     you should be using the standard library for Python 2.5 and *not*
>     the 2.6 one, and if you have strings with backslashes in them you
>     must make them raw strings or use double backslashes.
>
>     All the best,
>
>     Michael
>
>
----------------------------------------------------------------------------
>         ----------------------
>
>         Hello Antonio,
>
>         I've used the time module fine from IronPython 2 (you can
>         confirm this by installing IP 2 from the msi installer). I
>         suspect you have not correctly set sys.path for your hosted
>         code. Print sys.path from inside the hosted environment and
>         confirm that the directory containing the time module is there.
>
>         All the best,
>
>         Michael Foord
>
>         Ant?nio Piteira wrote:
>          
>
>             *http://www.wtvision.com/Mail/2007/logo_wTVision.gif*
>             <http://www.wtvision.com/>**
>
>                    
>                    
>
>             *www.wtvision.com <http://www.wtvision.com>
>             <http://www.wtvision.com>**
>             Tel: +351 21 831 06 86
>             Fax: +351 21 831 06 81
>             email: **info at wtvision.com <mailto:info at wtvision.com>
>             <mailto:info at wtvision.com <mailto:info at wtvision.com>>***
>
>                    
>
>             *Est?dios Grupo TV
>                
>
>
<http://maps.google.com/maps?f=d&hl=en&geocode=2727134586203630395,38.937584
>
<http://maps.google.com/maps?f=d&hl=en&geocode=2727134586203630395,38.937584
>
>
,-9.230719&saddr=Unknown+road+%4038.937584,+-9.230719&daddr=&mra=mr&sll=38.9
>
35778,-9.226456&sspn=0.033849,0.080338&ie=UTF8&ll=38.935778,-9.226456&spn=0.
>         033849,0.080338&t=h&z=14>
>
>          
>
>             Travessa da Fonte de Cima, n? 2
>             Asseiceira Grande
>             2665 **?618 Venda do Pinheiro** *
>
>             * *
>
>             * *
>
>             * *
>
>                    
>
>             Hi,
>
>             In Ironpython 1.x I could easily import time and do stuff
>             like time.sleep(x), but since I've changed to IronPython
>             2.0 I'm unable to do this. I always get "No module named
>             time".
>
>             I have IronPython hosted in an application and I've
>             already tried to append python libs path too.
>
>             Any ideas?!
>
>             * *
>
>             * *
>
>
>                    
>
>             **
>
>
>             * *
>
>
>                    
>
>             *Ant?nio Piteira**
>             Project Development
>             Director
>             email: antonio.piteira at wtvision.com
>             <mailto:antonio.piteira at wtvision.com>
>             <mailto:antonio.piteira at wtvision.com
>             <mailto:antonio.piteira at wtvision.com>>
>             mobile: +351 93 449 19 74 *
>
>
------------------------------------------------------------------------
>
>             _______________________________________________
>             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
> 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 glauco.uri at prometeia.it  Mon Feb  2 17:05:50 2009
From: glauco.uri at prometeia.it (Glauco Uri)
Date: Mon, 02 Feb 2009 17:05:50 +0100
Subject: [IronPython] new to Iron and question.
Message-ID: <498719DE.2090108@prometeia.it>

Hi all, i'm new here, but not to python...
I've started to study IronPy for thi problem.


I'm developing a web application for data storing.
Application is py + Turbogears + Mysql

Most of data come from a COM object installed on a Windows server.
This is a financial statistical  software developed for interaction with 
Microsoft office product.
With python and win32 is possible to use it and automate some work...... 
but my purpose is to have an unique server linux  and i cannot figure 
how to use this COM object.


some suggestion?

than you
Glauco




From vernondcole at gmail.com  Mon Feb  2 17:48:48 2009
From: vernondcole at gmail.com (Vernon Cole)
Date: Mon, 2 Feb 2009 09:48:48 -0700
Subject: [IronPython] new to Iron and question.
In-Reply-To: <498719DE.2090108@prometeia.it>
References: <498719DE.2090108@prometeia.it>
Message-ID: <b7eb4a700902020848j749c2629tcedbec9953f7fe38@mail.gmail.com>

I think that COM is a Windows only thing. I have never heard of it existing
in the Linux world.
Perhaps the Mono people have emulated DCOM (Distributed COM)?, and will
answer here.
Otherwise, you are out of luck as far as running on Linux is concerned.

If you want to run this on Windows, you can access MySQL using adodbapi,
which does the necessary COM for you.
See http://adodbapi.sourceforge.net
The MySQL server can be on either a Linux or Windows machine. My test server
runs on Ubuntu Linux.
--
Vernon Cole

On Mon, Feb 2, 2009 at 9:05 AM, Glauco Uri <glauco.uri at prometeia.it> wrote:

> Hi all, i'm new here, but not to python...
> I've started to study IronPy for thi problem.
>
>
> I'm developing a web application for data storing.
> Application is py + Turbogears + Mysql
>
> Most of data come from a COM object installed on a Windows server.
> This is a financial statistical  software developed for interaction with
> Microsoft office product.
> With python and win32 is possible to use it and automate some work......
> but my purpose is to have an unique server linux  and i cannot figure how to
> use this COM object.
>
>
> some suggestion?
>
> than you
> Glauco
>
>
> _______________________________________________
> 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/20090202/8f15ec62/attachment.html>

From jslutter at reactorzero.com  Mon Feb  2 18:52:32 2009
From: jslutter at reactorzero.com (Jeff Slutter)
Date: Mon, 02 Feb 2009 12:52:32 -0500
Subject: [IronPython] Moving/Copying a PythonFunction to a different scope
Message-ID: <498732E0.8010608@reactorzero.com>

My situation is that I have a .py file that defines a function. In this
function it makes reference to some variables that aren't defined in its
scope:

(in a very simple way, it is like this -- a lot more is going on, but it
isn't relevant)

import MyModule

def TestFunction(x):
  return SomeClass(x).Execute(SomeVar);



Later on, I create a new ScriptScope for my app, and I want to import
"TestFunction" in to it so I can use it. I'm trying to avoid actually
executing the .py file that defined it (it would import MyModule into my
scope and I don't want that for example).
I *do* compile the .py file when I first encounter it, and I can use
GetVariable to extract out the TestFunction object (as a PythonFunction).

Now, when I create my new ScriptScope, I actually define "SomeVar" (it
is unique to a ScriptScope), the variable used in TestFunction above. If
I were to SetVariable in my new ScriptScope and set the previously
extracted TestFunction, it will work -- except "SomeVar" isn't known to
TestFunction because it was created in a different ScriptScope, that
didn't have it defined (when I initially loaded the .py file).

I tried creating a new PythonFunction and passing it a CodeContext and
the function information from TestFunction to 'copy' it to my new
ScriptScope - but that functionality threw an exception as not
implemented (IP 2.0)

Is there some (multithread safe) way that I can either:
 a) copy TestFunction to my new ScriptScope and have it run in my scope
 b) find some way to get SomeVar defined for it (so that if another
ScriptScope, running in another thread, calls TestFunction, they want
cross their SomeVar values)

I *KNOW* this all sounds complicated and crazy, and that there are
probably cleaner ways of doing this, but based on other restrictions of
the application, I can not see a way of doing things without doing them
in this structure (the .py file referenced in this email is actually a
pseudo "plug-in" to my app, and SomeVar is some state information that I
need to implicitly pass around into that Execute call).

I thought maybe something with decorators, but they are done at function
definition and so I don't think that is of use.

Thanks,
-Jeff



From fuzzyman at voidspace.org.uk  Mon Feb  2 19:54:54 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 02 Feb 2009 18:54:54 +0000
Subject: [IronPython] Moving/Copying a PythonFunction to a different
	scope
In-Reply-To: <498732E0.8010608@reactorzero.com>
References: <498732E0.8010608@reactorzero.com>
Message-ID: <4987417E.40406@voidspace.org.uk>

Jeff Slutter wrote:
> My situation is that I have a .py file that defines a function. In this
> function it makes reference to some variables that aren't defined in its
> scope:
>
> (in a very simple way, it is like this -- a lot more is going on, but it
> isn't relevant)
>
> import MyModule
>
> def TestFunction(x):
>   return SomeClass(x).Execute(SomeVar);
>   


When you create a closure in Python it closes over variables in the 
scope in which it was defined (lexical scoping). What you are asking for 
is effectively dynamic scoping.

Even if it is possible to hack something together that works this 
particular structure really goes against the way Python works.

I would council you to try and find another  design.

All the best,

Michael Foord
>
>
> Later on, I create a new ScriptScope for my app, and I want to import
> "TestFunction" in to it so I can use it. I'm trying to avoid actually
> executing the .py file that defined it (it would import MyModule into my
> scope and I don't want that for example).
> I *do* compile the .py file when I first encounter it, and I can use
> GetVariable to extract out the TestFunction object (as a PythonFunction).
>
> Now, when I create my new ScriptScope, I actually define "SomeVar" (it
> is unique to a ScriptScope), the variable used in TestFunction above. If
> I were to SetVariable in my new ScriptScope and set the previously
> extracted TestFunction, it will work -- except "SomeVar" isn't known to
> TestFunction because it was created in a different ScriptScope, that
> didn't have it defined (when I initially loaded the .py file).
>
> I tried creating a new PythonFunction and passing it a CodeContext and
> the function information from TestFunction to 'copy' it to my new
> ScriptScope - but that functionality threw an exception as not
> implemented (IP 2.0)
>
> Is there some (multithread safe) way that I can either:
>  a) copy TestFunction to my new ScriptScope and have it run in my scope
>  b) find some way to get SomeVar defined for it (so that if another
> ScriptScope, running in another thread, calls TestFunction, they want
> cross their SomeVar values)
>
> I *KNOW* this all sounds complicated and crazy, and that there are
> probably cleaner ways of doing this, but based on other restrictions of
> the application, I can not see a way of doing things without doing them
> in this structure (the .py file referenced in this email is actually a
> pseudo "plug-in" to my app, and SomeVar is some state information that I
> need to implicitly pass around into that Execute call).
>
> I thought maybe something with decorators, but they are done at function
> definition and so I don't think that is of use.
>
> Thanks,
> -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 Rodney.Howeedy at Sun.COM  Mon Feb  2 21:58:36 2009
From: Rodney.Howeedy at Sun.COM (Rodney Howeedy)
Date: Mon, 02 Feb 2009 13:58:36 -0700
Subject: [IronPython] new to Iron and question.
In-Reply-To: <b7eb4a700902020848j749c2629tcedbec9953f7fe38@mail.gmail.com>
References: <498719DE.2090108@prometeia.it>
	<b7eb4a700902020848j749c2629tcedbec9953f7fe38@mail.gmail.com>
Message-ID: <49875E7C.3000703@Sun.COM>

FWIW...
I had a client-side COM .dll automation file (used by IE browser) that 
connects to a WCOM server running under JBoss on Linux connecting via 
JDBC to Oracle on Solaris.

Once we found iPy, we forged ahead with a single Windows host as the 
intermediary between our other Unix clients.  No .dll COM automation 
required on the clients as they all communicate via http to the single 
IronPython host running the http server.
The iPy tutorial explains how to convert your .dll COM file using the 
.NET SDK and import it for use in IronPython.

We researched your question about COM on Linux and only found defunct 
projects for COM emulation on Unix.

But iPy give you the COM automation in your iPy scripts along with all 
the Python goodness (e.g. http server, queue server, etc).

On 02/02/09 09:48, Vernon Cole wrote:
> I think that COM is a Windows only thing. I have never heard of it 
> existing in the Linux world.
> Perhaps the Mono people have emulated DCOM (Distributed COM)?, and 
> will answer here.
> Otherwise, you are out of luck as far as running on Linux is concerned.
>
> If you want to run this on Windows, you can access MySQL using 
> adodbapi, which does the necessary COM for you.
> See http://adodbapi.sourceforge.net
> The MySQL server can be on either a Linux or Windows machine. My test 
> server runs on Ubuntu Linux.
> --
> Vernon Cole
>
> On Mon, Feb 2, 2009 at 9:05 AM, Glauco Uri <glauco.uri at prometeia.it 
> <mailto:glauco.uri at prometeia.it>> wrote:
>
>     Hi all, i'm new here, but not to python...
>     I've started to study IronPy for thi problem.
>
>
>     I'm developing a web application for data storing.
>     Application is py + Turbogears + Mysql
>
>     Most of data come from a COM object installed on a Windows server.
>     This is a financial statistical  software developed for
>     interaction with Microsoft office product.
>     With python and win32 is possible to use it and automate some
>     work...... but my purpose is to have an unique server linux  and i
>     cannot figure how to use this COM object.
>
>
>     some suggestion?
>
>     than you
>     Glauco
>
>
>     _______________________________________________
>     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
>   

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

From pierrejules.tremblay at gmail.com  Mon Feb  2 22:50:30 2009
From: pierrejules.tremblay at gmail.com (Pierre-Jules Tremblay)
Date: Mon, 2 Feb 2009 16:50:30 -0500
Subject: [IronPython] problem with import, packages, and IronPython 1.1
Message-ID: <4590bfef0902021350p64a311bdyd445da4d51f7d36f@mail.gmail.com>

Hello,

We embedded IronPython 1.1 in our application.  Unfortunately I am running
into problems accessing .NET assemblies in Python.

In one situation, if I create a module (let's call it mymodule.py) and put
it in sys.path, with the following code in it:

import clr
clr.AddReference('System')
from System.Diagnostics import Process

def foo():
     p = Process()
     return p

and then send the IronPython interpreter a script that imports mymodule and
calls foo(), everything works fine:

import mymodule
p = mymodule.foo()

However, if mymodule.py is "packaged" in a subdirectory, let's say "subdir",
which is in the search path as well and has an empty __init__.py file,
thinks break:

import subdir.mymodule
p = subdir.mymodule.foo()

I get: "ImportError: can't find module named Diagnostics".  It's as though
the fact that I've "packaged" the module in a directory breaks the way
IronPython gives me bindings to the .NET assemblies...  Why should this
break?  Am I doing something wrong?

Help!

pj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090202/1b9cd6c5/attachment.html>

From glauco.uri at prometeia.it  Tue Feb  3 09:37:06 2009
From: glauco.uri at prometeia.it (Glauco Uri)
Date: Tue, 03 Feb 2009 09:37:06 +0100
Subject: [IronPython] new to Iron and question.
In-Reply-To: <49875E7C.3000703@Sun.COM>
References: <498719DE.2090108@prometeia.it>	<b7eb4a700902020848j749c2629tcedbec9953f7fe38@mail.gmail.com>
	<49875E7C.3000703@Sun.COM>
Message-ID: <49880232.90207@prometeia.it>

Rodney Howeedy ha scritto:
> FWIW...
> I had a client-side COM .dll automation file (used by IE browser) that 
> connects to a WCOM server running under JBoss on Linux connecting via 
> JDBC to Oracle on Solaris.
>
> Once we found iPy, we forged ahead with a single Windows host as the 
> intermediary between our other Unix clients.  No .dll COM automation 
> required on the clients as they all communicate via http to the single 
> IronPython host running the http server.
> The iPy tutorial explains how to convert your .dll COM file using the 
> .NET SDK and import it for use in IronPython.
This is not clear to me, my COM obj is installed over windows, with .NET 
SDK is possible to disassemble and recompile over mono / linux  iron  ?
>
> We researched your question about COM on Linux and only found defunct 
> projects for COM emulation on Unix.
Yes, this is a problem for me, i  want to eliminate windows installation 
, very espensive to use only fot this COM obj.
>
> But iPy give you the COM automation in your iPy scripts along with all 
> the Python goodness (e.g. http server, queue server, etc).

yes, i know this solution, if i cannot found any solution for migrating 
in one linux server.


Thank you
Glauco



From glauco.uri at prometeia.it  Tue Feb  3 18:02:15 2009
From: glauco.uri at prometeia.it (Glauco Uri)
Date: Tue, 03 Feb 2009 18:02:15 +0100
Subject: [IronPython] py to ip
Message-ID: <49887897.1000605@prometeia.it>

How is the best practice to convert this code in Iron?

 >>> import win32com.client
 >>> win32com.client.Dispatch("DSXXXX.XXXXChannel")
<win32com.gen_py.DSAXXXX -_XXXXChannel instance at 0x15331416>
 >>>


I've tryed this but don't work:
 >>> import clr
 >>> clr.AddReferenceToFile("DSXXXX.dll")
 >>> import DSXXXX
 >>> clr.SetCommandDispatcher( DSXXXXX.XXXXChannel )
 >>>

dll was converted following the instruction in Tutorial.htm



Thank you
Glauco


From antonio.piteira at wtvision.com  Tue Feb  3 18:12:54 2009
From: antonio.piteira at wtvision.com (=?iso-8859-1?Q?Ant=F3nio_Piteira?=)
Date: Tue, 3 Feb 2009 17:12:54 -0000
Subject: [IronPython] py to ip
In-Reply-To: <49887897.1000605@prometeia.it>
References: <49887897.1000605@prometeia.it>
Message-ID: <49887b18.03e9300a.4ec0.ffff81e5@mx.google.com>

Shouldn't you do :

import clr
clr.AddReferenceToFile("DSXXXX.dll")
from DSXXXX import *
clr.SetCommandDispatcher( DSXXXXX.XXXXChannel )

Anyway, can you give us the error or output?

----------------------------------

How is the best practice to convert this code in Iron?

 >>> import win32com.client
 >>> win32com.client.Dispatch("DSXXXX.XXXXChannel")
<win32com.gen_py.DSAXXXX -_XXXXChannel instance at 0x15331416>
 >>>


I've tryed this but don't work:
 >>> import clr
 >>> clr.AddReferenceToFile("DSXXXX.dll")
 >>> import DSXXXX
 >>> clr.SetCommandDispatcher( DSXXXXX.XXXXChannel )
 >>>

dll was converted following the instruction in Tutorial.htm



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



From antonio.piteira at wtvision.com  Tue Feb  3 18:14:31 2009
From: antonio.piteira at wtvision.com (=?iso-8859-1?Q?Ant=F3nio_Piteira?=)
Date: Tue, 3 Feb 2009 17:14:31 -0000
Subject: [IronPython] py to ip
In-Reply-To: <49887897.1000605@prometeia.it>
References: <49887897.1000605@prometeia.it>
Message-ID: <49887b79.04ff300a.4096.ffff8c13@mx.google.com>

I'm sorry, forget what I said... I have done "AddReferenceToFile", my
mistake.

But still, what is the output?

-----------------------------

How is the best practice to convert this code in Iron?

 >>> import win32com.client
 >>> win32com.client.Dispatch("DSXXXX.XXXXChannel")
<win32com.gen_py.DSAXXXX -_XXXXChannel instance at 0x15331416>
 >>>


I've tryed this but don't work:
 >>> import clr
 >>> clr.AddReferenceToFile("DSXXXX.dll")
 >>> import DSXXXX
 >>> clr.SetCommandDispatcher( DSXXXXX.XXXXChannel )
 >>>

dll was converted following the instruction in Tutorial.htm



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



From Rodney.Howeedy at Sun.COM  Tue Feb  3 19:06:44 2009
From: Rodney.Howeedy at Sun.COM (Rodney Howeedy)
Date: Tue, 03 Feb 2009 11:06:44 -0700
Subject: [IronPython] new to Iron and question.
In-Reply-To: <49880232.90207@prometeia.it>
References: <498719DE.2090108@prometeia.it>
	<b7eb4a700902020848j749c2629tcedbec9953f7fe38@mail.gmail.com>
	<49875E7C.3000703@Sun.COM> <49880232.90207@prometeia.it>
Message-ID: <D64CD003-05EE-40F4-9A79-CF2F7D46F219@sun.com>

The COM file in my case was a .dll in the common files directory off  
my system root.
Please reference the IronPython tutorial on how to use the .NET SDK  
and what it does.
No, it does not decompile a dll into source code.
 From my standpoint, it mapped class definitions from my COM file  
into .NET and did not eliminate a Windows server running iPy.  It just  
let me leverage the work with DLR integration by the IronPython team  
so I could work in Python.



On Feb 3, 2009, at 1:37 AM, Glauco Uri <glauco.uri at prometeia.it> wrote:

> Rodney Howeedy ha scritto:
>> FWIW...
>> I had a client-side COM .dll automation file (used by IE browser)  
>> that connects to a WCOM server running under JBoss on Linux  
>> connecting via JDBC to Oracle on Solaris.
>>
>> Once we found iPy, we forged ahead with a single Windows host as  
>> the intermediary between our other Unix clients.  No .dll COM  
>> automation required on the clients as they all communicate via http  
>> to the single IronPython host running the http server.
>> The iPy tutorial explains how to convert your .dll COM file using  
>> the .NET SDK and import it for use in IronPython.
> This is not clear to me, my COM obj is installed over windows,  
> with .NET SDK is possible to disassemble and recompile over mono /  
> linux  iron  ?
>>
>> We researched your question about COM on Linux and only found  
>> defunct projects for COM emulation on Unix.
> Yes, this is a problem for me, i  want to eliminate windows  
> installation , very espensive to use only fot this COM obj.
>>
>> But iPy give you the COM automation in your iPy scripts along with  
>> all the Python goodness (e.g. http server, queue server, etc).
>
> yes, i know this solution, if i cannot found any solution for  
> migrating in one linux server.
>
>
> Thank you
> Glauco
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From giles.thomas at resolversystems.com  Tue Feb  3 19:50:04 2009
From: giles.thomas at resolversystems.com (Giles Thomas)
Date: Tue, 03 Feb 2009 18:50:04 +0000
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
Message-ID: <498891DC.3010008@resolversystems.com>

Hi all,

Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on 
IronPython 2.0, and includes (alpha-level) support for numpy using our 
Ironclad project. 

We're releasing the beta tomorrow: this has a few performance problems 
(which are being addressed - many thanks to Dino Viehland for helping 
with this!) but is otherwise functionally complete.  If you're 
interested in trying it out, drop me a line!


Best regards,

Giles
-- 

Giles Thomas
MD & CTO, Resolver Systems Ltd.
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

Win up to $17,000 for a spreadsheet: <http://www.resolversystems.com/competition/>

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




From Shri.Borde at microsoft.com  Tue Feb  3 19:59:39 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 3 Feb 2009 10:59:39 -0800
Subject: [IronPython] py to ip
In-Reply-To: <49887b79.04ff300a.4096.ffff8c13@mx.google.com>
References: <49887897.1000605@prometeia.it>
	<49887b79.04ff300a.4096.ffff8c13@mx.google.com>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD53BEB58@NA-EXMSG-C104.redmond.corp.microsoft.com>

See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details.

>>> import System
>>> t = System.Type.GetTypeFromProgID("Excel.Application")
>>> excel = System.Activator.CreateInstance(t)
>>> wb = excel.Workbooks.Add()


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ant?nio Piteira
Sent: Tuesday, February 03, 2009 9:15 AM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] py to ip

I'm sorry, forget what I said... I have done "AddReferenceToFile", my
mistake.

But still, what is the output?

-----------------------------

How is the best practice to convert this code in Iron?

 >>> import win32com.client
 >>> win32com.client.Dispatch("DSXXXX.XXXXChannel")
<win32com.gen_py.DSAXXXX -_XXXXChannel instance at 0x15331416>
 >>>


I've tryed this but don't work:
 >>> import clr
 >>> clr.AddReferenceToFile("DSXXXX.dll")
 >>> import DSXXXX
 >>> clr.SetCommandDispatcher( DSXXXXX.XXXXChannel )
 >>>

dll was converted following the instruction in Tutorial.htm



Thank you
Glauco
_______________________________________________
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 dans at houmus.org  Tue Feb  3 21:12:04 2009
From: dans at houmus.org (Dan Shechter)
Date: Tue, 3 Feb 2009 22:12:04 +0200
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <498891DC.3010008@resolversystems.com>
References: <498891DC.3010008@resolversystems.com>
Message-ID: <2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>

Here!

I can't wait to use it with NumPy.

I actually have a .NET C# assembly that does some really nasty low-level
stuff like loading data from memory mapped
files and wrapping them with IList<T> :)

I can't wait to make Ironclad/Numpy blow up :)



On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas <
giles.thomas at resolversystems.com> wrote:

> Hi all,
>
> Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
> IronPython 2.0, and includes (alpha-level) support for numpy using our
> Ironclad project.
> We're releasing the beta tomorrow: this has a few performance problems
> (which are being addressed - many thanks to Dino Viehland for helping with
> this!) but is otherwise functionally complete.  If you're interested in
> trying it out, drop me a line!
>
>
> Best regards,
>
> Giles
> --
>
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> giles.thomas at resolversystems.com
> +44 (0) 20 7253 6372
>
> Win up to $17,000 for a spreadsheet: <
> http://www.resolversystems.com/competition/>
>
> 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 at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 

   Shechter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090203/87e61623/attachment.html>

From glauco.uri at prometeia.it  Wed Feb  4 09:48:58 2009
From: glauco.uri at prometeia.it (Glauco Uri)
Date: Wed, 04 Feb 2009 09:48:58 +0100
Subject: [IronPython] py to ip
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD53BEB58@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <49887897.1000605@prometeia.it>	<49887b79.04ff300a.4096.ffff8c13@mx.google.com>
	<710DF26F214D2B4BB94287123FFE980A2DD53BEB58@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <4989567A.90606@prometeia.it>

Shri Borde ha scritto:
> See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details.
>
>   


Thank you Shri, i've done some try and this still work well:

IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
 >>> import System
 >>> System.Type.GetTypeFromProgID("DSXXXX.XXXXChannel")
<System.RuntimeType object at 0x000000000000002B [System.__ComObject]>
 >>> qq = System.Type.GetTypeFromProgID("DSAXXXX.XXXXChannel")
 >>> System.Activator.CreateInstance( qq )
<System.__ComObject (_XXXXChannel) object at 0x000000000000002C>
 >>>


But now i've some question:

- the "GetTypeFromProgID" method let me use an installed COM objec over 
the PC still running this ipy script. This don't use Interop i think
If this is corerct i cannot in any way use remotley this object?


Try to explain my issue:
I'm writing a web application over a linux Server (A).
Some financial data come from "Thomson Datastream" using this COM obj 
installed on a Windows Server (B).
My purpose is to call this COM remotely from linux server.

probably i'm doing somethin wrong but from ipy description i've 
understood this i possible.

Thank's
Glauco



From glauco.uri at prometeia.it  Wed Feb  4 09:57:36 2009
From: glauco.uri at prometeia.it (Glauco Uri)
Date: Wed, 04 Feb 2009 09:57:36 +0100
Subject: [IronPython] py to ip
In-Reply-To: <49887b79.04ff300a.4096.ffff8c13@mx.google.com>
References: <49887897.1000605@prometeia.it>
	<49887b79.04ff300a.4096.ffff8c13@mx.google.com>
Message-ID: <49895880.5000406@prometeia.it>

Ant?nio Piteira ha scritto:
> I'm sorry, forget what I said... I have done "AddReferenceToFile", my
> mistake.
>
> But still, what is the output?
>
>   
None, nothing happens.

Seems that tlbimp hasnot worked well.
how can i test my converted dll ?

thank you
Glauco


From eyvind.axelsen at profdoc.no  Wed Feb  4 10:58:36 2009
From: eyvind.axelsen at profdoc.no (Eyvind Axelsen)
Date: Wed, 4 Feb 2009 10:58:36 +0100
Subject: [IronPython] Getting hold of a ClassDefinition within
	IronPython.Compiler.Ast.Statement.Transform()
In-Reply-To: <4987417E.40406@voidspace.org.uk>
References: <498732E0.8010608@reactorzero.com>
	<4987417E.40406@voidspace.org.uk>
Message-ID: <E888680DB6B4764FAB5338F36FCF4BF501A852B4@exchangesrv.profdoc.no>

Hi everyone,

I am playing around and experimenting with new language features within
IronPython (mainly out of academic interest), and I have been extending
the IronPython compiler/interpreter for this purpose. However, please
keep in mind that I am very new to this, and still don't quite know my
way around the source. What I am wondering is, if there is a way to get
hold of existing class definitions
(IronPython.Compiler.Ast.ClassDefintion) (or something similar) from
within the Transform method of a statement. 

Thanks in advance,

Eyvind W. Axelsen.


From william at resolversystems.com  Wed Feb  4 11:15:00 2009
From: william at resolversystems.com (William Reade)
Date: Wed, 04 Feb 2009 10:15:00 +0000
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
Message-ID: <49896AA4.3060202@resolversystems.com>

I should point out ahead of time that there's no mmap module in 
IronPython at the moment, and so memory-mapped ndarrays don't work yet 
-- although most of the usual numpy save/load bits do work, so you'll 
probably be fine (unless they're too big to fit in memory).

Dan Shechter wrote:
> Here!
>
> I can't wait to use it with NumPy.
>
> I actually have a .NET C# assembly that does some really nasty 
> low-level stuff like loading data from memory mapped
> files and wrapping them with IList<T> :)
>
> I can't wait to make Ironclad/Numpy blow up :)
>
>
>
> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas 
> <giles.thomas at resolversystems.com 
> <mailto:giles.thomas at resolversystems.com>> wrote:
>
>     Hi all,
>
>     Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
>     IronPython 2.0, and includes (alpha-level) support for numpy using
>     our Ironclad project.
>     We're releasing the beta tomorrow: this has a few performance
>     problems (which are being addressed - many thanks to Dino Viehland
>     for helping with this!) but is otherwise functionally complete.
>      If you're interested in trying it out, drop me a line!
>
>
>     Best regards,
>
>     Giles
>     -- 
>
>     Giles Thomas
>     MD & CTO, Resolver Systems Ltd.
>     giles.thomas at resolversystems.com
>     <mailto:giles.thomas at resolversystems.com>
>     +44 (0) 20 7253 6372
>
>     Win up to $17,000 for a spreadsheet:
>     <http://www.resolversystems.com/competition/>
>
>     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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>     http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
> -- 
>
>    Shechter.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   



From dinov at microsoft.com  Wed Feb  4 18:03:30 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 4 Feb 2009 09:03:30 -0800
Subject: [IronPython] Getting hold of a ClassDefinition
	within	IronPython.Compiler.Ast.Statement.Transform()
In-Reply-To: <E888680DB6B4764FAB5338F36FCF4BF501A852B4@exchangesrv.profdoc.no>
References: <498732E0.8010608@reactorzero.com>
	<4987417E.40406@voidspace.org.uk>
	<E888680DB6B4764FAB5338F36FCF4BF501A852B4@exchangesrv.profdoc.no>
Message-ID: <350E7D38B6D819428718949920EC23555717A64E53@NA-EXMSG-C102.redmond.corp.microsoft.com>

What do you mean by 'existing'?  Do you want the class definitions which the current statement is nested in?  Do you want to get to an arbitrary class definition somewhere in the AST?

Currently we don't maintain any of this but there's no reason you couldn't modify PythonAst.TransformToAst so that the AstGenerator held onto _body (along w/ the other places where we construct AstGenerators).  From there you could make AstGenerator(AstGenerator parent, ...) hold onto the parent AstGenerator so you can walk up from an inner ast gen and get to the outer most one.  If you want a parent class def you'll hit it as you're walking up the AstGenerator chtain.  Or with the bodies in place you could find any ClassDefinition you want by walking down from the top ast gen.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Eyvind Axelsen
Sent: Wednesday, February 04, 2009 1:59 AM
To: Discussion of IronPython
Subject: [IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform()

Hi everyone,

I am playing around and experimenting with new language features within
IronPython (mainly out of academic interest), and I have been extending
the IronPython compiler/interpreter for this purpose. However, please
keep in mind that I am very new to this, and still don't quite know my
way around the source. What I am wondering is, if there is a way to get
hold of existing class definitions
(IronPython.Compiler.Ast.ClassDefintion) (or something similar) from
within the Transform method of a statement.

Thanks in advance,

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


From Shri.Borde at microsoft.com  Wed Feb  4 18:51:56 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Wed, 4 Feb 2009 09:51:56 -0800
Subject: [IronPython] py to ip
In-Reply-To: <4989567A.90606@prometeia.it>
References: <49887897.1000605@prometeia.it>
	<49887b79.04ff300a.4096.ffff8c13@mx.google.com>
	<710DF26F214D2B4BB94287123FFE980A2DD53BEB58@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4989567A.90606@prometeia.it>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2DD53BF238@NA-EXMSG-C104.redmond.corp.microsoft.com>

I don't know much about remote COM (is that the same as DCOM?). IronPython supports invocation on OLEAUT objects. It has only minimal support for creating such objects (via. clr.AddReferenceToTypeLib), and otherwise relies on the user to create the object using the CLR (Type.GetTypeFromProgID) or other means. You can check if any of the Activator.CreateInstance overloads (http://msdn.microsoft.com/en-us/library/system.activator.createinstance.aspx) support remote COM.

Furthermore, I doubt if Mono supports even local COM interop. If you can't do it from C# on Mono, you won't be able to do it from IronPython on Mono either. I think you will need to find COM adapters that allow you to access COM from Linux and use those...

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glauco Uri
Sent: Wednesday, February 04, 2009 12:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] py to ip

Shri Borde ha scritto:
> See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details.
>
>


Thank you Shri, i've done some try and this still work well:

IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
 >>> import System
 >>> System.Type.GetTypeFromProgID("DSXXXX.XXXXChannel")
<System.RuntimeType object at 0x000000000000002B [System.__ComObject]>
 >>> qq = System.Type.GetTypeFromProgID("DSAXXXX.XXXXChannel")
 >>> System.Activator.CreateInstance( qq )
<System.__ComObject (_XXXXChannel) object at 0x000000000000002C>
 >>>


But now i've some question:

- the "GetTypeFromProgID" method let me use an installed COM objec over
the PC still running this ipy script. This don't use Interop i think
If this is corerct i cannot in any way use remotley this object?


Try to explain my issue:
I'm writing a web application over a linux Server (A).
Some financial data come from "Thomson Datastream" using this COM obj
installed on a Windows Server (B).
My purpose is to call this COM remotely from linux server.

probably i'm doing somethin wrong but from ipy description i've
understood this i possible.

Thank's
Glauco

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



From Rodney.Howeedy at Sun.COM  Wed Feb  4 20:07:03 2009
From: Rodney.Howeedy at Sun.COM (Rodney Howeedy)
Date: Wed, 04 Feb 2009 12:07:03 -0700
Subject: [IronPython] py to ip
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2DD53BF238@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <49887897.1000605@prometeia.it>
	<49887b79.04ff300a.4096.ffff8c13@mx.google.com>
	<710DF26F214D2B4BB94287123FFE980A2DD53BEB58@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4989567A.90606@prometeia.it>
	<710DF26F214D2B4BB94287123FFE980A2DD53BF238@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <4989E757.7020109@sun.com>

Glauco:
1) I don't recall using tlbimp to try to create an EXPorted COM Interop 
assembly.  I may have my notes incorrect so double check against the 
tutorial.  I used tlbexp to EXPort the COM Interop assembly into a .NET 
2.0 output file.  Here's my command line (note: you can get help from 
tlbexp for additional parameter inputs):
D:\IronPython 2.0\SIEK\9.2_OTAClient>"d:\Program 
Files\Microsoft.NET\SDK\v2.0\Bin\TlbExp.exe" "d:\IronPython 
2.0\SIEK\9.2_OTAClient\OTAClient.dll"

2) I edited my \lib\site.py file and added the complete path to my 
converted output file, "OTAClient.dll", at the path shown on the above 
command line.

3) I then was able to use clr to iPy import my correctly exported COM 
Interop Assembly file:
import clr
clr.AddReferenceToFile("OTAClientInterop.dll")
from OTAClientInterop import *

Shri Borde wrote:
> I don't know much about remote COM (is that the same as DCOM?). IronPython supports invocation on OLEAUT objects. It has only minimal support for creating such objects (via. clr.AddReferenceToTypeLib), and otherwise relies on the user to create the object using the CLR (Type.GetTypeFromProgID) or other means. You can check if any of the Activator.CreateInstance overloads (http://msdn.microsoft.com/en-us/library/system.activator.createinstance.aspx) support remote COM.
>
> Furthermore, I doubt if Mono supports even local COM interop. If you can't do it from C# on Mono, you won't be able to do it from IronPython on Mono either. I think you will need to find COM adapters that allow you to access COM from Linux and use those...
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glauco Uri
> Sent: Wednesday, February 04, 2009 12:49 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] py to ip
>
> Shri Borde ha scritto:
>   
>> See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details.
>>
>>
>>     
>
>
> Thank you Shri, i've done some try and this still work well:
>
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import System
>  >>> System.Type.GetTypeFromProgID("DSXXXX.XXXXChannel")
> <System.RuntimeType object at 0x000000000000002B [System.__ComObject]>
>  >>> qq = System.Type.GetTypeFromProgID("DSAXXXX.XXXXChannel")
>  >>> System.Activator.CreateInstance( qq )
> <System.__ComObject (_XXXXChannel) object at 0x000000000000002C>
>  >>>
>
>
> But now i've some question:
>
> - the "GetTypeFromProgID" method let me use an installed COM objec over
> the PC still running this ipy script. This don't use Interop i think
> If this is corerct i cannot in any way use remotley this object?
>
>
> Try to explain my issue:
> I'm writing a web application over a linux Server (A).
> Some financial data come from "Thomson Datastream" using this COM obj
> installed on a Windows Server (B).
> My purpose is to call this COM remotely from linux server.
>
> probably i'm doing somethin wrong but from ipy description i've
> understood this i possible.
>
> Thank's
> Glauco
>
> _______________________________________________
> 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 dans at houmus.org  Wed Feb  4 22:04:25 2009
From: dans at houmus.org (Dan Shechter)
Date: Wed, 4 Feb 2009 23:04:25 +0200
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <49896AA4.3060202@resolversystems.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
Message-ID: <2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>

I know :)
I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke.

I did notice though that .NET 4.0 WIll have "native" support for mmap()
through System.IO.MemoryMappedFiles...
So perhaps IP 2.X will add that as well...



On Wed, Feb 4, 2009 at 12:15 PM, William Reade
<william at resolversystems.com>wrote:

> I should point out ahead of time that there's no mmap module in IronPython
> at the moment, and so memory-mapped ndarrays don't work yet -- although most
> of the usual numpy save/load bits do work, so you'll probably be fine
> (unless they're too big to fit in memory).
>
> Dan Shechter wrote:
>
>> Here!
>>
>> I can't wait to use it with NumPy.
>>
>> I actually have a .NET C# assembly that does some really nasty low-level
>> stuff like loading data from memory mapped
>> files and wrapping them with IList<T> :)
>>
>> I can't wait to make Ironclad/Numpy blow up :)
>>
>>
>>
>> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas <
>> giles.thomas at resolversystems.com <mailto:giles.thomas at resolversystems.com>>
>> wrote:
>>
>>    Hi all,
>>
>>    Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
>>    IronPython 2.0, and includes (alpha-level) support for numpy using
>>    our Ironclad project.
>>    We're releasing the beta tomorrow: this has a few performance
>>    problems (which are being addressed - many thanks to Dino Viehland
>>    for helping with this!) but is otherwise functionally complete.
>>     If you're interested in trying it out, drop me a line!
>>
>>
>>    Best regards,
>>
>>    Giles
>>    --
>>    Giles Thomas
>>    MD & CTO, Resolver Systems Ltd.
>>    giles.thomas at resolversystems.com
>>    <mailto:giles.thomas at resolversystems.com>
>>    +44 (0) 20 7253 6372
>>
>>    Win up to $17,000 for a spreadsheet:
>>    <http://www.resolversystems.com/competition/>
>>
>>    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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>
>> --
>>
>>   Shechter.
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>



-- 

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

From dinov at microsoft.com  Wed Feb  4 22:20:10 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 4 Feb 2009 13:20:10 -0800
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
	<2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>

Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we?ll have to wait until then.  Having to rely on P/Invoke is one of the main reasons we don?t have this yet (IronPython doesn?t have any p/invokes today and we?d like to avoid them if at possible).

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
Sent: Wednesday, February 04, 2009 1:04 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0

I know :)
I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke.

I did notice though that .NET 4.0 WIll have "native" support for mmap() through System.IO.MemoryMappedFiles...
So perhaps IP 2.X will add that as well...


On Wed, Feb 4, 2009 at 12:15 PM, William Reade <william at resolversystems.com<mailto:william at resolversystems.com>> wrote:
I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory).

Dan Shechter wrote:
Here!

I can't wait to use it with NumPy.

I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped
files and wrapping them with IList<T> :)

I can't wait to make Ironclad/Numpy blow up :)


On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas <giles.thomas at resolversystems.com<mailto:giles.thomas at resolversystems.com> <mailto:giles.thomas at resolversystems.com<mailto:giles.thomas at resolversystems.com>>> wrote:

   Hi all,

   Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
   IronPython 2.0, and includes (alpha-level) support for numpy using
   our Ironclad project.
   We're releasing the beta tomorrow: this has a few performance
   problems (which are being addressed - many thanks to Dino Viehland
   for helping with this!) but is otherwise functionally complete.
    If you're interested in trying it out, drop me a line!


   Best regards,

   Giles
   --
   Giles Thomas
   MD & CTO, Resolver Systems Ltd.
   giles.thomas at resolversystems.com<mailto:giles.thomas at resolversystems.com>
   <mailto:giles.thomas at resolversystems.com<mailto:giles.thomas at resolversystems.com>>

   +44 (0) 20 7253 6372

   Win up to $17,000 for a spreadsheet:
   <http://www.resolversystems.com/competition/>

   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 at lists.ironpython.com<mailto:Users at lists.ironpython.com> <mailto:Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>>

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




--

  Shechter.
------------------------------------------------------------------------


_______________________________________________
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



--

   Shechter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090204/16a51b57/attachment.html>

From slide.o.mix at gmail.com  Wed Feb  4 22:43:09 2009
From: slide.o.mix at gmail.com (Slide)
Date: Wed, 4 Feb 2009 14:43:09 -0700
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
	<2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <a623f7d10902041343x4513b56emed73627bf87a7d42@mail.gmail.com>

I think that is a great plan. Having no P/Invokes makes it much more
platform agnostic.



On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Current thinking is that IronPython 3k will be the 1st version that will
> take a dependency on .NET 4.0 so we'll have to wait until then.  Having to
> rely on P/Invoke is one of the main reasons we don't have this yet
> (IronPython doesn't have any p/invokes today and we'd like to avoid them if
> at possible).
>
>
>
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
> Sent: Wednesday, February 04, 2009 1:04 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
>
>
>
> I know :)
> I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke.
>
> I did notice though that .NET 4.0 WIll have "native" support for mmap()
> through System.IO.MemoryMappedFiles...
> So perhaps IP 2.X will add that as well...
>
>
> On Wed, Feb 4, 2009 at 12:15 PM, William Reade <william at resolversystems.com>
> wrote:
>
> I should point out ahead of time that there's no mmap module in IronPython
> at the moment, and so memory-mapped ndarrays don't work yet -- although most
> of the usual numpy save/load bits do work, so you'll probably be fine
> (unless they're too big to fit in memory).
>
> Dan Shechter wrote:
>
> Here!
>
> I can't wait to use it with NumPy.
>
> I actually have a .NET C# assembly that does some really nasty low-level
> stuff like loading data from memory mapped
> files and wrapping them with IList<T> :)
>
> I can't wait to make Ironclad/Numpy blow up :)
>
>
> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas
> <giles.thomas at resolversystems.com <mailto:giles.thomas at resolversystems.com>>
> wrote:
>
>    Hi all,
>
>    Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
>    IronPython 2.0, and includes (alpha-level) support for numpy using
>    our Ironclad project.
>    We're releasing the beta tomorrow: this has a few performance
>    problems (which are being addressed - many thanks to Dino Viehland
>    for helping with this!) but is otherwise functionally complete.
>     If you're interested in trying it out, drop me a line!
>
>
>    Best regards,
>
>    Giles
>    --
>    Giles Thomas
>    MD & CTO, Resolver Systems Ltd.
>    giles.thomas at resolversystems.com
>
>    <mailto:giles.thomas at resolversystems.com>
>
>    +44 (0) 20 7253 6372
>
>    Win up to $17,000 for a spreadsheet:
>    <http://www.resolversystems.com/competition/>
>
>    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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>
>    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
> --
>
>   Shechter.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
>
> --
>
>    Shechter.
>
> _______________________________________________
> 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 dans at houmus.org  Wed Feb  4 23:00:15 2009
From: dans at houmus.org (Dan Shechter)
Date: Thu, 5 Feb 2009 00:00:15 +0200
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <a623f7d10902041343x4513b56emed73627bf87a7d42@mail.gmail.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
	<2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<a623f7d10902041343x4513b56emed73627bf87a7d42@mail.gmail.com>
Message-ID: <C9629208-434C-4494-9251-855725B7891F@houmus.org>

I beg to differ...
Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so  
it really boils down to who maintains the "low-level" bindings...  
Ultimately, without pinvokes you wouldn't be able to accomplish  
anything...

If I was able to get mmap working on Linux/windows/macosx x86/x64 in  
one day then I'm sure it can't be that much of a problem...

Beside managed runtimes like python/.net/java were never about being  
platform agnostic, just about being "less" platform specific...

I believe the official term is:
"write once, debug everywhere"...

       Shechter.

On 04/02/2009, at 23:43, Slide <slide.o.mix at gmail.com> wrote:

> I think that is a great plan. Having no P/Invokes makes it much more
> platform agnostic.
>
>
>
> On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland <dinov at microsoft.com>  
> wrote:
>> Current thinking is that IronPython 3k will be the 1st version that  
>> will
>> take a dependency on .NET 4.0 so we'll have to wait until then.   
>> Having to
>> rely on P/Invoke is one of the main reasons we don't have this yet
>> (IronPython doesn't have any p/invokes today and we'd like to avoid  
>> them if
>> at possible).
>>
>>
>>
>> From: users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
>> Sent: Wednesday, February 04, 2009 1:04 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
>>
>>
>>
>> I know :)
>> I have my own C# Assembly that does mmap() on Windows/Linux with  
>> PInvoke.
>>
>> I did notice though that .NET 4.0 WIll have "native" support for  
>> mmap()
>> through System.IO.MemoryMappedFiles...
>> So perhaps IP 2.X will add that as well...
>>
>>
>> On Wed, Feb 4, 2009 at 12:15 PM, William Reade <william at resolversystems.com 
>> >
>> wrote:
>>
>> I should point out ahead of time that there's no mmap module in  
>> IronPython
>> at the moment, and so memory-mapped ndarrays don't work yet --  
>> although most
>> of the usual numpy save/load bits do work, so you'll probably be fine
>> (unless they're too big to fit in memory).
>>
>> Dan Shechter wrote:
>>
>> Here!
>>
>> I can't wait to use it with NumPy.
>>
>> I actually have a .NET C# assembly that does some really nasty low- 
>> level
>> stuff like loading data from memory mapped
>> files and wrapping them with IList<T> :)
>>
>> I can't wait to make Ironclad/Numpy blow up :)
>>
>>
>> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas
>> <giles.thomas at resolversystems.com <mailto:giles.thomas at resolversystems.com 
>> >>
>> wrote:
>>
>>   Hi all,
>>
>>   Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
>>   IronPython 2.0, and includes (alpha-level) support for numpy using
>>   our Ironclad project.
>>   We're releasing the beta tomorrow: this has a few performance
>>   problems (which are being addressed - many thanks to Dino Viehland
>>   for helping with this!) but is otherwise functionally complete.
>>    If you're interested in trying it out, drop me a line!
>>
>>
>>   Best regards,
>>
>>   Giles
>>   --
>>   Giles Thomas
>>   MD & CTO, Resolver Systems Ltd.
>>   giles.thomas at resolversystems.com
>>
>>   <mailto:giles.thomas at resolversystems.com>
>>
>>   +44 (0) 20 7253 6372
>>
>>   Win up to $17,000 for a spreadsheet:
>>   <http://www.resolversystems.com/competition/>
>>
>>   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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>
>>   http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>>
>> --
>>
>>  Shechter.
>>
>> --- 
>> ---------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>>
>>
>> --
>>
>>   Shechter.
>>
>> _______________________________________________
>> 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 slide.o.mix at gmail.com  Wed Feb  4 23:12:57 2009
From: slide.o.mix at gmail.com (Slide)
Date: Wed, 4 Feb 2009 15:12:57 -0700
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <C9629208-434C-4494-9251-855725B7891F@houmus.org>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
	<2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<a623f7d10902041343x4513b56emed73627bf87a7d42@mail.gmail.com>
	<C9629208-434C-4494-9251-855725B7891F@houmus.org>
Message-ID: <a623f7d10902041412g195046a3ydcbfaab4f875a68a@mail.gmail.com>

That's true, but if the low-level bindings are in the framework
itself, rather than a consumer of the framework, it does make it
easier to port to other platforms which have the same API that wrap
the low-level bindings at the framework level.


On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter <dans at houmus.org> wrote:
> I beg to differ...
> Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it
> really boils down to who maintains the "low-level" bindings... Ultimately,
> without pinvokes you wouldn't be able to accomplish anything...
>
> If I was able to get mmap working on Linux/windows/macosx x86/x64 in one day
> then I'm sure it can't be that much of a problem...
>
> Beside managed runtimes like python/.net/java were never about being
> platform agnostic, just about being "less" platform specific...
>
> I believe the official term is:
> "write once, debug everywhere"...
>
>      Shechter.
>
> On 04/02/2009, at 23:43, Slide <slide.o.mix at gmail.com> wrote:
>
>> I think that is a great plan. Having no P/Invokes makes it much more
>> platform agnostic.
>>
>>
>>
>> On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland <dinov at microsoft.com> wrote:
>>>
>>> Current thinking is that IronPython 3k will be the 1st version that will
>>> take a dependency on .NET 4.0 so we'll have to wait until then.  Having
>>> to
>>> rely on P/Invoke is one of the main reasons we don't have this yet
>>> (IronPython doesn't have any p/invokes today and we'd like to avoid them
>>> if
>>> at possible).
>>>
>>>
>>>
>>> From: users-bounces at lists.ironpython.com
>>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
>>> Sent: Wednesday, February 04, 2009 1:04 PM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
>>>
>>>
>>>
>>> I know :)
>>> I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke.
>>>
>>> I did notice though that .NET 4.0 WIll have "native" support for mmap()
>>> through System.IO.MemoryMappedFiles...
>>> So perhaps IP 2.X will add that as well...
>>>
>>>
>>> On Wed, Feb 4, 2009 at 12:15 PM, William Reade
>>> <william at resolversystems.com>
>>> wrote:
>>>
>>> I should point out ahead of time that there's no mmap module in
>>> IronPython
>>> at the moment, and so memory-mapped ndarrays don't work yet -- although
>>> most
>>> of the usual numpy save/load bits do work, so you'll probably be fine
>>> (unless they're too big to fit in memory).
>>>
>>> Dan Shechter wrote:
>>>
>>> Here!
>>>
>>> I can't wait to use it with NumPy.
>>>
>>> I actually have a .NET C# assembly that does some really nasty low-level
>>> stuff like loading data from memory mapped
>>> files and wrapping them with IList<T> :)
>>>
>>> I can't wait to make Ironclad/Numpy blow up :)
>>>
>>>
>>> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas
>>> <giles.thomas at resolversystems.com
>>> <mailto:giles.thomas at resolversystems.com>>
>>> wrote:
>>>
>>>  Hi all,
>>>
>>>  Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
>>>  IronPython 2.0, and includes (alpha-level) support for numpy using
>>>  our Ironclad project.
>>>  We're releasing the beta tomorrow: this has a few performance
>>>  problems (which are being addressed - many thanks to Dino Viehland
>>>  for helping with this!) but is otherwise functionally complete.
>>>   If you're interested in trying it out, drop me a line!
>>>
>>>
>>>  Best regards,
>>>
>>>  Giles
>>>  --
>>>  Giles Thomas
>>>  MD & CTO, Resolver Systems Ltd.
>>>  giles.thomas at resolversystems.com
>>>
>>>  <mailto:giles.thomas at resolversystems.com>
>>>
>>>  +44 (0) 20 7253 6372
>>>
>>>  Win up to $17,000 for a spreadsheet:
>>>  <http://www.resolversystems.com/competition/>
>>>
>>>  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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>
>>>  http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>>  Shechter.
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> --
>>>
>>>  Shechter.
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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  Thu Feb  5 00:06:58 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 4 Feb 2009 15:06:58 -0800
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <a623f7d10902041412g195046a3ydcbfaab4f875a68a@mail.gmail.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
	<2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<a623f7d10902041343x4513b56emed73627bf87a7d42@mail.gmail.com>
	<C9629208-434C-4494-9251-855725B7891F@houmus.org>
	<a623f7d10902041412g195046a3ydcbfaab4f875a68a@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23555717A65199@NA-EXMSG-C102.redmond.corp.microsoft.com>

Where "make it easier" is really "make it an acceptable cost".

While a feature may have taken just a day for you to implement Dan it also has on-going costs.  Every feature inevitably has bugs and those bugs need to be fixed.  If we need to implement both the feature from the Python side plus the underlying functionality it's only going to have a higher on-going cost.  Even if the code is 100% bug free there's still on-going costs as the rest of the code base changes around it.  And even if we were to resolve those and say we won't fix them there's still at least the cost of triaging those bugs.

Also adding specific support for Linux or Mac OS/X APIs would imply that we should be testing those code paths on those platforms.  Which means that our check-in infrastructure that validates and rejects check-ins will also need to be updated to run tests on Linux or Mac OS/X.  Not to mention the potential distraction of "Why didn't you support FreeBSD?", "Where's my OS/2 support?", "What about ReactOS?" or someone else's favorite platform.  

Another additional consideration is that IronPython today is 100% safe & security transparent code.  That means when we need to ask the question "Can IronPython be used to elevate permissions?" the answer is simple - it's no.  Once we introduce a P/Invoke, or any other unsafe code, we will then need to deal with "Did that API that requires trust get implemented correct?".  It's much easier to rely upon .NET getting the security right so we can focus on the problems that our users directly care about.

So I'd say that one day quickly gets blown up into a lot of time most of which can be saved if we have the feature implemented for us in the platform we run on which happens to be .NET.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Slide
Sent: Wednesday, February 04, 2009 2:13 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0

That's true, but if the low-level bindings are in the framework
itself, rather than a consumer of the framework, it does make it
easier to port to other platforms which have the same API that wrap
the low-level bindings at the framework level.


On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter <dans at houmus.org> wrote:
> I beg to differ...
> Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it
> really boils down to who maintains the "low-level" bindings... Ultimately,
> without pinvokes you wouldn't be able to accomplish anything...
>
> If I was able to get mmap working on Linux/windows/macosx x86/x64 in one day
> then I'm sure it can't be that much of a problem...
>
> Beside managed runtimes like python/.net/java were never about being
> platform agnostic, just about being "less" platform specific...
>
> I believe the official term is:
> "write once, debug everywhere"...
>
>      Shechter.
>
> On 04/02/2009, at 23:43, Slide <slide.o.mix at gmail.com> wrote:
>
>> I think that is a great plan. Having no P/Invokes makes it much more
>> platform agnostic.
>>
>>
>>
>> On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland <dinov at microsoft.com> wrote:
>>>
>>> Current thinking is that IronPython 3k will be the 1st version that will
>>> take a dependency on .NET 4.0 so we'll have to wait until then.  Having
>>> to
>>> rely on P/Invoke is one of the main reasons we don't have this yet
>>> (IronPython doesn't have any p/invokes today and we'd like to avoid them
>>> if
>>> at possible).
>>>
>>>
>>>
>>> From: users-bounces at lists.ironpython.com
>>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
>>> Sent: Wednesday, February 04, 2009 1:04 PM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
>>>
>>>
>>>
>>> I know :)
>>> I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke.
>>>
>>> I did notice though that .NET 4.0 WIll have "native" support for mmap()
>>> through System.IO.MemoryMappedFiles...
>>> So perhaps IP 2.X will add that as well...
>>>
>>>
>>> On Wed, Feb 4, 2009 at 12:15 PM, William Reade
>>> <william at resolversystems.com>
>>> wrote:
>>>
>>> I should point out ahead of time that there's no mmap module in
>>> IronPython
>>> at the moment, and so memory-mapped ndarrays don't work yet -- although
>>> most
>>> of the usual numpy save/load bits do work, so you'll probably be fine
>>> (unless they're too big to fit in memory).
>>>
>>> Dan Shechter wrote:
>>>
>>> Here!
>>>
>>> I can't wait to use it with NumPy.
>>>
>>> I actually have a .NET C# assembly that does some really nasty low-level
>>> stuff like loading data from memory mapped
>>> files and wrapping them with IList<T> :)
>>>
>>> I can't wait to make Ironclad/Numpy blow up :)
>>>
>>>
>>> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas
>>> <giles.thomas at resolversystems.com
>>> <mailto:giles.thomas at resolversystems.com>>
>>> wrote:
>>>
>>>  Hi all,
>>>
>>>  Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
>>>  IronPython 2.0, and includes (alpha-level) support for numpy using
>>>  our Ironclad project.
>>>  We're releasing the beta tomorrow: this has a few performance
>>>  problems (which are being addressed - many thanks to Dino Viehland
>>>  for helping with this!) but is otherwise functionally complete.
>>>   If you're interested in trying it out, drop me a line!
>>>
>>>
>>>  Best regards,
>>>
>>>  Giles
>>>  --
>>>  Giles Thomas
>>>  MD & CTO, Resolver Systems Ltd.
>>>  giles.thomas at resolversystems.com
>>>
>>>  <mailto:giles.thomas at resolversystems.com>
>>>
>>>  +44 (0) 20 7253 6372
>>>
>>>  Win up to $17,000 for a spreadsheet:
>>>  <http://www.resolversystems.com/competition/>
>>>
>>>  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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>>>
>>>  http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>
>>> --
>>>
>>>  Shechter.
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> --
>>>
>>>  Shechter.
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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 dans at houmus.org  Thu Feb  5 00:27:20 2009
From: dans at houmus.org (Dan Shechter)
Date: Thu, 5 Feb 2009 01:27:20 +0200
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <350E7D38B6D819428718949920EC23555717A65199@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <498891DC.3010008@resolversystems.com>
	<2e8aa6310902031212rc0dc6fbq47e0e7511ca3e00@mail.gmail.com>
	<49896AA4.3060202@resolversystems.com>
	<2e8aa6310902041304j36d1b1f7r2448ab2f076cacfa@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555717A650BA@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<a623f7d10902041343x4513b56emed73627bf87a7d42@mail.gmail.com>
	<C9629208-434C-4494-9251-855725B7891F@houmus.org>
	<a623f7d10902041412g195046a3ydcbfaab4f875a68a@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555717A65199@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <2e8aa6310902041527m3c7c48fo2c5a9ef72f3c45af@mail.gmail.com>

I'm sorry if I wasn't clear, but the IP team's stance on this is totally
acceptable, I wasn't nudging anyone to do anything.

Personally, I think that such "improvements" should go into IPCE or some
other community type extensions project.

As we stand today, IP doesn't really work flawlessly on Mac/Linux anyway.
Patches need to be plugged for all kinds of quirks such as console support
etc.
Mind you, that "we" got into this state without any P/Invoking (referring
back to "Write once, debug everywhere")

I don't expect anything coming off the IP team to work on anything other
than MS.NET/SilverLight.

It's up to the community to pick it up from there on.


On Thu, Feb 5, 2009 at 1:06 AM, Dino Viehland <dinov at microsoft.com> wrote:

> Where "make it easier" is really "make it an acceptable cost".
>
> While a feature may have taken just a day for you to implement Dan it also
> has on-going costs.  Every feature inevitably has bugs and those bugs need
> to be fixed.  If we need to implement both the feature from the Python side
> plus the underlying functionality it's only going to have a higher on-going
> cost.  Even if the code is 100% bug free there's still on-going costs as the
> rest of the code base changes around it.  And even if we were to resolve
> those and say we won't fix them there's still at least the cost of triaging
> those bugs.
>
> Also adding specific support for Linux or Mac OS/X APIs would imply that we
> should be testing those code paths on those platforms.  Which means that our
> check-in infrastructure that validates and rejects check-ins will also need
> to be updated to run tests on Linux or Mac OS/X.  Not to mention the
> potential distraction of "Why didn't you support FreeBSD?", "Where's my OS/2
> support?", "What about ReactOS?" or someone else's favorite platform.
>
> Another additional consideration is that IronPython today is 100% safe &
> security transparent code.  That means when we need to ask the question "Can
> IronPython be used to elevate permissions?" the answer is simple - it's no.
>  Once we introduce a P/Invoke, or any other unsafe code, we will then need
> to deal with "Did that API that requires trust get implemented correct?".
>  It's much easier to rely upon .NET getting the security right so we can
> focus on the problems that our users directly care about.
>
> So I'd say that one day quickly gets blown up into a lot of time most of
> which can be saved if we have the feature implemented for us in the platform
> we run on which happens to be .NET.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] On Behalf Of Slide
> Sent: Wednesday, February 04, 2009 2:13 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
>
> That's true, but if the low-level bindings are in the framework
> itself, rather than a consumer of the framework, it does make it
> easier to port to other platforms which have the same API that wrap
> the low-level bindings at the framework level.
>
>
> On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter <dans at houmus.org> wrote:
> > I beg to differ...
> > Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it
> > really boils down to who maintains the "low-level" bindings...
> Ultimately,
> > without pinvokes you wouldn't be able to accomplish anything...
> >
> > If I was able to get mmap working on Linux/windows/macosx x86/x64 in one
> day
> > then I'm sure it can't be that much of a problem...
> >
> > Beside managed runtimes like python/.net/java were never about being
> > platform agnostic, just about being "less" platform specific...
> >
> > I believe the official term is:
> > "write once, debug everywhere"...
> >
> >      Shechter.
> >
> > On 04/02/2009, at 23:43, Slide <slide.o.mix at gmail.com> wrote:
> >
> >> I think that is a great plan. Having no P/Invokes makes it much more
> >> platform agnostic.
> >>
> >>
> >>
> >> On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland <dinov at microsoft.com>
> wrote:
> >>>
> >>> Current thinking is that IronPython 3k will be the 1st version that
> will
> >>> take a dependency on .NET 4.0 so we'll have to wait until then.  Having
> >>> to
> >>> rely on P/Invoke is one of the main reasons we don't have this yet
> >>> (IronPython doesn't have any p/invokes today and we'd like to avoid
> them
> >>> if
> >>> at possible).
> >>>
> >>>
> >>>
> >>> From: users-bounces at lists.ironpython.com
> >>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Shechter
> >>> Sent: Wednesday, February 04, 2009 1:04 PM
> >>> To: Discussion of IronPython
> >>> Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
> >>>
> >>>
> >>>
> >>> I know :)
> >>> I have my own C# Assembly that does mmap() on Windows/Linux with
> PInvoke.
> >>>
> >>> I did notice though that .NET 4.0 WIll have "native" support for mmap()
> >>> through System.IO.MemoryMappedFiles...
> >>> So perhaps IP 2.X will add that as well...
> >>>
> >>>
> >>> On Wed, Feb 4, 2009 at 12:15 PM, William Reade
> >>> <william at resolversystems.com>
> >>> wrote:
> >>>
> >>> I should point out ahead of time that there's no mmap module in
> >>> IronPython
> >>> at the moment, and so memory-mapped ndarrays don't work yet -- although
> >>> most
> >>> of the usual numpy save/load bits do work, so you'll probably be fine
> >>> (unless they're too big to fit in memory).
> >>>
> >>> Dan Shechter wrote:
> >>>
> >>> Here!
> >>>
> >>> I can't wait to use it with NumPy.
> >>>
> >>> I actually have a .NET C# assembly that does some really nasty
> low-level
> >>> stuff like loading data from memory mapped
> >>> files and wrapping them with IList<T> :)
> >>>
> >>> I can't wait to make Ironclad/Numpy blow up :)
> >>>
> >>>
> >>> On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas
> >>> <giles.thomas at resolversystems.com
> >>> <mailto:giles.thomas at resolversystems.com>>
> >>> wrote:
> >>>
> >>>  Hi all,
> >>>
> >>>  Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on
> >>>  IronPython 2.0, and includes (alpha-level) support for numpy using
> >>>  our Ironclad project.
> >>>  We're releasing the beta tomorrow: this has a few performance
> >>>  problems (which are being addressed - many thanks to Dino Viehland
> >>>  for helping with this!) but is otherwise functionally complete.
> >>>   If you're interested in trying it out, drop me a line!
> >>>
> >>>
> >>>  Best regards,
> >>>
> >>>  Giles
> >>>  --
> >>>  Giles Thomas
> >>>  MD & CTO, Resolver Systems Ltd.
> >>>  giles.thomas at resolversystems.com
> >>>
> >>>  <mailto:giles.thomas at resolversystems.com>
> >>>
> >>>  +44 (0) 20 7253 6372
> >>>
> >>>  Win up to $17,000 for a spreadsheet:
> >>>  <http://www.resolversystems.com/competition/>
> >>>
> >>>  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 at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> >>>
> >>>  http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>  Shechter.
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> 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
> >>>
> >>>
> >>> --
> >>>
> >>>  Shechter.
> >>>
> >>> _______________________________________________
> >>> 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
> >
> > _______________________________________________
> > 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 

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

From orestis at resolversystems.com  Thu Feb  5 13:29:22 2009
From: orestis at resolversystems.com (Orestis Markou)
Date: Thu, 05 Feb 2009 12:29:22 +0000
Subject: [IronPython] Two engines and clr.AddReference
	don't	work	together.
In-Reply-To: <350E7D38B6D819428718949920EC23555712BA4B06@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49819648.4000206@resolversystems.com>	<3841BB92-8FBB-4BD5-97E0-35A7C2116D70@houmus.org>	<4981AB42.2000201@resolversystems.com>	<4983481D.60305@resolversystems.com>	<350E7D38B6D819428718949920EC23555712BA4941@NA-EXMSG-C102.redmond.corp.microsoft.com>	<49838D70.80904@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23555712BA4B06@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <498ADBA2.9000605@resolversystems.com>

Hi Dino,

is this going to be backported to 2.0.x? If so, when should we expect a 
release?

We have a workaround right now, but to maintain API compatibility we 
probably have to monkeypatch clr.AddReference which is a nasty hack and 
we'd rather not do it :)

Regards,
Orestis Markou
Resolver Systems Ltd.

Dino Viehland wrote:
> Yep, and I'm happy to move back to the old behavior - being consistent w/ ourselves and broken seems better than being inconsistent w/ ourselves and broken :)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, January 30, 2009 3:30 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
> 
> Dino Viehland wrote:
>> You're right that it worked in 1.0 - but of course in 1.0 we would also end up with an arbitrary ordering between engines.  For example you could have:
>>
>> Engine 1:
>>       Sys.path = C:\
>>               Contains "Foo.dll"
>>
>> Engine 2:
>>       Sys.Path = D:\
>>               Contains "Foo.dll"
>>
>> Which Foo.dll gets loaded? :)  Unfortunately we don't necessarily know what engine is actually making the request.  We can certainly go back to the 1.0 behavior in the mean time but I believe this will be truly fixed when we get better control over this in some future version of the CLR.
>>
> 
> Unfortunately the current behaviour breaks certain Resolver One
> functionality. With IronPython 1 users could put assemblies their
> spreadsheet systems depended on in the same directory as the spreadsheet
> and it 'just worked', which isn't the case with the IronPython 2 port.
> 
> Even if it isn't always guaranteed to be correct, the old behaviour was
> much better for us. :-)
> 
> Thanks
> 
> Michael
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tom Wright
>> Sent: Friday, January 30, 2009 10:34 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] Two engines and clr.AddReference don't work together.
>>
>> Hi,
>>
>> Having two engines in the same AppDomain causes interesting behaviour
>> when trying trying to add references.
>>
>> Only the sys.path of the first engine that was created seems to be taken
>> into account when calling clr.AddReference, the second sys.path is ignored.
>>
>> See
>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20921
>> for more details and a repro.
>>
>> Tom Wright
>> Resolver Systems Ltd.
>> _______________________________________________
>> 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-- 
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
orestis at resolversystems.com
+44 (0) 20 7253 6372



From rweiss at chesapeakebay.net  Thu Feb  5 17:12:55 2009
From: rweiss at chesapeakebay.net (Rob Weiss)
Date: Thu, 5 Feb 2009 08:12:55 -0800 (PST)
Subject: [IronPython]  IronPython and SSIS issue - need help...bad
Message-ID: <21853213.post@talk.nabble.com>


Cross posted on Mono Group as well...

After reading up on how to run ssis packages on mono, I came across a how to
using IronPython.

Running it, I got this:

** (C:\PROGRA~2\Mono-2.2\lib\IPCE\ipy\ipy.exe:4420): WARNING **:
string/stringbu
ilder marshalling conversion 29 not implemented Traceback (most recent call
last):
  File Microsoft.SqlServer.ManagedDTS, line unknown, in .ctor
NotImplementedError: string/stringbuilder marshalling conversion 29 not
implemen ted

** (C:\PROGRA~2\Mono-2.2\lib\IPCE\ipy\ipy.exe:4420): WARNING **: Shutting
down f inalizer thread timed out.

Does anyone have any idea as to why/what is causing this issue? I have the
same problem when running against the same dll using a C# implementation of
the same code that is executing in IronPython.

I figured that if there was a IronPython article on how to run ssis
packages, that it would work, so I think it must be a config problem on my
machines.

My dev box is Windows running Mono 2.2 and my prod box id RHEL running Mono
2.2 - what could be wrong? I am finding the DLLs ok, otherwise I would not
be getting this far.

Help!! It I can get it to work in any fashion, I will publish the code for
everyone to use, so they don't suffer my frustrations!!

TIA,
Rob Weiss

-- 
View this message in context: http://www.nabble.com/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21853213.html
Sent from the IronPython mailing list archive at Nabble.com.



From rweiss at chesapeakebay.net  Thu Feb  5 18:23:48 2009
From: rweiss at chesapeakebay.net (Rob Weiss)
Date: Thu, 5 Feb 2009 09:23:48 -0800 (PST)
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <21853213.post@talk.nabble.com>
References: <21853213.post@talk.nabble.com>
Message-ID: <21856691.post@talk.nabble.com>




Rob Weiss wrote:
> 
> Cross posted on Mono Group as well...
> 
> After reading up on how to run ssis packages on mono, I came across a how
> to using IronPython.
> 
> Running it, I got this:
> 
> ** (C:\PROGRA~2\Mono-2.2\lib\IPCE\ipy\ipy.exe:4420): WARNING **:
> string/stringbu
> ilder marshalling conversion 29 not implemented Traceback (most recent
> call last):
>   File Microsoft.SqlServer.ManagedDTS, line unknown, in .ctor
> NotImplementedError: string/stringbuilder marshalling conversion 29 not
> implemen ted
> 
> ** (C:\PROGRA~2\Mono-2.2\lib\IPCE\ipy\ipy.exe:4420): WARNING **: Shutting
> down f inalizer thread timed out.
> 
> Does anyone have any idea as to why/what is causing this issue? I have the
> same problem when running against the same dll using a C# implementation
> of the same code that is executing in IronPython.
> 
> I figured that if there was a IronPython article on how to run ssis
> packages, that it would work, so I think it must be a config problem on my
> machines.
> 
> My dev box is Windows running Mono 2.2 and my prod box id RHEL running
> Mono
> 2.2 - what could be wrong? I am finding the DLLs ok, otherwise I would not
> be getting this far.
> 
> Help!! It I can get it to work in any fashion, I will publish the code for
> everyone to use, so they don't suffer my frustrations!!
> 
> TIA,
> Rob Weiss
> 
> 

Additional Info:

I removed mono from the equation. I loaded IP 2.0 on my windows xp pro dev
box. I ran the same script and got an error saying that it could not find
the DTS assembly, so I copied the DLL to the run directory, and executed it
again and got the following error:

C:\Program Files (x86)\IronPython 2.0\rob>..\ipy dts.py
running SSIS package . . .
Traceback (most recent call last):
  File "dts.py", line 64, in dts.py
  File "dts.py", line 18, in getpackage
  File "Microsoft.SqlServer.ManagedDTS", line unknown, in .ctor
IOError: Could not load file or assembly
'Microsoft.SqlServer.DTSRuntimeWrap, Ve
rsion=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of
its
 dependencies. The system cannot find the file specified.

Here is the code:
"""
Collection of utilities for programmatically
controlling SQL 2005 SQL Server Integration
Services (SSIS) packages with IronPython-1.1.1.
"""

import clr

clr.AddReference('Microsoft.SQLServer.ManagedDTS')

from Microsoft.SqlServer.Dts import Runtime

def getpackage(packagename):
    """
    Returns SSIS package with given name.
    Loads package from file.
    """
    app = Runtime.Application()
    return app.LoadPackage(packagename, None)

def getssisexecutables(package):
    """
    Returns collection of SSIS packages' Executables
    from a given SSIS package. 

    Example Executable:  DataFlow
    """
    return package.Executables 

def gettasks(executable):
    """
    Returns collection of SSIS tasks for a
    given executable. 
    
    Example - DataFlow Executable yields collection of 
    OLE DB Source, Copy Column, and Flat File Destination.
    """
    innobj = executable.InnerObject
    return innobj.ComponentMetaDataCollection
 
def gettaskobject(tasks, objectname):
    """
    Looks for object with objectname in
    collection of tasks (ComponentMetaDataCollection).
    Returns object if it finds it,
    False otherwise.
    """
    try:
        return tasks[objectname]
    except KeyError:
        return False

def setsqlforoledb(task, sqlstring):
    """
    Specific to OLEDB - directly manipulating
    SQL input to task.

    Sets the SQL string to sqlstring for the task.
    """
    task.CustomPropertyCollection['SqlCommand'].Value = sqlstring
    return 0

print 'running SSIS package . . .'
pkg = getpackage('Septic.dtsx')
success = pkg.Execute()

Any ideas?



-- 
View this message in context: http://www.nabble.com/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21856691.html
Sent from the IronPython mailing list archive at Nabble.com.



From eyvind.axelsen at profdoc.no  Thu Feb  5 18:42:10 2009
From: eyvind.axelsen at profdoc.no (Eyvind Axelsen)
Date: Thu, 5 Feb 2009 18:42:10 +0100
Subject: [IronPython] Getting hold of a ClassDefinition within
	IronPython.Compiler.Ast.Statement.Transform()
In-Reply-To: <350E7D38B6D819428718949920EC23555717A64E53@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <498732E0.8010608@reactorzero.com><4987417E.40406@voidspace.org.uk><E888680DB6B4764FAB5338F36FCF4BF501A852B4@exchangesrv.profdoc.no>
	<350E7D38B6D819428718949920EC23555717A64E53@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <E888680DB6B4764FAB5338F36FCF4BF501A85423@exchangesrv.profdoc.no>

Dino,

Thank you for responding! Getting hold of an arbitrary ClassDefinition (and then modifying it slightly) is what I'm trying to do, so I will try your suggestions. I suppose you don't have any (informal) documentation for the parser/compiler?

Eyvind.

-----Opprinnelig melding-----
Fra: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] P? vegne av Dino Viehland
Sendt: 4. februar 2009 18:04
Til: Discussion of IronPython
Emne: Re: [IronPython] Getting hold of a ClassDefinitionwithin IronPython.Compiler.Ast.Statement.Transform()

What do you mean by 'existing'?  Do you want the class definitions which the current statement is nested in?  Do you want to get to an arbitrary class definition somewhere in the AST?

Currently we don't maintain any of this but there's no reason you couldn't modify PythonAst.TransformToAst so that the AstGenerator held onto _body (along w/ the other places where we construct AstGenerators).  From there you could make AstGenerator(AstGenerator parent, ...) hold onto the parent AstGenerator so you can walk up from an inner ast gen and get to the outer most one.  If you want a parent class def you'll hit it as you're walking up the AstGenerator chtain.  Or with the bodies in place you could find any ClassDefinition you want by walking down from the top ast gen.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Eyvind Axelsen
Sent: Wednesday, February 04, 2009 1:59 AM
To: Discussion of IronPython
Subject: [IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform()

Hi everyone,

I am playing around and experimenting with new language features within
IronPython (mainly out of academic interest), and I have been extending
the IronPython compiler/interpreter for this purpose. However, please
keep in mind that I am very new to this, and still don't quite know my
way around the source. What I am wondering is, if there is a way to get
hold of existing class definitions
(IronPython.Compiler.Ast.ClassDefintion) (or something similar) from
within the Transform method of a statement.

Thanks in advance,

Eyvind W. Axelsen.
_______________________________________________
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 tenaciousb at gmail.com  Thu Feb  5 18:45:50 2009
From: tenaciousb at gmail.com (Bill Fellows)
Date: Thu, 5 Feb 2009 11:45:50 -0600
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <21856691.post@talk.nabble.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
Message-ID: <559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>

Far from an expert here, but could you be missing an assembly?  I have
a C# app that builds SSIS packages programatically and I have
references to

Microsoft.SqlServer.DTSPipelineWrap
Microsoft.SqlServer.DTSRuntimeWrap
Microsoft.SqlServer.ManagedDTS

/bill


From rweiss at chesapeakebay.net  Thu Feb  5 19:01:04 2009
From: rweiss at chesapeakebay.net (Rob Weiss)
Date: Thu, 5 Feb 2009 10:01:04 -0800 (PST)
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
Message-ID: <21857499.post@talk.nabble.com>


The C# code I have works when compiled and run on a windows machine. It does
not work on the RHEL box under mono. So I was trying to see if mono was the
issue.

Trying to eliminate the mono question, I downloaded IP's latest version
installed on my windows dev box and ran the script I listed in my earlier
post.

The IP code I have to run the ssis package does not run and returns the
error. I have copied the DLLs you listed below into the run directory, and
still get the error.

I am wondering if it is a config issue, but I get the exact same error on my
dev box and my prod box when running the C# code under mono.

When running the IP under mono to kick off the ssis package, I get the error
I listed in the prev post. Even if I run the IP from a command prompt to
kick off the ssis package (not under mono) I get the same error.

Thanks for your response, but I still have the issue!!



Bill Fellows wrote:
> 
> Far from an expert here, but could you be missing an assembly?  I have
> a C# app that builds SSIS packages programatically and I have
> references to
> 
> Microsoft.SqlServer.DTSPipelineWrap
> Microsoft.SqlServer.DTSRuntimeWrap
> Microsoft.SqlServer.ManagedDTS
> 
> /bill
> _______________________________________________
> 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/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21857499.html
Sent from the IronPython mailing list archive at Nabble.com.



From rweiss at chesapeakebay.net  Thu Feb  5 19:01:23 2009
From: rweiss at chesapeakebay.net (Rob Weiss)
Date: Thu, 5 Feb 2009 10:01:23 -0800 (PST)
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
Message-ID: <21857504.post@talk.nabble.com>


The C# code I have works when compiled and run on a windows machine. It does
not work on the RHEL box under mono. So I was trying to see if mono was the
issue.

Trying to eliminate the mono question, I downloaded IP's latest version
installed on my windows dev box and ran the script I listed in my earlier
post.

The IP code I have to run the ssis package does not run and returns the
error. I have copied the DLLs you listed below into the run directory, and
still get the error.

I am wondering if it is a config issue, but I get the exact same error on my
dev box and my prod box when running the C# code under mono.

When running the IP under mono to kick off the ssis package, I get the error
I listed in the prev post. Even if I run the IP from a command prompt to
kick off the ssis package (not under mono) I get the same error.

Thanks for your response, but I still have the issue!!



Bill Fellows wrote:
> 
> Far from an expert here, but could you be missing an assembly?  I have
> a C# app that builds SSIS packages programatically and I have
> references to
> 
> Microsoft.SqlServer.DTSPipelineWrap
> Microsoft.SqlServer.DTSRuntimeWrap
> Microsoft.SqlServer.ManagedDTS
> 
> /bill
> _______________________________________________
> 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/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21857504.html
Sent from the IronPython mailing list archive at Nabble.com.



From dinov at microsoft.com  Thu Feb  5 19:08:22 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 5 Feb 2009 10:08:22 -0800
Subject: [IronPython] Two engines and
	clr.AddReference	don't	work	together.
In-Reply-To: <498ADBA2.9000605@resolversystems.com>
References: <49819648.4000206@resolversystems.com>
	<3841BB92-8FBB-4BD5-97E0-35A7C2116D70@houmus.org>
	<4981AB42.2000201@resolversystems.com>	<4983481D.60305@resolversystems.com>
	<350E7D38B6D819428718949920EC23555712BA4941@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49838D70.80904@voidspace.org.uk>
	<350E7D38B6D819428718949920EC23555712BA4B06@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<498ADBA2.9000605@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC235557199D6D45@NA-EXMSG-C102.redmond.corp.microsoft.com>

Yep, it's going to be back ported.  I'd say 2.0.1 will probably be in 2-3 weeks.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou
Sent: Thursday, February 05, 2009 4:29 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.

Hi Dino,

is this going to be backported to 2.0.x? If so, when should we expect a 
release?

We have a workaround right now, but to maintain API compatibility we 
probably have to monkeypatch clr.AddReference which is a nasty hack and 
we'd rather not do it :)

Regards,
Orestis Markou
Resolver Systems Ltd.

Dino Viehland wrote:
> Yep, and I'm happy to move back to the old behavior - being consistent w/ ourselves and broken seems better than being inconsistent w/ ourselves and broken :)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Friday, January 30, 2009 3:30 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
> 
> Dino Viehland wrote:
>> You're right that it worked in 1.0 - but of course in 1.0 we would also end up with an arbitrary ordering between engines.  For example you could have:
>>
>> Engine 1:
>>       Sys.path = C:\
>>               Contains "Foo.dll"
>>
>> Engine 2:
>>       Sys.Path = D:\
>>               Contains "Foo.dll"
>>
>> Which Foo.dll gets loaded? :)  Unfortunately we don't necessarily know what engine is actually making the request.  We can certainly go back to the 1.0 behavior in the mean time but I believe this will be truly fixed when we get better control over this in some future version of the CLR.
>>
> 
> Unfortunately the current behaviour breaks certain Resolver One
> functionality. With IronPython 1 users could put assemblies their
> spreadsheet systems depended on in the same directory as the spreadsheet
> and it 'just worked', which isn't the case with the IronPython 2 port.
> 
> Even if it isn't always guaranteed to be correct, the old behaviour was
> much better for us. :-)
> 
> Thanks
> 
> Michael
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tom Wright
>> Sent: Friday, January 30, 2009 10:34 AM
>> To: Discussion of IronPython
>> Subject: [IronPython] Two engines and clr.AddReference don't work together.
>>
>> Hi,
>>
>> Having two engines in the same AppDomain causes interesting behaviour
>> when trying trying to add references.
>>
>> Only the sys.path of the first engine that was created seems to be taken
>> into account when calling clr.AddReference, the second sys.path is ignored.
>>
>> See
>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20921
>> for more details and a repro.
>>
>> Tom Wright
>> Resolver Systems Ltd.
>> _______________________________________________
>> 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-- 
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
orestis at resolversystems.com
+44 (0) 20 7253 6372

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


From dinov at microsoft.com  Thu Feb  5 19:15:38 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 5 Feb 2009 10:15:38 -0800
Subject: [IronPython] Getting hold of a ClassDefinition
	within	IronPython.Compiler.Ast.Statement.Transform()
In-Reply-To: <E888680DB6B4764FAB5338F36FCF4BF501A85423@exchangesrv.profdoc.no>
References: <498732E0.8010608@reactorzero.com><4987417E.40406@voidspace.org.uk><E888680DB6B4764FAB5338F36FCF4BF501A852B4@exchangesrv.profdoc.no>
	<350E7D38B6D819428718949920EC23555717A64E53@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<E888680DB6B4764FAB5338F36FCF4BF501A85423@exchangesrv.profdoc.no>
Message-ID: <350E7D38B6D819428718949920EC235557199D6D56@NA-EXMSG-C102.redmond.corp.microsoft.com>

Sorry, there's no additional documentation other than the comments.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Eyvind Axelsen
Sent: Thursday, February 05, 2009 9:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform()

Dino,

Thank you for responding! Getting hold of an arbitrary ClassDefinition (and then modifying it slightly) is what I'm trying to do, so I will try your suggestions. I suppose you don't have any (informal) documentation for the parser/compiler?

Eyvind.

-----Opprinnelig melding-----
Fra: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] P? vegne av Dino Viehland
Sendt: 4. februar 2009 18:04
Til: Discussion of IronPython
Emne: Re: [IronPython] Getting hold of a ClassDefinitionwithin IronPython.Compiler.Ast.Statement.Transform()

What do you mean by 'existing'?  Do you want the class definitions which the current statement is nested in?  Do you want to get to an arbitrary class definition somewhere in the AST?

Currently we don't maintain any of this but there's no reason you couldn't modify PythonAst.TransformToAst so that the AstGenerator held onto _body (along w/ the other places where we construct AstGenerators).  From there you could make AstGenerator(AstGenerator parent, ...) hold onto the parent AstGenerator so you can walk up from an inner ast gen and get to the outer most one.  If you want a parent class def you'll hit it as you're walking up the AstGenerator chtain.  Or with the bodies in place you could find any ClassDefinition you want by walking down from the top ast gen.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Eyvind Axelsen
Sent: Wednesday, February 04, 2009 1:59 AM
To: Discussion of IronPython
Subject: [IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform()

Hi everyone,

I am playing around and experimenting with new language features within
IronPython (mainly out of academic interest), and I have been extending
the IronPython compiler/interpreter for this purpose. However, please
keep in mind that I am very new to this, and still don't quite know my
way around the source. What I am wondering is, if there is a way to get
hold of existing class definitions
(IronPython.Compiler.Ast.ClassDefintion) (or something similar) from
within the Transform method of a statement.

Thanks in advance,

Eyvind W. Axelsen.
_______________________________________________
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 orestis at resolversystems.com  Thu Feb  5 19:27:55 2009
From: orestis at resolversystems.com (Orestis Markou)
Date: Thu, 05 Feb 2009 18:27:55 +0000
Subject: [IronPython] Two engines
	and	clr.AddReference	don't	work	together.
In-Reply-To: <350E7D38B6D819428718949920EC235557199D6D45@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49819648.4000206@resolversystems.com>	<3841BB92-8FBB-4BD5-97E0-35A7C2116D70@houmus.org>	<4981AB42.2000201@resolversystems.com>	<4983481D.60305@resolversystems.com>	<350E7D38B6D819428718949920EC23555712BA4941@NA-EXMSG-C102.redmond.corp.microsoft.com>	<49838D70.80904@voidspace.org.uk>	<350E7D38B6D819428718949920EC23555712BA4B06@NA-EXMSG-C102.redmond.corp.microsoft.com>	<498ADBA2.9000605@resolversystems.com>
	<350E7D38B6D819428718949920EC235557199D6D45@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <498B2FAB.7030700@resolversystems.com>

Thanks!

Dino Viehland wrote:
> Yep, it's going to be back ported.  I'd say 2.0.1 will probably be in 2-3 weeks.
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Orestis Markou
> Sent: Thursday, February 05, 2009 4:29 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
> 
> Hi Dino,
> 
> is this going to be backported to 2.0.x? If so, when should we expect a 
> release?
> 
> We have a workaround right now, but to maintain API compatibility we 
> probably have to monkeypatch clr.AddReference which is a nasty hack and 
> we'd rather not do it :)
> 
> Regards,
> Orestis Markou
> Resolver Systems Ltd.
> 
> Dino Viehland wrote:
>> Yep, and I'm happy to move back to the old behavior - being consistent w/ ourselves and broken seems better than being inconsistent w/ ourselves and broken :)
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Friday, January 30, 2009 3:30 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Two engines and clr.AddReference don't work together.
>>
>> Dino Viehland wrote:
>>> You're right that it worked in 1.0 - but of course in 1.0 we would also end up with an arbitrary ordering between engines.  For example you could have:
>>>
>>> Engine 1:
>>>       Sys.path = C:\
>>>               Contains "Foo.dll"
>>>
>>> Engine 2:
>>>       Sys.Path = D:\
>>>               Contains "Foo.dll"
>>>
>>> Which Foo.dll gets loaded? :)  Unfortunately we don't necessarily know what engine is actually making the request.  We can certainly go back to the 1.0 behavior in the mean time but I believe this will be truly fixed when we get better control over this in some future version of the CLR.
>>>
>> Unfortunately the current behaviour breaks certain Resolver One
>> functionality. With IronPython 1 users could put assemblies their
>> spreadsheet systems depended on in the same directory as the spreadsheet
>> and it 'just worked', which isn't the case with the IronPython 2 port.
>>
>> Even if it isn't always guaranteed to be correct, the old behaviour was
>> much better for us. :-)
>>
>> Thanks
>>
>> Michael
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tom Wright
>>> Sent: Friday, January 30, 2009 10:34 AM
>>> To: Discussion of IronPython
>>> Subject: [IronPython] Two engines and clr.AddReference don't work together.
>>>
>>> Hi,
>>>
>>> Having two engines in the same AppDomain causes interesting behaviour
>>> when trying trying to add references.
>>>
>>> Only the sys.path of the first engine that was created seems to be taken
>>> into account when calling clr.AddReference, the second sys.path is ignored.
>>>
>>> See
>>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20921
>>> for more details and a repro.
>>>
>>> Tom Wright
>>> Resolver Systems Ltd.
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 

-- 
Orestis Markou
Software Engineer,
Resolver Systems Ltd.
orestis at resolversystems.com
+44 (0) 20 7253 6372



From ctrachte at gmail.com  Thu Feb  5 21:50:36 2009
From: ctrachte at gmail.com (Carl Trachte)
Date: Thu, 5 Feb 2009 13:50:36 -0700
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <21857504.post@talk.nabble.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
	<21857504.post@talk.nabble.com>
Message-ID: <426ada670902051250o3a73c6cej7d0a1737ba282cef@mail.gmail.com>

Rob,

I posted the original article in the cookbook.  Sorry it has caused
you some grief.

At the time I was working with IronPython 1.1.  Not sure if this had
anything to do the problems you encountered.  I did not test this on
Mono and I apologize for the implicit suggestion that it would work
there.

I'll dig out the code from the project I was working on and try to
resurrect the mini-module I wrote.

Carl T.

On Thu, Feb 5, 2009 at 11:01 AM, Rob Weiss <rweiss at chesapeakebay.net> wrote:
>
> The C# code I have works when compiled and run on a windows machine. It does
> not work on the RHEL box under mono. So I was trying to see if mono was the
> issue.
>
> Trying to eliminate the mono question, I downloaded IP's latest version
> installed on my windows dev box and ran the script I listed in my earlier
> post.
>
> The IP code I have to run the ssis package does not run and returns the
> error. I have copied the DLLs you listed below into the run directory, and
> still get the error.
>
> I am wondering if it is a config issue, but I get the exact same error on my
> dev box and my prod box when running the C# code under mono.
>
> When running the IP under mono to kick off the ssis package, I get the error
> I listed in the prev post. Even if I run the IP from a command prompt to
> kick off the ssis package (not under mono) I get the same error.
>
> Thanks for your response, but I still have the issue!!
>
>
>
> Bill Fellows wrote:
>>
>> Far from an expert here, but could you be missing an assembly?  I have
>> a C# app that builds SSIS packages programatically and I have
>> references to
>>
>> Microsoft.SqlServer.DTSPipelineWrap
>> Microsoft.SqlServer.DTSRuntimeWrap
>> Microsoft.SqlServer.ManagedDTS
>>
>> /bill
>> _______________________________________________
>> 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/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21857504.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
>


From ctrachte at gmail.com  Thu Feb  5 22:11:21 2009
From: ctrachte at gmail.com (Carl Trachte)
Date: Thu, 5 Feb 2009 14:11:21 -0700
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <426ada670902051250o3a73c6cej7d0a1737ba282cef@mail.gmail.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
	<21857504.post@talk.nabble.com>
	<426ada670902051250o3a73c6cej7d0a1737ba282cef@mail.gmail.com>
Message-ID: <426ada670902051311y1372e314tc91b0a77d383685f@mail.gmail.com>

I had a look at the script.  It is still running in a .Net 2.0
environment with IronPython 1.1.  Since it is a production script and
I do not own the environment, it will take me a bit to upgrade it to
IronPython 2.0.

In the meantime, I will put a disclaimer in the recipe.  Michael, if
you feel it best to take the posting down, that is OK too.

Again, sorry for the trouble.

Carl T.

On Thu, Feb 5, 2009 at 1:50 PM, Carl Trachte <ctrachte at gmail.com> wrote:
> Rob,
>
> I posted the original article in the cookbook.  Sorry it has caused
> you some grief.
>
> At the time I was working with IronPython 1.1.  Not sure if this had
> anything to do the problems you encountered.  I did not test this on
> Mono and I apologize for the implicit suggestion that it would work
> there.
>
> I'll dig out the code from the project I was working on and try to
> resurrect the mini-module I wrote.
>
> Carl T.
>
> On Thu, Feb 5, 2009 at 11:01 AM, Rob Weiss <rweiss at chesapeakebay.net> wrote:
>>
>> The C# code I have works when compiled and run on a windows machine. It does
>> not work on the RHEL box under mono. So I was trying to see if mono was the
>> issue.
>>
>> Trying to eliminate the mono question, I downloaded IP's latest version
>> installed on my windows dev box and ran the script I listed in my earlier
>> post.
>>
>> The IP code I have to run the ssis package does not run and returns the
>> error. I have copied the DLLs you listed below into the run directory, and
>> still get the error.
>>
>> I am wondering if it is a config issue, but I get the exact same error on my
>> dev box and my prod box when running the C# code under mono.
>>
>> When running the IP under mono to kick off the ssis package, I get the error
>> I listed in the prev post. Even if I run the IP from a command prompt to
>> kick off the ssis package (not under mono) I get the same error.
>>
>> Thanks for your response, but I still have the issue!!
>>
>>
>>
>> Bill Fellows wrote:
>>>
>>> Far from an expert here, but could you be missing an assembly?  I have
>>> a C# app that builds SSIS packages programatically and I have
>>> references to
>>>
>>> Microsoft.SqlServer.DTSPipelineWrap
>>> Microsoft.SqlServer.DTSRuntimeWrap
>>> Microsoft.SqlServer.ManagedDTS
>>>
>>> /bill
>>> _______________________________________________
>>> 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/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21857504.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
>>
>


From tenaciousb at gmail.com  Fri Feb  6 06:38:08 2009
From: tenaciousb at gmail.com (Bill Fellows)
Date: Thu, 5 Feb 2009 23:38:08 -0600
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <426ada670902051311y1372e314tc91b0a77d383685f@mail.gmail.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
	<21857504.post@talk.nabble.com>
	<426ada670902051250o3a73c6cej7d0a1737ba282cef@mail.gmail.com>
	<426ada670902051311y1372e314tc91b0a77d383685f@mail.gmail.com>
Message-ID: <559e28300902052138k3dbaa5ep110c220f01e45d84@mail.gmail.com>

I have not read the article about SSIS and mono but I did have an XP
machine with .NET 3.5 installed on as well as a development edition of
SQL Server 2005.  I grabbed the latest versions of IP 1.1 and 2.0 from
codeplex and created a simple SSIS package that had a single script
task with a hello world message box.  I can run the package fine from
the command line (dtexec) and I can invoke it via your supplied python
script with both version of IP and it has no issues.

Having not touched Mono before, I assume that I merely click the Mono
2.2 Command prompt and invoke my IP the same way.  Assuming that is
correct, I achieve the same results as above.

Given that you have the error in both mono and MS's supplied run time,
I suspect your issue is a lack of SQL Server.  From my time on the
msdn forums for SSIS, a recurring theme was that people wanted to
provide packages as solutions to be run on boxes without having SQL
Server installed.  Perhaps it's just a licensing thing and there's no
real trick to it beyond having the DLLs, but the common respone there
was that it was not possible to run packages where the database was
not installed.  I don't have any environments to test against that
don't have SQL Server on it to prove/disprove that notion but
otherwise I'd be happy to try and help out if there is anything you'd
like for me to try.

/bill


From rweiss at chesapeakebay.net  Fri Feb  6 13:08:46 2009
From: rweiss at chesapeakebay.net (Rob Weiss)
Date: Fri, 6 Feb 2009 04:08:46 -0800 (PST)
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <559e28300902052138k3dbaa5ep110c220f01e45d84@mail.gmail.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
	<21857504.post@talk.nabble.com>
	<426ada670902051250o3a73c6cej7d0a1737ba282cef@mail.gmail.com>
	<426ada670902051311y1372e314tc91b0a77d383685f@mail.gmail.com>
	<559e28300902052138k3dbaa5ep110c220f01e45d84@mail.gmail.com>
Message-ID: <21871242.post@talk.nabble.com>


Carl,
Thanks for the help, looking forward to the update.

Bill,
I can get the package to run fine using dtsexec and it runs in VS BIS IDE,
It also runs with a C# app I wrote, so I am not having an issue other than
trying to get it to run under IP (on either a windows dev box with
everything installed, or the prod Red Hat Enterprise box) or IP on mono
(same boxes) using the supplied script. Carl posted a msg stating that he
was going to dust off the code and review a couple of things and get back to
us.

Thanks.
-- 
View this message in context: http://www.nabble.com/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21871242.html
Sent from the IronPython mailing list archive at Nabble.com.



From vinjvinj at gmail.com  Fri Feb  6 22:24:04 2009
From: vinjvinj at gmail.com (Vineet Jain (gmail))
Date: Fri, 6 Feb 2009 16:24:04 -0500
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
In-Reply-To: <498891DC.3010008@resolversystems.com>
References: <498891DC.3010008@resolversystems.com>
Message-ID: <005e01c988a1$3da36380$b8ea2a80$@com>

Hi Giles,

Do you know where I can download the beta from?

Vineet


-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Giles Thomas
Sent: Tuesday, February 03, 2009 1:50 PM
To: IronPython list
Subject: [IronPython] Resolver One 1.4 beta - with IronPython 2.0

Hi all,

Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on 
IronPython 2.0, and includes (alpha-level) support for numpy using our 
Ironclad project. 

We're releasing the beta tomorrow: this has a few performance problems 
(which are being addressed - many thanks to Dino Viehland for helping 
with this!) but is otherwise functionally complete.  If you're 
interested in trying it out, drop me a line!


Best regards,

Giles
-- 

Giles Thomas
MD & CTO, Resolver Systems Ltd.
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

Win up to $17,000 for a spreadsheet:
<http://www.resolversystems.com/competition/>

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 at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From jslutter at reactorzero.com  Sat Feb  7 05:48:00 2009
From: jslutter at reactorzero.com (Jeff Slutter)
Date: Fri, 06 Feb 2009 23:48:00 -0500
Subject: [IronPython] repr() results with uint, etc.
Message-ID: <498D1280.4090507@reactorzero.com>

I have functions (in C#) that return results as everything from byte,
sbyte, System.UInt16, int, uint, float, etc.

If I use repr() on the returned value within IP2.0 only bool, int,
int64, float, double and string types print out a nice value using repr.

The other types (byte, char, sbyte, uint16, int16, uint, uint64) all
print out like:
<System.UInt32 object at 0x000000000000002B [5]>


Is there a way to get repr to print out a nice result like int types?
(some way from inside IronPython, a different version of repr?)

Thanks,
Jeff


From dinov at microsoft.com  Sat Feb  7 06:05:27 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 6 Feb 2009 21:05:27 -0800
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <498D1280.4090507@reactorzero.com>
References: <498D1280.4090507@reactorzero.com>
Message-ID: <350E7D38B6D819428718949920EC235557199D75B5@NA-EXMSG-C102.redmond.corp.microsoft.com>

There's no existing functionality to do this but we could add __repr__ overloads onto the built-in types.  They would presumably return something like:

System.UInt32(1)

or:

UInt32(1)

Could you open a bug?

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Slutter
Sent: Friday, February 06, 2009 8:48 PM
To: Discussion of IronPython
Subject: [IronPython] repr() results with uint, etc.

I have functions (in C#) that return results as everything from byte,
sbyte, System.UInt16, int, uint, float, etc.

If I use repr() on the returned value within IP2.0 only bool, int,
int64, float, double and string types print out a nice value using repr.

The other types (byte, char, sbyte, uint16, int16, uint, uint64) all
print out like:
<System.UInt32 object at 0x000000000000002B [5]>


Is there a way to get repr to print out a nice result like int types?
(some way from inside IronPython, a different version of repr?)

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


From jslutter at reactorzero.com  Sat Feb  7 06:32:32 2009
From: jslutter at reactorzero.com (Jeff Slutter)
Date: Sat, 07 Feb 2009 00:32:32 -0500
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <498D1280.4090507@reactorzero.com>
References: <498D1280.4090507@reactorzero.com>
Message-ID: <498D1CF0.1080302@reactorzero.com>

Ok, looking at the source, I see the issue in:

public static string Repr(CodeContext/*!*/ context, object o)

Is it safe to add these types in to there like:
            if ((s = o as string) != null) return StringOps.__repr__(s);
            if (o is int) return Int32Ops.__repr__((int)o);
            if (o is uint) return ((uint)o).ToString();
            if (o is long) return ((long)o).ToString() + "L";
            if (o is ulong) return ((ulong)o).ToString() + "UL";
            if (o is byte) return ((byte)o).ToString();
            if (o is sbyte) return ((sbyte)o).ToString();
            if (o is char) return ((char)o).ToString();
            if (o is Int16) return ((Int16)o).ToString();
            if (o is UInt16) return ((UInt16)o).ToString();
?


Jeff Slutter wrote:
> I have functions (in C#) that return results as everything from byte,
> sbyte, System.UInt16, int, uint, float, etc.
> 
> If I use repr() on the returned value within IP2.0 only bool, int,
> int64, float, double and string types print out a nice value using repr.
> 
> The other types (byte, char, sbyte, uint16, int16, uint, uint64) all
> print out like:
> <System.UInt32 object at 0x000000000000002B [5]>
> 
> 
> Is there a way to get repr to print out a nice result like int types?
> (some way from inside IronPython, a different version of repr?)
> 
> Thanks,
> Jeff
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 



From curt at hagenlocher.org  Sat Feb  7 06:35:44 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Fri, 6 Feb 2009 21:35:44 -0800
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <498D1CF0.1080302@reactorzero.com>
References: <498D1280.4090507@reactorzero.com>
	<498D1CF0.1080302@reactorzero.com>
Message-ID: <d2155e360902062135t63ea649ak55d276f328ce659b@mail.gmail.com>

On Fri, Feb 6, 2009 at 9:32 PM, Jeff Slutter <jslutter at reactorzero.com> wrote:
> Ok, looking at the source, I see the issue in:
>
> public static string Repr(CodeContext/*!*/ context, object o)
>
> Is it safe to add these types in to there like:
>            if ((s = o as string) != null) return StringOps.__repr__(s);
>            if (o is int) return Int32Ops.__repr__((int)o);
>            if (o is uint) return ((uint)o).ToString();
>            if (o is long) return ((long)o).ToString() + "L";
>            if (o is ulong) return ((ulong)o).ToString() + "UL";
>            if (o is byte) return ((byte)o).ToString();
>            if (o is sbyte) return ((sbyte)o).ToString();
>            if (o is char) return ((char)o).ToString();
>            if (o is Int16) return ((Int16)o).ToString();
>            if (o is UInt16) return ((UInt16)o).ToString();
> ?

It's traditional (when possible) for repr to return a string
representation of something that can be typed into the interpreter to
get the original object back.  This is what distinguishes it from str.
 That's why Dino suggested the form he did.

--
Curt Hagenlocher
curt at hagenlocher.org


From dinov at microsoft.com  Sat Feb  7 06:51:04 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 6 Feb 2009 21:51:04 -0800
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <d2155e360902062135t63ea649ak55d276f328ce659b@mail.gmail.com>
References: <498D1280.4090507@reactorzero.com>
	<498D1CF0.1080302@reactorzero.com>
	<d2155e360902062135t63ea649ak55d276f328ce659b@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235557199D75BC@NA-EXMSG-C102.redmond.corp.microsoft.com>

And the correct change to the source code would be adding __repr__ methods to the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct formatting.  Presumably by updating the scripts that generate these types.  OTOH there's nothing particularly unsafe about your changes other then they don't match the normal convention for __repr__.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Friday, February 06, 2009 9:36 PM
To: Discussion of IronPython
Subject: Re: [IronPython] repr() results with uint, etc.

On Fri, Feb 6, 2009 at 9:32 PM, Jeff Slutter <jslutter at reactorzero.com> wrote:
> Ok, looking at the source, I see the issue in:
>
> public static string Repr(CodeContext/*!*/ context, object o)
>
> Is it safe to add these types in to there like:
>            if ((s = o as string) != null) return StringOps.__repr__(s);
>            if (o is int) return Int32Ops.__repr__((int)o);
>            if (o is uint) return ((uint)o).ToString();
>            if (o is long) return ((long)o).ToString() + "L";
>            if (o is ulong) return ((ulong)o).ToString() + "UL";
>            if (o is byte) return ((byte)o).ToString();
>            if (o is sbyte) return ((sbyte)o).ToString();
>            if (o is char) return ((char)o).ToString();
>            if (o is Int16) return ((Int16)o).ToString();
>            if (o is UInt16) return ((UInt16)o).ToString();
> ?

It's traditional (when possible) for repr to return a string
representation of something that can be typed into the interpreter to
get the original object back.  This is what distinguishes it from str.
 That's why Dino suggested the form he did.

--
Curt Hagenlocher
curt at hagenlocher.org
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From fuzzyman at voidspace.org.uk  Sat Feb  7 15:04:10 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 07 Feb 2009 14:04:10 +0000
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <350E7D38B6D819428718949920EC235557199D75BC@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <498D1280.4090507@reactorzero.com>	<498D1CF0.1080302@reactorzero.com>	<d2155e360902062135t63ea649ak55d276f328ce659b@mail.gmail.com>
	<350E7D38B6D819428718949920EC235557199D75BC@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <498D94DA.10405@voidspace.org.uk>

Dino Viehland wrote:
> And the correct change to the source code would be adding __repr__ methods to the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct formatting.  Presumably by updating the scripts that generate these types.  OTOH there's nothing particularly unsafe about your changes other then they don't match the normal convention for __repr__.
>   

+1 for the changes.

There are various other minor places where uints don't behave like 
numbers, which would be nice to address - especially for Ironclad (and 
making 64bit support a bit less painful for William).

Michael

Michael Foord
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
> Sent: Friday, February 06, 2009 9:36 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] repr() results with uint, etc.
>
> On Fri, Feb 6, 2009 at 9:32 PM, Jeff Slutter <jslutter at reactorzero.com> wrote:
>   
>> Ok, looking at the source, I see the issue in:
>>
>> public static string Repr(CodeContext/*!*/ context, object o)
>>
>> Is it safe to add these types in to there like:
>>            if ((s = o as string) != null) return StringOps.__repr__(s);
>>            if (o is int) return Int32Ops.__repr__((int)o);
>>            if (o is uint) return ((uint)o).ToString();
>>            if (o is long) return ((long)o).ToString() + "L";
>>            if (o is ulong) return ((ulong)o).ToString() + "UL";
>>            if (o is byte) return ((byte)o).ToString();
>>            if (o is sbyte) return ((sbyte)o).ToString();
>>            if (o is char) return ((char)o).ToString();
>>            if (o is Int16) return ((Int16)o).ToString();
>>            if (o is UInt16) return ((UInt16)o).ToString();
>> ?
>>     
>
> It's traditional (when possible) for repr to return a string
> representation of something that can be typed into the interpreter to
> get the original object back.  This is what distinguishes it from str.
>  That's why Dino suggested the form he did.
>
> --
> Curt Hagenlocher
> curt at hagenlocher.org
> _______________________________________________
> 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 jslutter at reactorzero.com  Sat Feb  7 16:35:10 2009
From: jslutter at reactorzero.com (Jeff Slutter)
Date: Sat, 07 Feb 2009 10:35:10 -0500
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <350E7D38B6D819428718949920EC235557199D75BC@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <498D1280.4090507@reactorzero.com>	<498D1CF0.1080302@reactorzero.com>	<d2155e360902062135t63ea649ak55d276f328ce659b@mail.gmail.com>
	<350E7D38B6D819428718949920EC235557199D75BC@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <498DAA2E.1030602@reactorzero.com>

I totally agree that it should be done the right way - I didn't know
what the right way was.

CodePlex issue has been opened: 21040

Thanks!

Dino Viehland wrote:
> And the correct change to the source code would be adding __repr__ methods to the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct formatting.  Presumably by updating the scripts that generate these types.  OTOH there's nothing particularly unsafe about your changes other then they don't match the normal convention for __repr__.


From dinov at microsoft.com  Sat Feb  7 19:47:35 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 7 Feb 2009 10:47:35 -0800
Subject: [IronPython] repr() results with uint, etc.
In-Reply-To: <498D94DA.10405@voidspace.org.uk>
References: <498D1280.4090507@reactorzero.com>
	<498D1CF0.1080302@reactorzero.com>
	<d2155e360902062135t63ea649ak55d276f328ce659b@mail.gmail.com>
	<350E7D38B6D819428718949920EC235557199D75BC@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<498D94DA.10405@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC235557199D75DD@NA-EXMSG-C102.redmond.corp.microsoft.com>

At least one of those is now fixed in 2.0.1 & 2.6 (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=20632)

The other one I know of is __index__ support, are there more?  Seems like doing these all at once makes sense.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Saturday, February 07, 2009 6:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] repr() results with uint, etc.

Dino Viehland wrote:
> And the correct change to the source code would be adding __repr__ methods to the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct formatting.  Presumably by updating the scripts that generate these types.  OTOH there's nothing particularly unsafe about your changes other then they don't match the normal convention for __repr__.
>   

+1 for the changes.

There are various other minor places where uints don't behave like 
numbers, which would be nice to address - especially for Ironclad (and 
making 64bit support a bit less painful for William).

Michael

Michael Foord
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
> Sent: Friday, February 06, 2009 9:36 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] repr() results with uint, etc.
>
> On Fri, Feb 6, 2009 at 9:32 PM, Jeff Slutter <jslutter at reactorzero.com> wrote:
>   
>> Ok, looking at the source, I see the issue in:
>>
>> public static string Repr(CodeContext/*!*/ context, object o)
>>
>> Is it safe to add these types in to there like:
>>            if ((s = o as string) != null) return StringOps.__repr__(s);
>>            if (o is int) return Int32Ops.__repr__((int)o);
>>            if (o is uint) return ((uint)o).ToString();
>>            if (o is long) return ((long)o).ToString() + "L";
>>            if (o is ulong) return ((ulong)o).ToString() + "UL";
>>            if (o is byte) return ((byte)o).ToString();
>>            if (o is sbyte) return ((sbyte)o).ToString();
>>            if (o is char) return ((char)o).ToString();
>>            if (o is Int16) return ((Int16)o).ToString();
>>            if (o is UInt16) return ((UInt16)o).ToString();
>> ?
>>     
>
> It's traditional (when possible) for repr to return a string
> representation of something that can be typed into the interpreter to
> get the original object back.  This is what distinguishes it from str.
>  That's why Dino suggested the form he did.
>
> --
> Curt Hagenlocher
> curt at hagenlocher.org
> _______________________________________________
> 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 ctrachte at gmail.com  Mon Feb  9 17:19:50 2009
From: ctrachte at gmail.com (Carl Trachte)
Date: Mon, 9 Feb 2009 09:19:50 -0700
Subject: [IronPython] Problem with Thread.Sleep
Message-ID: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>

Hello.

I'm a bit late to the 2.0 party, but I'm trying to upgrade my environment.

This code fails:

>>> from System.Threading import Thread
>>> Thread.Sleep(3000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 61, in warn
  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 99, in
warn_explicit
TypeError: getlines() takes exactly 1 argument (2 given)

I'm not a threading expert.  Basically I want the program to pause for
a few seconds.  Am I doing something wrong, or do I have something set
up wrong?

Thanks in advance.

Carl T.


From fuzzyman at voidspace.org.uk  Mon Feb  9 17:21:35 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 09 Feb 2009 16:21:35 +0000
Subject: [IronPython] Problem with Thread.Sleep
In-Reply-To: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>
References: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>
Message-ID: <4990580F.8040504@voidspace.org.uk>

Carl Trachte wrote:
> Hello.
>
> I'm a bit late to the 2.0 party, but I'm trying to upgrade my environment.
>
> This code fails:
>
>   
>>>> from System.Threading import Thread
>>>> Thread.Sleep(3000)
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 61, in warn
>   File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 99, in
> warn_explicit
> TypeError: getlines() takes exactly 1 argument (2 given)
>
> I'm not a threading expert.  Basically I want the program to pause for
> a few seconds.  Am I doing something wrong, or do I have something set
> up wrong?
>
> Thanks in advance.
>
>   

Thread.CurrentThread.Join(3000) will have the same effect, but that is a 
very odd error.

Michael

> Carl T.
> _______________________________________________
> 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 ctrachte at gmail.com  Mon Feb  9 17:26:13 2009
From: ctrachte at gmail.com (Carl Trachte)
Date: Mon, 9 Feb 2009 09:26:13 -0700
Subject: [IronPython] Problem with Thread.Sleep
In-Reply-To: <4990580F.8040504@voidspace.org.uk>
References: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>
	<4990580F.8040504@voidspace.org.uk>
Message-ID: <426ada670902090826w40281175ra2d57df213b0ab1c@mail.gmail.com>

Michael,
You are a hero.  Thanks.
Carl T.

On Mon, Feb 9, 2009 at 9:21 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Carl Trachte wrote:
>>
>> Hello.
>>
>> I'm a bit late to the 2.0 party, but I'm trying to upgrade my environment.
>>
>> This code fails:
>>
>>
>>>>>
>>>>> from System.Threading import Thread
>>>>> Thread.Sleep(3000)
>>>>>
>>
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in <module>
>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 61, in warn
>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 99, in
>> warn_explicit
>> TypeError: getlines() takes exactly 1 argument (2 given)
>>
>> I'm not a threading expert.  Basically I want the program to pause for
>> a few seconds.  Am I doing something wrong, or do I have something set
>> up wrong?
>>
>> Thanks in advance.
>>
>>
>
> Thread.CurrentThread.Join(3000) will have the same effect, but that is a
> very odd error.
>
> Michael
>
>> Carl T.
>> _______________________________________________
>> 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 Feb  9 18:32:49 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 9 Feb 2009 09:32:49 -0800
Subject: [IronPython] Problem with Thread.Sleep
In-Reply-To: <426ada670902090826w40281175ra2d57df213b0ab1c@mail.gmail.com>
References: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>
	<4990580F.8040504@voidspace.org.uk>
	<426ada670902090826w40281175ra2d57df213b0ab1c@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC235557199D77D6@NA-EXMSG-C102.redmond.corp.microsoft.com>

Or if your program has no UI components you can start with the -X:MTA option and the warning won't get issued.

Unfortunately the 2nd you hit a different warning it's likely you'll have the same problem.  So the underlying problem looks like we're somehow picking up a different linecache.py or that linecache's getlines method is being patched.   If you're sure neither of those are happening then my only guess would be that we could have a call site caching bug but against a function that seems fairly unlikely.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Carl Trachte
Sent: Monday, February 09, 2009 8:26 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Problem with Thread.Sleep

Michael,
You are a hero.  Thanks.
Carl T.

On Mon, Feb 9, 2009 at 9:21 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Carl Trachte wrote:
>>
>> Hello.
>>
>> I'm a bit late to the 2.0 party, but I'm trying to upgrade my environment.
>>
>> This code fails:
>>
>>
>>>>>
>>>>> from System.Threading import Thread
>>>>> Thread.Sleep(3000)
>>>>>
>>
>> Traceback (most recent call last):
>>  File "<stdin>", line 1, in <module>
>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 61, in warn
>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 99, in
>> warn_explicit
>> TypeError: getlines() takes exactly 1 argument (2 given)
>>
>> I'm not a threading expert.  Basically I want the program to pause for
>> a few seconds.  Am I doing something wrong, or do I have something set
>> up wrong?
>>
>> Thanks in advance.
>>
>>
>
> Thread.CurrentThread.Join(3000) will have the same effect, but that is a
> very odd error.
>
> Michael
>
>> Carl T.
>> _______________________________________________
>> 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


From fuzzyman at voidspace.org.uk  Mon Feb  9 18:44:01 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 09 Feb 2009 17:44:01 +0000
Subject: [IronPython] Problem with Thread.Sleep
In-Reply-To: <350E7D38B6D819428718949920EC235557199D77D6@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>	<4990580F.8040504@voidspace.org.uk>	<426ada670902090826w40281175ra2d57df213b0ab1c@mail.gmail.com>
	<350E7D38B6D819428718949920EC235557199D77D6@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <49906B61.8060406@voidspace.org.uk>

Dino Viehland wrote:
> Or if your program has no UI components you can start with the -X:MTA option and the warning won't get issued.
>
> Unfortunately the 2nd you hit a different warning it's likely you'll have the same problem.  So the underlying problem looks like we're somehow picking up a different linecache.py or that linecache's getlines method is being patched.   If you're sure neither of those are happening then my only guess would be that we could have a call site caching bug but against a function that seems fairly unlikely.
>   

I have a sneaking suspicion that this error happens if you use the 
Python 2.4 version of linecache. Is the Python 2.4 standard library (or 
bits of it!?!?) somehow on your IRONPYTHONPATH or included in your 
application?

Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Carl Trachte
> Sent: Monday, February 09, 2009 8:26 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Problem with Thread.Sleep
>
> Michael,
> You are a hero.  Thanks.
> Carl T.
>
> On Mon, Feb 9, 2009 at 9:21 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>   
>> Carl Trachte wrote:
>>     
>>> Hello.
>>>
>>> I'm a bit late to the 2.0 party, but I'm trying to upgrade my environment.
>>>
>>> This code fails:
>>>
>>>
>>>       
>>>>>> from System.Threading import Thread
>>>>>> Thread.Sleep(3000)
>>>>>>
>>>>>>             
>>> Traceback (most recent call last):
>>>  File "<stdin>", line 1, in <module>
>>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 61, in warn
>>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 99, in
>>> warn_explicit
>>> TypeError: getlines() takes exactly 1 argument (2 given)
>>>
>>> I'm not a threading expert.  Basically I want the program to pause for
>>> a few seconds.  Am I doing something wrong, or do I have something set
>>> up wrong?
>>>
>>> Thanks in advance.
>>>
>>>
>>>       
>> Thread.CurrentThread.Join(3000) will have the same effect, but that is a
>> very odd error.
>>
>> Michael
>>
>>     
>>> Carl T.
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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 dan.eloff at gmail.com  Mon Feb  9 20:17:49 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Mon, 9 Feb 2009 14:17:49 -0500
Subject: [IronPython] Any idea what might cause this?
Message-ID: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>

Hi IronPython team,

Occasionally, when importing one particular module on a background
thread I get this error:

SystemError: Collection was modified; enumeration operation may not execute.

The offending line is:

class SerializeCustom(_custom_base):

And _custom_base is defined earlier in the module as:

from mycsharpassembly import *
_custom_base = Serializers.SerializeCustom # from assembly

The problem is a real pain to replicate (i.e. me refreshing the
browser about 100 times) Hopefully someone will have an idea what
could cause this. I'm using build 44619, main (2.1 now 2.6) branch.

Thanks,
-Dan


From ctrachte at gmail.com  Mon Feb  9 20:39:13 2009
From: ctrachte at gmail.com (Carl Trachte)
Date: Mon, 9 Feb 2009 12:39:13 -0700
Subject: [IronPython] Problem with Thread.Sleep
In-Reply-To: <49906B61.8060406@voidspace.org.uk>
References: <426ada670902090819i5edc677es79d5d5d47e68680a@mail.gmail.com>
	<4990580F.8040504@voidspace.org.uk>
	<426ada670902090826w40281175ra2d57df213b0ab1c@mail.gmail.com>
	<350E7D38B6D819428718949920EC235557199D77D6@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49906B61.8060406@voidspace.org.uk>
Message-ID: <426ada670902091139h7385dd3eqd4793cc4af45953d@mail.gmail.com>

On Mon, Feb 9, 2009 at 10:44 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Dino Viehland wrote:
>>
>> Or if your program has no UI components you can start with the -X:MTA
>> option and the warning won't get issued.
>>
>> Unfortunately the 2nd you hit a different warning it's likely you'll have
>> the same problem.  So the underlying problem looks like we're somehow
>> picking up a different linecache.py or that linecache's getlines method is
>> being patched.   If you're sure neither of those are happening then my only
>> guess would be that we could have a call site caching bug but against a
>> function that seems fairly unlikely.
>>
>
> I have a sneaking suspicion that this error happens if you use the Python
> 2.4 version of linecache. Is the Python 2.4 standard library (or bits of
> it!?!?) somehow on your IRONPYTHONPATH or included in your application?
>
> Michael

Michael, Dino,
You are both right (and heroes, of course).  I had neglected to update
my CPython modules in my project to 2.5.  I put the new 2.5
linecache.py in the project.  The first call doesn't execute, but it
doesn't raise an error, just a warning:

>>> from System.Threading import Thread
>>> Thread.Sleep(4000)
sys:1: RuntimeWarning: Calling Thread.Sleep on and STA thread doesn't
pump messages.  Use Thread.CurrentThread.Join instead.
>>> # second try
>>> Thread.Sleep(4000)
>>> # paused for 4 seconds with no warning.

Carl T.

>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com
>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Carl Trachte
>> Sent: Monday, February 09, 2009 8:26 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Problem with Thread.Sleep
>>
>> Michael,
>> You are a hero.  Thanks.
>> Carl T.
>>
>> On Mon, Feb 9, 2009 at 9:21 AM, Michael Foord <fuzzyman at voidspace.org.uk>
>> wrote:
>>
>>>
>>> Carl Trachte wrote:
>>>
>>>>
>>>> Hello.
>>>>
>>>> I'm a bit late to the 2.0 party, but I'm trying to upgrade my
>>>> environment.
>>>>
>>>> This code fails:
>>>>
>>>>
>>>>
>>>>>>>
>>>>>>> from System.Threading import Thread
>>>>>>> Thread.Sleep(3000)
>>>>>>>
>>>>>>>
>>>>
>>>> Traceback (most recent call last):
>>>>  File "<stdin>", line 1, in <module>
>>>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 61, in
>>>> warn
>>>>  File "C:\Program Files\IronPython 2.0\Lib\warnings.py", line 99, in
>>>> warn_explicit
>>>> TypeError: getlines() takes exactly 1 argument (2 given)
>>>>
>>>> I'm not a threading expert.  Basically I want the program to pause for
>>>> a few seconds.  Am I doing something wrong, or do I have something set
>>>> up wrong?
>>>>
>>>> Thanks in advance.
>>>>
>>>>
>>>>
>>>
>>> Thread.CurrentThread.Join(3000) will have the same effect, but that is a
>>> very odd error.
>>>
>>> Michael
>>>
>>>
>>>>
>>>> Carl T.
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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  Mon Feb  9 21:53:22 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 09 Feb 2009 20:53:22 +0000
Subject: [IronPython] Any idea what might cause this?
In-Reply-To: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>
References: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>
Message-ID: <499097C2.5010307@voidspace.org.uk>

Dan Eloff wrote:
> Hi IronPython team,
>
> Occasionally, when importing one particular module on a background
> thread I get this error:
>
> SystemError: Collection was modified; enumeration operation may not execute.
>
> The offending line is:
>
> class SerializeCustom(_custom_base):
>
> And _custom_base is defined earlier in the module as:
>
> from mycsharpassembly import *
> _custom_base = Serializers.SerializeCustom # from assembly
>
> The problem is a real pain to replicate (i.e. me refreshing the
> browser about 100 times) Hopefully someone will have an idea what
> could cause this. I'm using build 44619, main (2.1 now 2.6) branch.
>   

It looks like importing is still not thread safe - but I guess that bit 
is obvious. I'll leave it to Dino or Curt for a more in depth analysis. :-)

I wonder if a debug build of IronPython for Silverlight would get you 
more information.

Michael

> Thanks,
> -Dan
> _______________________________________________
> 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  Mon Feb  9 22:09:47 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 9 Feb 2009 13:09:47 -0800
Subject: [IronPython] Any idea what might cause this?
In-Reply-To: <499097C2.5010307@voidspace.org.uk>
References: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>
	<499097C2.5010307@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC235557199D79A0@NA-EXMSG-C102.redmond.corp.microsoft.com>

I would suggest enabling exception detail and getting the stack trace from there if you can.  The problem is probably a .NET list or a dict somewhere that we're both updating an iterating over at the same time.  But it's hard to know what list/dict that is without the stack trace.  But a full stack trace will lead us right to the problem and it should be easy to fix.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, February 09, 2009 12:53 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Any idea what might cause this?

Dan Eloff wrote:
> Hi IronPython team,
>
> Occasionally, when importing one particular module on a background
> thread I get this error:
>
> SystemError: Collection was modified; enumeration operation may not execute.
>
> The offending line is:
>
> class SerializeCustom(_custom_base):
>
> And _custom_base is defined earlier in the module as:
>
> from mycsharpassembly import *
> _custom_base = Serializers.SerializeCustom # from assembly
>
> The problem is a real pain to replicate (i.e. me refreshing the
> browser about 100 times) Hopefully someone will have an idea what
> could cause this. I'm using build 44619, main (2.1 now 2.6) branch.
>   

It looks like importing is still not thread safe - but I guess that bit 
is obvious. I'll leave it to Dino or Curt for a more in depth analysis. :-)

I wonder if a debug build of IronPython for Silverlight would get you 
more information.

Michael

> Thanks,
> -Dan
> _______________________________________________
> 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 pierrejules.tremblay at gmail.com  Mon Feb  9 22:20:11 2009
From: pierrejules.tremblay at gmail.com (Pierre-Jules Tremblay)
Date: Mon, 9 Feb 2009 16:20:11 -0500
Subject: [IronPython] second attempt: problem with import, packages,
	and IronPython 1.1
Message-ID: <4590bfef0902091320q4fca5d2by94a04c7403841701@mail.gmail.com>

Hello IronPython team,

This did not seem to hit home with anyone, but I thought I'd try
again.  We'd like to avoid having to upgrade to IronPython 2.0 unless
it's absolutely necessary.

Hopefully someone can point me to documentation that can help me solve
on my own?  I haven't been able to find anything relevant.

Cheers,

pj

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

We embedded IronPython 1.1 in our application.  Unfortunately I am running
into problems accessing .NET assemblies in Python.

In one situation, if I create a module (let's call it mymodule.py) and put
it in sys.path, with the following code in it:

import clr
clr.AddReference('System')
from System.Diagnostics import Process

def foo():
     p = Process()
     return p

and then send the IronPython interpreter a script that imports mymodule and
calls foo(), everything works fine:

import mymodule
p = mymodule.foo()

However, if mymodule.py is "packaged" in a subdirectory, let's say "subdir",
which is in the search path as well and has an empty __init__.py file,
thinks break:

import subdir.mymodule
p = subdir.mymodule.foo()

I get: "ImportError: can't find module named Diagnostics".  It's as though
the fact that I've "packaged" the module in a directory breaks the way
IronPython gives me bindings to the .NET assemblies...  Why should this
break?  Am I doing something wrong?

Help!

pj


From dinov at microsoft.com  Tue Feb 10 01:49:38 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 9 Feb 2009 16:49:38 -0800
Subject: [IronPython] second attempt: problem with import, packages,
 and IronPython 1.1
In-Reply-To: <4590bfef0902091320q4fca5d2by94a04c7403841701@mail.gmail.com>
References: <4590bfef0902091320q4fca5d2by94a04c7403841701@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23555719DDBBA2@NA-EXMSG-C102.redmond.corp.microsoft.com>

If I setup this as you describe from the command line it just works:

x\
	subdir\
		__init__.py
		mymodule.py:
			import clr
			clr.AddReference('System')
			from System.Diagnostics import Process

			def foo():
     			p = Process()
			     return p

C:\Product\2\Merlin\Main > "C:\Program Files\IronPython-1.1.2\ipy.exe"
IronPython 1.1.2 (1.1.2) on .NET 2.0.50727.3521
Copyright (c) Microsoft Corporation. All rights reserved.
>>> import sys
>>> sys.path.append(r'C:/Product/2/Merlin/Main/x')
>>> import subdir.mymodule
>>> subdir.mymodule.foo()
<System.Diagnostics.Process object at 0x000000000000002B [System.Diagnostics.Process]>

The only thing I could think of is that clr.AddReference('System') is somehow picking up the wrong System.dll or System.exe.  You could try to run fuslogvw.exe and see what assemblies are getting picked up and where from, or you could just try changing the add reference to:

clr.AddReference("System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL")

which should always deterministically get the right assembly.  Alternately you could even try this from your hosting code:

engine.LoadAssembly(typeof(System.Diagnostics.Process).Assembly);

I don't remember whether we automatically loaded System.dll for you in 1.x or not so I don't know if that's necessary or not.  I'd also suggest doing a dir(System) to see what it prints out to see if there's a common theme amongst missing assemblies.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pierre-Jules Tremblay
Sent: Monday, February 09, 2009 1:20 PM
To: users at lists.ironpython.com
Subject: [IronPython] second attempt: problem with import, packages, and IronPython 1.1

Hello IronPython team,

This did not seem to hit home with anyone, but I thought I'd try
again.  We'd like to avoid having to upgrade to IronPython 2.0 unless
it's absolutely necessary.

Hopefully someone can point me to documentation that can help me solve
on my own?  I haven't been able to find anything relevant.

Cheers,

pj

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

We embedded IronPython 1.1 in our application.  Unfortunately I am running
into problems accessing .NET assemblies in Python.

In one situation, if I create a module (let's call it mymodule.py) and put
it in sys.path, with the following code in it:

import clr
clr.AddReference('System')
from System.Diagnostics import Process

def foo():
     p = Process()
     return p

and then send the IronPython interpreter a script that imports mymodule and
calls foo(), everything works fine:

import mymodule
p = mymodule.foo()

However, if mymodule.py is "packaged" in a subdirectory, let's say "subdir",
which is in the search path as well and has an empty __init__.py file,
thinks break:

import subdir.mymodule
p = subdir.mymodule.foo()

I get: "ImportError: can't find module named Diagnostics".  It's as though
the fact that I've "packaged" the module in a directory breaks the way
IronPython gives me bindings to the .NET assemblies...  Why should this
break?  Am I doing something wrong?

Help!

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



From pierrejules.tremblay at gmail.com  Tue Feb 10 02:51:44 2009
From: pierrejules.tremblay at gmail.com (Pierre-Jules Tremblay)
Date: Mon, 9 Feb 2009 20:51:44 -0500
Subject: [IronPython] second attempt: problem with import, packages,
	and 	IronPython 1.1
In-Reply-To: <350E7D38B6D819428718949920EC23555719DDBBA2@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4590bfef0902091320q4fca5d2by94a04c7403841701@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555719DDBBA2@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4590bfef0902091751g30a6a849l1bf665efec85c36e@mail.gmail.com>

Eureka - I'm an idiot.

Thanks for suggesting the simple trick of printing out the result of
dir(System).  I should have thought of that earlier.

Turns out the problem is that there is a module named system.py (all
lowercase) in the same subdirectory (or package) as the module I was
trying to import. I did not anticipate this behaviour, even on
Windows, as a Python 2.4 shell will happily import System.py and
system.py as different modules, provided they are in separate
directories of course.  That should be easy to fix, although there is
a lot of legacy CPython code depending on that unfortunately-named
'system.py' module.

So the IronPython behaviour appears to be different from CPython.  Is
that still true in 2.0?

Thank you very much for your help, and apologies for wasting your time.

pj

On Mon, Feb 9, 2009 at 7:49 PM, Dino Viehland <dinov at microsoft.com> wrote:
> If I setup this as you describe from the command line it just works:
>
> x\
>        subdir\
>                __init__.py
>                mymodule.py:
>                        import clr
>                        clr.AddReference('System')
>                        from System.Diagnostics import Process
>
>                        def foo():
>                        p = Process()
>                             return p
>
> C:\Product\2\Merlin\Main > "C:\Program Files\IronPython-1.1.2\ipy.exe"
> IronPython 1.1.2 (1.1.2) on .NET 2.0.50727.3521
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import sys
>>>> sys.path.append(r'C:/Product/2/Merlin/Main/x')
>>>> import subdir.mymodule
>>>> subdir.mymodule.foo()
> <System.Diagnostics.Process object at 0x000000000000002B [System.Diagnostics.Process]>
>
> The only thing I could think of is that clr.AddReference('System') is somehow picking up the wrong System.dll or System.exe.  You could try to run fuslogvw.exe and see what assemblies are getting picked up and where from, or you could just try changing the add reference to:
>
> clr.AddReference("System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL")
>
> which should always deterministically get the right assembly.  Alternately you could even try this from your hosting code:
>
> engine.LoadAssembly(typeof(System.Diagnostics.Process).Assembly);
>
> I don't remember whether we automatically loaded System.dll for you in 1.x or not so I don't know if that's necessary or not.  I'd also suggest doing a dir(System) to see what it prints out to see if there's a common theme amongst missing assemblies.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pierre-Jules Tremblay
> Sent: Monday, February 09, 2009 1:20 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] second attempt: problem with import, packages, and IronPython 1.1
>
> Hello IronPython team,
>
> This did not seem to hit home with anyone, but I thought I'd try
> again.  We'd like to avoid having to upgrade to IronPython 2.0 unless
> it's absolutely necessary.
>
> Hopefully someone can point me to documentation that can help me solve
> on my own?  I haven't been able to find anything relevant.
>
> Cheers,
>
> pj
>
> ============
>
> We embedded IronPython 1.1 in our application.  Unfortunately I am running
> into problems accessing .NET assemblies in Python.
>
> In one situation, if I create a module (let's call it mymodule.py) and put
> it in sys.path, with the following code in it:
>
> import clr
> clr.AddReference('System')
> from System.Diagnostics import Process
>
> def foo():
>     p = Process()
>     return p
>
> and then send the IronPython interpreter a script that imports mymodule and
> calls foo(), everything works fine:
>
> import mymodule
> p = mymodule.foo()
>
> However, if mymodule.py is "packaged" in a subdirectory, let's say "subdir",
> which is in the search path as well and has an empty __init__.py file,
> thinks break:
>
> import subdir.mymodule
> p = subdir.mymodule.foo()
>
> I get: "ImportError: can't find module named Diagnostics".  It's as though
> the fact that I've "packaged" the module in a directory breaks the way
> IronPython gives me bindings to the .NET assemblies...  Why should this
> break?  Am I doing something wrong?
>
> Help!
>
> pj
> _______________________________________________
> 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  Tue Feb 10 03:29:55 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 9 Feb 2009 18:29:55 -0800
Subject: [IronPython] second attempt: problem with import, packages,
 and 	IronPython 1.1
In-Reply-To: <4590bfef0902091751g30a6a849l1bf665efec85c36e@mail.gmail.com>
References: <4590bfef0902091320q4fca5d2by94a04c7403841701@mail.gmail.com>
	<350E7D38B6D819428718949920EC23555719DDBBA2@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4590bfef0902091751g30a6a849l1bf665efec85c36e@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC23555719DDBC0E@NA-EXMSG-C102.redmond.corp.microsoft.com>

We fixed the case insensitivity issue in 2.0 so that might be incentive to upgrade :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pierre-Jules Tremblay
Sent: Monday, February 09, 2009 5:52 PM
To: Discussion of IronPython
Subject: Re: [IronPython] second attempt: problem with import, packages, and IronPython 1.1

Eureka - I'm an idiot.

Thanks for suggesting the simple trick of printing out the result of
dir(System).  I should have thought of that earlier.

Turns out the problem is that there is a module named system.py (all
lowercase) in the same subdirectory (or package) as the module I was
trying to import. I did not anticipate this behaviour, even on
Windows, as a Python 2.4 shell will happily import System.py and
system.py as different modules, provided they are in separate
directories of course.  That should be easy to fix, although there is
a lot of legacy CPython code depending on that unfortunately-named
'system.py' module.

So the IronPython behaviour appears to be different from CPython.  Is
that still true in 2.0?

Thank you very much for your help, and apologies for wasting your time.

pj

On Mon, Feb 9, 2009 at 7:49 PM, Dino Viehland <dinov at microsoft.com> wrote:
> If I setup this as you describe from the command line it just works:
>
> x\
>        subdir\
>                __init__.py
>                mymodule.py:
>                        import clr
>                        clr.AddReference('System')
>                        from System.Diagnostics import Process
>
>                        def foo():
>                        p = Process()
>                             return p
>
> C:\Product\2\Merlin\Main > "C:\Program Files\IronPython-1.1.2\ipy.exe"
> IronPython 1.1.2 (1.1.2) on .NET 2.0.50727.3521
> Copyright (c) Microsoft Corporation. All rights reserved.
>>>> import sys
>>>> sys.path.append(r'C:/Product/2/Merlin/Main/x')
>>>> import subdir.mymodule
>>>> subdir.mymodule.foo()
> <System.Diagnostics.Process object at 0x000000000000002B [System.Diagnostics.Process]>
>
> The only thing I could think of is that clr.AddReference('System') is somehow picking up the wrong System.dll or System.exe.  You could try to run fuslogvw.exe and see what assemblies are getting picked up and where from, or you could just try changing the add reference to:
>
> clr.AddReference("System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL")
>
> which should always deterministically get the right assembly.  Alternately you could even try this from your hosting code:
>
> engine.LoadAssembly(typeof(System.Diagnostics.Process).Assembly);
>
> I don't remember whether we automatically loaded System.dll for you in 1.x or not so I don't know if that's necessary or not.  I'd also suggest doing a dir(System) to see what it prints out to see if there's a common theme amongst missing assemblies.
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pierre-Jules Tremblay
> Sent: Monday, February 09, 2009 1:20 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] second attempt: problem with import, packages, and IronPython 1.1
>
> Hello IronPython team,
>
> This did not seem to hit home with anyone, but I thought I'd try
> again.  We'd like to avoid having to upgrade to IronPython 2.0 unless
> it's absolutely necessary.
>
> Hopefully someone can point me to documentation that can help me solve
> on my own?  I haven't been able to find anything relevant.
>
> Cheers,
>
> pj
>
> ============
>
> We embedded IronPython 1.1 in our application.  Unfortunately I am running
> into problems accessing .NET assemblies in Python.
>
> In one situation, if I create a module (let's call it mymodule.py) and put
> it in sys.path, with the following code in it:
>
> import clr
> clr.AddReference('System')
> from System.Diagnostics import Process
>
> def foo():
>     p = Process()
>     return p
>
> and then send the IronPython interpreter a script that imports mymodule and
> calls foo(), everything works fine:
>
> import mymodule
> p = mymodule.foo()
>
> However, if mymodule.py is "packaged" in a subdirectory, let's say "subdir",
> which is in the search path as well and has an empty __init__.py file,
> thinks break:
>
> import subdir.mymodule
> p = subdir.mymodule.foo()
>
> I get: "ImportError: can't find module named Diagnostics".  It's as though
> the fact that I've "packaged" the module in a directory breaks the way
> IronPython gives me bindings to the .NET assemblies...  Why should this
> break?  Am I doing something wrong?
>
> Help!
>
> pj
> _______________________________________________
> 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 dan.eloff at gmail.com  Tue Feb 10 07:24:59 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Tue, 10 Feb 2009 01:24:59 -0500
Subject: [IronPython] Any idea what might cause this?
In-Reply-To: <350E7D38B6D819428718949920EC235557199D79A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>
	<499097C2.5010307@voidspace.org.uk>
	<350E7D38B6D819428718949920EC235557199D79A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0902092224t6b72a612x8f40f2e5105a1e22@mail.gmail.com>

Hi Dino,

I modified the importing code a to spit out the CLR trace and to auto
refresh the browser if there is no error. 299 reloads later it crashed
because it ran out of memory, looks like IE/silverlight has a leak.
108 reloads after that I hit paydirt. There error was in another
module, but appears to be the same issue.

Good luck!
-Dan

CLR Exception: System.InvalidOperationException: Collection was
modified; enumeration operation may not execute.
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource
resource)
   at System.Collections.Generic.Dictionary`2.ValueCollection.Enumerator.MoveNext()
   at IronPython.Runtime.Types.NewTypeMaker.StoreOverriddenMethod(MethodInfo
mi, String newName)
   at IronPython.Runtime.Types.NewTypeMaker.AddBaseMethods(Type
finishedType, Dictionary`2 specialNames)
   at IronPython.Runtime.Types.NewTypeMaker.CreateNewType()
   at IronPython.Runtime.Types.NewTypeMaker.<>c__DisplayClass1.<GetNewType>b__0()
   at Microsoft.Scripting.Utils.Publisher`2.GetOrCreateValue(TKey key,
Func`1 create)
   at IronPython.Runtime.Types.NewTypeMaker.GetNewType(String
typeName, PythonTuple bases, IAttributesCollection dict)
   at IronPython.Runtime.Types.PythonType..ctor(CodeContext context,
String name, PythonTuple bases, IAttributesCollection dict)
   at IronPython.Runtime.Types.PythonType.__new__(CodeContext context,
PythonType cls, String name, PythonTuple bases, IAttributesCollection
dict)
   at _stub_$454##282(Closure , CallSite , CodeContext , Object ,
String , PythonTuple , IAttributesCollection )
   at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
context, String name, Object[] bases, String selfNames,
IAttributesCollection vars)
   at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
context, String name, Object[] bases, String selfNames, CallTarget0
body)
   at S$27.Initialize(Scope $scope, LanguageContext $language)
   at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression
code, Scope scope)
   at Microsoft.Scripting.ScriptCode.Run(Scope scope)
   at IronPython.Runtime.PythonContext.CreateModule(String fileName,
Scope scope, ScriptCode scriptCode, ModuleOptions options)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName,
String moduleName, SourceUnit sourceCode, ModuleOptions options,
ScriptCode& scriptCode)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName,
String moduleName, SourceUnit sourceCode, ModuleOptions options)
   at IronPython.Runtime.Importer.LoadFromSourceUnit(CodeContext
context, SourceUnit sourceCode, String name, String path)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, String name, String path)
   at IronPython.Runtime.Importer.LoadFromDisk(CodeContext context,
String name, String fullName, String str)
   at IronPython.Runtime.Importer.ImportFromPathHook(CodeContext
context, String name, String fullName, List path, Func`5
defaultLoader)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String name, String fullName, List path)
   at IronPython.Runtime.Importer.ImportNestedModule(CodeContext
context, Scope scope, String name, List path)
   at IronPython.Runtime.Importer.ImportModuleFrom(CodeContext
context, Object from, String name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context,
Object globals, String modName, Boolean bottom, Int32 level)
   at IronPython.Runtime.Builtin.__import__(CodeContext context,
String name, Object globals, Object locals, Object fromlist, Int32
level)
   at IronPython.Runtime.Builtin.__import__(CodeContext context,
String name, Object globals, Object locals, Object fromlist)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String name)
   at _stub_$176##142(Closure , CallSite , CodeContext , Object , Object )
   at S$5.load_module$45(Object module)
   at _stub_$170##136(Closure , CallSite , CodeContext , Object , Object )
   at S$5.worker$48(Closure )


From dinov at microsoft.com  Tue Feb 10 18:48:28 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 10 Feb 2009 09:48:28 -0800
Subject: [IronPython] Any idea what might cause this?
In-Reply-To: <4817b6fc0902092224t6b72a612x8f40f2e5105a1e22@mail.gmail.com>
References: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>
	<499097C2.5010307@voidspace.org.uk>
	<350E7D38B6D819428718949920EC235557199D79A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0902092224t6b72a612x8f40f2e5105a1e22@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571B7F8B62@NA-EXMSG-C102.redmond.corp.microsoft.com>

Awesome, thanks for tracking this down.  This looks trivial to fix - we're just missing a lock statement.  I've added the lock to my next change that will go in (probably today).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Monday, February 09, 2009 10:25 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Any idea what might cause this?

Hi Dino,

I modified the importing code a to spit out the CLR trace and to auto
refresh the browser if there is no error. 299 reloads later it crashed
because it ran out of memory, looks like IE/silverlight has a leak.
108 reloads after that I hit paydirt. There error was in another
module, but appears to be the same issue.

Good luck!
-Dan

CLR Exception: System.InvalidOperationException: Collection was
modified; enumeration operation may not execute.
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource
resource)
   at System.Collections.Generic.Dictionary`2.ValueCollection.Enumerator.MoveNext()
   at IronPython.Runtime.Types.NewTypeMaker.StoreOverriddenMethod(MethodInfo
mi, String newName)
   at IronPython.Runtime.Types.NewTypeMaker.AddBaseMethods(Type
finishedType, Dictionary`2 specialNames)
   at IronPython.Runtime.Types.NewTypeMaker.CreateNewType()
   at IronPython.Runtime.Types.NewTypeMaker.<>c__DisplayClass1.<GetNewType>b__0()
   at Microsoft.Scripting.Utils.Publisher`2.GetOrCreateValue(TKey key,
Func`1 create)
   at IronPython.Runtime.Types.NewTypeMaker.GetNewType(String
typeName, PythonTuple bases, IAttributesCollection dict)
   at IronPython.Runtime.Types.PythonType..ctor(CodeContext context,
String name, PythonTuple bases, IAttributesCollection dict)
   at IronPython.Runtime.Types.PythonType.__new__(CodeContext context,
PythonType cls, String name, PythonTuple bases, IAttributesCollection
dict)
   at _stub_$454##282(Closure , CallSite , CodeContext , Object ,
String , PythonTuple , IAttributesCollection )
   at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
context, String name, Object[] bases, String selfNames,
IAttributesCollection vars)
   at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
context, String name, Object[] bases, String selfNames, CallTarget0
body)
   at S$27.Initialize(Scope $scope, LanguageContext $language)
   at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression
code, Scope scope)
   at Microsoft.Scripting.ScriptCode.Run(Scope scope)
   at IronPython.Runtime.PythonContext.CreateModule(String fileName,
Scope scope, ScriptCode scriptCode, ModuleOptions options)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName,
String moduleName, SourceUnit sourceCode, ModuleOptions options,
ScriptCode& scriptCode)
   at IronPython.Runtime.PythonContext.CompileModule(String fileName,
String moduleName, SourceUnit sourceCode, ModuleOptions options)
   at IronPython.Runtime.Importer.LoadFromSourceUnit(CodeContext
context, SourceUnit sourceCode, String name, String path)
   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, String name, String path)
   at IronPython.Runtime.Importer.LoadFromDisk(CodeContext context,
String name, String fullName, String str)
   at IronPython.Runtime.Importer.ImportFromPathHook(CodeContext
context, String name, String fullName, List path, Func`5
defaultLoader)
   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
String name, String fullName, List path)
   at IronPython.Runtime.Importer.ImportNestedModule(CodeContext
context, Scope scope, String name, List path)
   at IronPython.Runtime.Importer.ImportModuleFrom(CodeContext
context, Object from, String name)
   at IronPython.Runtime.Importer.ImportModule(CodeContext context,
Object globals, String modName, Boolean bottom, Int32 level)
   at IronPython.Runtime.Builtin.__import__(CodeContext context,
String name, Object globals, Object locals, Object fromlist, Int32
level)
   at IronPython.Runtime.Builtin.__import__(CodeContext context,
String name, Object globals, Object locals, Object fromlist)
   at IronPython.Runtime.Builtin.__import__(CodeContext context, String name)
   at _stub_$176##142(Closure , CallSite , CodeContext , Object , Object )
   at S$5.load_module$45(Object module)
   at _stub_$170##136(Closure , CallSite , CodeContext , Object , Object )
   at S$5.worker$48(Closure )
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dan.eloff at gmail.com  Tue Feb 10 19:18:53 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Tue, 10 Feb 2009 13:18:53 -0500
Subject: [IronPython] Any idea what might cause this?
In-Reply-To: <350E7D38B6D819428718949920EC2355571B7F8B62@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4817b6fc0902091117h7d19d6dbt2ec6440b82c6baa9@mail.gmail.com>
	<499097C2.5010307@voidspace.org.uk>
	<350E7D38B6D819428718949920EC235557199D79A0@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4817b6fc0902092224t6b72a612x8f40f2e5105a1e22@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571B7F8B62@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0902101018t6f30c98bjc69a3dbf8ab5150c@mail.gmail.com>

Excellent! I'll be sure to upgrade later this week.

Cheers,
-Dan

On Tue, Feb 10, 2009 at 12:48 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Awesome, thanks for tracking this down.  This looks trivial to fix - we're just missing a lock statement.  I've added the lock to my next change that will go in (probably today).
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
> Sent: Monday, February 09, 2009 10:25 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Any idea what might cause this?
>
> Hi Dino,
>
> I modified the importing code a to spit out the CLR trace and to auto
> refresh the browser if there is no error. 299 reloads later it crashed
> because it ran out of memory, looks like IE/silverlight has a leak.
> 108 reloads after that I hit paydirt. There error was in another
> module, but appears to be the same issue.
>
> Good luck!
> -Dan
>
> CLR Exception: System.InvalidOperationException: Collection was
> modified; enumeration operation may not execute.
>   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource
> resource)
>   at System.Collections.Generic.Dictionary`2.ValueCollection.Enumerator.MoveNext()
>   at IronPython.Runtime.Types.NewTypeMaker.StoreOverriddenMethod(MethodInfo
> mi, String newName)
>   at IronPython.Runtime.Types.NewTypeMaker.AddBaseMethods(Type
> finishedType, Dictionary`2 specialNames)
>   at IronPython.Runtime.Types.NewTypeMaker.CreateNewType()
>   at IronPython.Runtime.Types.NewTypeMaker.<>c__DisplayClass1.<GetNewType>b__0()
>   at Microsoft.Scripting.Utils.Publisher`2.GetOrCreateValue(TKey key,
> Func`1 create)
>   at IronPython.Runtime.Types.NewTypeMaker.GetNewType(String
> typeName, PythonTuple bases, IAttributesCollection dict)
>   at IronPython.Runtime.Types.PythonType..ctor(CodeContext context,
> String name, PythonTuple bases, IAttributesCollection dict)
>   at IronPython.Runtime.Types.PythonType.__new__(CodeContext context,
> PythonType cls, String name, PythonTuple bases, IAttributesCollection
> dict)
>   at _stub_$454##282(Closure , CallSite , CodeContext , Object ,
> String , PythonTuple , IAttributesCollection )
>   at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
> context, String name, Object[] bases, String selfNames,
> IAttributesCollection vars)
>   at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
> context, String name, Object[] bases, String selfNames, CallTarget0
> body)
>   at S$27.Initialize(Scope $scope, LanguageContext $language)
>   at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression
> code, Scope scope)
>   at Microsoft.Scripting.ScriptCode.Run(Scope scope)
>   at IronPython.Runtime.PythonContext.CreateModule(String fileName,
> Scope scope, ScriptCode scriptCode, ModuleOptions options)
>   at IronPython.Runtime.PythonContext.CompileModule(String fileName,
> String moduleName, SourceUnit sourceCode, ModuleOptions options,
> ScriptCode& scriptCode)
>   at IronPython.Runtime.PythonContext.CompileModule(String fileName,
> String moduleName, SourceUnit sourceCode, ModuleOptions options)
>   at IronPython.Runtime.Importer.LoadFromSourceUnit(CodeContext
> context, SourceUnit sourceCode, String name, String path)
>   at IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
> context, String name, String path)
>   at IronPython.Runtime.Importer.LoadFromDisk(CodeContext context,
> String name, String fullName, String str)
>   at IronPython.Runtime.Importer.ImportFromPathHook(CodeContext
> context, String name, String fullName, List path, Func`5
> defaultLoader)
>   at IronPython.Runtime.Importer.ImportFromPath(CodeContext context,
> String name, String fullName, List path)
>   at IronPython.Runtime.Importer.ImportNestedModule(CodeContext
> context, Scope scope, String name, List path)
>   at IronPython.Runtime.Importer.ImportModuleFrom(CodeContext
> context, Object from, String name)
>   at IronPython.Runtime.Importer.ImportModule(CodeContext context,
> Object globals, String modName, Boolean bottom, Int32 level)
>   at IronPython.Runtime.Builtin.__import__(CodeContext context,
> String name, Object globals, Object locals, Object fromlist, Int32
> level)
>   at IronPython.Runtime.Builtin.__import__(CodeContext context,
> String name, Object globals, Object locals, Object fromlist)
>   at IronPython.Runtime.Builtin.__import__(CodeContext context, String name)
>   at _stub_$176##142(Closure , CallSite , CodeContext , Object , Object )
>   at S$5.load_module$45(Object module)
>   at _stub_$170##136(Closure , CallSite , CodeContext , Object , Object )
>   at S$5.worker$48(Closure )
> _______________________________________________
> 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 empirebuilder at gmail.com  Wed Feb 11 11:11:15 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Wed, 11 Feb 2009 12:11:15 +0200
Subject: [IronPython] Any update on IronPython for ASP.Net?
Message-ID: <8cd017b80902110211tf7a7689iab7e53e7fec24ec0@mail.gmail.com>

The last one was using IronPython 2.0 Beta 3 and had the compatibility with
.Net 3.5 assembly issue.

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

From Jimmy.Schementi at microsoft.com  Wed Feb 11 11:14:44 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Wed, 11 Feb 2009 02:14:44 -0800
Subject: [IronPython] Any update on IronPython for ASP.Net?
In-Reply-To: <8cd017b80902110211tf7a7689iab7e53e7fec24ec0@mail.gmail.com>
References: <8cd017b80902110211tf7a7689iab7e53e7fec24ec0@mail.gmail.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BEAD88608@NA-EXMSG-C116.redmond.corp.microsoft.com>

I'll see if I can make a build out of the IronPython 2.0 branch of Microsoft.Web.Scripting.dll.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Wednesday, February 11, 2009 2:11 AM
To: Discussion of IronPython
Subject: [IronPython] Any update on IronPython for ASP.Net?

The last one was using IronPython 2.0 Beta 3 and had the compatibility with .Net 3.5 assembly issue.

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

From empirebuilder at gmail.com  Wed Feb 11 11:35:41 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Wed, 11 Feb 2009 12:35:41 +0200
Subject: [IronPython] Any update on IronPython for ASP.Net?
In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A3284BEAD88608@NA-EXMSG-C116.redmond.corp.microsoft.com>
References: <8cd017b80902110211tf7a7689iab7e53e7fec24ec0@mail.gmail.com>
	<5283CA0A4168DF4FBBD71AE9ECA5A3284BEAD88608@NA-EXMSG-C116.redmond.corp.microsoft.com>
Message-ID: <8cd017b80902110235n3a8a9943ve33fbaba11d8f647@mail.gmail.com>

Thank you. The hosting interface has changed between beta 3 and now. That
was the problem I encountered when I tried to monkey patch the last version
of asp.net future. Now that the DLR hosting interface is stable, it will be
easier to upgrade the runtime simply using assembly versioning.


On Wed, Feb 11, 2009 at 12:14 PM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:

>  I'll see if I can make a build out of the IronPython 2.0 branch of
> Microsoft.Web.Scripting.dll.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata
> *Sent:* Wednesday, February 11, 2009 2:11 AM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] Any update on IronPython for ASP.Net?
>
>
>
> The last one was using IronPython 2.0 Beta 3 and had the compatibility with
> .Net 3.5 assembly issue.
>
> --
> nomadlife.org
>



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

From empirebuilder at gmail.com  Wed Feb 11 12:51:03 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Wed, 11 Feb 2009 13:51:03 +0200
Subject: [IronPython] Jetfire scripting language
Message-ID: <8cd017b80902110351h3e8ecc4el810771f69c096426@mail.gmail.com>

This is a new kid on the block
http://www.codeplex.com/Jetfire.<http://www.codeplex.com/Jetfire>
It looks like a very interesting DSL for workflow than  full fledged
scripting language - no DLR integration.
-- 
nomadlife.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090211/d17c4589/attachment.html>

From mkhan at storediq.com  Wed Feb 11 17:56:17 2009
From: mkhan at storediq.com (Mohammed Khan)
Date: Wed, 11 Feb 2009 10:56:17 -0600
Subject: [IronPython] question about code <-> designer transitions
Message-ID: <21547B928F07B94E9DDAA44D722C5A721F02C9E44F@siq-ex1.storediq.com>

Hi folks,

I just started using iron python studio a couple of days ago, so this may be a newbie question:

>From the code view, I added some code to the __init__ method, and some code to the initializecomponent method, when I go to the designer and change something (for eg the tabindex of a control) and go back to code view, I get one of two behaviors:

1.       The code I typed disappears, the other code remains intact.

2.       The __init__ method only contains a pass, ie it removes the call to initializecomponent.. this of course causes the app to come up with an empty form if I run it..

I appreciate any help on this matter,

Thanks,

moek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090211/204963c6/attachment.html>

From dinov at microsoft.com  Wed Feb 11 18:18:54 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 11 Feb 2009 09:18:54 -0800
Subject: [IronPython] question about code <-> designer transitions
In-Reply-To: <21547B928F07B94E9DDAA44D722C5A721F02C9E44F@siq-ex1.storediq.com>
References: <21547B928F07B94E9DDAA44D722C5A721F02C9E44F@siq-ex1.storediq.com>
Message-ID: <350E7D38B6D819428718949920EC2355571B7F9072@NA-EXMSG-C102.redmond.corp.microsoft.com>

It sounds like you're hitting a bug in the codedom round tripping support.  IronPython Studio is really more of a sample and leaves much to be desired so it's likely you'll hit many more.  Michael Foord who has done tons of winforms development I believe recommends designing it in C# and then you can just subclass that from Python.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammed Khan
Sent: Wednesday, February 11, 2009 8:56 AM
To: users at lists.ironpython.com
Subject: [IronPython] question about code <-> designer transitions

Hi folks,

I just started using iron python studio a couple of days ago, so this may be a newbie question:

>From the code view, I added some code to the __init__ method, and some code to the initializecomponent method, when I go to the designer and change something (for eg the tabindex of a control) and go back to code view, I get one of two behaviors:

1.       The code I typed disappears, the other code remains intact.

2.       The __init__ method only contains a pass, ie it removes the call to initializecomponent.. this of course causes the app to come up with an empty form if I run it..

I appreciate any help on this matter,

Thanks,

moek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090211/62e59667/attachment.html>

From mkhan at storediq.com  Wed Feb 11 18:43:18 2009
From: mkhan at storediq.com (Mohammed Khan)
Date: Wed, 11 Feb 2009 11:43:18 -0600
Subject: [IronPython] question about code <-> designer transitions
In-Reply-To: <350E7D38B6D819428718949920EC2355571B7F9072@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <21547B928F07B94E9DDAA44D722C5A721F02C9E44F@siq-ex1.storediq.com>
	<350E7D38B6D819428718949920EC2355571B7F9072@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <21547B928F07B94E9DDAA44D722C5A721F02C9E466@siq-ex1.storediq.com>

Thanks for the info Dino, I will give the suggested method a try.

Thanks,

mfk

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Wednesday, February 11, 2009 11:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] question about code <-> designer transitions

It sounds like you're hitting a bug in the codedom round tripping support.  IronPython Studio is really more of a sample and leaves much to be desired so it's likely you'll hit many more.  Michael Foord who has done tons of winforms development I believe recommends designing it in C# and then you can just subclass that from Python.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Mohammed Khan
Sent: Wednesday, February 11, 2009 8:56 AM
To: users at lists.ironpython.com
Subject: [IronPython] question about code <-> designer transitions

Hi folks,

I just started using iron python studio a couple of days ago, so this may be a newbie question:

>From the code view, I added some code to the __init__ method, and some code to the initializecomponent method, when I go to the designer and change something (for eg the tabindex of a control) and go back to code view, I get one of two behaviors:

1.       The code I typed disappears, the other code remains intact.

2.       The __init__ method only contains a pass, ie it removes the call to initializecomponent.. this of course causes the app to come up with an empty form if I run it..

I appreciate any help on this matter,

Thanks,

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

From dan.eloff at gmail.com  Wed Feb 11 22:55:45 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Wed, 11 Feb 2009 16:55:45 -0500
Subject: [IronPython] Question about dictionaries in general
Message-ID: <4817b6fc0902111355p1e471d52x45f3e4298b8b0a46@mail.gmail.com>

Hi,

This is not an IronPython question really, but I notice the dictionary
architecture used by IronPython allows lock free read access. With
hashtables being so important to dynamic languages this has always
been a subject of interest to me. Did you do any comparisons with the
System.Collections.Generic dictionary? There seems to be three basic
strategies for making a thread-safe dictionary, dictionary with simple
locking on reads & writes, reader-writer lock, and lock free reads. I
would expect that the latter approach performs best, but it can depend
on the ratio of reads to writes and how much contention there is. I'd
be most interested to hear about the experiences of the IronPython
developers on this subject.

Thanks,
-Dan


From dinov at microsoft.com  Wed Feb 11 23:39:54 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 11 Feb 2009 14:39:54 -0800
Subject: [IronPython] Question about dictionaries in general
In-Reply-To: <4817b6fc0902111355p1e471d52x45f3e4298b8b0a46@mail.gmail.com>
References: <4817b6fc0902111355p1e471d52x45f3e4298b8b0a46@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571B7F92BD@NA-EXMSG-C102.redmond.corp.microsoft.com>

Here are the original PyBench results from when we switched to the new dictionary implementation back in February of last year:

Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other   diff
-------------------------------------------------------------------------------
            DictWithFloatKeys:   156ms   217ms  -28.1%   159ms   223ms  -28.9%
          DictWithIntegerKeys:   105ms   198ms  -47.0%   107ms   200ms  -46.6%
           DictWithStringKeys:   159ms   253ms  -37.2%   161ms   256ms  -37.1%
       SimpleDictManipulation:   108ms   176ms  -38.7%   110ms   180ms  -38.7%


(great timing, in 2 weeks the e-mail that had this data would have self destructed).

"this" is the new implementation, and "other" was the old implementation based upon System.Collections.Generic.Dictionary<object, object> where we just locked on all operations.   The implementation has undergone frequent tweaks to get it tuned to a more broad range of scenarios since then but I believe the PyBench numbers have held within 10% or so.  The one possible exception is float keys which will be much faster in 2.0.1 and in the current sources - although I don't know why you'd ever hash on floats :).

The big problem with the BCL dictionary is of course that it's not thread safe.  But we also solved another problem at the same time in that we used to have many different types that would pretend to by Python's dictionary type but weren't really.  So type({}) is type(someOtherObjectYouExpectedToReallyBeADict) was frequently false - but type({}) == type(...) would still be true due to this yucky type impersonation feature we had going on.  And we've gained a few other optimizations from having our own dictionary type - for example we can now quickly check whether or not a dictionary contains string keys for doing keyword splatting (an idea which even recently came up on python-dev).  So this wasn't entirely just about speeding it up via thread safety lock-free reads.

As for the individual options I'll add a 4th one to your list - a copy on write dictionary.  But I didn't investigate either COW or a reader-writer lock implementation.  COW I didn't look at just because it seems likely that we'll be dealing with big dictionaries frequently enough that it is likely to lose.  Maybe a hybrid COW/lock free reads will eventually make sense but will also be much more complex.  I didn't look at reader/writer lock simply because I've looked at using reader/writer locks in the past (I believe I was looking at it for our list implementation).  .NET's basic ReaderWriterLock class has a lot of overhead when compared to just doing simple operations like a dictionary read/write.  It's really meant to be used when there's a lot of work being done under the lock.  In 3.0 they added ReaderWriterLockSlim which performs better but requires full trust!  Not that we can depend on System.Core yet anyway...  But I'd suspect that needing to take the lock on every read will likely lose - and is only going to become a worse proposition over time as we get into a more and more multi-core world.

My biggest take away is that I almost wish we made dict/list not thread safe in IronPython and said that you had to lock if you planned on using them concurrently.  But that's probably impractical as people probably want modules to not being corrupted under multiple readers/writers :)  Ahh, if we only implemented from __future__ import GIL :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Wednesday, February 11, 2009 1:56 PM
To: Discussion of IronPython
Subject: [IronPython] Question about dictionaries in general

Hi,

This is not an IronPython question really, but I notice the dictionary
architecture used by IronPython allows lock free read access. With
hashtables being so important to dynamic languages this has always
been a subject of interest to me. Did you do any comparisons with the
System.Collections.Generic dictionary? There seems to be three basic
strategies for making a thread-safe dictionary, dictionary with simple
locking on reads & writes, reader-writer lock, and lock free reads. I
would expect that the latter approach performs best, but it can depend
on the ratio of reads to writes and how much contention there is. I'd
be most interested to hear about the experiences of the IronPython
developers on this subject.

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


From slide.o.mix at gmail.com  Thu Feb 12 00:00:59 2009
From: slide.o.mix at gmail.com (Slide)
Date: Wed, 11 Feb 2009 16:00:59 -0700
Subject: [IronPython] DLR mailing list
Message-ID: <a623f7d10902111500tce03edcxf724209d4060718b@mail.gmail.com>

Is there an ACTIVE DLR mailing list with topics specific to the DLR? I
know there are the discussions on codeplex, but was wondering if there
was something more active than that

Thanks,

slide

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


From floris.vannee at gmail.com  Thu Feb 12 01:28:02 2009
From: floris.vannee at gmail.com (Floris van Nee)
Date: Wed, 11 Feb 2009 16:28:02 -0800 (PST)
Subject: [IronPython] Invitation to connect on LinkedIn
Message-ID: <2044189707.743847.1234398482185.JavaMail.app@ech3-cdn08.prod>

LinkedIn
------------



   
Discussion,

I'd like to add you to my professional network on LinkedIn.

- Floris

Accept Floris van Nee's invite:
https://www.linkedin.com/e/isd/482579088/8actW2Z7/

------------------------------------------

What is LinkedIn and why should you join?
http://learn.linkedin.com/what-is-linkedin/


 
------
(c) 2009, LinkedIn Corporation

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

From curt at hagenlocher.org  Thu Feb 12 02:36:44 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Wed, 11 Feb 2009 17:36:44 -0800
Subject: [IronPython] DLR mailing list
In-Reply-To: <a623f7d10902111500tce03edcxf724209d4060718b@mail.gmail.com>
References: <a623f7d10902111500tce03edcxf724209d4060718b@mail.gmail.com>
Message-ID: <d2155e360902111736s3c00f63bsaf619aacf58080f1@mail.gmail.com>

There's only the CodePlex discussions for now.

On Wed, Feb 11, 2009 at 3:00 PM, Slide <slide.o.mix at gmail.com> wrote:

> Is there an ACTIVE DLR mailing list with topics specific to the DLR? I
> know there are the discussions on codeplex, but was wondering if there
> was something more active than that
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090211/0eada9bf/attachment.html>

From chris at flat3.org  Thu Feb 12 13:11:21 2009
From: chris at flat3.org (Chris Whitworth)
Date: Thu, 12 Feb 2009 12:11:21 +0000 (GMT)
Subject: [IronPython] Compiled WPF applications with pyc on ipy 2.0 - STA
	problem?
Message-ID: <Pine.LNX.4.64.0902121158400.4451@parm.vs.topper.me.uk>

Hi;

I just tried compiling the WPF example code (on 
http://www.ironpython.info/index.php/WPF_Example) with the pyc.py included 
with the IronPython 2.0 samples, and the resultant assembly basically 
doesn't work. When launched from the stub .exe, I get:

Unhandled Exception: System.InvalidOperationException: The calling thread 
must be STA, because many UI components require this.

...followed by a big stacktrace, showing this was basically triggered by 
the creation of a System.Windows.Input.InputManager as part of the 
System.Windows.Window ctor.

>From what I recall of my Windows development, this basically means the 
thing that's creating the System.Windows.Window() is running in a 
multithreaded apartment, and for arcane COM-related reasons, this isn't 
allowed. Any ideas on how to go about fixing this?

(The sample runs fine if launched directly from ipy, FWIW)

Cheers;
Chris
-- 
   "Back when I was young, we had to travel back in time to put the tape in so
    the game would load before we died."


From daftspaniel at gmail.com  Thu Feb 12 13:35:24 2009
From: daftspaniel at gmail.com (Davy Mitchell)
Date: Thu, 12 Feb 2009 12:35:24 +0000
Subject: [IronPython] Compiled WPF applications with pyc on ipy 2.0 -
	STA problem?
In-Reply-To: <Pine.LNX.4.64.0902121158400.4451@parm.vs.topper.me.uk>
References: <Pine.LNX.4.64.0902121158400.4451@parm.vs.topper.me.uk>
Message-ID: <20253b0c0902120435x49188e23y1742368c9287b4fb@mail.gmail.com>

 Hi Chris,

Have a look at
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19409

Davy


From chris at flat3.org  Thu Feb 12 13:47:34 2009
From: chris at flat3.org (Chris Whitworth)
Date: Thu, 12 Feb 2009 12:47:34 +0000 (GMT)
Subject: [IronPython] Compiled WPF applications with pyc on ipy 2.0 -
 STA problem?
In-Reply-To: <20253b0c0902120435x49188e23y1742368c9287b4fb@mail.gmail.com>
References: <Pine.LNX.4.64.0902121158400.4451@parm.vs.topper.me.uk>
	<20253b0c0902120435x49188e23y1742368c9287b4fb@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0902121246300.4451@parm.vs.topper.me.uk>

> Have a look at
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19409

Okay, that's hugely useful; thanks! I was halfway down the road of 
creating a new STA thread to launch the application from...

Cheers;
Chris


From dan.eloff at gmail.com  Thu Feb 12 19:30:43 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Thu, 12 Feb 2009 13:30:43 -0500
Subject: [IronPython] Question about dictionaries in general
In-Reply-To: <350E7D38B6D819428718949920EC2355571B7F92BD@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4817b6fc0902111355p1e471d52x45f3e4298b8b0a46@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571B7F92BD@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0902121030iec6caa3mf94910a7dbdb82c1@mail.gmail.com>

Thanks, Dino that was an interesting read. What amazed me was by how
much the new implementation beat the old locking one. The percentages
given are maybe not the most telling, -47% doesn't have the same
impact as "twice as fast" :) I totally agree with you on the COW, it
generally only works well for small collections or collections that
are rarely mutated. And your take on the ReaderWriterLock confirms my
experience with it, it just adds too much overhead (about 5 times as
much as Monitor) to be worth it for cheap operations. Probably it was
designed for more expensive IO related things. I wasn't aware of the
new ReaderWriterLockSlim, but the fact that it requires full trust
doesn't make it very appealing.

Thanks again for sharing your experiences and data on the subject.

-Dan

On Wed, Feb 11, 2009 at 5:39 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Here are the original PyBench results from when we switched to the new dictionary implementation back in February of last year:
>
> Test                             minimum run-time        average  run-time
>                                 this    other   diff    this    other   diff
> -------------------------------------------------------------------------------
>            DictWithFloatKeys:   156ms   217ms  -28.1%   159ms   223ms  -28.9%
>          DictWithIntegerKeys:   105ms   198ms  -47.0%   107ms   200ms  -46.6%
>           DictWithStringKeys:   159ms   253ms  -37.2%   161ms   256ms  -37.1%
>       SimpleDictManipulation:   108ms   176ms  -38.7%   110ms   180ms  -38.7%
>
>
> (great timing, in 2 weeks the e-mail that had this data would have self destructed).
>
> "this" is the new implementation, and "other" was the old implementation based upon System.Collections.Generic.Dictionary<object, object> where we just locked on all operations.   The implementation has undergone frequent tweaks to get it tuned to a more broad range of scenarios since then but I believe the PyBench numbers have held within 10% or so.  The one possible exception is float keys which will be much faster in 2.0.1 and in the current sources - although I don't know why you'd ever hash on floats :).
>
> The big problem with the BCL dictionary is of course that it's not thread safe.  But we also solved another problem at the same time in that we used to have many different types that would pretend to by Python's dictionary type but weren't really.  So type({}) is type(someOtherObjectYouExpectedToReallyBeADict) was frequently false - but type({}) == type(...) would still be true due to this yucky type impersonation feature we had going on.  And we've gained a few other optimizations from having our own dictionary type - for example we can now quickly check whether or not a dictionary contains string keys for doing keyword splatting (an idea which even recently came up on python-dev).  So this wasn't entirely just about speeding it up via thread safety lock-free reads.
>
> As for the individual options I'll add a 4th one to your list - a copy on write dictionary.  But I didn't investigate either COW or a reader-writer lock implementation.  COW I didn't look at just because it seems likely that we'll be dealing with big dictionaries frequently enough that it is likely to lose.  Maybe a hybrid COW/lock free reads will eventually make sense but will also be much more complex.  I didn't look at reader/writer lock simply because I've looked at using reader/writer locks in the past (I believe I was looking at it for our list implementation).  .NET's basic ReaderWriterLock class has a lot of overhead when compared to just doing simple operations like a dictionary read/write.  It's really meant to be used when there's a lot of work being done under the lock.  In 3.0 they added ReaderWriterLockSlim which performs better but requires full trust!  Not that we can depend on System.Core yet anyway...  But I'd suspect that needing to take the lock on every r
>  ead will likely lose - and is only going to become a worse proposition over time as we get into a more and more multi-core world.
>
> My biggest take away is that I almost wish we made dict/list not thread safe in IronPython and said that you had to lock if you planned on using them concurrently.  But that's probably impractical as people probably want modules to not being corrupted under multiple readers/writers :)  Ahh, if we only implemented from __future__ import GIL :)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
> Sent: Wednesday, February 11, 2009 1:56 PM
> To: Discussion of IronPython
> Subject: [IronPython] Question about dictionaries in general
>
> Hi,
>
> This is not an IronPython question really, but I notice the dictionary
> architecture used by IronPython allows lock free read access. With
> hashtables being so important to dynamic languages this has always
> been a subject of interest to me. Did you do any comparisons with the
> System.Collections.Generic dictionary? There seems to be three basic
> strategies for making a thread-safe dictionary, dictionary with simple
> locking on reads & writes, reader-writer lock, and lock free reads. I
> would expect that the latter approach performs best, but it can depend
> on the ratio of reads to writes and how much contention there is. I'd
> be most interested to hear about the experiences of the IronPython
> developers on this subject.
>
> Thanks,
> -Dan
> _______________________________________________
> 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 Kyle.Howland-Rose at aar.com.au  Fri Feb 13 00:22:37 2009
From: Kyle.Howland-Rose at aar.com.au (Howland-Rose, Kyle)
Date: Fri, 13 Feb 2009 10:22:37 +1100
Subject: [IronPython] try breaks traceback
Message-ID: <E3E4C7D6B896A043805949D136C327F4027D7A48@SYDEXCVS0.aar.com.au>

Hi all,
 
ipy 2.0 traceback seems to lose track of where exceptions come from
inside try-except blocks (which hampers debugging):
 
bash-3.2$ cat foo.py
import bar
class E(Exception):
  def __init__(self, message):
    Exception.__init__(self, message)
try:
 bar.baz()
except E, ex:
 pass
 
bash-3.2$ cat bar.py
def baz():
 "".sort(key=key_comparer.key)
 
bash-3.2$ ipy foo.py
Traceback (most recent call last):
  File "foo.py", line 6, in foo.py
AttributeError: 'str' object has no attribute 'sort'bash-3.2$
 
if I take the try-except block out I get the correct module line number:
 
bash-3.2$ cat foo2.py
import bar
class E(Exception):
  def __init__(self, message):
    Exception.__init__(self, message)
bar.baz()
 
bash-3.2$ ipy foo2.py
Traceback (most recent call last):
  File "foo2.py", line 5, in foo2.py
  File "h:\jobs\chris21views\bar.py", line 2, in baz
AttributeError: 'str' object has no attribute 'sort'bash-3.2$
 
Before I raise a bug I thought I would just check that I am not missing
something here.
 
Thanks, Kyle

************************************************************************
 
Allens Arthur Robinson online: http://www.aar.com.au
 
This email is confidential and may be subject to legal or other professional privilege. It is also subject to copyright. If you have received it in error, confidentiality and privilege are not waived and you must not disclose or use the information in it. Please notify the sender by return email and delete it from your system. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth).
 
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090213/4db0a116/attachment.html>

From dfugate at microsoft.com  Fri Feb 13 23:19:01 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Fri, 13 Feb 2009 14:19:01 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
Message-ID: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com>

Hello Python Community,

I?m pleased to announce the release of IronPython 2.0.1.  IronPython 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5 compatible release running under the .NET platform.  Our top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0.  One of many notable areas we?ve improved upon is that float-integer comparisons are now 74% faster than they were in 2.0.  A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.  A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.

In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release:

?         20632:  can't write a __len__ returning a uint

?         20492:  TupleExpression.IsExpandable is internal, should be public

?         20605:  Compiling with pyc and PySerial module

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

?         20623:  InitializeModule needs to add refs to mscorlib/System
We?d like to thank everyone in the community who contributed to these bugs: fwereade, Eloff, neraun, and kuno.


You can download IronPython 2.0.1 at:  http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

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

From Marty.Nelson at symyx.com  Fri Feb 13 23:32:21 2009
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Fri, 13 Feb 2009 14:32:21 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com>


Why is the assembly version the same as 2.0?

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at python.org
Subject: [IronPython] Announcing IronPython 2.0.1

 

Hello Python Community,

 

I'm pleased to announce the release of IronPython 2.0.1.  IronPython
2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5
compatible release running under the .NET platform.  Our top priority
for this release was improving upon performance while retaining
backwards compatibility with IronPython 2.0.  One of many notable areas
we've improved upon is that float-integer comparisons are now 74% faster
than they were in 2.0.  A full report documenting changes in interpreter
performance from 2.0 to 2.0.1 can be found at
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.
A special thanks goes out to Resolver Systems for helping us in
identifying areas needing performance improvements. 

 

In addition to numerous bug fixes in our IronPython 2.6 branch that were
backported to 2.0.1, we also fixed the following CodePlex bugs
specifically for this release:

*         20632:  can't write a __len__ returning a uint

*         20492:  TupleExpression.IsExpandable is internal, should be
public

*         20605:  Compiling with pyc and PySerial module

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

*         20623:  InitializeModule needs to add refs to mscorlib/System 

We'd like to thank everyone in the community who contributed to these
bugs: fwereade, Eloff, neraun, and kuno.

 

 

You can download IronPython 2.0.1 at:
http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseI
d=12481

 

The IronPython Team



=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090213/1035f86a/attachment.html>

From dinov at microsoft.com  Fri Feb 13 23:39:32 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 13 Feb 2009 14:39:32 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com>
	<515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BBD9DEE@NA-EXMSG-C102.redmond.corp.microsoft.com>

It's an in-place upgrade so you don't need to re-build hosts that were built against the previous versions of IronPython - they'll just continue to work.  If we changed the .NET assembly version then you'd either have to apply policy or rebuild.  The assembly file version is updated and that's how you can distinguish the two builds.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 2:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

Why is the assembly version the same as 2.0?

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at python.org
Subject: [IronPython] Announcing IronPython 2.0.1

Hello Python Community,

I'm pleased to announce the release of IronPython 2.0.1.  IronPython 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5 compatible release running under the .NET platform.  Our top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0.  One of many notable areas we've improved upon is that float-integer comparisons are now 74% faster than they were in 2.0.  A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.  A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.

In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release:

*         20632:  can't write a __len__ returning a uint

*         20492:  TupleExpression.IsExpandable is internal, should be public

*         20605:  Compiling with pyc and PySerial module

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

*         20623:  InitializeModule needs to add refs to mscorlib/System
We'd like to thank everyone in the community who contributed to these bugs: fwereade, Eloff, neraun, and kuno.


You can download IronPython 2.0.1 at:  http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

The IronPython Team
=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


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

From Marty.Nelson at symyx.com  Sat Feb 14 00:04:19 2009
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Fri, 13 Feb 2009 15:04:19 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <350E7D38B6D819428718949920EC2355571BBD9DEE@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC2355571BBD9DEE@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03F364A1@srv-be-101.Symyx-IC.symyx.com>

I guess one man's feature is another man's dll hell.

 

We've had lots of problems going from IP 2.0 Beta to IP 2.0.  Running an
installer that wants to put the dll in GAC when there's already that
version there seems to fail.  I've got to guide people through digging
into the GAC and checking the file version to find out they've got the
wrong version.  I thought it was just a beta to release thing, IP 2.0
was not compatible with the IP 2.0 Beta (not that I expect it to), but
what if there are breaking changes and we need to install side-by-side?

 

Managing policy files and being explicit about versions is a .NET way of
life.  I think maybe you guys have had your heads in the dynamic sand
for too long :-)

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 2:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

 

It's an in-place upgrade so you don't need to re-build hosts that were
built against the previous versions of IronPython - they'll just
continue to work.  If we changed the .NET assembly version then you'd
either have to apply policy or rebuild.  The assembly file version is
updated and that's how you can distinguish the two builds.

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 2:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

 

Why is the assembly version the same as 2.0?

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at python.org
Subject: [IronPython] Announcing IronPython 2.0.1

 

Hello Python Community,

 

I'm pleased to announce the release of IronPython 2.0.1.  IronPython
2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5
compatible release running under the .NET platform.  Our top priority
for this release was improving upon performance while retaining
backwards compatibility with IronPython 2.0.  One of many notable areas
we've improved upon is that float-integer comparisons are now 74% faster
than they were in 2.0.  A full report documenting changes in interpreter
performance from 2.0 to 2.0.1 can be found at
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.
A special thanks goes out to Resolver Systems for helping us in
identifying areas needing performance improvements. 

 

In addition to numerous bug fixes in our IronPython 2.6 branch that were
backported to 2.0.1, we also fixed the following CodePlex bugs
specifically for this release:

*         20632:  can't write a __len__ returning a uint

*         20492:  TupleExpression.IsExpandable is internal, should be
public

*         20605:  Compiling with pyc and PySerial module

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

*         20623:  InitializeModule needs to add refs to mscorlib/System 

We'd like to thank everyone in the community who contributed to these
bugs: fwereade, Eloff, neraun, and kuno.

 

 

You can download IronPython 2.0.1 at:
http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseI
d=12481

 

The IronPython Team

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.

 

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

From dinov at microsoft.com  Sat Feb 14 00:32:02 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 13 Feb 2009 15:32:02 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03F364A1@srv-be-101.Symyx-IC.symyx.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC2355571BBD9DEE@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<515335F32AA04440B3DE6FEA1993E9AD03F364A1@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BBD9E4D@NA-EXMSG-C102.redmond.corp.microsoft.com>

We're actually following the example of the CLR and other managed libraries here not something from dynamic languages :).  Minor non-breaking releases are in-place upgrades - for example you don't have mscorlib at version 2.0.50727.42, mscorlib at version 2.0.50727.3521 and a ton of versions in between - you just have mscorlib at the version it shipped at in 2005 which is 2.0.50727.42.  But it's file version changes with every patch so you can determine exactly what version you have.  And it's the same w/ all of the other framework DLLs as well.  So for major versions I agree with you - managing policy files is a way of life, but for minor versions not reving the assembly version is also a way of life.

As for concerns of breaking changes...  The 2.0 branch is locked down and only sees targeted changes that are explicitly back ported.  This is different from the major releases and the betas where there was active development which can and does alter APIs.  So we do maintain a high bar of compatibility between these point releases.  It's also what we've done with all the 1.x.y point releases as well so there isn't some new precedent here.

We could switch to updating the assembly version between minor versions but I'd like to have evidence that we are indeed breaking things first.  We have been more liberal than the frameworks (allowing signature changes in modules because they shouldn't be called directly from C#) but we haven't been hearing about problems to date.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 3:04 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

I guess one man's feature is another man's dll hell.

We've had lots of problems going from IP 2.0 Beta to IP 2.0.  Running an installer that wants to put the dll in GAC when there's already that version there seems to fail.  I've got to guide people through digging into the GAC and checking the file version to find out they've got the wrong version.  I thought it was just a beta to release thing, IP 2.0 was not compatible with the IP 2.0 Beta (not that I expect it to), but what if there are breaking changes and we need to install side-by-side?

Managing policy files and being explicit about versions is a .NET way of life.  I think maybe you guys have had your heads in the dynamic sand for too long :)

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 2:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

It's an in-place upgrade so you don't need to re-build hosts that were built against the previous versions of IronPython - they'll just continue to work.  If we changed the .NET assembly version then you'd either have to apply policy or rebuild.  The assembly file version is updated and that's how you can distinguish the two builds.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 2:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

Why is the assembly version the same as 2.0?

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at python.org
Subject: [IronPython] Announcing IronPython 2.0.1

Hello Python Community,

I'm pleased to announce the release of IronPython 2.0.1.  IronPython 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5 compatible release running under the .NET platform.  Our top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0.  One of many notable areas we've improved upon is that float-integer comparisons are now 74% faster than they were in 2.0.  A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.  A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.

In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release:

*         20632:  can't write a __len__ returning a uint

*         20492:  TupleExpression.IsExpandable is internal, should be public

*         20605:  Compiling with pyc and PySerial module

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

*         20623:  InitializeModule needs to add refs to mscorlib/System
We'd like to thank everyone in the community who contributed to these bugs: fwereade, Eloff, neraun, and kuno.


You can download IronPython 2.0.1 at:  http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

The IronPython Team
=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


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

From Marty.Nelson at symyx.com  Sat Feb 14 00:56:16 2009
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Fri, 13 Feb 2009 15:56:16 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <350E7D38B6D819428718949920EC2355571BBD9E4D@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com><350E7D38B6D819428718949920EC2355571BBD9DEE@NA-EXMSG-C102.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD03F364A1@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC2355571BBD9E4D@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03F364D0@srv-be-101.Symyx-IC.symyx.com>

Do you think that anyone providing a framework or library (code meant to
be consumed developers) should follow these guidelines (red and green
bits)?  Or should all products follow these guidelines?

 

Or does it depend where you are on the food chain?  It doesn't seem to
match with the guidance Microsoft provides in general to developers.

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

 

We're actually following the example of the CLR and other managed
libraries here not something from dynamic languages :-).  Minor
non-breaking releases are in-place upgrades - for example you don't have
mscorlib at version 2.0.50727.42, mscorlib at version 2.0.50727.3521 and
a ton of versions in between - you just have mscorlib at the version it
shipped at in 2005 which is 2.0.50727.42.  But it's file version changes
with every patch so you can determine exactly what version you have.
And it's the same w/ all of the other framework DLLs as well.  So for
major versions I agree with you - managing policy files is a way of
life, but for minor versions not reving the assembly version is also a
way of life.

 

As for concerns of breaking changes...  The 2.0 branch is locked down
and only sees targeted changes that are explicitly back ported.  This is
different from the major releases and the betas where there was active
development which can and does alter APIs.  So we do maintain a high bar
of compatibility between these point releases.  It's also what we've
done with all the 1.x.y point releases as well so there isn't some new
precedent here.  

 

We could switch to updating the assembly version between minor versions
but I'd like to have evidence that we are indeed breaking things first.
We have been more liberal than the frameworks (allowing signature
changes in modules because they shouldn't be called directly from C#)
but we haven't been hearing about problems to date.

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 3:04 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

 

I guess one man's feature is another man's dll hell.

 

We've had lots of problems going from IP 2.0 Beta to IP 2.0.  Running an
installer that wants to put the dll in GAC when there's already that
version there seems to fail.  I've got to guide people through digging
into the GAC and checking the file version to find out they've got the
wrong version.  I thought it was just a beta to release thing, IP 2.0
was not compatible with the IP 2.0 Beta (not that I expect it to), but
what if there are breaking changes and we need to install side-by-side?

 

Managing policy files and being explicit about versions is a .NET way of
life.  I think maybe you guys have had your heads in the dynamic sand
for too long :-)

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 2:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

 

It's an in-place upgrade so you don't need to re-build hosts that were
built against the previous versions of IronPython - they'll just
continue to work.  If we changed the .NET assembly version then you'd
either have to apply policy or rebuild.  The assembly file version is
updated and that's how you can distinguish the two builds.

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 2:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

 

Why is the assembly version the same as 2.0?

 

________________________________

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at python.org
Subject: [IronPython] Announcing IronPython 2.0.1

 

Hello Python Community,

 

I'm pleased to announce the release of IronPython 2.0.1.  IronPython
2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5
compatible release running under the .NET platform.  Our top priority
for this release was improving upon performance while retaining
backwards compatibility with IronPython 2.0.  One of many notable areas
we've improved upon is that float-integer comparisons are now 74% faster
than they were in 2.0.  A full report documenting changes in interpreter
performance from 2.0 to 2.0.1 can be found at
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.
A special thanks goes out to Resolver Systems for helping us in
identifying areas needing performance improvements. 

 

In addition to numerous bug fixes in our IronPython 2.6 branch that were
backported to 2.0.1, we also fixed the following CodePlex bugs
specifically for this release:

*         20632:  can't write a __len__ returning a uint

*         20492:  TupleExpression.IsExpandable is internal, should be
public

*         20605:  Compiling with pyc and PySerial module

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

*         20623:  InitializeModule needs to add refs to mscorlib/System 

We'd like to thank everyone in the community who contributed to these
bugs: fwereade, Eloff, neraun, and kuno.

 

 

You can download IronPython 2.0.1 at:
http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseI
d=12481

 

The IronPython Team

=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.

 

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

From dinov at microsoft.com  Sat Feb 14 01:20:52 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 13 Feb 2009 16:20:52 -0800
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03F364D0@srv-be-101.Symyx-IC.symyx.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD03F36484@srv-be-101.Symyx-IC.symyx.com><350E7D38B6D819428718949920EC2355571BBD9DEE@NA-EXMSG-C102.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD03F364A1@srv-be-101.Symyx-IC.symyx.com>
	<350E7D38B6D819428718949920EC2355571BBD9E4D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<515335F32AA04440B3DE6FEA1993E9AD03F364D0@srv-be-101.Symyx-IC.symyx.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BBD9EA0@NA-EXMSG-C102.redmond.corp.microsoft.com>

I wouldn't quite describe it as red & green bits as there's no green bits here.  But generally speaking if you can be highly confident of no breaking changes then I'd say not bumping the version number is a good idea.  Red and green bits is just one way of being confident about that.  Targeted bug fixing in a servicing branch is another way to be confident about that.

As for MS guidance I'm not sure what the official guidance is - but it's plain to see if it's not in-place upgrades for bug fixes then we're generally already not following that guidance.  And I don't see why other people would behave differently.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 3:56 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

Do you think that anyone providing a framework or library (code meant to be consumed developers) should follow these guidelines (red and green bits)?  Or should all products follow these guidelines?

Or does it depend where you are on the food chain?  It doesn't seem to match with the guidance Microsoft provides in general to developers.

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

We're actually following the example of the CLR and other managed libraries here not something from dynamic languages :).  Minor non-breaking releases are in-place upgrades - for example you don't have mscorlib at version 2.0.50727.42, mscorlib at version 2.0.50727.3521 and a ton of versions in between - you just have mscorlib at the version it shipped at in 2005 which is 2.0.50727.42.  But it's file version changes with every patch so you can determine exactly what version you have.  And it's the same w/ all of the other framework DLLs as well.  So for major versions I agree with you - managing policy files is a way of life, but for minor versions not reving the assembly version is also a way of life.

As for concerns of breaking changes...  The 2.0 branch is locked down and only sees targeted changes that are explicitly back ported.  This is different from the major releases and the betas where there was active development which can and does alter APIs.  So we do maintain a high bar of compatibility between these point releases.  It's also what we've done with all the 1.x.y point releases as well so there isn't some new precedent here.

We could switch to updating the assembly version between minor versions but I'd like to have evidence that we are indeed breaking things first.  We have been more liberal than the frameworks (allowing signature changes in modules because they shouldn't be called directly from C#) but we haven't been hearing about problems to date.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 3:04 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

I guess one man's feature is another man's dll hell.

We've had lots of problems going from IP 2.0 Beta to IP 2.0.  Running an installer that wants to put the dll in GAC when there's already that version there seems to fail.  I've got to guide people through digging into the GAC and checking the file version to find out they've got the wrong version.  I thought it was just a beta to release thing, IP 2.0 was not compatible with the IP 2.0 Beta (not that I expect it to), but what if there are breaking changes and we need to install side-by-side?

Managing policy files and being explicit about versions is a .NET way of life.  I think maybe you guys have had your heads in the dynamic sand for too long :)

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 2:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

It's an in-place upgrade so you don't need to re-build hosts that were built against the previous versions of IronPython - they'll just continue to work.  If we changed the .NET assembly version then you'd either have to apply policy or rebuild.  The assembly file version is updated and that's how you can distinguish the two builds.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Friday, February 13, 2009 2:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

Why is the assembly version the same as 2.0?

________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Friday, February 13, 2009 2:19 PM
To: Discussion of IronPython
Cc: python-announce-list at python.org
Subject: [IronPython] Announcing IronPython 2.0.1

Hello Python Community,

I'm pleased to announce the release of IronPython 2.0.1.  IronPython 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5 compatible release running under the .NET platform.  Our top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0.  One of many notable areas we've improved upon is that float-integer comparisons are now 74% faster than they were in 2.0.  A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.  A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.

In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release:

*         20632:  can't write a __len__ returning a uint

*         20492:  TupleExpression.IsExpandable is internal, should be public

*         20605:  Compiling with pyc and PySerial module

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

*         20623:  InitializeModule needs to add refs to mscorlib/System
We'd like to thank everyone in the community who contributed to these bugs: fwereade, Eloff, neraun, and kuno.


You can download IronPython 2.0.1 at:  http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

The IronPython Team
=======
Notice: This e-mail message, together with any attachments, contains
information of Symyx Technologies, Inc. or any of its affiliates or
subsidiaries that may be confidential, proprietary, copyrighted,
privileged and/or protected work product, and is meant solely for
the intended recipient. If you are not the intended recipient, and
have received this message in error, please contact the sender
immediately, permanently delete the original and any copies of this
email and any attachments thereto.


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

From inbilla at gmail.com  Sat Feb 14 13:14:47 2009
From: inbilla at gmail.com (Josh Green)
Date: Sat, 14 Feb 2009 12:14:47 +0000
Subject: [IronPython] Functions requiring a byte[]
Message-ID: <e66aee60902140414g3cc5d7e2h417ab5fed67c92f0@mail.gmail.com>

Hi Guys,

Just to be honest from the start, I am a .NET/Python newbie, I'm at home in
standard C++ so please bare with me!

Bascially an application that I am trying to script (FX Composer) uses
IronPython. One of the .NET methods exposed into python bares the following
signature:

public void LoadRawData(byte[] bytes, int width, int height, int depth,
FXComposer.Scene.FXFormat format, FXComposer.Scene.Effects.FXSurfaceType
type)

Now, my problem lies in passing information into that function in the form
of "byte[]".
How can I generate a value that this function will accept in that spot?

I have tried the following:
img.LoadRawData([255,255,255,0,0,0,0,0,0,255,255,255], 2, 2, 3,
FXFormat.R8G8B8, FXSurfaceType.Surface2D)

But it complains with the following error:
TypeError: expected Array, got list
CLR Exception:
    ArgumentTypeException
:
expected Array, got list

So I assume I have to create an array somehow... But I don't know how!

Any help you guys can give me would be fantastic, and any suggestions of
places where I might find relevant documentation on these issues (CLR type
conversion to Python types, etc) I would be grateful for your advice.

Thanks for your time

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090214/588746cb/attachment.html>

From fuzzyman at voidspace.org.uk  Sat Feb 14 14:51:38 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 14 Feb 2009 13:51:38 +0000
Subject: [IronPython] Functions requiring a byte[]
In-Reply-To: <e66aee60902140414g3cc5d7e2h417ab5fed67c92f0@mail.gmail.com>
References: <e66aee60902140414g3cc5d7e2h417ab5fed67c92f0@mail.gmail.com>
Message-ID: <4996CC6A.3040208@voidspace.org.uk>

Josh Green wrote:
> Hi Guys,
>
> Just to be honest from the start, I am a .NET/Python newbie, I'm at 
> home in standard C++ so please bare with me!
>
> Bascially an application that I am trying to script (FX Composer) uses 
> IronPython. One of the .NET methods exposed into python bares the 
> following signature:
>
> public void LoadRawData(byte[] bytes, int width, int height, int 
> depth, FXComposer.Scene.FXFormat format, 
> FXComposer.Scene.Effects.FXSurfaceType type)
>
> Now, my problem lies in passing information into that function in the 
> form of "byte[]".
> How can I generate a value that this function will accept in that spot?
>
> I have tried the following:
> img.LoadRawData([255,255,255,0,0,0,0,0,0,255,255,255], 2, 2, 3, 
> FXFormat.R8G8B8, FXSurfaceType.Surface2D)
>
> But it complains with the following error:
> TypeError: expected Array, got list
> CLR Exception:
>     ArgumentTypeException
> :
> expected Array, got list
>
> So I assume I have to create an array somehow... But I don't know how!

 >>> from System import Array, Byte
 >>>
 >>> a = Array[Byte]((1, 2, 45, 87))
 >>> a
Array[Byte]((<System.Byte object at 0x000000000000002B [1]>, 
<System.Byte objec
 at 0x000000000000002C [2]>, <System.Byte object at 0x000000000000002D 
[45]>, <
ystem.Byte object at 0x000000000000002E [87]>))
 >>>

>
> Any help you guys can give me would be fantastic, and any suggestions 
> of places where I might find relevant documentation on these issues 
> (CLR type conversion to Python types, etc) I would be grateful for 
> your advice.
>

IronPython in Action is an awesome resource. ;-)

Otherwise places like the IronPython cookbook are a good place to start: 
http://www.ironpython.info

All the best,


Michael Foord

> Thanks for your time
>
> Josh
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 giles.thomas at resolversystems.com  Sat Feb 14 21:51:07 2009
From: giles.thomas at resolversystems.com (Giles Thomas)
Date: Sat, 14 Feb 2009 20:51:07 +0000
Subject: [IronPython] Announcing IronPython 2.0.1
In-Reply-To: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com>
References: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD27@NA-EXMSG-C112.redmond.corp.microsoft.com>
Message-ID: <49972EBB.5080605@resolversystems.com>

Dave,

This is great news, many thanks to all on the IronPython team from all 
of us at Resolver Systems.  If all goes well, we'll be releasing our 
2.0-compatible version in the very near future.


Best regards,

Giles

-- 
Giles Thomas
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

Win up to $17,000 for a spreadsheet: <http://www.resolversystems.com/competition/>

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



Dave Fugate wrote:

> Hello Python Community,
>
>  
>
> I?m pleased to announce the release of IronPython 2.0.1.  IronPython 
> 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 
> 2.5 compatible release running under the .NET platform.  Our top 
> priority for this release was improving upon performance while 
> retaining backwards compatibility with IronPython 2.0.  One of many 
> notable areas we?ve improved upon is that float-integer comparisons 
> are now 74% faster than they were in 2.0.  A full report documenting 
> changes in interpreter performance from 2.0 to 2.0.1 can be found at 
> http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP201VsIP20Perf.  
> A special thanks goes out to Resolver Systems for helping us in 
> identifying areas needing performance improvements.
>
>  
>
> In addition to numerous bug fixes in our IronPython 2.6 branch that 
> were backported to 2.0.1, we also fixed the following CodePlex bugs 
> specifically for this release:
>
> ?         20632:  can't write a __len__ returning a uint
>
> ?         20492:  TupleExpression.IsExpandable is internal, should be 
> public
>
> ?         20605:  Compiling with pyc and PySerial module
>
> ?         20616:  wrong TypeError message when invoking "str.join": 
> implicit parameter 'self' not counted          
>
> ?         20623:  InitializeModule needs to add refs to mscorlib/System
>
> We?d like to thank everyone in the community who contributed to these 
> bugs: fwereade, Eloff, neraun, and kuno.
>
>  
>
>  
>
> You can download IronPython 2.0.1 at: 
>  http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481
>
>  
>
> The IronPython Team
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/20090214/ae6851da/attachment.html>

From boesen at xefion.com  Mon Feb 16 10:55:18 2009
From: boesen at xefion.com (Thomas P. Boesen)
Date: Mon, 16 Feb 2009 10:55:18 +0100
Subject: [IronPython] Released prototype Excel add-in making it easy to
	create Python add-ins
Message-ID: <49993806.1000204@xefion.com>

Hi,

I am thinking about creating an Excel add-in that makes it very easy to
create Excel macros / add-ins using Python (IronPython)

Any feedback about the idea will be greatly appreciated.

I have made a prototype of this add-in available here:
http://www.xefion.com/en/discoveryscript.html

The add-in would be free, although not open-source.

It takes quite a bit of ?plumbing? to get COM add-ins running within
Excel. My add-in would look for Python scripts in a specific directory
and automatically create Excel menu-items for all the scripts in that
directory. Hence, to get started the user just has to create a one-line
Python script and store this script in the designated folder, then he
can run the script from Excel.

There will be various other options, for example shared network
locations with scripts and connecting Excel events (e.g. OpenDoc or
SaveDoc) to scripts based on their names. Later versions might also work
with other Office programs (e.g. Word). The download-page mentioned
above contains a description of feature candidates.

:-) Thomas P. Boesen




From giles.thomas at resolversystems.com  Mon Feb 16 12:58:44 2009
From: giles.thomas at resolversystems.com (Giles Thomas)
Date: Mon, 16 Feb 2009 11:58:44 +0000
Subject: [IronPython] Released prototype Excel add-in making it easy to
 create Python add-ins
In-Reply-To: <49993806.1000204@xefion.com>
References: <49993806.1000204@xefion.com>
Message-ID: <499954F4.3080101@resolversystems.com>

IronPython in a spreadsheet?  Terrible idea, it'll never work ;-)


Cheers,

Giles

-- 
Giles Thomas
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

Win up to $17,000 for a spreadsheet: <http://www.resolversystems.com/competition/>

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



Thomas P. Boesen wrote:
> Hi,
>
> I am thinking about creating an Excel add-in that makes it very easy to
> create Excel macros / add-ins using Python (IronPython)
>
> Any feedback about the idea will be greatly appreciated.
>
> I have made a prototype of this add-in available here:
> http://www.xefion.com/en/discoveryscript.html
>
> The add-in would be free, although not open-source.
>
> It takes quite a bit of ?plumbing? to get COM add-ins running within
> Excel. My add-in would look for Python scripts in a specific directory
> and automatically create Excel menu-items for all the scripts in that
> directory. Hence, to get started the user just has to create a one-line
> Python script and store this script in the designated folder, then he
> can run the script from Excel.
>
> There will be various other options, for example shared network
> locations with scripts and connecting Excel events (e.g. OpenDoc or
> SaveDoc) to scripts based on their names. Later versions might also work
> with other Office programs (e.g. Word). The download-page mentioned
> above contains a description of feature candidates.
>
> :-) Thomas P. Boesen
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-- 
Giles Thomas
giles.thomas at resolversystems.com
+44 (0) 20 7253 6372

Win up to $17,000 for a spreadsheet: <http://www.resolversystems.com/competition/>

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




From empirebuilder at gmail.com  Mon Feb 16 13:09:35 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Mon, 16 Feb 2009 14:09:35 +0200
Subject: [IronPython] Released prototype Excel add-in making it easy to
	create Python add-ins
In-Reply-To: <499954F4.3080101@resolversystems.com>
References: <49993806.1000204@xefion.com>
	<499954F4.3080101@resolversystems.com>
Message-ID: <8cd017b80902160409o7317042evde27964874815e26@mail.gmail.com>

It will.. eventually..after the modules import completed..

On Mon, Feb 16, 2009 at 1:58 PM, Giles Thomas <
giles.thomas at resolversystems.com> wrote:

> IronPython in a spreadsheet?  Terrible idea, it'll never work ;-)
>
>
> Cheers,
>
> Giles
>
> --
> Giles Thomas
> giles.thomas at resolversystems.com
> +44 (0) 20 7253 6372
>
> Win up to $17,000 for a spreadsheet: <
> http://www.resolversystems.com/competition/>
>
> 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
>
>
>
>
> Thomas P. Boesen wrote:
>
>> Hi,
>>
>> I am thinking about creating an Excel add-in that makes it very easy to
>> create Excel macros / add-ins using Python (IronPython)
>>
>> Any feedback about the idea will be greatly appreciated.
>>
>> I have made a prototype of this add-in available here:
>> http://www.xefion.com/en/discoveryscript.html
>>
>> The add-in would be free, although not open-source.
>>
>> It takes quite a bit of "plumbing" to get COM add-ins running within
>> Excel. My add-in would look for Python scripts in a specific directory
>> and automatically create Excel menu-items for all the scripts in that
>> directory. Hence, to get started the user just has to create a one-line
>> Python script and store this script in the designated folder, then he
>> can run the script from Excel.
>>
>> There will be various other options, for example shared network
>> locations with scripts and connecting Excel events (e.g. OpenDoc or
>> SaveDoc) to scripts based on their names. Later versions might also work
>> with other Office programs (e.g. Word). The download-page mentioned
>> above contains a description of feature candidates.
>>
>> :-) Thomas P. Boesen
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
> --
> Giles Thomas
> giles.thomas at resolversystems.com
> +44 (0) 20 7253 6372
>
> Win up to $17,000 for a spreadsheet: <
> http://www.resolversystems.com/competition/>
>
> 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 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/20090216/321c9736/attachment.html>

From janrou at gmail.com  Mon Feb 16 18:47:16 2009
From: janrou at gmail.com (Jan R)
Date: Mon, 16 Feb 2009 18:47:16 +0100
Subject: [IronPython] IronPython WCF service implementation problem
Message-ID: <d1f1bd120902160947l3d54c92fg91caacf11581b846@mail.gmail.com>

Hi,

I try to implement WCF services with a IronPython script. I try to implement
the services for ICalculator in the WCF get started sample tutorial, see
attachments below and
http://msdn.microsoft.com/da-dk/library/ms751519(en-us).aspx.

Unfortunately I get the follwing Exception "InvalidOperationException" with
the message:

"In order to use one of the ServiceHost constructors that takes a service
instance, the InstanceContextMode of the service must be set to
InstanceContextMode.Single.  This can be configured via the
ServiceBehaviorAttribute.  Otherwise, please consider using the ServiceHost
constructors that take a Type argument."

How do I set the appriated InstanceContextMode of the python class
implemeting the services.

Please help me out!


Regards
Jan Rouvillain

Attachments.

Program.cs:


using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.ServiceModel;

using System.ServiceModel.Description;

using IronPython;

using IronPython.Hosting;

using Microsoft.Scripting;

using Microsoft.Scripting.Hosting;

namespace Microsoft.ServiceModel.Samples

{

class Program

{

static void Main(string[] args)

{

Uri baseAddress = new Uri("http://localhost:8000/ServiceModelSamples/Service");

// Se up python implmentation

PythonRunner pyr = new PythonRunner();

pyr.loadscript(@"..\..\..\Calculator\Calculator.py");

pyr.run();

ICalculator pyCalc = (ICalculator)pyr.getInstance("PyCalculator");

ServiceHost selfHost = new ServiceHost( (object) pyCalc, baseAddress);

try

{

// Step 3 of the hosting procedure: Add a service endpoint.

selfHost.AddServiceEndpoint(

typeof(ICalculator),

new WSHttpBinding(),

"CalculatorService");

// Step 4 of the hosting procedure: Enable metadata exchange.

ServiceMetadataBehavior smb = new ServiceMetadataBehavior();

smb.HttpGetEnabled = true;

selfHost.Description.Behaviors.Add(smb);

// Step 5 of the hosting procedure: Start (and then stop) the service.

selfHost.Open();

Console.WriteLine("The service is ready.");

Console.WriteLine("Press <ENTER> to terminate service.");

Console.WriteLine();

Console.ReadLine();

// Close the ServiceHostBase to shutdown the service.

selfHost.Close();

}

catch (CommunicationException ce)

{

Console.WriteLine("An exception occurred: {0}", ce.Message);

selfHost.Abort();

}

}

}

public class PythonRunner

{

Dictionary<String, Object> options;

private ScriptEngine engine;

private ScriptScope scope;

private CompiledCode code;

public PythonRunner()

{

InitializePythonEngine();

}

public void InitializePythonEngine()

{

options = new Dictionary<string, object>();

options["DivisionOptions"] = PythonDivisionOptions.New;

engine = Python.CreateEngine(options);

}

public void loadscript(string scriptPath)

{

ScriptSource script = engine.CreateScriptSourceFromFile(scriptPath);

code = script.Compile();

scope = engine.CreateScope();

}

public void SetVariable(string name, object value)

{

scope.SetVariable( name, value);

}

public void run()

{

try

{

code.Execute(scope);

}

catch (Exception exc)

{

Console.WriteLine("Python exception: " + exc.ToString());

}

}

public Object getInstance(string className)

{

ObjectOperations ops = engine.Operations;

object obj = scope.GetVariable(className);

return (Object) ops.Call(obj);

}

}

}







CalaculatorService.cs:



using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.ServiceModel;

namespace Microsoft.ServiceModel.Samples

{

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]

public interface ICalculator

{

    // Step7: Create the method declaration for the contract.

    [OperationContract]

    double Add(double n1, double n2);



    [OperationContract]

    double Subtract(double n1, double n2);



    [OperationContract]

    double Multiply(double n1, double n2);



    [OperationContract]

    double Divide(double n1, double n2);

    }

}



Calculator.py



import clr

clr.AddReference('PlatformService')

from Microsoft.ServiceModel.Samples import ICalculator



class PyCalculator(ICalculator):

    "Implements calculator services"



    def Add(self, a, b):

        print 'a ' + a + ' + b ' + b

        return a+b

    def Subtract(self, a, b):

        print 'a ' + a + ' - b ' + b

        return a-b

    def Multiply(self, a, b):

        print 'a ' + a + ' * b ' + b

        return a*b



    def Divide(self, a, b):

        print 'a ' + a + ' // b ' + b

        return a/b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090216/bac4f4ce/attachment.html>

From dinov at microsoft.com  Mon Feb 16 19:05:19 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 16 Feb 2009 10:05:19 -0800
Subject: [IronPython] try breaks traceback
In-Reply-To: <E3E4C7D6B896A043805949D136C327F4027D7A48@SYDEXCVS0.aar.com.au>
References: <E3E4C7D6B896A043805949D136C327F4027D7A48@SYDEXCVS0.aar.com.au>
Message-ID: <350E7D38B6D819428718949920EC2355571BBDA120@NA-EXMSG-C102.redmond.corp.microsoft.com>

This is definitely a bug (and quite an annoying one at that).  I've opened CodePlex bug #21199 to track the issue (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21199).  Thanks for the report!

I'll try and get this fixed in 2.6 fairly soon and depending on what the fix looks like it might get back ported to 2.0.2.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Howland-Rose, Kyle
Sent: Thursday, February 12, 2009 3:23 PM
To: users at lists.ironpython.com
Subject: [IronPython] try breaks traceback

Hi all,

ipy 2.0 traceback seems to lose track of where exceptions come from inside try-except blocks (which hampers debugging):

bash-3.2$ cat foo.py
import bar
class E(Exception):
  def __init__(self, message):
    Exception.__init__(self, message)
try:
 bar.baz()
except E, ex:
 pass

bash-3.2$ cat bar.py
def baz():
 "".sort(key=key_comparer.key)

bash-3.2$ ipy foo.py
Traceback (most recent call last):
  File "foo.py", line 6, in foo.py
AttributeError: 'str' object has no attribute 'sort'bash-3.2$

if I take the try-except block out I get the correct module line number:

bash-3.2$ cat foo2.py
import bar
class E(Exception):
  def __init__(self, message):
    Exception.__init__(self, message)
bar.baz()

bash-3.2$ ipy foo2.py
Traceback (most recent call last):
  File "foo2.py", line 5, in foo2.py
  File "h:\jobs\chris21views\bar.py", line 2, in baz
AttributeError: 'str' object has no attribute 'sort'bash-3.2$

Before I raise a bug I thought I would just check that I am not missing something here.

Thanks, Kyle



************************************************************************

Allens Arthur Robinson online: http://www.aar.com.au

This email is confidential and may be subject to legal or other professional privilege. It is also subject to copyright. If you have received it in error, confidentiality and privilege are not waived and you must not disclose or use the information in it. Please notify the sender by return email and delete it from your system. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth).

*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090216/31b3c2b8/attachment.html>

From ivan at flanders.co.nz  Mon Feb 16 19:10:20 2009
From: ivan at flanders.co.nz (Ivan Porto Carrero)
Date: Mon, 16 Feb 2009 19:10:20 +0100
Subject: [IronPython] IronPython WCF service implementation problem
In-Reply-To: <d1f1bd120902160947l3d54c92fg91caacf11581b846@mail.gmail.com>
References: <d1f1bd120902160947l3d54c92fg91caacf11581b846@mail.gmail.com>
Message-ID: <b1c6aabb0902161010r72841aa2q9c1b99e0387117b9@mail.gmail.com>

I guess you're stuck with implementing a skeleton class in C# that you then
monkey patch (don't know the term for Python) to give the implementation in
python

2009/2/16 Jan R <janrou at gmail.com>

> Hi,
>
> I try to implement WCF services with a IronPython script. I try to
> implement the services for ICalculator in the WCF get started sample
> tutorial, see attachments below and
> http://msdn.microsoft.com/da-dk/library/ms751519(en-us).aspx<http://msdn.microsoft.com/da-dk/library/ms751519%28en-us%29.aspx>
> .
>
> Unfortunately I get the follwing Exception "InvalidOperationException" with
> the message:
>
> "In order to use one of the ServiceHost constructors that takes a service
> instance, the InstanceContextMode of the service must be set to
> InstanceContextMode.Single.  This can be configured via the
> ServiceBehaviorAttribute.  Otherwise, please consider using the ServiceHost
> constructors that take a Type argument."
>
> How do I set the appriated InstanceContextMode of the python class
> implemeting the services.
>
> Please help me out!
>
>
> Regards
> Jan Rouvillain
>
> Attachments.
>
> Program.cs:
>
>
> using System;
>
> using System.Collections.Generic;
>
> using System.Linq;
>
> using System.Text;
>
> using System.ServiceModel;
>
> using System.ServiceModel.Description;
>
> using IronPython;
>
> using IronPython.Hosting;
>
> using Microsoft.Scripting;
>
> using Microsoft.Scripting.Hosting;
>
> namespace Microsoft.ServiceModel.Samples
>
> {
>
> class Program
>
> {
>
> static void Main(string[] args)
>
> {
>
> Uri baseAddress = new Uri("http://localhost:8000/ServiceModelSamples/Service");
>
> // Se up python implmentation
>
> PythonRunner pyr = new PythonRunner();
>
> pyr.loadscript(@"..\..\..\Calculator\Calculator.py");
>
>
> pyr.run();
>
> ICalculator pyCalc = (ICalculator)pyr.getInstance("PyCalculator");
>
> ServiceHost selfHost = new ServiceHost( (object) pyCalc, baseAddress);
>
> try
>
> {
>
> // Step 3 of the hosting procedure: Add a service endpoint.
>
> selfHost.AddServiceEndpoint(
>
> typeof(ICalculator),
>
> new WSHttpBinding(),
>
> "CalculatorService");
>
> // Step 4 of the hosting procedure: Enable metadata exchange.
>
> ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
>
> smb.HttpGetEnabled = true;
>
> selfHost.Description.Behaviors.Add(smb);
>
> // Step 5 of the hosting procedure: Start (and then stop) the service.
>
>
> selfHost.Open();
>
> Console.WriteLine("The service is ready.");
>
> Console.WriteLine("Press <ENTER> to terminate service.");
>
> Console.WriteLine();
>
> Console.ReadLine();
>
> // Close the ServiceHostBase to shutdown the service.
>
>
> selfHost.Close();
>
> }
>
> catch (CommunicationException ce)
>
> {
>
> Console.WriteLine("An exception occurred: {0}", ce.Message);
>
> selfHost.Abort();
>
> }
>
> }
>
> }
>
> public class PythonRunner
>
> {
>
> Dictionary<String, Object> options;
>
> private ScriptEngine engine;
>
> private ScriptScope scope;
>
> private CompiledCode code;
>
> public PythonRunner()
>
> {
>
> InitializePythonEngine();
>
> }
>
> public void InitializePythonEngine()
>
> {
>
> options = new Dictionary<string, object>();
>
> options["DivisionOptions"] = PythonDivisionOptions.New;
>
> engine = Python.CreateEngine(options);
>
> }
>
> public void loadscript(string scriptPath)
>
> {
>
> ScriptSource script = engine.CreateScriptSourceFromFile(scriptPath);
>
>
> code = script.Compile();
>
> scope = engine.CreateScope();
>
> }
>
> public void SetVariable(string name, object value)
>
> {
>
> scope.SetVariable( name, value);
>
> }
>
> public void run()
>
> {
>
> try
>
> {
>
> code.Execute(scope);
>
> }
>
> catch (Exception exc)
>
> {
>
> Console.WriteLine("Python exception: " + exc.ToString());
>
> }
>
> }
>
> public Object getInstance(string className)
>
> {
>
> ObjectOperations ops = engine.Operations;
>
> object obj = scope.GetVariable(className);
>
> return (Object) ops.Call(obj);
>
> }
>
> }
>
> }
>
>
>
>
>
>
>
> CalaculatorService.cs:
>
>
>
> using System;
>
> using System.Collections.Generic;
>
> using System.Linq;
>
> using System.Text;
>
> using System.ServiceModel;
>
> namespace Microsoft.ServiceModel.Samples
>
> {
>
> [ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
>
> public interface ICalculator
>
> {
>
>     // Step7: Create the method declaration for the contract.
>
>     [OperationContract]
>
>     double Add(double n1, double n2);
>
>
>
>     [OperationContract]
>
>     double Subtract(double n1, double n2);
>
>
>
>     [OperationContract]
>
>     double Multiply(double n1, double n2);
>
>
>
>     [OperationContract]
>
>     double Divide(double n1, double n2);
>
>     }
>
> }
>
>
>
> Calculator.py
>
>
>
> import clr
>
> clr.AddReference('PlatformService')
>
> from Microsoft.ServiceModel.Samples import ICalculator
>
>
>
> class PyCalculator(ICalculator):
>
>     "Implements calculator services"
>
>
>
>     def Add(self, a, b):
>
>         print 'a ' + a + ' + b ' + b
>
>         return a+b
>
>     def Subtract(self, a, b):
>
>         print 'a ' + a + ' - b ' + b
>
>         return a-b
>
>     def Multiply(self, a, b):
>
>         print 'a ' + a + ' * b ' + b
>
>         return a*b
>
>
>
>     def Divide(self, a, b):
>
>         print 'a ' + a + ' // b ' + b
>
>         return a/b
>
>
>
>
>
>
> _______________________________________________
> 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/20090216/b8345d93/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Feb 16 23:23:06 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 16 Feb 2009 22:23:06 +0000
Subject: [IronPython] Logging module
Message-ID: <4999E74A.1020505@voidspace.org.uk>

Codeplex item 21122 has just been closed: Python 2.5.2 logging module 
doesn't work

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21122

As far as I can tell it has been closed because _getframe support is 
needed for it to work. Instead why not distribute a patched version like 
FePy does?

That would seem a much better solution until _getframe is implemented 
and exactly the sort of thing that distributing the standard library 
would allow the IronPython team to do?

Michael

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




From curt at hagenlocher.org  Mon Feb 16 23:37:20 2009
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Mon, 16 Feb 2009 14:37:20 -0800
Subject: [IronPython] Logging module
In-Reply-To: <4999E74A.1020505@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
Message-ID: <d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>

That would require lawyers and nothing which involves lawyers is simple. :(
But let's say that someone else were to patch the logging module to test for
the presence of sys._getframe and perform an appropriate fallback when it's
not present.  If this patch were then submitted back to Python and
incorporated into the standard Python library, we'd naturally pick up and
take advantage of the change...

We're working on fixing this process, of course.

On Mon, Feb 16, 2009 at 2:23 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

> Codeplex item 21122 has just been closed: Python 2.5.2 logging module
> doesn't work
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21122
>
> As far as I can tell it has been closed because _getframe support is needed
> for it to work. Instead why not distribute a patched version like FePy does?
>
> That would seem a much better solution until _getframe is implemented and
> exactly the sort of thing that distributing the standard library would allow
> the IronPython team to do?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090216/4c309133/attachment.html>

From fuzzyman at voidspace.org.uk  Mon Feb 16 23:39:02 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 16 Feb 2009 22:39:02 +0000
Subject: [IronPython] Logging module
In-Reply-To: <d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
Message-ID: <4999EB06.5010302@voidspace.org.uk>

Curt Hagenlocher wrote:
> That would require lawyers and nothing which involves lawyers is 
> simple. :(

If you already have permission to distribute the standard library then 
it is unfortunate that *more* permission is needed to modify it. Sounds 
like the wrong question was asked. :-(

Oh well - good that this is being worked on.
>
> But let's say that someone else were to patch the logging module to 
> test for the presence of sys._getframe and perform an appropriate 
> fallback when it's not present.  If this patch were then submitted 
> back to Python and incorporated into the standard Python library, we'd 
> naturally pick up and take advantage of the change...
I'll see what I can do.

Michael

>
> We're working on fixing this process, of course.
>
> On Mon, Feb 16, 2009 at 2:23 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Codeplex item 21122 has just been closed: Python 2.5.2 logging
>     module doesn't work
>
>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21122
>
>     As far as I can tell it has been closed because _getframe support
>     is needed for it to work. Instead why not distribute a patched
>     version like FePy does?
>
>     That would seem a much better solution until _getframe is
>     implemented and exactly the sort of thing that distributing the
>     standard library would allow the IronPython team to do?
>
>     Michael
>
>     -- 
>     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  Mon Feb 16 23:59:06 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 16 Feb 2009 14:59:06 -0800
Subject: [IronPython] Logging module
In-Reply-To: <4999EB06.5010302@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>

Just to be clear - we could probably redistrubte a modified standard library if we wanted to, the bar for that is probably not too high compared to contributions.  But we've made a conscious decision to not do this - we'd like to get the point where we can give our changes back to the CPython community rather than forking the library.  So yes we did ask the wrong question but we also meant to :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, February 16, 2009 2:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Logging module

Curt Hagenlocher wrote:
> That would require lawyers and nothing which involves lawyers is 
> simple. :(

If you already have permission to distribute the standard library then 
it is unfortunate that *more* permission is needed to modify it. Sounds 
like the wrong question was asked. :-(

Oh well - good that this is being worked on.
>
> But let's say that someone else were to patch the logging module to 
> test for the presence of sys._getframe and perform an appropriate 
> fallback when it's not present.  If this patch were then submitted 
> back to Python and incorporated into the standard Python library, we'd 
> naturally pick up and take advantage of the change...
I'll see what I can do.

Michael

>
> We're working on fixing this process, of course.
>
> On Mon, Feb 16, 2009 at 2:23 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Codeplex item 21122 has just been closed: Python 2.5.2 logging
>     module doesn't work
>
>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21122
>
>     As far as I can tell it has been closed because _getframe support
>     is needed for it to work. Instead why not distribute a patched
>     version like FePy does?
>
>     That would seem a much better solution until _getframe is
>     implemented and exactly the sort of thing that distributing the
>     standard library would allow the IronPython team to do?
>
>     Michael
>
>     -- 
>     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


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


From fuzzyman at voidspace.org.uk  Tue Feb 17 00:01:40 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 16 Feb 2009 23:01:40 +0000
Subject: [IronPython] Logging module
In-Reply-To: <350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4999E74A.1020505@voidspace.org.uk>	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4999F054.4040008@voidspace.org.uk>

Dino Viehland wrote:
> Just to be clear - we could probably redistrubte a modified standard library if we wanted to, the bar for that is probably not too high compared to contributions.  But we've made a conscious decision to not do this - we'd like to get the point where we can give our changes back to the CPython community rather than forking the library.  So yes we did ask the wrong question but we also meant to :)
>   

Fair enough then. I'm just putting together a patch and will ask the 
guys on Python-Dev if we can get it into Python 2.6. You'll have to help 
me remember to pull it out once we have frames again!

I might not be able to sneak the patch in on 2.6-maint, so it might have 
to wait until 2.7.

Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, February 16, 2009 2:39 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Logging module
>
> Curt Hagenlocher wrote:
>   
>> That would require lawyers and nothing which involves lawyers is 
>> simple. :(
>>     
>
> If you already have permission to distribute the standard library then 
> it is unfortunate that *more* permission is needed to modify it. Sounds 
> like the wrong question was asked. :-(
>
> Oh well - good that this is being worked on.
>   
>> But let's say that someone else were to patch the logging module to 
>> test for the presence of sys._getframe and perform an appropriate 
>> fallback when it's not present.  If this patch were then submitted 
>> back to Python and incorporated into the standard Python library, we'd 
>> naturally pick up and take advantage of the change...
>>     
> I'll see what I can do.
>
> Michael
>
>   
>> We're working on fixing this process, of course.
>>
>> On Mon, Feb 16, 2009 at 2:23 PM, Michael Foord 
>> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>
>>     Codeplex item 21122 has just been closed: Python 2.5.2 logging
>>     module doesn't work
>>
>>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21122
>>
>>     As far as I can tell it has been closed because _getframe support
>>     is needed for it to work. Instead why not distribute a patched
>>     version like FePy does?
>>
>>     That would seem a much better solution until _getframe is
>>     implemented and exactly the sort of thing that distributing the
>>     standard library would allow the IronPython team to do?
>>
>>     Michael
>>
>>     -- 
>>     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  Tue Feb 17 02:00:57 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 16 Feb 2009 17:00:57 -0800
Subject: [IronPython] Logging module
In-Reply-To: <4999F054.4040008@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4999F054.4040008@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC2355571BBDA3E2@NA-EXMSG-C102.redmond.corp.microsoft.com>

Awesome!  At least the fixes can get in somehow :)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, February 16, 2009 3:02 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Logging module

Dino Viehland wrote:
> Just to be clear - we could probably redistrubte a modified standard library if we wanted to, the bar for that is probably not too high compared to contributions.  But we've made a conscious decision to not do this - we'd like to get the point where we can give our changes back to the CPython community rather than forking the library.  So yes we did ask the wrong question but we also meant to :)
>   

Fair enough then. I'm just putting together a patch and will ask the 
guys on Python-Dev if we can get it into Python 2.6. You'll have to help 
me remember to pull it out once we have frames again!

I might not be able to sneak the patch in on 2.6-maint, so it might have 
to wait until 2.7.

Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, February 16, 2009 2:39 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Logging module
>
> Curt Hagenlocher wrote:
>   
>> That would require lawyers and nothing which involves lawyers is 
>> simple. :(
>>     
>
> If you already have permission to distribute the standard library then 
> it is unfortunate that *more* permission is needed to modify it. Sounds 
> like the wrong question was asked. :-(
>
> Oh well - good that this is being worked on.
>   
>> But let's say that someone else were to patch the logging module to 
>> test for the presence of sys._getframe and perform an appropriate 
>> fallback when it's not present.  If this patch were then submitted 
>> back to Python and incorporated into the standard Python library, we'd 
>> naturally pick up and take advantage of the change...
>>     
> I'll see what I can do.
>
> Michael
>
>   
>> We're working on fixing this process, of course.
>>
>> On Mon, Feb 16, 2009 at 2:23 PM, Michael Foord 
>> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>
>>     Codeplex item 21122 has just been closed: Python 2.5.2 logging
>>     module doesn't work
>>
>>     http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21122
>>
>>     As far as I can tell it has been closed because _getframe support
>>     is needed for it to work. Instead why not distribute a patched
>>     version like FePy does?
>>
>>     That would seem a much better solution until _getframe is
>>     implemented and exactly the sort of thing that distributing the
>>     standard library would allow the IronPython team to do?
>>
>>     Michael
>>
>>     -- 
>>     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


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



From dan.eloff at gmail.com  Tue Feb 17 05:44:33 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Mon, 16 Feb 2009 23:44:33 -0500
Subject: [IronPython] Logging module
In-Reply-To: <4999F054.4040008@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4999F054.4040008@voidspace.org.uk>
Message-ID: <4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>

On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
>
> Fair enough then. I'm just putting together a patch and will ask the guys on
> Python-Dev if we can get it into Python 2.6. You'll have to help me remember
> to pull it out once we have frames again!
>

I'd suggest that we don't pull it out. It'd make it an easier decision
for the python-devs for one, I can't imagine they'd be enthusiastic to
accept a temporary patch. But the main thing being that frame support
will likely cause serious performance depredation, which means it's
likely to be an optional feature, hence we'd need that check anyway.
And then there's always Jython, which, as far as I know, would need
the same check.

So what kind of condition could we use that works with Jython and
IronPython currently, that won't break when IronPython does introduce
frames support (regardless of whether or not it has been enabled?)

Maybe just wrap it in a try/except?:

try:
    foo = sys._getframe(1)
except (ValueError, AttributeError): # for IronPython, Jython
    foo = None

Assuming Jython raises an AttributeError, which I do not know to be the case.

-Dan


From fuzzyman at voidspace.org.uk  Tue Feb 17 10:50:53 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 09:50:53 +0000
Subject: [IronPython] Logging module
In-Reply-To: <4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>
References: <4999E74A.1020505@voidspace.org.uk>	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>	<4999EB06.5010302@voidspace.org.uk>	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4999F054.4040008@voidspace.org.uk>
	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>
Message-ID: <499A887D.8080507@voidspace.org.uk>

Dan Eloff wrote:
> On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>> Fair enough then. I'm just putting together a patch and will ask the guys on
>> Python-Dev if we can get it into Python 2.6. You'll have to help me remember
>> to pull it out once we have frames again!
>>
>>     
>
> I'd suggest that we don't pull it out. It'd make it an easier decision
> for the python-devs for one, I can't imagine they'd be enthusiastic to
> accept a temporary patch. But the main thing being that frame support
> will likely cause serious performance depredation, which means it's
> likely to be an optional feature, hence we'd need that check anyway.
> And then there's always Jython, which, as far as I know, would need
> the same check.
>
> So what kind of condition could we use that works with Jython and
> IronPython currently, that won't break when IronPython does introduce
> frames support (regardless of whether or not it has been enabled?)
>
> Maybe just wrap it in a try/except?:
>
> try:
>     foo = sys._getframe(1)
> except (ValueError, AttributeError): # for IronPython, Jython
>     foo = None
>
> Assuming Jython raises an AttributeError, which I do not know to be the case.
>   

The actual patch is much simpler:

http://bugs.python.org/issue5287

We just need to set _srcfile to None and it prevents logging from 
calling _getframe at all.

I've posted the patch and asked the Python-dev guys to consider 
including it in Python 2.6.

On a side note - anyone know where tlbimp gets installed on Vista64?

Michael

> -Dan
> _______________________________________________
> 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 codekaizen at gmail.com  Tue Feb 17 10:55:44 2009
From: codekaizen at gmail.com (Rory Plaire)
Date: Tue, 17 Feb 2009 01:55:44 -0800
Subject: [IronPython] Logging module
In-Reply-To: <499A887D.8080507@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4999F054.4040008@voidspace.org.uk>
	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>
	<499A887D.8080507@voidspace.org.uk>
Message-ID: <bb8cb9ce0902170155q6fcf9484jb60c494d64cc632f@mail.gmail.com>

>
> On a side note - anyone know where tlbimp gets installed on Vista64?
>
>
Mine's in "C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin"

-rory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090217/8fff060a/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Feb 17 10:59:18 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 09:59:18 +0000
Subject: [IronPython] Logging module
In-Reply-To: <bb8cb9ce0902170155q6fcf9484jb60c494d64cc632f@mail.gmail.com>
References: <4999E74A.1020505@voidspace.org.uk>	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>	<4999EB06.5010302@voidspace.org.uk>	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4999F054.4040008@voidspace.org.uk>	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>	<499A887D.8080507@voidspace.org.uk>
	<bb8cb9ce0902170155q6fcf9484jb60c494d64cc632f@mail.gmail.com>
Message-ID: <499A8A76.2050202@voidspace.org.uk>

Rory Plaire wrote:
>
>     On a side note - anyone know where tlbimp gets installed on Vista64?
>
>  
> Mine's in "C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin"

Thank you. For the sake of future googlers mine was actually in: 
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin

I've been hunting for a while - so very grateful, thanks Rory.

Michael
>  
> -rory
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 janrou at gmail.com  Tue Feb 17 12:59:55 2009
From: janrou at gmail.com (Jan R)
Date: Tue, 17 Feb 2009 12:59:55 +0100
Subject: [IronPython] How to do the typeof( ) call on an IronPython
	implemented class in C#?
Message-ID: <d1f1bd120902170359t38c253d1lff809d8ef55bcfa0@mail.gmail.com>

Hello IronPython Experts.


How to do the typeof( ) call on an IronPython implemented class in C#?

The need to do a typeof(..) comes from implementing services in Windows
Communication Foundation (WCF) in IronPython. The WCF get-statrted sample
uses the overloaded constructor of the ServiceHost class that takes a
System.Type:

ServiceHost selfHost = new ServiceHost(typeof(CalculatorService), baseAddress);


I want to replace the CalculatorService with a IronPython class
PyCalculator. Note the typeof(...).

 I have tried the following without success, in order to give an instance of
the IronPython class to the ServiceHost constructor :

ICalculator pyCalc = (ICalculator)pyr.getInstance("PyCalculator");
ServiceHost selfHost = new ServiceHost( (object) pyCalc, baseAddress);

The IronPython class is attached below. The code results in an exception,
because the attribute InstanceContextMode have to be set to
InstanceContextMode.Single.

The WCF get-started sample is here:
http://msdn.microsoft.com/da-dk/library/ms734712(en-us).aspx

Can anyone help me out?


Regards
Jan Rouvillain

IronPython code:

import clr
clr.AddReference('CalculatorServer')
from Microsoft.ServiceModel.Samples import ICalculator

class PyCalculator(ICalculator):
  "Implements calculator services"

  def Add(self, a, b):
    print 'a ' + a + ' +  b ' + b
    return a+b

  def Subtract(self, a, b):
    print 'a ' + a + ' -  b ' + b
    return a-b

  def Multiply(self, a, b):
    print 'a ' + a + ' * b ' + b
    return a*b

  def Divide(self, a, b):
    print 'a ' + a + ' // b ' + b
    return a/b

C# interface declaration:

namespace Microsoft.ServiceModel.Samples
{
  [ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
  public interface ICalculator
  {
    // Step7: Create the method declaration for the contract.
    [OperationContract]
    double Add(double n1, double n2);
    [OperationContract]
    double Subtract(double n1, double n2);
    [OperationContract]
    double Multiply(double n1, double n2);
    [OperationContract]
    double Divide(double n1, double n2);
  }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090217/74ee176e/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Feb 17 13:18:41 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 12:18:41 +0000
Subject: [IronPython] How to do the typeof( ) call on an
 IronPython	implemented class in C#?
In-Reply-To: <d1f1bd120902170359t38c253d1lff809d8ef55bcfa0@mail.gmail.com>
References: <d1f1bd120902170359t38c253d1lff809d8ef55bcfa0@mail.gmail.com>
Message-ID: <499AAB21.4090501@voidspace.org.uk>

Jan R wrote:
> Hello IronPython Experts.
>
>
> How to do the typeof( ) call on an IronPython implemented class in C#?
>
> The need to do a typeof(..) comes from implementing services in 
> Windows Communication Foundation (WCF) in IronPython. The WCF 
> get-statrted sample uses the overloaded constructor of the ServiceHost 
> class that takes a System.Type:
>
> ServiceHost selfHost = new ServiceHost(typeof(CalculatorService), baseAddress);
>
> I want to replace the CalculatorService with a IronPython class 
> PyCalculator. Note the typeof(...).
>
>  I have tried the following without success, in order to give an 
> instance of the IronPython class to the ServiceHost constructor :
>
> ICalculator pyCalc = (ICalculator)pyr.getInstance("PyCalculator");
> ServiceHost selfHost = new ServiceHost( (object) pyCalc, baseAddress);

Can't you do the following?

ServiceHost selfHost = new ServiceHost(typeof(ICalculator), baseAddress);


Michael
>
> The IronPython class is attached below. The code results in an 
> exception, because the attribute InstanceContextMode have to be set to 
> InstanceContextMode.Single.
>
> The WCF get-started sample is here: 
> http://msdn.microsoft.com/da-dk/library/ms734712(en-us).aspx 
> <http://msdn.microsoft.com/da-dk/library/ms734712%28en-us%29.aspx>
>
> Can anyone help me out?
>
>
> Regards
> Jan Rouvillain
>
> IronPython code:
>
> import clr
> clr.AddReference('CalculatorServer')
> from Microsoft.ServiceModel.Samples import ICalculator
>
> class PyCalculator(ICalculator):
>   "Implements calculator services"
>
>   def Add(self, a, b):
>     print 'a ' + a + ' +  b ' + b
>     return a+b
>
>   def Subtract(self, a, b):
>     print 'a ' + a + ' -  b ' + b
>     return a-b
>
>   def Multiply(self, a, b):
>     print 'a ' + a + ' * b ' + b
>     return a*b
>
>   def Divide(self, a, b):
>     print 'a ' + a + ' // b ' + b
>     return a/b
>
> C# interface declaration:
>
> namespace Microsoft.ServiceModel.Samples
> {
>   [ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
>   public interface ICalculator
>   {
>     // Step7: Create the method declaration for the contract.
>     [OperationContract]
>     double Add(double n1, double n2);
>     [OperationContract]
>     double Subtract(double n1, double n2);
>     [OperationContract]
>     double Multiply(double n1, double n2);
>     [OperationContract]
>     double Divide(double n1, double n2);
>   }
> }
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 janrou at gmail.com  Tue Feb 17 13:54:54 2009
From: janrou at gmail.com (Jan R)
Date: Tue, 17 Feb 2009 13:54:54 +0100
Subject: [IronPython] How to do the typeof( ) call on an IronPython
	implemented class in C#?
In-Reply-To: <499AAB21.4090501@voidspace.org.uk>
References: <d1f1bd120902170359t38c253d1lff809d8ef55bcfa0@mail.gmail.com>
	<499AAB21.4090501@voidspace.org.uk>
Message-ID: <d1f1bd120902170454j550fe384w6a80dc3b3a1a8bb2@mail.gmail.com>

>
> Can't you do the following?
>
> ServiceHost selfHost = new ServiceHost(typeof(ICalculator), baseAddress);
>
>
> Michael
>
>>
 No!

The class given as parameter to typeof(..) have to implement the interface.
The interface is the service contract, which the server implements.

I have worked around the problem with a stub, that loads and runs the python
script, see attachment. For each stubbed method it calls the python
implemented method:

It would be smart to get rid of the stub.


Regards
Jan Rouvillain

C# stub:

  public class CalculatorServiceStub : ICalculator
  {
    private ICalculator pyCalc;
    public CalculatorServiceStub()
    {
      if (Program.pyr != null)
      {
        Program.pyr.loadscript(@"..\..\..\Calculator\Calculator.py");
        Program.pyr.run();
        pyCalc = (ICalculator)Program.pyr.getInstance("PyCalculator");
      }
    }
    public double Add(double n1, double n2)
    {
      return pyCalc.Add(n1,n2);
    }
    public double Subtract(double n1, double n2)
    {
      return pyCalc.Subtract(n1, n2);
    }
    public double Multiply(double n1, double n2)
    {
      return pyCalc.Multiply(n1, n2);
    }
    public double Divide(double n1, double n2)
    {
      return pyCalc.Divide(n1, n2);
    }
 }

The class PythonRunner is an adapter for loading, compiling, excuting,
instantiating objects and exchanging variables in and out of the script
Calculator.py.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090217/8b737d26/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Feb 17 13:59:36 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 12:59:36 +0000
Subject: [IronPython] How to do the typeof( ) call on an IronPython
 implemented class in C#?
In-Reply-To: <d1f1bd120902170454j550fe384w6a80dc3b3a1a8bb2@mail.gmail.com>
References: <d1f1bd120902170359t38c253d1lff809d8ef55bcfa0@mail.gmail.com>	
	<499AAB21.4090501@voidspace.org.uk>
	<d1f1bd120902170454j550fe384w6a80dc3b3a1a8bb2@mail.gmail.com>
Message-ID: <499AB4B8.4020004@voidspace.org.uk>

Jan R wrote:
>
>     Can't you do the following?
>
>     ServiceHost selfHost = new ServiceHost(typeof(ICalculator),
>     baseAddress);
>
>
>     Michael
>
>
>  No!
>
> The class given as parameter to typeof(..) have to implement the 
> interface. The interface is the service contract, which the server 
> implements.
>
> I have worked around the problem with a stub, that loads and runs the 
> python script, see attachment. For each stubbed method it calls the 
> python implemented method:
>
> It would be smart to get rid of the stub.

You could at least define the stub in C# with empty implementations - 
and then have your Python class subclass that directly rather than from 
the interface. You could then cast pyClass to the concrete type rather 
than the interface.

A *bit* less work and cleaner. The joy of statically typed languages. :-)

Michael
>
>
> Regards
> Jan Rouvillain
>
> C# stub:
>
>   public class CalculatorServiceStub : ICalculator
>   {
>     private ICalculator pyCalc;
>     public CalculatorServiceStub()
>     {
>       if (Program.pyr != null)
>       {
>         Program.pyr.loadscript(@"..\..\..\Calculator\Calculator.py");
>         Program.pyr.run();
>         pyCalc = (ICalculator)Program.pyr.getInstance("PyCalculator");
>       }
>     }
>     public double Add(double n1, double n2)
>     {
>       return pyCalc.Add(n1,n2);
>     }
>     public double Subtract(double n1, double n2)
>     {
>       return pyCalc.Subtract(n1, n2);
>     }
>     public double Multiply(double n1, double n2)
>     {
>       return pyCalc.Multiply(n1, n2);
>     }
>     public double Divide(double n1, double n2)
>     {
>       return pyCalc.Divide(n1, n2);
>     }
>  }
>
> The class PythonRunner is an adapter for loading, compiling, excuting, 
> instantiating objects and exchanging variables in and out of the 
> script Calculator.py.


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




From sheetal_gophane at persistent.co.in  Tue Feb 17 17:23:02 2009
From: sheetal_gophane at persistent.co.in (Sheetal Gophane)
Date: Tue, 17 Feb 2009 21:53:02 +0530
Subject: [IronPython] Calling WCF service
Message-ID: <004601c9911c$0271e420$0755ac60$@co.in>

Hi,

We are using channel Factory for calling WCF service in ironpython. But when
we give call to a method in that service, the method is not called and it
shows CPU usage almost 100%.
This method takes the request object and returns response.


I am giving the code snippet here.


This is in config file

 

<client>
<endpoint address="net.tcp://127.0.0.1:9083/MessagingService/"
binding="netTcpBinding" bindingConfiguration="BusinessNetTCPBinding"
contract="OnlineAVL.Services.Messaging.Interface.IOnlineAVLMessagingService"
name="MessagingServiceEP" />
</client>


in program.py

import clr



clr.AddReference('System.ServiceModel')
clr.AddReference('System')



import System
import System.ServiceModel



from System.ServiceModel import *



clr.AddReferenceByPartialName('OnlineAVL.Services.Messaging.Interface.dll')

from OnlineAVL.Services.Messaging.Interface import *



_factory = ChannelFactory[IOnlineAVLMessagingService]("MessagingServiceEP")
service = _factory.CreateChannel();


# request object is populated here
req = Request();
req.ID=System.Guid.Empty
req.Version=0

print "calling"
#call to method
res=service.GetPeriodMessagesByOwner(req)

print res


When we execute this, on console it prints "calling" and after that CPU
usage goes up to 100%, and the machine becomes extremely slow and then gives
OutOfMemory Exception. It does not call the service method also.
Any solution to this problem?
Thanks in advance.




-Sheetal

 


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090217/d1181edb/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Feb 17 18:59:45 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 17:59:45 +0000
Subject: [IronPython] [Fwd: [issue5287] logging package on IronPython]
Message-ID: <499AFB11.6050402@voidspace.org.uk>

The patch that was eventually accepted just wraps the call to _getframe
in a try...except - so that if _getframe is working then the package
should still work (I hope I got it right!). It is on 2.6-maint so can
hopefully be included in IronPython 2.6. If the 2.6 branch is released
before the next release of Python 2.6 then it will need to be pulled
from SVN.

Michael

-------- Original Message --------
Subject: 	[issue5287] logging package on IronPython
Date: 	Tue, 17 Feb 2009 17:50:23 +0000
From: 	Vinay Sajip <report at bugs.python.org>
Reply-To: 	Python tracker <report at bugs.python.org>
To: 	michael at voidspace.org.uk



Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into release26-maint.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5287>
_______________________________________


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



From Shri.Borde at microsoft.com  Tue Feb 17 19:02:41 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 17 Feb 2009 10:02:41 -0800
Subject: [IronPython] Logging module
In-Reply-To: <499A887D.8080507@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4999F054.4040008@voidspace.org.uk>
	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>
	<499A887D.8080507@voidspace.org.uk>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>

The proposal is to catch the ValueError exception using a try-except in the log function. Raising a ValueError is not going to be good for perf as exception handling on the CLR is relatively slow and meant for really exceptional circumstances. Ideally, the results of the first call will be cached. Normally, I would not worry about perf without concrete data, but users may be calling logging.log quite heavily with the assumption that it is fairly cheap.

Thanks,
Shri

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, February 17, 2009 1:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Logging module

Dan Eloff wrote:
> On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>> Fair enough then. I'm just putting together a patch and will ask the guys on
>> Python-Dev if we can get it into Python 2.6. You'll have to help me remember
>> to pull it out once we have frames again!
>>
>>     
>
> I'd suggest that we don't pull it out. It'd make it an easier decision
> for the python-devs for one, I can't imagine they'd be enthusiastic to
> accept a temporary patch. But the main thing being that frame support
> will likely cause serious performance depredation, which means it's
> likely to be an optional feature, hence we'd need that check anyway.
> And then there's always Jython, which, as far as I know, would need
> the same check.
>
> So what kind of condition could we use that works with Jython and
> IronPython currently, that won't break when IronPython does introduce
> frames support (regardless of whether or not it has been enabled?)
>
> Maybe just wrap it in a try/except?:
>
> try:
>     foo = sys._getframe(1)
> except (ValueError, AttributeError): # for IronPython, Jython
>     foo = None
>
> Assuming Jython raises an AttributeError, which I do not know to be the case.
>   

The actual patch is much simpler:

http://bugs.python.org/issue5287

We just need to set _srcfile to None and it prevents logging from 
calling _getframe at all.

I've posted the patch and asked the Python-dev guys to consider 
including it in Python 2.6.

On a side note - anyone know where tlbimp gets installed on Vista64?

Michael

> -Dan
> _______________________________________________
> 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  Tue Feb 17 19:06:41 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 18:06:41 +0000
Subject: [IronPython] Logging module
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <4999E74A.1020505@voidspace.org.uk>	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>	<4999EB06.5010302@voidspace.org.uk>	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4999F054.4040008@voidspace.org.uk>	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>	<499A887D.8080507@voidspace.org.uk>
	<710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <499AFCB1.4030802@voidspace.org.uk>

Shri Borde wrote:
> The proposal is to catch the ValueError exception using a try-except in the log function. Raising a ValueError is not going to be good for perf as exception handling on the CLR is relatively slow and meant for really exceptional circumstances. Ideally, the results of the first call will be cached. Normally, I would not worry about perf without concrete data, but users may be calling logging.log quite heavily with the assumption that it is fairly cheap.
>
>   
Given that it probably writes to a stream isn't that going to be much 
more expensive than catching an exception?

Michael

> Thanks,
> Shri
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Tuesday, February 17, 2009 1:51 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Logging module
>
> Dan Eloff wrote:
>   
>> On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
>> <fuzzyman at voidspace.org.uk> wrote:
>>   
>>     
>>> Fair enough then. I'm just putting together a patch and will ask the guys on
>>> Python-Dev if we can get it into Python 2.6. You'll have to help me remember
>>> to pull it out once we have frames again!
>>>
>>>     
>>>       
>> I'd suggest that we don't pull it out. It'd make it an easier decision
>> for the python-devs for one, I can't imagine they'd be enthusiastic to
>> accept a temporary patch. But the main thing being that frame support
>> will likely cause serious performance depredation, which means it's
>> likely to be an optional feature, hence we'd need that check anyway.
>> And then there's always Jython, which, as far as I know, would need
>> the same check.
>>
>> So what kind of condition could we use that works with Jython and
>> IronPython currently, that won't break when IronPython does introduce
>> frames support (regardless of whether or not it has been enabled?)
>>
>> Maybe just wrap it in a try/except?:
>>
>> try:
>>     foo = sys._getframe(1)
>> except (ValueError, AttributeError): # for IronPython, Jython
>>     foo = None
>>
>> Assuming Jython raises an AttributeError, which I do not know to be the case.
>>   
>>     
>
> The actual patch is much simpler:
>
> http://bugs.python.org/issue5287
>
> We just need to set _srcfile to None and it prevents logging from 
> calling _getframe at all.
>
> I've posted the patch and asked the Python-dev guys to consider 
> including it in Python 2.6.
>
> On a side note - anyone know where tlbimp gets installed on Vista64?
>
> Michael
>
>   
>> -Dan
>> _______________________________________________
>> 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 Shri.Borde at microsoft.com  Tue Feb 17 19:18:54 2009
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Tue, 17 Feb 2009 10:18:54 -0800
Subject: [IronPython] Logging module
In-Reply-To: <499AFCB1.4030802@voidspace.org.uk>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4999F054.4040008@voidspace.org.uk>
	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>
	<499A887D.8080507@voidspace.org.uk>
	<710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<499AFCB1.4030802@voidspace.org.uk>
Message-ID: <710DF26F214D2B4BB94287123FFE980A2E0BFD6144@NA-EXMSG-C104.redmond.corp.microsoft.com>

OK, looking closer, the try-except is in _log which is guarded by "if" checks. So if logging is disabled, the try-except is not even executed, which is great.

If logging is enabled, I assume the logging stream is cached, and so it will result in disk IO only when flushed, which could be relatively rare. Also, if the logging module supports things like flushing on a background thread, using a fixed-size in-memory cache for crash analysis, etc, flushing may never happen on the main thread. So there may still be a perf concern. However, since I am speculating at this point, I will revert to saying that the simpler solution should be tried first (which you have), and worry about perf only when there is specific data.

Thanks,
Shri


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Tuesday, February 17, 2009 10:07 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Logging module

Shri Borde wrote:
> The proposal is to catch the ValueError exception using a try-except in the log function. Raising a ValueError is not going to be good for perf as exception handling on the CLR is relatively slow and meant for really exceptional circumstances. Ideally, the results of the first call will be cached. Normally, I would not worry about perf without concrete data, but users may be calling logging.log quite heavily with the assumption that it is fairly cheap.
>
>   
Given that it probably writes to a stream isn't that going to be much 
more expensive than catching an exception?

Michael

> Thanks,
> Shri
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Tuesday, February 17, 2009 1:51 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Logging module
>
> Dan Eloff wrote:
>   
>> On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
>> <fuzzyman at voidspace.org.uk> wrote:
>>   
>>     
>>> Fair enough then. I'm just putting together a patch and will ask the guys on
>>> Python-Dev if we can get it into Python 2.6. You'll have to help me remember
>>> to pull it out once we have frames again!
>>>
>>>     
>>>       
>> I'd suggest that we don't pull it out. It'd make it an easier decision
>> for the python-devs for one, I can't imagine they'd be enthusiastic to
>> accept a temporary patch. But the main thing being that frame support
>> will likely cause serious performance depredation, which means it's
>> likely to be an optional feature, hence we'd need that check anyway.
>> And then there's always Jython, which, as far as I know, would need
>> the same check.
>>
>> So what kind of condition could we use that works with Jython and
>> IronPython currently, that won't break when IronPython does introduce
>> frames support (regardless of whether or not it has been enabled?)
>>
>> Maybe just wrap it in a try/except?:
>>
>> try:
>>     foo = sys._getframe(1)
>> except (ValueError, AttributeError): # for IronPython, Jython
>>     foo = None
>>
>> Assuming Jython raises an AttributeError, which I do not know to be the case.
>>   
>>     
>
> The actual patch is much simpler:
>
> http://bugs.python.org/issue5287
>
> We just need to set _srcfile to None and it prevents logging from 
> calling _getframe at all.
>
> I've posted the patch and asked the Python-dev guys to consider 
> including it in Python 2.6.
>
> On a side note - anyone know where tlbimp gets installed on Vista64?
>
> Michael
>
>   
>> -Dan
>> _______________________________________________
>> 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  Tue Feb 17 19:21:33 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 18:21:33 +0000
Subject: [IronPython] Logging module
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2E0BFD6144@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <4999E74A.1020505@voidspace.org.uk>	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>	<4999EB06.5010302@voidspace.org.uk>	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4999F054.4040008@voidspace.org.uk>	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>	<499A887D.8080507@voidspace.org.uk>	<710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>	<499AFCB1.4030802@voidspace.org.uk>
	<710DF26F214D2B4BB94287123FFE980A2E0BFD6144@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <499B002D.2080306@voidspace.org.uk>

Shri Borde wrote:
> OK, looking closer, the try-except is in _log which is guarded by "if" checks. So if logging is disabled, the try-except is not even executed, which is great.
>
>   
_srcfile can still be set to None to disable the call altogether if it 
becomes a performance burden.

Michael

> If logging is enabled, I assume the logging stream is cached, and so it will result in disk IO only when flushed, which could be relatively rare. Also, if the logging module supports things like flushing on a background thread, using a fixed-size in-memory cache for crash analysis, etc, flushing may never happen on the main thread. So there may still be a perf concern. However, since I am speculating at this point, I will revert to saying that the simpler solution should be tried first (which you have), and worry about perf only when there is specific data.
>
> Thanks,
> Shri
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Tuesday, February 17, 2009 10:07 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Logging module
>
> Shri Borde wrote:
>   
>> The proposal is to catch the ValueError exception using a try-except in the log function. Raising a ValueError is not going to be good for perf as exception handling on the CLR is relatively slow and meant for really exceptional circumstances. Ideally, the results of the first call will be cached. Normally, I would not worry about perf without concrete data, but users may be calling logging.log quite heavily with the assumption that it is fairly cheap.
>>
>>   
>>     
> Given that it probably writes to a stream isn't that going to be much 
> more expensive than catching an exception?
>
> Michael
>
>   
>> Thanks,
>> Shri
>>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Tuesday, February 17, 2009 1:51 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Logging module
>>
>> Dan Eloff wrote:
>>   
>>     
>>> On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
>>> <fuzzyman at voidspace.org.uk> wrote:
>>>   
>>>     
>>>       
>>>> Fair enough then. I'm just putting together a patch and will ask the guys on
>>>> Python-Dev if we can get it into Python 2.6. You'll have to help me remember
>>>> to pull it out once we have frames again!
>>>>
>>>>     
>>>>       
>>>>         
>>> I'd suggest that we don't pull it out. It'd make it an easier decision
>>> for the python-devs for one, I can't imagine they'd be enthusiastic to
>>> accept a temporary patch. But the main thing being that frame support
>>> will likely cause serious performance depredation, which means it's
>>> likely to be an optional feature, hence we'd need that check anyway.
>>> And then there's always Jython, which, as far as I know, would need
>>> the same check.
>>>
>>> So what kind of condition could we use that works with Jython and
>>> IronPython currently, that won't break when IronPython does introduce
>>> frames support (regardless of whether or not it has been enabled?)
>>>
>>> Maybe just wrap it in a try/except?:
>>>
>>> try:
>>>     foo = sys._getframe(1)
>>> except (ValueError, AttributeError): # for IronPython, Jython
>>>     foo = None
>>>
>>> Assuming Jython raises an AttributeError, which I do not know to be the case.
>>>   
>>>     
>>>       
>> The actual patch is much simpler:
>>
>> http://bugs.python.org/issue5287
>>
>> We just need to set _srcfile to None and it prevents logging from 
>> calling _getframe at all.
>>
>> I've posted the patch and asked the Python-dev guys to consider 
>> including it in Python 2.6.
>>
>> On a side note - anyone know where tlbimp gets installed on Vista64?
>>
>> Michael
>>
>>   
>>     
>>> -Dan
>>> _______________________________________________
>>> 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 dan.eloff at gmail.com  Tue Feb 17 21:08:46 2009
From: dan.eloff at gmail.com (Dan Eloff)
Date: Tue, 17 Feb 2009 15:08:46 -0500
Subject: [IronPython] Logging module
In-Reply-To: <710DF26F214D2B4BB94287123FFE980A2E0BFD6144@NA-EXMSG-C104.redmond.corp.microsoft.com>
References: <4999E74A.1020505@voidspace.org.uk>
	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>
	<4999EB06.5010302@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4999F054.4040008@voidspace.org.uk>
	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>
	<499A887D.8080507@voidspace.org.uk>
	<710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<499AFCB1.4030802@voidspace.org.uk>
	<710DF26F214D2B4BB94287123FFE980A2E0BFD6144@NA-EXMSG-C104.redmond.corp.microsoft.com>
Message-ID: <4817b6fc0902171208x606ef4e2kd126b8ceec506d9b@mail.gmail.com>

On Tue, Feb 17, 2009 at 1:18 PM, Shri Borde <Shri.Borde at microsoft.com> wrote:

>So there may still be a perf concern. However, since I am speculating at this point, I will revert to saying >that the simpler solution should be tried first (which you have), and worry about perf only when there is >specific data.
>

Why not encapsulate the functionality into a simple function call:

def getsrcfile():
    global getsrcfile
    try:
        return sys._getframe(2).yaddayadda
    except ValueError:
        getsrcfile = lambda: None
        return None

Please correct me if I'm wrong, but that should eliminate the perf concern?

(Note: I haven't actually looked at the logging module code)

-Dan


From jdm at marchray.net  Tue Feb 17 21:20:47 2009
From: jdm at marchray.net (Jonathan March)
Date: Tue, 17 Feb 2009 12:20:47 -0800 (PST)
Subject: [IronPython] please document file version numbers
Message-ID: <492635.17743.qm@web81601.mail.mud.yahoo.com>

> file version changes with every patch so you can determine exactly what version you have

I can find no documentation of the relationship between release version numbers (e.g. 2.0.1) and file versions (i.e. 2.0.20209.0). I would suggest that the file version number be listed in the following two locations:
1. The release download page
2. The read-me file for the release.

===

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

... Minor non-breaking releases are in-place upgrades ... But its file version changes with every patch so you can determine exactly what version you have. ... for minor versions not reving the assembly version is also a way of life.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090217/16a71753/attachment.html>

From dinov at microsoft.com  Tue Feb 17 21:28:25 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 17 Feb 2009 12:28:25 -0800
Subject: [IronPython] please document file version numbers
In-Reply-To: <492635.17743.qm@web81601.mail.mud.yahoo.com>
References: <492635.17743.qm@web81601.mail.mud.yahoo.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BBDA6EE@NA-EXMSG-C102.redmond.corp.microsoft.com>

Good suggestion - I've added this information to the release notes page for both 2.0 and 2.0.1.  Updating the read me (in particular in the MSI) is more difficult due to needing to re-sign the MSI.  But we should do that for future dot releases.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan March
Sent: Tuesday, February 17, 2009 12:21 PM
To: users at lists.ironpython.com
Subject: [IronPython] please document file version numbers

> file version changes with every patch so you can determine exactly what version you have

I can find no documentation of the relationship between release version numbers (e.g. 2.0.1) and file versions (i.e. 2.0.20209.0). I would suggest that the file version number be listed in the following two locations:
1. The release download page
2. The read-me file for the release.

===

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1

... Minor non-breaking releases are in-place upgrades ... But its file version changes with every patch so you can determine exactly what version you have. ... for minor versions not reving the assembly version is also a way of life.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090217/0e83ac06/attachment.html>

From fuzzyman at voidspace.org.uk  Tue Feb 17 22:55:52 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 17 Feb 2009 21:55:52 +0000
Subject: [IronPython] Logging module
In-Reply-To: <4817b6fc0902171208x606ef4e2kd126b8ceec506d9b@mail.gmail.com>
References: <4999E74A.1020505@voidspace.org.uk>	<d2155e360902161437l11509ef7qc7d38a3f9e17345@mail.gmail.com>	<4999EB06.5010302@voidspace.org.uk>	<350E7D38B6D819428718949920EC2355571BBDA32D@NA-EXMSG-C102.redmond.corp.microsoft.com>	<4999F054.4040008@voidspace.org.uk>	<4817b6fc0902162044s7be286efw1c783543456899ef@mail.gmail.com>	<499A887D.8080507@voidspace.org.uk>	<710DF26F214D2B4BB94287123FFE980A2E0BFD6129@NA-EXMSG-C104.redmond.corp.microsoft.com>	<499AFCB1.4030802@voidspace.org.uk>	<710DF26F214D2B4BB94287123FFE980A2E0BFD6144@NA-EXMSG-C104.redmond.corp.microsoft.com>
	<4817b6fc0902171208x606ef4e2kd126b8ceec506d9b@mail.gmail.com>
Message-ID: <499B3268.2070709@voidspace.org.uk>

Dan Eloff wrote:
> On Tue, Feb 17, 2009 at 1:18 PM, Shri Borde <Shri.Borde at microsoft.com> wrote:
>
>   
>> So there may still be a perf concern. However, since I am speculating at this point, I will revert to saying >that the simpler solution should be tried first (which you have), and worry about perf only when there is >specific data.
>>
>>     
>
> Why not encapsulate the functionality into a simple function call:
>
> def getsrcfile():
>     global getsrcfile
>     try:
>         return sys._getframe(2).yaddayadda
>     except ValueError:
>         getsrcfile = lambda: None
>         return None
>
> Please correct me if I'm wrong, but that should eliminate the perf concern?
>   

It's not quite structured like that. The patch has been accepted now and 
I think will be fine. If there are any real production issues it can be 
revisited.

Michael

> (Note: I haven't actually looked at the logging module code)
>
> -Dan
> _______________________________________________
> 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 kamil at dworakowski.name  Wed Feb 18 16:48:34 2009
From: kamil at dworakowski.name (Kamil Dworakowski)
Date: Wed, 18 Feb 2009 07:48:34 -0800 (PST)
Subject: [IronPython] seperate output
Message-ID: <5aa01109-8db4-44fc-9128-876a0a7f1557@p13g2000yqc.googlegroups.com>

Resolver One recalculations happen in a runtime, each recalc in a
seperate ScriptScope.

I am tinkering around adding an interactive shell (sth like python
interacitve interpreter) with access to the last recalc scope. This is
a window with two text boxes, one for input and out for output.
Ideally it would display only the output from the issued commands
there, and they shouldn't go to the 'output pane'. I am currently
using code.InteracitveShell inside the same runtime as the recalcs are
happening, and of course the command results go to the 'output pane'.
Any ideas on how to achieve that?


From william at resolversystems.com  Wed Feb 18 18:03:43 2009
From: william at resolversystems.com (William Reade)
Date: Wed, 18 Feb 2009 17:03:43 +0000
Subject: [IronPython] Ironclad v0.8.1 released
Message-ID: <499C3F6F.9070807@resolversystems.com>

Hi all

I'm fairly pleased to announce the release of Ironclad v0.8.1; it's not 
an enormous technical leap above v0.8, but it does now enable you to 
import and use SciPy and Matplotlib with IronPython on Win32 (with some 
restrictions; see project page) . Downloads, and more details, are 
available at http://code.google.com/p/ironclad -- please do play with 
it, and let me know if you have any problems.

Cheers
William


From dinov at microsoft.com  Wed Feb 18 18:12:36 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 18 Feb 2009 09:12:36 -0800
Subject: [IronPython] seperate output
In-Reply-To: <5aa01109-8db4-44fc-9128-876a0a7f1557@p13g2000yqc.googlegroups.com>
References: <5aa01109-8db4-44fc-9128-876a0a7f1557@p13g2000yqc.googlegroups.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BBDAAC1@NA-EXMSG-C102.redmond.corp.microsoft.com>

There was this recent thread which might help:

http://lists.ironpython.com/pipermail/users-ironpython.com/2009-January/009606.html

You could alternately replace sys.displayhook and do a similar thing (we'll flow a CodeContext into there if you define the function in C#, you can get the Scope, and route it to the appropriate window).  The downside of displayhook is it will only printing expression statements - so if the user does print 'hi' then it won't work.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski
Sent: Wednesday, February 18, 2009 7:49 AM
To: users at lists.ironpython.com
Subject: [IronPython] seperate output

Resolver One recalculations happen in a runtime, each recalc in a
seperate ScriptScope.

I am tinkering around adding an interactive shell (sth like python
interacitve interpreter) with access to the last recalc scope. This is
a window with two text boxes, one for input and out for output.
Ideally it would display only the output from the issued commands
there, and they shouldn't go to the 'output pane'. I am currently
using code.InteracitveShell inside the same runtime as the recalcs are
happening, and of course the command results go to the 'output pane'.
Any ideas on how to achieve that?
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From ctrachte at gmail.com  Wed Feb 18 18:59:14 2009
From: ctrachte at gmail.com (Carl Trachte)
Date: Wed, 18 Feb 2009 10:59:14 -0700
Subject: [IronPython] IronPython and SSIS issue - need help...bad
In-Reply-To: <21871242.post@talk.nabble.com>
References: <21853213.post@talk.nabble.com> <21856691.post@talk.nabble.com>
	<559e28300902050945n5074df06oeb3839662bece958@mail.gmail.com>
	<21857504.post@talk.nabble.com>
	<426ada670902051250o3a73c6cej7d0a1737ba282cef@mail.gmail.com>
	<426ada670902051311y1372e314tc91b0a77d383685f@mail.gmail.com>
	<559e28300902052138k3dbaa5ep110c220f01e45d84@mail.gmail.com>
	<21871242.post@talk.nabble.com>
Message-ID: <426ada670902180959v215151c5q6235bf8a9edd8ff2@mail.gmail.com>

On Fri, Feb 6, 2009 at 5:08 AM, Rob Weiss <rweiss at chesapeakebay.net> wrote:
>
> Carl,
> Thanks for the help, looking forward to the update.
>
> Bill,
> I can get the package to run fine using dtsexec and it runs in VS BIS IDE,
> It also runs with a C# app I wrote, so I am not having an issue other than
> trying to get it to run under IP (on either a windows dev box with
> everything installed, or the prod Red Hat Enterprise box) or IP on mono
> (same boxes) using the supplied script. Carl posted a msg stating that he
> was going to dust off the code and review a couple of things and get back to
> us.
>
> Thanks.

Sorry this took so long.  I've updated this recipe in the IronPython
Cookbook for IronPython 2.0 (no testing on Mono).  The main problem
seemed to be the loss of the ability to do Python index and name
lookups (variablename['foo']) on the SSIS collection objects.  The
code now is a little more verbose, but this is hardly a showstopper.

Thanks for the heads up on this.

Carl T.

> --
> View this message in context: http://www.nabble.com/IronPython-and-SSIS-issue---need-help...bad-tp21853213p21871242.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
>


From ecullen at fibertel.com.ar  Thu Feb 19 18:25:57 2009
From: ecullen at fibertel.com.ar (Ernesto Cullen)
Date: Thu, 19 Feb 2009 15:25:57 -0200
Subject: [IronPython] how to use an enum from a hosted script
Message-ID: <499D9625.8040702@fibertel.com.ar>

hi all,  
    I have IronPython hosted inside a c# project, and all goes well... 
until now when i want to use an enum c# type inside a script. For 
instance, I have in C# this declaration:

public enum NotificationTypeEnum {Main,Detail}

Then in a script I want to use this enum in an assignment:

NotifMessage('some message', NotificationTypeEnum.Main)

Where NotifMessage is a delegate expecting a string and a 
NotificationTypeEnum. When I try to run this script, IPy says that it 
does not know NotificationTypeEnum. I tried to add an Import but i get 
'Imports are disabled'.
Any ideas on how to pass this enumeration to a script? I am using IPy 1.1.

TIA

Ernesto Cullen



From dinov at microsoft.com  Thu Feb 19 18:38:07 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 19 Feb 2009 09:38:07 -0800
Subject: [IronPython] how to use an enum from a hosted script
In-Reply-To: <499D9625.8040702@fibertel.com.ar>
References: <499D9625.8040702@fibertel.com.ar>
Message-ID: <350E7D38B6D819428718949920EC2355571BD50CC9@NA-EXMSG-C102.redmond.corp.microsoft.com>

Generally what you'd do is:

import clr
clr.AddReference('yourdll')
from MyNamespace import NotificationTypeEnum

I have no idea where the 'Imports are disabled' exception would come from though.  If you could include the actual text of the exception that might be helpful.  Also running w/ the -X:ExceptionDetail command line and sending back that stack trace might be useful as well.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Ernesto Cullen
> Sent: Thursday, February 19, 2009 9:26 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] how to use an enum from a hosted script
> 
> hi all,
>     I have IronPython hosted inside a c# project, and all goes well...
> until now when i want to use an enum c# type inside a script. For
> instance, I have in C# this declaration:
> 
> public enum NotificationTypeEnum {Main,Detail}
> 
> Then in a script I want to use this enum in an assignment:
> 
> NotifMessage('some message', NotificationTypeEnum.Main)
> 
> Where NotifMessage is a delegate expecting a string and a
> NotificationTypeEnum. When I try to run this script, IPy says that it
> does not know NotificationTypeEnum. I tried to add an Import but i get
> 'Imports are disabled'.
> Any ideas on how to pass this enumeration to a script? I am using IPy
> 1.1.
> 
> TIA
> 
> Ernesto Cullen
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From fuzzyman at voidspace.org.uk  Thu Feb 19 18:54:31 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 19 Feb 2009 17:54:31 +0000
Subject: [IronPython] how to use an enum from a hosted script
In-Reply-To: <350E7D38B6D819428718949920EC2355571BD50CC9@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <499D9625.8040702@fibertel.com.ar>
	<350E7D38B6D819428718949920EC2355571BD50CC9@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <499D9CD7.4040506@voidspace.org.uk>

Dino Viehland wrote:
> Generally what you'd do is:
>
> import clr
> clr.AddReference('yourdll')
> from MyNamespace import NotificationTypeEnum
>
> I have no idea where the 'Imports are disabled' exception would come from though.  If you could include the actual text of the exception that might be helpful.  Also running w/ the -X:ExceptionDetail command line and sending back that stack trace might be useful as well.
>   

With IronPython hosted inside a C# application the -X:ExceptionDetail 
command line switch is likely to not be particularly useful... :-)

Michael



>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Ernesto Cullen
>> Sent: Thursday, February 19, 2009 9:26 AM
>> To: users at lists.ironpython.com
>> Subject: [IronPython] how to use an enum from a hosted script
>>
>> hi all,
>>     I have IronPython hosted inside a c# project, and all goes well...
>> until now when i want to use an enum c# type inside a script. For
>> instance, I have in C# this declaration:
>>
>> public enum NotificationTypeEnum {Main,Detail}
>>
>> Then in a script I want to use this enum in an assignment:
>>
>> NotifMessage('some message', NotificationTypeEnum.Main)
>>
>> Where NotifMessage is a delegate expecting a string and a
>> NotificationTypeEnum. When I try to run this script, IPy says that it
>> does not know NotificationTypeEnum. I tried to add an Import but i get
>> 'Imports are disabled'.
>> Any ideas on how to pass this enumeration to a script? I am using IPy
>> 1.1.
>>
>> TIA
>>
>> Ernesto Cullen
>>
>> _______________________________________________
>> 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  Thu Feb 19 19:06:22 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 19 Feb 2009 10:06:22 -0800
Subject: [IronPython] how to use an enum from a hosted script
In-Reply-To: <499D9CD7.4040506@voidspace.org.uk>
References: <499D9625.8040702@fibertel.com.ar>
	<350E7D38B6D819428718949920EC2355571BD50CC9@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<499D9CD7.4040506@voidspace.org.uk>
Message-ID: <350E7D38B6D819428718949920EC2355571BD50D09@NA-EXMSG-C102.redmond.corp.microsoft.com>

Woops :)  Yes, setting EngineOptions.ExceptionDetail may be more useful (depending on who's catching and printing the exception I guess).

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Thursday, February 19, 2009 9:55 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] how to use an enum from a hosted script
> 
> Dino Viehland wrote:
> > Generally what you'd do is:
> >
> > import clr
> > clr.AddReference('yourdll')
> > from MyNamespace import NotificationTypeEnum
> >
> > I have no idea where the 'Imports are disabled' exception would come
> from though.  If you could include the actual text of the exception
> that might be helpful.  Also running w/ the -X:ExceptionDetail command
> line and sending back that stack trace might be useful as well.
> >
> 
> With IronPython hosted inside a C# application the -X:ExceptionDetail
> command line switch is likely to not be particularly useful... :-)
> 
> Michael
> 
> 
> 
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.ironpython.com [mailto:users-
> >> bounces at lists.ironpython.com] On Behalf Of Ernesto Cullen
> >> Sent: Thursday, February 19, 2009 9:26 AM
> >> To: users at lists.ironpython.com
> >> Subject: [IronPython] how to use an enum from a hosted script
> >>
> >> hi all,
> >>     I have IronPython hosted inside a c# project, and all goes
> well...
> >> until now when i want to use an enum c# type inside a script. For
> >> instance, I have in C# this declaration:
> >>
> >> public enum NotificationTypeEnum {Main,Detail}
> >>
> >> Then in a script I want to use this enum in an assignment:
> >>
> >> NotifMessage('some message', NotificationTypeEnum.Main)
> >>
> >> Where NotifMessage is a delegate expecting a string and a
> >> NotificationTypeEnum. When I try to run this script, IPy says that
> it
> >> does not know NotificationTypeEnum. I tried to add an Import but i
> get
> >> 'Imports are disabled'.
> >> Any ideas on how to pass this enumeration to a script? I am using
> IPy
> >> 1.1.
> >>
> >> TIA
> >>
> >> Ernesto Cullen
> >>
> >> _______________________________________________
> >> 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 fuzzyman at voidspace.org.uk  Thu Feb 19 21:45:02 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 19 Feb 2009 20:45:02 +0000
Subject: [IronPython] Using setuptools to provide platform independence
Message-ID: <499DC4CE.9000201@voidspace.org.uk>

Hello all,

Interesting post on how the shapely library (geometry calculation 
package) aims for platform independence using setuptools to switch the 
calculation backend.

http://sgillies.net/blog/877/plugins-for-shapely

This already works for CPython and head of Jython - "IronPython seems to 
be a little farther behind".

Part of the setuptools infrastructure includes dependency management, so 
getting to run on IronPython has lots of potential benefits.

All the best,


Michael Foord

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




From guidonte at gmail.com  Fri Feb 20 03:29:35 2009
From: guidonte at gmail.com (Guido Amoruso)
Date: Fri, 20 Feb 2009 03:29:35 +0100
Subject: [IronPython] IronPython 2 on Mono
Message-ID: <f2454d4a0902191829ka9ada37rea34db7b3ac82f77@mail.gmail.com>

Hi,

I'm trying to build IronPython from svn trunk on Linux (Ubuntu Hardy,
with Mono 2.0.1) following the instructions at
http://www.nabble.com/IronPython-2.0-RC-2-on-Mono-td20889619.html.
Also tried using the last fepy patches (not only revision 597 as
suggested in the email), but they don't apply cleanly.

Can somebody help? I would be really fond of trying IronPython 2 on Mono!

Thank you in advance,
Guido Amoruso


From slide.o.mix at gmail.com  Fri Feb 20 04:14:43 2009
From: slide.o.mix at gmail.com (Slide)
Date: Thu, 19 Feb 2009 20:14:43 -0700
Subject: [IronPython] IronPython 2 on Mono
In-Reply-To: <f2454d4a0902191829ka9ada37rea34db7b3ac82f77@mail.gmail.com>
References: <f2454d4a0902191829ka9ada37rea34db7b3ac82f77@mail.gmail.com>
Message-ID: <a623f7d10902191914l67ac6a8fk169e782508f98327@mail.gmail.com>

On Thu, Feb 19, 2009 at 7:29 PM, Guido Amoruso <guidonte at gmail.com> wrote:
> Hi,
>
> I'm trying to build IronPython from svn trunk on Linux (Ubuntu Hardy,
> with Mono 2.0.1) following the instructions at
> http://www.nabble.com/IronPython-2.0-RC-2-on-Mono-td20889619.html.
> Also tried using the last fepy patches (not only revision 597 as
> suggested in the email), but they don't apply cleanly.
>
> Can somebody help? I would be really fond of trying IronPython 2 on Mono!
>
> Thank you in advance,
> Guido Amoruso


Can you give some more complete info on what issues you are running
into? Just saying "it doesn't work" doesn't help us pinpoint possible
issues.

Thanks,

slide


From guidonte at gmail.com  Fri Feb 20 04:44:50 2009
From: guidonte at gmail.com (Guido Amoruso)
Date: Fri, 20 Feb 2009 04:44:50 +0100
Subject: [IronPython] IronPython 2 on Mono
In-Reply-To: <a623f7d10902191914l67ac6a8fk169e782508f98327@mail.gmail.com>
References: <f2454d4a0902191829ka9ada37rea34db7b3ac82f77@mail.gmail.com>
	<a623f7d10902191914l67ac6a8fk169e782508f98327@mail.gmail.com>
Message-ID: <f2454d4a0902191944r734b47e6jb51a55b3aa82ce0c@mail.gmail.com>

Applying the patches doesn't work: following the email instructions,
just try applying the first one

patch -p1 < build/patch-exthack

there is one removed files, and the other bits get rejected

Hunk #1 FAILED at 16.
1 out of 1 hunk FAILED -- saving rejects to file
Src/Microsoft.Scripting.Core/Actions/IRestrictedMetaObject.cs.rej
patching file Src/Microsoft.Scripting.Core/Actions/MetaObjectExtensions.cs
Hunk #1 FAILED at 17.
1 out of 1 hunk FAILED -- saving rejects to file
Src/Microsoft.Scripting.Core/Actions/MetaObjectExtensions.cs.rej



On Fri, Feb 20, 2009 at 4:14 AM, Slide <slide.o.mix at gmail.com> wrote:
> On Thu, Feb 19, 2009 at 7:29 PM, Guido Amoruso <guidonte at gmail.com> wrote:
>> Hi,
>>
>> I'm trying to build IronPython from svn trunk on Linux (Ubuntu Hardy,
>> with Mono 2.0.1) following the instructions at
>> http://www.nabble.com/IronPython-2.0-RC-2-on-Mono-td20889619.html.
>> Also tried using the last fepy patches (not only revision 597 as
>> suggested in the email), but they don't apply cleanly.
>>
>> Can somebody help? I would be really fond of trying IronPython 2 on Mono!
>>
>> Thank you in advance,
>> Guido Amoruso
>
>
> Can you give some more complete info on what issues you are running
> into? Just saying "it doesn't work" doesn't help us pinpoint possible
> issues.
>
> Thanks,
>
> slide
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From dblank at brynmawr.edu  Fri Feb 20 15:44:46 2009
From: dblank at brynmawr.edu (Doug Blank)
Date: Fri, 20 Feb 2009 06:44:46 -0800 (PST)
Subject: [IronPython] IronPython 2.0 RC 2 on Mono
In-Reply-To: <5b0248170812072110j6a2694c8v8f221a9575cf1f22@mail.gmail.com>
References: <5b0248170812072110j6a2694c8v8f221a9575cf1f22@mail.gmail.com>
Message-ID: <22120412.post@talk.nabble.com>


Now that IronPython2 is out, wondering about IronPython on Mono...


Seo Sanghyeon-3 wrote:
> 
> Currently you need Mono SVN (both to run and to compile). Using SVN
> r120972 below.
> 

Any idea what version of Mono that is? Does IP2 build with Mono 2.2? It
would be great to put out a IPCE r8 for IP2.

Also, what would be the matching versions of IronRuby that would work with
IP on Mono? I see that DevHawk has a DLR nightly build that comes with Ruby
and Python:

http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr

but the early builds seem to be empty (I've sent Harry a note about that).
The latest versions of those builds don't quite work with Mono 2.0, but
perhaps Mono 2.2?

Thanks for any assistance!

-Doug


Seo Sanghyeon-3 wrote:
> 
> The binary runs fine.
> 
> IronPython includes its own copy of ExtensionAttribute, but this
> doesn't seem to work with Mono C# compiler: that is, extension methods
> don't get recognized as extension methods. This causes trouble where
> MetaObject is defined in Microsoft.Scripting.Core.dll, and its
> extensions are defined in MetaObjectExtensions in
> Microsoft.Scripting.dll. My hack below copies MetaObjectExtensions and
> its dependencies to Microsoft.Scripting.Core and patch it to be a
> partial class instead of a static class housing extension methods. Any
> better idea?
> 
> Also there are some unused files in the source distribution.
> 
> Below are steps I used to compile the source on Mono.
> 
> Download source from
> http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=19841
> $ unzip IronPython-2.0-Src.zip
> $ cd IronPython-2.0
> 
> Some hacks...
> $ svn co -r 597
> https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest
> build
> 
> This deletes unused files and does copying mentioned above
> $ sh build/pre.sh
> 
> Copies NAnt build file: it uses noconfig to avoid pulling System.Core.dll
> $ cp build/IronPython.build Src
> 
> Patches
> $ patch -p1 < build/patch-exthack
> $ patch -p1 < build/patch-console
> 
> Build
> $ cd Src
> $ nant
> 
> -- 
> Seo Sanghyeon
> _______________________________________________
> 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/IronPython-2.0-RC-2-on-Mono-tp20889619p22120412.html
Sent from the IronPython mailing list archive at Nabble.com.



From kamil at dworakowski.name  Fri Feb 20 17:15:37 2009
From: kamil at dworakowski.name (Kamil Dworakowski)
Date: Fri, 20 Feb 2009 08:15:37 -0800 (PST)
Subject: [IronPython] Redirecting stdout/stderr, but with context
In-Reply-To: <350E7D38B6D819428718949920EC23555712BA4B65@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4983B132.7060706@reactorzero.com>
	<350E7D38B6D819428718949920EC23555712BA4B61@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4983BA58.40403@reactorzero.com>
	<350E7D38B6D819428718949920EC23555712BA4B65@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <2f9898af-ad84-49c4-a858-6f253f1e7bf5@x10g2000yqk.googlegroups.com>

This will work for print statements inside the module, but not for
prints coming from arbitrary imported functions. I can't see how to
achive the separation without walking stack on each print.

On Jan 31, 2:45?am, Dino Viehland <di... at microsoft.com> wrote:
> Can you run each document on its own thread?
>
> Oh, it also looks like we actually flow CodeContext through to the caller. ?So you could do something like:
>
> class MyFile {
> ? ? ? ? public void write(CodeContext context, string data) {
> ? ? ? ? ? ? ? ? Scope curScope = context.Scope; ? ? ? ? // this gives you the module you're running in
>
> ? ? ? ? ? ? ? ? // handle write here keyed off of the scope object
> ? ? ? ? }
>
> }
>
> And replace sys.stdout with that.
>
> -----Original Message-----
> From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Jeff Slutter
> Sent: Friday, January 30, 2009 6:41 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Redirecting stdout/stderr, but with context
>
> Dino Viehland wrote:
> > You can always provide your own stream which is aware of what the currentoutputwindow is. ?It could store this in a thread static or just some variable that you update whenever the active window changes. ?You can set that via ScriptRuntime.IO.OutputStream. ?You could conceptually do the exact same thing from Python just by setting sys.stdout to a file-like object which knows what the currentoutputwindow is.
>
> This is what I'm doing right now and that's where I'm having my problem.
> ? ?I don't think this is a solvable problem since theoutputstream is
> shared by all ScriptScopes, just as theoutputstream for
> System.Console.WriteLine is the same across the process.
>
> In a nutshell, I have this:
>
> class Document
> {
> ? void AppendOutput( string text )
> ? {
> ? ? m_buffer.Add(text);
> ? }
> ? List<string> m_buffer;
>
> }
>
> class ConsoleWindow: Form
> {
> ? ?public void WriteOutput( string text, Document doc )
> ? ?{
> ? ? ? doc.AppendOutput( text );
> ? ? ? if( doc == m_currentDisplayingDoc )
> ? ? ? {
> ? ? ? ? ?textBox.Text += text;
> ? ? ? }
> ? ?}
>
> }
>
> class DocWriter
> {
> ? public DocWriter( ConsoleWindow console, Document doc )
> ? {
> ? ? m_console = console;
> ? ? m_document = doc;
> ? }
>
> ? public void write(string text)
> ? {
> ? ? m_console.WriteOutput( text, m_document );
> ? }
> ? ConsoleWindow m_console;
> ? Document m_document;
>
> }
>
> void OnDocumentActivate(Document doc)
> {
> ? DocWriter writer = new DocWrite(guiConsole, doc);
> ? object sysObj = doc.scope.GetVariable("sys");
> ? m_engine.Operations.SetMember(sysObj, "stdout", writer);
> ? m_engine.Operations.SetMember(sysObj, "stderr", writer);
>
> }
>
> The problem is:
> If there is a script running on DocumentA, that is streamingoutput, and
> then I switch to DocumentB while DocumentA continues to run - theoutput
> for DocumentA starts appearing in the console window for DocumentB as if
> it was for B. This is because sysout is system wide and if I change it
> while DocumentA is writing, then it starts outputting to the new stream
> that was set (and that was registered with DocumentB).
>
> -Jeff
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dblank at brynmawr.edu  Fri Feb 20 20:27:45 2009
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Fri, 20 Feb 2009 14:27:45 -0500
Subject: [IronPython] IronPython 2.0 RC 2 on Mono
In-Reply-To: <22120412.post@talk.nabble.com>
References: <5b0248170812072110j6a2694c8v8f221a9575cf1f22@mail.gmail.com>
	<22120412.post@talk.nabble.com>
Message-ID: <499F0431.3000708@brynmawr.edu>

Doug Blank wrote:
> Now that IronPython2 is out, wondering about IronPython on Mono...
> 
> Seo Sanghyeon-3 wrote:
>> Currently you need Mono SVN (both to run and to compile). Using SVN
>> r120972 below.
> 
> Any idea what version of Mono that is? Does IP2 build with Mono 2.2? It
> would be great to put out a IPCE r8 for IP2.
> 
> Also, what would be the matching versions of IronRuby that would work with
> IP on Mono? I see that DevHawk has a DLR nightly build that comes with Ruby
> and Python:
> 
> http://nightlybuilds.cloudapp.net/rss.ashx?project=dlr
> 
> but the early builds seem to be empty (I've sent Harry a note about that).
> The latest versions of those builds don't quite work with Mono 2.0, but
> perhaps Mono 2.2?

Answering part of my own question: Mono 2.2 that comes with OpenSuse is 
not capable of running the IP from the DLR nightly builds, versions 
10209 and later (earlier versions are unavailable there).

So, I'm still in quest of a IP/IR combo that I can run on mono. I will 
try building mono from SVN next...

-Doug

> Thanks for any assistance!
> 
> -Doug
> 
> 
> Seo Sanghyeon-3 wrote:
>> The binary runs fine.
>>
>> IronPython includes its own copy of ExtensionAttribute, but this
>> doesn't seem to work with Mono C# compiler: that is, extension methods
>> don't get recognized as extension methods. This causes trouble where
>> MetaObject is defined in Microsoft.Scripting.Core.dll, and its
>> extensions are defined in MetaObjectExtensions in
>> Microsoft.Scripting.dll. My hack below copies MetaObjectExtensions and
>> its dependencies to Microsoft.Scripting.Core and patch it to be a
>> partial class instead of a static class housing extension methods. Any
>> better idea?
>>
>> Also there are some unused files in the source distribution.
>>
>> Below are steps I used to compile the source on Mono.
>>
>> Download source from
>> http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=19841
>> $ unzip IronPython-2.0-Src.zip
>> $ cd IronPython-2.0
>>
>> Some hacks...
>> $ svn co -r 597
>> https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/latest
>> build
>>
>> This deletes unused files and does copying mentioned above
>> $ sh build/pre.sh
>>
>> Copies NAnt build file: it uses noconfig to avoid pulling System.Core.dll
>> $ cp build/IronPython.build Src
>>
>> Patches
>> $ patch -p1 < build/patch-exthack
>> $ patch -p1 < build/patch-console
>>
>> Build
>> $ cd Src
>> $ nant
>>
>> -- 
>> Seo Sanghyeon
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
> 


-- 
Douglas S. Blank
Director, Institute for Personal Robots in Education (IPRE)
http://www.roboteducation.org
Chair, and Associate Professor, Computer Science, Bryn Mawr College
http://cs.brynmawr.edu/~dblank  (610)526-6501


From ecullen at fibertel.com.ar  Fri Feb 20 22:10:59 2009
From: ecullen at fibertel.com.ar (Ernesto Cullen)
Date: Fri, 20 Feb 2009 19:10:59 -0200
Subject: [IronPython] how to use an enum from a hosted script
In-Reply-To: <350E7D38B6D819428718949920EC2355571BD50D09@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <499D9625.8040702@fibertel.com.ar>
	<350E7D38B6D819428718949920EC2355571BD50CC9@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<499D9CD7.4040506@voidspace.org.uk>
	<350E7D38B6D819428718949920EC2355571BD50D09@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <499F1C63.70900@fibertel.com.ar>

Thanks all, I have found the culprit: we use a home-modified version of 
IPy and one of the modifications was... to disable all import from 
scripts for security reasons. I have tried with the original version and 
it worked like a charm.
I will have to think in some workaround for the time being while we 
study how to restrict the import just to some known assemblies :-)

Again, thank you all for the prompt response!

Ernesto Cullen



From dblank at brynmawr.edu  Sat Feb 21 14:32:11 2009
From: dblank at brynmawr.edu (Doug Blank)
Date: Sat, 21 Feb 2009 05:32:11 -0800 (PST)
Subject: [IronPython]  IronPython-2.0.1-Bin.zip contains 2.0.0?
Message-ID: <22136075.post@talk.nabble.com>


Unless my system is not unzipping the right files, it looks like
IronPython-2.0.1-Bin.zip on page:

http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

actually has the 2.0.0 binaries:

$ cd IronPython-2.0.1
$ ipy.exe -X:ColorfulConsole
IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>>

Does anyone else see this?

-Doug
-- 
View this message in context: http://www.nabble.com/IronPython-2.0.1-Bin.zip-contains-2.0.0--tp22136075p22136075.html
Sent from the IronPython mailing list archive at Nabble.com.



From dfugate at microsoft.com  Sat Feb 21 19:07:14 2009
From: dfugate at microsoft.com (Dave Fugate)
Date: Sat, 21 Feb 2009 10:07:14 -0800
Subject: [IronPython] IronPython-2.0.1-Bin.zip contains 2.0.0?
In-Reply-To: <22136075.post@talk.nabble.com>
References: <22136075.post@talk.nabble.com>
Message-ID: <EECFB552375FDE49A23A13CE85EEC2FD1EA36BFD2C@NA-EXMSG-C112.redmond.corp.microsoft.com>

Thanking for reporting this.  These are indeed IP 2.0.1 binaries in IronPython-2.0.1-Bin.zip.  sys.version was kept the same between IP 2.0.0 and IP 2.0.1 similarly to what was done for the assembly versions.  If this is causing any specific issues or is too confusing, please let us know and we can revisit this for the next version of IronPython.

________________________________________
From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Doug Blank [dblank at brynmawr.edu]
Sent: Saturday, February 21, 2009 5:32 AM
To: users at lists.ironpython.com
Subject: [IronPython]  IronPython-2.0.1-Bin.zip contains 2.0.0?

Unless my system is not unzipping the right files, it looks like
IronPython-2.0.1-Bin.zip on page:

http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

actually has the 2.0.0 binaries:

$ cd IronPython-2.0.1
$ ipy.exe -X:ColorfulConsole
IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>>

Does anyone else see this?

-Doug
--
View this message in context: http://www.nabble.com/IronPython-2.0.1-Bin.zip-contains-2.0.0--tp22136075p22136075.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

From jdm at marchray.net  Sat Feb 21 20:40:27 2009
From: jdm at marchray.net (Jonathan March)
Date: Sat, 21 Feb 2009 11:40:27 -0800 (PST)
Subject: [IronPython] IronPython-2.0.1-Bin.zip contains 2.0.0?
References: <22136075.post@talk.nabble.com>
Message-ID: <593220.12556.qm@web81608.mail.mud.yahoo.com>

This release does not update the assembly version numbers. See comments here:
http://ironpython-urls.blogspot.com/2009/02/ironpython-201-released.html



________________________________
From: Doug Blank <dblank at brynmawr.edu>
To: users at lists.ironpython.com
Sent: Saturday, February 21, 2009 8:32:11 AM
Subject: [IronPython] IronPython-2.0.1-Bin.zip contains 2.0.0?


Unless my system is not unzipping the right files, it looks like
IronPython-2.0.1-Bin.zip on page:

http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=12481

actually has the 2.0.0 binaries:

$ cd IronPython-2.0.1
$ ipy.exe -X:ColorfulConsole
IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>>

Does anyone else see this?

-Doug
-- 
View this message in context: http://www.nabble.com/IronPython-2.0.1-Bin.zip-contains-2.0.0--tp22136075p22136075.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/20090221/9bd4b0b5/attachment.html>

From antonio.piteira at wtvision.com  Sun Feb 22 19:16:32 2009
From: antonio.piteira at wtvision.com (Antonio Piteira)
Date: Sun, 22 Feb 2009 18:16:32 +0000
Subject: [IronPython] Ironpython delegates...
Message-ID: <4057092c0902221016u73ce649bv7cb90164db0a6e10@mail.gmail.com>

I've been searching for CallTarget0 and from what I read it should be in
Microsoft.Scripting.dll, but when I add the reference to clr and
import CallTarget0
 from Microsoft.Scripting.dll I get this message:
---------------------------
Error...
---------------------------
Cannot import name CallTarget0
---------------------------
OK
---------------------------

Any ideas?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090222/4678038e/attachment.html>

From antonio.piteira at wtvision.com  Sun Feb 22 19:26:28 2009
From: antonio.piteira at wtvision.com (Antonio Piteira)
Date: Sun, 22 Feb 2009 18:26:28 +0000
Subject: [IronPython] Fwd: Ironpython delegates...
In-Reply-To: <4057092c0902221016u73ce649bv7cb90164db0a6e10@mail.gmail.com>
References: <4057092c0902221016u73ce649bv7cb90164db0a6e10@mail.gmail.com>
Message-ID: <4057092c0902221026m24588790r1c8abd9bcabb7101@mail.gmail.com>

Found the solution...

clr.AddReference("Ironpython")
from IronPython.Compiler import CallTarget0

I was looking in the wrong place.

--------------------------------------------------------------------------------------------------------------------------


I've been searching for CallTarget0 and from what I read it should be in
Microsoft.Scripting.dll, but when I add the reference to clr and
import CallTarget0
 from Microsoft.Scripting.dll I get this message:
---------------------------
Error...
---------------------------
Cannot import name CallTarget0
---------------------------
OK
---------------------------

Any ideas?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090222/84c3d57f/attachment.html>

From dinov at microsoft.com  Sun Feb 22 20:00:34 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Sun, 22 Feb 2009 11:00:34 -0800
Subject: [IronPython] Fwd: Ironpython delegates...
In-Reply-To: <4057092c0902221026m24588790r1c8abd9bcabb7101@mail.gmail.com>
References: <4057092c0902221016u73ce649bv7cb90164db0a6e10@mail.gmail.com>
	<4057092c0902221026m24588790r1c8abd9bcabb7101@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BD514B1@NA-EXMSG-C102.redmond.corp.microsoft.com>

Depending on what you're doing you might be better off using Func<object> instead of CallTarget0.  CallTarget0 is more of a Python implementation detail and could change w/ major IronPython versions - or even be replaced w/ Func<object>.  it's primary purpose is to be the delegate for calling a zero-arg Python function so it could change due to changes in how we implement functions.  Func<object> will always exist and do exactly what it says.  Of course if you are actually doing something w/ calling classes or functions then it's the right thing to use.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Antonio Piteira
Sent: Sunday, February 22, 2009 10:26 AM
To: users at lists.ironpython.com
Subject: [IronPython] Fwd: Ironpython delegates...

Found the solution...

clr.AddReference("Ironpython")
from IronPython.Compiler import CallTarget0

I was looking in the wrong place.

--------------------------------------------------------------------------------------------------------------------------


I've been searching for CallTarget0 and from what I read it should be in Microsoft.Scripting.dll, but when I add the reference to clr and import CallTarget0  from Microsoft.Scripting.dll I get this message:

---------------------------
Error...
---------------------------
Cannot import name CallTarget0
---------------------------
OK
---------------------------

Any ideas?

Thank you.

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

From empirebuilder at gmail.com  Sun Feb 22 23:09:31 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Mon, 23 Feb 2009 00:09:31 +0200
Subject: [IronPython] Please vote up this DLR memory leak bug
Message-ID: <8cd017b80902221409p564cf1b0j31018982f3e51f1a@mail.gmail.com>

There's only 5 votes so far.

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399


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

From jeanmarc.pouchoulon at gmail.com  Tue Feb 24 00:35:05 2009
From: jeanmarc.pouchoulon at gmail.com (jean-marc pouchoulon)
Date: Tue, 24 Feb 2009 00:35:05 +0100
Subject: [IronPython] searching ssh client library working with ironpython
Message-ID: <49A332A9.5080406@gmail.com>

Hi,

I want  to do ssh (client side )  with ironpython.
Nothing really simple  found on the web to do that or I miss it.
I try to use paramiko with ironclad but ...

 >>> import ironclad
 >>> import paramiko
Traceback (most recent call last):
  File "", line unknown, in <module>
  File "Snippets.scripting", line unknown, in Initialize
  File "Snippets.scripting", line unknown, in Initialize
  File "Snippets.scripting", line unknown, in Initialize
  File "Snippets.scripting", line unknown, in Initialize
  File "Snippets.scripting", line unknown, in Initialize
  File "C:\Users\..\ironclad-v0.8.1-bin\build\paramiko\rng_posix.py", 
line 54, in open_rng_device
paramiko.rng_posix.error: Unable to open /dev/urandom

( mmm I'm on vista why /dev/urandom  ?)
Crypto problem ?

 >>> import Crypto # Ok
 >>> from Crypto import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "mscorlib", line unknown, in get_Item
  File "mscorlib", line unknown, in ThrowKeyNotFoundException
KeyError: La cl? donn?e ?tait absente du dictionnaire.
 >>>


thanks for your help

jean-marc






From christian.muirhead at resolversystems.com  Tue Feb 24 16:50:56 2009
From: christian.muirhead at resolversystems.com (Christian Muirhead)
Date: Tue, 24 Feb 2009 15:50:56 +0000
Subject: [IronPython] bug: Modules with no docstring have wrong __doc__
Message-ID: <49A41760.2060305@resolversystems.com>

Hi guys -

Just found a minor bug in IP 2.0.1 - we're working around it in our 
documentation generation tool.

If you create an empty module, import it and print __doc__, you get:

module()
module(dict dictionary)
module(module parent, dict dictionary)
module(module parent, dict dictionary, bool isVisible)

In IP 1 and CPython, it was None.
I've filed this on codeplex:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21360

Cheers,
Christian


From dinov at microsoft.com  Tue Feb 24 18:40:55 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 24 Feb 2009 09:40:55 -0800
Subject: [IronPython] bug: Modules with no docstring have wrong __doc__
In-Reply-To: <49A41760.2060305@resolversystems.com>
References: <49A41760.2060305@resolversystems.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BE89B9E@NA-EXMSG-C102.redmond.corp.microsoft.com>

Thanks for reporting this - it looks like we just need to set the __doc__ in the dict to None.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Christian Muirhead
> Sent: Tuesday, February 24, 2009 7:51 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] bug: Modules with no docstring have wrong __doc__
> 
> Hi guys -
> 
> Just found a minor bug in IP 2.0.1 - we're working around it in our
> documentation generation tool.
> 
> If you create an empty module, import it and print __doc__, you get:
> 
> module()
> module(dict dictionary)
> module(module parent, dict dictionary)
> module(module parent, dict dictionary, bool isVisible)
> 
> In IP 1 and CPython, it was None.
> I've filed this on codeplex:
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=21360
> 
> Cheers,
> Christian
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Tue Feb 24 18:45:16 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 24 Feb 2009 09:45:16 -0800
Subject: [IronPython] searching ssh client library working with
 ironpython
In-Reply-To: <49A332A9.5080406@gmail.com>
References: <49A332A9.5080406@gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BE89BAB@NA-EXMSG-C102.redmond.corp.microsoft.com>

Can you run w/ the -X:ExceptionDetail command line option the for the import Crypt / from Crypto import * and report back the stack trace you get?

I'm not sure that I'll be of much use but if it's somewhere in IronPython instead of IronClad it might be an IronPython bug.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of jean-marc pouchoulon
> Sent: Monday, February 23, 2009 3:35 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] searching ssh client library working with
> ironpython
> 
> Hi,
> 
> I want  to do ssh (client side )  with ironpython.
> Nothing really simple  found on the web to do that or I miss it.
> I try to use paramiko with ironclad but ...
> 
>  >>> import ironclad
>  >>> import paramiko
> Traceback (most recent call last):
>   File "", line unknown, in <module>
>   File "Snippets.scripting", line unknown, in Initialize
>   File "Snippets.scripting", line unknown, in Initialize
>   File "Snippets.scripting", line unknown, in Initialize
>   File "Snippets.scripting", line unknown, in Initialize
>   File "Snippets.scripting", line unknown, in Initialize
>   File "C:\Users\..\ironclad-v0.8.1-bin\build\paramiko\rng_posix.py",
> line 54, in open_rng_device
> paramiko.rng_posix.error: Unable to open /dev/urandom
> 
> ( mmm I'm on vista why /dev/urandom  ?)
> Crypto problem ?
> 
>  >>> import Crypto # Ok
>  >>> from Crypto import *
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "mscorlib", line unknown, in get_Item
>   File "mscorlib", line unknown, in ThrowKeyNotFoundException
> KeyError: La cl? donn?e ?tait absente du dictionnaire.
>  >>>
> 
> 
> thanks for your help
> 
> jean-marc
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at microsoft.com  Tue Feb 24 18:59:48 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 24 Feb 2009 09:59:48 -0800
Subject: [IronPython] Please vote up this DLR memory leak bug
In-Reply-To: <8cd017b80902221409p564cf1b0j31018982f3e51f1a@mail.gmail.com>
References: <8cd017b80902221409p564cf1b0j31018982f3e51f1a@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BE89BBD@NA-EXMSG-C102.redmond.corp.microsoft.com>

Just some comments on this as there's a few issues intertwined here:

1.       Optimized code - this is currently the default and part of the original problem.  If you execute code in "optimized" mode we generate an uncollectible type.  In 2.6 I'm switching the default to be non-optimized and I also am trying out a change that should reduce the amount of leakage when we do this.  That will make the out of the box experience much better.

2.       Multiple script runtimes - there's a bug in the DLR when you repeatedly create script runtimes that the rules aren't getting collected. This is supposed to be fixed in 2.6 but I'm still seeing some leaks in this scenario that I'll look into and fix.  Back-porting this to 2.0 would be quite difficult as a lot of things have changed but we could certainly look at backporting a different fix to 2.0.

3.       There's a repro that defines "TestScriptOldClass" + n which leaks.  All class / function / member names in code get interned and this is where this leak is coming from.  If you remove the + n then everything works.  We may get rid of this interning at some point in the future but it's a fairly significant change.  I'm inclined to believe this one isn't as much of an issue as usually you aren't compiling code with new names every single type.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Sunday, February 22, 2009 2:10 PM
To: Discussion of IronPython
Subject: [IronPython] Please vote up this DLR memory leak bug

There's only 5 votes so far.

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399



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

From jeanmarc.pouchoulon at gmail.com  Tue Feb 24 23:26:29 2009
From: jeanmarc.pouchoulon at gmail.com (jean-marc pouchoulon)
Date: Tue, 24 Feb 2009 23:26:29 +0100
Subject: [IronPython] searching ssh client library working with
	ironpython
In-Reply-To: <350E7D38B6D819428718949920EC2355571BE89BAB@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <49A332A9.5080406@gmail.com>
	<350E7D38B6D819428718949920EC2355571BE89BAB@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <49A47415.2030106@gmail.com>

Dino Viehland a ?crit :
> Can you run w/ the -X:ExceptionDetail command line option the for the import Crypt / from Crypto import * and report back the stack trace you get?
>   
here it is

C:\Users\....\SDK\ironclad-v0.8.1-bin\build>"C:\Program Files\IronPython 
2.0\ipy.exe" -X:ExceptionDetail
IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074
Type "help", "copyright", "credits" or "license" for more information.
 >>> import ironclad
 >>> import Crypto
 >>> from Crypto import *
La cl? donn?e ?tait absente du dictionnaire.
   ? System.ThrowHelper.ThrowKeyNotFoundException()
   ? System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   ? 
Microsoft.Scripting.Runtime.CustomSymbolDictionary.Microsoft.Scripting.IAttributesCollection.get_Item(SymbolId 
name)
   ? IronPython.Runtime.Operations.PythonOps.ImportStar(CodeContext 
context, String fullName, Int32 level)
   ? <module>$731##550(Closure , Scope , LanguageContext )
   ? 
Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression 
code, Scope scope)
   ? Microsoft.Scripting.ScriptCode.Run(Scope scope)
   ? 
IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.<RunOneInteraction>b__0()
KeyError: La cl? donn?e ?tait absente du dictionnaire.
 >>>

jmp

> I'm not sure that I'll be of much use but if it's somewhere in IronPython instead of IronClad it might be an IronPython bug.
>
>   





From christian.muirhead at resolversystems.com  Wed Feb 25 17:23:43 2009
From: christian.muirhead at resolversystems.com (Christian Muirhead)
Date: Wed, 25 Feb 2009 16:23:43 +0000
Subject: [IronPython] searching ssh client library working
	with	ironpython
In-Reply-To: <49A47415.2030106@gmail.com>
References: <49A332A9.5080406@gmail.com>	<350E7D38B6D819428718949920EC2355571BE89BAB@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49A47415.2030106@gmail.com>
Message-ID: <49A5708F.4000207@resolversystems.com>

Hi jean-marc -

This looks like an Ironclad bug - we're looking into it now. It might be 
something simple to fix, or quite complicated; Ironclad's still a work 
in progress, and there are lots of parts of the Python C API that aren't 
implemented yet. I'll let you know when we've got a better idea of 
what's going on.

Cheers,
Christian



jean-marc pouchoulon wrote:
> Dino Viehland a ?crit :
>> Can you run w/ the -X:ExceptionDetail command line option the for the 
>> import Crypt / from Crypto import * and report back the stack trace 
>> you get?
>>   
> here it is
> 
> C:\Users\....\SDK\ironclad-v0.8.1-bin\build>"C:\Program Files\IronPython 
> 2.0\ipy.exe" -X:ExceptionDetail
> IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.3074
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import ironclad
>  >>> import Crypto
>  >>> from Crypto import *
> La cl? donn?e ?tait absente du dictionnaire.
>   ? System.ThrowHelper.ThrowKeyNotFoundException()
>   ? System.Collections.Generic.Dictionary`2.get_Item(TKey key)
>   ? 
> Microsoft.Scripting.Runtime.CustomSymbolDictionary.Microsoft.Scripting.IAttributesCollection.get_Item(SymbolId 
> name)
>   ? IronPython.Runtime.Operations.PythonOps.ImportStar(CodeContext 
> context, String fullName, Int32 level)
>   ? <module>$731##550(Closure , Scope , LanguageContext )
>   ? 
> Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression 
> code, Scope scope)
>   ? Microsoft.Scripting.ScriptCode.Run(Scope scope)
>   ? 
> IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.<RunOneInteraction>b__0() 
> 
> KeyError: La cl? donn?e ?tait absente du dictionnaire.
>  >>>
> 
> jmp
> 
>> I'm not sure that I'll be of much use but if it's somewhere in 
>> IronPython instead of IronClad it might be an IronPython bug.
>>
>>   
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From empirebuilder at gmail.com  Wed Feb 25 17:38:06 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Wed, 25 Feb 2009 18:38:06 +0200
Subject: [IronPython] Please vote up this DLR memory leak bug
In-Reply-To: <350E7D38B6D819428718949920EC2355571BE89BBD@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8cd017b80902221409p564cf1b0j31018982f3e51f1a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571BE89BBD@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8cd017b80902250838s7349e6bct830546fc3b34fce5@mail.gmail.com>

What is the impact of caching CompiledCode into this "collectability" issue?

I am working on a CMS that expose functions implemented in IronPython
to a template engine. So I read a directory of 40 or 50 xx.py files,
load it up and compiled them. This is off course a costly operation to
do it in every single HTTP request (and SLOW) so I compiled the source
code to CompiledCode and cache them.

Then for every HTTP request, I retrieve these CompiledCode's from the
Cache and call Execute(scope) to make the frozen code to be a real
function. So with X HTTP request, there will be X scope and  (X * 40)
functions being generated at runtime.

Now our memory consumption is huge and is getting bigger until IIS
gave up and recycle the process.

Dody G.




> Just some comments on this as there?s a few issues intertwined here:
>
> 1.?????? Optimized code ? this is currently the default and part of the
> original problem.? If you execute code in ?optimized? mode we generate an
> uncollectible type.? In 2.6 I?m switching the default to be non-optimized
> and I also am trying out a change that should reduce the amount of leakage
> when we do this.? That will make the out of the box experience much better.
>


> 2.?????? Multiple script runtimes ? there?s a bug in the DLR when you
> repeatedly create script runtimes that the rules aren?t getting collected.
> This is supposed to be fixed in 2.6 but I?m still seeing some leaks in this
> scenario that I?ll look into and fix.? Back-porting this to 2.0 would be
> quite difficult as a lot of things have changed but we could certainly look
> at backporting a different fix to 2.0.
>

> 3.?????? There?s a repro that defines ?TestScriptOldClass? + n which leaks.
> All class / function / member names in code get interned and this is where
> this leak is coming from.? If you remove the + n then everything works.? We
> may get rid of this interning at some point in the future but it?s a fairly
> significant change.? I?m inclined to believe this one isn?t as much of an
> issue as usually you aren?t compiling code with new names every single
> type.
>




>
>
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
> Sent: Sunday, February 22, 2009 2:10 PM
> To: Discussion of IronPython
> Subject: [IronPython] Please vote up this DLR memory leak bug
>
>
>
> There's only 5 votes so far.
>
>
>
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399
>
>
>
> --
> nomadlife.org



-- 
nomadlife.org


From jeanmarc.pouchoulon at gmail.com  Wed Feb 25 19:55:34 2009
From: jeanmarc.pouchoulon at gmail.com (jean-marc pouchoulon)
Date: Wed, 25 Feb 2009 19:55:34 +0100
Subject: [IronPython] searching ssh client library working
	with	ironpython
In-Reply-To: <49A5708F.4000207@resolversystems.com>
References: <49A332A9.5080406@gmail.com>	<350E7D38B6D819428718949920EC2355571BE89BAB@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<49A47415.2030106@gmail.com> <49A5708F.4000207@resolversystems.com>
Message-ID: <49A59426.1090105@gmail.com>

Christian Muirhead a ?crit :
> Hi jean-marc -
>   
Hi christian,
>  I'll let you know when we've got a better idea of 
> what's going on.
>   
Ok thanks a lot for all your answers.
jean-marc

>
>   
>
>   




From dinov at microsoft.com  Wed Feb 25 21:51:52 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 25 Feb 2009 12:51:52 -0800
Subject: [IronPython] Please vote up this DLR memory leak bug
In-Reply-To: <8cd017b80902250838s7349e6bct830546fc3b34fce5@mail.gmail.com>
References: <8cd017b80902221409p564cf1b0j31018982f3e51f1a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571BE89BBD@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8cd017b80902250838s7349e6bct830546fc3b34fce5@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BE8A18E@NA-EXMSG-C102.redmond.corp.microsoft.com>

Your approach should be perfectly fine (it's basically what CompiledCode was designed for) and it's not clear to me what would be leaking in this scenario.  

One suggestion I'd have for you is to download and install windbg (http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx).  

Then attach to your process which is using all the memory and type in:

.loadby sos mscorwks
!DumpHeap -stat

And send back the about the last 25 lines of that output.  That'll give us the most common objects which are using memory in the GC heap and we might be able to track it down from there.  If that's not sufficient maybe we can iterate and figure out what's going on.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
> Sent: Wednesday, February 25, 2009 8:38 AM
> To: Dino Viehland
> Cc: Discussion of IronPython
> Subject: Re: [IronPython] Please vote up this DLR memory leak bug
> 
> What is the impact of caching CompiledCode into this "collectability"
> issue?
> 
> I am working on a CMS that expose functions implemented in IronPython
> to a template engine. So I read a directory of 40 or 50 xx.py files,
> load it up and compiled them. This is off course a costly operation to
> do it in every single HTTP request (and SLOW) so I compiled the source
> code to CompiledCode and cache them.
> 
> Then for every HTTP request, I retrieve these CompiledCode's from the
> Cache and call Execute(scope) to make the frozen code to be a real
> function. So with X HTTP request, there will be X scope and  (X * 40)
> functions being generated at runtime.
> 
> Now our memory consumption is huge and is getting bigger until IIS
> gave up and recycle the process.
> 
> Dody G.
> 
> 
> 
> 
> > Just some comments on this as there's a few issues intertwined here:
> >
> > 1.?????? Optimized code - this is currently the default and part of
> the
> > original problem.? If you execute code in "optimized" mode we
> generate an
> > uncollectible type.? In 2.6 I'm switching the default to be non-
> optimized
> > and I also am trying out a change that should reduce the amount of
> leakage
> > when we do this.? That will make the out of the box experience much
> better.
> >
> 
> 
> > 2.?????? Multiple script runtimes - there's a bug in the DLR when you
> > repeatedly create script runtimes that the rules aren't getting
> collected.
> > This is supposed to be fixed in 2.6 but I'm still seeing some leaks
> in this
> > scenario that I'll look into and fix.? Back-porting this to 2.0 would
> be
> > quite difficult as a lot of things have changed but we could
> certainly look
> > at backporting a different fix to 2.0.
> >
> 
> > 3.?????? There's a repro that defines "TestScriptOldClass" + n which
> leaks.
> > All class / function / member names in code get interned and this is
> where
> > this leak is coming from.? If you remove the + n then everything
> works.? We
> > may get rid of this interning at some point in the future but it's a
> fairly
> > significant change.? I'm inclined to believe this one isn't as much
> of an
> > issue as usually you aren't compiling code with new names every
> single
> > type.
> >
> 
> 
> 
> 
> >
> >
> > From: users-bounces at lists.ironpython.com
> > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody
> Gunawinata
> > Sent: Sunday, February 22, 2009 2:10 PM
> > To: Discussion of IronPython
> > Subject: [IronPython] Please vote up this DLR memory leak bug
> >
> >
> >
> > There's only 5 votes so far.
> >
> >
> >
> >
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399
> >
> >
> >
> > --
> > nomadlife.org
> 
> 
> 
> --
> nomadlife.org
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From mksql at yahoo.com  Thu Feb 26 00:05:43 2009
From: mksql at yahoo.com (Matt)
Date: Wed, 25 Feb 2009 15:05:43 -0800 (PST)
Subject: [IronPython] Associate .ipy extension as IronPython in VS 2008?
Message-ID: <964261.15327.qm@web110803.mail.gq1.yahoo.com>

Having installed the ASP.NET Futures package, I get syntax highlighting for files with the .py extension in Visual Studio 2008. I am unable to find a setting to associate files with a .ipy extension as the same.

I use both the CPython and IronPython interpreters, and would like to use the file extensions to keep the scripts separate. Is there a VS config setting or a registry key to set the file type in VS?

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

From Jimmy.Schementi at microsoft.com  Thu Feb 26 01:40:03 2009
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Wed, 25 Feb 2009 16:40:03 -0800
Subject: [IronPython] Associate .ipy extension as IronPython in VS 2008?
In-Reply-To: <964261.15327.qm@web110803.mail.gq1.yahoo.com>
References: <964261.15327.qm@web110803.mail.gq1.yahoo.com>
Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A3284BEB541B99@NA-EXMSG-C116.redmond.corp.microsoft.com>

Can't you just tell the OS to associate .ipy files with devenv.exe? (Right-click on file --> Open with ... --> browse to devenv.exe). I don't think VS keeps track of file types associated with it, but the setup sets them.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matt
Sent: Wednesday, February 25, 2009 3:06 PM
To: users at lists.ironpython.com
Subject: [IronPython] Associate .ipy extension as IronPython in VS 2008?

Having installed the ASP.NET Futures package, I get syntax highlighting for files with the .py extension in Visual Studio 2008. I am unable to find a setting to associate files with a .ipy extension as the same.

I use both the CPython and IronPython interpreters, and would like to use the file extensions to keep the scripts separate. Is there a VS config setting or a registry key to set the file type in VS?


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

From empirebuilder at gmail.com  Thu Feb 26 09:07:03 2009
From: empirebuilder at gmail.com (Dody Gunawinata)
Date: Thu, 26 Feb 2009 10:07:03 +0200
Subject: [IronPython] Please vote up this DLR memory leak bug
In-Reply-To: <350E7D38B6D819428718949920EC2355571BE8A18E@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <8cd017b80902221409p564cf1b0j31018982f3e51f1a@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571BE89BBD@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<8cd017b80902250838s7349e6bct830546fc3b34fce5@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571BE8A18E@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <8cd017b80902260007w7a719b52m2db893bd6a4d7d0b@mail.gmail.com>

Microsoft.Scripting2.Core is a namespace copy of the IP source code -
based on IP 2.0 Beta 3 - just before one version that introduced
incompatibility with .Net 3.5

We are using ASP.Net with IronPython support based on July CTP 2007
(which I think ran on IP 2.0 Alpha X). The latest drop of IP for
ASP.Net was based on IP 2.0 Beta 4 which contained the .Net 3.5
incompatibility which makes in unusable for our application.

So my application has 2 copies of IP - one that runs the asp.net
dynamic support and the other that runs the scripting support (with 2
suffix in the namespace). It's a stupid situation but we rely a IP for
ASP.Net and that piece of technology has not been brought up to date
to a working state for .Net 3.5 framework- and our web productions
people rely on the software so it's full speed ahead regardless of the
technology limitation.

This memory leak might be gone if we have an up to date IP for ASP.Net
but one never know so here's the last 25 lines of the heap dump. I
hope this is useful.



79104368     3939        94536 System.Collections.ArrayList
7911f030     1708        95648 System.Reflection.Emit.DynamicMethod
7911f400     2999        95968 System.Reflection.Emit.SignatureHelper
109cbc9c     2516       100640 System.Linq.Expressions2.ConditionalExpression
1085c930     3181       101792 System.Scripting.SourceSpan
109c4594     3244       103808 System.Linq.Expressions2.ParameterExpression
10f63bcc     1237       110188
System.Collections.Generic.Dictionary`2+Entry[[System.Linq.Expressions2.Expression,
Microsoft.Scripting2.Core],[System.Linq.Expressions2.CompilerScope+Storage,
Microsoft.Scripting2.Core]][]
79135014        3       114968
System.Collections.Generic.Dictionary`2+Entry[[System.Int32,
mscorlib],[System.String, mscorlib]][]
10f60a2c     2260       117520
System.Collections.Generic.Dictionary`2[[System.Linq.Expressions2.Expression,
Microsoft.Scripting2.Core],[System.Object, mscorlib]]
109cfb1c     2736       120384 System.Linq.Expressions2.BinaryExpression
10f6145c     1743       125700
System.Collections.Generic.Dictionary`2+Entry[[System.Linq.Expressions2.Expression,
Microsoft.Scripting2.Core],[System.Object, mscorlib]][]
109c4e4c     3164       126560 System.Linq.Expressions2.ScopeExpression
109c4274     4142       132544 System.Linq.Expressions2.VariableExpression
109caf7c     3735       134460 System.Linq.Expressions2.UnaryExpression
10f5cd24     3762       135432
System.Linq.Expressions2.StackSpiller+ChildRewriter
106fa09c       40       138784
System.Collections.Generic.Dictionary`2+Entry[[Microsoft.Scripting.SymbolId,
Microsoft.Scripting],[Microsoft.Scripting.DynamicMixin+SlotInfo,
Microsoft.Scripting]][]
79111038     2585       144760 System.Reflection.RuntimePropertyInfo
79110680     3086       148128 System.Signature
106f63bc     4183       150588 Microsoft.Scripting.BuiltinFunction
109cbb3c     4327       155772 System.Linq.Expressions2.MemberExpression
791336d8       37       162960
System.Collections.Generic.Dictionary`2+Entry[[System.String,
mscorlib],[System.Int32, mscorlib]][]
109c320c     4726       170136 System.Linq.Expressions2.AssignmentExpression
7912f348     7171       172104
System.Collections.Generic.List`1[[System.Reflection.MethodInfo,
mscorlib]]
7911f538     1708       177632 System.Reflection.Emit.DynamicILGenerator
7910ea30    15685       188220 System.RuntimeMethodHandle
109c76cc     6304       201728 System.Linq.Expressions2.Block
7912d9bc      889       204576 System.Collections.Hashtable+bucket[]
790ff734    10742       214840 System.RuntimeType
79130510    11613       223528 System.RuntimeTypeHandle[]
791208b4    16407       262512 System.Reflection.Emit.GenericFieldInfo
10f552cc    18594       297504
System.Collections.ObjectModel.ReadOnlyCollection`1[[System.Linq.Expressions2.Expression,
Microsoft.Scripting2.Core]]
109c4f1c     9671       386840 System.Linq.Expressions2.MethodCallExpression
7912dd40      646       432936 System.Char[]
109c7634    16161       517152 System.Linq.Expressions2.ConstantExpression
79109778    12835       718760 System.Reflection.RuntimeMethodInfo
79135538     1494      1167624 System.Reflection.Emit.__FixupData[]
7910dd38   124487      1493844 System.RuntimeTypeHandle
7912d7c0    17031      1846316 System.Int32[]
7912dae8    11218      1877012 System.Byte[]
790fd8c4    46924      2987964 System.String
7912d8f8   134460      5074708 System.Object[]


On Wed, Feb 25, 2009 at 10:51 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Your approach should be perfectly fine (it's basically what CompiledCode was designed for) and it's not clear to me what would be leaking in this scenario.
>
> One suggestion I'd have for you is to download and install windbg (http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx).
>
> Then attach to your process which is using all the memory and type in:
>
> .loadby sos mscorwks
> !DumpHeap -stat
>
> And send back the about the last 25 lines of that output. ?That'll give us the most common objects which are using memory in the GC heap and we might be able to track it down from there. ?If that's not sufficient maybe we can iterate and figure out what's going on.
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
>> Sent: Wednesday, February 25, 2009 8:38 AM
>> To: Dino Viehland
>> Cc: Discussion of IronPython
>> Subject: Re: [IronPython] Please vote up this DLR memory leak bug
>>
>> What is the impact of caching CompiledCode into this "collectability"
>> issue?
>>
>> I am working on a CMS that expose functions implemented in IronPython
>> to a template engine. So I read a directory of 40 or 50 xx.py files,
>> load it up and compiled them. This is off course a costly operation to
>> do it in every single HTTP request (and SLOW) so I compiled the source
>> code to CompiledCode and cache them.
>>
>> Then for every HTTP request, I retrieve these CompiledCode's from the
>> Cache and call Execute(scope) to make the frozen code to be a real
>> function. So with X HTTP request, there will be X scope and ?(X * 40)
>> functions being generated at runtime.
>>
>> Now our memory consumption is huge and is getting bigger until IIS
>> gave up and recycle the process.
>>
>> Dody G.
>>
>>
>>
>>
>> > Just some comments on this as there's a few issues intertwined here:
>> >
>> > 1.?????? Optimized code - this is currently the default and part of
>> the
>> > original problem.? If you execute code in "optimized" mode we
>> generate an
>> > uncollectible type.? In 2.6 I'm switching the default to be non-
>> optimized
>> > and I also am trying out a change that should reduce the amount of
>> leakage
>> > when we do this.? That will make the out of the box experience much
>> better.
>> >
>>
>>
>> > 2.?????? Multiple script runtimes - there's a bug in the DLR when you
>> > repeatedly create script runtimes that the rules aren't getting
>> collected.
>> > This is supposed to be fixed in 2.6 but I'm still seeing some leaks
>> in this
>> > scenario that I'll look into and fix.? Back-porting this to 2.0 would
>> be
>> > quite difficult as a lot of things have changed but we could
>> certainly look
>> > at backporting a different fix to 2.0.
>> >
>>
>> > 3.?????? There's a repro that defines "TestScriptOldClass" + n which
>> leaks.
>> > All class / function / member names in code get interned and this is
>> where
>> > this leak is coming from.? If you remove the + n then everything
>> works.? We
>> > may get rid of this interning at some point in the future but it's a
>> fairly
>> > significant change.? I'm inclined to believe this one isn't as much
>> of an
>> > issue as usually you aren't compiling code with new names every
>> single
>> > type.
>> >
>>
>>
>>
>>
>> >
>> >
>> > From: users-bounces at lists.ironpython.com
>> > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody
>> Gunawinata
>> > Sent: Sunday, February 22, 2009 2:10 PM
>> > To: Discussion of IronPython
>> > Subject: [IronPython] Please vote up this DLR memory leak bug
>> >
>> >
>> >
>> > There's only 5 votes so far.
>> >
>> >
>> >
>> >
>> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399
>> >
>> >
>> >
>> > --
>> > nomadlife.org
>>
>>
>>
>> --
>> nomadlife.org
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
nomadlife.org


From antonio.piteira at wtvision.com  Thu Feb 26 11:10:07 2009
From: antonio.piteira at wtvision.com (Antonio Piteira)
Date: Thu, 26 Feb 2009 10:10:07 +0000
Subject: [IronPython] Fwd: Ironpython delegates...
In-Reply-To: <350E7D38B6D819428718949920EC2355571BD514B1@NA-EXMSG-C102.redmond.corp.microsoft.com>
References: <4057092c0902221016u73ce649bv7cb90164db0a6e10@mail.gmail.com>
	<4057092c0902221026m24588790r1c8abd9bcabb7101@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571BD514B1@NA-EXMSG-C102.redmond.corp.microsoft.com>
Message-ID: <4057092c0902260210o3fb18650s214ec9547b0f1ec2@mail.gmail.com>

Hi Dino,
Thanks for your reply...

I had to synchronize threads in order to avoid cross-threading operations. I
have Ironpython hosted on an aplication with plugins, every time I accessed
some form control ( Plugin Form Designer ) I got a cross-thread error, so I
needed to invoke that instance.
CallTarget solved my problem... Do you know any other methodology that works
better then CallTarget?

Thank you,
Ant?nio Piteira

2009/2/22 Dino Viehland <dinov at microsoft.com>

>  Depending on what you?re doing you might be better off using Func<object>
> instead of CallTarget0.  CallTarget0 is more of a Python implementation
> detail and could change w/ major IronPython versions ? or even be replaced
> w/ Func<object>.  it?s primary purpose is to be the delegate for calling a
> zero-arg Python function so it could change due to changes in how we
> implement functions.  Func<object> will always exist and do exactly what it
> says.  Of course if you are actually doing something w/ calling classes or
> functions then it?s the right thing to use.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Antonio Piteira
> *Sent:* Sunday, February 22, 2009 10:26 AM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] Fwd: Ironpython delegates...
>
>
>
> Found the solution...
>
>
>
> clr.AddReference("Ironpython")
>
> from IronPython.Compiler import CallTarget0
>
>
>
> I was looking in the wrong place.
>
>
>
>
> --------------------------------------------------------------------------------------------------------------------------
>
>
> I've been searching for *CallTarget0* and from what I read it should be in
> Microsoft.Scripting.dll, but when I add the reference to clr and
> import CallTarget0  from Microsoft.Scripting.dll I get this message:
>
>
>
> ---------------------------
>
> Error...
>
> ---------------------------
>
> Cannot import name CallTarget0
>
> ---------------------------
>
> OK
>
> ---------------------------
>
>
>
> Any ideas?
>
>
>
> Thank you.
>
>
>
> _______________________________________________
> 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/20090226/ef8ff932/attachment.html>

From mksql at yahoo.com  Thu Feb 26 16:44:30 2009
From: mksql at yahoo.com (Matt)
Date: Thu, 26 Feb 2009 07:44:30 -0800 (PST)
Subject: [IronPython] Associate .ipy extension as IronPython in VS 2008?
Message-ID: <217036.88361.qm@web110813.mail.gq1.yahoo.com>

Interestingly .py files are not associated with devenv.exe on my machine, but are recognized by VS as Python language files. This is not the case for .ipy files, which are associated with devenv.exe.

Date: Wed, 25 Feb 2009 16:40:03 -0800
From: Jimmy Schementi <Jimmy.Schementi at microsoft.com>
Subject: Re: [IronPython] Associate .ipy extension as IronPython in VS
??? 2008?
To: Discussion of IronPython <users at lists.ironpython.com>
Message-ID:
??? <5283CA0A4168DF4FBBD71AE9ECA5A3284BEB541B99 at NA-EXMSG-C116.redmond.corp.microsoft.com>
??? 
Content-Type: text/plain; charset="iso-8859-1"

Can't you just tell the OS to associate .ipy files with devenv.exe? (Right-click on file --> Open with ... --> browse to devenv.exe). I don't think VS keeps track of file types associated with it, but the setup sets them.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matt
Sent: Wednesday, February 25, 2009 3:06 PM
To: users at lists.ironpython.com
Subject: [IronPython] Associate .ipy extension as IronPython in VS 2008?

Having installed the ASP.NET Futures package, I get syntax highlighting for files with the .py extension in Visual Studio 2008. I am unable to find a setting to associate files with a .ipy extension as the same.

I use both the CPython and IronPython interpreters, and would like to use the file extensions to keep the scripts separate. Is there a VS config setting or a registry key to set the file type in VS?

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

From mksql at yahoo.com  Thu Feb 26 17:50:49 2009
From: mksql at yahoo.com (Matt)
Date: Thu, 26 Feb 2009 08:50:49 -0800 (PST)
Subject: [IronPython] (solved) Associate .ipy extension as IronPython in
	VS 2008?
Message-ID: <35448.4640.qm@web110802.mail.gq1.yahoo.com>


By duplicating the GUID used for the .py extension in a new registry key at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Languages\File
Extensions\.ipy], VS08 recognizes the syntax and provided limited Intellisense.


--- On Wed, 2/25/09, Matt <mksql at yahoo.com> wrote:

From: Matt <mksql at yahoo.com>
Subject: Associate .ipy extension as IronPython in VS 2008?
To: users at lists.ironpython.com
Date: Wednesday, February 25, 2009, 6:05 PM

Having installed the ASP.NET Futures package, I get syntax highlighting for files with the .py extension in Visual Studio 2008. I am unable to find a setting to associate files with a .ipy extension as the same.

I use both the CPython and IronPython interpreters, and would like to use the file extensions to keep the scripts separate. Is there a VS config setting or a registry key to set the file type in VS?



From dinov at microsoft.com  Fri Feb 27 23:10:53 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 27 Feb 2009 14:10:53 -0800
Subject: [IronPython] Fwd: Ironpython delegates...
In-Reply-To: <4057092c0902260210o3fb18650s214ec9547b0f1ec2@mail.gmail.com>
References: <4057092c0902221016u73ce649bv7cb90164db0a6e10@mail.gmail.com>
	<4057092c0902221026m24588790r1c8abd9bcabb7101@mail.gmail.com>
	<350E7D38B6D819428718949920EC2355571BD514B1@NA-EXMSG-C102.redmond.corp.microsoft.com>
	<4057092c0902260210o3fb18650s214ec9547b0f1ec2@mail.gmail.com>
Message-ID: <350E7D38B6D819428718949920EC2355571BF42CED@NA-EXMSG-C102.redmond.corp.microsoft.com>

Any delegate should work for this so I'd suggest Func<object> instead.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Antonio Piteira
Sent: Thursday, February 26, 2009 2:10 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Fwd: Ironpython delegates...

Hi Dino,

Thanks for your reply...

I had to synchronize threads in order to avoid cross-threading operations. I have Ironpython hosted on an aplication with plugins, every time I accessed some form control ( Plugin Form Designer ) I got a cross-thread error, so I needed to invoke that instance.
CallTarget solved my problem... Do you know any other methodology that works better then CallTarget?

Thank you,
Ant?nio Piteira

2009/2/22 Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>>

Depending on what you're doing you might be better off using Func<object> instead of CallTarget0.  CallTarget0 is more of a Python implementation detail and could change w/ major IronPython versions - or even be replaced w/ Func<object>.  it's primary purpose is to be the delegate for calling a zero-arg Python function so it could change due to changes in how we implement functions.  Func<object> will always exist and do exactly what it says.  Of course if you are actually doing something w/ calling classes or functions then it's the right thing to use.



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 Antonio Piteira
Sent: Sunday, February 22, 2009 10:26 AM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: [IronPython] Fwd: Ironpython delegates...



Found the solution...



clr.AddReference("Ironpython")

from IronPython.Compiler import CallTarget0



I was looking in the wrong place.



--------------------------------------------------------------------------------------------------------------------------


I've been searching for CallTarget0 and from what I read it should be in Microsoft.Scripting.dll, but when I add the reference to clr and import CallTarget0  from Microsoft.Scripting.dll I get this message:



---------------------------

Error...

---------------------------

Cannot import name CallTarget0

---------------------------

OK

---------------------------



Any ideas?



Thank you.



_______________________________________________
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/20090227/ff549fac/attachment.html>