Re: [IronPython] IronPython for ASP.Net

2009-05-25 Thread Dody Gunawinata
So is there any new timeline for this right now or is it in the beats me
territory?
Dody G.

On Sun, May 24, 2009 at 4:05 PM, Dody Gunawinata empirebuil...@gmail.comwrote:

 Bummer. Thanks for the info.


 On Sun, May 24, 2009 at 3:43 PM, Curt Hagenlocher c...@hagenlocher.orgwrote:

 Judging by the last internal email I saw about this on Friday, I'd guess
 not... :(


 On Sun, May 24, 2009 at 5:25 AM, Dody Gunawinata empirebuil...@gmail.com
  wrote:

 Is there any chance for this to come up today? I know it's weekend and
 the summer.

 On Fri, May 22, 2009 at 10:21 PM, Jimmy Schementi 
 jimmy.scheme...@microsoft.com wrote:

 Woops, I meant 2.6.



 *From:* users-boun...@lists.ironpython.com [mailto:
 users-boun...@lists.ironpython.com] *On Behalf Of *Dody Gunawinata
 *Sent:* Friday, May 22, 2009 11:39 AM
 *To:* Discussion of IronPython

 *Subject:* Re: [IronPython] IronPython for ASP.Net



 IronPython 2 Beta 1 ?

 On Fri, May 22, 2009 at 1:11 AM, Jimmy Schementi 
 jimmy.scheme...@microsoft.com wrote:

 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 
 jimmy.scheme...@microsoft.com 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/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 

Re: [IronPython] IronPython for ASP.Net

2009-05-25 Thread Jimmy Schementi
The Dynamic Language Support page on the ASP.NET Codeplex site 
(http://aspnet.codeplex.com) will be updated with a IronPython 2.6 Beta 1 
compatible version this week; once the ASP.NET updates things I'll let you know.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Monday, May 25, 2009 7:36 AM
To: Curt Hagenlocher
Cc: Discussion of IronPython
Subject: Re: [IronPython] IronPython for ASP.Net

So is there any new timeline for this right now or is it in the beats me 
territory?

Dody G.
On Sun, May 24, 2009 at 4:05 PM, Dody Gunawinata 
empirebuil...@gmail.commailto:empirebuil...@gmail.com wrote:
Bummer. Thanks for the info.

On Sun, May 24, 2009 at 3:43 PM, Curt Hagenlocher 
c...@hagenlocher.orgmailto:c...@hagenlocher.org wrote:
Judging by the last internal email I saw about this on Friday, I'd guess not... 
:(

On Sun, May 24, 2009 at 5:25 AM, Dody Gunawinata 
empirebuil...@gmail.commailto:empirebuil...@gmail.com wrote:
Is there any chance for this to come up today? I know it's weekend and the 
summer.
On Fri, May 22, 2009 at 10:21 PM, Jimmy Schementi 
jimmy.scheme...@microsoft.commailto:jimmy.scheme...@microsoft.com wrote:

Woops, I meant 2.6.



From: 
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
 On Behalf Of Dody Gunawinata
Sent: Friday, May 22, 2009 11:39 AM
To: Discussion of IronPython

Subject: Re: [IronPython] IronPython for ASP.Net



IronPython 2 Beta 1 ?

On Fri, May 22, 2009 at 1:11 AM, Jimmy Schementi 
jimmy.scheme...@microsoft.commailto:jimmy.scheme...@microsoft.com wrote:

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.NEThttp://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.NEThttp://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.commailto: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 

[IronPython] IPython is breathing but there's a compile() problem

2009-05-25 Thread Mike Krell
Now that 2.6B1 has frames support, I've started playing with IronPython
under IPython again.  I've managed to get a command prompt up (some modules
are missing, but the only crucial one is codeop, which I stole from the
standard distribution).

However, there's a problem with entering multiline code snippets
interactively.  With CPython, this looks like:

In [21]: if 1:
  :  if 1:
  :

(The indentation looks wrong without a fixed-width font, but you get the
idea.)

With IronPython, the second if 1: line blows up with a syntax error.  This
boils down to a difference in the way the compile() builtin works as used by
the codeop module.

I've written this up as a bug at codeplex.  Please vote for the bug here:

http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22692

It would be awesome if we could have a good IronPython + IPython story
before 2.6 is released!

Below are more details about the problem as described in the bug
description.

   Mike



bug description at codeplex follows

compile() behaves differently than in CPython in the presence of incomplete
multiline code snippets.  Fixing this incompatiblity is necessary for
running IronPython under IPython.

Here is a sample program illustrating the problem.  The program is a
modification of the code used in the standard codeop module by IPython to
determine when to provide a continuation prompt for a multiline snippet.



def testcompile(source, flags):

err = err1 = err2 = None
code = code1 = code2 = None

try:
code = compile(source, dummy, single, flags, 1)
except SyntaxError, err:
pass

try:
code1 = compile(source + \n, dummy, single, flags, 1)
except SyntaxError, err1:
pass

try:
code2 = compile(source + \n\n, dummy, single, flags, 1)
except SyntaxError, err2:
pass

print for source = '%s' and flags = %d % (source, flags),

if code:
print Syntax valid
elif not code1 and repr(err1) == repr(err2):
print Syntax error!
print
print err1:, repr(err1)
print err2:, repr(err2)
else:
print Continue on next line
print
print err1:, repr(err1)
print err2:, repr(err2)

print

# 0x200 is PyCF_DONT_IMPLY_DEDENT

testcompile(if 1:, 0x200)
testcompile(if 1:, 0)

testcompile(if 1:\n  if 1:, 0x200)
testcompile(if 1:\n  if 1:, 0)



Under CPython (2.6.1) the output is:



for source = 'if 1:' and flags = 512 Continue on next line

err1: SyntaxError('unexpected EOF while parsing', ('dummy', 1, 6, 'if
1:\n'))
err2: IndentationError('expected an indented block', ('dummy', 2, 1, '\n'))

for source = 'if 1:' and flags = 0 Continue on next line

err1: SyntaxError('unexpected EOF while parsing', ('dummy', 1, 6, 'if
1:\n'))
err2: IndentationError('expected an indented block', ('dummy', 2, 1, '\n'))

for source = 'if 1:
  if 1:' and flags = 512 Continue on next line

err1: IndentationError('expected an indented block', ('dummy', 2, 8, '  if
1:\n'))
err2: IndentationError('expected an indented block', ('dummy', 3, 1, '\n'))

for source = 'if 1:
  if 1:' and flags = 0 Continue on next line

err1: IndentationError('expected an indented block', ('dummy', 2, 8, '  if
1:\n'))
err2: IndentationError('expected an indented block', ('dummy', 3, 1, '\n'))




In all cases the code correctly outputs Continue on next line since both
snippets are incomplete but otherwise valid python.

For IronPython 2.6 Beta 1 the output is:



for source = 'if 1:' and flags = 512 Continue on next line

err1: IndentationError(unexpected token 'eof', ('dummy', 2, 1, ''))
err2: IndentationError(unexpected token 'eof', ('dummy', 3, 1, ''))

for source = 'if 1:' and flags = 0 Continue on next line

err1: IndentationError(unexpected token 'eof', ('dummy', 2, 1, ''))
err2: IndentationError(unexpected token 'eof', ('dummy', 3, 1, ''))

for source = 'if 1:
  if 1:' and flags = 512 Syntax error!

err1: IndentationError(unexpected token 'eof', ('dummy', 2, 8, '  if
1:\n'))
err2: IndentationError(unexpected token 'eof', ('dummy', 2, 8, '  if
1:\n'))

for source = 'if 1:
  if 1:' and flags = 0 Syntax error!

err1: IndentationError(unexpected token 'eof', ('dummy', 2, 8, '  if
1:\n'))
err2: IndentationError(unexpected token 'eof', ('dummy', 2, 8, '  if
1:\n'))



The second snippet is misinterpreted as being a syntax error instead of
merely incomplete.

This is very similar to the