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

Non-obvious Question about PyObjC and Xcode
by Daniel Lord Feb. 3, 2006

Feb. 3, 2006

I am a neophyte when it comes to Cocoa and ObjC so forgive me if his question is nonsensical and the answer is obvious to you seasoned professionals. I decided to tackle a formidable task: learning Cocoa and Objective-C by approaching them through Python and Perl which I know and find better 'RAD' tools (though I do know C and C++ and have written some small Carbon applications using XCode and Code Warrior in the past). So I face a steep and formidable learning curve akin to soloing the Eiger in Winter perhaps. But here goes... I have to say I am a bit confused on the two very different sets of directions for using PyObjC and I want to use the tools a formal way to avoid as much obsolescence of my projects as possible: 1. The Tutorials on the SourceForge site present a somewhat traditional way of creating outlets and actions and linking them to an instantiated class in Interface Builder before executing py2app. However, unlike using the Camel Bones Perl ObjC Bridge, I have to run the external build tool outside of Xcode to make a build. I find the Camel Bones method much easier and it almost tempts me to go back to using Perl over Python (I said _almost_ ;-) $$$$$This means that once py2app is run though, I cannot change my nib files because the outlets and actions won't be 'bridged' or will they? 2. The Apple documentation describes an entirely different process which involves the Bindings tab of the Inspector in Interface Builder and I don't really understand it very well. What confuses me is this: 1) are they two different methods of achieving the same end and eventually will coalesce into some standard that fits Xcode better or 2) are they instead stark differences in philosophy and underlying architecture in accessing the PyObjC Bridge which will stay diverged with one eventually obviating the other? The advantage of the Apple-documented way is that I can use Xcode for building the application which is very convenient and consistent but I don't really 'get' the Binding tab just yet since I would think that it would show the bindings I make the traditional way with the Control-click graphic connections if the underlying architecture is consistent--and it doesn't. So they seem mutually exclusive and not consistent in Xcode. That worries me frankly--it makes them both seem more like hacks. It seems to be one way or another. I find this 'schizophenic' approach to development tools unsettling and it concerns me that I risk very fast obsolescence of my work if I pick the wrong build approach. Or worse: that both methods are just temporary and will disappear capriciously one OS revision without warning.So it begs the question: which method will be the 'main- stream' recommendation going forward? The SourceForge team is clearly a standard-setter but then again Apple has 'vendor power' when it comes to Cocoa and Objective-C. The Apple way is far better integrated with Xcode but seems strained and awkward when creating the outlets and actions because it doesn't use the 'standard' that Objective-C/Cocoa projects use and all the Cocoa tutorials use.. Or am I just confused because Cocoa and the Apple Tools is fairly opaque to me at this point?

3 2

Re: [Pythonmac-SIG] wxPython building process on Mac Os X 10.4.x
by Bill Northcott Feb. 3, 2006

Feb. 3, 2006

Hi Adriano Back in September you wrote to pythonmac about build errors with Python 2.4 and wxPython 2.6.1. Did you ever find the answer to these? /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long double gammal (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2027: error: 'gamma' was not declared in this scope /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long int rinttoll (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2141: error: 'rinttol' was not declared in this scope /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h: In function 'long int roundtoll (long double)': /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/fp.h:2179: error: 'roundtol' was not declared in this scope error: command 'gcc' failed with exit status 1 I am trying to build wxPython 2.6.2 with Python 2.4 on MacOS X 10.4.4 and have similar problems. Cheers Bill Northcott

1 0

Re: [Pythonmac-SIG] wxPython build issue
by Bill Northcott Feb. 3, 2006

Feb. 3, 2006

One more observation on my last posting: The #ifndef POSIX_C_SOURCE condition on strcasecmp() in <string.h> seems to have been introduced between Panther and Tiger. Looking in the 10.3.9 SDK, strcasecmp() is only conditional on #ifndef _ANSI_SOURCE. So presumably the build works on Panther, but the new <string.h> seems to me to be correct, as in standards compliant. I have seen similar on Tru64 and Solaris, and seen similar problems arise. Bill Northcott

1 0

wxPython build issue
by Bill Northcott Feb. 3, 2006

Feb. 3, 2006

I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77) with some difficulty, which may just be me being dense. I have the latest ActivePython and have built and installed wxMac-2.6.2 widgets without problems. However when I attempt to build wxPython it breaks here: building '_core_' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -fPIC -fno-common -dynamic -DNDEBUG -g -O3 -Wall -Wstrict- prototypes -DSWIG_TYPE_TABLE=_wxPython_table -DHAVE_CONFIG_H - DWXP_USE_THREAD=1 -UNDEBUG -D__WXMAC__ -D_FILE_OFFSET_BITS=64 - D_LARGE_FILES -DNO_GCC_PRAGMA -Iinclude -Isrc -I/usr/local/lib/wx/ include/mac-ansi-release-2.6 -I/usr/local/include/wx-2.6 -I/Library/ Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/ helpers.cpp -o build/temp.darwin-8.4.0-Power_Macintosh-2.4/src/ helpers.o -O3 In file included from /usr/local/include/wx-2.6/wx/memory.h:20, from /usr/local/include/wx-2.6/wx/object.h:25, from /usr/local/include/wx-2.6/wx/wx.h:16, from include/wx/wxPython/wxPython_int.h:19, from src/helpers.cpp:16 /usr/local/include/wx-2.6/wx/string.h: In function `int Stricmp(const char*, const char*)': /usr/local/include/wx-2.6/wx/string.h:135: error: `strcasecmp' undeclared (first use this function) I can't say I have much understanding of the wxWidgets/wxPython build process but the error seems to go back to code in configure.in from wxWidgets. On lines 1632 to 1680 of configure.in there is code which appears to attempt to identify whether strcasecmp() is declared in <string.h> or <strings.h>. It is erroneously concluding that <string.h> is appropriate, and HAVE_STRCASECMP_IN_STRING.H is defined. However in <string.h> the declaration of strcasecmp() is conditional on #ifndef POSIX_C_SOURCE. So the wxPython compile breaks. Apple's man page is quite clear that to use strcasecmp(), <strings.h> is required. Indeed it says, "Their prototypes existed previously in <string.h> before they were moved to <strings.h> for IEEE Std 1003.1-2001 (``POSIX.1'') compliance." This would also seem to be compliant with OpenGroup standards as at: http://www.opengroup.org/ onlinepubs/007908799/xsh/strcasecmp.html. While Googling I came across some messages from Bob on what seemed to be a closely related issue Is there something that I am doing wrong or does this need fixing? If someone could give me some pointers about exactly how the wxWidgets configuration propagates down to wxPython, then I might be able to cook up some sort of fix. Also does anyone understand when and where POSIX_C_SOURCE gets defined? Bill Northcott

1 0

Re: [Pythonmac-SIG] MySQLdb lib help
by Bob Ippolito Feb. 1, 2006

Feb. 1, 2006

On Jan 18, 2006, at 9:10 PM, David Warde-Farley wrote: > > On 18-Jan-06, at 2:55 PM, Bob Ippolito wrote: > >> It's fine, unless you want to create redistributable applications. >> If you build an app with a vendor Python, it will only reliably work >> on that version of the OS. Future versions of Mac OS X will >> absolutely throw away Python 2.3 for Python 2.4 (or 2.5, depending on >> when that happens) and none of your applications will still work. > > Exactly what Bob said. Other than that, Apple's Python build wasn't > linked against GNU readline and thus is not very nice to use on the > interpreter command prompt (try the arrow keys with /usr/bin/ > python; I find it's a real pain not being able to at least up-arrow > to repeat previous commands a la bash/DOSkey/etc.). Dave forgot to CC the list... but if you want readline support for Apple Python 2.3 you can download the package from http:// pythonmac.org/packages/ and there are eggs up on Cheese Shop for use with easy_install. Note also that ActiveState's Python 2.4.2 also ships sans-readline due to license (same reason as Apple). I don't have a package for that, but there is an egg. -bob

6 30