just letting you know about one great project -- pyglet:
we use it for 3D graphics in SymPy, it is a pure python library, that
uses ctypes for binding to directx on win, opengl on linux and
something in mac os x. I am not an expert in 3D,
I just need something that just works and pyglet is it.
Some examples:
http://code.google.com/p/sympy/wiki/PlottingModule
and you can find a lot of examples on the pyglet webpage.
I am not sure it can be useful for Sage, since Sage is using the
notebook (mostly), but still it's a nice thing that one can finally
(after so many years) just write a simple Python program
and it can do 3D things (fast) on all platforms and all in pure Python.
Ondrej
Try this in Sage right now. It might work for you.
(1) From the command line, type
sage -sh
(2) Type
bash$ pythonw
(3) paste the following code into your python session:
from sympy import symbols, Plot
x,y,z = symbols('xyz')
Plot(x*y**3-y*x**3)
I just tried this and got a very nice dynamically rotateable 3d plot.
Very nice.
-- William
"pythonw" gave "command not found". If you meant "python", I got a
segfault:
wdj@wooster:/mnt/drive_hda1/sagefiles/sage-2.8.13.alpha1$ python
Python 2.5.1 (r251:54863, Nov 26 2007, 13:44:20)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import symbols, Plot
>>> x,y,z = symbols('xyz')
>>> Plot(x*y**3-y*x**3)
[0]: x*y**3 - y*x**3, 'mode=cartesian'
>>> Window initialization failed: No conforming visual exists
Segmentation fault (core dumped)
This is on an ubuntu 64 bit machine.
- William
(Sent from my iPhone.)
It needs fixing to work from Sage notebook, there is some pythonw
exception, but I have no idea what pythonw is. As to the segfault, it
is probably a bug in pyglet, I just updated to the newest one and
released sympy with that a few days ago. But ubuntu should work out of
the box (if you are using ubuntu).
Ondrej
I got the following on Ubunty 7.10 (32-bit). Any ideas what went wrong?
$ sage -sh
Starting subshell with Sage environment variables set:
$ pythonw
KABOOOM!!!
Whoops, command-not-found has crashed! Please file a bug report at:
https://bugs.launchpad.net/ubuntu/+source/command-not-found
Please include the following information with the report:
No module named CommandNotFound
Traceback (most recent call last):
File "/usr/lib/command-not-found", line 10, in <module>
from CommandNotFound import CommandNotFound
ImportError: No module named CommandNotFound
Python version: 2.5.1 final 0
bash: pythonw: command not found
$ python<TAB>
python python2.5-config python-config
python2.4 python2.5-dbg python-dbg
python2.4-config python2.5-dbg-config python-dbg-config
python2.5 python.cex
$ python
Python 2.5.1 (r251:54863, Nov 26 2007, 12:10:35)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import symbols, Plot
>>> x,y,z=symbols('xyz')
>>> Plot(x*y**3-y*x**3)
Xlib: extension "XFree86-DRI" missing on display ":1.0".
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/__init
__.py", line 16, in Plot
import plot
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/plot.p
y", line 8, in <module>
from plot_axes import PlotAxes
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/plot_a
xes.py", line 2, in <module>
from pyglet import font
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/pyglet
/font/__init__.py", line 79, in <module>
from pyglet import image
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/pyglet
/image/__init__.py", line 1964, in
<module>
_codecs.add_default_image_codecs()
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/pyglet
/image/codecs/__init__.py", line 173,
in add_default_image_codecs
import pyglet.image.codecs.gdkpixbuf2
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/pyglet
/image/codecs/gdkpixbuf2.py", line 50,
in <module>
gdk = pyglet.lib.load_library('gdk-x11-2.0')
File
"/home/grout/sage/local/lib/python2.5/site-packages/sympy/plotting/pyglet
/lib.py", line 43, in load_library
return ctypes.cdll.LoadLibrary(path)
File "/home/grout/sage/local/lib/python2.5/ctypes/__init__.py", line
425, in L oadLibrary
return self._dlltype(name)
File "/home/grout/sage/local/lib/python2.5/ctypes/__init__.py", line
342, in _ _init__
self._handle = _dlopen(self._name, mode)
OSError: /usr/lib/libcairo.so.2: undefined symbol: FT_Library_SetLcdFilter
>>>
I think this pythonw thing works for me only because I'm on osx and there is a
/usr/bin/pythonw, which means "run python with a gui", so it is
running a system-wide
python. However, because I did "sage -sh", I'm still getting the
packages installed
into sage, e.g., pyglet and sympy.
So folks, don't try this at home after all. That said, it's very
pretty when it works,
so we should definitely figure out if pyglet can somehow benefit sage.
William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
>
> Hi,
>
> I think this pythonw thing works for me only because I'm on osx and
> there is a
> /usr/bin/pythonw, which means "run python with a gui", so it is
> running a system-wide
> python. However, because I did "sage -sh", I'm still getting the
> packages installed
> into sage, e.g., pyglet and sympy.
FWIW, it appears that 'sage -sh' isn't doing the job I think it should:
$ echo $PATH
.:/usr/texbin:/Users/justin/bin:/usr/local/bin:/bin: ...
$ ./sage -sh
Starting subshell with Sage environment variables set:
$ echo $PATH
.:/usr/texbin:/Users/justin/bin:/usr/local/bin:/bin: ...
$ exit
Exited Sage subshell.
The PATH variable is the same before and after invoking the shell.
Shouldn't "$SAGE_ROOT/local/bin" be in there?
This works better (I hand-edited and truncated the output to keep
from overwhelming the reader):
$ . local/bin/sage-env
$ echo $PATH
$SAGE_ROOT/local/Frameworks/Python.framework/Versions/2.5/bin:
$SAGE_ROOT:.:/usr/texbin:/Users/justin/bin:/usr/local/bin:/bin: ...
but $SAGE_ROOT/local/bin is still missing. Also, I have no "pythonw"
anywhere in $SAGE_ROOT. There is one in "/usr/bin", from Apple (a
symlink to the default python2.3).
This is a fresh build of 2.9.alpha4. I get the same behavior for
2.8.1[45] (2.8.8.1 complains about "-sh").
Justin
--
Justin C. Walker, Curmudgeon-at-Large
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email
It looks like my problem might be trac #975
I'm running Ubuntu 7.10 Gutsy Gibbon, like mentioned in #975
-Jason
It's a mess to me:-)
wdj@wooster:~$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: No (If you want to find out why, try setting
LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0.1)
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite,
GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_program,
GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements,
GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters,
GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture,
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp,
GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias,
GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
GL_ATI_draw_buffers, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square,
GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite,
GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_NV_vertex_program,
GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table,
GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x63 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon
wdj@wooster:~$
>
> Carl Witty
>
> >
>
>
> On Dec 10, 3:17 pm, "Justin C. Walker" <jus...@mac.com> wrote:
>> FWIW, it appears that 'sage -sh' isn't doing the job I think it
>> should:
[snip]
> Maybe you have a .bashrc, .zshrc, or similar file that explicitly sets
> $PATH?
Good call. Somewhere along the line, I lost the last part of
PATH=....$PATH. It's time to prune that file anyway...it's been with
me for many years, and looks like Fibber McGee's closet (which may
not help most of you visualize it...).
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
My wife 'n kids 'n dogs are gone,
I can't get Jesus on the phone,
But Ol' Milwaukee's Best is my best friend.
-----------
I think you can just do 2D things easily in pygame. Pyglet is for both
2D and 3D things. It's a pure python, no difficult compilation of
modules. Also I think more choices are better rather than less
choices.
Ondrej
See also this post why pyglet is better than pygame:
http://aroberge.blogspot.com/2007/08/pyglet-and-pygame-which-one.html
Ondrej
I haven't had a mac for a bit, but when I did, I found the
something-like-2-line patch to make pygame work on a mac. It's pretty
trivial (there are I think two places with font calls that need to have
slightly different parameters). With that minor change, pygame worked
great on the mac. I haven't looked at it very much since the beginning
of the year, though.
Also, you can use opengl with pygame. I know there's been huge
discussions on the mailing list about using opengl python bindings
instead of the SDL 2d built-in capabilities. On the side, I've been
helping develop a pygame game and I looked at using opengl instead of
SDL. I thought that pygame was a pretty nice framework.
That said, pygame seems pretty stagnant. They've been advertising the
next release for a long time (I think 1.8 was originally due last
December). The current release was done in 2005 and their last commit
to the subversion repository seems like it was several months ago. Last
year I emailed the developers about the issue with a mac and I thought
they applied the patch, but I don't know, maybe not.
I don't know anything about pyglet, so I can't compare the two
frameworks very well. In looking through some pyglet examples, though,
it seems like pygame is a more comprehensive framework.
-Jason
Thanks for a thorough analysis. I'll ask the author of pyglet to
comment in this thread, maybe
he has something interesting to say.
Ondrej
Agree.
> I see that python-opengl now uses ctypes as well. So it should work on
> any distribution.
That's a valid point. I wrote to the pyglet mailiglist if they could
write here some replies:
http://groups.google.com/group/pyglet-users/browse_thread/thread/b7a19498d0d3cace/
Ondrej
Someone there posted this:
On 12/12/07, Ondrej Certik <ond...@certik.cz> wrote:
> Hi Alex and others,
> there is a discussion on sage-devel about pyglet vs pygame:
> http://groups.google.com/group/sage-devel/browse_thread/thread/8c844f...
> do you think you could please correct/add some information in there
> please?
Rather than join in your list, I'll just post some quick
clarifications which you can repost there. If your members have more
questions about pyglet etc, they are of course welcome to join this
list or email me.
Re: "No conforming visual": this looks like a 16-bit depth issue that
was fixed quite a while ago, but please make sure the author checks
with a newer version and opens an issue if not.
Re: "OpenGL/SDL/PyOpenGL":
For your requirements, only OpenGL will suffice (accelerated 3D
graphics on Mac/Windows/Linux). OpenGL is a graphics API that is
exposed on Windows, Linux and Mac. To use OpenGL from Python, you can
use either pyglet or PyOpenGL.
Regardless of whether pyglet or PyOpenGL is used to call the OpenGL
functions, you still need an OpenGL "context" -- a window into which
the graphics can be drawn. pyglet can provide you with such a
context, as can PyGame (PyOpenGL can too, with GLUT, but this has
limitations). Most other GUI toolkits, such as wxPython, PyGtk and
Tkinter can also create OpenGL contexts.
So, you should choose your context creator first: say, pyglet, if you
like its event and windowing system; or PyGame, if you prefer SDL's
event and windowing system (PyGame uses SDL, a C library, internally).
You may decide to go with PyGtk or wxPython etc instead, if you want
to use their GUI components.
Having chosen a context, you can then proceed to use OpenGL via pyglet
or PyOpenGL.
Re: "DirectX/OpenGL":
pyglet only uses DirectX for audio -- graphics are still done using
OpenGL on Windows. There are no DirectX bindings for Python that I'm
aware of (though you could use the COM interfaces directly, if you
were suitably masochistic).
Hope that clears up some things
Alex.
What do we have currently available in Sage? Apparently we have pyglet
(even though I can't get it working on Ubuntu 7.10). Do we already have
any of the other gui libraries mentioned?
-Jason
On Dec 12, 2007 10:20 PM, Ondrej Certik <ond...@certik.cz> wrote:
> Thanks for your reply. So pygame+pyopengl is more or less equivalent
> to pyglet? I.e. it runs on win, linux, mac and it allows you to do
> basically the same things?
Well, see the respective feature lists for the differences; they are
equivalent if _all_ you want to do is render to a single opengl
context.
> I am interested in reasons you stared pyglet, instead of improving
> pygame+pyopengl - pyglet must have some advantages. For example being
> a small, pure python library.
PyGame is fundamentally limited by SDL; a feature addition (such as
adding support for multiple windows) would require a modification to
SDL, to the PyGame DLL and to the PyGame Python modules.
Incidentally, the PyGame DLL is not required now that ctypes is
available; I rewrote PyGame to use ctypes last year but the then
maintainers were not interested in making the switch.
Because pyglet doesn't use SDL it can have include many features that
PyGame cannot (yet).
Alex.