From ronaldoussoren at mac.com Sat Apr 1 07:55:50 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 1 Apr 2006 07:55:50 +0200 Subject: [Pythonmac-SIG] Wiki Formatting In-Reply-To: <442C5DE0.2070204@noaa.gov> References: <4429A81C.9010805@noaa.gov> <442B2777.9080904@noaa.gov> <442C1C86.1040401@chem.unr.edu> <442C3CE5.80202@noaa.gov> <0C75392C-17CA-422F-9378-FCCF42AF6A15@mac.com> <442C5DE0.2070204@noaa.gov> Message-ID: <69678EBF-DBC4-4630-8B07-18B7102079E8@mac.com> On 31-mrt-2006, at 0:38, Christopher Barker wrote: > Ronald Oussoren wrote: >> I'd prefer not to have seperate Intel and PPC binaries. Would merging >> seperate >> Intel and PPC builds be of any use? > > Yes, though I'm not sure what you mean by merging. > > Do you mean lipo'ing them together? or having separate builds in > one *.mpkg? The former, to seperate builds in one package wouldn't be to usefull as you mention below. > > Ideally, we could get it all truly Universal, then one could build > Universal Py2App bundles with it and all. > > I think the big trick with SciPy is the Fortran components. SciPy, > Fortran and gcc 4 have been having trouble for a while. If that's > fixed, > I have no idea about how to build Universal binaries with gfortran or > g95. Does anyone know? IIRC both are frontends for GCC. You could probably build them using Apple's version of GCC (downloadable from Apple's opensource site) and then get the multiple-arch bit for free. The other alternative is a script that compiles using a compiler for intel, then with a compiler for ppc and finally uses lipo to merge the two. > > > While I'm on the topic, I'm looking into building Universal > binaries of > some other packages that depend on other libs. For instance, > matplotlib > depends on libpng and libfreetype. In the past, I've built static libs > of those, and then linked MPL against them, getting a nice > self-contained package. However, I have no idea how I would go about > building Universal static libs, or two sets of libs, or???? That depends :-) For my universal python build you definitely want to end up with Universal static libs. If configure doesn't check for CPU features (like sizeof(int) and byteorder) you can most likely get away with adding 'CFLAGS="-arch i386 -arch ppc -isysroot ..." LDFLAGS="-arch i386 - arch ppc -isysroot ..."' to the arguments of configure. Otherwise you either have to patch the sources (like we did for python), or create two builds and them lipo them together. I have a script to do the latter somewhere. Ronald > > Any suggestions? > > -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 at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Sat Apr 1 07:56:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 1 Apr 2006 07:56:59 +0200 Subject: [Pythonmac-SIG] PyObjC In-Reply-To: <85077387-5B03-4F83-B647-A323BD5D2A98@lexar.com> References: <2067FFEC-10B3-4AF5-9E35-060A5ABC4624@lexar.com> <13FA3F95-E1C6-4939-A0CD-2C047E95C648@usno.navy.mil> <85077387-5B03-4F83-B647-A323BD5D2A98@lexar.com> Message-ID: <63C8CA22-2C82-484C-9617-496A6BB2C3F2@mac.com> On 31-mrt-2006, at 1:01, Dan Grassi wrote: > Hi, > > I had embedded python under 10.3.x but under 10.4 it fails on import > from Foundation import * > It seems that the problem is that it is launching the wrong python. > > sys.path: ['/System/Library/Frameworks/Python.framework/Versions/ > 2.3/lib/python23.zip'... > > I have installed > MacPython-OSX-2.4.1-1.dmg > and > TigerPython24Fix-r2.mpkg > > I am including: > /Library/Frameworks/Python.framework/ > which has: > /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ > site-packages/PyObjC/ > > What am I missing that I need to setup? You're linking with the system python instead of the one you include in your application bundle. Ronald > > TIA, > > Dan_______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Sun Apr 2 05:02:56 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 1 Apr 2006 19:02:56 -0800 Subject: [Pythonmac-SIG] The Universal Buld and py2app In-Reply-To: References: <06Mar27.113702pst.58633@synergy1.parc.xerox.com> <5FB132E3-C499-4C2A-A927-CAEAE1839855@redivi.com> <44286D61.1070504@noaa.gov> <2CDC34C5-909B-4642-93EA-9BC73B05156D@redivi.com> <44288D18.6080400@noaa.gov> Message-ID: On Mar 27, 2006, at 5:29 PM, Bob Ippolito wrote: > > On Mar 27, 2006, at 5:10 PM, Christopher Barker wrote: > >> Bob, >> >> What's the status of Py2App and the new universal build. I'd like >> to start making packages for it, but I"d really like bdist_mpkg. > > Not Yet. I have some patches I need to integrate and test. I'll try > and get to it this weekend, maybe sooner. Ok, I got the patches in and I think they work now (despite the date). The patches were kinda busted and had tabs(!) but on trivial examples it seems to work. The branch with the patches is here: http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint (this is what is currently referenced by pyobjc's trunk as well). If enough people try this out and report that it works, then I'll wrap it up and make a release. -bob From cookedm at physics.mcmaster.ca Sun Apr 2 12:15:46 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Sun, 02 Apr 2006 06:15:46 -0400 Subject: [Pythonmac-SIG] Numpy Scipy and Darwinports In-Reply-To: <442D99D9.4060301@gmail.com> (Robert Kern's message of "Fri, 31 Mar 2006 15:06:33 -0600") References: <604B6946-5478-40FB-895E-251A83D437B2@free.fr> <442D99D9.4060301@gmail.com> Message-ID: Robert Kern writes: > David M. Cooke wrote: >> Jaonary Rabarisoa writes: >> >> >>>Hi all, >>>I'd like to build numpy and scipy with the gcc 4.1 provided by >>>darwinport (I fact, they need a fortran compiler). How can I do to >>>change the compiler to be used with distutils ? I've tried something >>>like this : >>> >>>python setup.py build --compiler=gcc-dp-4.1 ( all the file installed >>>with darwinports have the suffix -dp-4.1) >>> >>>but I didn't work. >> >> Use the CC environment variable: >> >> CC=gcc-dp-4.1 python setup.py build >> >> However, note that gfortran will *not* work with scipy: we don't know >> why, but we believe to be something to do with gfortran not being >> stable yet. I tested it recently; still no go. > > IIRC, someone found that gfortran 4.1 will work if d1mach.f is compiled with > only -O, not -O2. Possibly -ffloat-store, too, I don't remember. I'll have to try that out. > In any case, numpy.distutils doesn't let you set the name of the fortran > compiler through an environment variable, I don't think. I recommend making a > symlink named "gfortran" to the actual executable. Then: Actually, it does: it looks for F77 and F90 environment variables, along with F77FLAGS, F90FLAGS, FREEFLAGS, and FFLAGS. The code is in numpy/distutils/fcompiler/__init__.py:FCompiler.customize. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From andrew at trevorrow.com Mon Apr 3 08:00:19 2006 From: andrew at trevorrow.com (Andrew Trevorrow) Date: Mon, 3 Apr 2006 16:00:19 +1000 Subject: [Pythonmac-SIG] problem linking app with embedded Python Message-ID: I recently added Python scripting to our app (an open source, cross-platform Life app called Golly; see http://golly.sourceforge.net/ if you're interested). Based on what I read at http://pythonmac.org/wiki/FAQ (excellent resource BTW), our makefile uses these variables when compiling and linking: PYTHON_INCLUDE = -I`python -c "import distutils.sysconfig; print distutils.sysconfig.get_python_inc()"` PYTHON_LINK = `python -c "import distutils.sysconfig; print distutils.sysconfig.get_config_var('LINKFORSHARED')"` This works fine on OS 10.3.9, but on an Intel Mac running OS 10.4.5 the link step fails because PYTHON_LINK is set to this: -u __dummy -u _PyMac_Error -framework System Python.framework/Versions/2.3/Python -framework CoreServices -framework Foundation Does anybody know why it contains "Python.framework/Versions/2.3/Python" rather than "-framework Python"? I can fix the problem by explicitly using PYTHON_LINK = -u __dummy -u _PyMac_Error -framework System -framework Python -framework CoreServices -framework Foundation but presumably that's not a good long-term solution. This is my first project using gcc, makefiles, frameworks, Python, etc, so I'm still somewhat foggy about lots of things. Any advice would be much appreciated! Andrew From charles.hartman at conncoll.edu Tue Apr 4 14:19:23 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 4 Apr 2006 08:19:23 -0400 Subject: [Pythonmac-SIG] future of python/w Message-ID: I remember this came up recently, but I don't know where it's coming out: Is it likely that the python/pythonw distinction will disappear? I ask because I have to write a getting-started sheet for some students taking up Python, on various platforms. I know that any time I can eliminate a branch, incomprehension diminishes by 36.8%, so getting rid of "If you're on a Mac, this line should end with 'pythonw' rather than 'python' ?" would be nice. Charles Hartman From ronaldoussoren at mac.com Tue Apr 4 14:22:42 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 4 Apr 2006 14:22:42 +0200 Subject: [Pythonmac-SIG] future of python/w In-Reply-To: References: Message-ID: <78717358-AA97-40EA-899C-2721D1F58BED@mac.com> On 4-apr-2006, at 14:19, Charles Hartman wrote: > I remember this came up recently, but I don't know where it's coming > out: Is it likely that the python/pythonw distinction will disappear? > > I ask because I have to write a getting-started sheet for some > students taking up Python, on various platforms. I know that any time > I can eliminate a branch, incomprehension diminishes by 36.8%, so > getting rid of "If you're on a Mac, this line should end with > 'pythonw' rather than 'python' ?" would be nice. If you use my universal build python and pythonw are the same binary. Ronald > > Charles Hartman > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From charles.hartman at conncoll.edu Tue Apr 4 14:28:15 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 4 Apr 2006 08:28:15 -0400 Subject: [Pythonmac-SIG] future of python/w In-Reply-To: <78717358-AA97-40EA-899C-2721D1F58BED@mac.com> References: <78717358-AA97-40EA-899C-2721D1F58BED@mac.com> Message-ID: <80995E1C-1C73-414D-A329-F6019C2FD09C@conncoll.edu> Excellent news. I'll hope that, by the time these students get going (they'll be using wxPython), there will be a wxPython Universal too. Thanks! coh On Apr 4, 2006, at 8:22 AM, Ronald Oussoren wrote: > > On 4-apr-2006, at 14:19, Charles Hartman wrote: > >> I remember this came up recently, but I don't know where it's coming >> out: Is it likely that the python/pythonw distinction will disappear? >> >> I ask because I have to write a getting-started sheet for some >> students taking up Python, on various platforms. I know that any time >> I can eliminate a branch, incomprehension diminishes by 36.8%, so >> getting rid of "If you're on a Mac, this line should end with >> 'pythonw' rather than 'python' ?" would be nice. > > If you use my universal build python and pythonw are the same binary. > > Ronald >> >> Charles Hartman >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > From Chris.Barker at noaa.gov Tue Apr 4 18:07:08 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 04 Apr 2006 09:07:08 -0700 Subject: [Pythonmac-SIG] future of python/w In-Reply-To: <80995E1C-1C73-414D-A329-F6019C2FD09C@conncoll.edu> References: <78717358-AA97-40EA-899C-2721D1F58BED@mac.com> <80995E1C-1C73-414D-A329-F6019C2FD09C@conncoll.edu> Message-ID: <443299AC.6030902@noaa.gov> Charles Hartman wrote: > Excellent news. I'll hope that, by the time these students get going When might that be? weeks? maybe not. Months? probably. Charles Hartman wrote: >>> I ask because I have to write a getting-started sheet for some >>> students taking up Python, on various platforms. I hope you'll put it on the wiki or somewhere for all to see. -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 at noaa.gov From charles.hartman at conncoll.edu Tue Apr 4 19:17:35 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 4 Apr 2006 13:17:35 -0400 Subject: [Pythonmac-SIG] future of python/w In-Reply-To: <78b3a9580604040941p3222a0dbn7f6e9d8f9eca65d3@mail.gmail.com> References: <78717358-AA97-40EA-899C-2721D1F58BED@mac.com> <80995E1C-1C73-414D-A329-F6019C2FD09C@conncoll.edu> <443299AC.6030902@noaa.gov> <78b3a9580604040941p3222a0dbn7f6e9d8f9eca65d3@mail.gmail.com> Message-ID: The students won't begin on this until September. So that means -- knowing me -- the how-to sheet won't get done until the last week of August. I imagine we'll have wx long before then. (And hooray for the new book on wxPython by the way -- it's an excellent intro, though it's not an intro to Python itself.) Charles Hartman On Apr 4, 2006, at 12:41 PM, w chun wrote: > On 4/4/06, Christopher Barker wrote: >> Charles Hartman wrote: >>> Excellent news. I'll hope that, by the time these students get going >> >> When might that be? weeks? maybe not. Months? probably. >> >> Charles Hartman wrote: >>>>> I ask because I have to write a getting-started sheet for some >>>>> students taking up Python, on various platforms. >> >> I hope you'll put it on the wiki or somewhere for all to see. > > please also Xpost it to the edu-sig group too! > http://mail.python.org/mailman/listinfo/edu-sig > > thanks, > -- wesley > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "Core Python Programming", Prentice Hall, (c)2007,2001 > http://corepython.com > > wesley.j.chun :: wescpy-at-gmail.com > python training and technical consulting > cyberweb.consulting : silicon valley, ca > http://cyberwebconsulting.com From wescpy at gmail.com Tue Apr 4 18:41:25 2006 From: wescpy at gmail.com (w chun) Date: Tue, 4 Apr 2006 09:41:25 -0700 Subject: [Pythonmac-SIG] future of python/w In-Reply-To: <443299AC.6030902@noaa.gov> References: <78717358-AA97-40EA-899C-2721D1F58BED@mac.com> <80995E1C-1C73-414D-A329-F6019C2FD09C@conncoll.edu> <443299AC.6030902@noaa.gov> Message-ID: <78b3a9580604040941p3222a0dbn7f6e9d8f9eca65d3@mail.gmail.com> On 4/4/06, Christopher Barker wrote: > Charles Hartman wrote: > > Excellent news. I'll hope that, by the time these students get going > > When might that be? weeks? maybe not. Months? probably. > > Charles Hartman wrote: > >>> I ask because I have to write a getting-started sheet for some > >>> students taking up Python, on various platforms. > > I hope you'll put it on the wiki or somewhere for all to see. please also Xpost it to the edu-sig group too! http://mail.python.org/mailman/listinfo/edu-sig thanks, -- wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2007,2001 http://corepython.com wesley.j.chun :: wescpy-at-gmail.com python training and technical consulting cyberweb.consulting : silicon valley, ca http://cyberwebconsulting.com From toddobryan at mac.com Tue Apr 4 20:49:09 2006 From: toddobryan at mac.com (Todd O'Bryan) Date: Tue, 4 Apr 2006 14:49:09 -0400 Subject: [Pythonmac-SIG] PyXML install problems Message-ID: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> I just posted this to XML-SIG, but someone suggested the Mac list would be more helpful. (Aren't the Mac lists always more helpful?) Anyway... I have Mac OS X, 10.4.6 (updated this morning) with the new Python 2.4.3 Universal Binary just released at python.org. I'm trying to install PyXML, but having problems. It appears that, for some reason, gcc is not looking in /usr/include for header files. I've tried looking through setup.py to see what was going on, but I'm a Python newbie and just got lost in the code. For reference, /usr/include/limits.h does exist, and which gcc produces /usr/bin/gcc which is a link to /usr/bin/gcc-4.0 which seems to be the binary. Any ideas? Output of python setup.py build is given below. Thanks, Todd running build running build_py running build_ext building '_xmlplus.parsers.pyexpat' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -DXML_NS=1 -DXML_DTD=1 - DBYTEORDER=4321 -DXML_CONTEXT_BYTES=1024 -DHAVE_MEMMOVE=1 - Iextensions/expat/lib -I/Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4 -c extensions/pyexpat.c -o build/ temp.macosx-10.4-fat-2.4/extensions/pyexpat.o gcc: installation problem, cannot exec 'i686-apple-darwin8- gcc-4.0.0': No such file or directory In file included from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:18:20: error: limits.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:21:2: error: #error "Something's broken. UCHAR_MAX should be defined in limits.h." /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:25:2: error: #error "Python's source code assumes C's unsigned char is an 8-bit type." /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:32:19: error: stdio.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:34:5: error: #error "Python.h requires that stdio.h define NULL." /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:37:20: error: string.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:38:19: error: errno.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:39:20: error: stdlib.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:41:20: error: unistd.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:53:20: error: assert.h: No such file or directory In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:55, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:90:76: error: math.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:97:22: error: sys/time.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:98:18: error: time.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:116:24: error: sys/select.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:155:22: error: sys/stat.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:395:21: error: termios.h: No such file or directory In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:55, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:396: warning: 'struct winsize' declared inside parameter list /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:396: warning: its scope is only this definition or declaration, which is probably not what you want /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:396: warning: 'struct termios' declared inside parameter list /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:397: warning: 'struct winsize' declared inside parameter list /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:397: warning: 'struct termios' declared inside parameter list In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:74, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pymem.h:50: warning: parameter names (without types) in function declaration /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pymem.h:51: error: parse error before "size_t" In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:76, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ object.h:227: error: parse error before "FILE" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ object.h:371: error: parse error before "FILE" In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:77, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ objimpl.h:97: warning: parameter names (without types) in function declaration /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ objimpl.h:98: error: parse error before "size_t" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ objimpl.h:292: warning: parameter names (without types) in function declaration In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:81, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ unicodeobject.h:55:19: error: ctype.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ unicodeobject.h:118:21: error: wchar.h: No such file or directory In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:81, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ unicodeobject.h:511: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ unicodeobject.h:529: error: parse error before '*' token In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:84, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ longobject.h:63: error: parse error before "_PyLong_NumBits" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ longobject.h:63: warning: data definition has no type or storage class /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ longobject.h:79: error: parse error before "size_t" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ longobject.h:102: error: parse error before "size_t" In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:90, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ stringobject.h:10:20: error: stdarg.h: No such file or directory In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:90, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ stringobject.h:63: error: parse error before "va_list" In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:101, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:12: error: parse error before "FILE" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:12: warning: no semicolon at end of struct or union /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:15: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:28: error: parse error before '}' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:28: warning: data definition has no type or storage class /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:38: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:39: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:40: warning: data definition has no type or storage class /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:57: error: parse error before "FILE" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:58: error: parse error before "Py_UniversalNewlineFread" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:58: error: parse error before "size_t" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ fileobject.h:58: warning: data definition has no type or storage class In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:112, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyerrors.h:226: error: parse error before "size_t" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyerrors.h:228: error: parse error before "size_t" In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:116, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ modsupport.h:20: error: parse error before "va_list" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ modsupport.h:22: error: parse error before "va_list" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ modsupport.h:23: error: parse error before "va_list" In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:117, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:32: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:33: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:35: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:36: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:40: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:41: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:42: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:43: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:44: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:45: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:46: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:49: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:55: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:59: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:60: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:64: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:66: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:82: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:123: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pythonrun.h:125: error: parse error before '*' token In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:119, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ sysmodule.h:12: error: parse error before '*' token /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ sysmodule.h:12: error: parse error before "FILE" /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ sysmodule.h:12: warning: data definition has no type or storage class In file included from /Library/Frameworks/Python.framework/Versions/ 2.4/include/python2.4/Python.h:121, from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ import.h:25: error: parse error before "size_t" In file included from extensions/pyexpat.c:5: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:131: error: parse error before "size_t" In file included from extensions/pyexpat.c:10: extensions/expat/lib/expat.h:189: error: parse error before "size" extensions/expat/lib/expat.h:190: error: parse error before "size_t" extensions/expat/lib/expat.h:936: error: parse error before "size_t" extensions/expat/lib/expat.h:939: error: parse error before "size_t" extensions/pyexpat.c: In function 'set_error_attr': extensions/pyexpat.c:112: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c:112: error: (Each undeclared identifier is reported only once extensions/pyexpat.c:112: error: for each function it appears in.) extensions/pyexpat.c: In function 'set_error': extensions/pyexpat.c:134: warning: incompatible implicit declaration of built-in function 'sprintf' extensions/pyexpat.c:138: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'have_handler': extensions/pyexpat.c:151: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'get_handler_name': extensions/pyexpat.c:158: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'conv_string_to_unicode': extensions/pyexpat.c:177: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c:181: warning: incompatible implicit declaration of built-in function 'strlen' extensions/pyexpat.c: In function 'conv_string_len_to_unicode': extensions/pyexpat.c:190: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'conv_string_to_utf8': extensions/pyexpat.c:207: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'conv_string_len_to_utf8': extensions/pyexpat.c:220: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'getcode': extensions/pyexpat.c:255: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'trace_frame': extensions/pyexpat.c:310: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'trace_frame_exc': extensions/pyexpat.c:337: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'call_with_frame': extensions/pyexpat.c:375: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'string_intern': extensions/pyexpat.c:431: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'call_character_handler': extensions/pyexpat.c:448: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'flush_character_buffer': extensions/pyexpat.c:482: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_CharacterDataHandler': extensions/pyexpat.c:493: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c:510: warning: incompatible implicit declaration of built-in function 'memcpy' extensions/pyexpat.c: In function 'my_StartElementHandler': extensions/pyexpat.c:537: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_EndElementHandler': extensions/pyexpat.c:636: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_ProcessingInstructionHandler': extensions/pyexpat.c:640: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_UnparsedEntityDeclHandler': extensions/pyexpat.c:646: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_EntityDeclHandler': extensions/pyexpat.c:676: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_XmlDeclHandler': extensions/pyexpat.c:696: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'conv_content_model': extensions/pyexpat.c:709: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_ElementDeclHandler': extensions/pyexpat.c:737: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_AttlistDeclHandler': extensions/pyexpat.c:785: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_SkippedEntityHandler': extensions/pyexpat.c:798: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_NotationDeclHandler': extensions/pyexpat.c:806: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_StartNamespaceDeclHandler': extensions/pyexpat.c:816: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_EndNamespaceDeclHandler': extensions/pyexpat.c:823: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_CommentHandler': extensions/pyexpat.c:828: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_StartCdataSectionHandler': extensions/pyexpat.c:832: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_EndCdataSectionHandler': extensions/pyexpat.c:836: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_DefaultHandler': extensions/pyexpat.c:849: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_DefaultHandlerExpandHandler': extensions/pyexpat.c:855: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_NotStandaloneHandler': extensions/pyexpat.c:862: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_ExternalEntityRefHandler': extensions/pyexpat.c:866: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_StartDoctypeDeclHandler': extensions/pyexpat.c:881: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'my_EndDoctypeDeclHandler': extensions/pyexpat.c:889: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'get_parse_result': extensions/pyexpat.c:897: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'xmlparse_Parse': extensions/pyexpat.c:920: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'readinst': extensions/pyexpat.c:932: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c:970: warning: incompatible implicit declaration of built-in function 'memcpy' extensions/pyexpat.c: In function 'xmlparse_ParseFile': extensions/pyexpat.c:986: error: 'FILE' undeclared (first use in this function) extensions/pyexpat.c:986: error: 'fp' undeclared (first use in this function) extensions/pyexpat.c:987: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'xmlparse_SetBase': extensions/pyexpat.c:1050: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'xmlparse_GetBase': extensions/pyexpat.c:1066: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'xmlparse_GetInputContext': extensions/pyexpat.c:1080: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'xmlparse_ExternalEntityParserCreate': extensions/pyexpat.c:1112: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c:1134: warning: incompatible implicit declaration of built-in function 'malloc' extensions/pyexpat.c:1175: warning: incompatible implicit declaration of built-in function 'malloc' extensions/pyexpat.c: In function 'xmlparse_SetParamEntityParsing': extensions/pyexpat.c:1208: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: In function 'xmlparse_UseForeignDTD': extensions/pyexpat.c:1226: error: 'NULL' undeclared (first use in this function) extensions/pyexpat.c: At top level: extensions/pyexpat.c:1261: error: 'NULL' undeclared here (not in a function) extensions/pyexpat.c:1261: error: initializer element is not constant extensions/pyexpat.c:1261: error: (near initialization for 'xmlparse_methods[8].ml_name') extensions/pyexpat.c:1261: error: initializer element is not constant extensions/pyexpat.c:1261: error: (near initialization for 'xmlparse_methods[8].ml_meth') extensions/pyexpat.c:1261: error: initializer element is not constant extensions/pyexpat.c:1261: error: (near initialization for 'xmlparse_methods[8]') extensions/pyexpat.c: In function 'newxmlparseobject': extensions/pyexpat.c:1377: warning: incompatible implicit declaration of built-in function 'malloc' extensions/pyexpat.c: In function 'xmlparse_setattr': extensions/pyexpat.c:1581: warning: incompatible implicit declaration of built-in function 'malloc' extensions/pyexpat.c: At top level: extensions/pyexpat.c:1677: error: initializer element is not constant extensions/pyexpat.c:1677: error: (near initialization for 'Xmlparsetype.ob_type') extensions/pyexpat.c: In function 'pyexpat_ParserCreate': extensions/pyexpat.c:1728: error: initializer element is not constant extensions/pyexpat.c:1728: error: (near initialization for 'kwlist[3]') extensions/pyexpat.c:1734: warning: incompatible implicit declaration of built-in function 'strlen' extensions/pyexpat.c: At top level: extensions/pyexpat.c:1784: error: initializer element is not constant extensions/pyexpat.c:1784: error: (near initialization for 'pyexpat_methods[2].ml_name') extensions/pyexpat.c:1784: error: initializer element is not constant extensions/pyexpat.c:1784: error: (near initialization for 'pyexpat_methods[2].ml_meth') extensions/pyexpat.c:1784: error: initializer element is not constant extensions/pyexpat.c:1784: error: (near initialization for 'pyexpat_methods[2].ml_doc') extensions/pyexpat.c:1784: error: initializer element is not constant extensions/pyexpat.c:1784: error: (near initialization for 'pyexpat_methods[2]') extensions/pyexpat.c:2107: error: initializer element is not constant extensions/pyexpat.c:2107: error: (near initialization for 'handler_info[22].name') extensions/pyexpat.c:2107: error: initializer element is not constant extensions/pyexpat.c:2107: error: (near initialization for 'handler_info[22].setter') extensions/pyexpat.c:2107: error: initializer element is not constant extensions/pyexpat.c:2107: error: (near initialization for 'handler_info[22].handler') extensions/pyexpat.c:2107: error: initializer element is not constant extensions/pyexpat.c:2107: error: (near initialization for 'handler_info[22]') lipo: can't figure out the architecture type of: /var/tmp//ccUGGzrt.out error: command 'gcc' failed with exit status 255 From janssen at parc.com Tue Apr 4 21:38:57 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 4 Apr 2006 12:38:57 PDT Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: Your message of "Tue, 04 Apr 2006 11:49:09 PDT." <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> Message-ID: <06Apr4.123903pdt."58633"@synergy1.parc.xerox.com> > I have Mac OS X, 10.4.6 (updated this morning) with the new Python > 2.4.3 Universal Binary just released at python.org. Time to update the downloads page? Bill From bob at redivi.com Tue Apr 4 21:39:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 4 Apr 2006 12:39:23 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> References: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> Message-ID: <955AC211-A96C-472F-9862-5F2237ABB769@redivi.com> On Apr 4, 2006, at 11:49 AM, Todd O'Bryan wrote: > I just posted this to XML-SIG, but someone suggested the Mac list > would be more helpful. (Aren't the Mac lists always more helpful?) > > Anyway... > > I have Mac OS X, 10.4.6 (updated this morning) with the new Python > 2.4.3 Universal Binary just released at python.org. > > I'm trying to install PyXML, but having problems. It appears that, > for some reason, gcc is not looking in /usr/include for header files. > I've tried looking through setup.py to see what was going on, but I'm > a Python newbie and just got lost in the code. > > For reference, /usr/include/limits.h does exist, and which gcc > produces /usr/bin/gcc which is a link to /usr/bin/gcc-4.0 which seems > to be the binary. > > Any ideas? Output of python setup.py build is given below. When using the universal build, you need to have the universal SDK installed. It looks like you don't. -bob From Chris.Barker at noaa.gov Tue Apr 4 23:18:29 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 04 Apr 2006 14:18:29 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <955AC211-A96C-472F-9862-5F2237ABB769@redivi.com> References: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> <955AC211-A96C-472F-9862-5F2237ABB769@redivi.com> Message-ID: <4432E2A5.1090808@noaa.gov> Bob Ippolito wrote: > When using the universal build, you need to have the universal SDK > installed. It looks like you don't. Do you get that if you install the latest XCode tools? -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 at noaa.gov From Chris.Barker at noaa.gov Tue Apr 4 23:21:09 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 04 Apr 2006 14:21:09 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> Message-ID: <4432E345.7080402@noaa.gov> Bill Janssen wrote: > Time to update the downloads page? I'm not sure. We don't have a single Universal package available yet. However, it does work, on PPC, with the packages for the 2.4.1 Framework build. If you use it on Intel, however, you're stuck with building everything yourself, and I don't know how universally that works. I'd be inclined to wait until we have a core of commonly used packages available. -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 at noaa.gov From bob at redivi.com Tue Apr 4 23:56:18 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 4 Apr 2006 14:56:18 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <4432E2A5.1090808@noaa.gov> References: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> <955AC211-A96C-472F-9862-5F2237ABB769@redivi.com> <4432E2A5.1090808@noaa.gov> Message-ID: On Apr 4, 2006, at 2:18 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> When using the universal build, you need to have the universal SDK >> installed. It looks like you don't. > > Do you get that if you install the latest XCode tools? I don't know if it's installed by default yet, but it's definitely been in the past few releases of Xcode. It might be an optional part of the install. -bob From daniellord at mac.com Wed Apr 5 02:37:51 2006 From: daniellord at mac.com (Daniel Lord) Date: Tue, 4 Apr 2006 17:37:51 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: References: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> <955AC211-A96C-472F-9862-5F2237ABB769@redivi.com> <4432E2A5.1090808@noaa.gov> Message-ID: <9C89C4E5-BDE3-4DEA-89BC-0308E5980825@mac.com> Would this be a good way ti quickly figure it out: daniello ~ cc -arch i386 i686-apple-darwin8-gcc-4.0.1: no input files It looks like the compiler identifies itself as Intel-capable i.e. i686. Of course that is no guarantee the includes and libs are there, but its a good way to bet. I have Xcode 2.2.1 installed plus updated documentation for March 2006 (a whopping 270+MB download). As an aside and cautionary tale: I am just getting back on line--the 10.4.5 upgrade started corrupting files and eventually disk buffers and the super block. It seems I have had marginal DDR RAM for a few years, but it took the latest upgrade to really bring the problems to the fore. When Apple cautions you about buying cheap RAM--believe it! On Apr 4, 2006, at 2:56 PM, Bob Ippolito wrote: > > On Apr 4, 2006, at 2:18 PM, Christopher Barker wrote: > >> Bob Ippolito wrote: >>> When using the universal build, you need to have the universal SDK >>> installed. It looks like you don't. >> >> Do you get that if you install the latest XCode tools? > > I don't know if it's installed by default yet, but it's definitely > been in the past few releases of Xcode. It might be an optional part > of the install. > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Wed Apr 5 03:04:14 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 4 Apr 2006 18:04:14 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <9C89C4E5-BDE3-4DEA-89BC-0308E5980825@mac.com> References: <5AA85160-CF36-459D-9067-E617B3AD998D@mac.com> <955AC211-A96C-472F-9862-5F2237ABB769@redivi.com> <4432E2A5.1090808@noaa.gov> <9C89C4E5-BDE3-4DEA-89BC-0308E5980825@mac.com> Message-ID: <4DD05E9D-4F2E-42EC-91D0-E3BCA4DA5B22@redivi.com> On Apr 4, 2006, at 5:37 PM, Daniel Lord wrote: > On Apr 4, 2006, at 2:56 PM, Bob Ippolito wrote: > >> >> On Apr 4, 2006, at 2:18 PM, Christopher Barker wrote: >> >>> Bob Ippolito wrote: >>>> When using the universal build, you need to have the universal SDK >>>> installed. It looks like you don't. >>> >>> Do you get that if you install the latest XCode tools? >> >> I don't know if it's installed by default yet, but it's definitely >> been in the past few releases of Xcode. It might be an optional part >> of the install. >> > Would this be a good way ti quickly figure it out: > > daniello ~ cc -arch i386 > i686-apple-darwin8-gcc-4.0.1: no input files > > It looks like the compiler identifies itself as Intel-capable i.e. > i686. > Of course that is no guarantee the includes and libs are there, but > its a good way to bet. > I have Xcode 2.2.1 installed plus updated documentation for March > 2006 (a whopping 270+MB download). No, that's not a good way to figure it out. The best way is just to look for the SDK: /Developer/SDKs/MacOSX10.4u.sdk If the SDK is not there, then you did not install it. > As an aside and cautionary tale: I am just getting back on line-- > the 10.4.5 upgrade started corrupting files and eventually disk > buffers and the super block. > It seems I have had marginal DDR RAM for a few years, but it took > the latest upgrade to really bring the problems to the fore. > When Apple cautions you about buying cheap RAM--believe it! I wouldn't blame the 10.4.5 upgrade for corrupted files.. that's probably not a direct cause. I'd chalk it up to coincidence that your RAM or HDD started to fail at about the time that the upgrade was installed. It could've been happening long beforehand, but a system upgrade would certainly bring that kind of problem to the surface because it's overwriting files that are necessary for the OS to function at all. -bob From toddobryan at mac.com Wed Apr 5 03:13:16 2006 From: toddobryan at mac.com (Todd O'Bryan) Date: Tue, 4 Apr 2006 21:13:16 -0400 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <4432E345.7080402@noaa.gov> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> Message-ID: <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> OK, I successfully installed it. (Thanks for the simple-but-time- consuming-download-wise fix, Bob.) Now, how do I donate the binary back to the cause? Todd P.S. I'm willing to do some others, assuming it's not too complicated. MySQL-python just released 1.2.1, and 1.2.0 is the most recent available binary. I was able to install it, I think, but I got this warning when I tried to build. gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/ _mysql.o -L/usr/local/mysql/lib -lmysqlclient_r -lz -lm -o build/ lib.macosx-10.4-fat-2.4/_mysql.so /usr/bin/ld: for architecture i386 /usr/bin/ld: warning /usr/local/mysql/lib/libmysqlclient_r.a archive's cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (can't load from it) On Apr 4, 2006, at 5:21 PM, Christopher Barker wrote: > Bill Janssen wrote: >> Time to update the downloads page? > > I'm not sure. We don't have a single Universal package available yet. > > However, it does work, on PPC, with the packages for the 2.4.1 > Framework > build. If you use it on Intel, however, you're stuck with building > everything yourself, and I don't know how universally that works. > > I'd be inclined to wait until we have a core of commonly used packages > available. > > -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 at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Wed Apr 5 03:22:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 4 Apr 2006 18:22:12 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> Message-ID: On Apr 4, 2006, at 6:13 PM, Todd O'Bryan wrote: > OK, I successfully installed it. (Thanks for the simple-but-time- > consuming-download-wise fix, Bob.) > > Now, how do I donate the binary back to the cause? The current strategy would be to either build an egg for it, or a bdist_mpkg (probably the best idea for packages that don't use setuptools yet). Currently the version of py2app that should be used with a universal Python lives here (there hasn't bean a release yet): http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/ If you check that out and do: python setup.py bdist_mpkg --open That will install py2app and related tools. After that's done, you'll have a new bdist_mpkg shell command which you can just run in any directory with a setup.py and it will (more likely than not) build a .mpkg out of it. > P.S. I'm willing to do some others, assuming it's not too > complicated. MySQL-python just released 1.2.1, and 1.2.0 is the most > recent available binary. I was able to install it, I think, but I got > this warning when I tried to build. > > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g > -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/ > _mysql.o -L/usr/local/mysql/lib -lmysqlclient_r -lz -lm -o build/ > lib.macosx-10.4-fat-2.4/_mysql.so > /usr/bin/ld: for architecture i386 > /usr/bin/ld: warning /usr/local/mysql/lib/libmysqlclient_r.a > archive's cputype (18, architecture ppc) does not match cputype (7) > for specified -arch flag: i386 (can't load from it) That means your MySQL libraries are PPC only and won't be compatible with Python running on i386. You'll want to obtain a universal build of MySQL to link against. -bob From toddobryan at mac.com Wed Apr 5 04:11:24 2006 From: toddobryan at mac.com (Todd O'Bryan) Date: Tue, 4 Apr 2006 22:11:24 -0400 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> Message-ID: <6EECFD1C-F711-47AE-9790-3900F0C262D5@mac.com> On Apr 4, 2006, at 9:22 PM, Bob Ippolito wrote: > That will install py2app and related tools. After that's done, > you'll have a new bdist_mpkg shell command which you can just run > in any directory with a setup.py and it will (more likely than not) > build a .mpkg out of it. Hey, it worked! I now have a universal .mpkg for PyXML. What should I do with it? > That means your MySQL libraries are PPC only and won't be > compatible with Python running on i386. You'll want to obtain a > universal build of MySQL to link against. Yuck. MySQL hasn't released a universal binary; they have separate packages for PPC, PPC 64 bit, and x86. I could try building it from source, but my guess is that I'd very quickly be in over my head. Anything else I can do to help? Todd From bob at redivi.com Wed Apr 5 04:19:26 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 4 Apr 2006 19:19:26 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <6EECFD1C-F711-47AE-9790-3900F0C262D5@mac.com> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> <6EECFD1C-F711-47AE-9790-3900F0C262D5@mac.com> Message-ID: <3BA26556-E1EF-4379-8E6A-1613549E7AD0@redivi.com> On Apr 4, 2006, at 7:11 PM, Todd O'Bryan wrote: > On Apr 4, 2006, at 9:22 PM, Bob Ippolito wrote: > >> That will install py2app and related tools. After that's done, >> you'll have a new bdist_mpkg shell command which you can just run >> in any directory with a setup.py and it will (more likely than >> not) build a .mpkg out of it. > > Hey, it worked! I now have a universal .mpkg for PyXML. What should > I do with it? Zip it up and send it to me.. I'll see about creating a repository for universal packages sometime over the next few days (weekend is my best guess). >> That means your MySQL libraries are PPC only and won't be >> compatible with Python running on i386. You'll want to obtain a >> universal build of MySQL to link against. > > Yuck. MySQL hasn't released a universal binary; they have separate > packages for PPC, PPC 64 bit, and x86. I could try building it from > source, but my guess is that I'd very quickly be in over my head. I'd just wait, then. It's usually not worth learning the intricate details of porting other people's software to universal binaries when someone is almost definitely going to do it for you first. It's probably not all that hard to take the PPC and x86 builds and solder them together with lipo (there's a man page for it), but it might also require some hacking on the header files (if they're generated by autoconf or something). I wouldn't personally bother unless I had a pressing need to make a redistributable universal app that really needs MySQL support. -bob From ronaldoussoren at mac.com Wed Apr 5 13:19:15 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 05 Apr 2006 13:19:15 +0200 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <3BA26556-E1EF-4379-8E6A-1613549E7AD0@redivi.com> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> <6EECFD1C-F711-47AE-9790-3900F0C262D5@mac.com> <3BA26556-E1EF-4379-8E6A-1613549E7AD0@redivi.com> Message-ID: <1222594.1144235955846.JavaMail.ronaldoussoren@mac.com> On Wednesday, April 05, 2006, at 04:19AM, Bob Ippolito wrote: > >On Apr 4, 2006, at 7:11 PM, Todd O'Bryan wrote: > >> On Apr 4, 2006, at 9:22 PM, Bob Ippolito wrote: >> >>> That will install py2app and related tools. After that's done, >>> you'll have a new bdist_mpkg shell command which you can just run >>> in any directory with a setup.py and it will (more likely than >>> not) build a .mpkg out of it. >> >> Hey, it worked! I now have a universal .mpkg for PyXML. What should >> I do with it? > >Zip it up and send it to me.. I'll see about creating a repository >for universal packages sometime over the next few days (weekend is my >best guess). I'm refactoring my build script for universal python builds to create eggs for other software. I'll probably stuff that script and the files it uses in the pyobjc repository. Ronald From Chris.Barker at noaa.gov Wed Apr 5 18:18:00 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 05 Apr 2006 09:18:00 -0700 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <3BA26556-E1EF-4379-8E6A-1613549E7AD0@redivi.com> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> <6EECFD1C-F711-47AE-9790-3900F0C262D5@mac.com> <3BA26556-E1EF-4379-8E6A-1613549E7AD0@redivi.com> Message-ID: <4433EDB8.9050608@noaa.gov> Bob Ippolito wrote: > I'll see about creating a repository > for universal packages sometime over the next few days (weekend is my > best guess). Did you get a chance to take a look at my re-structuring of the pythonmac repository site? Anything else I can do to help? While we are on the topic, I'm looking at building a couple packages that require external libs (PIL, matplotlib). In the past, I've tried to build them as static libs and link them to the extensions to make it all self contained. I see two issues with this now; 1) How do I make Universal static lib? 2) We'll end up using the same libs over and over in multiple packages: Both PIL and matplotlib require libpng and libfreetype, for instance. I expect we'll see other overlapping libs. a) Is there any problem with two different extensions being loaded that are linked to the same static lib, particularly if they are different versions? b) If not, then I guess it's just a waste-of-memory issue, which probably isn't a big deal, but seems wasteful. I do think that any packages put on pythonmac.org should only depend on other packages available there. Perhaps we could make a "libs" package with a bunch of these common libs. If we put them in the python tree, would the linker find them? Would Py2App find them? Any thoughts? -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 at noaa.gov From ronaldoussoren at mac.com Wed Apr 5 21:08:39 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 5 Apr 2006 21:08:39 +0200 Subject: [Pythonmac-SIG] PyXML install problems In-Reply-To: <4433EDB8.9050608@noaa.gov> References: <06Apr4.123903pdt.58633@synergy1.parc.xerox.com> <4432E345.7080402@noaa.gov> <3CE4E082-8A48-4EF1-9253-A0FADB6EB07A@mac.com> <6EECFD1C-F711-47AE-9790-3900F0C262D5@mac.com> <3BA26556-E1EF-4379-8E6A-1613549E7AD0@redivi.com> <4433EDB8.9050608@noaa.gov> Message-ID: On 5-apr-2006, at 18:18, Christopher Barker wrote: > Bob Ippolito wrote: > >> I'll see about creating a repository >> for universal packages sometime over the next few days (weekend is my >> best guess). > > Did you get a chance to take a look at my re-structuring of the > pythonmac repository site? Anything else I can do to help? > > While we are on the topic, I'm looking at building a couple packages > that require external libs (PIL, matplotlib). In the past, I've > tried to > build them as static libs and link them to the extensions to make it > all self contained. I see two issues with this now; > > 1) How do I make Universal static lib? Basically use 'cc -arch i386 -arch ppc -isysroot /Developer/SDKs/ 10.4u.sdk' as the compiler and hope that configure doesn't check for endianness. (There may be spelling errors in that command-line, I haven't checked my build script). I have a version of PIL with tiff and jpeg support (Universal of course). > > 2) We'll end up using the same libs over and over in multiple > packages: > Both PIL and matplotlib require libpng and libfreetype, for > instance. I > expect we'll see other overlapping libs. > > a) Is there any problem with two different extensions being loaded > that > are linked to the same static lib, particularly if they are different > versions? That shouldn't be a problem until someone starts playing with dlopen flags, and that can't happen at the moment because dynload_next doesn't look at those :-). > > b) If not, then I guess it's just a waste-of-memory issue, which > probably isn't a big deal, but seems wasteful. I do think that any > packages put on pythonmac.org should only depend on other packages > available there. Perhaps we could make a "libs" package with a > bunch of > these common libs. > > If we put them in the python tree, would the linker find them? Would > Py2App find them? I don't know about the latter but the former shouldn't be a problem, you'll just have to make sure that the right linker arguments are used. Ronald From trentm at ActiveState.com Thu Apr 6 18:46:20 2006 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 6 Apr 2006 09:46:20 -0700 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.3.11 is now available Message-ID: <20060406164620.GB16253@activestate.com> I'm happy to announce that ActivePython 2.4.3.11 is now available from: http://www.ActiveState.com/Products/ActivePython/ This release is a maintenance/update release for existing platforms. See the announcement on python-announce for full details. Currently ActivePython provides separate Intel and PowerPC builds for Mac OS X rather than one universal build. Note that in the relatively near future ActivePython will switch to a universal build based on the code that Ronald and Bob have been working on. Ronald, you mentioned a while back that you intended to integrate that work with the main Python SVN. Is that still your intention? Cheers, Trent -- Trent Mick TrentM at ActiveState.com From ronaldoussoren at mac.com Thu Apr 6 21:49:40 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 6 Apr 2006 21:49:40 +0200 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.3.11 is now available In-Reply-To: <20060406164620.GB16253@activestate.com> References: <20060406164620.GB16253@activestate.com> Message-ID: On 6-apr-2006, at 18:46, Trent Mick wrote: > > Ronald, you mentioned a while back that you intended to integrate > that work > with the main Python SVN. Is that still your intention? Yes it is, but only for the trunk. Ronald From trentm at ActiveState.com Thu Apr 6 21:53:02 2006 From: trentm at ActiveState.com (Trent Mick) Date: Thu, 6 Apr 2006 12:53:02 -0700 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.3.11 is now available In-Reply-To: References: <20060406164620.GB16253@activestate.com> Message-ID: <20060406195302.GB16894@activestate.com> [Ronald Oussoren wrote] > > Ronald, you mentioned a while back that you intended to integrate > > that work with the main Python SVN. Is that still your intention? > > Yes it is, but only for the trunk. Cool, thanks. Trent -- Trent Mick TrentM at ActiveState.com From shane.holloway at ieee.org Thu Apr 6 22:39:45 2006 From: shane.holloway at ieee.org (Shane Holloway (IEEE)) Date: Thu, 6 Apr 2006 14:39:45 -0600 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison Message-ID: I was just wondering if anyone else had compared pystones on their box? I downloaded the latest Universal Build from the python.org and found things to be a bit sluggish. So I ran the pystones test to quickly gauge things, and noticed that things are indeed running about 1/3 of what they should be. (Specific info from the Terminal below.) Anyone have ideas? They both appear to be built from GCC 4.0. Let me know what other information you need from me. Also, are there build instructions for creating the Universal Packaging? Thanks, -Shane Holloway From the Universal Build installed python:: [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ 2.4/bin/python -V Python 2.4.3 [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ 2.4/bin/python -c "from test.pystone import pystones; print pystones()" (3.79, 13192.612137203167) From the release24-maint branch built on my box:: [shane at dynamic-46] python/py-24% svn info Path: . URL: http://svn.python.org/projects/python/branches/release24-maint Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 43662 Node Kind: directory Schedule: normal Last Changed Author: martin.v.loewis Last Changed Rev: 43618 Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr 2006) [shane at dynamic-46] python/py-24% ./python.exe -V Python 2.4.4c0 [shane at dynamic-46] python/py-24% ./python.exe -c "from test.pystone import pystones; print pystones()" (1.5799999999999998, 31645.569620253169) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/987a3c7d/attachment.html From twl at sauria.com Thu Apr 6 23:36:00 2006 From: twl at sauria.com (Ted Leung) Date: Thu, 6 Apr 2006 14:36:00 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: References: Message-ID: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> FWIW here are 3 runs from 1.83GHz MacBook Pro.... [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/bin/ python -c "from test.pystone import pystones; print pystones()" (2.0400000000000005, 24509.803921568622) =============================================================== 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/Python.framework/ Versions/2.4/bin/python -c "from test.pystone import pystones; print pystones()" (2.0299999999999998, 24630.541871921185) =============================================================== 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/Python.framework/ Versions/2.4/bin/python -c "from test.pystone import pystones; print pystones()" (2.0800000000000005, 24038.461538461532) Ted On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: > I was just wondering if anyone else had compared pystones on their > box? I downloaded the latest Universal Build from the python.org > and found things to be a bit sluggish. So I ran the pystones test > to quickly gauge things, and noticed that things are indeed running > about 1/3 of what they should be. (Specific info from the Terminal > below.) Anyone have ideas? They both appear to be built from GCC > 4.0. Let me know what other information you need from me. > > Also, are there build instructions for creating the Universal > Packaging? > > Thanks, > -Shane Holloway > > > > From the Universal Build installed python:: > > [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ > 2.4/bin/python -V > Python 2.4.3 > [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ > 2.4/bin/python -c "from test.pystone import pystones; print pystones > ()" > (3.79, 13192.612137203167) > > > > From the release24-maint branch built on my box:: > > [shane at dynamic-46] python/py-24% svn info > Path: . > URL: http://svn.python.org/projects/python/branches/release24-maint > Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 > Revision: 43662 > Node Kind: directory > Schedule: normal > Last Changed Author: martin.v.loewis > Last Changed Rev: 43618 > Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) > Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr 2006) > > [shane at dynamic-46] python/py-24% ./python.exe -V > Python 2.4.4c0 > [shane at dynamic-46] python/py-24% ./python.exe -c "from test.pystone > import pystones; print pystones()" > (1.5799999999999998, 31645.569620253169) > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ---- Ted Leung Blog: This message is: [ ] bloggable [x] ask first [ ] private -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/2aa85799/attachment-0001.htm From twl at sauria.com Thu Apr 6 23:36:00 2006 From: twl at sauria.com (Ted Leung) Date: Thu, 6 Apr 2006 14:36:00 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: References: Message-ID: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> FWIW here are 3 runs from 1.83GHz MacBook Pro.... [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/bin/ python -c "from test.pystone import pystones; print pystones()" (2.0400000000000005, 24509.803921568622) =============================================================== 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/Python.framework/ Versions/2.4/bin/python -c "from test.pystone import pystones; print pystones()" (2.0299999999999998, 24630.541871921185) =============================================================== 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/Python.framework/ Versions/2.4/bin/python -c "from test.pystone import pystones; print pystones()" (2.0800000000000005, 24038.461538461532) Ted On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: > I was just wondering if anyone else had compared pystones on their > box? I downloaded the latest Universal Build from the python.org > and found things to be a bit sluggish. So I ran the pystones test > to quickly gauge things, and noticed that things are indeed running > about 1/3 of what they should be. (Specific info from the Terminal > below.) Anyone have ideas? They both appear to be built from GCC > 4.0. Let me know what other information you need from me. > > Also, are there build instructions for creating the Universal > Packaging? > > Thanks, > -Shane Holloway > > > > From the Universal Build installed python:: > > [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ > 2.4/bin/python -V > Python 2.4.3 > [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ > 2.4/bin/python -c "from test.pystone import pystones; print pystones > ()" > (3.79, 13192.612137203167) > > > > From the release24-maint branch built on my box:: > > [shane at dynamic-46] python/py-24% svn info > Path: . > URL: http://svn.python.org/projects/python/branches/release24-maint > Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 > Revision: 43662 > Node Kind: directory > Schedule: normal > Last Changed Author: martin.v.loewis > Last Changed Rev: 43618 > Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) > Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr 2006) > > [shane at dynamic-46] python/py-24% ./python.exe -V > Python 2.4.4c0 > [shane at dynamic-46] python/py-24% ./python.exe -c "from test.pystone > import pystones; print pystones()" > (1.5799999999999998, 31645.569620253169) > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ---- Ted Leung Blog: This message is: [ ] bloggable [x] ask first [ ] private -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/2aa85799/attachment.html From mantha at chem.unr.edu Fri Apr 7 00:15:17 2006 From: mantha at chem.unr.edu (Jordan Mantha) Date: Thu, 6 Apr 2006 15:15:17 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> Message-ID: And here is mine on a 1.83GHz 17" Intel iMac: $ python -V Python 2.4.3 $ python -c "from test.pystone import pystones; print pystones()" (1.99, 25125.628140703517) -Jordan Mantha On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: > FWIW here are 3 runs from 1.83GHz MacBook Pro.... > > [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/ > bin/python -c "from test.pystone import pystones; print pystones()" > (2.0400000000000005, 24509.803921568622) > =============================================================== > 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/Python.framework/ > Versions/2.4/bin/python -c "from test.pystone import pystones; > print pystones()" > (2.0299999999999998, 24630.541871921185) > =============================================================== > 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/Python.framework/ > Versions/2.4/bin/python -c "from test.pystone import pystones; > print pystones()" > (2.0800000000000005, 24038.461538461532) > > Ted > > > On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: > >> I was just wondering if anyone else had compared pystones on their >> box? I downloaded the latest Universal Build from the python.org >> and found things to be a bit sluggish. So I ran the pystones test >> to quickly gauge things, and noticed that things are indeed >> running about 1/3 of what they should be. (Specific info from the >> Terminal below.) Anyone have ideas? They both appear to be built >> from GCC 4.0. Let me know what other information you need from me. >> >> Also, are there build instructions for creating the Universal >> Packaging? >> >> Thanks, >> -Shane Holloway >> >> >> >> From the Universal Build installed python:: >> >> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >> Versions/2.4/bin/python -V >> Python 2.4.3 >> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >> Versions/2.4/bin/python -c "from test.pystone import pystones; >> print pystones()" >> (3.79, 13192.612137203167) >> >> >> >> From the release24-maint branch built on my box:: >> >> [shane at dynamic-46] python/py-24% svn info >> Path: . >> URL: http://svn.python.org/projects/python/branches/release24-maint >> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >> Revision: 43662 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: martin.v.loewis >> Last Changed Rev: 43618 >> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr 2006) >> >> [shane at dynamic-46] python/py-24% ./python.exe -V >> Python 2.4.4c0 >> [shane at dynamic-46] python/py-24% ./python.exe -c "from >> test.pystone import pystones; print pystones()" >> (1.5799999999999998, 31645.569620253169) >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > ---- > Ted Leung Blog: > This message is: [ ] bloggable [x] ask first [ ] private > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/7eab7235/attachment-0001.htm From shane.holloway at ieee.org Fri Apr 7 02:08:38 2006 From: shane.holloway at ieee.org (Shane Holloway (IEEE)) Date: Thu, 6 Apr 2006 18:08:38 -0600 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> Message-ID: <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> Nice. Very jealous about the Intel MacBook Pros. :) You both better put them to good use! ;) Have either of you tried building the 2.4 release branch and running pystones from it? For those reading who may not know how from Terminal:: svn co http://svn.python.org/projects/python/branches/release24-maint py-24 cd py-24 ./configure make ./python.exe -c "from test.pystone import pystones; print pystones()" On Apr 6, 2006, at 16:15, Jordan Mantha wrote: > And here is mine on a 1.83GHz 17" Intel iMac: > > $ python -V > Python 2.4.3 > > $ python -c "from test.pystone import pystones; print pystones()" > (1.99, 25125.628140703517) > > -Jordan Mantha > > > On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: > >> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >> >> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/ >> bin/python -c "from test.pystone import pystones; print pystones()" >> (2.0400000000000005, 24509.803921568622) >> =============================================================== >> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >> Python.framework/Versions/2.4/bin/python -c "from test.pystone >> import pystones; print pystones()" >> (2.0299999999999998, 24630.541871921185) >> =============================================================== >> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >> Python.framework/Versions/2.4/bin/python -c "from test.pystone >> import pystones; print pystones()" >> (2.0800000000000005, 24038.461538461532) >> >> Ted >> >> >> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >> >>> I was just wondering if anyone else had compared pystones on >>> their box? I downloaded the latest Universal Build from the >>> python.org and found things to be a bit sluggish. So I ran the >>> pystones test to quickly gauge things, and noticed that things >>> are indeed running about 1/3 of what they should be. (Specific >>> info from the Terminal below.) Anyone have ideas? They both >>> appear to be built from GCC 4.0. Let me know what other >>> information you need from me. >>> >>> Also, are there build instructions for creating the Universal >>> Packaging? >>> >>> Thanks, >>> -Shane Holloway >>> >>> >>> >>> From the Universal Build installed python:: >>> >>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>> Versions/2.4/bin/python -V >>> Python 2.4.3 >>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>> Versions/2.4/bin/python -c "from test.pystone import pystones; >>> print pystones()" >>> (3.79, 13192.612137203167) >>> >>> >>> >>> From the release24-maint branch built on my box:: >>> >>> [shane at dynamic-46] python/py-24% svn info >>> Path: . >>> URL: http://svn.python.org/projects/python/branches/release24-maint >>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>> Revision: 43662 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: martin.v.loewis >>> Last Changed Rev: 43618 >>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr >>> 2006) >>> >>> [shane at dynamic-46] python/py-24% ./python.exe -V >>> Python 2.4.4c0 >>> [shane at dynamic-46] python/py-24% ./python.exe -c "from >>> test.pystone import pystones; print pystones()" >>> (1.5799999999999998, 31645.569620253169) >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> ---- >> Ted Leung Blog: >> This message is: [ ] bloggable [x] ask first [ ] private >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/3c05a0c8/attachment.html From zbir at urbanape.com Fri Apr 7 04:44:04 2006 From: zbir at urbanape.com (Zachery Bir) Date: Thu, 6 Apr 2006 22:44:04 -0400 Subject: [Pythonmac-SIG] NSUserDefaults still causing crash on MOSXI Message-ID: <6E81F5E1-3CFA-4013-A856-83D0EA5D8A18@urbanape.com> Still getting this with Mac OS X Intel, using Ronald's new 2.4.3 Universal Python and Bob's recent py2app work (pulled in with trunk of PyObjC). It will now at least get NSUserDefaults.SharedDefaults(), but dies trying to get the persistent domain. I've uploaded a new TestUserDefaults.zip to my site: The only thing different from before is the illegal instruction comes a bit later: from objc import YES, NO, selector from PyObjCTools import NibClassBuilder, AppHelper from Foundation import * from AppKit import * NibClassBuilder.extractClasses(u'MainMenu') class TestUserDefaultsAppDelegate(NibClassBuilder.AutoBaseClass): def awakeFromNib(self): self.output.setStringValue_(u'Success!') def init(self): self = super(TestUserDefaultsAppDelegate, self).init() self.bundleIdent = NSBundle.mainBundle().bundleIdentifier() NSUserDefaults.resetStandardUserDefaults() self.sud = NSUserDefaults.standardUserDefaults() pdomain = self.sud.persistentDomainForName_(self.bundleIdent) return self AppHelper.runEventLoop(argv=[]) Thanks, Zac From daniellord at mac.com Fri Apr 7 05:55:58 2006 From: daniellord at mac.com (Daniel Lord) Date: Thu, 6 Apr 2006 20:55:58 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> Message-ID: <47A8321F-DFA8-4803-9D9A-D4893AE0F354@mac.com> Just for fun I got the svn source and compiled it on my 1.8Ghz Dual G5 running 10.4.6 to add a data point: daniello ~/WIP/Python-Builds/py-24 ./python.exe -c "from test.pystone import pystones; print pystones()" (1.6199999999999999, 30864.1975308642) Better than the 1.86 GHZ MacBookPro but surprisingly closer than I'd expect. Man for a laptop, that MacBook Pro sings! I'll bet the 2.16 Ghz might just tie my dual. Come to think of it, although it's three and a half years old, that's kind of depressing ;-( On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote: > ./python.exe -c "from test.pystone import pystones; print pystones()" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/fd272238/attachment.html From stewreo at gmail.com Fri Apr 7 05:57:55 2006 From: stewreo at gmail.com (Stefan Werner) Date: Thu, 6 Apr 2006 20:57:55 -0700 Subject: [Pythonmac-SIG] linker error with UB 2.4.3 Message-ID: <6be03b9a0604062057p38f4e148p4cb3bca57b54b88c@mail.gmail.com> Hi, when trying to link my application against the universal binary build linked from Python.org, I get an error about these undefined symbols: /usr/bin/ld: Undefined symbols: _fstatvfs referenced from Python expected to be defined in libSystem _lchown referenced from Python expected to be defined in libSystem _statvfs referenced from Python expected to be defined in libSystem This happens only for the PPC part of my UB application, it seems to link the i386 part just fine. I am using the 10.3.9 SDK for the PPC side, 10.4u for i386. Do I need to link against the 10.4u SDK on both sides? I'd not be too happy about doing that, since I want to make sure the app runs perfeclty on 10.3.9/PPC. -Stefan From bob at redivi.com Fri Apr 7 06:05:43 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 6 Apr 2006 21:05:43 -0700 Subject: [Pythonmac-SIG] linker error with UB 2.4.3 In-Reply-To: <6be03b9a0604062057p38f4e148p4cb3bca57b54b88c@mail.gmail.com> References: <6be03b9a0604062057p38f4e148p4cb3bca57b54b88c@mail.gmail.com> Message-ID: <1F84DBB2-7042-456F-BFB0-F47376DFEBBA@redivi.com> On Apr 6, 2006, at 8:57 PM, Stefan Werner wrote: > when trying to link my application against the universal binary build > linked from Python.org, I get an error about these undefined symbols: > > /usr/bin/ld: Undefined symbols: > _fstatvfs referenced from Python expected to be defined in libSystem > _lchown referenced from Python expected to be defined in libSystem > _statvfs referenced from Python expected to be defined in libSystem > > This happens only for the PPC part of my UB application, it seems to > link the i386 part just fine. I am using the 10.3.9 SDK for the PPC > side, 10.4u for i386. Do I need to link against the 10.4u SDK on both > sides? I'd not be too happy about doing that, since I want to make > sure the app runs perfeclty on 10.3.9/PPC. 10.4u SDK on both sides. It still runs on 10.3.9 PPC. -bob From aleaxit at gmail.com Fri Apr 7 06:44:36 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Thu, 6 Apr 2006 21:44:36 -0700 Subject: [Pythonmac-SIG] 2.4.3 performance, Macbook Pro vs iBook G4 12" Message-ID: <79B053A4-7BC2-414E-A85D-A9EC0756A616@gmail.com> I'm wondering about comparative performance -- shouldn't a Macbook Pro 2.0 GHz be VASTLY faster than a humble iBook G4 12" (1.33 GHz PPC G4)? And yet, pybench 1.0 tells me: 7806 ms on the iBook, 7721 on the Macbook; also, the iBook measures at 22026 pystones/sec, the Macbook at 22624. That's with 2.4.3 on both. Am I doing something wrong, are there problems with the recent 2.4.3 Universal release, or are the two machines REALLY that close...?! Alex From bob at redivi.com Fri Apr 7 07:00:42 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 6 Apr 2006 22:00:42 -0700 Subject: [Pythonmac-SIG] 2.4.3 performance, Macbook Pro vs iBook G4 12" In-Reply-To: <79B053A4-7BC2-414E-A85D-A9EC0756A616@gmail.com> References: <79B053A4-7BC2-414E-A85D-A9EC0756A616@gmail.com> Message-ID: <5A3AB89C-E70C-433A-83AD-5C2AB9BEE218@redivi.com> On Apr 6, 2006, at 9:44 PM, Alex Martelli wrote: > I'm wondering about comparative performance -- shouldn't a Macbook > Pro 2.0 GHz be VASTLY faster than a humble iBook G4 12" (1.33 GHz PPC > G4)? > > And yet, pybench 1.0 tells me: 7806 ms on the iBook, 7721 on the > Macbook; also, the iBook measures at 22026 pystones/sec, the Macbook > at 22624. That's with 2.4.3 on both. Am I doing something wrong, > are there problems with the recent 2.4.3 Universal release, or are > the two machines REALLY that close...?! Make sure that the universal build is actually running i386. If you are running a python binary compiled PPC that happens to link to the universal framework, it's going to start up PPC under Rosetta. I'm not going to have an Intel machine for probably another few weeks so I can't test these things. You should see *exactly* the following output with a correctly installed universal build (with of course a different platform string): % lipo -info `which python` Architectures in the fat file: /Library/Frameworks/Python.framework/ Versions/Current/bin/python are: ppc i386 % lipo -info /Library/Frameworks/Python.framework/Python Architectures in the fat file: /Library/Frameworks/Python.framework/ Python are: ppc i386 % python -mplatform Darwin-8.6.0-Power_Macintosh-powerpc-32bit -bob From twl at sauria.com Fri Apr 7 07:04:43 2006 From: twl at sauria.com (Ted Leung) Date: Thu, 6 Apr 2006 22:04:43 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> Message-ID: <33638F78-C998-4761-B0BC-FA0C38CD2416@sauria.com> I just realized that I only sent this to Shane, so for the whole list (and Alex) Hmm. Here's three of those... [sprout:2065]> ./python.exe -c "from test.pystone import pystones; print pystones()" (1.22, 40983.606557377047) =============================================================== 2006-04-06 18:06 [sprout:2065]> ./python.exe -c "from test.pystone import pystones; print pystones()" (1.23, 40650.406504065038) =============================================================== 2006-04-06 18:06 [sprout:2065]> ./python.exe -c "from test.pystone import pystones; print pystones()" (1.22, 40983.606557377047) On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote: > Nice. Very jealous about the Intel MacBook Pros. :) You both > better put them to good use! ;) > > Have either of you tried building the 2.4 release branch and > running pystones from it? > > For those reading who may not know how from Terminal:: > > svn co http://svn.python.org/projects/python/branches/release24- > maint py-24 > cd py-24 > ./configure > make > ./python.exe -c "from test.pystone import pystones; print pystones()" > > > On Apr 6, 2006, at 16:15, Jordan Mantha wrote: > >> And here is mine on a 1.83GHz 17" Intel iMac: >> >> $ python -V >> Python 2.4.3 >> >> $ python -c "from test.pystone import pystones; print pystones()" >> (1.99, 25125.628140703517) >> >> -Jordan Mantha >> >> >> On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: >> >>> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >>> >>> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/ >>> bin/python -c "from test.pystone import pystones; print pystones()" >>> (2.0400000000000005, 24509.803921568622) >>> =============================================================== >>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>> import pystones; print pystones()" >>> (2.0299999999999998, 24630.541871921185) >>> =============================================================== >>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>> import pystones; print pystones()" >>> (2.0800000000000005, 24038.461538461532) >>> >>> Ted >>> >>> >>> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >>> >>>> I was just wondering if anyone else had compared pystones on >>>> their box? I downloaded the latest Universal Build from the >>>> python.org and found things to be a bit sluggish. So I ran the >>>> pystones test to quickly gauge things, and noticed that things >>>> are indeed running about 1/3 of what they should be. (Specific >>>> info from the Terminal below.) Anyone have ideas? They both >>>> appear to be built from GCC 4.0. Let me know what other >>>> information you need from me. >>>> >>>> Also, are there build instructions for creating the Universal >>>> Packaging? >>>> >>>> Thanks, >>>> -Shane Holloway >>>> >>>> >>>> >>>> From the Universal Build installed python:: >>>> >>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>> Versions/2.4/bin/python -V >>>> Python 2.4.3 >>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>> Versions/2.4/bin/python -c "from test.pystone import pystones; >>>> print pystones()" >>>> (3.79, 13192.612137203167) >>>> >>>> >>>> >>>> From the release24-maint branch built on my box:: >>>> >>>> [shane at dynamic-46] python/py-24% svn info >>>> Path: . >>>> URL: http://svn.python.org/projects/python/branches/release24-maint >>>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>>> Revision: 43662 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: martin.v.loewis >>>> Last Changed Rev: 43618 >>>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr >>>> 2006) >>>> >>>> [shane at dynamic-46] python/py-24% ./python.exe -V >>>> Python 2.4.4c0 >>>> [shane at dynamic-46] python/py-24% ./python.exe -c "from >>>> test.pystone import pystones; print pystones()" >>>> (1.5799999999999998, 31645.569620253169) >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> ---- >>> Ted Leung Blog: >> blog> >>> This message is: [ ] bloggable [x] ask first [ ] private >>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > ---- Ted Leung Blog: This message is: [ ] bloggable [x] ask first [ ] private -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/65e290fc/attachment.htm From twl at sauria.com Fri Apr 7 07:10:24 2006 From: twl at sauria.com (Ted Leung) Date: Thu, 6 Apr 2006 22:10:24 -0700 Subject: [Pythonmac-SIG] 2.4.3 performance, Macbook Pro vs iBook G4 12" In-Reply-To: <5A3AB89C-E70C-433A-83AD-5C2AB9BEE218@redivi.com> References: <79B053A4-7BC2-414E-A85D-A9EC0756A616@gmail.com> <5A3AB89C-E70C-433A-83AD-5C2AB9BEE218@redivi.com> Message-ID: <8381DF85-A6F8-4167-AF9A-789862A85ADC@sauria.com> On Apr 6, 2006, at 10:00 PM, Bob Ippolito wrote: > On Apr 6, 2006, at 9:44 PM, Alex Martelli wrote: > >> I'm wondering about comparative performance -- shouldn't a Macbook >> Pro 2.0 GHz be VASTLY faster than a humble iBook G4 12" (1.33 GHz PPC >> G4)? >> >> And yet, pybench 1.0 tells me: 7806 ms on the iBook, 7721 on the >> Macbook; also, the iBook measures at 22026 pystones/sec, the Macbook >> at 22624. That's with 2.4.3 on both. Am I doing something wrong, >> are there problems with the recent 2.4.3 Universal release, or are >> the two machines REALLY that close...?! > > Make sure that the universal build is actually running i386. If you > are running a python binary compiled PPC that happens to link to the > universal framework, it's going to start up PPC under Rosetta. I'm > not going to have an Intel machine for probably another few weeks so > I can't test these things. > > You should see *exactly* the following output with a correctly > installed universal build (with of course a different platform > string): > > % lipo -info `which python` > Architectures in the fat file: /Library/Frameworks/Python.framework/ > Versions/Current/bin/python are: ppc i386 > > % lipo -info /Library/Frameworks/Python.framework/Python > Architectures in the fat file: /Library/Frameworks/Python.framework/ > Python are: ppc i386 > > % python -mplatform > Darwin-8.6.0-Power_Macintosh-powerpc-32bit > Here's what my universal build says: [sprout:2000]> lipo -info `which python` ~ Architectures in the fat file: /usr/local/bin/python are: ppc i386 =============================================================== 2006-04-06 22:06[sprout:2001]> lipo -info /Library/Frameworks/ Python.framework/Python ~ Architectures in the fat file: /Library/Frameworks/Python.framework/ Python are: ppc i386 =============================================================== 2006-04-06 22:06[sprout:2002]> python - mplatform ~ Darwin-8.6.1-i386-32bit The python that Shane suggested that we build said this: [sprout:2004]> lipo -info python.exe ~/ tmp/py-24 Non-fat file: python.exe is architecture: i386 =============================================================== *** NOTE i didn't know what to put in here for the Framework line *** 2006-04-06 22:07[sprout:2005]> ./python.exe - mplatform ~/tmp/py-24 Darwin-8.6.1-i386-32bit Ted From bob at redivi.com Fri Apr 7 07:34:26 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 6 Apr 2006 22:34:26 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <33638F78-C998-4761-B0BC-FA0C38CD2416@sauria.com> References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> <33638F78-C998-4761-B0BC-FA0C38CD2416@sauria.com> Message-ID: <448CDF8F-A0AF-459D-800B-AC4715398BAB@redivi.com> Ok, I see what the problem is, because the Universal python is also half as fast on my PPC. It appears that the universal build is not using any compiler optimizations at all, where a normal build is -O3. I'm not quite sure where/why this is happening (autoconf is evil), but I'm sure someone will figure it out soon enough. # universal OPT= -DNDEBUG -g # normal OPT= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -bob On Apr 6, 2006, at 10:04 PM, Ted Leung wrote: > I just realized that I only sent this to Shane, so for the whole > list (and Alex) > > Hmm. Here's three of those... > > [sprout:2065]> ./python.exe -c "from test.pystone import pystones; > print pystones()" > (1.22, 40983.606557377047) > =============================================================== > 2006-04-06 18:06 > [sprout:2065]> ./python.exe -c "from test.pystone import pystones; > print pystones()" > (1.23, 40650.406504065038) > =============================================================== > 2006-04-06 18:06 > [sprout:2065]> ./python.exe -c "from test.pystone import pystones; > print pystones()" > (1.22, 40983.606557377047) > > > > On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote: > >> Nice. Very jealous about the Intel MacBook Pros. :) You both >> better put them to good use! ;) >> >> Have either of you tried building the 2.4 release branch and >> running pystones from it? >> >> For those reading who may not know how from Terminal:: >> >> svn co http://svn.python.org/projects/python/branches/release24- >> maint py-24 >> cd py-24 >> ./configure >> make >> ./python.exe -c "from test.pystone import pystones; print pystones()" >> >> >> On Apr 6, 2006, at 16:15, Jordan Mantha wrote: >> >>> And here is mine on a 1.83GHz 17" Intel iMac: >>> >>> $ python -V >>> Python 2.4.3 >>> >>> $ python -c "from test.pystone import pystones; print pystones()" >>> (1.99, 25125.628140703517) >>> >>> -Jordan Mantha >>> >>> >>> On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: >>> >>>> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >>>> >>>> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/ >>>> bin/python -c "from test.pystone import pystones; print pystones()" >>>> (2.0400000000000005, 24509.803921568622) >>>> =============================================================== >>>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>>> import pystones; print pystones()" >>>> (2.0299999999999998, 24630.541871921185) >>>> =============================================================== >>>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>>> import pystones; print pystones()" >>>> (2.0800000000000005, 24038.461538461532) >>>> >>>> Ted >>>> >>>> >>>> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >>>> >>>>> I was just wondering if anyone else had compared pystones on >>>>> their box? I downloaded the latest Universal Build from the >>>>> python.org and found things to be a bit sluggish. So I ran the >>>>> pystones test to quickly gauge things, and noticed that things >>>>> are indeed running about 1/3 of what they should be. (Specific >>>>> info from the Terminal below.) Anyone have ideas? They both >>>>> appear to be built from GCC 4.0. Let me know what other >>>>> information you need from me. >>>>> >>>>> Also, are there build instructions for creating the Universal >>>>> Packaging? >>>>> >>>>> Thanks, >>>>> -Shane Holloway >>>>> >>>>> >>>>> >>>>> From the Universal Build installed python:: >>>>> >>>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>>> Versions/2.4/bin/python -V >>>>> Python 2.4.3 >>>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>>> Versions/2.4/bin/python -c "from test.pystone import pystones; >>>>> print pystones()" >>>>> (3.79, 13192.612137203167) >>>>> >>>>> >>>>> >>>>> From the release24-maint branch built on my box:: >>>>> >>>>> [shane at dynamic-46] python/py-24% svn info >>>>> Path: . >>>>> URL: http://svn.python.org/projects/python/branches/release24- >>>>> maint >>>>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>>>> Revision: 43662 >>>>> Node Kind: directory >>>>> Schedule: normal >>>>> Last Changed Author: martin.v.loewis >>>>> Last Changed Rev: 43618 >>>>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>>>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr >>>>> 2006) >>>>> >>>>> [shane at dynamic-46] python/py-24% ./python.exe -V >>>>> Python 2.4.4c0 >>>>> [shane at dynamic-46] python/py-24% ./python.exe -c "from >>>>> test.pystone import pystones; print pystones()" >>>>> (1.5799999999999998, 31645.569620253169) >>>>> >>>>> _______________________________________________ >>>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>>> ---- >>>> Ted Leung Blog: >>> blog> >>>> This message is: [ ] bloggable [x] ask first [ ] private >>>> >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > ---- > Ted Leung Blog: > This message is: [ ] bloggable [x] ask first [ ] private > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/3719f863/attachment.html From bob at redivi.com Fri Apr 7 07:44:24 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 6 Apr 2006 22:44:24 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <448CDF8F-A0AF-459D-800B-AC4715398BAB@redivi.com> References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> <33638F78-C998-4761-B0BC-FA0C38CD2416@sauria.com> <448CDF8F-A0AF-459D-800B-AC4715398BAB@redivi.com> Message-ID: <3FE6C738-7AA0-4BFF-A7F7-14352F75CC84@redivi.com> I can't reproduce this when I configure from the universal trunk, maybe Ronald had an OPT environment variable set when he built it? -bob On Apr 6, 2006, at 10:34 PM, Bob Ippolito wrote: > Ok, I see what the problem is, because the Universal python is also > half as fast on my PPC. > > It appears that the universal build is not using any compiler > optimizations at all, where a normal build is -O3. I'm not quite > sure where/why this is happening (autoconf is evil), but I'm sure > someone will figure it out soon enough. > > # universal > OPT= -DNDEBUG -g > > # normal > OPT= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes > > -bob > > On Apr 6, 2006, at 10:04 PM, Ted Leung wrote: > >> I just realized that I only sent this to Shane, so for the whole >> list (and Alex) >> >> Hmm. Here's three of those... >> >> [sprout:2065]> ./python.exe -c "from test.pystone import pystones; >> print pystones()" >> (1.22, 40983.606557377047) >> =============================================================== >> 2006-04-06 18:06 >> [sprout:2065]> ./python.exe -c "from test.pystone import pystones; >> print pystones()" >> (1.23, 40650.406504065038) >> =============================================================== >> 2006-04-06 18:06 >> [sprout:2065]> ./python.exe -c "from test.pystone import pystones; >> print pystones()" >> (1.22, 40983.606557377047) >> >> >> >> On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote: >> >>> Nice. Very jealous about the Intel MacBook Pros. :) You both >>> better put them to good use! ;) >>> >>> Have either of you tried building the 2.4 release branch and >>> running pystones from it? >>> >>> For those reading who may not know how from Terminal:: >>> >>> svn co http://svn.python.org/projects/python/branches/release24- >>> maint py-24 >>> cd py-24 >>> ./configure >>> make >>> ./python.exe -c "from test.pystone import pystones; print pystones >>> ()" >>> >>> >>> On Apr 6, 2006, at 16:15, Jordan Mantha wrote: >>> >>>> And here is mine on a 1.83GHz 17" Intel iMac: >>>> >>>> $ python -V >>>> Python 2.4.3 >>>> >>>> $ python -c "from test.pystone import pystones; print pystones()" >>>> (1.99, 25125.628140703517) >>>> >>>> -Jordan Mantha >>>> >>>> >>>> On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: >>>> >>>>> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >>>>> >>>>> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/ >>>>> 2.4/bin/python -c "from test.pystone import pystones; print >>>>> pystones()" >>>>> (2.0400000000000005, 24509.803921568622) >>>>> =============================================================== >>>>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>>>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>>>> import pystones; print pystones()" >>>>> (2.0299999999999998, 24630.541871921185) >>>>> =============================================================== >>>>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>>>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>>>> import pystones; print pystones()" >>>>> (2.0800000000000005, 24038.461538461532) >>>>> >>>>> Ted >>>>> >>>>> >>>>> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >>>>> >>>>>> I was just wondering if anyone else had compared pystones on >>>>>> their box? I downloaded the latest Universal Build from the >>>>>> python.org and found things to be a bit sluggish. So I ran >>>>>> the pystones test to quickly gauge things, and noticed that >>>>>> things are indeed running about 1/3 of what they should be. >>>>>> (Specific info from the Terminal below.) Anyone have ideas? >>>>>> They both appear to be built from GCC 4.0. Let me know what >>>>>> other information you need from me. >>>>>> >>>>>> Also, are there build instructions for creating the Universal >>>>>> Packaging? >>>>>> >>>>>> Thanks, >>>>>> -Shane Holloway >>>>>> >>>>>> >>>>>> >>>>>> From the Universal Build installed python:: >>>>>> >>>>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>>>> Versions/2.4/bin/python -V >>>>>> Python 2.4.3 >>>>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>>>> Versions/2.4/bin/python -c "from test.pystone import pystones; >>>>>> print pystones()" >>>>>> (3.79, 13192.612137203167) >>>>>> >>>>>> >>>>>> >>>>>> From the release24-maint branch built on my box:: >>>>>> >>>>>> [shane at dynamic-46] python/py-24% svn info >>>>>> Path: . >>>>>> URL: http://svn.python.org/projects/python/branches/release24- >>>>>> maint >>>>>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>>>>> Revision: 43662 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: martin.v.loewis >>>>>> Last Changed Rev: 43618 >>>>>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>>>>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 >>>>>> Apr 2006) >>>>>> >>>>>> [shane at dynamic-46] python/py-24% ./python.exe -V >>>>>> Python 2.4.4c0 >>>>>> [shane at dynamic-46] python/py-24% ./python.exe -c "from >>>>>> test.pystone import pystones; print pystones()" >>>>>> (1.5799999999999998, 31645.569620253169) >>>>>> >>>>>> _______________________________________________ >>>>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>>> >>>>> ---- >>>>> Ted Leung Blog: >>>> blog> >>>>> This message is: [ ] bloggable [x] ask first [ ] private >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >> >> ---- >> Ted Leung Blog: >> This message is: [ ] bloggable [x] ask first [ ] private >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/4c5871d2/attachment-0001.htm From berkowit at silcom.com Fri Apr 7 07:38:32 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Thu, 06 Apr 2006 22:38:32 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <448CDF8F-A0AF-459D-800B-AC4715398BAB@redivi.com> Message-ID: Maybe someone should ask on the Xcode mailing list. Almost every question is being answered there by the lead Xcode Tools Apple engineer, Chris Espinosa. -- Paul Berkowitz From: Bob Ippolito Date: Thu, 6 Apr 2006 22:34:26 -0700 To: Ted Leung Cc: Subject: Re: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison Ok, I see what the problem is, because the Universal python is also half as fast on my PPC. It appears that the universal build is not using any compiler optimizations at all, where a normal build is -O3.? I'm not quite sure where/why this is happening (autoconf is evil), but I'm sure someone will figure it out soon enough. # universal OPT=? ? ? ? -DNDEBUG -g # normal OPT=? ? ? ? -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -bob On Apr 6, 2006, at 10:04 PM, Ted Leung wrote: > I just realized that I only sent this to Shane, so for the whole list (and > Alex) > > Hmm.? Here's three of those... > > [sprout:2065]> ./python.exe -c "from test.pystone import pystones; print > pystones()" > (1.22, 40983.606557377047) > =============================================================== 2006-04-06 > 18:06 > [sprout:2065]> ./python.exe -c "from test.pystone import pystones; print > pystones()" > (1.23, 40650.406504065038) > =============================================================== 2006-04-06 > 18:06 > [sprout:2065]> ./python.exe -c "from test.pystone import pystones; print > pystones()" > (1.22, 40983.606557377047) > > > > On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote: > >> Nice.? Very?jealous about the Intel MacBook Pros.? :)? You both better put >> them to good use!? ;) >> >> Have either of you tried building the 2.4 release branch and running pystones >> from it? >> >> For those reading who may not know how from Terminal:: >> >> svn co http://svn.python.org/projects/python/branches/release24-maint py-24 >> cd?py-24 >> ./configure >> make >> ./python.exe -c "from test.pystone import pystones; print pystones()" >> >> >> On Apr 6, 2006, at 16:15, Jordan Mantha wrote: >> >>> And here is mine on a 1.83GHz 17" Intel iMac: >>> >>> $ python -V >>> Python 2.4.3 >>> >>> $ python -c "from test.pystone import pystones; print pystones()" >>> (1.99, 25125.628140703517) >>> >>> -Jordan Mantha >>> >>> >>> On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: >>> >>>> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >>>> >>>> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/bin/python >>>> -c "from test.pystone import pystones; print pystones()" >>>> (2.0400000000000005, 24509.803921568622) >>>> =============================================================== 2006-04-06 >>>> 14:35[sprout:2132]> >>>> /Library/Frameworks/Python.framework/Versions/2.4/bin/python -c "from >>>> test.pystone import pystones; print pystones()" >>>> (2.0299999999999998, 24630.541871921185) >>>> =============================================================== 2006-04-06 >>>> 14:35[sprout:2132]> >>>> /Library/Frameworks/Python.framework/Versions/2.4/bin/python -c "from >>>> test.pystone import pystones; print pystones()" >>>> (2.0800000000000005, 24038.461538461532) >>>> >>>> Ted >>>> >>>> >>>> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >>>> >>>>> I was just wondering if anyone else had compared pystones on their box?? I >>>>> downloaded the latest Universal Build from the python.org and found things >>>>> to be a bit sluggish. ?So I ran the pystones test to quickly gauge things, >>>>> and noticed that things are indeed running about 1/3 of what they should >>>>> be.? (Specific info from the Terminal below.)? Anyone have ideas?? They >>>>> both appear to be built from GCC 4.0.? Let me know what other information >>>>> you need from me. >>>>> >>>>> Also, are there build instructions for creating the Universal Packaging? >>>>> >>>>> Thanks, >>>>> -Shane Holloway >>>>> >>>>> >>>>> >>>>> From the Universal Build installed python:: >>>>> >>>>> [shane at dynamic-46] ~% >>>>> /Library/Frameworks/Python.framework/Versions/2.4/bin/python -V >>>>> Python 2.4.3 >>>>> [shane at dynamic-46] ~% >>>>> /Library/Frameworks/Python.framework/Versions/2.4/bin/python -c "from >>>>> test.pystone import pystones; print pystones()" >>>>> (3.79, 13192.612137203167) >>>>> >>>>> >>>>> >>>>> From the release24-maint branch built on my box:: >>>>> >>>>> [shane at dynamic-46] python/py-24% svn info >>>>> Path: . >>>>> URL: http://svn.python.org/projects/python/branches/release24-maint >>>>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>>>> Revision: 43662 >>>>> Node Kind: directory >>>>> Schedule: normal >>>>> Last Changed Author: martin.v.loewis >>>>> Last Changed Rev: 43618 >>>>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>>>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr 2006) >>>>> >>>>> [shane at dynamic-46] python/py-24% ./python.exe -V >>>>> Python 2.4.4c0 >>>>> [shane at dynamic-46] python/py-24% ./python.exe -c "from test.pystone import >>>>> pystones; print pystones()" >>>>> (1.5799999999999998, 31645.569620253169) >>>>> ?? >>>>> _______________________________________________ >>>>> Pythonmac-SIG maillist? -? Pythonmac-SIG at python.org >>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>>> >>>> >>>> >>>> ---- >>>> Ted Leung? ? ? ? ? ? ? ? ? ? ? ? ? Blog: >>>> This message is:? [ ] bloggable ? [x] ask first? ? [ ] private >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist? -? Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist? -? Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >> > > > ---- > Ted Leung? ? ? ? ? ? ? ? ? ? ? ? ? Blog: > This message is:? [ ] bloggable ? [x] ask first? ? [ ] private > > > > _______________________________________________ > Pythonmac-SIG maillist? -? Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/e40bb229/attachment.html From bob at redivi.com Fri Apr 7 08:08:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 6 Apr 2006 23:08:22 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: References: Message-ID: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> It really has nothing to do with Xcode (or even GCC). This is all autoconf, but I'm pretty sure it was just that Ronald had an OPT environment variable set when he built it because I can't reproduce. -bob On Apr 6, 2006, at 10:38 PM, Paul Berkowitz wrote: > Maybe someone should ask on the Xcode mailing list. Almost every > question is being answered there by the lead Xcode Tools Apple > engineer, Chris Espinosa. > > -- > Paul Berkowitz > > > From: Bob Ippolito > Date: Thu, 6 Apr 2006 22:34:26 -0700 > To: Ted Leung > Cc: > Subject: Re: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone > Comparison > > Ok, I see what the problem is, because the Universal python is also > half as fast on my PPC. > > It appears that the universal build is not using any compiler > optimizations at all, where a normal build is -O3. I'm not quite > sure where/why this is happening (autoconf is evil), but I'm sure > someone will figure it out soon enough. > > # universal > OPT= -DNDEBUG -g > > # normal > OPT= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes > > -bob > > On Apr 6, 2006, at 10:04 PM, Ted Leung wrote: > >> I just realized that I only sent this to Shane, so for the whole >> list (and Alex) >> >> Hmm. Here's three of those... >> >> [sprout:2065]> ./python.exe -c "from test.pystone import pystones; >> print pystones()" >> (1.22, 40983.606557377047) >> =============================================================== >> 2006-04-06 18:06 >> [sprout:2065]> ./python.exe -c "from test.pystone import pystones; >> print pystones()" >> (1.23, 40650.406504065038) >> =============================================================== >> 2006-04-06 18:06 >> [sprout:2065]> ./python.exe -c "from test.pystone import pystones; >> print pystones()" >> (1.22, 40983.606557377047) >> >> >> >> On Apr 6, 2006, at 5:08 PM, Shane Holloway (IEEE) wrote: >> >>> Nice. Very jealous about the Intel MacBook Pros. :) You both >>> better put them to good use! ;) >>> >>> Have either of you tried building the 2.4 release branch and >>> running pystones from it? >>> >>> For those reading who may not know how from Terminal:: >>> >>> svn co http://svn.python.org/projects/python/branches/release24- >>> maint py-24 >>> cd py-24 >>> ./configure >>> make >>> ./python.exe -c "from test.pystone import pystones; print pystones >>> ()" >>> >>> >>> On Apr 6, 2006, at 16:15, Jordan Mantha wrote: >>> >>>> And here is mine on a 1.83GHz 17" Intel iMac: >>>> >>>> $ python -V >>>> Python 2.4.3 >>>> >>>> $ python -c "from test.pystone import pystones; print pystones()" >>>> (1.99, 25125.628140703517) >>>> >>>> -Jordan Mantha >>>> >>>> >>>> On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: >>>> >>>>> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >>>>> >>>>> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/ >>>>> 2.4/bin/python -c "from test.pystone import pystones; print >>>>> pystones()" >>>>> (2.0400000000000005, 24509.803921568622) >>>>> =============================================================== >>>>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>>>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>>>> import pystones; print pystones()" >>>>> (2.0299999999999998, 24630.541871921185) >>>>> =============================================================== >>>>> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >>>>> Python.framework/Versions/2.4/bin/python -c "from test.pystone >>>>> import pystones; print pystones()" >>>>> (2.0800000000000005, 24038.461538461532) >>>>> >>>>> Ted >>>>> >>>>> >>>>> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >>>>> >>>>>> I was just wondering if anyone else had compared pystones on >>>>>> their box? I downloaded the latest Universal Build from the >>>>>> python.org and found things to be a bit sluggish. So I ran >>>>>> the pystones test to quickly gauge things, and noticed that >>>>>> things are indeed running about 1/3 of what they should be. >>>>>> (Specific info from the Terminal below.) Anyone have ideas? >>>>>> They both appear to be built from GCC 4.0. Let me know what >>>>>> other information you need from me. >>>>>> >>>>>> Also, are there build instructions for creating the Universal >>>>>> Packaging? >>>>>> >>>>>> Thanks, >>>>>> -Shane Holloway >>>>>> >>>>>> >>>>>> >>>>>> >From the Universal Build installed python:: >>>>>> >>>>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>>>> Versions/2.4/bin/python -V >>>>>> Python 2.4.3 >>>>>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>>>>> Versions/2.4/bin/python -c "from test.pystone import pystones; >>>>>> print pystones()" >>>>>> (3.79, 13192.612137203167) >>>>>> >>>>>> >>>>>> >>>>>> >From the release24-maint branch built on my box:: >>>>>> >>>>>> [shane at dynamic-46] python/py-24% svn info >>>>>> Path: . >>>>>> URL: http://svn.python.org/projects/python/branches/release24- >>>>>> maint >>>>>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>>>>> Revision: 43662 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: martin.v.loewis >>>>>> Last Changed Rev: 43618 >>>>>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>>>>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 >>>>>> Apr 2006) >>>>>> >>>>>> [shane at dynamic-46] python/py-24% ./python.exe -V >>>>>> Python 2.4.4c0 >>>>>> [shane at dynamic-46] python/py-24% ./python.exe -c "from >>>>>> test.pystone import pystones; print pystones()" >>>>>> (1.5799999999999998, 31645.569620253169) >>>>>> >>>>>> _______________________________________________ >>>>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>>>> >>>>> >>>>> >>>>> ---- >>>>> Ted Leung Blog: >>>> blog> >>>>> This message is: [ ] bloggable [x] ask first [ ] private >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>>> >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>> >> >> >> ---- >> Ted Leung Blog: >> This message is: [ ] bloggable [x] ask first [ ] private >> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/d9ed784f/attachment-0001.htm From wescpy at gmail.com Fri Apr 7 09:07:05 2006 From: wescpy at gmail.com (w chun) Date: Fri, 7 Apr 2006 00:07:05 -0700 Subject: [Pythonmac-SIG] Problem w/Tkinter on 2.5 (Panther) In-Reply-To: <78b3a9580603301730p37691ea1x90b7d2ce7c34e90a@mail.gmail.com> References: <78b3a9580603301730p37691ea1x90b7d2ce7c34e90a@mail.gmail.com> Message-ID: <78b3a9580604070007w32d91355k4022ad8a4dfc3115@mail.gmail.com> update: the original build i used was 2.5a0 on Mar 28. with the latest 2.5a1 on Apr 6, i don't see this problem anymore, and my Tkinter scripts run fine straight from the shell. i love it when problems disappear like this, but it always leaves me wondering what the breakage was and what fixed it. -wesley On 3/30/06, w chun wrote: > Russell suggested that I xPost to you folks on the MacSIG list... > > http://mail.python.org/pipermail/python-list/2006-March/333614.html From ronaldoussoren at mac.com Fri Apr 7 09:08:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 07 Apr 2006 09:08:36 +0200 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> References: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> Message-ID: <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> On Friday, April 07, 2006, at 08:10AM, Bob Ippolito wrote: > It really has nothing to do with Xcode (or even GCC). This is all autoconf, but I'm pretty sure it was just that Ronald had an OPT > environment variable set when he built it because I can't reproduce. See Mac/OSX/Dist/build-installer.py. That indeed sets OPT to ensure that universal binary version libraries for bsddb and readline get picked up by the build process. I can rebuild the installer, but that will likely not happen until sometime next week due to lack of time. Ronald From ronaldoussoren at mac.com Fri Apr 7 15:33:26 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 07 Apr 2006 15:33:26 +0200 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> References: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> Message-ID: <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> On Friday, April 07, 2006, at 09:09AM, Ronald Oussoren wrote: > >On Friday, April 07, 2006, at 08:10AM, Bob Ippolito wrote: > >> It really has nothing to do with Xcode (or even GCC). This is all autoconf, but I'm pretty sure it was just that Ronald had an OPT >> environment variable set when he built it because I can't reproduce. > >See Mac/OSX/Dist/build-installer.py. That indeed sets OPT to ensure that universal binary version libraries for bsddb and readline get picked up by the build process. I can rebuild the installer, but that will likely not happen until sometime next week due to lack of time. I found some time to fire up the compiler. There's a new build of the 2.4.3 installer on my iDisk. If that works correctly I'll ask someone to replace the DMG on python.org. Please test if this fixes the speed issues and works in general, I haven't done any testing. The only thing changes w.r.t. the 2.4.3 DMG on python.org is the addition of -O3 to the compile flags. Ronald > >Ronald >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From zbir at urbanape.com Fri Apr 7 15:55:12 2006 From: zbir at urbanape.com (Zachery Bir) Date: Fri, 7 Apr 2006 09:55:12 -0400 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> References: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> Message-ID: On Apr 7, 2006, at 9:33 AM, Ronald Oussoren wrote: > I found some time to fire up the compiler. There's a new build of > the 2.4.3 installer on my iDisk. If that works correctly I'll ask > someone to replace the DMG on python.org. Please test if this > fixes the speed issues and works in general, I haven't done any > testing. The only thing changes w.r.t. the 2.4.3 DMG on python.org > is the addition of -O3 to the compile flags. *That's* mo' bettah (MacBook Pro 2.0GHz, 2GB RAM): zbir at Silverback $ python2.4 -c "from test.pystone import pystones; print pystones()" (1.1199999999999999, 44642.857142857145) ~ zbir at Silverback $ python2.4 -c "from test.pystone import pystones; print pystones()" (1.1499999999999999, 43478.260869565223) ~ zbir at Silverback $ python2.4 -c "from test.pystone import pystones; print pystones()" (1.1199999999999999, 44642.857142857145) Zac From daniellord at mac.com Fri Apr 7 16:59:52 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 7 Apr 2006 07:59:52 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: References: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> Message-ID: <9621BFF7-D7EE-4DF1-953A-31196981B48D@mac.com> ;-( Thanks Ron--Not! Now my 1.8 Dual really looks long in the tooth at 3.0 pystones. Guess I need to buy a MacBook now that it runs rings around my clunky old desktop. It would be interesting to see how the dual core G5 and Quad core do as well as the 2+ Ghz newer duals. I know the original G5s had a memory bottleneck and I am curious to see if the the DDR3 in the MacBook is what widened it or if the DDR2 and memory bus in the 2D Gen G5s removed it. On Apr 7, 2006, at 6:55 AM, Zachery Bir wrote: > On Apr 7, 2006, at 9:33 AM, Ronald Oussoren wrote: > >> I found some time to fire up the compiler. There's a new build of >> the 2.4.3 installer on my iDisk. If that works correctly I'll ask >> someone to replace the DMG on python.org. Please test if this >> fixes the speed issues and works in general, I haven't done any >> testing. The only thing changes w.r.t. the 2.4.3 DMG on python.org >> is the addition of -O3 to the compile flags. > > *That's* mo' bettah (MacBook Pro 2.0GHz, 2GB RAM): > > zbir at Silverback $ python2.4 -c "from test.pystone import pystones; > print pystones()" > (1.1199999999999999, 44642.857142857145) > ~ > zbir at Silverback $ python2.4 -c "from test.pystone import pystones; > print pystones()" > (1.1499999999999999, 43478.260869565223) > ~ > zbir at Silverback $ python2.4 -c "from test.pystone import pystones; > print pystones()" > (1.1199999999999999, 44642.857142857145) > > Zac > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From shane.holloway at ieee.org Fri Apr 7 02:08:38 2006 From: shane.holloway at ieee.org (Shane Holloway (IEEE)) Date: Thu, 6 Apr 2006 18:08:38 -0600 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: References: <8E4BBF6B-2858-4085-AACA-BB194F231A2B@sauria.com> Message-ID: <5A40CDFB-2319-462E-B34D-45592BEF7320@ieee.org> Nice. Very jealous about the Intel MacBook Pros. :) You both better put them to good use! ;) Have either of you tried building the 2.4 release branch and running pystones from it? For those reading who may not know how from Terminal:: svn co http://svn.python.org/projects/python/branches/release24-maint py-24 cd py-24 ./configure make ./python.exe -c "from test.pystone import pystones; print pystones()" On Apr 6, 2006, at 16:15, Jordan Mantha wrote: > And here is mine on a 1.83GHz 17" Intel iMac: > > $ python -V > Python 2.4.3 > > $ python -c "from test.pystone import pystones; print pystones()" > (1.99, 25125.628140703517) > > -Jordan Mantha > > > On Apr 6, 2006, at 2:36 PM, Ted Leung wrote: > >> FWIW here are 3 runs from 1.83GHz MacBook Pro.... >> >> [sprout:2132]> /Library/Frameworks/Python.framework/Versions/2.4/ >> bin/python -c "from test.pystone import pystones; print pystones()" >> (2.0400000000000005, 24509.803921568622) >> =============================================================== >> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >> Python.framework/Versions/2.4/bin/python -c "from test.pystone >> import pystones; print pystones()" >> (2.0299999999999998, 24630.541871921185) >> =============================================================== >> 2006-04-06 14:35[sprout:2132]> /Library/Frameworks/ >> Python.framework/Versions/2.4/bin/python -c "from test.pystone >> import pystones; print pystones()" >> (2.0800000000000005, 24038.461538461532) >> >> Ted >> >> >> On Apr 6, 2006, at 1:39 PM, Shane Holloway (IEEE) wrote: >> >>> I was just wondering if anyone else had compared pystones on >>> their box? I downloaded the latest Universal Build from the >>> python.org and found things to be a bit sluggish. So I ran the >>> pystones test to quickly gauge things, and noticed that things >>> are indeed running about 1/3 of what they should be. (Specific >>> info from the Terminal below.) Anyone have ideas? They both >>> appear to be built from GCC 4.0. Let me know what other >>> information you need from me. >>> >>> Also, are there build instructions for creating the Universal >>> Packaging? >>> >>> Thanks, >>> -Shane Holloway >>> >>> >>> >>> From the Universal Build installed python:: >>> >>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>> Versions/2.4/bin/python -V >>> Python 2.4.3 >>> [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/ >>> Versions/2.4/bin/python -c "from test.pystone import pystones; >>> print pystones()" >>> (3.79, 13192.612137203167) >>> >>> >>> >>> From the release24-maint branch built on my box:: >>> >>> [shane at dynamic-46] python/py-24% svn info >>> Path: . >>> URL: http://svn.python.org/projects/python/branches/release24-maint >>> Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 >>> Revision: 43662 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: martin.v.loewis >>> Last Changed Rev: 43618 >>> Last Changed Date: 2006-04-04 00:08:17 -0600 (Tue, 04 Apr 2006) >>> Properties Last Updated: 2006-04-03 14:39:26 -0600 (Mon, 03 Apr >>> 2006) >>> >>> [shane at dynamic-46] python/py-24% ./python.exe -V >>> Python 2.4.4c0 >>> [shane at dynamic-46] python/py-24% ./python.exe -c "from >>> test.pystone import pystones; print pystones()" >>> (1.5799999999999998, 31645.569620253169) >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> ---- >> Ted Leung Blog: >> This message is: [ ] bloggable [x] ask first [ ] private >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060406/3c05a0c8/attachment-0001.html From shane.holloway at ieee.org Fri Apr 7 17:43:22 2006 From: shane.holloway at ieee.org (Shane Holloway (IEEE)) Date: Fri, 7 Apr 2006 09:43:22 -0600 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> References: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> Message-ID: <7AD7C5D5-6FAB-408E-A5AE-4D8B3D696836@ieee.org> Works great!! Thanks Ronald & crew! [shane at dynamic-46] ~% /Library/Frameworks/Python.framework/Versions/ 2.4/bin/python -c "from test.pystone import pystones; print pystones()" (1.6299999999999999, 30674.846625766873) Very exciting times in the Mac community all around. Looking forward to so many things... Thanks, -Shane On Apr 7, 2006, at 07:33, Ronald Oussoren wrote: > > On Friday, April 07, 2006, at 09:09AM, Ronald Oussoren > wrote: > >> >> On Friday, April 07, 2006, at 08:10AM, Bob Ippolito >> wrote: >> >>> It really has nothing to do with Xcode (or even GCC). This is >>> all autoconf, but I'm pretty sure it was just that Ronald had an OPT >>> environment variable set when he built it because I can't reproduce. >> >> See Mac/OSX/Dist/build-installer.py. That indeed sets OPT to >> ensure that universal binary version libraries for bsddb and >> readline get picked up by the build process. I can rebuild the >> installer, but that will likely not happen until sometime next >> week due to lack of time. > > I found some time to fire up the compiler. There's a new build of > the 2.4.3 installer on my iDisk. If that works correctly I'll ask > someone to replace the DMG on python.org. Please test if this > fixes the speed issues and works in general, I haven't done any > testing. The only thing changes w.r.t. the 2.4.3 DMG on python.org > is the addition of -O3 to the compile flags. > > Ronald > >> >> Ronald >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From twl at sauria.com Fri Apr 7 18:51:51 2006 From: twl at sauria.com (Ted Leung) Date: Fri, 7 Apr 2006 09:51:51 -0700 Subject: [Pythonmac-SIG] 2.4.3 Python Universal Binary Pystone Comparison In-Reply-To: <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> References: <539FF965-FE41-4E4D-BFF3-19285E160AFE@redivi.com> <556142.1144393716492.JavaMail.ronaldoussoren@mac.com> <1486725.1144416806358.JavaMail.ronaldoussoren@mac.com> Message-ID: <0200ECBC-AE5B-4F6E-847B-19E61AE705C9@sauria.com> Looks good here, too: [sprout:2012]> /Library/Frameworks/Python.framework/Versions/2.4/bin/ python -c "from test.pystone import pystones; print pystones()" (1.26, 39682.539682539682) =============================================================== 2006-04-07 9:50 [sprout:2012]> /Library/Frameworks/Python.framework/Versions/2.4/bin/ python -c "from test.pystone import pystones; print pystones()" (1.25, 40000.0) =============================================================== 2006-04-07 9:50 [sprout:2012]> /Library/Frameworks/Python.framework/Versions/2.4/bin/ python -c "from test.pystone import pystones; print pystones()" (1.25, 40000.0) Ted On Apr 7, 2006, at 6:33 AM, Ronald Oussoren wrote: > > On Friday, April 07, 2006, at 09:09AM, Ronald Oussoren > wrote: > >> >> On Friday, April 07, 2006, at 08:10AM, Bob Ippolito >> wrote: >> >>> It really has nothing to do with Xcode (or even GCC). This is >>> all autoconf, but I'm pretty sure it was just that Ronald had an OPT >>> environment variable set when he built it because I can't reproduce. >> >> See Mac/OSX/Dist/build-installer.py. That indeed sets OPT to >> ensure that universal binary version libraries for bsddb and >> readline get picked up by the build process. I can rebuild the >> installer, but that will likely not happen until sometime next >> week due to lack of time. > > I found some time to fire up the compiler. There's a new build of > the 2.4.3 installer on my iDisk. If that works correctly I'll ask > someone to replace the DMG on python.org. Please test if this > fixes the speed issues and works in general, I haven't done any > testing. The only thing changes w.r.t. the 2.4.3 DMG on python.org > is the addition of -O3 to the compile flags. > > Ronald > >> >> Ronald >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ---- Ted Leung Blog: This message is: [ ] bloggable [x] ask first [ ] private From rowen at cesmail.net Fri Apr 7 21:01:26 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Fri, 07 Apr 2006 12:01:26 -0700 Subject: [Pythonmac-SIG] Suggest Aqua Tcl/Tk 8.4.11 instead of 8.4.12 Message-ID: I produce a cross-platform Python/Tkinter application. The last major release ran fine emulated on an intel Mac, but when I produced a recent alpha, that one did not. The new version had serious problems with pointer coordinates (in an image viewer that shows the image coords as the mouse moves over the image). Moving the window trashed the reported pixel positions. I tracked this difference down to "upgrading" from Aqua Tcl/Tk 8.4.11 to 8.4.12. The same software runs fine (under emulation on an intel mac) if built with 8.4.11. I have not seen the problem on my 10.3.9 Mac yet, but I have also not looked very hard, so I just don't know if it's there. In any case, the safest course is for Mac Python/Tkinter users to stick to Aqua Tcl/Tk 8.4.11. It is the best release I've seen in years, fixing some important long-standing issues on Aqua. Hoping this saves somebody some trouble... -- Russell From kevino at theolliviers.com Fri Apr 7 23:55:24 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Fri, 7 Apr 2006 14:55:24 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup References: Message-ID: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Hi all, Sorry this has taken forever and a day, but I didn't really want to say too much until I had something ready to show. Here is a 3D mock- up by Kenichi Yoshida (http://www.kenichiyoshida.jp/), who I've been working with on the icon. http://kevino.theolliviers.com/0406_macpython.jpg I think if you look at the design, you can pretty much tell the 'concept' behind it, but I'll go ahead and mention it anyways. :-) Basically, the blocks are the "building blocks" of Python. By putting those blocks together, of course, you get something that is greater than the sum of its parts - in this case, Python. Python (the language) is also the "glue" holding the blocks together. I personally like this icon quite a bit. It shows the modular nature of Python, and also has a sense of creativity embedded in it. The thought of building castles, ships, etc. from Legos immediately came to mind to me, and I thought that was such a fitting image for Python, particularly because it gives an image of trying things out and experimenting which is what Python is all about, IMHO. I personally can't think of any other icon design I've seen that pays homage both to the 'snake' image of Python, and yet also expresses the core ideas behind the language in such a visual and intuitive way. As an icon, the shape is colorful and distinctive but IMHO not too busy, so this icon will be recognizable even at small sizes. Some things to note: - The final icon will be in the OS X photo-illustrative style (see his web site for examples). This 3D mockup is to review the design of the icon. - We plan in the final design to put a basic face onto the head - think of the lego character faces; two white eyes with black dots, a line for the mouth, probably two black dots for nostrils, etc. I think that will further stress the creativity aspect of it and make it a little more distinctive as an icon. Thoughts? Comments? Thanks, Kevin From zbir at urbanape.com Sat Apr 8 00:11:43 2006 From: zbir at urbanape.com (Zachery Bir) Date: Fri, 7 Apr 2006 18:11:43 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> References: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Message-ID: <9736EEAA-EC4F-42FD-89DE-D1FCAC23D6BE@urbanape.com> On Apr 7, 2006, at 5:55 PM, Kevin Ollivier wrote: > Hi all, > > Sorry this has taken forever and a day, but I didn't really want to > say too much until I had something ready to show. Here is a 3D mock- > up by Kenichi Yoshida (http://www.kenichiyoshida.jp/), who I've been > working with on the icon. > > http://kevino.theolliviers.com/0406_macpython.jpg [snip] > Thoughts? Comments? Actually, I quite like it. I'd like to see the scaled down versions, of course, but it's kinda keen in a Breve model kinda way :^) Zac From loredo at astro.cornell.edu Sat Apr 8 00:24:53 2006 From: loredo at astro.cornell.edu (Tom Loredo) Date: Fri, 7 Apr 2006 18:24:53 -0400 Subject: [Pythonmac-SIG] libpython2.4 for OS X? Message-ID: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> Hi folks, I'm introducing a colleague of mine to Python. He heavily uses R, and so is interested in using the RPy (R from Python) and RSPython (R-Python bidirectional bridge) packages. We have RPy working, with plots displayed via X11; the quartz interface suffers the spinning ball problem, even when it's run with pythonw. The challenge is RSPython. The install fails at ./configure because it can't find a libpython2.4 library anywhere. I've looked for one in the usual places (/usr/lib, /usr/local/lib, Python.framework), but can't find one. Is there one lurking somewhere that I'm overlooking? If one is not in MacPython, is there a good reason (i.e., a reason it wouldn't be useful), or is there a way we can build one? He is using MacPython; I'm using ActivePython; we can't find the library in either case. Thanks, Tom Loredo ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From bob at redivi.com Sat Apr 8 00:39:17 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 7 Apr 2006 15:39:17 -0700 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> Message-ID: <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> On Apr 7, 2006, at 3:24 PM, Tom Loredo wrote: > I'm introducing a colleague of mine to Python. He heavily uses R, > and so is interested in using the RPy (R from Python) and RSPython > (R-Python bidirectional bridge) packages. We have RPy working, > with plots displayed via X11; the quartz interface suffers the > spinning ball problem, even when it's run with pythonw. > > The challenge is RSPython. The install fails at ./configure > because it can't find a libpython2.4 library anywhere. I've > looked for one in the usual places (/usr/lib, /usr/local/lib, > Python.framework), but can't find one. Is there one lurking > somewhere that I'm overlooking? If one is not in MacPython, > is there a good reason (i.e., a reason it wouldn't be useful), > or is there a way we can build one? Frameworks are dynamic libraries (technically MH_DYLIB on OS X), but they do not follow the same naming scheme, so they're not going to get picked up by a typical dumb configure-search. If you wanted, you could make something look like the appropriate dylib: % sudo ln -s ../Python /Library/Frameworks/Python.framework/Versions/ Current/lib/libpython2.4.dylib Then you'd add Python's lib and include dir to that path. Really the right way to link to Python is to ask it how via distutils (or reading the Makefile directly), not to hunt down libpython and whatnot. Software that thinks it knows how to do it manually almost always gets it wrong on at least some platforms. -bob From janssen at parc.com Sat Apr 8 00:54:51 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 7 Apr 2006 15:54:51 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Fri, 07 Apr 2006 14:55:24 PDT." <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Message-ID: <06Apr7.155458pdt."58633"@synergy1.parc.xerox.com> Hmmm... Kevin, I wonder if the checkerboard the blocks are standing on could perhaps become more of a morph of the new yin/yang Python logo. I'd like to see some kind of connection to the graphics being developed for the main Python web site. > http://kevino.theolliviers.com/0406_macpython.jpg Bill From rowen at cesmail.net Sat Apr 8 01:08:40 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Fri, 07 Apr 2006 16:08:40 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup References: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Message-ID: In article <31522BBF-8981-4E4B-88AB-D4EB61B3C417 at theolliviers.com>, Kevin Ollivier wrote: > Some things to note: > > - The final icon will be in the OS X photo-illustrative style (see > his web site for examples). This 3D mockup is to review the design of > the icon. > > - We plan in the final design to put a basic face onto the head - > think of the lego character faces; two white eyes with black dots, a > line for the mouth, probably two black dots for nostrils, etc. I > think that will further stress the creativity aspect of it and make > it a little more distinctive as an icon. > > Thoughts? Comments? I confess my first thought was that it looks a bit like a very distorted P, and that maybe making it look even more like a P (and skipping the snake connection altogether) might be interesting. Anyway, it looks nice to me. Not looking too much like a snake is a win, in my opinion. Much as I like ActiveState, their icon for ActiveState Python gives me the creeps, and I'm probably not the only one. -- Russell From loredo at astro.cornell.edu Sat Apr 8 01:21:20 2006 From: loredo at astro.cornell.edu (Tom Loredo) Date: Fri, 7 Apr 2006 19:21:20 -0400 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> Message-ID: <1144452080.4436f3f0452a6@astrosun2.astro.cornell.edu> Quoting Bob Ippolito : Thanks for the input, Bob. > Frameworks are dynamic libraries (technically MH_DYLIB on OS X), but > they do not follow the same naming scheme, so they're not going to > get picked up by a typical dumb configure-search. > > If you wanted, you could make something look like the appropriate dylib: > > % sudo ln -s ../Python /Library/Frameworks/Python.framework/Versions/ > Current/lib/libpython2.4.dylib > > Then you'd add Python's lib and include dir to that path. The person who is maintaining RSPython clearly didn't have full cross-platform capability in mind; there were one or two other things we had to fix via "ln -s" to get it to go as far as it did. Here I'm not quite clear on what you are suggesting---I'm not clear on where I should be when I "ln -s ../Python ..." Somewhere there is something called just "Python" that can be linked to as if it were a .dylib? -Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From bob at redivi.com Sat Apr 8 01:43:24 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 7 Apr 2006 16:43:24 -0700 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: <1144452080.4436f3f0452a6@astrosun2.astro.cornell.edu> References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> <1144452080.4436f3f0452a6@astrosun2.astro.cornell.edu> Message-ID: On Apr 7, 2006, at 4:21 PM, Tom Loredo wrote: > Quoting Bob Ippolito : > > Thanks for the input, Bob. > >> Frameworks are dynamic libraries (technically MH_DYLIB on OS X), but >> they do not follow the same naming scheme, so they're not going to >> get picked up by a typical dumb configure-search. >> >> If you wanted, you could make something look like the appropriate >> dylib: >> >> % sudo ln -s ../Python /Library/Frameworks/Python.framework/Versions/ >> Current/lib/libpython2.4.dylib >> >> Then you'd add Python's lib and include dir to that path. > > The person who is maintaining RSPython clearly didn't have full > cross-platform capability in mind; there were one or two other > things we had to fix via "ln -s" to get it to go as far as it did. I'd probably lobby to get them to fix the build process rather than maintain platform hack after platform hack. > Here I'm not quite clear on what you are suggesting---I'm not > clear on where I should be when I "ln -s ../Python ..." Somewhere > there is something called just "Python" that can be linked to > as if it were a .dylib? Relative symlinks are relative to the target. It doesn't matter where you do it from, so long as the target is right. The target I gave you is correct. There is a MH_DYLIB at /Library/Frameworks/ Python.framework/Versions/Current/Python, which is the parent dir of the above symlink target. -bob From mantha at chem.unr.edu Sat Apr 8 02:25:02 2006 From: mantha at chem.unr.edu (Jordan Mantha) Date: Fri, 7 Apr 2006 17:25:02 -0700 Subject: [Pythonmac-SIG] Python Universal packages- how can I help Message-ID: <72D32DA2-2E29-4B4B-8BD0-98B46450E40D@chem.unr.edu> Hi all! Ok, so I recently got my first mac, an Intel iMac (17") for work. So far I have been totally impressed. I really enjoy OSX and starting to get into Python more. However, I'm starting to feel bad that I have this thing and I'm not helping with testing/building Universal packages for other people to enjoy. I'm particularly interested in scientific python packages (scipy and friends, matplotlib, pyx, etc.) and wxpython. Is there a general place to find tutorials or something on creating Universal python packages? I'd like to help fill in http://pythonmac.org/wiki/UniversalPackages if I can. How would I go about doing that? Thanks, Jordan Mantha From bob at redivi.com Sat Apr 8 03:12:26 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 7 Apr 2006 18:12:26 -0700 Subject: [Pythonmac-SIG] Python Universal packages- how can I help In-Reply-To: <72D32DA2-2E29-4B4B-8BD0-98B46450E40D@chem.unr.edu> References: <72D32DA2-2E29-4B4B-8BD0-98B46450E40D@chem.unr.edu> Message-ID: <1085A6B0-6292-49A3-850F-466D77285A58@redivi.com> On Apr 7, 2006, at 5:25 PM, Jordan Mantha wrote: > Ok, so I recently got my first mac, an Intel iMac (17") for work. > So far I have been totally impressed. I really enjoy OSX and starting > to get into Python more. However, I'm starting to feel bad that I > have this thing and I'm not helping with testing/building Universal > packages for other people to enjoy. I'm particularly interested in > scientific python packages (scipy and friends, matplotlib, pyx, etc.) > and wxpython. Is there a general place to find tutorials or something > on creating Universal python packages? I'd like to help fill in > http://pythonmac.org/wiki/UniversalPackages if I can. How would I go > about doing that? The packages on that list are "unfriendly" in that they will not trivially compile universally. Getting those packages up to universal snuff is probably best left for the people who are already familiar with the peculiarities of those packages and the nuances of OS X porting and universal binaries. Most other packages should compile trivially out of the box. However, if you have a LOT of free time on your hands and you're interested in the ugly details you'll want to read up on: 1. the lipo command 2. the -arch and -isysroot flags to cc 2. the -syslibroot and -arch flags to ld. The universal build ships with a Makefile that tells distutils what to do, but anything with external dependencies will need those dependencies compiled by hand with custom environment variables to produce a universal static or dynamic library out of them. Sometimes it's trivial, other times not (especially if it does something stupid like endian or CPU detection at ./configure time) and you may have to compile PPC then i386 and lipo the result together (which may require a separate machine for each architecture). -bob From andrew at trevorrow.com Sat Apr 8 06:16:53 2006 From: andrew at trevorrow.com (Andrew Trevorrow) Date: Sat, 8 Apr 2006 14:16:53 +1000 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> Message-ID: At 3:39 PM -0700 7/4/06, Bob Ippolito wrote: > Really the right way to link to Python is to ask it how via distutils ... That's what I'm trying to do for my app, but on 10.4.5 I get an incorrect result using: python -c "import distutils.sysconfig; print distutils.sysconfig.get_config_var('LINKFORSHARED')" The result is: -u __dummy -u _PyMac_Error -framework System Python.framework/Versions/2.3/Python -framework CoreServices -framework Foundation This causes the link stage to fail because it contains "Python.framework/Versions/2.3/Python" rather than "-framework Python". Anybody got a fix for this? Andrew From bob at redivi.com Sat Apr 8 06:22:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 7 Apr 2006 21:22:12 -0700 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> Message-ID: <69843291-8010-4AB5-94CB-01E074781188@redivi.com> On Apr 7, 2006, at 9:16 PM, Andrew Trevorrow wrote: > At 3:39 PM -0700 7/4/06, Bob Ippolito wrote: > >> Really the right way to link to Python is to ask it how via >> distutils ... > > That's what I'm trying to do for my app, but on 10.4.5 I get an > incorrect > result using: > > python -c "import distutils.sysconfig; print > distutils.sysconfig.get_config_var('LINKFORSHARED')" > > The result is: > > -u __dummy -u _PyMac_Error -framework System Python.framework/ > Versions/2.3/Python -framework CoreServices -framework Foundation > > This causes the link stage to fail because it contains > "Python.framework/Versions/2.3/Python" rather than "-framework > Python". > > Anybody got a fix for this? You'd get the right result if you had a Python.framework symlink in your build dir. It doesn't use -framework Python because that's ambiguous without setting a bunch of environment variables. -bob From vivacarlie at gmail.com Sat Apr 8 06:39:22 2006 From: vivacarlie at gmail.com (Nehemiah Dacres) Date: Fri, 7 Apr 2006 23:39:22 -0500 Subject: [Pythonmac-SIG] is anyone annoyed with MacPython2.4's IDLE's cursor info Message-ID: <65fadfc30604072139u198bd372m3a9cd41b3aa25243@mail.gmail.com> I just don't like it being in the same corner as the resize handle (mostly because it completely distorts the text underneath) so maybe it should be moved to the left instead of the right bottom corner. has anyone else had a problem with this? Is there any reason for this design choice? will it be changed in the future? While im at it, will there ever be the same kind of syntax coloring in "Python IDE" otherwise I'll just continue to use TextWrangler"? From mantha at chem.unr.edu Sat Apr 8 06:58:07 2006 From: mantha at chem.unr.edu (Jordan Mantha) Date: Fri, 07 Apr 2006 21:58:07 -0700 Subject: [Pythonmac-SIG] Python Universal packages- how can I help In-Reply-To: <1085A6B0-6292-49A3-850F-466D77285A58@redivi.com> References: <72D32DA2-2E29-4B4B-8BD0-98B46450E40D@chem.unr.edu> <1085A6B0-6292-49A3-850F-466D77285A58@redivi.com> Message-ID: <443742DF.4090403@chem.unr.edu> Bob Ippolito wrote: > > On Apr 7, 2006, at 5:25 PM, Jordan Mantha wrote: > >> Ok, so I recently got my first mac, an Intel iMac (17") for work. >> So far I have been totally impressed. I really enjoy OSX and starting >> to get into Python more. However, I'm starting to feel bad that I >> have this thing and I'm not helping with testing/building Universal >> packages for other people to enjoy. I'm particularly interested in >> scientific python packages (scipy and friends, matplotlib, pyx, etc.) >> and wxpython. Is there a general place to find tutorials or something >> on creating Universal python packages? I'd like to help fill in >> http://pythonmac.org/wiki/UniversalPackages if I can. How would I go >> about doing that? > > The packages on that list are "unfriendly" in that they will not > trivially compile universally. Getting those packages up to universal > snuff is probably best left for the people who are already familiar with > the peculiarities of those packages and the nuances of OS X porting and > universal binaries. Most other packages should compile trivially out of > the box. > > However, if you have a LOT of free time on your hands and you're > interested in the ugly details you'll want to read up on: > 1. the lipo command > 2. the -arch and -isysroot flags to cc > 2. the -syslibroot and -arch flags to ld. > > The universal build ships with a Makefile that tells distutils what to > do, but anything with external dependencies will need those dependencies > compiled by hand with custom environment variables to produce a > universal static or dynamic library out of them. Sometimes it's > trivial, other times not (especially if it does something stupid like > endian or CPU detection at ./configure time) and you may have to compile > PPC then i386 and lipo the result together (which may require a separate > machine for each architecture). > Thanks for the info. I'll try to check those points. The universal builds sound a bit scary, which is probably the reason they aren't all over the place. I would assume creating Intel-only packages is easier, is that right? Can bdist_mpkg (and py2app for that matter) be used on Intel macs with the Universal Python 2.4.3 build? I'd like to learn how to use bdist_mpkg and py2app. I'm having a bit of trouble figuring where various packages are when it comes to Intel compatibility. Would making .mpkgs be a more realistic goal? Sorry if my questions are seeming silly. I'm used to building from source for myself and Linux packaging. -Jordan Mantha From andrew at trevorrow.com Sat Apr 8 09:23:33 2006 From: andrew at trevorrow.com (Andrew Trevorrow) Date: Sat, 8 Apr 2006 17:23:33 +1000 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: <69843291-8010-4AB5-94CB-01E074781188@redivi.com> References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> <69843291-8010-4AB5-94CB-01E074781188@redivi.com> Message-ID: At 9:22 PM -0700 7/4/06, Bob Ippolito wrote: > On Apr 7, 2006, at 9:16 PM, Andrew Trevorrow wrote: > >> At 3:39 PM -0700 7/4/06, Bob Ippolito wrote: >> >>> Really the right way to link to Python is to ask it how via distutils ... >> >> That's what I'm trying to do for my app, but on 10.4.5 I get an incorrect >> result using: >> >> python -c "import distutils.sysconfig; print distutils.sysconfig.get_config_var('LINKFORSHARED')" >> >> The result is: >> >> -u __dummy -u _PyMac_Error -framework System Python.framework/Versions/2.3/Python -framework CoreServices -framework Foundation >> >> This causes the link stage to fail because it contains >> "Python.framework/Versions/2.3/Python" rather than "-framework Python". >> >> Anybody got a fix for this? > > You'd get the right result if you had a Python.framework symlink in your build dir. But I didn't have to do that on 10.3.9. Are you saying that the info here http://pythonmac.org/wiki/FAQ#head-9dfb0aba2a1a5c882ae0ba329fda3e16e6835e2f is no longer correct for 10.4? > It doesn't use -framework Python because that's ambiguous without setting a bunch of environment variables. So what is the correct way to link an app that embeds Python on 10.4.x? I'll be happy to update the above wiki entry when I find out. All I'm trying to do is find a safe way to link our app against the Apple-supplied Python framework on 10.3, 10.4, etc. Andrew From charles.hartman at conncoll.edu Sat Apr 8 14:59:58 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 8 Apr 2006 08:59:58 -0400 Subject: [Pythonmac-SIG] talking points, Pythonismus Message-ID: <2DD4521E-D358-40EF-897D-5AB5E6912DB5@conncoll.edu> I've been campaigning with the main teacher of programming on my campus -- from my thoroughly non-leveraged position as prof of English -- to consider switching from Java to Python, for all the reasons which will be obvious to everybody here. (The existence of "wxPython in Action" is the decisive event for me.) I recently got a thoughtful reply from him which included this paragraph: > Actually, I am using Matlab, which is dynamically typed as well, in > some of my courses and I know it works well until types become > important. In image processing, for example, they easily mistake > the 'byte' data types for doubles which are the default. Ease of > use leads to overconfidence in this case. Sometimes they claim that > the program (the interpreter) isn't working right. I wonder if anybody has any suggestions about useful answers to this. Charles Charles Hartman Professor of English, Poet in Residence Connecticut College charles.hartman at conncoll.edu *the Scandroid* is at cherry.conncoll.edu/cohar/Programs.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060408/00557b08/attachment.htm From ronaldoussoren at mac.com Sat Apr 8 21:26:53 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 8 Apr 2006 21:26:53 +0200 Subject: [Pythonmac-SIG] is anyone annoyed with MacPython2.4's IDLE's cursor info In-Reply-To: <65fadfc30604072139u198bd372m3a9cd41b3aa25243@mail.gmail.com> References: <65fadfc30604072139u198bd372m3a9cd41b3aa25243@mail.gmail.com> Message-ID: On 8-apr-2006, at 6:39, Nehemiah Dacres wrote: > I just don't like it being in the same corner as the resize handle > (mostly because it completely distorts the text underneath) so maybe > it should be moved to the left instead of the right bottom corner. has > anyone else had a problem with this? Is there any reason for this > design choice? will it be changed in the future? My guess is that this won't be changed unless someone creates a patch that fixes these issues. I've spent some time in reordering some of the menus for the universal build, and that was enough tkinter for me. > While im at it, will there ever be the same kind of syntax coloring in > "Python IDE" otherwise I'll just continue to use TextWrangler"? You're probably better of asking about syntax coloring on the IDLE-dev list (http://mail.python.org/mailman/listinfo/idle-dev) Ronald > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Sat Apr 8 21:31:17 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 8 Apr 2006 21:31:17 +0200 Subject: [Pythonmac-SIG] libpython2.4 for OS X? In-Reply-To: References: <1144448693.4436e6b5393f5@astrosun2.astro.cornell.edu> <1963344E-52A1-4A4A-8271-28DEBC4743C3@redivi.com> <69843291-8010-4AB5-94CB-01E074781188@redivi.com> Message-ID: <34020FF5-84C0-4449-BEDE-631D3045D340@mac.com> On 8-apr-2006, at 9:23, Andrew Trevorrow wrote: > At 9:22 PM -0700 7/4/06, Bob Ippolito wrote: > >> On Apr 7, 2006, at 9:16 PM, Andrew Trevorrow wrote: >> >>> At 3:39 PM -0700 7/4/06, Bob Ippolito wrote: >>> >>>> Really the right way to link to Python is to ask it how via >>>> distutils ... >>> >>> That's what I'm trying to do for my app, but on 10.4.5 I get an >>> incorrect >>> result using: >>> >>> python -c "import distutils.sysconfig; print >>> distutils.sysconfig.get_config_var('LINKFORSHARED')" >>> >>> The result is: >>> >>> -u __dummy -u _PyMac_Error -framework System Python.framework/ >>> Versions/2.3/Python -framework CoreServices -framework Foundation >>> >>> This causes the link stage to fail because it contains >>> "Python.framework/Versions/2.3/Python" rather than "-framework >>> Python". >>> >>> Anybody got a fix for this? >> >> You'd get the right result if you had a Python.framework symlink >> in your build dir. > > But I didn't have to do that on 10.3.9. Are you saying that the > info here > http://pythonmac.org/wiki/ > FAQ#head-9dfb0aba2a1a5c882ae0ba329fda3e16e6835e2f > is no longer correct for 10.4? > >> It doesn't use -framework Python because that's ambiguous without >> setting a bunch of environment variables. > > So what is the correct way to link an app that embeds Python on > 10.4.x? > I'll be happy to update the above wiki entry when I find out. All I'm > trying to do is find a safe way to link our app against the Apple- > supplied > Python framework on 10.3, 10.4, etc. I'd guess that you have to replace Python.framework/Versions/2.3/ Python by /System/Library/Frameworks/Python.frameworks/Versions/2.3/ Python. That's equivalent to "-framework Python" if you don't have other framework builds of python on your system. Ronald From kevino at theolliviers.com Sat Apr 8 21:37:10 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Sat, 8 Apr 2006 12:37:10 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr7.155458pdt."58633"@synergy1.parc.xerox.com> References: <06Apr7.155458pdt."58633"@synergy1.parc.xerox.com> Message-ID: Hi Bill, On Apr 7, 2006, at 3:54 PM, Bill Janssen wrote: > Hmmm... > > Kevin, I wonder if the checkerboard the blocks are standing on could > perhaps become more of a morph of the new yin/yang Python logo. I'd > like to see some kind of connection to the graphics being developed > for the main Python web site. I think trying to incorporate two icons into one would be a bit much. I'm really not that concerned because Python for Windows has been shipping with a green snake image for 5+ years, and almost every project I've ever seen uses images of a green or yellow snake to represent Python. Also, I think it's a valid point that the Python logo is really not OS X/XP-style (It's reminiscent of BE's style to me, actually), and I really think the best way for an icon to say "OS X" is to be in the OS X style. Thanks, Kevin >> http://kevino.theolliviers.com/0406_macpython.jpg > > Bill From kevino at theolliviers.com Sat Apr 8 21:58:00 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Sat, 8 Apr 2006 12:58:00 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Message-ID: <879AAB09-1203-4C4B-94AD-33F8C1DA7D03@theolliviers.com> Hi Russell, On Apr 7, 2006, at 4:08 PM, Russell E. Owen wrote: > In article <31522BBF-8981-4E4B-88AB-D4EB61B3C417 at theolliviers.com>, > Kevin Ollivier wrote: > >> Some things to note: >> >> - The final icon will be in the OS X photo-illustrative style (see >> his web site for examples). This 3D mockup is to review the design of >> the icon. >> >> - We plan in the final design to put a basic face onto the head - >> think of the lego character faces; two white eyes with black dots, a >> line for the mouth, probably two black dots for nostrils, etc. I >> think that will further stress the creativity aspect of it and make >> it a little more distinctive as an icon. >> >> Thoughts? Comments? > > I confess my first thought was that it looks a bit like a very > distorted > P, and that maybe making it look even more like a P (and skipping the > snake connection altogether) might be interesting. I'll mention this to Kenichi. I think we should keep the snake connection, but I think if we adjust the blocks a bit, the P shape could be a bit more obvious, particularly when the icon is at smaller sizes (e.g. the dock icon). IMHO that might look pretty slick. ;-) I can't make any promises, but I think at least we can at least try moving the snake's head to the right a bit so it aligns vertically with the lower part of his tail. > Anyway, it looks nice to me. > > Not looking too much like a snake is a win, in my opinion. Much as I > like ActiveState, their icon for ActiveState Python gives me the > creeps, > and I'm probably not the only one. Agreed. I personally think this icon is an excellent compromise. The snake connection is there, for those who want it, but unlike other icons it IMHO has a strong focus on Python being a building/ development tool, which I think lots of people in the past have had trouble trying to express as an icon. (I think the plethora of icons using simple snake imagery is precisely because of this. ;-) Thanks, Kevin > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From daniellord at mac.com Sat Apr 8 22:41:01 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 8 Apr 2006 13:41:01 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <879AAB09-1203-4C4B-94AD-33F8C1DA7D03@theolliviers.com> References: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> <879AAB09-1203-4C4B-94AD-33F8C1DA7D03@theolliviers.com> Message-ID: <4F2FF218-1075-4F07-87B4-EC08561AD9F9@mac.com> For what it is worth, implementation looks quite 'OS X-like' and I like it for that reason. It also maintains the snake connection in a more abstract fashion which is good--I wonder if Mr. Van Rossum ever endorsed the snake imagery anyway now that I have been schooled (thanks Bob O. ;-) that the name is derived from a British comedy group and is not reptilian in origin. Perhaps a liitle selective beveling and smoothing the blocks just a bit might increase their grouped resemblance to close enough to a snake while allowing the 'P' to not be occluded by the addition of eyes and other features. The little compression around the head perhaps might allow this while maintaining more abstraction. Might keep it cleaner IMHO. I hope I am communicating this adequately--I fear I am not. But in any event nice work! Daniel On Apr 8, 2006, at 12:58, Kevin Ollivier wrote: > Hi Russell, > > On Apr 7, 2006, at 4:08 PM, Russell E. Owen wrote: > >> In article <31522BBF-8981-4E4B-88AB-D4EB61B3C417 at theolliviers.com>, >> Kevin Ollivier wrote: >> >>> Some things to note: >>> >>> - The final icon will be in the OS X photo-illustrative style (see >>> his web site for examples). This 3D mockup is to review the >>> design of >>> the icon. >>> >>> - We plan in the final design to put a basic face onto the head - >>> think of the lego character faces; two white eyes with black dots, a >>> line for the mouth, probably two black dots for nostrils, etc. I >>> think that will further stress the creativity aspect of it and make >>> it a little more distinctive as an icon. >>> >>> Thoughts? Comments? >> >> I confess my first thought was that it looks a bit like a very >> distorted >> P, and that maybe making it look even more like a P (and skipping the >> snake connection altogether) might be interesting. > > I'll mention this to Kenichi. I think we should keep the snake > connection, but I think if we adjust the blocks a bit, the P shape > could be a bit more obvious, particularly when the icon is at smaller > sizes (e.g. the dock icon). IMHO that might look pretty slick. ;-) I > can't make any promises, but I think at least we can at least try > moving the snake's head to the right a bit so it aligns vertically > with the lower part of his tail. > >> Anyway, it looks nice to me. >> >> Not looking too much like a snake is a win, in my opinion. Much as I >> like ActiveState, their icon for ActiveState Python gives me the >> creeps, >> and I'm probably not the only one. > > Agreed. I personally think this icon is an excellent compromise. The > snake connection is there, for those who want it, but unlike other > icons it IMHO has a strong focus on Python being a building/ > development tool, which I think lots of people in the past have had > trouble trying to express as an icon. (I think the plethora of icons > using simple snake imagery is precisely because of this. ;-) > > Thanks, > > Kevin > >> -- Russell >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From janssen at parc.com Sat Apr 8 23:37:39 2006 From: janssen at parc.com (Bill Janssen) Date: Sat, 8 Apr 2006 14:37:39 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Sat, 08 Apr 2006 12:37:10 PDT." Message-ID: <06Apr8.143748pdt."58633"@synergy1.parc.xerox.com> Hi, Kevin. > Hi Bill, > > On Apr 7, 2006, at 3:54 PM, Bill Janssen wrote: > > > Hmmm... > > > > Kevin, I wonder if the checkerboard the blocks are standing on could > > perhaps become more of a morph of the new yin/yang Python logo. I'd > > like to see some kind of connection to the graphics being developed > > for the main Python web site. > > I think trying to incorporate two icons into one would be a bit much. Agreed. I wasn't suggesting that. I was suggesting that the new *logo* be incorporated into the icon, in some fashion, not any of the new *icons* being developed around that logo for the website. I still think it's a good idea. It would be nice to have some point of graphic unification for the community. Specifically, I was thinking of an incorporation of this graphic element: http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/logo/python-logo-master-flat-symbolonly.png Andrew Clover's icons have the virtue of doing this: http://www.doxdesk.com/img/software/py/icons.png though I think the logo in them is somewhat too front and center, and kind of obscures the main purpose of the icon. By the way, a recent posting on python-dev (http://mail.python.org/pipermail/python-dev/2006-April/063517.html) intimates that those icons are coming to the various standard releases. A spec for usage of the new logo is at http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/logo/python-logo-master-flat-usage.png We can get the vector versions of the logo if you need them. > Also, I think it's a valid point that the Python > logo is really not OS X/XP-style (It's reminiscent of BE's style to > me, actually), and I really think the best way for an icon to say "OS > X" is to be in the OS X style. Right, and I think the thing to do would be to "OS X"-ize the flat logo and incorporate it into the design. For instance, the flat checkerboard the block-snake is standing on might become the flat logo instead. Bill From samrobertsmith at gmail.com Sun Apr 9 01:59:07 2006 From: samrobertsmith at gmail.com (linda.s) Date: Sat, 8 Apr 2006 16:59:07 -0700 Subject: [Pythonmac-SIG] bin and version Message-ID: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> Hi, I installed quite a few python versions in my computer and I want to know where they are located. Should i check them in the bin folder? If so, why I can not find the bin folder in my home directory? Thanks! linda From charles.hartman at conncoll.edu Sun Apr 9 02:25:20 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 8 Apr 2006 20:25:20 -0400 Subject: [Pythonmac-SIG] bin and version In-Reply-To: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> Message-ID: I can answer your second question: You're being confused by the Mac folder system vs the underlying Unix filesystem. All folders are (really, underlyingly) directories, but not all directories show up on the desktop as folders. Your home directory is, in Unix terms, someplace like /Users/yourUserName whereas the bin directories, which do not show up on the OS X desktop as folders at all, are /bin and /usr/bin. The "/usr" here is not at all the same thing as the OS X "/Users" directory. So in practice, you can't easily look for, or at, or into, the bin directories from within OS X. You have to go to the Terminal to do that. If you fire up the Terminal application and type cd / and then ls you'll see a list of files and directories at the top or root level of the Unix filesystem that underlies the Mac folder system. It will include "Applications" and "Users" and "Library" and other familiar stuff from folder-land, but also "usr" and "bin" other other unfamiliar, Unix-land stuff. Which doesn't answer your question about what (Unix) commands to issue (in the Terminal) to find your Pythons. I'll leave that to somebody who understands Unix-land better than I do . . . On Apr 8, 2006, at 7:59 PM, linda.s wrote: > Hi, > I installed quite a few python versions in my computer and I want to > know where they are located. > Should i check them in the bin folder? > If so, why I can not find the bin folder in my home directory? > Thanks! > linda > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kevino at theolliviers.com Sun Apr 9 03:25:10 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Sat, 8 Apr 2006 18:25:10 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr8.143748pdt."58633"@synergy1.parc.xerox.com> References: <06Apr8.143748pdt."58633"@synergy1.parc.xerox.com> Message-ID: <9439D401-5B52-48DD-A514-02BFAEB6C516@theolliviers.com> Hi Bill, (First, note to Kenichi - sorry to bother you with this. I had planned to summarize some of these things for you later on.) On Apr 8, 2006, at 2:37 PM, Bill Janssen wrote: > Hi, Kevin. > >> Hi Bill, >> >> On Apr 7, 2006, at 3:54 PM, Bill Janssen wrote: >> >>> Hmmm... >>> >>> Kevin, I wonder if the checkerboard the blocks are standing on could >>> perhaps become more of a morph of the new yin/yang Python logo. I'd >>> like to see some kind of connection to the graphics being developed >>> for the main Python web site. >> >> I think trying to incorporate two icons into one would be a bit much. > > Agreed. I wasn't suggesting that. I was suggesting that the new > *logo* be incorporated into the icon, in some fashion, not any of the > new *icons* being developed around that logo for the website. I still > think it's a good idea. I understood what you were asking for. Okay, let me be more detailed. If we do what you propose, what we would have is two 'elements', let's call them, in the final icon which serve the same purpose: identifying Python. It's redundant, if not confusing, and since the icons use different color schemes and designs, it will hurt the icon visibility and clarity as it gets smaller. We don't need a mockup created to know this. Just visualize it in your head, or make your own mockup by editing the image if you really feel you want to see what it would look like. > It would be nice to have some point of > graphic unification for the community. I appreciate what you want to do, but IMHO the correct way to have gone about this would have been to design the new Python logo from the start to be appropriate as an OS X icon. For whatever reason, though, that didn't happen. So now we have to either figure out how to transform their design in order to make their "image" of Python work for our situation, or come up with our own design which we feel is a suitable fit for the project on OS X. My interest lies firmly in the latter. Projects like PyGame and ModApache have their own visual identity for Python, and I don't see why the MacPython community, which has it's own web site, focus, and interest group, should be any different, particularly as it runs on an OS known for its unique and striking visual identity. Thanks, Kevin From vivacarlie at gmail.com Sun Apr 9 06:17:24 2006 From: vivacarlie at gmail.com (Nehemiah I. Dacres) Date: Sat, 8 Apr 2006 23:17:24 -0500 Subject: [Pythonmac-SIG] is anyone annoyed with MacPython2.4's IDLE's cursor info In-Reply-To: References: <65fadfc30604072139u198bd372m3a9cd41b3aa25243@mail.gmail.com> Message-ID: > >> While im at it, will there ever be the same kind of syntax >> coloring in >> "Python IDE" otherwise I'll just continue to use TextWrangler"? > > You're probably better of asking about syntax coloring on the IDLE-dev > list (http://mail.python.org/mailman/listinfo/idle-dev) Does Python IDE have a Dev Site or MAN page? cause i have no problem with IDLE's coloring, it HAS coloring, "Python IDE" DOESN'T thats why I asked. From bob at redivi.com Sun Apr 9 08:28:42 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 8 Apr 2006 23:28:42 -0700 Subject: [Pythonmac-SIG] is anyone annoyed with MacPython2.4's IDLE's cursor info In-Reply-To: References: <65fadfc30604072139u198bd372m3a9cd41b3aa25243@mail.gmail.com> Message-ID: <2CB451BF-4A8C-437D-A895-7431500A48BC@redivi.com> On Apr 8, 2006, at 9:17 PM, Nehemiah I. Dacres wrote: >> >>> While im at it, will there ever be the same kind of syntax >>> coloring in >>> "Python IDE" otherwise I'll just continue to use TextWrangler"? >> >> You're probably better of asking about syntax coloring on the IDLE- >> dev >> list (http://mail.python.org/mailman/listinfo/idle-dev) > > > Does Python IDE have a Dev Site or MAN page? cause i have no problem > with IDLE's coloring, it HAS coloring, "Python IDE" DOESN'T thats why > I asked. The old Python IDE is officially dead and has been for years. As of the Universal build, it no longer even ships. -bob From hengist.podd at virgin.net Sun Apr 9 13:44:53 2006 From: hengist.podd at virgin.net (has) Date: Sun, 9 Apr 2006 12:44:53 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> References: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Message-ID: Kevin Ollivier wrote: >Here is a 3D mock- up by Kenichi Yoshida (http://www.kenichiyoshida.jp/), who I've been working with on the icon. > >http://kevino.theolliviers.com/0406_macpython.jpg > >Thoughts? Comments? It's crap. Kenichi's done some really nice icons. This is not one of them. Sorry. has -- http://freespace.virgin.net/hamish.sanderson/ From hraban at fiee.net Sun Apr 9 14:52:04 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Sun, 9 Apr 2006 14:52:04 +0200 Subject: [Pythonmac-SIG] bin and version In-Reply-To: References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> Message-ID: > On Apr 8, 2006, at 7:59 PM, linda.s wrote: > >> Hi, >> I installed quite a few python versions in my computer and I want to >> know where they are located. >> Should i check them in the bin folder? >> If so, why I can not find the bin folder in my home directory? Am 2006-04-09 um 02:25 schrieb Charles Hartman: > Which doesn't answer your question about what (Unix) commands to > issue (in the Terminal) to find your Pythons. I'll leave that to > somebody who understands Unix-land better than I do . . . Try 'whereis python'. (I don't really know if it can list several different installations, I get only one.) Generally a great help is the 'locate' utility, but it first needs a database created: sudo /usr/libexec/locate.updatedb (sudo needs your password and locate.updatedb a long while...) and then locate python | grep bin/python (that lists 22 versions on my machine; some are only symlinks, others are part of applications or on my second partition with an old installation...) 'locate' is '/usr/bin/locate'; you should add '/usr/bin' to your PATH if it's not part of it already. BTW, instead of pure 'ls' you could use 'ls -FGAlh' to get more detailed information; I mapped that onto 'll' with: alias ll='ls -FGAlh' If you want to know which of your Pythons is used if you type 'python', try: which python Greetlings from Lake Constance! Hraban --- http://www.fiee.net http://www.cacert.org (I'm an assurer) From daniellord at mac.com Sun Apr 9 16:46:39 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 9 Apr 2006 07:46:39 -0700 Subject: [Pythonmac-SIG] bin and version In-Reply-To: References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> Message-ID: On Apr 8, 2006, at 7:59 PM, linda.s wrote: > Hi, > I installed quite a few python versions in my computer and I want to > know where they are located. > Should i check them in the bin folder? > If so, why I can not find the bin folder in my home directory? Someone answered the portion regarding the commands. As for the location of the 'bin' directory, OS X hides several UNIX directories in the Finder as part of their simplification facade. You can always access them from the shell: [daniello at mercury.local]$ cd /bin [daniello at mercury.local]$ ls -l total 16920 -rwxr-xr-x 1 root wheel 1065112 Jan 13 11:36 bash -r-xr-xr-x 1 root wheel 34848 Jan 13 11:28 cat -r-xr-xr-x 1 root wheel 52476 Jan 13 14:00 chmod -r-xr-xr-x 1 root wheel 43732 Jan 13 14:00 cp *** -rwxr-xr-x 2 root wheel 929856 Jan 13 10:02 zsh -rwxr-xr-x 2 root wheel 929856 Jan 13 10:02 zsh-4.2.3 Daniel From berkowit at silcom.com Sun Apr 9 17:20:30 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Sun, 09 Apr 2006 08:20:30 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <31522BBF-8981-4E4B-88AB-D4EB61B3C417@theolliviers.com> Message-ID: On 4/7/06 2:55 PM, "Kevin Ollivier" wrote: > Here is a 3D mock- > up by Kenichi Yoshida (http://www.kenichiyoshida.jp/), who I've been > working with on the icon. > > http://kevino.theolliviers.com/0406_macpython.jpg Personally, I find it far, far too fussy and busy. All those little blocks are bewildering, and awful. It's the opposite of what a good icon she be. Sorry. I really think you'd be better off using the new Python icon as is, or slightly "mac-ified". I'm not really "one of you" yet, but that's how it strikes this outsider. -- Paul Berkowitz From saggau at gmail.com Sun Apr 9 22:17:20 2006 From: saggau at gmail.com (Saggau) Date: Sun, 9 Apr 2006 16:17:20 -0400 Subject: [Pythonmac-SIG] NSZombies eating my brain Message-ID: Hi again folks. System version = 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] (Built-in) PyObjC from SVN as of about a week ago. So I've done this: from PyObjCTools import Signals Signals.dumpStackOnFatalSignal() from PyObjCTools import Debugging Debugging.installVerboseExceptionHandler() NSZombie is enabled (Thanks Bob I!) I've an NSArrayController to which I add a pretty extensive python object that subclasses NSObject that also has some "straight - up" python objects as attributes. Any more of a description would probably require someone to peer into my SVN repository, which I'm happy to share whith those who want to go the extra mile. (!) I've tried running in gdb with a breakpoint on -[_NSZombie retain], but I don't really know what I'm looking for. I'm looking at a lot of hex memory addresses with very little human-readable stuff in there. Am I missing some debugging symbols in python/pyobjc? I tried setting a breakpoint at (+[OC_PythonArray newWithPythonObject:]) to see perhaps what proxy objects are being instantiated, but I'm clearly in over my depth. Much googling, rtfm, stfw, etc. has gotten me to some interesting articles on malloc scribble and the like, but there is very little (that I can find) that leads this newbie in the right direction re: NSZombie eating my pybojc app! Stack traces below. Thanks to all who have helped thus far. Cheers, Jonathan Saggau Here is the bt when gdb hits NSZombie retain. Anybody have a clue-by-four for me? #0 0x92a43c80 in -[_NSZombie retain] () #1 0x9396c690 in -[_NSModelObservingTracker setIndexReferenceModelObjectArray:clearAllModelObjectObserving:] () #2 0x93980c54 in -[NSSelectionBinder _adjustObject:mode:observedController:observedKeyPath:context:editableState:adjustState:] () #3 0x939499a8 in -[NSValueBinder _observeValueForKeyPath:ofObject:context:] () #4 0x939808f4 in -[NSSelectionBinder observeValueForKeyPath:ofObject:change:context:] () #5 0x929fcd08 in -[NSObject(NSKeyValueObservingPrivate) _notifyObserversForKeyPath:change:] () #6 0x93972608 in -[NSController _notifyObserversForKeyPath:change:] () #7 0x9397246c in -[NSArrayController didChangeValuesForArrangedKeys:objectKeys:indexKeys:] () #8 0x93bf6c0c in -[NSArrayController _insertObject:atArrangedObjectIndex:objectHandler:] () #9 0x005072e8 in _ffi_call_DARWIN () at libffi-src/src/powerpc/darwin.S:119 #10 0x00506f00 in ffi_call (cif=0x1147470, fn=0x800000, rvalue=0x1147470, avalue=0x0) at libffi-src/src/powerpc/ffi_darwin.c:396 #11 0x00513da0 in PyObjCFFI_Caller (aMeth=0x4406b0, self=0x438170, args=0x103b2f0) at Modules/objc/libffi_support.m:1293 #12 0x00526eb0 in objcsel_call (self=0x4406b0, args=0x103b2f0) at Modules/objc/selector.m:516 #13 0x986e88e0 in PyObject_Call () #14 0x9874835c in PyEval_GetFuncDesc () #15 0x98747d4c in PyEval_GetFuncDesc () #16 0x98745414 in PyEval_EvalCode () #17 0x987465e4 in PyEval_EvalCodeEx () #18 0x986fd530 in PyFunction_SetClosure () #19 0x986e88e0 in PyObject_Call () #20 0x00527f88 in pysel_call (self=0x40dbe0, args=0x0, kwargs=0x410cf0) at Modules/objc/selector.m:941 #21 0x986e88e0 in PyObject_Call () #22 0x00510958 in method_stub (cif=0x1147470, resp=0xbfffc510, args=0xbfffc440, _userdata=0x0) at Modules/objc/libffi_support.m:479 #23 0x00507104 in ffi_closure_helper_DARWIN (closure=0x1147470, rvalue=0xbfffc510, pgr=0x1147470, pfr=0x0) at libffi-src/src/powerpc/ffi_darwin.c:699 #24 0x005073b4 in _ffi_closure_ASM () at darwin_closure.S:92 #25 0x937c1270 in -[NSApplication sendAction:to:from:] () #26 0x937c11a4 in -[NSControl sendAction:to:] () #27 0x937c1084 in -[NSCell _sendActionFrom:] () #28 0x937db09c in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #29 0x937dac84 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] () #30 0x937da6a8 in -[NSControl mouseDown:] () #31 0x9377beb0 in -[NSWindow sendEvent:] () #32 0x93724ef4 in -[NSApplication sendEvent:] () #33 0x9371c330 in -[NSApplication run] () #34 0x9380ce68 in NSApplicationMain () #35 0x010496f4 in objc_NSApplicationMain (self=0x1147470, args=0x90ab1aa0, kwds=0x1147470) at Modules/AppKit/_AppKit.m:129 #36 0x98747c5c in PyEval_GetFuncDesc () #37 0x98745414 in PyEval_EvalCode () #38 0x987465e4 in PyEval_EvalCodeEx () #39 0x98747f90 in PyEval_GetFuncDesc () #40 0x98747d34 in PyEval_GetFuncDesc () #41 0x98745414 in PyEval_EvalCode () #42 0x987465e4 in PyEval_EvalCodeEx () #43 0x98742eb8 in PyEval_EvalCode () #44 0x9876708c in PyRun_FileExFlags () #45 0x9873c210 in _PyUnicodeUCS2_IsAlpha () #46 0x98747c5c in PyEval_GetFuncDesc () #47 0x98745414 in PyEval_EvalCode () #48 0x987465e4 in PyEval_EvalCodeEx () #49 0x98747f90 in PyEval_GetFuncDesc () #50 0x98747d34 in PyEval_GetFuncDesc () #51 0x98745414 in PyEval_EvalCode () #52 0x987465e4 in PyEval_EvalCodeEx () #53 0x98742eb8 in PyEval_EvalCode () #54 0x9876708c in PyRun_FileExFlags () #55 0x987660b0 in PyRun_SimpleFileExFlags () #56 0x00003db0 in ?? () #57 0x00003e50 in ?? () #58 0x00002414 in ?? () #59 0x8fe01048 in __dyld__dyld_start () And here's the trace output in the console when the app just pukes running outside of gdb Stack trace (most recent call last): 0x00002414 (in Trigger) 0x00003e50 (in Trigger) 0x00003db0 (in Trigger) _PyRun_SimpleFileExFlags (in Python) _PyRun_FileExFlags (in Python) _PyEval_EvalCode (in Python) _PyEval_EvalCodeEx (in Python) _PyEval_EvalCode (in Python) _PyEval_GetFuncDesc (in Python) _PyEval_GetFuncDesc (in Python) _PyEval_EvalCodeEx (in Python) _PyEval_EvalCode (in Python) _PyEval_GetFuncDesc (in Python) __PyUnicodeUCS2_IsAlpha (in Python) _PyRun_FileExFlags (in Python) _PyEval_EvalCode (in Python) _PyEval_EvalCodeEx (in Python) _PyEval_EvalCode (in Python) _PyEval_GetFuncDesc (in Python) _PyEval_GetFuncDesc (in Python) _PyEval_EvalCodeEx (in Python) _PyEval_EvalCode (in Python) _PyEval_GetFuncDesc (in Python) _objc_NSApplicationMain (in _AppKit.so) (_AppKit.m:129) _NSApplicationMain (in AppKit) -[NSApplication run] (in AppKit) -[NSApplication sendEvent:] (in AppKit) -[NSWindow sendEvent:] (in AppKit) -[NSControl mouseDown:] (in AppKit) -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] (in AppKit) -[NSCell trackMouse:inRect:ofView:untilMouseUp:] (in AppKit) -[NSCell _sendActionFrom:] (in AppKit) -[NSControl sendAction:to:] (in AppKit) -[NSApplication sendAction:to:from:] (in AppKit) _ffi_closure_ASM (in _objc.so) (darwin_closure.S:95) _ffi_closure_helper_DARWIN (in _objc.so) (ffi_darwin.c:703) _method_stub (in _objc.so) (libffi_support.m:479) _PyObject_Call (in Python) _pysel_call (in _objc.so) (selector.m:941) _PyObject_Call (in Python) _PyFunction_SetClosure (in Python) _PyEval_EvalCodeEx (in Python) _PyEval_EvalCode (in Python) _PyEval_GetFuncDesc (in Python) _PyEval_GetFuncDesc (in Python) _PyObject_Call (in Python) _objcsel_call (in _objc.so) (selector.m:517) _PyObjCFFI_Caller (in _objc.so) (libffi_support.m:1300) _ffi_call (in _objc.so) (ffi_darwin.c:404) _ffi_call_DARWIN (in _objc.so) (darwin.S:121) -[NSArrayController _insertObject:atArrangedObjectIndex:objectHandler:] (in AppKit) -[NSArrayController didChangeValuesForArrangedKeys:objectKeys:indexKeys:] (in AppKit) -[NSController _notifyObserversForKeyPath:change:] (in AppKit) -[NSObject(NSKeyValueObservingPrivate) _notifyObserversForKeyPath:change:] (in Foundation) -[NSSelectionBinder observeValueForKeyPath:ofObject:change:context:] (in AppKit) -[NSValueBinder _observeValueForKeyPath:ofObject:context:] (in AppKit) -[NSSelectionBinder _adjustObject:mode:observedController:observedKeyPath:context:editableState:adjustState:] (in AppKit) -[_NSModelObservingTracker setIndexReferenceModelObjectArray:clearAllModelObjectObserving:] (in AppKit) -[_NSZombie retain] (in Foundation) +[NSException raise:format:] (in Foundation) _NSExceptionHandlerExceptionRaiser (in ExceptionHandling) 2006-04-09 16:13:52.454 Trigger[762] NSGenericException - *** Selector 'retain' sent to dealloced instance 0x1147be0 of class OC_PythonArray. Break at '-[_NSZombie retain]' to debug. -- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality. - Harry Partch There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060409/479e8a56/attachment.htm From bob at redivi.com Sun Apr 9 23:06:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 9 Apr 2006 14:06:22 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: On Apr 9, 2006, at 8:20 AM, Paul Berkowitz wrote: > On 4/7/06 2:55 PM, "Kevin Ollivier" wrote: > >> Here is a 3D mock- >> up by Kenichi Yoshida (http://www.kenichiyoshida.jp/), who I've been >> working with on the icon. >> >> http://kevino.theolliviers.com/0406_macpython.jpg > > Personally, I find it far, far too fussy and busy. All those little > blocks > are bewildering, and awful. It's the opposite of what a good icon > she be. > Sorry. I really think you'd be better off using the new Python icon > as is, > or slightly "mac-ified". I'm not really "one of you" yet, but > that's how it > strikes this outsider. I'm also -1. I just don't see it making a good icon at any size. While not ideal, we should probably just move forward with an icon set based on the new python.org logo. It's better than what we have, and it doesn't "realistically" depict a snake. I'm still open to new ideas and mockups, but it just doesn't seem pragmatic to wait it out forever. -bob From janssen at parc.com Sun Apr 9 23:27:23 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 9 Apr 2006 14:27:23 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Sat, 08 Apr 2006 18:25:10 PDT." <9439D401-5B52-48DD-A514-02BFAEB6C516@theolliviers.com> Message-ID: <06Apr9.142724pdt."58633"@synergy1.parc.xerox.com> Kevin, > If we do what you propose, what we would have is two 'elements', > let's call them, in the final icon which serve the same purpose: > identifying Python. It's redundant, if not confusing, and since the > icons use different color schemes and designs, it will hurt the icon > visibility and clarity as it gets smaller. Yes, I see what you mean. I think the colors of the new icon you're designing should be adjusted to be more in line with the new Python logo. That would solve the color problem. And rounding off a few edges on the icon would help it meld with the logo. > > It would be nice to have some point of > > graphic unification for the community. > > I appreciate what you want to do, but IMHO the correct way to have > gone about this would have been to design the new Python logo from > the start to be appropriate as an OS X icon. For whatever reason, > though, that didn't happen. Again, logos and icons are two different things. Incorporating the logo as an element of the "OS X"ish icon would be the way to go. > come > up with our own design which we feel is a suitable fit for the > project on OS X. My interest lies firmly in the latter. I think that's fine. I'm just saying that that design should borrow from and incorporate in some way the established graphic badging that the Python community at large is finally getting around to. > Projects like > PyGame and ModApache have their own visual identity for Python Because they pre-date the new logo, no doubt. After all, the old MacPython had that in-joke 16-ton weight. I think it's appropriate for both PyGame and ModApache to re-design their identities, too. Your mockup, as it is, just doesn't say "Python" (to me). > it runs on an OS known for its unique and striking visual identity. Hey, all the OS's are going to be that way Real Soon Now :-). I like the Mac too, but it's just Python. Bill From janssen at parc.com Sun Apr 9 23:29:38 2006 From: janssen at parc.com (Bill Janssen) Date: Sun, 9 Apr 2006 14:29:38 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Sun, 09 Apr 2006 14:06:22 PDT." Message-ID: <06Apr9.142939pdt."58633"@synergy1.parc.xerox.com> Bob Ippolito writes: > While not ideal, we should probably just move forward with an icon > set based on the new python.org logo. It's better than what we have, > and it doesn't "realistically" depict a snake. I'm still open to new > ideas and mockups, but it just doesn't seem pragmatic to wait it out > forever. Well, we'll see if Andrew Clover's icons show up for real. That would be an alternative set to think about. Bill From daniellord at mac.com Mon Apr 10 01:42:58 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 9 Apr 2006 16:42:58 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: I was hoping some encouragement might result in eventual simplification of the logo. I guess I'll repeat myself from a while back: why don't we just take blue and yellow official logo and 'aqua-fy' it a bit. Look at what Apple did for the Windows logo for BootCamp. Simple, elegant twist on the Windows logo that actually looks better than the original. that would keep the Python brand but make it 'Mac' as well. I took two minute to rough something out--whcih really sucks but I hope shows the idea. It needs the yellow color and the blue to be loser, but you get the idea (I hope). I am flying blind with Photoshop having never learned it--I hope someone how actually has talent will take it from here. -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 6866 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060409/36f3be93/attachment.tiff From treaves at silverfieldstech.com Mon Apr 10 01:49:33 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Sun, 9 Apr 2006 19:49:33 -0400 Subject: [Pythonmac-SIG] Install location Message-ID: Why is it the installer at http://www.python.org/download/releases/ 2.4.3/ install into /Applications ? Why does it not install as a framework? ActiveState Python does, although they still user /usr/ local/bin for the links. From hengist.podd at virgin.net Mon Apr 10 02:13:10 2006 From: hengist.podd at virgin.net (has) Date: Mon, 10 Apr 2006 01:13:10 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: Bill Janssen wrote: > > I appreciate what you want to do, but IMHO the correct way to have > > gone about this would have been to design the new Python logo from > > the start to be appropriate as an OS X icon. > >Again, logos and icons are two different things. Incorporating the >logo as an element of the "OS X"ish icon would be the way to go. Indeed. The Python logo is just a badge to be applied to the larger graphic(s) as necessary, in this case a family of four(?) OS X icons representing an interactive Python editor (IDLE), .py document file, .pyc/.pyo document file, and drag-n-drop script runner. The visual language for representing text-based editors and document files on OS X is extremely well established (e.g. compare Script Editor.app and .scpt documents), and there's probably a fair bit of precedence for the script runner too. So there's no reason that all of this shouldn't be regarded as a wholly solved problem. Now, some folk are bound to moan that the resulting icons look 'boring' or 'unoriginal', but quite honestly this matters not one whit. (Similarly, to those who don't personally like the new Python icon: tough, but it's a done deal now so suck it up and move on.) The only thing that matters is that these new icons are finished to a high standard (replete with drop shadows and subtle shading and highlights to give it some life, no crappy blocky aliasing, well-done alpha masks, and available in several sizes) and are instantly identifiable to users when displayed on screen. Remember, Python is a tool - a means to an end - not an end in itself. As long as they look professionally done, the desktop icons aren't what sells it (or not) to users. Folk are so busy over-analysing the problem to create the Gr8st Ic0nZ Evah!!!!1!! that we'll still be having this same argument come Python 2.6, and meantime 2.5 will be shipping with those dated, painfully amateurish and badly re-rendered OS 8 icons. All it needs is somebody with some decent Photoshop compositing skills (and maybe a nice 3D drawing of a technical pencil) to assemble the finished elements. I'd have done it myself by now just to settle it, only I don't have access to a decent copy of Photoshop any more and am a bit rusty after a few years out of the game, but I'm fair tempted to grit teeth and beat it out in the GIMP anyway. I'd be happy that someone with more practice at icon work did it though; that Kenichi Yoshida chap, for example, looks like he could do a very nice job just given the raw resources and left to get on with it. has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Apr 10 02:32:04 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 9 Apr 2006 17:32:04 -0700 Subject: [Pythonmac-SIG] Install location In-Reply-To: References: Message-ID: On Apr 9, 2006, at 4:49 PM, Timothy Reaves wrote: > Why is it the installer at http://www.python.org/download/releases/ > 2.4.3/ install into /Applications ? Why does it not install as a > framework? ActiveState Python does, although they still user /usr/ > local/bin for the links. It puts IDLE, BuildApplet, and the other applications that ship with MacPython in Applications. This is not unusual. It DOES install as a framework. It DOES by default put symlinks in /usr/local/bin. The slight differences in the way ActivePython behaves are deviations on their part. -bob From treaves at silverfieldstech.com Mon Apr 10 02:39:52 2006 From: treaves at silverfieldstech.com (Timothy Reaves) Date: Sun, 9 Apr 2006 20:39:52 -0400 Subject: [Pythonmac-SIG] Install location In-Reply-To: References: Message-ID: <10980877-524F-4E5E-A9B0-5C317605316F@silverfieldstech.com> On Apr 9, 2006, at 8:32 PM, Bob Ippolito wrote: > > On Apr 9, 2006, at 4:49 PM, Timothy Reaves wrote: > >> Why is it the installer at http://www.python.org/download/releases/ >> 2.4.3/ install into /Applications ? Why does it not install as a >> framework? ActiveState Python does, although they still user /usr/ >> local/bin for the links. > > It puts IDLE, BuildApplet, and the other applications that ship > with MacPython in Applications. This is not unusual. > > It DOES install as a framework. > > It DOES by default put symlinks in /usr/local/bin. > > The slight differences in the way ActivePython behaves are > deviations on their part. > > -bob > O.K. I must have misread the ReadMe.txt. From andrew at trevorrow.com Mon Apr 10 03:03:45 2006 From: andrew at trevorrow.com (Andrew Trevorrow) Date: Mon, 10 Apr 2006 11:03:45 +1000 Subject: [Pythonmac-SIG] prevent Tkinter changing app's menu? Message-ID: Our app uses embedded Python to allow users to run arbitrary scripts. Scripts that import Tkinter run fine on Windows, but on Mac OS X there is a serious problem. After a script does "root = Tk()" our app's menus are permanently changed in the following way: - The top item in the application menu changes to "About Tcl & Tk...". - The Quit item is disabled. - The File and Edit menus are completely replaced. - All further menus (except Help) are removed. Is there a way to prevent Tkinter clobbering our app's menus? Or perhaps a way to restore them after the root.mainloop() call? I've read Fredrik Lundh's excellent tutorial on Tkinter and done a lot of googling but haven't been able to find a solution. I can probably add some Mac-specific code to detect a menu change after a script ends and then rebuild our menus, but I'm hoping there's a simpler Tkinter (or Tcl?) solution. Andrew From saggau at gmail.com Mon Apr 10 03:09:51 2006 From: saggau at gmail.com (Saggau) Date: Sun, 9 Apr 2006 21:09:51 -0400 Subject: [Pythonmac-SIG] NSZombies eating my brain In-Reply-To: References: Message-ID: - initWithPythonObject:(PyObject*)v; { self = [super init]; if (!self) return nil; Py_INCREF(v); Py_XDECREF(value); value = v; return self; } In gdb the variable v is showing up as 0x0. when I break on [OC_PythonArray initWithPythonObject:] (There was a typo in my original post, I think) ;) Could this be the problem? On 4/9/06, Saggau wrote: > > Hi again folks. > > System version = 2.3.5 (#1, Mar 20 2005, 20:38:20) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] > (Built-in) > > PyObjC from SVN as of about a week ago. > > So I've done this: > from PyObjCTools import Signals > Signals.dumpStackOnFatalSignal() > from PyObjCTools import Debugging > Debugging.installVerboseExceptionHandler() > > NSZombie is enabled (Thanks Bob I!) > > I've an NSArrayController to which I add a pretty extensive python object > that subclasses NSObject that also has some "straight - up" python objects > as attributes. Any more of a description would probably require someone to > peer into my SVN repository, which I'm happy to share whith those who want > to go the extra mile. (!) > > I've tried running in gdb with a breakpoint on -[_NSZombie retain], but I > don't really know what I'm looking for. I'm looking at a lot of hex memory > addresses with very little human-readable stuff in there. Am I missing some > debugging symbols in python/pyobjc? > > I tried setting a breakpoint at (+[OC_PythonArray newWithPythonObject:]) > to see perhaps what proxy objects are being instantiated, but I'm clearly in > over my depth. Much googling, rtfm, stfw, etc. has gotten me to some > interesting articles on malloc scribble and the like, but there is very > little (that I can find) that leads this newbie in the right direction re: > NSZombie eating my pybojc app! > > Stack traces below. Thanks to all who have helped thus far. > > Cheers, > Jonathan Saggau > > Here is the bt when gdb hits NSZombie retain. Anybody have a clue-by-four > for me? > #0 0x92a43c80 in -[_NSZombie retain] () > #1 0x9396c690 in -[_NSModelObservingTracker > setIndexReferenceModelObjectArray:clearAllModelObjectObserving:] () > #2 0x93980c54 in -[NSSelectionBinder > _adjustObject:mode:observedController:observedKeyPath:context:editableState:adjustState:] > () > #3 0x939499a8 in -[NSValueBinder > _observeValueForKeyPath:ofObject:context:] () > #4 0x939808f4 in -[NSSelectionBinder > observeValueForKeyPath:ofObject:change:context:] () > #5 0x929fcd08 in -[NSObject(NSKeyValueObservingPrivate) > _notifyObserversForKeyPath:change:] () > #6 0x93972608 in -[NSController _notifyObserversForKeyPath:change:] () > #7 0x9397246c in -[NSArrayController > didChangeValuesForArrangedKeys:objectKeys:indexKeys:] () > #8 0x93bf6c0c in -[NSArrayController > _insertObject:atArrangedObjectIndex:objectHandler:] () > #9 0x005072e8 in _ffi_call_DARWIN () at > libffi-src/src/powerpc/darwin.S:119 > #10 0x00506f00 in ffi_call (cif=0x1147470, fn=0x800000, rvalue=0x1147470, > avalue=0x0) at libffi-src/src/powerpc/ffi_darwin.c:396 > #11 0x00513da0 in PyObjCFFI_Caller (aMeth=0x4406b0, self=0x438170, > args=0x103b2f0) at Modules/objc/libffi_support.m:1293 > #12 0x00526eb0 in objcsel_call (self=0x4406b0, args=0x103b2f0) at > Modules/objc/selector.m:516 > #13 0x986e88e0 in PyObject_Call () > #14 0x9874835c in PyEval_GetFuncDesc () > #15 0x98747d4c in PyEval_GetFuncDesc () > #16 0x98745414 in PyEval_EvalCode () > #17 0x987465e4 in PyEval_EvalCodeEx () > #18 0x986fd530 in PyFunction_SetClosure () > #19 0x986e88e0 in PyObject_Call () > #20 0x00527f88 in pysel_call (self=0x40dbe0, args=0x0, kwargs=0x410cf0) at > Modules/objc/selector.m:941 > #21 0x986e88e0 in PyObject_Call () > #22 0x00510958 in method_stub (cif=0x1147470, resp=0xbfffc510, > args=0xbfffc440, _userdata=0x0) at Modules/objc/libffi_support.m:479 > #23 0x00507104 in ffi_closure_helper_DARWIN (closure=0x1147470, > rvalue=0xbfffc510, pgr=0x1147470, pfr=0x0) at > libffi-src/src/powerpc/ffi_darwin.c:699 > #24 0x005073b4 in _ffi_closure_ASM () at darwin_closure.S:92 > #25 0x937c1270 in -[NSApplication sendAction:to:from:] () > #26 0x937c11a4 in -[NSControl sendAction:to:] () > #27 0x937c1084 in -[NSCell _sendActionFrom:] () > #28 0x937db09c in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () > #29 0x937dac84 in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] > () > #30 0x937da6a8 in -[NSControl mouseDown:] () > #31 0x9377beb0 in -[NSWindow sendEvent:] () > #32 0x93724ef4 in -[NSApplication sendEvent:] () > #33 0x9371c330 in -[NSApplication run] () > #34 0x9380ce68 in NSApplicationMain () > #35 0x010496f4 in objc_NSApplicationMain (self=0x1147470, args=0x90ab1aa0, > kwds=0x1147470) at Modules/AppKit/_AppKit.m:129 > #36 0x98747c5c in PyEval_GetFuncDesc () > #37 0x98745414 in PyEval_EvalCode () > #38 0x987465e4 in PyEval_EvalCodeEx () > #39 0x98747f90 in PyEval_GetFuncDesc () > #40 0x98747d34 in PyEval_GetFuncDesc () > #41 0x98745414 in PyEval_EvalCode () > #42 0x987465e4 in PyEval_EvalCodeEx () > #43 0x98742eb8 in PyEval_EvalCode () > #44 0x9876708c in PyRun_FileExFlags () > #45 0x9873c210 in _PyUnicodeUCS2_IsAlpha () > #46 0x98747c5c in PyEval_GetFuncDesc () > #47 0x98745414 in PyEval_EvalCode () > #48 0x987465e4 in PyEval_EvalCodeEx () > #49 0x98747f90 in PyEval_GetFuncDesc () > #50 0x98747d34 in PyEval_GetFuncDesc () > #51 0x98745414 in PyEval_EvalCode () > #52 0x987465e4 in PyEval_EvalCodeEx () > #53 0x98742eb8 in PyEval_EvalCode () > #54 0x9876708c in PyRun_FileExFlags () > #55 0x987660b0 in PyRun_SimpleFileExFlags () > #56 0x00003db0 in ?? () > #57 0x00003e50 in ?? () > #58 0x00002414 in ?? () > #59 0x8fe01048 in __dyld__dyld_start () > > And here's the trace output in the console when the app just pukes running > outside of gdb > > Stack trace (most recent call last): > 0x00002414 (in Trigger) > 0x00003e50 (in Trigger) > 0x00003db0 (in Trigger) > _PyRun_SimpleFileExFlags (in Python) > _PyRun_FileExFlags (in Python) > _PyEval_EvalCode (in Python) > _PyEval_EvalCodeEx (in Python) > _PyEval_EvalCode (in Python) > _PyEval_GetFuncDesc (in Python) > _PyEval_GetFuncDesc (in Python) > _PyEval_EvalCodeEx (in Python) > _PyEval_EvalCode (in Python) > _PyEval_GetFuncDesc (in Python) > __PyUnicodeUCS2_IsAlpha (in Python) > _PyRun_FileExFlags (in Python) > _PyEval_EvalCode (in Python) > _PyEval_EvalCodeEx (in Python) > _PyEval_EvalCode (in Python) > _PyEval_GetFuncDesc (in Python) > _PyEval_GetFuncDesc (in Python) > _PyEval_EvalCodeEx (in Python) > _PyEval_EvalCode (in Python) > _PyEval_GetFuncDesc (in Python) > _objc_NSApplicationMain (in _AppKit.so) (_AppKit.m:129) > _NSApplicationMain (in AppKit) > -[NSApplication run] (in AppKit) > -[NSApplication sendEvent:] (in AppKit) > -[NSWindow sendEvent:] (in AppKit) > -[NSControl mouseDown:] (in AppKit) > -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] (in AppKit) > -[NSCell trackMouse:inRect:ofView:untilMouseUp:] (in AppKit) > -[NSCell _sendActionFrom:] (in AppKit) > -[NSControl sendAction:to:] (in AppKit) > -[NSApplication sendAction:to:from:] (in AppKit) > _ffi_closure_ASM (in _objc.so) (darwin_closure.S:95) > _ffi_closure_helper_DARWIN (in _objc.so) (ffi_darwin.c:703) > _method_stub (in _objc.so) (libffi_support.m:479) > _PyObject_Call (in Python) > _pysel_call (in _objc.so) (selector.m:941) > _PyObject_Call (in Python) > _PyFunction_SetClosure (in Python) > _PyEval_EvalCodeEx (in Python) > _PyEval_EvalCode (in Python) > _PyEval_GetFuncDesc (in Python) > _PyEval_GetFuncDesc (in Python) > _PyObject_Call (in Python) > _objcsel_call (in _objc.so) (selector.m:517) > _PyObjCFFI_Caller (in _objc.so) (libffi_support.m:1300) > _ffi_call (in _objc.so) (ffi_darwin.c:404) > _ffi_call_DARWIN (in _objc.so) (darwin.S:121) > -[NSArrayController _insertObject:atArrangedObjectIndex:objectHandler:] > (in AppKit) > -[NSArrayController > didChangeValuesForArrangedKeys:objectKeys:indexKeys:] (in AppKit) > -[NSController _notifyObserversForKeyPath:change:] (in AppKit) > -[NSObject(NSKeyValueObservingPrivate) > _notifyObserversForKeyPath:change:] (in Foundation) > -[NSSelectionBinder observeValueForKeyPath:ofObject:change:context:] (in > AppKit) > -[NSValueBinder _observeValueForKeyPath:ofObject:context:] (in AppKit) > -[NSSelectionBinder > _adjustObject:mode:observedController:observedKeyPath:context:editableState:adjustState:] > (in AppKit) > -[_NSModelObservingTracker > setIndexReferenceModelObjectArray:clearAllModelObjectObserving:] (in AppKit) > > -[_NSZombie retain] (in Foundation) > +[NSException raise:format:] (in Foundation) > _NSExceptionHandlerExceptionRaiser (in ExceptionHandling) > 2006-04-09 16:13:52.454 Trigger[762] NSGenericException - *** Selector > 'retain' sent to dealloced instance 0x1147be0 of class OC_PythonArray. > Break at '-[_NSZombie retain]' to debug. > > > > -- > The extent to which an individual can resist being blindly led by > tradition is a good measure of his vitality. - Harry Partch > > There is a computer disease that anybody who works with computers knows > about. It's a very serious disease and it interferes completely with the > work. The trouble with computers is that you 'play' with them! - Richard P. > Feynman > > Few people are capable of expressing with equanimity opinions which differ > from the prejudices of their social environment. Most people are not even > capable of forming such opinions. - Einstein > > -- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality. - Harry Partch There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060409/094c8b6b/attachment.html From wescpy at gmail.com Mon Apr 10 08:25:26 2006 From: wescpy at gmail.com (w chun) Date: Sun, 9 Apr 2006 23:25:26 -0700 Subject: [Pythonmac-SIG] bin and version In-Reply-To: References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> Message-ID: <78b3a9580604092325p616c862en73c3b1f323f289c9@mail.gmail.com> one tricky thing to watch out for is not just where the executable is installed, but where the libraries are. you may have 2 executables sharing the same library, you may not. on my mac, python is installed in /sw/bin and /usr/local/bin, and the libraries are in /sw/lib, /usr/local/lib, and /Library/Frameworks/Python.framework/Versions i have 2.3.5, 2.4.3, and 2.5a1 installed on my iBook. cheers, -wesley From ronaldoussoren at mac.com Mon Apr 10 09:28:08 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 09:28:08 +0200 Subject: [Pythonmac-SIG] is anyone annoyed with MacPython2.4's IDLE'scursor info In-Reply-To: References: <65fadfc30604072139u198bd372m3a9cd41b3aa25243@mail.gmail.com> Message-ID: <416682.1144654088548.JavaMail.ronaldoussoren@mac.com> On Sunday, April 09, 2006, at 11:38PM, Nehemiah I. Dacres wrote: >> >>> While im at it, will there ever be the same kind of syntax >>> coloring in >>> "Python IDE" otherwise I'll just continue to use TextWrangler"? >> >> You're probably better of asking about syntax coloring on the IDLE-dev >> list (http://mail.python.org/mailman/listinfo/idle-dev) > > >Does Python IDE have a Dev Site or MAN page? cause i have no problem >with IDLE's coloring, it HAS coloring, "Python IDE" DOESN'T thats why >I asked. As Bob said: Don't use Python IDE. Python IDE is deprecated and won't be installed by my Universal Binary installer. It is an OS9 application that was never properly Carbonized. If I get around to it Python IDE will be removed in 2.5. Ronald >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From ronaldoussoren at mac.com Mon Apr 10 09:30:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 09:30:56 +0200 Subject: [Pythonmac-SIG] Install location In-Reply-To: References: Message-ID: <5396037.1144654256037.JavaMail.ronaldoussoren@mac.com> On Monday, April 10, 2006, at 02:07AM, Timothy Reaves wrote: > Why is it the installer at http://www.python.org/download/releases/ >2.4.3/ install into /Applications ? Why does it not install as a >framework? ActiveState Python does, although they still user /usr/ >local/bin for the links. The python.org installer also installs a framework with links in /usr/local/bin. It also installs a number of GUI applications in /Applications, but that's where your supposed to install application bundles! Ronald > > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From ronaldoussoren at mac.com Mon Apr 10 09:49:51 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 09:49:51 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <2003350.1144655391669.JavaMail.ronaldoussoren@mac.com> On Monday, April 10, 2006, at 02:25AM, has wrote: > >All it needs is somebody with some decent Photoshop compositing skills (and maybe a nice 3D drawing of a technical pencil) to > assemble the finished elements. I'd have done it myself by now just to settle it, only I don't have access to a decent copy of > Photoshop any more and am a bit rusty after a few years out of the game, but I'm fair tempted to grit teeth and beat it out in > the GIMP anyway. I'd be happy that someone with more practice at icon work did it though; that Kenichi Yoshida chap, for > example, looks like he could do a very nice job just given the raw resources and left to get on with it. +1. The "yoshida mockup" looks very OSX-ish, but I don't like it as an icon for python. It's definitely not an order of magnitude better than the python.org logo, hence we should go with the official logo. We need icons for: * .py/.pyw document (generic document icon with logo as a batch) * .pyc "document", like the .py icon but slightly different :-) * IDLE Application icon * Build Applet icon (or drop that tool?) It would also be nice to have a generic icon for python application bundles. That is, the icon you get when you build an application with Build Applet or py2app when you don't specify another icon. I have neither photoshop nor graphic skills, so it would be nice if someone else could create these icons. Ronald From hengist.podd at virgin.net Mon Apr 10 12:55:23 2006 From: hengist.podd at virgin.net (has) Date: Mon, 10 Apr 2006 11:55:23 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <2003350.1144655391669.JavaMail.ronaldoussoren@mac.com> References: <2003350.1144655391669.JavaMail.ronaldoussoren@mac.com> Message-ID: Ronald Oussoren wrote: > >All it needs is somebody with some decent Photoshop compositing skills (and maybe a nice 3D drawing of a technical pencil) to > > assemble the finished elements. [...] > > I'd be happy that someone with more practice at icon work did it though; that Kenichi Yoshida chap, for > > example, looks like he could do a very nice job just given the raw resources and left to get on with it. > >+1. The "yoshida mockup" looks very OSX-ish, but I don't like it as an icon for python. It's definitely not an order of magnitude better than the python.org logo, hence we should go with the official logo. His lego snake icon is awful but the other work on his site is good, so I think a straightforward brief requesting familiar icons for the following file types incorporating the Python logo and told to go away and do it would produce suitable result. But any decent artist ought to be able to do it; as I say, Python itself is very utilitarian so a very utilitarian set of icons is fine; wild flights of fancy are both unnecessary and unhelpful to users. >We need icons for: >* .py/.pyw document (generic document icon with logo as a batch) Yes, keep it simple: plain while document icon with Python logo in the middle. >* .pyc "document", like the .py icon but slightly different :-) Or .pyo. I'd suggest same as the above, except with some binary 0-1 symbols, either as a dark grey run of eight 1s and 0s along the bottom of the document, or as a light grey random 0-1 pattern covering the entire background of the document. Or you could put a short word like 'binary' or 'byte' or something like that along the bottom of an otherwise identical icon, which seems to be a common way of indicating its purpose. >* IDLE Application icon A typical editor icon a-la Script Editor except with the Python icon and a different style of pen (e.g. technical pencil) may be acceptable; the only caveat is that IDLE isn't a conventional document editor a-la Script Editor but more a lightweight interactive interpreter with a Save option on the side. If a document editor icon a-la Script Editor is deemed 'misleading', then something closer to Terminal.app's may better represent its function. Thoughts? >* Build Applet icon (or drop that tool?) (Forgot about that one.) I think the standard grinder idea is fine; it just needs redone to a modern standard and incorporating the Python logo. >It would also be nice to have a generic icon for python application bundles. That is, the icon you get when you build an application with Build Applet or py2app when you don't specify another icon. Something similar to the general applet icon that Script Editor gives you, except using the Python logo instead of the AS one. Also, PythonLauncher.app as I say; not entirely sure what the common way to represent something like that would be. There's the rocket idea a-la Java's Applet Launcher.app, so probably something similar perhaps with a slightly fatter rocket. >I have neither photoshop nor graphic skills, so it would be nice if someone else could create these icons. I have skills (though I'm still struggling a bit for tools) so I'll do it if nobody else comes up with a better candidate. has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Mon Apr 10 13:11:56 2006 From: hengist.podd at virgin.net (has) Date: Mon, 10 Apr 2006 12:11:56 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: I wrote: >>* IDLE Application icon > >A typical editor icon a-la Script Editor except with the Python icon and a different style of pen (e.g. technical pencil) may be acceptable; the only caveat is that IDLE isn't a conventional document editor a-la Script Editor but more a lightweight interactive interpreter with a Save option on the side. On second thoughts, IDLE's save option just does a straight dump of the interpreter display, so a document editor symbol is somewhat misleading and it should be something closer to a terminal window like Terminal.app. has -- http://freespace.virgin.net/hamish.sanderson/ From ronaldoussoren at mac.com Mon Apr 10 13:35:27 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 13:35:27 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <77764.1144668927117.JavaMail.ronaldoussoren@mac.com> On Monday, April 10, 2006, at 01:25PM, has wrote: >I wrote: > >>>* IDLE Application icon >> >>A typical editor icon a-la Script Editor except with the Python icon and a different style of pen (e.g. technical pencil) may be acceptable; the only caveat is that IDLE isn't a conventional document editor a-la Script Editor but more a lightweight interactive interpreter with a Save option on the side. > >On second thoughts, IDLE's save option just does a straight dump of the interpreter display, so a document editor symbol is somewhat misleading and it should be something closer to a terminal window like Terminal.app. IDLE can also edit python files and save them. What's missing is stanza in Info.plist that tells that IDLE can edit .py and .pyw files. An icon like that for Script Editor with the python.org logo instead of a scroll would IMO be acceptable. Ronald > >has >-- >http://freespace.virgin.net/hamish.sanderson/ >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From daniellord at mac.com Mon Apr 10 15:16:38 2006 From: daniellord at mac.com (Daniel Lord) Date: Mon, 10 Apr 2006 06:16:38 -0700 Subject: [Pythonmac-SIG] appscript installer contents not Universal In-Reply-To: References: Message-ID: I have discovered that the appscript installer from your site is not Universal, though building it from source using he new Universal Python build works. I have an Intel system and I built, installed, and tested it (somewhat with my own projects). If you send me the instruction to build the package (I have not built an OS X installer before so this would be a good chance to learn), I'll create a Universal installer as I have both PPC and i386 now to test on. Daniel From kquirk at solidworks.com Mon Apr 10 16:57:53 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Mon, 10 Apr 2006 10:57:53 -0400 Subject: [Pythonmac-SIG] talking points, Pythonismus Message-ID: Charles wrote: ~~~~~~~~~~~~~~ I've been campaigning with the main teacher of programming on my campus -- from my thoroughly non-leveraged position as prof of English -- to consider switching from Java to Python, for all the reasons which will be obvious to everybody here. (The existence of "wxPython in Action" is the decisive event for me.) I recently got a thoughtful reply from him which included this paragraph: Actually, I am using Matlab, which is dynamically typed as well, in some of my courses and I know it works well until types become important. In image processing, for example, they easily mistake the 'byte' data types for doubles which are the default. Ease of use leads to overconfidence in this case. Sometimes they claim that the program (the interpreter) isn't working right. ~~~~~~~~~~~~~~~~~~~~~~~ While true, I'm not sure this comment is particularly useful. It's the equivalent of saying that an automatic transmission is useful until shifting becomes important. Or that a snowblower is useful until shoveling becomes important. The real question is, what are you trying to encourage in your students? If you're trying to get students to understand algorithmic thinking, precision in their thoughts, and breaking down complex concepts into a series of small steps, you want the lowest-friction programming language you can find, and Python is certainly a great candidate (I think it's one of the best, but that's why I'm here.) I'm a huge fan of teaching introductory programming in high level languages with high level tools. Last summer I taught a group of high school teachers to teach programming using Python and PyGame. I had 4 days - and by the end of 4 days these inexperienced teachers had a working game written in Python, which at least one of the teachers later gave to her students as a programming assignment. But if you're trying to prepare students to be useful programmers in the real world, there are people who will argue that students eventually need to understand enough about computer architecture to deal with pointers and data types in their native bits. Joel Spolsky ("Joel on Software) argued this fairly eloquently in this article: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html I actually co-wrote a computer science textbook on Java...but in the couple of years since, I've come to the conclusion that Java is pretty much the worst of all possible worlds. Too low-level to be a scripting language, too high-level to be a good systems language, too damn wordy for applications programming. (But I do quite like the Java VM.) So in terms of discussions with your colleague, I'd suggest that he'd probably achieve everything he wanted by teaching both Python and C or C++ instead of doing it all in Java. But programming languages are religious artifacts, so be prepared for responses that may not be completely based in "objective" rationality. Kent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060410/cefa4f3c/attachment.html From gabor at nekomancer.net Mon Apr 10 17:06:14 2006 From: gabor at nekomancer.net (=?UTF-8?B?R8OhYm9yIEZhcmthcw==?=) Date: Mon, 10 Apr 2006 17:06:14 +0200 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japanese input" support Message-ID: <443A7466.5060206@nekomancer.net> hi, i'd like to write a simple python-mac application, for which i need to choose a gui toolkit. the problem is that i need to be able to enter japanese text, which means i need support for.... i don't know how that's called in osx (on linux that would be input methods). for example with tkinter it is not possible. i know that using pyobjc and doing directly cocoa would work, but last time i checked it it seemed quite complicated. so, is there something simpler? maybe a simple gui toolkit built on cocoa? thanks, gabor From hraban at fiee.net Mon Apr 10 18:27:01 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Mon, 10 Apr 2006 18:27:01 +0200 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japanese input" support In-Reply-To: <443A7466.5060206@nekomancer.net> References: <443A7466.5060206@nekomancer.net> Message-ID: <3C9E36BD-3EE9-4C43-93B6-D9007155BAA9@fiee.net> Am 2006-04-10 um 17:06 schrieb G?bor Farkas: > i'd like to write a simple python-mac application, > for which i need to choose a gui toolkit. > > the problem is that i need to be able to enter japanese text, > which means i need support for.... i don't know how that's called > in osx > (on linux that would be input methods). Did you have a look at wxPython? (http://www.wxpython.org) It's the best cross platform GUI toolkit for Python that I know of; it uses native controls on every platform (Mac, Win, GTK) and is able to handle Unicode chars, also Japanese. (Maybe there are issues with some special controls.) I don't know what else is needed for CJK, but I guess the input method is a matter of the OS, not of your app. Greetlings from Lake Constance! Hraban --- http://www.fiee.net http://www.cacert.org (I'm an assurer) From bob at redivi.com Mon Apr 10 18:43:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 10 Apr 2006 09:43:51 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <4BDE5848-6E5C-4066-B97F-746442985096@redivi.com> On Apr 10, 2006, at 4:11 AM, has wrote: > I wrote: > >>> * IDLE Application icon >> >> A typical editor icon a-la Script Editor except with the Python >> icon and a different style of pen (e.g. technical pencil) may be >> acceptable; the only caveat is that IDLE isn't a conventional >> document editor a-la Script Editor but more a lightweight >> interactive interpreter with a Save option on the side. > > On second thoughts, IDLE's save option just does a straight dump of > the interpreter display, so a document editor symbol is somewhat > misleading and it should be something closer to a terminal window > like Terminal.app. I think you're totally mislead as to what IDLE does. Yes, it has interactive interpreters with a save feature, but it also edits source files and has a debugger. It IS conventional. -bob From delza at livingcode.org Mon Apr 10 19:02:30 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 10 Apr 2006 10:02:30 -0700 Subject: [Pythonmac-SIG] bin and version In-Reply-To: References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> Message-ID: <24d517dd0604101002m7c7eba51s675d4431315ad25f@mail.gmail.com> On 4/9/06, Daniel Lord wrote: > > On Apr 8, 2006, at 7:59 PM, linda.s wrote: > > > Hi, > > I installed quite a few python versions in my computer and I want to > > know where they are located. > > Should i check them in the bin folder? > > If so, why I can not find the bin folder in my home directory? > > Someone answered the portion regarding the commands. As for the > location of the 'bin' directory, OS X hides several UNIX directories > in the Finder as part of their simplification facade. You can always > access them from the shell: [snipped] You can access them from the Finder too, either with the menu Go->Go to Folder... or via the keyboard: Cmd-Shift-G. Either way, you can then type in any directory (such as /bin/) and it will open up a Finder window for it, whether it is normally visible in the Finder or not. If you're already in the Terminal (or other command-line shell), the command "open [directory]" will open the directory as a folder in the Finder. So, "open ." will open the current directory, and "open /usr/local/bin" will open that directory in a Finder window. Of course, the quotes are just for this email, you don't type them in the command. --Dethe From saggau at gmail.com Mon Apr 10 19:24:33 2006 From: saggau at gmail.com (Saggau) Date: Mon, 10 Apr 2006 13:24:33 -0400 Subject: [Pythonmac-SIG] bin and version In-Reply-To: <24d517dd0604101002m7c7eba51s675d4431315ad25f@mail.gmail.com> References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> <24d517dd0604101002m7c7eba51s675d4431315ad25f@mail.gmail.com> Message-ID: You can show all hidden files in the finder, too. defaults write com.apple.finder AppleShowAllFiles -bool TRUE On tiger, this causes all icons to get a little bit transparent as though they're all hidden. I think that there is a macosxhints discussion about this that wraps it all up in a nice applescript or automator applet. Jonathan Saggau On 4/10/06, Dethe Elza wrote: > > On 4/9/06, Daniel Lord wrote: > > > > On Apr 8, 2006, at 7:59 PM, linda.s wrote: > > > > > Hi, > > > I installed quite a few python versions in my computer and I want to > > > know where they are located. > > > Should i check them in the bin folder? > > > If so, why I can not find the bin folder in my home directory? > > > > Someone answered the portion regarding the commands. As for the > > location of the 'bin' directory, OS X hides several UNIX directories > > in the Finder as part of their simplification facade. You can always > > access them from the shell: > [snipped] > > You can access them from the Finder too, either with the menu Go->Go > to Folder... or via the keyboard: Cmd-Shift-G. Either way, you can > then type in any directory (such as /bin/) and it will open up a > Finder window for it, whether it is normally visible in the Finder or > not. > > If you're already in the Terminal (or other command-line shell), the > command "open [directory]" will open the directory as a folder in the > Finder. So, "open ." will open the current directory, and "open > /usr/local/bin" will open that directory in a Finder window. Of > course, the quotes are just for this email, you don't type them in the > command. > > --Dethe > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality. - Harry Partch There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060410/47923d29/attachment.html From hengist.podd at virgin.net Mon Apr 10 19:29:06 2006 From: hengist.podd at virgin.net (has) Date: Mon, 10 Apr 2006 18:29:06 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4BDE5848-6E5C-4066-B97F-746442985096@redivi.com> References: <4BDE5848-6E5C-4066-B97F-746442985096@redivi.com> Message-ID: Bob wrote: >I think you're totally mislead as to what IDLE does. Yes, it has interactive interpreters with a save feature, but it also edits source files and has a debugger. It IS conventional. Yep, you're right. I never use IDLE myself (it's a bizarre-looking beast [1] and I notice it doesn't run appscript either) so missed that bit. Go with the SE-like format then. has [1] OT: I rather suspect IDLE's very un-Mac-like look and feel makes it more of a liability than an advantage in terms of attracting new users, but this is a different discussion for another time... -- http://freespace.virgin.net/hamish.sanderson/ From delza at livingcode.org Mon Apr 10 19:35:22 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 10 Apr 2006 10:35:22 -0700 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japanese input" support In-Reply-To: <443A7466.5060206@nekomancer.net> References: <443A7466.5060206@nekomancer.net> Message-ID: <24d517dd0604101035y5c375144w3e43c1dbd2e36bc8@mail.gmail.com> On 4/10/06, G?bor Farkas wrote: > hi, > > i'd like to write a simple python-mac application, > for which i need to choose a gui toolkit. The primary GUI toolkit for Mac-specific work is to use Cocoa via the PyObjC bridge. http://pyobjc.sourceforge.net/ > the problem is that i need to be able to enter japanese text, > which means i need support for.... i don't know how that's called in osx > (on linux that would be input methods). They're called input methods on OS X too. Take a look at Apple's docs on the subject of international text: http://developer.apple.com/documentation/Carbon/Conceptual/Supporting_Unicode_Input/index.html?http://developer.apple.com/documentation/Carbon/Conceptual/Supporting_Unicode_Input/sui_concepts/chapter_2_section_5.html To see the types of inputs that are available, go to the System Preferences and look at the International panel, especially the Input Menu tab. OS X is international by default, using Unicode for text strings internally, and supports a wide array of input > for example with tkinter it is not possible. I imagine that Tkinter works if you use the system input methods, but I haven't tested it. > i know that using pyobjc and doing directly cocoa would work, > but last time i checked it it seemed quite complicated. What was complicated about it? It's hard to help without further information. > so, is there something simpler? maybe a simple gui toolkit built on cocoa? There is a simple GUI toolkit built on Cocoa, it's called PyObjC. There are some efforts at making an even simpler interface, namely PyGUI and Renaissance, but I would recommend you work with PyObjC, build your UI with Interface Builder, and use AppKiDo to supplement Apple's documentation. PyGUI http://www.cosc.canterbury.ac.nz/~greg/python_gui/ Renaissance http://www.gnustep.it/Renaissance/ AppKiDo (handy Cocoa reference) http://homepage.mac.com/aglee/downloads/ > thanks, > gabor HTH --Dethe From gabor at nekomancer.net Mon Apr 10 20:04:57 2006 From: gabor at nekomancer.net (gabor) Date: Mon, 10 Apr 2006 20:04:57 +0200 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japanese input" support In-Reply-To: <24d517dd0604101035y5c375144w3e43c1dbd2e36bc8@mail.gmail.com> References: <443A7466.5060206@nekomancer.net> <24d517dd0604101035y5c375144w3e43c1dbd2e36bc8@mail.gmail.com> Message-ID: <443A9E49.3040006@nekomancer.net> Dethe Elza wrote: > On 4/10/06, G?bor Farkas wrote: >> hi, >> >> i'd like to write a simple python-mac application, >> for which i need to choose a gui toolkit. > > The primary GUI toolkit for Mac-specific work is to use Cocoa via the > PyObjC bridge. > > http://pyobjc.sourceforge.net/ > >> the problem is that i need to be able to enter japanese text, >> for example with tkinter it is not possible. > > I imagine that Tkinter works if you use the system input methods, but > I haven't tested it. i tried. i simply cut&pasted a small Tkinter program with a textfield (Entry object) from a webpage and tried it. but it was not able to "accept" japanese characters. > >> i know that using pyobjc and doing directly cocoa would work, >> but last time i checked it it seemed quite complicated. > > What was complicated about it? It's hard to help without further information. sorry. i should have written it more specifically. all those "objc-specific" things make it look complicated imho. look at: http://svn.red-bean.com/pyobjc/trunk/pyobjc/Examples/Scripts/HelloWorld.py " delegate = AppDelegate.alloc().init() NSApp().setDelegate_(delegate) " and things like that. i understand that there's just no other way if one wants to use the "raw" mac-api, but i'd prefer something "higher-level". > >> so, is there something simpler? maybe a simple gui toolkit built on cocoa? > > There is a simple GUI toolkit built on Cocoa, it's called PyObjC. > There are some efforts at making an even simpler interface, namely > PyGUI and Renaissance, but I would recommend you work with PyObjC, > build your UI with Interface Builder, and use AppKiDo to supplement > Apple's documentation. > > PyGUI > http://www.cosc.canterbury.ac.nz/~greg/python_gui/ pyGUI seems right now perfect :-) hmm... maybe i made a mistake not saying anything about what i'm trying to build. it's going to be a simple dictionary application,so it will only have a VERY simple gui... some textfields and some buttons and that's all (for now). so i simply don't need the complexity of the interface-builder and so on. i understand that it makes sense to learn it and so on, but for now, pyGUI is enough :-) many thanks for the information, gabor From kquirk at solidworks.com Mon Apr 10 20:22:58 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Mon, 10 Apr 2006 14:22:58 -0400 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support Message-ID: -----Original Message----- From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Dethe Elza Sent: Monday, April 10, 2006 1:35 PM To: G?bor Farkas Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support > > so, is there something simpler? maybe a simple gui toolkit built on cocoa? > There is a simple GUI toolkit built on Cocoa, it's called PyObjC. For particularly large values of "simple", I guess. For those who don't already speak Cocoa, PyObjC is annoyingly cumbersome. Using it requires that you understand Cocoa enough to know how to read its documentation, understand its message model, understand the way it handles object allocation, and be able to use Interface Builder. I get the impression that for those who've used Cocoa and prefer Python, it's a breath of fresh air...but for those who've not been swimming in a vat of Cocoa, it's not quite so appetizing. > There are some efforts at making an even simpler interface, > namely PyGUI and Renaissance, but I would recommend you work > with PyObjC, build your UI with Interface Builder, and use > AppKiDo to supplement Apple's documentation. Note this goal from the PyGUI documentation page: "Document the API purely in Python terms, so that the programmer does not need to read the documentation for another GUI library, in terms of another language, and translate into Python." - Kent From bob at redivi.com Mon Apr 10 20:29:30 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 10 Apr 2006 11:29:30 -0700 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japanese input" support In-Reply-To: <443A9E49.3040006@nekomancer.net> References: <443A7466.5060206@nekomancer.net> <24d517dd0604101035y5c375144w3e43c1dbd2e36bc8@mail.gmail.com> <443A9E49.3040006@nekomancer.net> Message-ID: On Apr 10, 2006, at 11:04 AM, gabor wrote: > Dethe Elza wrote: >> On 4/10/06, G?bor Farkas wrote: >>> hi, >>> >>> i'd like to write a simple python-mac application, >>> for which i need to choose a gui toolkit. >> >> The primary GUI toolkit for Mac-specific work is to use Cocoa via the >> PyObjC bridge. >> >> http://pyobjc.sourceforge.net/ >> >>> the problem is that i need to be able to enter japanese text, >>> for example with tkinter it is not possible. >> >> I imagine that Tkinter works if you use the system input methods, but >> I haven't tested it. > > i tried. i simply cut&pasted a small Tkinter program with a textfield > (Entry object) from a webpage and tried it. but it was not able to > "accept" japanese characters. > >> >>> i know that using pyobjc and doing directly cocoa would work, >>> but last time i checked it it seemed quite complicated. >> >> What was complicated about it? It's hard to help without further >> information. > > sorry. i should have written it more specifically. > all those "objc-specific" things make it look complicated imho. > > look at: > http://svn.red-bean.com/pyobjc/trunk/pyobjc/Examples/Scripts/ > HelloWorld.py > > " > delegate = AppDelegate.alloc().init() > NSApp().setDelegate_(delegate) > " > > and things like that. i understand that there's just no other way > if one > wants to use the "raw" mac-api, but i'd prefer something "higher- > level". This is the raw API, not the high level. Don't look at any of the scripts examples, you need to be looking at the examples that use Interface Builder. The tutorial is a much better place to start. -bob From delza at livingcode.org Mon Apr 10 20:38:55 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 10 Apr 2006 11:38:55 -0700 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support In-Reply-To: References: Message-ID: <24d517dd0604101138x6fe09ecdy6d4d88b0454db393@mail.gmail.com> On 4/10/06, Kent Quirk wrote: > > > so, is there something simpler? maybe a simple gui toolkit built on cocoa? > > > There is a simple GUI toolkit built on Cocoa, it's called PyObjC. > > For particularly large values of "simple", I guess. For those who don't already speak Cocoa, PyObjC is annoyingly cumbersome. Using it requires that you understand Cocoa enough to know how to read its documentation, understand its message model, understand the way it handles object allocation, and be able to use Interface Builder. The value of simple being: Exposing all of Cocoa, in a standard way so that existing documentation is usable, from Python. The translation makes using Cocoa from Python simple (as simple as it can be). > I get the impression that for those who've used Cocoa and prefer Python, it's a breath of fresh air...but for those who've not been swimming in a vat of Cocoa, it's not quite so appetizing. I have not used Objective-C for anything but a couple of trivial tutorials, I dove straight in with Python. I understand there is a bit of a learning curve, and I've blogged about some of my own learning experiences with PyObjC, Renaissance, and my love/hate relationship with Interface Builder on my blog: http://livingcode.blogspot.com/ I've been quiet there for awhile while I write my own blogging software (in PyObjC) to allow me to interate faster and get more of my PyObjC tutorial stuff posted. A lot of the time, when I've felt that I had to do too much work in PyObjC, it's because I was not doing it the Cocoa Way. And I totally agree that it can be a pain to learn The Cocoa Way in order to build a small, simple program. On the other hand, as you graduate to more complex programs, learning to do it right can ease your development work by orders of magnitude, so the investment can pay off. And some of the more hairy parts of Cocoa aren't necessary when you're working in Python, because you can just use the Python standard library (or 3rd party libraries), so you get the best of both worlds. > > There are some efforts at making an even simpler interface, > > namely PyGUI and Renaissance, but I would recommend you work > > with PyObjC, build your UI with Interface Builder, and use > > AppKiDo to supplement Apple's documentation. > > Note this goal from the PyGUI documentation page: > > "Document the API purely in Python terms, so that the programmer does not need to read the documentation for another GUI library, in terms of another language, and translate into Python." That can be a good goal, but on the other hand, there is a *lot* of documentation on Cocoa, far more than PyGUI will ever achieve, and the PyObjC bridge makes it trivial to translate that into Python. And I wouldn't expect PyGUI to expose everything from Cocoa (not it's purpose, it's a cross-platform wrapper), so if there's something beyond what PyGUI offers, don't be afraid to dip back to PyObjC. I do think that PyGUI is a much better approach to cross-platform GUI tools than, say, wxPython. The cross-platform abstractions should be kept as high-level as possible, i.e., in Python, not in a huge C++ library that then gets wrapped in Python. --Dethe > > > > - Kent > > From pecora at anvil.nrl.navy.mil Mon Apr 10 21:11:10 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon, 10 Apr 2006 15:11:10 -0400 Subject: [Pythonmac-SIG] wxPython book. First example misbehaves on my Mac ?? What's happening? Message-ID: <443AADCE.2020205@anvil.nrl.navy.mil> I just got the wxPython in Action book (Rappin and Dunn). Looks good. I've been fooling around with the first two (very trivial) examples, but their behavior is not what is expected. They run, a window (frame) opens, but then immediately closes and the application quits. No errors. Just "normal" termination. I've run it from BBEdit and from the command line. Same thing each way. I expected the window to stay open until I clicked the close button. Anyone have a clue for me? (it's gotta be something easy I'm missing). I'm running Python 2.4.1. Here's the code (9 lines): #!/usr/bin/pythonw import wx class App(wx.App): def OnInit(self): frame = wx.Frame(parent=None, title="BaRe") frame.Show() return true app = App() app.MainLoop() -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From dave.opstad at monotypeimaging.com Mon Apr 10 21:21:31 2006 From: dave.opstad at monotypeimaging.com (Opstad, Dave) Date: Mon, 10 Apr 2006 15:21:31 -0400 Subject: [Pythonmac-SIG] wxPython book. First example misbehaves on my Mac ?? What's happening? In-Reply-To: <443AADCE.2020205@anvil.nrl.navy.mil> Message-ID: On 4/10/06 12:11 PM, "Louis Pecora" wrote: > #!/usr/bin/pythonw > > import wx > > class App(wx.App): > def OnInit(self): > frame = wx.Frame(parent=None, title="BaRe") > frame.Show() > return true > > app = App() > app.MainLoop() I think the return should be True, not true. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060410/fbf6a444/attachment.html From charles.hartman at conncoll.edu Mon Apr 10 21:51:32 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 10 Apr 2006 15:51:32 -0400 Subject: [Pythonmac-SIG] wxPython book. First example misbehaves on my Mac ?? What's happening? In-Reply-To: References: Message-ID: On Apr 10, 2006, at 3:21 PM, Opstad, Dave wrote: > On 4/10/06 12:11 PM, "Louis Pecora" wrote: > > > #!/usr/bin/pythonw > > > > import wx > > > > class App(wx.App): > > def OnInit(self): > > frame = wx.Frame(parent=None, title="BaRe") > > frame.Show() > > return true > > > > app = App() > > app.MainLoop() > > I think the return should be True, not true. > > Dave > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig And I think the shebang line at the beginning should be #!/usr/bin/env pythonw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060410/297b022a/attachment.htm From zbir at urbanape.com Mon Apr 10 21:58:54 2006 From: zbir at urbanape.com (Zachery Bir) Date: Mon, 10 Apr 2006 15:58:54 -0400 Subject: [Pythonmac-SIG] The Universal Buld and py2app In-Reply-To: References: <06Mar27.113702pst.58633@synergy1.parc.xerox.com> <5FB132E3-C499-4C2A-A927-CAEAE1839855@redivi.com> <44286D61.1070504@noaa.gov> <2CDC34C5-909B-4642-93EA-9BC73B05156D@redivi.com> <44288D18.6080400@noaa.gov> Message-ID: On Apr 1, 2006, at 10:02 PM, Bob Ippolito wrote: > On Mar 27, 2006, at 5:29 PM, Bob Ippolito wrote: > >> On Mar 27, 2006, at 5:10 PM, Christopher Barker wrote: >> >>> Bob, >>> >>> What's the status of Py2App and the new universal build. I'd like >>> to start making packages for it, but I"d really like bdist_mpkg. >> >> Not Yet. I have some patches I need to integrate and test. I'll try >> and get to it this weekend, maybe sooner. > > Ok, I got the patches in and I think they work now (despite the > date). The patches were kinda busted and had tabs(!) but on trivial > examples it seems to work. > > The branch with the patches is here: > http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint > > (this is what is currently referenced by pyobjc's trunk as well). > > If enough people try this out and report that it works, then I'll > wrap it up and make a release. The py2app functionality works, and produces a Universal Binary. Modulo my other problems, it looks like it works great! :^) Zac From ronaldoussoren at mac.com Mon Apr 10 22:31:37 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 22:31:37 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <4BDE5848-6E5C-4066-B97F-746442985096@redivi.com> Message-ID: <6CF594C0-BC49-4B80-AA30-D642B9F133A1@mac.com> On 10-apr-2006, at 19:29, has wrote: > Bob wrote: > >> I think you're totally mislead as to what IDLE does. Yes, it has >> interactive interpreters with a save feature, but it also edits >> source files and has a debugger. It IS conventional. > > Yep, you're right. I never use IDLE myself (it's a bizarre-looking > beast [1] and I notice it doesn't run appscript either) so missed > that bit. Go with the SE-like format then. It should do appscript in the universal build. > > has > > [1] OT: I rather suspect IDLE's very un-Mac-like look and feel > makes it more of a liability than an advantage in terms of > attracting new users, but this is a different discussion for > another time... Feel free to send patches to make IDLE's look&feel more mac- like :-). IDLE is all we've got at the moment. Ronald > -- > http://freespace.virgin.net/hamish.sanderson/ > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Mon Apr 10 22:42:20 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 22:42:20 +0200 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support In-Reply-To: References: Message-ID: On 10-apr-2006, at 20:22, Kent Quirk wrote: > > > -----Original Message----- > From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig- > bounces at python.org] On Behalf Of Dethe Elza > Sent: Monday, April 10, 2006 1:35 PM > To: G?bor Farkas > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] needed: simple gui toolkit with > "japaneseinput" support > >>> so, is there something simpler? maybe a simple gui toolkit built >>> on cocoa? > >> There is a simple GUI toolkit built on Cocoa, it's called PyObjC. > > For particularly large values of "simple", I guess. For those who > don't already speak Cocoa, PyObjC is annoyingly cumbersome. Using > it requires that you understand Cocoa enough to know how to read > its documentation, understand its message model, understand the way > it handles object allocation, and be able to use Interface Builder. Interface Builder is in my optinion one of the strong points of Cocoa: drag&drop live objects to build a user interface and then load that from your application code. That's a lot more convenient than building a GUI in code. Cocoa's messaging model is not that much different from Python's. The major differences are two-stage object creationg (aka NSObject.alloc ().init()) and segmented method names (doFoo:andBar:). The hard part of Cocoa is understanding how you should write code that works with the framework instead of against it. In that it isn't different from other large and powerfull frameworks like Twisted. > > I get the impression that for those who've used Cocoa and prefer > Python, it's a breath of fresh air...but for those who've not been > swimming in a vat of Cocoa, it's not quite so appetizing. And to second Dethe: I'm also a python programmer that likes Cocoa. Heck, I wrote[1] PyObjC because I wanted to use Cocoa from Python. Ronald [1] Technically it's 'rewrote', but not much of the code from the original PyObjC is left by now. From trentm at ActiveState.com Mon Apr 10 23:14:03 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 10 Apr 2006 14:14:03 -0700 Subject: [Pythonmac-SIG] Install location In-Reply-To: References: Message-ID: <20060410211403.GB18402@activestate.com> [Timothy Reaves wrote] > Why is it the installer at http://www.python.org/download/releases/ > 2.4.3/ install into /Applications ? Why does it not install as a > framework? ActiveState Python does, although they still user /usr/ > local/bin for the links. As Bob and Ronald mentions the differences aren't quite that big. Both MacPython and ActivePython install core Python as a framework. The main differences are where the small apps associated with Python are placed. Similar to Apple's Python in /System/Library/Frameworks, ActivePython places Python.app, PythonLauncher.app and IDLE.app under the Resources dir in the framework area: /Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app The old (now deprecated) Mac "Python IDE.app" was never included in ActivePython. Ronald, There was discussion a while back to change the MacPython installer to NOT put symlinks in /usr/local/bin, but instead put the full /Library/Frameworks/Python.framework/Versions/2.4/bin on the user's PATH (either doing so automatically or showing the user how) so that setup.py-installed script would get on the PATH as well. Does the universal MacPython build do this or is it still the plan to do so? I was planning to move from using /usr/local/bin to the full framework path in a future ActivePython. Cheers, Trent -- Trent Mick TrentM at ActiveState.com From kquirk at solidworks.com Mon Apr 10 23:21:13 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Mon, 10 Apr 2006 17:21:13 -0400 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support Message-ID: -----Original Message----- From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] Sent: Monday, April 10, 2006 4:42 PM To: Kent Quirk Cc: Dethe Elza; G?bor Farkas; pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support >> I get the impression that for those who've used Cocoa and prefer >> Python, it's a breath of fresh air...but for those who've not been >> swimming in a vat of Cocoa, it's not quite so appetizing. >And to second Dethe: I'm also a python programmer that likes Cocoa. >Heck, I wrote[1] PyObjC because I wanted to use Cocoa from Python. Which is kinda the point -- you already knew Cocoa and wanted to use it in a different context. I don't wish to argue about what's "really" easy or difficult about Cocoa. I was trying to point out that people who don't use Cocoa already, coming at it from Python, find several things about Cocoa to be alien and difficult. And attempting to read and use Cocoa's documentation requires that you already "get" Cocoa, and understand the logic behind such things as two-stage object creation. I'm really not disparaging Cocoa at all as a development platform. I'm merely trying to point out the impedance mismatch between it and Python. Sometimes people forget how much they had to learn. For people experienced in Cocoa and already familiar with it, the similarities are far more important than the differences, and PyObjC is a wonderful tool. But for users unfamiliar with Cocoa and possibly unfamiliar with the Mac, the learning curve can be formidable. From ronaldoussoren at mac.com Mon Apr 10 23:29:11 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 23:29:11 +0200 Subject: [Pythonmac-SIG] Install location In-Reply-To: <20060410211403.GB18402@activestate.com> References: <20060410211403.GB18402@activestate.com> Message-ID: On 10-apr-2006, at 23:14, Trent Mick wrote: > [Timothy Reaves wrote] >> Why is it the installer at http://www.python.org/download/releases/ >> 2.4.3/ install into /Applications ? Why does it not install as a >> framework? ActiveState Python does, although they still user /usr/ >> local/bin for the links. > > As Bob and Ronald mentions the differences aren't quite that big. > Both MacPython and ActivePython install core Python as a framework. > > The main differences are where the small apps associated with > Python are > placed. Similar to Apple's Python in /System/Library/Frameworks, > ActivePython places Python.app, PythonLauncher.app and IDLE.app under > the Resources dir in the framework area: > /Library/Frameworks/Python.framework/Versions/2.4/Resources/ > Python.app Python.app should be in the framework, the only reason it exists is to make Apple's WindowServer happy. It is needed for GUI code in scripts and is the binary started by the pythonw command. PythonLauncher and IDLE are normal applications and should IMHO be in a location where users can click on them, which means the Applications folder. > > The old (now deprecated) Mac "Python IDE.app" was never included in > ActivePython. Good for you! I hope we can completely remove it for Python 2.5 (and my the universal build also doesn't install it) > > Ronald, > > There was discussion a while back to change the MacPython installer to > NOT put symlinks in /usr/local/bin, but instead put the full > /Library/Frameworks/Python.framework/Versions/2.4/bin > on the user's PATH (either doing so automatically or showing the user > how) so that setup.py-installed script would get on the PATH as well. > > Does the universal MacPython build do this or is it still the plan > to do > so? I was planning to move from using /usr/local/bin to the full > framework path in a future ActivePython. We do both at the moment: install symlinks in /usr/local/bin and make sure that the directory inside the framework is on $PATH by editing the shell profile of the user. Ronald > > Cheers, > Trent > > -- > Trent Mick > TrentM at ActiveState.com From ronaldoussoren at mac.com Mon Apr 10 23:43:35 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 10 Apr 2006 23:43:35 +0200 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support In-Reply-To: References: Message-ID: <66DABC4B-FAB5-4C26-92AB-ADDBFCB724D0@mac.com> On 10-apr-2006, at 23:21, Kent Quirk wrote: > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Monday, April 10, 2006 4:42 PM > To: Kent Quirk > Cc: Dethe Elza; G?bor Farkas; pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] needed: simple gui toolkit with > "japaneseinput" support > > > >>> I get the impression that for those who've used Cocoa and prefer >>> Python, it's a breath of fresh air...but for those who've not been >>> swimming in a vat of Cocoa, it's not quite so appetizing. > >> And to second Dethe: I'm also a python programmer that likes Cocoa. >> Heck, I wrote[1] PyObjC because I wanted to use Cocoa from Python. > > Which is kinda the point -- you already knew Cocoa and wanted to > use it in a different context. Mhhh, I'll have to do more proofreading before I sent out mail. I didn't know Cocoa when I wrote PyObjC, I wrote PyObjC because Cocoa seemed to be the best way to write OSX applications at the time (which was when OSX 10.0 was bleeding edge) and I prefer to program in Python. I actually learned Objective-C while writing PyObjC. > > I don't wish to argue about what's "really" easy or difficult about > Cocoa. I was trying to point out that people who don't use Cocoa > already, coming at it from Python, find several things about Cocoa > to be alien and difficult. And attempting to read and use Cocoa's > documentation requires that you already "get" Cocoa, and understand > the logic behind such things as two-stage object creation. Sadly enough that's also true for someone that tries to learn Objective-C for wring Ccooa programs. There's not much documentation that explains the right programming model for Cocoa applications, which means you'll often be stuck in increasingly complex code until you stumble across the way the framework designers intended you to write your code in the first place and most complexity disappears. > > I'm really not disparaging Cocoa at all as a development platform. > I'm merely trying to point out the impedance mismatch between it > and Python. Sometimes people forget how much they had to learn. For > people experienced in Cocoa and already familiar with it, the > similarities are far more important than the differences, and > PyObjC is a wonderful tool. But for users unfamiliar with Cocoa and > possibly unfamiliar with the Mac, the learning curve can be > formidable. > There's definitely a learning curve, but I don't think it is too steep and once you've climbed it you have a very powerfull framework to write native applications. I'm still amazed at how close the object models of Python and Objective-C/Cocoa are. Ronald From hengist.podd at virgin.net Mon Apr 10 23:45:39 2006 From: hengist.podd at virgin.net (has) Date: Mon, 10 Apr 2006 22:45:39 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <6CF594C0-BC49-4B80-AA30-D642B9F133A1@mac.com> References: <4BDE5848-6E5C-4066-B97F-746442985096@redivi.com> <6CF594C0-BC49-4B80-AA30-D642B9F133A1@mac.com> Message-ID: Ronald wrote: >>>I think you're totally mislead as to what IDLE does. Yes, it has interactive interpreters with a save feature, but it also edits source files and has a debugger. It IS conventional. >> >>Yep, you're right. I never use IDLE myself (it's a bizarre-looking beast [1] and I notice it doesn't run appscript either) so missed that bit. Go with the SE-like format then. > >It should do appscript in the universal build. Python 2.4.3/IDLE 1.1.3; appscript just raises a 'no window manager connection' in the interpreter window. Dunno why. >>[1] OT: I rather suspect IDLE's very un-Mac-like look and feel makes it more of a liability than an advantage in terms of attracting new users, but this is a different discussion for another time... > >Feel free to send patches to make IDLE's look&feel more mac-like :-). IDLE is all we've got at the moment. Indeed. And it would make a lovely little MacPython editor if only someone were willing and able to lavish lots of TLC on its UI. As I say, another discussion for another time - not dissing it, just noting that even the nicest of icons isn't going to solve all its problems. And I definitely don't have any time at the moment to contribute - still getting to grips with Cocoa, never mind learning Tk as well. I know my limits, and they suck. :p has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Mon Apr 10 23:58:50 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 10 Apr 2006 14:58:50 -0700 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support In-Reply-To: References: Message-ID: On Apr 10, 2006, at 2:21 PM, Kent Quirk wrote: > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Monday, April 10, 2006 4:42 PM > To: Kent Quirk > Cc: Dethe Elza; G?bor Farkas; pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] needed: simple gui toolkit with > "japaneseinput" support > > > >>> I get the impression that for those who've used Cocoa and prefer >>> Python, it's a breath of fresh air...but for those who've not been >>> swimming in a vat of Cocoa, it's not quite so appetizing. > >> And to second Dethe: I'm also a python programmer that likes Cocoa. >> Heck, I wrote[1] PyObjC because I wanted to use Cocoa from Python. > > Which is kinda the point -- you already knew Cocoa and wanted to > use it in a different context. > > I don't wish to argue about what's "really" easy or difficult about > Cocoa. I was trying to point out that people who don't use Cocoa > already, coming at it from Python, find several things about Cocoa > to be alien and difficult. And attempting to read and use Cocoa's > documentation requires that you already "get" Cocoa, and understand > the logic behind such things as two-stage object creation. > > I'm really not disparaging Cocoa at all as a development platform. > I'm merely trying to point out the impedance mismatch between it > and Python. Sometimes people forget how much they had to learn. For > people experienced in Cocoa and already familiar with it, the > similarities are far more important than the differences, and > PyObjC is a wonderful tool. But for users unfamiliar with Cocoa and > possibly unfamiliar with the Mac, the learning curve can be > formidable. There isn't an impedance mismatch between Python and Cocoa. The impedance mismatch is between Cocoa, which is largely declarative, and the other GUI frameworks, which are largely procedural. Python doesn't have any preconception about what a GUI is or how it should work (unless Tkinter counts for that, which it probably shouldn't), so there can't really be a logical impedance mismatch unless you're comparing it to some specific other GUI toolkit. Using wx or Qt brings lots of C++isms, using Tkinter brings lots of TCLisms, and using Cocoa brings Objective-Cisms. It just so happens that Objective-C and Python have very similar object models (more similar than the other choices), so there isn't really that much of an impedance mismatch there -- except for dynamically chosen selectors that happen to depend on non-object signatures. The impedance mismatch is so low in fact that PyObjC doesn't even know anything about GUIs either (unlike the other toolkits, which require a lot of wrapping), it just knows how to bridge the two language runtimes together in a practical way. -bob From bob at redivi.com Tue Apr 11 00:00:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 10 Apr 2006 15:00:28 -0700 Subject: [Pythonmac-SIG] Install location In-Reply-To: References: <20060410211403.GB18402@activestate.com> Message-ID: <8C28D640-DB87-492E-A9DD-2B1A78EDC34F@redivi.com> On Apr 10, 2006, at 2:29 PM, Ronald Oussoren wrote: > On 10-apr-2006, at 23:14, Trent Mick wrote: > >> The old (now deprecated) Mac "Python IDE.app" was never included in >> ActivePython. > > Good for you! I hope we can completely remove it for Python 2.5 > (and my > the universal build also doesn't install it) I'd bet they had to exclude it for licensing reasons anyway. >> There was discussion a while back to change the MacPython >> installer to >> NOT put symlinks in /usr/local/bin, but instead put the full >> /Library/Frameworks/Python.framework/Versions/2.4/bin >> on the user's PATH (either doing so automatically or showing the user >> how) so that setup.py-installed script would get on the PATH as well. >> >> Does the universal MacPython build do this or is it still the plan >> to do >> so? I was planning to move from using /usr/local/bin to the full >> framework path in a future ActivePython. > > We do both at the moment: install symlinks in /usr/local/bin and make > sure that the directory inside the framework is on $PATH by editing > the > shell profile of the user. Also note that both of these features are optional in the installer. -bob From trentm at ActiveState.com Tue Apr 11 00:11:07 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 10 Apr 2006 15:11:07 -0700 Subject: [Pythonmac-SIG] Install location In-Reply-To: <8C28D640-DB87-492E-A9DD-2B1A78EDC34F@redivi.com> References: <20060410211403.GB18402@activestate.com> <8C28D640-DB87-492E-A9DD-2B1A78EDC34F@redivi.com> Message-ID: <20060410221107.GA31273@activestate.com> [Bob Ippolito wrote] > > On Apr 10, 2006, at 2:29 PM, Ronald Oussoren wrote: > > >On 10-apr-2006, at 23:14, Trent Mick wrote: > > > >>The old (now deprecated) Mac "Python IDE.app" was never included in > >>ActivePython. > > > >Good for you! I hope we can completely remove it for Python 2.5 (and > >my the universal build also doesn't install it) > > I'd bet they had to exclude it for licensing reasons anyway. Huh? The main reason I didn't include "Python IDE" along with the waste libs was that they obviously were ancient, unmaintained and didn't provide near the functionality of other facilities (pyobjc instead of the waste stuff, IDLE and other free editors instead of Python IDE). Trent -- Trent Mick TrentM at ActiveState.com From wescpy at gmail.com Tue Apr 11 00:30:27 2006 From: wescpy at gmail.com (w chun) Date: Mon, 10 Apr 2006 15:30:27 -0700 Subject: [Pythonmac-SIG] wxPython book. First example misbehaves on my Mac ?? What's happening? In-Reply-To: References: Message-ID: <78b3a9580604101530i7343311dwef6d48f1e66d717a@mail.gmail.com> On 4/10/06, Charles Hartman wrote: > > And I think the shebang line at the beginning should be > #!/usr/bin/env pythonw > >> On Apr 10, 2006, at 3:21 PM, Opstad, Dave wrote: >> I think the return should be True, not true. the reason why you are seeing it just "flash" by is that the app is able to generate a GUI for you, but it is bombing out due to exceptions from "true". the shbang line may or may not be giving you problems (and seems to be working if you got a GUI frame), but it's best to take charles suggestion because then your app will work no matter where python(w) is. -- wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2007,2001 http://corepython.com wesley.j.chun :: wescpy-at-gmail.com python training and technical consulting cyberweb.consulting : silicon valley, ca http://cyberwebconsulting.com From bob at redivi.com Tue Apr 11 00:47:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 10 Apr 2006 15:47:00 -0700 Subject: [Pythonmac-SIG] Install location In-Reply-To: <20060410221107.GA31273@activestate.com> References: <20060410211403.GB18402@activestate.com> <8C28D640-DB87-492E-A9DD-2B1A78EDC34F@redivi.com> <20060410221107.GA31273@activestate.com> Message-ID: <31F63D0A-9BD1-44EB-AA50-856A4CDF3A52@redivi.com> On Apr 10, 2006, at 3:11 PM, Trent Mick wrote: > [Bob Ippolito wrote] >> >> On Apr 10, 2006, at 2:29 PM, Ronald Oussoren wrote: >> >>> On 10-apr-2006, at 23:14, Trent Mick wrote: >>> >>>> The old (now deprecated) Mac "Python IDE.app" was never included in >>>> ActivePython. >>> >>> Good for you! I hope we can completely remove it for Python 2.5 >>> (and >>> my the universal build also doesn't install it) >> >> I'd bet they had to exclude it for licensing reasons anyway. > > Huh? The main reason I didn't include "Python IDE" along with the > waste > libs was that they obviously were ancient, unmaintained and didn't > provide near the functionality of other facilities (pyobjc instead of > the waste stuff, IDLE and other free editors instead of Python IDE). Well, the WASTE license isn't all that friendly. I'd have thrown it out for that reason alone. -bob From bob at redivi.com Tue Apr 11 00:56:32 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 10 Apr 2006 15:56:32 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <4BDE5848-6E5C-4066-B97F-746442985096@redivi.com> <6CF594C0-BC49-4B80-AA30-D642B9F133A1@mac.com> Message-ID: <3E876250-555F-463F-BA5D-D65C8587255C@redivi.com> On Apr 10, 2006, at 2:45 PM, has wrote: > Ronald wrote: > >>>> I think you're totally mislead as to what IDLE does. Yes, it >>>> has interactive interpreters with a save feature, but it also >>>> edits source files and has a debugger. It IS conventional. >>> >>> Yep, you're right. I never use IDLE myself (it's a bizarre- >>> looking beast [1] and I notice it doesn't run appscript either) >>> so missed that bit. Go with the SE-like format then. >> >> It should do appscript in the universal build. > > Python 2.4.3/IDLE 1.1.3; appscript just raises a 'no window manager > connection' in the interpreter window. Dunno why. From an IDLE session: >>> import sys >>> sys.executable '/Applications/MacPython 2.4/IDLE.app/Contents/MacOS/Python' >>> import MacOS >>> MacOS.WMAvailable() False If you add a little hack like this to its startup script (or to bundlebuilder even), then it will work: import sys sys.executable = sys.prefix + '/bin/python' + sys.version[:3] >>> import sys >>> sys.executable '/Applications/MacPython 2.4/IDLE.app/Contents/MacOS/Python' >>> import MacOS >>> MacOS.WMAvailable() True I'm not sure why sys.executable is what it is in the subprocess, but WMAvailable does indeed work with that hack. -bob From delza at livingcode.org Tue Apr 11 01:12:19 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 10 Apr 2006 16:12:19 -0700 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support In-Reply-To: References: Message-ID: <24d517dd0604101612s74e893c0h3bc5af3e80766610@mail.gmail.com> On 4/10/06, Kent Quirk wrote: > > -----Original Message----- > From: Ronald Oussoren [mailto:ronaldoussoren at mac.com] > Sent: Monday, April 10, 2006 4:42 PM > To: Kent Quirk > Cc: Dethe Elza; G?bor Farkas; pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support > > > > >> I get the impression that for those who've used Cocoa and prefer > >> Python, it's a breath of fresh air...but for those who've not been > >> swimming in a vat of Cocoa, it's not quite so appetizing. > > >And to second Dethe: I'm also a python programmer that likes Cocoa. > >Heck, I wrote[1] PyObjC because I wanted to use Cocoa from Python. > > Which is kinda the point -- you already knew Cocoa and wanted to use it in a different context. Can't speak for Ronald (he's already spoken anyhow), but I learned Cocoa from Python. The most contact I've had with Objective-C is to port code from it into Python so that other folks coming to Cocoa from Python will have more examples to draw on. --Dethe From trentm at ActiveState.com Tue Apr 11 01:46:29 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 10 Apr 2006 16:46:29 -0700 Subject: [Pythonmac-SIG] Install location In-Reply-To: <31F63D0A-9BD1-44EB-AA50-856A4CDF3A52@redivi.com> References: <20060410211403.GB18402@activestate.com> <8C28D640-DB87-492E-A9DD-2B1A78EDC34F@redivi.com> <20060410221107.GA31273@activestate.com> <31F63D0A-9BD1-44EB-AA50-856A4CDF3A52@redivi.com> Message-ID: <20060410234629.GC4092@activestate.com> [Trent] > > ...the waste libs [are] obviously ancient, unmaintained > > and [don't] provide near the functionality of other facilities [Bob Ippolito wrote] > Well, the WASTE license isn't all that friendly. I'd have thrown it > out for that reason alone. Happy coincidence! :) Trent -- Trent Mick TrentM at ActiveState.com From saggau at gmail.com Tue Apr 11 05:12:21 2006 From: saggau at gmail.com (Saggau) Date: Mon, 10 Apr 2006 23:12:21 -0400 Subject: [Pythonmac-SIG] NSZombies eating my brain In-Reply-To: References: Message-ID: I'm instantiating afresh and adding my python object to the NSArray controller each time. It always crashes on the second addition with the NSZombie problem. Output of malloc_history on my NSZombie: superbadpbook:~ jonathan$ malloc_history 506 0x1147cb0 Call [2] [arg=12]: thread_a000ed98 |0x0 | _dyld_start | 0x2414 | 0x3e50 | 0x3db0 | PyRun_SimpleFileExFlags | PyRun_FileExFlags | PyEval_EvalCode | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | _PyUnicodeUCS2_IsAlpha | PyRun_FileExFlags | PyEval_EvalCode | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | objc_NSApplicationMain | NSApplicationMain | +[NSBundle(NSNibLoading) loadNibNamed:owner:] | +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] | +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] | loadNib | -[NSKeyedUnarchiver initForReadingWithData:] | _CFPropertyListCreateFromXMLData | parsePListTag | parseDictTag | parseArrayTag | parseDictTag | parseDictTag | _CFKeyedArchiverUIDCreate | _CFRuntimeCreateInstance | CFAllocatorAllocate Call [4] [arg=0]: thread_a000ed98 |0x0 | _dyld_start | 0x2414 | 0x3e50 | 0x3db0 | PyRun_SimpleFileExFlags | PyRun_FileExFlags | PyEval_EvalCode | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | _PyUnicodeUCS2_IsAlpha | PyRun_FileExFlags | PyEval_EvalCode | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | objc_NSApplicationMain | NSApplicationMain | +[NSBundle(NSNibLoading) loadNibNamed:owner:] | +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] | +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] | loadNib | -[NSKeyedUnarchiver dealloc] | _CFRelease | __CFArrayDeallocate | __CFArrayReleaseValues | _CFRelease | __CFDictionaryDeallocate | _CFRelease Call [2] [arg=12]: thread_a000ed98 |0x0 | _dyld_start | 0x2414 | 0x3e50 | 0x3db0 | PyRun_SimpleFileExFlags | PyRun_FileExFlags | PyEval_EvalCode | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | _PyUnicodeUCS2_IsAlpha | PyRun_FileExFlags | PyEval_EvalCode | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | objc_NSApplicationMain | NSApplicationMain | -[NSApplication run] | -[NSApplication sendEvent:] | -[NSWindow sendEvent:] | -[NSControl mouseDown:] | -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] | -[NSCell trackMouse:inRect:ofView:untilMouseUp:] | -[NSCell _sendActionFrom:] | -[NSControl sendAction:to:] | -[NSApplication sendAction:to:from:] | ffi_closure_ASM | ffi_closure_helper_DARWIN | method_stub | PyObject_Call | pysel_call | PyObject_Call | PyFunction_SetClosure | PyEval_EvalCodeEx | PyEval_EvalCode | PyEval_GetFuncDesc | PyEval_GetFuncDesc | PyObject_Call | objcsel_call | PyObjCFFI_Caller | ffi_call | ffi_call_DARWIN | -[NSArrayController _insertObject:atArrangedObjectIndex:objectHandler:] | -[NSArrayController didChangeValuesForArrangedKeys:objectKeys:indexKeys:] | -[NSController _notifyObserversForKeyPath:change:] | -[NSObject(NSKeyValueObservingPrivate) _notifyObserversForKeyPath:change:] | -[NSSelectionBinder observeValueForKeyPath:ofObject:change:context:] | -[NSValueBinder _observeValueForKeyPath:ofObject:context:] | -[NSSelectionBinder _adjustObject:mode:observedController:observedKeyPath:context:editableState:adjustState:] | -[NSSelectionBinder _valueForBindingWithoutResolve:mode:] | -[NSBinder valueForBinding:resolveMarkersToPlaceholders:] | -[NSBinder _valueForKeyPath:ofObject:mode:raisesForNotApplicableKeys:] | -[NSObject(NSKeyValueCoding) valueForKeyPath:] | -[NSArrayController _singleValueForKeyPath:] | -[NSObject(NSKeyValueCoding) valueForKeyPath:] | ffi_closure_ASM | ffi_closure_helper_DARWIN | object_method_valueForKey_ | _NSGetUsingKeyValueGetter | ffi_closure_ASM | ffi_closure_helper_DARWIN | method_stub | depythonify_c_return_value | depythonify_c_value | +[OC_PythonObject wrapPyObject:toId:] | +[OC_PythonArray newWithPythonObject:] | NSAllocateObject | _internal_class_createInstanceFromZone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060410/d27a5340/attachment.htm From dan at chalkie.org.uk Tue Apr 11 08:55:17 2006 From: dan at chalkie.org.uk (Dan White) Date: Tue, 11 Apr 2006 09:55:17 +0300 Subject: [Pythonmac-SIG] py2app - apple gcc4.0.1 - universal binaries - problems and questions In-Reply-To: References: Message-ID: <5B79132E-EBC4-412B-9C82-6657C4429F44@chalkie.org.uk> Dear Bob Zac and all, We are trying to use py2app to make a OSX .app (preferably universal) of our open source biomedical imaging software, BioImageXD. see http://www.bioimagexd.org for the source code I have a working source code version on a G5 machine, but I am having trouble getting a working .app using py2app. first a little background. BioImageXD is written in python (of course!) and uses wxPython for the GUI. however it relies heavily on the open source Visual?isation Toolkit (VTK) which is written in C++ and has python wrappings so the libs are available to python. We are using a customised version of VTK, not the one you can download, that fixes some specific problems of ours, so we have to compile our own versions of the shared libraries on OSX , linux and windows . questions/problems 1) I run py2app with the python code below, but it fails to launch... get to the splash screen then complains about : "BioImageXD error an unexpected error has occurred during execution of the main script." So we are still failing to add all the required dependencies... but I cant see how to fix it...? any clues? 2) how can I make a universal binary? We compile VTK C++ code using cmake and apple gcc 4.0.1. Can I get apple gcc to make universal binaries, which will then work with a universal binary python and py2app? How would I do that? What about the architecture specific compiler flags? Can I just use -fast to get optimization for intel and ppc architectures in the same universal binary? I dont know how to approach this problem. Are there some gcc compiler flags I need to use to generate universal binary shared libraries? Or do I have to make ppc and intel libraries, then lipo them together? What is the best way to make a universal binaries without using Xcode, and have py2app turn them into a universal binary BioImageXD.app application bundle? (Can I do it without using X code? Can python work with C++ in Xcode?) Your help and wisdom would be greatly appreciated! cheers Dan White - bioImageXD team Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From design at kenichiyoshida.jp Mon Apr 10 09:06:11 2006 From: design at kenichiyoshida.jp (kenichi yoshida) Date: Mon, 10 Apr 2006 16:06:11 +0900 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr8.143748pdt."58633"@synergy1.parc.xerox.com> References: <06Apr8.143748pdt."58633"@synergy1.parc.xerox.com> Message-ID: Hi all, Bill, I'm Kenichi Yoshida, an interface icon designer for OS X. Nice to meet you! > Andrew Clover's icons have the virtue of doing this: http:// > www.doxdesk.com/img/software/py/icons.png Very nice design :D. However, these icons for OS X? This ignores Apple Human Interface Guidelines. It won't match Macintosh desktop. A Macintosh user usually worries about the design in comparison with the user of other platforms. So we should make the MacPython icon like a OS X more. Do you hope that we make the MacPython icon by using the new logo? Thanks a lot, Kenichi Yoshida Photo-illustrative style icon design for Mac OS X www.kenichiyoshida.jp From portmgr at sbcglobal.net Mon Apr 10 13:15:30 2006 From: portmgr at sbcglobal.net (Mark Maly) Date: Mon, 10 Apr 2006 04:15:30 -0700 (PDT) Subject: [Pythonmac-SIG] Help Message-ID: <20060410111530.77678.qmail@web80226.mail.yahoo.com> I am new to Python and find it fascinating but am having a difficult time finding out how to install it on my imac system. My operating system is Mac OSX 10.4. Any suggestion for a newbie? Many thanks. Mark From toddobryan at mac.com Tue Apr 11 12:48:01 2006 From: toddobryan at mac.com (Todd O'Bryan) Date: Tue, 11 Apr 2006 06:48:01 -0400 Subject: [Pythonmac-SIG] Help In-Reply-To: <20060410111530.77678.qmail@web80226.mail.yahoo.com> References: <20060410111530.77678.qmail@web80226.mail.yahoo.com> Message-ID: www.python.org Find the Universal Mac OSX binary and install it. That's about it. Todd On Apr 10, 2006, at 7:15 AM, Mark Maly wrote: > I am new to Python and find it fascinating but am having a > difficult time finding out how to > install it on my imac system. My operating system is Mac OSX 10.4. > Any suggestion for a newbie? > > Many thanks. > > Mark > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From charles.hartman at conncoll.edu Tue Apr 11 13:31:53 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 11 Apr 2006 07:31:53 -0400 Subject: [Pythonmac-SIG] Help In-Reply-To: References: <20060410111530.77678.qmail@web80226.mail.yahoo.com> Message-ID: <2DD4AE8B-2874-4E9F-B85D-2B5CA7270060@conncoll.edu> --unless you want to write cross-platform-capable GUI programs. Then you're best off using wxPython, which isn't available as Universal yet, though probably soon. So for the moment, the current non-Universal (PPC) 2.4 is the more prudent bet. Charles Hartman On Apr 11, 2006, at 6:48 AM, Todd O'Bryan wrote: > www.python.org > > Find the Universal Mac OSX binary and install it. That's about it. > > Todd > > On Apr 10, 2006, at 7:15 AM, Mark Maly wrote: > >> I am new to Python and find it fascinating but am having a >> difficult time finding out how to >> install it on my imac system. My operating system is Mac OSX 10.4. >> Any suggestion for a newbie? >> >> Many thanks. >> >> Mark >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From pecora at anvil.nrl.navy.mil Tue Apr 11 14:50:37 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Tue, 11 Apr 2006 08:50:37 -0400 Subject: [Pythonmac-SIG] Help In-Reply-To: References: <20060410111530.77678.qmail@web80226.mail.yahoo.com> Message-ID: <443BA61D.1040506@anvil.nrl.navy.mil> > >> I am new to Python and find it fascinating but am having a >> difficult time finding out how to >> install it on my imac system. My operating system is Mac OSX 10.4. >> Any suggestion for a newbie? >> >> Many thanks. >> >> Mark >> _______________________________________________ >> First, you already have Python on your computer. Apple put it there in OS X (open a Terminal and type python, return and you're in. Try it out). But you probably want to put in a later version. However, DO NOT REMOVE THE APPLE VERSION. It will not be replaced. Another, newer python will be added in another folder. Check out these sites for more information (Do read the FAQ so you know how to really set things up): http://pythonmac.org/packages/ (go to Universal Packages), http://pythonmac.org/wiki/FAQ (take time to read it over and follow some other links to get the idea of how to set up and run Python on your Mac -- there are several approaches and many are free). -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From hengist.podd at virgin.net Tue Apr 11 15:25:22 2006 From: hengist.podd at virgin.net (has) Date: Tue, 11 Apr 2006 14:25:22 +0100 Subject: [Pythonmac-SIG] needed: simple gui toolkit with "japaneseinput" support Message-ID: Dethe Elza wrote: >Kent Quirk > > Which is kinda the point -- you already knew Cocoa and wanted to use it in a different context. > >Can't speak for Ronald (he's already spoken anyhow), but I learned >Cocoa from Python. Ditto here (art school graduate and self-taught coder, btw). I'm familiar with assembling GUI widgets via drag-n-drop (the easy bit) in IB from having used AppleScript Studio a bit, and I know just enough C that I can look at ObjC code and work out what it does when I need to. Plus I already understood basic MVC theory before I started, which is a good idea if you're building anything fancy, though this is the first time I've seriously put it into practice. However, in terms of learning how to define View-Controller connections in IB and learning the Cocoa APIs and design patterns I've done all that while in Python+PyObjC. Took me two whole days to wrap my mind around actions, outlets and custom classes in IB and how those related to the code I wrote in my .py files. But I'm relatively slow on the uptake, and once I cracked it I found it quite easy to work with and certainly preferable to writing View code by hand. The rest I've been picking up along the way as needed (AppKiDo rocks!:): creating my own NSDocument subclasses; shifting controller code into NSWindowController subclasses; using NSNotificationCenter to handle Model->Controller communication according to MVC rules; adding window toolbars, drawers, split-views, etc. I've a copy of Hillegass kicking around, but so far I've only looked up a few things in the index; mostly I just pull apart the existing PyObjC examples and learn from those. While it would be nice if there was a gentler, hand-holding environment like FaceSpan specifically for novice and lightweight users [1][2], Python+Cocoa really isn't too bad once you get over the initial intimidation. I put off learning Cocoa for a year or two worrying about how hard it would be, but once I sat down and spent a week or so with it it I found it was actually far less scary as I'd imagined it would be. Like most big application frameworks it just takes a little time and patience to find your bearings. The only real up-front requirements is that you need to be comfortable with object-oriented design and programming and can follow other peoples' abstractions. HTH has [1] Incidentally, while the current version of FaceSpan doesn't support third-party (i.e. not AppleScript) OSA languages, I believe the next version probably will - meaning you could write FaceSpan-based apps in a variety of languages. The only catch is that there isn't a really good, complete Python OSA component available yet (though there's a couple of potential candidates). [2] AppleScript Studio should be able to use an alternative OSA language with a little judicious hacking, although the Studio APIs are a bit crap anyway (more a poor man's version of Cocoa than a next-generation HyperCard) so I'm not sure you'd be better off with that than PyObjC. Though again, until there's a suitable Python OSA component this is all academic anyway. -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Tue Apr 11 15:25:52 2006 From: hengist.podd at virgin.net (has) Date: Tue, 11 Apr 2006 14:25:52 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <06Apr8.143748pdt."58633"@synergy1.parc.xerox.com> Message-ID: Kenichi Yoshida wrote: >>Andrew Clover's icons have the virtue of doing this: http:// www.doxdesk.com/img/software/py/icons.png > >Very nice design :D. > >However, these icons for OS X? Windows. >Do you hope that we make the MacPython icon by using the new logo? There's still some debate on this list on whether to use the official Python logo or do something different, but I think on balance folk are moving towards the official logo. I've been making my own notes on what's required along with my own recommendations on how they should be presented; I've included these below but they obviously aren't final or agreed upon so are folks' info only. Cheers, has ------- MacPython 2.5 Icon Design Requirements Main goals: - reinforce brand identity (i.e. use the official Python logo) - clearly indicate function (an editor should look like an editor, an editable document like an editable document, and so on) Misc. notes: - Python is a tool/utility, so apart for the blue/yellow Python logo itself icons should keep colour to a minimum as-per HIG. Icon family: IDLE.app application - a text-based script editor for Python. I'd suggest something similar to Script Editor.app, except using the Python logo and a different style of pen (e.g. technical drawing pen/pencil) of course. .py/.pyw files - Python source code document, editable and executable; the 'normal' file format used by Python scripters. I'd suggest something similar to AppleScript .scpt files, except using the Python logo .pyc/.pyo files - Python binary code document, executable but non-editable (should be similar to .py/.pyw icon, exept indicating binary content); these are mostly auto-generated by Python for efficiency. I'd suggest a variation of the .py icon that indicated binary content, e.g. a light backdrop of rows of random 1s and 0s, or a word like '011010', 'byte' or 'data' in its lower half. BuildApplet.app application - a drag-n-drop converter that turns Python code files into standalone double-clickable applications. A DropStuff.app-style grinder (which is what the old icon uses) is certainly one option. applet applications - applets created by Build Applet.app should be given a generic 'Python-based applet' icon by default. Probably use something similar to the AppleScript applets created by Script Editor.app. PythonLauncher.app application - a drag-n-drop script runner. Possibly use something similar to the Applet Launcher.app for Java. ------- -- http://freespace.virgin.net/hamish.sanderson/ From janssen at parc.com Tue Apr 11 18:13:01 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 11 Apr 2006 09:13:01 PDT Subject: [Pythonmac-SIG] Help In-Reply-To: Your message of "Tue, 11 Apr 2006 04:31:53 PDT." <2DD4AE8B-2874-4E9F-B85D-2B5CA7270060@conncoll.edu> Message-ID: <06Apr11.091311pdt."58633"@synergy1.parc.xerox.com> > --unless you want to write cross-platform-capable GUI programs. Then > you're best off using wxPython, which isn't available as Universal > yet, though probably soon. Or Jython with Swing (my personal choice for portable GUIs). Bill From pecora at anvil.nrl.navy.mil Tue Apr 11 23:43:20 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Tue, 11 Apr 2006 17:43:20 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. Message-ID: <443C22F8.3080706@anvil.nrl.navy.mil> I bought the wxPython in Action book and started trying the simple examples in Chap. 1. One thing I have run into is rather disappointing. Many errors (e.g. I typed return true, instead of return True) do not give the beloved Python tracback. That's one of the nice things that made me choose Python. Somehow once the app is launched if there is a bug it just quits without any information. I am now struggling to find out why example 3 (hello.py) won't work. I've been over it dozens of times checking indentation, spelling, etc. But the app never gets into OnInit (determined by the old fashion way of putting print's into the program at strategic stages). A window flashes open and then disappears. Process exited in the terminal. How are others using wxPython? Do you find you need to run in a debugger? Does that help? What do you recommend? Thanks for any suggestions. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From saggau at gmail.com Wed Apr 12 01:53:53 2006 From: saggau at gmail.com (Saggau) Date: Tue, 11 Apr 2006 19:53:53 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443C22F8.3080706@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> Message-ID: are you running your scripts with pythonw from the command line? On 4/11/06, Louis Pecora wrote: > > I bought the wxPython in Action book and started trying the simple > examples in Chap. 1. One thing I have run into is rather > disappointing. Many errors (e.g. I typed return true, instead of return > True) do not give the beloved Python tracback. That's one of the nice > things that made me choose Python. Somehow once the app is launched if > there is a bug it just quits without any information. I am now > struggling to find out why example 3 (hello.py) won't work. I've been > over it dozens of times checking indentation, spelling, etc. But the > app never gets into OnInit (determined by the old fashion way of putting > print's into the program at strategic stages). A window flashes open > and then disappears. Process exited in the terminal. > > How are others using wxPython? Do you find you need to run in a > debugger? Does that help? What do you recommend? > > Thanks for any suggestions. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality. - Harry Partch There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060411/70aa1643/attachment.html From daniellord at mac.com Wed Apr 12 01:54:02 2006 From: daniellord at mac.com (Daniel Lord) Date: Tue, 11 Apr 2006 16:54:02 -0700 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443C22F8.3080706@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> Message-ID: Personally I am with Bill, I like Jython but it unfortunately has fallen way behind in Python versions. But it has teh advantage that Java is supported on all main 'cross' platforms. On Apr 11, 2006, at 14:43, Louis Pecora wrote: > I bought the wxPython in Action book and started trying the simple > examples in Chap. 1. One thing I have run into is rather > disappointing. Many errors (e.g. I typed return true, instead of > return > True) do not give the beloved Python tracback. That's one of the nice > things that made me choose Python. Somehow once the app is > launched if > there is a bug it just quits without any information. I am now > struggling to find out why example 3 (hello.py) won't work. I've been > over it dozens of times checking indentation, spelling, etc. But the > app never gets into OnInit (determined by the old fashion way of > putting > print's into the program at strategic stages). A window flashes open > and then disappears. Process exited in the terminal. > > How are others using wxPython? Do you find you need to run in a > debugger? Does that help? What do you recommend? > > Thanks for any suggestions. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From charles.hartman at conncoll.edu Wed Apr 12 02:03:25 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 11 Apr 2006 20:03:25 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443C22F8.3080706@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> Message-ID: <57663A56-2BA5-4A63-856C-943D4DDD50DB@conncoll.edu> If I recall correctly, this syndrome is covered in the book. It happens because the diagnostic's going to a window that closes when the app does. Look up wx.App(redirect=True) in the index -- you can write the diagnostic to a file and examine it at leisure. Sorry, I'm doing this from memory so the details are hazy. Charles Hartman On Apr 11, 2006, at 5:43 PM, Louis Pecora wrote: > I bought the wxPython in Action book and started trying the simple > examples in Chap. 1. One thing I have run into is rather > disappointing. Many errors (e.g. I typed return true, instead of > return > True) do not give the beloved Python tracback. That's one of the nice > things that made me choose Python. Somehow once the app is > launched if > there is a bug it just quits without any information. I am now > struggling to find out why example 3 (hello.py) won't work. I've been > over it dozens of times checking indentation, spelling, etc. But the > app never gets into OnInit (determined by the old fashion way of > putting > print's into the program at strategic stages). A window flashes open > and then disappears. Process exited in the terminal. > > How are others using wxPython? Do you find you need to run in a > debugger? Does that help? What do you recommend? > > Thanks for any suggestions. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From saggau at gmail.com Wed Apr 12 02:31:46 2006 From: saggau at gmail.com (Saggau) Date: Tue, 11 Apr 2006 20:31:46 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443C4514.9030305@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> Message-ID: Charles is right: http://www.wxpython.org/docs/api/wx.App-class.html Have you looked at boa-constructor on sourceforge? boa-constructor.sourceforge.net I used to use it when I was a bigger-than-I-am-now linux geek and found it quite useful for building one-off gui toys. I found the learning curve more bearable using it. Cheers, Jonathan On 4/11/06, Louis Pecora wrote: > > Saggau wrote: > > are you running your scripts with pythonw from the command line? > > > > I'm running with pythonw from BBEdit although I have tried the command > line, too. Same behavior. I run other scripts no problem this way > including other wxPython examples I got on the web earlier. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > -- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality. - Harry Partch There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060411/15666e72/attachment.html From kevino at theolliviers.com Wed Apr 12 02:44:21 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Tue, 11 Apr 2006 17:44:21 -0700 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443C22F8.3080706@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> Message-ID: Hi Louis, On Apr 11, 2006, at 2:43 PM, Louis Pecora wrote: > I bought the wxPython in Action book and started trying the simple > examples in Chap. 1. One thing I have run into is rather > disappointing. Many errors (e.g. I typed return true, instead of > return > True) do not give the beloved Python tracback. That's one of the nice > things that made me choose Python. Somehow once the app is > launched if > there is a bug it just quits without any information. I am now > struggling to find out why example 3 (hello.py) won't work. I've been > over it dozens of times checking indentation, spelling, etc. But the > app never gets into OnInit (determined by the old fashion way of > putting > print's into the program at strategic stages). A window flashes open > and then disappears. Process exited in the terminal. Have you checked if there's anything in /Applications/Utilities/ Console.app? If you run scripts by double-clicking them in the Finder, that's where the output should be going. Regards, Kevin > How are others using wxPython? Do you find you need to run in a > debugger? Does that help? What do you recommend? > > Thanks for any suggestions. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From woklist at kyngchaos.com Wed Apr 12 03:46:08 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue, 11 Apr 2006 20:46:08 -0500 Subject: [Pythonmac-SIG] weak-link libraries problem Message-ID: I just ran into an odd and annoying problem - I'm building a Python library/extension thing for a package (MapServer) and have a library weak-linked (it's to a non-open source product, this is so others don't have to install that if they don't need it and I don't have to build multiple versions...). Python's import seems to ignore that, I suspect it's doing it's own library loading thing and checking all symbols or something. Is this normal? Is there a way to make Python NOT do it? Or am I stuck with it? ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From bob at redivi.com Wed Apr 12 04:24:39 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 11 Apr 2006 19:24:39 -0700 Subject: [Pythonmac-SIG] weak-link libraries problem In-Reply-To: References: Message-ID: On Apr 11, 2006, at 6:46 PM, William Kyngesburye wrote: > I just ran into an odd and annoying problem - I'm building a Python > library/extension thing for a package (MapServer) and have a library > weak-linked (it's to a non-open source product, this is so others > don't have to install that if they don't need it and I don't have to > build multiple versions...). Python's import seems to ignore that, I > suspect it's doing it's own library loading thing and checking all > symbols or something. > > Is this normal? Is there a way to make Python NOT do it? Or am I > stuck with it? I'm not entirely sure, I haven't tried it. It uses these NSModule flags to load extensions: NSLINKMODULE_OPTION_BINDNOW NSLINKMODULE_OPTION_RETURN_ON_ERROR NSLINKMODULE_OPTION_PRIVATE I don't believe that any of those options would defeat weak linking, though. You might have to find the library at runtime with the dyld or dl APIs and it use that way. Or strong-link to it in a separate extension that's only loaded if the library is detected. -bob From saggau at gmail.com Wed Apr 12 04:54:41 2006 From: saggau at gmail.com (Saggau) Date: Tue, 11 Apr 2006 22:54:41 -0400 Subject: [Pythonmac-SIG] weak-link libraries problem In-Reply-To: References: Message-ID: One way to say what I'm thinking: There might be another way around this. It's another way of using two modules, which might not be desirable, but not quite the "two versions of the same thing, one with expanded functionality" type. Instead, it's "Two different (and more basic/plain-Jane) library wrappers, one wrapping just the third party code functionality and one wrapping just my code functionality." You can then test for the existence of the third party code wrapper module and make your python code behave accordingly. Another way: You could build one wrapper module that is only the third party stuff and one that is only your code. Then you could use two imports in your python code, setting a variable or just testing whether to use the "with extras" version of your python code or the "stripped down" version. That way, you can ship either load both bundles or the one bundle depending on what the user's system has. Am I making any sense? I suspect not. the Pseudo-broken pythonic way to say it: #sorta try: import MyThirdPartyModuleWrapper #corresponding to MyThirdPartyModule.so import MyPythonCodeThatUsesTheThirdPartyModuleWrapper as MyPythonCode except ImportError: import MyPythonCodeThatDoesntUseTheThirdPartyModule as MyPythonCode in both MyPythonCodeThatDoesntUseTheThirdPartyModule.py and MyPythonCodeThatUsesTheThirdPartyModuleWrapper.py you would: #sorta import MyCodeThatIsntThirdParty #corresponding to MyCodeThatIsntThirdParty.so My-big-architectural-question (TM) is: If you know you're either going to have to deal with ifndef etc etc in your big module code or the equivalent test to see if the little third party module is loaded in your python code. Either way, you'll have to adjust what you're doing somewhere in code. I have found, with the caveat that I have limited experience with this, that writing multiple very simple and low-level loadable bundles / libraries with a thimbleful of functionality in each and letting python be happily dynamic about what gets imported is easier than trying to do the "I need to test if I can use this library or not" in a big loadable bundle / library. In other words, I know where I would rather write my most dynamic code. Python. :) It's just easier to do there and I'm lazy. Cheers, Jonathan Saggau PS - This is the really long version of what Bob just said here: "Or strong-link to it in a separate extension that's only loaded if the library is detected." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060411/7bede781/attachment-0001.html From woklist at kyngchaos.com Wed Apr 12 06:25:37 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue, 11 Apr 2006 23:25:37 -0500 Subject: [Pythonmac-SIG] weak-link libraries problem In-Reply-To: References: Message-ID: <2F0A62E9-FD0B-436C-9B8A-23894B6DD77D@kyngchaos.com> On Apr 11, 2006, at 9:24 PM, Bob Ippolito wrote: > > On Apr 11, 2006, at 6:46 PM, William Kyngesburye wrote: > >> I just ran into an odd and annoying problem - I'm building a Python >> library/extension thing for a package (MapServer) and have a library >> weak-linked (it's to a non-open source product, this is so others >> don't have to install that if they don't need it and I don't have to >> build multiple versions...). Python's import seems to ignore that, I >> suspect it's doing it's own library loading thing and checking all >> symbols or something. >> >> Is this normal? Is there a way to make Python NOT do it? Or am I >> stuck with it? > > I'm not entirely sure, I haven't tried it. It uses these NSModule > flags to load extensions: > NSLINKMODULE_OPTION_BINDNOW > NSLINKMODULE_OPTION_RETURN_ON_ERROR > NSLINKMODULE_OPTION_PRIVATE > > I don't believe that any of those options would defeat weak > linking, though. > > You might have to find the library at runtime with the dyld or dl > APIs and it use that way. Or strong-link to it in a separate > extension that's only loaded if the library is detected. > It would be nice if MapServer had a simple plugin mechanism. It's supposedly there, just not documented yet. On Apr 11, 2006, at 9:54 PM, Saggau wrote: > One way to say what I'm thinking: > > There might be another way around this. It's another way of using > two modules, which might not be desirable, but not quite the "two > versions of the same thing, one with expanded functionality" type. > Instead, it's "Two different (and more basic/plain-Jane) library > wrappers, one wrapping just the third party code functionality and > one wrapping just my code functionality." You can then test for > the existence of the third party code wrapper module and make your > python code behave accordingly. > > Another way: > > You could build one wrapper module that is only the third party > stuff and one that is only your code. Then you could use two > imports in your python code, setting a variable or just testing > whether to use the "with extras" version of your python code or the > "stripped down" version. That way, you can ship either load both > bundles or the one bundle depending on what the user's system has. > Am I making any sense? I suspect not. > I understand what you're saying, I'm just not enough of a programmer to do such a thing. > My-big-architectural-question (TM) is: > > If you know you're either going to have to deal with ifndef etc etc > in your big module code or the equivalent test to see if the little > third party module is loaded in your python code. Either way, > you'll have to adjust what you're doing somewhere in code. I have > found, with the caveat that I have limited experience with this, > that writing multiple very simple and low-level loadable bundles / > libraries with a thimbleful of functionality in each and letting > python be happily dynamic about what gets imported is easier than > trying to do the "I need to test if I can use this library or not" > in a big loadable bundle / library. > > In other words, I know where I would rather write my most dynamic > code. Python. :) It's just easier to do there and I'm lazy. > For those that use the python version of MapServer, they would not use the functionality in their python code of the extra optional external library if they don't need it. I know, kinda fragile. But it works well enough in the CGI and PHP versions. I guess I should just figure out the MapServer plugin thing. I was hoping I could wait until some documentation was written. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From charles.hartman at conncoll.edu Wed Apr 12 13:53:52 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 12 Apr 2006 07:53:52 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. References: <9678D558-27DA-4204-9C53-F27C9F87A11B@conncoll.edu> Message-ID: <13DDA92B-D38C-42C0-B342-9AC9B60CC3FE@conncoll.edu> (sorry -- I meant to post this to the list) Begin forwarded message: > From: Charles Hartman > Date: April 12, 2006 7:23:20 AM EDT > To: Louis Pecora > Subject: Re: [Pythonmac-SIG] wxPython -- some disappointment using it. > > For some notes on errata in the book, and some helpful discussion > of particular questions, you might want to go to > > http://www.manning-sandbox.com/forum.jspa?forumID=202 > > Charles Hartman > > > > On Apr 11, 2006, at 8:10 PM, Louis Pecora wrote: > >> Charles Hartman wrote: >>> If I recall correctly, this syndrome is covered in the book. It >>> happens because the diagnostic's going to a window that closes >>> when the app does. Look up wx.App(redirect=True) in the index -- >>> you can write the diagnostic to a file and examine it at leisure. >>> Sorry, I'm doing this from memory so the details are hazy. >>> >>> Charles Hartman >>> >> >> Ah, good info. Thanks! >> -- >> Cheers, >> >> Lou Pecora >> >> Code 6362 >> Naval Research Lab >> Washington, DC 20375 >> USA >> Ph: +202-767-6002 >> email: pecora at anvil.nrl.navy.mil >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060412/17de31a4/attachment.html From pecora at anvil.nrl.navy.mil Wed Apr 12 15:15:42 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 12 Apr 2006 09:15:42 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> Message-ID: <443CFD7E.5060306@anvil.nrl.navy.mil> Saggau wrote: > Charles is right: > http://www.wxpython.org/docs/api/wx.App-class.html > > Have you looked at boa-constructor on sourceforge? > boa-constructor.sourceforge.net > > I used to use it when I was a bigger-than-I-am-now linux geek and > found it quite useful for building one-off gui toys. I found the > learning curve more bearable using it. > > Cheers, > Jonathan > Thanks for the link and the hint on boa. I've heard of the latter, but never looked into it. I really do numerical calcs, but occasionally need a simple GUI dialog or open a window to plot in (very simple), but who knows, boa might be the ticket. Thanks, again. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From pecora at anvil.nrl.navy.mil Wed Apr 12 15:28:27 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 12 Apr 2006 09:28:27 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: References: <443C22F8.3080706@anvil.nrl.navy.mil> Message-ID: <443D007B.6030509@anvil.nrl.navy.mil> Kevin Ollivier wrote: > Hi Louis, > > On Apr 11, 2006, at 2:43 PM, Louis Pecora wrote: > >> I bought the wxPython in Action book and started trying the simple >> examples in Chap. 1. One thing I have run into is rather >> disappointing. Many errors (e.g. I typed return true, instead of return >> True) do not give the beloved Python tracback. That's one of the nice >> things that made me choose Python. Somehow once the app is launched if >> there is a bug it just quits without any information. I am now >> struggling to find out why example 3 (hello.py) won't work. I've been >> over it dozens of times checking indentation, spelling, etc. But the >> app never gets into OnInit (determined by the old fashion way of putting >> print's into the program at strategic stages). A window flashes open >> and then disappears. Process exited in the terminal. > > Have you checked if there's anything in > /Applications/Utilities/Console.app? If you run scripts by > double-clicking them in the Finder, that's where the output should be > going. > > Regards, > > Kevin > I'm running from BBEdit. Someone else pointed me to the link that showed how to do a redirect output. When I did that I got the traceback. I wish there were a way to keep the popup window with the traceback info open, but it quickly closes and the app quits. Redirecting found the error, but it is an extra step. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From pecora at anvil.nrl.navy.mil Wed Apr 12 15:34:40 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 12 Apr 2006 09:34:40 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <5B5D099F-32DD-4608-901D-4CD265821205@ijuggle5.com> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <5B5D099F-32DD-4608-901D-4CD265821205@ijuggle5.com> Message-ID: <443D01F0.3050500@anvil.nrl.navy.mil> Mark Thalman wrote: > Louis, > > If you don't need cross-platform compatibility, why not use EasyDialogs? > > http://python.org/doc/2.4.1/mac/module-EasyDialogs.html > Yes, I've messed with them a little. Really very nice ... and tempting. I'm on the fence. I got this wxPython book and it looks cool, but I really don't need full-blown GUI apps, but then I may look into boa... too many choices. :-) But that's a good thing. Sometimes. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From charles.hartman at conncoll.edu Wed Apr 12 15:39:04 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 12 Apr 2006 09:39:04 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443D007B.6030509@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443D007B.6030509@anvil.nrl.navy.mil> Message-ID: It occurs to me that if you added an OnExit() handler to your app -- any app that's giving quit-too-soon trouble. The handler could simply put up a wx.MessageBox, which gets an OK from the user. This would pause the app on the way out, and therefore permit the normal app output window (without changing redirection) to stay onscreen as long as one liked. A little baroque, but pretty easy. Charles Hartman On Apr 12, 2006, at 9:28 AM, Louis Pecora wrote: > Kevin Ollivier wrote: >> Hi Louis, >> >> On Apr 11, 2006, at 2:43 PM, Louis Pecora wrote: >> >>> I bought the wxPython in Action book and started trying the simple >>> examples in Chap. 1. One thing I have run into is rather >>> disappointing. Many errors (e.g. I typed return true, instead of >>> return >>> True) do not give the beloved Python tracback. That's one of the >>> nice >>> things that made me choose Python. Somehow once the app is >>> launched if >>> there is a bug it just quits without any information. I am now >>> struggling to find out why example 3 (hello.py) won't work. I've >>> been >>> over it dozens of times checking indentation, spelling, etc. But >>> the >>> app never gets into OnInit (determined by the old fashion way of >>> putting >>> print's into the program at strategic stages). A window flashes >>> open >>> and then disappears. Process exited in the terminal. >> >> Have you checked if there's anything in >> /Applications/Utilities/Console.app? If you run scripts by >> double-clicking them in the Finder, that's where the output should be >> going. >> >> Regards, >> >> Kevin >> > > I'm running from BBEdit. Someone else pointed me to the link that > showed how to do a redirect output. When I did that I got the > traceback. I wish there were a way to keep the popup window with the > traceback info open, but it quickly closes and the app quits. > Redirecting found the error, but it is an extra step. > > > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From midtoad at yahoo.com Wed Apr 12 17:42:20 2006 From: midtoad at yahoo.com (Stewart Midwinter) Date: Wed, 12 Apr 2006 11:42:20 -0400 (EDT) Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: Message-ID: <20060412154220.28818.qmail@web53902.mail.yahoo.com> > > From: Charles Hartman > If I recall correctly, this syndrome is covered in the book. It > happens because the diagnostic's going to a window that closes when > the app does. Look up wx.App(redirect=True) in the index -- you can > write the diagnostic to a file and examine it at leisure. > > From: Saggau > Charles is right: > http://www.wxpython.org/docs/api/wx.App-class.html thank you Charles, thank you Saggau (and thank you Daniel for posing the question). I'm also new to wxPython, though I've been working with Wax (a more pythonic layer on top of wxPython) for some months now), and I also was having a devil of a time trying to debug a simple app - the error window would pop up for a fraction of a second and then disappear. I tried your suggestion and indeed, I can read the exception message at my leisure! thanks again Stewart in Calgary __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From pecora at anvil.nrl.navy.mil Wed Apr 12 18:23:03 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 12 Apr 2006 12:23:03 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <20060412154220.28818.qmail@web53902.mail.yahoo.com> References: <20060412154220.28818.qmail@web53902.mail.yahoo.com> Message-ID: <443D2967.3090408@anvil.nrl.navy.mil> Stewart Midwinter wrote: > > thank you Charles, thank you Saggau (and thank you Daniel for posing > the question). I'm also new to wxPython, though I've been working > with Wax (a more pythonic layer on top of wxPython) for some months > now), and I also was having a devil of a time trying to debug a > simple app - the error window would pop up for a fraction of a second > and then disappear. > > I tried your suggestion and indeed, I can read the exception message > at my leisure! > > thanks again > Stewart in Calgary > > > Yep, the redirect works. I haven't tried the other suggestion of opening a messagebox dialog to hold the stdout window open. That would be nicer since it involves direct feedback instead of going to a file. But still nice to finally see what the problem was. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From alex at tweedly.net Wed Apr 12 18:16:17 2006 From: alex at tweedly.net (Alex Tweedly) Date: Wed, 12 Apr 2006 17:16:17 +0100 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443CFD7E.5060306@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> Message-ID: <443D27D1.9050109@tweedly.net> Louis Pecora wrote: > Thanks for the link and the hint on boa. I've heard of the latter, but > >never looked into it. I really do numerical calcs, but occasionally >need a simple GUI dialog or open a window to plot in (very simple), but >who knows, boa might be the ticket. Thanks, again. > > You should also look, then, at Pythoncard ( www.pythoncard.org ) Excellent for simple UIs, simple for excellent UIs :-) -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date: 11/04/2006 From pecora at anvil.nrl.navy.mil Wed Apr 12 21:31:44 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 12 Apr 2006 15:31:44 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443D27D1.9050109@tweedly.net> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <443D27D1.9050109@tweedly.net> Message-ID: <443D55A0.2010605@anvil.nrl.navy.mil> Alex Tweedly wrote: > Louis Pecora wrote: > > >> Thanks for the link and the hint on boa. I've heard of the latter, but >> >> never looked into it. I really do numerical calcs, but occasionally >> need a simple GUI dialog or open a window to plot in (very simple), but >> who knows, boa might be the ticket. Thanks, again. >> >> >> > You should also look, then, at Pythoncard ( www.pythoncard.org ) > Excellent for simple UIs, simple for excellent UIs :-) > > Just looked it over. Seems like the right level for what I do. But is it still under development? Looked stagnent to me. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From alex at tweedly.net Wed Apr 12 22:33:47 2006 From: alex at tweedly.net (Alex Tweedly) Date: Wed, 12 Apr 2006 21:33:47 +0100 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443D55A0.2010605@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <443D27D1.9050109@tweedly.net> <443D55A0.2010605@anvil.nrl.navy.mil> Message-ID: <443D642B.1090403@tweedly.net> Louis Pecora wrote: > Alex Tweedly wrote: > >> >> > > Just looked it over. Seems like the right level for what I do. But > is it still under development? Looked stagnent to me. It's under development - 0.8.2 will be out any day now, and contains a fair number of enhancements, including some big ones: - codeEditor handles multiple windows (using tabbed notebook style). - layoutEditor allows selection of, and operation on, multiple components (e.g. to align them, move them together, etc.) - layoutEditor gives direct access to all properties - additional samples, better Unicode handling, enhanced walk-through (tutorial style) documentation I'm struggling through the mechanics of releasing 0.8.2 - but you can get it already via anonymous cvs (see the instructions on the "cvs access" link from www.pythoncard.org ) The mailing list is pretty quiet - but generally responsive when questions are asked. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date: 11/04/2006 From mbroe at columbus.rr.com Wed Apr 12 22:57:19 2006 From: mbroe at columbus.rr.com (Michael Broe) Date: Wed, 12 Apr 2006 16:57:19 -0400 Subject: [Pythonmac-SIG] readline: where and how installed? Message-ID: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> I'm having an issue using IPython that may be related to readline, which I am pursuing on the IPython mailing list. I had my self-built version of readline 5.1 installed in /usr/local/ include, and I patched and reinstalled it, which was one theory for fixing the problem, but no go. I'm just curious about the readline component of the Universal MacPython 2.4.3 release. http://bob.pythonmac.org/archives/category/python/ says: "Includes a working bsddb, readline, and curses." Where is that readline installed? Who trumps who, a readline I have installed in /usr/local/include, or MacPython's readline? Does the installer check for the presence of readline, and make decisions accordingly? Just trying to get the lay of the land in order to isolate the problem. Here is my post to IPython, for context. Cheers, Mike --- If I partially (or completely) enter a command onto a line, then hit the up arrow, I cannot scroll back through history, and worse, if I hit up twice, or hit up then down, I get a bus error and am ejected from ipython. In the following, I type in "print range" then hit the up arrow twice: ~ $ ipython Python 2.4.3 (#1, Apr 7 2006, 10:54:33) Type "copyright", "credits" or "license" for more information. IPython 0.7.1.fix1 -- An enhanced Interactive Python. ? -> Introduction to IPython's features. %magic -> Information about IPython's 'magic' % functions. help -> Python's own help system. object? -> Details about 'object'. ?object also works, ?? prints more. In [1]: print rangeBus error ~ $ ipython That "ipython" after the last prompt is not typed in by me, it is accessed in the bash history by the second "up" I send. If I do "up" then "down", I'm dumped out to a bare prompt ~ $. --- From bob at redivi.com Wed Apr 12 23:09:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 12 Apr 2006 14:09:44 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> Message-ID: <1EDA582C-56C1-4F47-8887-4ED8C2D8752C@redivi.com> On Apr 12, 2006, at 1:57 PM, Michael Broe wrote: > I'm having an issue using IPython that may be related to readline, > which I am pursuing on the IPython mailing list. > > I had my self-built version of readline 5.1 installed in /usr/local/ > include, and I patched and reinstalled it, which was one theory for > fixing the problem, but no go. That's not going to do anything at all unless you were to also recompile Python. > I'm just curious about the readline component of the Universal > MacPython 2.4.3 release. > > http://bob.pythonmac.org/archives/category/python/ says: > > "Includes a working bsddb, readline, and curses." > > Where is that readline installed? Who trumps who, a readline I have > installed in /usr/local/include, or MacPython's readline? It's linked statically into the readline extension, so it doesn't know nor care about any other readline. > Does the installer check for the presence of readline, and make > decisions accordingly? No. It comes with its own private copy of readline. The installer doesn't recompile anything. > Just trying to get the lay of the land in order to isolate the > problem. > > Here is my post to IPython, for context. > > Cheers, > Mike > > --- > If I partially (or completely) enter a command onto a line, then hit > the up arrow, I cannot scroll back through history, and worse, if I > hit up twice, or hit up then down, I get a bus error and am ejected > from ipython. In the following, I type in "print range" then hit the > up arrow twice: Are you running 10.3.9 by chance? It might be an incompatibility there, we don't test very thoroughly on anything but 10.4.x due to availability. -bob From zpincus at stanford.edu Wed Apr 12 23:19:33 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Wed, 12 Apr 2006 14:19:33 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> Message-ID: <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> This is for Bob Ippolito - What version of readline comes with the Universal MacPython 2.4.3 release? And is it statically-linked, or is there a readline dylib somewhere in the python framework? I ask because Michael Broe reported some problems (see below) with IPython that I had tracked down to issues with readline 5.1. (Basically, the patches to readline 5.1 need to be applied.) It is thus of interest as to what version of readline is supplied with MacPython, and whether it is statically or dynamically linked. Also of interest: I had asked Michael to run python under GDB to see where the error he reported was happening, and Michael had some trouble with that: > ~ $ gdb python > GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov 2 17:28:16 > GMT 2005) > > (gdb) run > Starting program: /usr/local/bin/python > Reading symbols for shared libraries . done > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x8fe0100c in __dyld__dyld_start () > (gdb) This might be partially due to the fact that Michael's not using the latest version of GDB, but it's also possible that the problem stems from the execve that python is doing inside the fake bundle. If the most recent version of GDB can't handle the new python, that's a bit of a pain! (I think the problem can be handled by telling GDB to ignore SIGTRAPs, but this is a confusing issue...) Thanks, Zach On Apr 12, 2006, at 1:57 PM, Michael Broe wrote: > I'm having an issue using IPython that may be related to readline, > which I am pursuing on the IPython mailing list. > > I had my self-built version of readline 5.1 installed in /usr/local/ > include, and I patched and reinstalled it, which was one theory for > fixing the problem, but no go. > > I'm just curious about the readline component of the Universal > MacPython 2.4.3 release. > > http://bob.pythonmac.org/archives/category/python/ says: > > "Includes a working bsddb, readline, and curses." > > Where is that readline installed? Who trumps who, a readline I have > installed in /usr/local/include, or MacPython's readline? > > Does the installer check for the presence of readline, and make > decisions accordingly? > > Just trying to get the lay of the land in order to isolate the > problem. > > Here is my post to IPython, for context. > > Cheers, > Mike > > --- > If I partially (or completely) enter a command onto a line, then hit > the up arrow, I cannot scroll back through history, and worse, if I > hit up twice, or hit up then down, I get a bus error and am ejected > from ipython. In the following, I type in "print range" then hit the > up arrow twice: > > ~ $ ipython > Python 2.4.3 (#1, Apr 7 2006, 10:54:33) > Type "copyright", "credits" or "license" for more information. > > IPython 0.7.1.fix1 -- An enhanced Interactive Python. > ? -> Introduction to IPython's features. > %magic -> Information about IPython's 'magic' % functions. > help -> Python's own help system. > object? -> Details about 'object'. ?object also works, ?? prints more. > > In [1]: print rangeBus error > ~ $ ipython > > That "ipython" after the last prompt is not typed in by me, it is > accessed in the bash history by the second "up" I send. If I do "up" > then "down", I'm dumped out to a bare prompt ~ $. > --- > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Wed Apr 12 23:30:30 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 12 Apr 2006 14:30:30 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> Message-ID: On Apr 12, 2006, at 2:19 PM, Zachary Pincus wrote: > This is for Bob Ippolito - Well it's really for Ronald, I didn't build it. I have no idea. > What version of readline comes with the Universal MacPython 2.4.3 > release? And is it statically-linked, or is there a readline dylib > somewhere in the python framework? > > I ask because Michael Broe reported some problems (see below) with > IPython that I had tracked down to issues with readline 5.1. > (Basically, the patches to readline 5.1 need to be applied.) It is > thus of interest as to what version of readline is supplied with > MacPython, and whether it is statically or dynamically linked. It's static. -bob From zpincus at stanford.edu Wed Apr 12 23:40:43 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Wed, 12 Apr 2006 14:40:43 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> Message-ID: <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> >> This is for Bob Ippolito - > > Well it's really for Ronald, I didn't build it. I have no idea. Sorry! Hopefully Ronald will let us know what version of readline he used. Now, in regards to the GDB issue: can anyone with the latest developer tools who also has the Universal Python build installed try to run python under gdb? (I have a different install of python 2.4.3 that I don't want to nuke by installing the universal build just to test this; otherwise I wouldn't ask). All you need to do is run 'gdb python' and then type 'run' and see if you get a python prompt, or > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x8fe0100c in __dyld__dyld_start () I think you'll get the latter because of how the Universal MacPython is a dummy application bundle that just does an execve to the real python. This is known to confuse at least some versions of gdb. Though, with any luck, the latest version of gdb that Apple shipped won't be confused in this way. Zach From mbroe at columbus.rr.com Wed Apr 12 23:45:32 2006 From: mbroe at columbus.rr.com (Michael Broe) Date: Wed, 12 Apr 2006 17:45:32 -0400 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <1EDA582C-56C1-4F47-8887-4ED8C2D8752C@redivi.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <1EDA582C-56C1-4F47-8887-4ED8C2D8752C@redivi.com> Message-ID: OK so all my faffing about with readline was not making one whit of difference :) And now I know why... On Apr 12, 2006, at 5:09 PM, Bob Ippolito wrote: > > Are you running 10.3.9 by chance? It might be an incompatibility > there, we don't test very thoroughly on anything but 10.4.x due to > availability. 10.4.6. Well I'll digest all this and reexamine the problem. Once again thanks for the feedback. Cheers, Mike From bob at redivi.com Thu Apr 13 00:04:48 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 12 Apr 2006 15:04:48 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> Message-ID: On Apr 12, 2006, at 2:40 PM, Zachary Pincus wrote: >>> This is for Bob Ippolito - >> >> Well it's really for Ronald, I didn't build it. I have no idea. > > Sorry! Hopefully Ronald will let us know what version of readline he > used. > > Now, in regards to the GDB issue: can anyone with the latest > developer tools who also has the Universal Python build installed try > to run python under gdb? (I have a different install of python 2.4.3 > that I don't want to nuke by installing the universal build just to > test this; otherwise I wouldn't ask). > All you need to do is run > 'gdb python' > and then type > 'run' > and see if you get a python prompt, or >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x8fe0100c in __dyld__dyld_start () > > I think you'll get the latter because of how the Universal MacPython > is a dummy application bundle that just does an execve to the real > python. This is known to confuse at least some versions of gdb. > Though, with any luck, the latest version of gdb that Apple shipped > won't be confused in this way. Well, you could... explicitly run the actual python executable (potentially subject to change in future versions of Universal Python...): $ gdb --args `python -c "import sys; print sys.executable"` Continue through the trap: $ gdb --args python ... (gdb) r Starting program: /Library/Frameworks/Python.framework/Versions/2.4/ bin/python Reading symbols for shared libraries . done Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe0100c in __dyld__dyld_start () (gdb) c Continuing. Reading symbols for shared libraries ... done Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "help", "copyright", "credits" or "license" for more information. Reading symbols for shared libraries .. done >>> Attach: $ python Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.getpid() 20789 (from another terminal) $ gdb ... (gdb) attach 20789 Attaching to process 20789. Reading symbols for shared libraries . done Reading symbols for shared libraries ......... done 0x9001f5e8 in select () (gdb) c Continuing. -bob From zpincus at stanford.edu Thu Apr 13 00:20:50 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Wed, 12 Apr 2006 15:20:50 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> Message-ID: <05F711DE-DA07-4CD1-9A87-4720EA26116F@stanford.edu> >> Now, in regards to the GDB issue: can anyone with the latest >> developer tools who also has the Universal Python build installed try >> to run python under gdb? (I have a different install of python 2.4.3 >> that I don't want to nuke by installing the universal build just to >> test this; otherwise I wouldn't ask). >> All you need to do is run >> 'gdb python' >> and then type >> 'run' >> and see if you get a python prompt, or >>> Program received signal SIGTRAP, Trace/breakpoint trap. >>> 0x8fe0100c in __dyld__dyld_start () >> >> I think you'll get the latter because of how the Universal MacPython >> is a dummy application bundle that just does an execve to the real >> python. This is known to confuse at least some versions of gdb. >> Though, with any luck, the latest version of gdb that Apple shipped >> won't be confused in this way. > > Well, you could... It's good to have these different options listed in this email list -- thanks. I just wanted to make sure that what was going on was not an issue with Michael's slightly-old version of GDB, but a real by- product of the new MacPython situation. Anyhow, I'm only pointing this out mostly to get this information into the Google index, because this situation is bound to confuse some folks when they first try to run 'gdb python' under the new regime. While I'm sure that the execve stuff is a necessary evil (and certainly less troublesome than the pythonw mess), it's worth noting the little user-unfriendly situations like this that an "ideal" solution to the problem would not have. I guess the ball is rather in Apple's court to make things work better, but waiting around for that to happen is probably a waste. Also, what's the status of the MacPython branch vis a vis Python 2.5? Are the needed changes already in the svn for python 2.5? Or is the mac-specific branch going to stick around for a while? Just curious. Zach > explicitly run the actual python executable (potentially subject to > change in future versions of Universal Python...): > > $ gdb --args `python -c "import sys; print sys.executable"` > > Continue through the trap: > > $ gdb --args python > ... > > (gdb) r > Starting program: /Library/Frameworks/Python.framework/Versions/2.4/ > bin/python > Reading symbols for shared libraries . done > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x8fe0100c in __dyld__dyld_start () > (gdb) c > Continuing. > Reading symbols for shared libraries ... done > Python 2.4.3 (#1, Apr 7 2006, 10:54:33) > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > Reading symbols for shared libraries .. done > >>> > > Attach: > > $ python > Python 2.4.3 (#1, Apr 7 2006, 10:54:33) > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import os; os.getpid() > 20789 > > (from another terminal) > $ gdb > ... > (gdb) attach 20789 > Attaching to process 20789. > Reading symbols for shared libraries . done > Reading symbols for shared libraries ......... done > 0x9001f5e8 in select () > (gdb) c > Continuing. > > > -bob > From bob at redivi.com Thu Apr 13 00:42:38 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 12 Apr 2006 15:42:38 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <05F711DE-DA07-4CD1-9A87-4720EA26116F@stanford.edu> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> <05F711DE-DA07-4CD1-9A87-4720EA26116F@stanford.edu> Message-ID: On Apr 12, 2006, at 3:20 PM, Zachary Pincus wrote: >>> Now, in regards to the GDB issue: can anyone with the latest >>> developer tools who also has the Universal Python build installed >>> try >>> to run python under gdb? (I have a different install of python 2.4.3 >>> that I don't want to nuke by installing the universal build just to >>> test this; otherwise I wouldn't ask). >>> All you need to do is run >>> 'gdb python' >>> and then type >>> 'run' >>> and see if you get a python prompt, or >>>> Program received signal SIGTRAP, Trace/breakpoint trap. >>>> 0x8fe0100c in __dyld__dyld_start () >>> >>> I think you'll get the latter because of how the Universal MacPython >>> is a dummy application bundle that just does an execve to the real >>> python. This is known to confuse at least some versions of gdb. >>> Though, with any luck, the latest version of gdb that Apple shipped >>> won't be confused in this way. >> >> Well, you could... > > It's good to have these different options listed in this email list > -- thanks. I just wanted to make sure that what was going on was > not an issue with Michael's slightly-old version of GDB, but a real > by-product of the new MacPython situation. > > Anyhow, I'm only pointing this out mostly to get this information > into the Google index, because this situation is bound to confuse > some folks when they first try to run 'gdb python' under the new > regime. > > While I'm sure that the execve stuff is a necessary evil (and > certainly less troublesome than the pythonw mess), it's worth > noting the little user-unfriendly situations like this that an > "ideal" solution to the problem would not have. I guess the ball is > rather in Apple's court to make things work better, but waiting > around for that to happen is probably a waste. Yes, it is a necessary evil. We'll have to live with it. Apple isn't going to do a damned thing for us here, because they've had this particular design flaw since the beginning and have been aware of it for just about as long. I would think that most gdb users already know how to cross an execve, but maybe I'm wrong. > Also, what's the status of the MacPython branch vis a vis Python > 2.5? Are the needed changes already in the svn for python 2.5? Or > is the mac-specific branch going to stick around for a while? Just > curious. Python 2.5 will hopefully have universal capability, but AFAIK the patches are not yet integrated. Ronald is/was working on this, but I'm not sure what his progress is. -bob From zpincus at stanford.edu Thu Apr 13 05:52:25 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Wed, 12 Apr 2006 20:52:25 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> <05F711DE-DA07-4CD1-9A87-4720EA26116F@stanford.edu> Message-ID: <4BD44154-4264-4A78-8EE9-4297B8AB1A2B@stanford.edu> Well, not to keep this thread going on any more than necessary -- though we do still need to hear from Ronald about what version of readline was used for the Universal MacPython -- but I have a comment. > I would think that most gdb users already know how to cross an > execve, but maybe I'm wrong. I would disagree. You can amass a fairly decent knowledge of gdb without ever crossing an execve. People doing systems programming would of course know all about this, but people who develop and debug pretty exclusively single-process, single-task userland stuff could spend a whole lot of time in gdb without ever having to deal with forking, exec, or any of that. And since normal pythons don't execve on launch, it's even more confusing because nobody ever expects the spanish execve. Imagine you're someone like me -- a competent (I hope) graduate student who has been programming for over six years in C, C++, python and other crappier languages, but who has never done any systems work. One day 'gdb python' -- useful for tracking down errors in some little extension module you've made -- reports a SIGTRAP in __dyld__dyld_start. Googling for 'GDB SIGTRAP' or 'SIGRAP' yields almost nothing of any value as to understanding what's going on. It's a fun exercise to try to see if you could figure out what the "problem" with your program was if all you had to go on was: > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x8fe0100c in __dyld__dyld_start () without prior knowledge that (a) SIGTRAP is what happens when an execve happens and the program is being ptrace'd, or (b) that your copy of python is even doing an execve at all, and that might have implications for debugging. All I'm saying is that it might be a good idea to put a few lines in the README about the execve deal, and its implications for things like debugging. Because otherwise it could get pretty frustrating for some folk pretty fast. Zach From janssen at parc.com Thu Apr 13 07:34:55 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 12 Apr 2006 22:34:55 PDT Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: Your message of "Wed, 12 Apr 2006 20:52:25 PDT." <4BD44154-4264-4A78-8EE9-4297B8AB1A2B@stanford.edu> Message-ID: <06Apr12.223459pdt."58633"@synergy1.parc.xerox.com> > All I'm saying is that it might be a good idea to put a few lines in > the README about the execve deal, and its implications for things > like debugging. Because otherwise it could get pretty frustrating for > some folk pretty fast. I agree. This seems unnecessarily obscure. Just for fun, what's the point of the execve? Just to choose the right Python executable? Bill From janssen at parc.com Thu Apr 13 08:33:53 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 12 Apr 2006 23:33:53 PDT Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: Your message of "Wed, 12 Apr 2006 22:34:55 PDT." <06Apr12.223459pdt."58633"@synergy1.parc.xerox.com> Message-ID: <06Apr12.233354pdt."58633"@synergy1.parc.xerox.com> > Just for fun, what's the point of the execve? Just to choose the > right Python executable? Never mind, I found it on Bob's blog. It's to get around the requirement to have an app bundle if you want to draw on the screen, apparently. Bill From ronaldoussoren at mac.com Thu Apr 13 14:02:43 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 13 Apr 2006 14:02:43 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> Message-ID: <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> On 12-apr-2006, at 23:19, Zachary Pincus wrote: > This is for Bob Ippolito - No it isn't, Bob didn't build the 2.4.3 release ;-) > > What version of readline comes with the Universal MacPython 2.4.3 > release? And is it statically-linked, or is there a readline dylib > somewhere in the python framework? It is a staticly linked version of GNU readline 5.1. > > I ask because Michael Broe reported some problems (see below) with > IPython that I had tracked down to issues with readline 5.1. > (Basically, the patches to readline 5.1 need to be applied.) It is > thus of interest as to what version of readline is supplied with > MacPython, and whether it is statically or dynamically linked. > > Also of interest: > I had asked Michael to run python under GDB to see where the error he > reported was happening, and Michael had some trouble with that: >> ~ $ gdb python >> GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov 2 17:28:16 >> GMT 2005) >> >> (gdb) run >> Starting program: /usr/local/bin/python >> Reading symbols for shared libraries . done >> >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x8fe0100c in __dyld__dyld_start () >> (gdb) > > This might be partially due to the fact that Michael's not using the > latest version of GDB, but it's also possible that the problem stems > from the execve that python is doing inside the fake bundle. If the > most recent version of GDB can't handle the new python, that's a bit > of a pain! (I think the problem can be handled by telling GDB to > ignore SIGTRAPs, but this is a confusing issue...) That's because the python command is actually pythonw and this execv-s the real python interpreter to get the right process environment for GUI programs. Ronald From ronaldoussoren at mac.com Thu Apr 13 14:06:53 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 13 Apr 2006 14:06:53 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> <05F711DE-DA07-4CD1-9A87-4720EA26116F@stanford.edu> Message-ID: <55C29333-5D38-4267-B0AD-13EBDC964EA9@mac.com> On 13-apr-2006, at 0:42, Bob Ippolito wrote: >> >> While I'm sure that the execve stuff is a necessary evil (and >> certainly less troublesome than the pythonw mess), it's worth >> noting the little user-unfriendly situations like this that an >> "ideal" solution to the problem would not have. I guess the ball is >> rather in Apple's court to make things work better, but waiting >> around for that to happen is probably a waste. > > Yes, it is a necessary evil. We'll have to live with it. Apple > isn't going to do a damned thing for us here, because they've had > this particular design flaw since the beginning and have been aware > of it for just about as long. I agree with Bob, this is needed and it is unlikely that Apple will change the OS for this. If if they would change the OS this wouldn't change the current relase of OSX. > > I would think that most gdb users already know how to cross an > execve, but maybe I'm wrong. It's probably more that they don't expect and execv when they debug python :-) > >> Also, what's the status of the MacPython branch vis a vis Python >> 2.5? Are the needed changes already in the svn for python 2.5? Or >> is the mac-specific branch going to stick around for a while? Just >> curious. > > Python 2.5 will hopefully have universal capability, but AFAIK the > patches are not yet integrated. Ronald is/was working on this, but > I'm not sure what his progress is. I'm not making progress at the moment due to lack of time. I hope to have some time for working on this during the Easter weekend. Ronald From ronaldoussoren at mac.com Thu Apr 13 14:09:27 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 13 Apr 2006 14:09:27 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <06Apr12.233354pdt.58633@synergy1.parc.xerox.com> References: <06Apr12.233354pdt.58633@synergy1.parc.xerox.com> Message-ID: On 13-apr-2006, at 8:33, Bill Janssen wrote: >> Just for fun, what's the point of the execve? Just to choose the >> right Python executable? > > Never mind, I found it on Bob's blog. It's to get around the > requirement to have an app bundle if you want to draw on the screen, > apparently. That's right. Note that this functionality won't be changed, we could pick between having pythonw, which confuses all users, and this functionality, which confuses gdb users. Having less confusing for "normal" users is better. Ronald > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From pecora at anvil.nrl.navy.mil Thu Apr 13 16:06:05 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu, 13 Apr 2006 10:06:05 -0400 Subject: [Pythonmac-SIG] wxPython -- getting Traceback on errors (was: some disappointment using it.) In-Reply-To: References: <443C22F8.3080706@anvil.nrl.navy.mil> <443D007B.6030509@anvil.nrl.navy.mil> Message-ID: <443E5ACD.5090901@anvil.nrl.navy.mil> Charles Hartman wrote: > It occurs to me that if you added an OnExit() handler to your app -- > any app that's giving quit-too-soon trouble. The handler could simply > put up a wx.MessageBox, which gets an OK from the user. This would > pause the app on the way out, and therefore permit the normal app > output window (without changing redirection) to stay onscreen as long > as one liked. A little baroque, but pretty easy. > > Charles Hartman I think I've found the right circumstances in which getting Traceback works. I tried what you said above, but it didn't work, although I did get the code to work by providing more path info. Below is the App portion of the code (the hello.py example 3 in the book Chap.1). I get the code to work now so long as I have the full path to the graphic image. If I make an error in the path, the app exits (as it should, I would guess). The OnExit is not invoked if there is an error. Here are the circumstances in which it is invoked or not (I tried to put this in a logical order) : (1) __init__ (and hence, wx.App.__init__) are not called (both commented out) (a) path is wrong, error NO OnExit (b) path is right, no error NO OnExit (2) __init__ (and hence, wx.App.__init__) are both called as shown below (a) redirect= True (i) path is wrong NO OnExit , but output is in external file (ii) path is right YES OnExit , and output is in external file (b) redirect= False (i) path is wrong NO OnExit , but output is to Terminal with traceback (!) (ii) path is right YES OnExit, and output is to Terminal Bottom line: OnExit is only invoked if the program runs without error. If you want the traceback you have to include a call to wx.App.__init__ and set the type of redirect you want. Note that redirect to the Terminal works fine then and the whole Traceback appears as one would like. A good hint for newbies like me. App portion of my code: class App(wx.App): """Application Class;""" def __init__(self): wx.App.__init__(self,redirect=True, filename="/Users/louispecora/Desktop/Hello.out") def OnInit(self): print "***here" image=wx.Image('/Users/louispecora/Code/python/test_folder/wxPython_learn/rappin_cover150.jpg', wx.BITMAP_TYPE_JPEG) self.frame = Frame(image) self.frame.Show() self.SetTopWindow(self.frame) return True def OnExit(self): print "In OnExit()" retCode=wx.MessageBox("Quit?", caption="Message on Quit.") -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From mbroe at columbus.rr.com Thu Apr 13 16:30:44 2006 From: mbroe at columbus.rr.com (Michael Broe) Date: Thu, 13 Apr 2006 10:30:44 -0400 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <55C29333-5D38-4267-B0AD-13EBDC964EA9@mac.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <823083DC-F09F-47A4-A142-9C3E35EBEE6E@stanford.edu> <05F711DE-DA07-4CD1-9A87-4720EA26116F@stanford.edu> <55C29333-5D38-4267-B0AD-13EBDC964EA9@mac.com> Message-ID: Just wanted to report that patching readline 5.1 and recompiling python from source did fix the original problem I had with IPython. Cheers, Mike From pecora at anvil.nrl.navy.mil Thu Apr 13 16:45:58 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu, 13 Apr 2006 10:45:58 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443D27D1.9050109@tweedly.net> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <443D27D1.9050109@tweedly.net> Message-ID: <443E6426.5000503@anvil.nrl.navy.mil> Alex Tweedly wrote: > > You should also look, then, at Pythoncard ( www.pythoncard.org ) > Excellent for simple UIs, simple for excellent UIs :-) > Got it, ran sudo python setup.py install, seemed to go OK. Ran minimaltest and it could not find PythonCard module. I have a path to the PythonCard directory (folder) in my .pth file in the proper place down in Library/Frameworks/python... etc. Not sure why it can't see it. Other added packages are found fine by python. I am running on MacOS X 10.4.1 with Python 2.4.1 through the editor BBEdit. I've checked paths and spellings. No errors so far. Any hints? -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From zpincus at stanford.edu Thu Apr 13 18:41:02 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Thu, 13 Apr 2006 09:41:02 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <06Apr12.233354pdt.58633@synergy1.parc.xerox.com> Message-ID: >>> Just for fun, what's the point of the execve? Just to choose the >>> right Python executable? >> >> Never mind, I found it on Bob's blog. It's to get around the >> requirement to have an app bundle if you want to draw on the screen, >> apparently. > > That's right. > > Note that this functionality won't be changed, we could pick between > having pythonw, which confuses all users, and this functionality, > which > confuses gdb users. Having less confusing for "normal" users is > better. Just to be clear, I certainly don't suggest that the execve bit be removed, as I agree that it is *far* better than the pythonw situation. I do think it would be worth while to make explicit mention of the execve and its implications for debugging in the readme, though. Zach From zpincus at stanford.edu Thu Apr 13 18:47:46 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Thu, 13 Apr 2006 09:47:46 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> Message-ID: >> This is for Bob Ippolito - > > No it isn't, Bob didn't build the 2.4.3 release ;-) Sorry sorry! Thanks for making that build, by the way. > >> >> What version of readline comes with the Universal MacPython 2.4.3 >> release? And is it statically-linked, or is there a readline dylib >> somewhere in the python framework? > > It is a staticly linked version of GNU readline 5.1. So... I have found that IPython exposes a bug in GNU readline 5.1, sadly enough. This bug causes segfaults when the up-arrow key is used under certain situations. Ugh. Fortunately, the extant readline 5.1 patches solve this issue nicely. Hopefully you'll get a chance in the near future to update the Universal MacPython 2.4.3 distribution so that it doesn't have this issue. Also, a related query: Is there somewhere in the Python Framework structure that is appropriate for placing dynamic libraries that Python would link to? Judicious use of the install_name_tool and friends could produce a libreadline.dylib that the python binary would expect at a particular relative path from itself. This would allow that library to be dynamically linked, yet still live within (and be distributed with) the framework. Just a thought -- but it might be more work than it's worth. Zach From alex at tweedly.net Thu Apr 13 19:44:00 2006 From: alex at tweedly.net (Alex Tweedly) Date: Thu, 13 Apr 2006 18:44:00 +0100 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443E6426.5000503@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <443D27D1.9050109@tweedly.net> <443E6426.5000503@anvil.nrl.navy.mil> Message-ID: <443E8DE0.7010901@tweedly.net> Louis Pecora wrote: > Alex Tweedly wrote: > >> >> You should also look, then, at Pythoncard ( www.pythoncard.org ) >> Excellent for simple UIs, simple for excellent UIs :-) >> > Got it, ran sudo python setup.py install, seemed to go OK. Ran > minimaltest and it could not find PythonCard module. I have a path to > the PythonCard directory (folder) in my .pth file in the proper place > down in Library/Frameworks/python... etc. > > Not sure why it can't see it. Other added packages are found fine by > python. > > I am running on MacOS X 10.4.1 with Python 2.4.1 through the editor > BBEdit. > > I've checked paths and spellings. No errors so far. Any hints? > I'm pretty clueless about how everything (including the whole "framework" thing) fits together on OS X, but I'd suggest trying this ... run python, and do > import sys > print sys.path and see if it contains the PythonCard directory as you expect it. If it does, then further try > import os.path > for d in sys.path: > print d, os.path.isdir(d) and see if that tells you anything. If you're still stuck - I'd suggest asking on the pythoncard mailing list. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.1/310 - Release Date: 12/04/2006 From pecora at anvil.nrl.navy.mil Thu Apr 13 20:38:34 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Thu, 13 Apr 2006 14:38:34 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443E8DE0.7010901@tweedly.net> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <443D27D1.9050109@tweedly.net> <443E6426.5000503@anvil.nrl.navy.mil> <443E8DE0.7010901@tweedly.net> Message-ID: <443E9AAA.2010308@anvil.nrl.navy.mil> Alex Tweedly wrote: > > I'm pretty clueless about how everything (including the whole > "framework" thing) fits together on OS X, but I'd suggest trying this ... > > run python, and do > >> import sys >> print sys.path > > and see if it contains the PythonCard directory as you expect it. If > it does, then further try It does. Here's the print out of it: /Users/louispecora/Code/python/test_folder /Library/Frameworks/Python.framework/Versions/2.4/lib/python24.zip /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4 /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat-darwin /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat-mac /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat-mac/lib-scriptpackages /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-dynload /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Numeric /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/kinds /usr/local/bin /Users/louispecora/Code/python/general /Users/louispecora/Code/python/stats /Users/louispecora/Code/python/stats/BayesProb /Users/louispecora/Code/python/time_series /Users/louispecora/Code/python/plotwindow /users/louispecora/Code/python/dynamic/dynsys /Users/louispecora/Code/python/AddedPackagesfiles /Users/louispecora/Code/python/AddedPackagesfiles/kinds/Lib /Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1 /Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1/build/lib /Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1/build/lib/PythonCard /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode You can see the PythonCard directory near the bottom. >> import os.path >> for d in sys.path: >> print d, os.path.isdir(d) > and see if that tells you anything. Here you go: /Users/louispecora/Code/python/test_folder True /Library/Frameworks/Python.framework/Versions/2.4/lib/python24.zip False /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4 True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat-darwin True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat-mac True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/plat-mac/lib-scriptpackages True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-tk True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/lib-dynload True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Numeric True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/kinds True /usr/local/bin True /Users/louispecora/Code/python/general True /Users/louispecora/Code/python/stats True /Users/louispecora/Code/python/stats/BayesProb True /Users/louispecora/Code/python/time_series True /Users/louispecora/Code/python/plotwindow True /users/louispecora/Code/python/dynamic/dynsys True /Users/louispecora/Code/python/AddedPackagesfiles True /Users/louispecora/Code/python/AddedPackagesfiles/kinds/Lib True /Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1 True /Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1/build/lib True /Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1/build/lib/PythonCard True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app True /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode True There's PythonCard near the bottom. Is there anything to the error which is that module PythonCard cannot be found and that PythonCard is really a directory? Here's the original error: Traceback (most recent call last): File "/Users/louispecora/Code/python/AddedPackagesfiles/PythonCard-0.8.1/tests/minimalTest.py", line 3, in ? from PythonCard import model, test ImportError: No module named PythonCard Exit 1 > > If you're still stuck - I'd suggest asking on the pythoncard mailing > list. If you give up, that's my next step. Thanks for taking the time to help. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From ronaldoussoren at mac.com Thu Apr 13 22:19:53 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 13 Apr 2006 22:19:53 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> Message-ID: <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> On 13-apr-2006, at 18:47, Zachary Pincus wrote: >>> This is for Bob Ippolito - >> >> No it isn't, Bob didn't build the 2.4.3 release ;-) > > Sorry sorry! Thanks for making that build, by the way. > >> >>> >>> What version of readline comes with the Universal MacPython 2.4.3 >>> release? And is it statically-linked, or is there a readline dylib >>> somewhere in the python framework? >> >> It is a staticly linked version of GNU readline 5.1. > > So... I have found that IPython exposes a bug in GNU readline 5.1, > sadly enough. This bug causes segfaults when the up-arrow key is > used under certain situations. Ugh. Fortunately, the extant > readline 5.1 patches solve this issue nicely. Hopefully you'll get > a chance in the near future to update the Universal MacPython 2.4.3 > distribution so that it doesn't have this issue. Which patch? Please provide a link to that patch, I won't go hunting for it. > > Also, a related query: Is there somewhere in the Python Framework > structure that is appropriate for placing dynamic libraries that > Python would link to? Judicious use of the install_name_tool and > friends could produce a libreadline.dylib that the python binary > would expect at a particular relative path from itself. This would > allow that library to be dynamically linked, yet still live within > (and be distributed with) the framework. Just a thought -- but it > might be more work than it's worth. I don't see what this would buy us. It is possible to do this, but IMHO not really worth the trouble. Ronald From mbroe at columbus.rr.com Thu Apr 13 22:38:26 2006 From: mbroe at columbus.rr.com (Michael Broe) Date: Thu, 13 Apr 2006 16:38:26 -0400 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> Message-ID: <9A79E95C-ADE8-4ABA-A7AC-B3DF6F52F1AF@columbus.rr.com> On Apr 13, 2006, at 4:19 PM, Ronald Oussoren wrote: > Which patch? Please provide a link to that patch, I won't go hunting > for it. Current readline 5.1 patches are at: ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches Cheers, Mike From zpincus at stanford.edu Thu Apr 13 23:53:42 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Thu, 13 Apr 2006 14:53:42 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> Message-ID: >> So... I have found that IPython exposes a bug in GNU readline 5.1, >> sadly enough. This bug causes segfaults when the up-arrow key is >> used under certain situations. Ugh. Fortunately, the extant >> readline 5.1 patches solve this issue nicely. Hopefully you'll get >> a chance in the near future to update the Universal MacPython >> 2.4.3 distribution so that it doesn't have this issue. > > Which patch? Please provide a link to that patch, I won't go > hunting for it. I don't really like how they do it, but on the readline page ( http:// tiswww.tis.case.edu/~chet/readline/rltop.html ) they give you a link to download the latest version of readline ( ftp://ftp.cwru.edu/pub/ bash/readline-5.1.tar.gz ) as well as the link to the patch directory ( ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches ). I don't know why they don't spin out x.x.1 point releases to fix known bugs, but they don't, and instead provide the fixes as patches. So any readline build must include the current sources and any patches for that version to be considered bug-free. What a pain. >> Also, a related query: Is there somewhere in the Python Framework >> structure that is appropriate for placing dynamic libraries that >> Python would link to? Judicious use of the install_name_tool and >> friends could produce a libreadline.dylib that the python binary >> would expect at a particular relative path from itself. This would >> allow that library to be dynamically linked, yet still live within >> (and be distributed with) the framework. Just a thought -- but it >> might be more work than it's worth. > > I don't see what this would buy us. It is possible to do this, but > IMHO not really worth the trouble. It doesn't buy much really, except obviating the need to re-link python every time a library needs to be changed. So in this case, Michael could have built a fixed readline, put it in the right place, and gone on his merry way with the MacPython distribution. Instead he had to rebuild python himself, from scratch. It's not a big deal though either way. I was just mentioning the possibility, but not really advocating for it. Zach From zpincus at stanford.edu Fri Apr 14 03:01:31 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Thu, 13 Apr 2006 18:01:31 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> Message-ID: <3747D04E-D8C7-4392-9DC5-2312145397CA@stanford.edu> > You can build the readline extension separately from Python without > much fuss. I have a setup.py for it and the extracted source > sitting in my svn: > http://svn.red-bean.com/bob/readline/trunk/ Thanks! I didn't know it was that easy. Also, thanks everyone for your time while this issue got resolved. Zach From janssen at parc.com Fri Apr 14 03:41:59 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 13 Apr 2006 18:41:59 PDT Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: Your message of "Thu, 13 Apr 2006 14:53:42 PDT." Message-ID: <06Apr13.184201pdt."58633"@synergy1.parc.xerox.com> Just curious... Is there really a need for the readline library? On Mac, I always run Python shells in either (1) Terminal, or (2) xterm, or (3) an Emacs shell buffer. All of them have readline capability built in. I never need Python to have readline capability. What's the use case here? Bill From mbroe at columbus.rr.com Fri Apr 14 04:12:53 2006 From: mbroe at columbus.rr.com (Michael Broe) Date: Thu, 13 Apr 2006 22:12:53 -0400 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <06Apr13.184201pdt.58633@synergy1.parc.xerox.com> References: <06Apr13.184201pdt.58633@synergy1.parc.xerox.com> Message-ID: On Apr 13, 2006, at 9:41 PM, Bill Janssen wrote: > Just curious... > > Is there really a need for the readline library? On Mac, I always run > Python shells in either (1) Terminal, or (2) xterm, or (3) an Emacs > shell buffer. All of them have readline capability built in. I never > need Python to have readline capability. What's the use case here? The issue that got this going was using IPython, which is (i) a really nice command line interface to python for one thing, and (ii) has extremely good support for matplotlib, which I am using. It seems that IPython requires a fully patched version of readline 5.1. Without it, I (and others) found it can give a segmentation fault when you are zipping around the history with up arrow and down arrow. It's been a long time since anything 'just crashed' on me :) But it did it repeatedly with the unpatched version of readline. I never ran into anything like this problem with MacPython in any other environment. But since quite a few people in the IPython and matplotlib community recommend MacPython, I thought it was worth raising here. Cheers, Mike From janssen at parc.com Fri Apr 14 08:43:08 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 13 Apr 2006 23:43:08 PDT Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: Your message of "Thu, 13 Apr 2006 19:02:14 PDT." Message-ID: <06Apr13.234311pdt."58633"@synergy1.parc.xerox.com> > > I never > > need Python to have readline capability. > > Yeah you do, you probably just don't realize that you're using it. No, I really don't. The only time I ever interact with the Python REPL is in a GNU Emacs shell buffer (or, rarely, an Emacs pdb buffer), which does the dance for me. In the past I've had to go to some extra trouble to disable the readline support in Python, but that problem seems to have disappeared. > You need it to get readline capability. History, line editing, etc. Sure, I know. But as I pointed out, the environments in which I need that stuff all provide it already. I can see that if you are using some mathlib-style app written in Python, and for some reason aren't running it in an Emacs shell buffer, you might want it. I was wondering what those applications are? I suppose IDLE would be one of them. Bill From robert.kern at gmail.com Fri Apr 14 08:50:45 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 14 Apr 2006 01:50:45 -0500 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <06Apr13.184201pdt."58633"@synergy1.parc.xerox.com> References: <06Apr13.184201pdt."58633"@synergy1.parc.xerox.com> Message-ID: <443F4645.9080708@gmail.com> Bill Janssen wrote: > Just curious... > > Is there really a need for the readline library? On Mac, I always run > Python shells in either (1) Terminal, or (2) xterm, or (3) an Emacs > shell buffer. All of them have readline capability built in. I never > need Python to have readline capability. What's the use case here? 1) and 2) certainly don't have any readline capability built in to them. The Emacs shell buffer does, but it's not the same thing as the readline module, which IPython accesses to add its own completer functions. -- Robert Kern robert.kern at gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From ronaldoussoren at mac.com Fri Apr 14 09:45:45 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 14 Apr 2006 09:45:45 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <06Apr13.184201pdt.58633@synergy1.parc.xerox.com> References: <06Apr13.184201pdt.58633@synergy1.parc.xerox.com> Message-ID: <6051248.1145000745098.JavaMail.ronaldoussoren@mac.com> On Friday, April 14, 2006, at 03:42AM, Bill Janssen wrote: >Just curious... > >Is there really a need for the readline library? On Mac, I always run >Python shells in either (1) Terminal, or (2) xterm, or (3) an Emacs >shell buffer. All of them have readline capability built in. I never >need Python to have readline capability. What's the use case here? > >Bill Terminal and xterm don't have readline capability, the shell (bash) does. But that is of no use when you're in the python interactive shell. Then having readline support in python is very handy. Ronald > > From ronaldoussoren at mac.com Fri Apr 14 10:16:52 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 14 Apr 2006 10:16:52 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> Message-ID: <12215962.1145002612346.JavaMail.ronaldoussoren@mac.com> On Thursday, April 13, 2006, at 11:53PM, Zachary Pincus wrote: >>> So... I have found that IPython exposes a bug in GNU readline 5.1, >>> sadly enough. This bug causes segfaults when the up-arrow key is >>> used under certain situations. Ugh. Fortunately, the extant >>> readline 5.1 patches solve this issue nicely. Hopefully you'll get >>> a chance in the near future to update the Universal MacPython >>> 2.4.3 distribution so that it doesn't have this issue. >> >> Which patch? Please provide a link to that patch, I won't go >> hunting for it. > >I don't really like how they do it, but on the readline page ( http:// >tiswww.tis.case.edu/~chet/readline/rltop.html ) they give you a link >to download the latest version of readline ( ftp://ftp.cwru.edu/pub/ >bash/readline-5.1.tar.gz ) as well as the link to the patch directory >( ftp://ftp.cwru.edu/pub/bash/readline-5.1-patches ). I don't know >why they don't spin out x.x.1 point releases to fix known bugs, but >they don't, and instead provide the fixes as patches. So any readline >build must include the current sources and any patches for that >version to be considered bug-free. What a pain. You can say that. The bad part of this scheme is that they don't say this. I saw this directory when I downloaded readline, but assumed that these were patches that may or may not end up in a future version of readline. > >>> Also, a related query: Is there somewhere in the Python Framework >>> structure that is appropriate for placing dynamic libraries that >>> Python would link to? Judicious use of the install_name_tool and >>> friends could produce a libreadline.dylib that the python binary >>> would expect at a particular relative path from itself. This would >>> allow that library to be dynamically linked, yet still live within >>> (and be distributed with) the framework. Just a thought -- but it >>> might be more work than it's worth. >> >> I don't see what this would buy us. It is possible to do this, but >> IMHO not really worth the trouble. > >It doesn't buy much really, except obviating the need to re-link >python every time a library needs to be changed. So in this case, >Michael could have built a fixed readline, put it in the right place, >and gone on his merry way with the MacPython distribution. Instead he >had to rebuild python himself, from scratch. It's not a big deal >though either way. I was just mentioning the possibility, but not >really advocating for it. He could have done this even now, readline is a python extension and it is not very hard to build an installer for just readline. Ronald > >Zach > > From janssen at parc.com Fri Apr 14 12:00:47 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 14 Apr 2006 03:00:47 PDT Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: Your message of "Fri, 14 Apr 2006 00:45:45 PDT." <6051248.1145000745098.JavaMail.ronaldoussoren@mac.com> Message-ID: <06Apr14.030052pdt."58633"@synergy1.parc.xerox.com> > Terminal and xterm don't have readline capability, the shell (bash) > does. But that is of no use when you're in the python interactive > shell. Then having readline support in python is very handy. Right you are, Ronald. Thanks for the correction. I never use them bare; I always run Emacs in them and create a shell buffer. Consistent editing everywhere. OK, now I understand (though I still struggle to understand why people use raw terminal emulators, on modern machines; the ATK typescript ruined me :-). And the IPython example makes sense, as well. Bill From ronaldoussoren at mac.com Fri Apr 14 12:15:48 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 14 Apr 2006 12:15:48 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <06Apr14.030052pdt.58633@synergy1.parc.xerox.com> References: <06Apr14.030052pdt.58633@synergy1.parc.xerox.com> Message-ID: <14662458.1145009748153.JavaMail.ronaldoussoren@mac.com> On Friday, April 14, 2006, at 12:00PM, Bill Janssen wrote: >> Terminal and xterm don't have readline capability, the shell (bash) >> does. But that is of no use when you're in the python interactive >> shell. Then having readline support in python is very handy. > >Right you are, Ronald. Thanks for the correction. I never use them >bare; I always run Emacs in them and create a shell buffer. >Consistent editing everywhere. OK, now I understand (though I still >struggle to understand why people use raw terminal emulators, on >modern machines; the ATK typescript ruined me :-). And the IPython >example makes sense, as well. I could make some nasty remarks about emacs and you could then strike back with remarks about vi, but lets not go there :-) Ronald > >Bill > > From autodot at gmail.com Sat Apr 15 18:37:29 2006 From: autodot at gmail.com (Robertson Holt) Date: Sat, 15 Apr 2006 12:37:29 -0400 Subject: [Pythonmac-SIG] 2.3 vs 2.4 Message-ID: Hi, I'm using 10.3.9 removed Python 2.3 as per instructions on python.org installed Python 2.4 and now can't launch some apps which reference 2.3 dyld: /Applications/Alias/MotionBuilder 7 PLE/MotionBuilder 7 PLE.app/Contents/MacOS/ple can't open library: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (No such file or directory, errno = 2) I tried making an alias of Python.Framework in /System/Library/Frameworks/Python.framework/ to point to /Library/Frameworks/Python.framework/ & aliasing a fake /Versions/2.3 folder to the /Versions/2.4 but no luck. dyld: /Applications/Alias/MotionBuilder 7 PLE/MotionBuilder 7 PLE.app/Contents/MacOS/ple can't open library: /System/Library/Frameworks/Python.framework/Versions/2.3/Python (Not a directory, errno = 20) Suggestions? Much appreciated. -- Robertson Holt http://www.electrogelly.com From janssen at parc.com Sat Apr 15 20:30:29 2006 From: janssen at parc.com (Bill Janssen) Date: Sat, 15 Apr 2006 11:30:29 PDT Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: Your message of "Fri, 14 Apr 2006 03:15:48 PDT." <14662458.1145009748153.JavaMail.ronaldoussoren@mac.com> Message-ID: <06Apr15.113033pdt."58633"@synergy1.parc.xerox.com> > I could make some nasty remarks about emacs and you could then > strike back with remarks about vi, but lets not go there :-) Thanks for reminding me of vi. As I understand it (I'm afraid I've never seen the point of knowing much about vi :-) the model vi uses is quite different -- "lean and mean", a model suited to the early days of computing with low-powered 24x80 terminals, vs. Emacs's "live-inside" model. People who use it seem to slip in and out of it (for example, to do things like using the shell), rather than doing everything inside it. I surmise vi has no shell mode, and thus you'd need something else, something like readline, to provide that support. A good point. Bill From janssen at parc.com Sat Apr 15 20:32:43 2006 From: janssen at parc.com (Bill Janssen) Date: Sat, 15 Apr 2006 11:32:43 PDT Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: Your message of "Sat, 15 Apr 2006 09:37:29 PDT." Message-ID: <06Apr15.113248pdt."58633"@synergy1.parc.xerox.com> > Hi, > > I'm using 10.3.9 > > removed Python 2.3 as per instructions on python.org > > installed Python 2.4 > > and now can't launch some apps which reference 2.3 Please point me to the instructions on python.org which tell you to remove Python 2.3 from your Mac, so that I can stamp them out! Bill From daniellord at mac.com Sat Apr 15 20:43:38 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 15 Apr 2006 11:43:38 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: References: Message-ID: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> It is _not_ a good thing to remove Apple's Python. Don't panic though. First, let's stop this from happening to anybody else... Can you tell me where those instructions are that recommend that on Python.org? I believe they refer to a previous _MacPython_ that was installed which is not the same as _Apple's Python_ --perhaps that is what confused you? If so, please say so and tell me where the text is that confused you. (NOTE TO SELF: we might want to make that distinction more clear) There are applications (MotionBuilder is obviously one I now know) that look for Python, not on your environment path like IMHO they should, but instead embed the path. Someone with credulity (i.e. not me;-) should recommend Alias research adopt that practice. First let me try and help you: What did you do to remove it? If you just deleted symbolic links, great--put them back ;-). In the future, rather than removing things, try changing symbolic links in your path--that way recovery is rather simple. If you deleted files, the best thing to do is to to find another Mac running the same version of OS X you have and copy the Python framework back. If you cannot, I am not sure how to help. If you were successful in restoring things, then allow me to tell you what you should do in the future: The recommended approach (and it used to be the default on install for MacPython--I beleive it may still be but is optional now) is to install MacPython in /usr/local/bin leaving Apple's Python 2.3 intact. Then you put /usr/local/bin in your path ahead of /usr/bin (the location of the 2.3 python binary). then applications with hard links to /usr/bin/python don't break. Daniel On Apr 15, 2006, at 9:37, Robertson Holt wrote: > Hi, > > I'm using 10.3.9 > > removed Python 2.3 as per instructions on python.org > > installed Python 2.4 > > and now can't launch some apps which reference 2.3 > > dyld: /Applications/Alias/MotionBuilder 7 PLE/MotionBuilder 7 > PLE.app/Contents/MacOS/ple can't open library: > /System/Library/Frameworks/Python.framework/Versions/2.3/Python > (No such file or directory, errno = 2) > > I tried making an alias of Python.Framework in > /System/Library/Frameworks/Python.framework/ > > to point to /Library/Frameworks/Python.framework/ > > & aliasing a fake /Versions/2.3 folder > > to the /Versions/2.4 > > but no luck. > > dyld: /Applications/Alias/MotionBuilder 7 PLE/MotionBuilder 7 > PLE.app/Contents/MacOS/ple can't open library: > /System/Library/Frameworks/Python.framework/Versions/2.3/Python (Not > a directory, errno = 20) > > Suggestions? > > > Much appreciated. > > -- > Robertson Holt > http://www.electrogelly.com > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From nicholas.cole at gmail.com Sat Apr 15 21:05:07 2006 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sat, 15 Apr 2006 21:05:07 +0200 Subject: [Pythonmac-SIG] Fwd: more OS X oddities In-Reply-To: <20060415181953.GA10371@crayon.invisible-island.net> References: <20060415181953.GA10371@crayon.invisible-island.net> Message-ID: I realised that on OS X it is almost impossible (or at least I can't find a way) to capture F-key or meta-key presses using the python curses module. The following email has some code which illustrates the problem (it reports key-presses in 3 different ways). For some reason I don't understand it works on Linux but not OS X. Thomas Dickey from the bug-ncurses list points out that python may be using its own functions rather than those from curses itself. At any rate, this seems to be a mac issue, so I thought I'd point it out here. Best wishes, N. ---------- Forwarded message ---------- From: Thomas Dickey Date: Apr 15, 2006 8:19 PM Subject: Re: more OS X oddities To: Nicholas Cole Cc: bug-ncurses at gnu.org On Sat, Apr 15, 2006 at 04:20:36PM +0200, Nicholas Cole wrote: > Why does this code give the name of function keys on linux, but not on > OS X? I can't work out any way of capturing a function-key press > (either in X11 or Terminal.app) on OS X. > > Best, N. > > #!/usr/bin/python > import curses > import curses.ascii > > def mainloop(scr): > while 1: > scr.keypad(1) > ch = scr.getch() > try: > scr.erase() > scr.addstr(0,0, "%s, %s, %s" % > (curses.keyname(ch), curses.ascii.unctrl(ch), ch)) Checking a little - The python package for curses does not use the curses function unctrl(), and uses this chunk instead: def unctrl(c): bits = _ctoi(c) if bits == 0x7f: rep = "^?" elif bits & 0x20: rep = chr((bits & 0x7f) | 0x20) else: rep = "^" + chr(((bits & 0x7f) | 0x20) + 0x20) if bits & 0x80: return "!" + rep return rep (that accounts for the odd format of the output). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEQTlJcCNT4PfkjtsRArYrAKC/gk25beCJVHfQC/7vkCLjNNbtjACeJsoC xo+OWVMpY1lq5SyW26yeDiU= =DcUE -----END PGP SIGNATURE----- From troy_lists at rpsystems.net Sat Apr 15 23:10:10 2006 From: troy_lists at rpsystems.net (Troy Rollins) Date: Sat, 15 Apr 2006 17:10:10 -0400 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> Message-ID: <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> On Apr 15, 2006, at 2:43 PM, Daniel Lord wrote: > The recommended approach (and it used to be the default on install > for MacPython--I beleive it may still be but is optional now) is to > install MacPython in /usr/local/bin leaving Apple's Python 2.3 > intact. Then you put /usr/local/bin in your path ahead of /usr/bin > (the location of the 2.3 python binary). Daniel (and all), This sounds like good advise. In my case, I've installed the latest ActivePython from ActiveState, but the issues seem pretty much the same. I still have Apple's 2.3.5 installed. The thing I'm slightly unclear about is the best way to change my path on OSX. Changing things like ~/.profile and ~/.bash_profile change it for the shell, but do not change it systemwide. I've modified my ~/.MacOSX.environment.plist, which seems to do the job, but is it the right way to do it? > then applications with hard > links to /usr/bin/python don't break. This is true, but they do cause some confusion. For instance, I don't seem to be able to install wxPython... it finds the "wrong" python. Recommendations on how to correct my $path, or install wx on OSX.4.6 would be much appreciated. -- Troy RPSystems, Ltd. http://www.rpsystems.net From troy_lists at rpsystems.net Sun Apr 16 00:04:50 2006 From: troy_lists at rpsystems.net (Troy Rollins) Date: Sat, 15 Apr 2006 18:04:50 -0400 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> Message-ID: <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> On Apr 15, 2006, at 5:57 PM, Bob Ippolito wrote: > Is there any particular reason to change it in > MacOSX.environment.plist? What applications do you use that aren't > started from the shell, yet look in $PATH for Python? I've never > seen one, but then again I don't use GUI text editors like BBEdit > or TextMate so I'm not sure what they do by default. Komodo couldn't see it, it saw the unmodified path which did not include /usr/local/bin > >>> then applications with hard >>> links to /usr/bin/python don't break. >> >> This is true, but they do cause some confusion. For instance, I don't >> seem to be able to install wxPython... it finds the "wrong" python. > > Installers for extensions are specific to a particular version of > Python anyway. Mac OS X installers don't try and detect Python, > they hard code where they expect to find it (win32 installers do > search though). Your problem is that you found the wrong > installer, not that the installer found the wrong Python. Ah. I suppose that could be it too. I believe the one I found was designed for Python 2.4.3 framework edition, which apparently does not include ActivePython, which is also designed to be framework, or so I thought. -- Troy RPSystems, Ltd. http://www.rpsystems.net From daniellord at mac.com Sun Apr 16 00:35:08 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 15 Apr 2006 15:35:08 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> Message-ID: <18728978-4CC4-48E6-9AEA-D75BC119F27C@mac.com> On Apr 15, 2006, at 14:10, Troy Rollins wrote: > The thing I'm slightly unclear about is the best way to change my > path on OSX. Changing things like ~/.profile and ~/.bash_profile > change it for the shell, but do not change it systemwide. I've > modified my ~/.MacOSX.environment.plist, which seems to do the job, > but is it the right way to do it? Yes. It is the way to change it system wide for any applications the do not check the $PATH environment variable. And I think you meant ~/.MacOSX/environment.plist which is correct ;-) I only change the environment in those two ways (shell vars and environment.plist) and have no problems. And if I want a specific Python, /usr/bin/python or /usr/local/bin/python finds the one I intend to access. Maybe some of the more sage members of this community have more detailed or better advice, but that's what I recommend from my experience. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060415/58f3f4d9/attachment.html From daniellord at mac.com Sun Apr 16 00:44:34 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 15 Apr 2006 15:44:34 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 - Installer myopia In-Reply-To: <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> Message-ID: > On Apr 15, 2006, at 5:57 PM, Bob Ippolito wrote: > Installers for extensions are specific to a particular version of > Python anyway. But is that always necessary? I am sure it is sometimes, particularly when the OS changes dramatically like from 10.3 to 10.4. But what about the case of the Alias research product I wonder. > Mac OS X installers don't try and detect Python, > they hard code where they expect to find it (win32 installers do > search though). Your problem is that you found the wrong > installer, not that the installer found the wrong Python. Interesting lack of awareness and function in the Mac OS X installers. Is it by design or due to a limitation in options in the installer tools? Why don't they behave like some well-mannered installers I have used which locate *all* the potential paths and let you decide which one is used? And if the extension only works with say Python 2.4 on OS X 10.3, it could either force acceptance of that one or if it didn't find it, it could refuse to install. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060415/9b4a4a18/attachment-0001.htm From daniellord at mac.com Sun Apr 16 01:49:49 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 15 Apr 2006 16:49:49 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 - Installer myopia In-Reply-To: References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> Message-ID: <9CFE5F93-FD96-43C8-B0C7-14492F165C73@mac.com> On Apr 15, 2006, at 16:03, Bob Ippolito wrote: > It's possible that the wxPython guys screwed up, or it's possible > that you downloaded an installer for Apple's Python 2.3 framework > and expected it to work with an entirely different version of > Python installed in another location. You didn't really provide > enough information to determine which one of these it was. It wasn't me--it was Troy with the problem. I work in two environments: G5 PPC and Macbook Pro i386 so I am very, very careful to select the right packages for the right processor endian architecture and instruction set, the right Python, and the right OS version (and maybe phase of the Moon). I have spent (or rather wasted hours in the past) trying to track down a bug that turned out to be environment related. I am seeing one with Python and Growl on the Macbook Pro right now that works fine on the PPC. And I have the Universal Python 2.4, Growl, and appscript installed. So I learned (mostly;-). From daniellord at mac.com Sun Apr 16 01:43:22 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 15 Apr 2006 16:43:22 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <18728978-4CC4-48E6-9AEA-D75BC119F27C@mac.com> Message-ID: <3C171293-D5CC-42D3-A2DC-346F9B58F859@mac.com> On Apr 15, 2006, at 15:53, Bob Ippolito wrote: > There are relatively few applications that are launched by > LaunchServices *and* use the PATH environment variable. From the > rest of the thread, it sounds like Komodo is apparently one of these. Yes, Komodo seems to. I use Komodo (BTW they have a Universal version in Beta which I am running right now and appears fairly solid). But Komodo does let you choose how it finds the Python to run in its debugger: it allows you to let it use the $PATH as its default behavior or you can choose a Python to run. In fact, it brings up a dialog when launching the debugger allowing you to set command line option and several other things including: picking a debug configuration which means you can have multiple environment 'sets' and it shows you the environment variables in another tab(see pic below). IMHO I think an IDE, just like a good command line tool like a liner or compiler, should read environment variables to allow custom environment configurations. At least Active State seems to agree anyway ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 1.png Type: image/png Size: 232755 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060415/4a6fb103/attachment-0001.png From autodot at gmail.com Sun Apr 16 06:21:04 2006 From: autodot at gmail.com (Robertson Holt) Date: Sun, 16 Apr 2006 00:21:04 -0400 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: References: Message-ID: Ok, right I thought ApplePython = MacPython and got confused by this paragraph on the MacPython site, NOT python.org "The downside of Apple including 2.3 is that running MacPython 2.3.3 on Mac OS X 10.3 is a bit of a problem: when you install the full MacPython 2.3.3 distribution (the one labelled here as MacPython 2.3.3 for 10.2) the two installations may get confused when you build extension modules. We hope to solve this for 2.3.4, and in the mean time you can visit the FAQ for some workarounds if you really need 2.3." from (http://homepages.cwi.nl/~jack/macpython/macpython-osx.html) Which I assumed went for 2.4 as well, and followed the instructions from the Uninstall page. "Remove /Library/Frameworks/Python.framework and everything in it; remove /Applications/MacPython-2.3 and everything in it;" Which I deleted from the finder. I had already grabbed the binaries from python.org, so I missed the "As an almost complete MacPython 2.3 installation is already included in Panther by Apple the only thing you need is the MacPython 2.3 for Panther addons installer" on the 'Download' page of MacPython. I'll update later with the Fixes. Thanks to all for the help. From ronaldoussoren at mac.com Sun Apr 16 11:37:29 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 16 Apr 2006 11:37:29 +0200 Subject: [Pythonmac-SIG] 2.3 vs 2.4 - Installer myopia In-Reply-To: References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> Message-ID: On 16-apr-2006, at 0:44, Daniel Lord wrote: > >> On Apr 15, 2006, at 5:57 PM, Bob Ippolito wrote: >> Installers for extensions are specific to a particular version of >> Python anyway. > But is that always necessary? I am sure it is sometimes, > particularly when the OS changes dramatically like from 10.3 to 10.4. > But what about the case of the Alias research product I wonder. > Yes it is necessary, ABI for python extensions is not a completely stable ABI although you can often continue using extensions for an older release of python with a new release. More importantly, the site-packages directories for two major releases of python (such as python 2.3.x and python 2.4.x) are at different locations, hence the newer version won't even see the extensions you installed for the older one. >> Mac OS X installers don't try and detect Python, >> they hard code where they expect to find it (win32 installers do >> search though). Your problem is that you found the wrong >> installer, not that the installer found the wrong Python. > > Interesting lack of awareness and function in the Mac OS X > installers. Is it by design or due to a limitation in options in > the installer tools? > Why don't they behave like some well-mannered installers I have > used which locate *all* the potential paths and let you decide > which one is used? That due to a limitation in Apple's installer tool, you'll have to ask Apple why they don't fix this. > And if the extension only works with say Python 2.4 on OS X 10.3, > it could either force acceptance of that one or if it didn't find > it, it could refuse to install. That's up to whoever build the installer. bdist_mpkg (part of py2app) seems to check if the right version of python is installed. Ronald > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From altern2 at gmail.com Sun Apr 16 11:59:09 2006 From: altern2 at gmail.com (altern) Date: Sun, 16 Apr 2006 11:59:09 +0200 Subject: [Pythonmac-SIG] include all python with py2app Message-ID: <4442156D.8010800@gmail.com> hi i was wondering .. does anyone know if there is a simple way to include all modules python within an app using py2app? i could go one by one importing all modules from standard library but i wonder if there is some way to do it in one go. thanks -- enrike From kernel at troniczoo.net Sun Apr 16 22:38:32 2006 From: kernel at troniczoo.net (kernel) Date: Sun, 16 Apr 2006 21:38:32 +0100 Subject: [Pythonmac-SIG] Universal MacPython 10.3.9 Message-ID: hello, using the current UniversalBinary distro 2.4.3 of MacPython under 10.3.9 IDLE launches but then I get a spinning wheel which never stops. is this version Tiger only? otherwise I guess it's my setup... TIA, stefven. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 303 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060416/d330b954/attachment.bin From stevepymac at gnulinux.net Mon Apr 17 02:54:34 2006 From: stevepymac at gnulinux.net (steve) Date: Sun, 16 Apr 2006 20:54:34 -0400 Subject: [Pythonmac-SIG] Using setup.py/distutils on Intel Macs Message-ID: <4442E74A.8060902@gnulinux.net> Hello List, I'm new here so please forgive me if this is a dupe question .... I can't seem to install python source dists correctly. I follow: python setup.py build sudo python setup.py install It installs cleanly except I notice "byte-compiling build/bdist.darwin-8.6.1-Power_Macintosh" which seems very weird to me -- that is comes up as Power_Macintosh. When I start using the module I usually run into "ImportError: Inappropriate file type for dynamic loading". Is there any workarounds? This can be reproduced by downloading and installing the current stable PIL src dist from source. Thanks! Steve Milner From kw at kevin-walzer.com Mon Apr 17 05:05:24 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Sun, 16 Apr 2006 23:05:24 -0400 Subject: [Pythonmac-SIG] py2app/macho_standalone issue? Message-ID: <444305F4.5020708@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Setup: Python 2.4.3 "universal," 10.4.6, Xcode 2.2 I'm trying to use the "macho_standalone" script from the latest build of py2app that comes with pyobjc (the "universal" build that was just posted in the past couple of days). Trying to run macho_standalone on an app bundle (to relocate all the libs inside of the app bundle instead of doing them one-by-one with install_name_tool), I get the error below: Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 20, in ? main() File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 17, in main standaloneApp(fn) File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 10, in standaloneApp files = MachOStandalone(path).run() TypeError: __init__() takes at least 3 arguments (2 given) Not sure how to troubleshoot this. The documentation says that the app bundle name is the only required argument, so I don't know what else to add. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQwX0rTC5hIgjqTMRAjOxAJ9nSDbIDSwgb8I2IF/lh9yFNTaxawCeMdkF xInhBAP6WqN0nsllnOBW3kE= =P/Tc -----END PGP SIGNATURE----- From daniellord at mac.com Mon Apr 17 07:29:24 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 16 Apr 2006 22:29:24 -0700 Subject: [Pythonmac-SIG] Using setup.py/distutils on Intel Macs In-Reply-To: <4442E74A.8060902@gnulinux.net> References: <4442E74A.8060902@gnulinux.net> Message-ID: On Apr 16, 2006, at 17:54, steve wrote: > When I start using the module I usually run into "ImportError: > Inappropriate file type for dynamic loading". Is there any > workarounds? That error is ( in my experience) typical to receive when loading a PPC format library on the i386 platform. There might be a Universal PIL somewhere out there in the aether--try 'googling'. If you want to try and do it yourself, the workaround would start with compiling PIL for Intel i386 I would guess. I am no expert but try setting ensuring CFLAGS uses -arch 1386 instead of -arch ppc as a start. BUt there may be other issue. Hopefully not such as embedded endian issues since PIl is first written for Intel Win32 anyway. there could be other subtleties though. There are others around here far more knowledgeable than I--just answering because they have not so far. Daniel From steve at gnulinux.net Mon Apr 17 02:47:37 2006 From: steve at gnulinux.net (steve) Date: Sun, 16 Apr 2006 20:47:37 -0400 Subject: [Pythonmac-SIG] Using setup.py/distutils on Intel Macs Message-ID: <4442E5A9.7010001@gnulinux.net> Hello List, I'm new here so please forgive me if this is a dupe question .... I can't seem to install python source dists correctly. I follow: python setup.py build sudo python setup.py install It installs cleanly except I notice "byte-compiling build/bdist.darwin-8.6.1-Power_Macintosh" which seems very weird to me -- that is comes up as Power_Macintosh. When I start using the module I usually run into "ImportError: Inappropriate file type for dynamic loading". Is there any workarounds? This can be reproduced by downloading and installing the current stable PIL src dist from source. Thanks! Steve Milner From piet at cs.uu.nl Mon Apr 17 10:39:11 2006 From: piet at cs.uu.nl (Piet van Oostrum) Date: Mon, 17 Apr 2006 10:39:11 +0200 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: (Robertson Holt's message of "Sun, 16 Apr 2006 00:21:04 -0400") References: Message-ID: >>>>> "Robertson Holt" (RH) wrote: >RH> "Remove /Library/Frameworks/Python.framework and everything in it; >RH> remove /Applications/MacPython-2.3 and everything in it;" >RH> Which I deleted from the finder. But your error message was about a missing /System/Library/Frameworks/Python.framework/Versions/2.3/Python, i.e. not /Library/Frameworks/Python.framework, so it seems you removed /Systems/Library/Frameworks/Python.framework instead, contrary to the instruction. You will have to reinstall it, otherwise some applications may mysteriously fail. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From anand.vasudevan at wipro.com Mon Apr 17 12:44:55 2006 From: anand.vasudevan at wipro.com (anand.vasudevan at wipro.com) Date: Mon, 17 Apr 2006 16:14:55 +0530 Subject: [Pythonmac-SIG] Photoshop events from Python Message-ID: <3D81D46E0E63304FBC9ECEB136B4CF26023BB952@BLR-EC-MBX04.wipro.com> Hi, Our application which runs on Mac OS X, uses the API Suite generated by GenSuiteModule (provided by python) to communicate to Photoshop CS. Most of the input parameters that would be generally specified by the user such as rasterization options etc. are passed through the API generated by GenSuiteModule and the dialog display is also turned off. The API works fine in most of the cases but throws this exception when there are additional dialogs shown by Photoshop CS like when the file is corrupt or some fonts used in the document are not available: - TypeError: unpack non-sequence Following is the code-snippet from the application: - import Photoshop2 as ps ref = File.FSRef(path) alias = ref.FSNewAliasMinimal() open_opts = (EPS_open_options, resolution=300, use_antialias=True) ps.send_timeout = 5 * 60 ps.open(*[alias], **open_opts) After the 5 second timeout period, it throws an exception, when Photoshop displays a diaolog box with message such as "The parser module could not parse the file" or "The file was modified by another user. Continue anyway? and buttons". Has anyone faced this problem before? Is there a mechanism to respond to the dialogs shown by Photoshop, by way of sending events to press Continue or Cancel buttons or send the error message back to Python application from Photoshop? Regards Anand The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060417/5bc78abc/attachment.htm From kernel at troniczoo.net Mon Apr 17 13:09:31 2006 From: kernel at troniczoo.net (kernel) Date: Mon, 17 Apr 2006 12:09:31 +0100 Subject: [Pythonmac-SIG] Universal MacPython 10.3.9 In-Reply-To: <58651B36-5004-4DFB-B986-F30FE217A2A5@redivi.com> References: <58651B36-5004-4DFB-B986-F30FE217A2A5@redivi.com> Message-ID: <7a49a752c098e9896cc9f1d222049546@troniczoo.net> On 16 Apr 2006, at 23:17, Bob Ippolito wrote: > IDLE needs Tcl/Tk Aqua installed to function.? Have you installed it? yup, I had an older version (2.4.1 ?) working today which was just a PPC build not Universal... but, some of the tkinter examples in the extras folder exhibit the same behaviour (GUI starts then spinning wheel) so it looks like the problem is the TclTkl after all...? stefven From mwh at python.net Mon Apr 17 13:35:00 2006 From: mwh at python.net (Michael Hudson) Date: Mon, 17 Apr 2006 12:35:00 +0100 Subject: [Pythonmac-SIG] Fwd: more OS X oddities In-Reply-To: (Nicholas Cole's message of "Sat, 15 Apr 2006 21:05:07 +0200") References: <20060415181953.GA10371@crayon.invisible-island.net> Message-ID: <2mirp8l9jv.fsf@starship.python.net> "Nicholas Cole" writes: > I realised that on OS X it is almost impossible (or at least I can't > find a way) to capture F-key or meta-key presses using the python > curses module. I think this has to do with your terminal emulator more than anything. Try it in an xterm (if you have x11 installed...). Cheers, mwh -- What the semicolon's anxious supporters fret about is the tendency of contemporary writers to use a dash instead of a semicolon and thus precipitate the end of the world. -- Lynne Truss, "Eats, Shoots & Leaves" From frank.hoffsummer at gmail.com Mon Apr 17 18:49:06 2006 From: frank.hoffsummer at gmail.com (frank h.) Date: Mon, 17 Apr 2006 18:49:06 +0200 Subject: [Pythonmac-SIG] read content from latin-1 file, write it to ut8 file Message-ID: <60fae7c30604170949j46923b3do64bb2d5e24ab4728@mail.gmail.com> Hello, I am using Mac Python 2.4.1 on Mac OS X 10.4 and I cannot seem to be able to read from a latin-1 file and then write to a UTF8 file correctly Using Textwrangler on OS X, I create a latin-1 file with some special characters in it and save it as "test.txt" I am reading the textfile as such: f = codecs.open('test.txt', 'r', 'latin-1') content = f.read() f.close() type(content) all good. I can even print content.encode('utf8') ?????????????? (having set sys.defaultencoding to 'utf8' in siteconfig.py). Now I want to create a new utf8 file and write "content" into it. I do the following: f=codecs.open('newtest.txt','w','utf-8') f.write(content) f.close() my problem is, that when I open "newtest.txt" in Textwrangler again, Textwrangler recognizes the file as "MacRoman" encoded and the content is garbled. The same thing happens if I try to write content to a "latin-1" file again whats happening? thanks for any insight you might have -frank -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060417/785d63dc/attachment.htm From trentm at ActiveState.com Mon Apr 17 19:22:24 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 17 Apr 2006 10:22:24 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> Message-ID: <20060417172224.GF24200@activestate.com> [Troy Rollins wrote] > > Installers for extensions are specific to a particular version of > > Python anyway. Mac OS X installers don't try and detect Python, > > they hard code where they expect to find it (win32 installers do > > search though). Your problem is that you found the wrong > > installer, not that the installer found the wrong Python. > > Ah. I suppose that could be it too. I believe the one I found was > designed for Python 2.4.3 framework edition, which apparently does > not include ActivePython, which is also designed to be framework, or > so I thought. ActivePython 2.4.3 should most certainly be considered an install target for an extension looking for a "python 2.4.3" to install to. And, yes, ActivePython is a framework build/install of Python, just as are the Apple Python and MacPython builds. Trent -- Trent Mick TrentM at ActiveState.com From troy_lists at rpsystems.net Mon Apr 17 19:28:19 2006 From: troy_lists at rpsystems.net (Troy Rollins) Date: Mon, 17 Apr 2006 13:28:19 -0400 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: <20060417172224.GF24200@activestate.com> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <66E3B0D0-417A-4B24-AD99-72998BD75EE4@redivi.com> <1351FD26-2632-437A-ABE6-211F4F1836BD@rpsystems.net> <20060417172224.GF24200@activestate.com> Message-ID: On Apr 17, 2006, at 1:22 PM, Trent Mick wrote: > ActivePython 2.4.3 should most certainly be considered an install > target > for an extension looking for a "python 2.4.3" to install to. > > And, yes, ActivePython is a framework build/install of Python, just as > are the Apple Python and MacPython builds. Fair enough. Then I'm left wondering what the problem is, short of the possibility that I downloaded the wrong installer. I'll look into this again this afternoon. Might be worth asking, has anyone here got wxPython and ActivePython 2.4.3 working together on OSX.4.6? -- Troy RPSystems, Ltd. http://www.rpsystems.net From trentm at ActiveState.com Mon Apr 17 19:39:52 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 17 Apr 2006 10:39:52 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: <3C171293-D5CC-42D3-A2DC-346F9B58F859@mac.com> References: <359B1ACB-D84D-404E-8877-F9D5DFB0F1E4@mac.com> <8EA6F2E0-D347-4D77-B097-607A59C51B1B@rpsystems.net> <18728978-4CC4-48E6-9AEA-D75BC119F27C@mac.com> <3C171293-D5CC-42D3-A2DC-346F9B58F859@mac.com> Message-ID: <20060417173952.GG24200@activestate.com> [Daniel Lord wrote] > > On Apr 15, 2006, at 15:53, Bob Ippolito wrote: > > >There are relatively few applications that are launched by > >LaunchServices *and* use the PATH environment variable. From the > >rest of the thread, it sounds like Komodo is apparently one of these. > > Yes, Komodo seems to. I use Komodo (BTW they have a Universal version > in Beta which I am running right now and appears fairly solid). Yes, Komodo can be launched from either LaunchServices or from the shell. One correction though: The current Komodo beta is not a Universal build. We currently have separate builds for Mac OS X/PowerPC and Mac OS X/x86. We hope to have universal builds in the future but won't very soon. Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Mon Apr 17 20:44:24 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 17 Apr 2006 11:44:24 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: Message-ID: <20060417184424.GK24200@activestate.com> [Thomas Juntunen wrote] > > I'm trying to get wxPython going with ActivePython, Komodo and > > OSX.4.6 > > > > The wx installer is installing to my framework "system" python (Apple > > 2.3.5) > > > > Is there any way to get this to work with my setup? wxPython on the Mac seems to be painful right now. 1. You need to get the correct build for your version of Python. For ActivePython 2.4.x or MacPython 2.4.x that means getting one of the builds with "-py24" in the package name. 2. They have "ansi" and "unicode" builds. From what I can tell the "ansi" builds are probably only useful for Mac OS X 10.2.x compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater then I'd stick with the "unicode" builds. > There are lots of packages available as pre-built binaries for Python 2.4.x > on Tiger available here: > > http://pythonmac.org/packages/ 3. There don't seem to be builds of wxPython for Mac OS X/Intel anywhere. The builds that they have up here for Mac OS X http://www.wxpython.org/download.php#binaries are for the PowerPC architecture. I'm not on the wxPython mailing lists so I don't know if there are Mac OS X/Intel builds hiding somewhere or in the works. I was able to install wxPython for Python 2.4: wxPython2.6-osx-unicode-2.6.3.2-macosx10.3-py2.4.dmg on Mac OS X 10.3/PowerPC and use it (only minor testing). Unfortunately I was also able to *install* it on Mac OS X 10.4/Intel but it doesn't work (importing "wx" fails) because the binary modules in wx are for ppc while the running Python is x86. It looks like using wxPython on Mac OS X/Intel requires you to compile it yourself from source: http://sourceforge.net/project/showfiles.php?group_id=10718 wxPython-src-2.6.3.2.tar.gz Cheers, Trent -- Trent Mick TrentM at ActiveState.com From hengist.podd at virgin.net Mon Apr 17 21:08:04 2006 From: hengist.podd at virgin.net (has) Date: Mon, 17 Apr 2006 20:08:04 +0100 Subject: [Pythonmac-SIG] Photoshop events from Python In-Reply-To: <3D81D46E0E63304FBC9ECEB136B4CF26023BB952@BLR-EC-MBX04.wipro.com> References: <3D81D46E0E63304FBC9ECEB136B4CF26023BB952@BLR-EC-MBX04.wipro.com> Message-ID: Anand wrote: >Our application which runs on Mac OS X, uses the API Suite generated by GenSuiteModule (provided by python) to communicate to Photoshop CS. > >The API works fine in most of the cases but throws this exception when there are additional dialogs shown by Photoshop CS like when the file is corrupt or some fonts used in the document are not available: - > >TypeError: unpack non-sequence That particular error looks like it's coming from the GSM-generated glue module, aepack, aetools and/or aetypes, presumably due to a bug there. I would imagine what you should be seeing is an Apple event timeout error, MacOS.Error(-1712). But GSM et-al have long been flaky and are well past their 'best by' date now [1], so a fix is unlikely short of doing it yourself. As for ways to dismiss those pesky PS dialogs, you may get a PS scripting expert here who can answer that, otherwise your best bet is to ask on one of the Photoshop/AppleScript lists since I'm sure folks there run into the same problem often enough: (Don't have a link for Adobe's forums, but they're not hard to find.) HTH has [1] Appscript is the new goodness: . -- http://freespace.virgin.net/hamish.sanderson/ From troy_lists at rpsystems.net Mon Apr 17 21:14:03 2006 From: troy_lists at rpsystems.net (Troy Rollins) Date: Mon, 17 Apr 2006 15:14:03 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <20060417184424.GK24200@activestate.com> References: <20060417184424.GK24200@activestate.com> Message-ID: <2CD0E791-9FC2-44D7-B0E6-E6AF7DDA71EC@rpsystems.net> On Apr 17, 2006, at 2:44 PM, Trent Mick wrote: > wxPython on the Mac seems to be painful right now. > > 1. You need to get the correct build for your version of Python. For > ActivePython 2.4.x or MacPython 2.4.x that means getting one of the > builds with "-py24" in the package name. Thanks for the prompting Trent (Bob, and others). I have this working now. The download I used is named - wxPython2.6-osx-unicode-2.6.3.2-macosx10.3-py2.4.dmg The link to the proper file is: -- Troy RPSystems, Ltd. http://www.rpsystems.net From kevino at theolliviers.com Mon Apr 17 22:07:05 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Mon, 17 Apr 2006 13:07:05 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <20060417184424.GK24200@activestate.com> References: <20060417184424.GK24200@activestate.com> Message-ID: Hi Trent, On Apr 17, 2006, at 11:44 AM, Trent Mick wrote: > [Thomas Juntunen wrote] >>> I'm trying to get wxPython going with ActivePython, Komodo and >>> OSX.4.6 >>> >>> The wx installer is installing to my framework "system" python >>> (Apple >>> 2.3.5) >>> >>> Is there any way to get this to work with my setup? > > wxPython on the Mac seems to be painful right now. Suggestions and contributions welcome! :-) > 1. You need to get the correct build for your version of Python. For > ActivePython 2.4.x or MacPython 2.4.x that means getting one of the > builds with "-py24" in the package name. Of course, this is pretty much the same as with every other (binary) Python extension, isn't it? > 2. They have "ansi" and "unicode" builds. From what I can tell the > "ansi" builds are probably only useful for Mac OS X 10.2.x > compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater > then I'd stick with the "unicode" builds. The ansi builds are for people who haven't considered Unicode support when building their wxPython apps, and thus might have issues when their data is automatically converted to and from Unicode. In ansi mode, it just passes the actual 'bytes' around, so the user is in total control over how the data is encoded. It took me a couple days of auditing my codebase before I got everything working with Unicode, and while I'm glad I did, up until that point I (and users of my app) were doing just fine with ANSI builds. But yes, in general, Unicode is the recommended build on OS X, or any modern platform for that matter. >> There are lots of packages available as pre-built binaries for >> Python 2.4.x >> on Tiger available here: >> >> http://pythonmac.org/packages/ > > 3. There don't seem to be builds of wxPython for Mac OS X/Intel > anywhere. The builds that they have up here for Mac OS X > > http://www.wxpython.org/download.php#binaries > > are for the PowerPC architecture. I'm not on the wxPython mailing > lists so I don't know if there are Mac OS X/Intel builds hiding > somewhere or in the works. There aren't any Intel-only binaries, but packages containing Universal binaries (built using the Universal MacPython Framework) was finished up late last week and are just awaiting being uploaded to the wxPython SF site. So it should be pretty soon. They should work with the ActivePython build too, but I don't have a machine around to test that with. They will only work with Tiger though, due to the reasons mentioned above. > I was able to install wxPython for Python 2.4: > wxPython2.6-osx-unicode-2.6.3.2-macosx10.3-py2.4.dmg > on Mac OS X 10.3/PowerPC and use it (only minor testing). > > Unfortunately I was also able to *install* it on Mac OS X 10.4/ > Intel > but it doesn't work (importing "wx" fails) because the binary > modules > in wx are for ppc while the running Python is x86. Right. About the only thing we could do at this point is to add a command-line check on the architecture of the Python binary and bomb out if it's incorrect. I could go ahead and add such a test, although I think the OS X Installer will just give a generic "you are not allowed to install this package" message, which is arguably just as confusing to the user.... We could also add ppc to the filename, though I think it will easily be missed. In that sense, it's kinda a shame that the whole Package Manager deal fell apart. While I never liked the idea of a centralized repository for packages, the idea of Python developers being able to use distutils to create an installer that worked cross-platform (perhaps using a download and double-click solution like Win and OS X installers), and also allowed the user to manage their packages via an "Add/Remove/Update packages" interface was, I think, a very good one. It's a shame the time I put into crafting a cross-platform wxPython interface for this was wasted... ;-/ Regards, Kevin > It looks like using wxPython on Mac OS X/Intel requires you to compile > it yourself from source: > > http://sourceforge.net/project/showfiles.php?group_id=10718 > wxPython-src-2.6.3.2.tar.gz > > Cheers, > Trent > > -- > Trent Mick > TrentM at ActiveState.com > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From trentm at ActiveState.com Mon Apr 17 22:26:30 2006 From: trentm at ActiveState.com (Trent Mick) Date: Mon, 17 Apr 2006 13:26:30 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: <20060417184424.GK24200@activestate.com> Message-ID: <20060417202630.GB28644@activestate.com> [Trent] > >wxPython on the Mac seems to be painful right now. [Kevin Ollivier wrote] > Suggestions and contributions welcome! :-) My apologies, I was being unfairly brief. Some suggestions: - A review of the Mac OS X-related text on http://www.wxpython.org/download.php Some of that info is misleading: '''wxPythonOSX needs a "Framework" build of Python 2.3, also known as MacPython-OSX.''' To be fair explaining the myriad Python's out there for Mac OS X is hard. This sentence though connotes the wrong thing: that wxPython is only available for Python 2.3. '''If you would like to try Python 2.4.x on Panther or Tiger then you can get an installer here''' Again, to be fair, giving a download link for the current Python for Mac OS X (whatever that really means) is a moving target. There *is* a Python installer at that link, but it is no longer a recommended one. As well, some mention of the x86 arch issues would be helpful for users. Okay, *one* suggestion. :) I don't currently use wxPython at all. > >1. You need to get the correct build for your version of Python. For > > ActivePython 2.4.x or MacPython 2.4.x that means getting one of the > > builds with "-py24" in the package name. > > Of course, this is pretty much the same as with every other (binary) > Python extension, isn't it? Yes, I didn't mean to imply that wxPython is special here. > >2. They have "ansi" and "unicode" builds. From what I can tell the > > "ansi" builds are probably only useful for Mac OS X 10.2.x > > compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater > > then I'd stick with the "unicode" builds. > > The ansi builds are for people who haven't considered Unicode support > when building their wxPython apps, and thus might have issues when > their data is automatically converted to and from Unicode. In ansi > mode, it just passes the actual 'bytes' around, so the user is in > total control over how the data is encoded. It took me a couple days > of auditing my codebase before I got everything working with Unicode, > and while I'm glad I did, up until that point I (and users of my app) > were doing just fine with ANSI builds. > > But yes, in general, Unicode is the recommended build on OS X, or any > modern platform for that matter. If that is the case then I'd suggest having the link to the unicode build the only obvious one. Those requiring ANSI builds can be pointed to the SF.net "Files" page and/or a Unicode vs. ANSI wiki page. The current http://wiki.wxpython.org/index.cgi/UnicodeBuild, which *is* linked to there, probably already does a good job here. > There aren't any Intel-only binaries, but packages containing > Universal binaries (built using the Universal MacPython Framework) > was finished up late last week and are just awaiting being uploaded > to the wxPython SF site. So it should be pretty soon. That's good news. > > Unfortunately I was also able to *install* it on Mac OS X 10.4/ > > Intel but it doesn't work (importing "wx" fails) because the > > binary modules in wx are for ppc while the running Python is x86. > > Right. About the only thing we could do at this point is to add a > command-line check on the architecture of the Python binary and bomb > out if it's incorrect. I could go ahead and add such a test, although > I think the OS X Installer will just give a generic "you are not > allowed to install this package" message, which is arguably just as > confusing to the user.... We could also add ppc to the filename, > though I think it will easily be missed. Yah, Apple's packaging tools are a pain. Great for braindead simple stuff, but quite limiting for anything custom. Trent -- Trent Mick TrentM at ActiveState.com From janssen at parc.com Mon Apr 17 22:58:20 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 17 Apr 2006 13:58:20 PDT Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: Your message of "Sat, 15 Apr 2006 21:21:04 PDT." Message-ID: <06Apr17.135822pdt."58633"@synergy1.parc.xerox.com> I'll add a note in bold on the python.org Macintosh downloads page saying not to remove the Apple-provided version. Bill From janssen at parc.com Mon Apr 17 23:15:44 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 17 Apr 2006 14:15:44 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Tue, 11 Apr 2006 06:25:52 PDT." Message-ID: <06Apr17.141547pdt."58633"@synergy1.parc.xerox.com> I see that Andrew Clover has submitted an update of his icons for Python. http://thread.gmane.org/gmane.comp.python.devel/78197/focus=78701 Bill From mcovill at mac.com Mon Apr 17 22:59:21 2006 From: mcovill at mac.com (Mike Covill) Date: Mon, 17 Apr 2006 16:59:21 -0400 Subject: [Pythonmac-SIG] Building apps with hardcoded options using py2app Message-ID: I would like to package up different versions of our application which we normally specify on the command line with different command line options. For example: myapp.py or myapp.py -sim Can I use py2app to make different 'double-clickable' applications that would give us the same functionality? If so, how? Where would I specify the options? Or should I make different versions of my main.py file for each configuration. Thanks, Mike From njriley at uiuc.edu Mon Apr 17 23:48:16 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 17 Apr 2006 16:48:16 -0500 Subject: [Pythonmac-SIG] Building apps with hardcoded options using py2app In-Reply-To: References: Message-ID: <20060417214816.GA27066@uiuc.edu> On Mon, Apr 17, 2006 at 04:59:21PM -0400, Mike Covill wrote: > I would like to package up different versions of our application > which we normally specify on the command line with different command > line options. For > example: > myapp.py > or > myapp.py -sim > > Can I use py2app to make different 'double-clickable' applications > that would give us the same functionality? If so, how? Where would > I specify the options? Use -argv-inject. python setup.py py2app --help for more information. -- Nicholas Riley | From daniellord at mac.com Tue Apr 18 01:35:36 2006 From: daniellord at mac.com (Daniel Lord) Date: Mon, 17 Apr 2006 16:35:36 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr17.141547pdt.58633@synergy1.parc.xerox.com> References: <06Apr17.141547pdt.58633@synergy1.parc.xerox.com> Message-ID: On Apr 17, 2006, at 14:15, Bill Janssen wrote: > I see that Andrew Clover has submitted an update of his icons for > Python. > > http://thread.gmane.org/gmane.comp.python.devel/78197/focus=78701 That's more like it IMHO though I was hoping for a little Aqua Jellybean bevels on the Blue & Yellow logo part ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060417/5ff7bc76/attachment.html From daniellord at mac.com Tue Apr 18 07:48:07 2006 From: daniellord at mac.com (Daniel Lord) Date: Mon, 17 Apr 2006 22:48:07 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <2mirp8l9jv.fsf@starship.python.net> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> Message-ID: I was able to successfully compile and install it with just a few tweaks on my Macbook Pro this evening. I don't know if this newbies methods are optimal, but they seem to have worked finally (I tried straight 'out of the box' compiles which failed at first) [daniello at mercury.local]$ sudo python setup.py build_ext -i gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup -flat_namespace -no-cpp-precomp build/temp.macosx-10.4-fat-2.4/_imagingtk.o build/temp.macosx-10.4- fat-2.4/Tk/tkImaging.o -L/Library/Frameworks/Python.framework/ Versions/2.4/lib -L/usr/local/lib -L/usr/lib -o PIL/_imagingtk.so - framework Tcl -framework Tk *** lines removed *** -------------------------------------------------------------------- PIL 1.1.5 BUILD SUMMARY -------------------------------------------------------------------- version 1.1.5 platform darwin 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] -------------------------------------------------------------------- --- TKINTER support ok --- JPEG support ok --- ZLIB (PNG/ZIP) support ok --- FREETYPE2 support ok -------------------------------------------------------------------- To check the build, run the selftest.py script. [daniello at mercury.local]$ python selftest.py 55 tests passed. SUCCESS! Here is what I did: I installed four things: 1. zlib: a straight forward curl, tar zxvf, ./configure, make, sudo make install curl http://www.gzip.org/zlib/zlib-1.1.4.tar.gz -o zlib-1.1.4.tar.gz 2. freetype: DL from SourceForge and straight forward tar zxvf, ./ configure, make, sudo make install 3. jpeg-6b: this is where the trouble started. curl http://www.ijg.org/files/jpegsrc.v6b.tar.gz -o jpegsrc.v6b.tar.gz a. after untarring and running ./configure, open 'Makefile' and change one line: CFLAGS= -O2 -no-cpp-precomp -I$(srcdir) to CFLAGS= -arch i386 -O2 -no-cpp-precomp -I$(srcdir) then 'make; sudo make install' b. then we have to put some manifest files the the lib in the right place to be found by PIL's build setup.py (I chose /usr/local) sudo cp jconfig.h jmorecfg.h jpeglib.h /usr/local/include sudo cp libjpeg.a /usr/local/lib sudo ranlib /usr/local/lib/libjpeg.a 4. PIL: this required some tweaking per instructions given in the setup.py to find the jpeg lib and manifests. curl http://effbot.org/downloads/Imaging-1.1.5.tar.gz -o Imaging-1.1.5.tar.gz a. bascially, change JPEG_ROOT = None to JPEG_ROOT = "(/usr/local/lib,/usr/local/include)" then 'sudo python setup.py build_ext -i' And success follows--at least for me ;-) From piet at cs.uu.nl Tue Apr 18 10:27:52 2006 From: piet at cs.uu.nl (Piet van Oostrum) Date: Tue, 18 Apr 2006 10:27:52 +0200 Subject: [Pythonmac-SIG] read content from latin-1 file, write it to ut8 file In-Reply-To: <60fae7c30604170949j46923b3do64bb2d5e24ab4728@mail.gmail.com> (frank h.'s message of "Mon, 17 Apr 2006 18:49:06 +0200") References: <60fae7c30604170949j46923b3do64bb2d5e24ab4728@mail.gmail.com> Message-ID: >>>>> "frank h." (FH) wrote: >FH> Hello, >FH> I am using Mac Python 2.4.1 on Mac OS X 10.4 and I cannot seem to be able to >FH> read from a latin-1 file and then write to a UTF8 file correctly >FH> Using Textwrangler on OS X, I create a latin-1 file with some special >FH> characters in it and save it as "test.txt" >FH> I am reading the textfile as such: >FH> f = codecs.open('test.txt', 'r', 'latin-1') >FH> content = f.read() >FH> f.close() >FH> type(content) >FH> >FH> all good. I can even >FH> print content.encode('utf8') >FH> ?????????????? >FH> (having set sys.defaultencoding to 'utf8' in siteconfig.py). >FH> Now I want to create a new utf8 file and write "content" into it. I do the >FH> following: >FH> f=codecs.open('newtest.txt','w','utf-8') >FH> f.write(content) >FH> f.close() >FH> my problem is, that when I open "newtest.txt" in Textwrangler again, >FH> Textwrangler recognizes the file as "MacRoman" encoded and the content is >FH> garbled. Then that is Textwrangler's fault. Interpreting a utf-8 file as MacRoman will indeed give garbage. Maybe you can configure Texwrangler to recognize utf-8 files. Otherwise use an editor that does this well. This is not a python problem, as the file should be (and probably is) generated in utf-8. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From jrus at fas.harvard.edu Tue Apr 18 12:01:06 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Tue, 18 Apr 2006 06:01:06 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <4444B8E2.2090404@fas.harvard.edu> Hi all, has wrote: > Indeed. The Python logo is just a badge to be applied to the larger > graphic(s)as necessary, in this case a family of four(?) OS X icons > representing an interactive Python editor (IDLE), .py document file, > .pyc/.pyo document file, and drag-n-drop script runner. The visual > language for representing text-based editors and document files on OS > X is extremely well established (e.g. compare Script Editor.app and > .scpt documents), and there's probably a fair bit of precedence for > the script runner too. So there's no reason that all of this shouldn't > be regarded as a wholly solved problem. If someone comes up with a finished "badge" (or even a good explanation of what this should be, as long as it's not overly complex), I can make py/pyc document icons. I have the Photoshop template for it, having just made several dozen TextMate document icons (included in version 1.5.1). What should a drag-n-drop script runner look like? I'm willing to do that too, if it's a simple enough job. > All it needs is somebody with some decent Photoshop compositing skills > (and maybe a nice 3D drawing of a technical pencil) to assemble the > finished elements. Let me know what the "finished elements" are, and I'm glad to assemble them. It hopefully shouldn't take more than an hour or two at most. -Jacob From Chris.Barker at noaa.gov Tue Apr 18 18:26:53 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 09:26:53 -0700 Subject: [Pythonmac-SIG] bin and version In-Reply-To: References: <1d987df30604081659w56d7159ag61f68e2e584715e8@mail.gmail.com> <24d517dd0604101002m7c7eba51s675d4431315ad25f@mail.gmail.com> Message-ID: <4445134D.1020306@noaa.gov> Saggau wrote: > You can show all hidden files in the finder, too. > > defaults write com.apple.finder AppleShowAllFiles -bool TRUE Or you can use a utility called "tinker Tool" if you google it, you should find it. It's very handy. Does anyone know if it's possible to show some hidden files, but not all? there are multiple reasons to hide files. For instance, I'd like to see all the "unixy" files, but not all the .* ones. -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 at noaa.gov From brianhray at gmail.com Tue Apr 18 18:28:07 2006 From: brianhray at gmail.com (Brian Ray) Date: Tue, 18 Apr 2006 11:28:07 -0500 Subject: [Pythonmac-SIG] Garbage Collection with Carbon Message-ID: <6a7a87b90604180928v2684e4a1w73845ab86d217b3d@mail.gmail.com> Hi Python Mac People: When I run the following: ### import sys,os import Carbon.File import Carbon.CF def fileurl(posix): fileref = Carbon.File.FSRef(posix) cfurl = Carbon.CF.CFURLCreateFromFSRef(fileref) filestr = cfurl.CFURLGetString() return filestr.CFStringGetString() if __name__ == "__main__": print fileurl("/tmp") ### I get: python(7038) malloc: *** error for object 0x3101f0: double free python(7038) malloc: *** set a breakpoint in szone_error to debug file://localhost/private/tmp/ Can anybody tell me what those errors mean? And BTW, does anybody know if this code works fine with an untouched Tiger install. I am considering making this an automater script and giving to some friends. Although, the script does not work at all in Automator but works on the command line with the result above. I wonder if this makes Automator think the script failed? tia, Brian Ray with running python -v I get more info: snip... # /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/Carbon/CF.pyc has bad mtime import Carbon.CF # from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/Carbon/CF.py # can't create /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/Carbon/CF.pyc dlopen("/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-dynload/_CF.so", 2); import _CF # dynamically loaded from /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-dynload/_CF.so python(7053) malloc: *** error for object 0x310200: double free python(7053) malloc: *** set a breakpoint in szone_error to debug file://localhost/private/tmp/ ... snip From ronaldoussoren at mac.com Tue Apr 18 19:15:44 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 18 Apr 2006 19:15:44 +0200 Subject: [Pythonmac-SIG] Garbage Collection with Carbon In-Reply-To: <6a7a87b90604180928v2684e4a1w73845ab86d217b3d@mail.gmail.com> References: <6a7a87b90604180928v2684e4a1w73845ab86d217b3d@mail.gmail.com> Message-ID: <684D8FB4-7791-4CF9-8A7A-0BB9715E823D@mac.com> On 18-apr-2006, at 18:28, Brian Ray wrote: > Hi Python Mac People: > > > When I run the following: > > ### > import sys,os > import Carbon.File > import Carbon.CF > > def fileurl(posix): > fileref = Carbon.File.FSRef(posix) > cfurl = Carbon.CF.CFURLCreateFromFSRef(fileref) > filestr = cfurl.CFURLGetString() > return filestr.CFStringGetString() > > if __name__ == "__main__": > > print fileurl("/tmp") > ### > > I get: > > > python(7038) malloc: *** error for object 0x3101f0: double free > python(7038) malloc: *** set a breakpoint in szone_error to debug > file://localhost/private/tmp/ > > Can anybody tell me what those errors mean? And BTW, does anybody know > if this code works fine with an untouched Tiger install. I am > considering making this an automater script and giving to some > friends. Although, the script does not work at all in Automator but > works on the command line with the result above. I wonder if this > makes Automator think the script failed? This means there's a bug in the Carbon wrappers. I can reproduce this with my universal build as well as /usr/bin/python. Ronald From janssen at parc.com Tue Apr 18 19:19:59 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 18 Apr 2006 10:19:59 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Tue, 18 Apr 2006 03:01:06 PDT." <4444B8E2.2090404@fas.harvard.edu> Message-ID: <06Apr18.102003pdt."58633"@synergy1.parc.xerox.com> > If someone comes up with a finished "badge" (or even a good explanation If you look in http://doxdesk.com/img/software/py/icons2.zip, you'll find a file called baselogo.svg. In the lower left corner of that figure, you'll find a shaded two-intertwined-snakes badge that is the new Python site logo. That's the "badge" has was referring to. Bill From hraban at fiee.net Tue Apr 18 21:40:38 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Tue, 18 Apr 2006 21:40:38 +0200 Subject: [Pythonmac-SIG] read content from latin-1 file, write it to ut8 file In-Reply-To: References: <60fae7c30604170949j46923b3do64bb2d5e24ab4728@mail.gmail.com> Message-ID: <2EEB755B-0CE8-4E4A-920A-AEA4EDAE93D0@fiee.net> Am 2006-04-18 um 10:27 schrieb Piet van Oostrum: >> FH> my problem is, that when I open "newtest.txt" in Textwrangler >> again, >> FH> Textwrangler recognizes the file as "MacRoman" encoded and the >> content is >> FH> garbled. > > Then that is Textwrangler's fault. Interpreting a utf-8 file as > MacRoman > will indeed give garbage. Maybe you can configure Texwrangler to > recognize > utf-8 files. Otherwise use an editor that does this well. This is > not a > python problem, as the file should be (and probably is) generated > in utf-8. You can define TW's default encoding and define a different encoding of some file in the Open dialogue or use the "re-open in another encoding" menu entry. Greetlings from Lake Constance! Hraban --- http://www.fiee.net http://www.cacert.org (I'm an assurer) From frank at niessink.com Tue Apr 18 21:57:10 2006 From: frank at niessink.com (Frank Niessink) Date: Tue, 18 Apr 2006 21:57:10 +0200 Subject: [Pythonmac-SIG] py2app includes all python documentation in the app Message-ID: <44454496.9050107@niessink.com> Hi all, I'm bundling an app with py2app. Somehow, py2app is including *all* python documentation. There are numerous messages by py2app like this one while building the app: copying /Library/Frameworks/Python.framework/Versions/2.4/Resources/English.lpro j/Documentation/acks.html -> /Users/frank/taskcoach/build/TaskCoach.app/Contents /Frameworks/Python.framework/Versions/2.4/Resources/English.lproj/Documentation Python 2.4.1 py2app 0.2 (wxPython 2.6.3.2 in case it matters) How can I find out why py2app is including the docs? I tried creating the dependency graph, but "grep Documentation TaskCoach.dot" comes up empty, so apparently it is not a dependency issue. It seems py2app is simply copying /Library/Frameworks/Python.framework/Versions/2.4/Resources/ and everything below it. Why? And how to prevent it? Thanks in advance, Frank From Chris.Barker at noaa.gov Tue Apr 18 22:22:05 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 13:22:05 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> Message-ID: <44454A6D.2030601@noaa.gov> Daniel, It would be great if you could post this summary to: http://pythonmac.org/wiki/UniversalPackages thanks, -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 at noaa.gov From kw at kevin-walzer.com Tue Apr 18 22:34:34 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Tue, 18 Apr 2006 16:34:34 -0400 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <44454A6D.2030601@noaa.gov> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> Message-ID: <44454D5A.2060502@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Barker wrote: > Daniel, > > It would be great if you could post this summary to: > > http://pythonmac.org/wiki/UniversalPackages > > thanks, -Chris > > > Is a universal package of Tcl/Tk (for Tkinter apps) something that others would find useful? I'm putting together one for my own purposes and would be glad to contribute it (or post a download link) when it's ready. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFERU1ZrTC5hIgjqTMRAlg9AJ90ibOdJM+S+/cQSW2qz1rDRtXFGACeKVtt HiHr+bbPqhdiUyJNXjx4iXI= =TiEN -----END PGP SIGNATURE----- From jrus at fas.harvard.edu Tue Apr 18 22:39:58 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Tue, 18 Apr 2006 16:39:58 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr18.102003pdt."58633"@synergy1.parc.xerox.com> References: <4444B8E2.2090404@fas.harvard.edu> <06Apr18.102003pdt."58633"@synergy1.parc.xerox.com> Message-ID: <44454E9E.8050609@fas.harvard.edu> >> If someone comes up with a finished "badge" (or even a good explanation > > If you look in http://doxdesk.com/img/software/py/icons2.zip, you'll > find a file called baselogo.svg. In the lower left corner of that > figure, you'll find a shaded two-intertwined-snakes badge that is the > new Python site logo. That's the "badge" has was referring to. Yeah, I've seen the new python logo. There was discussion of "macifying" it. If the suggestion is to just leave the logo as-is, here's an [example][1] of what the icon could look like. -Jacob [1]: http://hcs.harvard.edu/~jrus/python/Mac-Python-Document-Icon.zip From Chris.Barker at noaa.gov Tue Apr 18 23:02:26 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 14:02:26 -0700 Subject: [Pythonmac-SIG] 2.3 vs 2.4 In-Reply-To: References: Message-ID: <444553E2.3030702@noaa.gov> Robertson Holt wrote: > and got confused by this paragraph on the MacPython site, NOT python.org We've GOT to get that site updated! Is Jack around? -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 at noaa.gov From Chris.Barker at noaa.gov Tue Apr 18 23:02:41 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 14:02:41 -0700 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <443CFD7E.5060306@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> Message-ID: <444553F1.1060606@noaa.gov> Louis Pecora wrote: > I really do numerical calcs, but occasionally > need a simple GUI dialog or open a window to plot in (very simple) Take a look at wxmpl. It helps you embed a matplotlib window in a wxPython app. It's pretty handy, once you get the hang of wxPython. Also, depending on what kind of data you are looking at, wx.lib.floatcanvas might be useful (shameless plug, I wrote it) > I wish there were a way to keep the popup window with the > traceback info open, but it quickly closes and the app quits. > Redirecting found the error, but it is an extra step. This is a BBEdit thing, really, I find it easiest just to run from the terminal command line, and see your tracebacks there. For really simple stuff, you can just: app = wx.App() image=wx.Image('/Users/louispecora/Code/python/test_folder/wxPython_learn/rappin_cover150.jpg',wx.BITMAP_TYPE_JPEG) frame = Frame(image) frame.Show() app.MainLoop() I'm pretty sure the default wx.App directs errors to the console. -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 at noaa.gov From Chris.Barker at noaa.gov Tue Apr 18 23:14:57 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 14:14:57 -0700 Subject: [Pythonmac-SIG] talking points, Pythonismus In-Reply-To: <2DD4521E-D358-40EF-897D-5AB5E6912DB5@conncoll.edu> References: <2DD4521E-D358-40EF-897D-5AB5E6912DB5@conncoll.edu> Message-ID: <444556D1.604@noaa.gov> Charles Hartman wrote: >> Actually, I am using Matlab, which is dynamically typed as well, in >> some of my courses and I know it works well until types become >> important. Matlab is a far cry from Python, as a programing language. Indeed, until recent versions, it was not the least bit dynamically typed, every variable was a matrix of doubles. It had some tricks for interpreting them as integers, booleans, or strings in some cases, but that was all there was. More recent versions do support other "real" data types, but the it's really more "weakly typed" than dynamically typed. Python's dynamic type system, is in fact, quite strongly typed. A given Python object is one type, and one type only and will not be interpreted differently depending on context. NAMES are not typed, but OBJECTS are. There can still be a bit of confusion when the same name refers to different objects of different types at different places in the code, but it's not as bad as Matlab. As for Matlab vs. Python: Anyone using Matlab, but feeling like it's not a "real" enough language for more powerful use, or to teach more about programming, should really look into using numpy (and SciPy). It gives you a powerful flexible array data type, similar to Matlab's but more powerful. And it gives you all the power and flexibility of Python. Numpy arrays are essentially statically typed: when they are created you define the size, shape and data type, so they can really teach a lot about data typing. >> Sometimes they claim that the program >> (the interpreter) isn't working right. and people also wonder why: x = 0.0 while x != 10.0: x + 0.1 never terminates. In any language. It's an opportunity for teaching. In fact, if you make a data type mistake in C, you get a segfault, or totally bogus results. People don't blame the compiler, because they expect C to be hard. The fact that users blame the interpreter is because most of time things do work as expected! I agree with another poster (and Joel Spolsky), that really learning about things like data types, pointers, recursion, etc, is critical to being a computer scientist, or a truly versatile programmer. However: 1) A lot of people can benefit from knowing how to do some programming that are not ever going to be computer scientists or professional programmers: Python gives them a very useful tool for a wide variety of programming needs, without the painful learning curve. 2) Even if someone is going to become a computer scientist or professional programmer, why do they need to learn all those painful details first? I think Python provides an excellent introduction to a lot of what programming is about, and it can be later supplemented with a course in Lisp, or C, C++ ,or even JAVA, later. Frankly, I wouldn't call anyone a "real" programmer that has only used one language. Any one language. In some ways, JAVA is the worse choice: you don't learn about the nitty gritty details of pointers and memory management that you get from C, and you don't get the high-level power and flexibility or Python either! -Chris Does that help? -- 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 at noaa.gov From Chris.Barker at noaa.gov Tue Apr 18 23:48:53 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 14:48:53 -0700 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> Message-ID: <44455EC5.6060401@noaa.gov> Ronald Oussoren wrote: > On 13-apr-2006, at 18:47, Zachary Pincus wrote: >> Also, a related query: Is there somewhere in the Python Framework >> structure that is appropriate for placing dynamic libraries that >> Python would link to? > I don't see what this would buy us. It is possible to do this, but > IMHO not really worth the trouble. I don't think it would buy anything for readline, but it would for libs that are used by multiple python extensions, like libpng and libfreetype, for instance. -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 at noaa.gov From jrus at fas.harvard.edu Wed Apr 19 00:06:54 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Tue, 18 Apr 2006 18:06:54 -0400 Subject: [Pythonmac-SIG] Psycho & 2.4.3 universal Message-ID: <444562FE.6080703@fas.harvard.edu> Hi, I couldn't compile [psyco][1] using the 2.4.3 universal version of Python on my 12" powerbook. I'm wondering if this is just a problem with universal Python, or if psycho doesn't compile in general under OS X. Thanks for any help, -Jacob [1]: http://psyco.sourceforge.net/ Here's what the terminal output looked like: $python setup.py build PROCESSOR = 'ivm' running build running build_py running build_ext building 'psyco._psyco' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -DALL_STATIC=1 -Ic/ivm -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c c/psyco.c -o build/temp.macosx-10.4-fat-2.4/c/psyco.o In file included from c/initialize.h:46, from c/psyco.c:14: c/dispatcher.c: In function ?do_promotion_internal?: c/dispatcher.c:1794: error: invalid lvalue in assignment In file included from c/initialize.h:46, from c/psyco.c:14: c/dispatcher.c: In function ?do_promotion_internal?: c/dispatcher.c:1794: error: invalid lvalue in assignment In file included from c/initialize.h:48, from c/psyco.c:14: c/psyfunc.c: In function ?psyco_proxycode?: c/psyfunc.c:633: warning: pointer targets in passing argument 1 of ?PyString_FromStringAndSize? differ in signedness In file included from c/initialize.h:48, from c/psyco.c:14: c/psyfunc.c: In function ?psyco_proxycode?: c/psyfunc.c:633: warning: pointer targets in passing argument 1 of ?PyString_FromStringAndSize? differ in signedness lipo: can't figure out the architecture type of: /var/tmp//ccUTzkfB.out error: command 'gcc' failed with exit status 1 From pecora at anvil.nrl.navy.mil Wed Apr 19 00:13:07 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Tue, 18 Apr 2006 18:13:07 -0400 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <444553F1.1060606@noaa.gov> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <444553F1.1060606@noaa.gov> Message-ID: <44456473.7030401@anvil.nrl.navy.mil> Christopher Barker wrote: > Louis Pecora wrote: >> I really do numerical calcs, but occasionally need a simple GUI >> dialog or open a window to plot in (very simple) > > Take a look at wxmpl. It helps you embed a matplotlib window in a > wxPython app. It's pretty handy, once you get the hang of wxPython. > Also, depending on what kind of data you are looking at, > wx.lib.floatcanvas might be useful (shameless plug, I wrote it) > >> I wish there were a way to keep the popup window with the traceback >> info open, but it quickly closes and the app quits. Redirecting >> found the error, but it is an extra step. > > This is a BBEdit thing, really, I find it easiest just to run from the > terminal command line, and see your tracebacks there. > > For really simple stuff, you can just: > > app = wx.App() > image=wx.Image('/Users/louispecora/Code/python/test_folder/wxPython_learn/rappin_cover150.jpg',wx.BITMAP_TYPE_JPEG) > > frame = Frame(image) > frame.Show() > app.MainLoop() > > I'm pretty sure the default wx.App directs errors to the console. > > wxmpl ? Yet another GUI. :-) Well, that's good. I'll check it out. I did get PythonCard and it looks pretty good, too. Nice to have a choice. Now EVERYONE STOP. NO MORE. :-) I got around the loss of Traceback. wxPython has a mechanism to set the redirection. Just putting it to False causes the usual Terminal output. So that now works. (Yes, it was in the book.) -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From jrus at fas.harvard.edu Wed Apr 19 00:11:45 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Tue, 18 Apr 2006 18:11:45 -0400 Subject: [Pythonmac-SIG] Psycho & 2.4.3 universal In-Reply-To: <444562FE.6080703@fas.harvard.edu> References: <444562FE.6080703@fas.harvard.edu> Message-ID: <44456421.5010407@fas.harvard.edu> I wrote: > I couldn't compile [psyco][1] using the 2.4.3 universal version of > Python on my 12" powerbook. I'm wondering if this is just a problem > with universal Python, or if psycho doesn't compile in general under OS X. Argh, never mind that message. I see now that psyco is clearly labeled as only working on i386. Nothing to see here, move along. -Jacob From Chris.Barker at noaa.gov Wed Apr 19 00:16:07 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 18 Apr 2006 15:16:07 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <44454D5A.2060502@kevin-walzer.com> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <44454D5A.2060502@kevin-walzer.com> Message-ID: <44456527.6040601@noaa.gov> Kevin Walzer wrote: > Is a universal package of Tcl/Tk (for Tkinter apps) something that > others would find useful? Isn't it part of the new Universal build? If not, then yes, please do contribute it. -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 at noaa.gov From daniellord at mac.com Wed Apr 19 00:18:46 2006 From: daniellord at mac.com (Daniel Lord) Date: Tue, 18 Apr 2006 15:18:46 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <44454A6D.2030601@noaa.gov> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> Message-ID: Chris, I will do that but as it stands, one has to build this on the system it is going to run on, i.e. i386. I assume, but haven't gotten around to trying to build this on my PPC system since there is a valid build for that already. First, I am going to create a package for this for i386-based Macs and see if I can write a script to do the whole thing 'auto- magically'. Then I'll write the instructions up. Which leads me to a philosophical question for the community: which makes since for things like this as a standard practice for distribution (ranging from hardest to easiest) 1) to create a package with copies of the libraries used as Universal 'FAT' binaries (zlib, freetype2, jpeg-6b) not to mention PIL as well that will install correctly for PPC or i386 systems but include useless binary versions and take up space, 2) have two separate 'chunks' and have the installer select one based on the installation platform, or 3) just provide two separate packages--one for i386 and one for PPC? Daniel On Apr 18, 2006, at 13:22, Christopher Barker wrote: > Daniel, > > It would be great if you could post this summary to: > > http://pythonmac.org/wiki/UniversalPackages > > thanks, -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 at noaa.gov From kernel at troniczoo.net Wed Apr 19 00:35:55 2006 From: kernel at troniczoo.net (kernel) Date: Tue, 18 Apr 2006 23:35:55 +0100 Subject: [Pythonmac-SIG] talking points, Pythonismus In-Reply-To: <444556D1.604@noaa.gov> References: <2DD4521E-D358-40EF-897D-5AB5E6912DB5@conncoll.edu> <444556D1.604@noaa.gov> Message-ID: <9deb7b0a86ab2ea2e1e168ad98712460@troniczoo.net> On 18 Apr 2006, at 22:14, Christopher Barker wrote: > 1) A lot of people can benefit from knowing how to do some programming > that are not ever going to be computer scientists or professional > programmers: Python gives them a very useful tool for a wide variety of > programming needs, without the painful learning curve. > > 2) Even if someone is going to become a computer scientist or > professional programmer, why do they need to learn all those painful > details first? I think Python provides an excellent introduction to a > lot of what programming is about, and it can be later supplemented with > a course in Lisp, or C, C++ ,or even JAVA, later. Frankly, I wouldn't > call anyone a "real" programmer that has only used one language. Any > one > language. which is why so many languages exist? I've though for a while that it's possible to become 'over trained' on one language (borrowing the term from neural nets) which can make it difficult to see the benefits of different approaches. From advertising at robbstucky.net Tue Apr 18 22:59:27 2006 From: advertising at robbstucky.net (Advertising Department) Date: Tue, 18 Apr 2006 16:59:27 -0400 Subject: [Pythonmac-SIG] Mac Python is DEAD Message-ID: (I'm totally confused about the nine versions of python for Mac OS X, the defunct or just not updated for 2 years MacPython pages, the current state of the macintosh specific library modules, etc.) To give my 2 cents... It doesn't really matter about a logo, icon, or universal build. If there is no recent info on the OFFICIAL python.org linked web pages, most new users will think it's become defunct, and look no further. NEWS April 2, 2004 MacPython 2.3.3 for Jaguar and MacPython-OS9 2.3.3 have finally been released. And on April 18, 2006, having no other information, we must assume in the last two years it's become totally stale, defunct and forgotten. Too bad. I guess I'll have to mess around with Java or Ruby. Doing a Google search produces way too much antique information for a newbie to sort thru, and just re-inforces the implication that python on Mac is dead. COME ON GUYS, get something up on the web page. ANYTHING!!! Point us to this list and tell us you've been too busy to mess around with newbie info. De-link Jack's pages from the Main page, and put up a list of current resources. ANYTHING that shows current activity!! From layne.bilyeu at robbstucky.net Wed Apr 19 00:33:54 2006 From: layne.bilyeu at robbstucky.net (corporate user) Date: Tue, 18 Apr 2006 18:33:54 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion Message-ID: Is this the right place to be asking stupid newbie questions about Mac OS X python issues? Most of the discussions here are way over my head. I have a python script that does not work after being transformed by py2app or py2applet. (it was originally written in macPython 2.33, Mac OS 9 and was happy as an applet under os 9) This script takes full paths as arguments to argv, does PIL transformations to the files and spits copies out to the same directory that the script was launched from. It works successfully in command line form. It seems to pass thru py2app happily using either a setup.py script or dropping onto py2applet. Dropping items onto the produced app causes it to launch. Console records my print statements as if it was working. But no files are generated. Is there some path magic that needs to be explicitly defined into my script to compensate when converting from a simple command line script to the full tree structure of a Mac OS X bundle? Or are there permissions surprises? Thanks From kernel at troniczoo.net Wed Apr 19 00:50:24 2006 From: kernel at troniczoo.net (kernel) Date: Tue, 18 Apr 2006 23:50:24 +0100 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: References: Message-ID: On 18 Apr 2006, at 21:59, Advertising Department wrote: > (I'm totally confused about the nine versions of python for Mac OS X, > the defunct or just not updated for 2 years MacPython pages, the > current state of the macintosh specific library modules, etc.) > > To give my 2 cents... > It doesn't really matter about a logo, icon, or universal build. If > there is no recent info on the OFFICIAL python.org linked web pages, > most new users will think it's become defunct, and look no further. I'm a new user too but I've never got the impression MacPython is dead. the presence of a Universal Binary suggests to me it's still alive. From janssen at parc.com Wed Apr 19 01:00:32 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 18 Apr 2006 16:00:32 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Tue, 18 Apr 2006 13:39:58 PDT." <44454E9E.8050609@fas.harvard.edu> Message-ID: <06Apr18.160038pdt."58633"@synergy1.parc.xerox.com> > Yeah, I've seen the new python logo. There was discussion of > "macifying" it. If the suggestion is to just leave the logo as-is, > here's an [example][1] of what the icon could look like. There's the flat logo, but the logo I was pointing to was a version that's shaded a bit to look slightly raised and rounded. Bill From charles.hartman at conncoll.edu Wed Apr 19 01:02:46 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 18 Apr 2006 19:02:46 -0400 Subject: [Pythonmac-SIG] talking points, Pythonismus In-Reply-To: <444556D1.604@noaa.gov> References: <2DD4521E-D358-40EF-897D-5AB5E6912DB5@conncoll.edu> <444556D1.604@noaa.gov> Message-ID: <69E6A931-7CAD-4C95-A586-3D0A5E2F88AB@conncoll.edu> On Apr 18, 2006, at 5:14 PM, Christopher Barker wrote: > Does that help? It does. Thanks -- and also to others who answered my request for ammo, in case I get to engage on the Python side. I don't think my CompSci is going to listen to a Prof of English, and I can't push too hard; but it's good to be armed in case. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060418/41fc1a1e/attachment.htm From janssen at parc.com Wed Apr 19 01:05:19 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 18 Apr 2006 16:05:19 PDT Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: Your message of "Tue, 18 Apr 2006 13:59:27 PDT." Message-ID: <06Apr18.160523pdt."58633"@synergy1.parc.xerox.com> Advertising Department, In my opinion, the problem is the term "MacPython". Python is Python, period, and we should just call it that, even if it's running on the Mac platform. Perhaps this was different in the pre-OSX days, but not now. I'd be happy to go though all the pages on python.org and stamp out references to "MacPython". But the NEWS section of python.org is totally disfunctional. Months go by without anyone bothering to add anything to it; I think the trouble is that no one knows what the "add" procedure is. Bill From charles.hartman at conncoll.edu Wed Apr 19 01:07:34 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 18 Apr 2006 19:07:34 -0400 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: References: Message-ID: <6BDB3EA6-E393-444E-BAFC-79DBFD1673F2@conncoll.edu> It seems to me that it would be a good idea to UNLINK this site (http://homepages.cwi.nl/~jack/macpython/) -- remove all links to it from pythonmac.org, to begin with. In fact, I'd call it urgent. Charles Hartman On Apr 18, 2006, at 4:59 PM, Advertising Department wrote: > (I'm totally confused about the nine versions of python for Mac OS X, > the defunct or just not updated for 2 years MacPython pages, the > current state of the macintosh specific library modules, etc.) > > To give my 2 cents... > It doesn't really matter about a logo, icon, or universal build. If > there is no recent info on the OFFICIAL python.org linked web pages, > most new users will think it's become defunct, and look no further. > NEWS > > April 2, 2004 MacPython 2.3.3 for Jaguar and MacPython-OS9 2.3.3 have > finally been released. > > And on April 18, 2006, having no other information, we must assume in > the last two years it's become totally stale, defunct and forgotten. > Too bad. I guess I'll have to mess around with Java or Ruby. > > Doing a Google search produces way too much antique information for a > newbie to sort thru, and just re-inforces the implication that python > on Mac is dead. > > COME ON GUYS, get something up on the web page. ANYTHING!!! Point us > to this list and tell us you've been too busy to mess around with > newbie info. De-link Jack's pages from the Main page, and put up a > list of current resources. > > ANYTHING that shows current activity!! > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From cwmoad at gmail.com Wed Apr 19 01:09:57 2006 From: cwmoad at gmail.com (Charlie Moad) Date: Tue, 18 Apr 2006 19:09:57 -0400 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: References: Message-ID: <6382066a0604181609u793e9118o67eb10ea5a42f009@mail.gmail.com> On 4/18/06, kernel wrote: > On 18 Apr 2006, at 21:59, Advertising Department wrote: > > > (I'm totally confused about the nine versions of python for Mac OS X, > > the defunct or just not updated for 2 years MacPython pages, the > > current state of the macintosh specific library modules, etc.) > > > > To give my 2 cents... > > It doesn't really matter about a logo, icon, or universal build. If > > there is no recent info on the OFFICIAL python.org linked web pages, > > most new users will think it's become defunct, and look no further. > > I'm a new user too but I've never got the impression MacPython is dead. > the presence of a Universal Binary suggests to me it's still alive. Hmm, I go to python.org and right in my face: Universal Mac OSX binary for Python 2.4.3. Thanks for all the hard work on making this new build guys. Especially for getting rid of the need for pythonw. If you google "mac python" you might get those older pages, but those should be left there for several reasons. My 2 cents, Charlie From janssen at parc.com Wed Apr 19 01:26:17 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 18 Apr 2006 16:26:17 PDT Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: Your message of "Tue, 18 Apr 2006 13:59:27 PDT." Message-ID: <06Apr18.162618pdt."58633"@synergy1.parc.xerox.com> > To give my 2 cents... > It doesn't really matter about a logo, icon, or universal build. If > there is no recent info on the OFFICIAL python.org linked web pages, > most new users will think it's become defunct, and look no further. Apparently this guy got past the main python.org page, with news about the Universal Binary, and also skipped the downloads/Macintosh section. Instead, he went straight to the Macintosh documentation (not unreasonable), which starts with "Using Python on a Macintosh", which points to Jack's defunct site. Now let's fix the documentation... Bill From janssen at parc.com Wed Apr 19 01:37:34 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 18 Apr 2006 16:37:34 PDT Subject: [Pythonmac-SIG] fixing the Mac documentation Message-ID: <06Apr18.163743pdt."58633"@synergy1.parc.xerox.com> Fred, I'd like to fix the Mac documentation. I believe I need checkin rights to the python/trunk/Doc svn subdirectory to do that. Is that right? Bill From tcj25 at cam.ac.uk Wed Apr 19 01:46:07 2006 From: tcj25 at cam.ac.uk (Terry Jones) Date: Wed, 19 Apr 2006 01:46:07 +0200 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: Your message at 16:05:19 on Tuesday, 18 April 2006 References: <06Apr18.160523pdt."58633"@synergy1.parc.xerox.com> Message-ID: <17477.31295.810249.739050@terry.jones.tc> | In my opinion, the problem is the term "MacPython". Python is Python, | period, and we should just call it that, even if it's running on the Mac | platform. Perhaps this was different in the pre-OSX days, but not now. Make that 4 cents on dropping the "Mac". The MacPython name is, to my ears, quite misleading. Terry From alex at tweedly.net Wed Apr 19 02:13:58 2006 From: alex at tweedly.net (Alex Tweedly) Date: Wed, 19 Apr 2006 01:13:58 +0100 Subject: [Pythonmac-SIG] wxPython -- some disappointment using it. In-Reply-To: <44456473.7030401@anvil.nrl.navy.mil> References: <443C22F8.3080706@anvil.nrl.navy.mil> <443C4514.9030305@anvil.nrl.navy.mil> <443CFD7E.5060306@anvil.nrl.navy.mil> <444553F1.1060606@noaa.gov> <44456473.7030401@anvil.nrl.navy.mil> Message-ID: <444580C6.804@tweedly.net> Louis Pecora wrote: >Christopher Barker wrote: > > >>Louis Pecora wrote: >> >> >>>I really do numerical calcs, but occasionally need a simple GUI >>>dialog or open a window to plot in (very simple) >>> >>> >>Take a look at wxmpl. It helps you embed a matplotlib window in a >>wxPython app. It's pretty handy, once you get the hang of wxPython. >>Also, depending on what kind of data you are looking at, >>wx.lib.floatcanvas might be useful (shameless plug, I wrote it) >> >> >> >wxmpl ? Yet another GUI. :-) Well, that's good. I'll check it >out. I did get PythonCard and it looks pretty good, too. Nice to have >a choice. Now EVERYONE STOP. NO MORE. :-) > > > wxmpl isn't another GUI - it's what you use to embed matplotlib windows within wxPython (and therefore also can be used to embed them within PythonCard); telling you about wxmpl is in response to the part of your original post saying "or open a window to plot in" -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.3/316 - Release Date: 17/04/2006 From janssen at parc.com Wed Apr 19 02:23:10 2006 From: janssen at parc.com (Bill Janssen) Date: Tue, 18 Apr 2006 17:23:10 PDT Subject: [Pythonmac-SIG] Fixing the documentation... Message-ID: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> Just looking at the docs, I'm trying to figure out what's good and what's bad. 1) We should no longer point people to Jack's site, we point them to the python.org Mac download page instead. 2) references to PythonIDE and PackageManager should go. 3) What about the following: 2. MacPython Modules 2.1 macpath -- MacOS path manipulation functions 2.2 macfs -- Various file system services 2.2.1 FSSpec Objects 2.2.2 Alias Objects 2.2.3 FInfo Objects 2.3 ic -- Access to Internet Config 2.3.1 IC Objects 2.4 MacOS -- Access to Mac OS interpreter features 2.5 macostools -- Convenience routines for file manipulation 2.6 findertools -- The finder's Apple Events interface 2.7 EasyDialogs -- Basic Macintosh dialogs 2.7.1 ProgressBar Objects 2.8 FrameWork -- Interactive application framework 2.8.1 Application Objects 2.8.2 Window Objects 2.8.3 ControlsWindow Object 2.8.4 ScrolledWindow Object 2.8.5 DialogWindow Objects 2.9 autoGIL -- Global Interpreter Lock handling in event loops 3. MacPython OSA Modules 3.1 gensuitemodule -- Generate OSA stub packages 3.2 aetools -- OSA client support 3.3 aepack -- Conversion between Python variables and AppleEvent data containers 3.4 aetypes -- AppleEvent objects 3.5 MiniAEFrame -- Open Scripting Architecture server support 3.5.1 AEServer Objects 4. MacOS Toolbox Modules 4.1 Carbon.AE -- Apple Events 4.2 Carbon.AH -- Apple Help 4.3 Carbon.App -- Appearance Manager 4.4 Carbon.CF -- Core Foundation 4.5 Carbon.CG -- Core Graphics 4.6 Carbon.CarbonEvt -- Carbon Event Manager 4.7 Carbon.Cm -- Component Manager 4.8 Carbon.Ctl -- Control Manager 4.9 Carbon.Dlg -- Dialog Manager 4.10 Carbon.Evt -- Event Manager 4.11 Carbon.Fm -- Font Manager 4.12 Carbon.Folder -- Folder Manager 4.13 Carbon.Help -- Help Manager 4.14 Carbon.List -- List Manager 4.15 Carbon.Menu -- Menu Manager 4.16 Carbon.Mlte -- MultiLingual Text Editor 4.17 Carbon.Qd -- QuickDraw 4.18 Carbon.Qdoffs -- QuickDraw Offscreen 4.19 Carbon.Qt -- QuickTime 4.20 Carbon.Res -- Resource Manager and Handles 4.21 Carbon.Scrap -- Scrap Manager 4.22 Carbon.Snd -- Sound Manager 4.23 Carbon.TE -- TextEdit 4.24 Carbon.Win -- Window Manager 4.25 ColorPicker -- Color selection dialog 5. Undocumented Modules 5.1 applesingle -- AppleSingle decoder 5.2 buildtools -- Helper module for BuildApplet and Friends 5.3 cfmfile -- Code Fragment Resource module 5.4 icopen -- Internet Config replacement for open() 5.5 macerrors -- Mac OS Errors 5.6 macresource -- Locate script resources 5.7 Nav -- NavServices calls 5.8 PixMapWrapper -- Wrapper for PixMap objects 5.9 videoreader -- Read QuickTime movies 5.10 W -- Widgets built on FrameWork 5.11 waste -- non-Apple TextEdit replacement My inclination is to delete them all :-). Except for ones where someone pipes up and tells me it still works. Let folks use the Wiki to find modules. 4) Should we document some of the newer stuff? py2app comes to mind. Bill From daniellord at mac.com Wed Apr 19 02:25:00 2006 From: daniellord at mac.com (Daniel Lord) Date: Tue, 18 Apr 2006 17:25:00 -0700 Subject: [Pythonmac-SIG] Mac Python is DEAD...Long Live Python on the Mac In-Reply-To: <17477.31295.810249.739050@terry.jones.tc> References: <06Apr18.160523pdt.58633@synergy1.parc.xerox.com> <17477.31295.810249.739050@terry.jones.tc> Message-ID: On Apr 18, 2006, at 16:46, Terry Jones wrote: > | In my opinion, the problem is the term "MacPython". Python is > Python, > | period, and we should just call it that, even if it's running on > the Mac > | platform. Perhaps this was different in the pre-OSX days, but > not now. > > Make that 4 cents on dropping the "Mac". The MacPython name is, to > my ears, > quite misleading. In fact, in my view, MacPython was the special build for OS 9 and earlier. I have never thought of the OS X distributions as 'MacPython' but rather Python for OS X just as Python for Red Hat Linux are still Python, just packaged and bundled as RPMs in order to install and work properly on the Red Hat Linux platform. I noticed the web information is trending in that direction, let's just make a clean break. Even if John Dvorak thinks Apple and OS X are doomed ;-) On another topic, we need to archive and keep available Jack Jansen's work. Jack made a great contribution to Python on the Mac, more than I think any other single individual, and one that should not be forgotten. Really. Link to it from the wiki and make it clear it is historical in nature and pioneering work by a key individual. MacPython _is_ dead (but not forgotten), Long live Python on the Mac. From layne.bilyeu at robbstucky.net Wed Apr 19 03:27:38 2006 From: layne.bilyeu at robbstucky.net (corporate user) Date: Tue, 18 Apr 2006 21:27:38 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: References: Message-ID: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> On Apr 18, 2006, at 8:44 PM, Bob Ippolito wrote: > > Print the paths and make sure they are what you expect them to be. > Without seeing the script there's little else I can tell you. > Thanks, didn't know if stupid newbie noise is acceptable here. Very simple beginner script. Not sure why it doesn't write files after py2appletizing. Seems to work just fine from the command line. What am I missing? ---------------------------- #!/usr/bin/env pythonw """ imageSizer - drag & drop image files onto this applet: Will create 2 Jpg files, names appended with a letter A - 432x432 pixels B - 150x150 pixels and will add whitespace to make images Square. """ import os, sys import Image, ImageFilter indent = " " BICUBIC = 3 ###Image module broke? so define it's constant here def main(): for infile in sys.argv[1:]: try: im = Image.open(infile) namebase = os.path.splitext(os.path.basename(infile)) [0] print "\n" + namebase ##strip B.S. from end of name (assume SKU number 15 digits) ##a regular expression would be better, ##if I could figure out the random logic users name things with namebase = namebase[0:15] width, height = im.size print indent + str(im.format) + indent + "width %d, height %d" % (width, height) if width != height: print indent + "Alert! Image is not square!" im = adjustsize(im) makeAsize(im, namebase) makeBsize(im, namebase) except IOError, errMsg: print "Caught Error\n" + str(errMsg) def adjustsize(daimage): width, height = daimage.size if width > height: print indent + "--wide image, space needed on top & bottom" spacer = (width - height)/2 print indent + " creating new image %d x %d" % (width, width) newimage = Image.new("RGB", (width, width), (255, 255, 255)) newimage.paste( daimage, (0, spacer) ) else: print indent + "--tall image, space needed on sides" spacer = (height - width)/2 print indent + " creating new image %d x %d" % (height, height) newimage = Image.new("RGB", (height, height), (255, 255, 255)) newimage.paste( daimage, (spacer, 0) ) return newimage def makeAsize(image, basename): outname = basename + "A" + ".jpg" print indent + "--creating " + outname out = image.resize( (432,432), BICUBIC) out.save(outname, "JPEG") def makeBsize(image, basename): outname = basename + "B" + ".jpg" print indent + "--creating " + outname out = image.resize( (150,150), BICUBIC) out.save(outname, "JPEG") if __name__ == '__main__': main() From jwt at onjapan.net Wed Apr 19 07:05:09 2006 From: jwt at onjapan.net (Jim Tittsler) Date: Wed, 19 Apr 2006 14:05:09 +0900 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> Message-ID: On Apr 19, 2006, at 10:27, corporate user wrote: > On Apr 18, 2006, at 8:44 PM, Bob Ippolito wrote: >> >> Print the paths and make sure they are what you expect them to be. >> Without seeing the script there's little else I can tell you. > > Very simple beginner script. Not sure why it doesn't write files > after py2appletizing. > Seems to work just fine from the command line. What am I missing? As Bob suggested, you do not appear to be specifying the paths for output files. You could use os.chdir() or include the path in your 'namebase' so that it gets included in 'outname'. > BICUBIC = 3 ###Image module broke? so define it's constant here BICUBIC = Image.BICUBIC (And it's "its." :-) But you should find out why your PIL is broken. -- Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6 Python Starship http://Starship.Python.net/ Ringo MUG Tokyo http://www.ringo.net/rss.html From daniellord at mac.com Wed Apr 19 07:38:20 2006 From: daniellord at mac.com (Daniel Lord) Date: Tue, 18 Apr 2006 22:38:20 -0700 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> Message-ID: <4416D0C4-4879-44FD-AA06-4716E94FA401@mac.com> On Apr 18, 2006, at 22:05, Jim Tittsler wrote: > >> BICUBIC = 3 ###Image module broke? so define it's constant here > BICUBIC = Image.BICUBIC > > (And it's "its." :-) But you should find out why your PIL is broken. Hey, I am taking a break an a little so I'll 'nit pick' English: It isn't actually clear (to me) whether he's wrong or not: he could mean the contraction 'it is' as in 'so define [that] it is constant here' as opposed to the possessive "define it's constant" . If the former, his usage was correct, if the latter your correction was warranted. Just pointing out that the use is ambiguous to someone who has no idea whether this is Bicubic interpolation or B-splines or whatever. I'll settle down and go away now that I've had my fun-- been that kind of day. I'll bet you _are_ right though ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060418/20d32ac1/attachment.htm From cygnusx1 at mac.com Wed Apr 19 02:23:32 2006 From: cygnusx1 at mac.com (Tom Bridgman) Date: Tue, 18 Apr 2006 20:23:32 -0400 Subject: [Pythonmac-SIG] Creating an 'inventory' of PYTHONPATH modules? Message-ID: <19473839e83d39eedc05184f466c129d@mac.com> This not be the right list for this but maybe someone can point me in the right direction. Apologies in advance. In my day job, I work in an environment with many (>10) Mac OS X & Linux boxes and python is getting a fair amount of usage. Unfortunately, a number of us have custom installations (home directory site-packages, modules in /usr/lib and /usr/local/lib trees, etc.) since root access is tightly controlled. There's now talk of 'standardizing' our installations but the idea of tracking down all the modules/versions etc. in use across multiple machines is daunting. The goal is to NFS mount these installations in a shared directory (probably separated by platform). Performing custom installations on each system via package manager or similar mechanism is just not practical in our environment. Has anyone written a (presumably python) package that could collect a listing of all the modules accessible through PYTHONPATH, possibly including version information and dependencies? Google searches revealed some ASPN recipes that are similar to what I seek but not quite there. Ideas? Thanks, Tom -- W.T. Bridgman, Ph.D. Physics & Astronomy From layne.bilyeu at robbstucky.net Wed Apr 19 15:38:23 2006 From: layne.bilyeu at robbstucky.net (corporate user) Date: Wed, 19 Apr 2006 09:38:23 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> Message-ID: <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> Many thanks to you Bob. You're a community treasure. > Also note that the Image module probably isn't broken (don't have > PIL installed at the moment, can't check). Constants don't > automagically just insert themselves into your script. You should > be able to reference it with Image.BICUBIC. yes, referencing Image.BICUBIC works correctly. As usual my problems lie with the scope. I'm forming the opinion that "from XXX import *" should be banned from all introduction, tutorial and example materials. It encourages naive assumptions about things automagically inserting themselves into your namespace. Everything seems simple when following the examples. But when you try paraphrasing them for your own work, it blows up in your face. It would be better to provide beginners an understanding of namespaces from the start. From hengist.podd at virgin.net Wed Apr 19 15:38:22 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 14:38:22 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> References: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> Message-ID: Bill Janssen wrote: >1) We should no longer point people to Jack's site, we point them to > the python.org Mac download page instead. Agree. Having links to the old MacPython site in places where folk expect to find up-to-date information doesn't help. Also, if there's somewhere to provide a list of highly respected Python contributors, make sure Jack's name is up there accompanied by his site link for posterity. Wouldn't want the removal of obsolete links from the main body of documentation to look like a writing out of history of the Jack and his terrific contribution to Mac Python over the years. >Just looking at the docs, I'm trying to figure out what's good and >what's bad. > >2) references to PythonIDE and PackageManager should go. Sounds fine to me. They're related products, not part of the core Python distribution, so shouldn't be any problem eliminating mention of those from the documentation. Might need to put in a short page about IDLE to replace the old Python IDE section. In addition, all mentions of OS 9 should either be expunged (e.g. the 'using Python on Mac OS 9' chapter) or changed to 'not supported' (should they still need to be documented for any reason). >3) What about the following: > > 2. MacPython Modules Well, it feels tempting at times just do a straight delete on this too. However: these modules are all part of the official distribution, so I would imagine that any to be dropped needs to go through the full deprecation procedure first. > 2.1 macpath -- MacOS path manipulation functions Deprecate. Also note that the 2.4.3 documentation now says "It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform)." which is incorrect (it uses POSIX-style paths), so delete that sentence. > 2.2 macfs -- Various file system services Already deprecated as of 2.3. Delete yet? > 2.3 ic -- Access to Internet Config No idea about this. Anyone else know if this is still working/relevant? > 2.4 MacOS -- Access to Mac OS interpreter features Get/SetCreatorAndType should really be fixed or deprecated as they don't appear to work for bundle-based files. > 2.5 macostools -- Convenience routines for file manipulation Not sure about this. It's pretty ancient and crusty though, so I'd be inclined to deprecate. > 2.6 findertools -- The finder's Apple Events interface Deprecate. > 2.7 EasyDialogs -- Basic Macintosh dialogs It's ancient and very crusty, but until there's an up-to-date replacement I guess it has to stay as-is for now, alas. Might be a good idea to check functions for unicode compatibility, long string support, etc. and add notes on any limitations found. > 2.8 FrameWork -- Interactive application framework Deprecate. > 2.9 autoGIL -- Global Interpreter Lock handling in event loops No idea. Anyone? > 3. MacPython OSA Modules Deprecate. > 4. MacOS Toolbox Modules These are just wrappers around the existing Carbon APIs. So as long as those APIs are themselves relevant, so are the wrappers. You can get background info, including a list of which APIs are legacy-only at: > 4.1 Carbon.AE -- Apple Events Ronald's been thinking it might be best to deprecate both Carbon.AE and Carbon.OSA and keep all the AE/OSA/appscript stuff together. Dunno if he's got any further on that yet; you could ask. > 4.2 Carbon.AH -- Apple Help Do nothing. > 4.3 Carbon.App -- Appearance Manager Apple's docs describe AM as 'the older QuickDraw-centric version of HITheme', but don't note it as being superceded/deprecated so I guess it should stay as-is. > 4.4 Carbon.CF -- Core Foundation > 4.5 Carbon.CG -- Core Graphics > 4.6 Carbon.CarbonEvt -- Carbon Event Manager Do nothing. > 4.7 Carbon.Cm -- Component Manager According to Apple's docs CM is largely historical; modern apps should use Core Foundation's Plug-in Services. Other Carbon APIs still rely on it though, so do nothing. > 4.8 Carbon.Ctl -- Control Manager According to Apple's docs, HIView is superseding the older Control Manager. For now though, do nothing. > 4.9 Carbon.Dlg -- Dialog Manager According to Apple's docs, Interface Builder and Carbon event handlers mostly supersede the Dialog Manager, except in the cases where you want to put up a standard alert dialog box or sheet. For now though, do nothing. > 4.10 Carbon.Evt -- Event Manager Deprecate, or at least add note to use modern alternative. Superceded by CarbonEvt. > 4.11 Carbon.Fm -- Font Manager > 4.12 Carbon.Folder -- Folder Manager > 4.13 Carbon.Help -- Help Manager Do nothing. > 4.14 Carbon.List -- List Manager Deprecate, or at least add note to use modern alternative. Superceded by Control Manager. > 4.15 Carbon.Menu -- Menu Manager > 4.16 Carbon.Mlte -- MultiLingual Text Editor Do nothing. > 4.17 Carbon.Qd -- QuickDraw Deprecate. QD is already deprecated in OS X 10.4. > 4.18 Carbon.Qdoffs -- QuickDraw Offscreen Deprecate. QD is already deprecated in OS X 10.4. > 4.19 Carbon.Qt -- QuickTime Do nothing. > 4.20 Carbon.Res -- Resource Manager and Handles According to Apple's docs, RM is historical, but I'm not sure about alternatives; need to check out Bundle Services. For now, probably do nothing. > 4.21 Carbon.Scrap -- Scrap Manager According to Apple's docs, Scrap Manager is superceded by Pasteboard Manager in OS X. We don't have a wrapper for that though, so probably do nothing. > 4.22 Carbon.Snd -- Sound Manager Do nothing. > 4.23 Carbon.TE -- TextEdit Deprecate/add note. Superceded by Mlte, which has unicode support, etc.. > 4.24 Carbon.Win -- Window Manager > 4.25 ColorPicker -- Color selection dialog Do nothing. > 5. Undocumented Modules > 5.1 applesingle -- AppleSingle decoder No idea. Anyone? > 5.2 buildtools -- Helper module for BuildApplet and Friends Deprecate, or at least add a note that py2app is the modern alternative and strongly recommended. > 5.3 cfmfile -- Code Fragment Resource module Probably deprecate. Anyone? > 5.4 icopen -- Internet Config replacement for open() Presumably in the same boat as '2.3 ic'. Anyone? > 5.5 macerrors -- Mac OS Errors Do nothing. > 5.6 macresource -- Locate script resources Presumably in same boat as '4.20 Carbon.Res'. Anyone? > 5.7 Nav -- NavServices calls Do nothing. > 5.8 PixMapWrapper -- Wrapper for PixMap objects Deprecate. (Since QD is deprecated on OS 10.4.) > 5.9 videoreader -- Read QuickTime movies No idea. Anyone? > 5.10 W -- Widgets built on FrameWork Deprecate. > 5.11 waste -- non-Apple TextEdit replacement Deprecate? (ISTR it's not in the universal build.) >My inclination is to delete them all :-). Except for ones where >someone pipes up and tells me it still works. Let folks use the Wiki >to find modules. Your inclination is understandable, but I don't think it'd be wisest. :) Personally I really dislike the 'deprecate in-place' approach that seems to be used in the Python docs. It'd be much clearer and easier on readers if all the crud were moved into a 'Deprecated modules' chapter. That way it wouldn't force readers to wade through piles of irrelevant cruft and junk each time that want to look up current info, but it could still be found when needed. Perhaps you could negotiate to do something like that? >4) Should we document some of the newer stuff? Carbon.LaunchServices, which is part of the standard library as of 2.4. It should be added to the 'Carbon' section as another placeholder page. There's also Carbon.OSA, which is part of the standard library as of 2.4 (though it's buggy and incomplete), which can be added to the 'Carbon' section as another placeholder page. It may or may not be deprecated, depending on what happens with the Carbon.AE module. plistlib probably ought to be mentioned. I suspect it's evil, as it's not using the Property List Services API, but am not familiar enough with it to really say anything more with confidence. >py2app comes to mind. For external projects I'd suggest adding placeholder pages that simply link to external sites (i.e. quick and simple for now; anyone with an urge to expand them can do so in their own time). PyObjC, py2app and appscript are the three obvious ones that I can think of. The PyObjC link is obvious . I imagine you'd link to Bob's site for py2app. At some poing I'd like to shift appscript off my personal webspace to a proper permanent home (sourceforge??), so maybe point to the wiki page for that for now. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Wed Apr 19 15:53:07 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 14:53:07 +0100 Subject: [Pythonmac-SIG] Mac Python is DEAD Message-ID: Bill Janssen wrote: > In my opinion, the problem is the term "MacPython". Python is Python, > period, and we should just call it that, even if it's running on the Mac > platform. Perhaps this was different in the pre-OSX days, but not now. On OS X I think of the 'MacPython' name more as a way to identify the particular distribution: MacPython, Fink Python, ActiveState Python, etc. It'd probably make more sense in that respect if it was 'Mac Python' rather than 'MacPython', but that's just an artifact of how it's evolved. Personally I have no problem dropping the 'Mac' prefix if it proves to be causing more confusion than it solves. Might need to think of a new distribution name though. has -- http://freespace.virgin.net/hamish.sanderson/ From layne.bilyeu at robbstucky.net Wed Apr 19 16:23:14 2006 From: layne.bilyeu at robbstucky.net (corporate user) Date: Wed, 19 Apr 2006 10:23:14 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> Message-ID: <55B5B076-F76C-49A4-82A8-526D6AD04CC7@robbstucky.net> Thank you Bob. >> Very simple beginner script. Not sure why it doesn't write files >> after py2appletizing. >> Seems to work just fine from the command line. What am I missing? > > You're missing the fact that the current directory in a py2app- > generated applet is inside the Resources folder of the applet itself. I made the assumption that since py2app automagically created an Apple application without my having to know anything about a bundle or its structure, that it would also create path emulation as well. Naively, I start with a script in my ~/src folder and I end with an application in my ~/src folder. Like a typical Apple user, I treat the bundle as the code itself and don't bother to dwell on its content or structure. I now understand what the --alias (-A) option to py2app is for. Otherwise you have to start planning for the Bundle tree structure from the start. Am I the first to make this assumption, or is this a tip that should be added to the wiki py2app example page? From charles.hartman at conncoll.edu Wed Apr 19 16:33:04 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 19 Apr 2006 10:33:04 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <55B5B076-F76C-49A4-82A8-526D6AD04CC7@robbstucky.net> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <55B5B076-F76C-49A4-82A8-526D6AD04CC7@robbstucky.net> Message-ID: On Apr 19, 2006, at 10:23 AM, corporate user wrote: > Naively, I start with a script in my ~/src folder and I end with an > application in my ~/src folder. Like a typical Apple user, I treat > the bundle as the code itself and don't bother to dwell on its > content or structure. > > I now understand what the --alias (-A) option to py2app is for. > Otherwise you have to start planning for the Bundle tree structure > from the start. > > Am I the first to make this assumption, or is this a tip that should > be added to the wiki py2app example page? Absolutely this needs to be addressed. Anybody who comes to Python programming from the Mac OS rather than from Unix falls into this mess -- what, my app is a folder?? -- at some point. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/fbcf61a2/attachment.htm From nirs at freeshell.org Wed Apr 19 15:41:27 2006 From: nirs at freeshell.org (Nir Soffer) Date: Wed, 19 Apr 2006 16:41:27 +0300 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> References: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> Message-ID: <25e6664fba0417eef39b6e36de0e0704@freeshell.org> On 19/04/2006, at 03:23, Bill Janssen wrote: > 3) What about the following: > > 2. MacPython Modules > 2.1 macpath -- MacOS path manipulation functions > 2.2 macfs -- Various file system services > 2.2.1 FSSpec Objects > 2.2.2 Alias Objects > 2.2.3 FInfo Objects > 2.3 ic -- Access to Internet Config > 2.3.1 IC Objects > 2.4 MacOS -- Access to Mac OS interpreter features > 2.5 macostools -- Convenience routines for file manipulation > 2.6 findertools -- The finder's Apple Events interface > 2.7 EasyDialogs -- Basic Macintosh dialogs > 2.7.1 ProgressBar Objects > 2.8 FrameWork -- Interactive application framework > 2.8.1 Application Objects > 2.8.2 Window Objects > 2.8.3 ControlsWindow Object > 2.8.4 ScrolledWindow Object > 2.8.5 DialogWindow Objects > 2.9 autoGIL -- Global Interpreter Lock handling in event loops > 3. MacPython OSA Modules > 3.1 gensuitemodule -- Generate OSA stub packages > 3.2 aetools -- OSA client support > 3.3 aepack -- Conversion between Python variables and > AppleEvent data containers > 3.4 aetypes -- AppleEvent objects > 3.5 MiniAEFrame -- Open Scripting Architecture server support > 3.5.1 AEServer Objects > 4. MacOS Toolbox Modules > 4.1 Carbon.AE -- Apple Events > 4.2 Carbon.AH -- Apple Help > 4.3 Carbon.App -- Appearance Manager > 4.4 Carbon.CF -- Core Foundation > 4.5 Carbon.CG -- Core Graphics > 4.6 Carbon.CarbonEvt -- Carbon Event Manager > 4.7 Carbon.Cm -- Component Manager > 4.8 Carbon.Ctl -- Control Manager > 4.9 Carbon.Dlg -- Dialog Manager > 4.10 Carbon.Evt -- Event Manager > 4.11 Carbon.Fm -- Font Manager > 4.12 Carbon.Folder -- Folder Manager > 4.13 Carbon.Help -- Help Manager > 4.14 Carbon.List -- List Manager > 4.15 Carbon.Menu -- Menu Manager > 4.16 Carbon.Mlte -- MultiLingual Text Editor > 4.17 Carbon.Qd -- QuickDraw > 4.18 Carbon.Qdoffs -- QuickDraw Offscreen > 4.19 Carbon.Qt -- QuickTime > 4.20 Carbon.Res -- Resource Manager and Handles > 4.21 Carbon.Scrap -- Scrap Manager > 4.22 Carbon.Snd -- Sound Manager > 4.23 Carbon.TE -- TextEdit > 4.24 Carbon.Win -- Window Manager > 4.25 ColorPicker -- Color selection dialog > 5. Undocumented Modules > 5.1 applesingle -- AppleSingle decoder > 5.2 buildtools -- Helper module for BuildApplet and Friends > 5.3 cfmfile -- Code Fragment Resource module > 5.4 icopen -- Internet Config replacement for open() > 5.5 macerrors -- Mac OS Errors > 5.6 macresource -- Locate script resources > 5.7 Nav -- NavServices calls > 5.8 PixMapWrapper -- Wrapper for PixMap objects > 5.9 videoreader -- Read QuickTime movies > 5.10 W -- Widgets built on FrameWork > 5.11 waste -- non-Apple TextEdit replacement > > My inclination is to delete them all :-). Except for ones where > someone pipes up and tells me it still works. Let folks use the Wiki > to find modules. Don't delete anything, some if not all these modules do work and are useful. Some of the docs are quite useless, and the only way is to use help(modulename), maybe the html can be generated from the module docstrings? Modules I used: * Carbon.File - to get the real case of a file name * MacOS - to get file type and creator code * plistlib - to read and write plist files Best Regards, Nir Soffer From daniellord at mac.com Wed Apr 19 17:18:05 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 08:18:05 -0700 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> Message-ID: <3B9F2778-7164-4DC5-9924-059715BBFF97@mac.com> On Apr 19, 2006, at 6:38, corporate user wrote: > Many thanks to you Bob. > You're a community treasure. > > >> Also note that the Image module probably isn't broken (don't have >> PIL installed at the moment, can't check). Constants don't >> automagically just insert themselves into your script. You should >> be able to reference it with Image.BICUBIC. > > yes, referencing Image.BICUBIC works correctly. > > As usual my problems lie with the scope. I'm forming the opinion that > "from XXX import *" should be banned from all introduction, tutorial > and example materials. It encourages naive assumptions about things > automagically inserting themselves into your namespace. Everything > seems simple when following the examples. But when you try > paraphrasing them for your own work, it blows up in your face. > > It would be better to provide beginners an understanding of > namespaces from the start. Most Python books do cover namespaces in the early chapters (at least the ones I read ;-). But 'from xxx import *' makes it too easy to forget them since it mashes the namespaces together. I've rarely encountered collisions but I try not to be that lazy. I try to use 'import xxxx' and prefix the module name as often as practical fro that reason. Of course the downside is that if the module name or path structure internally change one has a lot of string subs to do in the source. TANSTAAFL. From charles.hartman at conncoll.edu Wed Apr 19 17:24:53 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 19 Apr 2006 11:24:53 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <3B9F2778-7164-4DC5-9924-059715BBFF97@mac.com> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> <3B9F2778-7164-4DC5-9924-059715BBFF97@mac.com> Message-ID: <60A26946-2C56-412D-BA6B-BC3B49C042A7@conncoll.edu> I think one frequent reason people fall back on 'from xxx import *' is simply that typing the whole module name over and over gets tedious and makes the code sprawl. I find 'import xxx as yyy' very useful for this, since it can give you a nice short alias, still readable if you're careful about naming, to sprinkle through the code. Charles Hartman On Apr 19, 2006, at 11:18 AM, Daniel Lord wrote: > But 'from xxx import *' makes it too easy to > forget them since it mashes the namespaces together. I've rarely > encountered collisions but I try not to be that lazy. I try to use > 'import xxxx' and prefix the module name as often as practical fro > that reason. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/08b882ea/attachment.htm From janssen at parc.com Wed Apr 19 17:58:57 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 08:58:57 PDT Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: Your message of "Wed, 19 Apr 2006 06:38:22 PDT." Message-ID: <06Apr19.085859pdt."58633"@synergy1.parc.xerox.com> > > 4.2 Carbon.AH -- Apple Help > > Do nothing. Much like Apple Help itself :-). Bill From njriley at uiuc.edu Wed Apr 19 18:13:36 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Wed, 19 Apr 2006 11:13:36 -0500 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> Message-ID: <20060419161336.GA54724@uiuc.edu> On Wed, Apr 19, 2006 at 02:38:22PM +0100, has wrote: > > 2.3 ic -- Access to Internet Config > > No idea about this. Anyone else know if this is still working/relevant? It is basically deprecated for LaunchServices now. It would be really good if we could get a decent LaunchServices binding - as of now, there are several, all of which have some problems (?). > > 4.1 Carbon.AE -- Apple Events > > Ronald's been thinking it might be best to deprecate both Carbon.AE > and Carbon.OSA and keep all the AE/OSA/appscript stuff > together. Dunno if he's got any further on that yet; you could ask. How far do you think your stuff is from being able to be incorporated in the standard library? It'd be much nicer to just replace it rather than removing it. > > 4.7 Carbon.Cm -- Component Manager > > According to Apple's docs CM is largely historical; modern apps should use Core Foundation's Plug-in Services. Other Carbon APIs still rely on it though, so do nothing. Not to mention QuickTime and CoreAudio, which aren't going away any time soon. > > 4.20 Carbon.Res -- Resource Manager and Handles > > According to Apple's docs, RM is historical, but I'm not sure about alternatives; need to check out Bundle Services. For now, probably do nothing. Resources are still used quite a bit by OS X; don't think it's worth deprecating. > > 5. Undocumented Modules > > 5.1 applesingle -- AppleSingle decoder > > No idea. Anyone? Dunno, but it'd sure be nice if there were a programmatic interface to Bom.framework (which does AppleDouble, zips and cpio files with Mac metadata). This is Apple's problem, not ours, though. > > 5.4 icopen -- Internet Config replacement for open() > > Presumably in the same boat as '2.3 ic'. Anyone? Yeah, deprecate for LaunchServices. -- Nicholas Riley | From janssen at parc.com Wed Apr 19 18:14:57 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 09:14:57 PDT Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: Your message of "Wed, 19 Apr 2006 06:38:22 PDT." Message-ID: <06Apr19.091504pdt."58633"@synergy1.parc.xerox.com> Thanks, Has. I was hoping someone would go through that list bit-by-bit. I'm still in favor of simply removing outdated and dangerous docs, but perhaps there's some effective way of thoroughly marking them as bad, instead. Bill From Chris.Barker at noaa.gov Wed Apr 19 18:31:32 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 09:31:32 -0700 Subject: [Pythonmac-SIG] Psycho & 2.4.3 universal In-Reply-To: <44456421.5010407@fas.harvard.edu> References: <444562FE.6080703@fas.harvard.edu> <44456421.5010407@fas.harvard.edu> Message-ID: <444665E4.2020607@noaa.gov> Jacob Rus wrote: > Argh, never mind that message. I see now that psyco is clearly labeled > as only working on i386. Nothing to see here, move along. It'd be nice to know how/if it works on an Intel Mac, however. Anyone? -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 at noaa.gov From Chris.Barker at noaa.gov Wed Apr 19 18:49:05 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 09:49:05 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> Message-ID: <44466A01.8080903@noaa.gov> Bob Ippolito wrote: > *ALWAYS* prefer convenience over space. Never make separate > distributions for i386 and PPC. Simplicity is key. Absolutely. > I will no longer accept single-architecture packages for > pythonmac.org/packages except under special circumstances However... Right now, we don't have Universal packages for most things. This creates a difficult situation for folks, particularly those on Intel Macs. It is a serious challenge to build Universal packages, at least for those packages that rely on third party libs (PIL, Matplotlib, wxPython....) Until those folks with the skills to do it find the time to build some of the most common ones, I'm not sure it's such a bad idea to have a repository for i386 and PPC-only packages. About those libs: As it is a challenge to build universal libs, and a bunch of common python packages require the same libs, I'd love to see a repository of Universal libs for use with Python packages. My suggestion: A ExtraLibs.mpkg, right there with the packages on pythonmac.org that includes Universal shared libs required by some common packages. They could perhaps be installed in the Python Framework, so they won't interfere with anything else. a) is this possible? b) is this a good idea? I suggest the following libs: libfreetype libpng libjpeg Other common ones? -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 at noaa.gov From Chris.Barker at noaa.gov Wed Apr 19 18:53:04 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 09:53:04 -0700 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> Message-ID: <44466AF0.7030700@noaa.gov> corporate user wrote: > I'm forming the opinion that > "from XXX import *" should be banned from all introduction, tutorial > and example materials. Actually, it should be banned from virtually ALL user code! But tutorial and examples are a start! -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 at noaa.gov From Chris.Barker at noaa.gov Wed Apr 19 18:58:58 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 09:58:58 -0700 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <55B5B076-F76C-49A4-82A8-526D6AD04CC7@robbstucky.net> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <55B5B076-F76C-49A4-82A8-526D6AD04CC7@robbstucky.net> Message-ID: <44466C52.1000604@noaa.gov> corporate user wrote: > I made the assumption that since py2app automagically created an > Apple application without my having to know anything about a bundle > or its structure, that it would also create path emulation as well. I'm not sure that's your problem. I think your problem is really with the concept of a "working directory" when you start a python script from the command line, the working directory is the one that you're in when you start it up. When you double click and App, who knows what it is? (I'm sure it's defined, but I wouldn't ever count on it being useful, and it's definably not the same across platforms). So you need to either use full paths everywhere, or set the working directory yourself. I'd do the former. -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 at noaa.gov From zbir at urbanape.com Wed Apr 19 19:03:31 2006 From: zbir at urbanape.com (Zachery Bir) Date: Wed, 19 Apr 2006 13:03:31 -0400 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: <44466AF0.7030700@noaa.gov> References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> <44466AF0.7030700@noaa.gov> Message-ID: On Apr 19, 2006, at 12:53 PM, Christopher Barker wrote: > corporate user wrote: >> I'm forming the opinion that >> "from XXX import *" should be banned from all introduction, tutorial >> and example materials. > > Actually, it should be banned from virtually ALL user code! But > tutorial > and examples are a start! It has a strong place in PyObjC, where we're putting our natural inclination for multi-layered namespaces aside to fit in with the conventions of ObjC's single namespace. At least there (in PyObjC's context), it's a natural fit, and I'd much rather it continue to be presented as the convention. I know you said "virtually", but given the fact this is the pythonmac mailing list, and PyObjC plays (at least for me) a very big part of the Python on Mac landscape, I'd hate to see a ban on what is arguably a harmless (and very timesaving!) use of "from x import *". Zac From daniellord at mac.com Wed Apr 19 19:31:49 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 10:31:49 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <44466A01.8080903@noaa.gov> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> Message-ID: On Apr 19, 2006, at 9:49, Christopher Barker wrote: > My suggestion: > > A ExtraLibs.mpkg, right there with the packages on pythonmac.org that > includes Universal shared libs required by some common packages. They > could perhaps be installed in the Python Framework, so they won't > interfere with anything else. > > a) is this possible? > b) is this a good idea? > > I suggest the following libs: > > libfreetype > libpng > libjpeg > > Other common ones? I built Universal jpeg-6b, freetype2, and zlib for my current project of Universal PIL. I can add libpng in easily so I'll do it. So that makes jpeg, png, freetype, and zlib. What else? On the other topic... I have successfully packaged up a Universal PIL for 2.4 (thanks for the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am closer to releasing it. However, it isn't including the libs so I am studying py2app and bdist_mpkg nuances to figure out how to package them all in one installer. Once I get this done, I'll post it the instructions for hand building in the wiki and the all-in-one plus a separate Universal libs package on my iDisk. I am also trying to see if I can make a quick and dirty shell script using curl, sed, and toehr tools to create a one-button build and install but that is after the above. From daniellord at mac.com Wed Apr 19 19:33:25 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 10:33:25 -0700 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <06Apr19.091504pdt.58633@synergy1.parc.xerox.com> References: <06Apr19.091504pdt.58633@synergy1.parc.xerox.com> Message-ID: <62D15876-A81A-4B64-842A-9259F314FB02@mac.com> On Apr 19, 2006, at 9:14, Bill Janssen wrote: > I'm still in favor of simply removing outdated and dangerous docs, but > perhaps there's some effective way of thoroughly marking them as bad, > instead. Put in doc sections entitled Deprecated and Obsolete and do the same for the web and wiki. I'll help at some point but I am busy with this PIL/Lib thing right now ;-) From hengist.podd at virgin.net Wed Apr 19 19:06:17 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 18:06:17 +0100 Subject: [Pythonmac-SIG] Pythonmac-SIG] Fixing the documentation... Message-ID: Nicholas Riley wrote: > > > 2.3 ic -- Access to Internet Config > > > > No idea about this. Anyone else know if this is still working/relevant? > >It is basically deprecated for LaunchServices now. Righto, add it to the 'deprecate' list then. > It would be really good if we could get a decent LaunchServices binding - as of now, there are several, all of which have some problems (?). Bob did an LS wrapper early on, but it's long been superceded by the one in Python 2.4's standard library, which is the only one that counts. If there's deficiencies in that then bug reports, feature requests, patches, etc. should be filed on that. But this is a topic for a different thread. > > > 4.1 Carbon.AE -- Apple Events > > > > Ronald's been thinking it might be best to deprecate both Carbon.AE > > and Carbon.OSA and keep all the AE/OSA/appscript stuff > > together. > >How far do you think your stuff is from being able to be incorporated >in the standard library? Like PyObjC, I'm in no rush. Keeping things outside of the stdlib has its advantages too. Personally I think Win32All has the right idea: put all the platform-specific extensions in a separate all-in-one collection. Then they're not at the mercy of Python proper's development cycle. But this is also a topic for another thread. :) >It'd be much nicer to just replace it rather than removing it. Mind that deprecating Carbon.AE != removing it. It'll be a couple more Python revisions before the possibility of removal even arises, and there's no requirement to drop it even then. I suspect Ronald's reasoning is that it'd be more hassle to merge CarbonX.AE and CarbonX.OSA back into the standard library than leave them where they are. There's precious few parties using these extensions anyway - appscript and co. are the major ones - so reincorporating them doesn't really gain you anything beyond a warm-n-fuzzy sense of "completeness". Nice; but why make extra work for oneself? Anyway... I'll be using my own copies of AE.so and OSA.so for the forseeable future anyhow (backwards' compatibility), so I couldn't care less either way what happens to Carbon.AE and Carbon.OSA. > > > 4.20 Carbon.Res -- Resource Manager and Handles > > > > According to Apple's docs, RM is historical, but I'm not sure about alternatives; need to check out Bundle Services. For now, probably do nothing. > >Resources are still used quite a bit by OS X; don't think it's worth >deprecating. Resources are still in use, but the crusty old Resource Manager API itself has been superceded by the modern Bundle Services API which is what folks should be using nowadays. But since Carbon.CF doesn't seem to include Bundle Services, it's probably preferable to leave RM as-is on account of something is better than nothing. (Unless it's actually broken, of course.) > > Presumably in the same boat as '2.3 ic'. Anyone? > >Yeah, deprecate for LaunchServices. Yep, agree with that. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Wed Apr 19 19:33:11 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 18:33:11 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... Message-ID: Bill Janssen wrote: >Thanks, Has. > >I was hoping someone would go through that list bit-by-bit. See also NR's post and my reply to it; anything Internet Config-related looks reasonable to add to the 'deprecate' list. Hopefully there'll be a few more yeas/nays on it from other folks; like I say there's still a few I'm not sure about. >I'm still in favor of simply removing outdated and dangerous docs, but >perhaps there's some effective way of thoroughly marking them as bad, >instead. I dunno if there's anything actually "dangerous" in there; it's more just a case of "bloody awful-looking", "a complete waste of readers' time to trawl through" and "a rotten first impression for newcomers". Which still matters, of course; it just takes longer to drum up the motivation to deal with it. :) I'd agree that chapter 1's content should all be deleted as the stuff it refers to no longer exists. Replace it with a placeholder page (for now) that describes what's currently available: python/pythonw in Terminal.app, IDLE, PythonLauncher and BuildApplet (BA should probably be marked deprecated). Could also mention that OS X's system-wide scripts menu can - permissions willing - be used to run .py (and other) shell scripts. For deprecating individual modules, best to follow the standard procedure though. For documentation it seems to mean adding a bold "Deprecated since release 2.x" line at the top of the page for a whole module, or to the end of a individual function's description. (Pretty weak, if you ask me, but if that's the official policy then that's the official policy.) But you really need to check with the proper sources before doing anything. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From jrus at fas.harvard.edu Wed Apr 19 19:33:19 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 13:33:19 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr18.160038pdt."58633"@synergy1.parc.xerox.com> References: <44454E9E.8050609@fas.harvard.edu> <06Apr18.160038pdt."58633"@synergy1.parc.xerox.com> Message-ID: <4446745F.5060501@fas.harvard.edu> > There's the flat logo, but the logo I was pointing to was a version > that's shaded a bit to look slightly raised and rounded. Were you looking for something more like [this][1]? -Jacob [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png From daniellord at mac.com Wed Apr 19 19:37:08 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 10:37:08 -0700 Subject: [Pythonmac-SIG] py2app = newbie path confusion In-Reply-To: References: <37FDC0FC-8BB2-41F8-AEBC-B6D83D91C691@robbstucky.net> <5514E04E-9020-4B74-8437-12F4E58719D2@robbstucky.net> <44466AF0.7030700@noaa.gov> Message-ID: On Apr 19, 2006, at 10:03, Zachery Bir wrote: > On Apr 19, 2006, at 12:53 PM, Christopher Barker wrote: > >> corporate user wrote: >>> I'm forming the opinion that >>> "from XXX import *" should be banned from all introduction, tutorial >>> and example materials. >> >> Actually, it should be banned from virtually ALL user code! But >> tutorial >> and examples are a start! > > It has a strong place in PyObjC, where we're putting our natural > inclination for multi-layered namespaces aside to fit in with the > conventions of ObjC's single namespace. At least there (in PyObjC's > context), it's a natural fit, and I'd much rather it continue to be > presented as the convention. > > I know you said "virtually", but given the fact this is the pythonmac > mailing list, and PyObjC plays (at least for me) a very big part of > the Python on Mac landscape, I'd hate to see a ban on what is > arguably a harmless (and very timesaving!) use of "from x import *". It is fine in modules where the scoping and namespaces are thoughtfully implemented. Banning is too strong a word. It kind like a hand grenade--really dangerous for the unskilled, but man when you need one, you really need one ;-) Beginner's should be cautioned and receive qualified instruction before using: i.e. it should be documented ;-) From hengist.podd at virgin.net Wed Apr 19 20:06:41 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 19:06:41 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <2A41085B-3261-47F6-A781-88DC28E1A09B@redivi.com> References: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> <2A41085B-3261-47F6-A781-88DC28E1A09B@redivi.com> Message-ID: Bob Ippolito wrote: >>In addition, all mentions of OS 9 should either be expunged (e.g. the 'using Python on Mac OS 9' chapter) or changed to 'not supported' (should they still need to be documented for any reason). > >Mac OS 9 is definitely no longer supported at all. The *final* release for OS 9 is 2.3.3. There are no plans of there ever being a current version for that platform again. OK, expunge all mentions of 'OS 9' then. Agree with the rest too, apart from a couple things I'm not sure about: >>> 2.7 EasyDialogs -- Basic Macintosh dialogs >>[...] > >Remove, it depends on waste. Didn't see a waste dependency in the module; you sure about that? I've tried it and it still seems to be working okay (as well as it ever did, anyway), in which case immediate removal is not necessary. I wouldn't be averse to deprecating it just on general principle though. :) >>> 4.4 Carbon.CF -- Core Foundation > >This one is kinda broken and is irrelevant when PyObjC is installed. >It might have some minimal usage somewhere though. I'd deprecate it. How about putting a warning note on it for now saying it's buggy, and if nobody loves it enough to submit patches in the next year then deprecate it for 2.6? Inasmuch as the standard library includes any Mac-specific extensions in the first place you'd kinda expect it to include this one, so maybe give it a last opportunity before completely writing it off. >>>4) Should we document some of the newer stuff? >>[...] >>plistlib probably ought to be mentioned. I suspect it's evil, as it's not using the Property List Services API, but am not familiar enough with it to really say anything more with confidence. > >plistlib works ok. It used to be horribly broken, but the current version should be spec compliant. Including binary plists and all that? I've not tried it recently so wouldn't know. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From daniellord at mac.com Wed Apr 19 20:08:53 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 11:08:53 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446745F.5060501@fas.harvard.edu> References: <44454E9E.8050609@fas.harvard.edu> <06Apr18.160038pdt.58633@synergy1.parc.xerox.com> <4446745F.5060501@fas.harvard.edu> Message-ID: On Apr 19, 2006, at 10:33, Jacob Rus wrote: >> There's the flat logo, but the logo I was pointing to was a version >> that's shaded a bit to look slightly raised and rounded. > > Were you looking for something more like [this][1]? > > -Jacob > > [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png Much better. In fact a great deal better--its looks worthy of the Mac. I could even say this is great. But, pushing the envelope a bit if you don't think I am being too demanding... Can you 'aqua-fy it' little-- give it that slightly transparent look that is the Apple trademark? From frank at niessink.com Wed Apr 19 20:18:45 2006 From: frank at niessink.com (Frank Niessink) Date: Wed, 19 Apr 2006 20:18:45 +0200 Subject: [Pythonmac-SIG] py2app includes all python documentation in the app In-Reply-To: References: <44454496.9050107@niessink.com> Message-ID: <44467F04.9020202@niessink.com> Bob Ippolito: > It does just copy Resources. You'll have to use the latest py2app 0.2 > maintenance branch from svn. > > http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/ Thanks Bob, I checked out py2app from the URL given, ran setup.py as instructed. When I run python setup.py py2app, I get the following exception: copying /Library/Frameworks/Python.framework/Versions/2.4/bin/python -> /Users/frank/taskcoach/build/TaskCoach.app/Contents/Frameworks/Python.framework/Versions/2.4/bin Traceback (most recent call last): File "make.py", line 125, in ? setup(**setupOptions) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 373, in run self._run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 494, in _run self.run_normal() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 554, in run_normal self.create_binaries(py_files, pkgdirs, extensions, loader_files) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 644, in create_binaries mm.run_file(runtime) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOStandalone.py", line 87, in run_file mm.run_file(fn) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOGraph.py", line 65, in run_file raise ValueError, '%r does not contain architecture %s' % (pathname, self.arch) ValueError: '/Library/Frameworks/Python.framework/Versions/2.4/Python' does not contain architecture i386 This makes sense, somewhat, because I use the PPC version of Python 2.4.1 on a Intel Mac Mini. The reason for this is that there is no universal build of wxpython available yet. Apparently, py2app is expecting a i386 python version? Why? How can I tell it to expect and use the PPC version? Thanks, Frank From ronaldoussoren at mac.com Wed Apr 19 20:55:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 20:55:56 +0200 Subject: [Pythonmac-SIG] readline: where and how installed? In-Reply-To: <44455EC5.6060401@noaa.gov> References: <68FE44B6-3F61-44D4-B39B-5B8AC5D4172B@columbus.rr.com> <6AF9E39E-16B2-4E18-874C-0841181FA4E6@stanford.edu> <8DED8906-DD9F-47BA-9BF5-472DE43F3C48@mac.com> <2D0C1234-B32E-493C-9127-163747CBF497@mac.com> <44455EC5.6060401@noaa.gov> Message-ID: <66994937-EEB2-48CC-98FD-DBC915D062DC@mac.com> On 18-apr-2006, at 23:48, Christopher Barker wrote: > Ronald Oussoren wrote: >> On 13-apr-2006, at 18:47, Zachary Pincus wrote: >>> Also, a related query: Is there somewhere in the Python Framework >>> structure that is appropriate for placing dynamic libraries that >>> Python would link to? > >> I don't see what this would buy us. It is possible to do this, but >> IMHO not really worth the trouble. > > I don't think it would buy anything for readline, but it would for > libs > that are used by multiple python extensions, like libpng and > libfreetype, for instance. Why? I'd prefer to have fully self contained packages, and preferably eggs at that. Having a shared libary makes it *harder* to independendly update extensions using libpng or libfreetype. I'll have to package up my package build script one of these days ;-) Ronald From hengist.podd at virgin.net Wed Apr 19 20:59:20 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 19:59:20 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: Jacob Rus wrote: > > There's the flat logo, but the logo I was pointing to was a version > > that's shaded a bit to look slightly raised and rounded. > >Were you looking for something more like [this][1]? >[1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png The snake logo you've used there is an earlier, boxier attempt that's not as pleasing to the eye, and not the final version used on python.org. The version Bill means (I couldn't get his link to work) is this: http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/newlogo/python-logo-master-v3-trans.png Each snake has a slight linear colour gradient running diagonally, and the outer edges are curved. I posted a list of what seems to be needed earlier (still not got time to do them myself though); see: http://mail.python.org/pipermail/pythonmac-sig/2006-April/016869.html To which one might also add a Python egg icon - maybe a 3D egg with the Python logo on it, or a closed cuboid package-style box, or a standard Lego-cube-like plugin icon. has -- http://freespace.virgin.net/hamish.sanderson/ From ronaldoussoren at mac.com Wed Apr 19 20:59:01 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 20:59:01 +0200 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: References: Message-ID: <8F2517DD-4D6C-4371-8D04-A059D428A3AD@mac.com> On 18-apr-2006, at 22:59, Advertising Department wrote: > (I'm totally confused about the nine versions of python for Mac OS X, > the defunct or just not updated for 2 years MacPython pages, the > current state of the macintosh specific library modules, etc.) > > To give my 2 cents... > It doesn't really matter about a logo, icon, or universal build. If > there is no recent info on the OFFICIAL python.org linked web pages, > most new users will think it's become defunct, and look no further. > NEWS Sorry? There is a link to a python installer for macosx on python.org. We can't help that google points users that search for MacPython to Jack's site who has basically disappeared and hasn't updated his site for a long time. It is annoying that www.python.org/download/mac doesn't mention the universal installer. Could someone please fix that? Ronald From ronaldoussoren at mac.com Wed Apr 19 21:01:09 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 21:01:09 +0200 Subject: [Pythonmac-SIG] Psycho & 2.4.3 universal In-Reply-To: <44456421.5010407@fas.harvard.edu> References: <444562FE.6080703@fas.harvard.edu> <44456421.5010407@fas.harvard.edu> Message-ID: <16E2C4CC-F392-4881-8035-173D304DCDE9@mac.com> On 19-apr-2006, at 0:11, Jacob Rus wrote: > I wrote: >> I couldn't compile [psyco][1] using the 2.4.3 universal version of >> Python on my 12" powerbook. I'm wondering if this is just a problem >> with universal Python, or if psycho doesn't compile in general >> under OS X. > > Argh, never mind that message. I see now that psyco is clearly > labeled > as only working on i386. Nothing to see here, move along. There is someone to see for those users fortunate enough to own an intel mac :-) It should be possible to compile psyco if you add '-arch i386' to the extra_compile_args and extra_link_args in the setup.py for psyco. Ronald From jrus at fas.harvard.edu Wed Apr 19 21:08:11 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 15:08:11 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <44454E9E.8050609@fas.harvard.edu> <06Apr18.160038pdt.58633@synergy1.parc.xerox.com> <4446745F.5060501@fas.harvard.edu> Message-ID: <44468A9B.9040306@fas.harvard.edu> >> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png > > Much better. In fact a great deal better--its looks worthy of the Mac. > I could even say this is great. But, pushing the envelope a bit if > you don't think I am being too demanding... > Can you 'aqua-fy it' little-- give it that slightly transparent look > that is the Apple trademark? Well, that's what I was going for. Is [this][2] better? ([Folder][3] with icns file) I'm hardly an expert at drawing aqua icons, so my highlights might not be exactly right. Someone else may want to take a crack at it. In any case, even if a slightly more polished version of this is usable as a python document icon, what do we want to use for the other icons--drag-n-drop script runner, Editor/IDE, .pyc/.pyo files? pyc could just be the same but with "PYC" written at the bottom, I guess, but it could also have the paper background modified to signify "compiled" in some way. [2]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.png [3]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.zip From ronaldoussoren at mac.com Wed Apr 19 21:19:35 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 21:19:35 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> Message-ID: <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> On 19-apr-2006, at 2:23, Bill Janssen wrote: > Just looking at the docs, I'm trying to figure out what's good and > what's bad. > > 1) We should no longer point people to Jack's site, we point them to > the python.org Mac download page instead. Right. > > 2) references to PythonIDE and PackageManager should go. Right again. I want to remove those from python2.5 if I can, or at least move them somewhere where they cannot do harm. > > 3) What about the following: > > 2. MacPython Modules > 2.1 macpath -- MacOS path manipulation functions > 2.2 macfs -- Various file system services > 2.2.1 FSSpec Objects > 2.2.2 Alias Objects > 2.2.3 FInfo Objects > 2.3 ic -- Access to Internet Config > 2.3.1 IC Objects > 2.4 MacOS -- Access to Mac OS interpreter features > 2.5 macostools -- Convenience routines for file manipulation > 2.6 findertools -- The finder's Apple Events interface > 2.7 EasyDialogs -- Basic Macintosh dialogs > 2.7.1 ProgressBar Objects > 2.8 FrameWork -- Interactive application framework > 2.8.1 Application Objects > 2.8.2 Window Objects > 2.8.3 ControlsWindow Object > 2.8.4 ScrolledWindow Object > 2.8.5 DialogWindow Objects > 2.9 autoGIL -- Global Interpreter Lock handling in event loops > 3. MacPython OSA Modules > 3.1 gensuitemodule -- Generate OSA stub packages > 3.2 aetools -- OSA client support > 3.3 aepack -- Conversion between Python variables and > AppleEvent data containers > 3.4 aetypes -- AppleEvent objects > 3.5 MiniAEFrame -- Open Scripting Architecture server support > 3.5.1 AEServer Objects > 4. MacOS Toolbox Modules > 4.1 Carbon.AE -- Apple Events > 4.2 Carbon.AH -- Apple Help > 4.3 Carbon.App -- Appearance Manager > 4.4 Carbon.CF -- Core Foundation > 4.5 Carbon.CG -- Core Graphics > 4.6 Carbon.CarbonEvt -- Carbon Event Manager > 4.7 Carbon.Cm -- Component Manager > 4.8 Carbon.Ctl -- Control Manager > 4.9 Carbon.Dlg -- Dialog Manager > 4.10 Carbon.Evt -- Event Manager > 4.11 Carbon.Fm -- Font Manager > 4.12 Carbon.Folder -- Folder Manager > 4.13 Carbon.Help -- Help Manager > 4.14 Carbon.List -- List Manager > 4.15 Carbon.Menu -- Menu Manager > 4.16 Carbon.Mlte -- MultiLingual Text Editor > 4.17 Carbon.Qd -- QuickDraw > 4.18 Carbon.Qdoffs -- QuickDraw Offscreen > 4.19 Carbon.Qt -- QuickTime > 4.20 Carbon.Res -- Resource Manager and Handles > 4.21 Carbon.Scrap -- Scrap Manager > 4.22 Carbon.Snd -- Sound Manager > 4.23 Carbon.TE -- TextEdit > 4.24 Carbon.Win -- Window Manager > 4.25 ColorPicker -- Color selection dialog > 5. Undocumented Modules > 5.1 applesingle -- AppleSingle decoder > 5.2 buildtools -- Helper module for BuildApplet and Friends > 5.3 cfmfile -- Code Fragment Resource module > 5.4 icopen -- Internet Config replacement for open() > 5.5 macerrors -- Mac OS Errors > 5.6 macresource -- Locate script resources > 5.7 Nav -- NavServices calls > 5.8 PixMapWrapper -- Wrapper for PixMap objects > 5.9 videoreader -- Read QuickTime movies > 5.10 W -- Widgets built on FrameWork > 5.11 waste -- non-Apple TextEdit replacement > > My inclination is to delete them all :-). Except for ones where > someone pipes up and tells me it still works. Let folks use the Wiki > to find modules. I don't think you can remove them. IIRC some of this is generated somehow (although I don't know how). Macpath deals with OS9/Carbon style paths (Volume:directory:file instead of /Volume/directory/file). This might be usefull when using Carbon API's. The documentation for this module (and several others) does need to mention this instead of confusing users by mentioning it is for the mac. Section 4 (MacOS Toolbox Modules) definitely needs some text. At the very least it needs a general explanation about how to translate between the C interface as described in Apple's documentation and the Python interface. W (5.10) and waste (5.11) should probably go, waste won't work on intel systems anyway and W is ancient and not update for Carbon Events. Gensuitemodule should be deprecated, at the very least in the documentation. I don't know if we can point users to software that's not in the stdlib, but if we can I'd add a reference to appscript in the deprecation message in the documentation. Has can probably comment on the usefulness of the rest of section 3. I don't know enough about the rest to make useful comments about them. I do think however that we shouldn't remove all documentation, but should instead work on improving both the documentation and actual code. > > 4) Should we document some of the newer stuff? py2app comes to mind. Not in the official python documentation. You can't add documentation for stuff that is not part of the stdlib. More documentation for py2app is of course welcome, and I'm sure Bob is willing to add it to the py2app package when you write it :-) Ronald From hengist.podd at virgin.net Wed Apr 19 21:22:31 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 20:22:31 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt."58633"@synergy1.parc.xerox.com> <2A41085B-3261-47F6-A781-88DC28E1A09B@redivi.com> Message-ID: Bob Ippolito wrote: [EasyDialogs] >>Didn't see a waste dependency in the module; you sure about that? I've tried it and it still seems to be working okay (as well as it ever did, anyway), in which case immediate removal is not necessary. I wouldn't be averse to deprecating it just on general principle though. :) > >I thought it depended on W, which I think depends on waste. Maybe I'm wrong though. I've steered clear of all that stuff for quite a while. Nope, just the Carbon extensions from what I can tell. >A PyObjC-based replacement for EasyDialogs would be convenient though. The problems with EasyDialogs are mostly just because the implementation is ancient. Yep. The only catch about doing a set of simple, general-purpose in PyObjC is that you'd have PyObjC as a heavyweight dependency, and the main motivations for having something like ED are its simplicity and lightweightedness. It fills a low-end niche. The Nav module provides file dialogs, so really all that's needed is modern message, text entry and progress bar dialog implementations - preferably without requiring any new external dependencies. But anyway... any replacement is some way off. For now it's just a case of deciding whether to leave ED and its documentation as-is or deprecate it. I say deprecate if other folks agree. >>>plistlib works ok. It used to be horribly broken, but the current version should be spec compliant. >> >>Including binary plists and all that? I've not tried it recently so wouldn't know. > >No, it does not support binary plists or NeXT style plists. It supports XML plists. Still useful though. Sounds like a future reimplementation/replacement that uses the Core Foundation API instead of trying to parse things itself would be a wise move. For now though, I'd say just add a short page to the documentation so folk know the plistlib module exists and put a note on it indicating its limitations. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From daniellord at mac.com Wed Apr 19 21:34:51 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 12:34:51 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44468A9B.9040306@fas.harvard.edu> References: <44454E9E.8050609@fas.harvard.edu> <06Apr18.160038pdt.58633@synergy1.parc.xerox.com> <4446745F.5060501@fas.harvard.edu> <44468A9B.9040306@fas.harvard.edu> Message-ID: <2BEAB04B-2445-499A-92D2-CAA796AA4E32@mac.com> On Apr 19, 2006, at 12:08, Jacob Rus wrote: >>> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png >> >> Much better. In fact a great deal better--its looks worthy of the >> Mac. >> I could even say this is great. But, pushing the envelope a bit if >> you don't think I am being too demanding... >> Can you 'aqua-fy it' little-- give it that slightly transparent look >> that is the Apple trademark? > > Well, that's what I was going for. Is [this][2] better? ([Folder][3] > with icns file) > > I'm hardly an expert at drawing aqua icons, so my highlights might not > be exactly right. Someone else may want to take a crack at it. > > In any case, even if a slightly more polished version of this is > usable > as a python document icon, what do we want to use for the other > icons--drag-n-drop script runner, Editor/IDE, .pyc/.pyo files? pyc > could just be the same but with "PYC" written at the bottom, I guess, > but it could also have the paper background modified to signify > "compiled" in some way. > > [2]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.png > [3]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.zip I like it. But HAS is right--the icon on the www.python.org home page is more rounded. Now if you could take the new one and make it beveled and glassy liek you did the 'blocky' one I'd say we have a winner IMHO ;-) From frank at niessink.com Wed Apr 19 21:53:24 2006 From: frank at niessink.com (Frank Niessink) Date: Wed, 19 Apr 2006 21:53:24 +0200 Subject: [Pythonmac-SIG] py2app includes all python documentation in the app In-Reply-To: <126B50F9-8A6E-417B-A601-A5E361865064@redivi.com> References: <44454496.9050107@niessink.com> <44467F04.9020202@niessink.com> <126B50F9-8A6E-417B-A601-A5E361865064@redivi.com> Message-ID: <44469534.2040803@niessink.com> Bob Ippolito: >> >> Apparently, py2app is expecting a i386 python version? Why? How can I >> tell it to expect and use the PPC version? > > I actually don't know, I didn't write those patches. I won't have time > to look into this for at least a week, but you might want to dig into > the source code and see if there's a way to ask it for some particular > architecture. Your suggestion made me indeed read through the source code which made me find out there is an 'archs' option you can pass to py2app. archs is a comma-separated list of archs (in a string) to include. So I now pass "archs='ppc'" to py2app, which gets rid of the previous exception. However, now I run an error while py2app is copying /Library/Frameworks/Python.framework/Versions/2.4/Python to the app bundle. It looks like it is copying that file twice which apparently the underlying code doesn't like (I think that is one of shutil's methods). I'll investigate some more. Thanks for the help, Frank From ronaldoussoren at mac.com Wed Apr 19 21:52:57 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 21:52:57 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> Message-ID: <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> On 19-apr-2006, at 15:38, has wrote: > > >> 2.1 macpath -- MacOS path manipulation functions > > Deprecate. Also note that the 2.4.3 documentation now says "It can > be used to manipulate old-style Macintosh pathnames on Mac OS X (or > any other platform)." which is incorrect (it uses POSIX-style > paths), so delete that sentence. I'm not a native english speaker, but I read this as "you can use this to manipulate OS9 style paths on any platform". Just like you can use ntpath to manipulate windows-style paths (c:\foo\bar.txt) on any platform. That's actually a useful feature. As I mentioned in another message this module might be useful to work with OS9-style paths as used by some Carbon API's. > >> 2.4 MacOS -- Access to Mac OS interpreter features > > Get/SetCreatorAndType should really be fixed or deprecated as they > don't appear to work for bundle-based files. They should be fixed. Why does everyone want to remove what they don't quite understand? One of the strong points of python on the mac is that it is one of the *very* few languages that provides bindings to most parts of the system APIs. IMHO the bindings to Carbon suck, but that doesn't mean we should scrap or completely hide them. Stuff should be deprecated and removed only if we are absolutely sure it is useless, and preferably only if we have a replacement. An example of this is application scripting support, everybody seems to agree that appscript is miles better than the stuff in the stdlib. I'd love to deprecate Carbon.CF as well, but we can't do that until we have another way to access those APIs. PyObjC is about this > < close to doing that, I just haven't gotten around finishing the final bits yet. > > >> 2.5 macostools -- Convenience routines for file manipulation > > Not sure about this. It's pretty ancient and crusty though, so I'd > be inclined to deprecate. > > >> 2.6 findertools -- The finder's Apple Events interface > > Deprecate. > > >> 2.7 EasyDialogs -- Basic Macintosh dialogs > > It's ancient and very crusty, but until there's an up-to-date > replacement I guess it has to stay as-is for now, alas. Might be a > good idea to check functions for unicode compatibility, long string > support, etc. and add notes on any limitations found. > > >> 2.8 FrameWork -- Interactive application framework > > Deprecate. > > >> 2.9 autoGIL -- Global Interpreter Lock handling in event loops > > No idea. Anyone? I think this can be deprecated. This is a pretty neat trick to give up the GIL while an eventloop is waiting for events. That way you can easily use multithreaded programs in a GUI. That was useful when PyObjC didn't do GIL management itself (in the days when Python 2.3b1 was bleeding edge), but I don't think we still need this. > > >> 3. MacPython OSA Modules > > Deprecate. > > >> 4. MacOS Toolbox Modules > > These are just wrappers around the existing Carbon APIs. So as long > as those APIs are themselves relevant, so are the wrappers. You can > get background info, including a list of which APIs are legacy-only > at: > > newtocarbon/chapter_1_section_1.html> Right. As I mentioned in another message it would be nice if someone described the way API's are mapped from C to Python. That makes it easier to use examples and documentation for the C API. > > >> 4.1 Carbon.AE -- Apple Events > > Ronald's been thinking it might be best to deprecate both Carbon.AE > and Carbon.OSA and keep all the AE/OSA/appscript stuff together. > Dunno if he's got any further on that yet; you could ask. I'm slowly moving forwards, like most people these days I'm too busy to spend much time on this. I think it would be better to move all application scripting related code to an external package (and preferably one such package instead of the bundle of packages you need to install right now to get appscript). The rationale for this is that has is currently the only person that is working on application scripting support for python and that his work doesn't seem to be finished enough to freeze it by includeing it in the stdlib. > > >> 4.2 Carbon.AH -- Apple Help > > Do nothing. Documentation would be nice :-) > > >> 4.3 Carbon.App -- Appearance Manager > > Apple's docs describe AM as 'the older QuickDraw-centric version of > HITheme', but don't note it as being superceded/deprecated so I > guess it should stay as-is. > > >> 4.4 Carbon.CF -- Core Foundation >> 4.5 Carbon.CG -- Core Graphics >> 4.6 Carbon.CarbonEvt -- Carbon Event Manager > > Do nothing. > > >> 4.7 Carbon.Cm -- Component Manager > > According to Apple's docs CM is largely historical; modern apps > should use Core Foundation's Plug-in Services. Other Carbon APIs > still rely on it though, so do nothing. > > >> 4.8 Carbon.Ctl -- Control Manager > > According to Apple's docs, HIView is superseding the older Control > Manager. For now though, do nothing. > > >> 4.9 Carbon.Dlg -- Dialog Manager > > According to Apple's docs, Interface Builder and Carbon event > handlers mostly supersede the Dialog Manager, except in the cases > where you want to put up a standard alert dialog box or sheet. For > now though, do nothing. > > >> 4.10 Carbon.Evt -- Event Manager > > Deprecate, or at least add note to use modern alternative. > Superceded by CarbonEvt. Don't deprecate but not that you should CarbonEvt and that Apple has deprecated the Event Manager API. > > >> 4.11 Carbon.Fm -- Font Manager >> 4.12 Carbon.Folder -- Folder Manager >> 4.13 Carbon.Help -- Help Manager > > Do nothing. > > >> 4.14 Carbon.List -- List Manager > > Deprecate, or at least add note to use modern alternative. > Superceded by Control Manager. Same as Carbon.Evt. > > >> 4.15 Carbon.Menu -- Menu Manager >> 4.16 Carbon.Mlte -- MultiLingual Text Editor > > Do nothing. > > >> 4.17 Carbon.Qd -- QuickDraw > > Deprecate. QD is already deprecated in OS X 10.4. Likewise > > >> 4.18 Carbon.Qdoffs -- QuickDraw Offscreen > > Deprecate. QD is already deprecated in OS X 10.4. Likewise. > > >> 4.19 Carbon.Qt -- QuickTime > > Do nothing. Yet another piece of code to hunt down. Doesn't Bob have an enhanced version of this module? If so I think we should merge this into Python 2.5. > > >> 4.20 Carbon.Res -- Resource Manager and Handles > > According to Apple's docs, RM is historical, but I'm not sure about > alternatives; need to check out Bundle Services. For now, probably > do nothing. > > >> 4.21 Carbon.Scrap -- Scrap Manager > > According to Apple's docs, Scrap Manager is superceded by > Pasteboard Manager in OS X. We don't have a wrapper for that > though, so probably do nothing. > > >> 4.22 Carbon.Snd -- Sound Manager > > Do nothing. > > >> 4.23 Carbon.TE -- TextEdit > > Deprecate/add note. Superceded by Mlte, which has unicode support, > etc.. > > >> 4.24 Carbon.Win -- Window Manager >> 4.25 ColorPicker -- Color selection dialog > > Do nothing. > > >> 5. Undocumented Modules >> 5.1 applesingle -- AppleSingle decoder > > No idea. Anyone? > > >> 5.2 buildtools -- Helper module for BuildApplet and Friends > > Deprecate, or at least add a note that py2app is the modern > alternative and strongly recommended. > > >> 5.3 cfmfile -- Code Fragment Resource module > > Probably deprecate. Anyone? CFM is still used on OSX. However given the docstring for this module I'd guess that it can be deprecated. > > >> 5.4 icopen -- Internet Config replacement for open() > > Presumably in the same boat as '2.3 ic'. Anyone? I think this can be deprecated. This module replaces __builtin__.open by a function that sets the right type/creator codes using data from ic. That was useful in OS9, but I don't think is is very useful in today. > > >> 5.5 macerrors -- Mac OS Errors > > Do nothing. > > >> 5.6 macresource -- Locate script resources > > Presumably in same boat as '4.20 Carbon.Res'. Anyone? > > >> 5.7 Nav -- NavServices calls > > Do nothing. > > >> 5.8 PixMapWrapper -- Wrapper for PixMap objects > > Deprecate. (Since QD is deprecated on OS 10.4.) > > >> 5.9 videoreader -- Read QuickTime movies > > No idea. Anyone? This seems to be more of an example that a useful module. > > >> 5.10 W -- Widgets built on FrameWork > > Deprecate. > >> 5.11 waste -- non-Apple TextEdit replacement > > Deprecate? (ISTR it's not in the universal build.) I'm tempted to remove it altogether in 2.5. This depends on a 3th- party libary that isn't available for Intel. > > >> My inclination is to delete them all :-). Except for ones where >> someone pipes up and tells me it still works. Let folks use the Wiki >> to find modules. > > Your inclination is understandable, but I don't think it'd be > wisest. :) > > Personally I really dislike the 'deprecate in-place' approach that > seems to be used in the Python docs. It'd be much clearer and > easier on readers if all the crud were moved into a 'Deprecated > modules' chapter. That way it wouldn't force readers to wade > through piles of irrelevant cruft and junk each time that want to > look up current info, but it could still be found when needed. > Perhaps you could negotiate to do something like that? > > >> 4) Should we document some of the newer stuff? > > Carbon.LaunchServices, which is part of the standard library as of > 2.4. It should be added to the 'Carbon' section as another > placeholder page. > > There's also Carbon.OSA, which is part of the standard library as > of 2.4 (though it's buggy and incomplete), which can be added to > the 'Carbon' section as another placeholder page. It may or may not > be deprecated, depending on what happens with the Carbon.AE module. > > plistlib probably ought to be mentioned. I suspect it's evil, as > it's not using the Property List Services API, but am not familiar > enough with it to really say anything more with confidence. > > >> py2app comes to mind. > > For external projects I'd suggest adding placeholder pages that > simply link to external sites (i.e. quick and simple for now; > anyone with an urge to expand them can do so in their own time). > PyObjC, py2app and appscript are the three obvious ones that I can > think of. > > The PyObjC link is obvious . I imagine > you'd link to Bob's site for py2app. At some poing I'd like to > shift appscript off my personal webspace to a proper permanent home > (sourceforge??), so maybe point to the wiki page for that for now. I think it is better to keep not add references to PyObjC, py2app and appscript to the module reference other than in deprecation messages. That is, anyone that looks for the documentation for OSA modules should be told that those are deprecated and should be pointed to appscript. I really hate manuals that deprecate stuff without telling me what I should do instead. Ronald From ronaldoussoren at mac.com Wed Apr 19 21:56:52 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 21:56:52 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <06Apr19.091504pdt.58633@synergy1.parc.xerox.com> References: <06Apr19.091504pdt.58633@synergy1.parc.xerox.com> Message-ID: <6A3F977C-6186-4F80-A8AE-9896939D01A8@mac.com> On 19-apr-2006, at 18:14, Bill Janssen wrote: > Thanks, Has. > > I was hoping someone would go through that list bit-by-bit. > > I'm still in favor of simply removing outdated and dangerous docs, but > perhaps there's some effective way of thoroughly marking them as bad, > instead. I'm in favour of fixing stuff :-) Ronald From ronaldoussoren at mac.com Wed Apr 19 22:04:12 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:04:12 +0200 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <44466A01.8080903@noaa.gov> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> Message-ID: <72CECA44-C8F1-42D7-BFAF-687D661A4904@mac.com> On 19-apr-2006, at 18:49, Christopher Barker wrote: > Bob Ippolito wrote: >> *ALWAYS* prefer convenience over space. Never make separate >> distributions for i386 and PPC. Simplicity is key. > > Absolutely. > >> I will no longer accept single-architecture packages for >> pythonmac.org/packages except under special circumstances > > However... Right now, we don't have Universal packages for most > things. > This creates a difficult situation for folks, particularly those on > Intel Macs. It is a serious challenge to build Universal packages, at > least for those packages that rely on third party libs (PIL, > Matplotlib, > wxPython....) I'll post the script I'm using to build universal packages this weekend. I have recipes for the software I'm using and several other. That includes PIL (including jpeg, tif and freetype support). > About those libs: > > As it is a challenge to build universal libs, and a bunch of common > python packages require the same libs, I'd love to see a repository of > Universal libs for use with Python packages. It is actually not very hard to build univeral libraries for most software. I'd really prefer to ship addon packages as standalone eggs. > > My suggestion: > > A ExtraLibs.mpkg, right there with the packages on pythonmac.org that > includes Universal shared libs required by some common packages. They > could perhaps be installed in the Python Framework, so they won't > interfere with anything else. > > a) is this possible? yes > b) is this a good idea? no. This is an arbitrary selection of libraries, why these and not others? Ronald From janssen at parc.com Wed Apr 19 22:06:48 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 13:06:48 PDT Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: Your message of "Wed, 19 Apr 2006 11:59:01 PDT." <8F2517DD-4D6C-4371-8D04-A059D428A3AD@mac.com> Message-ID: <06Apr19.130650pdt."58633"@synergy1.parc.xerox.com> > It is annoying that www.python.org/download/mac doesn't mention the > universal installer. Could someone please fix that? Will do. Should this replace the dual-installer procedure that's mentioned there? For both 10.3 and 10.4? Bill From ronaldoussoren at mac.com Wed Apr 19 22:05:22 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:05:22 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446745F.5060501@fas.harvard.edu> References: <44454E9E.8050609@fas.harvard.edu> <06Apr18.160038pdt.58633@synergy1.parc.xerox.com> <4446745F.5060501@fas.harvard.edu> Message-ID: On 19-apr-2006, at 19:33, Jacob Rus wrote: >> There's the flat logo, but the logo I was pointing to was a version >> that's shaded a bit to look slightly raised and rounded. > > Were you looking for something more like [this][1]? That one looks nice. Ronald > > -Jacob > > [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kw at kevin-walzer.com Wed Apr 19 22:11:09 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Wed, 19 Apr 2006 16:11:09 -0400 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> Message-ID: <4446995D.8000803@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Oussoren wrote: >> >>> 4.2 Carbon.AH -- Apple Help >> Do nothing. > > Documentation would be nice :-) > >> I might be able to help here. I've actually used this module in non-Python apps (I used to use in Tcl/Tk apps by exec'ing 'python -c "from Carbon.AH...") and Aquamacs still loads its help docs this way. A Tkinter app I'm developing will also use this. What's the format for documentation? Who should it be sent to? - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFERplcrTC5hIgjqTMRAsCBAKCc9xo8vDnrmjXLkQo169WuRKZIVACdE0YQ EnPHZBT02PfxgBrcrfASRjA= =voUD -----END PGP SIGNATURE----- From daniellord at mac.com Wed Apr 19 22:12:32 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 13:12:32 -0700 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> Message-ID: <8BF00E6B-1908-4F47-BBC5-F4A483C9A48D@mac.com> On Apr 19, 2006, at 12:52, Ronald Oussoren wrote: >>> 2.1 macpath -- MacOS path manipulation functions >> >> Deprecate. Also note that the 2.4.3 documentation now says "It can >> be used to manipulate old-style Macintosh pathnames on Mac OS X (or >> any other platform)." which is incorrect (it uses POSIX-style >> paths), so delete that sentence. > > I'm not a native english speaker, but I read this as "you can use > this to manipulate OS9 style paths on any platform". Just like you > can use ntpath to manipulate windows-style paths (c:\foo\bar.txt) on > any platform. That's actually a useful feature. > > As I mentioned in another message this module might be useful to work > with OS9-style paths as used by some Carbon API's. Good suggestion, Ronald. I was just tinkering around with appscript and MS Excel a few days ago (still cannot access some things like borders properly and others are just 'bass-ackwards' in the Excel terminology defs so I gave up) but Excel expects colon-separated paths in file paths (yes even in 2004 when they last updated it). SO keeping the OS9 path separator routines is a good idea. I didn't know about them and so wrote my own regex conversion functions (ugh!) as a workaround. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/ea21d906/attachment.htm From skip at pobox.com Wed Apr 19 22:13:02 2006 From: skip at pobox.com (skip at pobox.com) Date: Wed, 19 Apr 2006 15:13:02 -0500 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: <06Apr18.160523pdt."58633"@synergy1.parc.xerox.com> References: <06Apr18.160523pdt."58633"@synergy1.parc.xerox.com> Message-ID: <17478.39374.215727.317882@montanaro.dyndns.org> Bill> But the NEWS section of python.org is totally disfunctional. Bill> Months go by without anyone bothering to add anything to it; I Bill> think the trouble is that no one knows what the "add" procedure Bill> is. I tend to agree with you. Given all the recent changes to the site, including a completely new tool chain used to build it, details about updating various bits like NEWS have been lost by many. Skip From janssen at parc.com Wed Apr 19 22:13:42 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 13:13:42 PDT Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: Your message of "Wed, 19 Apr 2006 12:56:52 PDT." <6A3F977C-6186-4F80-A8AE-9896939D01A8@mac.com> Message-ID: <06Apr19.131345pdt."58633"@synergy1.parc.xerox.com> > > On 19-apr-2006, at 18:14, Bill Janssen wrote: > > > Thanks, Has. > > > > I was hoping someone would go through that list bit-by-bit. > > > > I'm still in favor of simply removing outdated and dangerous docs, but > > perhaps there's some effective way of thoroughly marking them as bad, > > instead. > > I'm in favour of fixing stuff :-) > > Ronald > Sure. The question is, who's signing up to fix what, and how? Bill From skip at pobox.com Wed Apr 19 22:20:27 2006 From: skip at pobox.com (skip at pobox.com) Date: Wed, 19 Apr 2006 15:20:27 -0500 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: <8F2517DD-4D6C-4371-8D04-A059D428A3AD@mac.com> References: <8F2517DD-4D6C-4371-8D04-A059D428A3AD@mac.com> Message-ID: <17478.39819.374947.414968@montanaro.dyndns.org> Ronald> It is annoying that www.python.org/download/mac doesn't mention Ronald> the universal installer. It does now. It will take a few minutes for the global build process to update the website, but I checked in a minimal change to Subversion. Skip From ronaldoussoren at mac.com Wed Apr 19 22:22:04 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:22:04 +0200 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: <06Apr19.130650pdt.58633@synergy1.parc.xerox.com> References: <06Apr19.130650pdt.58633@synergy1.parc.xerox.com> Message-ID: On 19-apr-2006, at 22:06, Bill Janssen wrote: >> It is annoying that www.python.org/download/mac doesn't mention the >> universal installer. Could someone please fix that? > > Will do. Should this replace the dual-installer procedure that's > mentioned there? For both 10.3 and 10.4? The universal installer can be used for OSX 10.3.9 and later. There is no current installer for earlier releases of the OS. I haven't checked yet if the universal installer on python.org is still the original one without optimization or if it got replaced by the newer one. I've removed the latter from my iDisk because I ran out of the bandwidth allotment for my site :-(. Ronald From hengist.podd at virgin.net Wed Apr 19 22:23:58 2006 From: hengist.podd at virgin.net (has) Date: Wed, 19 Apr 2006 21:23:58 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> Message-ID: Ronald wrote: >Macpath deals with OS9/Carbon style paths (Volume:directory:file instead of /Volume/directory/file). Don't know where you're seeing this; I've tried a few of the functions and none work with HFS-style paths, only POSIX-style paths. The documentation describes it as an OS9 implementation of os.path, which I take to mean same Python API, presumably bridged to from os.path, but a different underlying implementation to get around the lack of POSIX APIs in OS 9 and earlier. I would imagine os.path just uses the standard Unix APIs on OS X, in which case this module is completely redundant and can be removed fairly quickly after deprecation. >Has can probably comment on the usefulness of the rest of section 3. Way ahead of you already. :) http://mail.python.org/pipermail/pythonmac-sig/2006-April/017046.html has -- http://freespace.virgin.net/hamish.sanderson/ From ronaldoussoren at mac.com Wed Apr 19 22:25:00 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:25:00 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <4446995D.8000803@kevin-walzer.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> <4446995D.8000803@kevin-walzer.com> Message-ID: <45B74812-525E-4447-97BF-9857C93E80CF@mac.com> On 19-apr-2006, at 22:11, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ronald Oussoren wrote: > >>> >>>> 4.2 Carbon.AH -- Apple Help >>> Do nothing. >> >> Documentation would be nice :-) >> >>> > > I might be able to help here. I've actually used this module in > non-Python apps (I used to use in Tcl/Tk apps by exec'ing 'python -c > "from Carbon.AH...") and Aquamacs still loads its help docs this > way. A > Tkinter app I'm developing will also use this. > > What's the format for documentation? Who should it be sent to? The format is a dialect of LaTeX, but supplying just plain text should be fine to as the documentation maintainers will convert it to the proper format if needed. Any documentation should be uploaded as a patch on sourceforge. Ronald From daniellord at mac.com Wed Apr 19 22:27:45 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 13:27:45 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <72CECA44-C8F1-42D7-BFAF-687D661A4904@mac.com> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> <72CECA44-C8F1-42D7-BFAF-687D661A4904@mac.com> Message-ID: <3F590BBD-2E9D-4AA0-88AD-E97E2F79313D@mac.com> On Apr 19, 2006, at 13:04, Ronald Oussoren wrote: > I'll post the script I'm using to build universal packages this > weekend. > I have recipes for the software I'm using and several other. That > includes > PIL (including jpeg, tif and freetype support). I'll put mine on my iDisk and send you a link. I'd like to see your scripts since I did it by hand and recorded it with bash typescript-- to later script it using sed for the text editing. I have a Macbook Pro and PPC will be happy to test things. > It is actually not very hard to build univeral libraries for most > software. Yeah, if *I* can do it it cannot be too arcane ;-) > I'd really prefer to ship addon packages as standalone eggs. Agreed Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/3322d96a/attachment.html From ronaldoussoren at mac.com Wed Apr 19 22:28:55 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:28:55 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <06Apr19.131345pdt.58633@synergy1.parc.xerox.com> References: <06Apr19.131345pdt.58633@synergy1.parc.xerox.com> Message-ID: <01619847-C38A-46A6-A911-D9E08F7C9BB9@mac.com> On 19-apr-2006, at 22:13, Bill Janssen wrote: >> >> On 19-apr-2006, at 18:14, Bill Janssen wrote: >> >>> Thanks, Has. >>> >>> I was hoping someone would go through that list bit-by-bit. >>> >>> I'm still in favor of simply removing outdated and dangerous >>> docs, but >>> perhaps there's some effective way of thoroughly marking them as >>> bad, >>> instead. >> >> I'm in favour of fixing stuff :-) >> >> Ronald >> > > Sure. The question is, who's signing up to fix what, and how? I don't know who will do it, I do know that we won't get very far by just talking about it ;-). Pick some part that you consider broken and propose how this can be fixed. I do want to fix as many bugs as possible for python 2.5, but that won't happen by itself. Ronald From ronaldoussoren at mac.com Wed Apr 19 22:29:26 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:29:26 +0200 Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: <17478.39819.374947.414968@montanaro.dyndns.org> References: <8F2517DD-4D6C-4371-8D04-A059D428A3AD@mac.com> <17478.39819.374947.414968@montanaro.dyndns.org> Message-ID: <793E687C-D6D5-463B-A899-D149870B51BD@mac.com> On 19-apr-2006, at 22:20, skip at pobox.com wrote: > > Ronald> It is annoying that www.python.org/download/mac doesn't > mention > Ronald> the universal installer. > > It does now. It will take a few minutes for the global build > process to > update the website, but I checked in a minimal change to Subversion. Thanks. Ronald From janssen at parc.com Wed Apr 19 22:34:01 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 13:34:01 PDT Subject: [Pythonmac-SIG] Mac Python is DEAD In-Reply-To: Your message of "Wed, 19 Apr 2006 13:13:02 PDT." <17478.39374.215727.317882@montanaro.dyndns.org> Message-ID: <06Apr19.133405pdt."58633"@synergy1.parc.xerox.com> NEWS was broken long before the new site. Bill From ronaldoussoren at mac.com Wed Apr 19 22:35:01 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:35:01 +0200 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <3F590BBD-2E9D-4AA0-88AD-E97E2F79313D@mac.com> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> <72CECA44-C8F1-42D7-BFAF-687D661A4904@mac.com> <3F590BBD-2E9D-4AA0-88AD-E97E2F79313D@mac.com> Message-ID: <29C12ADF-9680-475A-B09C-590AE5468C69@mac.com> On 19-apr-2006, at 22:27, Daniel Lord wrote: > > On Apr 19, 2006, at 13:04, Ronald Oussoren wrote: > >> I'll post the script I'm using to build universal packages this >> weekend. >> I have recipes for the software I'm using and several other. That >> includes >> PIL (including jpeg, tif and freetype support). > I'll put mine on my iDisk and send you a link. I'd like to see your > scripts since I did it by hand and recorded it with bash > typescript--to later script it using sed for the text editing. I > have a Macbook Pro and PPC will be happy to test things. I have a python script that's derived from the script that I'm using to build the univeral python distribution. > >> It is actually not very hard to build univeral libraries for most >> software. > Yeah, if *I* can do it it cannot be too arcane ;-) It can be pretty involved. If you're very unlucky you'll have to build a ppc and intel version version of software and then merge them using lipo. Luckily most python-related software I've run into until now can be coaxed into building using 'cc -arch ppc -arch i386' as the compiler. Ronald From skip at pobox.com Wed Apr 19 22:37:39 2006 From: skip at pobox.com (skip at pobox.com) Date: Wed, 19 Apr 2006 15:37:39 -0500 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <01619847-C38A-46A6-A911-D9E08F7C9BB9@mac.com> References: <06Apr19.131345pdt.58633@synergy1.parc.xerox.com> <01619847-C38A-46A6-A911-D9E08F7C9BB9@mac.com> Message-ID: <17478.40851.848585.602856@montanaro.dyndns.org> Ronald> I don't know who will do it, I do know that we won't get very Ronald> far by just talking about it ;-). Pick some part that you Ronald> consider broken and propose how this can be fixed. I do want to Ronald> fix as many bugs as possible for python 2.5, but that won't Ronald> happen by itself. If you find something that needs fixing to the website and don't have Subversion checkin privileges, feel free to send me (skip at pobox.com) the proposed change(s). I tend to get behind reading Python mailing lists not directly related to Python development, but if you send changes directly to me I'll try and get to them within a few hours or a day. Skip From jrus at fas.harvard.edu Wed Apr 19 22:41:59 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 16:41:59 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <4446A097.6030607@fas.harvard.edu> has wrote: > Jacob Rus wrote: >>> There's the flat logo, but the logo I was pointing to was a version >>> that's shaded a bit to look slightly raised and rounded. >> Were you looking for something more like [this][1]? >> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png > > The snake logo you've used there is an earlier, boxier attempt that's not as pleasing to the eye, and not the final version used on python.org. > > The version Bill means (I couldn't get his link to work) is this: > > http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/newlogo/python-logo-master-v3-trans.png > > Each snake has a slight linear colour gradient running diagonally, and the outer edges are curved. Ok, got it. Well, I've now put more time into this than I wanted to, but I've got a glassy version of the correct python logo at full size, [here][4]. Let me know what you all think. If it looks good to everyone, I can make a .py icon like the one linked above, and an editor icon like Script Editor and TextEdit's, though someone will have to help me with the pen/pencil/whatever. I'm still not clear what the "drag-n-drop script runner" icon should look like. -Jacob [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png From ronaldoussoren at mac.com Wed Apr 19 22:47:23 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 19 Apr 2006 22:47:23 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> Message-ID: <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> On 19-apr-2006, at 22:23, has wrote: > Ronald wrote: > >> Macpath deals with OS9/Carbon style paths (Volume:directory:file >> instead of /Volume/directory/file). > > Don't know where you're seeing this; I've tried a few of the > functions and none work with HFS-style paths, only POSIX-style > paths. The documentation describes it as an OS9 implementation of > os.path, which I take to mean same Python API, presumably bridged > to from os.path, but a different underlying implementation to get > around the lack of POSIX APIs in OS 9 and earlier. >>> help(macpath) >>> macpath.join('foo', 'bar') ':foo:bar' macpath is what got used as os.path on MacOS9, just like posixpath is os.path on unixy systems (including OSX) and ntpath is used on windows. Those can be used directly to manipulate paths for other platforms which is occasionally useful. > > I would imagine os.path just uses the standard Unix APIs on OS X, > in which case this module is completely redundant and can be > removed fairly quickly after deprecation. Yes, os.path is posixpath on OSX. > > >> Has can probably comment on the usefulness of the rest of section 3. > > Way ahead of you already. :) > > http://mail.python.org/pipermail/pythonmac-sig/2006-April/017046.html I noticed ;-) Ronald > > has > -- > http://freespace.virgin.net/hamish.sanderson/ From daniellord at mac.com Wed Apr 19 22:50:01 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 13:50:01 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446A097.6030607@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> Message-ID: On Apr 19, 2006, at 13:41, Jacob Rus wrote: > Ok, got it. Well, I've now put more time into this than I wanted to, > but I've got a glassy version of the correct python logo at full size, > [here][4]. Let me know what you all think. If it looks good to > everyone, I can make a .py icon like the one linked above, and an > editor > icon like Script Editor and TextEdit's, though someone will have to > help > me with the pen/pencil/whatever. I'm still not clear what the > "drag-n-drop script runner" icon should look like. > > -Jacob > > [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png Awesome! Ya da man! This get's my vote. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/29cdf4fe/attachment.htm From daniellord at mac.com Wed Apr 19 22:56:08 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 13:56:08 -0700 Subject: [Pythonmac-SIG] Universal PIL for Python 2.4 on OS X 10.4 needs testing In-Reply-To: <01619847-C38A-46A6-A911-D9E08F7C9BB9@mac.com> References: <06Apr19.131345pdt.58633@synergy1.parc.xerox.com> <01619847-C38A-46A6-A911-D9E08F7C9BB9@mac.com> Message-ID: I tested my Universal PIL installer for Python 2.4 on 10.4 on my MacbookPro but not PPC (my daughters refuse to quit Zoo Tycoon 2 and log off so I can tinker with it ;-) and it seems to work though I don't have a rigorous PIL test suite. The zip file is on my iDisk if anyone wants to give it a try. If it works, please somebody move it to a public host so I don't use up my bandwidth allotment like Ronald did ;-) http://homepage.mac.com/daniellord From njriley at uiuc.edu Wed Apr 19 23:02:28 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Wed, 19 Apr 2006 16:02:28 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446A097.6030607@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> Message-ID: <20060419210227.GC57150@uiuc.edu> On Wed, Apr 19, 2006 at 04:41:59PM -0400, Jacob Rus wrote: > Ok, got it. Well, I've now put more time into this than I wanted to, > but I've got a glassy version of the correct python logo at full size, > [here][4]. Let me know what you all think. If it looks good to > everyone, I can make a .py icon like the one linked above, and an editor > icon like Script Editor and TextEdit's, though someone will have to help > me with the pen/pencil/whatever. I'm still not clear what the > "drag-n-drop script runner" icon should look like. Looks great. Quick, make the other icons before anyone else complains! :) -- Nicholas Riley | From saggau at gmail.com Wed Apr 19 23:41:25 2006 From: saggau at gmail.com (Saggau) Date: Wed, 19 Apr 2006 17:41:25 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <20060419210227.GC57150@uiuc.edu> References: <4446A097.6030607@fas.harvard.edu> <20060419210227.GC57150@uiuc.edu> Message-ID: First thing that hit my brain: "That's IT." <----that doesn't happen often in my life. Rock on. Jonathan On 4/19/06, Nicholas Riley wrote: > > On Wed, Apr 19, 2006 at 04:41:59PM -0400, Jacob Rus wrote: > > Ok, got it. Well, I've now put more time into this than I wanted to, > > but I've got a glassy version of the correct python logo at full size, > > [here][4]. Let me know what you all think. If it looks good to > > everyone, I can make a .py icon like the one linked above, and an editor > > icon like Script Editor and TextEdit's, though someone will have to help > > me with the pen/pencil/whatever. I'm still not clear what the > > "drag-n-drop script runner" icon should look like. > > Looks great. Quick, make the other icons before anyone else > complains! :) > > -- > Nicholas Riley | > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality. - Harry Partch There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are not even capable of forming such opinions. - Einstein -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/9856efc3/attachment.htm From jrus at fas.harvard.edu Thu Apr 20 00:30:25 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 18:30:25 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446A097.6030607@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> Message-ID: <4446BA01.2020807@fas.harvard.edu> Ok, what do you all think of these script and compiled script icons: PNG: http://hcs.harvard.edu/~jrus/python/python-icons-a1.png ZIP: http://hcs.harvard.edu/~jrus/python/python-icons-a1.zip The zip file contains icns files, png files, and also folders with the icons applied. I'm glad to provide Photoshop files as well, if someone wants them. -Jacob From Chris.Barker at noaa.gov Thu Apr 20 00:53:00 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 15:53:00 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <38833B9B-8083-4635-9381-6BCEBBC91DCA@redivi.com> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> <38833B9B-8083-4635-9381-6BCEBBC91DCA@redivi.com> Message-ID: <4446BF4C.1010508@noaa.gov> Bob Ippolito wrote: > The libs should all be statically linked to the extensions, they > shouldn't be separate in the installer. Ronald Oussoren wrote: > I'd prefer to have fully self contained packages, and preferably > eggs at that. Having a shared libary makes it *harder* to independendly > update extensions using libpng or libfreetype. No one answered my question directly, but both Bob and Ronald have spoken: It's better for each package to statically link any libs it needs (unless Apple provides them), even though that means that a given python program may well end up using three copies of the same lib. Just to be totally clear: Is there any problem with the same program using three slightly different versions of the same lib? > I'll have to package up my package build script one of these days ;-) What does it do? Something different than bdist_mpkg ? Daniel Lord wrote: > I built Universal jpeg-6b, freetype2, and zlib for my current project > of Universal PIL. I can add libpng in easily so I'll do it. > So that makes jpeg, png, freetype, and zlib. What else? Those are the ones I need at the moment. Thanks! I guess a zip archive of the collection would be the best way to get it out there. > I have successfully packaged up a Universal PIL for 2.4 (thanks for > the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am > closer to releasing it. Post a link to it here when you are ready so we can test it. Maybe it would be helpful to have a standard way to link static libs with our packages. What I've done for matplotlib is create a "StaticLibs" directory at the same level as the setup./py, then hacked the setup.py to include it in the linking (and header) paths. I'll probably create one that has all of the above libs in it, then I can add a symlink to it for each package I'm trying to build. If anyone has any better ideas, I'd be glad to hear them. -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 at noaa.gov From Chris.Barker at noaa.gov Thu Apr 20 01:13:41 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 16:13:41 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446BA01.2020807@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> Message-ID: <4446C425.60202@noaa.gov> Jacob Rus wrote: > Ok, what do you all think of these script and compiled script icons: They look great, but what the heck is "DATA"? -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 at noaa.gov From berkowit at silcom.com Thu Apr 20 01:22:43 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Wed, 19 Apr 2006 16:22:43 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446A097.6030607@fas.harvard.edu> Message-ID: On 4/19/06 1:41 PM, "Jacob Rus" wrote: > Ok, got it. Well, I've now put more time into this than I wanted to, > but I've got a glassy version of the correct python logo at full size, > [here][4]. Let me know what you all think. If it looks good to > everyone, I can make a .py icon like the one linked above, and an editor > icon like Script Editor and TextEdit's, though someone will have to help > me with the pen/pencil/whatever. I'm still not clear what the > "drag-n-drop script runner" icon should look like. > > -Jacob > > [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png Looks great. And all the icons too. -- Paul Berkowitz From jrus at fas.harvard.edu Thu Apr 20 01:35:39 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 19:35:39 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446C425.60202@noaa.gov> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> Message-ID: <4446C94B.5090400@fas.harvard.edu> Christopher Barker wrote: > They look great, but what the heck is "DATA"? It was has's [idea][1] for what a .pyo/.pyc icons should look like, similar to how script editor allows saving of plain text .applescript files with an icon labeled "TEXT". [1]: http://mail.python.org/pipermail/pythonmac-sig/2006-April/016912.html Here are my thoughts on the rest of his post: > IDLE.app application - a text-based script editor for > Python. I'd suggest something similar to Script > Editor.app, except using the Python logo and a different > style of pen (e.g. technical drawing pen/pencil) of > course. Does someone have an example picture of a technical drawing pencil/pen that I could copy? > .py/.pyw files - Python source code document, editable > and executable; the 'normal' file format used by Python > scripters. I'd suggest something similar to AppleScript > .scpt files, except using the Python logo > > .pyc/.pyo files - Python binary code document, > executable but non-editable (should be similar to > .py/.pyw icon, exept indicating binary content); these > are mostly auto-generated by Python for efficiency. I'd > suggest a variation of the .py icon that indicated > binary content, e.g. a light backdrop of rows of random > 1s and 0s, or a word like '011010', 'byte' or 'data' in > its lower half. Ok, this is what I tried to do with those examples. Do people like them as is, or are there other ideas? > BuildApplet.app application - a drag-n-drop converter > that turns Python code files into standalone > double-clickable applications. A DropStuff.app-style > grinder (which is what the old icon uses) is certainly > one option. Does anyone have an OS X icon suitable grinder image? Alternately, something like the [help indexer][2] icon may work. I agree we want the idea of scripts going in and applications coming out. That probably means whatever we use for the applet icon should be coming out the other side. Thoughts? [2]: /Developer/Applications/Utilities/Help Indexer.app > applet applications - applets created by Build > Applet.app should be given a generic 'Python-based > applet' icon by default. Probably use something similar > to the AppleScript applets created by Script Editor.app. Hmm. I'm not sure whether python logo sitting on a white square will really do it. I can try to mock that up though. Are there any other ideas out there? > PythonLauncher.app application - a drag-n-drop script > runner. Possibly use something similar to the Applet > Launcher.app for Java. Grey rocket ship with python logo on the front? This might work, but also might look kind of lame, like the java Applet Launcher icon does. Then again, I don't have any great ideas for better ways to do this. Also, does anyone have anyone have any suggestions for the glassy python logo before I go ahead and make a bunch more icons based on it? -Jacob From janssen at parc.com Thu Apr 20 02:11:35 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 17:11:35 PDT Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: Your message of "Wed, 19 Apr 2006 13:37:39 PDT." <17478.40851.848585.602856@montanaro.dyndns.org> Message-ID: <06Apr19.171136pdt."58633"@synergy1.parc.xerox.com> Well, I was planning on fixing the documentation, but apparently the process requires a level of bureaucracy I'm just not willing to go through (though I can see why it might be necessary). I can't just check out the TeX sources and fix them, then check them back in. Instead, I apparently have to submit patches against them to sourceforge, using the cumbersome bugzilla, and wait for the documentation elves to update the documents. Perhaps this is why the documentation lags behind the code? Bill From daniellord at mac.com Thu Apr 20 02:32:32 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 17:32:32 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <4446BF4C.1010508@noaa.gov> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> <38833B9B-8083-4635-9381-6BCEBBC91DCA@redivi.com> <4446BF4C.1010508@noaa.gov> Message-ID: On Apr 19, 2006, at 15:53, Christopher Barker wrote: > Bob Ippolito wrote: >> The libs should all be statically linked to the extensions, they >> shouldn't be separate in the installer. > > Ronald Oussoren wrote: >> I'd prefer to have fully self contained packages, and preferably >> eggs at that. Having a shared libary makes it *harder* to >> independendly >> update extensions using libpng or libfreetype. > > No one answered my question directly, but both Bob and Ronald have > spoken: > > It's better for each package to statically link any libs it needs > (unless Apple provides them), even though that means that a given > python > program may well end up using three copies of the same lib. > > Just to be totally clear: Is there any problem with the same program > using three slightly different versions of the same lib? NOt as far as I can tell--the libraries are statically linked so don't even need to be on the platform after that. > >> I'll have to package up my package build script one of these days ;-) > > What does it do? Something different than bdist_mpkg ? By build I by hand: curl, patch code by hand, make; sudo make install. The libs need their make components patched to compile FAT binaries and PIL needed to be patched to find the .a files to link into its binaries. And freetype uses a confusing Jam-based install which had me searching for where to change it. > > Daniel Lord wrote: >> I built Universal jpeg-6b, freetype2, and zlib for my current project >> of Universal PIL. I can add libpng in easily so I'll do it. >> So that makes jpeg, png, freetype, and zlib. What else? > > Those are the ones I need at the moment. Thanks! I guess a zip archive > of the collection would be the best way to get it out there. I'll zip up the .a files and put them on my iDisk--will send you a URL when ready. > >> I have successfully packaged up a Universal PIL for 2.4 (thanks for >> the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am >> closer to releasing it. > > Post a link to it here when you are ready so we can test it. Bob tested it and posted it already (see his email). More testing would be appropriate though. > Maybe it would be helpful to have a standard way to link static libs > with our packages. What I've done for matplotlib is create a > "StaticLibs" directory at the same level as the setup./py, then hacked > the setup.py to include it in the linking (and header) paths. That sound reasonable, but not what I did--I installed them in /usr/ local/lib & include. > > I'll probably create one that has all of the above libs in it, then I > can add a symlink to it for each package I'm trying to build. > > If anyone has any better ideas, I'd be glad to hear them. > > -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 at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From delza at livingcode.org Thu Apr 20 02:47:37 2006 From: delza at livingcode.org (Dethe Elza) Date: Wed, 19 Apr 2006 17:47:37 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446BA01.2020807@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> Message-ID: <24d517dd0604191747gc092a9ct76e8938c7444e828@mail.gmail.com> On 4/19/06, Jacob Rus wrote: > Ok, what do you all think of these script and compiled script icons: > > PNG: http://hcs.harvard.edu/~jrus/python/python-icons-a1.png > ZIP: http://hcs.harvard.edu/~jrus/python/python-icons-a1.zip > > The zip file contains icns files, png files, and also folders with the > icons applied. > > I'm glad to provide Photoshop files as well, if someone wants them. > > -Jacob The icons are great, very Aqua and very Pythonic. Thanks for the time you put into this, and thanks to everyone else on the list for putting in the effort to test and critique other designs. This is going to make Python on the Mac look much more professional than the old falling weight did. Very nice. --Dethe From janssen at parc.com Thu Apr 20 02:57:33 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 17:57:33 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Wed, 19 Apr 2006 15:30:25 PDT." <4446BA01.2020807@fas.harvard.edu> Message-ID: <06Apr19.175742pdt."58633"@synergy1.parc.xerox.com> Jacob, Looks fine. It's interesting to look at the icons for TextEdit, in /Applications/TextEdit.app/Contents/Resources/*.icns. And looking at the XCode icons (/Developer/Applications/Xcode.app/Contents/Resources/*.icns), it looks like the "Mac way" of doing code icons (like for .py files) is to start with /Developer/Applications/Xcode.app/Contents/Resources/wosfile.icns and add a text version of the file suffix, in our case ".py". Apparently it should be a color; I'd pick green because the ".java" icon is a green one, and Python, like Java, is a byte-code interpreted language. Bill From daniellord at mac.com Thu Apr 20 03:32:32 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 18:32:32 -0700 Subject: [Pythonmac-SIG] py2app argvemulation bug (or mis-configure) on i386 Python 2.4 on OS X 10.4 Message-ID: <581BF313-3403-45EB-A1B8-B35F2742A253@mac.com> I decide to create a droplet from py2app in my copious spare time for a few minutes earlier and I noticed some errors in the Console plus the code is simply printing out all the strings in sys.argv plus, of course given the error, the paths of the files dropped on it never showed up in sys.argv[]. platform: Python 2.4 OS X 10.4 Universal MacbookPro i386 I did set: argv_emulation=True in the py2app options in setup.py I this below a know error on Python 2.4 on Intel? Console output: Exception in AE event handler function Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ python2.4/plat-mac/argvemulator.py", line 75, in callback_wrapper raise 'Cannot happen: AE callback without handler', (_class, _type) Cannot happen: AE callback without handler: ('tvea', 'codo') AE error: (-1, 'queue element not found during deletion') in High Level Event: '0x61657674' '0x6f636f64' Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ python2.4/plat-mac/argvemulator.py", line 53, in lowlevelhandler AE.AEProcessAppleEvent(event) Error: (-1, 'queue element not found during deletion') From jrus at fas.harvard.edu Thu Apr 20 03:34:58 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 21:34:58 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr19.175742pdt."58633"@synergy1.parc.xerox.com> References: <4446BA01.2020807@fas.harvard.edu> <06Apr19.175742pdt."58633"@synergy1.parc.xerox.com> Message-ID: <4446E542.1020803@fas.harvard.edu> Bill Janssen wrote: > It's interesting to look at the icons for TextEdit, in > /Applications/TextEdit.app/Contents/Resources/*.icns. > > And looking at the XCode icons > (/Developer/Applications/Xcode.app/Contents/Resources/*.icns), it > looks like the "Mac way" of doing code icons (like for .py files) is > to start with > /Developer/Applications/Xcode.app/Contents/Resources/wosfile.icns and > add a text version of the file suffix, in our case ".py". Apparently > it should be a color; I'd pick green because the ".java" icon is a > green one, and Python, like Java, is a byte-code interpreted language. No, I disagree. If there is any text, it should be in dark gray 18 point Lucida Grande, as per the HIG. XCode uses colored file extensions in its document graphics because it deals with many different types of source files, and this keeps them distinguishable. Python only has to worry about python scripts, and so a document icon with a distinguishable logo is sufficient (no need for text). This follows the example of apps like Script Editor. As for the rest of the icons. [Here][1] are several icons used by various OS X apps. Which of them should we draw on, and how? -Jacob [1]: http://hcs.harvard.edu/~jrus/python/misc-icons.png From janssen at parc.com Thu Apr 20 03:39:36 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 18:39:36 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Wed, 19 Apr 2006 17:57:33 PDT." <06Apr19.175742pdt."58633"@synergy1.parc.xerox.com> Message-ID: <06Apr19.183937pdt."58633"@synergy1.parc.xerox.com> I found two articles on creating icons that may provide some info. http://www.oreillynet.com/lpt/a/866 and http://www.oreillynet.com/lpt/a/964. Bill From janssen at parc.com Thu Apr 20 03:54:55 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 19 Apr 2006 18:54:55 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Wed, 19 Apr 2006 18:34:58 PDT." <4446E542.1020803@fas.harvard.edu> Message-ID: <06Apr19.185458pdt."58633"@synergy1.parc.xerox.com> > No, I disagree. If there is any text, it should be in dark gray 18 > point Lucida Grande, as per the HIG. XCode uses colored file extensions > in its document graphics because it deals with many different types of > source files, and this keeps them distinguishable. It's not just XCode. *Users* deal with many different kinds of source files, and apparently the icons used in XCode are the ones that Mac OS X uses generically. For example, look at the Finder icon for a Java source file, and you'll see that the XCode icon is used there, as well. The greeked source code in the background of the document indicates "source code", the file extension indicates the language, and the color apparently indicates something as well, though it's not clear (to me) just what. I'm happy with your .py icon, though having the greeked source code in the background would be cool. Of course, it's not Python source code. But we should be clear that we are using a non-Mac visual vocabulary here. Bill From jrus at fas.harvard.edu Thu Apr 20 04:06:34 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Wed, 19 Apr 2006 22:06:34 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <06Apr19.185458pdt."58633"@synergy1.parc.xerox.com> References: <4446E542.1020803@fas.harvard.edu> <06Apr19.185458pdt."58633"@synergy1.parc.xerox.com> Message-ID: <4446ECAA.8060800@fas.harvard.edu> Bill Janssen wrote: >> No, I disagree. If there is any text, it should be in dark gray 18 >> point Lucida Grande, as per the HIG. XCode uses colored file >> extensions in its document graphics because it deals with many >> different types of source files, and this keeps them >> distinguishable. > > It's not just XCode. *Users* deal with many different kinds of > source files, and apparently the icons used in XCode are the ones > that Mac OS X uses generically. For example, look at the Finder icon > for a Java source file, and you'll see that the XCode icon is used > there, as well. Yes, java source files get the xcode icons, because XCode is set up on your machine as the editor for java files (and registered as such with Launch Services). Similarly for c, etc. On my machine, some of these get XCode document icons, and some get TextMate document icons, because for me, TextMate is the editor for those file types. You miss my point, which is that python files don't need giant colored "py" splashed across them, if they have a distinguishable python icon. XCode does not follow the HIG, because it makes distinguishing c files from java files easier. Our new python icon will not have this problem, because it only needs to represent with one type of file. > The greeked source code in the background of the document indicates > "source code", the file extension indicates the language, and the > color apparently indicates something as well, though it's not clear > (to me) just what. If you like, we could add some greeked source code. If we do, then the pyo/pyc files will need something other than random 1s and 0s to distinguish it, especially at small sizes. I'm open to suggestions. > I'm happy with your .py icon, though having the greeked source code > in the background would be cool. Of course, it's not Python source > code. But we should be clear that we are using a non-Mac visual > vocabulary here. It's easy enough to add greeked python source code. If the feeling is that this helps the icon, we can add whatever type of greeked source code we like. From kevin at macosx.com Thu Apr 20 04:55:01 2006 From: kevin at macosx.com (kevin parks) Date: Wed, 19 Apr 2006 22:55:01 -0400 Subject: [Pythonmac-SIG] Unintsaller for Universal In-Reply-To: References: Message-ID: Hi... I been happily running 2.4.1 on my mac but i decided to load the universal installer on a different mac (that we plan to use for performance) and use 2.4.3 ... i mean why install and old version right ... uhmm ... anyway 2.4.3 is causing me much acid indigestion and is not playing nice with an audio package that i use and depend on.. (http://www.rtcmix.org) .... clearly i me and the folks who make rtcmix don't know enough about distutils to be on the cutting edge... I am desperate to dumb down to 2.4.1 and reinstall my rtcmix install with that (since i know it works on the other mac that way just fine) .... My understanding from reading this SIG is that this puppy would have a clean UNINSTALLER ... yet i don't see it... How do i uninstall 2.4.3? so that i can dial back to 2.4.1? or am i screwed? cheers, kevin From brendansimons at yahoo.ca Thu Apr 20 06:01:53 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu, 20 Apr 2006 00:01:53 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: >> Jacob Rus wrote: >> >>>> There's the flat logo, but the logo I was pointing to was a version >>>> that's shaded a bit to look slightly raised and rounded. >>>> >>> Were you looking for something more like [this][1]? >>> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png >>> >> The snake logo you've used there is an earlier, boxier attempt >> that's not as pleasing to the eye, and not the final version used >> on python.org. >> The version Bill means (I couldn't get his link to work) is this: >> http://www.fastmirrors.org/python/pub/beta.python.org/resources/ >> design/newlogo/python-logo-master-v3-trans.png >> Each snake has a slight linear colour gradient running diagonally, >> and the outer edges are curved. >> > > Ok, got it. Well, I've now put more time into this than I wanted > to, but I've got a glassy version of the correct python logo at > full size, [here][4]. Let me know what you all think. If it looks > good to everyone, I can make a .py icon like the one linked above, > and an editor icon like Script Editor and TextEdit's, though > someone will have to help me with the pen/pencil/whatever. I'm > still not clear what the "drag-n-drop script runner" icon should > look like. > > -Jacob > > [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png I fiddled with the java applet launcher icon a few weeks ago, but I didn't much like the result. You can see a copy here: http:// www.flickr.com/photos/28928816 at N00/131701626/ If you want the photoshop file with just the stretched out rocket, let me know Brendan -- Brendan Simons __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brendansimons at yahoo.ca Thu Apr 20 06:16:33 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu, 20 Apr 2006 00:16:33 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> On 19-Apr-06, at 8:57 PM, pythonmac-sig-request at python.org wrote: > Christopher Barker wrote: > > They look great, but what the heck is "DATA"? > > It was has's [idea][1] for what a .pyo/.pyc icons should look like, > similar to how script editor allows saving of plain > text .applescript files with an icon labeled "TEXT". > > [1]: http://mail.python.org/pipermail/pythonmac-sig/2006-April/ > 016912.html DATA is fine then I guess. The regular .py files should probably be badged "Python" as well, for users unfamiliar with the logo, and it could include a few lines of code (steal some from the cookbook) in the same font and colour as the "DATA" icon (see my thoughts on that below) > > > > .pyc/.pyo files - Python binary code document, > > executable but non-editable (should be similar to > > .py/.pyw icon, exept indicating binary content); these > > are mostly auto-generated by Python for efficiency. I'd > > suggest a variation of the .py icon that indicated > > binary content, e.g. a light backdrop of rows of random > > 1s and 0s, or a word like '011010', 'byte' or 'data' in > > its lower half. > > Ok, this is what I tried to do with those examples. Do people like > them as is, or are there other ideas? The general idea is good, but the implementation looks a bit cluttered. You could reduce the conflict by greying out the 10010 somewhat, making the font smaller (more lines), and leaving a bigger gap between the bottom of the 101010 and the word DATA. Somebody did this work for the last set of Python logos. Does anyone have the source? > > > PythonLauncher.app application - a drag-n-drop script > > runner. Possibly use something similar to the Applet > > Launcher.app for Java. > > Grey rocket ship with python logo on the front? This might work, > but also might look kind of lame, like the java Applet Launcher > icon does. Then again, I don't have any great ideas for better ways > to do this. > See my last email. Yeah, the potential for lameness is there, but maybe you can do something with it. > Also, does anyone have anyone have any suggestions for the glassy > python logo before I go ahead and make a bunch more icons based on it? I like it, but Aqua has tuned down a lot its glassiness in recent years. I would tone down the difference between highlights and shadows myself, but I'm not going to argue about it :) Good job! Brendan -- Brendan Simons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/24e02733/attachment.html From brendansimons at yahoo.ca Thu Apr 20 06:37:41 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu, 20 Apr 2006 00:37:41 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <95146343-9AA1-493E-8472-1A1AF9D7690F@yahoo.ca> On 20-Apr-06, at 12:15 AM, pythonmac-sig-request at python.org wrote: > From: Jacob Rus > Date: April 19, 2006 10:06:34 PM EDT (CA) > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Bill Janssen wrote: >>> No, I disagree. If there is any text, it should be in dark gray 18 >>> point Lucida Grande, as per the HIG. XCode uses colored file >>> extensions in its document graphics because it deals with many >>> different types of source files, and this keeps them >>> distinguishable. >> It's not just XCode. *Users* deal with many different kinds of >> source files, and apparently the icons used in XCode are the ones >> that Mac OS X uses generically. For example, look at the Finder icon >> for a Java source file, and you'll see that the XCode icon is used >> there, as well. > > Yes, java source files get the xcode icons, because XCode is set up > on your machine as the editor for java files (and registered as > such with Launch Services). Similarly for c, etc. On my machine, > some of these get XCode document icons, and some get TextMate > document icons, because for me, TextMate is the editor for those > file types. > > You miss my point, which is that python files don't need giant > colored "py" splashed across them, if they have a distinguishable > python icon. XCode does not follow the HIG, because it makes > distinguishing c files from java files easier. Our new python icon > will not have this problem, because it only needs to represent with > one type of file. I agree completely. > >> The greeked source code in the background of the document >> indicates "source code", the file extension indicates the >> language, and the color apparently indicates something as well, >> though it's not clear (to me) just what. > > If you like, we could add some greeked source code. If we do, then > the pyo/pyc files will need something other than random 1s and 0s > to distinguish it, especially at small sizes. I'm open to > suggestions. I tried colourizing the document, but it's nearly impossible to find a colour that complements both the blue and yellow of the logo. You could darken the paper slightly (not so much that you couldn't read the word "DATA" though. Brendan -- Brendan Simons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/36d97ca1/attachment.html From Chris.Barker at noaa.gov Thu Apr 20 06:39:25 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 21:39:25 -0700 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> <38833B9B-8083-4635-9381-6BCEBBC91DCA@redivi.com> <4446BF4C.1010508@noaa.gov> Message-ID: <4447107D.40702@noaa.gov> Daniel Lord wrote: > That sound reasonable, but not what I did--I installed them in /usr/ > local/lib & include. I've done that, but the only way I could make sure that they got statically linked was to make sure that there were not dynamic versions of the same libs anywhere else on the search path, so I found it easier to put them in a special place, and it's always possible that I'd have the dynamic libs installed for some other reason. -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 From Chris.Barker at noaa.gov Thu Apr 20 06:41:36 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 19 Apr 2006 21:41:36 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446C94B.5090400@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> Message-ID: <44471100.9090900@noaa.gov> Jacob Rus wrote: > Christopher Barker wrote: > > They look great, but what the heck is "DATA"? > > It was has's [idea][1] for what a .pyo/.pyc icons should look like, > similar to how script editor allows saving of plain text .applescript > files with an icon labeled "TEXT". Well, a script is text, but a .pyc file is not Data. Maybe "bytecode", which is too long, or "bytes" or "code" or ".pyc" or ??? In fact, I think the ones-and-zeros background without any words might work just fine. -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 From daniellord at mac.com Thu Apr 20 07:33:22 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 22:33:22 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44471100.9090900@noaa.gov> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> Message-ID: On Apr 19, 2006, at 21:41, Christopher Barker wrote: > Well, a script is text, but a .pyc file is not Data. Maybe "bytecode", > which is too long, or "bytes" or "code" or ".pyc" or ??? I think it should be an Apple with a bite out of it--get it? Apple, snake, apple, byte . I kill myself ;-) Okay obviously I need to shut up and go away now...Bye. From jrus at fas.harvard.edu Thu Apr 20 07:40:00 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Thu, 20 Apr 2006 01:40:00 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44471100.9090900@noaa.gov> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> Message-ID: <44471EB0.6060700@fas.harvard.edu> Christopher Barker wrote: > Jacob Rus wrote: >> Christopher Barker wrote: >> > They look great, but what the heck is "DATA"? >> It was has's [idea][1] for what a .pyo/.pyc icons should look like, >> similar to how script editor allows saving of plain text .applescript >> files with an icon labeled "TEXT". > Well, a script is text, but a .pyc file is not Data. Maybe "bytecode", > which is too long, or "bytes" or "code" or ".pyc" or ??? > In fact, I think the ones-and-zeros background without any words might > work just fine. Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon-variations.png Which do you prefer? -Jacob From kevin at macosx.com Thu Apr 20 07:44:31 2006 From: kevin at macosx.com (kevin parks) Date: Thu, 20 Apr 2006 01:44:31 -0400 Subject: [Pythonmac-SIG] Unintsaller for Universal In-Reply-To: <2D340AB3-2C5F-43B4-9F42-7A1603CCC1B2@redivi.com> References: <2D340AB3-2C5F-43B4-9F42-7A1603CCC1B2@redivi.com> Message-ID: thank you bob you rock! \m/ (>.<) \m/ this totally works ... (for anyone else needing to dumb down to 2.4.1) cheers all... -kp-- On Apr 20, 2006, at 1:02 AM, Bob Ippolito wrote: > > On Apr 19, 2006, at 7:55 PM, kevin parks wrote: > >> How do i uninstall 2.4.3? >> so that i can dial back to 2.4.1? or am i screwed? > > I don't think there were any plans for an uninstaller. Just install > 2.4.1 and everything will work fine, it'll overwrite everything that > needs to be overwritten. > > -bob From jrus at fas.harvard.edu Thu Apr 20 07:47:51 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Thu, 20 Apr 2006 01:47:51 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> Message-ID: <44472087.4050507@fas.harvard.edu> Brendan Simons wrote: > I like it, but Aqua has tuned down a lot its glassiness in recent > years. I would tone down the difference between highlights and shadows > myself, but I'm not going to argue about it :) You're probably right, but make sure you look at the actual icon files (in the zip files I linked to earlier) as well as the png files. There are some icc profile mismatch issues here, which I always seem to run into with png files (and it previews differently in Camino and Safari, for instance). The actual version may be duller than the preview you're seeing. Maybe I should post a screenshot instead of saving from photoshop. -Jacob From daniellord at mac.com Thu Apr 20 08:00:32 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 19 Apr 2006 23:00:32 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44472087.4050507@fas.harvard.edu> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44472087.4050507@fas.harvard.edu> Message-ID: <2A887FB5-3D64-4080-9CE3-168650F5E15C@mac.com> On Apr 19, 2006, at 22:47, Jacob Rus wrote: > Brendan Simons wrote: >> I like it, but Aqua has tuned down a lot its glassiness in recent >> years. I would tone down the difference between highlights and >> shadows >> myself, but I'm not going to argue about it :) > > You're probably right, but make sure you look at the actual icon files > (in the zip files I linked to earlier) as well as the png files. > There > are some icc profile mismatch issues here, which I always seem to run > into with png files (and it previews differently in Camino and Safari, > for instance). The actual version may be duller than the preview > you're > seeing. Maybe I should post a screenshot instead of saving from > photoshop. Jacob, I think your 'glassiness' is understated and fine. I never meant the extreme of the original colored iMac look. I think it adds a nice 3-D look especially in the smaller sizes and is under-stated enough to fit the Apple look of today with a little of a yellow and blue color Apple doesn't use. Could it be turned down a bit? Yeah I suppose. But there is a time to tweak and a time to move on when the diminishing returns of tweaking are vanishingly small and we can ignore subsequent terms in the series (flash-back to advanced engineering math ;-). Guess what time I think it is IMHO? Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060419/2891fdd1/attachment-0001.html From njriley at uiuc.edu Thu Apr 20 08:00:39 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 20 Apr 2006 01:00:39 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44471EB0.6060700@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> <44471EB0.6060700@fas.harvard.edu> Message-ID: <20060420060039.GA71874@uiuc.edu> On Thu, Apr 20, 2006 at 01:40:00AM -0400, Jacob Rus wrote: > Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon-variations.png > > Which do you prefer? I'd say "PYC", because although it isn't a word, the icon does a better job of connoting the file contents than any of the other words, and for people who know Python, "PYC" means something. My second choice would be the unadorned one. I'm actually wondering if using the folded-corner document icon for .pyc files is a good idea at all. The document icon usually indicates something that can be edited or at least viewed, and a .pyc file certainly can't be (easily :). Consider the executable icon (cd into /bin or whatever) as an example - although, I guess even run-only AppleScripts get a document icon. -- Nicholas Riley | From jrus at fas.harvard.edu Thu Apr 20 08:22:18 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Thu, 20 Apr 2006 02:22:18 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <95146343-9AA1-493E-8472-1A1AF9D7690F@yahoo.ca> References: <95146343-9AA1-493E-8472-1A1AF9D7690F@yahoo.ca> Message-ID: <4447289A.6040301@fas.harvard.edu> Hi again, So that others can more easily play with these icons, here are the Photoshop versions of the full-size glassy [logo][1], and the [document icons][2]. All the layers are included, so it should be pretty easy to tweak the highlights, etc. I probably won't have any more time to work on this for 2-3 days. -Jacob [1]: http://hcs.harvard.edu/~jrus/python/python-logo.psd [2]: http://hcs.harvard.edu/~jrus/python/python-icons.psd From ronaldoussoren at mac.com Thu Apr 20 08:47:05 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 08:47:05 +0200 Subject: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening In-Reply-To: <4446BF4C.1010508@noaa.gov> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> <44454A6D.2030601@noaa.gov> <93B3C6F7-78EE-432E-A569-70DCF6A7F638@redivi.com> <44466A01.8080903@noaa.gov> <38833B9B-8083-4635-9381-6BCEBBC91DCA@redivi.com> <4446BF4C.1010508@noaa.gov> Message-ID: <1060B325-FE92-4CC9-88ED-6F754699C747@mac.com> On 20-apr-2006, at 0:53, Christopher Barker wrote: > Bob Ippolito wrote: >> The libs should all be statically linked to the extensions, they >> shouldn't be separate in the installer. > > Ronald Oussoren wrote: >> I'd prefer to have fully self contained packages, and preferably >> eggs at that. Having a shared libary makes it *harder* to >> independendly >> update extensions using libpng or libfreetype. > > No one answered my question directly, but both Bob and Ronald have > spoken: > > It's better for each package to statically link any libs it needs > (unless Apple provides them), even though that means that a given > python > program may well end up using three copies of the same lib. > > Just to be totally clear: Is there any problem with the same program > using three slightly different versions of the same lib? Thanks to two-level namespaces that shouldn't be a problem unless two extensions share datastructures from a library. An example of this are the curses and panel extensions in the stdlib, both link to libcurses and they share datastructures from curses. You'll see a hard crash when those extensions are staticly linked to curses. > >> I'll have to package up my package build script one of these days ;-) > > What does it do? Something different than bdist_mpkg ? Its one level higher: a script that uses bdist_egg and bdist_mpkg to build binary packages given a list of recipes. That makes it a lot easier to tweak the build process or rebuild packages when the libraries they use are changed. Its the result of a pet peeve: I like binary packages on pythonmac.org, but don't like the fact that most of them seem to build by hand and that some required manual prodding to get them to work. Ronald From ronaldoussoren at mac.com Thu Apr 20 08:48:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 08:48:56 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4446BA01.2020807@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> Message-ID: <4B86D4E9-358C-4CA8-820D-09BF3D1DD35E@mac.com> On 20-apr-2006, at 0:30, Jacob Rus wrote: > Ok, what do you all think of these script and compiled script icons: > > PNG: http://hcs.harvard.edu/~jrus/python/python-icons-a1.png > ZIP: http://hcs.harvard.edu/~jrus/python/python-icons-a1.zip > > The zip file contains icns files, png files, and also folders with the > icons applied. > > I'm glad to provide Photoshop files as well, if someone wants them. I like these icons, although I'm not sure about the DATA label on the .pyc icon. Thank you for working on this, Ronald From ronaldoussoren at mac.com Thu Apr 20 08:52:53 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 08:52:53 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> Message-ID: On 20-apr-2006, at 6:16, Brendan Simons wrote: > > On 19-Apr-06, at 8:57 PM, pythonmac-sig-request at python.org wrote: > >> Christopher Barker wrote: >> > They look great, but what the heck is "DATA"? >> >> It was has's [idea][1] for what a .pyo/.pyc icons should look >> like, similar to how script editor allows saving of plain >> text .applescript files with an icon labeled "TEXT". >> >> [1]: http://mail.python.org/pipermail/pythonmac-sig/2006-April/ >> 016912.html > > DATA is fine then I guess. The regular .py files should probably > be badged "Python" as well, for users unfamiliar with the logo, and > it could include a few lines of code (steal some from the cookbook) > in the same font and colour as the "DATA" icon (see my thoughts on > that below) I'd prefer a nice and clean icon for .py files. Ronald From ronaldoussoren at mac.com Thu Apr 20 08:56:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 08:56:13 +0200 Subject: [Pythonmac-SIG] Unintsaller for Universal In-Reply-To: References: <2D340AB3-2C5F-43B4-9F42-7A1603CCC1B2@redivi.com> Message-ID: <1720FB2D-0B7A-46EC-B2EE-55BA712D7407@mac.com> On 20-apr-2006, at 7:44, kevin parks wrote: > thank you bob you rock! > > \m/ (>.<) \m/ > > this totally works ... (for anyone else needing to dumb down to 2.4.1) > > cheers all... I'm am interested in hearing about why you need to go back and if there's anything we can do to make it possible for you to use the universal installer. If the program that you mentioned in your first message is opensource I'd like to hear which one it is, that way we might be able to provide a workaround/fix for the issues you're having. Ronald > > -kp-- > > > > On Apr 20, 2006, at 1:02 AM, Bob Ippolito wrote: > >> >> On Apr 19, 2006, at 7:55 PM, kevin parks wrote: >> >>> How do i uninstall 2.4.3? >>> so that i can dial back to 2.4.1? or am i screwed? >> >> I don't think there were any plans for an uninstaller. Just install >> 2.4.1 and everything will work fine, it'll overwrite everything that >> needs to be overwritten. >> >> -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Thu Apr 20 11:02:31 2006 From: hengist.podd at virgin.net (has) Date: Thu, 20 Apr 2006 10:02:31 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> Message-ID: Ronald wrote: >>>Macpath deals with OS9/Carbon style paths (Volume:directory:file >>>instead of /Volume/directory/file). >> >>Don't know where you're seeing this; I've tried a few of the functions and none work with HFS-style paths, only POSIX-style paths. > > >>> macpath.join('foo', 'bar') >':foo:bar' OK, so that has colons - obviously I managed only to try the ones that didn't. :) That said, the actual result in the above example is wrong. It should be 'foo:bar', since 'foo' is an absolute path (a leading colon indicates a relative path, which is not the same): join('d1', 'Users') ':d1:Users' # wrong! (should be 'd1:Users') So that's pretty useless. More examples of brokenness: exists('d1:Users:has') False exists('/Users/has') True isdir('d1:Users:has') 0 isdir('/Users/has') True getsize('/Users/has/test.rb') 150 getsize('d1:Users:has:test.rb') OSError: [Errno 2] No such file or directory: 'd1:Users:has:test.rb' All demand a POSIX path, not an HFS path. So the module is well broken on OS X, and has been for the last five years and nobody's said or done anything about it yet. And even fixed it's still semi-worthless since there's a whole bunch of things you still can't do with HFS paths - i.e. no comparable 'os' module for creating, moving, deleting, etc. - and there's nothing in it for converting paths between HFS and POSIX formats so interoperability is also crap. This says it's a fairly useless module in reality, and won't be missed if it's jettisoned now. What'd make a lot more sense is fixing Carbon.CF so it can be used to convert between the different path formats. This functionality is needed anyway, and it'll allow folk who do need to handle HFS paths to use the os/os.path modules by turning them to POSIX paths and back. Tell you what: if you really don't want to deprecate it in 2.5, put a warning note on it saying it's multiply broken. If someone cares they can submit patches and it can be fixed in 2.6. If not, it can be deprecated then. ------- Daniel Lord wrote: >>>> 2.1 macpath -- MacOS path manipulation functions >>[...] >>As I mentioned in another message this module might be useful to work >>with OS9-style paths as used by some Carbon API's. > >Good suggestion, Ronald. I was just tinkering around with appscript and MS Excel a few days ago (still cannot access some things like borders properly and others are just 'bass-ackwards' in the Excel terminology defs so I gave up) but Excel expects colon-separated paths in file paths (yes even in 2004 when they last updated it). As for working with HFS paths (and a pox on scriptable apps that require them, btw, because they're fundamentally unreliable), you ought to be able to use Carbon.CF to translate between POSIX/Windows/HFS path styles. Unfortunately, I suspect getting in and out of there may be one of the areas that's broken. I wouldn't mind adding a makewithhfspath class method and hfspath instance method to macfile's Alias and File classes, but I'd want to be sure I had a correct implementation first, however, as it's not quite as trivial as it sounds on the surface (e.g. volume names are not a direct translation in either direction). has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Apr 20 11:42:34 2006 From: hengist.podd at virgin.net (has) Date: Thu, 20 Apr 2006 10:42:34 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> Message-ID: Brendan Simons wrote: >> > They look great, but what the heck is "DATA"? >> >> >>It was has's [idea][1] for what a .pyo/.pyc icons should look like, similar to how script editor allows saving of plain text .applescript files with an icon labeled "TEXT". >> >>[1]: http://mail.python.org/pipermail/pythonmac-sig/2006-April/016912.html >> > >DATA is fine then I guess. Nah, it was just one of many suggestions I floated. If the first reaction it elicits is 'what the heck?' then that's a powerful indication the idea's a bad one and should be dropped. Ditch it. >The regular .py files should probably be badged "Python" as well, I think that's overkill; you don't see other apps doing this sort of thing. Have some faith in your own material. :) Don't forget that file names will already have a '.py' suffix, so they're already in the boat with 99% of other OS X files that identify their type through their filename suffix. (BTW, .py files should also identify themselves as 'Python scripts' when folk who don't know what '.py' means do a 'Get Info' in Finder. But I think IDLE's plist still needs to be set up correctly for that.) >See my last email. Yeah, the potential for lameness is there, but maybe you can do something with it. > >>Also, does anyone have anyone have any suggestions for the glassy python logo before I go ahead and make a bunch more icons based on it? >> > >I like it, but Aqua has tuned down a lot its glassiness in recent years. I would tone down the difference between highlights and shadows myself, but I'm not going to argue about it :) I would agree with the glassiness maybe being overdone; it's become a bit of a clich? over the last few years thanks to OS X. "Lickability" is so 2002. :) It might be handy to compare versions with 2D-snakes and 3D-snakes side by side (the tonal gradient on the 2D version may need nudged up a fraction to make it pop a bit more against the backdrop). Perhaps with a third 50% version to compare too. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Apr 20 11:50:14 2006 From: hengist.podd at virgin.net (has) Date: Thu, 20 Apr 2006 10:50:14 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44471EB0.6060700@fas.harvard.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> <44471EB0.6060700@fas.harvard.edu> Message-ID: Jacob Rus wrote: >>In fact, I think the ones-and-zeros background without any words might work just fine. > >Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon-variations.png > >Which do you prefer? Ones-and-zeros only, I say. The only other thing that'd make sense is 'BYTECODE', but that's too long to fit and is probably overstating the case anyway. With the large icon it's clear that the file contains 'machine data', and with the smaller ones it gives them a dulled down look that distinguishes them from the brighter 'script' icons. The only other thing would be to see how they look applied to a folderful of py and pyc files; hopefully the brighter py icons are the ones that attract the eye more, since those are the ones we want users to be most interested in. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Thu Apr 20 11:50:53 2006 From: hengist.podd at virgin.net (has) Date: Thu, 20 Apr 2006 10:50:53 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> Message-ID: Ronald Oussoren wrote: >>> 2.1 macpath -- MacOS path manipulation functions >> >>Deprecate. Also note that the 2.4.3 documentation now says "It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform)." which is incorrect (it uses POSIX-style paths), so delete that sentence. > >I'm not a native english speaker, but I read this as "you can use this to manipulate OS9 style paths on any platform". Note that the above sentence was only added in the 2.4 docs. If you can find a way to make it do HFS paths then let me know, otherwise the sentence needs to be deleted and the module itself should be deprecated (i.e. folk should be using os.path anyway). >As I mentioned in another message this module might be useful to work with OS9-style paths as used by some Carbon API's. >> >>> 2.4 MacOS -- Access to Mac OS interpreter features >> >>Get/SetCreatorAndType should really be fixed or deprecated as they don't appear to work for bundle-based files. > >They should be fixed. Why does everyone want to remove what they don't quite understand? Fix or deprecate; doesn't bother me which as long as it's done. Bear in mind, however, that file typing has gotten a lot more complicated since OS 9 days, so this API has been grossly inadequate for the job for a long time now. Deprecating it would just be an honest admission of that fact; heck, might even encourage folks to come up with a modern replacement. And deprecation doesn't stop anyone using it in the meantime, of course, but considering it's been in this state for the last five years I doubt many are. :) >One of the strong points of python on the mac is that it is one of the *very* few languages that provides bindings to most parts of the system APIs. IMHO the bindings to Carbon suck, but that doesn't mean we should scrap or completely hide them. >I'd love to deprecate Carbon.CF as well, but we can't do that until we have another way to access those APIs. PyObjC is about this > < close to doing that, I just haven't gotten around finishing the final bits yet. As Bob says, Carbon.CF is pretty incomplete, broken and weird so is not a great deal of use as-is. I imagine that's why he said deprecate, since unless someone wants to do a major overhaul then it's not much better than useless anyway. (FWIW, I'd prefer to see it overhauled, but I ain't the one to do it, so...:) >>> 4.2 Carbon.AH -- Apple Help >> >>Do nothing. > >Documentation would be nice :-) Yeah, but let's finish cleaning up the existing material first, since that can be done in time for 2.5's release. If we wait for comprehensive new documentation to be completed first then nothing'll get done for 2.5 and we'll be back having this same discussion come 2.6. ;) >>> 4.10 Carbon.Evt -- Event Manager >> >>Deprecate, or at least add note to use modern alternative. Superceded by CarbonEvt. > >Don't deprecate but not that you should CarbonEvt and that Apple has deprecated the Event Manager API. If Apple have deprecated the original Carbon API then I think it makes very good sense to deprecate the Python wrapper for that API as well. That way, no surprises if/when Apple decide to break it/drop it. We're just following their lead. The only exception might be where we don't have a wrapper for the new API that supercedes it, in which case we should leave it undeprecated but add a warning note. In the case of Carbon.Evt, we have Carbon.CarbonEvt, so I don't think deprecation is too strong a statement to make. It says nothing about if/when a module will be removed (if ever); only that sensible folks should avoid its use in any future projects, and may want (or need) to update any existing dependent code at some point. has -- http://freespace.virgin.net/hamish.sanderson/ From ronaldoussoren at mac.com Thu Apr 20 12:49:29 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 12:49:29 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <4DC866E4-1DAF-4C37-BD44-10DED7CA7B7E@mac.com> Message-ID: On 20-apr-2006, at 11:50, has wrote: > Ronald Oussoren wrote: > >>>> 2.1 macpath -- MacOS path manipulation functions >>> >>> Deprecate. Also note that the 2.4.3 documentation now says "It >>> can be used to manipulate old-style Macintosh pathnames on Mac OS >>> X (or any other platform)." which is incorrect (it uses POSIX- >>> style paths), so delete that sentence. >> >> I'm not a native english speaker, but I read this as "you can use >> this to manipulate OS9 style paths on any platform". > > Note that the above sentence was only added in the 2.4 docs. If you > can find a way to make it do HFS paths then let me know, otherwise > the sentence needs to be deleted and the module itself should be > deprecated (i.e. folk should be using os.path anyway). It does do HFS paths right now, you can import it using 'import macpath'. Any mention of it being os.path on macos should be removed, that was true in os9 but not in osx. > > >> As I mentioned in another message this module might be useful to >> work with OS9-style paths as used by some Carbon API's. >>> >>>> 2.4 MacOS -- Access to Mac OS interpreter features >>> >>> Get/SetCreatorAndType should really be fixed or deprecated as >>> they don't appear to work for bundle-based files. >> >> They should be fixed. Why does everyone want to remove what they >> don't quite understand? > > Fix or deprecate; doesn't bother me which as long as it's done. > > Bear in mind, however, that file typing has gotten a lot more > complicated since OS 9 days, so this API has been grossly > inadequate for the job for a long time now. Deprecating it would > just be an honest admission of that fact; heck, might even > encourage folks to come up with a modern replacement. > > And deprecation doesn't stop anyone using it in the meantime, of > course, but considering it's been in this state for the last five > years I doubt many are. :) Could you please file a bug at SF about this, I'll surely forget to fix it if you don't. > > >>>> 4.2 Carbon.AH -- Apple Help >>> >>> Do nothing. >> >> Documentation would be nice :-) > > Yeah, but let's finish cleaning up the existing material first, > since that can be done in time for 2.5's release. If we wait for > comprehensive new documentation to be completed first then > nothing'll get done for 2.5 and we'll be back having this same > discussion come 2.6. ;) I want any documentation that I can, there's no need to write up comprehensive documention. If you (or anyone else for that matter) has knowledge about some part of the mac specific libaries and wishes to contribute documentation that would be greatly appreciated. > > >>>> 4.10 Carbon.Evt -- Event Manager >>> >>> Deprecate, or at least add note to use modern alternative. >>> Superceded by CarbonEvt. >> >> Don't deprecate but not that you should CarbonEvt and that Apple >> has deprecated the Event Manager API. > > If Apple have deprecated the original Carbon API then I think it > makes very good sense to deprecate the Python wrapper for that API > as well. That way, no surprises if/when Apple decide to break it/ > drop it. We're just following their lead. > > The only exception might be where we don't have a wrapper for the > new API that supercedes it, in which case we should leave it > undeprecated but add a warning note. In the case of Carbon.Evt, we > have Carbon.CarbonEvt, so I don't think deprecation is too strong a > statement to make. It says nothing about if/when a module will be > removed (if ever); only that sensible folks should avoid its use in > any future projects, and may want (or need) to update any existing > dependent code at some point. Yeah, you're right. Ronald From ronaldoussoren at mac.com Thu Apr 20 12:52:00 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 12:52:00 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> Message-ID: On 20-apr-2006, at 11:02, has wrote: > Ronald wrote: > >>>> Macpath deals with OS9/Carbon style paths (Volume:directory:file >>>> instead of /Volume/directory/file). >>> >>> Don't know where you're seeing this; I've tried a few of the >>> functions and none work with HFS-style paths, only POSIX-style >>> paths. >> >>>>> macpath.join('foo', 'bar') >> ':foo:bar' > > OK, so that has colons - obviously I managed only to try the ones > that didn't. :) > > That said, the actual result in the above example is wrong. It > should be 'foo:bar', since 'foo' is an absolute path (a leading > colon indicates a relative path, which is not the same): Could you please file this as a bug at the python tracker over at sourceforge? Bugs that are not in the tracker are likely to stay bugs unless someone with checkin privileges runs into them and is annoyed enough to fix them. Ronald From brendansimons at yahoo.ca Thu Apr 20 13:20:28 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu, 20 Apr 2006 07:20:28 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <7FF18325-F556-4822-91F6-DA8A7DB06E2D@yahoo.ca> On 20-Apr-06, at 5:51 AM, pythonmac-sig-request at python.org wrote: >> The regular .py files should probably be badged "Python" as well, > > I think that's overkill; you don't see other apps doing this sort > of thing. Have some faith in your own material. :) Don't forget > that file names will already have a '.py' suffix, so they're > already in the boat with 99% of other OS X files that identify > their type through their filename suffix. > > (BTW, .py files should also identify themselves as 'Python scripts' > when folk who don't know what '.py' means do a 'Get Info' in > Finder. But I think IDLE's plist still needs to be set up correctly > for that.) You do see other apps badging icons with the suffix. It's standard procedure for those files which can be opened by more than one editor/ reader. Take PDF for instance. The preview icon is there, but so is "PDF", as a reminder that you don't -really- need to open it with preview. Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/e4a266c0/attachment.html From jrus at fas.harvard.edu Thu Apr 20 13:31:15 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Thu, 20 Apr 2006 07:31:15 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <7FF18325-F556-4822-91F6-DA8A7DB06E2D@yahoo.ca> References: <7FF18325-F556-4822-91F6-DA8A7DB06E2D@yahoo.ca> Message-ID: <44477103.9000204@fas.harvard.edu> > You do see other apps badging icons with the suffix. It's standard > procedure for those files which can be opened by more than one > editor/reader. Take PDF for instance. The preview icon is there, but > so is "PDF", as a reminder that you don't -really- need to open it with > preview. Hmm... I would suggest that it's more about applications which can open more than one type of file. For instance, Preview.app puts a "PDF" badge on those icons because it opens many types of image files, and has 24 different badged icons for PDF, JPEG, ICNS, TIFF, FAX, etc., as well as a "generic" icon with no badge. The "PDF" badge shows up as a reminder that you aren't dealing with a JP2 file. I don't mean to be contentious here though. I'm perfectly happy putting "PYTHON" on the bottom of the document icons. -Jacob From ronaldoussoren at mac.com Thu Apr 20 14:09:05 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 14:09:05 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44477103.9000204@fas.harvard.edu> References: <7FF18325-F556-4822-91F6-DA8A7DB06E2D@yahoo.ca> <44477103.9000204@fas.harvard.edu> Message-ID: On 20-apr-2006, at 13:31, Jacob Rus wrote: >> You do see other apps badging icons with the suffix. It's standard >> procedure for those files which can be opened by more than one >> editor/reader. Take PDF for instance. The preview icon is there, >> but >> so is "PDF", as a reminder that you don't -really- need to open it >> with >> preview. > > Hmm... I would suggest that it's more about applications which can > open > more than one type of file. For instance, Preview.app puts a "PDF" > badge on those icons because it opens many types of image files, > and has > 24 different badged icons for PDF, JPEG, ICNS, TIFF, FAX, etc., as > well > as a "generic" icon with no badge. The "PDF" badge shows up as a > reminder that you aren't dealing with a JP2 file. > > I don't mean to be contentious here though. I'm perfectly happy > putting > "PYTHON" on the bottom of the document icons. I prefer both the .py and .pyc/.pyo icons without the text. Without text they are slightly cleaner and there shouldn't be any confusion about the type of file. Ronald From jschull at softlock.com Thu Apr 20 14:35:38 2006 From: jschull at softlock.com (Jon Schull) Date: Thu, 20 Apr 2006 08:35:38 -0400 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 36, Issue 60 Message-ID: <0956D047-9EF6-4E5B-BADF-18D326863113@softlock.com> >> >> >> On Apr 19, 2006, at 21:41, Christopher Barker wrote: >> >>> Well, a script is text, but a .pyc file is not Data. Maybe >>> "bytecode", >>> which is too long, or "bytes" or "code" or ".pyc" or ??? >> >> I think it should be an Apple with a bite out of it--get it? >> Apple, snake, apple, byte . >> I kill myself ;-) Okay obviously I need to shut up and go away >> now...Bye. > Actually, I think you nailed it... Apple, snake, tree of knowledge.... Two possible layouts are suggested by these images: http://www.fotosearch.com/BDX108/bxp26159/ http://it.rit.edu/~jis/pylogo/pylogo.png (if only I could really draw...) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull at digitalgoods.com fax: 978-246-0487 cell: 585-738-6696 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/8789f4c0/attachment-0001.html From mjb at uma.pt Thu Apr 20 16:41:49 2006 From: mjb at uma.pt (Michael Barber) Date: Thu, 20 Apr 2006 15:41:49 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44477103.9000204@fas.harvard.edu> References: <7FF18325-F556-4822-91F6-DA8A7DB06E2D@yahoo.ca> <44477103.9000204@fas.harvard.edu> Message-ID: On Apr 20, 2006, at 12:31 PM, Jacob Rus wrote: > > On Apr 20, Brendan Simons wrote: >> You do see other apps badging icons with the suffix. It's standard >> procedure for those files which can be opened by more than one >> editor/reader. Take PDF for instance. The preview icon is there, >> but >> so is "PDF", as a reminder that you don't -really- need to open it >> with >> preview. > > Hmm... I would suggest that it's more about applications which can > open > more than one type of file. For instance, Preview.app puts a "PDF" > badge on those icons because it opens many types of image files, > and has > 24 different badged icons for PDF, JPEG, ICNS, TIFF, FAX, etc., as > well > as a "generic" icon with no badge. The "PDF" badge shows up as a > reminder that you aren't dealing with a JP2 file. > > I don't mean to be contentious here though. I'm perfectly happy > putting > "PYTHON" on the bottom of the document icons. > > -Jacob > There is an interesting point to consider, here. As noted by the above writers, Preview has different badges on otherwise generic icons, although they interpret the reason for the badges differently. Possibly, both reasons are intended. However, the icons for Python are not completely analogous. With Preview, it doesn't matter that much what kind of image file you have: you open it and Preview shows it to you. With Python, we expect quite different behavior for .py files as compared to .pyc/.pyo -- so to me the real question is whether these two types of files are distinct enough. My impression is that they are distinct enough, but a bit more contrast wouldn't hurt, especially for smaller sizes. A badge wouldn't help me, since they are normally too small to be useful in column view in the Finder; I essentially don't use the icon view. So, what would the badge actually be for? Would it just be used to distinguish between .pyc and .pyo files? Would a visual difference between the two actually be useful? It wouldn't for me, but maybe for others. I guess I'd say go with PYC and PYO badges, or none at all, and rely on the stronger differences in the "page" part of the icon to ensure that the more important distinction between source and bytecode is clear. Moving the paired snakes badge off-center for the bytecode, like in the current icons for Python bytecode, could reinforce the difference, if desired. I must admit to not being terribly concerned about the point on a personal level. While I like the new icons very much, I doubt that I'll see much of the one for .py files; mine will continue to look like SubEthaEdit documents. -- Michael From kw at kevin-walzer.com Thu Apr 20 18:02:00 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Thu, 20 Apr 2006 12:02:00 -0400 Subject: [Pythonmac-SIG] macho_standalone progress: how to call -archs from command line? Message-ID: <4447B078.8070902@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had written a few days ago about getting this error when I try to run the latest macho_standalone on an app bundle in this fashion: macho_standalone ~/Desktop/Myapp.app: File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 20, in ? main() File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 17, in main standaloneApp(fn) File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 10, in standaloneApp files = MachOStandalone(path).run() TypeError: __init__() takes at least 3 arguments (2 given) Digging a bit deeper into the macholib code, I noted that MachOStandalone.py calls for an "archs" argument: class MachOStandalone(object): def __init__(self, base, archs, dest=None, graph=None, env=None, executable_path=None): self.base = os.path.join(os.path.abspath(base), '') if dest is None: dest = os.path.join(self.base, 'Contents', 'Frameworks') self.dest = dest self.mms = dict([[arch, FilteredMachOGraph(self, arch, graph=graph, env=env, executable_path=executable_path)] for arch in archs]) self.changemap = {} self.excludes = [] self.pending = deque() self.archs = archs So what I'm trying to figure out is how to correctly pass the "archs" argument in my command-line parameters. I've tried four variants: macho_standalone ~/Desktop/Myapp.app ppc macho_standalone ~/Desktop/Myapp.app "archs = 'ppc'" macho_standalone ~/Desktop/Myapp.app "archs = ['ppc']" macho_standalone ~/Desktop/Myapp.app -archs ppc All of these yield the same error message as above. I think I'm on the right track here, because when I hard-code the ppc architecture in the __init__ def above, macho_standalone works. def __init__(self, base, archs=['ppc'], dest=None, graph=None, env=None, executable_path=None): So what I need to do is find the correct magic to get the command-line args invoked properly. Does anyone have any suggestions? Thanks! - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER7B4rTC5hIgjqTMRAoeZAJ9+Qt+6ggPfZhW++Hqn3JankmwTBgCeKz7Q Jlmo6RkuKDnizVoUDzjhMeo= =Vd/V -----END PGP SIGNATURE----- From janssen at parc.com Thu Apr 20 18:25:23 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 20 Apr 2006 09:25:23 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Wed, 19 Apr 2006 22:40:00 PDT." <44471EB0.6060700@fas.harvard.edu> Message-ID: <06Apr20.092523pdt."58633"@synergy1.parc.xerox.com> > Which do you prefer? The PYC. Bill From kw at kevin-walzer.com Thu Apr 20 18:43:20 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Thu, 20 Apr 2006 12:43:20 -0400 Subject: [Pythonmac-SIG] Latest universal build is 404 Message-ID: <4447BA28.1080909@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After looking at my issues with macho_standalone, I realized I've been using the "official" universal download of MacPython: but Bob Ippolito's site recommends a more recent build available: http://pythonmac.org/packages/py24-fat/Universal-MacPython-2.4.3-2006-04-07.dmg This comes up (today, at least) as a 404. Is there another place to get it? - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER7onrTC5hIgjqTMRAj2HAKCUFFhH+8YDJIb3qAiLRUGcLYckAQCfTKEN DaZtL/B8m5AIj2ApVyKbBSk= =99+f -----END PGP SIGNATURE----- From Chris.Barker at noaa.gov Thu Apr 20 18:55:24 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 20 Apr 2006 09:55:24 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <20060420060039.GA71874@uiuc.edu> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> <44471EB0.6060700@fas.harvard.edu> <20060420060039.GA71874@uiuc.edu> Message-ID: <4447BCFC.80107@noaa.gov> Nicholas Riley wrote: > I'd say "PYC", > My second choice would be the unadorned one. My thoughts exactly. Only semi-related: Perhaps the "snakes" logo should be larger, filling more of the icon, particularly at the smaller sizes. There isn't any real info in the "paper" background. -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 at noaa.gov From charles.hartman at conncoll.edu Thu Apr 20 19:06:19 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Thu, 20 Apr 2006 13:06:19 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4447BCFC.80107@noaa.gov> References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> <44471EB0.6060700@fas.harvard.edu> <20060420060039.GA71874@uiuc.edu> <4447BCFC.80107@noaa.gov> Message-ID: On Apr 20, 2006, at 12:55 PM, Christopher Barker wrote: > Perhaps the "snakes" logo should be larger, filling more of the icon, > particularly at the smaller sizes. There isn't any real info in the > "paper" background. FWIW, I agree with that. Charles Hartman From daniellord at mac.com Thu Apr 20 19:25:54 2006 From: daniellord at mac.com (Daniel Lord) Date: Thu, 20 Apr 2006 10:25:54 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <4446A097.6030607@fas.harvard.edu> <4446BA01.2020807@fas.harvard.edu> <4446C425.60202@noaa.gov> <4446C94B.5090400@fas.harvard.edu> <44471100.9090900@noaa.gov> <44471EB0.6060700@fas.harvard.edu> <20060420060039.GA71874@uiuc.edu> <4447BCFC.80107@noaa.gov> Message-ID: <170B3167-1BA9-4871-9B48-B1F84103DF91@mac.com> On Apr 20, 2006, at 10:06, Charles Hartman wrote: > On Apr 20, 2006, at 12:55 PM, Christopher Barker wrote: > >> Perhaps the "snakes" logo should be larger, filling more of the icon, >> particularly at the smaller sizes. There isn't any real info in the >> "paper" background. > > FWIW, I agree with that. Me three. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/129d38a8/attachment.htm From rsfinn at gmail.com Thu Apr 20 19:49:46 2006 From: rsfinn at gmail.com (Russell Finn) Date: Thu, 20 Apr 2006 13:49:46 -0400 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> Message-ID: On 4/20/06, has wrote: > > >>> macpath.join('foo', 'bar') > >':foo:bar' > > That said, the actual result in the above example is wrong. It should be 'foo:bar', since 'foo' is an absolute path (a leading colon indicates a relative path, which is not the same): Well, no; see below. > join('d1', 'Users') > ':d1:Users' # wrong! (should be 'd1:Users') The docstring for macpath.isabs() contradicts this, however: """On the Mac, relative paths begin with a colon, but as a special case, paths with no colons at all are also relative. Anything else is absolute (the string up to the first colon is the volume name).""" This is in fact the historic interpretation of pathnames under Mac OS before OS X (to the best of my memory -- most of the File Manager functions that would take full pathnames were purged in Carbon). Under this interpretation the examples above are behaving properly. To get the effect has appears to expect, you would need to say e.g. "macpath.join ('d1:', 'Users')". > So that's pretty useless. Well, that's open to debate. The current documentation for macpath just lists which operations are implemented and doesn't specify how they're to behave. The current implementation is consistent, at least, if not well documented. > More examples of brokenness: > > exists('d1:Users:has') > False > exists('/Users/has') > True [snip] If d1 is the name of your system volume, then that would be a bug -- if you were explicitly calling macpath.exists() in the first case. If you're calling os.path.exists() under Mac OS X, then you're really getting posixpath.exists(): >>> os.path.exists >>> macpath.exists >>> posixpath.exists > So the module is well broken on OS X, and has been for the last five years and nobody's said or done anything about it yet. Only if you believe it should handle HFS and POSIX paths interchangeably. I don't believe it's "broken", but I won't claim it does much that's useful in the modern world other than handle HFS-style paths (if you happen to have one for some reason). Some interoperability functions (i.e. conversion between HFS and POSIX paths) might be useful for the benefit of older (pre-X) scripts that assumed HFS conventions, but the fact that no one's been clamoring for them suggests that the need isn't very urgent today. -- Russell Finn From mantha at chem.unr.edu Thu Apr 20 20:29:55 2006 From: mantha at chem.unr.edu (Jordan Mantha) Date: Thu, 20 Apr 2006 11:29:55 -0700 Subject: [Pythonmac-SIG] Psycho & 2.4.3 universal In-Reply-To: <16E2C4CC-F392-4881-8035-173D304DCDE9@mac.com> References: <444562FE.6080703@fas.harvard.edu> <44456421.5010407@fas.harvard.edu> <16E2C4CC-F392-4881-8035-173D304DCDE9@mac.com> Message-ID: <920E589C-7201-44B1-9976-B9B4CDB850D0@chem.unr.edu> On Apr 19, 2006, at 12:01 PM, Ronald Oussoren wrote: > On 19-apr-2006, at 0:11, Jacob Rus wrote: >> I wrote: >>> I couldn't compile [psyco][1] using the 2.4.3 universal version of >>> Python on my 12" powerbook. I'm wondering if this is just a problem >>> with universal Python, or if psycho doesn't compile in general >>> under OS X. >> >> Argh, never mind that message. I see now that psyco is clearly >> labeled >> as only working on i386. Nothing to see here, move along. > > There is someone to see for those users fortunate enough to own an > intel mac :-) > It should be possible to compile psyco if you add '-arch i386' to the > extra_compile_args > and extra_link_args in the setup.py for psyco. I just got the psyco svn checkout and ran "sudo python setup.py install". I wasn't sure what to use as a test so I just used pystones. No Psyco python -c "from test.pystone import pystones; print pystones()" (1.1899999999999999, 42016.806722689078) python -c "from test.pystone import pystones; print pystones(100000)" (2.4100000000000001, 41493.775933609955) With Psyco python -c "from test.pystone import pystones; import psyco; psyco.full (); print pystones()" (0.22, 227272.72727272726) python -c "from test.pystone import pystones; import psyco; psyco.full (); print pystones(100000)" (0.42999999999999999, 232558.13953488372) I repeated each test a couple times. Looks like psyco works. -Jordan Mantha From ronaldoussoren at mac.com Thu Apr 20 20:28:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 20:28:13 +0200 Subject: [Pythonmac-SIG] Latest universal build is 404 In-Reply-To: <4447BA28.1080909@kevin-walzer.com> References: <4447BA28.1080909@kevin-walzer.com> Message-ID: <469FE5D2-1A27-436D-AB78-A7F397379B59@mac.com> On 20-apr-2006, at 18:43, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > After looking at my issues with macho_standalone, I realized I've been > using the "official" universal download of MacPython: but Bob > Ippolito's > site recommends a more recent build available: > > http://pythonmac.org/packages/py24-fat/Universal- > MacPython-2.4.3-2006-04-07.dmg > > This comes up (today, at least) as a 404. Is there another place to > get it? It should work now. That should teach me no to do such updates while jugling several other tasks. Ronald > > > - -- > Kevin Walzer > Poetic Code > http://www.kevin-walzer.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFER7onrTC5hIgjqTMRAj2HAKCUFFhH+8YDJIb3qAiLRUGcLYckAQCfTKEN > DaZtL/B8m5AIj2ApVyKbBSk= > =99+f > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Thu Apr 20 20:38:43 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 20 Apr 2006 20:38:43 +0200 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> Message-ID: <1B98DDD0-536F-4725-B7C7-1551ED4C9146@mac.com> On 20-apr-2006, at 19:49, Russell Finn wrote: > >> More examples of brokenness: >> >> exists('d1:Users:has') >> False >> exists('/Users/has') >> True > > [snip] > > If d1 is the name of your system volume, then that would be a bug -- > if you were explicitly calling macpath.exists() in the first case. If > you're calling os.path.exists() under Mac OS X, then you're really > getting posixpath.exists(): Right. Any function that touches the actual filesystem won't work, just like you can't expect that ``ntpath.exists(r'\Users\has')`` returns True. The modules posixpath, ntpath and macpath are available on all platform just to be able to just somepath.join and other string manipulation functions on other types of platform. Contrary to what I thought this isn't mentioned as a goal/possibility in the library reference, appearently this was part of folkore when I learned python. > >>>> os.path.exists > >>>> macpath.exists > >>>> posixpath.exists > > >> So the module is well broken on OS X, and has been for the last >> five years and nobody's said or done anything about it yet. > > Only if you believe it should handle HFS and POSIX paths > interchangeably. I don't believe it's "broken", but I won't claim it > does much that's useful in the modern world other than handle > HFS-style paths (if you happen to have one for some reason). Which happens with some Carbon related APIs and appeantly also some scripting interfaces. > > Some interoperability functions (i.e. conversion between HFS and POSIX > paths) might be useful for the benefit of older (pre-X) scripts that > assumed HFS conventions, but the fact that no one's been clamoring for > them suggests that the need isn't very urgent today. Those functions exists and are part of the normal Carbon API's. macpath is an implementation for the path manipulation APIs in os.path for when you want to manipulate OS9 style paths. That is *all* it can be used for unless you're running on OS9. Ronald > > -- Russell Finn > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kw at kevin-walzer.com Thu Apr 20 21:29:11 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Thu, 20 Apr 2006 15:29:11 -0400 Subject: [Pythonmac-SIG] macho_standalone progress: how to call -archs from command line? In-Reply-To: <4447B078.8070902@kevin-walzer.com> References: <4447B078.8070902@kevin-walzer.com> Message-ID: <4447E107.1050303@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I think I'm on the right track here, because when I hard-code the ppc > architecture in the __init__ def above, macho_standalone works. > > def __init__(self, base, archs=['ppc'], dest=None, graph=None, > env=None, executable_path=None): I finally hard-coded the archs in MachOStandalone.py (archs=['ppc', 'i386]. That got me over the initial error message, but it seems like an ugly hack. If anyone can suggest a better alternative, I'd appreciate it. Regards, Kevin - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER+EHrTC5hIgjqTMRAj5GAJ9Y8V/jnwMsxT5w6r0xhpDhEiHt1wCgqN7V BX2mA9kOoENB7Anm4vf2azI= =nXuZ -----END PGP SIGNATURE----- From nirs at freeshell.org Thu Apr 20 21:40:39 2006 From: nirs at freeshell.org (Nir Soffer) Date: Thu, 20 Apr 2006 22:40:39 +0300 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44472087.4050507@fas.harvard.edu> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44472087.4050507@fas.harvard.edu> Message-ID: <386bc95344a26d2f05962c4eec2ddb1f@freeshell.org> On 20/04/2006, at 08:47, Jacob Rus wrote: > You're probably right, but make sure you look at the actual icon files > (in the zip files I linked to earlier) as well as the png files. There > are some icc profile mismatch issues here, which I always seem to run > into with png files (and it previews differently in Camino and Safari, > for instance). The actual version may be duller than the preview > you're > seeing. Maybe I should post a screenshot instead of saving from > photoshop. First use Convert to Profile to convert your file to sRGB profile, then use Save for Web and make sure you embed the colorsync profile in the file. Then it will display fine on Safari or Preview or any other Cocoa app. Best Regards, Nir Soffer From kw at kevin-walzer.com Thu Apr 20 21:42:19 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Thu, 20 Apr 2006 15:42:19 -0400 Subject: [Pythonmac-SIG] macho_standalone progress: how to call -archs from command line? In-Reply-To: <4447E107.1050303@kevin-walzer.com> References: <4447B078.8070902@kevin-walzer.com> <4447E107.1050303@kevin-walzer.com> Message-ID: <4447E41B.1010803@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Walzer wrote: > >>> I think I'm on the right track here, because when I hard-code the ppc >>> architecture in the __init__ def above, macho_standalone works. >>> >>> def __init__(self, base, archs=['ppc'], dest=None, graph=None, >>> env=None, executable_path=None): > > > I finally hard-coded the archs in MachOStandalone.py (archs=['ppc', > 'i386]. That got me over the initial error message, but it seems like an > ugly hack. If anyone can suggest a better alternative, I'd appreciate it. As a corrolary to this, if you are just running macho_standalone on a ppc binary, edit the code in MachOStandalone.py accordingly (i.e. don't include 'i386'). - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER+QbrTC5hIgjqTMRAr0DAJ9U0bJnrlqKQqEeeEI0gYsB2HmTpACgkvf6 XjNd91VDsgB2qYizu29TURs= =GnlM -----END PGP SIGNATURE----- From jschull at softlock.com Thu Apr 20 14:35:38 2006 From: jschull at softlock.com (Jon Schull) Date: Thu, 20 Apr 2006 08:35:38 -0400 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 36, Issue 60 In-Reply-To: References: Message-ID: <38062F24-9EF5-42FF-9A42-565136965F76@softlock.com> > I think it should be an Apple with a bite out of it--get it? Apple, > snake, apple, byte . > I kill myself ;-) Okay obviously I need to shut up and go away > now...Bye. Actually, I think you nailed it... Apple, snake, tree of knowledge.... Two possible layouts are suggested by these images: http://www.fotosearch.com/BDX108/bxp26159/ http://it.rit.edu/~jis/pylogo/pylogo.png (if only I could really draw...) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull at digitalgoods.com fax: 978-246-0487 cell: 585-738-6696 On Apr 20, 2006, at 2:00 AM, pythonmac-sig-request at python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request at python.org > > You can reach the person managing the list at > pythonmac-sig-owner at python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > Today's Topics: > > 1. Re: Fwd: MacPython icon mockup (Brendan Simons) > 2. Re: Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I > succeeded this evening (Christopher Barker) > 3. Re: Fwd: MacPython icon mockup (Christopher Barker) > 4. Re: Fwd: MacPython icon mockup (Daniel Lord) > 5. Re: Fwd: MacPython icon mockup (Jacob Rus) > 6. Re: Unintsaller for Universal (kevin parks) > 7. Re: Fwd: MacPython icon mockup (Jacob Rus) > 8. Re: Fwd: MacPython icon mockup (Daniel Lord) > > From: Brendan Simons > Date: April 20, 2006 12:37:41 AM EDT > To: pythonmac-sig at python.org, Jacob Rus > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > > On 20-Apr-06, at 12:15 AM, pythonmac-sig-request at python.org wrote: > >> From: Jacob Rus >> Date: April 19, 2006 10:06:34 PM EDT (CA) >> To: pythonmac-sig at python.org >> Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup >> >> >> Bill Janssen wrote: >>>> No, I disagree. If there is any text, it should be in dark gray 18 >>>> point Lucida Grande, as per the HIG. XCode uses colored file >>>> extensions in its document graphics because it deals with many >>>> different types of source files, and this keeps them >>>> distinguishable. >>> It's not just XCode. *Users* deal with many different kinds of >>> source files, and apparently the icons used in XCode are the ones >>> that Mac OS X uses generically. For example, look at the Finder >>> icon >>> for a Java source file, and you'll see that the XCode icon is used >>> there, as well. >> >> Yes, java source files get the xcode icons, because XCode is set >> up on your machine as the editor for java files (and registered as >> such with Launch Services). Similarly for c, etc. On my machine, >> some of these get XCode document icons, and some get TextMate >> document icons, because for me, TextMate is the editor for those >> file types. >> >> You miss my point, which is that python files don't need giant >> colored "py" splashed across them, if they have a distinguishable >> python icon. XCode does not follow the HIG, because it makes >> distinguishing c files from java files easier. Our new python >> icon will not have this problem, because it only needs to >> represent with one type of file. > > I agree completely. > >> >>> The greeked source code in the background of the document >>> indicates "source code", the file extension indicates the >>> language, and the color apparently indicates something as well, >>> though it's not clear (to me) just what. >> >> If you like, we could add some greeked source code. If we do, >> then the pyo/pyc files will need something other than random 1s >> and 0s to distinguish it, especially at small sizes. I'm open to >> suggestions. > > I tried colourizing the document, but it's nearly impossible to > find a colour that complements both the blue and yellow of the > logo. You could darken the paper slightly (not so much that you > couldn't read the word "DATA" though. > > Brendan > -- > Brendan Simons > > From: Christopher Barker > Date: April 20, 2006 12:39:25 AM EDT > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 > Python 2.4 IIRC--I succeeded this evening > > > Daniel Lord wrote: > >> That sound reasonable, but not what I did--I installed them in / >> usr/ local/lib & include. > > I've done that, but the only way I could make sure that they got > statically linked was to make sure that there were not dynamic > versions of the same libs anywhere else on the search path, so I > found it easier to put them in a special place, and it's always > possible that I'd have the dynamic libs installed for some other > reason. > > -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 > > > > > From: Christopher Barker > Date: April 20, 2006 12:41:36 AM EDT > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Jacob Rus wrote: >> Christopher Barker wrote: >> > They look great, but what the heck is "DATA"? >> It was has's [idea][1] for what a .pyo/.pyc icons should look >> like, similar to how script editor allows saving of plain >> text .applescript files with an icon labeled "TEXT". > > Well, a script is text, but a .pyc file is not Data. Maybe > "bytecode", which is too long, or "bytes" or "code" or ".pyc" or ??? > > In fact, I think the ones-and-zeros background without any words > might work just fine. > > -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 > > > > > From: Daniel Lord > Date: April 20, 2006 1:33:22 AM EDT > To: Christopher Barker > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > > On Apr 19, 2006, at 21:41, Christopher Barker wrote: > >> Well, a script is text, but a .pyc file is not Data. Maybe >> "bytecode", >> which is too long, or "bytes" or "code" or ".pyc" or ??? > > I think it should be an Apple with a bite out of it--get it? Apple, > snake, apple, byte . > I kill myself ;-) Okay obviously I need to shut up and go away > now...Bye. > > > > > From: Jacob Rus > Date: April 20, 2006 1:40:00 AM EDT > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Christopher Barker wrote: >> Jacob Rus wrote: >>> Christopher Barker wrote: >>> > They look great, but what the heck is "DATA"? >>> It was has's [idea][1] for what a .pyo/.pyc icons should look >>> like, similar to how script editor allows saving of plain >>> text .applescript files with an icon labeled "TEXT". >> Well, a script is text, but a .pyc file is not Data. Maybe >> "bytecode", which is too long, or "bytes" or "code" or ".pyc" or ??? >> In fact, I think the ones-and-zeros background without any words >> might work just fine. > > Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon- > variations.png > > Which do you prefer? > > -Jacob > > > > > > From: kevin parks > Date: April 20, 2006 1:44:31 AM EDT > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Unintsaller for Universal > > > thank you bob you rock! > > \m/ (>.<) \m/ > > this totally works ... (for anyone else needing to dumb down to 2.4.1) > > cheers all... > > -kp-- > > > > On Apr 20, 2006, at 1:02 AM, Bob Ippolito wrote: > >> >> On Apr 19, 2006, at 7:55 PM, kevin parks wrote: >> >>> How do i uninstall 2.4.3? >>> so that i can dial back to 2.4.1? or am i screwed? >> >> I don't think there were any plans for an uninstaller. Just >> install 2.4.1 and everything will work fine, it'll overwrite >> everything that needs to be overwritten. >> >> -bob > > > > > > From: Jacob Rus > Date: April 20, 2006 1:47:51 AM EDT > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Brendan Simons wrote: >> I like it, but Aqua has tuned down a lot its glassiness in recent >> years. I would tone down the difference between highlights and >> shadows myself, but I'm not going to argue about it :) > > You're probably right, but make sure you look at the actual icon > files (in the zip files I linked to earlier) as well as the png > files. There are some icc profile mismatch issues here, which I > always seem to run into with png files (and it previews differently > in Camino and Safari, for instance). The actual version may be > duller than the preview you're seeing. Maybe I should post a > screenshot instead of saving from photoshop. > > -Jacob > > > > > > From: Daniel Lord > Date: April 20, 2006 2:00:32 AM EDT > To: Jacob Rus > Cc: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > > On Apr 19, 2006, at 22:47, Jacob Rus wrote: > >> Brendan Simons wrote: >>> I like it, but Aqua has tuned down a lot its glassiness in recent >>> years. I would tone down the difference between highlights and >>> shadows >>> myself, but I'm not going to argue about it :) >> >> You're probably right, but make sure you look at the actual icon >> files >> (in the zip files I linked to earlier) as well as the png files. >> There >> are some icc profile mismatch issues here, which I always seem to run >> into with png files (and it previews differently in Camino and >> Safari, >> for instance). The actual version may be duller than the preview >> you're >> seeing. Maybe I should post a screenshot instead of saving from >> photoshop. > > Jacob, > I think your 'glassiness' is understated and fine. I never meant > the extreme of the original colored iMac look. > I think it adds a nice 3-D look especially in the smaller sizes and > is under-stated enough to fit the Apple look of today with a little > of a yellow and blue color Apple doesn't use. Could it be turned > down a bit? Yeah I suppose. But there is a time to tweak and a time > to move on when the diminishing returns of tweaking are vanishingly > small and we can ignore subsequent terms in the series (flash-back > to advanced engineering math ;-). Guess what time I think it is IMHO? > > Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/2529ea1d/attachment.htm From daniellord at mac.com Thu Apr 20 23:33:01 2006 From: daniellord at mac.com (Daniel Lord) Date: Thu, 20 Apr 2006 14:33:01 -0700 Subject: [Pythonmac-SIG] HFS versus POSIX paths (changed from fixing the documentation) In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> Message-ID: <04DE8F64-CF89-433B-A002-1203C738AB67@mac.com> I changed the topic so many can avoid it and we don't bore them to tears ;-) On Apr 20, 2006, at 2:02, has wrote: > As for working with HFS paths (and a pox on scriptable apps that > require them, btw, because they're fundamentally unreliable), you > ought to be able to use Carbon.CF to translate between POSIX/ > Windows/HFS path styles. Unfortunately, I suspect getting in and > out of there may be one of the areas that's broken. I am writing an app combining excel and python/appscript to fetch quotes from the web and value stock portfolios . But I give up on using appscript with Excel--some things just don't work because I think the terminology is seriously warped if no broken. Applescriptworks but appscript doesn't. I instead build a text Applescript from strings and use popen2 to invoke osascript like this example which reads in the stock symbols from a named range in an excel spreadsheet: def readSymbolList(self, workbook, worksheet, range): _getSymbolsScript = """tell app "Microsoft Excel" return Value of Range "%s" of Worksheet "%s" of Workbook "%s" end tell""" # read symbols from spreadsheet cout, cin = popen2.popen2( "/usr/bin/osascript -e \'%s\'" % \ (_getSymbolsScript % (range, worksheet, workbook))) symbols = cout.readline()[:-1] symbols = re.sub(",\s",",",symbols) if (self.DEBUG): print __module__, "::","symbols=", repr(symbols) # create symbolList symbolList = [] symbols = string.split(symbols, ",") if (self.DEBUG): print __module__, "::","stocks=", repr(symbols) for symbol in symbols: if (symbol != '0'): symbolList.append(symbol) cout.close() cin.close() return symbolList > I wouldn't mind adding a makewithhfspath class method and hfspath > instance method to macfile's Alias and File classes, but I'd want > to be sure I had a correct implementation first, however, as it's > not quite as trivial as it sounds on the surface (e.g. volume names > are not a direct translation in either direction). If you really desire to you can but I just wrote a quick hack using re.sub() that correctly converts the paths I use so my needs are met. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/f9924bd1/attachment.html From bear42 at code-bear.com Fri Apr 21 01:58:54 2006 From: bear42 at code-bear.com (bear) Date: Thu, 20 Apr 2006 19:58:54 -0400 Subject: [Pythonmac-SIG] Framework build with readline - question Message-ID: <4448203E.9080004@code-bear.com> I'm trying to do a framework build of Python 2.4.2 and need to have Python use a local install of readline 5.0 but the configure step seems to be ignoring my --with-readline configure is run like this: ./configure --prefix=/home/bear/test --enable-framework=/home/bear/test/Library/Frameworks --with-readline=/home/bear/test --disable-ipv6 I've confirmed that at /home/bear/test there is include/readline/* and lib/readline/* Before I go digging into configure and related files I figure I would ask here. thanks, bear From jrus at fas.harvard.edu Fri Apr 21 02:25:10 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Thu, 20 Apr 2006 20:25:10 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> Message-ID: <44482666.20803@fas.harvard.edu> has wrote: > It might be handy to compare versions with 2D-snakes and 3D-snakes side > by side (the tonal gradient on the 2D version may need nudged up a > fraction to make it pop a bit more against the backdrop). Perhaps with a > third 50% version to compare too. http://hcs.harvard.edu/~jrus/python/flat-vs-glossy.png From brendansimons at yahoo.ca Fri Apr 21 05:11:19 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Thu, 20 Apr 2006 23:11:19 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: I've attached a few more mockups using Jacob's excellent aquified logo. Have a look here: http://www.flickr.com/photos/28928816 at N00/132185325/ In the spirit of open source, the layered psd files are available here: http://s65.yousendit.com/d.aspx?id=2CK5SUGTM74TH3OXH3WY6R8T66 -Brendan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ryanwilcox at mac.com Fri Apr 21 05:22:05 2006 From: ryanwilcox at mac.com (Ryan Wilcox) Date: Thu, 20 Apr 2006 23:22:05 -0400 Subject: [Pythonmac-SIG] Size of (Universal) Py2app apps? Message-ID: Hi all, I recently converted my pyobjc application to Universal Python 2.4, and the size came out to 7.4MB. Does this sound reasonable to everybody in size, or is there something in my setup.py that I need to change/add now that I'm building universal? Thanks, _Ryan Wilcox -- Wilcox Development Solutions: Toolsmiths for the Internet Age PGP: 0x2F4E9C31 From njriley at uiuc.edu Fri Apr 21 05:38:57 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 20 Apr 2006 22:38:57 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <20060421033857.GA85481@uiuc.edu> On Thu, Apr 20, 2006 at 11:11:19PM -0400, Brendan Simons wrote: > I've attached a few more mockups using Jacob's excellent aquified > logo. Have a look here: > http://www.flickr.com/photos/28928816 at N00/132185325/ The .pyc logo is a great improvement over everything else I've seen - the bit patterns don't quite line up nicely. You might also consider using a small snippet of Python bytecode instead, like the XP icons did: I don't think stealing the Apple Installer icon is a good idea for .egg though - double-clicking it doesn't install anything. Perhaps something closer to a StuffIt archive icon (a closed box) or a Python logo behind Apple's zipper icon with "EGG" underneath. Or an egg? Anyone remember Software Ventures' logo? :) The PYTHON text appears to be in the wrong font. By analogy with AppleScript, perhaps the text shouldn't be there at all (although how many people will recognize the Python logo anyway?) Otherwise, looks terrific! Wish I had any artistic talent so I could offer something other than suggestions. -- Nicholas Riley | From daniellord at mac.com Fri Apr 21 06:50:45 2006 From: daniellord at mac.com (Daniel Lord) Date: Thu, 20 Apr 2006 21:50:45 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <5FB93999-49CF-4C5A-8DF8-0C1519A65EEC@mac.com> On Apr 20, 2006, at 20:11, Brendan Simons wrote: > I've attached a few more mockups using Jacob's excellent aquified > logo. Have a look here: > http://www.flickr.com/photos/28928816 at N00/132185325/ > > In the spirit of open source, the layered psd files are available > here: > http://s65.yousendit.com/d.aspx?id=2CK5SUGTM74TH3OXH3WY6R8T66 I have to say: I really like these. Visually distinct, crisp, and clear. Great work to all of you who have put talents I wish I had in graphic design to work and produced an outstanding set of icons the Mac Python community should be proud of. I know I am. I am sure the tweaking will continue, but I think its 98 pct there. I'll let you all sort it out, but I am ready to take these now--of course I am one small meager vote ;-). From jrus at fas.harvard.edu Fri Apr 21 06:56:45 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 00:56:45 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <4448660D.9090506@fas.harvard.edu> Brendan Simons wrote: > I've attached a few more mockups using Jacob's excellent aquified > logo. Have a look here: > http://www.flickr.com/photos/28928816 at N00/132185325/ > > In the spirit of open source, the layered psd files are available here: > http://s65.yousendit.com/d.aspx?id=2CK5SUGTM74TH3OXH3WY6R8T66 That's great! Putting ideas on paper will keep the ball rolling. A few comments: 1. I just realized that I didn't mask some of the lighting effects in that "aquified logo", so there's some spillover into the space around it, which has since been fixed, in both [psd][1] and [png][2] versions online. 2. Go ahead and use the [document icon psd][3] I put up as a base. The template comes straight from Apple. This will help, for instance, when you want to write stuff under the page turn, which is a separate layer on top complete with shadow. 3. The logo on the .py icon seems a bit on the big side. Almost all such icons are bigger than the AHIG recommends, but I think this is pushing it. 4. I agree that the Idle icon should probably have some sort of technical pen. Can someone find an image of one? 5. I think we should put drop-shadows on the logos in the .py, Idle, and .pyc icons (instead of a stroke). 6. I've never used .egg files, but this icon makes them look like installers. Is that what they are? 7. We still need a few more, like the drag-n-drop applet maker, the icons for the associated applets themselves. In general though, looks good! -Jacob From troy_lists at rpsystems.net Fri Apr 21 07:03:57 2006 From: troy_lists at rpsystems.net (Troy Rollins) Date: Fri, 21 Apr 2006 01:03:57 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <5FB93999-49CF-4C5A-8DF8-0C1519A65EEC@mac.com> References: <5FB93999-49CF-4C5A-8DF8-0C1519A65EEC@mac.com> Message-ID: <33E914D2-33D4-4E20-98E1-8B216C8BA788@rpsystems.net> On Apr 21, 2006, at 12:50 AM, Daniel Lord wrote: > I have to say: I really like these. Visually distinct, crisp, and > clear. Great work to all of you who have put talents I wish I had in > graphic design to work and produced an outstanding set of icons the > Mac Python community should be proud of. I know I am. I am sure the > tweaking will continue, but I think its 98 pct there. I'll let you > all sort it out, but I am ready to take these now--of course I am one > small meager vote ;-). To ask the inevitable dumb question... what will you do with them? Override the creator code icons for those types of files somehow? Manually attach them to things? Something else? -- Troy RPSystems, Ltd. http://www.rpsystems.net From dp at ulaluma.com Fri Apr 21 07:08:00 2006 From: dp at ulaluma.com (Donovan Preston) Date: Thu, 20 Apr 2006 22:08:00 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448660D.9090506@fas.harvard.edu> References: <4448660D.9090506@fas.harvard.edu> Message-ID: <006EE1E7-A1F7-44B0-A07C-9173B6BEEFE1@ulaluma.com> On Apr 20, 2006, at 9:56 PM, Jacob Rus wrote: > 6. I've never used .egg files, but this icon makes them look like > installers. Is that what they are? They are .zip files that contain python files and other resources used by a python package. Instead of installing source in your site- packages directory, you drop an egg in there and you can import from those packages/modules. > 7. We still need a few more, like the drag-n-drop applet maker, the > icons for the associated applets themselves. How about something like the old stuffit icons used to look like: http://www.flowjo.com/win/assets/images/drag.jpg With a python logo going in the top and a generic application coming out the bottom. dp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060420/ede6b3ac/attachment.htm From dp at ulaluma.com Fri Apr 21 07:00:45 2006 From: dp at ulaluma.com (Donovan Preston) Date: Thu, 20 Apr 2006 22:00:45 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <20060421033857.GA85481@uiuc.edu> References: <20060421033857.GA85481@uiuc.edu> Message-ID: <2A003E7C-0F62-4D34-95EB-A66C69FDA139@ulaluma.com> On Apr 20, 2006, at 8:38 PM, Nicholas Riley wrote: > On Thu, Apr 20, 2006 at 11:11:19PM -0400, Brendan Simons wrote: >> I've attached a few more mockups using Jacob's excellent aquified >> logo. Have a look here: >> http://www.flickr.com/photos/28928816 at N00/132185325/ Awesome. I love them. Ship it. :-) > I don't think stealing the Apple Installer icon is a good idea for > .egg though - double-clicking it doesn't install anything. Perhaps > something closer to a StuffIt archive icon (a closed box) or a Python > logo behind Apple's zipper icon with "EGG" underneath. Or an egg? > Anyone remember Software Ventures' logo? :) How about just the lego brick used for components with the python logo on the side. Look in /System/Library/Components. > The PYTHON text appears to be in the wrong font. By analogy with > AppleScript, perhaps the text shouldn't be there at all (although how > many people will recognize the Python logo anyway?) Probably the python logo is enough, since the file ends in .py. dp From njriley at uiuc.edu Fri Apr 21 07:09:47 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri, 21 Apr 2006 00:09:47 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448660D.9090506@fas.harvard.edu> References: <4448660D.9090506@fas.harvard.edu> Message-ID: <20060421050947.GA87250@uiuc.edu> On Fri, Apr 21, 2006 at 12:56:45AM -0400, Jacob Rus wrote: > 6. I've never used .egg files, but this icon makes them look like > installers. Is that what they are? No, they're the equivalent of jar files (archives of Python code), except they're not launchable. Unfortunately the jar icon is rather boring: it's just a coffee cup in a document with "JAR" underneath it. -- Nicholas Riley | From dp at ulaluma.com Fri Apr 21 07:10:46 2006 From: dp at ulaluma.com (Donovan Preston) Date: Thu, 20 Apr 2006 22:10:46 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <33E914D2-33D4-4E20-98E1-8B216C8BA788@rpsystems.net> References: <5FB93999-49CF-4C5A-8DF8-0C1519A65EEC@mac.com> <33E914D2-33D4-4E20-98E1-8B216C8BA788@rpsystems.net> Message-ID: On Apr 20, 2006, at 10:03 PM, Troy Rollins wrote: > > On Apr 21, 2006, at 12:50 AM, Daniel Lord wrote: > >> I have to say: I really like these. Visually distinct, crisp, and >> clear. Great work to all of you who have put talents I wish I had in >> graphic design to work and produced an outstanding set of icons the >> Mac Python community should be proud of. I know I am. I am sure the >> tweaking will continue, but I think its 98 pct there. I'll let you >> all sort it out, but I am ready to take these now--of course I am one >> small meager vote ;-). > > To ask the inevitable dumb question... what will you do with them? > Override the creator code icons for those types of files somehow? > Manually attach them to things? Something else? The document icon can be inside the IDLE application as the document icon. If the installer associates .py files with IDLE, then they'll get that icon. Of course if someone changes the association (mine are associated with Aquamacs or sometimes SubEthaEdit) then they'll change, but that's fine. Anyone who does that knows why it happened. dp From njriley at uiuc.edu Fri Apr 21 07:16:07 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Fri, 21 Apr 2006 00:16:07 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <2A003E7C-0F62-4D34-95EB-A66C69FDA139@ulaluma.com> References: <20060421033857.GA85481@uiuc.edu> <2A003E7C-0F62-4D34-95EB-A66C69FDA139@ulaluma.com> Message-ID: <20060421051607.GB87250@uiuc.edu> On Thu, Apr 20, 2006 at 10:00:45PM -0700, Donovan Preston wrote: > > I don't think stealing the Apple Installer icon is a good idea for > > .egg though - double-clicking it doesn't install anything. Perhaps > > something closer to a StuffIt archive icon (a closed box) or a Python > > logo behind Apple's zipper icon with "EGG" underneath. Or an egg? > > Anyone remember Software Ventures' logo? :) > > How about just the lego brick used for components with the python > logo on the side. Look in /System/Library/Components. Gah, I meant to suggest this in my last email. I think this is a good idea too. Or an egg-shaped brick? *ducks* > > The PYTHON text appears to be in the wrong font. By analogy with > > AppleScript, perhaps the text shouldn't be there at all (although how > > many people will recognize the Python logo anyway?) > > Probably the python logo is enough, since the file ends in .py. Good point - .py is unlikely to be a hidden extension. -- Nicholas Riley | From jrus at fas.harvard.edu Fri Apr 21 08:03:00 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 02:03:00 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448660D.9090506@fas.harvard.edu> References: <4448660D.9090506@fas.harvard.edu> Message-ID: <44487594.7000407@fas.harvard.edu> Jacob Rus wrote: > 1. I just realized that I didn't mask some of the lighting effects in > that "aquified logo", so there's some spillover into the space > around it, which has since been fixed, in both [psd][1] and [png][2] > versions online. > 2. Go ahead and use the [document icon psd][3] I put up as a base. The > template comes straight from Apple. This will help, for instance, > when you want to write stuff under the page turn, which is a > separate layer on top complete with shadow. Whoops, I just realized, I left off the links: [1]: http://hcs.harvard.edu/~jrus/python/python-logo.psd [2]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png [3]: http://hcs.harvard.edu/~jrus/python/python-icons.psd From jrus at fas.harvard.edu Fri Apr 21 09:38:05 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 03:38:05 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <44488BDD.6040203@fas.harvard.edu> Brendan Simons wrote: > I've attached a few more mockups using Jacob's excellent aquified > logo. Have a look here: > http://www.flickr.com/photos/28928816 at N00/132185325/ Alright, I tried the monochrome idea for bytecode files, and also put up my own attempt at an embossed logo on a rocket: http://hcs.harvard.edu/~jrus/python/docs-and-rocket.png All of these are also included in the psd file (which keeps getting bigger... I should maybe remove some unused layers): http://hcs.harvard.edu/~jrus/python/python-icons.psd -Jacob From mjb at uma.pt Fri Apr 21 12:31:07 2006 From: mjb at uma.pt (Michael Barber) Date: Fri, 21 Apr 2006 11:31:07 +0100 Subject: [Pythonmac-SIG] hiding pyc files Message-ID: <160A1756-6258-4AF3-B775-B443D7444DE3@uma.pt> All the recent discussion of icons and filetypes has got me wondering: is there a way to get the Finder to hide all of the bytecode files? Presumably, this would require hiding files based on the filename extensions. I've been unable to find anything about that with Google; I get drowned in the flood of pages about how to hide the extensions, which is not what I'm looking for at all. Anyone have any idea about how it's done, or if it is even possible? Really, it's a pity that compiled bytecode files aren't prepended with a dot as well as getting the pyc extension. -- Michael From zbir at urbanape.com Fri Apr 21 13:13:54 2006 From: zbir at urbanape.com (Zachery Bir) Date: Fri, 21 Apr 2006 07:13:54 -0400 Subject: [Pythonmac-SIG] Size of (Universal) Py2app apps? In-Reply-To: References: Message-ID: On Apr 20, 2006, at 11:22 PM, Ryan Wilcox wrote: > Hi all, > > I recently converted my pyobjc application to Universal Python 2.4, > and the size came out to 7.4MB. > > Does this sound reasonable to everybody in size, or is there > something in my setup.py that I need to change/add now that I'm > building universal? It's reasonable. Moving to 2.4 means, you're bundling your own Python runtime, now. Before, you could reasonably get away with only the modules needed to run with Apple's built-in runtime. Zac From brendansimons at yahoo.ca Fri Apr 21 14:04:24 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Fri, 21 Apr 2006 08:04:24 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> On 21-Apr-06, at 6:00 AM, donovan wrote: >> I don't think stealing the Apple Installer icon is a good idea for >> .egg though - double-clicking it doesn't install anything. Perhaps >> something closer to a StuffIt archive icon (a closed box) or a Python >> logo behind Apple's zipper icon with "EGG" underneath. Or an egg? >> Anyone remember Software Ventures' logo? :) > > How about just the lego brick used for components with the python > logo on the side. Look in /System/Library/Components. I'm wary of using the brick logo, because as far as I can see Apple uses them extensively for OS components. I don't want to dilute their visual meaning by co-opting the icon for something different. I agree that the box isn't great either though since eggs aren't executable. On 21-Apr-06, at 6:00 AM, donovan preston wrote: > On Apr 20, 2006, at 8:38 PM, Nicholas Riley wrote: > >> On Thu, Apr 20, 2006 at 11:11:19PM -0400, Brendan Simons wrote: >>> I've attached a few more mockups using Jacob's excellent aquified >>> logo. Have a look here: >>> http://www.flickr.com/photos/28928816 at N00/132185325/ > > Awesome. I love them. Ship it. :-) > >> I don't think stealing the Apple Installer icon is a good idea for >> .egg though - double-clicking it doesn't install anything. Perhaps >> something closer to a StuffIt archive icon (a closed box) or a Python >> logo behind Apple's zipper icon with "EGG" underneath. Or an egg? >> Anyone remember Software Ventures' logo? :) > > How about just the lego brick used for components with the python > logo on the side. Look in /System/Library/Components. > >> The PYTHON text appears to be in the wrong font. By analogy with >> AppleScript, perhaps the text shouldn't be there at all (although how >> many people will recognize the Python logo anyway?) > > Probably the python logo is enough, since the file ends in .py. > > dp OK, here I have to disagree again. I use icon view all the time, and I really appreciate having filetypes written on file icons. It's one of the reasons I switched to the mac. It lets me know what type of is what without having to decode some unfamiliar icon, or look to the file extension (which is still optional on the mac, though I admit, required for python). I'll look into the font, but I thought it was supposed to be Lucida Grande. Does anyone have a wiki where I could throw up a straw poll? On 21-Apr-06, at 6:00 AM, jacob rus wrote: > Brendan Simons wrote: >> I've attached a few more mockups using Jacob's excellent aquified >> logo. Have a look here: >> http://www.flickr.com/photos/28928816 at N00/132185325/ > > Alright, I tried the monochrome idea for bytecode files, and also > put up my own attempt at an embossed logo on a rocket: > > http://hcs.harvard.edu/~jrus/python/docs-and-rocket.png > > All of these are also included in the psd file (which keeps getting > bigger... I should maybe remove some unused layers): > > http://hcs.harvard.edu/~jrus/python/python-icons.psd > > -Jacob These are great Jacob. I like the disk image in particular. There's a couple of changes I'd like to try this evening: - I will incorporate your new icon, - I want to see what real python bytecode looks like on the pyc/pyo icon. - The rocket logo looks better to me centered over the widest bit - The mechanical pencil needs a bit of perspective so that it appears to lay flat on the sheet. If you're looking for more pencil images, here's two good ones: http://www.keyboardmag.com/Pictures/web/y/h/c/Pentel_Pencil.jpg http://www.misterart.com/grouppix/280x210/2000/g2417.jpg I'll check back with something tonight, Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/6ebecf6d/attachment.html From zbir at urbanape.com Fri Apr 21 14:09:01 2006 From: zbir at urbanape.com (Zachery Bir) Date: Fri, 21 Apr 2006 08:09:01 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: On Apr 21, 2006, at 8:04 AM, Brendan Simons wrote: > On 21-Apr-06, at 6:00 AM, donovan wrote: >>> I don't think stealing the Apple Installer icon is a good idea for >>> .egg though - double-clicking it doesn't install anything. Perhaps >>> something closer to a StuffIt archive icon (a closed box) or a >>> Python >>> logo behind Apple's zipper icon with "EGG" underneath. Or an egg? >>> Anyone remember Software Ventures' logo? :) >> >> How about just the lego brick used for components with the python >> logo on the side. Look in /System/Library/Components. > > I'm wary of using the brick logo, because as far as I can see Apple > uses them extensively for OS components. I don't want to dilute > their visual meaning by co-opting the icon for something > different. I agree that the box isn't great either though since > eggs aren't executable. A lot of Internet Plug-ins use them, and I've seen them branded by the developers of such. I don't think we'll be diluting much. Zac From jrus at fas.harvard.edu Fri Apr 21 15:18:56 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 09:18:56 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: <4448DBC0.9060305@fas.harvard.edu> Brendan Simons wrote: > I'm wary of using the brick logo, because as far as I can see Apple uses > them extensively for OS components. I don't want to dilute their visual > meaning by co-opting the icon for something different. I agree that the > box isn't great either though since eggs aren't executable. The brick icon is just a generic "Plug-in" icon, used by numerous types of plug-ins throughout the OS (iTunes plugins, internet plugins, &c.) > OK, here I have to disagree again. I use icon view all the time, and I > really appreciate having filetypes written on file icons. It's one of > the reasons I switched to the mac. It lets me know what type of is > what without having to decode some unfamiliar icon, or look to the file > extension (which is still optional on the mac, though I admit, required > for python). I'll look into the font, but I thought it was supposed > to be Lucida Grande. It's only unfamiliar once ;). In any case, if you do want to add text, use the template, because all the Apple icons use 18 point Lucida Grande Bold, black text, 60% opacity, -20 tracking, "Crisp" rendering, and centered at a particular spot. The easiest way to imitate this is by just using the template. > - The rocket logo looks better to me centered over the widest bit Yeah, I think so too, now that I compare them. I'm still not sure I like the rocket in general... it's kind of tacky. > - The mechanical pencil needs a bit of perspective so that it appears to > lay flat on the sheet. If you're looking for more pencil images, here's > two good ones: Hmm... I'll let someone else take a crack at that one--I just copied some picture off a random google search. For reference, here's what the AHIG has to say about icons: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIcons/chapter_14_section_2.html -Jacob From gandreas at visi.com Fri Apr 21 15:04:02 2006 From: gandreas at visi.com (glenn andreas) Date: Fri, 21 Apr 2006 08:04:02 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: On Apr 21, 2006, at 7:09 AM, Zachery Bir wrote: > On Apr 21, 2006, at 8:04 AM, Brendan Simons wrote: > >> On 21-Apr-06, at 6:00 AM, donovan wrote: >>>> I don't think stealing the Apple Installer icon is a good idea for >>>> .egg though - double-clicking it doesn't install anything. Perhaps >>>> something closer to a StuffIt archive icon (a closed box) or a >>>> Python >>>> logo behind Apple's zipper icon with "EGG" underneath. Or an egg? >>>> Anyone remember Software Ventures' logo? :) >>> >>> How about just the lego brick used for components with the python >>> logo on the side. Look in /System/Library/Components. >> >> I'm wary of using the brick logo, because as far as I can see Apple >> uses them extensively for OS components. I don't want to dilute >> their visual meaning by co-opting the icon for something >> different. I agree that the box isn't great either though since >> eggs aren't executable. > > A lot of Internet Plug-ins use them, and I've seen them branded by > the developers of such. I don't think we'll be diluting much. > > Zac That's because the lego brick icon is designed for "plug-ins" (i.e., some form of a bundle with executable code) - to see it in action, create a new folder named "test.plugin" (and tell the Finder that yes, you do want that extension), and you'll see it turn into the lego brick (and if you get info, it'll even say "Kind: Plug-in") Since a .egg is neither a bundle nor does it contain executable code, it doesn't seem right to me. A shaded egg with a python logo decal seems good... Glenn Andreas gandreas at gandreas.com wicked fun! quadrium | build, mutate, evolve | images, textures, backgrounds, art From zbir at urbanape.com Fri Apr 21 15:31:25 2006 From: zbir at urbanape.com (Zachery Bir) Date: Fri, 21 Apr 2006 09:31:25 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> On Apr 21, 2006, at 9:04 AM, glenn andreas wrote: > On Apr 21, 2006, at 7:09 AM, Zachery Bir wrote: > >> A lot of Internet Plug-ins use them, and I've seen them branded by >> the developers of such. I don't think we'll be diluting much. >> >> Zac > > That's because the lego brick icon is designed for "plug-ins" (i.e., > some form of a bundle with executable code) - to see it in action, > create a new folder named "test.plugin" (and tell the Finder that > yes, you do want that extension), and you'll see it turn into the > lego brick (and if you get info, it'll even say "Kind: Plug-in") > > Since a .egg is neither a bundle nor does it contain executable code, > it doesn't seem right to me. I was merely commenting on the possibility of dilution if the brand (python logo) were applied. I agree with your sentiments. > A shaded egg with a python logo decal seems good... +1 Zac From arthur at iaaa.nl Fri Apr 21 15:42:06 2006 From: arthur at iaaa.nl (Arthur Elsenaar) Date: Fri, 21 Apr 2006 15:42:06 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448DBC0.9060305@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <4448DBC0.9060305@fas.harvard.edu> Message-ID: On 21 Apr 2006, at 15:18, Jacob Rus wrote: >> - The rocket logo looks better to me centered over the widest bit > > Yeah, I think so too, now that I compare them. I'm still not sure I > like the rocket in general... it's kind of tacky. just a quick idea, launching on the mac is equivalent to bouncing (in the dock). Maybe an icon with a kind of strobe/ line effect will do; a bounce or launched from a canon like.. much akin to what is done in cartoons. ae From jrus at fas.harvard.edu Fri Apr 21 16:14:09 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 10:14:09 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> Message-ID: <4448E8B1.90704@fas.harvard.edu> Zachery Bir wrote: > glenn andreas wrote: >> A shaded egg with a python logo decal seems good... > > +1 How's this then: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png -Jacob From zbir at urbanape.com Fri Apr 21 16:22:30 2006 From: zbir at urbanape.com (Zachery Bir) Date: Fri, 21 Apr 2006 10:22:30 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448E8B1.90704@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> Message-ID: On Apr 21, 2006, at 10:14 AM, Jacob Rus wrote: > Zachery Bir wrote: >> glenn andreas wrote: >>> A shaded egg with a python logo decal seems good... >> >> +1 > > How's this then: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png Love it! Zac From bear42 at code-bear.com Fri Apr 21 16:28:21 2006 From: bear42 at code-bear.com (bear) Date: Fri, 21 Apr 2006 10:28:21 -0400 Subject: [Pythonmac-SIG] Framework build with readline - question In-Reply-To: <4448203E.9080004@code-bear.com> References: <4448203E.9080004@code-bear.com> Message-ID: <4448EC05.3040707@code-bear.com> looks like I found my answer. It seems --with-readline is no longer required and that configure will locate readline if it's installed. Since we are building our own framework build and don't want to depend on the target system having readline we need to pass to configure LIBS= and CPPFLAGS= so that the autoconf tests will find our local copy of readline. bear wrote: > I'm trying to do a framework build of Python 2.4.2 and need to have > Python use a local install of readline 5.0 but the configure step seems > to be ignoring my --with-readline > > configure is run like this: > > ./configure --prefix=/home/bear/test > --enable-framework=/home/bear/test/Library/Frameworks > --with-readline=/home/bear/test > --disable-ipv6 > > > I've confirmed that at /home/bear/test there is include/readline/* and > lib/readline/* > > Before I go digging into configure and related files I figure I would > ask here. > > thanks, > > bear > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > From mark at mophilly.com Fri Apr 21 16:39:00 2006 From: mark at mophilly.com (Mark Phillips) Date: Fri, 21 Apr 2006 07:39:00 -0700 Subject: [Pythonmac-SIG] where to load files? Message-ID: I have a server application I wrote using Webware. It runs well on Fedora Core and RH 6.3. Now I have a need to install it on Mac OS X Server 10.4.x. The application needs to run 24/7, and to be launched at boot. I want to place the files so that os updates and similar do not interfere with the application. I have two directory trees to consider. First is Webware, which gets updated independently from my application files. Then there are my own set of .py files that are stored in another directory. I was on #macppython yesterday and the consensus seemed to be to place the file trees in /opt. I notice that MacPython installs in /Library/Frameworks/ Python.framework/Versions. Twisted is in the /Library/Python/2.3/site- packages. Apache2 installed in /opt. Does anyone have a suggestion of a reasonable and safe location for these two sets of files? Mark Phillips Mophilly & Associates On the web at http://www.mophilly.com On the phone at 619 444-9210 From kw at kevin-walzer.com Fri Apr 21 17:02:51 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Fri, 21 Apr 2006 11:02:51 -0400 Subject: [Pythonmac-SIG] Universal build of Tcl/Tk: 2 Pythonic questions Message-ID: <4448F41B.3050201@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. In preparing my "universal build" of Tcl/Tk for upload to the Pythonmac package site, I just realized that it is from a CVS HEAD tarball that's a couple of weeks old--which means that it's Tcl/Tk 8.5, not 8.4.x. Will Tkinter work when loaded against Tcl/Tk 8.5, instead of Tcl/Tk 8.4? (In Tcl/Tk this does not present a problem; its stubs mechanism allows packages compiled against one version to run against another.) If 8.4.x is required, I'll grab the latest 8.4.13 release, which should have the required changes in it (which were not in 8.4.12). 2. Doing a test build of an app with py2app and my universal version of Tcl/Tk, I get this error: raise ValueError, "got unrecognized magic of %08x" % (header.magic, MH_MAGIC, MH_CIGAM) TypeError: not all arguments converted during string formatting - -- And the build stops. I was also running into this with running macho_standalone by itself. I have no idea what the problem is, although I notice that it seems to happen when py2app is trying to graph the stubs library (libtclstub.8.5.a, for instance). Complete traceback below: Graphing /Applications/pysol/pysol-4.82-src/dist/PySol 4.82.app/Contents/Frameworks/Tcl.framework/Versions/8.5/libtclstub8.5.a (ppc) Traceback (most recent call last): File "setup.py", line 33, in ? frameworks=['/Library/Tcl.framework/Versions/8.5', 'Librar/Tk.framework/Versions/8.5'], File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 373, in run self._run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 494, in _run self.run_normal() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 554, in run_normal self.create_binaries(py_files, pkgdirs, extensions, loader_files) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 652, in create_binaries platfiles = mm.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOStandalone.py", line 101, in run mm.run_file(fn) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOGraph.py", line 62, in run_file m = MachO(pathname) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachO.py", line 254, in __init__ self.load() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachO.py", line 287, in load self.archs = self.load_fat(fat, fh) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachO.py", line 273, in load_fat raise ValueError, "got unrecognized magic of %08x" % (header.magic, MH_MAGIC, MH_CIGAM) TypeError: not all arguments converted during string formatting - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESPQbrTC5hIgjqTMRAmARAKCRF9uVAO+l1KdpWzW7dydRZnxAkQCgnTJ3 cPzcYXZn3pE0rF4Xtw2bcNw= =raXl -----END PGP SIGNATURE----- From kquirk at solidworks.com Fri Apr 21 17:03:16 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Fri, 21 Apr 2006 11:03:16 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: Ok, that set just rocks. Nice work. -----Original Message----- From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of Jacob Rus Sent: Friday, April 21, 2006 10:14 AM To: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup Zachery Bir wrote: > glenn andreas wrote: >> A shaded egg with a python logo decal seems good... > > +1 How's this then: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png -Jacob /mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Fri Apr 21 12:06:45 2006 From: hengist.podd at virgin.net (has) Date: Fri, 21 Apr 2006 11:06:45 +0100 Subject: [Pythonmac-SIG] HFS versus POSIX paths (changed from fixing the documentation) In-Reply-To: <04DE8F64-CF89-433B-A002-1203C738AB67@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> <04DE8F64-CF89-433B-A002-1203C738AB67@mac.com> Message-ID: Daniel Lord wrote: >I am writing an app combining excel and python/appscript to fetch quotes from the web and value stock portfolios . >But I give up on using appscript with Excel--some things just don't work because I think the terminology is seriously warped if no broken. Applescriptworks but appscript doesn't. Please send examples of where breakage occurs so I can figure out why. >I instead build a text Applescript from strings and use popen2 to invoke osascript like this example which reads in the stock symbols from a named range in an excel spreadsheet: The osax module provides a runscript() function that's easier to use if you're just wanting to pass in parameters. (It's a simple wrapper around Standard Additions' 'run script' command.) Or I can supply a rough version of osawrapper, which is a high-level wrapper around CarbonX.OSA; gives you much more power/flexibility when using AS from Python. Just ask. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Fri Apr 21 12:55:26 2006 From: hengist.podd at virgin.net (has) Date: Fri, 21 Apr 2006 11:55:26 +0100 Subject: [Pythonmac-SIG] Fixing the documentation... In-Reply-To: <1B98DDD0-536F-4725-B7C7-1551ED4C9146@mac.com> References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> <1B98DDD0-536F-4725-B7C7-1551ED4C9146@mac.com> Message-ID: Russell Finn wrote: >Well, no; see below. > >> join('d1', 'Users') >> ':d1:Users' # wrong! (should be 'd1:Users') > >The docstring for macpath.isabs() contradicts this, however: > > """On the Mac, relative paths begin with a colon, > but as a special case, paths with no colons at all are also relative. > Anything else is absolute (the string up to the first colon is the > volume name).""" > >This is in fact the historic interpretation of pathnames under Mac OS >before OS X Hmm, missed that. Ta for pointing it out. So that's an official HFS thing, rather than just a macpath thing, I take it? Somewhat strange anyway. -- Ronald Oussoren wrote: >>>More examples of brokenness: >>> >>>exists('d1:Users:has') >>>False >>>exists('/Users/has') >>>True >> >>[snip] >> >>If d1 is the name of your system volume, then that would be a bug -- Yep, it's a valid HFS path. Ergo, bug. >Right. Any function that touches the actual filesystem won't work So those should be deprecated/removed/flagged as not supporting HFS paths, and therefore no longer a useful or relevant part of the module. >>I don't believe it's "broken", but I won't claim it >>does much that's useful in the modern world other than handle >>HFS-style paths (if you happen to have one for some reason). > >Which happens with some Carbon related APIs and appeantly also some scripting interfaces. I dunno how many Carbon APIs require HFS path strings, as opposed to FSRefs, etc. (which the Python wrappers already allow you to convert to/from POSIX paths). OS 9 was pretty thorough in using file objects rather than path strings. So I'm a bit dubious this is such a big deal. As for scriptable applications that require HFS, not POSIX, paths, the problem here is that there's no easy way to convert POSIX path strings to HFS path strings and back using Python. macpath is zero relevance/use here since it doesn't provide functions for this, so this is no justification for keeping it. >Those functions exists and are part of the normal Carbon API's. macpath is an implementation for the path manipulation APIs in os.path for when you want to manipulate OS9 style paths. That is *all* it can be used for unless you're running on OS9. So the ONLY thing it's still good for is path munging then. Which isn't such a good idea to do since HFS path strings are fundamentally unsafe anyway - they can't distinguish between identically named volumes. As I say earlier, you're better off converting paths to POSIX form for splitting and joining them. If you really want to keep it, you need to stub/remove everything except the functions that still apply to HFS paths, which by my guess is: commonprefix, join, normcase, normpath, split, splitext. Still, it's a pretty pathetic collection of weak and obsolete functions with hardly any uses or users, and I honestly can't see any good reason why it needs to stay an active part of the standard library. Smacks of "Never mind the quality; feel the width." So I still say deprecate, but if not then it should at least be cleaned up so the complete garbage is removed. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From kw at kevin-walzer.com Fri Apr 21 18:21:08 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Fri, 21 Apr 2006 12:21:08 -0400 Subject: [Pythonmac-SIG] Universal build of Tcl/Tk: 2 Pythonic questions In-Reply-To: <4448F41B.3050201@kevin-walzer.com> References: <4448F41B.3050201@kevin-walzer.com> Message-ID: <44490674.1030201@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Walzer wrote: > 1. In preparing my "universal build" of Tcl/Tk for upload to the > Pythonmac package site, I just realized that it is from a CVS HEAD > tarball that's a couple of weeks old--which means that it's Tcl/Tk 8.5, > not 8.4.x. Will Tkinter work when loaded against Tcl/Tk 8.5, instead of > Tcl/Tk 8.4? (In Tcl/Tk this does not present a problem; its stubs > mechanism allows packages compiled against one version to run against > another.) If 8.4.x is required, I'll grab the latest 8.4.13 release, > which should have the required changes in it (which were not in 8.4.12). Further testing shows I'll need to build 8.4.13 instead. :-( Back to the Terminal... - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFESQZ0rTC5hIgjqTMRAvq6AJ422L0le0drCN/NMeav3RhfZRmcbwCgpfo6 A3ZP1uWoV837yJWDvxvBuXY= =eplR -----END PGP SIGNATURE----- From janssen at parc.com Fri Apr 21 18:42:42 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 21 Apr 2006 09:42:42 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Thu, 20 Apr 2006 20:11:19 PDT." Message-ID: <06Apr21.094244pdt."58633"@synergy1.parc.xerox.com> > http://www.flickr.com/photos/28928816 at N00/132185325/ Great job, the both of you. Let's declare victory and go home. Bill From Chris.Barker at noaa.gov Fri Apr 21 18:45:38 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 21 Apr 2006 09:45:38 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44482666.20803@fas.harvard.edu> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44482666.20803@fas.harvard.edu> Message-ID: <44490C32.5050906@noaa.gov> Jacob Rus wrote: >> It might be handy to compare versions with 2D-snakes and 3D-snakes side >> by side +1 on the glossy: it really says OS-X > I don't think stealing the Apple Installer icon is a good idea for > .egg though - double-clicking it doesn't install anything. Yet. We have talked about making a app that's a front end to easy-install, that would install an .egg. Maybe we should save the icons for that. Remember that on OS-X icons are primarily associated with applications, rather than file types, so that when you associate an application to a file type, you get the icon from that application (at least by default). That that icon is the "Egg Installer" icon, rather than the egg icon. This applies to any of the *.egg icons proposed. Question: Do icons need to be associated with applications? Personally, I'd love to have all my *.py files have a nice python icon, but be able to choose what text editor or IDE I'd want them to open up with my default (and it won't be IDLE!). i.e. I want the python icon, NOT the BBedit icon, even though I usually use BBedit to edit python files. -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 at noaa.gov From daniellord at mac.com Fri Apr 21 19:27:48 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 21 Apr 2006 10:27:48 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44490C32.5050906@noaa.gov> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44482666.20803@fas.harvard.edu> <44490C32.5050906@noaa.gov> Message-ID: On Apr 21, 2006, at 9:45, Christopher Barker wrote: > > Question: Do icons need to be associated with applications? > Personally, > I'd love to have all my *.py files have a nice python icon, but be > able > to choose what text editor or IDE I'd want them to open up with my > default (and it won't be IDLE!). i.e. I want the python icon, NOT the > BBedit icon, even though I usually use BBedit to edit python files. Chris, it is my experience that the Finder 'helpfully' replaces the file's icon with the 'appropriate' type of icon for the program that will open it. I will variously open files with more than one application depending on what I am doing (C/C++: Xcode/BBedit, Python: Komodo/BBEdit/Python) and I find it vexing to say the least but for neophytes it is probably a good thing that Apple chose to do it. So I suffer in silence. Riddle: When is a py not a py? Answer: when it is python source file you made with BBEdit. From jrus at fas.harvard.edu Fri Apr 21 20:44:33 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 14:44:33 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44490C32.5050906@noaa.gov> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44482666.20803@fas.harvard.edu> <44490C32.5050906@noaa.gov> Message-ID: <44492811.9030200@fas.harvard.edu> Christopher Barker wrote: > Question: Do icons need to be associated with applications? Personally, > I'd love to have all my *.py files have a nice python icon, but be able > to choose what text editor or IDE I'd want them to open up with my > default (and it won't be IDLE!). i.e. I want the python icon, NOT the > BBedit icon, even though I usually use BBedit to edit python files. Yeah, the way to do it is editing the app's Info.plist, and adding the icon to my.app/Contents/Resources. It's not too hard to do, but of course will break when you update the app. -Jacob From brendansimons at yahoo.ca Fri Apr 21 20:53:29 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Fri, 21 Apr 2006 11:53:29 -0700 (PDT) Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 36, Issue 69 In-Reply-To: Message-ID: <20060421185329.56711.qmail@web31107.mail.mud.yahoo.com> >From: Zachery Bir >Date: Fri, 21 Apr 2006 10:22:30 -0400 >Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup >On Apr 21, 2006, at 10:14 AM, Jacob Rus wrote: >> Zachery Bir wrote: >>> glenn andreas wrote: >>>> A shaded egg with a python logo decal seems good... >>> >>> +1 >> >> How's this then: >> >> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png >Love it! >Zac Me too. Nic job Jacob. We just need the grinder thingy now. (What was that for again?) -Brendan From Chris.Barker at noaa.gov Fri Apr 21 21:12:32 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 21 Apr 2006 12:12:32 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44492811.9030200@fas.harvard.edu> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44482666.20803@fas.harvard.edu> <44490C32.5050906@noaa.gov> <44492811.9030200@fas.harvard.edu> Message-ID: <44492EA0.8090209@noaa.gov> Jacob Rus wrote: > Christopher Barker wrote: > >> Question: Do icons need to be associated with applications? Personally, >> I'd love to have all my *.py files have a nice python icon, but be able >> to choose what text editor or IDE I'd want them to open up with my >> default (and it won't be IDLE!). i.e. I want the python icon, NOT the >> BBedit icon, even though I usually use BBedit to edit python files. > > Yeah, the way to do it is editing the app's Info.plist, and adding the > icon to my.app/Contents/Resources. But wouldn't that make all BBedit associated files get the Python icon? -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 at noaa.gov From daniellord at mac.com Fri Apr 21 21:36:34 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 21 Apr 2006 12:36:34 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44492EA0.8090209@noaa.gov> References: <4559F52C-F1CA-4EAA-B38A-9585A5FF0A52@yahoo.ca> <44482666.20803@fas.harvard.edu> <44490C32.5050906@noaa.gov> <44492811.9030200@fas.harvard.edu> <44492EA0.8090209@noaa.gov> Message-ID: <809AA5D9-FB68-4E2D-AD77-FC51B46F8B70@mac.com> On Apr 21, 2006, at 12:12, Christopher Barker wrote: >> Yeah, the way to do it is editing the app's Info.plist, and adding >> the >> icon to my.app/Contents/Resources. > > But wouldn't that make all BBedit associated files get the Python > icon? Yes, I believe it would and, further, one would have to keep 'hacking' it with every update. I just 'right-click' on files and choose my application to open them. As I said it is inconvenient, but it is still better than Windows ;-) BTW I am working on a telepathic Services Menu Component and Finder injection component that will just _know_ which application you want associated with a given file each time you view it in the Finder but its been slow going any volunteers ;-) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/73acc379/attachment.html From janssen at parc.com Fri Apr 21 21:52:38 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 21 Apr 2006 12:52:38 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Fri, 21 Apr 2006 12:12:32 PDT." <44492EA0.8090209@noaa.gov> Message-ID: <06Apr21.125240pdt."58633"@synergy1.parc.xerox.com> > > Yeah, the way to do it is editing the app's Info.plist, and adding the > > icon to my.app/Contents/Resources. > But wouldn't that make all BBedit associated files get the Python icon? No. Take a look at http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/BPRuntimeConfig.pdf You can associate different icons with different document types based on a number of document parameters, such as what extension it has, what its MIME type is, and what its "OSType" is. Bill From jrus at fas.harvard.edu Fri Apr 21 22:44:27 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 16:44:27 -0400 Subject: [Pythonmac-SIG] on a tangent from new icons Message-ID: <4449442B.6050903@fas.harvard.edu> While we're adding a bunch of icons to Mac Python, and editing Info.plist files, and so on, I think we might as well make a few other changes: 1. If it doesn't already, I think Mac Python should ship with a python spotlight importer (I got one somewhere else, but should be default) 2. Let's export some UTI's for .pyc/.pyo files and .egg files (maybe public.python-bytecode and public.python-egg or something, or maybe they need to be org.python.python-bytecode, etc.) 3. Let's make sure that python files get useful "kMDItemKind" names. Right now, if I associate one with PythonIDE.app, I get "plain text file" for .pyc, and "Document" for .pyo, which is not useful. 4. Let's add some spaces in the names of things like PythonIDE.app, BuildApplet.app, PythonLauncher.app and PackageManager.app. Some other questions: * What's the difference between PythonIDE.app and IDLE.app? Should they get different icons? Is one of them preferred to the other? I just use TextMate and iPython from terminal, so I don't really know what all they do. * What exactly do python eggs do? Are they just extra modules packaged up, or can you run them as standalone apps? * If the latter, how exactly do eggs differ from the applet's created by BuildApplet.app? * Do we want different icons for py2applet.app and BuildApplet.app? What exactly is the difference between these? Basically, I'm confused by the seemingly endless official or semi-official ways to package up python code and edit it on the Mac. Are any of these deprecated? -Jacob From dp at ulaluma.com Fri Apr 21 23:16:45 2006 From: dp at ulaluma.com (Donovan Preston) Date: Fri, 21 Apr 2006 14:16:45 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: <02CE71EF-38CF-4683-A0B8-2AA754087FAA@ulaluma.com> On Apr 21, 2006, at 5:04 AM, Brendan Simons wrote: > I'm wary of using the brick logo, because as far as I can see Apple > uses them extensively for OS components. I don't want to dilute > their visual meaning by co-opting the icon for something > different. I agree that the box isn't great either though since > eggs aren't executable. eggs are like components. They are plugins that you drop into Python to give Python more capabilities. >> Probably the python logo is enough, since the file ends in .py. > OK, here I have to disagree again. I use icon view all the time, > and I really appreciate having filetypes written on file icons. > It's one of the reasons I switched to the mac. It lets me know > what type of is what without having to decode some unfamiliar > icon, or look to the file extension (which is still optional on the > mac, though I admit, required for python). I'll look into the > font, but I thought it was supposed to be Lucida Grande. I'm fine with having py on the icon. I don't care because I'll never be seeing that particular icon, because my py files will be associated with another editor. dp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/4336c90c/attachment.htm From dp at ulaluma.com Fri Apr 21 23:18:00 2006 From: dp at ulaluma.com (Donovan Preston) Date: Fri, 21 Apr 2006 14:18:00 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: On Apr 21, 2006, at 6:04 AM, glenn andreas wrote: > Since a .egg is neither a bundle nor does it contain executable code, > it doesn't seem right to me. What? That's exactly what an egg is, a bundle (zip) of executable code. dp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/12df2bd4/attachment.html From dp at ulaluma.com Fri Apr 21 23:23:01 2006 From: dp at ulaluma.com (Donovan Preston) Date: Fri, 21 Apr 2006 14:23:01 -0700 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 36, Issue 69 In-Reply-To: <20060421185329.56711.qmail@web31107.mail.mud.yahoo.com> References: <20060421185329.56711.qmail@web31107.mail.mud.yahoo.com> Message-ID: On Apr 21, 2006, at 11:53 AM, Brendan Simons wrote: > >> From: Zachery Bir >> Date: Fri, 21 Apr 2006 10:22:30 -0400 >> Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > >> On Apr 21, 2006, at 10:14 AM, Jacob Rus wrote: > >>> Zachery Bir wrote: >>>> glenn andreas wrote: >>>>> A shaded egg with a python logo decal seems good... >>>> >>>> +1 >>> >>> How's this then: >>> >>> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > >> Love it! > >> Zac > > > Me too. Nic job Jacob. We just need the grinder thingy now. > (What was that for again?) I also really like these. Since nobody seems to like my lego brick idea, and the egg is really gorgeous, I'm changing my vote to this egg. The grinder is for the thing that converts dropped python scripts into a standalone Python application. Not something I really care about, but since we're making so much progress with this icon design, we might as well finish it for completeness. dp From dp at ulaluma.com Fri Apr 21 23:33:58 2006 From: dp at ulaluma.com (Donovan Preston) Date: Fri, 21 Apr 2006 14:33:58 -0700 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: <4449442B.6050903@fas.harvard.edu> References: <4449442B.6050903@fas.harvard.edu> Message-ID: <0DB5538C-1901-457E-BF45-B8BE41BA674D@ulaluma.com> On Apr 21, 2006, at 1:44 PM, Jacob Rus wrote: > 1. If it doesn't already, I think Mac Python should ship with a > python > spotlight importer (I got one somewhere else, but should be > default) I'm +0 on this. I got the spotlight importer someone mentioned on this list a while back and it worked ok, but I don't really find spotlight to be that useful. Since there seems to be a lot of energy right now towards producing a complete Python install experience on the mac, installing it might be good. But it might need to get checked into the Python mainline for that to happen, which might be more trouble than it is worth. Can the person who wrote the importer pipe up? How is it licensed? Can someone who has Python checkin rights volunteer to get it checked in and built by the normal build process? If not, then I think it should remain a separate download. > 2. Let's export some UTI's for .pyc/.pyo files and .egg files (maybe > public.python-bytecode and public.python-egg or something, or > maybe > they need to be org.python.python-bytecode, etc.) +1 > 3. Let's make sure that python files get useful "kMDItemKind" names. > Right now, if I associate one with PythonIDE.app, I get "plain > text > file" for .pyc, and "Document" for .pyo, which is not useful. +1 > 4. Let's add some spaces in the names of things like PythonIDE.app, > BuildApplet.app, PythonLauncher.app and PackageManager.app. PythonIDE and PackageManager are dead. Build Applet and Python Launcher seem like nice names, but I really don't care that much. +0. > Some other questions: > > * What's the difference between PythonIDE.app and IDLE.app? Should > they get different icons? Is one of them preferred to the > other? I > just use TextMate and iPython from terminal, so I don't really > know > what all they do. IDLE is written in Tkinter and is cross-platform. It is maintained by the core Python developers. PythonIDE is written using the ancient Mac OS Python bindings (Toolbox, now Carbon) and hasn't really worked very well for about 5 years. It's going away in the next release. Continue to use TextMate and IPython, it's what every Python developer does anyway :-) (I use Aquamacs and regular python in Terminal) > * What exactly do python eggs do? Are they just extra modules > packaged up, or can you run them as standalone apps? They are zipfiles of the kinds of things you normally see in your site-packages directory, either Python modules or packages. You can't run them. > * If the latter, how exactly do eggs differ from the applet's > created > by BuildApplet.app? BuildApplet takes the script you drop on it and puts it inside of an Application bundle as the main script. When you double-click the resulting application, it starts python and executes your main script. > * Do we want different icons for py2applet.app and BuildApplet.app? > What exactly is the difference between these? No idea. If there's a py2applet, it probably deprecates BuildApplet. I wasn't aware of this. I always just used py2app from the command line to build standalone Python applications, I don't see much value in offering drag-and-drop solutions, but I don't see the harm in offering them. > Basically, I'm confused by the seemingly endless official or > semi-official ways to package up python code and edit it on the Mac. > Are any of these deprecated? Yeah. Let's finally remove all the confusing deprecated crap. dp From gandreas at visi.com Fri Apr 21 23:39:34 2006 From: gandreas at visi.com (glenn andreas) Date: Fri, 21 Apr 2006 16:39:34 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> Message-ID: <6B3722EB-92EB-48A2-A245-9A8B0761C9A4@visi.com> On Apr 21, 2006, at 4:18 PM, Donovan Preston wrote: > > On Apr 21, 2006, at 6:04 AM, glenn andreas wrote: > >> Since a .egg is neither a bundle nor does it contain executable code, >> it doesn't seem right to me. > > What? That's exactly what an egg is, a bundle (zip) of executable > code. A "Bundle" under OS/X has a very specific meaning and structure (a folder, usually with an Info.plist file at the root, and things inside a subfolder called "Contents" - see for details)) - and a zip file isn't one. Glenn Andreas gandreas at gandreas.com The most merciful thing in the world ... is the inability of the human mind to correlate all its contents - HPL -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/780ea7db/attachment.htm From tomp at earthlink.net Fri Apr 21 23:56:18 2006 From: tomp at earthlink.net (Tom Pollard) Date: Fri, 21 Apr 2006 17:56:18 -0400 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: <0DB5538C-1901-457E-BF45-B8BE41BA674D@ulaluma.com> References: <4449442B.6050903@fas.harvard.edu> <0DB5538C-1901-457E-BF45-B8BE41BA674D@ulaluma.com> Message-ID: On Apr 21, 2006, at 5:33 PM, Donovan Preston wrote: > Can the person who wrote the importer pipe up? How is it licensed? > Can someone who has Python checkin rights volunteer to get it checked > in and built by the normal build process? If not, then I think it > should remain a separate download. I have an alternative Python spotlight importer, if anyone's interested. It's based on John Wiseman's Lisp Metatdata Importer and uses regular expressions, rather than PyObjC, making it much faster and leaner than the other one that's circulating out there (40x faster for my source directories). The importer and sources can be downloaded from http://homepage.mac.com/wtpollard/Software/FileSharing5.html I really don't care what anyone does with it. Tom From jrus at fas.harvard.edu Sat Apr 22 00:08:23 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 18:08:23 -0400 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: <4449442B.6050903@fas.harvard.edu> References: <4449442B.6050903@fas.harvard.edu> Message-ID: <444957D7.4040007@fas.harvard.edu> Bob Ippolito wrote: > Jacob Rus wrote: >> * Do we want different icons for py2applet.app and BuildApplet.app? >> What exactly is the difference between these? > > BuildApplet isn't any good at creating self-contained applications. > py2applet is. py2app does not ship with Python. Ok, well neither of the apps has an icon yet, but I [updated][1] some of the icons. I think that the "applet" icon can be the default for applets created by BuildApplet, and the "generic python app" icon can be the default for apps created with py2app or py2applet. How does that sound? Is it possible to give py2app a default icon? -Jacob [1]: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png From bob at redivi.com Sat Apr 22 00:13:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 21 Apr 2006 15:13:51 -0700 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: <444957D7.4040007@fas.harvard.edu> References: <4449442B.6050903@fas.harvard.edu> <444957D7.4040007@fas.harvard.edu> Message-ID: <94EF06E2-02F0-425C-9D83-57B5EC5B017B@redivi.com> On Apr 21, 2006, at 3:08 PM, Jacob Rus wrote: > Bob Ippolito wrote: >> Jacob Rus wrote: >>> * Do we want different icons for py2applet.app and >>> BuildApplet.app? >>> What exactly is the difference between these? >> >> BuildApplet isn't any good at creating self-contained applications. >> py2applet is. py2app does not ship with Python. > > Ok, well neither of the apps has an icon yet, but I [updated][1] > some of > the icons. I think that the "applet" icon can be the default for > applets created by BuildApplet, and the "generic python app" icon > can be > the default for apps created with py2app or py2applet. How does that > sound? Is it possible to give py2app a default icon? Yes, of course we can give py2app-built apps a default icon. py2applet should probably have a different icon though, so it's distinguishable from the apps it generates. When/if you come up with them, just shoot them over my way and I'll see about tossing them in! -bob From jrus at fas.harvard.edu Sat Apr 22 00:49:21 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 18:49:21 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> Message-ID: <6740C6D3-AE61-48A0-BE57-6865DE9CBDC1@fas.harvard.edu> has wrote: > The pen on the IDLE icon could use some subtle tweaking as it's > looking a bit flat, grey and lifeless, and a tad long and thin too... > > I've attached a rough version to give an idea. I might've taken > slightly too much off the barrel, and I've lost some highlights. It > was quick-n-dirty and I didn't have my tablet to hand, so don't > take it as gospel truth; you'll have to fine-tune your own version > yourself. :) I just grabbed the pencil off the internet, shortened it, and stuck it on. I should probably change the perspective, and make the changes you suggest. Maybe a different pencil would be a better model. I'll give it another shot, though other submissions would be great. :) > The only icon that isn't working yet is the generic icon: the > snakes and the pencil/brush/ruler are both battling to be center of > attention - the eye keeps bouncing uncomfortably back and forward > between the two - and the icon as a whole is a bit similar to the > IDLE icon. I agree. > One thing you might try is making the snakes appear like those on > the .dmg - lighter greyscale, perhaps without the glass effect - so > the overall look is closer to the Mac's standard generic > application icon and the original "A" is clearly dominant, but > still with an indication of its Pythonness. Alright, how is this: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 1.png Type: image/png Size: 20460 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/96bf3c8f/attachment-0001.png -------------- next part -------------- > If it still doesn't work then it'll be a case of coming up with a > more radical alternative. (I know folk don't want an AppleScript > applet clone, but certainly something as different to the generic > app icon as that is.) However, I think it probably will. I think that it'd be good to keep the applet icon for use with Build Applet.app, and let this icon be for icons created with py2app/ py2applet (I think that's in line with the traditional distinction between applets and apps as well, the former not really being standalone). Thanks for all the suggestions and encouragement. Keep the insight coming. -Jacob From janssen at parc.com Sat Apr 22 01:06:35 2006 From: janssen at parc.com (Bill Janssen) Date: Fri, 21 Apr 2006 16:06:35 PDT Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: Your message of "Fri, 21 Apr 2006 15:08:23 PDT." <444957D7.4040007@fas.harvard.edu> Message-ID: <06Apr21.160645pdt."58633"@synergy1.parc.xerox.com> > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png The egg icon looks odd to me. I think it's that the highlights on the logo don't seem to match the lighting direction on the egg. Or maybe the narrow end of the egg is just too wide. Not sure. Bill From mark at mophilly.com Sat Apr 22 01:39:38 2006 From: mark at mophilly.com (Mark Phillips) Date: Fri, 21 Apr 2006 16:39:38 -0700 Subject: [Pythonmac-SIG] osx 10.4 launch daemon Message-ID: <477B46EF-21DF-4DBE-BB48-67CDA11FD9C5@mophilly.com> I am setting up a server application that needs to be available 24/7. I would like to set this up to launch whenever the machine reboots. On RedHat 6.3 and Fedora Core, I modified rc.local and added a couple of cron jobs to handle the launch and housekeeping. I noted at developer.apple.com the change in osx 10.4 to launchd and launch daemons. Can anyone point me to doc's, forums, etc. dealing with this? What would be best are examples of plist files used in LIbrary/ LaunchDaemons that involve python. TIA, Mark Phillips Mophilly & Associates On the web at http://www.mophilly.com On the phone at 619 444-9210 From daniellord at mac.com Sat Apr 22 01:40:33 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 21 Apr 2006 16:40:33 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <6740C6D3-AE61-48A0-BE57-6865DE9CBDC1@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <6740C6D3-AE61-48A0-BE57-6865DE9CBDC1@fas.harvard.edu> Message-ID: <8D22485C-0E9E-413E-ACFD-4ABA83694E5C@mac.com> As for applet icons. How about taking a different tack such as a variation on the icon used for Applescript applications: After all, a p2app application is still a script deep down. -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedGraphic.tiff Type: image/tiff Size: 6448 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/f88afd9c/attachment.tiff From jrus at fas.harvard.edu Sat Apr 22 01:55:34 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 19:55:34 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <8D22485C-0E9E-413E-ACFD-4ABA83694E5C@mac.com> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <6740C6D3-AE61-48A0-BE57-6865DE9CBDC1@fas.harvard.edu> <8D22485C-0E9E-413E-ACFD-4ABA83694E5C@mac.com> Message-ID: Daniel Lord wrote: > As for applet icons. How about taking a different tack such as a > variation on the icon used for Applescript applications: After > all, a p2app application is still a script deep down. I was thinking along the lines of the "Generic Java Application" [icon][1]. I think it's useful to visually distinguish between applets made with Applet Builder.app, and those made with py2app. The py2app apps should hopefully be much more like regular OS X applications. The icon is more about what the thing can do for me than what it is deep down, IMO. But what did you have in mind for an "variation" applet icon? Feel free to mock something up yourself using my [photoshop file][2], or bounce specific ideas along. -Jacob [1]: http://hcs.harvard.edu/~jrus/python/misc-icons.png [2]: http://hcs.harvard.edu/~jrus/python/python-icons.psd From jrus at fas.harvard.edu Sat Apr 22 01:57:45 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 19:57:45 -0400 Subject: [Pythonmac-SIG] osx 10.4 launch daemon In-Reply-To: <477B46EF-21DF-4DBE-BB48-67CDA11FD9C5@mophilly.com> References: <477B46EF-21DF-4DBE-BB48-67CDA11FD9C5@mophilly.com> Message-ID: <44497179.7010404@fas.harvard.edu> Mark Phillips wrote: > I am setting up a server application that needs to be available 24/7. > I would like to set this up to launch whenever the machine reboots. > On RedHat 6.3 and Fedora Core, I modified rc.local and added a couple > of cron jobs to handle the launch and housekeeping. I noted at > developer.apple.com the change in osx 10.4 to launchd and launch > daemons. > > Can anyone point me to doc's, forums, etc. dealing with this? What > would be best are examples of plist files used in LIbrary/ > LaunchDaemons that involve python. The best way IMO to figure out launchd is to fire up the open-source [Lingon][1], a great little GUI app for modifying launchd plists. -Jacob [1]: http://lingon.sourceforge.net/ From kevin at macosx.com Sat Apr 22 03:22:44 2006 From: kevin at macosx.com (kevin parks) Date: Fri, 21 Apr 2006 21:22:44 -0400 Subject: [Pythonmac-SIG] spaces In-Reply-To: References: Message-ID: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> please god, no... grrr.... i hate escaping spaces in the terminal. double grr... On Apr 21, 2006, at 4:44 PM, pythonmac-sig-request at python.org wrote: > 4. Let's add some spaces in the names of things like PythonIDE.app, > BuildApplet.app, PythonLauncher.app and PackageManager.app. From bob at redivi.com Sat Apr 22 03:39:20 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 21 Apr 2006 18:39:20 -0700 Subject: [Pythonmac-SIG] spaces In-Reply-To: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> References: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> Message-ID: <4A047940-271E-4FCE-BC66-FD70BDD49E26@redivi.com> Since these are GUI apps, there's little use for them from the terminal.. beyond open -a "Build Applet" or whatever. I'm -0 because these aren't really all that visible anyway and it just doesn't seem like a real win. BuildApplet will go away eventually, and PythonLauncher is rarely ever touched directly. Ever hear of tab completion? :) -bob On Apr 21, 2006, at 6:22 PM, kevin parks wrote: > please god, no... grrr.... i hate escaping spaces in the terminal. > double grr... > > > > On Apr 21, 2006, at 4:44 PM, pythonmac-sig-request at python.org wrote: > >> 4. Let's add some spaces in the names of things like PythonIDE.app, >> BuildApplet.app, PythonLauncher.app and PackageManager.app. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jrus at fas.harvard.edu Sat Apr 22 03:44:50 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 21:44:50 -0400 Subject: [Pythonmac-SIG] spaces In-Reply-To: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> References: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> Message-ID: <44498A92.3020406@fas.harvard.edu> kevin parks wrote: > On Apr 21, 2006, at 4:44 PM, Jacob Rus wrote: > >> 4. Let's add some spaces in the names of things like PythonIDE.app, >> BuildApplet.app, PythonLauncher.app and PackageManager.app. > > please god, no... grrr.... i hate escaping spaces in the terminal. > double grr... Why would you ever need Python Launcher or Build Applet.app from the shell? The point of them is that they do drag-n-drop. And names with no spaces are ugly and unmaclike. -Jacob From kevin at macosx.com Sat Apr 22 03:51:48 2006 From: kevin at macosx.com (kevin parks) Date: Fri, 21 Apr 2006 21:51:48 -0400 Subject: [Pythonmac-SIG] spaces In-Reply-To: <4A047940-271E-4FCE-BC66-FD70BDD49E26@redivi.com> References: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> <4A047940-271E-4FCE-BC66-FD70BDD49E26@redivi.com> Message-ID: On Apr 21, 2006, at 9:39 PM, Bob Ippolito wrote: > I'm -0 because these aren't really all that visible anyway and it just > doesn't seem like a real win. BuildApplet will go away eventually, > and PythonLauncher is rarely ever touched directly. true enough.. on these 2 in particular.. but one way i get docs to launch in various apps is to use open -a in the terminal.. Especially on media files & text files that get opened & worked on in a dozen or so apps. > Ever hear of tab completion? :) yeah, and every so often it actually works for me if i get lucky and the names are very distinct. without it i would die.. but if you have 5 things that start with the word Python in the same directory even tab completion is gonna make you batty. Python Launcher Python Funnybiz.app Python YoMama.app. Python README.txt The world isn't gonna end but i am still 100% -0 on this proposal... -kp-- From jrus at fas.harvard.edu Sat Apr 22 05:00:22 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Fri, 21 Apr 2006 23:00:22 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448E8B1.90704@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> Message-ID: <44499C46.4080402@fas.harvard.edu> Jacob Rus wrote: > How's this then: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png Alright, 2 or 3 of the icons have since been updated, and that picture is new and improved. Are there any more suggested tweaks, or are the icons done so far ready to sail? Specifically, what do people think of the "generic application" icon as a default for apps created by py2app/py2applet? Also, is the pencil for the IDLE.app icon now okay, or can it still use work? The icons still needing to be done are one for py2applet, and one for BuildApplet.app. I'm thinking both of these can be stuffit-esque grinders, or similar, one with the "applet" icon coming out the bottom, and the other with the "generic app" icon coming out the bottom, and with python scripts going in the top. -Jacob From spe.stani.be at gmail.com Sat Apr 22 05:16:22 2006 From: spe.stani.be at gmail.com (SPE Stani's Python Editor) Date: Sat, 22 Apr 2006 05:16:22 +0200 Subject: [Pythonmac-SIG] help needed with py2app for self updating application Message-ID: <2078a7ad0604212016s51e75321ga225ef7c9d1547b3@mail.gmail.com> Hi, I need to do my first experiment with py2app. I creating a GUI program with wxPython which will be distributed for Mac and Windows. The audience of the program is not technical at all (eg they've never heard about Python), so everything should go automatically. The program should be able to update itself and to update its database (collection of .txt files). These are two separated things and don't happen simultaneously. I thought of the following: - seperate the code which will be updated and zip it to use a zipimport - zip the .txt files These files can then be downloaded (urllib or so) and if the download has completed succesfully, replace their old files. For the updated python code it is necessary to restart the program for the database not. These questions arise: - I have Python2.4, wxPython2.6.3, OS X 10.4 Will it run on other versions of OS X? If not will a version compiled on OS X 10.3 run on OS X 10.4 or do I need to provide a file for every OS X version? - can a zipimport be life replaced if it doesn't require root permissions (I would guess so) - do I have to declare something special for wxPython? - what is at the moment the most common zip format for Mac? zip, tar.gz, stuffit, ...? - how can I bundle a zipimport file with py2app? Let say this is the folder layout of the program: application.py code.zip (contains main.py, ui.py, etc..) * data.zip (contains .txt files) * other files (preferably bundled but not necessary) such as the wxPython libraries and whatever py2app will want to include (* means should be remote updatable/synchronizable) application.py is just a dummy file which calls code.main.main() Should I declare code.zip as a data file or as a python package? Of course it would be nice if someone be so kind to suggest a simple setup.py recipee for this... Thanks in advance, Stani -- http://pythonide.stani.be http://pythonide.stani.be/screenshots http://pythonide.stani.be/manual/html/manual.html From daniellord at mac.com Sat Apr 22 05:21:38 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 21 Apr 2006 20:21:38 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44499C46.4080402@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <44499C46.4080402@fas.harvard.edu> Message-ID: <6DFF0359-9917-428D-A562-4F9B5468494E@mac.com> On Apr 21, 2006, at 20:00, Jacob Rus wrote: > Jacob Rus wrote: >> How's this then: >> >> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > > Alright, 2 or 3 of the icons have since been updated, and that picture > is new and improved. Are there any more suggested tweaks, or are the > icons done so far ready to sail? Specifically, what do people > think of > the "generic application" icon as a default for apps created by > py2app/py2applet? Also, is the pencil for the IDLE.app icon now okay, > or can it still use work? > > The icons still needing to be done are one for py2applet, and one for > BuildApplet.app. I'm thinking both of these can be stuffit-esque > grinders, or similar, one with the "applet" icon coming out the > bottom, > and the other with the "generic app" icon coming out the bottom, and > with python scripts going in the top. > > -Jacob I like them and I'll take them just as they are.. Thanks for all your hard work and putting up with all the detailed critiques. Your patience is exceeded only by your talent. Thank you for contributing to the Mac Python community. Daniel From spe.stani.be at gmail.com Sat Apr 22 05:39:24 2006 From: spe.stani.be at gmail.com (SPE Stani's Python Editor) Date: Sat, 22 Apr 2006 05:39:24 +0200 Subject: [Pythonmac-SIG] help needed with py2app for self updating application In-Reply-To: <2078a7ad0604212016s51e75321ga225ef7c9d1547b3@mail.gmail.com> References: <2078a7ad0604212016s51e75321ga225ef7c9d1547b3@mail.gmail.com> Message-ID: <2078a7ad0604212039r541be30dl5827f954e7774e6f@mail.gmail.com> One more question which which versions of python and wxPython ship OS X 10.2, 10.3 and any version which is still common? (For 10.4 it is python2.3.5 and wxPython2.5.3.1 (check with import wx;wx.VERSION). Stani -- http://pythonide.stani.be http://pythonide.stani.be/screenshots http://pythonide.stani.be/manual/html/manual.html From berkowit at silcom.com Sat Apr 22 06:08:15 2006 From: berkowit at silcom.com (Paul Berkowitz) Date: Fri, 21 Apr 2006 21:08:15 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <8D22485C-0E9E-413E-ACFD-4ABA83694E5C@mac.com> Message-ID: On 4/21/06 4:40 PM, "Daniel Lord" wrote: > As for applet icons. How about taking a different tack such as a > variation on the icon used for Applescript applications: > After all, a p2app application is still a script deep down. NOT a good idea. That icon belongs to AppleScript, and Apple. You're really asking for it if you upset the AppleScript faithful... ;-) -- Paul Berkowitz From daniellord at mac.com Sat Apr 22 07:13:14 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 21 Apr 2006 22:13:14 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <31233E1C-7140-4AD3-95E8-D421687D76BA@mac.com> On Apr 21, 2006, at 21:08, Paul Berkowitz wrote: > On 4/21/06 4:40 PM, "Daniel Lord" wrote: > >> As for applet icons. How about taking a different tack such as a >> variation on the icon used for Applescript applications: >> After all, a p2app application is still a script deep down. > > NOT a good idea. That icon belongs to AppleScript, and Apple. > You're really > asking for it if you upset the AppleScript faithful... ;-) Yeah. What was I thinking--they are already sore that we have regex, native extensibility that actually doable by mere mortal, arbitrary precision arithmetic, robust file handling, consistent implementation, advanced abstract data types, powerful libraries and modules, multi-platform support, an Objective-C bridge, cooler (or soon to be) icons and much, much more... and they don't. No point in poking them with a sharp stick eh? From daniellord at mac.com Sat Apr 22 07:17:09 2006 From: daniellord at mac.com (Daniel Lord) Date: Fri, 21 Apr 2006 22:17:09 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! Message-ID: <3D005B11-5414-4B6E-A858-BBFE61CC5823@mac.com> The analog of a single gene pool in nature has come to pass for arbitrary precison math (APM) for OS X (native not Python). GMP is 'it' for APM as far as I can tell unless I want to write my own. And GMP doesn't compile on Mac-tel and won't for some time: The current release is 4.2, released 2006-03-26. It fixes all bugs found in 4.1.4, as well as several portability problems. It also adds several new features. Note that we chose not to work around all new GCC bugs in this release. Never forget to do a make check after building the library to make likely it was not miscompiled! Issues with GMP 4.2: Miscompilation on several platforms using several different compilers. Remember to run make check! GMP does not build on MacInteltoch machines. Since Apple uses their own, creative assembly syntax, it is not trivial to fix this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060421/d588201b/attachment.htm From bob at redivi.com Sat Apr 22 10:59:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 22 Apr 2006 01:59:23 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: <3D005B11-5414-4B6E-A858-BBFE61CC5823@mac.com> References: <3D005B11-5414-4B6E-A858-BBFE61CC5823@mac.com> Message-ID: On Apr 21, 2006, at 10:17 PM, Daniel Lord wrote: > The analog of a single gene pool in nature has come to pass for > arbitrary precison math (APM) for OS X (native not Python). > GMP is 'it' for APM as far as I can tell unless I want to write my > own. > And GMP doesn't compile on Mac-tel and won't for some time: You can get arbitrary precision math from the decimal module if you really need it. It's not fast, but it's there. -bob From ronaldoussoren at mac.com Sat Apr 22 14:38:12 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 22 Apr 2006 14:38:12 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <4448E8B1.90704@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> Message-ID: <40A738C5-6CD8-45D4-847F-0C0B313B5491@mac.com> On 21-apr-2006, at 16:14, Jacob Rus wrote: > Zachery Bir wrote: >> glenn andreas wrote: >>> A shaded egg with a python logo decal seems good... >> >> +1 > > How's this then: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png These icons look great many thanks to you and anyone else on the list that was involved with their creation. What's the difference between generic application.app and applet.app? I wouldn't make a distintion between applets (what buildapplet builds) and applications (what py2app builds) and prefer the generic application icon for both of them. The only thing that seems to be missing is an icon for 'Build Applet'. Now that we're almost there it is time to be annoying ;-). Are you willing to donate these icons to the PSF (Python Software Foundation), are at least write down the terms in which these icons may be used? I've sent a message to python-dev to ask what is needed to get new icons included into the python distribution. Ronald > > -Jacob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Sat Apr 22 14:55:16 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 22 Apr 2006 14:55:16 +0200 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: <4449442B.6050903@fas.harvard.edu> References: <4449442B.6050903@fas.harvard.edu> Message-ID: On 21-apr-2006, at 22:44, Jacob Rus wrote: > While we're adding a bunch of icons to Mac Python, and editing > Info.plist files, and so on, I think we might as well make a few other > changes: > > 1. If it doesn't already, I think Mac Python should ship with a > python > spotlight importer (I got one somewhere else, but should be > default) For the moment anything in the official installer needs to be part of the official python.org distribution. Anything else needs to be installed seperately for now. That may change in the future, but not until I've had time to think about the issues and write down a proposal about what to include and what not. > > 2. Let's export some UTI's for .pyc/.pyo files and .egg files (maybe > public.python-bytecode and public.python-egg or something, or > maybe > they need to be org.python.python-bytecode, etc.) At least some of these are part of the OS. It can't hurt to add these UTIs to the Info.plist for IDLE of course. > > 3. Let's make sure that python files get useful "kMDItemKind" names. > Right now, if I associate one with PythonIDE.app, I get "plain > text > file" for .pyc, and "Document" for .pyo, which is not useful. That related to the spotlight importer. > > 4. Let's add some spaces in the names of things like PythonIDE.app, > BuildApplet.app, PythonLauncher.app and PackageManager.app. PythonIDE.app and PackageManager.app are deprecated and will not be included in future versions of the installer (or the current universal one for that matter). Adding a space to PythonLauncher and BuildApplet is a good idea. > > > Some other questions: > > * What's the difference between PythonIDE.app and IDLE.app? Should > they get different icons? Is one of them preferred to the > other? I > just use TextMate and iPython from terminal, so I don't really > know > what all they do. Ignore PythonIDE.app. > > * What exactly do python eggs do? Are they just extra modules > packaged up, or can you run them as standalone apps? They are packaged python libraries, basically a cross-platform alternative to .mpkg installer and simular to java's JAR files. > > * If the latter, how exactly do eggs differ from the applet's > created > by BuildApplet.app? Applets are applications, eggs are libraries. > > * Do we want different icons for py2applet.app and BuildApplet.app? > What exactly is the difference between these? I'm entertaining the thought of just dropping BuildApplet and advocating the use of py2applet instead. Until we actually drop BuildApplet we can use the same icon for py2applet and BuildApplet. > > Basically, I'm confused by the seemingly endless official or > semi-official ways to package up python code and edit it on the Mac. > Are any of these deprecated? * PythonLauncher: double-click on .py/.pyw files to run them * IDLE: python IDE (cross-platform using tkinter) * py2applet: build standalone applications using drag&drop. * BuildApplet: simular to py2applet, but older PythonIDE is the MacOS9 IDE for python, PackageManager is an attempt at an easy to use tool for installing additinal packages. Both are no longer maintained and are deprecated. Now that we (almost) have new icons it would be great if someone could have a look at IDLE and at the very least writes down what could be done to make it a better OSX citizen. Actual patches would of course even be better. Please keep in mind that IDLE is a cross-platform application using tkinter and that it is probably virtually impossible to make it a really great OSX application. Ronald > > -Jacob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Sat Apr 22 14:57:43 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 22 Apr 2006 14:57:43 +0200 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: References: <4449442B.6050903@fas.harvard.edu> <0DB5538C-1901-457E-BF45-B8BE41BA674D@ulaluma.com> Message-ID: <14FDB8E2-D934-45FF-B4FA-9F377EC251E9@mac.com> On 21-apr-2006, at 23:56, Tom Pollard wrote: > > I really don't care what anyone does with it. That's not good enough of inclusion in the distribution ;-). Ronald P.S. I haven't looked at this yet > > Tom > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Sat Apr 22 15:08:07 2006 From: hengist.podd at virgin.net (has) Date: Sat, 22 Apr 2006 14:08:07 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <44499C46.4080402@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <44499C46.4080402@fas.harvard.edu> Message-ID: Jacob Rus wrote: >>http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > >[...]what do people think of the "generic application" icon as a default for apps created by py2app/py2applet? Definitely getting there. Though the top snake could do with being a bit lighter. The icon is, first and foremost, a statement that "this is an application"; the snake logo is just a subtle hint to say, "by the way, it's built in Python". The eye should be drawn to the "A" first, then pick up on the subtle 'hint' behind it, and finally come to rest on the "A" again. Right now the top snake is about 40% grey and still fighting with the "A" for the eye's attention; I'd take it to 30% (I've tried it here) and maybe knock 2% off the bottom snake just to preserve noticeable contrast between them. > Also, is the pencil for the IDLE.app icon now okay, or can it still use work? Looks perfect. (Now we just need IDLE's insides to look as beautiful as its outside - perhaps in 2.6...;) >The icons still needing to be done are one for py2applet, and one for BuildApplet.app. I'm thinking both of these can be stuffit-esque grinders, or similar, one with the "applet" icon coming out the bottom, and the other with the "generic app" icon coming out the bottom, and with python scripts going in the top. Sounds fine - I have no better ideas. The grinder is a bit of a clich?, but I don't see this as any bad thing here: you want its purpose to be obvious to users, and folks are used to interpreting the grinder symbol as 'format converter'. ... One last thing: try the egg with the logo positioned vertically. Having the egg itself on the diagonal works well, but putting the snakes on the same diagonal makes them hard to read [1], and causes the strong visual bottom-left-to-top-right diagonal line to completely dominate the entire image. Putting the logo vertically (I've tried it here) makes it easy to identify and the contrast of diagonal and vertical gives the whole thing a bit more of a 'jaunty' look, rather than just looking a bit drunk. Plus it improves consistency with the rest of the icon set (where the snakes are always the same vertical orientation, either literally or implied by perspective). HTH has [1] i.e. It's not like when they're shown in perspective, when they're only 10 degrees off the vertical and you've got the rectangular 'paper' framing it to remind you of up/down/left/right. Rotated 45 degrees it really starts to look like a different "X" shaped symbol rather than the "+" shape it's meant to be. -- http://freespace.virgin.net/hamish.sanderson/ From aleaxit at gmail.com Sat Apr 22 18:50:31 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Sat, 22 Apr 2006 09:50:31 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: References: Message-ID: On Apr 22, 2006, at 1:59 AM, pythonmac-sig-request at python.org wrote: > No arbitrary precison math on Mac-tel say it ain't so! It ain't so. > The analog of a single gene pool in nature has come to pass for > arbitrary precison math (APM) for OS X (native not Python). > GMP is 'it' for APM as far as I can tell unless I want to write my > own. I believe intel also has libraries (they offered them for beta at some point, but I didn't follow through on that), but that's not the key point. > And GMP doesn't compile on Mac-tel and won't for some time: > > The current release is 4.2, released 2006-03-26. It fixes all bugs > found in 4.1.4, as well as several portability problems. It also > adds several new features. Note that we chose not to work around > all new GCC bugs in this release. Never forget to do a make check > after building the library to make likely it was not miscompiled! > > Issues with GMP 4.2: > > Miscompilation on several platforms using several different > compilers. Remember to run make check! > GMP does not build on MacInteltoch machines. Since Apple uses their > own, creative assembly syntax, it is not trivial to fix this. Nope. The current maintainer of GMP is apparently Apple-hostile AND by his own admission no expert on autoconf/libtools and similar blackmagic -- and apparently unable to admit it when he's dead wrong. Apple's assembly syntax is totally irrelevant here. The reason make check fails is Apple's creative *ld semantics*: an object file inside a library file is NOT brought in if the only symbols it satisfies are DATA ones. Make check makes an executable with unresolved symbols because of this strange "optimization" in Apple's ld (I dimly remember from the past other linkers with this kind of strangeness), that's all. Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp 4.2 which I had sent him -- it's a TINY patch (aparts from comments explaining why it exists, it's just *THREE* bedraggled lines...!!!): http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ patch-0001.obj GMP's maintainer rejected it as "THis is a too ugly patch for inclusion in GMP." (!!!). Anyway, download and apply that patch, and make check passes with flying colors. Then, I had the deadline for the 2nd ed of the Nutshell, then a week's vacation at the Grand Canyon, and have been catching up on things, so I haven't done any further followthrough - yet. Once this idiocy is solved, there is another problem: I STILL can't link gmpy.so beause I can't make libgmp.a to build properly for linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS contents): brain:~/alex/gmpy alex$ python setup.py build_ext -i running build_ext building 'gmpy' extension creating build/temp.macosx-10.4-fat-2.4 creating build/temp.macosx-10.4-fat-2.4/src gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ gmpy.o -L/usr/local/lib -lgmp -o gmpy.so /usr/bin/ld: for architecture i386 /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) /usr/bin/ld: for architecture ppc /usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (can't load from it) collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or directory) error: command 'gcc' failed with exit status 1 brain:~/alex/gmpy alex$ Don't worry about the failure on the ppc branch, that's just because the .a is not universal and would presumably result in making a non- universal .so -- could be fixed later. I've tried with a nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away. It's yet another TODO item, with lower priority than "the biggie" below. The biggie is the like: /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation entries in non-writable section (__TEXT,__text) I've tried ("manually", i.e. with CFLAGS=... on the ./configure of GMP 4.2) various -f flags to try to make libgmp.a PIC (which I assume is what's the error's complaining about?) -- -fPIC, -fno-common, others; no luck so far. I've explored every mention on the web of this errorcode about "local relocation entries in non-writable section", but, no luck so far. It may be trivial for people more deeply familiar with Apple's toolchain (ld most of all) than I am, and I do have several at work I can consult on that, but, as I said, I didn't yet have much time for followup. Once I understand how to fix it with CFLAGS=..., then I must understand how to embed the fix via autoconf/configure/libtools, which is scary (MY knowledge of that part being very scarce). Finally, there will be the political fight to make the maintainer accept the resulting patches. BTW, the biggie is fully reproducible on PPC Macs, too, so GMP 4.2 builds on those in a state which still doesn't let gmpy.so link (it may feel less urgent just because GMP 4.1.* does build fine;-). I've even tried using 4.1.* on mac-intel but it breaks in different ways and it seems to me that there's no point fighting with that one, I might well focus my limited time and energy on 4.2!-) BTW**2, any advice from ANYbody with better grasp of Apple's ld, the significance of -bundle vs -dylib, autoconf and friends, etc, etc, will be most welcome!-) Alex From charles.hartman at conncoll.edu Sat Apr 22 19:01:34 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 22 Apr 2006 13:01:34 -0400 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: References: Message-ID: <70E4F205-488D-4B8B-A01E-4619A25B6DA6@conncoll.edu> A new edition of the Nutshell? That is great news! That's the book I go back to, out of a dozen I've got, most often. Updated for 2.5 perhaps? Charles Hartman On Apr 22, 2006, at 12:50 PM, Alex Martelli wrote: > Then, I had the deadline for the 2nd ed of the Nutshell, then a > week's vacation at the Grand Canyon, and have been catching up on -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060422/2de2f097/attachment.html From aleaxit at gmail.com Sat Apr 22 19:21:28 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Sat, 22 Apr 2006 10:21:28 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: <70E4F205-488D-4B8B-A01E-4619A25B6DA6@conncoll.edu> References: <70E4F205-488D-4B8B-A01E-4619A25B6DA6@conncoll.edu> Message-ID: On Apr 22, 2006, at 10:01 AM, Charles Hartman wrote: > A new edition of the Nutshell? That is great news! That's the book > I go back to, out of a dozen I've got, most often. Updated for 2.5 > perhaps? Focused on 2.4 (and pointing out what 2.4 added to 2.3, so that by subtraction it should also be quite usable for 2.3) -- but also with as much 2.5 info as I could ascertain given 2.5's alpha-1 stage. (e.g., debates on whether eggs/easy_install/setuptools are going into 2.5 are still raging on python-dev; and the fine points of the new `with' statement are still not settled; it's quite possible that the book's coverage of such issues ended up wrong!-). Alex From daniellord at mac.com Sat Apr 22 19:38:04 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 22 Apr 2006 10:38:04 -0700 Subject: [Pythonmac-SIG] HFS versus POSIX paths (changed from fixing the documentation) In-Reply-To: References: <06Apr18.172318pdt.58633@synergy1.parc.xerox.com> <76BADD25-40A2-4EC9-94C6-DF2FC315062B@mac.com> <3298923F-88EA-4569-85B6-4A775AA5077C@mac.com> <04DE8F64-CF89-433B-A002-1203C738AB67@mac.com> Message-ID: <65D1D47A-0077-47FC-B7B5-80E9A61611BF@mac.com> On Apr 21, 2006, at 3:06, has wrote: > Daniel Lord wrote: > >> I am writing an app combining excel and python/appscript to fetch >> quotes from the web and value stock portfolios . >> But I give up on using appscript with Excel--some things just >> don't work because I think the terminology is seriously warped if >> no broken. Applescriptworks but appscript doesn't. > > Please send examples of where breakage occurs so I can figure out why. I'll get around to this in a little while--I kind of shelved that project after I got tired of using hacks to bring Excel 'to heel' > >> I instead build a text Applescript from strings and use popen2 to >> invoke osascript like this example which reads in the stock >> symbols from a named range in an excel spreadsheet: > > The osax module provides a runscript() function that's easier to > use if you're just wanting to pass in parameters. (It's a simple > wrapper around Standard Additions' 'run script' command.) > > Or I can supply a rough version of osawrapper, which is a high- > level wrapper around CarbonX.OSA; gives you much more power/ > flexibility when using AS from Python. Just ask. Sure. Maybe I'll see if I can improve on it given you said it was rough. I need to learn a lot more about OSA, AE, etc. first though. Daniel From daniellord at mac.com Sat Apr 22 20:03:26 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 22 Apr 2006 11:03:26 -0700 Subject: [Pythonmac-SIG] New wiki entry on Universal libraries and extensions Message-ID: <3247ECA0-5401-43D1-A9D4-A6B74A88C588@mac.com> I made good on my threat and wrote it up. Wiki's are famous for providing misinformation because anyone can write to them regardless of the veracity of their exposition (e.g. a newb like me). So, if someone doesn't mind, please review my content and let's get anything incorrect fixed. http://pythonmac.org/wiki/UniversalLibrariesAndExtensions Daniel From daniellord at mac.com Sat Apr 22 20:23:33 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 22 Apr 2006 11:23:33 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: References: Message-ID: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> On Apr 22, 2006, at 9:50, Alex Martelli wrote: > >> And GMP doesn't compile on Mac-tel and won't for some time: >> >> The current release is 4.2, released 2006-03-26. It fixes all bugs >> found in 4.1.4, as well as several portability problems. It also >> adds several new features. Note that we chose not to work around >> all new GCC bugs in this release. Never forget to do a make check >> after building the library to make likely it was not miscompiled! >> >> Issues with GMP 4.2: >> >> Miscompilation on several platforms using several different >> compilers. Remember to run make check! >> GMP does not build on MacInteltoch machines. Since Apple uses their >> own, creative assembly syntax, it is not trivial to fix this. > Nope. The current maintainer of GMP is apparently Apple-hostile AND > by his own admission no expert on autoconf/libtools and similar > blackmagic -- and apparently unable to admit it when he's dead wrong. > > Apple's assembly syntax is totally irrelevant here. The reason make > check fails is Apple's creative *ld semantics*: an object file inside > a library file is NOT brought in if the only symbols it satisfies are > DATA ones. > Make check makes an executable with unresolved symbols because of > this strange "optimization" in Apple's ld (I dimly remember from the > past other linkers with this kind of strangeness), that's all. > > Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp 4.2 > which I had sent him -- it's a TINY patch (aparts from comments > explaining why it exists, it's just *THREE* bedraggled lines...!!!): > > http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ > patch-0001.obj Thanks Alex! I'll give this a try. I have to believe there is a way around this--we just need to find the right person at Apple. I know someone who might know someone... > > GMP's maintainer rejected it as "THis is a too ugly patch for > inclusion in GMP." (!!!). Given the importance of scientific and academic computing to Apple, someone at Apple should hear about this unacceptable and behavior and deal with it 'appropriately'. If not, I think Karl Rove has a little time on his hands before the election ;-) Volunteering for the role of maintainer is a role of stewardship that requires a reticence in the face of criticism and histrionics as well as a dedication to serve the community. But sometimes unfortunately, it is done more out of ego, a need to control, and a desire to mete out petty revenge on mere mortals from on high. If that's the case here, it would be a real shame--let's hope its not. Perhaps we just misunderstand his position and Apple can help with detente. I'll try to do what I can to help with gmpy though the inner workings of ld are probably too arcane and labyrinthine for me. > Anyway, download and apply that patch, and make check passes with > flying colors. > > > Then, I had the deadline for the 2nd ed of the Nutshell, then a > week's vacation at the Grand Canyon, and have been catching up on > things, so I haven't done any further followthrough - yet. > > Once this idiocy is solved, there is another problem: I STILL can't > link gmpy.so beause I can't make libgmp.a to build properly for > linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS > contents): > > brain:~/alex/gmpy alex$ python setup.py build_ext -i > running build_ext > building 'gmpy' extension > creating build/temp.macosx-10.4-fat-2.4 > creating build/temp.macosx-10.4-fat-2.4/src > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - > fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - > fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ > Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c > src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g > -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ > gmpy.o -L/usr/local/lib -lgmp -o gmpy.so > /usr/bin/ld: for architecture i386 > /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation > entries in non-writable section (__TEXT,__text) > /usr/bin/ld: for architecture ppc > /usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7, > architecture i386) does not match cputype (18) for specified -arch > flag: ppc (can't load from it) > collect2: ld returned 1 exit status > lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or > directory) > error: command 'gcc' failed with exit status 1 > brain:~/alex/gmpy alex$ > > Don't worry about the failure on the ppc branch, that's just because > the .a is not universal and would presumably result in making a non- > universal .so -- could be fixed later. I've tried with a > nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away. > It's yet another TODO item, with lower priority than "the biggie" > below. > > The biggie is the like: > > /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation > entries in non-writable section (__TEXT,__text) > > I've tried ("manually", i.e. with CFLAGS=... on the ./configure of > GMP 4.2) various -f flags to try to make libgmp.a PIC (which I assume > is what's the error's complaining about?) -- -fPIC, -fno-common, > others; no luck so far. I've explored every mention on the web of > this errorcode about "local relocation entries in non-writable > section", but, no luck so far. > > It may be trivial for people more deeply familiar with Apple's > toolchain (ld most of all) than I am, and I do have several at work I > can consult on that, but, as I said, I didn't yet have much time for > followup. Once I understand how to fix it with CFLAGS=..., then I > must understand how to embed the fix via autoconf/configure/libtools, > which is scary (MY knowledge of that part being very scarce). > Finally, there will be the political fight to make the maintainer > accept the resulting patches. > > BTW, the biggie is fully reproducible on PPC Macs, too, so GMP 4.2 > builds on those in a state which still doesn't let gmpy.so link (it > may feel less urgent just because GMP 4.1.* does build fine;-). I've > even tried using 4.1.* on mac-intel but it breaks in different ways > and it seems to me that there's no point fighting with that one, I > might well focus my limited time and energy on 4.2!-) > > BTW**2, any advice from ANYbody with better grasp of Apple's ld, the > significance of -bundle vs -dylib, autoconf and friends, etc, etc, > will be most welcome!-) > > > Alex > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jrus at fas.harvard.edu Sat Apr 22 20:36:09 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Sat, 22 Apr 2006 14:36:09 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <40A738C5-6CD8-45D4-847F-0C0B313B5491@mac.com> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <40A738C5-6CD8-45D4-847F-0C0B313B5491@mac.com> Message-ID: Ronald Oussoren wrote: >> 3. Let's make sure that python files get useful "kMDItemKind" >> names. >> Right now, if I associate one with PythonIDE.app, I get >> "plain text >> file" for .pyc, and "Document" for .pyo, which is not useful. > That related to the spotlight importer. No, it's related to the CFBundleTypeName declared in the Info.plist of the application assigned to them. > Now that we (almost) have new icons it would be great if someone > could have > a look at IDLE and at the very least writes down what could be done > to make > it a better OSX citizen. Actual patches would of course even be > better. > > Please keep in mind that IDLE is a cross-platform application using > tkinter and that it is probably virtually impossible to make it a > really great OSX application. Can we start by using cmd-q, cmd-s, cmd-v, etc. as the keyboard shortcuts? The ctrl- versions are confusing, and also override useful text shortcuts like ^a to go to the beginning of the line, etc. Also, opt-/, opt-g, opt-shift-s, and opt-m are completely worthless as shortcuts because they get overridden as ?, ?, ?, and ? before ever making it to the menus. Of course, that won't go /that/ far toward making IDLE work on Mac, but it's a start. > I wouldn't make a distintion between applets (what buildapplet > builds) and applications (what py2app builds) and prefer the > generic application icon for both of them. Okay, that's fine. > The only thing that seems to be missing is an icon for 'Build Applet'. Indeed. I'll try, but I'm not sure I'm up to drawing it. > Now that we're almost there it is time to be annoying ;-). Are you > willing to donate these icons to the PSF (Python Software > Foundation), are at least write down the terms in which these icons > may be used? I've sent a message to python-dev to ask what is > needed to get new icons included into the python distribution. I'd be glad to have the PSF use them for any purpose. Some sort of attribution would be nice too. What's the norm for these things? -Jacob From jrus at fas.harvard.edu Sat Apr 22 21:11:49 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Sat, 22 Apr 2006 15:11:49 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <44499C46.4080402@fas.harvard.edu> Message-ID: <370E7F79-A1DC-420C-B68A-F8B30439C317@fas.harvard.edu> has wrote: > Definitely getting there. Though the top snake could do with being > a bit lighter. The icon is, first and foremost, a statement that > "this is an application"; the snake logo is just a subtle hint to > say, "by the way, it's built in Python". The eye should be drawn to > the "A" first, then pick up on the subtle 'hint' behind it, and > finally come to rest on the "A" again. > > Right now the top snake is about 40% grey and still fighting with > the "A" for the eye's attention; I'd take it to 30% (I've tried it > here) and maybe knock 2% off the bottom snake just to preserve > noticeable contrast between them. > ... > One last thing: try the egg with the logo positioned vertically. > Having the egg itself on the diagonal works well, but putting the > snakes on the same diagonal makes them hard to read [1], and causes > the strong visual bottom-left-to-top-right diagonal line to > completely dominate the entire image. > > Putting the logo vertically (I've tried it here) makes it easy to > identify and the contrast of diagonal and vertical gives the whole > thing a bit more of a 'jaunty' look, rather than just looking a bit > drunk. Plus it improves consistency with the rest of the icon set > (where the snakes are always the same vertical orientation, either > literally or implied by perspective). Alright, I've tried those two changes: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png What do you think? From aleaxit at gmail.com Sat Apr 22 21:36:35 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Sat, 22 Apr 2006 12:36:35 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> References: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> Message-ID: On Apr 22, 2006, at 11:23 AM, Daniel Lord wrote: ... >> Apple's assembly syntax is totally irrelevant here. The reason make >> check fails is Apple's creative *ld semantics*: an object file inside >> a library file is NOT brought in if the only symbols it satisfies are >> DATA ones. ... >> http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ >> patch-0001.obj > > Thanks Alex! I'll give this a try. I have to believe there is a way > around this--we just need to find the right person at Apple. I know > someone who might know someone... OK, let's give it a try. But making 'make check' pass is secondary: we already have the tiny patch to GMP 4.2 to do so, getting it into GMP 4.2 itself is important (to help out others) but mostly a political fight (on which pressure from Apple might hinder as much as help!-). > I'll try to do what I can to help with gmpy though the inner > workings of ld are probably too arcane and labyrinthine for me. It's not just gmpy, but anything that needs to be linked as -bundle, whatever that means exactly. The workings of ld are slightly arcane -- I did already ask for advice from colleagues who I thought SHOULD know; for example, Matt Austern, who besides authoring "Generic programming and the STL" and shepherding library standards for the next generation of C++, led the gcc 4 group at Apple, focusing on many optimizations therefor... *he* easily admits that linking on MacOSX (as soon as dylibs, bundles, frameworks, and the interplay of their namespaces and constraints enters the picture) is something he never fully fathomed (no real need for him to delve into that, it appears). autoconf and friends are even scarier (to me, at least)...;-). Alex From hengist.podd at virgin.net Sat Apr 22 21:42:28 2006 From: hengist.podd at virgin.net (has) Date: Sat, 22 Apr 2006 20:42:28 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <370E7F79-A1DC-420C-B68A-F8B30439C317@fas.harvard.edu> References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <44499C46.4080402@fas.harvard.edu> <370E7F79-A1DC-420C-B68A-F8B30439C317@fas.harvard.edu> Message-ID: Jacob Rus wrote: >Alright, I've tried those two changes: >http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > >What do you think? Lovely. has -- http://freespace.virgin.net/hamish.sanderson/ From ronaldoussoren at mac.com Sat Apr 22 22:09:44 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 22 Apr 2006 22:09:44 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <40A738C5-6CD8-45D4-847F-0C0B313B5491@mac.com> Message-ID: <78662CC8-D80A-4735-BEE2-7E7A14725D01@mac.com> On 22-apr-2006, at 20:36, Jacob Rus wrote: > Ronald Oussoren wrote: >>> 3. Let's make sure that python files get useful "kMDItemKind" >>> names. >>> Right now, if I associate one with PythonIDE.app, I get >>> "plain text >>> file" for .pyc, and "Document" for .pyo, which is not useful. >> That related to the spotlight importer. > > No, it's related to the CFBundleTypeName declared in the Info.plist > of the application assigned to them. Mhmm, I should have researched that before writing my message. The Info.plist issue is fixable. > >> Now that we (almost) have new icons it would be great if someone >> could have >> a look at IDLE and at the very least writes down what could be >> done to make >> it a better OSX citizen. Actual patches would of course even be >> better. >> >> Please keep in mind that IDLE is a cross-platform application using >> tkinter and that it is probably virtually impossible to make it a >> really great OSX application. > > Can we start by using cmd-q, cmd-s, cmd-v, etc. as the keyboard > shortcuts? The ctrl- versions are confusing, and also override > useful text shortcuts like ^a to go to the beginning of the line, etc. > > Also, opt-/, opt-g, opt-shift-s, and opt-m are completely worthless > as shortcuts because they get overridden as ?, ?, ?, and ? before > ever making it to the menus. > > Of course, that won't go /that/ far toward making IDLE work on Mac, > but it's a start. Those changes are actually quite easy, IDLE has some configuration files that contain the key-bindings it uses. What bothers me most is the menu-bar and layout of some windows. > >> I wouldn't make a distintion between applets (what buildapplet >> builds) and applications (what py2app builds) and prefer the >> generic application icon for both of them. > > Okay, that's fine. > >> The only thing that seems to be missing is an icon for 'Build >> Applet'. > > Indeed. I'll try, but I'm not sure I'm up to drawing it. > >> Now that we're almost there it is time to be annoying ;-). Are you >> willing to donate these icons to the PSF (Python Software >> Foundation), are at least write down the terms in which these >> icons may be used? I've sent a message to python-dev to ask what >> is needed to get new icons included into the python distribution. > > I'd be glad to have the PSF use them for any purpose. Some sort of > attribution would be nice too. What's the norm for these things? I don't know. If send a message to python-dev and the PSF to ask about this. Ronald > > -Jacob > > From brendansimons at yahoo.ca Sat Apr 22 22:16:27 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat, 22 Apr 2006 16:16:27 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <83454243-C561-44ED-861E-7BF4EB34E70C@yahoo.ca> On 22-Apr-06, at 4:59 AM, pythonmac-sig-request at python.org wrote: > Date: April 21, 2006 11:00:22 PM EDT (CA) > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Jacob Rus wrote: >> How's this then: >> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > > Alright, 2 or 3 of the icons have since been updated, and that > picture is new and improved. Are there any more suggested tweaks, > or are the icons done so far ready to sail? Specifically, what do > people think of the "generic application" icon as a default for > apps created by py2app/py2applet? Also, is the pencil for the > IDLE.app icon now okay, or can it still use work? > > The icons still needing to be done are one for py2applet, and one > for BuildApplet.app. I'm thinking both of these can be stuffit- > esque grinders, or similar, one with the "applet" icon coming out > the bottom, and the other with the "generic app" icon coming out > the bottom, and with python scripts going in the top. > > -Jacob I like what you did with the idle pen, egg shadow, and generic app icons Jacob. Thanks again. For the build applet, if the grider icon doesn't work, what about the generic app icon self assembling from bits. Like this: http://www.flickr.com/photos/28928816 at N00/133016352/ Brendan -- Brendan Simons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060422/cec1be6c/attachment.htm From jrus at fas.harvard.edu Sat Apr 22 22:21:54 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Sat, 22 Apr 2006 16:21:54 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <46F9525A-8F44-4D5C-AB55-556AC3996A70@yahoo.ca> <68A01F6C-B3EB-416C-9D44-2012FE52636E@urbanape.com> <4448E8B1.90704@fas.harvard.edu> <44499C46.4080402@fas.harvard.edu> <370E7F79-A1DC-420C-B68A-F8B30439C317@fas.harvard.edu> Message-ID: <895392AA-E5B7-4A63-85C1-C258DD9E79E2@fas.harvard.edu> Jordan Krushen wrote: > +1 on everything so far, including the recent changes on the egg, but > the egg still looks odd to me.. it looks like it's sitting on its thin > end.. would it be possible to flip the ends of the egg? Alright, one more go with the egg icon. I agree, it did look a bit off: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png -Jacob From jrus at fas.harvard.edu Sat Apr 22 22:28:35 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Sat, 22 Apr 2006 16:28:35 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <83454243-C561-44ED-861E-7BF4EB34E70C@yahoo.ca> References: <83454243-C561-44ED-861E-7BF4EB34E70C@yahoo.ca> Message-ID: <6051BDF0-5B9D-4826-8411-9B9362D86148@fas.harvard.edu> Brendan Simons wrote: > For the build applet, if the grider icon doesn't work, what about > the generic app icon self assembling from bits. Like this: > > http://www.flickr.com/photos/28928816 at N00/133016352/ Ooh, that's kind of neat. I was trying to find pictures of meat grinders, but none of them are really the right shape to make good icons. I'll keep thinking about it. -Jacob From ronaldoussoren at mac.com Sat Apr 22 22:29:12 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 22 Apr 2006 22:29:12 +0200 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: References: Message-ID: <9A0FCF52-5708-4C5F-9E74-DB4C4AA81D6B@mac.com> On 22-apr-2006, at 18:50, Alex Martelli wrote: > > Once this idiocy is solved, there is another problem: I STILL can't > link gmpy.so beause I can't make libgmp.a to build properly for > linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS > contents): > > brain:~/alex/gmpy alex$ python setup.py build_ext -i > running build_ext > building 'gmpy' extension > creating build/temp.macosx-10.4-fat-2.4 > creating build/temp.macosx-10.4-fat-2.4/src > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - > fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - > fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ > Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c > src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g > -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ > gmpy.o -L/usr/local/lib -lgmp -o gmpy.so > /usr/bin/ld: for architecture i386 > /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation > entries in non-writable section (__TEXT,__text) On other platforms I'd say that gmp should be compiled with -fPIC in the compiler flags. On OSX however this should be the default. It could be a problem in an assembly file. Given the .asm files and configure script I'd guess that it might help to add '--with-pic' to the configure line. Ronald From janssen at parc.com Sat Apr 22 22:31:37 2006 From: janssen at parc.com (Bill Janssen) Date: Sat, 22 Apr 2006 13:31:37 PDT Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: Your message of "Sat, 22 Apr 2006 13:21:54 PDT." <895392AA-E5B7-4A63-85C1-C258DD9E79E2@fas.harvard.edu> Message-ID: <06Apr22.133147pdt."58633"@synergy1.parc.xerox.com> > Jordan Krushen wrote: > > +1 on everything so far, including the recent changes on the egg, but > > the egg still looks odd to me.. it looks like it's sitting on its thin > > end.. would it be possible to flip the ends of the egg? > > Alright, one more go with the egg icon. I agree, it did look a bit off: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png That's a great-looking egg! Bill From brendansimons at yahoo.ca Sat Apr 22 22:34:55 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Sat, 22 Apr 2006 16:34:55 -0400 Subject: [Pythonmac-SIG] on a tangent from new icons In-Reply-To: References: Message-ID: On 21-Apr-06, at 6:13 PM, pythonmac-sig-request at python.org wrote: > On Apr 21, 2006, at 3:08 PM, Jacob Rus wrote: > >> Bob Ippolito wrote: >>> Jacob Rus wrote: >>>> * Do we want different icons for py2applet.app and >>>> BuildApplet.app? >>>> What exactly is the difference between these? >>> >>> BuildApplet isn't any good at creating self-contained applications. >>> py2applet is. py2app does not ship with Python. >> >> Ok, well neither of the apps has an icon yet, but I [updated][1] >> some of >> the icons. I think that the "applet" icon can be the default for >> applets created by BuildApplet, and the "generic python app" icon >> can be >> the default for apps created with py2app or py2applet. How does that >> sound? Is it possible to give py2app a default icon? > > Yes, of course we can give py2app-built apps a default icon. > py2applet should probably have a different icon though, so it's > distinguishable from the apps it generates. When/if you come up > with them, just shoot them over my way and I'll see about tossing > them in! > > -bob Jacob, In your composite image, does the applet.app icon refer to applications built with buildapplet.app, or buildapplet.app itself? If the former, what is the rationale for using different icons for py2app-built apps, and applets? They're both applications as far as the user is concerned. Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060422/4667a2b9/attachment.html From daniellord at mac.com Sat Apr 22 22:51:52 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 22 Apr 2006 13:51:52 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: References: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> Message-ID: <647B8FAE-362C-4E21-B326-8D1F59A5A46A@mac.com> On Apr 22, 2006, at 12:36, Alex Martelli wrote: > It's not just gmpy, but anything that needs to be linked as - > bundle, whatever that means exactly. The workings of ld are > slightly arcane -- I did already ask for advice from colleagues who > I thought SHOULD know; for example, Matt Austern, who besides > authoring "Generic programming and the STL" and shepherding library > standards for the next generation of C++, led the gcc 4 group at > Apple, focusing on many optimizations therefor... *he* easily > admits that linking on MacOSX (as soon as dylibs, bundles, > frameworks, and the interplay of their namespaces and constraints > enters the picture) is something he never fully fathomed (no real > need for him to delve into that, it appears). autoconf and friends > are even scarier (to me, at least)...;-). Yup. Just ran into it with pcre (see below). Building pcre for i386 separately works, but trying the old ' -arch ppc -arch i386 ' CFLAGS trick is what appears to precipitate the failure. gcc -arch ppc -arch i386 -O2 -g -I. -Ipcre-6.6 -o .libs/pcretest pcretest.o ./.libs/libpcre.dylib ./.libs/libpcreposix.dylib /Users/ daniello/Project/Python-Builds/pcre/.libs/libpcre.dylib /usr/bin/ld: for architecture ppc /usr/bin/ld: warning ./.libs/libpcre.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/ld: warning ./.libs/libpcreposix.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/ld: warning /Users/daniello/Project/Python-Builds/ pcre/.libs/libpcre.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) /usr/bin/ld: Undefined symbols: _pcre_callout _pcre_compile _pcre_config _pcre_copy_substring _pcre_dfa_exec _pcre_exec _pcre_free _pcre_free_substring _pcre_free_substring_list _pcre_fullinfo _pcre_get_stringnumber _pcre_get_substring _pcre_get_substring_list _pcre_info _pcre_maketables _pcre_malloc _pcre_stack_free _pcre_stack_malloc _pcre_study _pcre_version collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccYAMG1B.out (No such file or directory) make: *** [pcretest] Error 1 So I did a little reading, and at least for my problem above the answer is in the man page for ld: UNIVERSAL FILE SUPPORT The link editor accepts ``universal'' (multiple- architecture) input files, but always creates a ``thin'' (single- architecture), standard Mach-O output file. The architecture is specified using the -arch arch_type option. If this option is not used, ld(1) attempts to deter- mine the output architecture by examining the first object file encoun- tered on the command line. If it is a ``thin'' file, its architecture determines that of the output file. If the first input file is a ``universal'' file, the ``best'' architecture for the host is used. (See the explanation of the -arch option, below.) The compiler driver cc(1) handles creating universal executables by calling ld(1) multiple times and using lipo(1) to create a ``univer- sal'' file from the results of the ld(1) executions. So the answer, IMHO and I could be wrong since I am very new to this, is one of two choices: 1) use 'ld' to produce two separate builds and then use 'lipo' to weld them together as a 'FAT' dylib or 2) To use 'cc' to build the dylibs and it takes care of teh seprate building and 'lipo-ing' Or maybe I have this wrong and the errros only seem the same and they are really dissimilar. From jordan at krushen.com Sat Apr 22 23:01:52 2006 From: jordan at krushen.com (Jordan Krushen) Date: Sat, 22 Apr 2006 14:01:52 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <7443471536897568580@unknownmsgid> References: <895392AA-E5B7-4A63-85C1-C258DD9E79E2@fas.harvard.edu> <7443471536897568580@unknownmsgid> Message-ID: On 4/22/06, Bill Janssen wrote: > > Alright, one more go with the egg icon. I agree, it did look a bit off: > > > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > > That's a great-looking egg! +1 :) J. From aleaxit at gmail.com Sat Apr 22 23:51:57 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Sat, 22 Apr 2006 14:51:57 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: <647B8FAE-362C-4E21-B326-8D1F59A5A46A@mac.com> References: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> <647B8FAE-362C-4E21-B326-8D1F59A5A46A@mac.com> Message-ID: <22B59646-0B00-4C44-A443-48A5452C7AE2@gmail.com> On Apr 22, 2006, at 1:51 PM, Daniel Lord wrote: ... > So the answer, IMHO and I could be wrong since I am very new to > this, is one of two choices: > 1) use 'ld' to produce two separate builds and then use 'lipo' to > weld them together as a 'FAT' dylib or > 2) To use 'cc' to build the dylibs and it takes care of teh seprate > building and 'lipo-ing' > > Or maybe I have this wrong and the errros only seem the same and > they are really dissimilar. I'm pretty new at this too -- I've owned an intel Mac for less than a month, and it's been a busy time, little chance to learn or tweak much yet; and in particular I've not yet been able to build a fat- binary .so Python extension with the Universal MacPython 2.4.3 and any simple "python setup.py build_ext -i" approach. Ronald may hopefully understand these issues (and what if anything needs to be tweaked in distutils) a bit better... Alex From hengist.podd at virgin.net Sun Apr 23 00:49:49 2006 From: hengist.podd at virgin.net (has) Date: Sat, 22 Apr 2006 23:49:49 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: Jacob Rus wrote: >Ronald Oussoren wrote: >>Now that we (almost) have new icons it would be great if someone could have >>a look at IDLE and at the very least writes down what could be done to make >>it a better OSX citizen. Actual patches would of course even be better. If I get a chance, I'll see if I can make some notes on where the UI falls short. I've not got time to start learning the source though. >>I wouldn't make a distintion between applets (what buildapplet builds) and applications (what py2app builds) and prefer the generic application icon for both of them. > >Okay, that's fine. Agree with that. Could also use the same (or very similar) icons for BuildApplet and py2applet. They serve the same purpose, and hopefully by the time Python 2.6 comes around py2app and py2applet will replace bundlebuilder and BA completely anyway. >>The only thing that seems to be missing is an icon for 'Build Applet'. > >Indeed. I'll try, but I'm not sure I'm up to drawing it. I could draw up a grinder or something in Illustrator, but it probably won't be for some days. If you can find something sooner, that's cool, otherwise let me know middle of next week and I'll see what I can do. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From daniellord at mac.com Sun Apr 23 01:06:55 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 22 Apr 2006 16:06:55 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: <22B59646-0B00-4C44-A443-48A5452C7AE2@gmail.com> References: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> <647B8FAE-362C-4E21-B326-8D1F59A5A46A@mac.com> <22B59646-0B00-4C44-A443-48A5452C7AE2@gmail.com> Message-ID: On Apr 22, 2006, at 14:51, Alex Martelli wrote: > > On Apr 22, 2006, at 1:51 PM, Daniel Lord wrote: > ... >> So the answer, IMHO and I could be wrong since I am very new to >> this, is one of two choices: >> 1) use 'ld' to produce two separate builds and then use 'lipo' to >> weld them together as a 'FAT' dylib or >> 2) To use 'cc' to build the dylibs and it takes care of teh >> seprate building and 'lipo-ing' >> >> Or maybe I have this wrong and the errros only seem the same and >> they are really dissimilar. > > I'm pretty new at this too -- I've owned an intel Mac for less than > a month, and it's been a busy time, little chance to learn or tweak > much yet; and in particular I've not yet been able to build a fat- > binary .so Python extension with the Universal MacPython 2.4.3 and > any simple "python setup.py build_ext -i" approach. Ronald may > hopefully understand these issues (and what if anything needs to be > tweaked in distutils) a bit better... I just bought my Macbook Pro about 2 weeks ago so I am twice the newbie ;-) I just now wrote a quick and dirty test of making static 'FAT' lib that succeeded... At first I got these errors similar to what we've been seeing: [daniello at mercury.local]$ make -f Makefile cc -O2 -fno-common -c answer1.c cc -O2 -fno-common -c answer2.c ar crv libanswer.a answer1.o answer2.o a - answer1.o a - answer2.o ranlib libanswer.a cc -arch ppc -arch i386 -Wl,-syslibroot,/Developer/SDKs/ MacOSX10.4u.sdk -o static static.o -L. -lanswer /usr/bin/ld: for architecture ppc /usr/bin/ld: warning static.o cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) rch flag: ppc (can't load from it) /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccEO7pnk.out (No such file or directory) make: *** [static] Error 1 Then poking around the docs and "Advanced OSX Programming", I found something to try: LDFLAGS = -arch ppc -arch i386 -Wl,-syslibroot,/Developer/SDKs/ MacOSX10.4u.sdk And that did it. Try it an let me know if that solves your problem...more later after I figure out the details From daniellord at mac.com Sun Apr 23 01:13:40 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 22 Apr 2006 16:13:40 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <07659618-1EED-46DE-BA5F-FA688C02A881@mac.com> On Apr 22, 2006, at 15:49, has wrote: > Jacob Rus wrote: > >> Ronald Oussoren wrote: >>> Now that we (almost) have new icons it would be great if someone >>> could have >>> a look at IDLE and at the very least writes down what could be >>> done to make >>> it a better OSX citizen. Actual patches would of course even be >>> better. > > If I get a chance, I'll see if I can make some notes on where the > UI falls short. I've not got time to start learning the source though. > > >>> I wouldn't make a distintion between applets (what buildapplet >>> builds) and applications (what py2app builds) and prefer the >>> generic application icon for both of them. >> >> Okay, that's fine. > > Agree with that. Could also use the same (or very similar) icons > for BuildApplet and py2applet. They serve the same purpose, and > hopefully by the time Python 2.6 comes around py2app and py2applet > will replace bundlebuilder and BA completely anyway. > > >>> The only thing that seems to be missing is an icon for 'Build >>> Applet'. >> >> Indeed. I'll try, but I'm not sure I'm up to drawing it. > > I could draw up a grinder or something in Illustrator, but it > probably won't be for some days. If you can find something sooner, > that's cool, otherwise let me know middle of next week and I'll see > what I can do. Maybe this is another of my 'wlid and crazy' ideas, but what about a waring-style blender instead of a grinder. You can probably find a nice photo of a blender somewhere more easily than a grinder. From aleaxit at gmail.com Sun Apr 23 01:35:38 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Sat, 22 Apr 2006 16:35:38 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: <9A0FCF52-5708-4C5F-9E74-DB4C4AA81D6B@mac.com> References: <9A0FCF52-5708-4C5F-9E74-DB4C4AA81D6B@mac.com> Message-ID: <89E563CB-9A26-4039-A997-26A3216C7578@gmail.com> On Apr 22, 2006, at 1:29 PM, Ronald Oussoren wrote: ... > On other platforms I'd say that gmp should be compiled with -fPIC > in the compiler flags. On OSX however this That's one of the things I tried (adding CFLAGS=-fPIC to the ./ configure invocation), uselessly. > should be the default. It could be a problem in an assembly file. > Given the .asm files and configure script I'd guess that it might > help to add '--with-pic' to the configure line. OK, tried this - and now the assembly is failing: /bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. - DOPERATION_`echo dive_1 | sed 's/_$//'` -fPIC `test -f 'dive_1.asm' || echo './'`dive_1.asm ../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I. -I.. - D__GMP_WITHIN_GMP -I.. -DOPERATION_dive_1 -fPIC dive_1.asm -fno- common -DPIC -o dive_1.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_dive_1 -DPIC dive_1.asm >tmp-dive_1.s gcc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. - DOPERATION_dive_1 -fPIC tmp-dive_1.s -fno-common -DPIC -o dive_1.o tmp-dive_1.s:108:invalid character '@' in first operand make[2]: *** [dive_1.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The relevant fragment of that tmp-dive_1.s is: 106 call Lmovl_eip_ebp 107 addl $_GLOBAL_OFFSET_TABLE_, %ebp 108 movl ___gmp_modlimb_invert_table at GOT(%ebp), %ebp 109 movzbl (%eax,%ebp), %ebp and the corresponding fragment of dive_1.s: 79 ifdef(`PIC',` 80 call L(movl_eip_ebp) 81 addl $_GLOBAL_OFFSET_TABLE_, %ebp 82 movl modlimb_invert_table at GOT(%ebp), %ebp 83 movzbl (%eax,%ebp), %ebp C inv 8 bits 84 85 ',` 86 dnl non-PIC 87 movzbl modlimb_invert_table(%eax), %ebp C inv 8 bits 88 ') So, m4 is doing its job (so, your suggestion was no doubt right, thanks!), picking the PIC version rather the non-PIC one... and unfortunately the PIC version does hit some assembler-syntax issue, it would seem. One note in the Makefile in that directory may be relevant...: # Libtool adds -DPIC when building a shared object and the .asm files look # for that. But it should be noted that the other PIC flags are on occasion # important too, in particular FreeBSD 2.2.8 gas 1.92.3 requires -k before # it accepts PIC constructs like @GOT, and gcc adds that flag only under # -fPIC. (Later versions of gas are happy to accept PIC stuff any time.) I can't find any docs for the "@GOT" syntax (presumably of GNU as), though I'm sure it's somehow referring to a global-offset-table -- the only occurrence of '@' I've found in GNU as's Reference manual is about .symver (and it does appear relevant to what ld is later meant to do), but there are no occurrences of that directive in these source and include files anyway. Unfortunately, no web search engine that I know of has any notion of letting you search for special characters such as '@', and the word 'GOT' is so common that it is absolutely no use whatsoever - I've searched for 'global offset table, 'pic' and 'position independent code', and so on and so forth, but all to no avail. Assuming there's some parallel between Apple assembler syntax for x86 and PPC I've pored over the Powerpc assembler parts of GMP 4.2, and there are some very cryptic notes about assembly PIC and non-PIC for Linux AIX and Darwin, but nothing that seems to apply or help in any way here. I'm rather stalled, so, for now, I've built GMP 4.2 to NOT use any assembly on my Mac-Intel and proceeded with other work needed to make gmpy compatible with GMP 4.2 (mostly tweaks on unittests, but one somewhat major rework to the random-number facility, which changed drastically in 4.2). Anyway, thanks for the help so far -- my plans now include checking the current gmpy (with GMP 4.2 _and_ 4.1) on PPC, measuring speed (to guess how much I lose by having to disable assembly on Mac-Intel), further checking and measuring on Linux and Windows, etc. I hope, before I release gmpy 1.02 at some point, to get back to the "assembly on Mac-Intel" issues... can anybody perchance suggest suitable newsgroups, mailing lists, or sites, where somebody might, upon seeing the issue with "whatever at GOT(%bx)" etc, immediately suggest some solution?-) Alex From aleaxit at gmail.com Sun Apr 23 01:40:40 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Sat, 22 Apr 2006 16:40:40 -0700 Subject: [Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so! In-Reply-To: References: <4D4BCEAB-D0E7-49EB-9B6A-FEE3DB8968A9@mac.com> <647B8FAE-362C-4E21-B326-8D1F59A5A46A@mac.com> <22B59646-0B00-4C44-A443-48A5452C7AE2@gmail.com> Message-ID: On Apr 22, 2006, at 4:06 PM, Daniel Lord wrote: ... > cc -arch ppc -arch i386 -Wl,-syslibroot,/Developer/SDKs/ > MacOSX10.4u.sdk -o static static.o -L. -lanswer ... > /usr/bin/ld: for architecture ppc > /usr/bin/ld: warning static.o cputype (7, architecture i386) does > not match cputype (18) for specified -arch flag: ppc (file not loaded) > rch flag: ppc (can't load from it) > /usr/bin/ld: Undefined symbols: > _main > collect2: ld returned 1 exit status > lipo: can't open input file: /var/tmp//ccEO7pnk.out (No such file > or directory) > make: *** [static] Error 1 > > > Then poking around the docs and "Advanced OSX Programming", I found > something to try: > > LDFLAGS = -arch ppc -arch i386 -Wl,-syslibroot,/Developer/SDKs/ > MacOSX10.4u.sdk > > And that did it. Try it an let me know if that solves your > problem...more later after I figure out the details Not sure I understand -- you do seem to have those flags in the cc command I left quoted above. Also, building with "python setup.py" (as always recommended for compiling and linking Python extensions) already specifies those flags, so that exporting that LDFLAGS causes an error due to the repetition...: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup -arch ppc -arch i386 -Wl,- syslibroot,/Developer/SDKs/MacOSX10.4u.sdk build/temp.macosx-10.4- fat-2.4/src/gmpy.o -L/usr/local/lib -lgmp -o build/lib.macosx-10.4- fat-2.4/gmpy.so /usr/bin/ld: -syslibroot: multiply specified collect2: ld returned 1 exit status /usr/bin/ld: -syslibroot: multiply specified collect2: ld returned 1 exit status etc. Maybe I misunderstand what you're suggesting...? Thanks, Alex From atenderholt at gmail.com Sat Apr 22 02:08:00 2006 From: atenderholt at gmail.com (Adam Tenderholt) Date: Fri, 21 Apr 2006 17:08:00 -0700 Subject: [Pythonmac-SIG] import sip problem (Universal Mac 2.4.3) and build options Message-ID: <7781a1b50604211708j79a60bf2ka084924a3184133b@mail.gmail.com> I'm trying to get sip and PyQt working with Universal MacPython 2.4.3. It compiles fine however trying to import sip results in the error: "ImportError: Inappropriate file type for dynamic loading". I posted on the PyKDE/PyQt/sip mailing list, and it was suggested that I try to reconfigure and rebuild Python-2.4.3 with: DYNLOADFILE=dynload_shlib.o ./configure --enable-framework --enable-toolbox-glue --enable-shared Unfortunately, I get the following error during make: /usr/bin/ld: warning Python.framework/Versions/2.4/Python cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: _PyMac_Error _Py_Main collect2: ld returned 1 exit status I've looked online for the options used to compile Universal MacPython, but I haven't had any luck. Is there a someplace I should be looking? Thanks, Adam From jrus at fas.harvard.edu Sun Apr 23 22:36:26 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Sun, 23 Apr 2006 16:36:26 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: Message-ID: <444BE54A.9020703@fas.harvard.edu> has wrote: > I could draw up a grinder or something in Illustrator, but it probably won't be for some days. If you can find something sooner, that's cool, otherwise let me know middle of next week and I'll see what I can do. Okay, this is kind of goofy, but might work. The second image is the "drop" state. Check out the zip to see it in action. PNG: http://hcs.harvard.edu/~jrus/python/py-grinder.png ZIP: http://hcs.harvard.edu/~jrus/python/py-grinder.zip -Jacob From ronaldoussoren at mac.com Sun Apr 23 23:14:37 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 23 Apr 2006 23:14:37 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444BE54A.9020703@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> Message-ID: On 23-apr-2006, at 22:36, Jacob Rus wrote: > has wrote: >> I could draw up a grinder or something in Illustrator, but it >> probably won't be for some days. If you can find something sooner, >> that's cool, otherwise let me know middle of next week and I'll >> see what I can do. > Okay, this is kind of goofy, but might work. Goofy isn't necessarily a bad thing;-) Ronald From daniellord at mac.com Sun Apr 23 23:19:07 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 23 Apr 2006 14:19:07 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444BE54A.9020703@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> Message-ID: <94A5E918-D727-4079-AEB2-0BD345812F29@mac.com> On Apr 23, 2006, at 13:36, Jacob Rus wrote: > has wrote: >> I could draw up a grinder or something in Illustrator, but it >> probably won't be for some days. If you can find something sooner, >> that's cool, otherwise let me know middle of next week and I'll >> see what I can do. > Okay, this is kind of goofy, but might work. The second image is the > "drop" state. Check out the zip to see it in action. > > PNG: http://hcs.harvard.edu/~jrus/python/py-grinder.png > ZIP: http://hcs.harvard.edu/~jrus/python/py-grinder.zip As ling as you are convinced you want a grinder over a _blender_ (hint;-), then... That one is nicely done.d From njriley at uiuc.edu Sun Apr 23 23:30:23 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun, 23 Apr 2006 16:30:23 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444BE54A.9020703@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> Message-ID: <20060423213023.GA16633@uiuc.edu> On Sun, Apr 23, 2006 at 04:36:26PM -0400, Jacob Rus wrote: > has wrote: > > I could draw up a grinder or something in Illustrator, but it probably won't be for some days. If you can find something sooner, that's cool, otherwise let me know middle of next week and I'll see what I can do. > Okay, this is kind of goofy, but might work. The second image is the > "drop" state. Check out the zip to see it in action. > > PNG: http://hcs.harvard.edu/~jrus/python/py-grinder.png > ZIP: http://hcs.harvard.edu/~jrus/python/py-grinder.zip Nice looking, but unrecognizable and impractical at small sizes. Even at full size, I had to stare at it for a few seconds before I recongized what it was trying to depict. The dropping action at a small size (say 32x32) looks like something kicking out, rather than a handle turning. -- Nicholas Riley | From dp at ulaluma.com Sun Apr 23 23:53:49 2006 From: dp at ulaluma.com (Donovan Preston) Date: Sun, 23 Apr 2006 14:53:49 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <20060423213023.GA16633@uiuc.edu> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> Message-ID: <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> On Apr 23, 2006, at 2:30 PM, Nicholas Riley wrote: > On Sun, Apr 23, 2006 at 04:36:26PM -0400, Jacob Rus wrote: >> has wrote: >>> I could draw up a grinder or something in Illustrator, but it >>> probably won't be for some days. If you can find something >>> sooner, that's cool, otherwise let me know middle of next week >>> and I'll see what I can do. >> Okay, this is kind of goofy, but might work. The second image is the >> "drop" state. Check out the zip to see it in action. >> >> PNG: http://hcs.harvard.edu/~jrus/python/py-grinder.png >> ZIP: http://hcs.harvard.edu/~jrus/python/py-grinder.zip > > Nice looking, but unrecognizable and impractical at small sizes. Even > at full size, I had to stare at it for a few seconds before I > recongized what it was trying to depict. The dropping action at a > small size (say 32x32) looks like something kicking out, rather than a > handle turning. What about something more like the Help Indexer in /Developer/ Applications/Utilities. A little more stylized and less photorealistic. Should look better at smaller sizes. dp From jrus at fas.harvard.edu Mon Apr 24 02:20:48 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Sun, 23 Apr 2006 20:20:48 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> Message-ID: <444C19E0.2020307@fas.harvard.edu> Donovan Preston wrote: > What about something more like the Help Indexer in /Developer/ > Applications/Utilities. A little more stylized and less > photorealistic. Should look better at smaller sizes. Yeah, building on Brendan Simons' idea of what a Help Indexer-esque Applet Builder.app icon should look like, here's what I've come up with: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png Sadly, the grinder isn't destined for glory. (I agree that it's not so great at small sizes, or even at 128x128, but at full size it's fun to drop stuff on :-) -Jacob From daniellord at mac.com Mon Apr 24 02:38:55 2006 From: daniellord at mac.com (Daniel Lord) Date: Sun, 23 Apr 2006 17:38:55 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444C19E0.2020307@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> Message-ID: <6E0F37F6-7727-473C-8208-03E4085BC324@mac.com> On Apr 23, 2006, at 17:20, Jacob Rus wrote: > Yeah, building on Brendan Simons' idea of what a Help Indexer-esque > Applet Builder.app icon should look like, here's what I've come up > with: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png Well what do you know! Even better than a blender though I suppsoe there will be a lot of comments on the angle of the output of the app icon etc. Me? I'll probably rarely see it and it fine right now for me IMHO. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060423/3709997d/attachment.htm From bob at redivi.com Mon Apr 24 03:37:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 23 Apr 2006 18:37:21 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444C19E0.2020307@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> Message-ID: <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> On Apr 23, 2006, at 5:20 PM, Jacob Rus wrote: > Donovan Preston wrote: >> What about something more like the Help Indexer in /Developer/ >> Applications/Utilities. A little more stylized and less >> photorealistic. Should look better at smaller sizes. > > Yeah, building on Brendan Simons' idea of what a Help Indexer-esque > Applet Builder.app icon should look like, here's what I've come up > with: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png +1, I like it! -bob From zbir at urbanape.com Mon Apr 24 04:07:54 2006 From: zbir at urbanape.com (Zachery Bir) Date: Sun, 23 Apr 2006 22:07:54 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> Message-ID: On Apr 23, 2006, at 9:37 PM, Bob Ippolito wrote: > On Apr 23, 2006, at 5:20 PM, Jacob Rus wrote: > >> Donovan Preston wrote: >>> What about something more like the Help Indexer in /Developer/ >>> Applications/Utilities. A little more stylized and less >>> photorealistic. Should look better at smaller sizes. >> >> Yeah, building on Brendan Simons' idea of what a Help Indexer-esque >> Applet Builder.app icon should look like, here's what I've come up >> with: >> >> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > > +1, I like it! Moi, aussi. Put a fork in it, it's done! Zac From dp at ulaluma.com Mon Apr 24 06:43:34 2006 From: dp at ulaluma.com (Donovan Preston) Date: Sun, 23 Apr 2006 21:43:34 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> Message-ID: <9A70C92F-7644-40C5-B524-6760A5580850@ulaluma.com> On Apr 23, 2006, at 7:07 PM, Zachery Bir wrote: > On Apr 23, 2006, at 9:37 PM, Bob Ippolito wrote: > >> On Apr 23, 2006, at 5:20 PM, Jacob Rus wrote: >> >>> Donovan Preston wrote: >>>> What about something more like the Help Indexer in /Developer/ >>>> Applications/Utilities. A little more stylized and less >>>> photorealistic. Should look better at smaller sizes. >>> >>> Yeah, building on Brendan Simons' idea of what a Help Indexer-esque >>> Applet Builder.app icon should look like, here's what I've come up >>> with: >>> >>> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png >> >> +1, I like it! > > Moi, aussi. Put a fork in it, it's done! Totally. Rocks. dp From njriley at uiuc.edu Mon Apr 24 06:56:03 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun, 23 Apr 2006 23:56:03 -0500 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444C19E0.2020307@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> Message-ID: <20060424045602.GA21194@uiuc.edu> On Sun, Apr 23, 2006 at 08:20:48PM -0400, Jacob Rus wrote: > Donovan Preston wrote: > > What about something more like the Help Indexer in /Developer/ > > Applications/Utilities. A little more stylized and less > > photorealistic. Should look better at smaller sizes. > > Yeah, building on Brendan Simons' idea of what a Help Indexer-esque > Applet Builder.app icon should look like, here's what I've come up with: > > http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > > Sadly, the grinder isn't destined for glory. (I agree that it's not so > great at small sizes, or even at 128x128, but at full size it's fun to > drop stuff on :-) Sorry to rain on your parade :-) The new icon looks great. Can these icons (and their source Photoshop files, etc.) be checked into some Subversion repository, so they can continue to be developed? I'd hate to see someone else have to start from scratch in the event new Mac OS X icons need to be produced. -- Nicholas Riley | From jrus at fas.harvard.edu Mon Apr 24 07:18:03 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Mon, 24 Apr 2006 01:18:03 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> Message-ID: <444C5F8B.2090503@fas.harvard.edu> Zachery Bir wrote: > Bob Ippolito wrote: >> +1, I like it! > Moi, aussi. Put a fork in it, it's done! Ok, the fork is in. http://hcs.harvard.edu/~jrus/python/python-icons.zip P.S. two of the icons have drop states. From woklist at kyngchaos.com Mon Apr 24 16:23:02 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon, 24 Apr 2006 09:23:02 -0500 Subject: [Pythonmac-SIG] installer and .profile Message-ID: <9942C4E3-5EE8-4AAE-9D07-C0E82B708E7A@kyngchaos.com> I just noticed a small issue with the new universal installer. It adds a path to the python bin folder to the user's ~/.profile. 1. The Apple-default bash shell doesn't read .profile (doesn't for me). (I think tcsh does, but I always used .login back then) 2. If it doesn't exist, .profile gets created with root ownership, since the installer must autorize to install. 3. Symlinks to the python binaries are installed in /usr/local/bin anyways. So really the installer should check if /usr/lcoal/bin is in the user's path. Since a user can choose their shell, maybe it shouldn't be trying to add to the user's path, but just tell the user that's what they need to do. Or if there is some way for the installer to figure out the user's default shell (I know it's a setting in the netinfo database for each user), the installer could intelligently edit the correct shell init (ie .bash_profile). ----- William Kyngesburye http://www.kyngchaos.com/ "Those people who most want to rule people are, ipso-facto, those least suited to do it." - A rule of the universe, from the HitchHiker's Guide to the Galaxy From woklist at kyngchaos.com Mon Apr 24 17:26:20 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon, 24 Apr 2006 10:26:20 -0500 Subject: [Pythonmac-SIG] installer and .profile In-Reply-To: <12344386.1145890500984.JavaMail.ronaldoussoren@mac.com> References: <9942C4E3-5EE8-4AAE-9D07-C0E82B708E7A@kyngchaos.com> <12344386.1145890500984.JavaMail.ronaldoussoren@mac.com> Message-ID: <91A06E1D-D9DD-4A4F-B33B-243496155616@kyngchaos.com> On Apr 24, 2006, at 9:55 AM, Ronald Oussoren wrote: > > On Monday, April 24, 2006, at 04:37PM, William Kyngesburye > wrote: > >> I just noticed a small issue with the new universal installer. It >> adds a path to the python bin folder to the user's ~/.profile. >> >> 1. The Apple-default bash shell doesn't read .profile (doesn't for >> me). (I think tcsh does, but I always used .login back then) > > Bash does read .profile, unless a .bash_profile exists. > Ah, well, I was always a little confused by all the levels of shell init scripts. >> >> 2. If it doesn't exist, .profile gets created with root ownership, >> since the installer must autorize to install. > > That's a bug. > >> >> Since a user can choose their shell, maybe it shouldn't be trying to >> add to the user's path, but just tell the user that's what they need >> to do. Or if there is some way for the installer to figure out the >> user's default shell (I know it's a setting in the netinfo database >> for each user), the installer could intelligently edit the correct >> shell init (ie .bash_profile). > > The script is smart enough to edit the shell configuration of the > users shell. > I guess this would be a bug also, then? I have a .bash_profile, yet it added the .profile instead of editing my .bash_profile. > And BTW. we have documentation about what the user should do to > add the right directory to their PATH. It turns out most users don't > read the documentation or are unix-illiterate enough to not being > able to perform the changes that are required. Automating this task > is a lot friendlier to those users. Not in the readme that is on the installer disk image. If it's in the documentation after install, at least that much should be duplicated in the readme since it's an install thing. Or at least mention in the readme what the installer does in the user's environment (some people might get a little touchy about having user files quietly modified by an installer). ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From delza at livingcode.org Mon Apr 24 18:11:11 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 24 Apr 2006 09:11:11 -0700 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444C5F8B.2090503@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> <444C5F8B.2090503@fas.harvard.edu> Message-ID: <24d517dd0604240911m25a78bb5pe0560fdcb1d9ed49@mail.gmail.com> On 4/23/06, Jacob Rus wrote: > Zachery Bir wrote: > > Bob Ippolito wrote: > >> +1, I like it! > > Moi, aussi. Put a fork in it, it's done! > Ok, the fork is in. > > http://hcs.harvard.edu/~jrus/python/python-icons.zip > > P.S. two of the icons have drop states. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > I'm very impressed with these icons, thanks for all the work you've put into it. --Dethe From ronaldoussoren at mac.com Mon Apr 24 18:15:17 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 24 Apr 2006 18:15:17 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> Message-ID: On 24-apr-2006, at 3:37, Bob Ippolito wrote: > > On Apr 23, 2006, at 5:20 PM, Jacob Rus wrote: > >> Donovan Preston wrote: >>> What about something more like the Help Indexer in /Developer/ >>> Applications/Utilities. A little more stylized and less >>> photorealistic. Should look better at smaller sizes. >> >> Yeah, building on Brendan Simons' idea of what a Help Indexer-esque >> Applet Builder.app icon should look like, here's what I've come up >> with: >> >> http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > > +1, I like it! Same here. Let's stop here. I'll see if I can do a new release of the universal build this week that includes these icons. Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From charles.hartman at conncoll.edu Mon Apr 24 18:22:34 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 12:22:34 -0400 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <444C5F8B.2090503@fas.harvard.edu> References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> <444C5F8B.2090503@fas.harvard.edu> Message-ID: <81505222-0A15-4AB6-838B-2BD62738D32A@conncoll.edu> It's amazing what a nice, shiny, new icon can do for morale. I'm breathing better already. (And I'm not even being ironic.) That's a sixteen-ton weight off my chest. Charles Hartman On Apr 24, 2006, at 1:18 AM, Jacob Rus wrote: > Zachery Bir wrote: >> Bob Ippolito wrote: >>> +1, I like it! >> Moi, aussi. Put a fork in it, it's done! > Ok, the fork is in. > > http://hcs.harvard.edu/~jrus/python/python-icons.zip > > P.S. two of the icons have drop states. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Mon Apr 24 19:11:56 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 10:11:56 -0700 Subject: [Pythonmac-SIG] spaces In-Reply-To: References: <95a5c1891e397aeee7a80dea11fa270a@macosx.com> <4A047940-271E-4FCE-BC66-FD70BDD49E26@redivi.com> Message-ID: <444D06DC.1040600@noaa.gov> kevin parks wrote: > The world isn't gonna end but i am still 100% -0 on this proposal... It won't kill me either, but FWIW: -1 I guess that's what I get for being more a *nix guy than a Mac Guy. -CHB -- 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 at noaa.gov From jmgore75 at gmail.com Mon Apr 24 01:28:39 2006 From: jmgore75 at gmail.com (Jeremy Gore) Date: Sun, 23 Apr 2006 19:28:39 -0400 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel Message-ID: I use the old Numeric package quite a bit (numpy is just not ready for primetime) and stupid me, I didn't check if it was available before I installed the Universal binary package for python 2.4.3. Rather than moving backwards, I'd like to try getting it to compile. However, I can't seem to find the cvs/svn with the most recent configuration files. Where are those? I'd also like to install numarray, numpy, and scipy. (numpy won't compile due to "can't locate file for : -lcc_dynamic"; this was also a problem for the sources of numarray and Numeric) I'm running a MacBookPro with 10.4.6. From bob at redivi.com Mon Apr 24 19:42:27 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 24 Apr 2006 10:42:27 -0700 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: References: Message-ID: On Apr 23, 2006, at 4:28 PM, Jeremy Gore wrote: > I use the old Numeric package quite a bit (numpy is just not ready > for primetime) and stupid me, I didn't check if it was available > before I installed the Universal binary package for python 2.4.3. > Rather than moving backwards, I'd like to try getting it to compile. > However, I can't seem to find the cvs/svn with the most recent > configuration files. Where are those? > > I'd also like to install numarray, numpy, and scipy. (numpy won't > compile due to "can't locate file for : -lcc_dynamic"; this was also > a problem for the sources of numarray and Numeric) > > I'm running a MacBookPro with 10.4.6. Are you sure you have the latest Xcode installed with the 10.4u SDK? -lcc_dynamic sounds like compiler mismatch or something. -bob From Chris.Barker at noaa.gov Mon Apr 24 20:14:18 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 11:14:18 -0700 Subject: [Pythonmac-SIG] New wiki entry on Universal libraries and extensions In-Reply-To: <3247ECA0-5401-43D1-A9D4-A6B74A88C588@mac.com> References: <3247ECA0-5401-43D1-A9D4-A6B74A88C588@mac.com> Message-ID: <444D157A.3040607@noaa.gov> Daniel Lord wrote: > I made good on my threat and wrote it up. Thanks for writing this up. Maybe it should be part of: http://pythonmac.org/wiki/UniversalPackages or at least linked there. > please review my content and let's get anything > incorrect fixed. For now, I've just fixed a couple typos and formatting errors. My primary comment is that you're discussing building a Universal package, but keeping the external libs installed with the standard "make install". I haven't tried your scheme yet, but usually that results in dynamic libs being built, sometimes by themselves, and sometimes along with the static libs. The trick here is that you can sometimes get the dynamic libs instead of the static ones when you link. Either way, it will work fine on your system, but there's really no point in building a Universal Package if you're not trying to distribute it (or a Py2App bundle built with it) That's why I put the static libs I build into a a special place inside my home directory -- I can be sure that's what's getting linked. -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 at noaa.gov From Chris.Barker at noaa.gov Mon Apr 24 20:18:05 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 11:18:05 -0700 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: References: Message-ID: <444D165D.3080809@noaa.gov> Bob Ippolito wrote: > On Apr 23, 2006, at 4:28 PM, Jeremy Gore wrote: >> I use the old Numeric package quite a bit (numpy is just not ready >> for primetime) and stupid me, I didn't check if it was available >> before I installed the Universal binary package for python 2.4.3. >> Rather than moving backwards, I'd like to try getting it to compile. >> I'm running a MacBookPro with 10.4.6. > > Are you sure you have the latest Xcode installed with the 10.4u SDK? > -lcc_dynamic sounds like compiler mismatch or something. Yes, it should work. Better yet, let's try to get a universal package built. When you've resolved this, please update the Numeric section on: http://pythonmac.org/wiki/UniversalPackages -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 at noaa.gov From Chris.Barker at noaa.gov Mon Apr 24 20:31:22 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 11:31:22 -0700 Subject: [Pythonmac-SIG] Applets? Message-ID: <444D197A.1080202@noaa.gov> Hi all, Along with the icon discussion (they look great, by the way) There has been a lot of mention of BuildApplet and Py2Applet, etc. I'm a bit confused as to what actually exists. This is my understanding -- someone please clarify if I'm wrong: BuildApplication: Builds a complete *.app bundle, including the entire python interpreter, etc. Is is not longer being maintained, and may or may not work in a given instance. BuildApplet: Builds a *.app bundle that does not include python, and thus looks and acts like a "real application", but requires a complete appropriate python installation. Also no longer maintained, and may or may not work. Py2App: Builds a complete *.app bundle (like BuildApplication) that includes everything but python if the system python is used, and includes everything if another python is used. It is more robust than BuildApplication and is being maintained with a version supporting the Universal build released. Py2Applet: This does not exist. If it did, it would be like BuildApplet, but using the Py2App code base. My understanding is that Bob I. (author of Py2App) has no need for such a thing, and has thus not written it. He has indicated that he will accept patches, however. (Have I got that right, Bob?) Oh, and BuildApplication and BuildApplet are not going to be included in future versions. Thanks for any clarification. -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 at noaa.gov From robert.kern at gmail.com Mon Apr 24 20:34:08 2006 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 24 Apr 2006 13:34:08 -0500 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: References: Message-ID: <444D1A20.3040600@gmail.com> Bob Ippolito wrote: > On Apr 23, 2006, at 4:28 PM, Jeremy Gore wrote: > >>I use the old Numeric package quite a bit (numpy is just not ready >>for primetime) and stupid me, I didn't check if it was available >>before I installed the Universal binary package for python 2.4.3. >>Rather than moving backwards, I'd like to try getting it to compile. >>However, I can't seem to find the cvs/svn with the most recent >>configuration files. Where are those? >> >>I'd also like to install numarray, numpy, and scipy. (numpy won't >>compile due to "can't locate file for : -lcc_dynamic"; this was also >>a problem for the sources of numarray and Numeric) >> >>I'm running a MacBookPro with 10.4.6. > > Are you sure you have the latest Xcode installed with the 10.4u SDK? > -lcc_dynamic sounds like compiler mismatch or something. It's a scipy-specific issue. We add that library when compiling against g77-built libraries, and up until recently, it also showed up when using gfortran. It should be fixed now in recent SVN checkouts of numpy. -- Robert Kern robert.kern at gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From Chris.Barker at noaa.gov Mon Apr 24 20:34:56 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 11:34:56 -0700 Subject: [Pythonmac-SIG] help needed with py2app for self updating application In-Reply-To: <2078a7ad0604212039r541be30dl5827f954e7774e6f@mail.gmail.com> References: <2078a7ad0604212016s51e75321ga225ef7c9d1547b3@mail.gmail.com> <2078a7ad0604212039r541be30dl5827f954e7774e6f@mail.gmail.com> Message-ID: <444D1A50.7060402@noaa.gov> SPE Stani's Python Editor wrote: > One more question which which versions of python and wxPython ship OS > X 10.2, 10.3 and any version which is still common? (For 10.4 it is > python2.3.5 and wxPython2.5.3.1 (check with import wx;wx.VERSION). | Python | wxPython 10.2 2.2.? none (this python was pretty broken) 10.3 | 2.3.1 | none 10.4 | 2.3.5 | 2.5.3.1 In general, it's a better idea to ship your own python, using Py2App. If you need to support 10.2, this may be tricky. It's easiest to only support 10.3.9 and above, then you can use the Universal Python and Py2App and have only one version to ship. -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 at noaa.gov From bob at redivi.com Mon Apr 24 20:44:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 24 Apr 2006 11:44:05 -0700 Subject: [Pythonmac-SIG] Applets? In-Reply-To: <444D197A.1080202@noaa.gov> References: <444D197A.1080202@noaa.gov> Message-ID: On Apr 24, 2006, at 11:31 AM, Christopher Barker wrote: > Hi all, > > Along with the icon discussion (they look great, by the way) There has > been a lot of mention of BuildApplet and Py2Applet, etc. I'm a bit > confused as to what actually exists. This is my understanding -- > someone > please clarify if I'm wrong: > > BuildApplication: Builds a complete *.app bundle, including the > entire > python interpreter, etc. Is is not longer being maintained, and may or > may not work in a given instance. I don't think this exists. > BuildApplet: Builds a *.app bundle that does not include python, and > thus looks and acts like a "real application", but requires a complete > appropriate python installation. Also no longer maintained, and may or > may not work. Correct. > Py2App: Builds a complete *.app bundle (like BuildApplication) that > includes everything but python if the system python is used, and > includes everything if another python is used. It is more robust than > BuildApplication and is being maintained with a version supporting the > Universal build released. > > Py2Applet: This does not exist. If it did, it would be like > BuildApplet, > but using the Py2App code base. My understanding is that Bob I. > (author > of Py2App) has no need for such a thing, and has thus not written > it. He > has indicated that he will accept patches, however. (Have I got that > right, Bob?) Technically the current name is py2applet, but it has the standalone app behavior. I'd like to slap a GUI on it that lets you tweak settings and generate a setup.py or just build the app, but that's not in the cards any time soon. -bob From kevino at theolliviers.com Mon Apr 24 21:04:38 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Mon, 24 Apr 2006 12:04:38 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <20060417202630.GB28644@activestate.com> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> Message-ID: Hi Trent, Bob, etc. Sorry for the late reply. It's been a busy week. I've altered wxPython's downloads page to hopefully be clearer and more up-to- date. As for the ANSI/Unicode issue, I made Unicode a little more prominent but ANSI still gets quite a lot of downloads, so I'm hesitant to make it hard to get to. But I've made the Unicode builds the first ones so as to encourage those who don't know/care to just click on Unicode, so if that does make a big difference in the number of people who download ANSI, we can re-evaluate moving it later. (I simply don't know how many people actually need the ANSI build for their app to work...) I also added the Universal binaries pre-release build, along with a note explaining the Tiger-only issue and giving a blueprint for lipo'ing the PPC and Universal builds if anyone wants to try that to see if it works on Panther. ;-) (I don't have time to attempt it right now.) URL is here: http://wxpython.org/downloads.php Thanks, Kevin On Apr 17, 2006, at 1:26 PM, Trent Mick wrote: > [Trent] >>> wxPython on the Mac seems to be painful right now. > > [Kevin Ollivier wrote] >> Suggestions and contributions welcome! :-) > > My apologies, I was being unfairly brief. > Some suggestions: > > - A review of the Mac OS X-related text on > http://www.wxpython.org/download.php > Some of that info is misleading: > > '''wxPythonOSX needs a "Framework" build of Python 2.3, also > known as > MacPython-OSX.''' > > To be fair explaining the myriad Python's out there for Mac OS X is > hard. This sentence though connotes the wrong thing: that > wxPython is > only available for Python 2.3. > > '''If you would like to try Python 2.4.x on Panther or Tiger then > you > can get an installer here''' > > Again, to be fair, giving a download link for the current Python for > Mac OS X (whatever that really means) is a moving target. There > *is* a > Python installer at that link, but it is no longer a recommended > one. > > As well, some mention of the x86 arch issues would be helpful for > users. > > Okay, *one* suggestion. :) I don't currently use wxPython at all. > > >>> 1. You need to get the correct build for your version of Python. For >>> ActivePython 2.4.x or MacPython 2.4.x that means getting one of >>> the >>> builds with "-py24" in the package name. >> >> Of course, this is pretty much the same as with every other (binary) >> Python extension, isn't it? > > Yes, I didn't mean to imply that wxPython is special here. > > >>> 2. They have "ansi" and "unicode" builds. From what I can tell the >>> "ansi" builds are probably only useful for Mac OS X 10.2.x >>> compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater >>> then I'd stick with the "unicode" builds. >> >> The ansi builds are for people who haven't considered Unicode support >> when building their wxPython apps, and thus might have issues when >> their data is automatically converted to and from Unicode. In ansi >> mode, it just passes the actual 'bytes' around, so the user is in >> total control over how the data is encoded. It took me a couple days >> of auditing my codebase before I got everything working with Unicode, >> and while I'm glad I did, up until that point I (and users of my app) >> were doing just fine with ANSI builds. >> >> But yes, in general, Unicode is the recommended build on OS X, or any >> modern platform for that matter. > > If that is the case then I'd suggest having the link to the unicode > build the only obvious one. Those requiring ANSI builds can be pointed > to the SF.net "Files" page and/or a Unicode vs. ANSI wiki page. > > The current http://wiki.wxpython.org/index.cgi/UnicodeBuild, which > *is* > linked to there, probably already does a good job here. > > >> There aren't any Intel-only binaries, but packages containing >> Universal binaries (built using the Universal MacPython Framework) >> was finished up late last week and are just awaiting being uploaded >> to the wxPython SF site. So it should be pretty soon. > > That's good news. > > >>> Unfortunately I was also able to *install* it on Mac OS X 10.4/ >>> Intel but it doesn't work (importing "wx" fails) because the >>> binary modules in wx are for ppc while the running Python is x86. >> >> Right. About the only thing we could do at this point is to add a >> command-line check on the architecture of the Python binary and bomb >> out if it's incorrect. I could go ahead and add such a test, although >> I think the OS X Installer will just give a generic "you are not >> allowed to install this package" message, which is arguably just as >> confusing to the user.... We could also add ppc to the filename, >> though I think it will easily be missed. > > Yah, Apple's packaging tools are a pain. Great for braindead simple > stuff, but quite limiting for anything custom. > > > Trent > > -- > Trent Mick > TrentM at ActiveState.com From hengist.podd at virgin.net Mon Apr 24 21:07:08 2006 From: hengist.podd at virgin.net (has) Date: Mon, 24 Apr 2006 20:07:08 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <444BE54A.9020703@fas.harvard.edu> <20060423213023.GA16633@uiuc.edu> <6F55D98B-5648-47AA-95EB-2129890E3171@ulaluma.com> <444C19E0.2020307@fas.harvard.edu> <7DA04890-FCA8-49F1-BCDF-0F6A19E9F3F7@redivi.com> Message-ID: Ronald Oussoren wrote: >>+1, I like it! > >Same here. Let's stop here. Agree. Great work. Time to hit the presses. :) has -- http://freespace.virgin.net/hamish.sanderson/ From pecora at anvil.nrl.navy.mil Mon Apr 24 21:13:27 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Mon, 24 Apr 2006 15:13:27 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> Message-ID: <444D2357.3030307@anvil.nrl.navy.mil> Kevin Ollivier wrote: > Hi Trent, Bob, etc. > > Sorry for the late reply. It's been a busy week. I've altered > wxPython's downloads page to hopefully be clearer and more up-to- > date. As for the ANSI/Unicode issue, I made Unicode a little more > prominent but ANSI still gets quite a lot of downloads, so I'm > hesitant to make it hard to get to. But I've made the Unicode builds > the first ones so as to encourage those who don't know/care to just > click on Unicode, so if that does make a big difference in the number > of people who download ANSI, we can re-evaluate moving it later. (I > simply don't know how many people actually need the ANSI build for > their app to work...) I also added the Universal binaries pre-release > build, along with a note explaining the Tiger-only issue and giving a > blueprint for lipo'ing the PPC and Universal builds if anyone wants > to try that to see if it works on Panther. ;-) (I don't have time to > attempt it right now.) URL is here: > > http://wxpython.org/downloads.php > > Thanks, > > Kevin > > Thanks for all that, Kevin. Nice touch putting the uninstaller for the PREvious version in with the new distro. I would have been searching my drive all day to find the old uninstaller. :-) -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From njriley at uiuc.edu Mon Apr 24 21:30:57 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 24 Apr 2006 14:30:57 -0500 Subject: [Pythonmac-SIG] help needed with py2app for self updating application In-Reply-To: <444D1A50.7060402@noaa.gov> References: <2078a7ad0604212016s51e75321ga225ef7c9d1547b3@mail.gmail.com> <2078a7ad0604212039r541be30dl5827f954e7774e6f@mail.gmail.com> <444D1A50.7060402@noaa.gov> Message-ID: <20060424193057.GB29566@uiuc.edu> On Mon, Apr 24, 2006 at 11:34:56AM -0700, Christopher Barker wrote: > SPE Stani's Python Editor wrote: > > One more question which which versions of python and wxPython ship OS > > X 10.2, 10.3 and any version which is still common? (For 10.4 it is > > python2.3.5 and wxPython2.5.3.1 (check with import wx;wx.VERSION). > > | Python | wxPython > 10.2 2.2.? none (this python was pretty broken) > 10.3 | 2.3.1 | none ^^^^^ this is actually 2.3, not 2.3.1. -- Nicholas Riley | From charles.hartman at conncoll.edu Mon Apr 24 21:52:44 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 15:52:44 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> Message-ID: <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> Excellent! Problem, though -- a bone-dumb one, I'm quite sure, but I'm living proof that the unsavvy can run into it: On my Intel iMac I downloaded and installed 1. the Universal-MacPython-2.4.3.dmg (it made a new Applications/ MacPython 2.4 folder, beside my existing Applications/MacPython-2.4 folder) 2. the wxPython2.6-osx-unicode-2.6.3.2rc1-universal10.4-py2.4.dmg In the Terminal "python" gives me the expected version, but "import wx" gives: Python 2.4.3 (#1, Mar 30 2006, 11:02:16) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx Traceback (most recent call last): File "", line 1, in ? File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/wx-2.6-mac-unicode/wx/__init__.py", line 42, in ? from wx._core import * File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", line 4, in ? import _core_ ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac- unicode/wx/_core_.so: Library not loaded: /usr/local/lib/wxPython- unicode-2.6.3.2/lib/libwx_macud-2.6.0.dylib Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core_.so Reason: image not found >>> Charles Hartman P.S. I had /usr/local/bin in my path before. Now I've got: PATH=/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/ local/bin:/ . . . On Apr 24, 2006, at 3:04 PM, Kevin Ollivier wrote: > Hi Trent, Bob, etc. > > Sorry for the late reply. It's been a busy week. I've altered > wxPython's downloads page to hopefully be clearer and more up-to- > date. As for the ANSI/Unicode issue, I made Unicode a little more > prominent but ANSI still gets quite a lot of downloads, so I'm > hesitant to make it hard to get to. But I've made the Unicode builds > the first ones so as to encourage those who don't know/care to just > click on Unicode, so if that does make a big difference in the number > of people who download ANSI, we can re-evaluate moving it later. (I > simply don't know how many people actually need the ANSI build for > their app to work...) I also added the Universal binaries pre-release > build, along with a note explaining the Tiger-only issue and giving a > blueprint for lipo'ing the PPC and Universal builds if anyone wants > to try that to see if it works on Panther. ;-) (I don't have time to > attempt it right now.) URL is here: > > http://wxpython.org/downloads.php > > Thanks, > > Kevin > > On Apr 17, 2006, at 1:26 PM, Trent Mick wrote: > >> [Trent] >>>> wxPython on the Mac seems to be painful right now. >> >> [Kevin Ollivier wrote] >>> Suggestions and contributions welcome! :-) >> >> My apologies, I was being unfairly brief. >> Some suggestions: >> >> - A review of the Mac OS X-related text on >> http://www.wxpython.org/download.php >> Some of that info is misleading: >> >> '''wxPythonOSX needs a "Framework" build of Python 2.3, also >> known as >> MacPython-OSX.''' >> >> To be fair explaining the myriad Python's out there for Mac OS X is >> hard. This sentence though connotes the wrong thing: that >> wxPython is >> only available for Python 2.3. >> >> '''If you would like to try Python 2.4.x on Panther or Tiger then >> you >> can get an installer here''' >> >> Again, to be fair, giving a download link for the current Python >> for >> Mac OS X (whatever that really means) is a moving target. There >> *is* a >> Python installer at that link, but it is no longer a recommended >> one. >> >> As well, some mention of the x86 arch issues would be helpful for >> users. >> >> Okay, *one* suggestion. :) I don't currently use wxPython at all. >> >> >>>> 1. You need to get the correct build for your version of Python. >>>> For >>>> ActivePython 2.4.x or MacPython 2.4.x that means getting one of >>>> the >>>> builds with "-py24" in the package name. >>> >>> Of course, this is pretty much the same as with every other (binary) >>> Python extension, isn't it? >> >> Yes, I didn't mean to imply that wxPython is special here. >> >> >>>> 2. They have "ansi" and "unicode" builds. From what I can tell the >>>> "ansi" builds are probably only useful for Mac OS X 10.2.x >>>> compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater >>>> then I'd stick with the "unicode" builds. >>> >>> The ansi builds are for people who haven't considered Unicode >>> support >>> when building their wxPython apps, and thus might have issues when >>> their data is automatically converted to and from Unicode. In ansi >>> mode, it just passes the actual 'bytes' around, so the user is in >>> total control over how the data is encoded. It took me a couple days >>> of auditing my codebase before I got everything working with >>> Unicode, >>> and while I'm glad I did, up until that point I (and users of my >>> app) >>> were doing just fine with ANSI builds. >>> >>> But yes, in general, Unicode is the recommended build on OS X, or >>> any >>> modern platform for that matter. >> >> If that is the case then I'd suggest having the link to the unicode >> build the only obvious one. Those requiring ANSI builds can be >> pointed >> to the SF.net "Files" page and/or a Unicode vs. ANSI wiki page. >> >> The current http://wiki.wxpython.org/index.cgi/UnicodeBuild, which >> *is* >> linked to there, probably already does a good job here. >> >> >>> There aren't any Intel-only binaries, but packages containing >>> Universal binaries (built using the Universal MacPython Framework) >>> was finished up late last week and are just awaiting being uploaded >>> to the wxPython SF site. So it should be pretty soon. >> >> That's good news. >> >> >>>> Unfortunately I was also able to *install* it on Mac OS X 10.4/ >>>> Intel but it doesn't work (importing "wx" fails) because the >>>> binary modules in wx are for ppc while the running Python is x86. >>> >>> Right. About the only thing we could do at this point is to add a >>> command-line check on the architecture of the Python binary and bomb >>> out if it's incorrect. I could go ahead and add such a test, >>> although >>> I think the OS X Installer will just give a generic "you are not >>> allowed to install this package" message, which is arguably just as >>> confusing to the user.... We could also add ppc to the filename, >>> though I think it will easily be missed. >> >> Yah, Apple's packaging tools are a pain. Great for braindead simple >> stuff, but quite limiting for anything custom. >> >> >> Trent >> >> -- >> Trent Mick >> TrentM at ActiveState.com > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Mon Apr 24 21:54:22 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 12:54:22 -0700 Subject: [Pythonmac-SIG] Applets? In-Reply-To: References: <444D197A.1080202@noaa.gov> Message-ID: <444D2CEE.1060908@noaa.gov> Bob Ippolito wrote: > Technically the current name is py2applet, but it has the standalone > app behavior. So Py2applet is just a new name for Py2app? Why the name change? I kind of liked the App vs. Applet Distinction, and would like to have a way to do either. > I'd like to slap a GUI on it that lets you tweak settings and > generate a setup.py or just build the app, but that's not in the > cards any time soon. To bad, it's a great idea. If it ever happens, and if I (or someone else) every makes the "don't bundle in python" version, it could be a check-box in the GUI. How would you build the GUI? PyObjC? -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 at noaa.gov From charles.hartman at conncoll.edu Mon Apr 24 22:20:56 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 16:20:56 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> Message-ID: <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> On Apr 24, 2006, at 3:52 PM, Charles Hartman wrote: >>>> import wx > Traceback (most recent call last): > File "", line 1, in ? > File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/wx-2.6-mac-unicode/wx/__init__.py", line 42, > in ? > from wx._core import * > File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", line 4, in ? > import _core_ > ImportError: Failure linking new module: /Library/Frameworks/ > Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac- > unicode/wx/_core_.so: Library not loaded: /usr/local/lib/wxPython- > unicode-2.6.3.2/lib/libwx_macud-2.6.0.dylib > Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ > lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core_.so > Reason: image not found I've discovered that I don't have /usr/local/lib/wxPython-unicode-2.6.3.2/lib/libwx_macud-2.6.0.dylib though I *do* haved /usr/local/lib/wxPython-unicode-2.6.3.2rc1/lib/libwx_macud-2.6.0.dylib So something in the installer is out of kilter. What's the best way to fix? I don't want to screw it up worse . . . Charles Hartman From ronaldoussoren at mac.com Mon Apr 24 22:24:35 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 24 Apr 2006 22:24:35 +0200 Subject: [Pythonmac-SIG] Applets? In-Reply-To: <444D197A.1080202@noaa.gov> References: <444D197A.1080202@noaa.gov> Message-ID: On 24-apr-2006, at 20:31, Christopher Barker wrote: > Hi all, > > Along with the icon discussion (they look great, by the way) There has > been a lot of mention of BuildApplet and Py2Applet, etc. I'm a bit > confused as to what actually exists. This is my understanding -- > someone > please clarify if I'm wrong: > > BuildApplication: Builds a complete *.app bundle, including the > entire > python interpreter, etc. Is is not longer being maintained, and may or > may not work in a given instance. IIRC it is even worse than that, it may not have been ported from OS9 at all. > > BuildApplet: Builds a *.app bundle that does not include python, and > thus looks and acts like a "real application", but requires a complete > appropriate python installation. Also no longer maintained, and may or > may not work. This builds an application bundle that contains a single python file and depends on the installed python and site-packages to run. > > Oh, and BuildApplication and BuildApplet are not going to be > included in > future versions. I'm entertaining the thought of dropping BuildApplet. But as it solves a real need I might improve it instead (mostly testing and better documentation). Ronald From bob at redivi.com Mon Apr 24 22:29:59 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 24 Apr 2006 13:29:59 -0700 Subject: [Pythonmac-SIG] Applets? In-Reply-To: <444D2CEE.1060908@noaa.gov> References: <444D197A.1080202@noaa.gov> <444D2CEE.1060908@noaa.gov> Message-ID: <767E17D5-D242-4663-BB9B-AA23A8B65A3A@redivi.com> On Apr 24, 2006, at 12:54 PM, Christopher Barker wrote: > Bob Ippolito wrote: > >> Technically the current name is py2applet, but it has the standalone >> app behavior. > > So Py2applet is just a new name for Py2app? Why the name change? I > kind > of liked the App vs. Applet Distinction, and would like to have a > way to > do either. No. py2applet is the drag and drop application (and command-line utility) that tries to make an application out of a bunch of junk you pass to it (script, icon, plist, data files, etc.). It's a lot like BuildApplet in theory, it just happens to make a stand-alone application instead of something tiny. >> I'd like to slap a GUI on it that lets you tweak settings and >> generate a setup.py or just build the app, but that's not in the >> cards any time soon. > > To bad, it's a great idea. If it ever happens, and if I (or someone > else) every makes the "don't bundle in python" version, it could be a > check-box in the GUI. > > How would you build the GUI? PyObjC? Yes. -bob From charles.hartman at conncoll.edu Mon Apr 24 22:38:47 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 16:38:47 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> Message-ID: <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> On Apr 24, 2006, at 4:20 PM, Charles Hartman wrote: > > On Apr 24, 2006, at 3:52 PM, Charles Hartman wrote: > >>>>> import wx >> Traceback (most recent call last): >> File "", line 1, in ? >> File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/wx-2.6-mac-unicode/wx/__init__.py", line 42, >> in ? >> from wx._core import * >> File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ >> python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", line 4, in ? >> import _core_ >> ImportError: Failure linking new module: /Library/Frameworks/ >> Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac- >> unicode/wx/_core_.so: Library not loaded: /usr/local/lib/wxPython- >> unicode-2.6.3.2/lib/libwx_macud-2.6.0.dylib >> Referenced from: /Library/Frameworks/Python.framework/Versions/ >> 2.4/ >> lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core_.so >> Reason: image not found > > I've discovered that I don't have > /usr/local/lib/wxPython-unicode-2.6.3.2/lib/libwx_macud-2.6.0.dylib > though I *do* haved > /usr/local/lib/wxPython-unicode-2.6.3.2rc1/lib/ > libwx_macud-2.6.0.dylib > > So something in the installer is out of kilter. > > What's the best way to fix? I don't want to screw it up worse . . . > > Charles Hartman I did the "obvious": sudo mv /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/lib/ wxPython-unicode-2.6.3.2 and it seems to work. Did I create havoc somewhere else? COH From Chris.Barker at noaa.gov Mon Apr 24 22:59:00 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 13:59:00 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> Message-ID: <444D3C14.3010006@noaa.gov> Charles Hartman wrote: > I did the "obvious": > sudo mv /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/lib/ > wxPython-unicode-2.6.3.2 > and it seems to work. Did I create havoc somewhere else? probably not, but in general, you should use a sym link, rather than a re-name: sudo ln -s /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/lib/wxPython-unicode-2.6.3.2 however, it looks like you're installing the new Universal build of wxPython into ActivePython. It may well work, but I think the Universal wxPython was built with and designed for the UniversalBuild at: http://pythonmac.org/packages/py24-fat/ I don't think ActivePython has a Universal Build yet. That may explain a few of your oddities. By the way, we should put a copy of the wxPython dmg on http://pythonmac.org as well as on the wxPython site. -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 at noaa.gov From Chris.Barker at noaa.gov Mon Apr 24 23:08:53 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 14:08:53 -0700 Subject: [Pythonmac-SIG] Applets? In-Reply-To: References: <444D197A.1080202@noaa.gov> Message-ID: <444D3E65.2070708@noaa.gov> Ronald Oussoren wrote: > I'm entertaining the thought of dropping BuildApplet. But as it solves a > real need I might improve it instead (mostly testing and better > documentation). I also think it solves a real need. But I'd probably rather see it based on the Py2App code. I don't know that code, but I can't imagine it's that hard to have not include any files in the Python Framework tree, but otherwise behave the same. -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 at noaa.gov From charles.hartman at conncoll.edu Tue Apr 25 00:13:56 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 18:13:56 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <444D3C14.3010006@noaa.gov> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> Message-ID: On Apr 24, 2006, at 4:59 PM, Christopher Barker wrote: > Charles Hartman wrote: >> I did the "obvious": >> sudo mv /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >> lib/ wxPython-unicode-2.6.3.2 >> and it seems to work. Did I create havoc somewhere else? > > probably not, but in general, you should use a sym link, rather > than a re-name: > > sudo ln -s /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ > lib/wxPython-unicode-2.6.3.2 > > > however, it looks like you're installing the new Universal build of > wxPython into ActivePython. It may well work, but I think the > Universal wxPython was built with and designed for the > UniversalBuild at: > Something is very screwy here. Because I've been waiting for wxPython before trying the Universal, I followed links, not from here, but from wxpython.org/download.php ("You will need the Universal MacPython available from Python.org") which took me to www.python.org/ download/releases/2.4.3 where there is a link to "Universal- MacPython-2.4.3.dmg". I assumed I was getting Ronald's build. Is it ActiveState's??? Perhaps -- to put it calmly -- there should a note to this effect? Can I now just download the one from pythonmac.org ("Universal- MacPython-2.4.3-2006-04-07.dmg") and install it, and expect things to work? If you ask me (or even if you don't) this is a fiasco of links. Yes, I was clicking a little cavlierly. But I've been a bystander through a lot of this -- and if I can end up with the wrong (and in a way non- functioning) universal build if Python for Mac, we've got, I submit, a problem for new users. Charles Hartman > http://pythonmac.org/packages/py24-fat/ > > I don't think ActivePython has a Universal Build yet. > > That may explain a few of your oddities. > > By the way, we should put a copy of the wxPython dmg on http:// > pythonmac.org as well as on the wxPython site. > > > > -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 at noaa.gov From kevino at theolliviers.com Tue Apr 25 00:27:59 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Mon, 24 Apr 2006 15:27:59 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> Message-ID: Hi Charles, On Apr 24, 2006, at 3:13 PM, Charles Hartman wrote: > > On Apr 24, 2006, at 4:59 PM, Christopher Barker wrote: > >> Charles Hartman wrote: >>> I did the "obvious": >>> sudo mv /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >>> lib/ wxPython-unicode-2.6.3.2 >>> and it seems to work. Did I create havoc somewhere else? >> >> probably not, but in general, you should use a sym link, rather >> than a re-name: >> >> sudo ln -s /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >> lib/wxPython-unicode-2.6.3.2 >> >> >> however, it looks like you're installing the new Universal build of >> wxPython into ActivePython. It may well work, but I think the >> Universal wxPython was built with and designed for the >> UniversalBuild at: >> > > Something is very screwy here. Because I've been waiting for wxPython > before trying the Universal, I followed links, not from here, but > from wxpython.org/download.php ("You will need the Universal > MacPython available from Python.org") which took me to www.python.org/ > download/releases/2.4.3 where there is a link to "Universal- > MacPython-2.4.3.dmg". I assumed I was getting Ronald's build. Is it > ActiveState's??? Perhaps -- to put it calmly -- there should a note > to this effect? I don't think so. I think I need to go back and check the build scripts, as I may not have added the rc1 in every place that I need to. It really should be in the directory name that gets installed. (I'm surprised it worked on my machine, though.) I'll take a look at it later today. Sorry for the trouble! Kevin > Can I now just download the one from pythonmac.org ("Universal- > MacPython-2.4.3-2006-04-07.dmg") and install it, and expect things to > work? > > If you ask me (or even if you don't) this is a fiasco of links. Yes, > I was clicking a little cavlierly. But I've been a bystander through > a lot of this -- and if I can end up with the wrong (and in a way non- > functioning) universal build if Python for Mac, we've got, I submit, > a problem for new users. > > Charles Hartman > >> http://pythonmac.org/packages/py24-fat/ >> >> I don't think ActivePython has a Universal Build yet. >> >> That may explain a few of your oddities. >> >> By the way, we should put a copy of the wxPython dmg on http:// >> pythonmac.org as well as on the wxPython site. >> >> >> >> -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 at noaa.gov > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Tue Apr 25 00:29:21 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 24 Apr 2006 15:29:21 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> Message-ID: <444D5141.4000601@noaa.gov> Charles Hartman wrote: > I assumed I was getting Ronald's build. > Is it ActiveState's??? The title of this thread is """Installing wxPython with ActivePython and OSX""" ActivePython is ActiveState's Python, which is why I thought you were using it. Perhaps it's only the thread title that's wrong. Sorry if I confused you! > If you ask me (or even if you don't) this is a fiasco of links. It is a bit, but once we have the critical packages working with the Universal build, I think it can settle down. I find the ActiveState thing a bit annoying - are they really adding any value? Maybe they are, as I haven't tried it, I don't know. I'll go try the Universal wxPython now, and report back. -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 at noaa.gov From bob at redivi.com Tue Apr 25 01:24:17 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 24 Apr 2006 16:24:17 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> Message-ID: <49041394-8154-4C54-9AED-EDB0B6B30DEA@redivi.com> On Apr 24, 2006, at 3:13 PM, Charles Hartman wrote: > > On Apr 24, 2006, at 4:59 PM, Christopher Barker wrote: > >> Charles Hartman wrote: >>> I did the "obvious": >>> sudo mv /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >>> lib/ wxPython-unicode-2.6.3.2 >>> and it seems to work. Did I create havoc somewhere else? >> >> probably not, but in general, you should use a sym link, rather >> than a re-name: >> >> sudo ln -s /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >> lib/wxPython-unicode-2.6.3.2 >> >> >> however, it looks like you're installing the new Universal build of >> wxPython into ActivePython. It may well work, but I think the >> Universal wxPython was built with and designed for the >> UniversalBuild at: >> > > Something is very screwy here. Because I've been waiting for wxPython > before trying the Universal, I followed links, not from here, but > from wxpython.org/download.php ("You will need the Universal > MacPython available from Python.org") which took me to www.python.org/ > download/releases/2.4.3 where there is a link to "Universal- > MacPython-2.4.3.dmg". I assumed I was getting Ronald's build. Is it > ActiveState's??? Perhaps -- to put it calmly -- there should a note > to this effect? Do not download from python.org. Unless they've updated it recently, that's the unoptimized (about twice as slow on either platform) older version with a couple errata. > Can I now just download the one from pythonmac.org ("Universal- > MacPython-2.4.3-2006-04-07.dmg") and install it, and expect things to > work? That's the most recent Unviersal Python, but I'm not sure if you can expect wxPython to work or not :) -bob From charles.hartman at conncoll.edu Tue Apr 25 01:47:22 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 19:47:22 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <49041394-8154-4C54-9AED-EDB0B6B30DEA@redivi.com> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> <49041394-8154-4C54-9AED-EDB0B6B30DEA@redivi.com> Message-ID: <55FFF516-4FB6-4D8A-9DE5-D30AB872194F@conncoll.edu> Thanks to Chris, Kevin, and Bob. Yes, I should have changed the thread name. I stayed with it because it's where Kevin posted the good news about wxPython. Maybe I'm missing something, but isn't it awfully silly to have these competing versions around, with names and apparent pedigrees similar enough so that, for instance, if somebody stumbles onto this list asking about problems with "this new Universal binary of Python 2.4 I just installed," it won't take two rounds of messages even to find out what version it is? How anyone could guess that pythonmac.org/ packages has the current best while the one at python.org/download/ releases is obsolete, is beyond me. This is not doing any good for all the fine bring-in-the-newbies work that's been going on (revivified website, spanking new icons, etc). I can happily report, though, that *either* Universal build of Python- for-the-Macintosh 2.4 seems to work with the pre-release Universal of wxPython 2.6.3.2 -- after something's done to fix the lib location. Charles Hartman On Apr 24, 2006, at 7:24 PM, Bob Ippolito wrote: > > On Apr 24, 2006, at 3:13 PM, Charles Hartman wrote: > >> >> On Apr 24, 2006, at 4:59 PM, Christopher Barker wrote: >> >>> Charles Hartman wrote: >>>> I did the "obvious": >>>> sudo mv /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >>>> lib/ wxPython-unicode-2.6.3.2 >>>> and it seems to work. Did I create havoc somewhere else? >>> >>> probably not, but in general, you should use a sym link, rather >>> than a re-name: >>> >>> sudo ln -s /usr/local/lib/wxPython-unicode-2.6.3.2rc1 /usr/local/ >>> lib/wxPython-unicode-2.6.3.2 >>> >>> >>> however, it looks like you're installing the new Universal build of >>> wxPython into ActivePython. It may well work, but I think the >>> Universal wxPython was built with and designed for the >>> UniversalBuild at: >>> >> >> Something is very screwy here. Because I've been waiting for wxPython >> before trying the Universal, I followed links, not from here, but >> from wxpython.org/download.php ("You will need the Universal >> MacPython available from Python.org") which took me to >> www.python.org/ >> download/releases/2.4.3 where there is a link to "Universal- >> MacPython-2.4.3.dmg". I assumed I was getting Ronald's build. Is it >> ActiveState's??? Perhaps -- to put it calmly -- there should a note >> to this effect? > > Do not download from python.org. Unless they've updated it > recently, that's the unoptimized (about twice as slow on either > platform) older version with a couple errata. > >> Can I now just download the one from pythonmac.org ("Universal- >> MacPython-2.4.3-2006-04-07.dmg") and install it, and expect things to >> work? > > That's the most recent Unviersal Python, but I'm not sure if you > can expect wxPython to work or not :) > > -bob > From bob at redivi.com Tue Apr 25 01:53:33 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 24 Apr 2006 16:53:33 -0700 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <55FFF516-4FB6-4D8A-9DE5-D30AB872194F@conncoll.edu> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> <49041394-8154-4C54-9AED-EDB0B6B30DEA@redivi.com> <55FFF516-4FB6-4D8A-9DE5-D30AB872194F@conncoll.edu> Message-ID: <870B8249-E8CB-44CB-89E3-B8B8F5A350E0@redivi.com> On Apr 24, 2006, at 4:47 PM, Charles Hartman wrote: > Thanks to Chris, Kevin, and Bob. Yes, I should have changed the > thread name. I stayed with it because it's where Kevin posted the > good news about wxPython. > > Maybe I'm missing something, but isn't it awfully silly to have > these competing versions around, with names and apparent pedigrees > similar enough so that, for instance, if somebody stumbles onto > this list asking about problems with "this new Universal binary of > Python 2.4 I just installed," it won't take two rounds of messages > even to find out what version it is? How anyone could guess that > pythonmac.org/packages has the current best while the one at > python.org/download/releases is obsolete, is beyond me. This is not > doing any good for all the fine bring-in-the-newbies work that's > been going on (revivified website, spanking new icons, etc). Well no kidding. I don't personally have access to the python.org server and neither does Ronald. I don't think either of us asked for it to be posted there, it wasn't ready at the time. I'm not sure who's supposed to fix it either. -bob From charles.hartman at conncoll.edu Tue Apr 25 02:13:22 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Mon, 24 Apr 2006 20:13:22 -0400 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <870B8249-E8CB-44CB-89E3-B8B8F5A350E0@redivi.com> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> <49041394-8154-4C54-9AED-EDB0B6B30DEA@redivi.com> <55FFF516-4FB6-4D8A-9DE5-D30AB872194F@conncoll.edu> <870B8249-E8CB-44CB-89E3-B8B8F5A350E0@redivi.com> Message-ID: On Apr 24, 2006, at 7:53 PM, Bob Ippolito wrote: > > On Apr 24, 2006, at 4:47 PM, Charles Hartman wrote: > >> Thanks to Chris, Kevin, and Bob. Yes, I should have changed the >> thread name. I stayed with it because it's where Kevin posted the >> good news about wxPython. >> >> Maybe I'm missing something, but isn't it awfully silly to have >> these competing versions around, with names and apparent pedigrees >> similar enough so that, for instance, if somebody stumbles onto >> this list asking about problems with "this new Universal binary of >> Python 2.4 I just installed," it won't take two rounds of messages >> even to find out what version it is? How anyone could guess that >> pythonmac.org/packages has the current best while the one at >> python.org/download/releases is obsolete, is beyond me. This is >> not doing any good for all the fine bring-in-the-newbies work >> that's been going on (revivified website, spanking new icons, etc). > > Well no kidding. I don't personally have access to the python.org > server and neither does Ronald. I don't think either of us asked > for it to be posted there, it wasn't ready at the time. I'm not > sure who's supposed to fix it either. I've filed a site bug report on python.org. Charles From janssen at parc.com Tue Apr 25 02:16:00 2006 From: janssen at parc.com (Bill Janssen) Date: Mon, 24 Apr 2006 17:16:00 PDT Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: Your message of "Mon, 24 Apr 2006 16:53:33 PDT." <870B8249-E8CB-44CB-89E3-B8B8F5A350E0@redivi.com> Message-ID: <06Apr24.171604pdt."58633"@synergy1.parc.xerox.com> > Well no kidding. I don't personally have access to the python.org > server and neither does Ronald. I don't think either of us asked for > it to be posted there, it wasn't ready at the time. I'm not sure > who's supposed to fix it either. I do. I'll see what can be done. I favor taking pointers off the "releases" page and pointing it to the "downloads" page. Bill From mark at mophilly.com Tue Apr 25 02:52:07 2006 From: mark at mophilly.com (Mark Phillips) Date: Mon, 24 Apr 2006 17:52:07 -0700 Subject: [Pythonmac-SIG] pycrypto and gcc 4 Message-ID: <14BAFB63-6502-4B92-9475-787EE4E79BAE@mophilly.com> Yesterday I attempted to install the pycrypto package. "setup.py build" invoked gcc, which threw a huge number of errors on signedness. As it was taco time, I left for the day. Today, I read through some lists and the "signedness" errors for gcc v4 sounded benign so I ran the build again. This time it sailed through without errors. Feeling bold and a bit light on coffee, I set aside the obvious concerns and ran "setup.py install". No errors were raised. Alas, my bubble of ignorance was burst rather quickly by IDLE. "import Crypto.Cipher" fails on ImportError: No module named Crypto. Crypto and other files are in site-packages. I have the Universal-MacPython-2.4.3-2006-04-07 installed on Mac OS 10.4.6 PPC. I thought (hoped) that since pycrypto setup builds from source I would slip through without a problem. Ah, well, so, what to do next? TIA, - Mark From mark at mophilly.com Tue Apr 25 03:11:20 2006 From: mark at mophilly.com (Mark Phillips) Date: Mon, 24 Apr 2006 18:11:20 -0700 Subject: [Pythonmac-SIG] pycrypto and gcc 4 In-Reply-To: <14BAFB63-6502-4B92-9475-787EE4E79BAE@mophilly.com> References: <14BAFB63-6502-4B92-9475-787EE4E79BAE@mophilly.com> Message-ID: I forgot to mention one important fact: the test.py included in pycrypto ran fine, and raised no errors, when I ran it immediately following the build/install efforts. On Apr 24, 2006, at 5:52 PM, Mark Phillips wrote: > Yesterday I attempted to install the pycrypto package. "setup.py > build" invoked gcc, which threw a huge number of errors on > signedness. As it was taco time, I left for the day. > > Today, I read through some lists and the "signedness" errors for gcc > v4 sounded benign so I ran the build again. This time it sailed > through without errors. Feeling bold and a bit light on coffee, I set > aside the obvious concerns and ran "setup.py install". No errors were > raised. > > Alas, my bubble of ignorance was burst rather quickly by IDLE. > "import Crypto.Cipher" fails on ImportError: No module named Crypto. > Crypto and other files are in site-packages. > > I have the Universal-MacPython-2.4.3-2006-04-07 installed on Mac OS > 10.4.6 PPC. I thought (hoped) that since pycrypto setup builds from > source I would slip through without a problem. > > Ah, well, so, what to do next? > > TIA, > > - Mark > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From daniellord at mac.com Tue Apr 25 04:04:51 2006 From: daniellord at mac.com (Daniel Lord) Date: Mon, 24 Apr 2006 19:04:51 -0700 Subject: [Pythonmac-SIG] New wiki entry on Universal libraries and extensions In-Reply-To: <444D157A.3040607@noaa.gov> References: <3247ECA0-5401-43D1-A9D4-A6B74A88C588@mac.com> <444D157A.3040607@noaa.gov> Message-ID: <2E07982A-10B2-4487-87C5-633E950E9DB0@mac.com> On Apr 24, 2006, at 11:14, Christopher Barker wrote: > My primary comment is that you're discussing building a Universal > package, but keeping the external libs installed with the standard > "make > install". I haven't tried your scheme yet, but usually that results in > dynamic libs being built, sometimes by themselves, and sometimes along > with the static libs. The trick here is that you can sometimes get the > dynamic libs instead of the static ones when you link. Either way, it > will work fine on your system, but there's really no point in > building a > Universal Package if you're not trying to distribute it (or a Py2App > bundle built with it) Good point. In fact, though I was able to compile 'FAT' static libs, the shared libs are all just i386--I just now checked. BUt I linked against the static lib so things are fine this time, but more care in the future to ensure the shared libs are not found would be prudent and I'll take note of it. From jrus at fas.harvard.edu Tue Apr 25 04:12:52 2006 From: jrus at fas.harvard.edu (Jacob Rus) Date: Mon, 24 Apr 2006 22:12:52 -0400 Subject: [Pythonmac-SIG] [PSF-Board] New artwork for the OSX port In-Reply-To: <1F5523ED-A1EC-41B0-9662-3C5D06AA0B0B@mac.com> References: <444A9617.4050702@holdenweb.com> <1F5523ED-A1EC-41B0-9662-3C5D06AA0B0B@mac.com> Message-ID: <9F59A246-AFAF-4365-8C9C-0ED637E252B4@fas.harvard.edu> Hi. > p.s. how do people like the new logo over in pythonmac land? It's okay, but our version[1, 2] is shinier. ;) [1]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png [2]: http://hcs.harvard.edu/~jrus/python/prettified-py-icons.png > The standard contribution form filled out by the originator should > suffice. See http://www.python.org/psf/contrib/ for details. So I'm supposed to sign the form and fax/mail it in? > What kind of attribution would you like? I'll definitely add a > readme file to the distribution that mentions you designed these > icons. Anything else is open for discussion. That seems fine. Is there some file that lists all the people who have contributed in other ways to the Mac Python distributions? It seems that right now the readme only has some links to websites. In IDLE.app, the application menu only has a general "About Tcl & Tk", though PythonLauncher.app does seem to have an about box crediting Jack Jansen, and the now defunct PythonIDE.app has an about box crediting Just Van Rossum. There are surely more people than those two involved in getting Mac Python into users' hands. -Jacob On Apr 23, 2006, at 8:06 AM, Ronald Oussoren wrote: > Jacob, > > This is the reply I got from the PSF w.r.t. the icons. Tim Parkin, > who created the new python.org logo, also gave permission to use > the logo in the icons (see the second message). > > What kind of attribution would you like? I'll definitely add a > readme file to the distribution that mentions you designed these > icons. Anything else is open for discussion. > > Ronald > > Begin forwarded message: >> From: Steve Holden >> Date: 22 april 2006 22:46:15 GMT+02:00 >> To: Ronald Oussoren >> Subject: Re: [PSF-Board] New artwork for the OSX port >> >> Ronald Oussoren wrote: >>> Hi, >>> Guido forwarded me to you for this. >>> Over on the pytonmac-sig we've almost reached consensus on some >>> new artwork for the OSX port. These are icons for python files >>> and several applications that use the new python.org logo. >>> I'm wondering what the preconditions are for getting these into >>> the python distribution. Does the author/artist have to donate >>> them to the PSF or are there other rules? >> The standard contribution form filled out by the originator should >> suffice. It grants the PSF permission to republish under the >> Python license agreement. Nothing else should be required. See >> >> http://www.python.org/psf/contrib/ >> >> for details. >> >> regards >> Steve > > Begin forwarded message: >> From: Tim Parkin >> Date: 22 april 2006 21:48:11 GMT+02:00 >> To: ronaldoussoren at mac.com >> Subject: re: python logo icon etc >> >> Hi, >> >> I noticed the post on python-dev about the new logo/icons.. I need to >> pass ownership over to the PSF at some point (nobody has told me how >> yet) but being as I currently own license I could officially say 'yes >> please use them' :-) >> >> I don't think anyone is going to have any objection but it would >> be best >> to post to psf anyway. >> >> Cheers >> >> Tim >> >> p.s. how do people like the new logo over in pythonmac land? From ronaldoussoren at mac.com Tue Apr 25 08:08:27 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 25 Apr 2006 08:08:27 +0200 Subject: [Pythonmac-SIG] Installing wxPython with ActivePython and OSX In-Reply-To: <870B8249-E8CB-44CB-89E3-B8B8F5A350E0@redivi.com> References: <20060417184424.GK24200@activestate.com> <20060417202630.GB28644@activestate.com> <141C5E10-DA43-44C6-87CE-6864FCF3C276@conncoll.edu> <7DE985F2-AC49-492B-BBC2-002F1F342A7C@conncoll.edu> <65C6CCE2-1C57-43E8-A36C-392CA4E4B27C@conncoll.edu> <444D3C14.3010006@noaa.gov> <49041394-8154-4C54-9AED-EDB0B6B30DEA@redivi.com> <55FFF516-4FB6-4D8A-9DE5-D30AB872194F@conncoll.edu> <870B8249-E8CB-44CB-89E3-B8B8F5A350E0@redivi.com> Message-ID: On 25-apr-2006, at 1:53, Bob Ippolito wrote: > > On Apr 24, 2006, at 4:47 PM, Charles Hartman wrote: > >> Thanks to Chris, Kevin, and Bob. Yes, I should have changed the >> thread name. I stayed with it because it's where Kevin posted the >> good news about wxPython. >> > > Well no kidding. I don't personally have access to the python.org > server and neither does Ronald. I don't think either of us asked for > it to be posted there, it wasn't ready at the time. I'm not sure > who's supposed to fix it either. The version at python.org was posted there because I asked for it. I have asked Anthony to upload the latest version, but so far he hasn't reacted yet. Ronald > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Tue Apr 25 10:45:46 2006 From: hengist.podd at virgin.net (has) Date: Tue, 25 Apr 2006 09:45:46 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: One last thing: looking at the shiny new icon set I realised there wasn't a specific icon done for Python.app, which gets launched whenever Python needs a Window Manager connection. (Can't imagine who forgot to put that on the list...) However, with both BB and py2app using the same icons the 'applet' icon is essentially going spare, and I think it'd be an ideal choice for Python.app: clean, simple, app-ish looking, and a nice big highly visible snake logo that'll show up well in the Dock. (Plus it avoids having to do any additional artwork.:) Alternatively, just the snakes by themselves would do the trick. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From jmgore75 at gmail.com Mon Apr 24 21:06:08 2006 From: jmgore75 at gmail.com (Jeremy Gore) Date: Mon, 24 Apr 2006 15:06:08 -0400 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: References: Message-ID: <9E9AB9D6-A656-4F25-8F87-8FC0FCA6D726@gmail.com> On Apr 24, 2006, at 1:42 PM, Bob Ippolito wrote: > > On Apr 23, 2006, at 4:28 PM, Jeremy wrote: > >> I use the old Numeric package quite a bit (numpy is just not ready >> for primetime) and stupid me, I didn't check if it was available >> before I installed the Universal binary package for python 2.4.3. >> Rather than moving backwards, I'd like to try getting it to compile. >> However, I can't seem to find the cvs/svn with the most recent >> configuration files. Where are those? >> >> I'd also like to install numarray, numpy, and scipy. (numpy won't >> compile due to "can't locate file for : -lcc_dynamic"; this was also >> a problem for the sources of numarray and Numeric) >> >> I'm running a MacBookPro with 10.4.6. > > Are you sure you have the latest Xcode installed with the 10.4u > SDK? -lcc_dynamic sounds like compiler mismatch or something. > > -bob I have the latest Xcode, and the 10.4u SDK is installed. The same thing happens whether or not /usr/local/lib/libcc_dynamic.a is absent or is symlinked to /usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a. gcc --version: i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /usr/bin/gcc Here's the output of Numeric 24.2 python setup.py build; the main problem seems to be the -lcc_dynamic flag, although the -framework vecLib flag also seems to be raising problems. Either that or -arch i386. : running build running build_py creating build creating build/lib.macosx-10.4-fat-2.4 copying Lib/ArrayPrinter.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/LinearAlgebra.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/Matrix.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/MLab.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/Numeric.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/numeric_version.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/Precision.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/RandomArray.py -> build/lib.macosx-10.4-fat-2.4 copying Lib/UserArray.py -> build/lib.macosx-10.4-fat-2.4 creating build/lib.macosx-10.4-fat-2.4/FFT copying Packages/FFT/Lib/__init__.py -> build/lib.macosx-10.4-fat-2.4/ FFT copying Packages/FFT/Lib/FFT.py -> build/lib.macosx-10.4-fat-2.4/FFT creating build/lib.macosx-10.4-fat-2.4/MA copying Packages/MA/Lib/__init__.py -> build/lib.macosx-10.4-fat-2.4/MA copying Packages/MA/Lib/MA.py -> build/lib.macosx-10.4-fat-2.4/MA copying Packages/MA/Lib/MA_version.py -> build/lib.macosx-10.4- fat-2.4/MA creating build/lib.macosx-10.4-fat-2.4/RNG copying Packages/RNG/Lib/__init__.py -> build/lib.macosx-10.4-fat-2.4/ RNG copying Packages/RNG/Lib/Statistics.py -> build/lib.macosx-10.4- fat-2.4/RNG creating build/lib.macosx-10.4-fat-2.4/dotblas copying Packages/dotblas/dotblas/__init__.py -> build/lib.macosx-10.4- fat-2.4/dotblas creating build/lib.macosx-10.4-fat-2.4/Numeric_headers copying Include/__init__.py -> build/lib.macosx-10.4-fat-2.4/ Numeric_headers creating build/lib.macosx-10.4-fat-2.4/Numeric_headers/Numeric copying Include/Numeric/arrayobject.h -> build/lib.macosx-10.4- fat-2.4/Numeric_headers/Numeric copying Include/Numeric/f2c.h -> build/lib.macosx-10.4-fat-2.4/ Numeric_headers/Numeric copying Include/Numeric/ranlib.h -> build/lib.macosx-10.4-fat-2.4/ Numeric_headers/Numeric copying Include/Numeric/ufuncobject.h -> build/lib.macosx-10.4- fat-2.4/Numeric_headers/Numeric running build_ext building '_numpy' extension creating build/temp.macosx-10.4-fat-2.4 creating build/temp.macosx-10.4-fat-2.4/Src gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -faltivec -lcc_dynamic -framework vecLib -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Src/_numpymodule.c -o build/temp.macosx-10.4-fat-2.4/Src/_numpymodule.o i686-apple-darwin8-gcc-4.0.1: -lcc_dynamic: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: vecLib: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -lcc_dynamic: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: vecLib: linker input file unused because linking not done gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -faltivec -lcc_dynamic -framework vecLib -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Src/arrayobject.c -o build/temp.macosx-10.4-fat-2.4/Src/arrayobject.o i686-apple-darwin8-gcc-4.0.1: -lcc_dynamic: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: vecLib: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -lcc_dynamic: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: vecLib: linker input file unused because linking not done gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -faltivec -lcc_dynamic -framework vecLib -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/ Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Src/ufuncobject.c -o build/temp.macosx-10.4-fat-2.4/Src/ufuncobject.o powerpc-apple-darwin8-gcc-4.0.1: -lcc_dynamic: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done powerpc-apple-darwin8-gcc-4.0.1: vecLib: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -lcc_dynamic: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: -framework: linker input file unused because linking not done i686-apple-darwin8-gcc-4.0.1: vecLib: linker input file unused because linking not done gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup -faltivec -lcc_dynamic -framework vecLib build/temp.macosx-10.4-fat-2.4/Src/_numpymodule.o build/ temp.macosx-10.4-fat-2.4/Src/arrayobject.o build/temp.macosx-10.4- fat-2.4/Src/ufuncobject.o -o build/lib.macosx-10.4-fat-2.4/_numpy.so /usr/bin/ld: for architecture i386 /usr/bin/ld: can't locate file for: -lcc_dynamic collect2: ld returned 1 exit status /usr/bin/ld: for architecture ppc /usr/bin/ld: can't locate file for: -lcc_dynamic collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccCKxQm1.out (No such file or directory) error: command 'gcc' failed with exit status 1 Why is it linking ALWAYS causes problems? Whose bright idea was it to spread all these unix programs and their associated files across dozens of directories anyway? Frameworks don't seem that counter intuitive and they're a lot cleaner. From nicholas.cole at gmail.com Tue Apr 25 12:33:13 2006 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 25 Apr 2006 12:33:13 +0200 Subject: [Pythonmac-SIG] Fwd: more OS X oddities In-Reply-To: <2mirp8l9jv.fsf@starship.python.net> References: <20060415181953.GA10371@crayon.invisible-island.net> <2mirp8l9jv.fsf@starship.python.net> Message-ID: On 4/17/06, Michael Hudson wrote: > > I think this has to do with your terminal emulator more than anything. > Try it in an xterm (if you have x11 installed...). I think you're right that it is to do with the terminal emulation. Results of some quick testing (on Tiger): F1-4 do not work correctly. F5-8 and F13 work correctly in both xterm and Terminal.app Meta keys are correctly reported in xterm. (using Alt/option as meta). This is where it gets interesting. In Terminal.app if "Use Option Key as Meta key" is selected in the window settings dialog, it actually seems to become impossible to type any meta chars at all. On my system these keypresses seem to become just normal character keys. If "Use Option as Meta Key" is not selected, option-keypress produces strange results. The interesting thing is that these are identical to using the Apple- key as a modifier under X11. >From which I think we conclude that the terminal emulation is a strange mess. :-) The only real oddity is that when "option" is supposed to be acting as a meta key python/curses doesn't seem to see that it is being pressed at all. But this could well be yet another emulator bug. :-) Best, N. From brendansimons at yahoo.ca Tue Apr 25 15:15:15 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue, 25 Apr 2006 09:15:15 -0400 (EDT) Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup Message-ID: <20060425131515.34552.qmail@web31110.mail.mud.yahoo.com> Oh, I thought that's what the Python Launcher did. A bouncing rocket in the dock is a pretty good cue that Python is launching something. So I'm +1 on using the current Python Launcher icon If not that then (is the launcher actually used otherwise?) I'm +0 on just the glassy logo. Brendan -- Brendan Simons On 25-Apr-06, at 5:33 AM, pythonmac-sig-request at python.org wrote: >From: has >Date: April 25, 2006 4:45:46 AM EDT (CA) >To: pythonmac-sig at python.org >Cc: jrus at fas.harvard.edu >Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > >One last thing: looking at the shiny new icon set I realised there >wasn't a specific icon done for Python.app, which gets launched >whenever Python needs a Window Manager connection. (Can't >imagine who forgot to put that on the list...) > >However, with both BB and py2app using the same icons the 'applet' >icon is essentially going spare, and I think it'd be an ideal choice for >Python.app: clean, simple, app-ish looking, and a nice big highly >visible snake logo that'll show up well in the Dock. (Plus it avoids >having to do any additional artwork.:) Alternatively, just the snakes >by themselves would do the trick. > >HTH > >has >-- >http://freespace.virgin.net/hamish.sanderson/ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ronaldoussoren at mac.com Tue Apr 25 15:29:34 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 25 Apr 2006 15:29:34 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <20060425131515.34552.qmail@web31110.mail.mud.yahoo.com> References: <20060425131515.34552.qmail@web31110.mail.mud.yahoo.com> Message-ID: <8A4C6385-7F9B-4A95-B45E-3451B6193499@mac.com> On 25-apr-2006, at 15:15, Brendan Simons wrote: > Oh, > > I thought that's what the Python Launcher did. A > bouncing rocket in the dock is a pretty good cue that > Python is launching something. So I'm +1 on using the > current Python Launcher icon > > If not that then (is the launcher actually used > otherwise?) I'm +0 on just the glassy logo. I'm going to use the rocket of the Python.app that is inside the framework and will use the same icon for Python Launcher. The latter is a tool that can be used to run python files by double-clicking on them. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060425/d29ad4b3/attachment.bin From brendansimons at yahoo.ca Tue Apr 25 19:09:19 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue, 25 Apr 2006 13:09:19 -0400 (EDT) Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <8A4C6385-7F9B-4A95-B45E-3451B6193499@mac.com> Message-ID: <20060425170919.69953.qmail@web31104.mail.mud.yahoo.com> OK, I obviously need to learn a little about the launch sequence of mac python files. Here's what I've discovered: 1) Double clicking a terminal-based python script from finder launches PythonLauncher (soon to be a rocket icon), then the terminal. 2) Running a wx.python script from TextWrangler using #!/usr/bin/pythonw skips PythonLauncher, and leaves a "Python" icon (just the 16 ton weight) in the dock until I quit the wx.app. Is this the "Python.app" from the framework? 3) Double clicking a wx.python script from finder launches PythonLauncher, then leaves the "Python" icon in the dock as before 4) Dragging the wx.python script onto buildapplet makes an application with the blank app icon. Double clicking this icon puts a -third- style of icon in the dock (a 16 ton weight on a panel) with the same name as my app. OK, so given this behaviour, I retract my earlier reccomendation. If the "Python.app" icon will be staying in the dock while the app runs (cases 2, 3), I'm -1 on the rocket, and +1 on the "applet" icon we're not using yet. As for case 4, shouldn't the dock icon match the app icon? Brendan -- Brendan Simons --- Ronald Oussoren wrote: > > On 25-apr-2006, at 15:15, Brendan Simons wrote: > > > Oh, > > > > I thought that's what the Python Launcher did. A > > bouncing rocket in the dock is a pretty good cue > that > > Python is launching something. So I'm +1 on using > the > > current Python Launcher icon > > > > If not that then (is the launcher actually used > > otherwise?) I'm +0 on just the glassy logo. > > I'm going to use the rocket of the Python.app that > is inside the > framework and will use the same icon for Python > Launcher. The latter > is a tool that can be used to run python files by > double-clicking on > them. > > Ronald > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ronaldoussoren at mac.com Tue Apr 25 19:19:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 25 Apr 2006 19:19:56 +0200 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: <20060425170919.69953.qmail@web31104.mail.mud.yahoo.com> References: <20060425170919.69953.qmail@web31104.mail.mud.yahoo.com> Message-ID: On 25-apr-2006, at 19:09, Brendan Simons wrote: > OK, I obviously need to learn a little about the > launch sequence of mac python files. Here's what I've > discovered: > > 1) Double clicking a terminal-based python script from > finder launches PythonLauncher (soon to be a rocket > icon), then the terminal. That's right. Python Launcher is an helper application for opening .py and .pyw with the plain old command-line python interpreter. The latter is not a real application bundle and can therefore not be associated with file extensions, hence Python Launcher. > > 2) Running a wx.python script from TextWrangler using > #!/usr/bin/pythonw skips PythonLauncher, and leaves a > "Python" icon (just the 16 ton weight) in the dock > until I quit the wx.app. Is this the "Python.app" > from the framework? That's right. The Python.app in the framework contains the binary that will be started when you start pythonw (or python for that matter) from the terminal. This is the command-line python interpreter we all know and love, but stuffed inside an OSX application bundle. The application bundle is necessary to enable access to the window server. > > 3) Double clicking a wx.python script from finder > launches PythonLauncher, then leaves the "Python" icon > in the dock as before That's because of (2) > > 4) Dragging the wx.python script onto buildapplet > makes an application with the blank app icon. Double > clicking this icon puts a -third- style of icon in the > dock (a 16 ton weight on a panel) with the same name > as my app. That icon will be replaced by the generic python application icon. > > > OK, so given this behaviour, I retract my earlier > reccomendation. If the "Python.app" icon will be > staying in the dock while the app runs (cases 2, 3), > I'm -1 on the rocket, and +1 on the "applet" icon > we're not using yet. You have some point there. I'm against haveing two different icons for applications. I'll experiment a little with the rocket and application icons to see which looks more natural. > > As for case 4, shouldn't the dock icon match the app > icon? They should match. If they don't match you have probably found a bug in the BuildApplet. My guess is that the applet is build in the wrong order and the finder sees the application bundle and extracts (and caches) its icon before the bundle contains the icon. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060425/7aa33139/attachment.bin From hengist.podd at virgin.net Tue Apr 25 20:04:47 2006 From: hengist.podd at virgin.net (has) Date: Tue, 25 Apr 2006 19:04:47 +0100 Subject: [Pythonmac-SIG] Fwd: MacPython icon mockup In-Reply-To: References: <20060425170919.69953.qmail@web31104.mail.mud.yahoo.com> Message-ID: Ronald Oussoren wrote: >>OK, so given this behaviour, I retract my earlier >>reccomendation. If the "Python.app" icon will be >>staying in the dock while the app runs (cases 2, 3), >>I'm -1 on the rocket, and +1 on the "applet" icon >>we're not using yet. > >You have some point there. I'm against haveing two different icons for applications. I'll experiment a little with the rocket and application icons to see which looks more natural. Can't say I'd thought of reusing the PythonLauncher.app icon for Python.app, given they're not the same thing, but it might work ok. Leave it in your capable hands then. has -- http://freespace.virgin.net/hamish.sanderson/ From chipartist at metrocast.net Tue Apr 25 19:52:16 2006 From: chipartist at metrocast.net (chip nyman) Date: Tue, 25 Apr 2006 13:52:16 -0400 Subject: [Pythonmac-SIG] multi-platform Python distributions question Message-ID: <00c201c66890$fd85edf0$6401a8c0@DADSCOMP253GHZ> I have a small non-commercial calendar applet featuring heavy use of wxPython that I've written on WinXP but will eventually need to be distributed to a number of platforms, including current Macs. Are there any subscribers to this list who'd consider helping me prep a py2app version for Mac OSX 10.3.9 and above? Also, are there other pythonMac lists or similar resources I should investigate that might provide useful info for such an undertaking? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060425/ac75a42f/attachment-0001.htm From brendansimons at yahoo.ca Tue Apr 25 21:40:14 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue, 25 Apr 2006 15:40:14 -0400 (EDT) Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: Message-ID: <20060425194015.24849.qmail@web31110.mail.mud.yahoo.com> While you're (re)considering adding Build Applet.app to the distribution, can I suggest another useful app? PyCrust is a great little interactive Python shell that adds introspection and code completion. It's written in wx.python and comes packaged in a .app bundle with a nice icon :) You can get a (pre-release) copy of the universal binary version here: http://prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs-demos-2.6.3.2rc1-universal10.4-py2.4.dmg The source code is managed as part of wx.python, but this app in particular is pretty stable, and is useful outside of wx. (imho) It would be a lot nicer to send newbies to pycrust then to the command line for their first look at Python. Any thoughts? Brendan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From charles.hartman at conncoll.edu Tue Apr 25 22:03:51 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 25 Apr 2006 16:03:51 -0400 Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <20060425194015.24849.qmail@web31110.mail.mud.yahoo.com> References: <20060425194015.24849.qmail@web31110.mail.mud.yahoo.com> Message-ID: <4306BFA4-DD25-4D8E-8A3F-973A07989B2D@conncoll.edu> On Apr 25, 2006, at 3:40 PM, Brendan Simons wrote: > While you're (re)considering adding Build Applet.app > to the distribution, can I suggest another useful app? > > PyCrust is a great little interactive Python shell > that adds introspection and code completion. It's > written in wx.python and comes packaged in a .app > bundle with a nice icon :) You can get a > (pre-release) copy of the universal binary version > here: > > http://prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs- > demos-2.6.3.2rc1-universal10.4-py2.4.dmg > > The source code is managed as part of wx.python, but > this app in particular is pretty stable, and is useful > outside of wx. (imho) > > It would be a lot nicer to send newbies to pycrust > then to the command line for their first look at > Python. As representative perpetual ignoramus & honorary newbie, I agree. I never much noticed PyCrust until "wxPython in Action" brought it to my attention, but I think it's great. For me, this is the replacement for the late unlamented PythonIDE. And -- if I understand rightly -- because it doesn't have IDLE's Tkinter underpinnings it doesn't make writing GUI code with wxPython difficult. (I suppose its wxPython underpinnings could make it difficult to write Tkinter code.) Charles Hartman From bob at redivi.com Tue Apr 25 22:53:26 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 25 Apr 2006 13:53:26 -0700 Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <4306BFA4-DD25-4D8E-8A3F-973A07989B2D@conncoll.edu> References: <20060425194015.24849.qmail@web31110.mail.mud.yahoo.com> <4306BFA4-DD25-4D8E-8A3F-973A07989B2D@conncoll.edu> Message-ID: <3738D62A-4A32-424E-8BB8-26CB57610B54@redivi.com> On Apr 25, 2006, at 1:03 PM, Charles Hartman wrote: > > On Apr 25, 2006, at 3:40 PM, Brendan Simons wrote: > >> While you're (re)considering adding Build Applet.app >> to the distribution, can I suggest another useful app? >> >> PyCrust is a great little interactive Python shell >> that adds introspection and code completion. It's >> written in wx.python and comes packaged in a .app >> bundle with a nice icon :) You can get a >> (pre-release) copy of the universal binary version >> here: >> >> http://prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs- >> demos-2.6.3.2rc1-universal10.4-py2.4.dmg >> >> The source code is managed as part of wx.python, but >> this app in particular is pretty stable, and is useful >> outside of wx. (imho) >> >> It would be a lot nicer to send newbies to pycrust >> then to the command line for their first look at >> Python. > > As representative perpetual ignoramus & honorary newbie, I agree. I > never much noticed PyCrust until "wxPython in Action" brought it to > my attention, but I think it's great. For me, this is the replacement > for the late unlamented PythonIDE. And -- if I understand rightly -- > because it doesn't have IDLE's Tkinter underpinnings it doesn't make > writing GUI code with wxPython difficult. (I suppose its wxPython > underpinnings could make it difficult to write Tkinter code.) This is incorrect. IDLE should work just fine with wxPython, it runs code in a subprocess. PyCrust on the other hand probably does have problems, though. -bob From brendansimons at yahoo.ca Wed Apr 26 00:04:59 2006 From: brendansimons at yahoo.ca (Brendan Simons) Date: Tue, 25 Apr 2006 18:04:59 -0400 (EDT) Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <4306BFA4-DD25-4D8E-8A3F-973A07989B2D@conncoll.edu> Message-ID: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> -On Apr 25, 2006, at 1:03 PM, Charles Hartman wrote: > > On Apr 25, 2006, at 3:40 PM, Brendan Simons wrote: > >> While you're (re)considering adding Build Applet.app >> to the distribution, can I suggest another useful app? >> >> PyCrust is a great little interactive Python shell >> that adds introspection and code completion. It's >> written in wx.python and comes packaged in a .app >> bundle with a nice icon :) You can get a >> (pre-release) copy of the universal binary version >> here: >> >> http://prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs- >> demos-2.6.3.2rc1-universal10.4-py2.4.dmg >> >> The source code is managed as part of wx.python, but >> this app in particular is pretty stable, and is useful >> outside of wx. (imho) >> >> It would be a lot nicer to send newbies to pycrust >> then to the command line for their first look at >> Python. > > As representative perpetual ignoramus & honorary newbie, I agree. I > never much noticed PyCrust until "wxPython in Action" brought it to > my attention, but I think it's great. For me, this is the replacement > for the late unlamented PythonIDE. And -- if I understand rightly -- > because it doesn't have IDLE's Tkinter underpinnings it doesn't make > writing GUI code with wxPython difficult. (I suppose its wxPython > underpinnings could make it difficult to write Tkinter code.) >This is incorrect. IDLE should work just fine with wxPython, it runs >code in a subprocess. PyCrust on the other hand probably does have >problems, though. >-bob Just tried, and neither the IDLE nor PyCrust interactive shells supports wx (or any other gui framework) out of the box. IDLE complains about needing to use Pythonw, and PyCrust just hangs (probably due to the issue Bob mentioned). If the interactive shell in IDLE can be made to interact with gui's, then it will do I suppose. (It's not as nice as PyCrust, but that's a killer feature). Nevermind then, Brendan -- Brendan Simons __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From gandreas at gandreas.com Wed Apr 26 00:51:59 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Tue, 25 Apr 2006 17:51:59 -0500 Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> References: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> Message-ID: > >> -bob > > Just tried, and neither the IDLE nor PyCrust > interactive shells supports wx (or any other gui > framework) out of the box. IDLE complains about > needing to use Pythonw, and PyCrust just hangs > (probably due to the issue Bob mentioned). > > If the interactive shell in IDLE can be made to > interact with gui's, then it will do I suppose. (It's > not as nice as PyCrust, but that's a killer feature). I just tried this with ScrIDE (using the Pythonw Rich Shell interactive window): >>> from wxPython.wx import * >>> class main_window(wxFrame): ... def __init__(self, parent, id, title): ... wxFrame.__init__(self, parent, -1, title, size = (200, 100), ... style=wxDEFAULT_FRAME_STYLE|wxNO_FULL_REPAINT_ON_RESIZE) ... self.control = wxTextCtrl(self, -1, style=wxTE_MULTILINE) ... self.Show(true) ... >>> class App(wxApp): ... def OnInit(self): ... frame = main_window(None, -1, "wxPython: (A Demonstration)") ... self.SetTopWindow(frame) ... return true ... >>> app = App(0) >>> app.MainLoop() Seems to work, complete with things like completion, doc strings and the like (but having not done any wx work in a decade, it's hard to tell if there are problems) Glenn Andreas gandreas at gandreas.com wicked fun! Mad, Bad, and Dangerous to Know From Chris.Barker at noaa.gov Wed Apr 26 01:40:47 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 25 Apr 2006 16:40:47 -0700 Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> References: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> Message-ID: <444EB37F.2090202@noaa.gov> Brendan Simons wrote: >>> this app in particular is pretty stable, and is > useful outside of wx. (imho) Yes, it's useful outside of wx, but it's useless without wx, so it makes sense to distribute it with wx. > PyCrust just hangs It should work with wx, that's what it's designed for,. However, it doesn't spawn another process, so you don't want to create another wxApp. Try this is a pycrust session: >> import wx >> f = wx.Frame(None, title="Test Frame") >> f.Show() -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 at noaa.gov From bob at redivi.com Wed Apr 26 02:10:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 25 Apr 2006 17:10:11 -0700 Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> References: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> Message-ID: <6F619FD4-5752-423E-B74E-8028522C15E5@redivi.com> On Apr 25, 2006, at 3:04 PM, Brendan Simons wrote: > > -On Apr 25, 2006, at 1:03 PM, Charles Hartman wrote: > >> >> On Apr 25, 2006, at 3:40 PM, Brendan Simons wrote: >> >>> While you're (re)considering adding Build > Applet.app >>> to the distribution, can I suggest another useful > app? >>> >>> PyCrust is a great little interactive Python shell >>> that adds introspection and code completion. It's >>> written in wx.python and comes packaged in a .app >>> bundle with a nice icon :) You can get a >>> (pre-release) copy of the universal binary version >>> here: >>> >>> > http://prdownloads.sourceforge.net/wxpython/wxPython2.6-osx-docs- >>> demos-2.6.3.2rc1-universal10.4-py2.4.dmg >>> >>> The source code is managed as part of wx.python, > but >>> this app in particular is pretty stable, and is > useful >>> outside of wx. (imho) >>> >>> It would be a lot nicer to send newbies to pycrust >>> then to the command line for their first look at >>> Python. >> >> As representative perpetual ignoramus & honorary > newbie, I agree. I >> never much noticed PyCrust until "wxPython in > Action" brought it to >> my attention, but I think it's great. For me, this > is the replacement >> for the late unlamented PythonIDE. And -- if I > understand rightly -- >> because it doesn't have IDLE's Tkinter underpinnings > it doesn't make >> writing GUI code with wxPython difficult. (I suppose > its wxPython >> underpinnings could make it difficult to write > Tkinter code.) > >> This is incorrect. IDLE should work just fine with > wxPython, it runs >> code in a subprocess. PyCrust on the other hand > probably does have >> problems, though. > >> -bob > > Just tried, and neither the IDLE nor PyCrust > interactive shells supports wx (or any other gui > framework) out of the box. IDLE complains about > needing to use Pythonw, and PyCrust just hangs > (probably due to the issue Bob mentioned). > > If the interactive shell in IDLE can be made to > interact with gui's, then it will do I suppose. (It's > not as nice as PyCrust, but that's a killer feature). IDLE will work, it needs a tweak that's not currently present in Universal Python. It was discussed on the list a couple weeks ago, I'm not sure if we've made that change to the branch or not. -bob From atenderholt at gmail.com Wed Apr 26 02:37:37 2006 From: atenderholt at gmail.com (Adam Tenderholt) Date: Tue, 25 Apr 2006 17:37:37 -0700 Subject: [Pythonmac-SIG] The Universal Buld and py2app Message-ID: <7781a1b50604251737j5471aba4s67157db499d45734@mail.gmail.com> I just checked out py2app from the svn repository (revision 916). However, it doesn't build for me. It gets stuck on the sip.py recipe. The error is below: File "/Developer/py2app-0.2/src/py2app/build_app.py", line 464, in process_recipes rval = check(self, mf) File "/Developer/py2app-0.2/src/py2app/recipes/sip.py", line 40, in check packages = self.config() File "/Developer/py2app-0.2/src/py2app/recipes/sip.py", line 17, in config qtdir = cfg.qt_lib_dir File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/sipconfig.py", line 178, in __getattr__ raise AttributeError, "\"%s\" is not a valid configuration value or user option" % name AttributeError: "qt_lib_dir" is not a valid configuration value or user option I'm using sip-4.4.1 with MacPython 2.3.5 on an intel mac. PyQt builds and scripts using pyqt work fine. Do you have any suggestions? Thanks, Adam From bob at redivi.com Wed Apr 26 05:18:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 25 Apr 2006 20:18:21 -0700 Subject: [Pythonmac-SIG] The Universal Buld and py2app In-Reply-To: <7781a1b50604251737j5471aba4s67157db499d45734@mail.gmail.com> References: <7781a1b50604251737j5471aba4s67157db499d45734@mail.gmail.com> Message-ID: On Apr 25, 2006, at 5:37 PM, Adam Tenderholt wrote: > I just checked out py2app from the svn repository (revision 916). > However, it doesn't build for me. It gets stuck on the sip.py recipe. > The error is below: Did you check out the trunk, or the maintenance branch? The trunk is not usable. http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/ Also, you probably shouldn't use Python 2.3.5 as shipped on intel macs. It's got some known bugs (endian and otherwise) and is old, use the 2.4 universal build: http://pythonmac.org/packages/py24-fat/ -bob From atenderholt at gmail.com Wed Apr 26 08:42:53 2006 From: atenderholt at gmail.com (Adam Tenderholt) Date: Tue, 25 Apr 2006 23:42:53 -0700 Subject: [Pythonmac-SIG] The Universal Buld and py2app In-Reply-To: References: <7781a1b50604251737j5471aba4s67157db499d45734@mail.gmail.com> Message-ID: <7781a1b50604252342u3003b755jbad3a3603fcc47ed@mail.gmail.com> > Did you check out the trunk, or the maintenance branch? The trunk is > not usable. > > http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/ I did use the maintenance branch. Sorry, should have specified. > Also, you probably shouldn't use Python 2.3.5 as shipped on intel > macs. It's got some known bugs (endian and otherwise) and is old, > use the 2.4 universal build: > > http://pythonmac.org/packages/py24-fat/ I tried this version when I was struggling to get PyQt to work. However, I couldn't get sip-4.4.1 to work properly with this version. It compiled just fine, but whenever you tried to import the sip moduled (ie. when PyQt is configured), it fails with the message: "ImportError: Inappropriate file type for dynamic loading" I asked on the PyKDE mailing list, and I was that something in the flags you use makes it give that error, and that compiling from source (enabling framework, make framework install) should fix it. Unfortunately, I got an error when I tried compiling from source: /usr/bin/ld: warning Python.framework/Versions/2.4/Python cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: _PyMac_Error _Py_Main collect2: ld returned 1 exit status It looks like this is due to ppc being specified somewhere. I didn't see an easy to way to tell configure that I wanted i386 instead of ppc. Is there a flag I can pass to the configure script, or do I have to do a "CFLAGS=-arch i386" and CXXFLAGS='-arch i386'? And how do I make this a universal app? Thanks for your help, Adam From jmgore75 at gmail.com Wed Apr 26 15:35:34 2006 From: jmgore75 at gmail.com (Jeremy Gore) Date: Wed, 26 Apr 2006 09:35:34 -0400 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: <47363756-80D7-41D3-B813-86CB204DFB64@redivi.com> References: <30A38AA4-39D0-4BD2-AA1C-5495F29677C4@gmail.com> <47363756-80D7-41D3-B813-86CB204DFB64@redivi.com> Message-ID: <0F2C40BC-D3F4-4552-B506-D0133014D8F5@gmail.com> I posted earlier on building Numeric on a MacBook Pro with the latest Universal build of python, installed via pkg. Similar problems have arisen with compiling other packages. I believe distutils to be at fault. The problem is the -lcc_dynamic flag invoked on gcc. During the build process whenever it threw an error I went back and reinvoked gcc with that flag removed, and it compiled fine, then continued with setup.py build; after several fixes of this sort the job completed, I installed it, and everything appears to work as expected. I'm not a distutils expert so I'm not sure where this flag is stored or what it means or how to prevent it being invoked. I think somehow the python which I installed (from http:// pythonmac.org/packages/py24-fat/index.html) was compiled with this flag coded in, and it doesn't work on my MacBook. Perhaps it's a matter of a different architecture or a different setup, I don't know. I can't even find a cc_dynamic library file that it would link to. The same thing happened whether or not /usr/local/lib/ libcc_dynamic.a is absent or is symlinked to /usr/lib/gcc/i686-apple- darwin8/4.0.1/libgcc.a. But it doesn't seem to be necessary on my machine, and thus I think python2.4-fat should be altered to incorporate this. It should be noted that I experienced similar problems with other packages besides Numeric. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060426/5ce36206/attachment.htm From daniellord at mac.com Wed Apr 26 16:07:46 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 26 Apr 2006 07:07:46 -0700 Subject: [Pythonmac-SIG] Apple Tutorial on building Universal binaries from Open Source Message-ID: This is fairly simple and uses Xcode, but really all Xcode is in this case is a wrapper for the shell scripts. I am going to try it with just commandline tools and scripts. Should work fine. http://developer.apple.com/opensource/buildingopensourceuniversal.html The references at the end are good sources of more detailed info. These should help a lot of people in their struggles: Adopting Universal Binaries on Mac OS X Universal Binary Programming Guidelines Porting UNIX/Linux Applications to Mac OS X GCC Porting Guide The GNU Compiler Collection on Mac OS X Technical Note TN2137: Building Universal Binaries from configure- based Open Source Projects Daniel Lord daniellord at mac.com --- "You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late." -- Mountaineer's Adage -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060426/04aea622/attachment.html From jmgore75 at gmail.com Wed Apr 26 17:25:03 2006 From: jmgore75 at gmail.com (Jeremy Gore) Date: Wed, 26 Apr 2006 11:25:03 -0400 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: <47363756-80D7-41D3-B813-86CB204DFB64@redivi.com> References: <30A38AA4-39D0-4BD2-AA1C-5495F29677C4@gmail.com> <47363756-80D7-41D3-B813-86CB204DFB64@redivi.com> Message-ID: <15DA08B8-F9E6-414A-829E-1D40F60E67FC@gmail.com> I found my problem. For whatever reason I had a export CFLAGS="-faltivec -lcc_dynamic - framework vecLib" in a configuration file that I carried over from a previous machine. I must have added it there to address the deficiencies of a previous compilation. Now everything works perfectly. Sorry for the confusion! Jeremy From chipartist at metrocast.net Wed Apr 26 20:16:43 2006 From: chipartist at metrocast.net (chip nyman) Date: Wed, 26 Apr 2006 14:16:43 -0400 Subject: [Pythonmac-SIG] multi-platform Python distributions question References: <00c201c66890$fd85edf0$6401a8c0@DADSCOMP253GHZ> <444EAC16.6070000@noaa.gov> Message-ID: <019401c6695d$9272a620$6401a8c0@DADSCOMP253GHZ> Mark and Chris, thanks for your interest. Here's some in-depth info about my project. I've designed a desktop applet that displays custom artwork and interface elements, and incorporates a modified calendar control from the wxPython demo as a basis for its calendar grid implementation. Basically this applet is intended to mimic to some degree an "ink-on-paper" wall calendar of the variety that usually uses themed graphics as decorations. The applet is initially to be used to display artwork produced by members of an artists' web community I frequent, conceptart.org, but can be adapted to display any graphics that can be "modulized" with image2py. The interface artwork is also so modulized, so that can also be easily customized. The applet is designed to adjust itself to any size and aspect ratio of art, within reasonable limits (even unreasonable if the artwork is properly modified for inclusion), with partially-fixed-size regions dedicated to the UI. Currently, to avoid the need for complex graphics code for resampling and scaling the artwork, the displayed artwork is fixed in scale, with no allowance for dynamic adaptation to monitor size. Artwork modules for different screen resolutions are the alternate solution, a bit inelegant in terms of coding but better for proper display of the art, which is the driving purpose for the calendar applet. The applet windows cannot be dynamically resized, for much the same reason. There is functionality for marking and adding short text notes to selected dates on the calendar control, which is accessed on user demand. The applet is designed to be platform non-specific, using borderless or simple-border frames and avoiding as much as possible platform dependencies in terms of interface controls, which are very rudimentary. In its current implementation, there are no user menus, and only three main interface buttons -- Close, Minimize, and Open Calendar Grid. A TaskBarIcon provides user control as well, for Close, Minimize and Restore commands. The calendar control itself employs the date navigation functions from the wxPython demo (calendar window version), with modified date marking code, and new code to permit input, recording and reading w/output of the date-selective text notes. Two pickled text files with custom (though rather simple) formatting rules are used for persistent data: the calendar text notes and the closing position of the applet. I've only been using Python since the first of this month, so I've depended heavily on adaptation of existing modules when feasible, drawing mainly from the wxPython GUI library. Originality is in the interface design and its visual character, in the scripting to maintain the frames hierarchy the visual design requires, and in the date marking functions added to (or modified from) the calendar control. Distribution of the applet will be international and multi-platform, reflecting the wide member base of conceptart.org. An informal survey has already identified Win98, WinXP (home and Pro), Mac OSX 10.3.9 and above, and Debian Linux as platforms in use by the members, so I need some assistance in prepping distribution packages that do not require separate installations of Python 2.4 and wxPython 2.6 Unicode (though the Win98 version will likely be wxPython ANSI). So far I've done successful test builds for the WinXP and Win98 platforms using py2exe. Since I am primarily a CG artist, I don't maintain multi-platform systems for my programming efforts (which in the past have included TcL-based plugins and RealBasic standalones for Mac OS 9.x, and UnrealScript for game-specific coding on Windows), so instead I'm seeking the assistance of interested Python community members. I chose Python as the implementing code base because my research indicated it is very flexible, has a respectable documentation database (essential for a novice such as I), and is very similar in syntax and abstract structure to the other scripting languages I've used. The applet is to be distributed free of charge, as a vehicle for promoting contributing artists from conceptart.org. Contributors to the packaging efforts will of course be credited if so desired. My current functionality status is unreleased beta; my plans are to release the beta for testing by the end of April. Beta testers will be chosen primarily from the conceptart.org membership, the initial target audience for the applet, but I would of course welcome feedback from the Python community as well. I hope that answers most questions. I can provide URLs to forum threads on conceptart.org that have some details about the look of the beta if that is of further interest. chip ----- Original Message ----- From: "Christopher Barker" To: "chip nyman" Sent: Tuesday, April 25, 2006 7:09 PM Subject: Re: [Pythonmac-SIG] multi-platform Python distributions question > chip nyman wrote: >> I have a small non-commercial calendar applet featuring heavy use of >> wxPython that I've written on WinXP but will eventually need to be >> distributed to a number of platforms, including current Macs. Are >> there any subscribers to this list who'd consider helping me prep a >> py2app version for Mac OSX 10.3.9 and above? > > Tell us more about the app -- something to get us interested! > > > Also, are there other >> pythonMac lists or similar resources I should investigate that might >> provide useful info for such an undertaking? Thanks. > > I'd try the wxpython-users list too. > > -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 at noaa.gov > From ronaldoussoren at mac.com Wed Apr 26 20:32:51 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 26 Apr 2006 20:32:51 +0200 Subject: [Pythonmac-SIG] Compiling Numeric for OSX-intel In-Reply-To: <15DA08B8-F9E6-414A-829E-1D40F60E67FC@gmail.com> References: <30A38AA4-39D0-4BD2-AA1C-5495F29677C4@gmail.com> <47363756-80D7-41D3-B813-86CB204DFB64@redivi.com> <15DA08B8-F9E6-414A-829E-1D40F60E67FC@gmail.com> Message-ID: <47E6D233-C14A-4B05-9F0B-40B7D6AD56CD@mac.com> On 26-apr-2006, at 17:25, Jeremy Gore wrote: > I found my problem. > > For whatever reason I had a export CFLAGS="-faltivec -lcc_dynamic - > framework vecLib" in a configuration file that I carried over from a > previous machine. I must have added it there to address the > deficiencies of a previous compilation. Now everything works > perfectly. > > Sorry for the confusion! Thanks for telling us about the solution to your problem. Ronald > > Jeremy > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060426/5ef7d411/attachment.bin From ronaldoussoren at mac.com Wed Apr 26 20:37:54 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 26 Apr 2006 20:37:54 +0200 Subject: [Pythonmac-SIG] Adding Apps - Pycrust too? In-Reply-To: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> References: <20060425220459.28696.qmail@web31101.mail.mud.yahoo.com> Message-ID: On 26-apr-2006, at 0:04, Brendan Simons wrote: > > Just tried, and neither the IDLE nor PyCrust > interactive shells supports wx (or any other gui > framework) out of the box. IDLE complains about > needing to use Pythonw, and PyCrust just hangs > (probably due to the issue Bob mentioned). The IDLE one is a bug that will be fixed with the next release. > > If the interactive shell in IDLE can be made to > interact with gui's, then it will do I suppose. (It's > not as nice as PyCrust, but that's a killer feature). If anyone is looking for a nice self-contained project, making IDLE a better OSX citizen would be one. This does require tkinter programming and probably some research on how to do some things with Tk and porting that to python. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060426/d8be5bda/attachment-0001.bin From danthorpe at zepler.net Thu Apr 27 03:08:12 2006 From: danthorpe at zepler.net (Daniel Thorpe) Date: Thu, 27 Apr 2006 02:08:12 +0100 Subject: [Pythonmac-SIG] Appscript, adding files to iTunes Message-ID: <706F273F-D10A-40FE-BDA0-96F664E83CBF@zepler.net> Hi, I'm wondering if anyone can help me with an Appscript / iTunes utility I'm trying to write. Does anyone know how I add m4a files to my iTunes library using appscript? So far, I have a list of filenames, which I want to add to my library (which I've got a reference to). According to app('iTunes').add.help () I have to pass the function a list of Alias(s). I think this means Finder alias files, but I can't seem to be able to create them using app('Finder').make(). This is my code so far.... import os, from optparse import OptionParser from appscript import * def getListOfFinderItems(directory): files = ["%s%s" % (directory, file,) for file in os.listdir(directory)] # Need to make a list of 'alias files' Finder = app('Finder') # Finder.make.help() # aliases = [None] * len(files) # for i,file in enumerate(files): # Finder.make(new=k.alias_file,at=aliases[i],to=file) return aliases def addToiTunes(directory): audiofiles = getListOfFinderItems(directory) iTunesApp = app('iTunes') for src in iTunesApp.sources.get(): if src.kind.get() == k.library: iTunesLib = src.playlists[1].get() break # iTunesApp.add.help() iTunesLib.add.help() if __name__ == "__main__": parser = OptionParser() parser.add_option("-f", "--folder", dest="folder", help="Select the folder containing audio files.") (options, args) = parser.parse_args() addToiTunes(options.folder) Cheers Dan Thorpe From daniellord at mac.com Thu Apr 27 05:19:04 2006 From: daniellord at mac.com (Daniel Lord) Date: Wed, 26 Apr 2006 20:19:04 -0700 Subject: [Pythonmac-SIG] GMP bigot now chastened. In-Reply-To: References: Message-ID: <592ACDBA-9CD7-4F7B-B789-1E38459219E4@mac.com> Alex, Just so you and anyone who cares that our platform get fair treatment know. Turns out the Mac bigot was behaving badly again. GMP 4.2 doesn't compile on PPC macs either and he was blaming Apple's compilers. Turns out we figured out a fix involving PIC--it seems Linux PPCs have the same problem. So it was gcc problem not an Apple one. I called him on and asked that he fix the site to avoid further embarassment ( i did that privately) but I publicly asked him to include the patches for Apple i386 and PPC in the source and wondered why they hadn't been adopted. That struck a nerve so he set my mail address to be moderated effectively quarantining me to stifle me. I figured this would happen and I didn't care--I got in a few licks and he's made a fool of himself. He took down the diatribe against Apple at least. In my life experience, I have found that appeasing such ignorant fools drunk with power only encourages them. It was a good fight, I accomplished what I wanted, and I feel no loss with the gmp list--I really only want it to work. On Apr 22, 2006, at 9:50, Alex Martelli wrote: > > On Apr 22, 2006, at 1:59 AM, pythonmac-sig-request at python.org wrote: > >> No arbitrary precison math on Mac-tel say it ain't so! > > It ain't so. > > >> The analog of a single gene pool in nature has come to pass for >> arbitrary precison math (APM) for OS X (native not Python). >> GMP is 'it' for APM as far as I can tell unless I want to write my >> own. > > I believe intel also has libraries (they offered them for beta at > some point, but I didn't follow through on that), but that's not the > key point. > >> And GMP doesn't compile on Mac-tel and won't for some time: >> >> The current release is 4.2, released 2006-03-26. It fixes all bugs >> found in 4.1.4, as well as several portability problems. It also >> adds several new features. Note that we chose not to work around >> all new GCC bugs in this release. Never forget to do a make check >> after building the library to make likely it was not miscompiled! >> >> Issues with GMP 4.2: >> >> Miscompilation on several platforms using several different >> compilers. Remember to run make check! >> GMP does not build on MacInteltoch machines. Since Apple uses their >> own, creative assembly syntax, it is not trivial to fix this. > Nope. The current maintainer of GMP is apparently Apple-hostile AND > by his own admission no expert on autoconf/libtools and similar > blackmagic -- and apparently unable to admit it when he's dead wrong. > > Apple's assembly syntax is totally irrelevant here. The reason make > check fails is Apple's creative *ld semantics*: an object file inside > a library file is NOT brought in if the only symbols it satisfies are > DATA ones. > Make check makes an executable with unresolved symbols because of > this strange "optimization" in Apple's ld (I dimly remember from the > past other linkers with this kind of strangeness), that's all. > > Enrico Franchi posted to gmp-bugs, two weeks ago, a patch to gmp 4.2 > which I had sent him -- it's a TINY patch (aparts from comments > explaining why it exists, it's just *THREE* bedraggled lines...!!!): > > http://swox.com/list-archives/gmp-bugs/attachments/20060407/f364005b/ > patch-0001.obj > > GMP's maintainer rejected it as "THis is a too ugly patch for > inclusion in GMP." (!!!). > > > Anyway, download and apply that patch, and make check passes with > flying colors. > > > Then, I had the deadline for the 2nd ed of the Nutshell, then a > week's vacation at the Grand Canyon, and have been catching up on > things, so I haven't done any further followthrough - yet. > > Once this idiocy is solved, there is another problem: I STILL can't > link gmpy.so beause I can't make libgmp.a to build properly for > linkage into a -bundle. Specifically (with gmpy.sf.net's current CVS > contents): > > brain:~/alex/gmpy alex$ python setup.py build_ext -i > running build_ext > building 'gmpy' extension > creating build/temp.macosx-10.4-fat-2.4 > creating build/temp.macosx-10.4-fat-2.4/src > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - > fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - > fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/usr/local/include -I/ > Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c > src/gmpy.c -o build/temp.macosx-10.4-fat-2.4/src/gmpy.o > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g > -bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/src/ > gmpy.o -L/usr/local/lib -lgmp -o gmpy.so > /usr/bin/ld: for architecture i386 > /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation > entries in non-writable section (__TEXT,__text) > /usr/bin/ld: for architecture ppc > /usr/bin/ld: warning /usr/local/lib/libgmp.a archive's cputype (7, > architecture i386) does not match cputype (18) for specified -arch > flag: ppc (can't load from it) > collect2: ld returned 1 exit status > lipo: can't open input file: /var/tmp//ccGbVJa4.out (No such file or > directory) > error: command 'gcc' failed with exit status 1 > brain:~/alex/gmpy alex$ > > Don't worry about the failure on the ppc branch, that's just because > the .a is not universal and would presumably result in making a non- > universal .so -- could be fixed later. I've tried with a > nonuniversal 2.4.3 (from Activestate) and THAT halfbug goes away. > It's yet another TODO item, with lower priority than "the biggie" > below. > > The biggie is the like: > > /usr/bin/ld: /usr/local/lib/libgmp.a(add_n.o) has local relocation > entries in non-writable section (__TEXT,__text) > > I've tried ("manually", i.e. with CFLAGS=... on the ./configure of > GMP 4.2) various -f flags to try to make libgmp.a PIC (which I assume > is what's the error's complaining about?) -- -fPIC, -fno-common, > others; no luck so far. I've explored every mention on the web of > this errorcode about "local relocation entries in non-writable > section", but, no luck so far. > > It may be trivial for people more deeply familiar with Apple's > toolchain (ld most of all) than I am, and I do have several at work I > can consult on that, but, as I said, I didn't yet have much time for > followup. Once I understand how to fix it with CFLAGS=..., then I > must understand how to embed the fix via autoconf/configure/libtools, > which is scary (MY knowledge of that part being very scarce). > Finally, there will be the political fight to make the maintainer > accept the resulting patches. > > BTW, the biggie is fully reproducible on PPC Macs, too, so GMP 4.2 > builds on those in a state which still doesn't let gmpy.so link (it > may feel less urgent just because GMP 4.1.* does build fine;-). I've > even tried using 4.1.* on mac-intel but it breaks in different ways > and it seems to me that there's no point fighting with that one, I > might well focus my limited time and energy on 4.2!-) > > BTW**2, any advice from ANYbody with better grasp of Apple's ld, the > significance of -bundle vs -dylib, autoconf and friends, etc, etc, > will be most welcome!-) > > > Alex > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig Daniel Lord daniellord at mac.com --- "You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late." -- Mountaineer's Adage From bob at redivi.com Thu Apr 27 07:33:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 26 Apr 2006 22:33:00 -0700 Subject: [Pythonmac-SIG] PIL 1.1.5 universal package currently broken Message-ID: It seems that the PIL build is missing freetype *and* it's not even linked to a dynamic version of it. Very strange. >>> import _imagingft Traceback (most recent call last): File "", line 1, in ? ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/PIL/ _imagingft.so: Symbol not found: _FT_New_Face Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/PIL/_imagingft.so Expected in: flat namespace $ otool -L /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/PIL/_imagingft.so /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/PIL/_imagingft.so: /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3) From aleaxit at gmail.com Thu Apr 27 07:45:57 2006 From: aleaxit at gmail.com (Alex Martelli) Date: Wed, 26 Apr 2006 22:45:57 -0700 Subject: [Pythonmac-SIG] GMP bigot now chastened. In-Reply-To: <592ACDBA-9CD7-4F7B-B789-1E38459219E4@mac.com> References: <592ACDBA-9CD7-4F7B-B789-1E38459219E4@mac.com> Message-ID: <8324A622-D266-429C-8CD2-623753D72BE5@gmail.com> On Apr 26, 2006, at 8:19 PM, Daniel Lord wrote: > Alex, > Just so you and anyone who cares that our platform get fair > treatment know. Turns out the Mac bigot was behaving badly again. > GMP 4.2 doesn't compile on PPC macs either and he was blaming > Apple's compilers. Turns out we figured out a fix involving PIC--it > seems Linux PPCs have the same problem. So it was gcc problem not > an Apple one. I called him on and asked that he fix the site to > avoid further embarassment ( i did that privately) but I publicly > asked him to include the patches for Apple i386 and PPC in the > source and wondered why they hadn't been adopted. That struck a > nerve so he set my mail address to be moderated effectively > quarantining me to stifle me. I figured this would happen and I > didn't care--I got in a few licks and he's made a fool of himself. > He took down the diatribe against Apple at least. In my life > experience, I have found that appeasing such ignorant fools drunk > with power only encourages them. It was a good fight, I > accomplished what I wanted, and I feel no loss with the gmp list--I > really only want it to work. Wow, thanks for the update -- that [[expletive deleted]] maintainer is most definitely doing GMP no favors (nor, any favors to the cause of open source, either). So, I guess, eventually we'll have to fork GMP, or something:-(. Ah well -- so the next minor 4.2.* is expected to build well -with- ppc on Mac both intel and PPC...? Thanks for your efforts, in any case! Alex From phil at riverbankcomputing.co.uk Thu Apr 27 08:58:14 2006 From: phil at riverbankcomputing.co.uk (Phil Thompson) Date: Thu, 27 Apr 2006 07:58:14 +0100 Subject: [Pythonmac-SIG] Why dynload_next.c rather than dynload_shlib.c? Message-ID: <200604270758.14265.phil@riverbankcomputing.co.uk> Apple's Python seems to be built with dynload_shlib.c which allows it to handle extension modules built as bundles and dynamic libraries. python.org Python uses dynload_next.c which means that extension modules must be built as bundles. Is there any particular reason for this (I'm new to MacOS)? Thanks, Phil From zpincus at stanford.edu Thu Apr 27 09:55:57 2006 From: zpincus at stanford.edu (Zachary Pincus) Date: Thu, 27 Apr 2006 00:55:57 -0700 Subject: [Pythonmac-SIG] Why dynload_next.c rather than dynload_shlib.c? In-Reply-To: <200604270758.14265.phil@riverbankcomputing.co.uk> References: <200604270758.14265.phil@riverbankcomputing.co.uk> Message-ID: <7BF459E2-0B25-44D6-9357-54FD16FCC684@stanford.edu> As of Python 2.5a2, python.org python should use dynload_shlib.c on 10.3 and 10.4. I didn't realize that Apple's python was built differently... Anyhow, if you want to build your own Py2.4 with dynload_shlib the patch is pretty easy. You can search for the patch on sourceforge (it's against 2.5 but it applies cleanly to 2.4 too, I think) or I can send it to you. This peculiarity dates from earlier versions of OS X that did not have dlopen() functionality -- then the next APIs were all that there were. Zach On Apr 26, 2006, at 11:58 PM, Phil Thompson wrote: > Apple's Python seems to be built with dynload_shlib.c which allows > it to > handle extension modules built as bundles and dynamic libraries. > > python.org Python uses dynload_next.c which means that extension > modules must > be built as bundles. > > Is there any particular reason for this (I'm new to MacOS)? > > Thanks, > Phil > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Thu Apr 27 12:56:12 2006 From: hengist.podd at virgin.net (has) Date: Thu, 27 Apr 2006 11:56:12 +0100 Subject: [Pythonmac-SIG] Appscript, adding files to iTunes Message-ID: Daniel Thorpe wrote: >Hi, I'm wondering if anyone can help me with an Appscript / iTunes >utility I'm trying to write. Does anyone know how I add m4a files to >my iTunes library using appscript? > >So far, I have a list of filenames, which I want to add to my library >(which I've got a reference to). According to app('iTunes').add.help >() I have to pass the function a list of Alias(s). I think this means >Finder alias files, but I can't seem to be able to create them using >app('Finder').make(). Nope, no relation to Finder. 'Alias' is an AE type. Ch.6 of the appscript manual lists the common AE type <-> Python mappings. Example: from appscript import * from macfile import * files = [Alias(u'/Users/foo/some.mp3'), Alias(u'/Users/foo/another.mp3'), ...] itunes = app('iTunes') itunes.add(files, to=itunes.playlists['Library']) HTH has -- http://freespace.virgin.net/hamish.sanderson/ From daniellord at mac.com Thu Apr 27 15:40:11 2006 From: daniellord at mac.com (Daniel Lord) Date: Thu, 27 Apr 2006 06:40:11 -0700 Subject: [Pythonmac-SIG] GMP bigot now chastened. In-Reply-To: <8324A622-D266-429C-8CD2-623753D72BE5@gmail.com> References: <592ACDBA-9CD7-4F7B-B789-1E38459219E4@mac.com> <8324A622-D266-429C-8CD2-623753D72BE5@gmail.com> Message-ID: On Apr 26, 2006, at 22:45, Alex Martelli wrote: > > On Apr 26, 2006, at 8:19 PM, Daniel Lord wrote: > >> Alex, >> Just so you and anyone who cares that our platform get fair >> treatment know. Turns out the Mac bigot was behaving badly again. >> GMP 4.2 doesn't compile on PPC macs either and he was blaming >> Apple's compilers. Turns out we figured out a fix involving PIC-- >> it seems Linux PPCs have the same problem. So it was gcc problem >> not an Apple one. I called him on and asked that he fix the site >> to avoid further embarassment ( i did that privately) but I >> publicly asked him to include the patches for Apple i386 and PPC >> in the source and wondered why they hadn't been adopted. That >> struck a nerve so he set my mail address to be moderated >> effectively quarantining me to stifle me. I figured this would >> happen and I didn't care--I got in a few licks and he's made a >> fool of himself. He took down the diatribe against Apple at least. >> In my life experience, I have found that appeasing such ignorant >> fools drunk with power only encourages them. It was a good fight, >> I accomplished what I wanted, and I feel no loss with the gmp >> list--I really only want it to work. > > Wow, thanks for the update -- that [[expletive deleted]] maintainer > is most definitely doing GMP no favors (nor, any favors to the > cause of open source, either). So, I guess, eventually we'll have > to fork GMP, or something:-(. > > Ah well -- so the next minor 4.2.* is expected to build well -with- > ppc on Mac both intel and PPC...? Well, that is if he actually follows through and checks in the changes. No telling what he'll do since he holds the keys to the repository and the forums--he can be a a magnaimous king or a repressive tyrant --his choice. We'll have to wait and see. they took down the diatribe against Apple assembler and have now a geenral comlaint about an increase in 'broken' gcc implementations that is platform agnostic. So IMHO, that is a big win for the Mac. What I'll do in the mean time, is put both patches up in the MacPython wiki so at least people 'googling' for a solution will find them. If we cannot work with him, we'll work around him as best we can. Jsut for posterity, here is the PPC one (thanks to Jack Howarth -- howarth at bromo.msbb.uc.edu) he is building GMP 2.4 on a G5 with Xcode 2.2.1: Daniel, My initial guess at the source of the problem turned out to be correct. I had thought the use of -fno-common to provide PIC code seemed suspect. If you rebuild gmp 4.2 on a G5 with... ./configure --enable-cxx CC='gcc -fPIC' CXX='g++ -fPIC' ...the resulting build passes make check fine. We ran into a lot of this in ppc-linux. Any shared libs built on ppc without -fPIC are subject to weird hard to debug crashes. I seriously doubt that -fno-common provides the same compiler behavior as -fPIC. Often on ppc compiles I have seen both used together. Jack Daniel Lord daniellord at mac.com --- "You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late." -- Mountaineer's Adage From frank at niessink.com Thu Apr 27 22:35:31 2006 From: frank at niessink.com (Frank Niessink) Date: Thu, 27 Apr 2006 22:35:31 +0200 Subject: [Pythonmac-SIG] /Applications/MacPython 2.4/Extras/Tools missing from Universal build? Message-ID: <44512B13.2080808@niessink.com> Hi all, Maybe I'm missing something (pun not intended), but I'm missing /Applications/MacPython 2.4/Extras/Tools and contents from the Universal build. Are those tools put somewhere else? Cheers, Frank From kw at kevin-walzer.com Fri Apr 28 15:50:21 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Fri, 28 Apr 2006 09:50:21 -0400 Subject: [Pythonmac-SIG] /Applications/MacPython 2.4/Extras/Tools missing from Universal build? In-Reply-To: <44512B13.2080808@niessink.com> References: <44512B13.2080808@niessink.com> Message-ID: <44521D9D.9080901@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Niessink wrote: > Hi all, > > Maybe I'm missing something (pun not intended), but I'm missing > /Applications/MacPython 2.4/Extras/Tools and contents from the Universal > build. Are those tools put somewhere else? > > Cheers, Frank > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > What exactly were you looking for in that directory? The old PythonIDE and Package Manager? That was removed from the distribution. Idle, BuildApplet, and the demos are all that's left. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUh2crTC5hIgjqTMRAh4tAJ4qY6d+qO7v9j9ImTPJMKHidRZDfgCfQGpd ionRSMrW8ZN1pfAnYDt6v24= =nlMv -----END PGP SIGNATURE----- From frank at niessink.com Fri Apr 28 15:57:04 2006 From: frank at niessink.com (Frank Niessink) Date: Fri, 28 Apr 2006 15:57:04 +0200 Subject: [Pythonmac-SIG] /Applications/MacPython 2.4/Extras/Tools missing from Universal build? In-Reply-To: <44521D9D.9080901@kevin-walzer.com> References: <44512B13.2080808@niessink.com> <44521D9D.9080901@kevin-walzer.com> Message-ID: <44521F30.3090109@niessink.com> Kevin Walzer: > What exactly were you looking for in that directory? The old PythonIDE > and Package Manager? That was removed from the distribution. Idle, > BuildApplet, and the demos are all that's left. I use(d) /Applications/MacPython 2.4/Extras/Tools/i18n/pygettext.py for internationalization and /Applications/MacPython 2.4/Extras/Tools/webchecker/webchecker.py to validate url's. Cheers, Frank From kw at kevin-walzer.com Fri Apr 28 16:12:50 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Fri, 28 Apr 2006 10:12:50 -0400 Subject: [Pythonmac-SIG] Universal installation of Tcl/Tk Aqua--for Tkinter developers Message-ID: <445222E2.3030009@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For Tkinter developers: I've put together a universal installation package of the Tcl/Tk Aqua frameworks, based on Tcl/Tk 8.4.13. This package should work with the universal build of Python that's been released. You can download the package at http://tk-components.sourceforge.net/installer/. Be sure to look for the "Aqua" package--there is also a universal build of Tcl/Tk for X11 at the site, which will probably be less useful. Thanks. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUiLirTC5hIgjqTMRAqoOAJ9Gj5IOmYy/ANDkT8nEI5D9CcRJTQCgh2ew cL9ib5Zfpxooa1vcyJvmV2I= =F/qz -----END PGP SIGNATURE----- From bob at redivi.com Fri Apr 28 17:24:06 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 28 Apr 2006 08:24:06 -0700 Subject: [Pythonmac-SIG] Universal installation of Tcl/Tk Aqua--for Tkinter developers In-Reply-To: <445222E2.3030009@kevin-walzer.com> References: <445222E2.3030009@kevin-walzer.com> Message-ID: On Apr 28, 2006, at 7:12 AM, Kevin Walzer wrote: > I've put together a universal installation package of the Tcl/Tk Aqua > frameworks, based on Tcl/Tk 8.4.13. This package should work with the > universal build of Python that's been released. > > You can download the package at > http://tk-components.sourceforge.net/installer/. > > Be sure to look for the "Aqua" package--there is also a universal > build > of Tcl/Tk for X11 at the site, which will probably be less useful. The universal build links against the /System Tk.. so barring a replacement or install_name_tool hacking of _tkinter.so or some DYLD environment variable tricks, installing this will not influence universal python in any way. -bob From kw at kevin-walzer.com Fri Apr 28 17:34:21 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Fri, 28 Apr 2006 11:34:21 -0400 Subject: [Pythonmac-SIG] Universal installation of Tcl/Tk Aqua--for Tkinter developers In-Reply-To: References: <445222E2.3030009@kevin-walzer.com> Message-ID: <445235FD.9060102@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: > > On Apr 28, 2006, at 7:12 AM, Kevin Walzer wrote: > >> I've put together a universal installation package of the Tcl/Tk Aqua >> frameworks, based on Tcl/Tk 8.4.13. This package should work with the >> universal build of Python that's been released. >> >> You can download the package at >> http://tk-components.sourceforge.net/installer/. >> >> Be sure to look for the "Aqua" package--there is also a universal build >> of Tcl/Tk for X11 at the site, which will probably be less useful. > > The universal build links against the /System Tk.. so barring a > replacement or install_name_tool hacking of _tkinter.so or some DYLD > environment variable tricks, installing this will not influence > universal python in any way. > > -bob > > Won't this linking cause the universal build to break when Apple ships a new OS, presumably with updated Tcl/Tk libraries? - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUjX8rTC5hIgjqTMRAqRvAJ9yN1Rox85J8dVWXNTocJ++IZRr6wCgqMW1 OvPzVVtVQ8N2VbL0jgMTS6A= =yORZ -----END PGP SIGNATURE----- From bob at redivi.com Fri Apr 28 18:01:46 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 28 Apr 2006 09:01:46 -0700 Subject: [Pythonmac-SIG] Universal installation of Tcl/Tk Aqua--for Tkinter developers In-Reply-To: <445235FD.9060102@kevin-walzer.com> References: <445222E2.3030009@kevin-walzer.com> <445235FD.9060102@kevin-walzer.com> Message-ID: On Apr 28, 2006, at 8:34 AM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bob Ippolito wrote: >> >> On Apr 28, 2006, at 7:12 AM, Kevin Walzer wrote: >> >>> I've put together a universal installation package of the Tcl/Tk >>> Aqua >>> frameworks, based on Tcl/Tk 8.4.13. This package should work with >>> the >>> universal build of Python that's been released. >>> >>> You can download the package at >>> http://tk-components.sourceforge.net/installer/. >>> >>> Be sure to look for the "Aqua" package--there is also a universal >>> build >>> of Tcl/Tk for X11 at the site, which will probably be less useful. >> >> The universal build links against the /System Tk.. so barring a >> replacement or install_name_tool hacking of _tkinter.so or some DYLD >> environment variable tricks, installing this will not influence >> universal python in any way. > > Won't this linking cause the universal build to break when Apple > ships a > new OS, presumably with updated Tcl/Tk libraries? Potentially. I didn't say it that this was necessarily the correct behavior, only that this is what it currently does. -bob