[IronPython] Any update to open-sourcing IPY for ASP.Net?

[Adam Brand]

I thought I sent a message on this a while back but I don't think it went
through.

 

Any update on getting the source code for IronPython for ASP.Net released?

 

Thanks,

Adam

 

 

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

[IronPython] Fwd: IronPython for ASP.Net

[Adam Brand]

"we’re doing it right and getting the source code released and Ms-Pl’d, so
we can include it on Codeplex sources, builds, and nightly builds. Then it
can be included in each IronPython release, just like Silverlight binaries
are."

Any update on this front? Did legal/the team give up on on the idea? Would
be awesome to see this happen for the community (and for 2.6.1 RC1
goodness).

Adam

-- Forwarded message --
From: Jimmy Schementi 
Date: Wed, May 20, 2009 at 7:17 PM
Subject: Re: [IronPython] IronPython for ASP.Net
To: "d...@nomadlife.org" , Discussion of IronPython <
users@lists.ironpython.com>


First off, it hasn’t been three years: a refresh was released 8 months ago,
and sent to this very list:

http://lists.ironpython.com/pipermail/users-ironpython.com/2008-September/008497.html



Secondly, rather than just producing these one off releases (where are very
taxing on the team), we’re doing it right and getting the source code
released and Ms-Pl’d, so we can include it on Codeplex sources, builds, and
nightly builds. Then it can be included in each IronPython release, just
like Silverlight binaries are.



Lastly, IronRuby and IronPython are programming languages, made by
programming language teams. We’re very interested in running as many
existing Ruby and Python programs as possible. It just so happens that
Django and Rails are popular, complex pieces of software that help find
bugs, and give the languages street cred for running them. If those web
frameworks didn’t run, theirs probably something wrong with our language.



Running in ASP.NET and MVC require a significant amount of work *outside* of
the language, so it really isn’t a language team’s purpose to build that.
Sure they provide good demos as conferences or blog posts, but they’ll only
be toys. We’ve invested in those technologies before, which is why the
ASP.NET and Silverlight integration exists, but no one is working on
enabling web-technologies full-time (though I have spurts of diving back
into Silverlight from time to time). If you don’t like the level of
investment in dynamic languages for Microsoft web technologies, that’s
something that you should communicate to the ASP.NET team; Phil Haack (
http://www.haacked.com) or Dmitry Robsman (http://blogs.msdn.com/dmitryr)
are good people to address.



~Jimmy



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Dody Gunawinata
*Sent:* Wednesday, May 20, 2009 1:22 PM
*To:* Discussion of IronPython
*Subject:* [IronPython] IronPython for ASP.Net



Is there any update for IronPython for ASP.Net?



It has been three years since IronPython support for ASP.Net introduced with
the release of the whitepaper (
http://www.asp.net/DynamicLanguages/whitepaper/) and the first binary. Since
then I think we've had Katrina, a Beijing Olympic, a new President, a
financial collapse and two James Bond movies - yet until now there is still
no up to date support for the technology. I know that the legal team, etc
are working on the source release, but I think it is pretty galling that
Microsoft's own web framework stack is barely supported by its own dynamic
language technology, both on the 'classic' ASP.Net and MVC stack. I mean
there is more energy put into having IronPython and IronRuby to run Django
and RubyOnRails web framework instead of ASP.Net stack. This just doesn't
make sense to me.

-- 
nomadlife.org

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

Re: [IronPython] FW: App_Script Problem in latest IronPython for ASP.Net

[Adam Brand]

Thanks. The previous release had the correct behavior, so hopefully it isn’t
hard to do.



Adam



Adam Brand

SilverKey Technologies



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Jimmy Schementi
*Sent:* Tuesday, August 04, 2009 9:13 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] FW: App_Script Problem in latest IronPython for
ASP.Net



Not yet, sorry. I think I can fix that for the next release and make them
reload if they've been modified, but I haven't checked if there is a way to
do that today. I'll take a look now...

~Jimmy

Sent from my phone


On Aug 4, 2009, at 8:57 AM, "Adam Brand"  wrote:

 Any update on this?

On Fri, Jun 12, 2009 at 2:47 PM, Jimmy Schementi <
jimmy.scheme...@microsoft.com> wrote:

Not sure if it’s by design or just failing to reload it correctly. I’ll take
a look shortly.



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
*Sent:* Friday, June 12, 2009 8:54 AM
*To:* Discussion of IronPython
*Subject:* [IronPython] FW: App_Script Problem in latest IronPython for
ASP.Net



Does anyone have any insight into this?



Thanks,

Adam



Adam Brand

SilverKey Technologies



*From:* Adam Brand [mailto:ad...@silverkeytech.com]
*Sent:* Sunday, May 31, 2009 7:53 AM
*To:* 'Discussion of IronPython'
*Subject:* App_Script Problem in latest IronPython for ASP.Net



I’ve noticed that with the latest bits for IronPython for ASP.Net, files in
app_script only seem to be revisited when the app pool is restarted.



For example, if I have a file called hello_world.py in App_Script, and
delete that file, the app still executes code in that file as if it were
there. If I change a line in the file, that line is not shown as changed
until I restart the app pool.



Is this by design, a bug, or something I’m doing wrong?



Thanks,

Adam


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




-- 
Adam Brand

Managing Partner
SilverKey Technologies

Direct: +1-312-239-6722
Main: +1-312-951-7525
Skype: adamsilverkey
Email: ad...@silverkeytech.com
www.silverkeytech.com

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

Re: [IronPython] IronPython for ASP.Net

[Adam Brand]

and give the languages street cred for running them. If those web
> frameworks didn’t run, theirs probably something wrong with our language.
>
>
>
> Running in ASP.NET and MVC require a significant amount of work *outside*of 
> the language, so it really isn’t a language team’s purpose to build that.
> Sure they provide good demos as conferences or blog posts, but they’ll only
> be toys. We’ve invested in those technologies before, which is why the
> ASP.NET and Silverlight integration exists, but no one is working on
> enabling web-technologies full-time (though I have spurts of diving back
> into Silverlight from time to time). If you don’t like the level of
> investment in dynamic languages for Microsoft web technologies, that’s
> something that you should communicate to the ASP.NET team; Phil Haack (
> http://www.haacked.com) or Dmitry Robsman (http://blogs.msdn.com/dmitryr)
> are good people to address.
>
>
>
> ~Jimmy
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Dody Gunawinata
> *Sent:* Wednesday, May 20, 2009 1:22 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] IronPython for ASP.Net
>
>
>
> Is there any update for IronPython for ASP.Net?
>
>
>
> It has been three years since IronPython support for ASP.Net introduced
> with the release of the whitepaper (
> http://www.asp.net/DynamicLanguages/whitepaper/) and the first binary.
> Since then I think we've had Katrina, a Beijing Olympic, a new President, a
> financial collapse and two James Bond movies - yet until now there is still
> no up to date support for the technology. I know that the legal team, etc
> are working on the source release, but I think it is pretty galling that
> Microsoft's own web framework stack is barely supported by its own dynamic
> language technology, both on the 'classic' ASP.Net and MVC stack. I mean
> there is more energy put into having IronPython and IronRuby to run Django
> and RubyOnRails web framework instead of ASP.Net stack. This just doesn't
> make sense to me.
>
> --
> nomadlife.org
>
>
>
>
> --
> nomadlife.org
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


-- 
Adam Brand

Managing Partner
SilverKey Technologies

Direct: +1-312-239-6722
Main: +1-312-951-7525
Skype: adamsilverkey
Email: ad...@silverkeytech.com
www.silverkeytech.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] FW: App_Script Problem in latest IronPython for ASP.Net

[Adam Brand]

Any update on this?

On Fri, Jun 12, 2009 at 2:47 PM, Jimmy Schementi <
jimmy.scheme...@microsoft.com> wrote:

> Not sure if it’s by design or just failing to reload it correctly. I’ll
> take a look shortly.
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
> *Sent:* Friday, June 12, 2009 8:54 AM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] FW: App_Script Problem in latest IronPython for
> ASP.Net
>
>
>
> Does anyone have any insight into this?
>
>
>
> Thanks,
>
> Adam
>
>
>
> Adam Brand
>
> SilverKey Technologies
>
>
>
> *From:* Adam Brand [mailto:ad...@silverkeytech.com]
> *Sent:* Sunday, May 31, 2009 7:53 AM
> *To:* 'Discussion of IronPython'
> *Subject:* App_Script Problem in latest IronPython for ASP.Net
>
>
>
> I’ve noticed that with the latest bits for IronPython for ASP.Net, files in
> app_script only seem to be revisited when the app pool is restarted.
>
>
>
> For example, if I have a file called hello_world.py in App_Script, and
> delete that file, the app still executes code in that file as if it were
> there. If I change a line in the file, that line is not shown as changed
> until I restart the app pool.
>
>
>
> Is this by design, a bug, or something I’m doing wrong?
>
>
>
> Thanks,
>
> Adam
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


-- 
Adam Brand

Managing Partner
SilverKey Technologies

Direct: +1-312-239-6722
Main: +1-312-951-7525
Skype: adamsilverkey
Email: ad...@silverkeytech.com
www.silverkeytech.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Random Number Generation

[Adam Brand]

Awesome, thanks that worked. I was using IronPython for ASP.net and did not
have a pointer to the standard library.



One last question though if anyone knows…is there a way to do this
sys.path.append from Global.asax? I know there is a python equivalent
global.py, but we right now have a bunch of code in global.asax and would
need to rewrite that in python if not. Or can they co-exist?



Thanks,

Adam



Adam Brand

SilverKey Technologies



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *David DiCato
*Sent:* Wednesday, June 24, 2009 9:31 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] Random Number Generation



Seo is correct; in order to import random, you need the CPython standard
library in sys.path. There are 3 ways to do this:

1.   Run IronPython from the standard library directory (the working
directory is in sys.path by default)

2.   Append the standard lib directory to sys.path for invocation of
IronPython, e.g.:

import sys

sys.path.append(r’c:\Program Files\IronPython 2.6\Lib’)

3.   (Recommended) Set the environment variable IRONPYTHONPATH to point
to the standard lib directory



System.Random is implemented in terms of .NET integers, which are 32-bit.
When your script passed 99, IronPython tried to represent it in 32
bits, causing an arithmetic overflow. In a pinch, you can use slightly more
complicated logic to suit your needs, e.g.:

var_utmn = randgen.Next(1,10) * 10 +
randgen.Next(9)

But using the CPython library is much cleaner J.



A final word of advice: Both standard libraries’ random number generators
use the convention that the first argument is inclusive and the second is
exclusive. This means that your code will generate random numbers from
10 to 98, which may or may not be what you want.



Good luck,

- David



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
*Sent:* Wednesday, June 24, 2009 5:22 PM
*To:* Discussion of IronPython
*Subject:* [IronPython] Random Number Generation



I feel newbish writing this, but I’m having problems generating random
numbers in IronPython.



I tried “import random” but that doesn’t seem to work (module not found).



I tried creating a System.Random but when I run

var_utmn = randgen.Next(10,99) I get a buffer overflow.



Any ideas? The random number needs to be above those two numbers indicated
above.



Thanks,

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

[IronPython] Random Number Generation

[Adam Brand]

I feel newbish writing this, but I’m having problems generating random
numbers in IronPython.



I tried “import random” but that doesn’t seem to work (module not found).



I tried creating a System.Random but when I run

var_utmn = randgen.Next(10,99) I get a buffer overflow.



Any ideas? The random number needs to be above those two numbers indicated
above.



Thanks,

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

[IronPython] FW: App_Script Problem in latest IronPython for ASP.Net

[Adam Brand]

Does anyone have any insight into this?



Thanks,

Adam



Adam Brand

SilverKey Technologies



*From:* Adam Brand [mailto:ad...@silverkeytech.com]
*Sent:* Sunday, May 31, 2009 7:53 AM
*To:* 'Discussion of IronPython'
*Subject:* App_Script Problem in latest IronPython for ASP.Net



I’ve noticed that with the latest bits for IronPython for ASP.Net, files in
app_script only seem to be revisited when the app pool is restarted.



For example, if I have a file called hello_world.py in App_Script, and
delete that file, the app still executes code in that file as if it were
there. If I change a line in the file, that line is not shown as changed
until I restart the app pool.



Is this by design, a bug, or something I’m doing wrong?



Thanks,

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

Re: [IronPython] VS Support/Intelllisense for IronPython

[Adam Brand]

We could probably wrangle a few people together for it from the list…could
anyone over on the DLR team PM it or help with initial architectural
support?



I volunteer myself to help…probably with the specs/docs and testing as I’m
not a hardcore developer.



Any volunteers to help with the dev side?



Adam



Adam Brand

SilverKey Technologies



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Oleg Tkachenko
*Sent:* Thursday, June 11, 2009 2:08 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] VS Support/Intelllisense for IronPython



It’s IPy 1.X and it’s basically VS integration sample hence as you can
imagine it’s more focused on integration aspects, not on tool quality.

I wish it was an open source project driven by the community…

--

Oleg



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
*Sent:* Thursday, June 11, 2009 1:20 PM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] VS Support/Intelllisense for IronPython



Ah…I didn’t know about IronPython Studio

(
http://ironpythonstudio.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=8934
).



…it seems fairly thorough. What happened to that project? What are its main
limitations?



Adam



Adam Brand

SilverKey Technologies



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Dino Viehland
*Sent:* Thursday, June 11, 2009 11:18 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] VS Support/Intelllisense for IronPython



We’ve made some attempts in the past (e.g. IronPython Studio) but there’s no
longer any active development for intellisense.



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
*Sent:* Thursday, June 11, 2009 7:35 AM
*To:* Discussion of IronPython
*Subject:* [IronPython] VS Support/Intelllisense for IronPython



I was wondering if there is any ongoing development to support Intellisense
with IronPython in Visual Studio.



Can someone from the team comment on this?



Thanks,

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

Re: [IronPython] VS Support/Intelllisense for IronPython

[Adam Brand]

Ah…I didn’t know about IronPython Studio

(
http://ironpythonstudio.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=8934
).



…it seems fairly thorough. What happened to that project? What are its main
limitations?



Adam



Adam Brand

SilverKey Technologies



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Dino Viehland
*Sent:* Thursday, June 11, 2009 11:18 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] VS Support/Intelllisense for IronPython



We’ve made some attempts in the past (e.g. IronPython Studio) but there’s no
longer any active development for intellisense.



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
*Sent:* Thursday, June 11, 2009 7:35 AM
*To:* Discussion of IronPython
*Subject:* [IronPython] VS Support/Intelllisense for IronPython



I was wondering if there is any ongoing development to support Intellisense
with IronPython in Visual Studio.



Can someone from the team comment on this?



Thanks,

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

Re: [IronPython] VS Support/Intelllisense for IronPython

[Adam Brand]

Is adding Intellisense for IPY to VS something that can be done by the
community, or does it require access to source code that we can’t access?



I’m not familiar with the extent to which VS can be customized for
languages.



Thanks,

Adam



Adam Brand

SilverKey Technologies



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Dino Viehland
*Sent:* Thursday, June 11, 2009 11:18 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] VS Support/Intelllisense for IronPython



We’ve made some attempts in the past (e.g. IronPython Studio) but there’s no
longer any active development for intellisense.



*From:* users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
*Sent:* Thursday, June 11, 2009 7:35 AM
*To:* Discussion of IronPython
*Subject:* [IronPython] VS Support/Intelllisense for IronPython



I was wondering if there is any ongoing development to support Intellisense
with IronPython in Visual Studio.



Can someone from the team comment on this?



Thanks,

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

[IronPython] VS Support/Intelllisense for IronPython

[Adam Brand]

I was wondering if there is any ongoing development to support Intellisense
with IronPython in Visual Studio.



Can someone from the team comment on this?



Thanks,

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

[IronPython] IronPython for ASP.Net file locations

[Adam Brand]

I noticed that if I google "IronPython for ASP.Net", none of the first
results get you easily to a link to actually download the bits.

 

I know there is the broad category of "ASP.Net Dynamic Languages Support,"
but I think a more useful name for the IronPython support would be
IronPython for ASP.Net.

 

Unless many other languages are forthcoming, I was thinking the following
changes could be made to the CodePlex project:

1.   Rename it to be IronPython for ASP.Net

2.   Change the H1 title on
http://www.codeplex.com/aspnet/Wiki/View.aspx?title=Dynamic%20Language%20Sup
port
 &referringTitle=Home to be "IronPython for
ASP.Net"

3.   Change the "Downloads" on the right site to show the IronPython for
ASP.Net release.

 

Also, if you could change the outdated Microsoft Downloads page (#1 in the
Google search results) to have a pointer to the new files, that would be
ideal. Similarly with any other blog entries.

 

Adam

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

[IronPython] App_Script Problem in latest IronPython for ASP.Net

[Adam Brand]

I've noticed that with the latest bits for IronPython for ASP.Net, files in
app_script only seem to be revisited when the app pool is restarted.

 

For example, if I have a file called hello_world.py in App_Script, and
delete that file, the app still executes code in that file as if it were
there. If I change a line in the file, that line is not shown as changed
until I restart the app pool.

 

Is this by design, a bug, or something I'm doing wrong?

 

Thanks,

Adam 

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

Re: [IronPython] [ATTN] ASP.NET and IronPython 2.6 Beta 1

[Adam Brand]

NICE!

 

Just a thought, but maybe on the download page you should put a link that
says "IronPython for ASP.Net Binaries" or something. Right now the link to
"sample" is kind of confusing. The way I read "sample" is that it will just
contain source code, not actual binaries.

 

Thanks,

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
Sent: Tuesday, May 26, 2009 12:39 PM
To: Discussion of IronPython
Subject: [IronPython] [ATTN] ASP.NET and IronPython 2.6 Beta 1

 

Download Now

http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17613#Down
loadId=69511

 

This release is compatible with IronPython
<http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=25126
>  2.6 Beta 1. Currently it does not include Language Services Support and
project templates. To create a new IronPython ASP.NET WebForms project,
simply copy the "examples\hello-webforms" to a new directory and rename the
directory to your liking. A redistributed copy of IronPython 2.6 Beta 1 can
be found in the "bin" directory; all files except
Microsoft.Web.Scripting.dll, the IronPython ASP.NET integration, are from
the IronPython 2.6 Beta 1 release. 

Included in this release are two WebForms examples that are written in
IronPython: "hello-webforms" and "album-handler", which can be found in the
"examples" directory. "hello-webforms" is a simple web application that
shows PostBack handling, and "album-handler" is a larger web application
that creates a photo album from a directory of images and generates
thumbnails for them on the fly.

 

Release notes:
http://aspnet.codeplex.com/Wiki/View.aspx?title=Dynamic%20Language%20Support

Release page:
http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17613

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

Re: [IronPython] IronPython for ASP.Net

[Adam Brand]

w00t! J Thank you so much!

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
Sent: Thursday, May 21, 2009 3:11 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython for ASP.Net

 

I completely agree with your points; we have a finite amount of resources
and choose to focus on language compatibility over .NET web-stack
integration. Though IronPython has done that web-work in the past, we're
purely focused on compat. I've forwarded on the previous mail to the ASP.NET
team; I want to see IronPython and IronRuby be used on the web more too. =)

 

That being said, I've just finished packaging up Microsoft.Web.Scripting.dll
that works against the released IronPython 2 Beta 1, and I'll be releasing
it either today to tomorrow . so end of conversation? =P Na, I this is a
good conversation to have, but in short you'll be able to use IronPython 2
Beta 1 in ASP.NET very soon again. Hopefully the next beta of IronPython 2.6
will include the DLL and source, otherwise I'll make this package again.

 

~js

 

From: Dody Gunawinata [mailto:empirebuil...@gmail.com] 
Sent: Thursday, May 21, 2009 4:23 AM
To: Jimmy Schementi
Cc: Discussion of IronPython
Subject: Re: [IronPython] IronPython for ASP.Net

 

The refresh was unusable because it contained the version of IronPyton that
is not compatible with .Net 3.5 framework (I think it was built on IP 2.0
Beta 3/4); 

I'm griping about this issue in this list because I don't think this is a
completely separate issue from the DLR programming languages. Maybe it is
not a direct responsibility of this team, but the impact is direct for the
following reasons:

*   Nobody adopts a language as is. The libraries matters. The existing
community of Python and Ruby are not going to move to Windows platform just
because IronPython and IronRuby are being worked on and released. They have
had a multi platform runtimes with de facto standards that are capable of
doing wonderful things for more than a decade.
*   There is much bigger market for language adoption for existing
.Net/Windows based developers (and new developers) and these guys/gals are
using mostly standard Microsoft stacks. And they are using .Net via mainly
C# and VB.Net. If the DLR languages do not have proper support at least for
the major technology stacks (I would consider ASP.Net/Silverlight as major
stacks), many people will not consider using the DLR based language for
their production systems.
*   I know ASP.Net MVC is open source and it's free to be extended etc,
but ASP.Net WebForm have be en deployed massively and that's not going to
change anytime soon. And theres is already a support, albeit poor and not up
to date, for ASP.Net webform stacks in IronPython. Not having it fully
updated is a waste of opportunity.
*   .Net 4.0 and C# vNext contains dynamic language support but really,
what is good for if the DLR languages can only be used in much more limited
scenarios because some major technology stacks are not supported.
*   You raised correctly that Django and  RoR are being used to validate
the  languages. But I would argue that the existing technology stack support
validates the DLR platform, not just the languages. 

So yes, I'm not happy with the level of investment being put on supporting
the technology stacks because I think it is pretty short sighted. No, I
don't blame this team for this but at least if I complain on this list, it
might have a chance being forwarded internally because this is one of the
best community mailing list for Microsoft technologies. 

Dody Gunawinata

On Thu, May 21, 2009 at 5:17 AM, Jimmy Schementi
 wrote:

First off, it hasn't been three years: a refresh was released 8 months ago,
and sent to this very list:

 
<http://lists.ironpython.com/pipermail/users-ironpython.com/2008-September/0
08497.html>
http://lists.ironpython.com/pipermail/users-ironpython.com/2008-September/00
8497.html

 

Secondly, rather than just producing these one off releases (where are very
taxing on the team), we're doing it right and getting the source code
released and Ms-Pl'd, so we can include it on Codeplex sources, builds, and
nightly builds. Then it can be included in each IronPython release, just
like Silverlight binaries are.

 

Lastly, IronRuby and IronPython are programming languages, made by
programming language teams. We're very interested in running as many
existing Ruby and Python programs as possible. It just so happens that
Django and Rails are popular, complex pieces of software that help find
bugs, and give the languages street cred for running them. If those web
frameworks didn't run, theirs probably something wrong with our language. 

 

Running in  <http://ASP.NET> ASP.NET and MVC require a significant amount of
work outside of the lang

Re: [IronPython] IronPython for ASP.Net

[Adam Brand]

Hi Jimmy,

 

Until we're able to get the source code fully released, do you think it
would be possible to maybe get four or five volunteers NDA'd source code
access to update the build? Regardless of when the source code is released,
that work would need to get done.so maybe this way we could get a headstart?

 

Thanks,

Adam

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
Sent: Wednesday, May 20, 2009 8:17 PM
To: d...@nomadlife.org; Discussion of IronPython
Subject: Re: [IronPython] IronPython for ASP.Net

 

First off, it hasn't been three years: a refresh was released 8 months ago,
and sent to this very list:

http://lists.ironpython.com/pipermail/users-ironpython.com/2008-September/00
8497.html

 

Secondly, rather than just producing these one off releases (where are very
taxing on the team), we're doing it right and getting the source code
released and Ms-Pl'd, so we can include it on Codeplex sources, builds, and
nightly builds. Then it can be included in each IronPython release, just
like Silverlight binaries are.

 

Lastly, IronRuby and IronPython are programming languages, made by
programming language teams. We're very interested in running as many
existing Ruby and Python programs as possible. It just so happens that
Django and Rails are popular, complex pieces of software that help find
bugs, and give the languages street cred for running them. If those web
frameworks didn't run, theirs probably something wrong with our language. 

 

Running in ASP.NET and MVC require a significant amount of work outside of
the language, so it really isn't a language team's purpose to build that.
Sure they provide good demos as conferences or blog posts, but they'll only
be toys. We've invested in those technologies before, which is why the
ASP.NET and Silverlight integration exists, but no one is working on
enabling web-technologies full-time (though I have spurts of diving back
into Silverlight from time to time). If you don't like the level of
investment in dynamic languages for Microsoft web technologies, that's
something that you should communicate to the ASP.NET team; Phil Haack
(http://www.haacked.com) or Dmitry Robsman (http://blogs.msdn.com/dmitryr)
are good people to address.

 

~Jimmy

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Wednesday, May 20, 2009 1:22 PM
To: Discussion of IronPython
Subject: [IronPython] IronPython for ASP.Net

 

Is there any update for IronPython for ASP.Net?

 

It has been three years since IronPython support for ASP.Net introduced with
the release of the whitepaper
(http://www.asp.net/DynamicLanguages/whitepaper/) and the first binary.
Since then I think we've had Katrina, a Beijing Olympic, a new President, a
financial collapse and two James Bond movies - yet until now there is still
no up to date support for the technology. I know that the legal team, etc
are working on the source release, but I think it is pretty galling that
Microsoft's own web framework stack is barely supported by its own dynamic
language technology, both on the 'classic' ASP.Net and MVC stack. I mean
there is more energy put into having IronPython and IronRuby to run Django
and RubyOnRails web framework instead of ASP.Net stack. This just doesn't
make sense to me.

-- 
nomadlife.org

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

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

That is great news, and a great solution! Thanks!

 

Adam

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
Sent: Tuesday, May 05, 2009 9:25 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Rather than just releasing builds, I'm waiting on the OK from the ASP.NET to
release to source code for it, so it can be included in the IronPython
releases and the Codeplex sources/daily builds. That seems like a much
better solution. =) I'll keep you posted (I've been in conference-mode for
the past couple months, so things have been slow, sorry!).

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Adam Brand
Sent: Tuesday, May 05, 2009 5:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Any updated timeline on this (IronPython 2.6/ASP.Net Integration)? Just
wanted to check in and see where it was on the list.

 

Thanks,

Adam

2009/3/30 Jimmy Schementi 

A IronPython 2.6 version of the ASP.NET integration will be out shortly, I
have to get time to make a build and get it sent over to the ASP.NET team.
I'm working through some other things I need to get done first, but assume
two weeks.

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Adam Brand
Sent: Saturday, March 28, 2009 1:37 PM


To: 'Discussion of IronPython'
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Any update on the timeline for getting IronPython for ASP.Net updated? This
would make a world of difference for our IronPython-based web app.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Saturday, March 28, 2009 1:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

This is awesome. Web application can benefit from this "adaptive
compilation" approach a lot - especially for low trafficked sites.

On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas
 wrote:

Dave,

This is great news, congratulations to the IP team on this release! We'll do
a test-port of Resolver One early next week and will reply to the list with
any issues we find.


Cheers,

Giles


Dave Fugate wrote:

Hello Python Community,

We're pleased to announce the release of IronPython 2.6 Alpha 1. As you
might imagine, this release is all about supporting new CPython 2.6 features
such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes
(PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
version required for this release is the same as IronPython 2.0; namely .NET
2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we
get your feedback on the release(s) quickly to incorporate requested
changes.

Besides CPython 2.6 features, another significant change in this release is
that ipy.exe now uses "adaptive compilation" by default. Adaptive
compilation is a technique in which IronPython:

1. Interprets and executes Python method calls up to /N/ times for a given
method. If you're only going to execute a method a few times, it's typically
faster to interpret the method instead of compiling and executing it

2. Compiles and executes the Python method call on the /N+1/ invocation of
the method. Compilation of a Python method is a heavyweight operation, but
we can reuse the result for subsequent invocations

3. Reuses the previously compiled method for new calls to the Python method.
This operation is much faster than interpreting the method call as the
method was already compiled in the previous step

The reason for this change is that it provides a nice performance gain for
Python code containing lots of functions/methods that only get called a few
times. All this said, this feature is still undergoing active development
and as a consequence some Python scripts may actually run slower with it
turned on. For this reason, our old default mode of running Python scripts
is still available by passing the -O or -D flags to ipy.exe. Any feedback on
how this new feature affects your IronPython applications performance-wise
would be greatly appreciated.

There's also a few minor changes since IronPython 2.0.1 that are worth
calling out here:

. IronPython.msi now installs NGEN'ed binaries by default

. IronPython.msi now offers a little more selection with respect to what
you'd like to install. For example, Silverlight templates are optional

. The default installation location of IronPython.msi no longer indicates
whether the 2.6 release is an Alpha, Beta, or a patched release. Future
IronPython 2.6 installations will rep

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

Any updated timeline on this (IronPython 2.6/ASP.Net Integration)? Just
wanted to check in and see where it was on the list.
Thanks,
Adam

2009/3/30 Jimmy Schementi 

>  A IronPython 2.6 version of the ASP.NET integration will be out shortly,
> I have to get time to make a build and get it sent over to the ASP.NETteam. 
> I’m working through some other things I need to get done first, but
> assume two weeks.
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
> *Sent:* Saturday, March 28, 2009 1:37 PM
>
> *To:* 'Discussion of IronPython'
> *Subject:* Re: [IronPython] Announcing IronPython 2.6 Alpha 1
>
>
>
> Any update on the timeline for getting IronPython for ASP.Net updated? This
> would make a world of difference for our IronPython-based web app.
>
>
>
> Adam
>
>
>
> Adam Brand
>
> SilverKey Technologies
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Dody Gunawinata
> *Sent:* Saturday, March 28, 2009 1:09 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Announcing IronPython 2.6 Alpha 1
>
>
>
> This is awesome. Web application can benefit from this "adaptive
> compilation" approach a lot - especially for low trafficked sites.
>
> On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas <
> giles.tho...@resolversystems.com> wrote:
>
> Dave,
>
> This is great news, congratulations to the IP team on this release! We'll
> do a test-port of Resolver One early next week and will reply to the list
> with any issues we find.
>
>
> Cheers,
>
> Giles
>
>
> Dave Fugate wrote:
>
> Hello Python Community,
>
> We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you
> might imagine, this release is all about supporting new CPython 2.6 features
> such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes
> (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
> version required for this release is the same as IronPython 2.0; namely .NET
> 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
> only a couple Alphas and Betas of IronPython 2.6. As such, it’s key that we
> get your feedback on the release(s) quickly to incorporate requested
> changes.
>
> Besides CPython 2.6 features, another significant change in this release is
> that ipy.exe now uses “adaptive compilation” by default. Adaptive
> compilation is a technique in which IronPython:
>
> 1. Interprets and executes Python method calls up to /N/ times for a given
> method. If you’re only going to execute a method a few times, it’s typically
> faster to interpret the method instead of compiling and executing it
>
> 2. Compiles and executes the Python method call on the /N+1/ invocation of
> the method. Compilation of a Python method is a heavyweight operation, but
> we can reuse the result for subsequent invocations
>
> 3. Reuses the previously compiled method for new calls to the Python
> method. This operation is much faster than interpreting the method call as
> the method was already compiled in the previous step
>
> The reason for this change is that it provides a nice performance gain for
> Python code containing lots of functions/methods that only get called a few
> times. All this said, this feature is still undergoing active development
> and as a consequence some Python scripts may actually run slower with it
> turned on. For this reason, our old default mode of running Python scripts
> is still available by passing the –O or -D flags to ipy.exe. Any feedback on
> how this new feature affects your IronPython applications performance-wise
> would be greatly appreciated.
>
> There’s also a few minor changes since IronPython 2.0.1 that are worth
> calling out here:
>
> · IronPython.msi now installs NGEN’ed binaries by default
>
> · IronPython.msi now offers a little more selection with respect to what
> you’d like to install. For example, Silverlight templates are optional
>
> · The default installation location of IronPython.msi no longer indicates
> whether the 2.6 release is an Alpha, Beta, or a patched release. Future
> IronPython 2.6 installations will replace previous 2.6 releases which will
> be uninstalled automatically
>
> · The -X:PreferComInteropAssembly flag has been removed. All COM interop is
> now done through normal COM dispatch
>
> You can download IronPython 2.6 Alpha 1 at:
> http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982
>
> The IronPython Team
>
> --

[IronPython] ASP.Net Dynamic Language Support Download Location?

[Adam Brand]

Sorry if this sounds like a newbie question, but where can I get the
September 2008 ASP.Net Dynamic Language Support files?

 

I looked here:
http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17613 but
for the life of me I can't see any link to the actual binaries. All I see
are two examples and some documentation.

 

Thanks,

Adam

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

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

No worries.just excited to get it J. Thanks for continuing to work on it.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
Sent: Friday, April 17, 2009 12:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

I guess I really meant 3 weeks, because I was doing Lang.NET conference
stuff all this past week. Sorry for the wait.

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Adam Brand
Sent: Thursday, April 16, 2009 11:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Is there any updated timeline on this? Looking forward to it :-). I'm sure
you're swamped...if there is anything the community can do to speed this up
please let us know.

 

Thanks,

Adam

On Mon, Mar 30, 2009 at 4:44 PM, Jimmy Schementi
 wrote:

A IronPython 2.6 version of the ASP.NET integration will be out shortly, I
have to get time to make a build and get it sent over to the ASP.NET team.
I'm working through some other things I need to get done first, but assume
two weeks.

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Adam Brand
Sent: Saturday, March 28, 2009 1:37 PM


To: 'Discussion of IronPython'
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Any update on the timeline for getting IronPython for ASP.Net updated? This
would make a world of difference for our IronPython-based web app.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Saturday, March 28, 2009 1:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

This is awesome. Web application can benefit from this "adaptive
compilation" approach a lot - especially for low trafficked sites.

On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas
 wrote:

Dave,

This is great news, congratulations to the IP team on this release! We'll do
a test-port of Resolver One early next week and will reply to the list with
any issues we find.


Cheers,

Giles


Dave Fugate wrote:

Hello Python Community,

We're pleased to announce the release of IronPython 2.6 Alpha 1. As you
might imagine, this release is all about supporting new CPython 2.6 features
such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes
(PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
version required for this release is the same as IronPython 2.0; namely .NET
2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we
get your feedback on the release(s) quickly to incorporate requested
changes.

Besides CPython 2.6 features, another significant change in this release is
that ipy.exe now uses "adaptive compilation" by default. Adaptive
compilation is a technique in which IronPython:

1. Interprets and executes Python method calls up to /N/ times for a given
method. If you're only going to execute a method a few times, it's typically
faster to interpret the method instead of compiling and executing it

2. Compiles and executes the Python method call on the /N+1/ invocation of
the method. Compilation of a Python method is a heavyweight operation, but
we can reuse the result for subsequent invocations

3. Reuses the previously compiled method for new calls to the Python method.
This operation is much faster than interpreting the method call as the
method was already compiled in the previous step

The reason for this change is that it provides a nice performance gain for
Python code containing lots of functions/methods that only get called a few
times. All this said, this feature is still undergoing active development
and as a consequence some Python scripts may actually run slower with it
turned on. For this reason, our old default mode of running Python scripts
is still available by passing the -O or -D flags to ipy.exe. Any feedback on
how this new feature affects your IronPython applications performance-wise
would be greatly appreciated.

There's also a few minor changes since IronPython 2.0.1 that are worth
calling out here:

. IronPython.msi now installs NGEN'ed binaries by default

. IronPython.msi now offers a little more selection with respect to what
you'd like to install. For example, Silverlight templates are optional

. The default installation location of IronPython.msi no longer indicates
whether the 2.6 release is an Alpha, Beta, or a patched release. Future
IronPython 2.6 installations will replace previous 2.6 releases which will
be uninstalled automatically

. The -X:PreferComInterop

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

Is there any updated timeline on this? Looking forward to it :-). I'm sure
you're swamped...if there is anything the community can do to speed this up
please let us know.
Thanks,
Adam

On Mon, Mar 30, 2009 at 4:44 PM, Jimmy Schementi <
jimmy.scheme...@microsoft.com> wrote:

>  A IronPython 2.6 version of the ASP.NET integration will be out shortly,
> I have to get time to make a build and get it sent over to the ASP.NETteam. 
> I’m working through some other things I need to get done first, but
> assume two weeks.
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Adam Brand
> *Sent:* Saturday, March 28, 2009 1:37 PM
>
> *To:* 'Discussion of IronPython'
> *Subject:* Re: [IronPython] Announcing IronPython 2.6 Alpha 1
>
>
>
> Any update on the timeline for getting IronPython for ASP.Net updated? This
> would make a world of difference for our IronPython-based web app.
>
>
>
> Adam
>
>
>
> Adam Brand
>
> SilverKey Technologies
>
>
>
> *From:* users-boun...@lists.ironpython.com [mailto:
> users-boun...@lists.ironpython.com] *On Behalf Of *Dody Gunawinata
> *Sent:* Saturday, March 28, 2009 1:09 PM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Announcing IronPython 2.6 Alpha 1
>
>
>
> This is awesome. Web application can benefit from this "adaptive
> compilation" approach a lot - especially for low trafficked sites.
>
> On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas <
> giles.tho...@resolversystems.com> wrote:
>
> Dave,
>
> This is great news, congratulations to the IP team on this release! We'll
> do a test-port of Resolver One early next week and will reply to the list
> with any issues we find.
>
>
> Cheers,
>
> Giles
>
>
> Dave Fugate wrote:
>
> Hello Python Community,
>
> We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you
> might imagine, this release is all about supporting new CPython 2.6 features
> such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes
> (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
> version required for this release is the same as IronPython 2.0; namely .NET
> 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
> only a couple Alphas and Betas of IronPython 2.6. As such, it’s key that we
> get your feedback on the release(s) quickly to incorporate requested
> changes.
>
> Besides CPython 2.6 features, another significant change in this release is
> that ipy.exe now uses “adaptive compilation” by default. Adaptive
> compilation is a technique in which IronPython:
>
> 1. Interprets and executes Python method calls up to /N/ times for a given
> method. If you’re only going to execute a method a few times, it’s typically
> faster to interpret the method instead of compiling and executing it
>
> 2. Compiles and executes the Python method call on the /N+1/ invocation of
> the method. Compilation of a Python method is a heavyweight operation, but
> we can reuse the result for subsequent invocations
>
> 3. Reuses the previously compiled method for new calls to the Python
> method. This operation is much faster than interpreting the method call as
> the method was already compiled in the previous step
>
> The reason for this change is that it provides a nice performance gain for
> Python code containing lots of functions/methods that only get called a few
> times. All this said, this feature is still undergoing active development
> and as a consequence some Python scripts may actually run slower with it
> turned on. For this reason, our old default mode of running Python scripts
> is still available by passing the –O or -D flags to ipy.exe. Any feedback on
> how this new feature affects your IronPython applications performance-wise
> would be greatly appreciated.
>
> There’s also a few minor changes since IronPython 2.0.1 that are worth
> calling out here:
>
> · IronPython.msi now installs NGEN’ed binaries by default
>
> · IronPython.msi now offers a little more selection with respect to what
> you’d like to install. For example, Silverlight templates are optional
>
> · The default installation location of IronPython.msi no longer indicates
> whether the 2.6 release is an Alpha, Beta, or a patched release. Future
> IronPython 2.6 installations will replace previous 2.6 releases which will
> be uninstalled automatically
>
> · The -X:PreferComInteropAssembly flag has been removed. All COM interop is
> now done through normal COM dispatch
>
> You can download IronPython 2.6 Alpha 1 at:
> http://ironpython.codeplex.com/Release/ProjectReleases.as

[IronPython] Main Utility of IronPython?

[Adam Brand]

What do you guys think people are using IronPython for, primarily?

 

Web Apps? WinForms? Admin scripting? 

 

There were over 20,000 searches for IronPython last month. In comparison,
IronRuby got 8,100.  ASP.Net MVC got practically no searches. Why all the
interest? What is the killer use case?

 

I would think web apps, but I don't think that's backed up by the usage of
IronPython for ASP.Net.

 

The primary reason we use it is for web apps, where we feel there are
productivity gains using IP for ASP.Net for front-end code and C# on the
backend. This use case, though, requires people to use two different
languages, which is a bit of a bar to raise where people mostly use C#.
There had better be significant productivity boosts using IP for that to
catch on.  

 

Thoughts on what IP's niche is and will be?

 

Adam

SilverKey Technologies

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

Re: [IronPython] IronPython in Action Out!

[Adam Brand]

Also done! Looking forward to it. 

You might not get rich, but you could make some good money :-).

1. There were around 18,000 searches for "ironpython" in March in Google,
another 2000 or so for related terms.
(https://adwords.google.com/select/KeywordToolExternal). 
2. Put up an Adwords campaign that takes people to a special landing page
explaining what the book has to offer, testimonials, and a link to buy
(promote the e-book pdf over the hard copy for instant gratification/better
margin). Something like:
http://www.perrymarshall.com/google/?gclid=CLPB_uKx6ZkCFcxL5QoduTpBPw but
less cheesy/hard sell for a cynical technical audience and a direct CTA to
buy.
3. Allow people to download some choice chapters for free from the landing
page in #2, delivered via email (and agreeing to "opt in").
4. Put the people in #3 on an "autoresponder" (chain) informative marketing
campaign where you send them choice pages and tips; one email per day for
five days, then one per week for four weeks, then one email per month until
they unsubscribe. Aweber.com is good and cheap for this.
5. Profit :-)

You should be able to get a good clickthrough rate with an ad that reads:
Line1: IronPython in Action
Line2: New Book with Rave Reviews
Line3: Download Your Free Chapter Now

...so assume a 10% CTR. On the landing page, you should be able to get a 10%
conversion rate between direct buys from the landing page (5%) and the chain
email marketing campaign (5%).

So 200 sales per month...if your average profit per book (ebook and regular)
is $10 then you could bring in $2000 per month or $24K per year. Maybe more
if you raise the price of the book ($39.99?).

/end free Internet marketing advice

Adam

Adam Brand
SilverKey Technologies


-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Alex News
Sent: Saturday, April 11, 2009 10:11 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython in Action Out!

>  Some proportion comes back - god knows no-one writes technical books to
get
> rich though! I do slightly better if you buy it through one of the links
on
> http://www.ironpythoninaction.com/

Done.  I look forward to reading it!

Alex


On 4/10/09, Michael Foord  wrote:
> David Seruyange wrote:
>
> > Congrats although I was able to get a copy early (about 2 weeks ago)
> directly from Manning. Paid full price, I hope that somehow trickles back
to
> you :)
> >
>
>  Some proportion comes back - god knows no-one writes technical books to
get
> rich though! I do slightly better if you buy it through one of the links
on
> http://www.ironpythoninaction.com/
>
>  It has been a long journey getting to this point, so at the moment all
that
> matters is people reading it - and hopefully finding it useful!
>
>  All the best,
>
>  Michael
>
>
> >
> > David
> >
> > On Fri, Apr 10, 2009 at 12:09 PM, Shri Borde  <mailto:shri.bo...@microsoft.com>> wrote:
> >
> >Congratulations! This is very exciting!
> >
> >-Original Message-
> >From: users-boun...@lists.ironpython.com
> ><mailto:users-boun...@lists.ironpython.com>
> >[mailto:users-boun...@lists.ironpython.com
> ><mailto:users-boun...@lists.ironpython.com>] On Behalf
> Of Michael
> >Foord
> >Sent: Friday, April 10, 2009 11:17 AM
> >To: Discussion of IronPython
> >Subject: [IronPython] IronPython in Action Out!
> >
> >Hello all,
> >
> >*Finally* IronPython in Action is out. This is the first English
> >language book on IronPython and is now in stock with Manning and
> >Amazon.com and on the Safari bookshelf. You can get all the
> >details from:
> >
> >* http://www.ironpythoninaction.com
> >
> >It covers a whole range of topics, with introductions to Python and
> >.NET, using various Python libraries and .NET framework classes, web
> >development with ASP.NET <http://ASP.NET>, Silverlight and web
> >services, plus topics like
> >WPF, testing, metaprogramming, system administration, embedding
> >IronPython in .NET applications and so on.
> >
> >The foreword is by Jim Hugunin and Dino Viehland is the technical
> >editor.
> >
> >Many thanks to all those who helped, including those who gave
feedback
> >during the early access program.
> >
> >All the best,
> >
> >Michael Foord
> >
> >--
> >http://www.ironpythoninaction.com/
> >http://www.voidspace.org.uk/blog
> >
> >
> >

Re: [IronPython] with_statement in IronPython for ASP.Net?

[Adam Brand]

Yeah this is a really weird issue; Jimmy mentioned he would look into it.
Will post back to the list when we find out what the deal was.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Thursday, April 09, 2009 2:00 PM
To: Discussion of IronPython
Subject: Re: [IronPython] with_statement in IronPython for ASP.Net?

 

IronPython 2 targets CPython 2.5 compatibility.  In 2.5, you need the
__future__ line in order to use the "with" statement.  It's quite possible
that this wasn't implemented yet in that alpha or beta of IronPython.

 

It's in 2.6 where you don't need the "from __future__ import
with_statement".

On Fri, Apr 3, 2009 at 12:01 PM, Adam Brand  wrote:

Using IronPython for ASP.Net, trying to use:

from __future__ import with_statement

 

...get the message:

future feature is not defined:with_statement

 

Have put the __future__.py file in the directory that py file is in as well
as my lib folder.

 

Any ideas? I saw some references to needing to put the switch -X:Python25,
but I think that was for earlier versions of IPY. AFAIK the IP for ASP.NET
<http://asp.net/>  is IronPython 2, Alpha 1...I'm thinking that one
shouldn't need the switch?

 

 

Thanks,

Adam



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

 

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

[IronPython] with_statement in IronPython for ASP.Net?

[Adam Brand]

Using IronPython for ASP.Net, trying to use:
from __future__ import with_statement

...get the message:
future feature is not defined:with_statement

Have put the __future__.py file in the directory that py file is in as well
as my lib folder.

Any ideas? I saw some references to needing to put the switch -X:Python25,
but I think that was for earlier versions of IPY. AFAIK the IP for
ASP.NETis IronPython 2, Alpha 1...I'm thinking that one shouldn't need
the switch?


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

[IronPython] Python In-Browser Code Editor

[Adam Brand]

Hey all,
We've been looking for an in-browser code editor to replace EditArea for
editing IP code in-browser...something faster/lighter. I found codemirror (
http://marijn.haverbeke.nl/codemirror/) and worked with another community
member (Timothy Farrell) to create a Python plugin for it (he did the work,
I did the prodding/testing :-)).

If anyone is interested in testing the IP implementations of Python in this
editor (for parsing and syntax highlighting), we'd love to incorporate
feedback and make this a very solid option for the IP community.

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

Re: [IronPython] try...finally in yield

[Adam Brand]

You can check out the files in question here:
<http://github.com/devhawk/devhawk_ipy/tree>
http://github.com/devhawk/devhawk_ipy/tree. ... those files are patched now
to use the below.which uses "with" to ensure the Dispose(). So the file is
closed after the lines in the file are read.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Sunday, March 29, 2009 6:27 PM
To: Discussion of IronPython
Subject: Re: [IronPython] try...finally in yield

 

Maybe I don't understand the problem you're having.  Can you describe it
with a little more detail?  When exactly do you want the file to be closed?

2009/3/29 Adam Brand 

We are using 2.0 beta I think as part of ipy for asp.net. I don't think
close() is implemented in that version. Am I wrong?

 

Harry (who made it) suggested this:

def _process(xr):


  while xr.Read():
xr.MoveToContent()
node = XmlNode(xr)
yield node
if xr.IsEmptyElement:

  node = XmlNode(xr, endElement=True)
  yield node

 

def load(xml):
  """generates an iterator over the XmlNodes in the stream of XML
represented by the xml argument"""
  if isinstance(xml, XmlReader):
for n in _process(xml): yield n
  else:
with XmlReader.Create(xml) as xr:
  for n in _process(xr): yield n

 

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Saturday, March 28, 2009 7:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] try...finally in yield

 

So I assume you're calling close() on the generator?  A try/finally around
the code in the generator can be used to catch the StopIteration exception
and force the dispose.  But even better, you could say "from __future__
import with_statement" at the top of your file and then say something like
this:

def parse(xml):
with XmlReader.Create(xml) as xr
while xr.Read():
[...]

We automatically do the right thing when using "with" and IDisposable, so
"with" effectively becomes like a C# "using" block.

2009/3/28 Adam Brand 

I'm using IronPython for ASP.Net...have some code (not mine,
http://devhawk.net/2008/05/07/Deserializing+XML+With+IronPython.aspx - Harry
Pierson's) that converts an xml file into an object. It has the below
function:

def parse(xml):
xr = XmlReader.Create(xml)
while xr.Read():
xr.MoveToContent()
node = XmlNode(xr)
yield node
if (xr.IsEmptyElement):
node.nodeType = XmlNodeType.EndElement
del node.attributes
yield node

This code is problematic as it locks the xml file it is reading. I tried a
try...finally to do a .Close() and .Dispose(), but the compiler was not
happy with that. Just putting .Close() and .Dispose() at the end doesn't
work.

In reading up, I found this:
http://docs.python.org/whatsnew/2.5.html#pep-342

"The addition of the close() method has one side effect that isn't obvious.
close() is called when a generator is garbage-collected, so this means the
generator's code gets one last chance to run before the generator is
destroyed. This last chance means that try...finally statements in
generators can now be guaranteed to work; the finally clause will now always
get a chance to run. The syntactic restriction that you couldn't mix yield
statements with a try...finally suite has therefore been removed. "

I'm guessing that this isn't implemented in the version of IronPython in IP
for ASP.Net.

Does anyone have any ideas on a workaround for the generator for this
version?

Thanks,
Adam

-- 
Adam Brand


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

 


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

 

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

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

Fantastic! If you need any help in testing, let us know of course J.

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jimmy Schementi
Sent: Monday, March 30, 2009 4:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

A IronPython 2.6 version of the ASP.NET integration will be out shortly, I
have to get time to make a build and get it sent over to the ASP.NET team.
I'm working through some other things I need to get done first, but assume
two weeks.

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Adam Brand
Sent: Saturday, March 28, 2009 1:37 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Any update on the timeline for getting IronPython for ASP.Net updated? This
would make a world of difference for our IronPython-based web app.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Saturday, March 28, 2009 1:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

This is awesome. Web application can benefit from this "adaptive
compilation" approach a lot - especially for low trafficked sites.

On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas
 wrote:

Dave,

This is great news, congratulations to the IP team on this release! We'll do
a test-port of Resolver One early next week and will reply to the list with
any issues we find.


Cheers,

Giles


Dave Fugate wrote:

Hello Python Community,

We're pleased to announce the release of IronPython 2.6 Alpha 1. As you
might imagine, this release is all about supporting new CPython 2.6 features
such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes
(PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
version required for this release is the same as IronPython 2.0; namely .NET
2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we
get your feedback on the release(s) quickly to incorporate requested
changes.

Besides CPython 2.6 features, another significant change in this release is
that ipy.exe now uses "adaptive compilation" by default. Adaptive
compilation is a technique in which IronPython:

1. Interprets and executes Python method calls up to /N/ times for a given
method. If you're only going to execute a method a few times, it's typically
faster to interpret the method instead of compiling and executing it

2. Compiles and executes the Python method call on the /N+1/ invocation of
the method. Compilation of a Python method is a heavyweight operation, but
we can reuse the result for subsequent invocations

3. Reuses the previously compiled method for new calls to the Python method.
This operation is much faster than interpreting the method call as the
method was already compiled in the previous step

The reason for this change is that it provides a nice performance gain for
Python code containing lots of functions/methods that only get called a few
times. All this said, this feature is still undergoing active development
and as a consequence some Python scripts may actually run slower with it
turned on. For this reason, our old default mode of running Python scripts
is still available by passing the -O or -D flags to ipy.exe. Any feedback on
how this new feature affects your IronPython applications performance-wise
would be greatly appreciated.

There's also a few minor changes since IronPython 2.0.1 that are worth
calling out here:

. IronPython.msi now installs NGEN'ed binaries by default

. IronPython.msi now offers a little more selection with respect to what
you'd like to install. For example, Silverlight templates are optional

. The default installation location of IronPython.msi no longer indicates
whether the 2.6 release is an Alpha, Beta, or a patched release. Future
IronPython 2.6 installations will replace previous 2.6 releases which will
be uninstalled automatically

. The -X:PreferComInteropAssembly flag has been removed. All COM interop is
now done through normal COM dispatch

You can download IronPython 2.6 Alpha 1 at:
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982 

The IronPython Team



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

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




-- 
nomadlife.org

Re: [IronPython] try...finally in yield

[Adam Brand]

We are using 2.0 beta I think as part of ipy for asp.net. I don't think
close() is implemented in that version. Am I wrong?

 

Harry (who made it) suggested this:

def _process(xr):
  while xr.Read():
xr.MoveToContent()
node = XmlNode(xr)
yield node
if xr.IsEmptyElement:
  node = XmlNode(xr, endElement=True)
  yield node

 

def load(xml):
  """generates an iterator over the XmlNodes in the stream of XML
represented by the xml argument"""
  if isinstance(xml, XmlReader):
for n in _process(xml): yield n
  else:
with XmlReader.Create(xml) as xr:
  for n in _process(xr): yield n

 

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Saturday, March 28, 2009 7:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] try...finally in yield

 

So I assume you're calling close() on the generator?  A try/finally around
the code in the generator can be used to catch the StopIteration exception
and force the dispose.  But even better, you could say "from __future__
import with_statement" at the top of your file and then say something like
this:

def parse(xml):
with XmlReader.Create(xml) as xr
while xr.Read():
[...]

We automatically do the right thing when using "with" and IDisposable, so
"with" effectively becomes like a C# "using" block.

2009/3/28 Adam Brand 

I'm using IronPython for ASP.Net...have some code (not mine,
http://devhawk.net/2008/05/07/Deserializing+XML+With+IronPython.aspx - Harry
Pierson's) that converts an xml file into an object. It has the below
function:

def parse(xml):
xr = XmlReader.Create(xml)
while xr.Read():
xr.MoveToContent()
node = XmlNode(xr)
yield node
if (xr.IsEmptyElement):
node.nodeType = XmlNodeType.EndElement
del node.attributes
yield node

This code is problematic as it locks the xml file it is reading. I tried a
try...finally to do a .Close() and .Dispose(), but the compiler was not
happy with that. Just putting .Close() and .Dispose() at the end doesn't
work.

In reading up, I found this:
http://docs.python.org/whatsnew/2.5.html#pep-342

"The addition of the close() method has one side effect that isn't obvious.
close() is called when a generator is garbage-collected, so this means the
generator's code gets one last chance to run before the generator is
destroyed. This last chance means that try...finally statements in
generators can now be guaranteed to work; the finally clause will now always
get a chance to run. The syntactic restriction that you couldn't mix yield
statements with a try...finally suite has therefore been removed. "

I'm guessing that this isn't implemented in the version of IronPython in IP
for ASP.Net.

Does anyone have any ideas on a workaround for the generator for this
version?

Thanks,
Adam

-- 
Adam Brand


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

 

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

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

I think that was directed at Dody.but now that you mention it, I'm sure
there would be more adopters if there was more momentum behind ipy for
asp.net rather than just ipy with intellisense. I suspect more people are
developing web apps than not.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Howland-Rose, Kyle
Sent: Sunday, March 29, 2009 3:20 PM
To: d...@nomadlife.org; Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

Hi Adam,

 

About "intellisense is not a major blocker for iron python adoption".

 

Unfortunately I think it might be.  The commercial world is all about
productivity.  I did a survey at work about replacing a well-known
development environment with eclipse and the result was "our only real
requirement is intellisense".

 

Cheers,

Kyle

 

  _  

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Monday, 30 March 2009 6:57 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

I think the fact that there are more users for "Assembly for Web Pages" and
"AJAX on ALGOL" than IronPython for ASP.Net contributes to the delay in
updates. It's too bad for us that got addicted to the elegance of the
solution in the first place. I remember a couple of months ago about updated
support for intellisense in IP for ASP.Net, etc. Those are nice to have but
I think an updated IP would be enough to make everybody involved ecstatic. I
got a feeling intellisense is not a major blocker for iron python adoption.

 

2009/3/28 Adam Brand 

Any update on the timeline for getting IronPython for ASP.Net updated? This
would make a world of difference for our IronPython-based web app.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Saturday, March 28, 2009 1:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

This is awesome. Web application can benefit from this "adaptive
compilation" approach a lot - especially for low trafficked sites.

On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas
 wrote:

Dave,

This is great news, congratulations to the IP team on this release! We'll do
a test-port of Resolver One early next week and will reply to the list with
any issues we find.


Cheers,

Giles


Dave Fugate wrote:

Hello Python Community,

We're pleased to announce the release of IronPython 2.6 Alpha 1. As you
might imagine, this release is all about supporting new CPython 2.6 features
such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes
(PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
version required for this release is the same as IronPython 2.0; namely .NET
2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we
get your feedback on the release(s) quickly to incorporate requested
changes.

Besides CPython 2.6 features, another significant change in this release is
that ipy.exe now uses "adaptive compilation" by default. Adaptive
compilation is a technique in which IronPython:

1. Interprets and executes Python method calls up to /N/ times for a given
method. If you're only going to execute a method a few times, it's typically
faster to interpret the method instead of compiling and executing it

2. Compiles and executes the Python method call on the /N+1/ invocation of
the method. Compilation of a Python method is a heavyweight operation, but
we can reuse the result for subsequent invocations

3. Reuses the previously compiled method for new calls to the Python method.
This operation is much faster than interpreting the method call as the
method was already compiled in the previous step

The reason for this change is that it provides a nice performance gain for
Python code containing lots of functions/methods that only get called a few
times. All this said, this feature is still undergoing active development
and as a consequence some Python scripts may actually run slower with it
turned on. For this reason, our old default mode of running Python scripts
is still available by passing the -O or -D flags to ipy.exe. Any feedback on
how this new feature affects your IronPython applications performance-wise
would be greatly appreciated.

There's also a few minor changes since IronPython 2.0.1 that are worth
calling out here:

. IronPython.msi now installs NGEN'ed binaries by default

. IronPython.msi now offers a little more selection with respect to what
you'd like to install. For example, Silverlight templates are optional

. The d

[IronPython] try...finally in yield

[Adam Brand]

I'm using IronPython for ASP.Net...have some code (not mine,
http://devhawk.net/2008/05/07/Deserializing+XML+With+IronPython.aspx - Harry
Pierson's) that converts an xml file into an object. It has the below
function:

def parse(xml):
xr = XmlReader.Create(xml)
while xr.Read():
xr.MoveToContent()
node = XmlNode(xr)
yield node
if (xr.IsEmptyElement):
node.nodeType = XmlNodeType.EndElement
del node.attributes
yield node

This code is problematic as it locks the xml file it is reading. I tried a
try...finally to do a .Close() and .Dispose(), but the compiler was not
happy with that. Just putting .Close() and .Dispose() at the end doesn't
work.

In reading up, I found this:
http://docs.python.org/whatsnew/2.5.html#pep-342

"The addition of the close() method has one side effect that isn’t obvious.
close() is called when a generator is garbage-collected, so this means the
generator’s code gets one last chance to run before the generator is
destroyed. This last chance means that try...finally statements in
generators can now be guaranteed to work; the finally clause will now always
get a chance to run. The syntactic restriction that you couldn’t mix yield
statements with a try...finally suite has therefore been removed. "

I'm guessing that this isn't implemented in the version of IronPython in IP
for ASP.Net.

Does anyone have any ideas on a workaround for the generator for this
version?

Thanks,
Adam

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

Re: [IronPython] Announcing IronPython 2.6 Alpha 1

[Adam Brand]

Any update on the timeline for getting IronPython for ASP.Net updated? This
would make a world of difference for our IronPython-based web app.

 

Adam

 

Adam Brand

SilverKey Technologies

 

From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Saturday, March 28, 2009 1:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.6 Alpha 1

 

This is awesome. Web application can benefit from this "adaptive
compilation" approach a lot - especially for low trafficked sites.

On Thu, Mar 26, 2009 at 11:08 PM, Giles Thomas
 wrote:

Dave,

This is great news, congratulations to the IP team on this release! We'll do
a test-port of Resolver One early next week and will reply to the list with
any issues we find.


Cheers,

Giles


Dave Fugate wrote:

Hello Python Community,

We're pleased to announce the release of IronPython 2.6 Alpha 1. As you
might imagine, this release is all about supporting new CPython 2.6 features
such as the 'bytes' and 'bytearray' types (PEP 3112), decorators for classes
(PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET
version required for this release is the same as IronPython 2.0; namely .NET
2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release
only a couple Alphas and Betas of IronPython 2.6. As such, it's key that we
get your feedback on the release(s) quickly to incorporate requested
changes.

Besides CPython 2.6 features, another significant change in this release is
that ipy.exe now uses "adaptive compilation" by default. Adaptive
compilation is a technique in which IronPython:

1. Interprets and executes Python method calls up to /N/ times for a given
method. If you're only going to execute a method a few times, it's typically
faster to interpret the method instead of compiling and executing it

2. Compiles and executes the Python method call on the /N+1/ invocation of
the method. Compilation of a Python method is a heavyweight operation, but
we can reuse the result for subsequent invocations

3. Reuses the previously compiled method for new calls to the Python method.
This operation is much faster than interpreting the method call as the
method was already compiled in the previous step

The reason for this change is that it provides a nice performance gain for
Python code containing lots of functions/methods that only get called a few
times. All this said, this feature is still undergoing active development
and as a consequence some Python scripts may actually run slower with it
turned on. For this reason, our old default mode of running Python scripts
is still available by passing the -O or -D flags to ipy.exe. Any feedback on
how this new feature affects your IronPython applications performance-wise
would be greatly appreciated.

There's also a few minor changes since IronPython 2.0.1 that are worth
calling out here:

. IronPython.msi now installs NGEN'ed binaries by default

. IronPython.msi now offers a little more selection with respect to what
you'd like to install. For example, Silverlight templates are optional

. The default installation location of IronPython.msi no longer indicates
whether the 2.6 release is an Alpha, Beta, or a patched release. Future
IronPython 2.6 installations will replace previous 2.6 releases which will
be uninstalled automatically

. The -X:PreferComInteropAssembly flag has been removed. All COM interop is
now done through normal COM dispatch

You can download IronPython 2.6 Alpha 1 at:
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982 

The IronPython Team



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

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




-- 
nomadlife.org

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