Re: PyOpenGL and graphics card support
that works. Thx below is the output for my system: gluGetString - GLU_VERSION: 1.2.2.0 Microsoft Corporation gluGetString - GLU_EXTENSIONS: GL_EXT_bgra glGetString - GL_VENDOR: NVIDIA Corporation glGetString - GL_RENDERER: GeForce 9500 GT/PCI/SSE2 glGetString - GL_SHADING_LANGUAGE_VERSION: 1.40 NVIDIA via Cg compiler glGetString - GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_framebuffer_object GL_ARB_geometry_shader4 GL_ARB_imaging GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_bindable_uniform GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_texture_shared_exponent GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_conditional_render GL_NV_depth_clamp GL_NV_explicit_multisample GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_parameter_buffer_object2 GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render
PyOpenGL and graphics card support
OpenGL newbie alert!!! Do I need to do anything special to use OpenGL capabilities of my graphics card ? I have the impression PyOpenG is using the Windows emulation. when I execute the following code: print glGetString - GL_VENDOR: , glGetString (GL_VENDOR) print glGetString - GL_RENDERER:, glGetString (GL_RENDERER) print glGetString - GL_SHADING_LANGUAGE_VERSION:, glGetString (GL_SHADING_LANGUAGE_VERSION) print glGetString - GL_EXTENSIONS: , glGetString (GL_EXTENSIONS) print gluGetString - GLU_VERSION: , gluGetString (GLU_VERSION) print gluGetString - GLU_EXTENSIONS:, gluGetString (GLU_EXTENSIONS) I get the following results: glGetString - GL_VENDOR: None glGetString - GL_RENDERER: None glGetString - GL_SHADING_LANGUAGE_VERSION: None glGetString - GL_EXTENSIONS: None gluGetString - GLU_VERSION:1.2.2.0 Microsoft Corporation gluGetString - GLU_EXTENSIONS: I am using Python 2.6.2 and PyOpenGL3.0.1a3 on Windows 7 Enterprise My graphics card is NVIDIA GeForce 9500 GT card with driver date = 7/14/2009 and version = 8.15.11.9038 -- http://mail.python.org/mailman/listinfo/python-list
Re: PyOpenGL and graphics card support
these are the imports I use: from OpenGL.GL import * from OpenGL.GLUT import * from OpenGL.GLU import * -- http://mail.python.org/mailman/listinfo/python-list
cross compile Python to Linux-ARM
Hi, We are looking to use Python on an embedded Linux ARM system. What I gather from googling the subject is that it is not that straight forward (a fair amount of patching hacking). Nobody out there that has done it claims it is easy, which makes me worried. I haven't seen a description on porting Python 2.6 or 3.0 yet. Is it much different than for the earlier versions (the latest I have seem is Python 2.5). Does it matter whether Python is cross compiled to Linux 2.4 or Linux 2.6 ? Can anyone point to a howto they know works well ? What are the chances of an 'officially' supported ARM-Linux Python distribution ? (or is it safer to wait for industrial spec Intel Atom boards to avoid the cross compilation altogether ? What would it take for the Linux version of Python to be easily cross compiled (i.e. would the Linux-Python maintainers be willing to include and maintain cross-compilation specific functions) ? Let's say we can get it done. How is the performance and stability of a working Python on an embedded ARM-Linux system ? Does cross compiling Python automatically include the standard Python library, or is that yet another adventure ? thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: import wx works interactive but not from script
ok, sorry for the long wait. I tried this on both my work (XP) and home PC (Vista64) and they are both consistent. I had both Python2.6 and Python 3.0 installed. wxPython didn't like that. As soon as I uninstalled Python3.0, my wxPython started running again. Must be some kind of registry thing. Thanks for the suggestion. -- http://mail.python.org/mailman/listinfo/python-list
import wx works interactive but not from script
when I call import wx from the interactive console, it works (i.e. it doesn't complain). But when I call the same from a script, it complains that it can not find the wx module. works for interactive Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import wx does not work frm script-- Traceback (most recent call last): File c:\temp\myscript.py, line 4, in module import wx ImportError: No module named wx I run Vista Home premium 64bit. Python 2.6.1 (the 32-bit version). I installed the latest 32-bit ANSI version of wxpython. (http:// downloads.sourceforge.net/wxpython/wxPython2.8-win32-ansi-2.8.9.1- py26.exe) In the folder C:\Python26\Lib\site-packages, I find a wx.pth file with a single line in there: wx-2.8-msw-ansi in that same directory is a folder named wx-2.8-msw-ansi and it contains a subdirectory called wx with what appears to be the regular wx libary stuff, including __init__.py My PATH starts with C:\Python26;C:\Python26\Scripts;C:\Python26\lib; any idea's ? -- http://mail.python.org/mailman/listinfo/python-list
Re: import wx works interactive but not from script
I ran the script from a command line, so it is not a file association thing. I do have multiple versions of Python installed on that machine. I will uninstall them all and install a single version from clean. Thanks for the suggestion -- http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
this is alink explaining how to add new fonts to the command line (e.g. Lucida Sans Unicode) http://phatness.com/node/1643 -- http://mail.python.org/mailman/listinfo/python-list
unable to print Unicode characters in Python 3
Hi,
while checking out Python 3, I read that all text strings are now
natively Unicode.
In the Python language reference (http://docs.python.org/3.0/reference/
lexical_analysis.html) I read that I can show Unicode character in
several ways.
\u supposedly allows me to specify the Unicode character by hex
number and the format \N{name} allows me to specify by Unicode
name.
Neither seem to work for me.
What am I doing wrong ?
Please see error output below where I am trying to show the EURO sign
(http://www.fileformat.info/info/unicode/char/20ac/index.htm):
Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
print('\u20ac')
Traceback (most recent call last):
File stdin, line 1, in module
File c:\python30\lib\io.py, line 1491, in write
b = encoder.encode(s)
File c:\python30\lib\encodings\cp437.py, line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u20ac' in
position 0: character maps to undefined
print (\N{EURO SIGN})
Traceback (most recent call last):
File stdin, line 1, in module
File c:\python30\lib\io.py, line 1491, in write
b = encoder.encode(s)
File c:\python30\lib\encodings\cp437.py, line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u20ac' in
position 0: character maps to undefined
--
http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
Hmm this works for me, it's a self compiled version: ~ $ python3 Python 3.0 (r30:67503, Dec 29 2008, 21:35:15) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 You are running on Linux. Mine is on Windows. Anyone else have this issue on Windows ? -- http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
As Benjamin Kaplin said, Windows terminals use the old cp1252 character set, which cannot display the euro sign. You'll either have to run it in something more modern like the cygwin rxvt terminal, or output some other way, such as through a GUI. With the standard console, I get the same. But with IDLE, using the same Python build but through a different interface Scream at Microsoft or try to find or encourage a console replacement that Python could use. In the meanwhile, use IDLE. Not perfect for Unicode, but better. So, if I understand it correctly, it should work as long as you run your Python code on something that can actually print the Unicode character. Apparently, the Windows command line can not. I mainly program command line tools to be used by Windows users. So I guess I am screwed. Other than converting my tools to have a graphic interface, is there any other solution, other than give Bill Gates a call and bring his command line up to the 21st century ? -- http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
Now that I know the problem, I found the following on Google. Windows uses codepages to display different character sets. (http:// en.wikipedia.org/wiki/Code_page) The Windows chcp command allows you to change the character set from the original 437 set. When you type on the command line: chcp 65001 it sets your console in UTF-8 mode. (http://en.wikipedia.org/wiki/Code_page_65001) Unfortunately, it still doesn't do what I want. Instead of printing the error message above, it prints nothing. -- http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
chcp 1252 does allow me to print the EURO sign. Thanks for pointing that out. However, it does not show me some ALL Unicode characters. Very frustrating. I was hoping to find something that allows me to print any Unicode character on the console. -- http://mail.python.org/mailman/listinfo/python-list
executables no longer executing on PC's without Python installed
Hi, I recently figured out a problem that came up with the latest versions of Python and cx_Freeze. I thought I post it here so that it might be usefull to someone. The problem was that, when I switched to Python 2.6.x and cx_Freeze-4.0.1.win32-py2.6.msi, the executables that were produced ran perfectly on my PC but not any other PC. They did not print any useful information whatsoever. Googling around, I learned that it had to do with Visual Studio being installed on my PC and not on the other PC's. The common solution that worked for other people was to put the redistributable manifest and DLL's from C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT, into the same directory as the generated EXE. This didn't work for me. With the help of Anthony Tuininga, I finally tracked it down to the DLL version. In the good ol' days, when your application was lacking the C rntime library DLL in its search path, it gave a clear warning. e.g. can not find msvcr71.dll or something like that. The only thing you needed to do was to go look for one (either on your PC or on the internet), and pluck whatever DLL with that name into the search path, typically in the same directory as your exe or windows \system32. It didn't care about different versions of DLL's. Now with the advent of at least Visual Studio 2008 (and probably 2005, but I skipped that one), Microsoft, in its infinite wisdom, decided that that method was way too easy for everyone and came up with yet another way to torment everyone that dares to develop software in anything else than Microsoft monstrosities. I am referring to these mysterious things with names like side by side installation, SxS, manifests, assemblies, ... Why does the noble community of enlightened scholars developing Python care at all ? Because Python 2.6 binaries for Windows are now compiled using Visual Studio 2008. In essence, that should not mean more than replacing your msvcr71.dll with msvcr90.dll. Unfortunately, you inherit this assemblies crap with it. The new terminology invented with this and the MSDN articles on this subject make it only more obscure and complicated than it should be. In a nutshell, DLL's now are attributed with a version number. Executables generated with VS2008 are now restricted to run only with a predefined specific version of a DLL. This allows you to run executable A with version X of a DLL and another exe with version Y of that same DLL and not be affected with obscure bugs caused by pairing the wrong version of a DLL with an exe (the infamous DLL hell). How do you pair an exe with a particular DLL version ? That is done with manifest files, basically a small XML file, listing the exact version number and some obscure hash numbers for integrity checking. I haven't figured out how to manually produce these (VS2008 does this for you) but fortunately for us, Python developers we don't need to care. We just have to use the same one the Python distribution was compiled with. How do I know which version Python is compiled with ? The easiest way is to install Python with the option install just for me. This has the result that the msvcrxx.dll used by Python is copied into the c:\pythonxx directory instead of in a common windows\system32 folder (or something like that). This was my first mistake, I used the other option install for other users. This should not be a problem. cx_Freeze is clever enough to go out and find this DLL for you. It will probably find the right one, PROVIDING you have the right version of the DLL's in your search path. Now back to Microsoft. Up until around 9/16/2008, there was only 1 version of msvcr DLL's, nl. 9.0.21022.8 and that was good, because it happens to be the same version Python was installed with. The only thing you have to do is to accompany your generated exe with a manifest with the correct hieroglyphs, copy this dll in the same directory and you were done. (you actually need 2 manifest files: one that accompanies to the exe which DLL version it needs, and another manifest file that specifies the versions of the DLL. The exe manifest can be embedded in the exe). Poor old Anthony Tuininga had to figure this out the hard way. He makes our lives a lot easier by already embedding the correct exe manifest into the executable. You can check this by opening the generated binary with a hex editor and scroll down until you see some XML. That is the manifest. That will tell you which DLL's it needs and which version (nl. 9.0.21022.8). It needs to be this version because of the version of Visual Studio 2008 used to compile Python itself. Having Visual Studio 2008 installed on your PC while freezing your Python apps should not be a problem. Even if you didn't specify install just for me, cx_Freeze will probably find msvcr90.dll somewhere. But then came Visual Studio 2008 SP1. With it came an updated msvcr90.dll with version 9.00.30729.1. That is what I had installed and things went south from
unicode box drawing
How can I print the unicode box drawing characters in python: print u'\u2500' print u'\u2501' print u'\u2502' print u'\u2503' print u'\u2504' Traceback (most recent call last): File \test.py, line 3, in ? print u'\u2500' File C:\Python24\lib\encodings\cp1252.py, line 18, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeEncodeError: 'charmap' codec can't encode character u'\u2500' in position 0: character maps to undefined -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode box drawing
on windows using python 2.4. ??? yes, as a matter of fact I am. Did not feel the need to switch to 2.5 yet. I'm gonna give this a try, but it requires me to dig up 2.5 versions of the libraries i am using. (one of them didn't at the time and that is why I stuck to 2.4) -- http://mail.python.org/mailman/listinfo/python-list
Re: unicode box drawing
on windows using python 2.4. ??? I was on Python 2.4.3 and it gave me that problem. I upgraded to 2.4.4 and it works. thanks for the tip. -- http://mail.python.org/mailman/listinfo/python-list
