Re: [Pythonmac-SIG] Question using cvs2svn
On 2-dec-04, at 18:19, Janice Cheung wrote: Greetings! I recently installed cvs2svn (a version of subversion) on my Mac OS X 10.3.6. I've also installed Sleepycat Berkeley DB 4.3.21. When I attempt to run $"cvs2svn" at the prompt, I receive this error message: ERROR: your installation of Python does not contain a suitable DBM module. This script cannot continue. to solve: see http://python.org/doc/current/lib/module-anydbm.html for details. That is indeed a rather stupid error message: what it tries to say is that the only Python dbm modules that are available are not good enough for cvs2svn. So you need to install one that is good enough (such as Sleepycat Berkeley DB), but you also need to install the corresponding Python module. Does anyone happen to know about an easy to install DB + Python module? Bob, anything in your PackMan database, maybe? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On 2-dec-04, at 16:11, Bob Ippolito wrote: Patch your config/Makefile of your existing Python 2.3.0 installation (see a recent email of mine on the subject) Here's an idea: could we somehow incorporate your patch into one of the Python Makefiles (Mac/OSX/Makefile comes to mind) and add a test for whether it's needed too? It would be nice if anyone building 2.4 framework Python on an unpatched 10.3 would get a warning along the lines of WARNING: your Apple-installed Python needs a path to coexist peacefully with MacPython 2.4 WARNING: run "sudo make patchpython2.3" in Mac/OSX to apply the patch. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building 2.4
On 3 Dec 2004, at 10:56, Ronald Oussoren wrote: It would also be possible to monkey-patch the 2.3 install. IIRC I've posted one way to do a long time ago. That message should be in the archives. The advantage would be that you do not have to patch files in /System, we could even use this to install include files outside of /System while keeping them functional. The disadvantage is that my approach seems to induce vomitting in some people ;-) I assume that was me:-) But I can't for the life of me remember how you did it. Do you have a reference? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Python Framework vs 'traditional' was Re: version numbers and dependencies
did someone already tried to compile python 2.4 with --enable-framework _and_ tried to destroot the install? It seems utterly broken - some stuff relies on already installed files which are - of course - not yet in the installdir but inside the destroot... Hmm, I missed the original of this message, somehow (or was it on darwinports only)? This is a known problem, which is explained in Mac/OSX/Dist/README: Currently (November 2003) there is still a bug in the build procedure for $DESTROOT builds: building some of the applets will fail (in ``Mac/OSX/Makefile``) if you don't have the same version of Python installed normally. So before doing the distribution you should build and install a framework Python in the normal way. Unfortunately, the problem is rather difficult to fix. buildapplet (or py2app, or similar tools) will need to be told that we're in a destroot install situation, so that if it wants filenames it should use the non-destrooted version but if it actually needs the data that's in the files it should use the destrooted filename. I can live with the current workaround for MacPython installers, if it's a problem for darwinports file a bugreport and a solution may be available sooner:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Pythonmac-SIG Digest, Vol 20, Issue 24
The PythonIDE not starting problem is completely unrelated to your other problems. You've encountered a bug in the IDE (for which I'll add a FAQ entry shortly). If you've set your IDE scripts directory to something containing more than 200-something files the menu building code runs out of menu entries. The fix is to first remove your IDE preferences (~/Library/Preferences/Python/PythonIDE preferences), and then not set your scripts directory to something that has too many files (such as your home directory). On 20-dec-04, at 18:38, Jon Schull wrote: Now if I double click on "/Applications/MacPython-2.3/PythonIDE.app" the startup screen appears briefly and disappears. The console gets = Mon Dec 20 2004 = 12:31:36 US/Eastern = Traceback (most recent call last): File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ PythonIDE.py", line 59, in ? _PythonIDEMain.PythonIDE() File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ PythonIDEMain.py", line 41, in __init__ Wapplication.Application.__init__(self, 'Pide') File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ IDE/Wapplication.py", line 28, in __init__ FrameWork.Application.__init__(self) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/FrameWork.py", line 115, in __init__ self.makemenubar() File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ IDE/Wapplication.py", line 275, in makemenubar self.makeusermenus() File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ PythonIDEMain.py", line 159, in makeusermenus self.makescriptsmenu() File "/Applications/MacPython-2.3/PythonIDE.app/Contents/Resources/ PythonIDEMain.py", line 261, in makescriptsmenu self.scriptswalk(fsr.as_pathname(), self.scriptsmenu) File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ IDE/Wapplication.py", line 309, in scriptswalk self.scriptswalk(path, submenu, done) File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ IDE/Wapplication.py", line 309, in scriptswalk self.scriptswalk(path, submenu, done) File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ IDE/Wapplication.py", line 308, in scriptswalk submenu = FrameWork.SubMenu(menu, name) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/FrameWork.py", line 708, in SubMenu return menu.addsubmenu(label, title) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/FrameWork.py", line 595, in addsubmenu sub = Menu(self.bar, title, -1) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/FrameWork.py", line 545, in __init__ self.id, self.menu = self.bar.addmenu(title, after, id) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/FrameWork.py", line 479, in addmenu id = self.getnextid() File "/System/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools/ IDE/Wapplication.py", line 433, in getnextid id = self.possibleIDs[0] IndexError: list index out of range -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Read Strings from Resources
On 20-dec-04, at 20:06, [EMAIL PROTECTED] wrote:
I working on a project, where I want to read a STR# resource and write
it
into an xml file.
With Carbon.Res I can easily access the file an read the string
Resources
for each ID. But with the Res.Get1Resource('STR#', id).data I get all
the
strings in the list in one string only. Is there a method in python
like
GetIndSting or something like it?
To my surprise there isn't! And nobody ever complained!
The problem is that the Carbon modules are generated automatically, and
GetIndString is declared in TextUtils.h, not in Resource.h, so it isn't
picked up.
I've filed a bug report (#1089399), so it'll be fixed, but that's a
long term thing (not before 2.5). In the short term you'll have to
parse the STR# resource yourself. I'm not 100% sure, but I think
they're just a null-byte separated list. If they're something else (a
list of Pascal strings?) I'll just hope someone will chime in.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Installing Twisted-1.3.0
On 21-dec-04, at 23:38, Bob Ippolito wrote: building 'twisted.spread.cBanana' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.o -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/twisted/spread/cBanana.so ld: can't locate file for: -lbundle1.o error: command 'gcc' failed with exit status 1 That is quite a strange error, but cBanana is not required nor even enabled by default these days. This is harmless. Well, as you say, it could point to a problem with the Xcode/gcc installation. It appears as if the "-Wl,-F. -Wl,-F. -bundle" options don't get passed correctly to the linker. "-Wl,-F." means: please pass "-F." to the linker. But it appears as if it is somehow combined in a funny way with the following "-bundle" option. If gcc is funny this could well affect other command lines as well. Check that gcc is indeed Apple's gcc, and not something else. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Read Strings from Resources
On 22 Dec 2004, at 00:22, Opstad, Dave wrote:
I've filed a bug report (#1089399), so it'll be fixed, but that's a
long term thing (not before 2.5). In the short term you'll have to
parse the STR# resource yourself. I'm not 100% sure, but I think
they're just a null-byte separated list. If they're something else (a
list of Pascal strings?) I'll just hope someone will chime in.
According to MacTypes.r (in the last Universal Headers revision), the
Rez format for a 'STR#' resource is as follows:
type 'STR#' {
integer = $$Countof(StringArray);
array StringArray {
pstring; /* String */
};
};
So it looks like a 2-byte count followed by an array of Pascal strings.
Ah yes. And now that I see this I seem to remember that the pstrings
are padded to a 2-byte boundary.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Tkinter and Python 2.2
If I have the source code for TkAqua, can it be modified and recompiled as a separate binary for PoserPython? [I'm guessing this is preferable to trying to get one instance of TkAqua to work for both instances of Python] Does it make any difference if I don't have any other instances of TkAqua on my system? I don't think there's any need to recompile TkAqua, or anything drastic like that. If you have TkAqua installed on your system the only thing you really need to do is build the _tkinter extension module against that TkAqua. Now, depending on how old the Python is that PoserPython is based on this may be a bit of work, but doable. If PoserPython's version is one that already supported linking against AquaTk you just rip the relevant portion out of the toplevel setup.py for that Python version. If the Tk support code in setup.py has all sorts of references to "-framework Tk" then that should work. If it appears that setup.py for the relevant Python version does not support AuqaTk then there's a bit more work to do. You can try to get setup.py from a recent (2.3 or later) Python distribution and working from there. Trying to isolate only the _tkinter-relevant code in Python's main setup.py can be a bit daunting. It may be worthwhile to look at the setup.py for Fredrik Lund's PIL (the Python imaging l,ibrary) package. It has also isolated and duplicated/modified the _tkinter build code and incorporated it into their own setup.py (because PIL will optionally build a custom _tkinter that has support for PIL images). -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Let's discuss MacPython distributions for january
With the next version of Ambulant out the door and a whole week off (well, only from work, not from the kid or the wife:-) I'd like to get some work done on Python again. And with Python 2.3.5 and probably 2.4.1 imminent that seems to be good timing. Part of this email is highly technical, but part is (somewhat) end-user oriented, so feel free to comment only on the parts that interest you. In january I'd like to get two MacPythons out: - MacPython 2.4.1 (full installer for Panther, time permitting for Jaguar too) - MacPython 2.3 additions, version 3 The main feature of these is that they should coexist peacefully. With each other, and with user-built (or fink-installed, or whatever) Python 2.3.5 or 2.4.1. And MacPython 2.4.1 should coexist peacefully with an unmodified Apple Python 2.3 (possibly after making slight modifications to that 2.3 installation). More on this below. The second feature is that they'll finally have the newer version of Package Manager (or, actually, the underlying pimp module), which allows the maintainer (me:-) to have a single database for all 10.3.X releases of MacOSX. And, of course, there's bug fixes for things like the PythonIDE scripts folder bug and such. First question: what am I missing? Anything that should really go into either (or both) of these? Any serious bugs that you want fixed? Second question: I think the solution to peaceful coexistence is that all Pythons adopt the solution sketched in Bob's mail <http://mail.python.org/pipermail/pythonmac-sig/2004-December/ 012292.html>. That discussion is rather technical, but what it boils down to is that all Pythons (on 10.3) build their extensions with "-undefined dynamic_lookup", thereby forestalling that extensions inadvertently pull in a second, different, Python framework. Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and sketched in the mail mentioned above). Fixing this in the Apple-installed 2.3 is a bit more difficult, though. We can either modify it in-place (with admin permission) or do a complicated patch that Ronald came up with last year. While in general you should not muck with Apple-installed things I think that for this once I have a preference for the simple in-place modification over the slightly convoluted patch. Opinions, anyone? Then there's the question of how to get the patch in place, and here I need a bit of help. For people building Python 2.4.1 from source I can add a test (in "make frameworkinstall") for an unpatched Apple 2.3 and print a warning that people need to apply the patch. The MacPython 2.4.1 and 2.3-additions-version-3 installers could simply apply the patch. But I'm not sure what to do about Pythons installed by Fink and darwinports and other such packages. There's also the question of the form of the patch. What needs to be done (in case of the in-place modification) is a one-line change to /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ config/Makefile. The patch could either be a shell script (containing a simple "ed" command to patch the file, or maybe a Python script so it can do some checking) or a .pkg file. The former is easiest for people building from source, the latter would also be a partial solution for fink users (partial, because it would allow them to apply the patch, but there's still no way to warn them that it is needed). Or should we do both? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Let's discuss MacPython distributions for january
On 24-dec-04, at 1:01, Bob Ippolito wrote: In january I'd like to get two MacPythons out: - MacPython 2.4.1 (full installer for Panther, time permitting for Jaguar too) - MacPython 2.3 additions, version 3 There is the small issue of Zope X3 not being compatible with MacPython 2.3.0 .. so perhaps a 2.3.5 distro should also be considered, or considered instead of the additions? Well, I definitely want a version 3 of the additions, to replace the current one. A 2.3.5 MacPython distribution wouldn't tie in with Apple's Python. But is there any reason to have the whole MacPython stuff (toolbox modules, etc) to run Zope? Because if there isn't then a simple Python 2.3.5 (non-framework, standard unix build, installed into /usr/local) should do the trick. Actually, if we get everything right in the source tree then the darwinports or fink distribution should work just fine. The second feature is that they'll finally have the newer version of Package Manager (or, actually, the underlying pimp module), which allows the maintainer (me:-) to have a single database for all 10.3.X releases of MacOSX. Hopefully the GUI bugs are fixed too? They should be. But could you check in the bug database whether there are any still open, please? What about distributing a version of Ronald's written-in-PyObjC PackageManager instead, and having MacPython 2.4.1 and MacPython 2.3.5 coming batteries included with PyObjC 1.2 plus py2app 1.7 (replacing BuildApplet with py2applet)? Later, later. First I want to get distributions out that are pretty similar to what we have now, but with the problems (conflicts when building plugin modules, endless hassle to keep PackMan database up to date) fixed. +0 for any patches to 2.3.x explicitly for Fink or Darwinports. Not specifically for Fink or Darwinports, but I want to get the -undefined dynamic_lookup fix into the source distributions for 2.3.x (and 2.4.x), so fink and darwinports should pick it up automatically. Unless they have their own fixes, and in that case their fixes are either just as good, or else we can scald the in public:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Debuggers wanted for fixup script
I've added a script Mac/OSX/fixapplepython23.py to the CVS repository, only to the trunk for now, that will inspect and fix the Apple-installed Python 2.3 as per what we discussed here (making extensions build in a way that works, even if newer Pythons are installed). I'd like it if people could test the script, and test whether they see the warning (you need to run this script) if they do a framework install of 2.5a0 if their apple-python needs patching. Also, if people could run this on OSX 10.2 and 10.4, just to see that it doesn't cause any problems there, would be nice. The script does all sorts of error-checking (which hasn't been tested yet, of course:-), and I'm actually thinking of having the patch-installer (also discussed previously, this is a .pkg installer that will fix Apple-installed Python for people not building from source) also simply run this script, in stead of bluntly installing a modified copy of lib/config/Makefile. Opinions on this? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] More testers needed: Fix installer
Ok, Bob, you win:-) I've created an installer package that replaces the Makefile after a simple test that you're actually running 10.3 and have that Makefile in the right place (i.e. didn't mess too much with your installation). If people could test this that'd be nice. Again, I'm especially interested in feedback from people running 10.2 or 10.4 (where the installer should refuse to run, with a decent message). You can find the package at <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On 27-dec-04, at 15:04, Michael Hudson wrote: Indeed you can, and it seems to work (tm) on Panther here, but I'm *reasonably* sure you have chosen the wrong name for the package :) Yeah, consider that a working title. I may call it "The Installer that makes Apple-Installed Python on 10.3 build correct extension modules even after installing newer framework builds of Python". But suggestions for shorter names are welcome... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On 27-dec-04, at 17:47, Michael Hudson wrote: On 27 Dec 2004, at 16:38, Bob Ippolito wrote: On Dec 27, 2004, at 11:31 AM, Michael Hudson wrote: But 10.3 is Panther, not Jaguar, right? Yes. That was rhetorical :) I'm not being completely thick, am I? The file should surely be called PantherPythonFix.dmg. Yes, yes, yes, yes, yes. You have now all made your point, I mixed my cats up:-) Sorry about that, -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer
On 27-dec-04, at 17:44, Bob Ippolito wrote: You can find the package at <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. The Makefile is missing the MACOSX_DEPLOYMENT_TARGET=10.3 before the $(CC) .. which means that for most people, it won't compile extension modules, because not everyone has this set in their login scripts.. Ah, forgot about that one, thanks! I'll pull the installer, and I'll create a new one tomorrow (with a different name:-). The same problem holds for the fixapplepython script, so I'll fix that one too. What would be the easiest fix for 2.3.5: backporting the distutils fixes (so it'll set MACOSX_DEPLOYMENT_TARGET) or simply setting that variable in the $(LD) macro (through configure)? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] More testers needed: Fix installer v1.1
There's a new one, with a new name and the environment bug fixed: <http://www.cwi.nl/~jack/macpython/PantherPythonFix.dmg>. Please give it a try, -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Using TkAqua /Tkinter with custom Python 2.2
On 28-dec-04, at 20:46, Andrew Roazen wrote: I was referred here by Kevin Walzer at tcl-mac's mailing list: > Can any of the core MacPython developers take a look at this thread and > give us the Pythonic viewpoint on these questions? (hooking TkAqua and > Tkinter into an old version of Python for the Mac with undocumented, > proprietary modifications: what issues should he consider?) I posted a reply to this (I think on both pythonmac-sig and mactcl) last week. Did you see that message? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2
On 29-dec-04, at 4:35, Bob Ippolito wrote: This is the wrong fix. Distutils is dumber than you think. This patch just breaks C++ compilation in a different way. The correct solution is a patch to distutils of some kind. from distutils/unixccompiler.py:174 if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] self.spawn(linker + ld_args) "linker" is the variable expanded LDSHARED (or whatever comes out of sysconfig.customize_compiler). Bah! Any suggestions as to what to do to get c++ compilation fixed? Also, could you point me to a readily available extension package that uses c++? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How badly is _locale broken?
On 29-dec-04, at 11:32, Ronald Oussoren wrote: I know that. But not linking with CoreServices should fix _locale for python scripts that don't use mac-specific features. If I understand correctly it's the loading of CoreServices that causes the _locale problem, right? If that's indeed the case then I think not linking with CoreServices would make this problem even worse: imagine a scenario where an unsuspecting user has working code in a toy app, but it fails when used in his GUI app (which happens to use CoreServices). Or code that works standalone but not in . -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] The PantherPythonFix installer and C++ extensions
On 29-dec-04, at 11:40, Bob Ippolito wrote: [Bob notes that my PantherPythonFix installer will break C++ compilation because distutils simply replaces the first component of LDSHARED with "c++"] Any suggestions as to what to do to get c++ compilation fixed? I can think of two ways: 1. Patch distutils to actually do os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because CCompiler.spawn doesn't take an environment dict. 2. Patch distutils to skip over environment variables (basically change that "0" into something smarter). This is probably less desirable because who knows where this happens, and who knows what third party compiler subclasses used this original stupid code as a template. Both of these mean that "the simple installer that just puts a new Makefile into lib/python2.3/config" has just gone out the window:-( I think I have a better alternative to both of these suggestions (basically what I just checked in for 2.5a0: allow the Makefile to force a setting for MACOSX_DEPLOYMENT_TARGET, unless it was set already), but that still leaves the problem that there's more files to patch. We could of course replace sysconfig.py and sysconfig.pyc in place, but I don't feel happy about that. (So: please argue that it isn't a problem). Or we could install a newer, patched distutils into /Library/Python/2.3. But that has the problem that it'll obliterate any other newer distutils the end user may have installed. Also not a good idea. Or maybe someone here has a silver bullet? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?
On 29-dec-04, at 17:58, Kevin Walzer wrote: I'm curious about whether BuildApplet and PythonIDE will be included in the next iteration of MacPython, or whether these will be replaced by py2app and PyOxide. Although I know these are old technologies, especially BuildApplet, I'd like to request that they be retained, even if they're not updated or enhanced. Just to give the party line on this: - BuildApplet and PythonIDE will be with us as-is for the MacPython 2.4 series of releases. They may move into some dark corner when replacements are available, but they will be available. - Like you (and has, if I understand him correctly) I think the minimal functionality BuildApplet provides has a place in the grand scheme of things. Bob is 100% right in all of his arguments (it doesn't work, it can't work, it won't work anywhere else, it'll only work in a very limited number of cases, etc etc etc), but BuildApplet has been with us for 10 years now and proven it's worth. And what it does was copied from "save as applet" in Apple's Script Editor (along with all the warts) and that is still going strong after 15 years. So if I have a say in things there'll be something as simple as BuildApplet for a long time to come:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions
On 30-dec-04, at 10:02, Ronald Oussoren wrote: In the quick-and-dirty-hacks category: you could write two simple shell-scripts that start the compiler with the right environment variables: run-cc: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" run-c++: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" Here's an even better idea (I think), please think about whether it would fly: In the Makefile we not only change LDSHARED and BLDSHARED to start with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll teach distutils to fiddle with our command lines:-) Only question is: would this have any adverse side efffects? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions
On 30-dec-04, at 21:01, Bob Ippolito wrote: On Dec 30, 2004, at 2:52 PM, Ronald Oussoren wrote: On 30-dec-04, at 18:49, Bob Ippolito wrote: On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote: On 30-dec-04, at 10:02, Ronald Oussoren wrote: In the quick-and-dirty-hacks category: you could write two simple shell-scripts that start the compiler with the right environment variables: run-cc: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" run-c++: #!/bin/sh env MACOSX_DEPLOYMENT_TARGET=10.3 gcc "[EMAIL PROTECTED]" Here's an even better idea (I think), please think about whether it would fly: In the Makefile we not only change LDSHARED and BLDSHARED to start with " env MACOSX_DEPLOYMENT_TARGET=10.3", but also CXX. That'll teach distutils to fiddle with our command lines:-) Only question is: would this have any adverse side efffects? Same problem. If you replace the first word, you'll end up with either "g++ gcc..." or "g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc..." depending on whether "env" was used or not. Wouldn't you end up with 'env MAC.. gcc' when linking c++ extensions? distutils changes the first word which is 'env' in either case. Oh.. right. But then given a bunch of .o files, it will probably not link in libstdc++. Who knows what SciPy will do with Fortran... Sigh, you're right. Which leaves two options: 1. Always use g++ to link in LDSHARED (in addition to the "env" tricks above). Would this have any adverse consequences? 2. Use Ronald's idea of wrapper scripts for both gcc and g++. We'd have to come up with decent names, though (so that if they're accidentally deleted the user may at least have an idea what they were supposed to do), maybe something like macpy23-gcc and macpy23-g++? Also, we'd need a place to put them. /Library/Python/2.3-PythonPantherFix? /System/yaddayaddayadda/python2.3/config/PythonPantherFix? Other ideas? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Testers needed again: Fix installer 1.2
There's yet another new version of the Python 2.3 fix installer available: <http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg>. This one should also make C++ extensions build correctly again with apple-installed Python 2.3 on 10.3, after installing a later framework build. Please let me know whether it works, especially with real C++ extensions (I only tried a toy extension). And, for the record, I used Ronalds solution of using driver scripts for gcc and g++ that set the MACOSX_DEPLOYMENT_TARGET environment variable before running the compiler. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3
On 2-jan-05, at 4:40, Bob Ippolito wrote: +SCRIPT="""#!/bin/sh +export MACOSX_DEPLOYMENT_TARGET=10.3 +exec %s "[EMAIL PROTECTED]" This script should check to see if MACOSX_DEPLOYMENT_TARGET is already set. If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an extension that requires 10.4 features) then I'm going to have some serious problems with this fix. I was going to do that, but then I thought it didn't make any sense, because this script is *only* used in the context of Apple-provided Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other than 10.3 (be it lower or higher) while compiling an extension for Apple's 2.3 is going to produce disappointing results anyway. But, if I've missed a use case, please enlighten me. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3
On 2-jan-05, at 22:35, Bob Ippolito wrote: On 2-jan-05, at 4:40, Bob Ippolito wrote: +SCRIPT="""#!/bin/sh +export MACOSX_DEPLOYMENT_TARGET=10.3 +exec %s "[EMAIL PROTECTED]" This script should check to see if MACOSX_DEPLOYMENT_TARGET is already set. If I have some reason to set MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an extension that requires 10.4 features) then I'm going to have some serious problems with this fix. I was going to do that, but then I thought it didn't make any sense, because this script is *only* used in the context of Apple-provided Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other than 10.3 (be it lower or higher) while compiling an extension for Apple's 2.3 is going to produce disappointing results anyway. But, if I've missed a use case, please enlighten me. You're right, of course. I had realized that I was commenting on the fixpython script after I had replied, but my concern is still applicable to whatever solution is used for Python 2.4.1. Anything lower than 10.3 is of course an error, in either case. 2.4.1 will install this fix into Apple-installed Python 2.3 (if applicable, i.e. if you're installing 2.4.1 on 10.3), but for its own use it will have the newer distutils, which understands that it needs to pick up MACOSX_DEPLOYMENT_TARGET from the Makefile, so it'll never see these scripts. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Live fast, die young: testers wanted for new MacPython additions
Folks, I have a first version of the next "MacPython additions for 10.3" available. Please give it a try, including test-driving the Package Manager (which has gone up to version 0.5, and has had all the packages updated to newer versions). Report here with any problems you find, and also if you think there are fixes missing. I'll wait for about a week and unless anyone (including myself) has found problems in that time this'll replace the old additions installer. Download from <http://homepages.cwi.nl/~jack/macpython/MacPython-Panther-2.3 -3b1.dmg>. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
On 3 Jan 2005, at 23:40, Bob Ippolito wrote: Most people on Mac OS X have a lot of memory, and Mac OS X generally does a good job about swapping in and out without causing much of a problem, so I'm personally not very surprised that it could go unnoticed this long. *Except* when you're low on free disk space. 10.2 and before were really bad with this, usually hanging the machine, 10.3 is better but it's still pretty bad when compared to other unixen. It probably has something to do with the way OSX overcommits memory and swapspace, for which it apparently uses a different algorithm than FreeBSD or Linux. I wouldn't be surprised if the bittorrent problem report in this thread was due to being low on diskspace. And that could also be true for the original error report that sparked this discussion. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] .pydistutils.cfg (was: pychecker)
Gosh, I'd never even heard of .pydistutils.cfg. I've added a note to the FAQ pointing to it. Then I looked at the distutils code, and noticed that there's also an optional distutils.cfg inside the package. So that made me wonder: we could install a symlink in /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that points to, say, /Library/Python/2.3/distutils.cfg, and put an (admin-editable) file there that directs scripts tot the right place system wide (/usr/local/bin by default, probably). -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] .pydistutils.cfg (was: pychecker)
On 4-jan-05, at 14:42, Bob Ippolito wrote: On Jan 4, 2005, at 8:09 AM, Jack Jansen wrote: I'd never even heard of .pydistutils.cfg. I've added a note to the FAQ pointing to it. It has some more features in Python 2.4, you can use it to add new build command packages to distutils out-of-tree (like py2app, bdist_mpkg, etc.). Of course, very few distutils extensions are implemented in away that is compatible with this new feature, but it's there and I'll probably end up making py2app and bdist_mpkg compatible. Interesting... Although: you only need py2app and bdist_mpkg on the supplier-side (right?), so it doesn't really buy us all that much except a bit of convenience. Then I looked at the distutils code, and noticed that there's also an optional distutils.cfg inside the package. So that made me wonder: we could install a symlink in /System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that points to, say, /Library/Python/2.3/distutils.cfg, and put an (admin-editable) file there that directs scripts tot the right place system wide (/usr/local/bin by default, probably). +1 on the idea +1 for /usr/local/bin as the "right place" Not so sure about install-data pointing to /usr/local/share (earlier on in the thread), because some packages might try and locate their data files using means other than distutils (sys.prefix relative). Yeah, I was wondering about that one too. I'll leave it out, if the end user wants it s/he can edit the file. Another thing that would be nice is to have some admin-writable place to put header files (in addition to Python's own headers) too. But that would require a patch to distutils and might need to happen in the 2.5 tree. [EVIL GRIN] What happens if we set both "include_dirs" and "headers" to, say, /Library/Python/2.3/python-includes in distutils.cfg? We'd need a bit of extra glue for PackMan binary installs (so it sends include files there too), but if this would cause include files to be installed there *and* that directory added to the -I flags we'd be all set, I think... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.4 Framework build?
On 7-jan-05, at 21:02, Nick Matsakis wrote: It appears to me that there is not a python 2.4 framework build in fink. Is this actually the case? It is my impression that a framework build is necessary to use appscript and other Mac goodies. Is this still the case with 2.4? Finally, what is the easiest way to get a framework build of 2.4? Is there a binary installer somewhere? I'm working on a lot of distributions right now, including a 2.4.1 framework build. It can't really be finished until 2.4.1 comes out, but if people want to give a 2.4.1a0 build a try: let me know and I'll make it available. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Help - MacPython stopped running
On 7-jan-05, at 18:23, Marshall Labow wrote: Can anyone help me? I am running Panther (10.3.7) and installed the upgrade to Python 2.3 (MacPython IDE) and it worked for a few days. Now when I attempt to load the program, the splash screen appears for a few seconds and then disappears without the finder ever showing Python IDE as being active. I have tried (1) rebooting the computer; (2) re-installing MacPython; and (3) deleting the existing MacPython files and re-installing them. Nothing so far helps. Anyone have any suggestions? You've probably run into the "Scripts menu" problem. See the FAQ for a fix (in short: remove your IDE preferences file). If that doesn't help please report back, -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X
On 7-jan-05, at 22:55, Brendan Simons wrote: This is an old thread, (and an old topic) but my question is about the state of the "new tools" described in Bob's presentation at last year's pyCon. Scanning the archives, I see Jack and Just have talked about a PyObjC-based python ide since 2002. I've really anxious to see how they are coming along. Aren't we all:-( The problem is one of time: I've spent all of my working hours the last year on a completely un-pythonic project (www.ambulantplayer.org, but I do plan to do Python bindings some time this year), and now that I finally have some time to do Python work I'm concentrating on the important infrastructural problems (mainly the "multiple-python-problem" and getting Package Manager to be more maintainable). I assume Just is similarly occupied by other priorities (hmm, that doesn't look like english:-). I haven't even had the time to seriously look at PyOXIDE, let alone the other contenders. But I'm still very interested in getting a good replacement for the IDE, it's just that I don't have the time to invest in it. Is there some way we could turn this "next generation IDE" thing into a group effort? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SOAPpy
At best, your various Python installations (in your case, at least Apple's Python 2.3 and darwinports Python 2.4) will be completely independent. At worst they'll break each other, but that's a different story for now:-) What seems to have happened in your case is that you installed fpconst and pyXML into Apple's Python 2.3, then got SOAPpy from darwinports (which installed its own separate Python 2.4). You can check this be seeing whether there' s fpconst and pyXML stuff in /Library/Python/2.3, which is where Apple's Python keeps its extension modules. Apparently darwinports' dependencies aren't complete, otherwise it would have loaded copies of fpconst and pyXML for it's Python 2.4 too. Why SOAPpy didn't work for Apple Python I don't know. But your best course of action is probably to get the missing fpconst module into darwinports' Python 2.4, by running its setup.py again with the right python. On 10 Jan 2005, at 05:25, Kim Cascone wrote: I'm trying to install SOAPpy I first DL'd and installed fpconst and pyXML (but I don't think they are in the right place) I then DL'd the SOAPpy from the web site (not darwinports) and tried to do an install it couldn't find fpconst I went to darwinports and DL'd SOAPpy from there and it seemed to load in the dependencies for me this time but somehow I also got Python2.4 installed as well... so now when I try to build SOAPpy I get the following error: Bourbaki:/SOAPpy-0.11.6 root# python /SOAPpy-0.11.6/setup.py build Traceback (most recent call last): File "/SOAPpy-0.11.6/setup.py", line 8, in ? from SOAPpy.version import __version__ File "/SOAPpy-0.11.6/SOAPpy/__init__.py", line 5, in ? from Client import * File "/SOAPpy-0.11.6/SOAPpy/Client.py", line 57, in ? from Parser import parseSOAPRPC File "/SOAPpy-0.11.6/SOAPpy/Parser.py", line 8, in ? import fpconst ImportError: No module named fpconst I think there are some differences in the two different SOAPpy packages I DL'd, the first one was done via CVS and the second via a .tar.gz package which was DL'd and extracted...so the various parts were placed in odd places like the python2.4/ is in my /opt/local/lib (I added a $PATH for this in my ~/.bash_profile) for some reason and not in the Library/Frameworks/Python.framework/Versions/ dir can anyone tell me where fpconst should be located? as well as whether python2.4 should be in the Library/Frameworks... dir? thanks in advance! KIM _______ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [EMAIL PROTECTED]: MindVision Releases VISE X 1.5 for Mac OS X]
On 11-jan-05, at 2:01, Bob Ippolito wrote: On Jan 10, 2005, at 19:33, Neal Norwitz wrote: I thought this might be of interest here. The PSF owns a license to VISE. Jack knows the details. I think that this is only really relevant to Mac OS9. I'm not sure if Jack plans to make another release for OS9? I plan to do a final 2.3.5 release. But that does depend on my OS9 partition still starting up (I've reshuffled things), I'm not going to install OS9 and CodeWarrior and all that from scratch. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Testers needed again: Fix installer 1.2
On 11-jan-05, at 11:09, Michael Twomey wrote: Hi, I just tried out the installer and it works fine, but it appears to have littered my disk with CVS directories, was that intentional? (I'm guessing not) Good catch! I've created a new installer that doesn't have this problem. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Any suggestions for a questionnaire site?
Folks,
I want to do a questionnaire shortly, on the subject of which
installers people want most (2.{3,4}.X for 10.{2,3}, mainly).
That'll help me spend my time most efficiently (my MacPython time, that
is:-)
Does anyone know of a decent site that hosts such questionnaires that
is both easy to use and cheap (preferably free:-)?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?)
On 14-jan-05, at 23:57, Bob Ippolito wrote: I have traced the problem. It is a two-parter: (1) There is a module namespace conflict: WebWare has a package named WebKit PyObjC has a package named WebKit As far as I know this is the first time this potential problem with python's naming convention is seen in the wild. Maybe it's worth it to report it to python-dev? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] a question about paths
On 17 Jan 2005, at 20:01, Robert Costain wrote: I downloaded the source for Python 2.3.4 and ran configure, make and make install - I have some experience doing installations like this and am quite comfortable doing it. It appears to have been installed correctly, but when I run "python -V" in Terminal to check the version number, it still shows the Apple-installed version 2.2. How do I get the system to default to the new installation of Python? The new Python will be in /usr/local/bin/python, you have to make sure it is used in stead of Apple's Python 2.2 (which is in /usr/bin/python). It's been a long time since I installed mailman, but I wouldn't be surprised if the easiest way to get mailman to use your new Python is to re-install mailman, making sure you use /usr/local/bin/python. Do this by putting /usr/local/bin in your $PATH before /usr/bin and then running configure. [checking...] Yes, that's easiest. Or you can use the --with-python option to configure. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] coding preference
On 19-jan-05, at 18:54, Chris Barker wrote: I've never used QT, so I can't speak to the advantages. One reason I would consider switching, however, is that there are more Scientific Widgets for QT (like http://qwt.sourceforge.net/). If you don't have a need for those, then wx should be fine. I've only used it from C++, and only on Linux (the multimedia projects I do tend to grow platform-dependent UI solutions), but I was favorably impressed. Functionality tends to be in the place where you expect it, which is where most GUI packages break down (including Cocoa), and the documentation is pretty good. For Linux standards things look absolutely great on-screen. Which brings me to my real point: I don't think a good cross-platform GUI toolkit is possible. Period. There are some things that simply cannot be matched programmatically, specifically when paradigms are different. So while a really good x-platform GUI toolkit may get the "look" right, I don't think it'll ever manage getting the "feel" right. Which means your stuck with the worst of both worlds: something that looks like a (say) Mac application but doesn't behave like it. My solution: for throwaway applications consider a cross-platform toolkit, for anything serious use MVC and code the view and controller in a platform-native toolkit. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
On 23-jan-05, at 15:55, Bob Ippolito wrote: On Jan 23, 2005, at 9:29, has wrote: Just reading up on Automator development <http://developer.apple.com/macosx/tiger/automator.html> and wondering if the MacPython community (or anyone in it) has any plans to 0wnz0r it yet? Like providing a 'Python Automator Action' template for Xcode, flogging a nice introductory 'Developing Automator Actions with Python' article to online tech sites like O'Reilly, making themselves a presence on Automator mailing lists and forums when they arrive, etc. With Tiger arriving soon, seems like a grand opportunity for someone with a pre-release build and a hankering for MacPython evangelism to get in at the head of the rush and mop the floor with the competition. :) Given the description, it would be trivial to write an Automator Action in PyObjC 1.2+ using the py2app plug-in bundle support. I doubt I'll be using Automator often enough to become a PyObjC Automator evangelist though. What's the advantage of PyObjC here? Just because it makes it easier to write the plugin, or does it help with writing the Python code too? Because I wouldn't mind having automator support in a future "MacPython for Tiger additions"... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] coding preference
ining. It certainly wasn't as 'slick' as an Apple app, but it worked and some people quite liked it. And in the end, that's how I personally measure whether a technology is "good" or not. Whether or not it has a positive impact. Fully agreed. I guess that where I said "throwaway app" I should have said "applications that provide a unique service that isn't available anywhere else". Whether that unique service is for you yourself only (as in a throwaway app) or for a larger community isn't the point. But if your app is competing with other products (an IDE, an image editing program, a database or spreadsheet, whatever) it will really have to stand out in functionality to offset the disadvantages of a cross-platform toolkit. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] python.h and veclib.h incompatible?
Google found one possibly interesting reference,
<http://mail.python.org/pipermail/pythonmac-sig/2003-September/
008759.html> and the rest of that thread.
The trick seems to be to include before "python.h".
On 25 Jan 2005, at 03:31, Brian Clarkson wrote:
Hello.
I was swig'ing an extension that made use of veclib in its internals
and discovered that if python.h is included before veclib.h that
compilation will not succeed. It seems they are interacting so that
parts of fp.h are being left out when they shouldn't be.
I have distilled the problem down to the following simple test case:
begin test.cpp
#include
#include
#include
using namespace std;
int main(){
cerr << scalb(3,4) << endl;
return 0;
}
end test.cpp
Which when compiled as follows:
gcc -I/sw/include/python2.3 -c test.cpp
gives the following errors:
In file included from /sw/include/python2.3/python.h:70,
from test.cpp:1:
/sw/include/python2.3/objimpl.h:255: warning: use of `long double'
type; its
size may change in a future release
/sw/include/python2.3/objimpl.h:255: warning: (Long double usage is
reported
only once for each file.
/sw/include/python2.3/objimpl.h:255: warning: To disable this warning,
use
-Wno-long-double.)
In file included from
/System/Library/Frameworks/CoreServices.framework/Frameworks/
CarbonCore.framework/Headers/CarbonCore.h:165,
from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:21,
from
/System/Library/Frameworks/veclib.framework/Headers/veclib.h:20,
from test.cpp:2:
/System/Library/Frameworks/CoreServices.framework/Frameworks/
CarbonCore.framework/Headers/fp.h: In
function `long double scalbl(long double, long int)':
/System/Library/Frameworks/CoreServices.framework/Frameworks/
CarbonCore.framework/Headers/fp.h:1896: error: `
scalb' undeclared (first use this function)
/System/Library/Frameworks/CoreServices.framework/Frameworks/
CarbonCore.framework/Headers/fp.h:1896: error: (Each
undeclared identifier is reported only once for each function it
appears
in.)
Other than refactoring in order to hide veclib.h from python.h, does
anyone have any fixes for this?
Thanks in advance!
Brian
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity?
On 26-jan-05, at 21:50, has wrote: Bob wrote: It doesn't sound like that's what he wants. Yeah I know, I was thinking laterally; throwing random ideas into the ring 'n that. iTunes... Mac Mini... media centers... cross-platform... LANs... etc... seems a very wide field; perhaps there's opportunities there for MacPython to do interesting things. Definitely, but someone has to do them:-) When I came across the Mac mini media center stuff a couple of days ago I realised that this would be an area where Python/MacPython/PyObjC/appscript could really shine. They have very few ObjC developers right now, and a rather large agenda. Think of it: the end user will want to use the remote control to browse a selection of songs (or radio stations) on-screen and have the result play through itunes. So we're talking a combination of unix programming/bit manipulation (reading /dev/ttyXX and getting the IR commands), a reasonable user interface in 640x480 (or 575xtheotherone) and talking to iTunes. Python is the only language I can think of that I would consider doing something like this in. But, of course, I don't have the time:-( But it would really make me happy if people looking for pet projects could have a look at this... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] MacPython 2.3.5 for 10.2 Release Candidate available
Folks, a MacPython 2.3.5 release for MacOSX 10.2 (also works on 10.3) is available for testing. Please download it from <http://homepages.cwi.nl/~jack/macpython/beta.html> and send feedback (preferably to the mailing list) telling me whether it works. I'm quite convinced this is going to be the final installer, but before I publicly announce it I'd like a couple of positive replies. Also, the PackMan database for 10.2 isn't as complete as I'd like yet, that'll be done in the next few days. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] MacPython 2.3.5 for OS9 Release Candidate available
Hot on the heels of 2.3.5 for 10.2 another installer is available for testing: MacPython 2.3.5 for MacOS9. Again, download it via <http://homepages.cwi.nl/~jack/macpython/beta.html> As it is likely that this is the very last release of Python for classic MacOS, marking the end of Python on the platform on which it was originally implemented initially many years ago, I suggest that if you think you may ever again need Python on MacOS9 (or Python in the Classic environment on MacOSX) you want to give this installer a quick test. Also, there is some time pressure on getting the MacOS9 release right: the license for Installer Vise will expire within a month, and it would be silly to shell out another $1000 for another year. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you find the app that matches a creator type
On 1-feb-05, at 2:09, Bob Ippolito wrote: Unfortunately these patches need to be rewritten such that they change the gensuitemodule scripts I think you mean bgen, yes?:) Yeah I mean bgen... I'm confusing the evil code generators Bob, I hope you realise that these "evil code generators" were written by Guido Himself (Our Beloved Leader, He Who Coded What No Man Coded Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) My main tasks in the MacPython world have been: a) Keep those two working with new releases of Python b) Keep those two working with whatever new stuff Steve (Our Beloved Leader, He Who Designed What No Man Designed Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) came up with. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fink, DarwinPorts vs py2app
On 10-feb-05, at 20:56, Michael Hudson wrote: Michael Maibaum <[EMAIL PROTECTED]> writes: As for Python. As soon as there is a framework version of Python that can be installed via a destroot for packaging, I'll add it to DarwinPorts. Or if someone can figure out how to hack the current version to do it... Is there a bug report for this? It has been fixed, see <http://www.python.org/sf/1091468>. The fix is in 2.3.5 and will be in the forthcoming 2.4.1. I don't think I've ever done fixes that needed so many things changed in so many places, for the benefit of so few users. But then, I myself am one of those few:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Main Python on Mac version?
This thread touches on something I've been wanting to do for some time now: add a "Which Python do I need" page to the website. I'd like to organise this by MacOS version, so people can quickly determine what they need. Here's a quick start for such a list, you can all help me by filling in the blanks, missing bits, etc. MacOSX 10.3, no special requirements: Use Apple-supplied Python with the MacPython Additions MacOSX 10.3, need Python 2.4: MacPython 2.4.1 (forthcoming) Make sure to install PythonPantherFix MacOSX 10.3, need bugfixes from Python 2.3.1-2.3.5: MacPython 2.3.5 for 10.2 and 10.3 Make sure to install PythonPantherFix MacOSX 10.3, want to distribute turnkey apps with py2app: MacPython 2.3.5 for 10.2 and 10.3 (or, when it's done, MacPython 2.4.1) Make sure to install PythonPantherFix MacOSX 10.3, need to run Zope/whatever other package: Gee... I have no idea... MacOSX 10.3, need Python 2.2 or earlier: You need to build this yourself, from source Make sure to install PythonPantherFix MacOSX 10.3 or 10.2, need Classic Python: MacPython-OS9 2.3.5 MacOSX 10.2, no special requirements: MacPython 2.4.1 (forthcoming) MacOSX 10.2, need Python 2.3: MacPython 2.3.5 MacOSX 10.2, need Python 2.2: Use Apple-supplied Python MacOSX 10.1 or earlier: Either build from source yourself, or make do with MacPython-OS9 2.3.5 MacOS 9.2: MacPython-OS9 2.3.5 MacOS 9 or 9.1: MacPython-OS9 2.3.5 Also install CarbonLib 1.3 from Apple MacOS 8.1 or later: MacPython-OS9 2.2.3 You may need to install Appearance Manager 1.1 on 8.1 Older MacOS releases, including all 68K Macintoshes: MacPython 1.5.2 -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] broken web link on Mac Python webpage
On 18-feb-05, at 22:24, Rick Thomas wrote: A (hopefully) minor nit: On the web page <http://homepages.cwi.nl/~jack/macpython/beta.html> there is a link to a "fix for Apple Python". Unfortunately, clicking the link tries to go to <http://homepages.cwi.nl/~jack/macpython/pantherfix> , which doesn't exist. The link works for me... So, either (a) I fixed it inadvertantly, (b) it only works for me, or (c) we're talking about different links? Can you check whether it works now, and if it doesn't give some details? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Qualcomm Purevoice codec
On 22 Feb 2005, at 08:24, Roger Binns wrote: Can anyone give me hints on how to access the Qualcomm Purevoice codec that is part of Quicktime from Python? In BitPim we convert between wav and Purevoice using the convertor that Qualcomm provides: http://www.cdmatech.com/solutions/products/purevoice_download.jsp Note that they don't supply it for MacOS X. There is however a codec inside Quicktime. Ideally I want as close functionality as possible as their Windows and Linux binaries. [...] I couldn't find anything relevant using Google. There is a Carbon.QT module but none of the methods appear to do any form of conversion. The quicktime module for Python 2.4 has a lot of new functionality (and it's also available as an addon for Python 2.3, through my experimental database for Package Manager). Access to codecs is one of the things that has been added. But, of course, I've only tested it very lightly and it's very possible I forgot some essential things. Could you please check whether Python 2.4 (or its Carbon.Qt module used in 2.3) allows you to access the codec you need? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Compiling Python on Tiger
If anyone has tried to build Python on Tiger: could you please contact me? I've received a bug report that I'd like some more data points on... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Embedding with CW6
On 24-mrt-05, at 14:28, Steve Spicklemire wrote: Hi Folks, Back in the pretty old days (python 1.5 or so I think) I developed a Macromedia Director (MMD) scripting Xtra that allowed Lingo scripts to use python as an embedded language. It worked great... but I moved on and haven't done anything Carbon in years. Now I find myself in a situation where I need to get that Xtra working with the latest MMD. The Macromedia XDK seems to only support Codewarrior on the Mac. I have only CW6 at this point (I have an email sent off to Metrowerks asking how I might get CW7) so I guess I can't build the latest sources (as they seem to want CW7). So.. the question is: What's the latest set of sources that will likely work on CW6? (in case I can't get CW7). It's difficult to tell (I have to work from the log messages, and compare checkins to release tags), but it seems I made the switch from CW6 to CW7 in December 2001. The log messages seem to suggest that 2.2 was released with CW7. So that means 2.1 is the last version that'll build with CW6... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Audio I/O
On 2-apr-05, at 17:24, J. Devaney wrote: I'm working on a python project that requires audio I/O (via the soundcard) - I basically just need a stream that can be analyzed in real-time and stored to a file. I've looked into various options - such as portaudio using a python wrapper - but since portability isn't really I issue I was wondering if there was a more direct (and simpler approach). There's the Carbon.Snd module, which interfaces to the old Sound Manager, and there's the Quicktime module. I don't think the Quicktime module as shipped with Python 2.3 (which Apple ships with 10.3) supports capturing, but I think that the Quicktime module in 2.4 should support it. But: I don't know of people who have tried it, so please report back here whether it works. You can also download and install the new Quicktime for Python 2.3: if you open the experimental database in Package Manager you'll see it listed. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] webcam snapshot from Python
On 12-apr-05, at 20:49, Mathieu Lecarme wrote: There is a win32 project http://videocapture.sourceforge.net/ But on Mac Quicktime know how to grab picture from a webcam. HackTV seams to be a nice example for that. How can i take a picture (not a movie) from a webcam with macPython? The Quicktime module should be able to do this, if you're using 2.4.1. If you're still using 2.3 you can download and install the new Quicktime module through Package Manager or from Bob's package list. For the documentation you read Apple's C quicktime docs, and remember that a C function like "FooBarMovie(Movie *m, int x, int y)" will be represented in Python as a method of the Movie object, i.e. call m.FooBarMovie(x, y). And the same question as I asked in a similar thread last week: the quicktime module should be able to handle capturing, but I've never had any feedback that it actually works. So please report back here. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Weird import problem with PythonIDE on Mac (was 'import problem')
On 22 Apr 2005, at 03:06, Chris Smith wrote:
###
def y1():
pass
def foo():
from __main__ import y1
pass
foo()
###
Here is a version of the code, stripped of the timeit code. The above
segment exhibits the same symptoms as the previously submitted one.
Even though I am running this as "__main__" it behaves as though it is
not __main__. i.e. if I run this with pyOxide without the 'run as
__main__' option, it generates the same ImportError ('Can't import
y1') as it does when run in the PythonIDE.
In the pythonIDE it generates the error whether the 'run as __main__'
option is on or off. As a test of that option, I verified that the
following code only runs when the __main__ option is on and it worked
as expected:
###
if __name__=='__main__':
print 'running as main'
###
As always, reading the source provides the answer.
If you look in PyEdit.py, method Editor.execstring(), you'll see that
the only thing "run as __main__" does is set the module name to
"__main__". It does *not* change the globals dictionary to __main__.
I'm not sure about the reasoning behind this, I think Just wanted to
make sure that if you had two edit windows open both with "run as
__main__" selected they didn't influence each other. On the other hand
I can imageine that if you do that, open two windows in __main__ mode,
the behaviour you want is exactly that.
Just?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Did anyone play with TransformProcessType yet?
No, I've not come out of hiding just yet (still far too busy with Ambulant to do any Python work), but I came across TransformProcessType just tonight, so I did a quick experiment and it seems to work. What it does is turn any process into a full-fledged windowing application, with a dock icon, the possibility of a menu bar, etc. So this may be the way to get rid of "pythonw". I quickly added a method MacOS.SetWMAvailable(), and it seems good enough for running the IDE with "python" in stead of "pythonw". The icon is ugly (a terminal- style script), and the application menu title is "python" in stead of whatever script you're running, but that can all be fixed. Did anyone else have a look at this call? Is it worth it to invest some time into it? If it is I'll check it in and people who build Python from CVS can play around with it. Please reply also to me personally, I still have 847 pythonmac-sig mails waiting for me so if you reply only to the list it'll be a long time before I see it... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Selecting in BBEdit & Python Indenting style (spaces)
On 29-nov-2005, at 18:33, Louis Pecora wrote: > What the heck were they (Guido?) thinking when they used 4 spaces > as the one true mode of indentation for Python? Initially Python was unix-only, and there (at that time) a tab was 8 spaces and that is that, no problem with mixing tab/spaces. Then the Mac (and later dos/windows) joined the scene, which had 4-space tabs. Then it was deemed mixing tab/space was bad (because code got ugly or even didn't work when ported between 4- and 8-space tabs. Because at that time most editors (both on Unix and Windows) still did not have the feature to set how many spaces a tabstop was it was decided to go with spaces for indenting: going with tabs would have meant unix- heads would be stuck with unusable 8-space indents. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] universal python framework?
On 9-dec-2005, at 18:56, William Kyngesburye wrote: > I'm starting to build universal binaries for a bunch of 'nix stuff, > some of which have python bindings/extensions. Has anyone looked at > a universal Python framework? I'd hate to have to step backwards to > Apple's included Python framework for that, but I may have to. There's a fairly recent Apple technote that discusses how to build universal binaries for products with a configure/make build procedure, such as Python, and I hope to look at that next week. But Ronald already discovered that distutils has problems with building universal extensions, so that may also turn out to be a problem (although he wants to build something more complicated, with the PPC binary being 10.3/10.4 compatible). And the "easy" way is to simply configure Python twice (Python builds nicely in a different directory than the source, I'm doing that all the time), once for ppc once for x86, and then using lipo to combine everything. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PyObjC + AEInstallEventHandler crash?
On 21-dec-2005, at 2:51, Bob Ippolito wrote:
>> Trying to figure why the following test app crashes when a 'testtest'
>> Apple event is sent to it:
>>
>>
>> # cocoatest.py
>>
>> from PyObjCTools import AppHelper
>> from Carbon.AE import AEInstallEventHandler
>>
>> AEInstallEventHandler('test', 'test', lambda evt, res:0)
>>
>> AppHelper.runEventLoop()
>>
>>
>>
>> Additional notes: the test app doesn't crash when
>> AppKit.NSAppleEventManager is used to install the event handler
>> function,
>> nor when CarbonEvt is used instead of PyObjC.
>>
>> I'm getting a similar crash in some CarbonX.OSA code within a
>> PyObjC-based
>> app and reckon identifying what's causing the test app to crash
>> will help
>> me solve the problem there. Any ideas as to the cause, suggestions
>> where
>> to look, how to debug it more effectively, etc. would be a big
>> help as
>> I've been stuck on this for more than a day now and have only just
>> fitted
>> a new laptop case after the last temper tantrum. :p
>
> My guess is that there's a refcount or GIL bug in
> Carbon.AE.AEInstallEventHandler.
You guessed correctly: AEInstallEventHandler is blissfully unaware of
refcounts. It simply passes the address of the callback function
object to the C AEInstallEventHandler, and hopes the object still
exists when the callback comes.
The workaround is to keep a reference to the object around. Which is
apparently also the normal case, I think this is the first report
I've seen of this problem, and I wouldn't be surprised if this code
even predates my responsibility for the toolbox modules (i.e. Guido
himself wrote this:-).
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Job postings - allow or not?
Folks, I've just let a job posting through to the list, after looking at it for a long time and unsure whether or not we want these. If you have a strong opinion (or a weak opinion, or anything resembling an opinion:-) on the matter: please let me know, then I'll use the collective feedback as a guidance in the future. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Job postings - allow or not?
The majority of the people seem to think the occasional job posting is fine, with this policy to be reviewed when we're sick and tired of the number of job postings. But as we've so far had only one in the 10+ years this list exists I think we're pretty safe for the time being:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] bugs in _Qtmodule
On 4-okt-2006, at 3:58, Jeff Senn wrote:
While attempting to use the QuickTime sequence grabber
interfaces from Python I notice that there is some
confusion between Component and ComponentInstance
in _Qtmodule.c.
I believe most of the instances of "CmpObj_{Convert,New}"
in _Qtmodule should actually be "CmpInstObj_{Convert,New}"
(There are a few that are correctly CmpObj_...)
I have a (moderately tested) patch...
A patch won't help much, because _Qtmodule is generated (through
qtscan.py/qtsupport.py). I assume that there's a one-line mistake in
qtsupport, which leads to one C type being handled as CmpObj in stead
of CmpInstObj.
Hmm, well at least the patch will contain that information, I guess.
Could you put it on sourceforge and assign it to me?
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] problem fixing Carbon.AE/CarbonX.AE conflicts
On 10-Nov-2006, at 12:31 , has wrote:On 9 Nov 2006, at 16:49, Ronald Oussoren wrote: Unfortunately, when I try to do this, all I get is a bunch of 'symbol not found' errors on import: That's because there are hooks in the core interpreter for the Carbon modules. Yeah, already took a look at mactoolboxglue.c, but it was all hardwired and didn't really help. I think there must be other stuff going on as well.Not really: the hooks are only there because at the time I wrote itI thought the export-via-python a bit too much of a hack.But since then everyone is doing it, and with cobject it can actuallybe done in a pretty safe way, so I would use something like thatnowadays.-- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python and Zeroconf?
On 26-Dec-2006, at 19:29 , Nehemiah Dacres wrote: his problem might be how to make fat python byte code, or rather, universal binaries with python. Python byte code is architecture-independent[*], so that shouldn't be a problem. [*] I think there was a problem with portability between machines with 32 and 64 bit integers, but I recall that that has been solved also. And at least it isn't a problem for ppc/intel mac portability. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How to create a desktop alias to run a python file?
On 20-mrt-2007, at 17:30, Alfred Morgan wrote: > From: Stani's Python Editor <[EMAIL PROTECTED] > > This is probably very easy, but I don't find how to do it. I want to > execute this command if an user clicks on the icon of the alias on the > desktop: > > /usr/bin/pythonw path/gui.pyw > > Like other people said, you probably don't want to do that, but > unlike other people, I'll answer your question. > > mkdir ~/Desktop/MyProg.app > echo '#!/usr/bin/env pythonw /path/gui.pyw' > ~/Desktop/MyProg.app/ > MyProg > chmod +x ~/Desktop/MyProg.app/MyProg > > double click MyProg on the desktop and it should launch your python > program using pythonw I was very surprised when I saw this, I'd never seen this before. And, indeed, when I tried it it didn't work:-( Maybe you skipped an important step in the instructions? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How to create a desktop alias to run a python file?
On 23-Mar-2007, at 22:27 , Alfred Morgan wrote: #!/bin/sh cat > /tmp/alfred_hw.py << . from Tkinter import Tk, Label r=Tk() Label(r, text="Hello World").pack() r.mainloop() . mkdir ~/Desktop/alfred_hw.app cat > ~/Desktop/alfred_hw.app/alfred_hw << . #!/usr/bin/env pythonw /tmp/alfred_hw.py . chmod +x ~/Desktop/alfred_hw.app/alfred_hw Yes, this one works for me just fine!! I'm very surprised, because it does not follow any Apple guideline for application bundles that I've ever seen. (Also, I don't know what I did differently yesterday when it didn't work for me, but never mind that). BTW: you can make things even simpler by putting the Python code into alfred_hw. And moreover you don't need pythonw, apparently because you're in an App bundle already: #!/bin/sh mkdir ~/Desktop/alfred_hw.app cat > ~/Desktop/alfred_hw.app/alfred_hw << . #!/usr/bin/env python from Tkinter import Tk, Label r=Tk() Label(r, text="Hello World").pack() r.mainloop() . chmod +x ~/Desktop/alfred_hw.app/alfred_hw Is anyone else familiar with such simple .app bundles? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Recording audio on Mac
On 24-mrt-2007, at 16:46, Lucio Torre wrote: > Hi, > > I want to record audio on mac. Ive seen that the function SPBRecord > does what i need. > (http://developer.apple.com/documentation/QuickTime/INMAC/SOUND/ > imsoundinput.19.htm) > > This function is wrapped in the Carbon.Snd python library. My problem > is that i need to pass a SPBOjb parameter and im unable to create an > object of that kind. Carbon.Snd is very old, and it hasn't seen much development in the last 8 years. Mainly because the API is baroque, and Apple has been steering people away from it for years. Quicktime is probably your best option for recording from Python, but I wouldn't bet on it that all the correct functionality is exported to Python. But I'll be going to need some recording facilities too in the near future, so if there's something you miss let me know and I'll add it. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Macintosh modules/Carbon/documentation
On 30-Mar-2007, at 22:55 , Kevin Walzer wrote: Looking at the "Macintosh Library" documentation that ships with 2.5, I see a lot of outdated stuff: references to the old PythonIDE, PackageManager, and so on. What is the process for updating these docs, submitting a bug report, etc.? Also, there appears to be a lot of modules in the "Macintosh Library"--Carbon modules, generally--that are undocumented, or are broken, or (almost as bad) no one know if they work or not. Has anyone gone through these to sort out what works, what should be deprecated, etc.? Does it make sense to deprecate the entire Carbon module? What's the process for this? I had a chat about this with Ronald a few months ago, where we basically went through all the modules. Ronald, do you have your notes handy? Carbon itself should be fine. It is indeed undocumented within the Python documentation, but the transformation from the official Apple C documentation is pretty clear (I think). -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Macintosh modules/Carbon/documentation
On 31-Mar-2007, at 19:58 , has wrote: Furthermore, this stumbling block has a stumbling block of its own: bgen. There's very few folk around who understand it at all, and no documentation (AFAIK) for anyone else to make sense of it. Until there's some sort of decision made about bgen's future (maintain and document it? Replace it completely? Abandon it and maintain existing code by hand?), I can't see anyone really wanting to step into that tarpit. I'm committed to bgen, for at least the next couple of years. I'm also using it to generate a bidirectional C++ bridge for Ambulant (which is my main project nowadays, and which is one of the things that makes me spend so little time with development of Python itself). But unfortunately getting the &*^$ thing in better shape for initial use is something that keeps slipping:-( -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] StuffIt 10 can corrupt applications packaged with py2app
On 25-apr-2007, at 7:50, Ronald Oussoren wrote: > > On 24 Apr, 2007, at 5:45, Brian Christensen wrote: > >> >> Following up on this lead we found that there is a problem with >> StuffIt 10. My application was distributed as a zip file so the user >> used StuffIt to unzip the file. It turns out that StuffIt was >> unzipping and deleting the site-packages.zip inside of the >> application! > > That's very lame behaviour on StufIt's part. It's a preference. In Stuffit Expander it's called "Continue to expand if possible", in the full stuffit it's probably something similar. It's on by default, it's what makes stuffit do the full decoding and unpacking of, say, a .tar.gz. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] StuffIt 10 can corrupt applications packaged with py2app
On 25-apr-2007, at 20:52, Bill Janssen wrote: >> Christopher Barker wrote: >> >>> 1) is there a point-and-click and/or drag-and-drop way to create >>> *.dmgs? >> >> There are lots of freeware and shareware apps that do this-- >> FreeDMG is a >> good one. There are also command-line wrappers for hdiutils. Just >> google. > > I don't know about point and click, but a simple script app could be > wrapped around this: > > /usr/bin/hdiutil create -srcfolder SOMEDIR -volname VOLUMENAME -ov > OUTPUTFILE.dmg > > It creates a dmg with SOMEDIR as the contents. Now that this thread goes more and more offtopic I'll add something I've been struggling with for a while: is there a way to programmatically set the background image in the resulting DMG? What I'm doing now is create an R/W DMG containing all the files plus the background image in a hidden folder, then mount that and ask the user (i.e. me:-) to set the folder background image and position the icons, then press return. Then the script continues, unmounting the image and converting to an RO compressed DMG. I can't seem to find a way to set the folder background image through a shell command or applescript or anything... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports "no eligible process"
On 8-Jun-2007, at 13:19 , has wrote:
You might add a note that since findertools uses aetools which is
[over]due for deprecation, findertools should be deprecated as well.
[...]
Or you can do it with appscript if you prefer:
from appscript import *
from mactypes import Alias
path = '/Users/drew/Documents'
app('Finder').items[Alias(path)].open()
Problem with deprecating aetools is that there is a truckload of
modules that depend on it, findertools among them. I'd love to
rewrite them to use appscript, and it wouldn't even be all that much
work, but I simply don't have the time (and probably won't have the
time in the coming few years).
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports "no eligible process"
On 11-jun-2007, at 14:30, has wrote: > On 10 Jun 2007, at 18:19, Ronald Oussoren wrote: > >> I'm more tempted to remove aetools in 2.6 if it cannot be fixed >> with a small amount of work. Leaving code that is fundamentally >> broken is just lame. > > Fine by me - I'm all for an aggressive houseclean, as you know. I've > no interest in fixing these modules, or even vetting them to see what > needs done. Like I say, if users actually cared about this stuff, > they'd have been complaining/doing something about it by now. Then please zap it now (at least in the trunk) so that problems show up sooner rather than later. I'm reasonably sure that there's various things that depend on it (possibly indirectly), these would need fixing then. At least if the module is scrapped now we should find out what breaks, -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] findertools.launch reports "no eligible process"
On 12-jun-2007, at 16:07, has wrote: > Not just that - there's other modernisation work required too. All of > which would be a complete waste of time and effort since nobody uses > these modules any more. > > Anyway, the items to remove from plat-mac are: > > aepack > aetools > aetypes > findertools > gensuitemodule > lib_scriptpackages > MiniAEFrame You missed EasyDialogs, which is also the one we may want to keep. It uses aepack for the file dialogs. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] QuickTime: BeginFullScreen
The problem is the "Ptr*" argument: BeginFullScreen returns an opaque pointer (Ptr) through a reference parameter, and the automatic interface code generator doesn't know how to treat this. It thinks it knows how to treat the companion "Ptr" argument to EndFullScreen (representing it as a string on the Python side and passing the address to EndFullScreen) but it actually gets it wildly wrong. As the pointer is opaque we could represent it as a cobject on the Python side. I can do the magic incantations to have bgen generate a new Qt interface module, but I'd need your help to test it. Ideal would be if you're building Python from svn source (then I'll just send you a replacement _Qtmodule.c, and if it works I'll check it in to the repository) otherwise we'd have to work out some other way, contact me by private email. On 11-Jun-2007, at 13:31 , Edward Hartley wrote: Hi I've been examining the functions exposed in the PythonMac Qt and QuickTime libraries and it seems that whilst the EndFullScreen call and the appropriate flags are exposed as can be seen from this snip from ipython help(Qt) EndFullScreen(...) (Ptr fullState, long flags) -> None however the corresponding BeginFullScreen is not available. My question is what is needed to make BeginFullScreen available to the MacPython API. I am willing to commit time to doing the development and have comnsiderable experience of using SWIG under Linux. I am not familiar with the build mechanism for MacPython but I am willing to learn. I had initially thought that this might depend on having QuickTime Pro but further investigation shows that BeginFullScreen is an integral part of the framework and available in from Movies.h which I'm assuming is the basis for the MacPython Quicktime wrapper The declaration is in /System/Frameworks/QuickTime.framework/ Headers as follows: /* * BeginFullScreen() * * Availability: *Mac OS X: in version 10.0 and later in QuickTime.framework *CarbonLib:in CarbonLib 1.0 and later *Non-Carbon CFM: in QuickTimeLib 2.5 and later *Windows: in qtmlClient.lib 3.0 and later */ extern OSErr BeginFullScreen( Ptr *restoreState, GDHandle whichGD, short * desiredWidth, short * desiredHeight, WindowRef * newWindow, RGBColor * eraseColor, long flags) AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER; Interestingly the Java Quicktime quicktime bridge has BeginFullScreen available. http://developer.apple.com/documentation/Java/Reference/1.4.1/ Java141API_QTJ/quicktime/std/movies/FullScreen.html Also there is an example of the use of the C API available in the developer documentation: http://developer.apple.com/samplecode/qtfullscreen/listing1.html So I'm assuming that any restrictions on exposing BeginFullScreen that may have applied in the past are no longer in force. TIA Ed Hartley ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Democracy player
Maybe everyone but me knew this already (even though I don't remember seeing any posts on this), but the new Democracy Player, which is a really convenient way to watch and share video over the net, with an outstanding user interface too, is almost completely written in Python. The website is <http://www.getdemocracy.com/>. And the Mac version is (of course) PyObjC-based. I also downloaded the code, and while I haven't tried to build it yet (it needs boost and pyrex and a couple of other things that I don't have time to install right now) it is well-structured and a joy to read. Definitely worth a look if you have a couple of hours to burn, -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] 64-bit code
On 17-Jun-2007, at 20:06 , Kevin Walzer wrote: OK, I guess this means that 32-bit isn't going away any time soon. The Carbon-dev list seems to think that this announcement means Carbon is going the way of Classic. At least some of the people on that list say that they will drop Mac support rather than port to Cocoa, because they need 64-bit. That's not directly germane to my concerns, as I don't think I need 64-bit for what I do. The last sentence is the pit you'll fall in. At least, it's the pit that I'm scared of falling in. Even though my own code would benefit little from 64 bits, it depends on all sorts of third party libraries (mainly media stuff in my case, but the same holds for many other fields). As soon as such a library gets a twofold performance increase from switching to 64bits it's going to be very tempting for me to follow suit. And this works iteratively: as soon as I switch to 64bits then people using my stuff will have to follow too. And even the tiniest application nowadays uses layer upon layer of third party software. Indeed, 32 bit support isn't going to go away in the next 2 years, but the bell has tolled. Compare what happened to Windows programs when they switched from win16 to win32: even though win16 programs could technically continue to be run for a pretty long time they were cut off from new developments and either were ported or died. But, all that said, I'm not scared of the 32-64 transition. For my own code it'll probably be comparable to the PPC-Intel transition: more work than you hope for but nothing as drastic as the OS9-OSX switch or the 68K-PPC switch. The only thing I'm a bit scared of is Apple's own useful toolkits that depend on Carbon, specifically QuickTime and AppleEvents. I'm not too sure about AE, but for QuickTime I know that you have to leave QTKit and switch to the old QuickTime API's very often if you do more than play a simple video. So effectively this'll mean that the "single toolkit for everything" paradigm will break, because Oldstyle-C-Quicktime will (in 64 bit space) lose it's ability to tweak the rendering so it'll be an edit- only API and QTKit will have to be used for rendering. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Audio_mac.py fails in writeframes
On 11-Oct-2007, at 18:51 , punch wrote: I'm running 'OS X' 10.4.10 and python 2.5.1 on a MacBook Pro SR. When I try to run any of the audio demos, specifically Audio_mac.py, I get errors. The error is in the writeframes method. It appears to try and pack the constant extSH (set to 0xFF) as a signed byte, which it cannot do. Change the struct.pack format from 'llHhllbbl' to 'llHhllBBl'. The code predates the distinction between signed and unsigned bytes in struct.pack. But be warned that this also shows how well-maintained the code is:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?
If I understand the architecture correctly I would go with option 1. And get the Mac guys to write their code in a reusable way, i.e. have them export enough low-level functionality in their API. This should be easy enough in ObjC. It'll allow tweaking from the Python side, and if you're lucky during the project they'll see the advantage of Python and all jump on the bandwagon:-) BTW: there's a potential third architecture that I can see: write a Cocoa app with a Python module embedded. This is similar to option 1, but depending on which technologies you use it may be easier to structure things with ObjC "in charge" in stead of Python. But if you also structure your Python code well it shouldn't be much of a problem to switch from design 1 to design 3 later in the development process. On 26-okt-2007, at 9:01, Darran Edmundson wrote: > > I have a couple of Cocoa/Quicktime developers working on a small > custom > application. These guys are very capable at OS X programming but > don't > have any python experience. I, on the other hand, have a lot of > python > experience but virtually no Mac development experience. I could > really > do with some advice from someone able to see "the big picture". > > A bit of background ... We are working on a museum exhibit where a > large > 65" 1920x1080 screen attached to a Mac Pro is electronically > positioned > on a 4m industrial slide-track via a physical interface device. Each > millimeter of track corresponds to a different image in a 4000 frame > photo-jpeg-encoded Quicktime. The user tweaks the interface > device, the > screen moves, the image changes appropriately - that's the basic plan. > > I have a python program on the Mac that determines, among other > things, > the screen location. The OS X developers are going to write a > full-screen Cocoa application that handles the display side of things > (along with some tricks like: change to a new movie; tweak the > opacity; > add a second layer movie; etc.) The question then: how to join these > two codes? > > Options (that I can think of, probably more worthy of discussion): > > 1) Get the Mac guys to write their application as a library that > can be > wrapped in pyObjC and invoked by my python program. In this scenario, > the result is only one process/program with no network issues. > > 2) Add networking code to both the python and cocoa apps in order to > communicate (binary socket, XML over http, Bonjour, etc.). Easy in > python via Twisted, no doubt less so in cocoa. > > As always, any advice is much appreciated. > > Cheers, > Darran. > > -- > Darran Edmundson [EMAIL PROTECTED] > http://www.edmstudio.com > ___ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?
On 27-Oct-2007, at 02:55 , Darran Edmundson wrote: I've recommended that Douglas join this mailing list and ask questions. My only concern is that most people coming to this list are probably python users (like myself) who want to write Mac apps. Douglas is coming from the opposite tack - he's a hardcore Cocoa developer who doesn't know python at all. With this in mind, do you have any pointers in designing a library that is easily called from python? There are some things you can do in ObjC that are difficult to expose to Python, but as they're so unusual I've never come across them I've also conveniently forgotten what they are:-) Oh yes, I think if you pass a C structure you have to do some massaging (excpe tif PyObjC already knows about that structure, such as for NSPoint and such, then the work has already been done for you). I wondered, for example, if he wrote the Objective C library and a separate Objective C test application to exercise the code, if the test app could then simply be ported to pyObjC? This way Douglas wouldn't need to worry about python at all ... If you do this very early during development, i.e. when the library API has only a couple of calls you have the ObjC programmer write a minimal test script which you then port to Python, you could give this back to the ObjC developer. There's a very good chance this'll teach them enough Python to continue the testing directly in Python. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] sys.path on Leopard
On 1-Nov-2007, at 20:45 , Brian Granger wrote: > Running python setup.py install on Leopard causes packages to be > installed in the usual: > > /Library/Python/2.5/site-packages > > But, Apple put this directory _after_ > > /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ > python > > in sys.path. This, even if a user installs a newer version of one of > these packages, the builtin python will always use Apple's older > version. Bah. The order is very strange: - First most of the Python-supplied and Apple-supplied directories, - Then /Library/Python/2.5/site-packages - Then PyObjC, which is also Apple-supplied - Then $HOME/Library/Python/2.5/site-packages, if it exists. By all means, report a bug. There is a workaround that packages can use to fix this, by the way, through using Python code inside a .pth file. I used that in the distant past to allow packman to fix bugs in system packages. I put the following line (without indentation) into ~/Library/Python/ 2.5/site-packages/HackPath.pth import sys ; sys.path.insert(0, '/Users/jack/MyPythonPrependedPath') And, indeed, '/Users/jack/MyPythonPrependedPath' ends up as the first entry in sys.path. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Anyone playing with CoreAnimation yet?
I've just realised how powerful CoreAnimation is, and I want to start playing with it, especially with the interaction of CoreAnimation CALayer with "classic" AppKit views and how to treat events, etc. Is anyone else here using it, and/or interested in sharing experience? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Any hints on building libpng universal?
On 23-nov-2007, at 4:58, David Warde-Farley wrote: > Hi again, > > I'm trying to build a universal libpng package at the moment for use > with matplotlib from pythonmac.org/packages. There's an older version > up on undefined.org that's referred to in some mailing list postings > but there've been some major security holes fixed since then, so I've > been trying to automate the process of building a > > gcc complains about the '-M' flag being used with multiple -arch > flags, [...] I don't remember what I did to build libpng universal, but problems with '-M' are usually solved by adding '--disable-dependency- tracking' to the configure command. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 20 dec 2007, at 12:35, Ronald Oussoren wrote: > > That's easily fixable. I'm thinking about reviving Jack's MacPython > addons idea: a small .mpkg that will install IDLE.app, a 64-bit > command-line interpreter and some small fixes (such as the distutiles > one). That should make Leopard's builtin python a lot more useable > without requireing people to basicly install the same version of > python that is already on their system. I think this would be a very good idea, even if only from a "political" point of view. Even though I've been an open source developer since long before the word existed I find that I'm getting sick and tired of the reinvent- the-world attitude that is far too common in the open source community. If I am new to Python on the Mac and I've played with Apple Python a little, but as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new (and not directly Apple-endorsed) I might just drop out. And at the very least it's mightily inconvenient. Also note that the chances that the distutils fix or the 64-bit fix are likely to affect me are exactly zero (the "newcomer me" from this paragraph, not the "flesh and blood Jack" me:-). -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
I've been thinking a bit more about being forced to upgrade package X when I'm not interested, and I realised that the times it really bothers me are even one more step removed: if I was interested in package X and the website/whatever told me "don't use the current version of X, use the newer one" I can probably live with that. The real problem is when I couldn't care less about package X but I'm really interested in Y, which uses X, and then X forcing me to upgrade it. Python is in a pretty good shape right now, with well-packaged extension modules being compatible with a fairly wide range of Python installations, but please let's try and keep it that way. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 3 jan 2008, at 14:22, Ronald Oussoren wrote: > Now that there are several people that want to support Apple's build > of python: how do we go forward from here? > > I think we should start a small project for "MacPython Addons", this > project will install: > > * Hotfix for distutils to ensure that distutils builds univeral > binaries (32-bit only at first) > * (possibly) hotfix to ensure that you can install '-fat-' eggs on > 10.5 > * /Applications/Python-2.5/IDLE.app I think that for "true" end users Idle is the only serious omission. The first one is really for developers only, and the second one doesn't really become important until such fat eggs become widely available (which they are not right now, IIRC). Hmm, idea to keep this manageable: how much work would it be to create tiny installers for each of these hotfixes, and then have a umbrella installer that encompasses all of these? That way, as new problems surface the only work would be to create a hotfix installer for that single problem and do a tiny update to the umbrella installer. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pystone numbers for different Macs...
On 20-Jan-2008, at 19:23 , Daniel Lord wrote: > I ran the test on my 1st Gen Quad Core ( 2 x Quad-core 3.0 GHz, 13GB > RAM) and was a bit surprised to see little improvement over the Core > Duo numbers. > > 63019.7 pystones/second > > I am assuming the GIL is limiting threading and therefore I am really > running on one or two cores--hence the tangible improvement is just > CPU speed: from 2.33 GHz to 3.0 GHz and a bit of the memory bandwidth > increase as well. Interesting... My first generation quadcore at 2.6 Ghz clocks at 62578.2. So there's another limiting factor: from my machine to yours is a 15% speed bump, but only a 1% increase in pystone numbers. Somebody told me recently that MacOSX is not very good for fast task switching with multiprocessors, because apparently (his words, and possibly misrepresented by me) the implementation of semaphores sucks. This seems to corroborate that. Hmm, what is your bus speed? Mine is 1.33 Ghz, is yours that as well is it 1.5 Ghz? If the former it could be that semaphores somehow run at bus speed and semaphore overhead dwarves any processing done. If your bus runs at 1.5Ghz there must be yet another bottleneck... -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pystone numbers for different Macs...
On 20-Jan-2008, at 20:53 , [EMAIL PROTECTED] wrote: >Daniel> I am assuming the GIL is limiting threading and therefore > I am >Daniel> really running on one or two cores--hence the tangible >Daniel> improvement is just CPU speed: from 2.33 GHz to 3.0 GHz > and a >Daniel> bit of the memory bandwidth increase as well. > > The GIL doesn't enter into things here. The pystones benchmark isn't > multithreaded so even if Python was free-threaded the pystones > benchmark > wouldn't benefit from it. Hmm, you're right. And there aren't any magic threads either (happens far too often nowadays, grmpf), I just checked that with gdb. So: any other speculations as to why 2.66Ghz->3.0Ghz gives only a 1% increase in pystones? I can't physically reach my Mac Pro for another week, but maybe someone else could try disabling three cores? If that increases the pystone number (in stead of decreasing it) this could point to a processor affinity problem in MacOSX. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] python23 under leopard (intel mac)
On 22-Jan-2008, at 22:55 , Ronald Oussoren wrote: > > On 21 Jan, 2008, at 19:58, j47 wrote: > >> >> I am also having trouble with Python 2.3.6 under Leopard (yes, I'm >> stuck with >> this version). > > That's too bad, this version is not supported on Leopard. >> >> >> Tried everything as below. I still get: >> >> Undefined symbols: >> "__dummy", referenced from: >> ld: symbol(s) not found >> collect2: ld returned 1 exit status >> make: *** [python.exe] Error 1 >> >> Any ideas? > > The error you're getting seems to be related to the build procedure, > hence I'd look into the differences in compiler/linker arguments > between 2.3.6 and 2.5.1 to try to detect what's going on. IIRC that "__dummy" was a workaround for something not being loaded into the shared library that's at the heart of the Python framework. Don't ask me what wasn't being loaded, this is really long ago (OSX 10.2, or 10.3 at the latest). If you look through the Makefile (Makefile.pre.in, configure.in, etc) you should be able to find it, there's probably a linker flag "-u __dummy" somewhere. Try removing it, and see what breaks. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Key Bindings on cross platform apps.
On 1-Feb-2008, at 23:55 , Christopher Barker wrote: Hi all I'm trying help out Rob McMullen get his "Peppy" editor working well on OS-X. I'm thinking about about key bindings. There are some apps that have sets of keyboard shortcuts and let you switch between them with a preference. This is very handy, because now a Mac user of application X can chose whether s/he wants Mac- oriented shortcuts (so find will be command-F, for example) and another user of X on the Mac who happens to be familiar with the Windows version of X can chose Windows-X-compatible shortcuts (so find would be F3, probably). I don't like customizable keyboard shortcuts in general (this is what makes it impossible to type anything in someone else's Emacs, for example), but in this one case I think it's definitely worth it. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CoreGraphics, 10.5
Are you sure your mask is actually greyscale? If I looks as if there's a repeating pattern in your result image. Maybe you could also use an assert to make sure bitsPerComponent() == bitsPerPixel() and #components==1. On 16-Feb-2008, at 13:45 , Erik van Blokland wrote: Folks, I've been wrestling with some CoreGraphics stuff, OSX 10.5.2, stock Python 2.5.1. I want to load a RGB image, then load a grayscale image, draw one while using the other as a mask. I can build all the required objects. I can draw with "masking-like things" happening to the image. But the masking appears to be according to a (random) piece of memory, rather than the pixels from the mask image. The RGB image: http://erik.letterror.com/cg/picture.png The grayscale mask: http://erik.letterror.com/cg/mask.tif The resulting image: http://erik.letterror.com/cg/results.png The script: http://erik.letterror.com/cg/cgMaskTestPost.py The script which draws this file is below. Yellow background, rgb image of a neon sign, mask. I get the impression I'm somehow not making the right kind of mask. Or perhaps the parameters I'm passing to it are wrong. Perhaps the mask image is wrong. I've tried black/white bitmaps, tiff, jpeg, png, grayscale 8 bit, 24 bit. Different formats result in different patterns being used as a mask - so there is some correlation between the file and the result. Is this anywhere close to how it needs to be done? Any pointers are most welcome, thanks! Erik van Blokland #! /usr/bin/python2.5 from CoreGraphics import * import os def test(): testWidth = 1000 testHeight = 500 fileName = 'picture.png'# name of a 8 bit PNG, RGB image maskName = 'mask.tif' # name of an 8 bit, grayscale tiff # the paths root = os.getcwd() filePath = os.path.join(root,fileName) maskPath = os.path.join(root,maskName) dstPath = os.path.join(root, "results.png") # data providers for the image and the mask img = CGImageImport(CGDataProviderCreateWithFilename(filePath)) maskProvider = CGDataProviderCreateWithFilename(maskPath) imgMask = CGImageImport(maskProvider) # first, let's find out some things about the mask. width = imgMask.getWidth() height = imgMask.getHeight() bitsPerComponent = imgMask.getBitsPerComponent() bitsPerPixel = imgMask.getBitsPerPixel() bytesPerRow = imgMask.getBytesPerRow() shouldInterpolate = True decode = [0,255]# not relevant? # make the mask maskObject = CGImageMaskCreate(width, height, bitsPerComponent, bitsPerPixel, bytesPerRow, maskProvider, decode, shouldInterpolate) # now make the image with source image AND mask imgWithMask = CGImage_createWithMask(img, maskObject) # make a new image to save it all ctx = CGBitmapContextCreateWithColor(testWidth, testHeight, CGColorSpaceCreateDeviceRGB(), (0,0,0,0)) # a background color ctx.setRGBFillColor(.9, .9, 0, .8) ctx.addRect(CGRectMake(0, 0, testWidth, testHeight)) ctx.fillPath() # draw the masked image ctx.drawImage(CGRectMake(50, 50, width, height), imgWithMask) CGContext_writeToFile(ctx, dstPath, kCGImageFormatPNG) print "done" if __name__ == "__main__": test() ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Carbon bindings' future (was: Re: eliminating appscript-triggered Dock icon)
On 9-Apr-2008, at 07:56 , Ronald Oussoren wrote: Even fixing bgen isn't that much work, once you understand the code. The problem is that bgen is a nearly vertical learning curve and Jack seems to be the only person that understands enough of bgen to be able to hack on it. I'm definitely in favor of ditching bgen and moving toward PyObjC-based wrappers. I would also be in favor of using PyObjC-based wrappers. But: I'm not sure that completely ditching bgen is what's needed. The front-end of bgen, which reads the C header files and produces what's basically interface definitions, should be understandable. The xxxgen.py files (which are really the interface definitions) could then be used to create bridgesupport files, and everything should play together well enough. The only problem would be compatibility: one of the things bgen does is convert the procedural Carbon C argument convention (with the main object being the first argument, usually) to an OO model on the Python side. I don't think bridgesupport can pull off this trick. And the conversion of arguments to be more Pythonic (two arguments of the form "char *buf, int bufsiz" are represented as a single string on the Python side, and lots more) is probably difficult too. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Back-porting Python 2.3 to Mac OS X 10.5?
Brad, there's only one potential problem and that's the PPC/Intel issue. If you have a PowerPC mac (or you can live with running Python under Rosetta on an Intel Mac) I would first try to download a binary 2.3.X. My guess is that there's a 90% chance that it works. The issue might be finding compatible binary installers for Tcl/Tk and wxPython. If the binary installer doesn't work just build the source. BUT (large but, here): don't try to build for Intel, only for PPC. If you have a PPPC mac that's easy. If you don't have one it's going to be a bit of a problem. The normal way to build for one platform on another platform is through the --host crosscompilation support of configure, but Python doesn't like that. Try starting with running the whole configure/build with CFLAGS="-arch ppc" in the environment. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Is there still a good reason for separate macpython and pyobjc mailing lists?
Now that pyobjc is a first-class citizen of MacPython, is there any reason to maintain two mailing lists? Are there any people who are on one of the lists and not the other? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Problem with Framework
On 10-Aug-2008, at 12:06 , Georg Seifert wrote: is there a way to select witch framework to use? I've never found one. I have two tricks (working together) I use when I build software to distribute: 1. After building my distribution, I run a script "testdependencies" (attached to this message) that uses otool -L to ensure all dependencies are in Apple-maintained locations (i.e. no / Library, no /usr/local, etc). testdependencies Description: Binary data 2. If this script returns a warning (about one out of two times:-) I do a temporary "sudo chmod 0 /usr/local /Library/Frameworks/ Python ..." and rebuild the whole distribution. If there's anything that I really need from /Library or /usr/local I copy it into the bundle and mangle the name with install_name_tool. For Python-based projects py2app can do this for you, too. Georg On 9-Aug-2008, at 17:56 , Georg Seifert wrote: Dyld Error Message: Library not loaded: /Library/Frameworks/Python.framework/Versions/ 2.4/Python Referenced from: /Users/Tim/Desktop/Pantografer.app/Contents/ MacOS/Pantografer Reason: image not found Here's the smoking gun: it tries to load a user-installed copy of Python 2.4 which doesn't exist. I assume that on your development machine you have 2.4 installed, and /Library (with the user-installed 2.4) takes precedence over / System/Library (with the Apple-installed 2.5) when you built the app. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Creating Application()
On 24-Aug-2008, at 21:28 , N3buK4Dn3ZZ4r wrote: Hi there. I'm not a complete newbie in python, but in building GUIs. I've worked around a bit with Tkinter and I think, I can handle this one, but I also tried to work with the "FrameWork" module, to create Menubars and this kind of stuff. But I did not even get a Application() object createt. Could anyone please post a simple code example, that creates a Application() Object and a Menuitem or something like this? Unless you have a very good reason to use FrameWork (and it appears you don't, as you're just starting): stay away from FrameWork. It is almost 15 years old (originally written by Guido himself), uses MacOS9 APIs that are likely to disappear some time soon and hasn't been maintained in 7 years or so (I know, I was the last maintainer). If you want to try something new for GUI development: look at Cocoa/ PyObjC. It is completely unlike anything else and the learning curve can be pretty steep when you come from another GUI toolkit, but that's mainly because you have to un-learn a lot of things. A Cocoa GUI almost writes itself. I always have the feeling that I've somehow cheated when I'm done: the GUI works, but I don't remember actually writing any code:-) -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie questions about Mac APIs in Python
On 14-Oct-2008, at 19:36 , Joe Strout wrote: On Oct 13, 2008, at 10:49 AM, Chris.Barker wrote: But what if we want to do some of them from a wxPython app (only when we detect we're running on a Mac, of course)? Good question -- can pyObjC play well with wx? Anyone know? Or more generally: can you invoke some Cocoa functionality from any generic Python app, or does it have to be a PyObjC app through and through? For example: suppose we wanted to take the clean but Windows-only "speech" package: <http://pypi.python.org/pypi/speech/0.5.1> ...and add Mac OS X support to it. The speech facilities in Cocoa (or Carbon, for that matter) are pretty easy to use; but this is a generic module, that ought to work in any Python app, whether it's got a wx GUI or even no GUI at all. Is this possible, and how would we go about it? Some simple things "just work", also in command line tools. These are usually the CoreFoundation things that are pretty passive objects (CFDictionaries and such). Some things work fine in a command line tool, as long as you make your command line tool have a run loop by allocating an NSRunLoop and calling one of it's run methods. But this wil require restructuring your app a bit. You may get away with running the runloop in a separate thread, but I have no experience with this (does anyone else?). I wouldn't be surprised if your speech stuff would fall in this category. Some things will contact the window server, and this is not only obviously gui-related things like dialogs and such but also more subtle ones like some AppleEvents stuff. These will still work from a command line app, but they will probably not work from, say, a CGI script (as there's no window server). Hmm, maybe the speech stuff falls in this category after all, Apple may not want you to access the speaker if you're not the owner of the screen (the "you" here being the person running the script). -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Example of stand-alone NSRunLoop?
On 15 okt 2008, at 05:34, Joe Strout wrote: # Now we need a NSRunLoop... runLoop = NSRunLoop.alloc() # note: no init() method? runLoop.run() I think allocating a runloop is hardly ever what you need: there's one already, and you want to get that: runLoop = NSRunLoop.mainRunLoop() This indeed brings up the speech listener window-let (Can't test it, no microphone right now). This is a paradigm you'll come across often in Cocoa: there's a lot of objects of which there is one instance per application, and there's a class method to get that instance. NSApplication, NSFontManager, NSNotificationCentre, too many to mention, really. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
