ANN: PyScript 0.6.0 released
Overview: PyScript is a python module for producing high quality postscript graphics. Rather than use a GUI to draw a picture, the picture is programmed using python and the PyScript objects. Some of the key features are: * All scripting is done in python, which is a high level, easy to learn, well developed scripting language. * All the objects can be translated, scaled, rotated, ... in fact any affine transformation. * Plain text is automatically kerned. * You can place arbitrary LaTeX expressions on your figures. * You can create your own figure objects, and develop a library of figure primitives. * Output is publication quality. License: Released under the GPL Changes: The major change in this release is a complete rewrite of the Talk and Poster classes of the presentation library. There have also been many bug fixes and minor other improvements. For details see the PyScript web page: http://pyscript.sourceforge.net";>pyscript.sourceforge.net. Getting the software: One can download the latest version (0.6) from: http://pyscript.sourceforge.net";>PyScript Requirements: * Python 2.2 and above * An up-to-date LaTeX distribution Authors: * Alexei Gilchrist <[EMAIL PROTECTED]> * Paul Cochrane <[EMAIL PROTECTED]> If you use this software, have any suggestions, or bug reports, please let us know! -- [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Running autogenerated code in another python instance
Hi all, I've got an application that I'm writing that autogenerates python code which I then execute with exec(). I know that this is not the best way to run things, and I'm not 100% sure as to what I really should do. I've had a look through Programming Python and the Python Cookbook, which have given me ideas, but nothing has gelled yet, so I thought I'd put the question to the community. But first, let me be a little more detailed in what I want to do: I have a python module (called pyvisi, but you don't need to know that) which attempts to simplify the writing of scripts for high performance computing visualisation applications. What it does is provides a layer between the user and the actual renderer backend that is actually going to process the code. Effectively all my app does is to autogenerate the code the user would have to write were they savvy with the python interface to vtk (the visualisation toolkit). This reduces the effort on the part of the user quite a lot. What I have currently is my python module generating the equivalent vtk-python code and then executing this in an exec(). This is not nice (and potentially very slow), especially if one has to share around data, so what I want to do is have a separate python process or thread which just sits there accepting the autogenerated text strings as if the user were writing them directly at the python prompt (or equivalent), and returning any error messages generated. Also, I want to be able to share data between the two processes/threads so that one doesn't have to turn numerical data into a string which is then turned back into numerical data inside the exec() call (ugly, I know, but it works). Maybe a picture will help as well (time going down the page): Main Proc(1) | |> Renderer(2) | | | <-- Data(3) --> | | | | more commands| | ---> | | | | even more cmds | | ---> | | | | render finished | | shut down Rndrr | | <--- | | | main proc continues or finishes (1) the main process where the python code destined for the backend is generated (2) the secondary process which accepts and runs the code it receives (3) data to visualised; shared between the two processes Ok, hopefully you get what I want to do now... So, what is the best way to do this? Threads share memory, so this is handy to share the data around, however, how does one send arbitrary commands to be processed by a thread? One way to do this would be to use pipes, but this means that I can't share the data around as easily. I've also seen the Pyro project as a possibility, but I would like to keep this as "core python" as possible. Any help or advice would be really (really!) appreciated. TIA Paul -- Paul Cochrane Earth Systems Science Computational Centre University of Queensland, Brisbane, Queensland 4072, Australia E: cochrane at esscc dot uq dot edu dot au -- http://mail.python.org/mailman/listinfo/python-list
Re: Running autogenerated code in another python instance
On Wed, 02 Nov 2005 06:33:28 +, Bengt Richter wrote:
> On Wed, 2 Nov 2005 06:08:22 + (UTC), Paul Cochrane <[EMAIL PROTECTED]>
> wrote:
>
>>Hi all,
>>
>>I've got an application that I'm writing that autogenerates python code
>>which I then execute with exec(). I know that this is not the best way to
>>run things, and I'm not 100% sure as to what I really should do. I've had a
>>look through Programming Python and the Python Cookbook, which have given me
>>ideas, but nothing has gelled yet, so I thought I'd put the question to the
>>community. But first, let me be a little more detailed in what I want to
>>do:
>>
Bengt,
Thanks for your reply!
> It's a little hard to tell without knowing more about your
> user input (command language?) syntax that is translated to
> or feeds the process that "autogenerates python code".
Ok, I'll try and clarify things as much as I can.
> E.g., is it a limited python subset that you are accepting as input,
> or a command language that you might implement using the cmd module, or ?
It's basically just a command language I guess. Perhaps it's best to
explain using an example. Here's the pyvisi code that generates a very
simple line plot using the vtk renderer module:
"""
Example of plotting lines with pyvisi
"""
# set up some data to plot
from Numeric import *
x = arange(10, typecode=Float)
y = x**2
# example code for how a user would write a script in pyvisi
from pyvisi import * # base level visualisation stuff
# import the objects to render the scene using the specific renderer
#from pyvisi.renderers.gnuplot import * # gnuplot
from pyvisi.renderers.vtk import * # vtk
#from pyvisi.renderers.plplot import *# plplot
# define the scene object
# a Scene is a container for all of the kinds of things you want to put
# into your plot for instance, images, meshes, arrow/vector/quiver plots,
# contour plots, spheres etc.
scene = Scene()
# create a LinePlot object
plot = LinePlot(scene)
# add some helpful info to the plot
plot.title = 'Example 2D line plot'
plot.xlabel = 'x'
plot.ylabel = 'x^2'
plot.linestyle = 'lines'
# assign some data to the plot
plot.setData(x, y)
# render the scene to screen
scene.render(pause=True, interactive=True)
# save the scene out to file
## png
plot.setData(x, y) # have to do this now because we've already
# render()ed the scene, will be removed in the
# future
scene.save(fname="simpleLinePlot.png", format=PngImage())
This code then gets translated by the pyvisi module into the vtk-python
code:
import vtk
from Numeric import *
# LinePlot.__init__()
_plot = vtk.vtkXYPlotActor()
_renderer = vtk.vtkRenderer()
_renderWindow = vtk.vtkRenderWindow()
_renderWindow.AddRenderer(_renderer)
_renderWindow.SetSize(640,480)
_renderer.SetBackground(1,1,1)
# Renderer._initRendererModule
# LinePlot.setData()
_x = array([0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0])
_xData = vtk.vtkDataArray.CreateDataArray(vtk.VTK_FLOAT)
_xData.SetNumberOfTuples(len(_x))
_y0 = array([0.0, 1.0, 4.0, 9.0, 16.0, 25.0, 36.0, 49.0, 64.0, 81.0])
_y0Data = vtk.vtkDataArray.CreateDataArray(vtk.VTK_FLOAT)
_y0Data.SetNumberOfTuples(len(_y0))
for i in range(len(_x)):
_xData.SetTuple1(i,_x[i])
for i in range(len(_x)):
_y0Data.SetTuple1(i,_y0[i])
_fieldData0 = vtk.vtkFieldData()
_fieldData0.AllocateArrays(2)
_fieldData0.AddArray(_xData)
_fieldData0.AddArray(_y0Data)
_dataObject0 = vtk.vtkDataObject()
_dataObject0.SetFieldData(_fieldData0)
_plot.AddDataObjectInput(_dataObject0)
_plot.SetXValuesToValue()
_plot.SetDataObjectXComponent(0,0)
_plot.SetDataObjectYComponent(0,1)
_plot.GetXAxisActor2D().GetProperty().SetColor(0, 0, 0)
_plot.GetYAxisActor2D().GetProperty().SetColor(0, 0, 0)
_renderer.SetBackground(1.0, 1.0, 1.0)
_lut = vtk.vtkLookupTable()
_lut.Build()
_colours = []
_colours.append(_lut.GetColor(0))
_plot.SetPlotColor(0, _colours[0][0], _colours[0][1], _colours[0][2])
_plot.SetPosition(0.1, 0.1)
_plot.SetWidth(0.8)
_plot.SetHeight(0.8)
# Scene.render()
_lut = vtk.vtkLookupTable()
_refLut = vtk.vtkLookupTable()
_lut.Build()
_refLut.Build()
for _i in range(256):
_lut.SetTableValue(_i, _refLut.GetTableValue(255-_i))
_iRenderer = vtk.vtkRenderWindowInteractor()
_iRenderer.SetRenderWindow(_renderWindow)
# LinePlot.render()
_renderer.AddActor2D(_plot)
_plot.SetTitle('Example 2D line plot')
_plot.SetXTitle('x')
_plot.SetYTitle('x^2')
_renderWindow.Render()
_iRenderer.Start()
Which is pretty ugly for the user to have to get to grips with, so I'm
trying to simplify the interface to the back end. I'm writing other
backends so that one only needs to change one line of code to then use
gnuplot or plplot as the renderer
Re: Running autogenerated code in another python instance
On Thu, 03 Nov 2005 19:56:48 +, Tom Anderson wrote: > On Thu, 3 Nov 2005, Paul Cochrane wrote: > >> On Wed, 02 Nov 2005 06:33:28 +, Bengt Richter wrote: >> >>> On Wed, 2 Nov 2005 06:08:22 + (UTC), Paul Cochrane <[EMAIL PROTECTED]> >>> wrote: >>> >>>> I've got an application that I'm writing that autogenerates python >>>> code which I then execute with exec(). I know that this is not the >>>> best way to run things, and I'm not 100% sure as to what I really >>>> should do. I've had a look through Programming Python and the Python >>>> Cookbook, which have given me ideas, but nothing has gelled yet, so I >>>> thought I'd put the question to the community. But first, let me be a >>>> little more detailed in what I want to do: > Paul, this is a rather interesting problem. There are two aspects to it, > which i believe are probably separable: getting instructions from the > client to the server, and getting data back from the server to the client. > The former is more complex, i think, and what's attracted the attention so > far. Tom, thanks heaps for your reply! > The first thing i'd say is that, while eval/exec is definitely a code > smell, that doesn't mean it's never the right solution. If you need to be > able to express complex things, python code might well be the best way to > do it, and the best way to evaluate python code is eval/exec. After looking at the problem a bit more I've come up with a simpler solution to the problem I initially posted; and it involves exec. I've realised that what I've been doing wrong is to compile the code first before I exec it. If I just exec the generated code (within a predefined namespace) then pyvisi does all of the things I want it to do without needing separate processes for generating and rendering the code. This has also solved my data passing problem. I now just need to pass a reference to the data into the namespace where I'm running the generated code and it all works really nicely. Basically the problem had been staring me in the face for ages and I just hadn't seen it. (duh!) >>> It's a little hard to tell without knowing more about your user input >>> (command language?) syntax that is translated to or feeds the process >>> that "autogenerates python code". >> >> It's basically just a command language I guess. > > Hang on - the stuff that the user writes is what you're calling "pyvisi > code", is that right? That doesn't look like 'just a command language', > that looks like python, using a library you've written. Or is there > another language, the "just a command language", on top of that? You're right, it isn't a command language (I looked up the cmd module in Python in a Nutshell and then realised that a large part of my reply was in the "I guess" part). It is just python code that is being run. > > And what you call "vtk-python code" - this is python again, but using > the renderer's native library, right? That's correct. > > And you generate the vtk-python from the pyvisi-python by executing the > pyvisi-python, there being (pluggable renderer-specific) logic in the > guts of your pyvisi classes to emit the vtk-python code, right? You're > not parsing anything? No parsing going on. Just a translation of high-level ideas into the low level of the renderer underneath. > >>> There are lots of easy things you could do without generating and >>> exec-ing python code per se. >> >> I'd love to know of other options. I like the idea of generating the >> code one would have to write for a particular renderer so that if the >> user wanted to, they could use the autogenerated code to form the basis >> of a specific visualisation script they could then hack themselves. > > If you want vtk-python code as an intermediate, i think you're stuck > with eval/exec [1]. So do I. And as I said above, it seems to have simplified my problem significantly. I've also managed to speed the code up as well! Thanks heaps for the rest of your comments and suggestions. They've been really helpful for me to see alternative and probably cleaner ways of doing what I want to do. > To be honest, i'd go with exec. :-) Again, thanks for your help, I really do appreciate it. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Running autogenerated code in another python instance
On Mon, 07 Nov 2005 00:01:29 +, Bengt Richter wrote: > On Thu, 03 Nov 2005 14:23:53 +1000, Paul Cochrane <[EMAIL PROTECTED]> wrote: > >>On Wed, 02 Nov 2005 06:33:28 +, Bengt Richter wrote: >> >>> On Wed, 2 Nov 2005 06:08:22 + (UTC), Paul Cochrane <[EMAIL PROTECTED]> >>> wrote: >>> >>>>Hi all, >>>> >>>>I've got an application that I'm writing that autogenerates python code >>>>which I then execute with exec(). I know that this is not the best way to >>>>run things, and I'm not 100% sure as to what I really should do. I've had a >>>>look through Programming Python and the Python Cookbook, which have given me >>>>ideas, but nothing has gelled yet, so I thought I'd put the question to the >>>>community. But first, let me be a little more detailed in what I want to >>>>do: >>>> >> >>Bengt, >> >>Thanks for your reply! >> >>> It's a little hard to tell without knowing more about your >>> user input (command language?) syntax that is translated to >>> or feeds the process that "autogenerates python code". >>Ok, I'll try and clarify things as much as I can. >> > [...snip great reply...] Thanks :-) > > I owe you another reply, but I started and I couldn't spend the time to > do it justice. But in the meanwhile, I would suggest thinking about how > the MVC (model-view-controller) concept might help you factor things. > ISTM you are already part way there. See > http://en.wikipedia.org/wiki/MVC Thanks for the tip. > for some infos. To that I'd add that if you want a top level interactive > visualization tool, > you might want to look at it like a kind of IDE, where you might want a few > workspace/project kind > of top level commands to help manage what you would otherwise do by way of > manually creating > directory subtrees for various things etc. Anyway, if you want to use > template code and edit > it and then compile and run it, you could select templates and make working > copies automatically > and invoke some favorite editor on it from the top level command interpreter. > Having these > pieces consistently arranged in projects/workspaces and shared template > spaces etc. would > make it a single command to create a fresh space and not worry about > colliding with something > you did just to show someone a little demo, etc. This is not the central > topic, but good useability > is nice ;-) I think this is probably a bit more complex than I really want. All I want to do is to take the pain out of scripting visualisation of large and complex data sets. My code will eventually run inside a batch job, or behind a web-based GRID interface thing (still being developed by other people in my group). The interactive part of vtk is just a handy side effect; allowing users to rotate objects within a window and see what's on the other side etc is really nice, but not necessarily the main aim. Nevertheless, I've found out what I've been doing wrong all along: I've been compiling the code objects before exec-ing them. By just running exec on the generated code I can run the code generation and rendering within the one process (since not compiling beforehand allows me to maintain state), and I can pass the data around as the objects themselves and not this convoluted convert to string, convert back to number process I had going. It's also now a lot faster (which is always a bonus)! > That way if you just wanted to re-run something, you'd just select it and > skip calling the > editor. Or if a step was to generate data, you could either create the data > source program > by several steps or possibly just go on to define or invoke a visualization > step with > a particular renderer and/or output, knowing that the data source was already > set up in a > standard way. You could also consider borrowing unix piping/redirection > concepts > for some command syntax, for composition of standard interface actions (not > to mention > invoking the real thing in a subprocess when appropriate). Just > free-associating here ;-) These are great ideas, but probably a bit more than I can handle atm :-) > Anyway, gotta go for now, sorry. No worries! I really appreciate your feedback. Paul -- http://mail.python.org/mailman/listinfo/python-list
[ANN] PyScript 0.5 released
PyScript is a python module for producing high quality postscript graphics. Rather than use a GUI to draw a picture, the picture is programmed using python and the PyScript objects. Some of the key features are: * All scripting is done in python, which is a high level, easy to learn, well developed scripting language. * All the objects can be translated, scaled, rotated, ... in fact any affine transformation. * Plain text is automatically kerned. * You can place abritrary LaTeX expressions on your figures. * You can create your own figure objects, and develop a library of figure primitives. * Output is publication quality. LICENSE: Released under the GPL The major change in this release is a complete rewrite of the Path object. The internals have completely changed and there have been some incompatible changes with previous versions but it's now much closer to what was envisaged for the object. There have also been many bug fixes and minor other improvements. For details see the PyScript web page: http://pyscript.sourceforge.net";>pyscript.sourceforge.net. http://pyscript.sourceforge.net";>PyScript 0.5 - a python module for producing high quality postscript graphics; rather than use a GUI to draw a picture, the picture is programmed using python and the pyscript objects. (10-Jan-05) -- [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Gnuplot.py and, _by far_, the weirdest thing I've ever seen on my computer
I had similar problems with Gnuplot.py, basically, one couldn't use ascii
mode for plotting grid data, and had to set binary=1 in the GridData()
method. (this is off the top of my head, so I might have the binary/ascii
thing the wrong way around). What fixed the problem was going to version
Gnuplot.py 1.7. What version are you using? If it's 1.6, that *might* be
the problem (although, I can't be 100% sure).
HTH
Regards,
Paul
* syd ([EMAIL PROTECTED]) [050405 07:26]:
> I don't even know where to begin. This is just bizarre. I just picked
> up the Gnuplot.py module (a light interface to gnuplot commands) and
> was messing around with it today.
>
> I've got a tiny script, but it only works from the command line about
> half the time! In the python interpreter, 100%. Ipython, 100%. I'm
> not kidding.
>
> #!/bin/env python
> import Gnuplot
> g = Gnuplot.Gnuplot(debug=1)
> g.title('A simple example')
> g('set data style linespoints')
> g('set terminal png small color')
> g('set output "myGraph.png"')
> g.plot([[0,1.1], [1,5.8], [2,3.3], [3,100]])
>
> Here's just one example -- it does not work, then it works. It seems
> totally random. It will work a few times, then it won't for a few
> times...
>
> bash-2.05b$ ./myGnu.py
> gnuplot> set title "A simple example"
> gnuplot> set data style linespoints
> gnuplot> set terminal png small color
> gnuplot> set output "myGraph.png"
> gnuplot> plot '/tmp/tmp5LXAow' notitle
>
> gnuplot> plot '/tmp/tmp5LXAow' notitle
> ^
> can't read data file "/tmp/tmp5LXAow"
> line 0: util.c: No such file or directory
>
> bash-2.05b$ ./myGnu.py
> gnuplot> set title "A simple example"
> gnuplot> set data style linespoints
> gnuplot> set terminal png small color
> gnuplot> set output "myGraph.png"
> gnuplot> plot '/tmp/tmpHMTkpL' notitle
>
> (and it makes the graph image just fine)
>
> I mean what the hell is going on? My permissions on /tmp are wide open
> (drwxrwxrwt). It does the same thing when I run as root. And it
> _always_ works when I use the interpreter or interactive python.
>
> Any clues would be greatly appreciated. I'm baffled.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
--
Paul Cochrane
Computational Scientist/Software Developer
Earth Systems Science Computational Centre
Rm 703, SMI Building
University of Queensland
Brisbane
Queensland 4072
Australia
--
http://mail.python.org/mailman/listinfo/python-list
