🌐 Mailman 3 December 2009 - Pythonmac-SIG - python.org

python-config ldflags problem on mac
by Robin Dec. 18, 2009

Dec. 18, 2009

Hi, I have a problem with using python-config --ldflags on a Mac. Using my python.org install: robin-mbp:github robince$ which python-config /Library/Frameworks/Python.framework/Versions/2.5/bin/python-config robin-mbp:github robince$ python-config --ldflags -L/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config -ldl -lpython2.5 But if I build a C file with python embedded, the above linker flags result it in it embedding the system python. Obviously the -lpython2.5 is picking up the system one in preference to the one on the -L path. So far the only way I've got it to build against the one I want is with LDFLAGS=-F/ -framework Python (as well as -undefined dynamic_lookup -bundle, but I don't think that's relevant to the problem) However, I am looking for a way to determine this for users to install. Shouldn't python-config return the right thing? Is there something simple to add to LDFLAGS to allow -lpython2.5 to choose the right one so I can continue to use python-config (ie only search the path specified with -L) - this would allow the python-config output to work correctly for both the system python or user installed python. Or is there another way to determine (in an external build tool like make) the correct linker flags for the python in a users path (ie -F/ -framework Python). Any advice appreciated, Cheers Robin

2 1

Re: [Pythonmac-SIG] timeout of connection?
by has Dec. 18, 2009

Dec. 18, 2009

Jon Christopher wrote: >> Are you sure all commands are being executed? > > Reasonably, but I'll have to check again. Always helps to be sure. Been there, done that. >> What do the references produced by the following look like: >> >> print app("EyeTV").recordings.get() > > > IIRC, it's a list of recording objects (defined in the EyeTV dictionary) > which can then be passed back to EyeTV: > [...] > Now that I think about it, my app caches those recording objects for > quite some time. Is there a possibility that they could expire or become > invalidated over time? Bear in mind that Apple event IPC uses queries, not pointers, to identify remote objects. (It's roughly analogous to sending XPath queries over XML-RPC.) The reason I ask to see an actual result is because some types of queries are more 'reliable' than others. Only the by-id reference form gives anything like a guarantee of locating the same object every time you use it in a command. >> Have you tried enabling AEDebug and observing the events being sent? > > Interesting idea. Any suggestions on how to do so? My application > is a plug-in for Front Row, > and there's something weird about the way FR is started: there's a > separate launcher app > for the actual .app in /System/Library/Core Services/Front Row.app; > I'm not sure if launching FR > from the command line actually works, which makes setting the AEDebug > environment variable > problematic. Try setting it on EyeTV. http://developer.apple.com/mac/library/technotes/tn2004/tn2124.html#SECAE has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net

1 0

Re: [Pythonmac-SIG] timeout of connection?
by has Dec. 17, 2009

Dec. 17, 2009

Jon Christopher wrote: > So, I'll reiterate my request. Can can any of the appscript gurus > think of any reason why > the following (pseudo) code should fail: > > > import appscript > id=app("EyeTV").recordings.get()[0] > app("EyeTV").play(id) # works just fine > app("EyeTV").stop() #works just fine > > go_do_other_stuff_possibly_in_other_threads_for_a_really_long_time() > > app("EyeTV").play(id) # has no effect Is the EyeTV process running throughout, or does it quit and restart? Are you sure all commands are being executed? What do the references produced by the following look like: print app("EyeTV").recordings.get() Have you tried enabling AEDebug and observing the events being sent? has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net

2 1

timeout of connection?
by Jon Christopher Dec. 17, 2009

Dec. 17, 2009

I'm the developer of PyeTV (http://code.google.com/p/pyetv/), a Front Row plugin for EyeTV. I'm experiencing some weird behavior that I'd like to ask the experts here about. Essentially all PyeTV does is communicate with EyeTV via appscript and throw up a few menu options in Front Row. When the user activates a menu option for playing a recording, it sends the appropriate appscript command to EyeTV, something like: app("EyeTV").play(id) where "id" is the stored integer id of the recording to play. In general, this works quite well, however, there are certain curcumstances where it seems that EyeTV never gets the message to play the recording. It seems that after Front Row has been idle for quite some time (perhaps 12 hours or more), and I then attempt to play a recording, it doesn't seem like the message is sent to EyeTV, (or perhaps it's just not received; I can't really tell.) If I then restart Front Row (and therefore python) and try again, it works 100% of the time, until it's been idle again for a long time. I haven't been able to observe anything unusual in the logs, and am beginning to grasp at straws for an explanation here. I've stared at my code and poked and prodded it until my eyes have started bleeding, all to no avail. I'm beginning to wonder if the problem might lie in some of the behind-the-scenes implementation details of appscript. Perhaps there's some sort of caching of connections to applications which times at some point. In any case, can any of the appscript gurus think of any reason why the following (pseudo) code should fail: import appscript id=app("EyeTV").recordings.get()[0] app("EyeTV").play(id) # works just fine app("EyeTV").stop() #works just fine go_do_other_stuff_possibly_in_other_threads_for_a_really_long_time() app("EyeTV").play(id) # has no effect Thanks, Jon Again, I've researched this quite a bit, and haven't

3 7

Re: [Pythonmac-SIG] coercing to text (Adam Morris)
by has Dec. 15, 2009

Dec. 15, 2009

Adam Morris wrote: > ASTranslate tells me that > tell application "Pages" to tell front document to get selection as text > should be > app(u'Pages').documents[1].selection.get(resulttype=k.unicode_text) > > but that doesn't return what I want (a reference? ... hardly useful!). Yet: > > app('Pages').documents[1].selection()() > > returns what I want. The unicode text. > > I don't get what that 'extra' set of parens is doing. What implicit function > is being called? Can't imagine it's get(). app('Pages').documents[1].selection()() is shorthand for: app('Pages').documents[1].selection.get().get() First command asks for the selection property's value; Pages returns a reference representing a text range. Second command asks for the specified text range, Pages returns the characters in that range as a (Unicode) string. > I'm obviously missing something here, but no idea what! ASTranslate seems to > be missing it too. Thanks for your help! ASTranslate only tells you what events AppleScript sent. In this case, it looks like Pages is completely ignoring the return type argument and always returning a reference (Apple never laid down hard rules about how this feature should work, so different applications do all sorts of different things - though most just ignore it). If the value returned by an application command isn't of the type you specified, AppleScript will make its own attempt to correct this by coercing the value itself - and AS resolves coercing a reference by packing it into a 'get' event and sending it off for the application to evaluate. (You won't see that second event in ASTranslate unless the 'send events to app' option is checked.) Appscript replicates most AppleScript behaviours for sake of application compatibility, but doesn't try to mimic this sort of opaque, non-publicly documented magic (e.g. no implicit gets, no munging of 'count' commands) just because it's tricky to figure out exactly what AS is doing at times, and mimicking it badly is worse than not mimicking it at all. So what you ask appscript for is exactly what you get, and 98% of the time it's what AS would have asked for as well. It's the other 2% of corner cases that are tricky to fathom, but once you understand what's going on it should be straightforward to rephrase your requests appropriately - in this case by sending a second 'get' command yourself. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net

1 0

Re: [Pythonmac-SIG] coercing to text (Adam Morris)
by Adam Morris Dec. 15, 2009

Dec. 15, 2009

ASTranslate tells me that tell application "Pages" to tell front document to get selection as text should be app(u'Pages').documents[1].selection.get(resulttype=k.unicode_text) but that doesn't return what I want (a reference? ... hardly useful!). Yet: app('Pages').documents[1].selection()() returns what I want. The unicode text. I don't get what that 'extra' set of parens is doing. What implicit function is being called? Can't imagine it's get(). I'm obviously missing something here, but no idea what! ASTranslate seems to be missing it too. Thanks for your help! -Adam

1 0

Re: [Pythonmac-SIG] coercing to text
by hengist.podd e-mail Dec. 15, 2009

Dec. 15, 2009

Adam Morris wrote: > In Applescript, I would write the following: > > tell app "Pages" to tell front document to get its selection -- text from > character x to character y > tell app "Pages" to tell front document to get its selection as text -- > "whatever is selected" At a guess, the 'text' type isn't recognised outside of AppleScript 2.0 and you need to specify the 'Unicode text' type instead. So try k.Unicode_text in place of k.text and see if that works. (Annoyingly, applications seem to ignore unrecognised 'as' parameters rather than reporting them as errors, otherwise you'd know for sure if that was the problem.) If you run your above AppleScript in ASTranslate as Ned suggests, it will display each Apple event that AppleScript sends in appscript syntax. Very handy when you already know how to do it AppleScript and need some clues on how to write your appscript commands correctly. HTH has

2 1

Re: [Pythonmac-SIG] coercing to text
by Adam Morris Dec. 14, 2009

Dec. 14, 2009

In Applescript, I would write the following: tell app "Pages" to tell front document to get its selection -- text from character x to character y tell app "Pages" to tell front document to get its selection as text -- "whatever is selected" > Are you sure you are formulating the correct reference? Normally there > is no need to coerce the type. You might want to try has's ASTranslate > tool: http://appscript.sourceforge.net/tools.html > > -- > Ned Deily, > nad(a)acm.org > > > >

1 0

coercing to text
by Adam Morris Dec. 13, 2009

Dec. 13, 2009

Hi all, Quick question from someone getting used to appscript with python. How do I coerce into a text? reference.get(resulttype=k.text) But that doesn't seem to do what I want it to do. In Applescript I actually get the string, but in appscript I still get a reference. Thanks for your help! -Adam

2 1

32-bit build of Python 3.1 on 64-bit machine running Snow Leopard?
by Mitchell L Model Dec. 13, 2009

Dec. 13, 2009

Is it possible to create 32-bit build of Python 3.1 on 64-bit machine running Snow Leopard? Using the 3.1 subversion sources I have tried a variety of configure settings, but all produce 64-bit builds. The following does create a 32-bit only build for 2.6: configure --enable-framework --with-universal-archs=32-bit --enable-universalsdk=/ One reason I am asking is because I am curious about how the 3.1.1 binary installer, which is 32-bit only, was created -- was it just done on a 32-bit machine? I have other reasons to ask that are related to attempts to many experiments I've performed on several different machines in 10.5 and 10.6 building 3.1 and PyQt and running 3.1 inside of IDEs.

2 1