Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
On Mar 2, 2005, at 1:02 PM, has wrote: It's already there, so it's not going anywhere in 2.4. The justification is that people *did* ask for an OSA wrapper -- I believe you were one of the larger proponents. No, I wanted a Python OSA component. Different thing. The only person I know was asking for an OSA wrapper was Donovan, and he went off to work on Nevow yonks ago and AFAIK never did anything with it. I wanted an OSA module so that it would be possible to write a Python OSA component using a more inside out approach. Writing a Python OSA component is going to require accessing much of the functionality in OSA.h from Python, and bgen is a reasonably expedient way to expose Carbon headers in the Universal Headers format. Unfortunately, unless you try the resulting module, things do tend to be broken without manual tweaking. I was able to write bgen wrappers for CarbonEvents and IBCarbon and tweak the bgen module by hand until the resulting modules were actually usable for trivial applications, but obviously nobody ever tried this with the OSA module. I am still interested in producing a Python OSA component, hopefully with the OSA module, but unfortunately it is a lot more work than I have free time for at the moment. I lost my drive to work on it when it became clear that HAS was far more energetic in this space than I was, and HAS didn't seem willing to listen to what I had to say about the subject or collaborate with anybody. dp ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] EasyDialogs + Appscript + iPhoto = zombies!
Hi,
I've written a small appscript that exports an iPhoto album using the
"album" photo album tool (written in Perl, but I don't have time to
rewrite it... :-/). I wrote the Python script and installed it as
/Library/Scripts/Applications/iPhoto/iphoto2album so I can use it from
the global Scripts menu. It works fine, but it leaves a zombie Python
process lying around every time I run it. I don't know a whole lot
about unix process control, but I found that to avoid zombie processes
you need to "double-fork". So here's a mock-up of my current code,
mostly copied from
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012:
BEGIN
#! /usr/bin/env pythonw
import os, sys
import EasyDialogs as dialogs, datetime
from appscript import *
def main():
# This is obviously a dummy main function
errfile = open("/Users/n8gray/ip2a.errors", "w")
errfile.write("Made it!")
errfile.close()
dialogs.Message( "Everything works ok." )
try:
pid = os.fork()
if pid > 0:
# exit first parent
sys.exit(0)
except OSError, e:
print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror)
sys.exit(1)
# decouple from parent environment
#os.chdir("/") # I've tried with and without this line.
os.setsid()
os.umask(0)
# do second fork
try:
pid = os.fork()
if pid > 0:
# exit from second parent, print eventual PID before
# print "Daemon PID %d" % pid
sys.exit(0)
except OSError, e:
print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror)
sys.exit(1)
# Open file descriptors
if not sys.stderr: sys.stderr = sys.stdout
si = file('/dev/null', 'r')
so = file('/dev/null', 'a+')
se = file('/dev/null', 'a+', 0)
# Redirect standard file descriptors.
os.dup2(si.fileno(), sys.stdin.fileno())
os.dup2(so.fileno(), sys.stdout.fileno())
os.dup2(se.fileno(), sys.stderr.fileno())
# start the daemon main loop
main()
END
Unfortunately, it still produces a zombie after each run and I don't
see the dialog either. The error log file does get written to,
though, so I know the double-fork succeeds.
Can anybody help me figure out what the problems are? Also, is there
any way to get rid of all the damn zombie processes on my system
without rebooting?
Thanks,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science -->
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
On Mar 2, 2005, at 16:02, has wrote: Bob wrote: It can't happen until Python 2.6 at the earliest. I don't think it's very likely to go away anyway. Good luck! Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure? As I stated before, "MacAll" can't use the Carbon namespace, so this trivial reorganization is not possible. It could if you just punted the _entire_ Carbon namespace into MacAll. Or are there dependencies in the core Python framework that prevent this? And if there is, hell, why not just deprecate the whole thing and create a new 'carbon' namespace in MacAll and tell folk to use that in future? You might never get rid of Carbon, but at least it'll get it sufficiently out the way for a clean new officially sanctioned version to set up shop. If you punted the entire Carbon namespace into MacAll, it wouldn't be compatible with any current Python, which is a non-starter. If you named it carbon, it would definitely be the cause of headaches and confusion due to the default case insensitivity of HFS+ and the similarity to the existing namespace. Anyway, many of the things in the Carbon namespace aren't Carbon at all. QuickTime, for example. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
Bob wrote: If you learn bgen and submit proper patches Without proper documentation and tutorials? Sorry, but masochistic self-flagellation is not my thing. This is somebody else's house of cards to sort out before everyone else can seriously be expected to play in it. Yet you screw around with the Carbon modules, which also have no documentation or tutorials? No more than I can help. And there is documentation if you're willing to work through docstrings and Apple docs to extract the relevant info. It's not much fun, but it's doable. Besides, what's the point in me going to the trouble of properly patching something if the fix won't percolate into the main distribution for another year when I need it now? If the fix didn't consist of adding new features With specific regard to OSA.so, of course it would consist of adding new features: half the damn OSA API is missing from the stupid thing. In the case of OSA.so and any other new MacPython 2.4 additions that haven't been tested, until Jack posts a final MacPython 2.4 distribution then it ought to be safe to revoke their inclusion. The extension(s) are part of Python 2.4, and follow the same policy as anything else in there. The lack of a binary release doesn't really mean anything. Whatever; if it's too late to change then write it off; leave it in the standard library but expunge all mention of it and maybe add a warning to let the unwary know it's duff. Anyway, let's not lose site of the big picture: what really matters is to change the rules so this kind of nonsense doesn't happen again. Do you agree with that? It's already there, so it's not going anywhere in 2.4. The justification is that people *did* ask for an OSA wrapper -- I believe you were one of the larger proponents. No, I wanted a Python OSA component. Different thing. The only person I know was asking for an OSA wrapper was Donovan, and he went off to work on Nevow yonks ago and AFAIK never did anything with it. It's partially your fault for not testing it *before* final release. No, don't you try dumping this on me. It's _entirely_ the fault of whoever decided to include an untested module in the standard library. Doesn't matter if there's a hundred or a thousand or a million people screaming for it; doesn't matter how loud they scream, throw tantrums or turn blue in the face. As I already said, it's really simple: if nobody cares about it enough to test it then don't put it in. No exceptions. Look, if I submitted a completely unused, untested and potentially broken module for inclusion in the standard library I'd be told to get lost and not come back until I'd fully addressed that, and quite right too. Please tell me the justification for the apparent double standard here. In addition, I believe submission rules for the standard Python distribution require modules not only to work but also be in widespread usage before it'll even get looked at. Why should MacPython not be following this rule too? This is not personal: I'm not looking for blood, to cause embarassment, assign guilt, score petty points, etc. I am simply trying to show there is an ongoing problem here that folk should acknowlege and try to address. It can't happen until Python 2.6 at the earliest. I don't think it's very likely to go away anyway. Good luck! Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure? As I stated before, "MacAll" can't use the Carbon namespace, so this trivial reorganization is not possible. It could if you just punted the _entire_ Carbon namespace into MacAll. Or are there dependencies in the core Python framework that prevent this? And if there is, hell, why not just deprecate the whole thing and create a new 'carbon' namespace in MacAll and tell folk to use that in future? You might never get rid of Carbon, but at least it'll get it sufficiently out the way for a clean new officially sanctioned version to set up shop. My point? Doing a job badly is the _worst_ thing possible. If you can't or won't do it properly, you shouldn't to do it at all. Very few people care that undocumented modules don't work correctly. You have to look pretty hard to even notice their existence in the first place. I've never heard of a broken undocumented standard library module becoming a deal-breaker for someone new to Python. "MacPython: We've all this great Mac-specific stuff, but we won't tell you how to use any of it. Also, quite a bit of it is broken because we couldn't be bothered to do do a decent job of it." This is not the way to make a great impression with users. And really, what is the point of wasting valuable time and effort doing a half-assed job? It could be spent much more profitably elsewhere doing something more productive: writing modules you actually care about yourself, providing better documentation for existing mo
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
On Mar 2, 2005, at 9:51, has wrote: Bob wrote: If you learn bgen and submit proper patches Without proper documentation and tutorials? Sorry, but masochistic self-flagellation is not my thing. This is somebody else's house of cards to sort out before everyone else can seriously be expected to play in it. Yet you screw around with the Carbon modules, which also have no documentation or tutorials? Besides, what's the point in me going to the trouble of properly patching something if the fix won't percolate into the main distribution for another year when I need it now? If the fix didn't consist of adding new features, and you submitted it today, it could be in 2.4.1 in less than two weeks. You're confusing issues here. The problem is that you need OSA functionality. Removing something from the standard library does nothing to solve that problem. No, I'm using OSA.so as an illustrative example because I'm already familiar with it. The point is that potentially broken modules should not be going into standard library. And until they've been tested, all modules should be considered potentially broken. OSA.so is a prime example: I _know_ it hasn't been tested, because it took me five minutes to discover the first deal-killer bug. Other modules may be just as untested, but I can't speak for them as I've not tried them myself. In the case of OSA.so and any other new MacPython 2.4 additions that haven't been tested, until Jack posts a final MacPython 2.4 distribution then it ought to be safe to revoke their inclusion. The extension(s) are part of Python 2.4, and follow the same policy as anything else in there. The lack of a binary release doesn't really mean anything. Removing the extension may or may not be a good idea. If /some/ of it works, it might be worth keeping. In OSA.so's case the breakage is pretty fundamental, e.g. not being able to compile scripts from source is pretty much a deal-breaker by itself, never mind the other bugs and huge chunk of missing API. I hear no great clamour from the gallery to use this module, broken or otherwise, so just punt the bastard out. It's virtually worthless as it is, and sticking it in will only make it harder to clean up the mess later on. Other modules I can't speak for, other than to say that if nobody's tested them yet then it would be better to keep them out than until they are. If folk really care about them, they'll whip together and run some tests quickly enough. And if they don't care about them, it means those modules aren't worth including in the standard library in the first place. (Seriously, what are the justifications for putting stuff nobody needs or wants into the standard library?) It's already there, so it's not going anywhere in 2.4. The justification is that people *did* ask for an OSA wrapper -- I believe you were one of the larger proponents. It's partially your fault for not testing it *before* final release. Kicking a lot of this stuff back out the standard library would be a good start, because it's clearly not qualified to be there. Push it into 'MacAll', and take it from there. Well obviously that's not an option, Why? All it means users have to do two installs instead of one to get set up which is no huge effort, and in practice the MacPython installer could bundle and run a recent copy of the MacAll installer for convenience. And once all this stuff is out the standard library it's free to be working on without the onerous scheduling restrictions and personnel bottleneck that comes from being locked up in the standard library. Have I missed something? It can't happen until Python 2.6 at the earliest. I don't think it's very likely to go away anyway. Good luck! Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure? As I stated before, "MacAll" can't use the Carbon namespace, so this trivial reorganization is not possible. My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY. It's fine for users to avoid the standard library. But that doesn't excuse filling it up with crap and then saying we shouldn't be concerned by this behaviour because users can always go elsewhere if they don't like it. Different issue. If you can't see any problems in having two parallel libraries: one an officially sanctioned and bundled broken-ass POS and the other a giant third-party band-aid, then you really need to start looking harder. The damage it could cause MacPython's public image and credibility alone should be of significant concern. It's like letting your house get covered in three feet of rotting unwashed dishes and cat poop and then wondering why nobody wants to come round and visit any more. It does a disservice to Python's reputation, its developers and its end-users, and it's the sort of behaviour that'll eventually turn folk off Python and onto something
Re: [Pythonmac-SIG] CFURL Pain
On 3/2/05 6:00 AM, "has" <[EMAIL PROTECTED]> wrote: >> In this case, the API *asks* for an Alias. So, yeah, you do >> actually want an Alias. > > No, the TextEdit dictionary says 'alias', but the dictionary is > merely documentation, not the API itself, and dictionaries are > regularly incorrect. It should almost certainly read 'file'. IIRC, > the sdef format doesn't even list 'alias' as one of the standard > primitive types, so I've no idea where TextEdit gets it from. > Probably a blow on the head or something. The type 'alias' for the Save command in the Standard Suite is a long, longstanding bug in AppleScript. It should say 'file specification', or 'file', I guess. There's a special problem in AppleScript applications which have their own 'file' keywords meaning something else (like Outlook Express and Entourage), as you can imagine. Fortunately there is an equally longstanding coercion, performs by AppleScript itself, that allows you to use a string or Unicode text there. In OS X, the coercion is now to fileURL, I believe. Whether this coercion takes place at a deep enough level (AppleEvent?) that it will work also for appscript and MacPython, I don't know. If you try it, what happens? In _any_ AppleScriptable application, you can always just use the text file path for 'save' in AppleScript, and it works. -- Paul Berkowitz ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
Bob wrote: Absolutely. I have no problem with mistakes being made. It's setting them in stone that's the trouble. Not stone, just molasses. Near enough as makes no practical difference. It's a situation that should not occur in the first place. These molasses are entirely man-made. If you learn bgen and submit proper patches Without proper documentation and tutorials? Sorry, but masochistic self-flagellation is not my thing. This is somebody else's house of cards to sort out before everyone else can seriously be expected to play in it. Besides, what's the point in me going to the trouble of properly patching something if the fix won't percolate into the main distribution for another year when I need it now? You're confusing issues here. The problem is that you need OSA functionality. Removing something from the standard library does nothing to solve that problem. No, I'm using OSA.so as an illustrative example because I'm already familiar with it. The point is that potentially broken modules should not be going into standard library. And until they've been tested, all modules should be considered potentially broken. OSA.so is a prime example: I _know_ it hasn't been tested, because it took me five minutes to discover the first deal-killer bug. Other modules may be just as untested, but I can't speak for them as I've not tried them myself. In the case of OSA.so and any other new MacPython 2.4 additions that haven't been tested, until Jack posts a final MacPython 2.4 distribution then it ought to be safe to revoke their inclusion. Removing the extension may or may not be a good idea. If /some/ of it works, it might be worth keeping. In OSA.so's case the breakage is pretty fundamental, e.g. not being able to compile scripts from source is pretty much a deal-breaker by itself, never mind the other bugs and huge chunk of missing API. I hear no great clamour from the gallery to use this module, broken or otherwise, so just punt the bastard out. It's virtually worthless as it is, and sticking it in will only make it harder to clean up the mess later on. Other modules I can't speak for, other than to say that if nobody's tested them yet then it would be better to keep them out than until they are. If folk really care about them, they'll whip together and run some tests quickly enough. And if they don't care about them, it means those modules aren't worth including in the standard library in the first place. (Seriously, what are the justifications for putting stuff nobody needs or wants into the standard library?) Kicking a lot of this stuff back out the standard library would be a good start, because it's clearly not qualified to be there. Push it into 'MacAll', and take it from there. Well obviously that's not an option, Why? All it means users have to do two installs instead of one to get set up which is no huge effort, and in practice the MacPython installer could bundle and run a recent copy of the MacAll installer for convenience. And once all this stuff is out the standard library it's free to be working on without the onerous scheduling restrictions and personnel bottleneck that comes from being locked up in the standard library. Have I missed something? It can't happen until Python 2.6 at the earliest. I don't think it's very likely to go away anyway. Good luck! Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure? My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY. It's fine for users to avoid the standard library. But that doesn't excuse filling it up with crap and then saying we shouldn't be concerned by this behaviour because users can always go elsewhere if they don't like it. Different issue. If you can't see any problems in having two parallel libraries: one an officially sanctioned and bundled broken-ass POS and the other a giant third-party band-aid, then you really need to start looking harder. The damage it could cause MacPython's public image and credibility alone should be of significant concern. It's like letting your house get covered in three feet of rotting unwashed dishes and cat poop and then wondering why nobody wants to come round and visit any more. It does a disservice to Python's reputation, its developers and its end-users, and it's the sort of behaviour that'll eventually turn folk off Python and onto something else. My point? Doing a job badly is the _worst_ thing possible. If you can't or won't do it properly, you shouldn't to do it at all. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote: FSSpec is legacy. It should not ever be used in any code except to reference nonexistent files or to deal with legacy APIs. You shouldn't use them if the API will take an FSRef or an Alias. Neither FSRef or Alias can be used to refer to non-existent files. FileURL does, but I'm not sure it can yet be used safely in place of FSSpecs in all cases, plus their standard Carbon.CF implementation is busted. FSSpecs suck, but I'm not sure they can be completely ignored just yet - any time I've tried to streamline aem/appscript to save the user from dealing with crap like this I've ended up having to re-expose it again in all its ugliness after something else ralphed on the 'clean and elegant' version. Rock, hard place. What's really needed is for MacPython to provide a standard high-level File class that abstracts over all this mess so module authors can have a solid and reliable API to implement against and end users don't normally need to futz directly with this stuff. No doubt an interesting and challenging problem for anyone that wanted to tackle it. In this case, the API *asks* for an Alias. So, yeah, you do actually want an Alias. No, the TextEdit dictionary says 'alias', but the dictionary is merely documentation, not the API itself, and dictionaries are regularly incorrect. It should almost certainly read 'file'. IIRC, the sdef format doesn't even list 'alias' as one of the standard primitive types, so I've no idea where TextEdit gets it from. Probably a blow on the head or something. Cocoa Scripting APIs are _also_ frequently buggy and ill-designed, and specifying files was one of its classic blunders in earlier incarnations which they've been trying to rectify ever since. So it is possible that they've buggered things up differently in 10.3 such that you do have to specify an existing file in a 'save' command; I don't have 10.3 so can't check offhand. If they have, I'm sure there's bugs filed on that as well, but I can't recall hearing anything about it. Nevertheless, 'save' commands have always traditionally accepted a file handle specifying an as-yet non-existent file for saving documents to a new file, and ignoring periodic Apple incompetence I don't believe this policy has formally changed for one moment. Apply one dose of healthy skepticism and a large dollop of plain common sense - both absolutely essential when it comes to Mac application scripting - and this should be obvious. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
