🌐 Mailman 3 February 2006 - Pythonmac-SIG - python.org

Re: [Pythonmac-SIG] My stab at a new page
by Schollnick, Benjamin Feb. 9, 2006

Feb. 9, 2006

> I fixed a couple of the problems Bob noted, and added some > links to pictures (how to start the Terminal, and what the > IDLE IDE looks like). Looks good... But I would suggest... Python on the Macintosh You're in luck! Python comes pre-installed on Apple's Macintosh series of computers that run OS X, for versions of OS X greater than 10.1. is a little clumsy... How about.... Python on the Macintosh Any Mac OS X (10.1+) users are in luck! Python comes pre-installed on every Macintosh that is running OS X 10.1 or higher. Since Apple has nicely included Python with their Operating systems you can get started simply by opening a terminal window (see below). Once you have experimented with Python you may want to consider upgrading to a newer version of Python. For details on upgrading, see "If you want a newer version of Python" below. - Benjamin

1 0

Problems with PyOpenGL build and fixes?
by Bill Northcott Feb. 9, 2006

Feb. 9, 2006

I downloaded and installed Bob's binary of wxPython for 2.4, which seems to work nicely but expects PyOpenGL to be installed. So I tried installing it and fell right back into the header file messes again. Issues so far: 1. the current source tarball has a big problem. There is a script, get_gl_extensions.py, at the top level of the cvs code which adds a heap of cruft starting '#include <GL/glext.h> on to the end of almost all the wrapper .i files. This include does not work on MacOS but even changing it to <OpenGL/glext.h> just results in a load of 'syntax error's. Using CVS code gets over this. It seems the offending script was merged to the head in July 2005. Does any one know why? 2. config/ darwin.cfg adds /System/Library/Frameworks/ Kernel.framework/Headers to the header search path. This creates a problem because '#include <stat.h> then includes the Kernel framework version of stat.h which lacks necessary declarations. This issue has also been reported by others on PyOpenGL mail lists. Does anyone know why the Kernel framework is used? 3. around src/config.h:96 there is code like #ifdef CGL_PLATFORM #include <OpenGL/gl.h> #include <OpenGL/glu.h> #include <glut.h> #else this leaves certain functions undeclared such as CGLGetCurrentContext. Altering the code thus removes these problems #ifdef CGL_PLATFORM #include <OpenGL/gl.h> #include <OpenGL/glu.h> #include <OpenGL/OpenGL.h> #include <GLUT/glut.h> #else this change has a side benefit of rendering the include_dirs on line 14 of darwin.cfg unnecessary. A directive like '#include <OpenGL/ gl.h>' automatically searches the standard framework search path (~/ Library/Frameworks:/Library/Frameworks:/System/Library/Frameworks) for an OpenGL.framework and the loads the header from the Headers directory in that framework. 4. at src/gle/src/texgen.c around line 14 there is the following: #ifdef __APPLE_CC__ /#include <sys/types.h> /* Darwin has a bug that doesn't define u_short in */ /#include <sys/malloc.h> /* malloc.h, so we have to get it through stdio.h. */ #else #include <malloc.h> #endif this results in malloc and realloc not being declared. I have no idea how this code got concocted. All the sources I have consulted (Apple's documentation, Opengroup standards and even my 1988 copy of K&R) say malloc and realloc are provided by <stdlib.h>. Changing the code as below results in all the warnings going away #ifdef __APPLE_CC__ #include <stdlib.h> #else #include <malloc.h> #endif With these changes the cvs code for PyOpenGL builds happily, although there are still a lot of warnings. Thanks Bill Northcott PS This build works happily with _POSIX_C_SOURCES defined!

3 6

Re: [Pythonmac-SIG] a beginner's list
by Christopher Barker Feb. 9, 2006

Feb. 9, 2006

Bill Janssen wrote: > You had no idea about it because it's not going to happen. "Apple is > likely to yank their python out from under you"? Come on, this is > absurd. In 10.5, /usr/bin/python is likely to be Python 2.4 instead > of 2.3, but the odds are 9999 to 1 that it will be there, and the > Python community has taken great pains to make sure 2.4 is > backwards-compatible with 2.3. > > We can only quote odds because none of us work for Apple, but still, > in my opinion -- what troll-bait! It was not intended that way. Yes, Apple will most likely supply a Python with 10.5. It will also most likely be a 2.4.*. What I don't see any evidence for is them keeping 2.3.5 around as well. What that means is that all the packages you have compiled and installed for 2.3.* will no longer work. Yes, python-only scripts that use usr/bin/python will most likely work, but that's it. If you think Apple will keep 2.3.* around, in addition to a newer 2.4.*, then tell us why. They didn't keep 2.2* around when 10.3 came out. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

3 3

wxPython 2.6.2.1 source build a final summary
by Bill Northcott Feb. 9, 2006

Feb. 9, 2006

This is a final summary of my experiences building wxPython 2.6.2.1 sources on MacOS X 10.4.4 with ActivePython 2.4.2.10 and Xcode 2.2.1 with gcc-3.3 and g77. To avoid the problems with _POSIX_C_SOURCE and friends, I conditionalized the defines for _POSIX_C_SOURCE _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED with #if !defined(__cplusplus). This has enabled me to build a number of modules including wxPython without problem. The C sources are quite happy with the POSIX defines and the C++ sources don't get them. It seems to me that these changes should be made in Python. The configure test for strcasecmp seems wrong to me. As I see it, most modern operating environments are standards compliant. So they will have strings.h and it will contain strcasecmp. The use of string.h should be just a fall back. All that is necessary to fix this is to swap the tests around to check for strings.h first followed by string.h and the hack as a final default. I still feel much happier using the _POSIX_C_SOURCE define to always get strcasecmp from strings.h. That will always work in a C program by definition. The problem is C++. Really you should not use strcasecmp in a C++ program. The 'right' answer is to have a C source file defining a small utility function wxstrcasecmp() and link this with the C++ object files. That way you can be sure that POSIX compliance will do it for you. With those changes, wxPython now builds for me from source and it runs Bob's demo programs. without recompiling them. Cheers Bill Northcott

1 0

Re: [Pythonmac-SIG] a beginner's list
by Brendan Simons Feb. 9, 2006

Feb. 9, 2006

Some quick thoughts on previous posts: Lou Pecora wrote: > In addtion you are forgetting that we can have them install > TextWrangler (a no-brainer) and then run scripts from there. > Almost an IDE in some ways. I work that way from BBEdit and it's > fine. Write script, hit 'Run.' Terminal window opens up. Of > course, this does not address an interactive session ... or does > it. I never tried that in BBEdit. Possible? Not in textwrangler, but wxPython comes with a nice interactive shell (with code completion!) "PyCrust". It's built as a .app, so it installs and works like any other application on OS X http:// prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs- demos-2.6.2.1-macosx10.3-py2.4.dmg As to the parent question, I was extremely happy learning Python in Textwrangler until I broke down and bought Komodo. SPE is almost there, but still needs a binary install. On the other hand, the terminal is already there on everyone's machine. Christopher Barker wrote: > BTW, "Open Terminal Here" is a nifty applet you can put in your > finder that you can click on, and a terminal window will open, and > cd itself to the directory that the finder is currently viewing. > It's clearly an ugly hack, but it does the job: Here's another easy way to do the same thing: Open the terminal. Type "ls" followed by a space, but don't hit return. Now click on the finder and open the folder you want Terminal to access. In the titlebar of the finder window, next to the folder's name, is a little folder icon. Drag that icon to your terminal window (Expose helps if you have lots of windows open). Terminal will spell out the folder's path for you. Now return to Terminal and hit enter. > However, I think a consensus is building: > -- define the Framework installer for 2.4 as the "standard" and > most supported python for OS-X. (the existing build for 10.3 and > the universal build for 10.4) > -- also provide at least a quick tutorial for newbies, based on > the built-in Python, and put a link to it near the top of the main > page. > -- At the end of that tutorial, give an explanation of why (and > when) one might want to install the newer build of Python for > further work. I agree, but I would switch the order/emphasis. The page should start with a "Try it yourself" link, where we show them how Python can let them do useful and interesting things out of the box. Under that link, and at the end of the tutorial, you can have a "Get Better" link which details how to use framework python, easyinstall etc. www.rubyonrails.org has the right idea. Brendan -- Brendan Simons __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

wxPython 2.6.2.1 source build a new issue
by Bill Northcott Feb. 9, 2006

Feb. 9, 2006

If you try to build wxWidgets from the wxPython 2.6.2.1 sources with '--enable-optimize --disable-debug', configure creates setup.h in a release directory but the Makefile looks for it in a debug directory. Whoops! Maybe this is related to the problem with the monolithic build. Bill northcott

1 0

Re: [Pythonmac-SIG] a beginner's list
by linc Feb. 9, 2006

Feb. 9, 2006

> > Full disclosure: I'm a UNIX person. The first thing > I do when I get a > new Mac is make sure X11 is installed on it, and in my > Login Items. > The second thing I do is build an X11 version of GNU > Emacs from the > CVS repository. > Hi, This caught my eye. I have been using a Cocoa-based Emacs for a year or two, and it only has one font, kind of clumsy on my clamshell with the low resolution. Any tips on doing this, or do you know of any binary builds available? A real Emacs with X support would be awesome. Thanks, linc -- ACHTUNG!!! Das machine is nicht fur gefingerpoken und mittengrabben. Ist easy schnappen der springenwerk, blowenfusen und corkenpoppen mit spitzensparken. Ist nicht fur gewerken by das dummkopfen. Das rubbernecken sightseeren keepen hands in das pockets. Relaxen und vatch das blinkenlights!!!

3 2

[Fwd: [visionegg] 2 problems setting up 2 screen window (OSX 10.3.9)]
by Douglas Taylor Feb. 8, 2006

Feb. 8, 2006

Hi All, I'm forwarding this message I sent to the VisionEgg list as they couldn't help me there. Basically there are 2 problems. 1) I can't hide the toolbar when not in FULLSCREEN. From the post below it seems it used to work. 2) If I try and cover both monitors with the window the screens whithens out and I can see no rendering when I ask for a 2048x768 window. If I go down to 2046x768 it works fine but there are 2 lines of the background screen visible. I am using pygame 1.7.0 Thanks for any help. Doug Taylor -------- Original Message -------- Subject: [visionegg] 2 problems setting up 2 screen window (OSX 10.3.9) Date: Wed, 08 Feb 2006 12:07:34 -0800 From: Douglas Taylor <dtaylor(a)ski.org> Reply-To: visionegg(a)freelists.org To: visionegg(a)freelists.org Hi Andrew and All, I'm trying to get a 2 screen setup going to demo some stereo stimuli. The following works as advertised import os os.environ['SDL_VIDEO_WINDOW_POS']="0,0" Trying to get rid of the toolbar does not. I followed the example from Andrew's post > import pygame.macosx > pygame.macosx.app.mainMenu().setMenuBarVisible_(False) http://mail.python.org/pipermail/pythonmac-sig/2003-August/008482.html The error I get pygame.macosx.app.mainMenu().setMenuBarVisible_(False) AttributeError: 'module' object has no attribute 'app' My pygame is pygame version 1.7.0 (OK) Do I need a newer version of pygame? I have 2 monitors both at 1024x768 resolution. When I request a window 2048x768 the window is whited out and no rendering can be seen. The max. screen size I could ask for is 2046x768 to see my stim. Any ideas what going on here? Thanks for any help. Doug ====================================== The Vision Egg mailing list Archives: http://www.freelists.org/archives/visionegg Website: http://www.visionegg.org/mailinglist.html

1 0

Re: [Pythonmac-SIG] Fwd: New Page, first proposal
by Louis Pecora Feb. 8, 2006

Feb. 8, 2006

Charles, First, good start. You've really thought this through and I see the replies are coming fast and hard. Second, Chris Barker ( I called you Baker before, my apologies) had some good replies most of which I agree with. I will add what little I have to his. I think the issue of a standard Python version is important, but I still emphasize not disparaging Apple's, but treating it as a demo/test-drive version. Most people understand the concept of demo programs that they can try out and then full-featured versions that they can graduate to. I would not give that up. It's a nice, easy intro for anyone. That will mean a little tutorial in the beginner's section on how to use the pre-installed 2.3.x version. It's worth it. I would not relegate the C/C++ extensions to another page. Many technical people come from the land of MatLab or Mathematica, etc. and are fully aware of the idea of extending a programming front end using some type of faster compiled functions. Catch their eye on the first page. Then a link to more info. Chris suggested the first page be beginner-oriented (I think he meant that), but I would just say keep the short headers for the advanced stuff and up the visibility of the beginner's page early on (probably in your [1]). And now just a few more suggestions, Charles Hartman wrote: > > > Begin forwarded message: > >> *From: *Charles Hartman <charles.hartman(a)conncoll.edu >> <mailto:charles.hartman@conncoll.edu>> >> >> For a page title that covers the ground broadly and accurately, I propose >> Python on the Mac >> Problems with that? Better suggestions? A subtitle ? What you need to use Python on Mac OS X. (that addresses Chris' OS X or Classic question) >> >> Four stages in the project are foreseeable: >> 1. Establish the basic organization of the page >> 2. Collect the essential technical data, and probably also less >> essential materials >> to be relegated to secondary pages >> 3. Produce some friendly prose >> 4. Build the html for the page >> >> #4 is fun, and I wouldn't mind doing it in DreamWeaver if nobody else >> has better tools and skills. #3 is easy enough, though checking it >> for accuracy needs to be a community effort. I am not competent to do >> #2, but this list is full of people who are. Glad you can do #4, because I don't have a clue (I guess you can do Wiki since Chris keeps saying it -- that would be nice). #3 I can help with for beginners (because I'm not that far from one). >> >> ===== the Python-on-the-Mac page ======================= >> >> [1] "If you're a Mac user who wants to learn to write Python programs": >> note Apple distro, be politely disparaging toward it, provide links to Here's where you put a prominent link to a BEGINNER'S PAGE. and maybe mentioning here Apple's distro as a test drive (don't be disparaging, just emphasize how much better the advanced version is). >> Bob's framework, with notes (how extensive is this?) on other stuff >> required >> ActiveState's framework, with similar notes >> provide links to >> how-to-program sites >> how-to-program-in-Python sites >> how-to-program-for-the-Mac sites >> >> SWIG, pyrex, --- I'm sure others will suggest many more. Let me read more replies to catch up. More later. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora(a)anvil.nrl.navy.mil

1 0

More on Beginner's list - the 2.4.1 Install
by Louis Pecora Feb. 8, 2006

Feb. 8, 2006

OK, you guys have twisted this non-pro's arm enough. I just installed Python 2.4.1 on my Tiger machine from Bob Ippolito's site (not the active state one, but the framework). Yes, I followed up with the TigerFix install. But I still get Python 2.3.5 when I start python in my terminal. HAHAHAHAHAHA. Chris, Bob, just kidding. Just kidding. I've seen that one so much on this list that even I remembered to edit my .tcshrc file and put /usr/local/bin before /usr/bin. So for Charles H. and all of us working on the Beginner's list. For the install of 2.4.1 as a separate, better Python we need to add, 1) Get the Python 2.4.1 package from Bob Ippolito's site [the link here] (thank you, Bob, very much) 2) If you're running Tiger (10.4.x) also get the TigerFix package [the link here] 3) Install Python 2.4.1 -- maybe a little detail for those who haven't seen .dmg files and packages. 4) Install TigerFix 5) Edit your appropriate terminal login file (.profile, .bash_profile, .tcshrc, etc -- maybe listing which go with which shell and maybe for the novices how you find and edit hidden files!). Put /usr/local/bin before /usr/bin in the path. I guess the whole path thing should be spelled out. 6) Remind people that if they are using pythonw so they can open GUI things, that pythonw 2.4.1 is also installed with the 2.4.1 package and is used automatically once you change the login file. In the vein of someone else here who recommended we not denigrate the Apple installed Python, I agree. Just treat that like software companies do a demo or "stripped-down" version of their application. You can use it for simple stuff. Take Python for a test drive and see if you like it. How nice. No need to puzzle over complex installation and package dependencies. Just hop in and turn the key. Then, oh, by the way, if you want a better version that offers even more, here's a simple way to get it (directions as above). I'm sure there's more that can be added to this and I'm willing to write more (including about paths -- as much/little as I know) for the beginner's list. Charles H. tell me what might help. To everyone, Please correct any of the above. I am not an expert. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora(a)anvil.nrl.navy.mil

2 1