Re: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s
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
Re: [IronPython] InteractiveCode and function definitions
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
fuzzy...@voidspace.org.ukwrote:
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()
Microsoft.Scripting.ScriptCodeParseResult object at 0x003F
[IncompleteStatement]
s = engine.CreateScriptSourceFromString('def f():\n print 1\n\n',
'foo', SourceCodeKind.InteractiveCode)
s.GetCodeProperties()
Microsoft.Scripting.ScriptCodeParseResult object at 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
Re: [IronPython] InteractiveCode and function definitions
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
fuzzy...@voidspace.org.ukwrote:
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 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()
Microsoft.Scripting.ScriptCodeParseResult object at
0x003F [IncompleteStatement]
s = engine.CreateScriptSourceFromString('def f():\n print
1\n\n', 'foo', SourceCodeKind.InteractiveCode)
s.GetCodeProperties()
Microsoft.Scripting.ScriptCodeParseResult object at
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 mailto: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
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 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
fuzzy...@voidspace.org.uk mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
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()
Microsoft.Scripting.ScriptCodeParseResult object at
0x003F [IncompleteStatement]
s = engine.CreateScriptSourceFromString('def f():\n print
1\n\n', 'foo', SourceCodeKind.InteractiveCode)
s.GetCodeProperties()
Microsoft.Scripting.ScriptCodeParseResult object at
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
___
Re: [IronPython] InteractiveCode and function definitions
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
fuzzy...@voidspace.org.ukwrote:
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 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
fuzzy...@voidspace.org.uk mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
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()
Microsoft.Scripting.ScriptCodeParseResult object at
0x003F [IncompleteStatement]
s = engine.CreateScriptSourceFromString('def f():\n print
1\n\n', 'foo', SourceCodeKind.InteractiveCode)
s.GetCodeProperties()
Microsoft.Scripting.ScriptCodeParseResult object at
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
Re: [IronPython] InteractiveCode and function definitions
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
fuzzy...@voidspace.org.uk 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
fuzzy...@voidspace.org.uk mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
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
fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
mailto:fuzzy...@voidspace.org.uk
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
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 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 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org
Re: [IronPython] ipy.exe not found -- sorry, haven't programmed on windows since 90s
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
