Re: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s

[Thomas Gagne]

Hurray!  The Path is now working! Thanks for your help.


___
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]

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.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
>

Re: [IronPython] InteractiveCode and function definitions

[Michael Foord]

Curt Hagenlocher wrote:
What I've done is to test explicitly for the blank line at the end in 
conjuction with the test for ScriptCodeParseResult.IncompleteStatement:
 
completeThought = (result == ScriptCodeParseResult.Complete or

result == ScriptCodeParseResult.Invalid or
(result == ScriptCodeParseResult.IncompleteStatement and 
text.endswith('\n\n')))


Thanks guys - I've got a working implementation that seems to handle all 
the cases we need. Nice one.


Michael


On Thu, Apr 16, 2009 at 10:54 AM, Michael Foord 
mailto:fuzzy...@voidspace.org.uk>> wrote:


Curt Hagenlocher wrote:

That's only because you've decided to arbitrarily[*] define
"\n\n" as being a signal to mean "complete".  That's not part
of the actual language specification.

It's the behaviour of the interactive interpreter though - which
specifies something. It's also the specification adhered to by the
code module for implementing interactive interpreters.


In fact, if I append "\n\n  print 2\n\n" to that string, it's
still a valid Python program.  The key here is that "the user
has entered a complete thought" is a property of the
interpreter and not of the language.  I might well decide that
the "commit" key sequence is Control+E (as it is in SQL Server
Management Studio) instead of "enter enter".
 My point is that it's not correct for IronPython to dictate
the semantics of your interpreter.


Fine, so do you have any suggestions as to how to replicate the
behaviour of the interactive interpreter - whether or not it
counts as a specification?

Michael

 [*] Okay, "arbitrary" is a bit strong in that it's what
python.exe and ipy.exe defines. :)

On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord
mailto:fuzzy...@voidspace.org.uk>
>> wrote:

   Curt Hagenlocher wrote:

   "IncompleteStatement" means that the user is allowed to
type
   more code.  If you want to know whether or not it's a valid
   (complete) string, just check for it not being Invalid.  A
   function definition is never "complete" in Python because
   there's never a terminating curly brace :).


   But that isn't sufficient to implement an interactive
interpreter
   on top of. This code conceptually is complete as far as an
   interactive interpreter is concerned:


 'def f():\n  print 1\n\n'

   It also means you can't distinguish between the previous
kind of
   incomplete (which is incomplete because the user *could*
type more
   code) and this kind of incomplete:

 'a = """'

   or:

 'a = (1 + 2 +'

   Which are both incomplete because the user *must* type more
code.
   (Although the latter two give IncompleteToken - I wonder if
that
   would be enough.)

   Because of the other IronPython bugs we can't use the code
module
   and ScriptSource / ScriptParseResult doesn't give sufficient
   information. Any other ideas?

   Michael


   On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord
   mailto:fuzzy...@voidspace.org.uk>
>
   
   >> import clr
  >>> clr.AddReference('IronPyth

Re: [IronPython] InteractiveCode and function definitions

[Curt Hagenlocher]

What I've done is to test explicitly for the blank line at the end in
conjuction with the test for ScriptCodeParseResult.IncompleteStatement:

completeThought = (result == ScriptCodeParseResult.Complete or
result == ScriptCodeParseResult.Invalid or
(result == ScriptCodeParseResult.IncompleteStatement and
text.endswith('\n\n')))

On Thu, Apr 16, 2009 at 10:54 AM, Michael Foord
wrote:

> Curt Hagenlocher wrote:
>
>> That's only because you've decided to arbitrarily[*] define "\n\n" as
>> being a signal to mean "complete".  That's not part of the actual language
>> specification.
>>
> It's the behaviour of the interactive interpreter though - which specifies
> something. It's also the specification adhered to by the code module for
> implementing interactive interpreters.
>
> In fact, if I append "\n\n  print 2\n\n" to that string, it's still a valid
>> Python program.  The key here is that "the user has entered a complete
>> thought" is a property of the interpreter and not of the language.  I might
>> well decide that the "commit" key sequence is Control+E (as it is in SQL
>> Server Management Studio) instead of "enter enter".
>>  My point is that it's not correct for IronPython to dictate the semantics
>> of your interpreter.
>>
>
> Fine, so do you have any suggestions as to how to replicate the behaviour
> of the interactive interpreter - whether or not it counts as a
> specification?
>
> Michael
>
>   [*] Okay, "arbitrary" is a bit strong in that it's what python.exe and
>> ipy.exe defines. :)
>>
>>  On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord <
>> fuzzy...@voidspace.org.uk > wrote:
>>
>>Curt Hagenlocher wrote:
>>
>>"IncompleteStatement" means that the user is allowed to type
>>more code.  If you want to know whether or not it's a valid
>>(complete) string, just check for it not being Invalid.  A
>>function definition is never "complete" in Python because
>>there's never a terminating curly brace :).
>>
>>
>>But that isn't sufficient to implement an interactive interpreter
>>on top of. This code conceptually is complete as far as an
>>interactive interpreter is concerned:
>>
>>
>>  'def f():\n  print 1\n\n'
>>
>>It also means you can't distinguish between the previous kind of
>>incomplete (which is incomplete because the user *could* type more
>>code) and this kind of incomplete:
>>
>>  'a = """'
>>
>>or:
>>
>>  'a = (1 + 2 +'
>>
>>Which are both incomplete because the user *must* type more code.
>>(Although the latter two give IncompleteToken - I wonder if that
>>would be enough.)
>>
>>Because of the other IronPython bugs we can't use the code module
>>and ScriptSource / ScriptParseResult doesn't give sufficient
>>information. Any other ideas?
>>
>>Michael
>>
>>
>>On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord
>>mailto:fuzzy...@voidspace.org.uk>
>>>>> wrote:
>>
>>   Hello guys,
>>
>>   We're trying to detect whether a section of code is
>>complete (to
>>   mimic the behaviour of the interactive interpreter).
>>
>>   First of all we tried using the Python standard library code
>>   module which provides interactive console classes. There
>>are two
>>   outstanding bugs on codeplex (one reported by me today) which
>>   prevent this being an ideal solution:
>>
>>
>> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064
>>
>> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881
>>
>>   The second approach was to create a ScriptSource and looking at
>>   the code properties to tell if the statement is complete or not
>>   (using IronPython 2.0.1). However we can never get it to
>>return a
>>   ScriptParseResult.Complete for function definitions. Code below
>>   shows using \n for newlines but we have also tried with \r\n.
>>
>>   >>> import clr
>>   >>> clr.AddReference('IronPython')
>>   >>> clr.AddReference('Microsoft.Scripting')
>>   >>> from IronPython.Hosting import Python
>>   >>> from Microsoft.Scripting import SourceCodeKind,
>>   ScriptCodeParseResult
>>   >>>
>>   >>> engine = Python.CreateEngine()
>>   >>> s = engine.CreateScriptSourceFromString('def f():\n  print
>>   1\n', 'foo', SourceCodeKind.InteractiveCode)
>>   >>> s.GetCodeProperties()
>>   >   0x003F [IncompleteStatement]>
>>   >>> s = engine.CreateScriptSourceFromString('def f():\n  print
>>   1\n\n', 'foo', SourceCodeKind.InteractiveCode)
>>   >>> s.GetCodeProperties()
>>   >   0x0040 [IncompleteStatement]>
>>   >>>
>>
>>   The DLR hosting spec has little h

Re: [IronPython] InteractiveCode and function definitions

[Dino Viehland]

I suggest explicitly checking for the final blank line.  That's what our 
command line does.

> -Original Message-
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Thursday, April 16, 2009 10:55 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] InteractiveCode and function definitions
> 
> Curt Hagenlocher wrote:
> > That's only because you've decided to arbitrarily[*] define "\n\n" as
> > being a signal to mean "complete".  That's not part of the actual
> > language specification.
> It's the behaviour of the interactive interpreter though - which
> specifies something. It's also the specification adhered to by the code
> module for implementing interactive interpreters.
> 
> > In fact, if I append "\n\n  print 2\n\n" to that string, it's still a
> > valid Python program.  The key here is that "the user has entered a
> > complete thought" is a property of the interpreter and not of the
> > language.  I might well decide that the "commit" key sequence is
> > Control+E (as it is in SQL Server Management Studio) instead of
> "enter
> > enter".
> >
> > My point is that it's not correct for IronPython to dictate the
> > semantics of your interpreter.
> 
> Fine, so do you have any suggestions as to how to replicate the
> behaviour of the interactive interpreter - whether or not it counts as
> a
> specification?
> 
> Michael
> 
> >
> > [*] Okay, "arbitrary" is a bit strong in that it's what python.exe
> and
> > ipy.exe defines. :)
> >
> > On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord
> > mailto:fuzzy...@voidspace.org.uk>> wrote:
> >
> > Curt Hagenlocher wrote:
> >
> > "IncompleteStatement" means that the user is allowed to type
> > more code.  If you want to know whether or not it's a valid
> > (complete) string, just check for it not being Invalid.  A
> > function definition is never "complete" in Python because
> > there's never a terminating curly brace :).
> >
> >
> > But that isn't sufficient to implement an interactive interpreter
> > on top of. This code conceptually is complete as far as an
> > interactive interpreter is concerned:
> >
> >
> >   'def f():\n  print 1\n\n'
> >
> > It also means you can't distinguish between the previous kind of
> > incomplete (which is incomplete because the user *could* type
> more
> > code) and this kind of incomplete:
> >
> >   'a = """'
> >
> > or:
> >
> >   'a = (1 + 2 +'
> >
> > Which are both incomplete because the user *must* type more code.
> > (Although the latter two give IncompleteToken - I wonder if that
> > would be enough.)
> >
> > Because of the other IronPython bugs we can't use the code module
> > and ScriptSource / ScriptParseResult doesn't give sufficient
> > information. Any other ideas?
> >
> > Michael
> >
> >
> > On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord
> > mailto:fuzzy...@voidspace.org.uk>
> >  > >> wrote:
> >
> >Hello guys,
> >
> >We're trying to detect whether a section of code is
> > complete (to
> >mimic the behaviour of the interactive interpreter).
> >
> >First of all we tried using the Python standard library
> code
> >module which provides interactive console classes. There
> > are two
> >outstanding bugs on codeplex (one reported by me today)
> which
> >prevent this being an ideal solution:
> >
> >
> >
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064
> >
> >
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881
> >
> >The second approach was to create a ScriptSource and
> looking at
> >the code properties to tell if the statement is complete
> or not
> >(using IronPython 2.0.1). However we can never get it to
> > return a
> >ScriptParseResult.Complete for function definitions. Code
> below
> >shows using \n for newlines but we have also tried with
> \r\n.
> >
> >>>> import clr
> >>>> clr.AddReference('IronPython')
> >>>> clr.AddReference('Microsoft.Scripting')
> >>>> from IronPython.Hosting import Python
> >>>> from Microsoft.Scripting import SourceCodeKind,
> >ScriptCodeParseResult
> >>>>
> >>>> engine = Python.CreateEngine()
> >>>> s = engine.CreateScriptSourceFromString('def f():\n
> print
> >1\n', 'foo', SourceCodeKind.InteractiveCode)
> >>>> s.GetCodeProperties()
> > >0x003F [IncompleteStatement]>
> >>>> s = engine.CreateScriptSourceFromString('def f():\n
> print
> >1\n\n', 'foo', SourceCodeKind.InteractiveCode)
> >>>> s.GetC

Re: [IronPython] InteractiveCode and function definitions

[Michael Foord]

Curt Hagenlocher wrote:
That's only because you've decided to arbitrarily[*] define "\n\n" as 
being a signal to mean "complete".  That's not part of the actual 
language specification.
It's the behaviour of the interactive interpreter though - which 
specifies something. It's also the specification adhered to by the code 
module for implementing interactive interpreters.


In fact, if I append "\n\n  print 2\n\n" to that string, it's still a 
valid Python program.  The key here is that "the user has entered a 
complete thought" is a property of the interpreter and not of the 
language.  I might well decide that the "commit" key sequence is 
Control+E (as it is in SQL Server Management Studio) instead of "enter 
enter".
 
My point is that it's not correct for IronPython to dictate the 
semantics of your interpreter.


Fine, so do you have any suggestions as to how to replicate the 
behaviour of the interactive interpreter - whether or not it counts as a 
specification?


Michael

 
[*] Okay, "arbitrary" is a bit strong in that it's what python.exe and 
ipy.exe defines. :)


On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord 
mailto:fuzzy...@voidspace.org.uk>> wrote:


Curt Hagenlocher wrote:

"IncompleteStatement" means that the user is allowed to type
more code.  If you want to know whether or not it's a valid
(complete) string, just check for it not being Invalid.  A
function definition is never "complete" in Python because
there's never a terminating curly brace :).


But that isn't sufficient to implement an interactive interpreter
on top of. This code conceptually is complete as far as an
interactive interpreter is concerned:


  'def f():\n  print 1\n\n'

It also means you can't distinguish between the previous kind of
incomplete (which is incomplete because the user *could* type more
code) and this kind of incomplete:

  'a = """'

or:

  'a = (1 + 2 +'

Which are both incomplete because the user *must* type more code.
(Although the latter two give IncompleteToken - I wonder if that
would be enough.)

Because of the other IronPython bugs we can't use the code module
and ScriptSource / ScriptParseResult doesn't give sufficient
information. Any other ideas?

Michael


On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord
mailto:fuzzy...@voidspace.org.uk>
>> wrote:

   Hello guys,

   We're trying to detect whether a section of code is
complete (to
   mimic the behaviour of the interactive interpreter).

   First of all we tried using the Python standard library code
   module which provides interactive console classes. There
are two
   outstanding bugs on codeplex (one reported by me today) which
   prevent this being an ideal solution:

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


   The second approach was to create a ScriptSource and looking at
   the code properties to tell if the statement is complete or not
   (using IronPython 2.0.1). However we can never get it to
return a
   ScriptParseResult.Complete for function definitions. Code below
   shows using \n for newlines but we have also tried with \r\n.

   >>> import clr
   >>> clr.AddReference('IronPython')
   >>> clr.AddReference('Microsoft.Scripting')
   >>> from IronPython.Hosting import Python
   >>> from Microsoft.Scripting import SourceCodeKind,
   ScriptCodeParseResult
   >>>
   >>> engine = Python.CreateEngine()
   >>> s = engine.CreateScriptSourceFromString('def f():\n  print
   1\n', 'foo', SourceCodeKind.InteractiveCode)
   >>> s.GetCodeProperties()
   
   >>> s = engine.CreateScriptSourceFromString('def f():\n  print
   1\n\n', 'foo', SourceCodeKind.InteractiveCode)
   >>> s.GetCodeProperties()
   
   >>>

   The DLR hosting spec has little helpful to say on the matter as
   far as I can tell.

   Looking at an example from Tomas it doesn't seem very different
   from what we're doing:

   http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/

   Any clues as to what we are doing wrong or how to procede?

   Thanks

   Michael

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


   ___
   Users mailing list
   Users@lists.ironpython.com

>

Re: [IronPython] InteractiveCode and function definitions

[Curt Hagenlocher]

That's only because you've decided to arbitrarily[*] define "\n\n" as being
a signal to mean "complete".  That's not part of the actual language
specification.  In fact, if I append "\n\n  print 2\n\n" to that string,
it's still a valid Python program.  The key here is that "the user has
entered a complete thought" is a property of the interpreter and not of the
language.  I might well decide that the "commit" key sequence is Control+E
(as it is in SQL Server Management Studio) instead of "enter enter".

My point is that it's not correct for IronPython to dictate the semantics of
your interpreter.

[*] Okay, "arbitrary" is a bit strong in that it's what python.exe and
ipy.exe defines. :)

On Thu, Apr 16, 2009 at 10:36 AM, Michael Foord
wrote:

> Curt Hagenlocher wrote:
>
>> "IncompleteStatement" means that the user is allowed to type more code.
>>  If you want to know whether or not it's a valid (complete) string, just
>> check for it not being Invalid.  A function definition is never "complete"
>> in Python because there's never a terminating curly brace :).
>>
>
> But that isn't sufficient to implement an interactive interpreter on top
> of. This code conceptually is complete as far as an interactive interpreter
> is concerned:
>
>   'def f():\n  print 1\n\n'
>
> It also means you can't distinguish between the previous kind of incomplete
> (which is incomplete because the user *could* type more code) and this kind
> of incomplete:
>
>   'a = """'
>
> or:
>
>   'a = (1 + 2 +'
>
> Which are both incomplete because the user *must* type more code. (Although
> the latter two give IncompleteToken - I wonder if that would be enough.)
>
> Because of the other IronPython bugs we can't use the code module and
> ScriptSource / ScriptParseResult doesn't give sufficient information. Any
> other ideas?
>
> Michael
>
>
>> On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord <
>> fuzzy...@voidspace.org.uk > wrote:
>>
>>Hello guys,
>>
>>We're trying to detect whether a section of code is complete (to
>>mimic the behaviour of the interactive interpreter).
>>
>>First of all we tried using the Python standard library code
>>module which provides interactive console classes. There are two
>>outstanding bugs on codeplex (one reported by me today) which
>>prevent this being an ideal solution:
>>
>>http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064
>>http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881
>>
>>The second approach was to create a ScriptSource and looking at
>>the code properties to tell if the statement is complete or not
>>(using IronPython 2.0.1). However we can never get it to return a
>>ScriptParseResult.Complete for function definitions. Code below
>>shows using \n for newlines but we have also tried with \r\n.
>>
>>>>> import clr
>>>>> clr.AddReference('IronPython')
>>>>> clr.AddReference('Microsoft.Scripting')
>>>>> from IronPython.Hosting import Python
>>>>> from Microsoft.Scripting import SourceCodeKind,
>>ScriptCodeParseResult
>>>>>
>>>>> engine = Python.CreateEngine()
>>>>> s = engine.CreateScriptSourceFromString('def f():\n  print
>>1\n', 'foo', SourceCodeKind.InteractiveCode)
>>>>> s.GetCodeProperties()
>>>0x003F [IncompleteStatement]>
>>>>> s = engine.CreateScriptSourceFromString('def f():\n  print
>>1\n\n', 'foo', SourceCodeKind.InteractiveCode)
>>>>> s.GetCodeProperties()
>>>0x0040 [IncompleteStatement]>
>>>>>
>>
>>The DLR hosting spec has little helpful to say on the matter as
>>far as I can tell.
>>
>>Looking at an example from Tomas it doesn't seem very different
>>from what we're doing:
>>
>>http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/
>>
>>Any clues as to what we are doing wrong or how to procede?
>>
>>Thanks
>>
>>Michael
>>
>>--http://www.ironpythoninaction.com/
>>http://www.voidspace.org.uk/blog
>>
>>
>>___
>>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
>>
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> ___
> 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] InteractiveCode and function definitions

[Michael Foord]

Curt Hagenlocher wrote:
"IncompleteStatement" means that the user is allowed to type more 
code.  If you want to know whether or not it's a valid (complete) 
string, just check for it not being Invalid.  A function definition is 
never "complete" in Python because there's never a terminating curly 
brace :).


But that isn't sufficient to implement an interactive interpreter on top 
of. This code conceptually is complete as far as an interactive 
interpreter is concerned:


   'def f():\n  print 1\n\n'

It also means you can't distinguish between the previous kind of 
incomplete (which is incomplete because the user *could* type more code) 
and this kind of incomplete:


   'a = """'

or:

   'a = (1 + 2 +'

Which are both incomplete because the user *must* type more code. 
(Although the latter two give IncompleteToken - I wonder if that would 
be enough.)


Because of the other IronPython bugs we can't use the code module and 
ScriptSource / ScriptParseResult doesn't give sufficient information. 
Any other ideas?


Michael



On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord 
mailto:fuzzy...@voidspace.org.uk>> wrote:


Hello guys,

We're trying to detect whether a section of code is complete (to
mimic the behaviour of the interactive interpreter).

First of all we tried using the Python standard library code
module which provides interactive console classes. There are two
outstanding bugs on codeplex (one reported by me today) which
prevent this being an ideal solution:

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

The second approach was to create a ScriptSource and looking at
the code properties to tell if the statement is complete or not
(using IronPython 2.0.1). However we can never get it to return a
ScriptParseResult.Complete for function definitions. Code below
shows using \n for newlines but we have also tried with \r\n.

>>> import clr
>>> clr.AddReference('IronPython')
>>> clr.AddReference('Microsoft.Scripting')
>>> from IronPython.Hosting import Python
>>> from Microsoft.Scripting import SourceCodeKind,
ScriptCodeParseResult
>>>
>>> engine = Python.CreateEngine()
>>> s = engine.CreateScriptSourceFromString('def f():\n  print
1\n', 'foo', SourceCodeKind.InteractiveCode)
>>> s.GetCodeProperties()

>>> s = engine.CreateScriptSourceFromString('def f():\n  print
1\n\n', 'foo', SourceCodeKind.InteractiveCode)
>>> s.GetCodeProperties()

>>>

The DLR hosting spec has little helpful to say on the matter as
far as I can tell.

Looking at an example from Tomas it doesn't seem very different
from what we're doing:

http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/

Any clues as to what we are doing wrong or how to procede?

Thanks

Michael

-- 
http://www.ironpythoninaction.com/

http://www.voidspace.org.uk/blog


___
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
  



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


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

Re: [IronPython] InteractiveCode and function definitions

[Curt Hagenlocher]

"IncompleteStatement" means that the user is allowed to type more code.  If
you want to know whether or not it's a valid (complete) string, just check
for it not being Invalid.  A function definition is never "complete" in
Python because there's never a terminating curly brace :).

On Thu, Apr 16, 2009 at 10:05 AM, Michael Foord
wrote:

> Hello guys,
>
> We're trying to detect whether a section of code is complete (to mimic the
> behaviour of the interactive interpreter).
>
> First of all we tried using the Python standard library code module which
> provides interactive console classes. There are two outstanding bugs on
> codeplex (one reported by me today) which prevent this being an ideal
> solution:
>
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22064
> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=21881
>
> The second approach was to create a ScriptSource and looking at the code
> properties to tell if the statement is complete or not (using IronPython
> 2.0.1). However we can never get it to return a ScriptParseResult.Complete
> for function definitions. Code below shows using \n for newlines but we have
> also tried with \r\n.
>
> >>> import clr
> >>> clr.AddReference('IronPython')
> >>> clr.AddReference('Microsoft.Scripting')
> >>> from IronPython.Hosting import Python
> >>> from Microsoft.Scripting import SourceCodeKind, ScriptCodeParseResult
> >>>
> >>> engine = Python.CreateEngine()
> >>> s = engine.CreateScriptSourceFromString('def f():\n  print 1\n', 'foo',
> SourceCodeKind.InteractiveCode)
> >>> s.GetCodeProperties()
>  [IncompleteStatement]>
> >>> s = engine.CreateScriptSourceFromString('def f():\n  print 1\n\n',
> 'foo', SourceCodeKind.InteractiveCode)
> >>> s.GetCodeProperties()
>  [IncompleteStatement]>
> >>>
>
> The DLR hosting spec has little helpful to say on the matter as far as I
> can tell.
>
> Looking at an example from Tomas it doesn't seem very different from what
> we're doing:
>
> http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/
>
> Any clues as to what we are doing wrong or how to procede?
>
> Thanks
>
> Michael
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
>
> ___
> 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] InteractiveCode and function definitions

[Michael Foord]

Hello guys,

We're trying to detect whether a section of code is complete (to mimic 
the behaviour of the interactive interpreter).


First of all we tried using the Python standard library code module 
which provides interactive console classes. There are two outstanding 
bugs on codeplex (one reported by me today) which prevent this being an 
ideal solution:


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

The second approach was to create a ScriptSource and looking at the code 
properties to tell if the statement is complete or not (using IronPython 
2.0.1). However we can never get it to return a 
ScriptParseResult.Complete for function definitions. Code below shows 
using \n for newlines but we have also tried with \r\n.


>>> import clr
>>> clr.AddReference('IronPython')
>>> clr.AddReference('Microsoft.Scripting')
>>> from IronPython.Hosting import Python
>>> from Microsoft.Scripting import SourceCodeKind, ScriptCodeParseResult
>>>
>>> engine = Python.CreateEngine()
>>> s = engine.CreateScriptSourceFromString('def f():\n  print 1\n', 
'foo', SourceCodeKind.InteractiveCode)

>>> s.GetCodeProperties()
[IncompleteStatement]>
>>> s = engine.CreateScriptSourceFromString('def f():\n  print 1\n\n', 
'foo', SourceCodeKind.InteractiveCode)

>>> s.GetCodeProperties()
[IncompleteStatement]>

>>>

The DLR hosting spec has little helpful to say on the matter as far as I 
can tell.


Looking at an example from Tomas it doesn't seem very different from 
what we're doing:


http://blog.tomasm.net/2009/04/15/python-says-hello-to-ruby/

Any clues as to what we are doing wrong or how to procede?

Thanks

Michael

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


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

Re: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s

[Thomas Gagne]

I was able to get my program working.  I still haven't gotten around to
fixing the ipy.exe path thing, but the code below does what I hoped it
would---work.


import clr
import sys
import System

sys.path.append('c:\\program files\\ceTe Software\\DynamicPDF v5.0.2 for
.NET\\bin\\')

clr.AddReference('ceTe.DynamicPDF.35')
 
from ceTe.DynamicPDF import *
from ceTe.DynamicPDF.PageElements import *

document = Document()
document.Author = "Thomas Gagne"
document.Title = "Hello"

page = Page(PageSize.Letter, PageOrientation.Portrait, 54.0)
label = Label("Hello, world!", 0, 0, 504, 100, Font.Helvetica, 18,
TextAlign.Center)
page.Elements.Add(label)
document.Pages.Add(page)

document.Draw ("helloWorld.pdf")

System.Diagnostics.Process.Start("helloWorld.pdf")

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