From enrike at altern.org  Fri Oct  1 16:17:04 2004
From: enrike at altern.org (altern)
Date: Fri Oct  1 16:19:04 2004
Subject: [Pythonmac-SIG] compiling pyopengl + numeric
In-Reply-To: <BD81CEAE.39573%jhrsn@pitt.edu>
References: <BD81CEAE.39573%jhrsn@pitt.edu>
Message-ID: <415D66E0.8070201@altern.org>

hi

i just compiled pyopngl but now when i try to import the pyOpenGL module 
i get this error:

 >>> import OpenGL
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "OpenGL/__init__.py", line 26, in ?
     from GL.GL__init___ import __numeric_present__, __numeric_support__
   File "OpenGL/GL/__init__.py", line 2, in ?
     from GL__init__ import *
ImportError: No module named GL__init__


then i tried to install Numeric 23 but ii get this error

Src/lapack_litemodule.c: At top level:
Src/lapack_litemodule.c:651: warning: function declaration isn't a prototype
Src/lapack_litemodule.c:648: warning: `lapack_liteError' defined but not 
used
gcc -Wl,-F. -Wl,-F. -bundle -framework Python 
build/temp.darwin-7.4.1-Power_Macintosh-2.3/Src/lapack_litemodule.o 
-L/usr/lib/atlas -llapack -lcblas -lf77blas -latlas -lg2c -o 
build/lib.darwin-7.4.1-Power_Macintosh-2.3/lapack_lite.so
ld: warning -L: directory name (/usr/lib/atlas) does not exist
ld: can't locate file for: -llapack
error: command 'gcc' failed with exit status 1

anyone knows what am i doing wrong?

thanks

-- 
enrike

From Chris.Barker at noaa.gov  Fri Oct  1 18:31:23 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Fri Oct  1 18:37:54 2004
Subject: [Pythonmac-SIG] compiling pyopengl + numeric
In-Reply-To: <415D66E0.8070201@altern.org>
References: <BD81CEAE.39573%jhrsn@pitt.edu> <415D66E0.8070201@altern.org>
Message-ID: <415D865B.2010308@noaa.gov>

altern wrote:

> then i tried to install Numeric 23 but ii get this error
> 
> Src/lapack_litemodule.c: At top level:
> Src/lapack_litemodule.c:651: warning: function declaration isn't a 
> prototype
> 
> anyone knows what am i doing wrong?

the setup.py that comes with Numeric23 accidentally (I assume) is set to 
  build Numeric against an existing lapack lib, rather than the 
lapack-lite that Numeric comes with.

Either:
A) install an lapack lib: this is the best option if you are doing 
linear algebra on large matrices
B) edit the setup.py to use the provided one. It should be commented 
well enough to do that
C) download Numeric 22, and use its setup.y to figure out what needs to 
change. You may well be able to simply use it with 23.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov
From Chris.Barker at noaa.gov  Fri Oct  1 19:47:46 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Fri Oct  1 19:54:17 2004
Subject: [Pythonmac-SIG] compiling pyopengl + numeric
In-Reply-To: <415D865B.2010308@noaa.gov>
References: <BD81CEAE.39573%jhrsn@pitt.edu> <415D66E0.8070201@altern.org>
	<415D865B.2010308@noaa.gov>
Message-ID: <415D9842.5090301@noaa.gov>

Chris Barker wrote:
> Either:
> A) install an lapack lib: this is the best option if you are doing 
> linear algebra on large matrices
> B) edit the setup.py to use the provided one. It should be commented 
> well enough to do that
> C) download Numeric 22, and use its setup.y to figure out what needs to 
> change. You may well be able to simply use it with 23.

oops, sorry, I'm on a lot of mailing lists, and I didn't notice that 
this is the macpython list. On OS-X, you want to:

use PackageManager to get Numeric, preferably from Bob Ippolito's 
repository, which will give you Numeric linked against Apple's lapack.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov
From Chris.Barker at noaa.gov  Fri Oct  1 19:51:21 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Fri Oct  1 19:57:52 2004
Subject: [Pythonmac-SIG] Re: cwd and PythonLauncher problem -- a bit more
	info
In-Reply-To: <E112EB3A-1317-11D9-8320-000A95686CD8@redivi.com>
References: <BD81CEAE.39573%jhrsn@pitt.edu>
	<E112EB3A-1317-11D9-8320-000A95686CD8@redivi.com>
Message-ID: <415D9919.6090102@noaa.gov>

Bob Ippolito wrote:

> GUI apps in 
> OS X always have a current directory of /

really? UGG!
 > (not sure why you ever saw it
> have a path of the user directory, maybe PythonLauncher does that on 
> purpose?).  It would make sense for PythonLauncher to behave otherwise 
> though.
> 
> In the meantime, you could do:
> 
> import os
> os.chdir(os.path.dirname(__file__))
> 
> which will change to the directory that your script is in.

Is there a reliable way to change it to the user's home directory? can 
you count on this?:

import os
os.chdir(os.getenv("HOME"))

this works from a shell, but will HOME be defined in a GUI app?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov
From bob at redivi.com  Fri Oct  1 20:03:58 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  1 20:04:35 2004
Subject: [Pythonmac-SIG] Re: cwd and PythonLauncher problem -- a bit more
	info
In-Reply-To: <415D9919.6090102@noaa.gov>
References: <BD81CEAE.39573%jhrsn@pitt.edu>
	<E112EB3A-1317-11D9-8320-000A95686CD8@redivi.com>
	<415D9919.6090102@noaa.gov>
Message-ID: <4431C46E-13D4-11D9-BC84-000A95686CD8@redivi.com>


On Oct 1, 2004, at 1:51 PM, Chris Barker wrote:

> Bob Ippolito wrote:
>
>> GUI apps in OS X always have a current directory of /
>
> really? UGG!

Well if you think about it, it makes sense... where else would it be?  
The Resources folder of the application?  The folder the application is 
in?  It's ambiguous and really depends on what your application does.

> > (not sure why you ever saw it
>> have a path of the user directory, maybe PythonLauncher does that on 
>> purpose?).  It would make sense for PythonLauncher to behave 
>> otherwise though.
>> In the meantime, you could do:
>> import os
>> os.chdir(os.path.dirname(__file__))
>> which will change to the directory that your script is in.
>
> Is there a reliable way to change it to the user's home directory? can 
> you count on this?:
>
> import os
> os.chdir(os.getenv("HOME"))
>
> this works from a shell, but will HOME be defined in a GUI app?

That should work fine.

-bob
From n8gray at gmail.com  Fri Oct  1 21:51:53 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Fri Oct  1 21:52:07 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
Message-ID: <aee06c9e041001125164940792@mail.gmail.com>

Hello MacPythons,

I'm having trouble getting my python scripts to launch from the
command line under OS X 10.3.  The usual #! lines don't work as I
expect.  Neither '#!/usr/bin/pythonw' nor '#!/usr/bin/python' work --
they are ignored and the script is treated as a bash script.  OTOH,
'#!/usr/bin/env python' does work, but I want to be assured of getting
the system python version instead of, for example, the Fink version. 
Any ideas what's going wrong?

Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
perfect but the 255 character limit on the message length is *way* too
short.  It's also annoying that the resulting dialogs are not keyboard
navigable, but that's less important of an issue.  Is there anything
similar that allows larger messages?

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From jhrsn at pitt.edu  Fri Oct  1 23:27:17 2004
From: jhrsn at pitt.edu (Jim Harrison)
Date: Fri Oct  1 23:26:27 2004
Subject: [Pythonmac-SIG] cwd and PythonLauncher problem--behavior
	variability is Bad=?ISO-8859-1?B?gQ==?=
In-Reply-To: <4431C46E-13D4-11D9-BC84-000A95686CD8@redivi.com>
Message-ID: <BD8343F5.39690%jhrsn@pitt.edu>

on 10/1/04 2:03 PM, Bob Ippolito at bob@redivi.com wrote:

>>> In the meantime, you could do:
>>> import os
>>> os.chdir(os.path.dirname(__file__))
>>> which will change to the directory that your script is in.
>>
>> Chris Barker wrote:
>>
>> Is there a reliable way to change it to the user's home directory? can
>> you count on this?:
>> 
>> import os
>> os.chdir(os.getenv("HOME"))

Thanks very much for the responses.

While Bob and Chris's workarounds are effective, I think this is an issue
that could use a bit of attention because of existing inconsistencies:

In the statement: myFileHandle = open('spam.txt', 'r')

1. When a script is run from IDLE or MacPythonIDE (OSX 10.3.5), open finds
or creates spam.txt in the directory containing the script file.

2. When a script is run in Windows either from IDLE or by double-clicking,
spam.txt is also found or created in the directory containing the script.

3. When the script is double-clicked on OSX, drag/dropped on PythonLauncher,
or run from PyOXIDE or BBEdit, open does not find spam.txt in the directory
of the script or the file is created at / (once I had a file created in my
home directory and I haven't tried to track that behavior down further).

4. Some of the existing Python documentation, such as the second edition of
O'Reilly's Learning Python, states explicitly that the default file path for
file names in the situation above is the directory the file is executing
from.

5. I think most users would feel intuitively that navigating the command
line to a directory (using cd) and then calling python to run a file in that
directory should behave similarly to navigating to a directory through the
GUI and double clicking a python script in that directory (assuming file
types are set so that the script is passed to the interpreter). This
currently is the case on Windows but not on OSX. My hazy memory is that the
classic PythonLauncher did set the default to the directory containing the
file.

Without getting into an argument about who is doing it the right way, this
variability in documentation and behavior can be confusing to new Python
users (I'm currently teaching an introductory Python class) and overall is
probably Not A Good Thing.

Jim Harrison
Univ. of Pittsburgh
From altis at semi-retired.com  Fri Oct  1 23:30:21 2004
From: altis at semi-retired.com (Kevin Altis)
Date: Fri Oct  1 23:30:27 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <aee06c9e041001125164940792@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
Message-ID: <195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>

On Oct 1, 2004, at 12:51 PM, Nathaniel Gray wrote:

> Hello MacPythons,
>
> I'm having trouble getting my python scripts to launch from the
> command line under OS X 10.3.  The usual #! lines don't work as I
> expect.  Neither '#!/usr/bin/pythonw' nor '#!/usr/bin/python' work --
> they are ignored and the script is treated as a bash script.  OTOH,
> '#!/usr/bin/env python' does work, but I want to be assured of getting
> the system python version instead of, for example, the Fink version.
> Any ideas what's going wrong?
>
> Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
> perfect but the 255 character limit on the message length is *way* too
> short.  It's also annoying that the resulting dialogs are not keyboard
> navigable, but that's less important of an issue.  Is there anything
> similar that allows larger messages?
>
> Cheers,
> -n8

Hmm, I don't know what the explanation of the #! line not working is, 
but I found the same thing, I had to use /usr/bin/env pythonw to make 
it work as expected. The error message I received is for tcsh since my 
system was upgraded from Jaguar and I never bothered to switch to bash.

tcsh: import: Command not found.
from: can't read /var/mail/wx.lib
tcsh: Badly placed ()'s.

I don't like having to do a chmod such as chmod a+x on my Python 
scripts on the Mac, so typically I just run everything as a script 
argument to pythonw or run the script from the Finder via 
double-clicking, so I hadn't run into this before.

As for doing simple dialogs I don't know all the Mac-specific options, 
but wxPython provides all the system dialogs and then some and of 
course it works the same on Linux, Mac OS X, and Windows. The 
dialogs.py module provides function wrappers for all of the dialogs so 
you don't have to worry about creating an instance of the dialog 
classes, showing the dialog, and then destroying it, instead you just 
make a function call which is a nice match for modal dialogs. It would 
be tough to get much simpler than this.

If you install wxPython, you'll find the module at 
/Library/Python/2.3/wx/lib/dialogs.py. Below is a simple example of 
using the function wrappers, but dialogs.py contains a full if __name__ 
== '__main__' block to demonstrate use of all of the dialogs and 
results. I used the named args just to make the examples clearer.

#!/usr/bin/env pythonw
##!/usr/bin/pythonw

import wx
from wx.lib import dialogs

app = wx.PySimpleApp()
#dialogs.alertDialog(None, message='hello')
dialogs.scrolledMessageDialog(None, title='Multi-line message', 
message='one\ntwo\three\nfour')

ka

From hengist.podd at virgin.net  Sat Oct  2 00:27:14 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct  2 00:29:37 2004
Subject: [Pythonmac-SIG] scrapp-0.1.0
Message-ID: <a05200f37bd83887290c5@[81.103.144.218]>

Hi folks,

First version of scrapp, a simple SCRiptable APPlication framework, 
uploaded for your viewing pleasure:

http://freespace.virgin.net/hamish.sanderson/scrapp-0.1.0.tar.gz


Also requires aem-0.3.1 and osaterminology-0.2.1; see:

http://freespace.virgin.net/hamish.sanderson/appscript.html


Basic documentation is done, plus a couple of examples, but still 
lacking AppleScripter-friendly installation instructions, explanation 
of how it works, background info on MacPython, other examples, etc. 
Also can't decide if I should do detailed explanation or a tutorial 
walkthrough, though I'm inclining more to the latter - what do folk 
think? If the latter, do you think the TextCommands app would be a 
suitable project, or should I create a series of very simple, fairly 
abstract projects, each one demonstrating a single aspect of its use?

Comments and suggestions, please.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From n8gray at gmail.com  Sat Oct  2 03:06:49 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sat Oct  2 03:06:52 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
Message-ID: <aee06c9e04100118061724ef9a@mail.gmail.com>

On Fri, 1 Oct 2004 14:30:21 -0700, Kevin Altis <altis@semi-retired.com> wrote:

> Hmm, I don't know what the explanation of the #! line not working is,
> but I found the same thing, I had to use /usr/bin/env pythonw to make
> it work as expected. The error message I received is for tcsh since my
> system was upgraded from Jaguar and I never bothered to switch to bash.
> 
> tcsh: import: Command not found.
> from: can't read /var/mail/wx.lib
> tcsh: Badly placed ()'s.

I figured this out.  The problem is that pythonw is a symlink to
pythonw2.3, which is a shell script, and Darwin won't allow the
interpreter for one script to be another script.  I ended up using
this ugly line:
#!/System/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app/Contents/MacOS/Python

Thankfully, Darwin doesn't seem to mind really long #! lines.  The
proper solution, AFAICT, is to make /usr/bin/pythonw2.3 a symlink to
the mess I listed above rather than a shell script that wraps the mess
I listed above.  This is how /usr/bin/python2.3 works, which is why
#!/usr/bin/python does work (I was mistaken when I reported that it
didn't).

I'm not sure who to file the bug report with.  Can anybody point me in
the right direction?

> As for doing simple dialogs I don't know all the Mac-specific options,
> but wxPython provides all the system dialogs and then some and of
> course it works the same on Linux, Mac OS X, and Windows. The
> dialogs.py module provides function wrappers for all of the dialogs so
> you don't have to worry about creating an instance of the dialog
> classes, showing the dialog, and then destroying it, instead you just
> make a function call which is a nice match for modal dialogs. It would
> be tough to get much simpler than this.

I'm afraid downloading WxPython is too heavyweight.  I'm trying to use
Python as AppleScript, essentially.  I was thrilled to find appscript,
makes it feasible to do exactly that, but I need a simple, lightweight
way to interact with users.  The balance is heavily weighted towards a
solution that is platform-specific and has few (preferably no)
dependencies.  Basically I really want an EasyDialogs that works.  ;^)

Thanks for your help,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From bob at redivi.com  Sat Oct  2 03:50:36 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 03:51:12 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e04100118061724ef9a@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
Message-ID: <7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>

On Oct 1, 2004, at 9:06 PM, Nathaniel Gray wrote:

> On Fri, 1 Oct 2004 14:30:21 -0700, Kevin Altis  
> <altis@semi-retired.com> wrote:
>
>> Hmm, I don't know what the explanation of the #! line not working is,
>> but I found the same thing, I had to use /usr/bin/env pythonw to make
>> it work as expected. The error message I received is for tcsh since my
>> system was upgraded from Jaguar and I never bothered to switch to  
>> bash.
>>
>> tcsh: import: Command not found.
>> from: can't read /var/mail/wx.lib
>> tcsh: Badly placed ()'s.
>
> I figured this out.  The problem is that pythonw is a symlink to
> pythonw2.3, which is a shell script, and Darwin won't allow the
> interpreter for one script to be another script.  I ended up using
> this ugly line:
> #!/System/Library/Frameworks/Python.framework/Versions/Current/ 
> Resources/Python.app/Contents/MacOS/Python
>
> Thankfully, Darwin doesn't seem to mind really long #! lines.  The
> proper solution, AFAICT, is to make /usr/bin/pythonw2.3 a symlink to
> the mess I listed above rather than a shell script that wraps the mess
> I listed above.  This is how /usr/bin/python2.3 works, which is why
> #!/usr/bin/python does work (I was mistaken when I reported that it
> didn't).
>
> I'm not sure who to file the bug report with.  Can anybody point me in
> the right direction?

It's not a bug.  The reason pythonw is a shell script is so that the  
argv[0] for the Python interpreter process points to an interpreter  
executable that exists inside of a valid application bundle.  This is  
necessary in order for the WindowServer to accept a connection to your  
process without using undocumented private hacks.  It would be possible  
to do this by means other than a shell script, but "exec" is a  
convenient way of doing this.

You shouldn't really be using bare scripts as GUI applications in the  
first place.  You may want to take a look at py2app (which is basically  
usable at this point, unless you depend on a funky package like PIL or  
pygame):
http://svn.red-bean.com/bob/py2app/trunk/
(which depends on)
http://svn.red-bean.com/bob/macholib/trunk/

>> As for doing simple dialogs I don't know all the Mac-specific options,
>> but wxPython provides all the system dialogs and then some and of
>> course it works the same on Linux, Mac OS X, and Windows. The
>> dialogs.py module provides function wrappers for all of the dialogs so
>> you don't have to worry about creating an instance of the dialog
>> classes, showing the dialog, and then destroying it, instead you just
>> make a function call which is a nice match for modal dialogs. It would
>> be tough to get much simpler than this.
>
> I'm afraid downloading WxPython is too heavyweight.  I'm trying to use
> Python as AppleScript, essentially.  I was thrilled to find appscript,
> makes it feasible to do exactly that, but I need a simple, lightweight
> way to interact with users.  The balance is heavily weighted towards a
> solution that is platform-specific and has few (preferably no)
> dependencies.  Basically I really want an EasyDialogs that works.  ;^)

You could emulate EasyDialogs with PyObjC, which is pretty lightweight.  
  You could also probably convince appscript to do all your dialogs in  
the same way that Applescript does.

Using py2app (or to a lesser extent, bundlebuilder) makes applications  
that have no dependencies anyway, so that part of your argument doesn't  
really hold much water.  Using wxPython would make for relatively large  
standalone applications, but standalone applications nonetheless.

-bob
From janssen at parc.com  Sat Oct  2 04:28:08 2004
From: janssen at parc.com (Bill Janssen)
Date: Sat Oct  2 04:28:41 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED] 
In-Reply-To: Your message of "Fri, 01 Oct 2004 18:50:36 PDT."
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com> 
Message-ID: <04Oct1.192812pdt."58617"@synergy1.parc.xerox.com>

> You may want to take a look at py2app (which is basically  
> usable at this point, unless you depend on a funky package like PIL or  
> pygame):

Come on, Bob, PIL is hardly unusual.  I'd say py2app isn't really
usable if it can't handle PIL and its ilk.  Perhaps for AppleScript
replacements, though.

Bill
From bob at redivi.com  Sat Oct  2 04:39:43 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 04:40:18 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED] 
In-Reply-To: <04Oct1.192812pdt."58617"@synergy1.parc.xerox.com>
References: <04Oct1.192812pdt."58617"@synergy1.parc.xerox.com>
Message-ID: <50D3F0A9-141C-11D9-BEA4-000A95686CD8@redivi.com>


On Oct 1, 2004, at 10:28 PM, Bill Janssen wrote:

>> You may want to take a look at py2app (which is basically
>> usable at this point, unless you depend on a funky package like PIL or
>> pygame):
>
> Come on, Bob, PIL is hardly unusual.  I'd say py2app isn't really
> usable if it can't handle PIL and its ilk.  Perhaps for AppleScript
> replacements, though.

I was referring to its *implementation*, not its popularity or utility.

PIL does some ridiculous things in order to find its plugins, which 
makes it impossible to determine its dependencies without special code 
that knows that PIL wants every possible module that ends with 
"ImagePlugin".  It is in no way compatible with the way that 
modulefinder works.

pygame refers to several data files, which is another behavior that 
modulefinder does not support.

In either case they will work once I add the code that allows you to 
include a package as-is, but that code has not yet been written.

Currently, properly written packages (even with dylib or framework 
dependencies) should work just fine (wxPython, Tkinter, PyObjC, etc.).  
Tkinter and PyObjC are tested, wxPython is not.

-bob
From n8gray at gmail.com  Sat Oct  2 07:54:55 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sat Oct  2 07:54:59 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
Message-ID: <aee06c9e04100122543713b8af@mail.gmail.com>

On Fri, 1 Oct 2004 21:50:36 -0400, Bob Ippolito <bob@redivi.com> wrote:
> On Oct 1, 2004, at 9:06 PM, Nathaniel Gray wrote:

> > I figured this out.  The problem is that pythonw is a symlink to
> > pythonw2.3, which is a shell script, and Darwin won't allow the
> > interpreter for one script to be another script.  I ended up using
> > this ugly line:
> > #!/System/Library/Frameworks/Python.framework/Versions/Current/
> > Resources/Python.app/Contents/MacOS/Python
> >
> > Thankfully, Darwin doesn't seem to mind really long #! lines.  The
> > proper solution, AFAICT, is to make /usr/bin/pythonw2.3 a symlink to
> > the mess I listed above rather than a shell script that wraps the mess
> > I listed above.  This is how /usr/bin/python2.3 works, which is why
> > #!/usr/bin/python does work (I was mistaken when I reported that it
> > didn't).
> >
> > I'm not sure who to file the bug report with.  Can anybody point me in
> > the right direction?
> 
> It's not a bug.  The reason pythonw is a shell script is so that the
> argv[0] for the Python interpreter process points to an interpreter
> executable that exists inside of a valid application bundle.  This is
> necessary in order for the WindowServer to accept a connection to your
> process without using undocumented private hacks.  It would be possible
> to do this by means other than a shell script, but "exec" is a
> convenient way of doing this.

Would a simple C program that did the same thing work?  It's pretty
bad that a python interpreter can't work in a #! line.  If it can be
made to work without too much pain I'd suggest it ought to be done,
for the sake of consistency.

> You shouldn't really be using bare scripts as GUI applications in the
> first place.  You may want to take a look at py2app (which is basically
> usable at this point, unless you depend on a funky package like PIL or
> pygame):
> http://svn.red-bean.com/bob/py2app/trunk/
> (which depends on)
> http://svn.red-bean.com/bob/macholib/trunk/

Thanks for the references.  I'll check them out, but I don't really
want to write GUI applications, I want to write scripts that can do
elementary dialog-based user interaction.  AFAICT there's not much
other than the #! issue standing in the way.

> >> As for doing simple dialogs I don't know all the Mac-specific options,
> >> but wxPython provides all the system dialogs and then some and of
> >> course it works the same on Linux, Mac OS X, and Windows. The
> >> dialogs.py module provides function wrappers for all of the dialogs so
> >> you don't have to worry about creating an instance of the dialog
> >> classes, showing the dialog, and then destroying it, instead you just
> >> make a function call which is a nice match for modal dialogs. It would
> >> be tough to get much simpler than this.
> >
> > I'm afraid downloading WxPython is too heavyweight.  I'm trying to use
> > Python as AppleScript, essentially.  I was thrilled to find appscript,
> > makes it feasible to do exactly that, but I need a simple, lightweight
> > way to interact with users.  The balance is heavily weighted towards a
> > solution that is platform-specific and has few (preferably no)
> > dependencies.  Basically I really want an EasyDialogs that works.  ;^)
> 
> You could emulate EasyDialogs with PyObjC, which is pretty lightweight.
>   You could also probably convince appscript to do all your dialogs in
> the same way that Applescript does.

These are probably the most promising routes.  Really, I asked the
question hoping somebody had done something with PyObjC or appscript
already and I could use their code.

BTW, is there any intention to get PyObjC included in the standard
Python distro?  It would be nice if EasyDialogs could be updated to OS
X standards.

> Using py2app (or to a lesser extent, bundlebuilder) makes applications
> that have no dependencies anyway, so that part of your argument doesn't
> really hold much water.  Using wxPython would make for relatively large
> standalone applications, but standalone applications nonetheless.

I actually meant dependencies for the casual scripter, not the
end-user.  I'd love to be able to tell my friends, "Python makes an
elegant replacement for AppleScript for your simple scripting tasks
and you only need to install 1 package to make it work."  If
EasyDialogs was just a little better it would already be true! :-) 
If/when appscript and/or PyObjC get into the core then the argument
would become even simpler and much more convincing.

Thanks,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From bob at redivi.com  Sat Oct  2 08:29:13 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 08:29:51 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e04100122543713b8af@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
Message-ID: <60AB8BF0-143C-11D9-AFE1-000A95686CD8@redivi.com>

On Oct 2, 2004, at 1:54 AM, Nathaniel Gray wrote:

> On Fri, 1 Oct 2004 21:50:36 -0400, Bob Ippolito <bob@redivi.com> wrote:
>> On Oct 1, 2004, at 9:06 PM, Nathaniel Gray wrote:
>
>>> I figured this out.  The problem is that pythonw is a symlink to
>>> pythonw2.3, which is a shell script, and Darwin won't allow the
>>> interpreter for one script to be another script.  I ended up using
>>> this ugly line:
>>> #!/System/Library/Frameworks/Python.framework/Versions/Current/
>>> Resources/Python.app/Contents/MacOS/Python
>>>
>>> Thankfully, Darwin doesn't seem to mind really long #! lines.  The
>>> proper solution, AFAICT, is to make /usr/bin/pythonw2.3 a symlink to
>>> the mess I listed above rather than a shell script that wraps the 
>>> mess
>>> I listed above.  This is how /usr/bin/python2.3 works, which is why
>>> #!/usr/bin/python does work (I was mistaken when I reported that it
>>> didn't).
>>>
>>> I'm not sure who to file the bug report with.  Can anybody point me 
>>> in
>>> the right direction?
>>
>> It's not a bug.  The reason pythonw is a shell script is so that the
>> argv[0] for the Python interpreter process points to an interpreter
>> executable that exists inside of a valid application bundle.  This is
>> necessary in order for the WindowServer to accept a connection to your
>> process without using undocumented private hacks.  It would be 
>> possible
>> to do this by means other than a shell script, but "exec" is a
>> convenient way of doing this.
>
> Would a simple C program that did the same thing work?  It's pretty
> bad that a python interpreter can't work in a #! line.  If it can be
> made to work without too much pain I'd suggest it ought to be done,
> for the sake of consistency.

Yes it can be done in C.  It *might* make Python 2.4 if somebody 
submits a patch right away.  I'm not volunteering, though :)

>> You shouldn't really be using bare scripts as GUI applications in the
>> first place.  You may want to take a look at py2app (which is 
>> basically
>> usable at this point, unless you depend on a funky package like PIL or
>> pygame):
>> http://svn.red-bean.com/bob/py2app/trunk/
>> (which depends on)
>> http://svn.red-bean.com/bob/macholib/trunk/
>
> Thanks for the references.  I'll check them out, but I don't really
> want to write GUI applications, I want to write scripts that can do
> elementary dialog-based user interaction.  AFAICT there's not much
> other than the #! issue standing in the way.

Any application that uses the GUI is a GUI application, period.

>>>> As for doing simple dialogs I don't know all the Mac-specific 
>>>> options,
>>>> but wxPython provides all the system dialogs and then some and of
>>>> course it works the same on Linux, Mac OS X, and Windows. The
>>>> dialogs.py module provides function wrappers for all of the dialogs 
>>>> so
>>>> you don't have to worry about creating an instance of the dialog
>>>> classes, showing the dialog, and then destroying it, instead you 
>>>> just
>>>> make a function call which is a nice match for modal dialogs. It 
>>>> would
>>>> be tough to get much simpler than this.
>>>
>>> I'm afraid downloading WxPython is too heavyweight.  I'm trying to 
>>> use
>>> Python as AppleScript, essentially.  I was thrilled to find 
>>> appscript,
>>> makes it feasible to do exactly that, but I need a simple, 
>>> lightweight
>>> way to interact with users.  The balance is heavily weighted towards 
>>> a
>>> solution that is platform-specific and has few (preferably no)
>>> dependencies.  Basically I really want an EasyDialogs that works.  
>>> ;^)
>>
>> You could emulate EasyDialogs with PyObjC, which is pretty 
>> lightweight.
>>   You could also probably convince appscript to do all your dialogs in
>> the same way that Applescript does.
>
> These are probably the most promising routes.  Really, I asked the
> question hoping somebody had done something with PyObjC or appscript
> already and I could use their code.
>
> BTW, is there any intention to get PyObjC included in the standard
> Python distro?  It would be nice if EasyDialogs could be updated to OS
> X standards.

Neither PyObjC or appscript are ready to become part of the standard 
Python distribution.  They definitely won't make 2.4, so that makes 2.5 
the earliest possible opportunity for inclusion into Python.  Who knows 
when that will be.

>> Using py2app (or to a lesser extent, bundlebuilder) makes applications
>> that have no dependencies anyway, so that part of your argument 
>> doesn't
>> really hold much water.  Using wxPython would make for relatively 
>> large
>> standalone applications, but standalone applications nonetheless.
>
> I actually meant dependencies for the casual scripter, not the
> end-user.  I'd love to be able to tell my friends, "Python makes an
> elegant replacement for AppleScript for your simple scripting tasks
> and you only need to install 1 package to make it work."  If
> EasyDialogs was just a little better it would already be true! :-)
> If/when appscript and/or PyObjC get into the core then the argument
> would become even simpler and much more convincing.

I'd say that it's more likely that PyObjC and/or appscript would be 
picked up by Apple for a future release of Mac OS X before the PSF 
picks them up for inclusion into Python.  Particularly PyObjC, because 
Apple already ships ObjC bridges for Perl and Java.

-bob
From altis at semi-retired.com  Sat Oct  2 08:51:57 2004
From: altis at semi-retired.com (Kevin Altis)
Date: Sat Oct  2 08:52:00 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e04100122543713b8af@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
Message-ID: <8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>

On Oct 1, 2004, at 10:54 PM, Nathaniel Gray wrote:

> I actually meant dependencies for the casual scripter, not the
> end-user.  I'd love to be able to tell my friends, "Python makes an
> elegant replacement for AppleScript for your simple scripting tasks
> and you only need to install 1 package to make it work."  If
> EasyDialogs was just a little better it would already be true! :-)
> If/when appscript and/or PyObjC get into the core then the argument
> would become even simpler and much more convincing.

It is possible that Apple will include the current versions of PyObjC, 
wxPython, and/or appscript with Tiger, but I wouldn't count on it and 
it still won't solve the problem on Jaguar or Panther. There isn't a 
whole lot of difference between installing PyObjC and wxPython from a 
user standpoint, they both are distributed as disk images and get 
installed by double-clicking a package file. Of course, you could use 
the PackageManager as well, but that has other problems. AFAIK, 
appscript is orthogonal to the issue of whether you do the GUI via 
wxPython or PyObjC even if that GUI is a linear series of steps and 
only uses dialogs for input. For scripting other applications appscript 
certainly seems easier to use than PyObjC from the examples I've seen 
and used myself. So, I think you're going to want to install two 
packages, but neither are hard to do and it will work on different 
versions of Mac OS X.

ka

From bob at redivi.com  Sat Oct  2 09:05:28 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 09:06:06 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
Message-ID: <710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>


On Oct 2, 2004, at 2:51 AM, Kevin Altis wrote:

> On Oct 1, 2004, at 10:54 PM, Nathaniel Gray wrote:
>
>> I actually meant dependencies for the casual scripter, not the
>> end-user.  I'd love to be able to tell my friends, "Python makes an
>> elegant replacement for AppleScript for your simple scripting tasks
>> and you only need to install 1 package to make it work."  If
>> EasyDialogs was just a little better it would already be true! :-)
>> If/when appscript and/or PyObjC get into the core then the argument
>> would become even simpler and much more convincing.
>
> It is possible that Apple will include the current versions of PyObjC, 
> wxPython, and/or appscript with Tiger, but I wouldn't count on it and 
> it still won't solve the problem on Jaguar or Panther. There isn't a 
> whole lot of difference between installing PyObjC and wxPython from a 
> user standpoint, they both are distributed as disk images and get 
> installed by double-clicking a package file. Of course, you could use 
> the PackageManager as well, but that has other problems. AFAIK, 
> appscript is orthogonal to the issue of whether you do the GUI via 
> wxPython or PyObjC even if that GUI is a linear series of steps and 
> only uses dialogs for input. For scripting other applications 
> appscript certainly seems easier to use than PyObjC from the examples 
> I've seen and used myself. So, I think you're going to want to install 
> two packages, but neither are hard to do and it will work on different 
> versions of Mac OS X.

What PyObjC examples are you thinking of that demonstrate scripting of 
other applications?  If any exist, they certainly aren't using any 
written-in-Objective-C facilities to script other applications.  AppKit 
really doesn't have any features that will let you script other 
applications (though it does have features that help you develop a 
scriptable application).  The Python standard library ways of doing 
Apple Events are ancient and cumbersome, so of course anything using 
appscript is going to look a heck of a lot better (it's a wrapper on 
top of them), but none of them depend on PyObjC.

It is possible to write a GUI that is a linear series of steps using 
only dialogs for input with purely Apple Events (and therefore possible 
using only appscript).  I'm not sure it would be particularly great, 
but that's what AppleScripters have done for quite some time.

-bob
From whamoo at rknet.it  Sat Oct  2 09:14:44 2004
From: whamoo at rknet.it (whamoo)
Date: Sat Oct  2 09:14:09 2004
Subject: [Pythonmac-SIG] =?iso-8859-1?q?Pyobjc_some_help_please_=28standa?=
 =?iso-8859-1?q?lone_application_with_xcode=29_=A0?=
In-Reply-To: <710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
	<710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>
Message-ID: <BCC0DB4A-1442-11D9-803A-000A95C62238@rknet.it>

Hi to all,

I'm doing some program with pyobjc, and i like it a lot...
I've installed the 1.1, so xcode gave me some template to create
program, ok, very nice, using interface builder, using xcode to write
the code, all is working nice, i build application and the .app
work...
But... There is a way to tell xcode that i want a standalone
application, with pyobjc and other lib, so i can share my program to
my little non-programmer friends? ;-)

Thanks a lot for who respond me (maybe i offer a pizza)

ps: python2.3, panther 10.3.5, xcode 1.1

Matteo Rattotti

Whamoo www.rknet.it
Powered by:
- MacOsX
- Gnu / Linux Debian Sarge
- Amiga Os 3.9
- Milk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 746 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041002/efe664e8/attachment.bin
From n8gray at gmail.com  Sat Oct  2 11:51:59 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sat Oct  2 11:52:11 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <60AB8BF0-143C-11D9-AFE1-000A95686CD8@redivi.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<60AB8BF0-143C-11D9-AFE1-000A95686CD8@redivi.com>
Message-ID: <aee06c9e04100202515dee5289@mail.gmail.com>

On Sat, 2 Oct 2004 02:29:13 -0400, Bob Ippolito <bob@redivi.com> wrote:
> On Oct 2, 2004, at 1:54 AM, Nathaniel Gray wrote:
> >
> > Would a simple C program that did the same thing work?  It's pretty
> > bad that a python interpreter can't work in a #! line.  If it can be
> > made to work without too much pain I'd suggest it ought to be done,
> > for the sake of consistency.
> 
> Yes it can be done in C.  It *might* make Python 2.4 if somebody
> submits a patch right away.  I'm not volunteering, though :)

You got it:
http://sourceforge.net/tracker/index.php?func=detail&aid=1038911&group_id=5470&atid=305470

> > Thanks for the references.  I'll check them out, but I don't really
> > want to write GUI applications, I want to write scripts that can do
> > elementary dialog-based user interaction.  AFAICT there's not much
> > other than the #! issue standing in the way.
> 
> Any application that uses the GUI is a GUI application, period.

Maybe, but a script is not necessarily an application.  I'm talking
about linear scripts that just need to ask the user a question or two,
not event-driven applications.  Script UI requirements are quite
minimal.

> >> You could emulate EasyDialogs with PyObjC, which is pretty
> >> lightweight.
> >>   You could also probably convince appscript to do all your dialogs in
> >> the same way that Applescript does.
> >
> > These are probably the most promising routes.  Really, I asked the
> > question hoping somebody had done something with PyObjC or appscript
> > already and I could use their code.
> >
> > BTW, is there any intention to get PyObjC included in the standard
> > Python distro?  It would be nice if EasyDialogs could be updated to OS
> > X standards.
> 
> Neither PyObjC or appscript are ready to become part of the standard
> Python distribution.  They definitely won't make 2.4, so that makes 2.5
> the earliest possible opportunity for inclusion into Python.  Who knows
> when that will be.

Ok.

> >> Using py2app (or to a lesser extent, bundlebuilder) makes applications
> >> that have no dependencies anyway, so that part of your argument
> >> doesn't
> >> really hold much water.  Using wxPython would make for relatively
> >> large
> >> standalone applications, but standalone applications nonetheless.
> >
> > I actually meant dependencies for the casual scripter, not the
> > end-user.  I'd love to be able to tell my friends, "Python makes an
> > elegant replacement for AppleScript for your simple scripting tasks
> > and you only need to install 1 package to make it work."  If
> > EasyDialogs was just a little better it would already be true! :-)
> > If/when appscript and/or PyObjC get into the core then the argument
> > would become even simpler and much more convincing.
> 
> I'd say that it's more likely that PyObjC and/or appscript would be
> picked up by Apple for a future release of Mac OS X before the PSF
> picks them up for inclusion into Python.  Particularly PyObjC, because
> Apple already ships ObjC bridges for Perl and Java.

That would be great.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From n8gray at gmail.com  Sat Oct  2 12:06:52 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sat Oct  2 12:06:55 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
Message-ID: <aee06c9e041002030632becd9@mail.gmail.com>

On Fri, 1 Oct 2004 23:51:57 -0700, Kevin Altis <altis@semi-retired.com> wrote:
> 
> It is possible that Apple will include the current versions of PyObjC,
> wxPython, and/or appscript with Tiger, but I wouldn't count on it and
> it still won't solve the problem on Jaguar or Panther. 

Bah.  Let them eat cake.  ;^)  Seriously, I'm just trying to figure
out if things are moving in the right direction, and if so, on what
time scale.

> There isn't a
> whole lot of difference between installing PyObjC and wxPython from a
> user standpoint, they both are distributed as disk images and get
> installed by double-clicking a package file. 

You have a good point, but I don't know if dial-up users would agree. 
PyObjC is about 2.7M while wxPython is about 18.6M.

> Of course, you could use
> the PackageManager as well, but that has other problems. AFAIK,
> appscript is orthogonal to the issue of whether you do the GUI via
> wxPython or PyObjC even if that GUI is a linear series of steps and
> only uses dialogs for input. For scripting other applications appscript
> certainly seems easier to use than PyObjC from the examples I've seen
> and used myself. So, I think you're going to want to install two
> packages, but neither are hard to do and it will work on different
> versions of Mac OS X.

Well, since nobody has used the time machine to solve my problem
before I asked it, I'll probably investigate the idea of using
appscript to exploit AppleScript's dialog capabilities.

Thanks,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From jhrsn at pitt.edu  Sat Oct  2 13:58:57 2004
From: jhrsn at pitt.edu (Jim Harrison)
Date: Sat Oct  2 13:58:05 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <aee06c9e041001125164940792@mail.gmail.com>
Message-ID: <BD841041.396C3%jhrsn@pitt.edu>

on 10/1/04 3:51 PM, Nathaniel Gray at n8gray@gmail.com wrote:

> Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
> perfect but the 255 character limit on the message length is *way* too
> short.  It's also annoying that the resulting dialogs are not keyboard
> navigable, but that's less important of an issue.  Is there anything
> similar that allows larger messages?

You might have a look at EasyGUI:

http://www.ferg.org/easygui/index.html

In supports basic alerts and button responses, file opening and save
dialogs, a simple data entry form dialog, clickable list dialogs and a
couple of scrolling text field dialogs for long messages or editing. It's
based on Tkinter, so should work everywhere. At least some of the dialogs
support keyboard navigation.

Jim Harrison
Univ. of Pittsburgh
From mlpollard at earthlink.net  Sat Oct  2 04:02:21 2004
From: mlpollard at earthlink.net (Tom Pollard)
Date: Sat Oct  2 14:50:46 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
Message-ID: <189BA312-1417-11D9-982F-000A959B24A6@earthlink.net>


On Oct 1, 2004, at 9:50 PM, Bob Ippolito wrote:
> You shouldn't really be using bare scripts as GUI applications in the 
> first place.

Why do say that?

Tom

From enrike at altern.org  Sat Oct  2 15:31:54 2004
From: enrike at altern.org (altern)
Date: Sat Oct  2 15:33:32 2004
Subject: [Pythonmac-SIG] compiling pyopengl + numeric
In-Reply-To: <415D9842.5090301@noaa.gov>
References: <BD81CEAE.39573%jhrsn@pitt.edu>
	<415D66E0.8070201@altern.org>	<415D865B.2010308@noaa.gov>
	<415D9842.5090301@noaa.gov>
Message-ID: <415EADCA.6010603@altern.org>

hi

>> Either:
>> A) install an lapack lib: this is the best option if you are doing 
>> linear algebra on large matrices
>> B) edit the setup.py to use the provided one. It should be commented 
>> well enough to do that
>> C) download Numeric 22, and use its setup.y to figure out what needs 
>> to change. You may well be able to simply use it with 23.
> 
> 
> oops, sorry, I'm on a lot of mailing lists, and I didn't notice that 
> this is the macpython list. On OS-X, you want to:
> 
> use PackageManager to get Numeric, preferably from Bob Ippolito's 
> repository, which will give you Numeric linked against Apple's lapack.

Ok, now its kind of working but I just realised that there was somthing 
else wrong. The funny thing is that if i go to the terminal and start 
python, then i can import for example wx (i installed it manually) but 
then if I try to import OpenGL or Numeric i get an error. Then i go and 
open Python interactive from the python IDE and i am able to import 
opengl and numeric with no errors at all.

in the terminal i get
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin

and in the IDE python interactive i get
Python 2.3.3 (#2, Dec 23 2003, 22:56:29)
[GCC 3.1 20020420 (prerelease)]

I actually tried to update manually the latest version of python for 
mac. Looks to me like i have two different versions installed and that 
the system is not very well informed about it!.

i am not sure what i am supposed to do about this. i remember having had 
a similar problem under linux but i dont remember what files i edited to 
solve the conflict. Any tips?

thanks!

-- 
enrike

From njriley at uiuc.edu  Sat Oct  2 17:42:30 2004
From: njriley at uiuc.edu (Nicholas Riley)
Date: Sat Oct  2 17:43:48 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <189BA312-1417-11D9-982F-000A959B24A6@earthlink.net>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<189BA312-1417-11D9-982F-000A959B24A6@earthlink.net>
Message-ID: <20041002154229.GA3492@uiuc.edu>

On Fri, Oct 01, 2004 at 10:02:21PM -0400, Tom Pollard wrote:
> 
> On Oct 1, 2004, at 9:50 PM, Bob Ippolito wrote:
> >You shouldn't really be using bare scripts as GUI applications in the 
> >first place.
> 
> Why do say that?

OS X doesn't know how to deal with such things, in general.  GUI
(Carbon/Cocoa) applications should be applications, or at least
packaged as such, otherwise a lot of stuff breaks.  For example, an
app needs an icon and a name in the dock, and in the menu bar; what if
someone chooses "Show in Finder"?  What kind of documents could the
script open?

None of these items can be synthesized without either Info.plist or
resource ('BNDL'/owner/'plst') based.  py2app is very simple to use,
and can produce small, self-contained script applications.  Or if you
just want a one-off thing for your own use, try pythonw, but realize
it's getting all this information from Python.app.

This is really no different from AppleScript - scripts must be saved
as applets before they can be double-clicked.  Otherwise, scripts
typically run in another application's context, for example that of
the Script Editor.  AppleScript explicitly prohibits use of the GUI
from the command line:

% osascript -e 'display dialog "foo"'
0:20: execution error: No user interaction allowed. (-1713)

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
From jerry.levan at eku.edu  Sat Oct  2 21:06:56 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Sat Oct  2 21:07:00 2004
Subject: [Pythonmac-SIG] TCL is going to have loadable TK...
In-Reply-To: <20041002070606.63C311E4006@bag.python.org>
References: <20041002070606.63C311E4006@bag.python.org>
Message-ID: <3AEA45E0-14A6-11D9-9145-000393779D9C@eku.edu>

This recently appeared on the Mac-TCL list....
so maybe python could do something similar...

Jerry

> The main project change is addition of a pkgIndex.tcl script in 
> Tk.framework/Resources/Scripts, which enables [package require Tk].
>
> I've also added code to TkpInit() that checks if we are loaded into a 
> bundled executable; and if not, attempts to dynamically acquire the 
> undocumented CPSEnableForegroundOperation SPI and use it to notify the 
> window server that we are now a full GUI application (this will not 
> break if that SPI ever disappears or changes its name).
> Even though we've previously discussed and rejected using CPS SPI, 
> I've lost my scruples on this after talking to the LaunchServices 
> engineers at WWDC (who said to go ahead and use the same workaround 
> that JAR launcher, SDL, wxPython etc all already use, it's not likely 
> to go away at this point and an official solution is not in the 
> pipeline). Just google for CPSEnableForegroundOperation to see how 
> widespread use of this SPI is... In any case, this code can be 
> disabled via #define if desired.
> Of course it's still much preferred to use a bundled executable, as 
> you cannot get a dock icon, document bindings, a bundle id, etc 
> otherwise, also the aete resource for Wish is not available to an 
> unbundled executable (i.e. app cannot be targeted via AppleScript)
>
> With all this, [package require Tk] now works from tclsh wrapped as a 
> bundled executable, and also unbundled if the above code is enabled.
>
> In particular, this also allows the Tcl::Tk perl module to properly 
> load TkAqua:
> 	http://search.cpan.org/~vkon/Tcl/
> 	http://search.cpan.org/~vkon/Tcl-Tk/
> get release 0.84 which has my changes to build the Tcl module against 
> Tcl.framework; and configure the Tcl module with
> 	perl Makefile.PL --tclconfig 
> /Library/Frameworks/Tcl.framework/tclConfig.sh --usestubs 
> INSTALLSITEMAN3DIR=/usr/local/man/man3
> and the Tcl::Tk module with
> 	perl Makefile.PL INSTALLSITEMAN3DIR=/usr/local/man/man3
> both modules should pass all their 'make test's...
>
> Jim, could you review this for checkin?
>
> Cheers,
>
> Daniel

From hengist.podd at virgin.net  Sat Oct  2 20:51:20 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct  2 21:20:44 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
Message-ID: <a05200f3bbd844b68b362@[81.103.144.218]>

Kevin Altis wrote:

>>I actually meant dependencies for the casual scripter, not the
>>end-user.  I'd love to be able to tell my friends, "Python makes an
>>elegant replacement for AppleScript for your simple scripting tasks
>>and you only need to install 1 package to make it work."  If
>>EasyDialogs was just a little better it would already be true! :-)
>>If/when appscript and/or PyObjC get into the core then the argument
>>would become even simpler and much more convincing.
>
>It is possible that Apple will include the current versions of 
>PyObjC, wxPython, and/or appscript with Tiger, but I wouldn't count 
>on it and it still won't solve the problem on Jaguar or Panther. 
>There isn't a whole lot of difference between installing PyObjC and 
>wxPython from a user standpoint, they both are distributed as disk 
>images and get installed by double-clicking a package file. Of 
>course, you could use the PackageManager as well, but that has other 
>problems. AFAIK, appscript is orthogonal to the issue of whether you 
>do the GUI via wxPython or PyObjC even if that GUI is a linear 
>series of steps and only uses dialogs for input. For scripting other 
>applications appscript certainly seems easier to use than PyObjC 
>from the examples I've seen and used myself. So, I think you're 
>going to want to install two packages, but neither are hard to do 
>and it will work on different versions of Mac OS X.

As a tangent to your orthogonal, would it make sense if Apple's 
MacPython installation had its site-packages folder at, say, 
/Library/Python/site-packages, instead of deep inside the perennial 
no-go area that is /System?

Might also fit with something I remember Jack talking about some time 
back - maybe moving some of the Mac-specific modules out of the 
standard distribution and provided as a separate add-on package, 
allowing them to be dealt with as a separate ongoing concern rather 
than tied to the development cycle of MacPython.framework.

(Apologies in advance if this is a stupid question: I'm still stuck 
on 10.2.8 so haven't had a chance to deal with the vagaries of 
Panther MacPython firsthand.)

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Sat Oct  2 20:52:01 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct  2 21:20:47 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
	<710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>
Message-ID: <a05200f3abd844034133d@[81.103.144.218]>

Bob Ippolito wrote:

>It is possible to write a GUI that is a linear series of steps using 
>only dialogs for input with purely Apple Events (and therefore 
>possible using only appscript).  I'm not sure it would be 
>particularly great, but that's what AppleScripters have done for 
>quite some time.

AppleScript uses OSAXen (OSA eXtensions) for displaying simple 
dialogs atop a GUI application (by default, the app that called them, 
but can be any other). They actually work quite well simple graphical 
input/output in batch scripts, despite the OSAX system itself being a 
pretty cheesy procedural, C/Pascal-only, namespace-polluting bodge to 
compensate for the lack of extensibility in AppleScript, and never 
replaced by something better.

Appscript doesn't support osaxen - there's few that'd be of any use 
to MacPython users, so it's not really worth it. I've been wrapping 
the more useful ones; there's an unfinished, untested copy posted 
here:

http://freespace.virgin.net/hamish.sanderson/osax-0.1.0.tar.gz

Wouldn't be my preferred way of doing things, but maybe it'll fill a 
gap for now.

BTW, checked the OS 10.3 release notes today and the 255 character 
limit has finally been lifted on the 'display dialog' osax, so should 
do for the OP's purposes long as backwards compatibility with OS 10.2 
isn't needed.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From bob at redivi.com  Sat Oct  2 21:45:30 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 21:46:07 2004
Subject: [Pythonmac-SIG] TCL is going to have loadable TK...
In-Reply-To: <3AEA45E0-14A6-11D9-9145-000393779D9C@eku.edu>
References: <20041002070606.63C311E4006@bag.python.org>
	<3AEA45E0-14A6-11D9-9145-000393779D9C@eku.edu>
Message-ID: <9DFE7B94-14AB-11D9-AD64-000A95686CD8@redivi.com>

Hah!  Well, if everyone else is doing it, and the LaunchServices guys 
say it's ok.. then I suppose we could follow suit.

What do you think Jack, Just?  We could add it to the MacOS module.  
Perhaps an optional "force" parameter to MacOS.WMAvaialble()?

It's only fitting, given that I'm the one that unleashed this whole 
mess a couple years ago by reverse engineering the JAR launcher and 
publically disclosing CPSEnableForegroundOperation.  You can tell 
because I was lazy and didn't bother (at first) to determine exactly 
how many arguments that CPSEnableForeground has so you'll see that many 
people are still using this prototype:
CPSEnableForegroundOperation( ProcessSerialNumber *psn, UInt32 _arg2, 
UInt32 _arg3, UInt32 _arg4, UInt32 _arg5);

When I'm pretty sure that later on I looked into it and found that psn 
is the only necessary argument.

Note that it *is* possible to get the dock icon and some other things 
if you manage to rewrite argv[0] early enough to point inside a bundle 
(basically emulating pythonw), which should probably be possible, 
especially if my patch that removes the Foundation/CoreFoundation/etc. 
dependencies from Python.framework is taken..

-bob

On Oct 2, 2004, at 3:06 PM, Jerry LeVan wrote:

> This recently appeared on the Mac-TCL list....
> so maybe python could do something similar...
>
> Jerry
>
>> The main project change is addition of a pkgIndex.tcl script in 
>> Tk.framework/Resources/Scripts, which enables [package require Tk].
>>
>> I've also added code to TkpInit() that checks if we are loaded into a 
>> bundled executable; and if not, attempts to dynamically acquire the 
>> undocumented CPSEnableForegroundOperation SPI and use it to notify 
>> the window server that we are now a full GUI application (this will 
>> not break if that SPI ever disappears or changes its name).
>> Even though we've previously discussed and rejected using CPS SPI, 
>> I've lost my scruples on this after talking to the LaunchServices 
>> engineers at WWDC (who said to go ahead and use the same workaround 
>> that JAR launcher, SDL, wxPython etc all already use, it's not likely 
>> to go away at this point and an official solution is not in the 
>> pipeline). Just google for CPSEnableForegroundOperation to see how 
>> widespread use of this SPI is... In any case, this code can be 
>> disabled via #define if desired.
>> Of course it's still much preferred to use a bundled executable, as 
>> you cannot get a dock icon, document bindings, a bundle id, etc 
>> otherwise, also the aete resource for Wish is not available to an 
>> unbundled executable (i.e. app cannot be targeted via AppleScript)
>>
>> With all this, [package require Tk] now works from tclsh wrapped as a 
>> bundled executable, and also unbundled if the above code is enabled.
>>
>> In particular, this also allows the Tcl::Tk perl module to properly 
>> load TkAqua:
>> 	http://search.cpan.org/~vkon/Tcl/
>> 	http://search.cpan.org/~vkon/Tcl-Tk/
>> get release 0.84 which has my changes to build the Tcl module against 
>> Tcl.framework; and configure the Tcl module with
>> 	perl Makefile.PL --tclconfig 
>> /Library/Frameworks/Tcl.framework/tclConfig.sh --usestubs 
>> INSTALLSITEMAN3DIR=/usr/local/man/man3
>> and the Tcl::Tk module with
>> 	perl Makefile.PL INSTALLSITEMAN3DIR=/usr/local/man/man3
>> both modules should pass all their 'make test's...
>>
>> Jim, could you review this for checkin?
>>
>> Cheers,
>>
>> Daniel
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
From bob at redivi.com  Sat Oct  2 21:49:22 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 21:50:01 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <a05200f3bbd844b68b362@[81.103.144.218]>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
	<a05200f3bbd844b68b362@[81.103.144.218]>
Message-ID: <27F6DB4B-14AC-11D9-AD64-000A95686CD8@redivi.com>


On Oct 2, 2004, at 2:51 PM, has wrote:

> Kevin Altis wrote:
>
>>> I actually meant dependencies for the casual scripter, not the
>>> end-user.  I'd love to be able to tell my friends, "Python makes an
>>> elegant replacement for AppleScript for your simple scripting tasks
>>> and you only need to install 1 package to make it work."  If
>>> EasyDialogs was just a little better it would already be true! :-)
>>> If/when appscript and/or PyObjC get into the core then the argument
>>> would become even simpler and much more convincing.
>>
>> It is possible that Apple will include the current versions of 
>> PyObjC, wxPython, and/or appscript with Tiger, but I wouldn't count 
>> on it and it still won't solve the problem on Jaguar or Panther. 
>> There isn't a whole lot of difference between installing PyObjC and 
>> wxPython from a user standpoint, they both are distributed as disk 
>> images and get installed by double-clicking a package file. Of 
>> course, you could use the PackageManager as well, but that has other 
>> problems. AFAIK, appscript is orthogonal to the issue of whether you 
>> do the GUI via wxPython or PyObjC even if that GUI is a linear series 
>> of steps and only uses dialogs for input. For scripting other 
>> applications appscript certainly seems easier to use than PyObjC from 
>> the examples I've seen and used myself. So, I think you're going to 
>> want to install two packages, but neither are hard to do and it will 
>> work on different versions of Mac OS X.
>
> As a tangent to your orthogonal, would it make sense if Apple's 
> MacPython installation had its site-packages folder at, say, 
> /Library/Python/site-packages, instead of deep inside the perennial 
> no-go area that is /System?

It does.. essentially.  /System/.../site-packages is a symlink to 
/Library/Python/2.3.  The sys.path points to 
/System/..../site-packages, so that's what most people see (in 
tracebacks, etc.).

> Might also fit with something I remember Jack talking about some time 
> back - maybe moving some of the Mac-specific modules out of the 
> standard distribution and provided as a separate add-on package, 
> allowing them to be dealt with as a separate ongoing concern rather 
> than tied to the development cycle of MacPython.framework.

This is what the win32all / py2exe projects do.  I'm not against it, 
but Apple might not end up including these "optional" modules in OS 
releases.  I'm not really sure if this is better or worse than the 
current situation.

-bob
From bob at redivi.com  Sat Oct  2 21:51:09 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 21:51:45 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <a05200f3abd844034133d@[81.103.144.218]>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
	<710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>
	<a05200f3abd844034133d@[81.103.144.218]>
Message-ID: <68284328-14AC-11D9-AD64-000A95686CD8@redivi.com>

On Oct 2, 2004, at 2:52 PM, has wrote:

> Bob Ippolito wrote:
>
>> It is possible to write a GUI that is a linear series of steps using 
>> only dialogs for input with purely Apple Events (and therefore 
>> possible using only appscript).  I'm not sure it would be 
>> particularly great, but that's what AppleScripters have done for 
>> quite some time.
>
> AppleScript uses OSAXen (OSA eXtensions) for displaying simple dialogs 
> atop a GUI application (by default, the app that called them, but can 
> be any other). They actually work quite well simple graphical 
> input/output in batch scripts, despite the OSAX system itself being a 
> pretty cheesy procedural, C/Pascal-only, namespace-polluting bodge to 
> compensate for the lack of extensibility in AppleScript, and never 
> replaced by something better.
>
> Appscript doesn't support osaxen - there's few that'd be of any use to 
> MacPython users, so it's not really worth it. I've been wrapping the 
> more useful ones; there's an unfinished, untested copy posted here:
>
> http://freespace.virgin.net/hamish.sanderson/osax-0.1.0.tar.gz
>
> Wouldn't be my preferred way of doing things, but maybe it'll fill a 
> gap for now.

What I was saying is that it's technically possible, not that it is 
currently reasonable to do :)

-bob
From n8gray at gmail.com  Sat Oct  2 22:06:15 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sat Oct  2 22:06:18 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e04100202515dee5289@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<60AB8BF0-143C-11D9-AFE1-000A95686CD8@redivi.com>
	<aee06c9e04100202515dee5289@mail.gmail.com>
Message-ID: <aee06c9e041002130665f2989@mail.gmail.com>

On Sat, 2 Oct 2004 02:51:59 -0700, Nathaniel Gray <n8gray@gmail.com> wrote:
> On Sat, 2 Oct 2004 02:29:13 -0400, Bob Ippolito <bob@redivi.com> wrote:
> > Yes it can be done in C.  It *might* make Python 2.4 if somebody
> > submits a patch right away.  I'm not volunteering, though :)
> 
> You got it:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1038911&group_id=5470&atid=305470

Do I need to mention this on python-dev or is creating the patch on SF
sufficient for having somebody consider it for 2.4?

Thanks,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From bob at redivi.com  Sat Oct  2 22:36:04 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  2 22:36:42 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e041002130665f2989@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<60AB8BF0-143C-11D9-AFE1-000A95686CD8@redivi.com>
	<aee06c9e04100202515dee5289@mail.gmail.com>
	<aee06c9e041002130665f2989@mail.gmail.com>
Message-ID: <AE080A75-14B2-11D9-AD64-000A95686CD8@redivi.com>


On Oct 2, 2004, at 4:06 PM, Nathaniel Gray wrote:

> On Sat, 2 Oct 2004 02:51:59 -0700, Nathaniel Gray <n8gray@gmail.com>  
> wrote:
>> On Sat, 2 Oct 2004 02:29:13 -0400, Bob Ippolito <bob@redivi.com>  
>> wrote:
>>> Yes it can be done in C.  It *might* make Python 2.4 if somebody
>>> submits a patch right away.  I'm not volunteering, though :)
>>
>> You got it:
>> http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=1038911&group_id=5470&atid=305470
>
> Do I need to mention this on python-dev or is creating the patch on SF
> sufficient for having somebody consider it for 2.4?

This should be sufficient.. assign it to Jack Jansen if you can, he's  
probably the only one who could/would implement it... but chances are  
he will read this thread (when he has time).

-bob
From n8gray at gmail.com  Sun Oct  3 02:56:14 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sun Oct  3 02:56:17 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <a05200f3abd844034133d@81.103.144.218>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>
	<710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>
	<a05200f3abd844034133d@81.103.144.218>
Message-ID: <aee06c9e0410021756109b1945@mail.gmail.com>

On Sat, 2 Oct 2004 19:52:01 +0100, has <hengist.podd@virgin.net> wrote:
> AppleScript uses OSAXen (OSA eXtensions) for displaying simple
> dialogs atop a GUI application (by default, the app that called them,
> but can be any other). They actually work quite well simple graphical
> input/output in batch scripts, despite the OSAX system itself being a
> pretty cheesy procedural, C/Pascal-only, namespace-polluting bodge to
> compensate for the lack of extensibility in AppleScript, and never
> replaced by something better.
> 
> Appscript doesn't support osaxen - there's few that'd be of any use
> to MacPython users, so it's not really worth it. I've been wrapping
> the more useful ones; there's an unfinished, untested copy posted
> here:
> 
> http://freespace.virgin.net/hamish.sanderson/osax-0.1.0.tar.gz
> 
> Wouldn't be my preferred way of doing things, but maybe it'll fill a
> gap for now.

Hey, this looks perfect!  It basically has the same capabilities as EasyDialogs.

> BTW, checked the OS 10.3 release notes today and the 255 character
> limit has finally been lifted on the 'display dialog' osax, so should
> do for the OP's purposes long as backwards compatibility with OS 10.2
> isn't needed.

Interesting.  Too bad the EasyDialogs interface truncates strings at
the Python level, otherwise it might have already worked for me.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From just at letterror.com  Sun Oct  3 08:15:53 2004
From: just at letterror.com (Just van Rossum)
Date: Sun Oct  3 08:16:01 2004
Subject: [Pythonmac-SIG] TCL is going to have loadable TK...
In-Reply-To: <9DFE7B94-14AB-11D9-AD64-000A95686CD8@redivi.com>
Message-ID: <r01050400-1026-B11FA87F150311D9A81C003065D5E7E4@[10.0.0.23]>

Bob Ippolito wrote:

> What do you think Jack, Just?  We could add it to the MacOS module.  
> Perhaps an optional "force" parameter to MacOS.WMAvaialble()?

Or maybe a new function? I'm +1 on including the functionality, either
way.

Just
From bob at redivi.com  Sun Oct  3 10:23:14 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Oct  3 10:23:48 2004
Subject: [Pythonmac-SIG] TCL is going to have loadable TK...
In-Reply-To: <r01050400-1026-B11FA87F150311D9A81C003065D5E7E4@[10.0.0.23]>
References: <r01050400-1026-B11FA87F150311D9A81C003065D5E7E4@[10.0.0.23]>
Message-ID: <78762D97-1515-11D9-AFF0-000A95686CD8@redivi.com>


On Oct 3, 2004, at 2:15 AM, Just van Rossum wrote:

> Bob Ippolito wrote:
>
>> What do you think Jack, Just?  We could add it to the MacOS module.
>> Perhaps an optional "force" parameter to MacOS.WMAvaialble()?
>
> Or maybe a new function? I'm +1 on including the functionality, either
> way.

I'm ambivalent as to whether it should be a new function or not.  I 
suppose I'm obligated to write the patch either way since I unleashed 
the beast.. so whatever the popular opinion settles on, or a decree by 
Jack, wins.

-bob
From hengist.podd at virgin.net  Sun Oct  3 15:44:29 2004
From: hengist.podd at virgin.net (has)
Date: Sun Oct  3 16:06:18 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e0410021756109b1945@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>	
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>	
	<aee06c9e04100118061724ef9a@mail.gmail.com>	
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>	
	<aee06c9e04100122543713b8af@mail.gmail.com>	
	<8D605708-143F-11D9-A0B5-000A9598382A@semi-retired.com>	
	<710FD1B4-1441-11D9-AFE1-000A95686CD8@redivi.com>	
	<a05200f3abd844034133d@81.103.144.218>
	<aee06c9e0410021756109b1945@mail.gmail.com>
Message-ID: <a05200f3dbd85a523a862@[81.103.144.218]>

Nathaniel Gray wrote:

>  > http://freespace.virgin.net/hamish.sanderson/osax-0.1.0.tar.gz
>
>Hey, this looks perfect!  It basically has the same capabilities as 
>EasyDialogs.

Standard Additions' dialog commands lack one or two features found in 
ED, most notably the ability to do password input, so it's not a 
complete replacement for it. Anyway, while wrapping existing Apple 
osaxen gets you some nice, useful functionality virtually for free, 
it's an evolutionary dead-end and not a serious substitute for a 
proper, modern 'easydialogs' module. But I guess it'll do in a pinch 
until one comes along. :p

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From gandreas at gandreas.com  Sun Oct  3 16:56:06 2004
From: gandreas at gandreas.com (Glenn Andreas)
Date: Sun Oct  3 16:56:35 2004
Subject: [Pythonmac-SIG] ANN: PyOXIDE 0.7.0 - Cocoa based Python IDE
Message-ID: <p06002000bd85c1f6accf@[10.0.0.65]>

PyOXIDE 0.7.0 is now available for abuse.  There has been some major 
work rewriting internal file tracking/meta data handle to support 
some improvements in breakpoints - PyOXIDE now supports conditional 
breakpoints, tracepoints (will print out an expression and continue), 
"sound  points" (play a sound),  pause points (pauses in the debugger 
for a moment and continues), and the ability to disable specific 
breakpoints.  There has also been other debugger work done to improve 
external debugging (breakpoints work much better) and project 
debugging (still a few rough ends).

There are also a number of other improvements (such as an "imports" 
popup to quickly go to the imported file) and other such things (such 
as "find all" in a file).  This version will also try to run scripts 
with the current directory set to where the script lives (previously 
it just set up the search path to include that).


PyOXIDE 0.7.0 has only been tested with 10.3, but should work with 
10.2 (assuming it can find the python framework).  The sources are 
built using XCode 1.2 on 10.3.

PyOXIDE 0.7.0 is now available on my idisk (as PyOXIDE_0.7.0.dmg):

	from the pather finder, "connect to other public folder" and 
type in "gandreas"
or
	http://projects.gandreas.com/pyoxide/

or hopefully you should just be able to "check for update" from 
within PyOXIDE itself.

If you want to build from source, you'll need to get 
PyOXIDE_Src_0.7.0.dmg, and IDEKit_0.3.0.dmg (also built XCode 1.2 on 
10.3).  IDEKit_0.3.0.dmg  is found either on the idisk above or 
<http://projects.gandreas.com/idekit/>  PyOXIDE source is covered 
under a BSD-style license.  The IDEKit framework is covered under 
LGPL, so you can freely link it in other projects.


-- 
Glenn Andreas                      gandreas@gandreas.com
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know
From n8gray at gmail.com  Sun Oct  3 22:50:35 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Sun Oct  3 22:50:41 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <BD841041.396C3%jhrsn@pitt.edu>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<BD841041.396C3%jhrsn@pitt.edu>
Message-ID: <aee06c9e04100313501f3d9cf0@mail.gmail.com>

On Sat, 02 Oct 2004 07:58:57 -0400, Jim Harrison <jhrsn@pitt.edu> wrote:
> on 10/1/04 3:51 PM, Nathaniel Gray at n8gray@gmail.com wrote:
> 
> > Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
> > perfect but the 255 character limit on the message length is *way* too
> > short.  It's also annoying that the resulting dialogs are not keyboard
> > navigable, but that's less important of an issue.  Is there anything
> > similar that allows larger messages?
> 
> You might have a look at EasyGUI:
> 
> http://www.ferg.org/easygui/index.html
> 
> In supports basic alerts and button responses, file opening and save
> dialogs, a simple data entry form dialog, clickable list dialogs and a
> couple of scrolling text field dialogs for long messages or editing. It's
> based on Tkinter, so should work everywhere. At least some of the dialogs
> support keyboard navigation.

Thanks, I'll take a look.  Unfortunately, I don't think the OS X
system python ships with Tkinter.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From bob at redivi.com  Sun Oct  3 22:51:41 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Oct  3 22:52:19 2004
Subject: [Pythonmac-SIG] ANN: py2app 0.1
Message-ID: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com>

py2app is the bundlebuilder replacement we've all been waiting for.  It 
is implemented as a distutils command, similar to py2exe.

Even at this early stage, it's probably the most advanced python 
packaging utility out there with regard to dependency analysis.  It's 
at a "works for me and the two other people that have tried it" stage.  
It's not particularly documented, and I don't have time to document it 
today, but you should be able to get along given the examples.  Since 
it is very similar to py2exe in design, you can also borrow ideas from 
there.

If you have any issues with py2app, please let me know.  Provide source 
if possible.  I'm particularly interested in problematic packages which 
use import tricks or in-package data files such as PIL or pygame.  
These two are explicitly supported by the extensible "recipe" mechanism 
of py2app, but there are surely others.  I believe PEAK, ZConfig, 
Twisted, etc. may do one or both of these things.  Until a recipe is 
created for a particular problematic package, you may always just 
include it wholesale with the -p argument.

Download and related links are here:
http://undefined.org/python/#py2app

-bob
From bob at redivi.com  Sun Oct  3 23:02:27 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Oct  3 23:03:04 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <aee06c9e04100313501f3d9cf0@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<BD841041.396C3%jhrsn@pitt.edu>
	<aee06c9e04100313501f3d9cf0@mail.gmail.com>
Message-ID: <88856564-157F-11D9-9C5D-000A95686CD8@redivi.com>

On Oct 3, 2004, at 4:50 PM, Nathaniel Gray wrote:

> On Sat, 02 Oct 2004 07:58:57 -0400, Jim Harrison <jhrsn@pitt.edu> 
> wrote:
>> on 10/1/04 3:51 PM, Nathaniel Gray at n8gray@gmail.com wrote:
>>
>>> Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
>>> perfect but the 255 character limit on the message length is *way* 
>>> too
>>> short.  It's also annoying that the resulting dialogs are not 
>>> keyboard
>>> navigable, but that's less important of an issue.  Is there anything
>>> similar that allows larger messages?
>>
>> You might have a look at EasyGUI:
>>
>> http://www.ferg.org/easygui/index.html
>>
>> In supports basic alerts and button responses, file opening and save
>> dialogs, a simple data entry form dialog, clickable list dialogs and a
>> couple of scrolling text field dialogs for long messages or editing. 
>> It's
>> based on Tkinter, so should work everywhere. At least some of the 
>> dialogs
>> support keyboard navigation.
>
> Thanks, I'll take a look.  Unfortunately, I don't think the OS X
> system python ships with Tkinter.

No, it definitely does not... although I would say "fortunately", 
because TclTkAqua isn't something I'd like to see more applications 
using :)

You're definitely not going to find what you need in the standard 
library.  An EasyDialogs replacement built using PyObjC is probably the 
most extensible and lightweight solution to this problem.  If you write 
one, it could probably even go into the PyObjC distribution, which has 
a pretty high circulation and is probably the most likely Python 
package to make it into a future release of OS X.

-bob
From jordan at krushen.com  Sun Oct  3 23:51:37 2004
From: jordan at krushen.com (Jordan Krushen)
Date: Sun Oct  3 23:51:42 2004
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] Pyobjc some help please
	(standalone application	with xcode)
In-Reply-To: <C7BC11E3-12E4-11D9-B5A1-000D93AD379E@mac.com>
References: <541186a0409300040672c8183@mail.gmail.com>
	<C7BC11E3-12E4-11D9-B5A1-000D93AD379E@mac.com>
Message-ID: <666F7181-1586-11D9-998F-000A958E9340@krushen.com>

On 30-Sep-04, at 6:29 AM, Ronald Oussoren wrote:

> On 30-sep-04, at 9:40, Matteo Rattotti wrote:
>
>> But... There is a way to tell xcode that i want a standalone
>> application, with pyobjc and other lib, so i can share my program to
>> my little non-programmer friends? ;-)
>
> Hmm. The ProjectBuilder templates used to have a feature for that 
> (some special build option). I cannot find it in the Xcode templates.

I believe changing the build style from Development to Deployment is 
supposed to do that for the bridge, not sure about external modules.  
It's surely a good place to start :)

J.

From bob at redivi.com  Mon Oct  4 00:11:34 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct  4 00:12:09 2004
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] Pyobjc some help please
	(standalone application	with xcode)
In-Reply-To: <666F7181-1586-11D9-998F-000A958E9340@krushen.com>
References: <541186a0409300040672c8183@mail.gmail.com>
	<C7BC11E3-12E4-11D9-B5A1-000D93AD379E@mac.com>
	<666F7181-1586-11D9-998F-000A958E9340@krushen.com>
Message-ID: <2FFEAC0A-1589-11D9-9C5D-000A95686CD8@redivi.com>

On Oct 3, 2004, at 5:51 PM, Jordan Krushen wrote:

> On 30-Sep-04, at 6:29 AM, Ronald Oussoren wrote:
>
>> On 30-sep-04, at 9:40, Matteo Rattotti wrote:
>>
>>> But... There is a way to tell xcode that i want a standalone
>>> application, with pyobjc and other lib, so i can share my program to
>>> my little non-programmer friends? ;-)
>>
>> Hmm. The ProjectBuilder templates used to have a feature for that 
>> (some special build option). I cannot find it in the Xcode templates.
>
> I believe changing the build style from Development to Deployment is 
> supposed to do that for the bridge, not sure about external modules.  
> It's surely a good place to start :)

It's basically something that you need to do manually.  I make 
references to all of the packages, modules, etc. that I use and make 
sure they get copied into the .app.  If I need something 10.2 
compatible, it's even more difficult (stripping down the python 
framework, picking out the system modules that need to be included, 
etc.)  It's quite a pain, and it was my primary motivation (on top of 
bundlebuilder's huge flaws) for doing py2app.

You could also try using py2app instead of Xcode, which is altogether a 
more robust solution anyway.  Note that either way, building a 10.2 
compatible application requires building against a 10.2 compatible 
python and modules.  With py2app this is done by just starting it up 
with the 10.2 compatible Python.  I haven't tested 10.2 compatibility, 
but I know it works in theory because I've tested that py2app 
distinguishes between the system's Python 2.3 and my own installation 
of Python 2.4 :)

-bob
From Cameron at Phaseit.net  Mon Oct  4 01:09:08 2004
From: Cameron at Phaseit.net (Cameron Laird)
Date: Mon Oct  4 01:09:24 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <88856564-157F-11D9-9C5D-000A95686CD8@redivi.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<BD841041.396C3%jhrsn@pitt.edu>
	<aee06c9e04100313501f3d9cf0@mail.gmail.com>
	<88856564-157F-11D9-9C5D-000A95686CD8@redivi.com>
Message-ID: <20041003230908.GA19078@lairds.us>

On Sun, Oct 03, 2004 at 05:02:27PM -0400, Bob Ippolito wrote:
			.
			.
			.
> >Thanks, I'll take a look.  Unfortunately, I don't think the OS X
> >system python ships with Tkinter.
> 
> No, it definitely does not... although I would say "fortunately", 
> because TclTkAqua isn't something I'd like to see more applications 
> using :)
			.
			.
			.
This is one of the many cases where subtlety is lost on me.  I
*think* you favor Cocoa and PyObjC, and see TclTkAqua as only a
competitor to them--is that right?  I sure agree there's a lot
to like about PyObjC.
From bob at redivi.com  Mon Oct  4 02:48:09 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct  4 02:48:45 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <20041003230908.GA19078@lairds.us>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<BD841041.396C3%jhrsn@pitt.edu>
	<aee06c9e04100313501f3d9cf0@mail.gmail.com>
	<88856564-157F-11D9-9C5D-000A95686CD8@redivi.com>
	<20041003230908.GA19078@lairds.us>
Message-ID: <0FB4C0C4-159F-11D9-9C5D-000A95686CD8@redivi.com>


On Oct 3, 2004, at 7:09 PM, Cameron Laird wrote:

> On Sun, Oct 03, 2004 at 05:02:27PM -0400, Bob Ippolito wrote:
>>> Thanks, I'll take a look.  Unfortunately, I don't think the OS X
>>> system python ships with Tkinter.
>>
>> No, it definitely does not... although I would say "fortunately",
>> because TclTkAqua isn't something I'd like to see more applications
>> using :)
> 			.
> This is one of the many cases where subtlety is lost on me.  I
> *think* you favor Cocoa and PyObjC, and see TclTkAqua as only a
> competitor to them--is that right?  I sure agree there's a lot
> to like about PyObjC.

I don't like TclTkAqua because it produces ugly, buggy, and barely 
usable applications on OS X.  I have no real problem with Tk on other 
platforms, in fact I've used it willingly on Windows in a commercial 
product :)

-bob
From bob at redivi.com  Mon Oct  4 05:16:58 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct  4 05:17:33 2004
Subject: [Pythonmac-SIG] Re: [Distutils] ANN: py2app 0.1
In-Reply-To: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>
References: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>
Message-ID: <DA16EC16-15B3-11D9-BAB4-000A95686CD8@redivi.com>


On Oct 3, 2004, at 10:52 PM, Phillip J. Eby wrote:

> At 04:51 PM 10/3/04 -0400, Bob Ippolito wrote:
>> I believe PEAK, ZConfig, Twisted, etc. may do one or both of these 
>> things.
>
> PEAK definitely includes data files in package directories, and the 
> latest version of the distutils supports doing such installs directly. 
>  (PEAK uses setuptools, though, since its minimum Python version is 
> Python 2.2.2.)

py2app is using setuptools too, supporting a minimum Python version of 
2.3.0.  It was MUCH MUCH simpler than using distutils directly.  
Additionally I borrowed the sdist script from PyObjC that ignores 
subversion junk.

> I don't have a Mac, though, so I'll have to rely on your feedback 
> regarding PEAK's buildability with py2app.  There are a number of 
> potential issues:
>
> * Current versions of Python have a broken reload() function with 
> respect to PEP 302; PEAK uses 'reload()' to drive a "lazy import" 
> facility that also allows setting triggers to run when modules are 
> imported.
>
> * PEAK uses in-package data files, and expects them to be accessible 
> as regular files.  This means that even if reload() worked correctly, 
> it would break with e.g. putting the package in a zipfile.  I do plan 
> to make this PEP 302 compatible in the near future, by checking for a 
> __loader__ attribute with a 'get_data()' method, and using that 
> instead of direct filesystem access, if available.
>
> * PEAK uses dynamic and lazy imports extensively, which makes it 
> impossible to find all its imports using only bytecode analysis.  An 
> ability to specify modules or packages as part of a setup.py is a 
> must.

Yeah, I was pretty sure that this was the case.  You simply just 
specify that you want to include PEAK as a package (which includes the 
whole package as-is, outside of the zip file).  At some point I'll add 
a recipe that detects the presence of PEAK and makes this happen 
automatically, like I do for pygame, but I'm going to wait a bit until 
I hear about other packages so I can just do them all at once before 
the next release.

-bob
From bob at redivi.com  Mon Oct  4 06:36:34 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct  4 06:37:11 2004
Subject: [Pythonmac-SIG] Re: [Distutils] ANN: py2app 0.1
In-Reply-To: <5.1.1.6.0.20041003234922.03412d90@mail.telecommunity.com>
References: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>
	<5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>
	<5.1.1.6.0.20041003234922.03412d90@mail.telecommunity.com>
Message-ID: <F895D491-15BE-11D9-9846-000A95686CD8@redivi.com>


On Oct 3, 2004, at 11:51 PM, Phillip J. Eby wrote:

> At 11:16 PM 10/3/04 -0400, Bob Ippolito wrote:
>> py2app is using setuptools too, supporting a minimum Python version 
>> of 2.3.0.  It was MUCH MUCH simpler than using distutils directly.
>
> Nice to know.  What parts of setuptools did you end up using?  
> "Features", "dependencies", or just the data file stuff?

Well, it's open source, you can look for yourself :)

http://svn.red-bean.com/bob/py2app/trunk/setup.py

I'm using find_packages, the package_data stuff.. maybe other stuff 
implicitly?  I didn't read the source or documentation for setuptools, 
I just cut+pasted from PEAK's setup.py.  I went to PEAK first because I 
knew it dealt with installing multiple top level packages with data 
files and such, and I knew these things were terribly difficult with 
stock distutils.  "Features" will probably be useful to me in the 
future, but it's not something I needed for this.

-bob
From ronaldoussoren at mac.com  Mon Oct  4 07:31:07 2004
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon Oct  4 07:32:31 2004
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] Pyobjc some help please
	(standalone application	with xcode)
In-Reply-To: <2FFEAC0A-1589-11D9-9C5D-000A95686CD8@redivi.com>
References: <541186a0409300040672c8183@mail.gmail.com>
	<C7BC11E3-12E4-11D9-B5A1-000D93AD379E@mac.com>
	<666F7181-1586-11D9-998F-000A958E9340@krushen.com>
	<2FFEAC0A-1589-11D9-9C5D-000A95686CD8@redivi.com>
Message-ID: <97CCA7D8-15C6-11D9-8D57-000A95C77748@mac.com>


On 4-okt-04, at 0:11, Bob Ippolito wrote:
>
>
> You could also try using py2app instead of Xcode, which is altogether 
> a more robust solution anyway.

Would it be possible and useful to have Xcode templates that use py2app 
to create the application? I don't like haveing three different 
"official" methods for building an application.

Ronald

From bob at redivi.com  Mon Oct  4 07:43:42 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct  4 07:44:19 2004
Subject: [Pyobjc-dev] Re: [Pythonmac-SIG] Pyobjc some help please
	(standalone application	with xcode)
In-Reply-To: <97CCA7D8-15C6-11D9-8D57-000A95C77748@mac.com>
References: <541186a0409300040672c8183@mail.gmail.com>
	<C7BC11E3-12E4-11D9-B5A1-000D93AD379E@mac.com>
	<666F7181-1586-11D9-998F-000A958E9340@krushen.com>
	<2FFEAC0A-1589-11D9-9C5D-000A95686CD8@redivi.com>
	<97CCA7D8-15C6-11D9-8D57-000A95C77748@mac.com>
Message-ID: <5956F930-15C8-11D9-9846-000A95686CD8@redivi.com>

On Oct 4, 2004, at 1:31 AM, Ronald Oussoren wrote:

> On 4-okt-04, at 0:11, Bob Ippolito wrote:
>>
>>
>> You could also try using py2app instead of Xcode, which is altogether 
>> a more robust solution anyway.
>
> Would it be possible and useful to have Xcode templates that use 
> py2app to create the application? I don't like haveing three different 
> "official" methods for building an application.

It should be possible and useful (for deployment, anyway).  The 
templates aren't really very good at producing things that can be 
easily deployed.

Bundlebuilder should be completely deprecated once we have a way to 
build plugins with py2app.  There will still only be two ways, unless 
Project Builder is officially supported and counted separately.

-bob
From pje at telecommunity.com  Mon Oct  4 04:52:08 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Oct  4 09:35:06 2004
Subject: [Pythonmac-SIG] Re: [Distutils] ANN: py2app 0.1
In-Reply-To: <074B39A6-157E-11D9-9C5D-000A95686CD8@redivi.com>
Message-ID: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>

At 04:51 PM 10/3/04 -0400, Bob Ippolito wrote:
>I believe PEAK, ZConfig, Twisted, etc. may do one or both of these things.

PEAK definitely includes data files in package directories, and the latest 
version of the distutils supports doing such installs directly.  (PEAK uses 
setuptools, though, since its minimum Python version is Python 2.2.2.)

I don't have a Mac, though, so I'll have to rely on your feedback regarding 
PEAK's buildability with py2app.  There are a number of potential issues:

* Current versions of Python have a broken reload() function with respect 
to PEP 302; PEAK uses 'reload()' to drive a "lazy import" facility that 
also allows setting triggers to run when modules are imported.

* PEAK uses in-package data files, and expects them to be accessible as 
regular files.  This means that even if reload() worked correctly, it would 
break with e.g. putting the package in a zipfile.  I do plan to make this 
PEP 302 compatible in the near future, by checking for a __loader__ 
attribute with a 'get_data()' method, and using that instead of direct 
filesystem access, if available.

* PEAK uses dynamic and lazy imports extensively, which makes it impossible 
to find all its imports using only bytecode analysis.  An ability to 
specify modules or packages as part of a setup.py is a must.

From pje at telecommunity.com  Mon Oct  4 05:51:33 2004
From: pje at telecommunity.com (Phillip J. Eby)
Date: Mon Oct  4 09:35:07 2004
Subject: [Pythonmac-SIG] Re: [Distutils] ANN: py2app 0.1
In-Reply-To: <DA16EC16-15B3-11D9-BAB4-000A95686CD8@redivi.com>
References: <5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>
	<5.1.1.6.0.20041003224544.02456eb0@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20041003234922.03412d90@mail.telecommunity.com>

At 11:16 PM 10/3/04 -0400, Bob Ippolito wrote:
>py2app is using setuptools too, supporting a minimum Python version of 
>2.3.0.  It was MUCH MUCH simpler than using distutils directly.

Nice to know.  What parts of setuptools did you end up using?  "Features", 
"dependencies", or just the data file stuff?

From s.lach at wanadoo.nl  Mon Oct  4 11:00:00 2004
From: s.lach at wanadoo.nl (Juan Sebasti=?ISO-8859-1?B?4Q==?=n Lach)
Date: Mon Oct  4 11:23:12 2004
Subject: [Pythonmac-SIG] Speech
Message-ID: <BD86DDB0.2718%s.lach@wanadoo.nl>

Hi

> Hum... dunno why that code didn't work, but if you wanna give the new
> osax package a shot and let us know if it works for you that'd be
> cool, eg:
> 
> import osax
> osax.say('hello world')


I'll give it a try later, thanx

js

From unistein at gmx.ch  Mon Oct  4 12:08:50 2004
From: unistein at gmx.ch (Peter Steiner)
Date: Mon Oct  4 12:09:24 2004
Subject: [Pythonmac-SIG] How can I include command line arguments in bundled
	apps?
Message-ID: <634F8913-15ED-11D9-80B8-000A956A6750@gmx.ch>

Hello

I wish to tweak IDLE.app from MacPython 2.3 for Panther addons to call  
IDLE with the -Qnew switch.

According to Gregor Lingl in  
http://mail.python.org/pipermail/edu-sig/2003-September/003150.html the  
-Qnew switch alone is not enough; -n is needed too.

I tried editing IDLE.app/Contents/MacOS/IDLE adding the switches with

sys.argv.insert(1, "-n")
sys.argv.insert(0, "-Qnew")

just after

sys.argv.insert(1, mainprogram)

but then the bundle wouldn't start anymore.

It works however if I start IDLE from the terminal:

$ pythonw -Qnew  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
idlelib/idle.py -n

Is it possible to achieve this with a bundle?

Regards, Peter
-- 
Peter Steiner <unistein@gmx.ch>         PGP-ID 0x02850F53 (DH/DSS)
PGP Fingerprint 68AB D08E D995 41B4 C6FD  639D 9B94 D249 0285 0F53

From Jack.Jansen at cwi.nl  Mon Oct  4 16:02:09 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Mon Oct  4 16:03:35 2004
Subject: [Pythonmac-SIG] How can I include command line arguments in
	bundled apps?
In-Reply-To: <634F8913-15ED-11D9-80B8-000A956A6750@gmx.ch>
References: <634F8913-15ED-11D9-80B8-000A956A6750@gmx.ch>
Message-ID: <FB8D423A-160D-11D9-B331-000A958D1666@cwi.nl>


On 4-okt-04, at 12:08, Peter Steiner wrote:

> Hello
>
> I wish to tweak IDLE.app from MacPython 2.3 for Panther addons to call 
> IDLE with the -Qnew switch.
>
> According to Gregor Lingl in 
> http://mail.python.org/pipermail/edu-sig/2003-September/003150.html 
> the -Qnew switch alone is not enough; -n is needed too.
>
> I tried editing IDLE.app/Contents/MacOS/IDLE adding the switches with
>
> sys.argv.insert(1, "-n")
> sys.argv.insert(0, "-Qnew")
>
> just after
>
> sys.argv.insert(1, mainprogram)

> but then the bundle wouldn't start anymore.

I don't see why this wouldn't work. Cou you try running 
/Applications/MacPython-2.3/IDLE.app/Contents/MacOS/IDLE from the 
command line to see whether it produces any error output? And/or check 
the console window to see whether there's anything there...
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From unistein at gmx.ch  Mon Oct  4 16:45:38 2004
From: unistein at gmx.ch (Peter Steiner)
Date: Mon Oct  4 16:46:12 2004
Subject: [Pythonmac-SIG] How can I include command line arguments in
	bundled apps?
In-Reply-To: <FB8D423A-160D-11D9-B331-000A958D1666@cwi.nl>
References: <634F8913-15ED-11D9-80B8-000A956A6750@gmx.ch>
	<FB8D423A-160D-11D9-B331-000A958D1666@cwi.nl>
Message-ID: <0E8A0D8C-1614-11D9-80B8-000A956A6750@gmx.ch>

Am 04.10.2004 um 16:02 schrieb Jack Jansen:
>
> On 4-okt-04, at 12:08, Peter Steiner wrote:
>
>> I tried editing IDLE.app/Contents/MacOS/IDLE adding the switches with
>>
>> sys.argv.insert(1, "-n")
>> sys.argv.insert(0, "-Qnew")
>>
>> just after
>>
>> sys.argv.insert(1, mainprogram)
>
>> but then the bundle wouldn't start anymore.
>
> I don't see why this wouldn't work. Cou you try running 
> /Applications/MacPython-2.3/IDLE.app/Contents/MacOS/IDLE from the 
> command line to see whether it produces any error output? And/or check 
> the console window to see whether there's anything there...

I got sys.argv slightly wrong. With

sys.argv.insert(1, mainprogram)
sys.argv.insert(2, "-n")
sys.argv.insert(1, "-Qnew")

it works from the command line. Double-clicking in the Finder does not 
work; console.log has the following:

> Error: option -p not recognized
>
> USAGE: idle  [-deins] [-t title] [file]*
> ...(rest skipped)

Regards, Peter
-- 
Peter Steiner <unistein@gmx.ch>         PGP-ID 0x02850F53 (DH/DSS)
PGP Fingerprint 68AB D08E D995 41B4 C6FD  639D 9B94 D249 0285 0F53

From gandreas at gandreas.com  Mon Oct  4 16:53:29 2004
From: gandreas at gandreas.com (Glenn Andreas)
Date: Mon Oct  4 16:54:07 2004
Subject: [Pythonmac-SIG] How can I include command line arguments in 
	bundled apps?
In-Reply-To: <0E8A0D8C-1614-11D9-80B8-000A956A6750@gmx.ch>
References: <634F8913-15ED-11D9-80B8-000A956A6750@gmx.ch>
	<FB8D423A-160D-11D9-B331-000A958D1666@cwi.nl>
	<0E8A0D8C-1614-11D9-80B8-000A956A6750@gmx.ch>
Message-ID: <p06002002bd87140d4d32@[10.0.0.65]>

At 4:45 PM +0200 10/4/04, Peter Steiner wrote:
>  Double-clicking in the Finder does not work; console.log has the following:
>
>>Error: option -p not recognized
>>
>>USAGE: idle  [-deins] [-t title] [file]*
>>...(rest skipped)
>
>Regards, Peter

Anything doubleclicked from the Finder gets a "-psn" options in the 
command line (which specifies the process serial number, though it's 
unclear exactly what that is needed for)

-- 
Glenn Andreas                      gandreas@gandreas.com 
<http://www.gandreas.com/> oh my!
Mad, Bad, and Dangerous to Know
From unistein at gmx.ch  Mon Oct  4 17:19:02 2004
From: unistein at gmx.ch (Peter Steiner)
Date: Mon Oct  4 17:19:36 2004
Subject: [Pythonmac-SIG] How can I include command line arguments in
	bundled apps?
In-Reply-To: <p06002002bd87140d4d32@[10.0.0.65]>
References: <634F8913-15ED-11D9-80B8-000A956A6750@gmx.ch>
	<FB8D423A-160D-11D9-B331-000A958D1666@cwi.nl>
	<0E8A0D8C-1614-11D9-80B8-000A956A6750@gmx.ch>
	<p06002002bd87140d4d32@[10.0.0.65]>
Message-ID: <B9394658-1618-11D9-80B8-000A956A6750@gmx.ch>

Am 04.10.2004 um 16:53 schrieb Glenn Andreas:

> At 4:45 PM +0200 10/4/04, Peter Steiner wrote:
>>  Double-clicking in the Finder does not work; console.log has the 
>> following:
>>
>>> Error: option -p not recognized
>>>
>>> USAGE: idle  [-deins] [-t title] [file]*
>>> ...(rest skipped)
>>
>> Regards, Peter
>
> Anything doubleclicked from the Finder gets a "-psn" options in the 
> command line (which specifies the process serial number, though it's 
> unclear exactly what that is needed for)

Apparently the __argvemulator_idle parameter takes care of the 
-psn_xxxxx option, but not if there are other options inbetween. 
Rearranging the sys.argv manipulation helped:

> sys.argv.insert(1, mainprogram)
> sys.argv.insert(1, "-Qnew")
> sys.argv.append("-n")

Short summary (correct me if I'm wrong)
- options for python itself should go to the front of sys.argv
- options for the invoked python program should go the the end of 
sys.argv
- inbetween argvemulator is doing some magic with Finder supplied 
arguments

Regards and thanks for the quick help!

Peter
-- 
Peter Steiner <unistein@gmx.ch>         PGP-ID 0x02850F53 (DH/DSS)
PGP Fingerprint 68AB D08E D995 41B4 C6FD  639D 9B94 D249 0285 0F53

From smithsm at samuelsmith.org  Mon Oct  4 22:04:52 2004
From: smithsm at samuelsmith.org (Samuel M.Smith)
Date: Mon Oct  4 22:04:58 2004
Subject: [Pythonmac-SIG] webkit cgi build and startupitems problems
In-Reply-To: <4152056D.1020909@noaa.gov>
References: <44296DA8-F31B-11D7-B2D5-000A9574DA40@cs.vu.nl>
	<6A871B24-0CE2-11D9-B0E7-000A95C4B360@samuelsmith.org>
	<4152056D.1020909@noaa.gov>
Message-ID: <A73F28EC-1640-11D9-8C18-000A95C4B360@samuelsmith.org>

> I'm pretty sure you need a new version of wkcommon.h, which you can  
> get from:
>
> http://cvs.sourceforge.net/viewcvs.py/webware/Webware/WebKit/Adapters/ 
> common/
>

that fixed it. Thanks,


>> Has anybody figured out how to have webkit appserver startup  
>> automatically in os x 10.3.5?
>
> sorry I haven't got that far yet!
>
Well I found a tutuorial online for making startupitems for os X
http://osxfaq.1dot1.com/Tutorials/LearningCenter/OSXTutorials/Startup/ 
index.ws

Based on that I came up with something that works


everthing has to be owned by root so either sudo or do it as root

make a directory in /library/startupitems
call it whatever you want
I called mine WebkitAppserver
make two files inside the directory WebkitAppserver
both must be owned by root
first file must be named the same as the directory in this case  
WebkitAppserver
it must have ugo+rx permissions

the second file must be named StartupParameters.plist
I am not sure what permissions it should have but ugo+rx works

put the following into the file WebkitAppserver. Put the path to where  
you have
Appserver stored in the two cd lines

#! /bin/sh

. /etc/rc.common

StartService ()
{
	ConsoleMessage "Starting Webkit Appserver"
	#change directory to where the Appserver lives
    	cd /users/webware/webware81/webkit
      ./Appserver >> /var/log/webkit 2>&1 &
}

StopService ()
{
    	ConsoleMessage "Stopping Webkit Appserver"
	#change directory to where the Appserver lives
  	cd /users/webware/webware81/webkit
    ./Appserver stop >> /var/log/webkit 2>&1
}

RestartService ()
{
    ConsoleMessage "Reloading Webkit Appserver"
    StopService;
    StartService;
}

RunService "$1"


Now put the following into the file
StartupParameters.plist

{
   Description   = "Webkit Appserver";
   Provides      = ("Webkit");
   Requires      = ("Resolver");
   Uses          = ("Network Time", "httpd");
   OrderPreference    = "Last";
   Messages =
   {
     start = "Starting Webkit Appserver";
     stop  = "Stopping Webkit Appserver";
     restart  = "Reloading Webkit Appserver";
   };
}


I don't know if it matters what is in the Uses line but Network Time  
was in another example and I thought
httpd should be there.

Anyway it works.

to test
->cd /library/startupitems/webkitappserver
->sudo webkitappserver start


From s.lach at wanadoo.nl  Tue Oct  5 01:58:08 2004
From: s.lach at wanadoo.nl (Juan Sebasti=?ISO-8859-1?B?4Q==?=n Lach)
Date: Tue Oct  5 01:58:09 2004
Subject: [Pythonmac-SIG] Speech...
Message-ID: <BD87B030.2737%s.lach@wanadoo.nl>

Hi, I installed osax again and now it works fine...


Thanx a lot

js

From bob at redivi.com  Tue Oct  5 08:00:10 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct  5 08:00:15 2004
Subject: [Pythonmac-SIG] TCL is going to have loadable TK...
In-Reply-To: <78762D97-1515-11D9-AFF0-000A95686CD8@redivi.com>
References: <r01050400-1026-B11FA87F150311D9A81C003065D5E7E4@[10.0.0.23]>
	<78762D97-1515-11D9-AFF0-000A95686CD8@redivi.com>
Message-ID: <D0D74C45-1693-11D9-BA78-000A95686CD8@redivi.com>

On Oct 3, 2004, at 4:23 AM, Bob Ippolito wrote:

> On Oct 3, 2004, at 2:15 AM, Just van Rossum wrote:
>
>> Bob Ippolito wrote:
>>
>>> What do you think Jack, Just?  We could add it to the MacOS module.
>>> Perhaps an optional "force" parameter to MacOS.WMAvaialble()?
>>
>> Or maybe a new function? I'm +1 on including the functionality, either
>> way.
>
> I'm ambivalent as to whether it should be a new function or not.  I 
> suppose I'm obligated to write the patch either way since I unleashed 
> the beast.. so whatever the popular opinion settles on, or a decree by 
> Jack, wins.

Maybe we don't need to add this to Python.. I am fine with requiring 
PyObjC.  PyObjC gives us a nice little FFI for anything that's in a 
bundle, so this can be done in pure python:

Here's an example of (ab)using the FFI to call into the CPS SPI:
http://svn.red-bean.com/pyobjc/trunk/pyobjc/Examples/wmEnable.py

[I have only tested this with Tiger DP.. someone else will have to 
confirm that it works on 10.3 and/or 10.2]

-bob
From lanceboyle at cwazy.co.uk  Tue Oct  5 10:33:07 2004
From: lanceboyle at cwazy.co.uk (Lance Boyle)
Date: Tue Oct  5 10:33:05 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <aee06c9e04100313501f3d9cf0@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<BD841041.396C3%jhrsn@pitt.edu>
	<aee06c9e04100313501f3d9cf0@mail.gmail.com>
Message-ID: <2EBC81BE-16A9-11D9-8161-003065F93FF0@cwazy.co.uk>


On Oct 3, 2004, at 1:50 PM, Nathaniel Gray wrote:

>> on 10/1/04 3:51 PM, Nathaniel Gray at n8gray@gmail.com wrote:
>>
>>> Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
>>> perfect but the 255 character limit on the message length is *way* 
>>> too
>>> short.  It's also annoying that the resulting dialogs are not 
>>> keyboard
>>> navigable, but that's less important of an issue.  Is there anything
>>> similar that allows larger messages?
>>>
I think this is what you're looking for. It's easy to use and creates 
Cocoa dialogs. Really. Check it out:

http://www.bluem.net/downloads/pashua_en/

The download includes a Python example.

FWIW, I wrote an Ada wrapper for it.

Jerry

From whamoo at rknet.it  Tue Oct  5 13:50:17 2004
From: whamoo at rknet.it (whamoo)
Date: Tue Oct  5 13:49:43 2004
Subject: [Pythonmac-SIG] Pyobjc and Panel?
Message-ID: <B9F5D875-16C4-11D9-8C03-000A95C62238@rknet.it>

Hi to all,

I have some problem to use the cocoa panel (NSOpenPanel, and 
NSSavePanel) using PyObjC...
I must import AppKit right? Then? Calling AppKit.NSOpenPanel() result 
to :"(TypeError: Use class methods to instantiate new Objective-C 
objects)",
So how to use the panel? (and it is normal that pydoc on AppKit take 1 
minute to open?)

Thanks a lot =)

Whamoo www.rknet.it
Powered by:
- MacOsX
- Gnu / Linux Debian Sarge
- Amiga Os 3.9
- Milk

From bob at redivi.com  Tue Oct  5 14:01:04 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct  5 14:01:08 2004
Subject: [Pythonmac-SIG] Pyobjc and Panel?
In-Reply-To: <B9F5D875-16C4-11D9-8C03-000A95C62238@rknet.it>
References: <B9F5D875-16C4-11D9-8C03-000A95C62238@rknet.it>
Message-ID: <3BF32A79-16C6-11D9-AA6E-000A95686CD8@redivi.com>


On Oct 5, 2004, at 7:50 AM, whamoo wrote:

> I have some problem to use the cocoa panel (NSOpenPanel, and  
> NSSavePanel) using PyObjC...
> I must import AppKit right? Then? Calling AppKit.NSOpenPanel() result  
> to :"(TypeError: Use class methods to instantiate new Objective-C  
> objects)",
> So how to use the panel? (and it is normal that pydoc on AppKit take 1  
> minute to open?)

Yes you must import AppKit to use AppKit functionality.  Yes it's  
normal for pydoc to be very slow for PyObjC modules.  You shouldn't be  
using pydoc, you should be using Apple's documentation.  There is very  
little useful information in the pydoc for AppKit, Foundation, etc.

You create an NSOpenPanel instance the same way you do in Objective C.

1) Read the documentation:
http://developer.apple.com/documentation/Cocoa/Reference/ 
ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html

2) Find the designated initializer in the documentation:
openPanel
+ (NSOpenPanel *)openPanel
Creates and returns a new NSOpenPanel object. The open panel has been  
initialized with default values.

3) Translate the Objective C in the documentation into PyObjC code:

from AppKit import *

# this isn't a full example, this code needs to be called during a  
runloop...
panel = NSOpenPanel.openPanel()
rval = panel.runModalForTypes_([u'py'])
print panel.filenames()


If this doesn't make sense to you, I suggest you read through some of  
the examples and all of the documentation for PyObjC.

-bob
From leknarf at pacbell.net  Tue Oct  5 23:26:27 2004
From: leknarf at pacbell.net (Scott Frankel)
Date: Tue Oct  5 23:26:31 2004
Subject: [Pythonmac-SIG] python include location
Message-ID: <3738A88A-1715-11D9-AE87-000A95A7B782@pacbell.net>


Apologies in advance for the ignorant question that follows.  I think 
my brain
stopped working.

Where is Python.h located?

I'm looking for the "path of the Python include (usually Python.h)"  so 
I can build
the PyGreSQL module for Python <--> PostgreSQL interactions.  I am 
using the
MacPython v2.3 release on OSX10.3.5.

Thanks
Scott

From Jack.Jansen at cwi.nl  Wed Oct  6 00:04:30 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Wed Oct  6 00:04:24 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs
In-Reply-To: <aee06c9e041001125164940792@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
Message-ID: <882F04F2-171A-11D9-83BB-000D934FF6B4@cwi.nl>


On 1 Oct 2004, at 21:51, Nathaniel Gray wrote:

> Also, I'd like a simple way to put up dialogs.  EasyDialogs would be
> perfect but the 255 character limit on the message length is *way* too
> short.  It's also annoying that the resulting dialogs are not keyboard
> navigable, but that's less important of an issue.  Is there anything
> similar that allows larger messages?

The 255 character limit is because the Carbon API that EasyDialogs
uses to set the message uses a Str255 argument (which is, as the
name suggests, limited to 255 characters).

I think there are APIs that allow long strings, so it should be doable
to adapt EasyDialogs to use those (at least for the messages, the
dialog title and button titles and default input values and all the
other stuff are probably fine at 255 chars).

Anyone willing to have a look at the Carbon documentation and
EasyDialogs to see whether there's an easy fix for this?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From bob at redivi.com  Wed Oct  6 02:03:01 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 02:03:08 2004
Subject: [Pythonmac-SIG] #! line and simple dialogs [SOLVED]
In-Reply-To: <aee06c9e04100122543713b8af@mail.gmail.com>
References: <aee06c9e041001125164940792@mail.gmail.com>
	<195FB526-13F1-11D9-A0B5-000A9598382A@semi-retired.com>
	<aee06c9e04100118061724ef9a@mail.gmail.com>
	<7470E4CE-1415-11D9-BEA4-000A95686CD8@redivi.com>
	<aee06c9e04100122543713b8af@mail.gmail.com>
Message-ID: <16B04D39-172B-11D9-BA59-000A95686CD8@redivi.com>


On Oct 2, 2004, at 1:54 AM, Nathaniel Gray wrote:

> On Fri, 1 Oct 2004 21:50:36 -0400, Bob Ippolito <bob@redivi.com> wrote:
>> On Oct 1, 2004, at 9:06 PM, Nathaniel Gray wrote:
>
>> You could emulate EasyDialogs with PyObjC, which is pretty 
>> lightweight.
>>   You could also probably convince appscript to do all your dialogs in
>> the same way that Applescript does.
>
> These are probably the most promising routes.  Really, I asked the
> question hoping somebody had done something with PyObjC or appscript
> already and I could use their code.

Here's a start...  You could use this technique to implement the 
others.  File open/saving should be easy because the panels can already 
do that modal.


from AppKit import *
from Foundation import *
from PyObjCTools import AppHelper
import sys, os, objc

startedApplication = None

class ModalResponder(NSObject):
     rval = None
     def performModalJunk_(self, (fn, args, kwargs)):
         self.rval = None
         try:
             self.rval = fn(*args, **kwargs)
         except Exception, e:
             self.rval = e
         NSApp().stop_(self)

     def fetchResult(self):
         rval = self.rval
         self.rval = None
         if isinstance(rval, Exception):
             raise rval
         return rval

_modalResponder = ModalResponder.alloc().init()

def ensureModal(fn):
     def _ensureModal(*args, **kwargs):
         global startedApplication
         if startedApplication is None:
             startedApplication = NSApp() is None
             app = NSApplication.sharedApplication()
         if NSApp():
             return fn(*args, **kwargs)
         else:
             
NSRunloop.currentRunLoop().performSelector_target_order_modes_(
                 'performModalJunk:', _modalResponder,
                 2000, [NSDefaultRunLoopMode])
             NSApplication.run()
             return _modalResponder.fetchResult()
     _ensureModal.__doc__ = fn.__doc__
     return _ensureModal


def Message(msg, defaultButton=None, alternateButton=None, 
otherButton=None, title=u' '):
     """Display a MESSAGE string.

     Return when the user clicks the OK button or presses Return.
     """
     return NSRunInformationalAlertPanel(title, msg, defaultButton, 
alternateButton, otherButton)
Message = ensureModal(Message)
From cohar at conncoll.edu  Wed Oct  6 01:09:27 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Wed Oct  6 03:50:03 2004
Subject: [Pythonmac-SIG] Trying to make an app
Message-ID: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>

I'm using wxPython (2.5.7.2) with the OS 10.3.5 Python (2.3). I want to 
make a standalone that will run on other OSX Macs. (Later I'll want to 
make Windows executables but that's the future.) So far, I haven't been 
able to make one that will run even on another 10.3 machine that 
doesn't have wxPython on it.

I've tried various approaches. I'm working on py2app, but don't 
understand it yet. (No documentation; does anyone know of a 
simple-minded run-through?) My closest approach has been with 
bundlebuilder. I learned to include the wxPython libraries in the 
'libs=[]' field within the buildapp() call, but NOT to include the 
symbolic links (which keep the resulting app from even being copied 
from a CD onto another machine; a Weird Alias error message). But so 
far, I still get an app whose icon bounces up and down, but won't load. 
I haven't had enough time on a "virgin" machine to get out the Console, 
etc, looking for error messages, which I suppose is my next step. 
Meanwhile, does anyone have a suggestion for what might still be 
missing from my would-be standalone?

Beyond that, I'm confused about whether a standalone that finally does 
work on 10.3 will also work on 10.2, 10.1.

Charles Hartman

From bob at redivi.com  Wed Oct  6 04:22:02 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 04:22:12 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
Message-ID: <823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>

On Oct 5, 2004, at 7:09 PM, Charles Hartman wrote:

> I'm using wxPython (2.5.7.2) with the OS 10.3.5 Python (2.3). I want 
> to make a standalone that will run on other OSX Macs. (Later I'll want 
> to make Windows executables but that's the future.) So far, I haven't 
> been able to make one that will run even on another 10.3 machine that 
> doesn't have wxPython on it.
>
> I've tried various approaches. I'm working on py2app, but don't 
> understand it yet. (No documentation; does anyone know of a 
> simple-minded run-through?) My closest approach has been with 
> bundlebuilder. I learned to include the wxPython libraries in the 
> 'libs=[]' field within the buildapp() call, but NOT to include the 
> symbolic links (which keep the resulting app from even being copied 
> from a CD onto another machine; a Weird Alias error message). But so 
> far, I still get an app whose icon bounces up and down, but won't 
> load. I haven't had enough time on a "virgin" machine to get out the 
> Console, etc, looking for error messages, which I suppose is my next 
> step. Meanwhile, does anyone have a suggestion for what might still be 
> missing from my would-be standalone?

bundlebuilder is a dead end, don't bother.

py2app should pretty much just work if you give it your script.  I 
don't have wxPython on this machine so I can't tell if anything special 
needs to be done or not, but I'm relatively certain it should Just Work 
if memory serves correctly.  Look at the examples directory.

> Beyond that, I'm confused about whether a standalone that finally does 
> work on 10.3 will also work on 10.2, 10.1.

Definitely not.  Anything you build on 10.3 will only work on >= 10.3 
(unless the Python and extensions that you're building with were all 
compiled for 10.2.. but that is beyond the scope of any help I'm 
willing to give at this point because I have never gone through the 
trouble to create such an envionment).

-bob
From n9yty at n9yty.com  Wed Oct  6 04:47:48 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Wed Oct  6 04:47:54 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
Message-ID: <1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>


On Oct 5, 2004, at 9:22 PM, Bob Ippolito wrote:
> py2app should pretty much just work if you give it your script.  I 
> don't have wxPython on this machine so I can't tell if anything 
> special needs to be done or not, but I'm relatively certain it should 
> Just Work if memory serves correctly.  Look at the examples directory.

  I get a lot of output and then it dies with this:

  error: can't copy 'C': doesn't exist or not a regular file

  Here is the skeletal stuff in my build script, adapted from my 
bundlebuilder stuff, so maybe not the best approach:

from distutils.core import setup
import py2app
name = "BitPim"
iconfile = "bitpim.icns"
data_files=[]
includePackages=[]
verstr = "%s-%s" % (v['NAME'], v['VERSION'])

(some files stuffed into data_files, a few packages included in 
includePackages)

plist = dict(
   CFBundleIconFile            = iconfile,
   CFBundleName                = name,
   CFBundleShortVersionString  = verstr,
   CFBundleGetInfoString       = '-'.join([name, verstr]),
   CFBundleExecutable          = name,
   CFBundleIdentifier          = 'net.sourceforge.bitpim',
)
app = [ dict(optimize=2,
              packages=includePackages,
              includes=data_files,
              iconfile=iconfile,
              script="bp.py",
              plist=plist,),]
setup( data_files = data_files, app = app,)

Anyway, all by the seat of my pants and probably wrong, but it's not 
working. ;-)

Thanks


From bob at redivi.com  Wed Oct  6 05:02:27 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 05:02:34 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
Message-ID: <2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>


On Oct 5, 2004, at 10:47 PM, Steven Palm wrote:

>
> On Oct 5, 2004, at 9:22 PM, Bob Ippolito wrote:
>> py2app should pretty much just work if you give it your script.  I 
>> don't have wxPython on this machine so I can't tell if anything 
>> special needs to be done or not, but I'm relatively certain it should 
>> Just Work if memory serves correctly.  Look at the examples 
>> directory.
>
>  I get a lot of output and then it dies with this:
>
>  error: can't copy 'C': doesn't exist or not a regular file
>
>  Here is the skeletal stuff in my build script, adapted from my 
> bundlebuilder stuff, so maybe not the best approach:
<bitpim setup script cut>

Well it works with a trivial wx app.. I just tested it.  See 
http://svn.red-bean.com/bob/py2app/trunk/examples/wxPython/doodle/

As far as this package goes, I can't help you without more information. 
  Try it without packages or includes, it's supposed to do all that for 
you.

-bob
From bob at redivi.com  Wed Oct  6 07:36:53 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 07:37:01 2004
Subject: [Pythonmac-SIG] ANN: py2app 0.1.1
Message-ID: <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>

`py2app`_ is the bundlebuilder replacement we've all been waiting for.   
It is implemented as a distutils command, similar to `py2exe`_, that  
builds Mac OS X applications from Python scripts, extensions, and  
related data files.  It tries very hard to include all dependencies it  
can find so that your application can be distributed standalone, as Mac  
OS X applications should be.

`py2app`_ 0.1.1 is primarily a bugfix release:

  * Several problems related to Mac OS X 10.2 compatibility and  
standalone building have been resolved
  * Scripts that are not in the same directory as setup.py now work
  * A new recipe has been added that removes the pydoc -> Tkinter  
dependency
  * A recipe has been added for py2app itself
  * a `wxPython`_ example (superdoodle) has been added.  Demonstrates  
not only how easy it is (finally!) to bundle `wxPython`_ applications,  
but also how one setup.py can deal with both `py2exe`_ and `py2app`_.
  * A new experimental tool, py2applet, has been added.  Once you've  
built it (``python setup.py py2app``, of course), you should be able to  
build simple applications simply by dragging your main script and  
optionally any packages, data files, Info.plist and icon it needs.

Known issues:

  * Includes *all* files from packages, it should be smart enough to  
strip unused .py/.pyc/.pyo files (to save space, depending on which  
optimization flag is used).

  * The default PyRuntimeLocations can cause problems on machines that  
have a /Library/Frameworks/Python.framework installed.  Workaround is  
to set a plist that has the following key:  
``PyRuntimeLocations=['/System/Library/Frameworks/Python.framework/ 
Versions/2.3/Python']`` (this will be resolved soon)

Download and related links are here:
http://undefined.org/python/#py2app

.. _`wxPython`: http://www.wxpython.org/
.. _`py2app`: http://undefined.org/python/#py2app
.. _`py2exe`: http://starship.python.net/crew/theller/py2exe/
From Jack.Jansen at cwi.nl  Wed Oct  6 13:06:42 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Wed Oct  6 13:08:04 2004
Subject: [Pythonmac-SIG] python include location
In-Reply-To: <3738A88A-1715-11D9-AE87-000A95A7B782@pacbell.net>
References: <3738A88A-1715-11D9-AE87-000A95A7B782@pacbell.net>
Message-ID: <CDAFD42E-1787-11D9-8AA1-000A958D1666@cwi.nl>


On 5-okt-04, at 23:26, Scott Frankel wrote:

>
> Apologies in advance for the ignorant question that follows.  I think  
> my brain
> stopped working.
>
> Where is Python.h located?

It's in include/python2.3 relative to sys.prefix (which makes me wonder  
why the pygresql build process can't deduce this itself...). For  
Apple-installed Python on 10.3 this translates to  
/System/Library/Frameworks/Python.framework/Versions/2.3/include/ 
python2.3.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman

From bob at redivi.com  Wed Oct  6 16:08:52 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 16:09:34 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <B70AD09A-1793-11D9-BC97-000393A37396@conncoll.edu>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<B70AD09A-1793-11D9-BC97-000393A37396@conncoll.edu>
Message-ID: <4091FB2E-17A1-11D9-B2E0-000A95686CD8@redivi.com>

On Oct 6, 2004, at 8:31 AM, Charles Hartman wrote:

>> py2app should pretty much just work if you give it your script.  I 
>> don't have wxPython on this machine so I can't tell if anything 
>> special needs to be done or not, but I'm relatively certain it should 
>> Just Work if memory serves correctly.  Look at the examples 
>> directory.
>>
> I apologize for a really lame question -- but where do I put the (now) 
> py2app-0.1.1 folder when I've downloaded it? Should I be trying to 
> make an .app file of py2app itself? If I put the folder in  
> /Library/Python/2.3 with other packages like wxPython and Numeric, and 
> try the Terminal command 'python setup.py py2app', I get the errmsg 
> "invalid command 'py2app' (no module named 
> 'distutils.command.py2app'". If I just double-lick the 'setup.py' file 
> in (for instance) .../py2app-0.1.1/examples/wxPython/doodle, I get "no 
> module named py2app". Same message if I navigate to 
> .../tools/py2applet and use "python setup.py py2app".
>
> So I can see I'm doing something really *basically* stupid here, but 
> none of the logical (?) alternatives I've tried gives me an error 
> message with enough of a hint to steer me. Sorry; I know the inside of 
> Python, however poorly, a lot better than the outside.

Same way you install just about anything else for Python..

% cd py2app-0.1.1
% sudo python setup.py install

-bob
From n9yty at n9yty.com  Wed Oct  6 16:36:50 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Wed Oct  6 16:36:55 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
Message-ID: <28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>


On Oct 5, 2004, at 10:02 PM, Bob Ippolito wrote:
> Well it works with a trivial wx app.. I just tested it.  See 
> http://svn.red-bean.com/bob/py2app/trunk/examples/wxPython/doodle/

  Thanks for taking the time to test that, Bob.

> As far as this package goes, I can't help you without more 
> information.  Try it without packages or includes, it's supposed to do 
> all that for you.

  Well, most of the things included are resources for the program (data 
files/etc) and need to be specifically included on Linux/Windows as 
well. I overlooked the fact that for BundleBuilder this was a list of 
tuples, so no wonder py2app was getting confused. :-(  Sorry about 
that!

  I fixed that, and now it launches but dies with a recursion error... 
It may be related to not being able to find it's resource files because 
it expects them to live in "Contents/Resources/resources", and that's 
how I had BundleBuilder setting it up as well, but I can't immediately 
see a way to get py2app to duplicate the tree.

  They get copied like this:

  copying ./resources/pblayout.xy -> BitPim.app/Contents/Resources

  Any way to get py2app to preserve the original directory hierarchy?

  Thanks!


From bob at redivi.com  Wed Oct  6 16:46:18 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 16:46:54 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
Message-ID: <7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>


On Oct 6, 2004, at 10:36 AM, Steven Palm wrote:

>
> On Oct 5, 2004, at 10:02 PM, Bob Ippolito wrote:
>
>> As far as this package goes, I can't help you without more 
>> information.  Try it without packages or includes, it's supposed to 
>> do all that for you.
>
>  Well, most of the things included are resources for the program (data 
> files/etc) and need to be specifically included on Linux/Windows as 
> well. I overlooked the fact that for BundleBuilder this was a list of 
> tuples, so no wonder py2app was getting confused. :-(  Sorry about 
> that!
>
>  I fixed that, and now it launches but dies with a recursion error... 
> It may be related to not being able to find it's resource files 
> because it expects them to live in "Contents/Resources/resources", and 
> that's how I had BundleBuilder setting it up as well, but I can't 
> immediately see a way to get py2app to duplicate the tree.
>
>  They get copied like this:
>
>  copying ./resources/pblayout.xy -> BitPim.app/Contents/Resources
>
>  Any way to get py2app to preserve the original directory hierarchy?

One way is to specify the resources folder instead of every file in the 
resources folder.  The default tree copier in py2app is going to ignore 
.svn and CVS garbage that may be in there so it's usually fine to do.

Another way is to specify a list of tuples.. which should definitely 
work but I haven't really tried it myself.

setup(
     data_files=[('resources', ['./resources/pblayout.xy', ...]), ...],
     ...
)

-bob
From whamoo at rknet.it  Wed Oct  6 16:57:49 2004
From: whamoo at rknet.it (whamoo)
Date: Wed Oct  6 16:57:14 2004
Subject: [Pythonmac-SIG] [ANN]Cocoadialog 0.1 prerelease/unstable/beta
	version
Message-ID: <172FBA72-17A8-11D9-B42A-000A95C62238@rknet.it>

Hi to all,

Working on the code of Bob Ippolito i've written a stupid 
implementation of some cocoa dialog.
This is only an idea, nothing definitive, but usable, for now only 
message, open and save dialog are implemented, helps, ideas
and more are welcome =)

For now only two file, for use include cocoadialog, here some example:

<code>
import cocoadialog

res = cocoadialog.savedialog()
file = (res.filename(), 'w')
file.write("bla bla")
file.close()

------ or -------

import cocoadialog

res = cocoadialog.alertdialog(msg="Today is a good day to die", 
defbutton="you're mad", altbutton="Ok let's go to battle", info="We 
didn't care of your life")
if res.button == 1:
	print "Poor me"
if res.button == 0:
	print "Ok, let's go"
</code>

for other exmple "pydoc cocoadialog"

Whamoo www.rknet.it
Powered by:
- MacOsX
- Gnu / Linux Debian Sarge
- Amiga Os 3.9
- Milk

From sw at wordtech-software.com  Wed Oct  6 17:00:23 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Wed Oct  6 17:00:26 2004
Subject: [Pythonmac-SIG] py2app--cool!
Message-ID: <41640887.70905@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is just a quick "thank-you" to Bob for the excellent work on
py2app. I've been playing with it and I'm amazed at how easy it is: all
the complexity of Bundlebuilder is gone, or at least hidden from people
at my modest skill level.

It looks like I'll be a) drastically overhauling the Python-app-bundle
tutorial at my website and b) re-packaging all the Python application
bundles I'm maintaining (wxGlade, Leo, Pears, etc.). No more hacking
"save as applet."

Thanks again, Bob!

- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZAiHJmdQs+6YVcoRAtGxAKCIVXnxZZtrxaYffOwGjzoL/sxPjQCfV5AS
rkZ0Kp801VFr14md9odHxYI=
=pmRv
-----END PGP SIGNATURE-----
From n9yty at n9yty.com  Wed Oct  6 17:39:09 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Wed Oct  6 17:39:12 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
Message-ID: <DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>


On Oct 6, 2004, at 9:46 AM, Bob Ippolito wrote:
> On Oct 6, 2004, at 10:36 AM, Steven Palm wrote:
>> setting it up as well, but I can't immediately see a way to get 
>> py2app to duplicate the tree.
>>
>>  They get copied like this:
>>
>>  copying ./resources/pblayout.xy -> BitPim.app/Contents/Resources
>>
>>  Any way to get py2app to preserve the original directory hierarchy?
>
> One way is to specify the resources folder instead of every file in 
> the resources folder.  The default tree copier in py2app is going to 
> ignore .svn and CVS garbage that may be in there so it's usually fine 
> to do.

  Unfortunately not everything in the directory gets put into the 
bundle. :-(

> Another way is to specify a list of tuples.. which should definitely 
> work but I haven't really tried it myself.
>
> setup(
>     data_files=[('resources', ['./resources/pblayout.xy', ...]), ...],
>     ...
> )

  That seemed to work.

  I can't figure out the right syntax to get it to process an options 
list to make an icon, set the dest_dir, etc... Maybe I'll just sit back 
and wait for some of the more seasoned PythonMAC folks  to give this a 
going-over.

  Even though the `resource` files are where they are supposed to be, I 
still get an error on running the program about recursion errors and 
that it cannot find it's resource files.

  Thanks!

  Steve


From bob at redivi.com  Wed Oct  6 17:59:24 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 18:00:01 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
Message-ID: <B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>


On Oct 6, 2004, at 11:39 AM, Steven Palm wrote:

>
> On Oct 6, 2004, at 9:46 AM, Bob Ippolito wrote:
>> On Oct 6, 2004, at 10:36 AM, Steven Palm wrote:
>>> setting it up as well, but I can't immediately see a way to get 
>>> py2app to duplicate the tree.
>>>
>>>  They get copied like this:
>>>
>>>  copying ./resources/pblayout.xy -> BitPim.app/Contents/Resources
>>>
>>>  Any way to get py2app to preserve the original directory hierarchy?
>>
>> One way is to specify the resources folder instead of every file in 
>> the resources folder.  The default tree copier in py2app is going to 
>> ignore .svn and CVS garbage that may be in there so it's usually fine 
>> to do.
>
>  Unfortunately not everything in the directory gets put into the 
> bundle. :-(

Could you give me some hints as to what goes in and what does not?  I 
don't see any reason why this should be the case.

>> Another way is to specify a list of tuples.. which should definitely 
>> work but I haven't really tried it myself.
>>
>> setup(
>>     data_files=[('resources', ['./resources/pblayout.xy', ...]), ...],
>>     ...
>> )
>
>  That seemed to work.
>
>  I can't figure out the right syntax to get it to process an options 
> list to make an icon, set the dest_dir, etc... Maybe I'll just sit 
> back and wait for some of the more seasoned PythonMAC folks  to give 
> this a going-over.

You can do all of those on the commandline or you can set them in an 
options dictionary the same way you would with py2exe.

setup(
	...
	app=['myapp.py'],
	options=dict(py2app=dict(
		iconfile='myicon.icns',
		...
	)),
	...
)

>  Even though the `resource` files are where they are supposed to be, I 
> still get an error on running the program about recursion errors and 
> that it cannot find it's resource files.

This is probably a bug in your program.. without any more information I 
can't help you.  The current directory of a py2app bundle is the 
Resources folder, so open('resources/mydatafile') will just work unless 
you do a chdir.

-bob
From n9yty at n9yty.com  Wed Oct  6 18:44:46 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Wed Oct  6 18:44:50 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
Message-ID: <08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>


On Oct 6, 2004, at 10:59 AM, Bob Ippolito wrote:
> On Oct 6, 2004, at 11:39 AM, Steven Palm wrote:
>>  Even though the `resource` files are where they are supposed to be, 
>> I still get an error on running the program about recursion errors 
>> and that it cannot find it's resource files.
>
> This is probably a bug in your program.. without any more information 
> I can't help you.  The current directory of a py2app bundle is the 
> Resources folder, so open('resources/mydatafile') will just work 
> unless you do a chdir.

  Hmmm...  Here is where it's looking... It initially does this when one 
of the modules loads:

# Where to find bitmaps etc
p=sys.path[0]
if os.path.isfile(p): # zip importer in action
     p=os.path.dirname(p)
resourcedirectory=os.path.abspath(os.path.join(p, 'resources'))

And then later when trying  to load them it uses:

  os.path.join(resourcedirectory, filename)

So the difference in invocation between the bundlebuuilder-built  
application bundle and the py2app-built application bundle is causing a 
problem with finding the path where we are being run from, at least in 
the way that BitPim is trying to find it in the above code. Anyway, 
that's something for me to worry about. ;^)

Thanks!


From bob at redivi.com  Wed Oct  6 19:04:39 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 19:05:19 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
Message-ID: <CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>

On Oct 6, 2004, at 12:44 PM, Steven Palm wrote:

>
> On Oct 6, 2004, at 10:59 AM, Bob Ippolito wrote:
>> On Oct 6, 2004, at 11:39 AM, Steven Palm wrote:
>>>  Even though the `resource` files are where they are supposed to be, 
>>> I still get an error on running the program about recursion errors 
>>> and that it cannot find it's resource files.
>>
>> This is probably a bug in your program.. without any more information 
>> I can't help you.  The current directory of a py2app bundle is the 
>> Resources folder, so open('resources/mydatafile') will just work 
>> unless you do a chdir.
>
>  Hmmm...  Here is where it's looking... It initially does this when 
> one of the modules loads:
>
> # Where to find bitmaps etc
> p=sys.path[0]
> if os.path.isfile(p): # zip importer in action
>     p=os.path.dirname(p)
> resourcedirectory=os.path.abspath(os.path.join(p, 'resources'))
>
> And then later when trying  to load them it uses:
>
>  os.path.join(resourcedirectory, filename)
>
> So the difference in invocation between the bundlebuuilder-built  
> application bundle and the py2app-built application bundle is causing 
> a problem with finding the path where we are being run from, at least 
> in the way that BitPim is trying to find it in the above code. Anyway, 
> that's something for me to worry about. ;^)

Ok so don't do that!  Your application is trying to be too tricky.  
sys.path[0] is going to point to the os.path.dirname(sys.argv[0]), 
which is the bootstrap executable.  sys.path[1] is Resources, though.

If you want to see all stuff you need to know about look at 
examples/simple/ .. it is a program that prints out sys.executable, 
etc.

You start in the Resources folder, so just do:
resourcedirectory='resources'

-bob
From n9yty at n9yty.com  Wed Oct  6 21:04:37 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Wed Oct  6 21:04:39 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
Message-ID: <9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>


On Oct 6, 2004, at 12:04 PM, Bob Ippolito wrote:
>> So the difference in invocation between the bundlebuuilder-built  
>> application bundle and the py2app-built application bundle is causing 
>> a problem with finding the path where we are being run from, at least 
>> in the way that BitPim is trying to find it in the above code. 
>> Anyway, that's something for me to worry about. ;^)
>
> Ok so don't do that!  Your application is trying to be too tricky.  
> sys.path[0] is going to point to the os.path.dirname(sys.argv[0]), 
> which is the bootstrap executable.  sys.path[1] is Resources, though.

  Well, this isn't *my* app, it's Roger Binns who is the main developer, 
I just pitch in to build Macintosh versions. He really on the whole 
abhors platform unique and is doing that too (I assume) deal with 
Windows and Linux in a consistent fashion. If it proves that py2app is 
the best Mac packaging solution, then it may also be required to change 
that initialization code to fit it.

  On the other hand, the bundlebuilder process produces a 15MB package, 
while the py2app package is about 40MB, so maybe it's not time to 
switch yet until you are able to strip out unneeded parts of referenced 
modules.

> You start in the Resources folder, so just do:
> resourcedirectory='resources'

  Ah, but he is later using that as a base point for other paths... It's 
confusing, and obviously well outside of the scope of what py2app is 
responsible for. Now  that you've educated me a bit more I'll  work it 
out with Roger. ;-)

  Steve


From rowen at cesmail.net  Wed Oct  6 21:34:47 2004
From: rowen at cesmail.net (Russell E. Owen)
Date: Wed Oct  6 21:34:55 2004
Subject: [Pythonmac-SIG] Re: ANN: py2app 0.1.1
References: <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>
Message-ID: <rowen-D1B0F4.12344706102004@sea.gmane.org>

In article <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>,
 Bob Ippolito <bob@redivi.com> wrote:

> `py2app`_ is the bundlebuilder replacement we've all been waiting for.   
> It is implemented as a distutils command, similar to `py2exe`_, that  
> builds Mac OS X applications from Python scripts, extensions, and  
> related data files.  It tries very hard to include all dependencies it  
> can find so that your application can be distributed standalone, as Mac  
> OS X applications should be.

I look at the 0.1 distro and examples and it really looks promising. 
However, I did have two questions before I dive into trying to get my 
app bundled:
- Do you have any hints or gotchas for distributing Tkinter apps and 
have Tcl/Tk bundled inside. I want the target MacOS X 10.3 user to be 
able to run my app without installing anything.
- As an extension to that question...any hints on installing tcl 
extensions ("snack", specifically) into such a bundled app?

-- Russell

From bob at redivi.com  Wed Oct  6 21:38:43 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 21:39:23 2004
Subject: [Pythonmac-SIG] Re: ANN: py2app 0.1.1
In-Reply-To: <rowen-D1B0F4.12344706102004@sea.gmane.org>
References: <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>
	<rowen-D1B0F4.12344706102004@sea.gmane.org>
Message-ID: <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com>


On Oct 6, 2004, at 3:34 PM, Russell E. Owen wrote:

> In article <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>,
>  Bob Ippolito <bob@redivi.com> wrote:
>
>> `py2app`_ is the bundlebuilder replacement we've all been waiting for.
>> It is implemented as a distutils command, similar to `py2exe`_, that
>> builds Mac OS X applications from Python scripts, extensions, and
>> related data files.  It tries very hard to include all dependencies it
>> can find so that your application can be distributed standalone, as 
>> Mac
>> OS X applications should be.
>
> I look at the 0.1 distro and examples and it really looks promising.
> However, I did have two questions before I dive into trying to get my
> app bundled:
> - Do you have any hints or gotchas for distributing Tkinter apps and
> have Tcl/Tk bundled inside. I want the target MacOS X 10.3 user to be
> able to run my app without installing anything.

It works exactly like that out of the box.

> - As an extension to that question...any hints on installing tcl
> extensions ("snack", specifically) into such a bundled app?

No idea, give me instructions on how to do it and a minimal example 
that uses it and I'll see what can be done.

-bob
From bob at redivi.com  Wed Oct  6 21:45:13 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 21:45:50 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
	<9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
Message-ID: <3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>

On Oct 6, 2004, at 3:04 PM, Steven Palm wrote:

> On Oct 6, 2004, at 12:04 PM, Bob Ippolito wrote:
>>> So the difference in invocation between the bundlebuuilder-built  
>>> application bundle and the py2app-built application bundle is 
>>> causing a problem with finding the path where we are being run from, 
>>> at least in the way that BitPim is trying to find it in the above 
>>> code. Anyway, that's something for me to worry about. ;^)
>>
>> Ok so don't do that!  Your application is trying to be too tricky.  
>> sys.path[0] is going to point to the os.path.dirname(sys.argv[0]), 
>> which is the bootstrap executable.  sys.path[1] is Resources, though.
>
>  Well, this isn't *my* app, it's Roger Binns who is the main 
> developer, I just pitch in to build Macintosh versions. He really on 
> the whole abhors platform unique and is doing that too (I assume) deal 
> with Windows and Linux in a consistent fashion. If it proves that 
> py2app is the best Mac packaging solution, then it may also be 
> required to change that initialization code to fit it.

I'll see if I can change sys.path[0] without breaking anything useful.

>  On the other hand, the bundlebuilder process produces a 15MB package, 
> while the py2app package is about 40MB, so maybe it's not time to 
> switch yet until you are able to strip out unneeded parts of 
> referenced modules.

Probably because the bundlebuilder process isn't embedding everything 
it actually needs, or you're including too many packages explicitly 
without reason.  Either that or there's a WHOLE LOT of python code and 
you should turn on zip compression.  I can't know unless I can see a ls 
-lR of what went in there or something.  If I don't get this kind of 
assistance from users like you then py2app will likely never suit your 
needs, so don't throw it away yet .. it's probably a trivial fix.

>> You start in the Resources folder, so just do:
>> resourcedirectory='resources'
>
>  Ah, but he is later using that as a base point for other paths... 
> It's confusing, and obviously well outside of the scope of what py2app 
> is responsible for. Now  that you've educated me a bit more I'll  work 
> it out with Roger. ;-)

Well, you've confused me :)

-bob
From bob at redivi.com  Wed Oct  6 22:22:08 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 22:22:45 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
	<9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
	<3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
Message-ID: <65CA00FB-17D5-11D9-A1CC-000A95686CD8@redivi.com>


On Oct 6, 2004, at 3:45 PM, Bob Ippolito wrote:

> On Oct 6, 2004, at 3:04 PM, Steven Palm wrote:
>
>> On Oct 6, 2004, at 12:04 PM, Bob Ippolito wrote:
>>>> So the difference in invocation between the bundlebuuilder-built  
>>>> application bundle and the py2app-built application bundle is 
>>>> causing a problem with finding the path where we are being run 
>>>> from, at least in the way that BitPim is trying to find it in the 
>>>> above code. Anyway, that's something for me to worry about. ;^)
>>>
>>> Ok so don't do that!  Your application is trying to be too tricky.  
>>> sys.path[0] is going to point to the os.path.dirname(sys.argv[0]), 
>>> which is the bootstrap executable.  sys.path[1] is Resources, 
>>> though.
>>
>>  Well, this isn't *my* app, it's Roger Binns who is the main 
>> developer, I just pitch in to build Macintosh versions. He really on 
>> the whole abhors platform unique and is doing that too (I assume) 
>> deal with Windows and Linux in a consistent fashion. If it proves 
>> that py2app is the best Mac packaging solution, then it may also be 
>> required to change that initialization code to fit it.
>
> I'll see if I can change sys.path[0] without breaking anything useful.

It's changed in svn trunk.  sys.path[0] should point to 
Contents/Resources now.

-bob
From n9yty at n9yty.com  Wed Oct  6 22:40:05 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Wed Oct  6 22:40:08 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
	<9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
	<3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
Message-ID: <E767DE43-17D7-11D9-A51D-000D9335B6B6@n9yty.com>


On Oct 6, 2004, at 2:45 PM, Bob Ippolito wrote:
> I'll see if I can change sys.path[0] without breaking anything useful.

  Thanks. Honestly, I don't know which is more "intuitive" or "better",  
you're in a much better position than I am to make a decision about 
what is generally a "better" idea for most people.

>>  On the other hand, the bundlebuilder process produces a 15MB 
>> package, while the py2app package is about 40MB, so maybe it's not 
>> time to switch yet until you are able to strip out unneeded parts of 
>> referenced modules.
>
> Probably because the bundlebuilder process isn't embedding everything 
> it actually needs,

  Well, it does run fine on virgin systems that have no non-standard 
components installed. However, if py2app is bundling in a whole python 
distribution and bundlebuilder is relying on the system install, then 
it would explain it.

>  or you're including too many packages explicitly without reason.

  Not sure, most of the code is Roger's.

>   Either that or there's a WHOLE LOT of python code and you should 
> turn on zip compression.  I can't know unless I can see a ls -lR of 
> what went in there or something.  If I don't get this kind of 
> assistance from users like you then py2app will likely never suit your 
> needs, so don't throw it away yet .. it's probably a trivial fix.

  I'm not about to throw it away, you've worked too hard on it. ;-)  I 
jumped on the testing bandwagon when I saw your announcement precisely 
because I wanted to provide feedback on how it works for random app out 
in the wild.

  By the way, I cannot get the "dist_dir" option to use the directory 
specified, the output bundle always goes in my current directory (where 
setup.py is).

  One more issue is that some package parts are loaded dynamically, such 
as this:

dlg=CommPortDialog(self, 
__import__(self.phonemodels[self.phonebox.GetValue()]), 
defaultport=self.commbox.GetValue(), sashposition=p)

  It complains that it cannot find the module referenced by 
self.phonemodels[self.phonebox.GetValue()]).

  For bundlebuilder, I was doing this:

     coms=glob.glob("com_*.py")
     for c in coms:
         myapp.includePackages.append(c[:-3])

  For py2app, I was just using passing a build includePackages list in 
via the "packages" element in the options dict. I cannot find the 
comm_* files anywhere in the generated bundle, in the site_packages.zip 
file or outside of it. They are included as:

     options = dict(p2app=dict(
                  optimize=2,
                  dist_dir="./dist/",
                  compress=1,
                  packages=includePackages,
                  includes=data_files,
                  iconfile=iconfile,
                  plist=plist))

  where includePackages is built above.

  Also, the dependencies checker seems to be missing the fact that 
libusb must be included... I see it coming up with a libusb.so, but 
that's just the SWWIG generated stub, I think, in bundlebuilder I had 
to include the dylib itself.

  Here is a listing of the package:

ls -lR BitPim.app
total 0
drwxr-xr-x  7 n9yty  wheel  238  6 Oct 15:20 Contents

BitPim.app/Contents:
total 16
drwxr-xr-x  6 n9yty  wheel   204  6 Oct 15:20 Frameworks
-rw-r--r--  1 n9yty  wheel  1935  6 Oct 15:20 Info.plist
drwxr-xr-x  3 n9yty  wheel   102  6 Oct 15:20 MacOS
-rw-r--r--  1 n9yty  wheel     8  6 Oct 15:20 PkgInfo
drwxr-xr-x  8 n9yty  wheel   272  6 Oct 15:20 Resources

BitPim.app/Contents/Frameworks:
total 17584
-rwxr-xr-x  1 n9yty  wheel  2101772  6 Oct 15:20 libSDL-1.2.0.7.0.dylib
-rwxr-xr-x  1 n9yty  wheel   326860  6 Oct 15:20 libexpat.0.4.0.dylib
-rwxr-xr-x  1 n9yty  wheel  6297076  6 Oct 15:20 
libwx_mac-2.5.2.0.0.dylib
-rwxr-xr-x  1 n9yty  wheel   268440  6 Oct 15:20 
libwx_mac_gizmos-2.5.2.0.0.dylib

BitPim.app/Contents/MacOS:
total 112
-rwxr-xr-x  1 n9yty  wheel  53832  5 Oct 23:02 BitPim

BitPim.app/Contents/Resources:
total 32
drwxr-xr-x   6 n9yty  wheel  204  6 Oct 15:20 Python
-rw-r--r--   1 n9yty  wheel  597  6 Oct 15:20 __boot__.py
-rwxr-xr-x   1 n9yty  wheel  449  3 Oct 14:50 __error__.sh
drwxr-xr-x  25 n9yty  wheel  850  6 Oct 15:20 resources
-rw-r--r--   1 n9yty  wheel  322  3 Oct 14:50 sitecustomize.py
-rw-r--r--   1 n9yty  wheel  653  4 Oct 20:16 sitecustomize.pyc

BitPim.app/Contents/Resources/Python:
total 9136
-rw-r--r--  1 n9yty  wheel     2176 13 Sep 10:11 bp.py
drwxr-xr-x  6 n9yty  wheel      204  6 Oct 15:20 lib-dynload
drwxr-xr-x  3 n9yty  wheel      102  6 Oct 15:20 site-packages
-rw-r--r--  1 n9yty  wheel  4672712  6 Oct 15:20 site-packages.zip

BitPim.app/Contents/Resources/Python/lib-dynload:
total 0
drwxr-xr-x   3 n9yty  wheel  102  6 Oct 15:20 Crypto
drwxr-xr-x   3 n9yty  wheel  102  6 Oct 15:20 native
drwxr-xr-x  11 n9yty  wheel  374  6 Oct 15:20 wx
drwxr-xr-x   3 n9yty  wheel  102  6 Oct 15:20 xml

BitPim.app/Contents/Resources/Python/lib-dynload/Crypto:
total 0
drwxr-xr-x  5 n9yty  wheel  170  6 Oct 15:20 Cipher

BitPim.app/Contents/Resources/Python/lib-dynload/Crypto/Cipher:
total 416
-rwxr-xr-x  1 n9yty  wheel  54012  6 Oct 15:20 AES.so
-rwxr-xr-x  1 n9yty  wheel  50700  6 Oct 15:20 Blowfish.so
-rwxr-xr-x  1 n9yty  wheel  99348  6 Oct 15:20 DES3.so

BitPim.app/Contents/Resources/Python/lib-dynload/native:
total 0
drwxr-xr-x  3 n9yty  wheel  102  6 Oct 15:20 usb

BitPim.app/Contents/Resources/Python/lib-dynload/native/usb:
total 200
-rwxr-xr-x  1 n9yty  wheel  98472  6 Oct 15:20 _libusb.so

BitPim.app/Contents/Resources/Python/lib-dynload/wx:
total 46440
-rwxr-xr-x  1 n9yty  wheel   884260  6 Oct 15:20 _calendar.so
-rwxr-xr-x  1 n9yty  wheel  3527400  6 Oct 15:20 _controls_.so
-rwxr-xr-x  1 n9yty  wheel  3958192  6 Oct 15:20 _core_.so
-rwxr-xr-x  1 n9yty  wheel  2695224  6 Oct 15:20 _gdi_.so
-rwxr-xr-x  1 n9yty  wheel  2523108  6 Oct 15:20 _gizmos.so
-rwxr-xr-x  1 n9yty  wheel  2121300  6 Oct 15:20 _grid.so
-rwxr-xr-x  1 n9yty  wheel  1918696  6 Oct 15:20 _html.so
-rwxr-xr-x  1 n9yty  wheel  2936924  6 Oct 15:20 _misc_.so
-rwxr-xr-x  1 n9yty  wheel  3193096  6 Oct 15:20 _windows_.so

BitPim.app/Contents/Resources/Python/lib-dynload/xml:
total 0
drwxr-xr-x  3 n9yty  wheel  102  6 Oct 15:20 parsers

BitPim.app/Contents/Resources/Python/lib-dynload/xml/parsers:
total 896
-rwxr-xr-x  1 n9yty  wheel  455196  6 Oct 15:20 pyexpat.so

BitPim.app/Contents/Resources/Python/site-packages:
total 0
drwxr-xr-x  239 n9yty  wheel  8126  6 Oct 15:20 encodings

BitPim.app/Contents/Resources/Python/site-packages/encodings:
total 2960
-rw-r--r--  1 n9yty  wheel   4631 13 Sep  2003 __init__.py
-rw-r--r--  1 n9yty  wheel   4460 13 Sep  2003 __init__.pyc
-rw-r--r--  1 n9yty  wheel   4460 13 Sep  2003 __init__.pyo
-rw-r--r--  1 n9yty  wheel   9425 13 Sep  2003 aliases.py
-rw-r--r--  1 n9yty  wheel   6060 13 Sep  2003 aliases.pyc
-rw-r--r--  1 n9yty  wheel   6060 13 Sep  2003 aliases.pyo
-rw-r--r--  1 n9yty  wheel    727 13 Sep  2003 ascii.py
-rw-r--r--  1 n9yty  wheel   1958 13 Sep  2003 ascii.pyc
-rw-r--r--  1 n9yty  wheel   1958 13 Sep  2003 ascii.pyo
-rw-r--r--  1 n9yty  wheel   1770 13 Sep  2003 base64_codec.py
-rw-r--r--  1 n9yty  wheel   3833 13 Sep  2003 base64_codec.pyc
-rw-r--r--  1 n9yty  wheel   3711 13 Sep  2003 base64_codec.pyo
-rw-r--r--  1 n9yty  wheel   1245 13 Sep  2003 charmap.py
-rw-r--r--  1 n9yty  wheel   3114 13 Sep  2003 charmap.pyc
-rw-r--r--  1 n9yty  wheel   3114 13 Sep  2003 charmap.pyo
-rw-r--r--  1 n9yty  wheel  11920 13 Sep  2003 cp037.py
-rw-r--r--  1 n9yty  wheel   5728 13 Sep  2003 cp037.pyc
-rw-r--r--  1 n9yty  wheel   5728 13 Sep  2003 cp037.pyo
-rw-r--r--  1 n9yty  wheel   7030 13 Sep  2003 cp1006.py
-rw-r--r--  1 n9yty  wheel   4203 13 Sep  2003 cp1006.pyc
-rw-r--r--  1 n9yty  wheel   4203 13 Sep  2003 cp1006.pyo
-rw-r--r--  1 n9yty  wheel  11910 13 Sep  2003 cp1026.py
-rw-r--r--  1 n9yty  wheel   5766 13 Sep  2003 cp1026.pyc
-rw-r--r--  1 n9yty  wheel   5766 13 Sep  2003 cp1026.pyo
-rw-r--r--  1 n9yty  wheel    842 13 Sep  2003 cp1140.py
-rw-r--r--  1 n9yty  wheel   2336 13 Sep  2003 cp1140.pyc
-rw-r--r--  1 n9yty  wheel   2336 13 Sep  2003 cp1140.pyo
-rw-r--r--  1 n9yty  wheel   5196 13 Sep  2003 cp1250.py
-rw-r--r--  1 n9yty  wheel   3905 13 Sep  2003 cp1250.pyc
-rw-r--r--  1 n9yty  wheel   3905 13 Sep  2003 cp1250.pyo
-rw-r--r--  1 n9yty  wheel   6837 13 Sep  2003 cp1251.py
-rw-r--r--  1 n9yty  wheel   4575 13 Sep  2003 cp1251.pyc
-rw-r--r--  1 n9yty  wheel   4575 13 Sep  2003 cp1251.pyo
-rw-r--r--  1 n9yty  wheel   2444 13 Sep  2003 cp1252.py
-rw-r--r--  1 n9yty  wheel   3010 13 Sep  2003 cp1252.pyc
-rw-r--r--  1 n9yty  wheel   3010 13 Sep  2003 cp1252.pyo
-rw-r--r--  1 n9yty  wheel   6325 13 Sep  2003 cp1253.py
-rw-r--r--  1 n9yty  wheel   4379 13 Sep  2003 cp1253.pyc
-rw-r--r--  1 n9yty  wheel   4379 13 Sep  2003 cp1253.pyo
-rw-r--r--  1 n9yty  wheel   2757 13 Sep  2003 cp1254.py
-rw-r--r--  1 n9yty  wheel   3114 13 Sep  2003 cp1254.pyc
-rw-r--r--  1 n9yty  wheel   3114 13 Sep  2003 cp1254.pyo
-rw-r--r--  1 n9yty  wheel   5341 13 Sep  2003 cp1255.py
-rw-r--r--  1 n9yty  wheel   4187 13 Sep  2003 cp1255.pyc
-rw-r--r--  1 n9yty  wheel   4187 13 Sep  2003 cp1255.pyo
-rw-r--r--  1 n9yty  wheel   4871 13 Sep  2003 cp1256.py
-rw-r--r--  1 n9yty  wheel   4037 13 Sep  2003 cp1256.pyc
-rw-r--r--  1 n9yty  wheel   4037 13 Sep  2003 cp1256.pyo
-rw-r--r--  1 n9yty  wheel   5449 13 Sep  2003 cp1257.py
-rw-r--r--  1 n9yty  wheel   3984 13 Sep  2003 cp1257.pyc
-rw-r--r--  1 n9yty  wheel   3984 13 Sep  2003 cp1257.pyo
-rw-r--r--  1 n9yty  wheel   3091 13 Sep  2003 cp1258.py
-rw-r--r--  1 n9yty  wheel   3256 13 Sep  2003 cp1258.pyc
-rw-r--r--  1 n9yty  wheel   3256 13 Sep  2003 cp1258.pyo
-rw-r--r--  1 n9yty  wheel  10863 13 Sep  2003 cp424.py
-rw-r--r--  1 n9yty  wheel   5877 13 Sep  2003 cp424.pyc
-rw-r--r--  1 n9yty  wheel   5877 13 Sep  2003 cp424.pyo
-rw-r--r--  1 n9yty  wheel   8026 13 Sep  2003 cp437.py
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp437.pyc
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp437.pyo
-rw-r--r--  1 n9yty  wheel  11920 13 Sep  2003 cp500.py
-rw-r--r--  1 n9yty  wheel   5728 13 Sep  2003 cp500.pyc
-rw-r--r--  1 n9yty  wheel   5728 13 Sep  2003 cp500.pyo
-rw-r--r--  1 n9yty  wheel   8065 13 Sep  2003 cp737.py
-rw-r--r--  1 n9yty  wheel   4818 13 Sep  2003 cp737.pyc
-rw-r--r--  1 n9yty  wheel   4818 13 Sep  2003 cp737.pyo
-rw-r--r--  1 n9yty  wheel   7997 13 Sep  2003 cp775.py
-rw-r--r--  1 n9yty  wheel   4623 13 Sep  2003 cp775.pyc
-rw-r--r--  1 n9yty  wheel   4623 13 Sep  2003 cp775.pyo
-rw-r--r--  1 n9yty  wheel   7875 13 Sep  2003 cp850.py
-rw-r--r--  1 n9yty  wheel   4368 13 Sep  2003 cp850.pyc
-rw-r--r--  1 n9yty  wheel   4368 13 Sep  2003 cp850.pyo
-rw-r--r--  1 n9yty  wheel   8174 13 Sep  2003 cp852.py
-rw-r--r--  1 n9yty  wheel   4638 13 Sep  2003 cp852.pyc
-rw-r--r--  1 n9yty  wheel   4638 13 Sep  2003 cp852.pyo
-rw-r--r--  1 n9yty  wheel   7790 13 Sep  2003 cp855.py
-rw-r--r--  1 n9yty  wheel   4818 13 Sep  2003 cp855.pyc
-rw-r--r--  1 n9yty  wheel   4818 13 Sep  2003 cp855.pyo
-rw-r--r--  1 n9yty  wheel   6554 13 Sep  2003 cp856.py
-rw-r--r--  1 n9yty  wheel   4502 13 Sep  2003 cp856.pyc
-rw-r--r--  1 n9yty  wheel   4502 13 Sep  2003 cp856.pyo
-rw-r--r--  1 n9yty  wheel   7808 13 Sep  2003 cp857.py
-rw-r--r--  1 n9yty  wheel   4378 13 Sep  2003 cp857.pyc
-rw-r--r--  1 n9yty  wheel   4378 13 Sep  2003 cp857.pyo
-rw-r--r--  1 n9yty  wheel   8067 13 Sep  2003 cp860.py
-rw-r--r--  1 n9yty  wheel   4573 13 Sep  2003 cp860.pyc
-rw-r--r--  1 n9yty  wheel   4573 13 Sep  2003 cp860.pyo
-rw-r--r--  1 n9yty  wheel   8051 13 Sep  2003 cp861.py
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp861.pyc
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp861.pyo
-rw-r--r--  1 n9yty  wheel   7630 13 Sep  2003 cp862.py
-rw-r--r--  1 n9yty  wheel   4718 13 Sep  2003 cp862.pyc
-rw-r--r--  1 n9yty  wheel   4718 13 Sep  2003 cp862.pyo
-rw-r--r--  1 n9yty  wheel   7924 13 Sep  2003 cp863.py
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp863.pyc
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp863.pyo
-rw-r--r--  1 n9yty  wheel   7747 13 Sep  2003 cp864.py
-rw-r--r--  1 n9yty  wheel   4724 13 Sep  2003 cp864.pyc
-rw-r--r--  1 n9yty  wheel   4724 13 Sep  2003 cp864.pyo
-rw-r--r--  1 n9yty  wheel   8046 13 Sep  2003 cp865.py
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp865.pyc
-rw-r--r--  1 n9yty  wheel   4583 13 Sep  2003 cp865.pyo
-rw-r--r--  1 n9yty  wheel   7972 13 Sep  2003 cp866.py
-rw-r--r--  1 n9yty  wheel   4828 13 Sep  2003 cp866.pyc
-rw-r--r--  1 n9yty  wheel   4828 13 Sep  2003 cp866.pyo
-rw-r--r--  1 n9yty  wheel   7606 13 Sep  2003 cp869.py
-rw-r--r--  1 n9yty  wheel   4732 13 Sep  2003 cp869.pyc
-rw-r--r--  1 n9yty  wheel   4732 13 Sep  2003 cp869.pyo
-rw-r--r--  1 n9yty  wheel   6675 13 Sep  2003 cp874.py
-rw-r--r--  1 n9yty  wheel   4683 13 Sep  2003 cp874.pyc
-rw-r--r--  1 n9yty  wheel   4683 13 Sep  2003 cp874.pyo
-rw-r--r--  1 n9yty  wheel  11692 13 Sep  2003 cp875.py
-rw-r--r--  1 n9yty  wheel   6112 13 Sep  2003 cp875.pyc
-rw-r--r--  1 n9yty  wheel   6112 13 Sep  2003 cp875.pyo
-rw-r--r--  1 n9yty  wheel   1750 13 Sep  2003 hex_codec.py
-rw-r--r--  1 n9yty  wheel   3776 13 Sep  2003 hex_codec.pyc
-rw-r--r--  1 n9yty  wheel   3654 13 Sep  2003 hex_codec.pyo
-rw-r--r--  1 n9yty  wheel   5486 13 Sep  2003 idna.py
-rw-r--r--  1 n9yty  wheel   5631 13 Sep  2003 idna.pyc
-rw-r--r--  1 n9yty  wheel   5631 13 Sep  2003 idna.pyo
-rw-r--r--  1 n9yty  wheel    909 13 Sep  2003 iso8859_1.py
-rw-r--r--  1 n9yty  wheel   2437 13 Sep  2003 iso8859_1.pyc
-rw-r--r--  1 n9yty  wheel   2437 13 Sep  2003 iso8859_1.pyo
-rw-r--r--  1 n9yty  wheel   3900 13 Sep  2003 iso8859_10.py
-rw-r--r--  1 n9yty  wheel   3316 13 Sep  2003 iso8859_10.pyc
-rw-r--r--  1 n9yty  wheel   3316 13 Sep  2003 iso8859_10.pyo
-rw-r--r--  1 n9yty  wheel   4567 13 Sep  2003 iso8859_13.py
-rw-r--r--  1 n9yty  wheel   3488 13 Sep  2003 iso8859_13.pyc
-rw-r--r--  1 n9yty  wheel   3488 13 Sep  2003 iso8859_13.pyo
-rw-r--r--  1 n9yty  wheel   3030 13 Sep  2003 iso8859_14.py
-rw-r--r--  1 n9yty  wheel   3036 13 Sep  2003 iso8859_14.pyc
-rw-r--r--  1 n9yty  wheel   3036 13 Sep  2003 iso8859_14.pyo
-rw-r--r--  1 n9yty  wheel   1396 13 Sep  2003 iso8859_15.py
-rw-r--r--  1 n9yty  wheel   2597 13 Sep  2003 iso8859_15.pyc
-rw-r--r--  1 n9yty  wheel   2597 13 Sep  2003 iso8859_15.pyo
-rw-r--r--  1 n9yty  wheel   4560 13 Sep  2003 iso8859_2.py
-rw-r--r--  1 n9yty  wheel   3524 13 Sep  2003 iso8859_2.pyc
-rw-r--r--  1 n9yty  wheel   3524 13 Sep  2003 iso8859_2.pyo
-rw-r--r--  1 n9yty  wheel   2914 13 Sep  2003 iso8859_3.py
-rw-r--r--  1 n9yty  wheel   3078 13 Sep  2003 iso8859_3.pyc
-rw-r--r--  1 n9yty  wheel   3078 13 Sep  2003 iso8859_3.pyo
-rw-r--r--  1 n9yty  wheel   4105 13 Sep  2003 iso8859_4.py
-rw-r--r--  1 n9yty  wheel   3384 13 Sep  2003 iso8859_4.pyc
-rw-r--r--  1 n9yty  wheel   3384 13 Sep  2003 iso8859_4.pyo
-rw-r--r--  1 n9yty  wheel   6476 13 Sep  2003 iso8859_5.py
-rw-r--r--  1 n9yty  wheel   4224 13 Sep  2003 iso8859_5.pyc
-rw-r--r--  1 n9yty  wheel   4224 13 Sep  2003 iso8859_5.pyo
-rw-r--r--  1 n9yty  wheel   4383 13 Sep  2003 iso8859_6.py
-rw-r--r--  1 n9yty  wheel   3994 13 Sep  2003 iso8859_6.pyc
-rw-r--r--  1 n9yty  wheel   3994 13 Sep  2003 iso8859_6.pyo
-rw-r--r--  1 n9yty  wheel   5541 13 Sep  2003 iso8859_7.py
-rw-r--r--  1 n9yty  wheel   3940 13 Sep  2003 iso8859_7.pyc
-rw-r--r--  1 n9yty  wheel   3940 13 Sep  2003 iso8859_7.pyo
-rw-r--r--  1 n9yty  wheel   3345 13 Sep  2003 iso8859_8.py
-rw-r--r--  1 n9yty  wheel   3552 13 Sep  2003 iso8859_8.pyc
-rw-r--r--  1 n9yty  wheel   3552 13 Sep  2003 iso8859_8.pyo
-rw-r--r--  1 n9yty  wheel   1304 13 Sep  2003 iso8859_9.py
-rw-r--r--  1 n9yty  wheel   2551 13 Sep  2003 iso8859_9.pyc
-rw-r--r--  1 n9yty  wheel   2551 13 Sep  2003 iso8859_9.pyo
-rw-r--r--  1 n9yty  wheel   8676 13 Sep  2003 koi8_r.py
-rw-r--r--  1 n9yty  wheel   4826 13 Sep  2003 koi8_r.pyc
-rw-r--r--  1 n9yty  wheel   4826 13 Sep  2003 koi8_r.pyo
-rw-r--r--  1 n9yty  wheel   1528 13 Sep  2003 koi8_u.py
-rw-r--r--  1 n9yty  wheel   2588 13 Sep  2003 koi8_u.pyc
-rw-r--r--  1 n9yty  wheel   2588 13 Sep  2003 koi8_u.pyo
-rw-r--r--  1 n9yty  wheel    737 13 Sep  2003 latin_1.py
-rw-r--r--  1 n9yty  wheel   1980 13 Sep  2003 latin_1.pyc
-rw-r--r--  1 n9yty  wheel   1980 13 Sep  2003 latin_1.pyo
-rw-r--r--  1 n9yty  wheel   7209 13 Sep  2003 mac_cyrillic.py
-rw-r--r--  1 n9yty  wheel   4755 13 Sep  2003 mac_cyrillic.pyc
-rw-r--r--  1 n9yty  wheel   4755 13 Sep  2003 mac_cyrillic.pyo
-rw-r--r--  1 n9yty  wheel   7567 13 Sep  2003 mac_greek.py
-rw-r--r--  1 n9yty  wheel   4657 13 Sep  2003 mac_greek.pyc
-rw-r--r--  1 n9yty  wheel   4657 13 Sep  2003 mac_greek.pyo
-rw-r--r--  1 n9yty  wheel   7234 13 Sep  2003 mac_iceland.py
-rw-r--r--  1 n9yty  wheel   4377 13 Sep  2003 mac_iceland.pyc
-rw-r--r--  1 n9yty  wheel   4377 13 Sep  2003 mac_iceland.pyo
-rw-r--r--  1 n9yty  wheel   8013 13 Sep  2003 mac_latin2.py
-rw-r--r--  1 n9yty  wheel   4676 13 Sep  2003 mac_latin2.pyc
-rw-r--r--  1 n9yty  wheel   4676 13 Sep  2003 mac_latin2.pyo
-rw-r--r--  1 n9yty  wheel   7273 13 Sep  2003 mac_roman.py
-rw-r--r--  1 n9yty  wheel   4405 13 Sep  2003 mac_roman.pyc
-rw-r--r--  1 n9yty  wheel   4405 13 Sep  2003 mac_roman.pyo
-rw-r--r--  1 n9yty  wheel   7297 13 Sep  2003 mac_turkish.py
-rw-r--r--  1 n9yty  wheel   4421 13 Sep  2003 mac_turkish.pyc
-rw-r--r--  1 n9yty  wheel   4421 13 Sep  2003 mac_turkish.pyo
-rw-r--r--  1 n9yty  wheel    810 13 Sep  2003 mbcs.py
-rw-r--r--  1 n9yty  wheel   2035 13 Sep  2003 mbcs.pyc
-rw-r--r--  1 n9yty  wheel   2035 13 Sep  2003 mbcs.pyo
-rw-r--r--  1 n9yty  wheel   2385 13 Sep  2003 palmos.py
-rw-r--r--  1 n9yty  wheel   2849 13 Sep  2003 palmos.pyc
-rw-r--r--  1 n9yty  wheel   2849 13 Sep  2003 palmos.pyo
-rw-r--r--  1 n9yty  wheel   6180 13 Sep  2003 punycode.py
-rw-r--r--  1 n9yty  wheel   9969 13 Sep  2003 punycode.pyc
-rw-r--r--  1 n9yty  wheel   9969 13 Sep  2003 punycode.pyo
-rw-r--r--  1 n9yty  wheel   1552 13 Sep  2003 quopri_codec.py
-rw-r--r--  1 n9yty  wheel   3736 13 Sep  2003 quopri_codec.pyc
-rw-r--r--  1 n9yty  wheel   3614 13 Sep  2003 quopri_codec.pyo
-rw-r--r--  1 n9yty  wheel    648 13 Sep  2003 raw_unicode_escape.py
-rw-r--r--  1 n9yty  wheel   1679 13 Sep  2003 raw_unicode_escape.pyc
-rw-r--r--  1 n9yty  wheel   1679 13 Sep  2003 raw_unicode_escape.pyo
-rw-r--r--  1 n9yty  wheel   2031 13 Sep  2003 rot_13.py
-rw-r--r--  1 n9yty  wheel   3515 13 Sep  2003 rot_13.pyc
-rw-r--r--  1 n9yty  wheel   3515 13 Sep  2003 rot_13.pyo
-rw-r--r--  1 n9yty  wheel    422 13 Sep  2003 string_escape.py
-rw-r--r--  1 n9yty  wheel   1563 13 Sep  2003 string_escape.pyc
-rw-r--r--  1 n9yty  wheel   1563 13 Sep  2003 string_escape.pyo
-rw-r--r--  1 n9yty  wheel    792 13 Sep  2003 undefined.py
-rw-r--r--  1 n9yty  wheel   2255 13 Sep  2003 undefined.pyc
-rw-r--r--  1 n9yty  wheel   2255 13 Sep  2003 undefined.pyo
-rw-r--r--  1 n9yty  wheel    636 13 Sep  2003 unicode_escape.py
-rw-r--r--  1 n9yty  wheel   1647 13 Sep  2003 unicode_escape.pyc
-rw-r--r--  1 n9yty  wheel   1647 13 Sep  2003 unicode_escape.pyo
-rw-r--r--  1 n9yty  wheel    642 13 Sep  2003 unicode_internal.py
-rw-r--r--  1 n9yty  wheel   1663 13 Sep  2003 unicode_internal.pyc
-rw-r--r--  1 n9yty  wheel   1663 13 Sep  2003 unicode_internal.pyo
-rw-r--r--  1 n9yty  wheel   1903 13 Sep  2003 utf_16.py
-rw-r--r--  1 n9yty  wheel   3811 13 Sep  2003 utf_16.pyc
-rw-r--r--  1 n9yty  wheel   3811 13 Sep  2003 utf_16.pyo
-rw-r--r--  1 n9yty  wheel    730 13 Sep  2003 utf_16_be.py
-rw-r--r--  1 n9yty  wheel   1915 13 Sep  2003 utf_16_be.pyc
-rw-r--r--  1 n9yty  wheel   1915 13 Sep  2003 utf_16_be.pyo
-rw-r--r--  1 n9yty  wheel    730 13 Sep  2003 utf_16_le.py
-rw-r--r--  1 n9yty  wheel   1915 13 Sep  2003 utf_16_le.pyc
-rw-r--r--  1 n9yty  wheel   1915 13 Sep  2003 utf_16_le.pyo
-rw-r--r--  1 n9yty  wheel    550 13 Sep  2003 utf_7.py
-rw-r--r--  1 n9yty  wheel   1516 13 Sep  2003 utf_7.pyc
-rw-r--r--  1 n9yty  wheel   1516 13 Sep  2003 utf_7.pyo
-rw-r--r--  1 n9yty  wheel    609 13 Sep  2003 utf_8.py
-rw-r--r--  1 n9yty  wheel   1575 13 Sep  2003 utf_8.pyc
-rw-r--r--  1 n9yty  wheel   1575 13 Sep  2003 utf_8.pyo
-rw-r--r--  1 n9yty  wheel   3152 13 Sep  2003 uu_codec.py
-rw-r--r--  1 n9yty  wheel   5149 13 Sep  2003 uu_codec.pyc
-rw-r--r--  1 n9yty  wheel   5027 13 Sep  2003 uu_codec.pyo
-rw-r--r--  1 n9yty  wheel   1793 13 Sep  2003 zlib_codec.py
-rw-r--r--  1 n9yty  wheel   3774 13 Sep  2003 zlib_codec.pyc
-rw-r--r--  1 n9yty  wheel   3652 13 Sep  2003 zlib_codec.pyo

BitPim.app/Contents/Resources/resources:
total 3232
-rw-r--r--  1 n9yty  wheel      956  6 Apr  2004 bitfling.png
-rw-r--r--  1 n9yty  wheel      432  9 Sep  2003 bitpim.css
-rw-r--r--  1 n9yty  wheel  1349728 28 Sep 14:40 bitpim.htb
-rw-r--r--  1 n9yty  wheel      560 12 Apr 08:36 bitpim_usb.ids
-rw-r--r--  1 n9yty  wheel      456 25 Jan  2004 mozilla.pdc
-rw-r--r--  1 n9yty  wheel      241  4 Nov  2003 palm.pdc
-rw-r--r--  1 n9yty  wheel     3833 23 Aug 10:34 pblayout.xy
-rw-r--r--  1 n9yty  wheel      563  6 Feb  2004 pbpl-view.xy
-rw-r--r--  1 n9yty  wheel       23  1 Feb  2004 pbps-colourful.xy
-rw-r--r--  1 n9yty  wheel      104  5 Feb  2004 pbps-ledger.xy
-rw-r--r--  1 n9yty  wheel    43520 25 Aug 13:57 pic05.jpg
-rw-r--r--  1 n9yty  wheel     1044 13 Nov  2003 private.png
-rw-r--r--  1 n9yty  wheel      831 15 Aug  2003 ringer.png
-rw-r--r--  1 n9yty  wheel       18  5 Apr  2004 ringtone-style.xy
-rw-r--r--  1 n9yty  wheel      672 18 Apr 01:57 ringtone.xy
-rw-r--r--  1 n9yty  wheel    48958  8 Sep  2003 splashscreen.jpg
-rw-r--r--  1 n9yty  wheel     3625 23 Aug 10:34 styles.xy
-rw-r--r--  1 n9yty  wheel     1773  5 Mar  2003 unknown.png
-rw-r--r--  1 n9yty  wheel   125975  4 Jul 01:32 usb.ids
-rw-r--r--  1 n9yty  wheel      689 18 Aug 03:21 usb_needdriver.ids
-rw-r--r--  1 n9yty  wheel       18  9 Feb  2004 wallpaper-style.xy
-rw-r--r--  1 n9yty  wheel     4507 13 Nov  2003 wallpaper.png
-rw-r--r--  1 n9yty  wheel      682 18 Apr 01:57 wallpaper.xy


From bob at redivi.com  Wed Oct  6 23:06:48 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct  6 23:07:28 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <E767DE43-17D7-11D9-A51D-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
	<9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
	<3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
	<E767DE43-17D7-11D9-A51D-000D9335B6B6@n9yty.com>
Message-ID: <A337FB94-17DB-11D9-A1CC-000A95686CD8@redivi.com>


On Oct 6, 2004, at 4:40 PM, Steven Palm wrote:

> On Oct 6, 2004, at 2:45 PM, Bob Ippolito wrote:
>> I'll see if I can change sys.path[0] without breaking anything useful.
>
>  Thanks. Honestly, I don't know which is more "intuitive" or "better", 
>  you're in a much better position than I am to make a decision about 
> what is generally a "better" idea for most people.
>
>>>  On the other hand, the bundlebuilder process produces a 15MB 
>>> package, while the py2app package is about 40MB, so maybe it's not 
>>> time to switch yet until you are able to strip out unneeded parts of 
>>> referenced modules.
>>
>> Probably because the bundlebuilder process isn't embedding everything 
>> it actually needs,
>
>  Well, it does run fine on virgin systems that have no non-standard 
> components installed. However, if py2app is bundling in a whole python 
> distribution and bundlebuilder is relying on the system install, then 
> it would explain it.

That depends on if you're using the vendor provided Python or not.  In 
this case it is using the vendor provided Python.  It seems that the 
only possible explanation for the missing 25MB is that py2app is not 
stripping debugging symbols from the included extensions and dylibs 
(particularly wx).  I'll add an option to do that, but until then you 
can do something like :
find BitPim.app -name "*.so" -or -name "*.dylib" -exec strip {} \;

and see if that makes a difference.

>>  or you're including too many packages explicitly without reason.
>
>  Not sure, most of the code is Roger's.

I was referring to the setup.py

>>   Either that or there's a WHOLE LOT of python code and you should 
>> turn on zip compression.  I can't know unless I can see a ls -lR of 
>> what went in there or something.  If I don't get this kind of 
>> assistance from users like you then py2app will likely never suit 
>> your needs, so don't throw it away yet .. it's probably a trivial 
>> fix.
>
>  I'm not about to throw it away, you've worked too hard on it. ;-)  I 
> jumped on the testing bandwagon when I saw your announcement precisely 
> because I wanted to provide feedback on how it works for random app 
> out in the wild.
>
>  By the way, I cannot get the "dist_dir" option to use the directory 
> specified, the output bundle always goes in my current directory 
> (where setup.py is).

dist_dir isn't what you think it is.. I'm using the same semantics as 
py2exe (which I don't particularly like, so that may change).  In order 
to change the resultant executable destination you have to do:

setup(
	app = [
		dict(script="myscript.py", dest_base="./dist"),
	],
)

  BitPim.app/Contents/Resources/Python/lib-dynload/native/usb

>  One more issue is that some package parts are loaded dynamically, 
> such as this:
>
> dlg=CommPortDialog(self, 
> __import__(self.phonemodels[self.phonebox.GetValue()]), 
> defaultport=self.commbox.GetValue(), sashposition=p)
>
>  It complains that it cannot find the module referenced by 
> self.phonemodels[self.phonebox.GetValue()]).
>
>  For bundlebuilder, I was doing this:
>
>     coms=glob.glob("com_*.py")
>     for c in coms:
>         myapp.includePackages.append(c[:-3])
>
>  For py2app, I was just using passing a build includePackages list in 
> via the "packages" element in the options dict. I cannot find the 
> comm_* files anywhere in the generated bundle, in the 
> site_packages.zip file or outside of it. They are included as:
>
>     options = dict(p2app=dict(
>                  optimize=2,
>                  dist_dir="./dist/",
>                  compress=1,
>                  packages=includePackages,
>                  includes=data_files,
>                  iconfile=iconfile,
>                  plist=plist))
>
>  where includePackages is built above.

There are several problems with this:
There is a typo in the options dict.. it should be:
dict(py2app=dict(

dist_dir doesn't do what you think it does (as stated above).

packages are python packages (as in, folders with __init__.py).  That 
should be includes instead.

includes is not for data files.  data_files should be passed to the 
setup function directly.

>  Also, the dependencies checker seems to be missing the fact that 
> libusb must be included... I see it coming up with a libusb.so, but 
> that's just the SWWIG generated stub, I think, in bundlebuilder I had 
> to include the dylib itself.

Can you show me the output of:
otool -Lv 
BitPim.app/Contents/Resources/Python/lib-dynload/native/usb/_libusb.so

Where is this usb package and how do I build it so I can see what it's 
doing?

btw - svn trunk includes the encodings package instead of including it 
as a package.. so that gets rid of a bunch of files and should save 1mb 
or so (before compression).

-bob
From sw at wordtech-software.com  Wed Oct  6 23:36:43 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Wed Oct  6 23:36:47 2004
Subject: [Pythonmac-SIG] Subdirectories in py2app?
Message-ID: <4164656B.3020307@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been trying to build wxglade with py2app, but it does not seem to
copy any of the subdirectories (/bitmaps, /codegen, /widgets, etc.
Wouldn't it scan the current working directory of the setup script to
copy these materials over?

Also, adding these folders and files manually to the app bundle after
it's generated (to the resources directory) doesn't seem to work. The
app bounces in the dock and dies silently with no output to console.

I know documentation hasn't been written yet, but is there more that
needs to be added to the setup.py script apart from the main application
file (setup (wxglade.py)?

- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZGVqJmdQs+6YVcoRAj+BAJ9J7kTvlzVqYgoBUW/YwmrmJwmXgQCfeYKQ
jUXi9lXF+E/SQhrrOOJgRII=
=vAq1
-----END PGP SIGNATURE-----
From bob at redivi.com  Thu Oct  7 02:31:22 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct  7 02:31:56 2004
Subject: [Pythonmac-SIG] Subdirectories in py2app?
In-Reply-To: <4164656B.3020307@wordtech-software.com>
References: <4164656B.3020307@wordtech-software.com>
Message-ID: <36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>


On Oct 6, 2004, at 5:36 PM, Kevin Walzer wrote:

> I've been trying to build wxglade with py2app, but it does not seem to
> copy any of the subdirectories (/bitmaps, /codegen, /widgets, etc.
> Wouldn't it scan the current working directory of the setup script to
> copy these materials over?

No, py2app most certainly does not assume that everything in the 
current directory should go in the app bundle.

> Also, adding these folders and files manually to the app bundle after
> it's generated (to the resources directory) doesn't seem to work. The
> app bounces in the dock and dies silently with no output to console.

I have no idea.. when you do strange things you get strange results :)

> I know documentation hasn't been written yet, but is there more that
> needs to be added to the setup.py script apart from the main 
> application
> file (setup (wxglade.py)?

After having looked at wxGlade, it does a large number of things that 
make it quite hard to bundle up in any fashion (it's too dynamic).. the 
big two are:

- it expects to load code and data from the same place on the filesystem
- it loads lots of code dynamically, only from the filesystem

Basically what's needed is a packaged-application specific bootstrap 
for wxGlade that does all of its code loading statically (new modules 
surely aren't going to show up at runtime), and patch some globals in 
common.py accordingly (it looks like the only source of this).. or else 
you will have to specify the widgets and code writers *as* data files 
and specify all of their dependencies explicitly.

-bob
From sw at wordtech-software.com  Thu Oct  7 02:57:44 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Thu Oct  7 02:57:47 2004
Subject: [Pythonmac-SIG] Subdirectories in py2app?
In-Reply-To: <36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>
References: <4164656B.3020307@wordtech-software.com>
	<36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>
Message-ID: <41649488.4000409@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hmmmm...OK, I'll see what I can do.

For what it's worth, wxGlade runs fine when packaged as an applet (in
that context, I save wxglade.py as an applet from Python IDE and then do
what I outlined earlier--add all the other files to the bundle
manually). It doesn't function as a standalone, obviously, because I
haven't added the wxPython libraries, but it runs fine when wxPython is
correctly installed.

So, I'll see if I can give your suggestion a try. I'll also see if
py2applet works. Barring that, I'll leave it as a "hacked applet." :-)

Thanks,
Kevin



Bob Ippolito wrote:

|
| On Oct 6, 2004, at 5:36 PM, Kevin Walzer wrote:
|
|> I've been trying to build wxglade with py2app, but it does not seem to
|> copy any of the subdirectories (/bitmaps, /codegen, /widgets, etc.
|> Wouldn't it scan the current working directory of the setup script to
|> copy these materials over?
|
|
| No, py2app most certainly does not assume that everything in the current
| directory should go in the app bundle.
|
|> Also, adding these folders and files manually to the app bundle after
|> it's generated (to the resources directory) doesn't seem to work. The
|> app bounces in the dock and dies silently with no output to console.
|
|
| I have no idea.. when you do strange things you get strange results :)
|
|> I know documentation hasn't been written yet, but is there more that
|> needs to be added to the setup.py script apart from the main application
|> file (setup (wxglade.py)?
|
|
| After having looked at wxGlade, it does a large number of things that
| make it quite hard to bundle up in any fashion (it's too dynamic).. the
| big two are:
|
| - it expects to load code and data from the same place on the filesystem
| - it loads lots of code dynamically, only from the filesystem
|
| Basically what's needed is a packaged-application specific bootstrap for
| wxGlade that does all of its code loading statically (new modules surely
| aren't going to show up at runtime), and patch some globals in common.py
| accordingly (it looks like the only source of this).. or else you will
| have to specify the widgets and code writers *as* data files and specify
| all of their dependencies explicitly.
|
| -bob
|
|


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZJSHJmdQs+6YVcoRAv/2AJ430CEuEoZS45gcs2JFKTLPgdK77QCbBgQ1
9YGRrGkXtqDbqknsa0khNZg=
=+gaO
-----END PGP SIGNATURE-----
From n9yty at n9yty.com  Thu Oct  7 04:07:50 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Thu Oct  7 04:07:55 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <A337FB94-17DB-11D9-A1CC-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
	<9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
	<3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
	<E767DE43-17D7-11D9-A51D-000D9335B6B6@n9yty.com>
	<A337FB94-17DB-11D9-A1CC-000A95686CD8@redivi.com>
Message-ID: <B097BFA4-1805-11D9-8054-000D9335B6B6@n9yty.com>


On Oct 6, 2004, at 4:06 PM, Bob Ippolito wrote:
> find BitPim.app -name "*.so" -or -name "*.dylib" -exec strip {} \;

  That didn't change the bundle size, so obviously that's not it. Maybe  
it's not a huge deal, I'll come back to this one later. ;-)  It's  
obviously putting more in the bundle because when I make a compressed  
disk image (as I did after bundlebuilder as well), the size is almost  
twice as big (14MB as opposed to ~7MB before).

>>>  or you're including too many packages explicitly without reason.
>>
>>  Not sure, most of the code is Roger's.
>
> I was referring to the setup.py

  Here is my new base setup.py:

     from distutils.core import setup
     import py2app
     import string
     packageroot="."
     name = "BitPim"
     iconfile = "bitpim.icns"
     v=getsubs()
     data_files=[]
     includes=[]
     includePackages=[]
     verstr = "%s-%s" % (v['NAME'], v['VERSION'])
     for dir,files in resources():
         for file in files:
             fname = os.path.basename(file)
             data_files.append( os.path.join(dir, fname))
     coms=glob.glob("com_*.py")
     for c in coms:
         includes.append(c[:-3])
     plist = dict(
         CFBundleIconFile            = iconfile,
         CFBundleName                = name,
         CFBundleShortVersionString  = verstr,
         CFBundleGetInfoString       = '-'.join([name, verstr]),
         CFBundleExecutable          = name,
         CFBundleIdentifier          = 'net.sourceforge.bitpim',
     )
     opts = dict(py2app=dict(
                  iconfile=iconfile,
                  plist=plist,
                  includes=includes
                  ))
     app = [ dict(
                  plist=plist,
                  script="bp.py",
                  ),]
     setup( data_files = [ ('resources', data_files) ], options = opts,   
app = ap
p,)

  If I turn on "optimize=2", I get this failure when building:

Traceback (most recent call last):
   File "setup.py", line 415, in ?
     macbuild()
   File "setup.py", line 394, in macbuild
     setup( data_files = [ ('resources', data_files) ], options = opts,   
app = app,)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/distutils/core.py", line 149, in setup
     dist.run_commands()
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/distutils/dist.py", line 907, in run_commands
     self.run_command(cmd)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/distutils/dist.py", line 927, in run_command
     cmd_obj.run()
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/py2app/build_app.py", line 214, in run
     self._run()
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/py2app/build_app.py", line 310, in _run
     self.create_binaries(new_py_files, pkgdirs, extensions, mm)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/py2app/build_app.py", line 373, in  
create_binaries
     dry_run=self.dry_run)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/py2app/util.py", line 117, in byte_compile
     spawn(cmd, verbose=verbose, dry_run=dry_run)
NameError: global name 'spawn' is not defined

> dist_dir isn't what you think it is.. I'm using the same semantics as  
> py2exe (which I don't particularly like, so that may change).  In  
> order to change the resultant executable destination you have to do:
>
> setup(
> 	app = [
> 		dict(script="myscript.py", dest_base="./dist"),
> 	],
> )

I couldn't get dest_base to work, I just do this:

     os.system('mv ./BitPim.app ./dist');

>  BitPim.app/Contents/Resources/Python/lib-dynload/native/usb
>
>>  One more issue is that some package parts are loaded dynamically,  
>> such as this:
>>
>> dlg=CommPortDialog(self,  
>> __import__(self.phonemodels[self.phonebox.GetValue()]),  
>> defaultport=self.commbox.GetValue(), sashposition=p)
>>
>>  It complains that it cannot find the module referenced by  
>> self.phonemodels[self.phonebox.GetValue()]).
>>
>>  For bundlebuilder, I was doing this:
>>
>>     coms=glob.glob("com_*.py")
>>     for c in coms:
>>         myapp.includePackages.append(c[:-3])
>>
>>  For py2app, I was just using passing a build includePackages list in  
>> via the "packages" element in the options dict. I cannot find the  
>> comm_* files anywhere in the generated bundle, in the  
>> site_packages.zip file or outside of it. They are included as:
>>
>>     options = dict(p2app=dict(
>>                  optimize=2,
>>                  dist_dir="./dist/",
>>                  compress=1,
>>                  packages=includePackages,
>>                  includes=data_files,
>>                  iconfile=iconfile,
>>                  plist=plist))
>>
>>  where includePackages is built above.
>
> There are several problems with this:
> There is a typo in the options dict.. it should be:
> dict(py2app=dict(

  That fixed that. ;-)

>>  Also, the dependencies checker seems to be missing the fact that  
>> libusb must be included... I see it coming up with a libusb.so, but  
>> that's just the SWWIG generated stub, I think, in bundlebuilder I had  
>> to include the dylib itself.
>
> Can you show me the output of:
> otool -Lv  
> BitPim.app/Contents/Resources/Python/lib-dynload/native/usb/_libusb.so

_libusb.so:
         /System/Library/Frameworks/Python.framework/Versions/2.3/Python  
(compatibility version 2.3.0, current version 2.3.0)
         time stamp 1092103224 Mon Aug  9 21:00:24 2004
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 71.1.1)
         time stamp 1085619810 Wed May 26 20:03:30 2004

I guess when that was built it compiled in what it needed from libusb,  
I had both a static and shared version of that available.

> Where is this usb package and how do I build it so I can see what it's  
> doing?

The library is at libusb.sourceforge.net, but obviously you don't have  
to spend much time on it, as I was mistaken about it being needed.

> btw - svn trunk includes the encodings package instead of including it  
> as a package.. so that gets rid of a bunch of files and should save  
> 1mb or so (before compression).

  I get this when using the trunk version:

Traceback (most recent call last):
   File  
"/usr/local/src/bitpim/bitpim/dist/BitPim.app/Contents/Resources/ 
__boot__.py", line 26, in ?
     _run('bp.py')
   File  
"/usr/local/src/bitpim/bitpim/dist/BitPim.app/Contents/Resources/ 
__boot__.py", line 23, in _run
     execfile(os.path.join(base, 'Python', script), globals(), globals())
   File  
"/usr/local/src/bitpim/bitpim/dist/BitPim.app/Contents/Resources/ 
Python/bp.py", line 75, in ?
     import gui
   File "gui.pyc", line 23, in ?
   File "wx/__init__.pyc", line 42, in ?
   File "wx/_core.pyc", line 4, in ?
   File "wx/_core_.pyc", line 18, in ?
   File "wx/_core_.pyc", line 15, in __load
ImportError:  
'/usr/local/src/bitpim/bitpim/dist/BitPim.app/Contents/Resources/ 
Python/lib-dynload/wx/_core_.so' not found
2004-10-06 20:51:28.492 BitPim[1121] BitPim Error
2004-10-06 20:51:28.492 BitPim[1121] An unexpected error has occurred  
during execution of the main script

ImportError:  
'/usr/local/src/bitpim/bitpim/dist/BitPim.app/Contents/Resources/ 
Python/lib-dynload/wx/_core_.so' not found

  Finally, back to a real basic question...

  Is there a way in the script which contains the setup() call to  
actually have it build the bundle without having to specifically  
provide the py2app parameter on the command line? BitPim uses a  
"makedist.py" file to build for all three platforms, and in the past  
you would just issue "python makedist.py" to build it, it would be nice  
if you didn't have to give the Mac additional parameters.  I see Roger  
is using py2exe to build the Windows version, but he has a sub-config  
file and is spawning a subshell from makedist.py with a new python  
interpreter to run it. That seems ugly. ;-)

  Thanks!


From n9yty at n9yty.com  Thu Oct  7 04:30:43 2004
From: n9yty at n9yty.com (Steven Palm)
Date: Thu Oct  7 04:30:48 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <B097BFA4-1805-11D9-8054-000D9335B6B6@n9yty.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<1BF48EEC-1742-11D9-A51D-000D9335B6B6@n9yty.com>
	<2767B0C8-1744-11D9-88CF-000A95686CD8@redivi.com>
	<28CAB87E-17A5-11D9-A51D-000D9335B6B6@n9yty.com>
	<7B5A29CC-17A6-11D9-890A-000A95686CD8@redivi.com>
	<DD511F05-17AD-11D9-A51D-000D9335B6B6@n9yty.com>
	<B1B9777B-17B0-11D9-890A-000A95686CD8@redivi.com>
	<08131635-17B7-11D9-A51D-000D9335B6B6@n9yty.com>
	<CF384986-17B9-11D9-890A-000A95686CD8@redivi.com>
	<9199E1D7-17CA-11D9-A51D-000D9335B6B6@n9yty.com>
	<3D70DB6C-17D0-11D9-A1CC-000A95686CD8@redivi.com>
	<E767DE43-17D7-11D9-A51D-000D9335B6B6@n9yty.com>
	<A337FB94-17DB-11D9-A1CC-000A95686CD8@redivi.com>
	<B097BFA4-1805-11D9-8054-000D9335B6B6@n9yty.com>
Message-ID: <E37BD9F4-1808-11D9-8054-000D9335B6B6@n9yty.com>


On Oct 6, 2004, at 9:07 PM, Steven Palm wrote:
>  Finally, back to a real basic question...
>
>  Is there a way in the script which contains the setup() call to 
> actually have it build the bundle without having to specifically 
> provide the py2app parameter on the command line? BitPim uses a 
> "makedist.py" file to build for all three platforms, and in the past 
> you would just issue "python makedist.py" to build it, it would be 
> nice if you didn't have to give the Mac additional parameters.  I see 
> Roger is using py2exe to build the Windows version, but he has a 
> sub-config file and is spawning a subshell from makedist.py with a new 
> python interpreter to run it. That seems ugly. ;-)

  I found an answer to this one:

setup( data_files = [ ('resources', data_files) ], options = opts,  app 
= ap
p, script_args = ("py2app",) )

  Just passing it along for the archives.


From whamoo at rknet.it  Thu Oct  7 11:50:12 2004
From: whamoo at rknet.it (whamoo)
Date: Thu Oct  7 11:49:41 2004
Subject: [Pythonmac-SIG] Question about pyobjc and cocoa "Dialog" (for
	cococadialog.py)
Message-ID: <48A19243-1846-11D9-823F-000A95C62238@rknet.it>

Hi to all,

I've written the code for use in python some cocoa dialog like 
NSOpenPanel/SavePanel, and NSAlert, but cocoa has a "dialog" for
interacting with user input? Like AskString of EasyDialogs?
And what other dialogs can be usefull?

Thanks a lot

Whamoo www.rknet.it
Powered by:
- MacOsX
- Gnu / Linux Debian Sarge
- Amiga Os 3.9
- Milk

From cohar at conncoll.edu  Wed Oct  6 14:31:58 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Thu Oct  7 12:50:10 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
Message-ID: <B70AD09A-1793-11D9-BC97-000393A37396@conncoll.edu>

I apologize for a really lame question -- but where do I put the (now) 
py2app-0.1.1 folder when I've downloaded it? Should I be trying to make 
an .app file of py2app itself? If I put the folder in  
/Library/Python/2.3 with other packages like wxPython and Numeric, and 
try the Terminal command 'python setup.py py2app', I get the errmsg 
"invalid command 'py2app' (no module named 'distutils.command.py2app'". 
If I just double-lick the 'setup.py' file in (for instance) 
.../py2app-0.1.1/examples/wxPython/doodle, I get "no module named 
py2app". Same message if I navigate to .../tools/py2applet and use 
"python setup.py py2app".

So I can see I'm doing something really *basically* stupid here, but 
none of the logical (?) alternatives I've tried gives me an error 
message with enough of a hint to steer me. Sorry; I know the inside of 
Python, however poorly, a lot better than the outside.

Charles Hartman


> py2app should pretty much just work if you give it your script.  I 
> don't have wxPython on this machine so I can't tell if anything 
> special needs to be done or not, but I'm relatively certain it should 
> Just Work if memory serves correctly.  Look at the examples directory.
>
> -bob
>

From cohar at conncoll.edu  Wed Oct  6 16:38:44 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Thu Oct  7 12:50:11 2004
Subject: [Pythonmac-SIG] Trying to make an app
In-Reply-To: <4091FB2E-17A1-11D9-B2E0-000A95686CD8@redivi.com>
References: <9B2E7CC0-1723-11D9-BC97-000393A37396@conncoll.edu>
	<823772F5-173E-11D9-88CF-000A95686CD8@redivi.com>
	<B70AD09A-1793-11D9-BC97-000393A37396@conncoll.edu>
	<4091FB2E-17A1-11D9-B2E0-000A95686CD8@redivi.com>
Message-ID: <6CC6BA0D-17A5-11D9-BC97-000393A37396@conncoll.edu>


On Oct 6, 2004, at 10:08 AM, Bob Ippolito wrote:

> Same way you install just about anything else for Python..
>
> % cd py2app-0.1.1
> % sudo python setup.py install
>
> -bob


Thank you.

Charles Hartman

From bob at redivi.com  Thu Oct  7 21:51:11 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct  7 21:51:46 2004
Subject: [Distutils] Re: [Pythonmac-SIG] Re: ANN: py2app 0.1.1
In-Reply-To: <rowen-EB6BD0.12381107102004@sea.gmane.org>
References: <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>
	<rowen-D1B0F4.12344706102004@sea.gmane.org>
	<552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com>
	<rowen-EB6BD0.12381107102004@sea.gmane.org>
Message-ID: <3D3C89B4-189A-11D9-AB63-000A95686CD8@redivi.com>


On Oct 7, 2004, at 3:38 PM, Russell E. Owen wrote:

> In article <552D13C8-17CF-11D9-A1CC-000A95686CD8@redivi.com>,
>  Bob Ippolito <bob@redivi.com> wrote:
>
>> On Oct 6, 2004, at 3:34 PM, Russell E. Owen wrote:
>> ..
>>> In article <BAA61254-1759-11D9-88CF-000A95686CD8@redivi.com>,
>>>  Bob Ippolito <bob@redivi.com> wrote:
>>> ...
>>> - As an extension to that question...any hints on installing tcl
>>> extensions ("snack", specifically) into such a bundled app?
>>
>> No idea, give me instructions on how to do it and a minimal example
>> that uses it and I'll see what can be done.
>
> Aqua Tcl extensions live in /Library/Tcl, typically each in its own
> subfolder. For example snack lives in /Library/Tcl/snack2.2/
>
> When bundled, Tcl can find extensions in
> Contents/Frameworks/Tcl.framework/Resources/
> e.g. for snack:
> Contents/Frameworks/Tcl.framework/Resources/snack2.2/
>
> (That may not be the best location, but it works. I found it by trial
> and error.).
>
> I can put together a sample app and send it along separately if you 
> like.

I'm more interested in having a development environment that mirrors 
yours to see if it's possible or reasonable to find usage of snack 
automatically.  Depending on how Tcl extensions are linked, it might be 
necessary to rewrite their mach headers (or else you can, in theory, 
get the same "version mismatch" problem that Python has).

If Tcl can find extensions in 
Contents/Frameworks/Tcl.framework/Resources when *not* bundled, that 
might be a good place to put them.. because py2app makes little attempt 
to strip down frameworks other than Python.framework.  For versioned 
frameworks, it will skip the versions you are not linking to, but 
everything in that version (and anything outside of versioned 
directories) will be copied.

-bob
From rowen at cesmail.net  Thu Oct  7 22:06:21 2004
From: rowen at cesmail.net (Russell E. Owen)
Date: Thu Oct  7 22:06:26 2004
Subject: [Pythonmac-SIG] Re: Subdirectories in py2app?
References: <4164656B.3020307@wordtech-software.com>
	<36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>
Message-ID: <rowen-ABBB2D.13062107102004@sea.gmane.org>

In article <36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>,
 Bob Ippolito <bob@redivi.com> wrote:

> On Oct 6, 2004, at 5:36 PM, Kevin Walzer wrote:
> After having looked at wxGlade, it does a large number of things that 
> make it quite hard to bundle up in any fashion (it's too dynamic).. the 
> big two are:
> 
> - it expects to load code and data from the same place on the filesystem
> - it loads lots of code dynamically, only from the filesystem
> 
> Basically what's needed is a packaged-application specific bootstrap 
> for wxGlade that does all of its code loading statically (new modules 
> surely aren't going to show up at runtime), and patch some globals in 
> common.py accordingly (it looks like the only source of this).. or else 
> you will have to specify the widgets and code writers *as* data files 
> and specify all of their dependencies explicitly.

My app is similar and I'd rather take the 2nd tactic if possible (since 
it's already what I'm doing with bundlebuilder and it works without any 
subtle tricks aside from some ugliness in my build script).

Do you have any suggestions on how to include a package of python code 
mixed with resources that cannot be zipped or reorganized?

-- Russell

From bob at redivi.com  Thu Oct  7 22:19:05 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct  7 22:19:41 2004
Subject: [Pythonmac-SIG] Re: Subdirectories in py2app?
In-Reply-To: <rowen-ABBB2D.13062107102004@sea.gmane.org>
References: <4164656B.3020307@wordtech-software.com>
	<36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>
	<rowen-ABBB2D.13062107102004@sea.gmane.org>
Message-ID: <23065FCD-189E-11D9-AB63-000A95686CD8@redivi.com>

On Oct 7, 2004, at 4:06 PM, Russell E. Owen wrote:

> In article <36DC97CA-17F8-11D9-A1CC-000A95686CD8@redivi.com>,
>  Bob Ippolito <bob@redivi.com> wrote:
>
>> On Oct 6, 2004, at 5:36 PM, Kevin Walzer wrote:
>> After having looked at wxGlade, it does a large number of things that
>> make it quite hard to bundle up in any fashion (it's too dynamic).. 
>> the
>> big two are:
>>
>> - it expects to load code and data from the same place on the 
>> filesystem
>> - it loads lots of code dynamically, only from the filesystem
>>
>> Basically what's needed is a packaged-application specific bootstrap
>> for wxGlade that does all of its code loading statically (new modules
>> surely aren't going to show up at runtime), and patch some globals in
>> common.py accordingly (it looks like the only source of this).. or 
>> else
>> you will have to specify the widgets and code writers *as* data files
>> and specify all of their dependencies explicitly.
>
> My app is similar and I'd rather take the 2nd tactic if possible (since
> it's already what I'm doing with bundlebuilder and it works without any
> subtle tricks aside from some ugliness in my build script).
>
> Do you have any suggestions on how to include a package of python code
> mixed with resources that cannot be zipped or reorganized?

The packages option allows you to do this, however the packages end up 
in Resources/Python/site-packages/ .. wxGlade assumes that data files 
such as README.txt as well as code files are in the same Resources 
folder, which is the problem there.  Additionally, the code that 
wxGlade loads isn't really in package format, it's just a folder full 
of code.

You can also specify the code as data files, however that will not scan 
the bytecode for additional dependencies.

I think I will have to add a feature that will scan code for 
dependencies that also specifies that the files will be copied by other 
means, or that the files should have an alternate destination.

-bob
From bob at redivi.com  Fri Oct  8 00:47:46 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  8 00:48:21 2004
Subject: [Pythonmac-SIG] py2app: Packaging wxGlade
Message-ID: <E80F9C35-18B2-11D9-AB63-000A95686CD8@redivi.com>

(Note: this information is relevant to `py2app`_ 0.1.2 - which is  
currently just on the `svn trunk`_)

In order to see how hard it would be to package a complicated  
application such as `wxGlade`_, I decided to give it a try.  `wxGlade`_  
is quite a dynamic beast with regard to code generation and widget  
plugins, so it was a bit of a pain to deal with.  I actually had to add  
several features to `py2app`_ in the process:

* A feature where one module can be "aliased" to another module.  I  
needed this because wxPython.wx points to wx, but is not actually on  
the filesystem.
* An extensible module filtering system, so a recipe can say "yes" or  
"no" to any extension or python module it comes across.  Before this,  
there was only one static filter that would say "no" to standard  
library modules when using a vendor Python.

`wxGlade`_ causes problems because it needs to list the "codegen" and  
"widgets" directories, and load code from them.  This would be easy if:

* The path were configurable in some way (using sys.path, a separate  
variable, etc.).  Packages go into .../Python/site-packages/, where it  
expected to see them at .../
* The list of modules were configurable in some way (right now it  
expects to perform an os.listdir)

The naive way would be to just include them as data files, however this  
prevents dependency analysis from occurring.  It turns out that  
`wxGlade`_ did indeed cause new dependencies in these modules so a more  
complicated solution was required.  The solution to this particular  
problem is in three parts:

1. Add "codegen" and "widgets" as data files
2. Add a wxglade recipe that scans all of these plugins for dependencies
3. Have the wxglade recipe install a filter that makes sure these  
dependencies aren't copied into the normal place

The other customization I used was a custom boot script, wxGlade.py.   
This boot script does two things:

1. Starts up wxGlade as per wxglade.py, but in a simpler way (less is  
needed, the environment is already sane)
2. Monkeypatches a bug in `wxGlade`_ so that it can open the help files

The example setup.py and bootstrap wxGlade.py are located at:
http://undefined.org/python/wxGlade-0.3.4-py2app.tgz

Note that setup.py expects a `wxGlade 0.3.4`_ distribution to be  
unpacked in ./wxGlade-0.3.4

.. _`py2app`: http://undefined.org/python/#py2app
.. _`svn trunk`: http://svn.red-bean.com/bob/py2app/trunk
.. _`wxGlade`: http://wxglade.sourceforge.net/
.. _`wxGlade 0.3.4`:  
http://sourceforge.net/project/showfiles.php? 
group_id=58225&package_id=54072&release_id=264401

-bob
From ocroquette at free.fr  Fri Oct  8 16:00:20 2004
From: ocroquette at free.fr (Olivier Croquette)
Date: Fri Oct  8 16:00:26 2004
Subject: [Pythonmac-SIG] Replacing AppleScript by Python
Message-ID: <41669D74.7040808@free.fr>

Hi,

First, let me introduce myself : I own since a few months a Mac under 
X.3. I am new to this world and know much better the Unix world, where I 
started to work with Python.

I am trying to control an application, namely iView MediaPro.

Until now, I knew only about AppleScript, so I started doing it in 
AppleScript. But it is really a pain, and I am really missing Python!

Today, I discovered the MacPython project and also PyObjC.

The problem I have, is following: I created a Python-iView interface 
thanks to the "Generate OSA suite" from the PythonIDE.

It worked, so now I am trying to see how I will use it.

I just created a small script (looking at the generated module source 
code), but actually it seems far more difficult as I expected.

There is visibly no exact equivalent between something like :

tell application "iView MediaPro"
  tell catalog 1
   set mediaItem to import file MediaFile
  end tell
end tell

and the equivalent in Python.

Did I miss something, or is it needed to hack a lot to get something 
working ?

Please help me, I can't live with AppleScript anymore :)

Regards

Olivier
From sw at wordtech-software.com  Fri Oct  8 16:07:12 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Fri Oct  8 16:07:16 2004
Subject: [Pythonmac-SIG] Re: py2app: Packaging wxGlade
In-Reply-To: <E80F9C35-18B2-11D9-AB63-000A95686CD8@redivi.com>
References: <E80F9C35-18B2-11D9-AB63-000A95686CD8@redivi.com>
Message-ID: <41669F10.20308@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bob,

Thank you for the revised code and instructions on wxGlade. I will take
give them a try today and report back.

All best,
Kevin

Bob Ippolito wrote:
| (Note: this information is relevant to `py2app`_ 0.1.2 - which is
| currently just on the `svn trunk`_)
|
| In order to see how hard it would be to package a complicated
| application such as `wxGlade`_, I decided to give it a try.  `wxGlade`_
| is quite a dynamic beast with regard to code generation and widget
| plugins, so it was a bit of a pain to deal with.  I actually had to add
| several features to `py2app`_ in the process:
|
| * A feature where one module can be "aliased" to another module.  I
| needed this because wxPython.wx points to wx, but is not actually on
| the filesystem.
| * An extensible module filtering system, so a recipe can say "yes" or
| "no" to any extension or python module it comes across.  Before this,
| there was only one static filter that would say "no" to standard
| library modules when using a vendor Python.
|
| `wxGlade`_ causes problems because it needs to list the "codegen" and
| "widgets" directories, and load code from them.  This would be easy if:
|
| * The path were configurable in some way (using sys.path, a separate
| variable, etc.).  Packages go into .../Python/site-packages/, where it
| expected to see them at .../
| * The list of modules were configurable in some way (right now it
| expects to perform an os.listdir)
|
| The naive way would be to just include them as data files, however this
| prevents dependency analysis from occurring.  It turns out that
| `wxGlade`_ did indeed cause new dependencies in these modules so a more
| complicated solution was required.  The solution to this particular
| problem is in three parts:
|
| 1. Add "codegen" and "widgets" as data files
| 2. Add a wxglade recipe that scans all of these plugins for dependencies
| 3. Have the wxglade recipe install a filter that makes sure these
| dependencies aren't copied into the normal place
|
| The other customization I used was a custom boot script, wxGlade.py.
| This boot script does two things:
|
| 1. Starts up wxGlade as per wxglade.py, but in a simpler way (less is
| needed, the environment is already sane)
| 2. Monkeypatches a bug in `wxGlade`_ so that it can open the help files
|
| The example setup.py and bootstrap wxGlade.py are located at:
| http://undefined.org/python/wxGlade-0.3.4-py2app.tgz
|
| Note that setup.py expects a `wxGlade 0.3.4`_ distribution to be
| unpacked in ./wxGlade-0.3.4
|
| .. _`py2app`: http://undefined.org/python/#py2app
| .. _`svn trunk`: http://svn.red-bean.com/bob/py2app/trunk
| .. _`wxGlade`: http://wxglade.sourceforge.net/
| .. _`wxGlade 0.3.4`:  http://sourceforge.net/project/showfiles.php?
| group_id=58225&package_id=54072&release_id=264401
|
| -bob
|
|


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZp8PJmdQs+6YVcoRApyaAJ97ec4keWda24/9afhH6jkJWgpKWwCfQOGZ
ReaAHDwZpDZOtCQBPiO+xY0=
=oabg
-----END PGP SIGNATURE-----
From joaoleao at gmx.net  Fri Oct  8 18:18:43 2004
From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=)
Date: Fri Oct  8 18:18:57 2004
Subject: [Pythonmac-SIG] Question about py2app and applets
Message-ID: <B8F9358A-1945-11D9-B640-000393967AF4@gmx.net>

Hi everyone

When I do "Save as applet" from the IDE, the resulting app isn't 
working on other machines besides mine as far as I tested with two 
other machines in my office. These applets rely only on the default 
Apple Python and the tested machines are running 10.3.5 as mine.
The applet starts and dies silently a few seconds later. Is this a 
known issue?

Because of behavior, when I want an applet (I mean an app that needs no 
dependencies other than the default Python) I've been using 
bundlebuilder with the --semi-standalone option and I get an app with 
same size.

Now I'm starting to use py2app and I wonder if there's some kind of 
option (argument?) that does the same as the --semi-standalone option 
in bundlebuilder.
Just to give an example:
My first attempt to do this with py2app was actually with py2applet. I 
simply drag and dropped my script and I got an app with 1,6 Mb.
With bundlebuilder (--semi-standalone) it would be 68 kb.

Thank you
_
jo?o
From bob at redivi.com  Fri Oct  8 19:02:30 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  8 19:03:08 2004
Subject: [Pythonmac-SIG] Question about py2app and applets
In-Reply-To: <B8F9358A-1945-11D9-B640-000393967AF4@gmx.net>
References: <B8F9358A-1945-11D9-B640-000393967AF4@gmx.net>
Message-ID: <D6CD7CA3-194B-11D9-8CA6-000A95686CD8@redivi.com>


On Oct 8, 2004, at 12:18 PM, Jo?o Le?o wrote:

> Because of behavior, when I want an applet (I mean an app that needs 
> no dependencies other than the default Python) I've been using 
> bundlebuilder with the --semi-standalone option and I get an app with 
> same size.
>
> Now I'm starting to use py2app and I wonder if there's some kind of 
> option (argument?) that does the same as the --semi-standalone option 
> in bundlebuilder.
> Just to give an example:
> My first attempt to do this with py2app was actually with py2applet. I 
> simply drag and dropped my script and I got an app with 1,6 Mb.
> With bundlebuilder (--semi-standalone) it would be 68 kb.

What version of py2app is that?  When I build an app with only stdlib 
dependencies using py2app from svn trunk it comes out to 56kb.

Do you have a /Library/Frameworks/Python.framework installed?  It might 
be finding and using that..

-bob
From joaoleao at gmx.net  Fri Oct  8 21:29:47 2004
From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=)
Date: Fri Oct  8 21:29:54 2004
Subject: [Pythonmac-SIG] Question about py2app and applets
Message-ID: <6A29E635-1960-11D9-B640-000393967AF4@gmx.net>


On 8 de out de 2004, at 18:02, Bob Ippolito wrote:

>
> On Oct 8, 2004, at 12:18 PM, Jo?o Le?o wrote:
>
>> Because of behavior, when I want an applet (I mean an app that needs 
>> no dependencies other than the default Python) I've been using 
>> bundlebuilder with the --semi-standalone option and I get an app with 
>> same size.
>>
>> Now I'm starting to use py2app and I wonder if there's some kind of 
>> option (argument?) that does the same as the --semi-standalone option 
>> in bundlebuilder.
>> Just to give an example:
>> My first attempt to do this with py2app was actually with py2applet. 
>> I simply drag and dropped my script and I got an app with 1,6 Mb.
>> With bundlebuilder (--semi-standalone) it would be 68 kb.
>
> What version of py2app is that?  When I build an app with only stdlib 
> dependencies using py2app from svn trunk it comes out to 56kb.

I used py2app 0.1.1. I built py2applet and drag'n'dropped my script on 
the icon.
The script uses stdlib and CoreGraphics (don't know if it's stdlib but 
it lives in the 10.3 default Python)

> Do you have a /Library/Frameworks/Python.framework installed?  It 
> might be finding and using that..

Humm... I don't think so. The only Python.framework I can see is under 
/System/Library/Frameworks (I gess this is the usual).
From bob at redivi.com  Fri Oct  8 21:30:07 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  8 21:30:43 2004
Subject: [Pythonmac-SIG] Question about py2app and applets
In-Reply-To: <BF63F76A-195E-11D9-B640-000393967AF4@gmx.net>
References: <B8F9358A-1945-11D9-B640-000393967AF4@gmx.net>
	<D6CD7CA3-194B-11D9-8CA6-000A95686CD8@redivi.com>
	<BF63F76A-195E-11D9-B640-000393967AF4@gmx.net>
Message-ID: <766B9EFC-1960-11D9-8CA6-000A95686CD8@redivi.com>

On Oct 8, 2004, at 3:17 PM, Jo?o Le?o wrote:

> On 8 de out de 2004, at 18:02, Bob Ippolito wrote:
>
>>
>> On Oct 8, 2004, at 12:18 PM, Jo?o Le?o wrote:
>>
>>> Because of behavior, when I want an applet (I mean an app that needs 
>>> no dependencies other than the default Python) I've been using 
>>> bundlebuilder with the --semi-standalone option and I get an app 
>>> with same size.
>>>
>>> Now I'm starting to use py2app and I wonder if there's some kind of 
>>> option (argument?) that does the same as the --semi-standalone 
>>> option in bundlebuilder.
>>> Just to give an example:
>>> My first attempt to do this with py2app was actually with py2applet. 
>>> I simply drag and dropped my script and I got an app with 1,6 Mb.
>>> With bundlebuilder (--semi-standalone) it would be 68 kb.
>>
>> What version of py2app is that?  When I build an app with only stdlib 
>> dependencies using py2app from svn trunk it comes out to 56kb.
>
> I used py2app 0.1.1. I built py2applet and drag'n'dropped my script on 
> the icon.
> The script uses stdlib and CoreGraphics (don't know if it's stdlib but 
> it lives in the 10.3 default Python)

It is in the stdlib path so it shouldn't get included.  Try using svn 
trunk.  py2app 0.1.1 may have included the whole encodings package 
(even though it is stdlib), which would be my best explanation for the 
file size.

>> Do you have a /Library/Frameworks/Python.framework installed?  It 
>> might be finding and using that..
>
> Humm... I don't think so. The only Python.framework I can see is under 
> /System/Library/Frameworks (I gess this is the usual)

That is the usual.

-bob
From hengist.podd at virgin.net  Fri Oct  8 21:49:10 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct  8 22:02:24 2004
Subject: [Pythonmac-SIG] Replacing AppleScript by Python
Message-ID: <a05200f4dbd8c9a007e83@[81.103.144.218]>

Olivier Croquette wrote:

>I am trying to control an application, namely iView MediaPro.
>
>Until now, I knew only about AppleScript, so I started doing it in
>AppleScript. But it is really a pain, and I am really missing Python!
>
>Today, I discovered the MacPython project and also PyObjC.
>
>The problem I have, is following: I created a Python-iView interface
>thanks to the "Generate OSA suite" from the PythonIDE.

aetools, gensuitemodule, etc. are due for replacement. Use appscript instead:

http://freespace.virgin.net/hamish.sanderson/appscript.html

Get the latest version, 0.6.0. (Also requires aem and 
osaterminology.) Appscript wraps up application object model 
references - actually simple relational queries - in a layer of 
terminology-driven syntactic sugar similar to standard Python OO 
syntax. Much nicer to use than the clumsy gsm.


>There is visibly no exact equivalent between something like :
>
>tell application "iView MediaPro"
>   tell catalog 1
>    set mediaItem to import file MediaFile
>   end tell
>end tell


Not used IMP myself so I'm kinda guessing here, but the following 
should work (or at least come close):

from Carbon.File import FSSpec
from appscript import *

mediaItem = app('iView 
MediaPro.app').catalogs[1].import(FSSpec('/path/to/MediaFile'))


HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From karl at elemtech.com  Fri Oct  8 22:42:55 2004
From: karl at elemtech.com (Karl Merkley)
Date: Fri Oct  8 22:43:01 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
Message-ID: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>


I have an application that I am porting to the Mac.  On Linux it 
requires that I link against libpython.so.  It  appears that Mac OS X 
10.3 does not include a libpython.dylib.   I _think_ I would like to 
stay compatible with the native python on the Mac.  What is the correct 
method for getting the shared library?  Assuming that I have to build 
it myself, what set of source do I download and build?  Are there any 
gotchas that I need to be aware of?

	TIA,
               Karl

From bob at redivi.com  Fri Oct  8 22:50:26 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  8 22:50:58 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
In-Reply-To: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>
References: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>
Message-ID: <AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>


On Oct 8, 2004, at 4:42 PM, Karl Merkley wrote:

> I have an application that I am porting to the Mac.  On Linux it 
> requires that I link against libpython.so.  It  appears that Mac OS X 
> 10.3 does not include a libpython.dylib.   I _think_ I would like to 
> stay compatible with the native python on the Mac.  What is the 
> correct method for getting the shared library?  Assuming that I have 
> to build it myself, what set of source do I download and build?  Are 
> there any gotchas that I need to be aware of?

Python on the Mac is built as a framework, which is linked to with 
-framework Python rather than -lpython.  You should be asking distutils 
how to link against Python.  Take a look at:

 >>> import distutils.sysconfig
 >>> distutils.sysconfig.get_config_vars()

I believe the keys used for embedding python are LINKFORSHARED and 
CFLAGSFORSHARED.

-bob
From karl at elemtech.com  Fri Oct  8 23:01:18 2004
From: karl at elemtech.com (Karl Merkley)
Date: Fri Oct  8 23:01:25 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
In-Reply-To: <AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>
References: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>
	<AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>
Message-ID: <33105626-196D-11D9-A447-000D9337B8A2@elemtech.com>

Thanks.  I'll take a look at that.  Like I said "newbie."  I don't even 
know what questions to ask yet!

	Karl

On Oct 8, 2004, at 2:50 PM, Bob Ippolito wrote:

>
> On Oct 8, 2004, at 4:42 PM, Karl Merkley wrote:
>
>> I have an application that I am porting to the Mac.  On Linux it 
>> requires that I link against libpython.so.  It  appears that Mac OS X 
>> 10.3 does not include a libpython.dylib.   I _think_ I would like to 
>> stay compatible with the native python on the Mac.  What is the 
>> correct method for getting the shared library?  Assuming that I have 
>> to build it myself, what set of source do I download and build?  Are 
>> there any gotchas that I need to be aware of?
>
> Python on the Mac is built as a framework, which is linked to with 
> -framework Python rather than -lpython.  You should be asking 
> distutils how to link against Python.  Take a look at:
>
> >>> import distutils.sysconfig
> >>> distutils.sysconfig.get_config_vars()
>
> I believe the keys used for embedding python are LINKFORSHARED and 
> CFLAGSFORSHARED.
>
> -bob
>
>

From bob at redivi.com  Fri Oct  8 23:12:06 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  8 23:12:38 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
In-Reply-To: <33105626-196D-11D9-A447-000D9337B8A2@elemtech.com>
References: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>
	<AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>
	<33105626-196D-11D9-A447-000D9337B8A2@elemtech.com>
Message-ID: <B5565BAE-196E-11D9-8CA6-000A95686CD8@redivi.com>


On Oct 8, 2004, at 5:01 PM, Karl Merkley wrote:

> On Oct 8, 2004, at 2:50 PM, Bob Ippolito wrote:
>
>>
>> On Oct 8, 2004, at 4:42 PM, Karl Merkley wrote:
>>
>>> I have an application that I am porting to the Mac.  On Linux it 
>>> requires that I link against libpython.so.  It  appears that Mac OS 
>>> X 10.3 does not include a libpython.dylib.   I _think_ I would like 
>>> to stay compatible with the native python on the Mac.  What is the 
>>> correct method for getting the shared library?  Assuming that I have 
>>> to build it myself, what set of source do I download and build?  Are 
>>> there any gotchas that I need to be aware of?
>>
>> Python on the Mac is built as a framework, which is linked to with 
>> -framework Python rather than -lpython.  You should be asking 
>> distutils how to link against Python.  Take a look at:
>>
>> >>> import distutils.sysconfig
>> >>> distutils.sysconfig.get_config_vars()
>>
>> I believe the keys used for embedding python are LINKFORSHARED and 
>> CFLAGSFORSHARED.
> Thanks.  I'll take a look at that.  Like I said "newbie."  I don't 
> even know what questions to ask yet!

Well, from experience, I can say that porting software from a language 
you're not terribly familiar with to a platform that you don't know 
inside and out has quite a steep learning curve! :)  I've been at it 
for over three and a half years (doesn't seem like that long, though) 
and I still run into things that confuse me every now and again.

-bob
From karl at elemtech.com  Fri Oct  8 23:38:49 2004
From: karl at elemtech.com (Karl Merkley)
Date: Fri Oct  8 23:38:57 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
In-Reply-To: <B5565BAE-196E-11D9-8CA6-000A95686CD8@redivi.com>
References: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>
	<AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>
	<33105626-196D-11D9-A447-000D9337B8A2@elemtech.com>
	<B5565BAE-196E-11D9-8CA6-000A95686CD8@redivi.com>
Message-ID: <712A765E-1972-11D9-A447-000D9337B8A2@elemtech.com>


On Oct 8, 2004, at 3:12 PM, Bob Ippolito wrote:

>
> On Oct 8, 2004, at 5:01 PM, Karl Merkley wrote:
>
>> On Oct 8, 2004, at 2:50 PM, Bob Ippolito wrote:
>>
>>>
>>> On Oct 8, 2004, at 4:42 PM, Karl Merkley wrote:
>>>
>>>> I have an application that I am porting to the Mac.  On Linux it 
>>>> requires that I link against libpython.so.  It  appears that Mac OS 
>>>> X 10.3 does not include a libpython.dylib.   I _think_ I would like 
>>>> to stay compatible with the native python on the Mac.  What is the 
>>>> correct method for getting the shared library?  Assuming that I 
>>>> have to build it myself, what set of source do I download and 
>>>> build?  Are there any gotchas that I need to be aware of?
>>>
>>> Python on the Mac is built as a framework, which is linked to with 
>>> -framework Python rather than -lpython.  You should be asking 
>>> distutils how to link against Python.  Take a look at:
>>>
>>> >>> import distutils.sysconfig
>>> >>> distutils.sysconfig.get_config_vars()
>>>
>>> I believe the keys used for embedding python are LINKFORSHARED and 
>>> CFLAGSFORSHARED.
>> Thanks.  I'll take a look at that.  Like I said "newbie."  I don't 
>> even know what questions to ask yet!
>
> Well, from experience, I can say that porting software from a language 
> you're not terribly familiar with to a platform that you don't know 
> inside and out has quite a steep learning curve! :)  I've been at it 
> for over three and a half years (doesn't seem like that long, though) 
> and I still run into things that confuse me every now and again.
>
> -bob
>
>

I have should have just trusted my build system.  CMake rocks! 
(www.cmake.org)  I had already gotten Qt and vtk installed and I had to 
tell it where vtk lived but it found all the correct python and Qt 
settings all on its own.  Very cool.  I've already got it built and 
running.

	Thanks,
		Karl

From bob at redivi.com  Fri Oct  8 23:42:42 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct  8 23:43:14 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
In-Reply-To: <712A765E-1972-11D9-A447-000D9337B8A2@elemtech.com>
References: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>
	<AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>
	<33105626-196D-11D9-A447-000D9337B8A2@elemtech.com>
	<B5565BAE-196E-11D9-8CA6-000A95686CD8@redivi.com>
	<712A765E-1972-11D9-A447-000D9337B8A2@elemtech.com>
Message-ID: <FB8FFA29-1972-11D9-9993-000A95686CD8@redivi.com>


On Oct 8, 2004, at 5:38 PM, Karl Merkley wrote:

> On Oct 8, 2004, at 3:12 PM, Bob Ippolito wrote:
>
>>
>> On Oct 8, 2004, at 5:01 PM, Karl Merkley wrote:
>>
>>> On Oct 8, 2004, at 2:50 PM, Bob Ippolito wrote:
>>>
>>>>
>>>> On Oct 8, 2004, at 4:42 PM, Karl Merkley wrote:
>>>>
>>>>> I have an application that I am porting to the Mac.  On Linux it 
>>>>> requires that I link against libpython.so.  It  appears that Mac 
>>>>> OS X 10.3 does not include a libpython.dylib.   I _think_ I would 
>>>>> like to stay compatible with the native python on the Mac.  What 
>>>>> is the correct method for getting the shared library?  Assuming 
>>>>> that I have to build it myself, what set of source do I download 
>>>>> and build?  Are there any gotchas that I need to be aware of?
>>>>
>>>> Python on the Mac is built as a framework, which is linked to with 
>>>> -framework Python rather than -lpython.  You should be asking 
>>>> distutils how to link against Python.  Take a look at:
>>>>
>>>> >>> import distutils.sysconfig
>>>> >>> distutils.sysconfig.get_config_vars()
>>>>
>>>> I believe the keys used for embedding python are LINKFORSHARED and 
>>>> CFLAGSFORSHARED.
>>> Thanks.  I'll take a look at that.  Like I said "newbie."  I don't 
>>> even know what questions to ask yet!
>>
>> Well, from experience, I can say that porting software from a 
>> language you're not terribly familiar with to a platform that you 
>> don't know inside and out has quite a steep learning curve! :)  I've 
>> been at it for over three and a half years (doesn't seem like that 
>> long, though) and I still run into things that confuse me every now 
>> and again.
>
> I have should have just trusted my build system.  CMake rocks! 
> (www.cmake.org)  I had already gotten Qt and vtk installed and I had 
> to tell it where vtk lived but it found all the correct python and Qt 
> settings all on its own.  Very cool.  I've already got it built and 
> running.

Excellent!  One thing that would definitely help the community is to 
write an email, create a wiki page at http://pythonmac.org/wiki/, or a 
blog entry (if you have one) that goes through what you needed to do in 
order to get VTK+Python running.  I think VTK is something that a bunch 
of people would like to use.. I tried to build it at some point a long 
time ago, but it wasn't quite ported and the sheer amount of time it 
takes to do a build of VTK discouraged me from finishing with it :)

-bob
From bob at redivi.com  Sat Oct  9 00:04:12 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct  9 00:04:47 2004
Subject: [Pythonmac-SIG] ANN: py2app 0.1.2
Message-ID: <FC743B10-1975-11D9-9993-000A95686CD8@redivi.com>

`py2app`_ is the bundlebuilder replacement we've all been waiting for.  
It is implemented as a distutils command, similar to `py2exe`_, that 
builds Mac OS X applications from Python scripts, extensions, and 
related data files.  It tries very hard to include all dependencies it 
can find so that your application can be distributed standalone, as Mac 
OS X applications should be.

`py2app`_ 0.1.2 is primarily a bugfix release:

  * The encodings package now gets included in the zip file (saves space)
  * A copy of the Python interpreter is not included anymore in 
standalone builds (saves space)
  * The executable bootstrap is now stripped by default (saves a little 
space)
  * sys.argv is set correctly now, it used to point to the executable, 
now it points to the boot script.  This should enhance compatibility 
with some applications.
  * Adds an "Alias" feature to modulegraph, so that sys.modules 
craziness such as wxPython.wx -> wx can be accomodated (this particular 
craziness is also now handled by default)
  * A sys.path alternative may be passed to find_modules now, though 
this is not used yet
  * The Command instance is now passed to recipes instead of the 
Distribution instance (though no recipes currently use either)
  * The post-filtering of modules and extensions is now generalized into 
a stack and can be modified by recipes
  * A `wxPython`_ example demonstrating how to package `wxGlade`_ has 
been added
  * PyRuntimeLocations is now set to (only) the location of the current 
interpreter's Python.framework for alias and semi-standalone build 
modes (enhances compatibility with extensions built with an unpatched 
Makefile with Mac OS X 10.3's Python 2.3.0)

Known issues:

  * Includes *all* files from packages, it should be smart enough to 
strip unused .py/.pyc/.pyo files (to save space, depending on which 
optimization flag is used).

Download and related links are here:
http://undefined.org/python/#py2app

.. _`wxGlade`: http://wxglade.sourceforge.net/
.. _`wxPython`: http://www.wxpython.org/
.. _`py2app`: http://undefined.org/python/#py2app
.. _`py2exe`: http://starship.python.net/crew/theller/py2exe/
From Chris.Barker at noaa.gov  Sat Oct  9 00:33:26 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Sat Oct  9 00:33:25 2004
Subject: [Pythonmac-SIG] Newbie Mac Question
In-Reply-To: <FB8FFA29-1972-11D9-9993-000A95686CD8@redivi.com>
References: <A200D76E-196A-11D9-A447-000D9337B8A2@elemtech.com>	<AE904E73-196B-11D9-8CA6-000A95686CD8@redivi.com>	<33105626-196D-11D9-A447-000D9337B8A2@elemtech.com>	<B5565BAE-196E-11D9-8CA6-000A95686CD8@redivi.com>	<712A765E-1972-11D9-A447-000D9337B8A2@elemtech.com>
	<FB8FFA29-1972-11D9-9993-000A95686CD8@redivi.com>
Message-ID: <416715B6.1060704@noaa.gov>

Bob Ippolito wrote:

> Excellent!  One thing that would definitely help the community is to 
> write an email, create a wiki page at http://pythonmac.org/wiki/, or a 
> blog entry (if you have one) that goes through what you needed to do in 
> order to get VTK+Python running.  I think VTK is something that a bunch 
> of people would like to use..

Yes, absolutely! please do that!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov
From steph-info at wanadoo.fr  Sun Oct 10 11:39:28 2004
From: steph-info at wanadoo.fr (Stephane Serra)
Date: Sun Oct 10 11:39:31 2004
Subject: [Pythonmac-SIG] Re: ANN: py2app 0.1.2 (long)
In-Reply-To: <20041009100005.37FBA1E401F@bag.python.org>
Message-ID: <4779712D-1AA0-11D9-BB20-00050231A219@wanadoo.fr>

Hello Bob, Giving a try to this new version it seems to break the two 
following apps on  OSX10.2.8 :

1?  I'm unable to get pygame example to run since it crashes with the 
following console message :

 > Interpreter not initialized (version mismatch?)

Dump output is :


Date/Time:  2004-10-10 11:03:41 +0200
OS Version: 10.2.8 (Build 6R73)
Host:       g3.rennes.lan

Command:    aliens
PID:        882

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000028

Thread 0 Crashed:
  #0   0x00744d48 in PyErr_Occurred (errors.c:81)
  #1   0x006b7120 in PySequence_List (abstract.c:1469)
  #2   0x006fd49c in mro_implementation (typeobject.c:1247)
  #3   0x006f863c in mro_internal (typeobject.c:1289)
  #4   0x006f9c08 in PyType_Ready (typeobject.c:3181)
  #5   0x006f9a10 in PyType_Ready (typeobject.c:3133)
  #6   0x00299ae4 in init_objc (module.m:767)
  #7   0x1009f05c in _PyImport_LoadDynamicModule (importdl.c:54)
  #8   0x1009b144 in load_module (import.c:1709)
  #9   0x1009c1a4 in import_submodule (import.c:2292)
  #10  0x1009bc44 in load_next (import.c:2116)
  #11  0x1009df08 in import_module_ex (import.c:1958)
  #12  0x1009cd60 in PyImport_ImportModuleEx (import.c:1998)
  #13  0x1006a088 in builtin___import__ (bltinmodule.c:45)
  #14  0x1000bbec in PyObject_Call (abstract.c:1756)
  #15  0x10076c2c in PyEval_CallObjectWithKeywords (ceval.c:3347)
  #16  0x100746b0 in eval_frame (ceval.c:1996)
  #17  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #18  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #19  0x1009a40c in PyImport_ExecCodeModuleEx (import.c:622)
  #20  0x100cbba0 in zipimporter_load_module (zipimport.c:365)
  #21  0x10008778 in PyObject_CallMethod (abstract.c:1756)
  #22  0x1009b290 in load_module (import.c:1764)
  #23  0x1009c1a4 in import_submodule (import.c:2292)
  #24  0x1009bc44 in load_next (import.c:2116)
  #25  0x1009df08 in import_module_ex (import.c:1958)
  #26  0x1009cd60 in PyImport_ImportModuleEx (import.c:1998)
  #27  0x1006a088 in builtin___import__ (bltinmodule.c:45)
  #28  0x1000bbec in PyObject_Call (abstract.c:1756)
  #29  0x10076c2c in PyEval_CallObjectWithKeywords (ceval.c:3347)
  #30  0x100746b0 in eval_frame (ceval.c:1996)
  #31  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #32  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #33  0x1009a40c in PyImport_ExecCodeModuleEx (import.c:622)
  #34  0x100cbba0 in zipimporter_load_module (zipimport.c:365)
  #35  0x10008778 in PyObject_CallMethod (abstract.c:1756)
  #36  0x1009b290 in load_module (import.c:1764)
  #37  0x1009c1a4 in import_submodule (import.c:2292)
  #38  0x1009bbf0 in load_next (import.c:2112)
  #39  0x1009df08 in import_module_ex (import.c:1958)
  #40  0x1009cd60 in PyImport_ImportModuleEx (import.c:1998)
  #41  0x1006a088 in builtin___import__ (bltinmodule.c:45)
  #42  0x1000bbec in PyObject_Call (abstract.c:1756)
  #43  0x10076c2c in PyEval_CallObjectWithKeywords (ceval.c:3347)
  #44  0x100746b0 in eval_frame (ceval.c:1996)
  #45  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #46  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #47  0x1009a40c in PyImport_ExecCodeModuleEx (import.c:622)
  #48  0x100cbba0 in zipimporter_load_module (zipimport.c:365)
  #49  0x10008778 in PyObject_CallMethod (abstract.c:1756)
  #50  0x1009b290 in load_module (import.c:1764)
  #51  0x1009c1a4 in import_submodule (import.c:2292)
  #52  0x1009bbf0 in load_next (import.c:2112)
  #53  0x1009df08 in import_module_ex (import.c:1958)
  #54  0x1009cd60 in PyImport_ImportModuleEx (import.c:1998)
  #55  0x1006a088 in builtin___import__ (bltinmodule.c:45)
  #56  0x1000bbec in PyObject_Call (abstract.c:1756)
  #57  0x10076c2c in PyEval_CallObjectWithKeywords (ceval.c:3347)
  #58  0x100746b0 in eval_frame (ceval.c:1996)
  #59  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #60  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #61  0x100a9a5c in run_node (pythonrun.c:1268)
  #62  0x1006b078 in builtin_execfile (bltinmodule.c:614)
  #63  0x10076d98 in call_function (ceval.c:3440)
  #64  0x10074970 in eval_frame (ceval.c:2117)
  #65  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #66  0x1007707c in fast_function (ceval.c:3529)
  #67  0x10076e70 in call_function (ceval.c:3458)
  #68  0x10074970 in eval_frame (ceval.c:2117)
  #69  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #70  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #71  0x100a9a5c in run_node (pythonrun.c:1268)
  #72  0x100a91b4 in PyRun_SimpleFileExFlags (pythonrun.c:865)
  #73  0x00003e40 in 0x3e40
  #74  0x00003ee0 in 0x3ee0
  #75  0x00002588 in 0x2588
  #76  0x000023fc in 0x23fc

PPC Thread State:
   srr0: 0x00744d48 srr1: 0x0000f030                vrsave: 0x00000000
    xer: 0x20000000   lr: 0x006b85b0  ctr: 0x00744d2c   mq: 0x00000000
     r0: 0x006b85b0   r1: 0xbfffbbc0   r2: 0x00000000   r3: 0x007b6bbc
     r4: 0x00744d34   r5: 0x006b85b0   r6: 0x42002244   r7: 0xfffffffe
     r8: 0x00000002   r9: 0x00000000  r10: 0x00000000  r11: 0x007bf9d8
    r12: 0x00744d2c  r13: 0x00108e7c  r14: 0x0014b1c0  r15: 0x1010249c
    r16: 0x00000000  r17: 0x00000000  r18: 0x00108e80  r19: 0x007a72b0
    r20: 0x0031d030  r21: 0x00000000  r22: 0x1010bb14  r23: 0x1010c034
    r24: 0x0031d6f0  r25: 0x00000000  r26: 0x0031d710  r27: 0x007a72b0
    r28: 0x0031d730  r29: 0x00000000  r30: 0x00000000  r31: 0x006b858c

2? the PyObjC example "Tinytinyedit" crashes with the following
dump history:



Date/Time:  2004-10-10 11:24:02 +0200
OS Version: 10.2.8 (Build 6R73)
Host:       g3.rennes.lan

Command:    TinyTinyEdit
PID:        992

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x7c7c1bcc

Thread 0 Crashed:
  #0   0x10049564 in PyType_IsSubtype (typeobject.c:817)
  #1   0x001c7a38 in machsignals_handleSignal (machsignals.m:85)
  #2   0x10076d98 in call_function (ceval.c:3440)
  #3   0x10074970 in eval_frame (ceval.c:2117)
  #4   0x10076fe8 in fast_function (ceval.c:3520)
  #5   0x10076e70 in call_function (ceval.c:3458)
  #6   0x10074970 in eval_frame (ceval.c:2117)
  #7   0x10076fe8 in fast_function (ceval.c:3520)
  #8   0x10076e70 in call_function (ceval.c:3458)
  #9   0x10074970 in eval_frame (ceval.c:2117)
  #10  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #11  0x1007707c in fast_function (ceval.c:3529)
  #12  0x10076e70 in call_function (ceval.c:3458)
  #13  0x10074970 in eval_frame (ceval.c:2117)
  #14  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #15  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #16  0x100a9a5c in run_node (pythonrun.c:1268)
  #17  0x1006b078 in builtin_execfile (bltinmodule.c:614)
  #18  0x10076d98 in call_function (ceval.c:3440)
  #19  0x10074970 in eval_frame (ceval.c:2117)
  #20  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #21  0x1007707c in fast_function (ceval.c:3529)
  #22  0x10076e70 in call_function (ceval.c:3458)
  #23  0x10074970 in eval_frame (ceval.c:2117)
  #24  0x10075c88 in PyEval_EvalCodeEx (ceval.c:2663)
  #25  0x10078afc in PyEval_EvalCode (ceval.c:537)
  #26  0x100a9a5c in run_node (pythonrun.c:1268)
  #27  0x100a91b4 in PyRun_SimpleFileExFlags (pythonrun.c:865)
  #28  0x00003e40 in 0x3e40
  #29  0x00003ee0 in 0x3ee0
  #30  0x00002588 in 0x2588
  #31  0x000023fc in 0x23fc

PPC Thread State:
   srr0: 0x10049564 srr1: 0x0000f030                vrsave: 0x00000000
    xer: 0x20000000   lr: 0x100987a4  ctr: 0x10049554   mq: 0x00000000
     r0: 0x100987a4   r1: 0xbfffed80   r2: 0x100987a4   r3: 0x7c7c1b78
     r4: 0x100f506c   r5: 0x10118740   r6: 0x001c819c   r7: 0xbfffee30
     r8: 0x1004955c   r9: 0x101174e0  r10: 0x10038668  r11: 0x101109d4
    r12: 0x10049554  r13: 0x0053470c  r14: 0x006823b0  r15: 0x1010249c
    r16: 0x00000000  r17: 0x00000000  r18: 0x100727f8  r19: 0x0000020c
    r20: 0x00000000  r21: 0x1007249c  r22: 0x00000001  r23: 0x000f94c0
    r24: 0x000fd0dc  r25: 0x00000001  r26: 0x00534718  r27: 0x001c819c
    r28: 0x001c7fa8  r29: 0x10076d98  r30: 0x00166150  r31: 0x10098740


I precise I'd  set the "installInterrupt=False" trick with PyObjC 
example. Do you get any idea
on those crashes ?


			St?phane Serra.



From bob at redivi.com  Sun Oct 10 12:02:57 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Oct 10 12:03:35 2004
Subject: [Pythonmac-SIG] Re: ANN: py2app 0.1.2 (long)
In-Reply-To: <4779712D-1AA0-11D9-BB20-00050231A219@wanadoo.fr>
References: <4779712D-1AA0-11D9-BB20-00050231A219@wanadoo.fr>
Message-ID: <8F7B3528-1AA3-11D9-8267-000A95686CD8@redivi.com>


On Oct 10, 2004, at 5:39 AM, Stephane Serra wrote:

> Hello Bob, Giving a try to this new version it seems to break the two 
> following apps on  OSX10.2.8 :
>
> 1?  I'm unable to get pygame example to run since it crashes with the 
> following console message :
>
> > Interpreter not initialized (version mismatch?)

You have multiple versions of Python installed.  Which Python 
interpreter did you create the bundle with, and which ones do you have 
installed?  This shouldn't happen, but I don't currently support 
non-framework builds of Python (i.e. fink, darwinports, the vendor 
installation of 2.2.0 w/ OS X 10.2) so if you built with one of those 
and you have framework Pythons installed then you will most definitely 
have serious problems.  py2app isn't very well tested on 10.2 and 
certainly isn't well tested in environments with a whole bunch of 
different Pythons installed (though it should work in most cases).

> 2? the PyObjC example "Tinytinyedit" crashes with the following
> dump history:
>
--
>
> I precise I'd  set the "installInterrupt=False" trick with PyObjC 
> example. Do you get any idea
> on those crashes ?

I'm not sure what that means, but I suggest updating to the latest 
version of PyObjC from svn (which should have installInterrupt off by 
default).  If that doesn't fix it, then it's probably due to your 
multiple versions of Python installed.

-bob
From rkern at ucsd.edu  Sun Oct 10 15:34:32 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Sun Oct 10 15:34:37 2004
Subject: [Pythonmac-SIG] VTK+Python build instructions
Message-ID: <41693A68.8050908@ucsd.edu>

I rebuilt VTK and its Python wrappers so I could run Mayavi 
<URL:http://mayavi.sf.net> and wrote up the process that I used for 
everyone's edification. I am using Panther and the standard Python 2.3.


Building VTK+Python on Panther
------------------------------

Download VTK 4.4 from
http://public.kitware.com/VTK/get-software.php

Download CMake binary installer from
http://www.cmake.org/HTML/Download.html

Attach the CMake disk image and install the package. You will now have, 
among other things, programs cmake and ccmake in /usr/local/bin . Make 
sure /usr/local/bin is in your PATH.

Unpack the VTK source somewhere.

     $ cd ~/src
     $ tar zxf ~/downloads/VTK-4.4-LatestRelease.tar.gz
     $ cd VTK

Make a subdirectory named "build".

     $ mkdir build
     $ cd build

Run ccmake with the main VTK directory as its argument.

     $ ccmake ..

You should now be in a curses-based text interface. With my Terminal 
color settings, I can't see if the options are highlighted as one moves 
the cursor, so just look at the bar near the bottom to see which option 
is currently highlighted. There is also a wxWidgets GUI interface, but I 
can't get it to run properly.

Press [c] to start configuring.

Toggle BUILD_SHARED_LIBS on.

Keep VTK_USE_CARBON on. Do not use VTK_USE_COCOA (The Cocoa 
implementation is not compatible with Python, yet).

Toggle VTK_USE_HYBRID on (Mayavi uses the vtkHybrid kit).

Toggle VTK_WRAP_PYTHON on.

Toggle VTK_WRAP_TCL on (Mayavi needs it).

Press [c] to configure. It should have found your framework Python. If 
you have installed TclTkAqua, it should also have found the appropriate 
frameworks.

If there are no errors, press [g] to generate the makefiles and exit. If 
nothing happens press [c] again and try pressing [g] once more. You may 
have to go back and forth pressing [c] and [g] until all information is 
found. Intuitive, yes?

Execute make and wait until it finishes. This takes a long time. Make 
some coffee. In fact, go to Colombia, harvest the beans, roast them, 
grind them, and brew your cup of coffee. When you get back, the build 
might be finished.

"make install" will install VTK into /usr/local (or whatever directory 
you told it to install to).

Change to the Python wrapper directory and install the Python wrappers.

     $ cd Wrapping/Python
     $ sudo python setup.py install

Add /usr/local/lib/vtk to your DYLD_LIBRARY_PATH. You will want to do 
this in your ~/.bashrc as well.

     $ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib/vtk

You're done!

-- 
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter
From bob at redivi.com  Sun Oct 10 21:18:16 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Oct 10 21:18:53 2004
Subject: [Pythonmac-SIG] ANN: py2app 0.1.3
Message-ID: <23860F46-1AF1-11D9-BA09-000A95686CD8@redivi.com>

`py2app`_ is the bundlebuilder replacement we've all been waiting for.  
It is implemented as a distutils command, similar to `py2exe`_, that 
builds Mac OS X applications from Python scripts, extensions, and 
related data files.  It tries very hard to include all dependencies it 
can find so that your application can be distributed standalone, as Mac 
OS X applications should be.

`py2app`_ 0.1.3 is a refactoring and new features release:

  * ``altgraph``, my fork of Istvan Albert's `graphlib`_, is now part of 
the distribution
  * ``py2app.modulegraph`` has been refactored to use ``altgraph``
  * `py2app`_ can now create `GraphViz`_ DOT graphs with the ``-g`` 
option (`TinyTinyEdit example`_)
  * Moved the filter stack into ``py2app.modulegraph``
  * Fixed a bug that may have been in 0.1.2 where explicitly included 
packages would not be scanned by ``macholib``
  * ``py2app.apptemplate`` now contains a stripped down ``site`` module 
as opposed to a ``sitecustomize``
  * Alias builds are now the only ones that contain the system and user 
``site-packages`` directory in ``sys.path``
  * The ``pydoc`` recipe has been beefed up to also exclude 
``BaseHTTPServer``, etc.

Known issues:

  * Commands marked with XXX in the help are not implemented
  * Includes *all* files from packages, it should be smart enough to 
strip unused .py/.pyc/.pyo files (to save space, depending on which 
optimization flag is used)
  * ``macholib`` should be refactored to use ``altgraph``
  * ``py2app.build_app`` and ``py2app.modulegraph`` should be refactored 
to search for dependencies on a per-application basis

Download and related links are here:
http://undefined.org/python/#py2app

.. _`graphlib`: 
http://www.personal.psu.edu/staff/i/u/iua1/python/graphlib/html/
.. _`GraphViz`: http://www.research.att.com/sw/tools/graphviz/
.. _`TinyTinyEdit example`: http://undefined.org/~bob/TinyTinyEdit.pdf
.. _`py2app`: http://undefined.org/python/#py2app
.. _`py2exe`: http://starship.python.net/crew/theller/py2exe/
From brownr at ucalgary.ca  Sun Oct 10 22:19:30 2004
From: brownr at ucalgary.ca (Robert Brown)
Date: Sun Oct 10 22:19:35 2004
Subject: [Pythonmac-SIG] solution for matplotlib compile problems
In-Reply-To: <m2655w6ej8.fsf@mother.paradise.lost>
References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net>
	<83B74998-1242-11D9-BABA-000A95928086@yale.edu>
	<m2655w6ej8.fsf@mother.paradise.lost>
Message-ID: <B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>

The latest version of matplotlib built out of the box for me... once I 
built libpng and freetype2.  It works great -- this really is a nice 
package.  Now all we need is some way to use Cocoa as a backend... 
maybe by writing PDF support?


On 29-Sep-04, at 1:50 PM, John Hunter wrote:

>>>>>> "Adam" == Adam Naples <adam.naples@yale.edu> writes:
>
>     Adam> Hi, I have been trying to get the latest version of
>     Adam> matplotlib to install (OS 10.3.5). the first attempt looked
>     Adam> promising and then crashed after a few minutes.  I
>     Adam> downloaded this file you linked to and all I get is.
>
> You shouldn't do this.  That file (written by me) was for an earlier
> version of matplotlib and the latest release includes those changes.
>
>     Adam> $ python setup.py install Traceback (most recent call last):
>     Adam> File "setup.py", line 52, in ?  from setupext import
>     Adam> build_agg, build_gtkagg, build_tkagg, \ ImportError: cannot
>     Adam> import name build_transforms
>
>     Adam> is this similar to the errors you were having?  any help
>     Adam> would be great.  thanks in advance -an
>
> No this is unrelated to Kenneth's earlier problems, which were related
> to not being able to find tkinter properly.
>
> Your build tree is out of whack since you are using the wrong
> setup.py.
>
> Make sure you read the install instructions at
> http://matplotlib.sourceforge.net/installing.html including the OSX
> specific stuff, then get the latest tarball (0.63.0), rm -rf any old
> matplotlib packages you have a round, and trying anew.  Post any build
> errors you get and I'll help you sort them out.  Typically, only the
> first error message or two conveys any useful information.
>
> JDH
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
---------------------------------------------------
Robb Brown
Seaman Family MR Research Centre
Calgary, Alberta, Canada
From rkern at ucsd.edu  Sun Oct 10 22:43:49 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Sun Oct 10 22:43:58 2004
Subject: [Pythonmac-SIG] solution for matplotlib compile problems
In-Reply-To: <B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>
References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net>	<83B74998-1242-11D9-BABA-000A95928086@yale.edu>	<m2655w6ej8.fsf@mother.paradise.lost>
	<B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>
Message-ID: <41699F05.4010702@ucsd.edu>

Robert Brown wrote:
> The latest version of matplotlib built out of the box for me... once I 
> built libpng and freetype2.  It works great -- this really is a nice 
> package.  Now all we need is some way to use Cocoa as a backend... maybe 
> by writing PDF support?

When someone (probably me) writes a Kiva[1] backend for matplotlib, 
you'll get both of these.

[1] http://svn.enthought.com/svn/enthought/trunk/kiva/

-- 
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter
From Jack.Jansen at cwi.nl  Mon Oct 11 00:01:27 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Mon Oct 11 00:01:10 2004
Subject: [Pythonmac-SIG] Replacing AppleScript by Python
In-Reply-To: <a05200f4dbd8c9a007e83@[81.103.144.218]>
References: <a05200f4dbd8c9a007e83@[81.103.144.218]>
Message-ID: <EF3BCE9A-1B07-11D9-8360-000D934FF6B4@cwi.nl>


On 8 Oct 2004, at 21:49, has wrote:

> mediaItem = app('iView 
> MediaPro.app').catalogs[1].import(FSSpec('/path/to/MediaFile'))

"import" is a reserved word. If appscript uses the same reserved word 
clash algorithm as the old gensuitemodule stuff then it'll be turned 
into "import_".
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From hengist.podd at virgin.net  Mon Oct 11 00:12:17 2004
From: hengist.podd at virgin.net (has)
Date: Mon Oct 11 00:12:41 2004
Subject: [Pythonmac-SIG] Replacing AppleScript by Python
In-Reply-To: <EF3BCE9A-1B07-11D9-8360-000D934FF6B4@cwi.nl>
References: <a05200f4dbd8c9a007e83@[81.103.144.218]>
	<EF3BCE9A-1B07-11D9-8360-000D934FF6B4@cwi.nl>
Message-ID: <a05200f03bd8f63d81fc3@[81.103.145.108]>

Jack Jansen wrote:

>>mediaItem = app('iView 
>>MediaPro.app').catalogs[1].import(FSSpec('/path/to/MediaFile'))
>
>"import" is a reserved word. If appscript uses the same reserved 
>word clash algorithm as the old gensuitemodule stuff then it'll be 
>turned into "import_".

Good spot, thanks. Yes, it should be 'import_'.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From njriley at uiuc.edu  Mon Oct 11 00:23:11 2004
From: njriley at uiuc.edu (Nicholas Riley)
Date: Mon Oct 11 00:23:15 2004
Subject: [Pythonmac-SIG] solution for matplotlib compile problems
In-Reply-To: <B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>
References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net>
	<83B74998-1242-11D9-BABA-000A95928086@yale.edu>
	<m2655w6ej8.fsf@mother.paradise.lost>
	<B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>
Message-ID: <20041010222311.GA99930@uiuc.edu>

On Sun, Oct 10, 2004 at 02:19:30PM -0600, Robert Brown wrote:
> The latest version of matplotlib built out of the box for me... once I 
> built libpng and freetype2.  It works great -- this really is a nice 
> package.  Now all we need is some way to use Cocoa as a backend... 
> maybe by writing PDF support?

It's not as capable as matplotlib, but I've recently had a lot of
success with PyChart's native PDF output:

	 <http://www.hpl.hp.com/personal/Yasushi_Saito/pychart/>

The PDF output is all implemented directly, but it is efficient, fast
and easy to customize for what I've needed.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
From steph-info at wanadoo.fr  Mon Oct 11 13:37:41 2004
From: steph-info at wanadoo.fr (Stephane Serra)
Date: Mon Oct 11 13:37:45 2004
Subject: [Pythonmac-SIG] Re: ANN: py2app 0.1.2
In-Reply-To: <20041011100006.138D91E4012@bag.python.org>
Message-ID: <F5C4B884-1B79-11D9-A3D7-00050231A219@wanadoo.fr>


Thanks for your reply Bob,

	I have the osx 10.2.8 stock python 2.2,  the framework Macpython
2.3.4 in /Library/Frameworks and I think probably one version from fink 
(Dia) in /sw
which is on a separate disk I ONLY mount when  needed.

	The Python version I use is surely the Framework one (I installed with,
and built the test apps with...).
		
	What's strange is the py2app v.0.1.1 worked while
I noted version 0.1.2 doesn't copy all the needed frameworks
stuff in the app Framewok folder.
	But wait, the bugs you corrected with version 0.1.4
make things work fine again !!!

	

			St?phane Serra.



From hengist.podd at virgin.net  Wed Oct 13 16:29:57 2004
From: hengist.podd at virgin.net (has)
Date: Wed Oct 13 16:30:16 2004
Subject: [Pythonmac-SIG] [ann] appscript 0.7.0 released
Message-ID: <a05200f07bd92eb902d7c@[81.103.145.108]>

Hi all,

New version of appscript is out:

http://freespace.virgin.net/hamish.sanderson/appscript.html

Main changes are updated documentation and the return of built-in 
help(). Any comments/problems/etc, let me know, thanks.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From n8gray at gmail.com  Wed Oct 13 23:55:17 2004
From: n8gray at gmail.com (Nathaniel Gray)
Date: Wed Oct 13 23:55:21 2004
Subject: [Pythonmac-SIG] [ann] appscript 0.7.0 released
In-Reply-To: <a05200f07bd92eb902d7c@81.103.145.108>
References: <a05200f07bd92eb902d7c@81.103.145.108>
Message-ID: <aee06c9e041013145532810dc1@mail.gmail.com>

Hooray!  Appscript is a great tool that has the potential to do big
things for Python on Macs.  Keep up the good work!

Cheers,
-n8

On Wed, 13 Oct 2004 15:29:57 +0100, has <hengist.podd@virgin.net> wrote:
> Hi all,
> 
> New version of appscript is out:
> 
> http://freespace.virgin.net/hamish.sanderson/appscript.html
> 
> Main changes are updated documentation and the return of built-in
> help(). Any comments/problems/etc, let me know, thanks.
> 
> has
> --
> http://freespace.virgin.net/hamish.sanderson/
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 


-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
From enrike at altern.org  Thu Oct 14 18:20:40 2004
From: enrike at altern.org (altern)
Date: Thu Oct 14 18:24:25 2004
Subject: [Pythonmac-SIG] installing wxpython on panther
In-Reply-To: <20041010222311.GA99930@uiuc.edu>
References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net>	<83B74998-1242-11D9-BABA-000A95928086@yale.edu>	<m2655w6ej8.fsf@mother.paradise.lost>	<B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>
	<20041010222311.GA99930@uiuc.edu>
Message-ID: <416EA758.3000508@altern.org>

hi

i am trying to install wxpython on panther. My problem is that because i 
installed python 3.3.3 and the default installer for wxpython goes into 
the panther python version instead of the latest version i installed.

i downloaded the source but i am not sure what i should do to avoid this 
problem, i also tried the package manager but seems to just download the 
.dmg so back to square one.
Any suggestions would be apreciated.

thanks


-- 
enrike

From bob at redivi.com  Thu Oct 14 18:41:00 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct 14 18:41:40 2004
Subject: [Pythonmac-SIG] installing wxpython on panther
In-Reply-To: <416EA758.3000508@altern.org>
References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net>	<83B74998-1242-11D9-BABA-000A95928086@yale.edu>	<m2655w6ej8.fsf@mother.paradise.lost>	<B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>
	<20041010222311.GA99930@uiuc.edu> <416EA758.3000508@altern.org>
Message-ID: <D4B7EDB4-1DFF-11D9-9A2E-000A95686CD8@redivi.com>


On Oct 14, 2004, at 12:20 PM, altern wrote:

> i am trying to install wxpython on panther. My problem is that because 
> i installed python 3.3.3 and the default installer for wxpython goes 
> into the panther python version instead of the latest version i 
> installed.
>
> i downloaded the source but i am not sure what i should do to avoid 
> this problem, i also tried the package manager but seems to just 
> download the .dmg so back to square one.
> Any suggestions would be apreciated.

I suggest just sticking with the stock Python 2.3.0 and using the 
binary installer.  Otherwise you will have to compile everything from 
source, and you will certainly run into Version Mismatch problems at 
some time or another.

-bob
From hengist.podd at virgin.net  Thu Oct 14 19:14:30 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 14 19:50:45 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f07bd92eb902d7c@[81.103.145.108]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
Message-ID: <a05200f0abd9456c5d66a@[81.103.145.108]>

Hi all,

First, a quick update: just posted appscript 0.7.1, which fixes a 
couple minor bugs:

http://freespace.virgin.net/hamish.sanderson/appscript.html

I've also added a dump() function to appscript.terminology which 
parses and stores an application's terminology as a Python module. 
This will be used by the terminology caching system I'm planning for 
0.8.0, something that's required for remote application scripting [1] 
and should also allow users to reduce the time it takes to create new 
'app' objects by caching terminology data in advance.

...

Now to business: I'm looking for suggestions on how best to implement 
this caching system. I've no clear idea on how to proceed with it, so 
am throwing the thing open to discussion.


Notes:

- Ideally the cache would operate constantly and transparently, 
automatically caching an application's terminology the first time 
it's used, and loading cached terminologies from disk by application 
name and version number. A fully automated cache may not be 
practical, however, in which case the user would need to manually 
trigger the caching process and/or explicitly instruct appscript when 
to load a cached terminology.

- Terminology modules may be generated on the machine where the 
application resides and copied onto the machines that will remotely 
control that application.

- The less user scripts are tied to a specific machine, the better. 
If the user has to add machine-specific code to their script to load 
terminology for a remote application (e.g. the terminology module's 
name), that may be acceptable as such scripts are already less than 
100% portable due to the presence of network-specific eppc addresses. 
Breaking portability would not be acceptable in scripts that use 
cached terminologies simply to improve startup time when scripting 
local apps, however - such scripts should work regardless of whether 
terminology comes from a cache or direct from the application.

- Any other way it could be done better? e.g. Run a 'terminology 
server' daemon on each machine that supplies appscript with all its 
terminology needs? Such daemons could maintain terminology caches for 
local applications, and serve terminology data across networks upon 
demand so that remote clients don't need to maintain their own 
terminology caches for remote apps. Can't hurt to toss around ideas 
at this point.

- Usability and reliability are essential, and portability would be a 
big advantage.

- Also, some other poor sap may have to maintain the appscript code 
some day, so KISS as much as possible.

- Last thing I want is a clumsy Glue-style system.

- Remote scripting support is already implemented in aem for those 
that want to check it out.


Questions:

1. Is there a universal and foolproof way to get an application's 
version number? Particularly when that application is running 
remotely?

2. If not, how else could an application be uniquely identified? URL 
or full path are options, though paths may change, applications may 
be updated in-situ, copies of the same application may exist in 
multiple locations (e.g. if InDesign 3.0.1 is on a dozen networked 
machines, it'd be better to have a single terminology module that 
works with all of them than have a dozen identical modules, each one 
tied to a different location), and multiple versions of the same app 
may exist on a single machine.

3. How and where should terminology modules be stored?

4. How should terminology modules be [uniquely] named when created? 
How should they be located and loaded for use? Can this be done by 
filename/directory structure alone, or would it need a central index 
to locate modules by application name, version,etc?

5. If a fully automated cache isn't possible, what would need to be 
done manually and how?

6. What all could go wrong?



Please post your thoughts, suggestions, criticisms, etc. This is the 
second-to-last major task I'm facing (the last is writing full 
documentation), so the sooner it's solved the sooner I can get on 
with kicking the damn thing out the door at last. :)

Many thanks,

has

--

[1]  OSAGetAppTerminology doesn't work across networks, so a remote 
app's terminology needs to be sourced locally.
-- 
http://freespace.virgin.net/hamish.sanderson/
From Jack.Jansen at cwi.nl  Thu Oct 14 22:00:09 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Thu Oct 14 22:00:13 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f0abd9456c5d66a@[81.103.145.108]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
Message-ID: <A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>

I think you want to start with something of an architecture for getting 
terminology, something similar to Python's import mechanism: there are 
a number of engines that allow you to get at terminology data (one that 
reads aete resources, one that starts the application and asks it, one 
that uses the cache, etc), and these all use a common well-defined API. 
You then provide a default set of engines in a default order, but the 
users can change this order, or add their own special-purpose engine to 
the front, etc.

How you decide that a terminology is "right" is also an issue: if you 
want terminology for MyApp 1.0.1 and the first importer can supply it 
for MyApp 1.0, do you continue searching? Ideally this would depend on 
the script, but that puts the burden on the script writer.

And you probably have to think of *why* you want caching. The choice of 
how to organise things depends on whether the main goal is to make 
remote scripting possible, or to speed up access to local apps, or 
whatever other reason there may be.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From sw at wordtech-software.com  Thu Oct 14 22:00:56 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Thu Oct 14 22:01:04 2004
Subject: [Pythonmac-SIG] Re: py2app: Packaging wxGlade
In-Reply-To: <E80F9C35-18B2-11D9-AB63-000A95686CD8@redivi.com>
References: <E80F9C35-18B2-11D9-AB63-000A95686CD8@redivi.com>
Message-ID: <416EDAF8.3020701@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bob,

Thanks for the updated version of py2app and the patched script for
wxGlade. After a couple of failed attempts, I got everything packaged
up, and it runs beautifully. I will get a revised version of wxGlade
available for downlaod from my website in the near future, and I'm also
going to update the instructions on the various Python pages I maintain.

I want to change the generic app icon to a custom one in wxGlade--I'm
assuming I can just do this by editing info.plist and adding the correct
.icns file to the app bundle? I haven't been able to find documentation
to see how to do this directly in py2app.

Thanks,
Kevin


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBbtr3JmdQs+6YVcoRAgaJAJ9MBPNJXSM+HTVIaMn9uhfGDdKmwwCfV6dW
wP6pXCrNTSrRtSPh2j0fstw=
=IU2c
-----END PGP SIGNATURE-----
From bob at redivi.com  Fri Oct 15 01:20:04 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 15 01:20:39 2004
Subject: [Pythonmac-SIG] Re: py2app: Packaging wxGlade
In-Reply-To: <416EDAF8.3020701@wordtech-software.com>
References: <E80F9C35-18B2-11D9-AB63-000A95686CD8@redivi.com>
	<416EDAF8.3020701@wordtech-software.com>
Message-ID: <944B7056-1E37-11D9-BD1D-000A95686CD8@redivi.com>

On Oct 14, 2004, at 4:00 PM, Kevin Walzer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bob,
>
> Thanks for the updated version of py2app and the patched script for
> wxGlade. After a couple of failed attempts, I got everything packaged
> up, and it runs beautifully. I will get a revised version of wxGlade
> available for downlaod from my website in the near future, and I'm also
> going to update the instructions on the various Python pages I 
> maintain.
>
> I want to change the generic app icon to a custom one in wxGlade--I'm
> assuming I can just do this by editing info.plist and adding the 
> correct
> .icns file to the app bundle? I haven't been able to find documentation
> to see how to do this directly in py2app.

Either specify iconfile as an option to py2app in the options 
dictionary or commandline, or specify the icon as a data_file and make 
sure that CFBundleIcon gets set to the name of the icon.  The pygame 
aliens example should do one of these approaches.

-bob
From wtbridgman at radix.net  Fri Oct 15 05:17:00 2004
From: wtbridgman at radix.net (W.T. Bridgman)
Date: Fri Oct 15 05:17:02 2004
Subject: [Pythonmac-SIG] Attempted SciPy 0.3.2 build on MacOS X
Message-ID: <AD739580-1E58-11D9-AEFB-000A95ACFF76@radix.net>

Hello,

I've made half-hearted attempts to install SciPy (v0.3) under OS X but  
was concerned because it was unclear from the instructions whether the  
test failures under scipy.stats module impacted the results from that  
particular module.

Anyway, when 0.3.2 was released with the claim that the tests pass on  
OS X, I decided to give it a try using Chris Fonnesbeck's instructions  
as a guide.   A few things I found:

1) The changes to setup.py don't seem to apply in this release.  I had  
to remove ./Lib/sparse.

2) The build failed with a somewhat strange error message from the  
config.h file apparently created with xplt.  Since xplt/ was reported  
as revised for the Mac, I opted to remove ./Lib/xplt as well.

3) The build seemed to run to completion, so I ran the tests.  Some of  
the messages were really cryptic as to whether the test was successful,  
but the run finally failed with:

.Testing weibull_max
.Testing weibull_min
.........
======================================================================
ERROR: check_simple_todense  
(scipy.io.mmio.test_mmio.test_mmio_coordinate)
----------------------------------------------------------------------
Traceback (most recent call last):
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/scipy/io/tests/test_mmio.py", line 152, in  
check_simple_todense
     b = mmread(fn).todense()
AttributeError: todense

----------------------------------------------------------------------
Ran 946 tests in 5.006s

FAILED (errors=1)
<unittest.TextTestRunner object at 0x2acbe30>
 >>>
------------------------------------------------------------------------ 
--------------------------
Some investigation suggested this error might be related to my removal  
of xplt.  I'll play with the tutorial to test more components of the  
build.

As for my build, I'm on MacOS 10.3.5 and XCode v1.5.  All versions  
except SciPy as you describe on your instructions (FFTW 2.1.5).  Below  
is some troubleshooting output suggested in INSTALL.txt.

Thanks for any and all assistance,
Tom
------------------------------------------------------------------------ 
---------------------------
Planck:~ bridgman$ python -c 'from f2py2e.diagnose import run;run()'
------
os.name='posix'
------
sys.platform='darwin'
------
sys.version:
2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)]
------
sys.prefix:
/System/Library/Frameworks/Python.framework/Versions/2.3
------
sys.path='/Users/bridgman:/System/Library/Frameworks/Python.framework/ 
Versions/2.3/lib/python23.zip:/System/Library/Frameworks/ 
Python.framework/Versions/2.3/lib/python2.3:/System/Library/Frameworks/ 
Python.framework/Versions/2.3/lib/python2.3/plat-darwin:/System/ 
Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat- 
mac:/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-mac/lib-scriptpackages:/System/Library/Frameworks/ 
Python.framework/Versions/2.3/lib/python2.3/lib-tk:/System/Library/ 
Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-dynload:/ 
System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages:/System/Library/Frameworks/Python.framework/Versions/2.3/ 
lib/python2.3/site-packages/HTMLgen:/System/Library/Frameworks/ 
Python.framework/Versions/2.3/lib/python2.3/site-packages/Numeric:/ 
System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/PIL:/System/Library/Frameworks/Python.framework/Versions/ 
2.3/lib/python2.3/site-packages/PyObjC:/System/Library/Frameworks/ 
Python.framework/Versions/2.3/lib/python2.3/site-packages/vtk_python'
------
Found Numeric version '23.1' in  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/Numeric/Numeric.pyc
Found numarray version '1.1' in  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/numarray/__init__.pyc
Found f2py2e version '2.39.235_1693' in  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/f2py2e/f2py2e.pyc
Found scipy_distutils version '0.3.2' in  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/scipy_distutils/__init__.pyc'
------
Importing scipy_distutils.command.build_flib ... error: No module named  
build_flib
------
Checking availability of supported Fortran compilers:
error: local variable 'build_flib' referenced before assignment
------
Importing scipy_distutils.fcompiler ... ok
------
Checking availability of supported Fortran compilers:
customize CompaqFCompiler
customize AbsoftFCompiler
Could not locate executable ifort
Could not locate executable ifc
Could not locate executable efort
Could not locate executable efc
Could not locate executable ifort
customize IntelFCompiler
Could not locate executable f77
customize GnuFCompiler
customize SunFCompiler
customize VastFCompiler
customize IbmFCompiler
customize LaheyFCompiler
customize IntelVisualFCompiler
customize IntelItaniumFCompiler
customize PGroupFCompiler
customize CompaqVisualFCompiler
customize MipsFCompiler
customize HPUXFCompiler
customize IntelItaniumVisualFCompiler
customize NAGFCompiler
List of available Fortran compilers:
   --fcompiler=gnu  GNU Fortran Compiler (3.4.0)
List of unavailable Fortran compilers:
   --fcompiler=absoft   Absoft Corp Fortran Compiler
   --fcompiler=compaq   Compaq Fortran Compiler
   --fcompiler=compaqv  DIGITAL|Compaq Visual Fortran Compiler
   --fcompiler=hpux     HP Fortran 90 Compiler
   --fcompiler=ibm      IBM XL Fortran Compiler
   --fcompiler=intel    Intel Fortran Compiler for 32-bit apps
   --fcompiler=intele   Intel Fortran Compiler for Itanium apps
   --fcompiler=intelev  Intel Visual Fortran Compiler for Itanium apps
   --fcompiler=intelv   Intel Visual Fortran Compiler for 32-bit apps
   --fcompiler=lahey    Lahey/Fujitsu Fortran 95 Compiler
   --fcompiler=mips     MIPSpro Fortran Compiler
   --fcompiler=nag      NAGWare Fortran 95 Compiler
   --fcompiler=pg       Portland Group Fortran Compiler
   --fcompiler=sun      Sun|Forte Fortran 95 Compiler
   --fcompiler=vast     Pacific-Sierra Research Fortran 90 Compiler
List of unimplemented Fortran compilers:
   --fcompiler=f  Fortran Company/NAG F Compiler
For compiler details, run 'config_fc --verbose' setup command.
------
Importing scipy_distutils.command.cpuinfo ... error: No module named  
cpuinfo
Importing scipy_distutils.cpuinfo ... ok
------
CPU information: getNCPUs is_32bit is_ppc is_ppc7450 ------
Planck:~ bridgman$

From enrike at altern.org  Fri Oct 15 11:08:10 2004
From: enrike at altern.org (altern)
Date: Fri Oct 15 11:14:56 2004
Subject: [Pythonmac-SIG] [Fwd: installing wxpython on panther]
Message-ID: <416F937A.6010805@altern.org>

sorry i am not sure if anyone answered my email from yesterday as i had 
a problem with my email program and all emails received yesterday were 
deleted before i could read them.
There it goes again just un case it wasnt delivered.


-------- Original Message --------
Subject: installing wxpython on panther
Date: Thu, 14 Oct 2004 18:20:40 +0200
From: altern <enrike@altern.org>
To: pythonmac-sig@python.org
References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net> 
<83B74998-1242-11D9-BABA-000A95928086@yale.edu> 
<m2655w6ej8.fsf@mother.paradise.lost> 
<B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca> 
<20041010222311.GA99930@uiuc.edu>

hi

i am trying to install wxpython on panther. My problem is that i
installed python 2.3.3 and the default installer for wxpython goes into
the panther python version (2.3) instead of the latest version i installed.

i downloaded the source but i am not sure what i should do to install it 
into the right place, i also tried the package manager but seems that 
this just downloads the
.dmg and later i need to install it manually, so i am back to square one.
Any suggestions would be apreciated.

thanks


-- 
enrike



-- 
enrike

From brian_l at mac.com  Fri Oct 15 12:14:49 2004
From: brian_l at mac.com (Brian Lenihan)
Date: Fri Oct 15 12:14:58 2004
Subject: [Pythonmac-SIG] [Fwd: installing wxpython on panther]
In-Reply-To: <416F937A.6010805@altern.org>
References: <416F937A.6010805@altern.org>
Message-ID: <0C4A315A-1E93-11D9-803D-000A95841920@mac.com>


On Oct 15, 2004, at 2:08 AM, altern wrote:

> sorry i am not sure if anyone answered my email from yesterday as i  
> had a problem with my email program and all emails received yesterday  
> were deleted before i could read them.
> There it goes again just un case it wasnt delivered.
>
>
> -------- Original Message --------
> Subject: installing wxpython on panther
> Date: Thu, 14 Oct 2004 18:20:40 +0200
> From: altern <enrike@altern.org>
> To: pythonmac-sig@python.org
> References: <92A10444-D753-11D8-9884-000A956870AC@sbcglobal.net>  
> <83B74998-1242-11D9-BABA-000A95928086@yale.edu>  
> <m2655w6ej8.fsf@mother.paradise.lost>  
> <B0D6DFDC-1AF9-11D9-B562-000A9575B6C8@ucalgary.ca>  
> <20041010222311.GA99930@uiuc.edu>
>
> hi
>
> i am trying to install wxpython on panther. My problem is that i
> installed python 2.3.3 and the default installer for wxpython goes into
> the panther python version (2.3) instead of the latest version i  
> installed.

You can create some symlinks to the installed wx packages in your 2.3.3  
site-packages

ln -s /Library/Python/2.3/wx  
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/wx

ln -s /Library/Python/2.3/wxPython  
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- 
packages/wxPython

There are other problems running multiple versions of python.  As long  
as you stick with compatible versions (2.3.x) it's pretty easy to deal  
with If you rename Apple's version to keep it out of the way.  You can  
even continue to use Apple's modules such as CoreGraphics (also by  
using symlinks).  I even have 2.3.4 and 2.4a3 in the same Framework and  
haven't had any problems.

> i downloaded the source but i am not sure what i should do to install  
> it into the right place, i also tried the package manager but seems  
> that this just downloads the
> .dmg and later i need to install it manually, so i am back to square  
> one.
> Any suggestions would be apreciated.
>
> thanks
>
>
> -- 
> enrike
>
>
>
> -- 
> enrike
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

From hengist.podd at virgin.net  Fri Oct 15 12:36:27 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 15 13:54:12 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
Message-ID: <a05200f0cbd94b092d6f1@[81.103.145.108]>

Jack Jansen wrote:

>I think you want to start with something of an architecture for 
>getting terminology, something similar to Python's import mechanism: 
>there are a number of engines that allow you to get at terminology 
>data (one that reads aete resources, one that starts the application 
>and asks it,

Getting terminology from applications is the OSA's job. This is 
currently done by OSAGetAppTerminology, though eventually sdefs will 
supercede aetes, at which point a new OSA call will no doubt be added 
for getting terminology in sdef format. osaterminology should use 
this call on OSes that provide it, otherwise it should use 
OSAGetAppTerminology.


>one that uses the cache, etc), and these all use a common well-defined API.

There are several places a standard API could be located:

1. After osaterminology.aeteparser.getaete. This would capture the 
raw aete data directly returned from OSAGetAppTerminology. A cache 
module generated here would contain a list of unparsed aete strings.

2. Between the aete parser and consumers. (Note: the 0.6.0 rewrite 
has already decoupled these via a SAX-style API; see 
osaterminology.aeteparser.__init__.) A cache module generated here 
would basically be a long list of method calls that recreate the 
original parsing events when fed a consumer instance.

3. After appscript.terminology module. This would capture fully 
processed, specialised data structures containing minimal name-code 
translation information needed to build references. (See the dump() 
function I just added.)


A cache inserted at any of these locations would do for remote 
scripting support. For optimising appscript performance, later is 
better. There are two performance humps affecting app object creation:

- The first call to OSAGetAppTerminology is very slow, ~0.5sec. 
Subsequent calls are very fast; it's just that first one that's the 
killer. The OSATerminology extension has to provide a scripting 
component instance to OSAGetAppTerminology, and uses the AppleScript 
component as it's about the only one available; unfortunately the AS 
component is rather slow to load. If anyone has any ideas for routing 
around this, e.g. using a faster loading dummy component or turning 
the OSATerminology extension into a permanently running daemon, I'm 
all ears.

- The time it takes to parse the terminology and turn it into Python 
data structures. This is a non-issue for the help systems which don't 
require top performance, but it's a definite problem for application 
scripting as slow starts are a real turn-off, particularly for folk 
used to AppleScript. (AS performs all terminology translation work at 
compile-time so doesn't have the same runtime overheads as appscript.)


Inserting a cache at #1 or #2 will avoid the first of these humps, 
reducing startup time by 0.5sec. Inserting it at #3 will avoid both 
and effectively eliminate startup overhead completely: importing a 
dump()ed terminology module is 10x faster than parsing that 
terminology from source (e.g. 0.02sec instead of 0.2sec).

Note that a cache at #3 will be of little general use, as the only 
data it holds is name<->AE code translation tables. For example, both 
help systems require full terminology, so when scripting remote 
applications the interactive help() would be unavailable and HTML 
terminology docs would need to be generated on the host machine then 
distributed to users. But how big an issue this would be I dunno; I 
reckon this is probably the lesser of two evils but what do others 
think?


Of course, there's no technical reason why a caching system couldn't 
support >1 of these options by supporting multiple converters and 
allowing clients to request the type of cached data they require. The 
cache system would be concerned with matching cached terminologies to 
the applications specified by the client, not with the specific 
content of individual terminology modules. I'd be a tad cautious here 
as there's obvious potential for the implementation and user 
interface to balloon out of control, but it's certainly an option to 
consider.


>You then provide a default set of engines in a default order, but 
>the users can change this order, or add their own special-purpose 
>engine to the front, etc.

I think pluggable engines would be overkill. There's only two places 
terminology data could come from: the original application or the 
cache. And there's only one resolution order that really makes sense: 
if a cache is available then get the terminology from that, otherwise 
get it from the application (or raise an error if that's not 
possible, i.e. the application is remote).


>How you decide that a terminology is "right" is also an issue: if 
>you want terminology for MyApp 1.0.1 and the first importer can 
>supply it for MyApp 1.0, do you continue searching?

That's an easy one: in an automatic terminology retrieval system, the 
cached terminology must _exactly_ match the version of application 
being scripted. If it doesn't, the terminology must be retrieved from 
the application (if it's a local app) or an error raised (if it's a 
remote app). In a manual system where the user specifies the cached 
terminology to use as part of the app constructor, it would be up to 
them to ensure they used the correct one; c.f. AppleScript's 'using 
terminology from' blocks.

Admittedly, in a mostly-automatic system we might just wing it and 
assume that as long as the url/path matches, the application and the 
cached terminology are up to date. Rather less safe than checking 
version numbers, mind you, so some folk are bound to trip up 
following system/application updates since the cache system won't 
pick up on the change itself. I'd be very reluctant to make cache 
generation full automatic in this case, leaving it to the user to add 
to and update the cache directory completely by themselves.


>And you probably have to think of *why* you want caching. The choice 
>of how to organise things depends on whether the main goal is to 
>make remote scripting possible, or to speed up access to local apps, 
>or whatever other reason there may be.

Indeed. Keep thrashing. :)

Thanks,

has

-- 
http://freespace.virgin.net/hamish.sanderson/
From fonnesbeck at mac.com  Fri Oct 15 14:06:26 2004
From: fonnesbeck at mac.com (Christopher Fonnesbeck)
Date: Fri Oct 15 14:06:33 2004
Subject: [Pythonmac-SIG] Re: Attempted SciPy 0.3.2 build on MacOS X
In-Reply-To: <AD739580-1E58-11D9-AEFB-000A95ACFF76@radix.net>
References: <AD739580-1E58-11D9-AEFB-000A95ACFF76@radix.net>
Message-ID: <A3D6FC8E-1EA2-11D9-81F9-000A956FDAC0@mac.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Oct 14, 2004, at 11:17 PM, W.T. Bridgman wrote:

> Hello,
>
> I've made half-hearted attempts to install SciPy (v0.3) under OS X but 
> was concerned because it was unclear from the instructions whether the 
> test failures under scipy.stats module impacted the results from that 
> particular module.
>
> Anyway, when 0.3.2 was released with the claim that the tests pass on 
> OS X, I decided to give it a try using Chris Fonnesbeck's instructions 
> as a guide.   A few things I found:
>
> 1) The changes to setup.py don't seem to apply in this release.  I had 
> to remove ./Lib/sparse.
>

You dont need to remove anything -- you can simply add modules you dont 
want to the ignore_packages list in setup.py. I recommend using a CVS 
build. I have not had to mess with sparse in a long time.

> 2) The build failed with a somewhat strange error message from the 
> config.h file apparently created with xplt.  Since xplt/ was reported 
> as revised for the Mac, I opted to remove ./Lib/xplt as well.
>

  See comment above. No need to remove anything.

> 3) The build seemed to run to completion, so I ran the tests.  Some of 
> the messages were really cryptic as to whether the test was 
> successful, but the run finally failed with:

Some stats tests are known to fail -- they are not a big deal. That 
module is earmarked for a remake soon, I think.

These issues have all been mentioned on the scipy mailing list, so you 
might want to have a peek at the archives.

Cheers,
Chris

- --
Christopher J. Fonnesbeck ( f o n n e s b e c k @ m a c . c o m )
Georgia Cooperative Fish & Wildlife Research Unit
University of Georgia, Athens GA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBb71GytlHstVxLUURAn0XAKC31r2jvg4ES0A6zP6JZy+qN8/OuwCg2frQ
KsA0IijKRI7hf9lUluuPrCM=
=J2Ei
-----END PGP SIGNATURE-----

From rkern at ucsd.edu  Fri Oct 15 14:15:41 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Fri Oct 15 15:41:07 2004
Subject: [Pythonmac-SIG] Re: Attempted SciPy 0.3.2 build on MacOS X
In-Reply-To: <A3D6FC8E-1EA2-11D9-81F9-000A956FDAC0@mac.com>
References: <AD739580-1E58-11D9-AEFB-000A95ACFF76@radix.net>
	<A3D6FC8E-1EA2-11D9-81F9-000A956FDAC0@mac.com>
Message-ID: <416FBF6D.9060505@ucsd.edu>

Christopher Fonnesbeck wrote:

>> 3) The build seemed to run to completion, so I ran the tests.  Some of 
>> the messages were really cryptic as to whether the test was 
>> successful, but the run finally failed with:
> 
> 
> Some stats tests are known to fail -- they are not a big deal.

Not anymore. They have been fixed.

-- 
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter
From jbarden at wilcoxd.com  Fri Oct 15 16:36:15 2004
From: jbarden at wilcoxd.com (Jared Barden)
Date: Fri Oct 15 16:36:30 2004
Subject: [Pythonmac-SIG] PyObjc and Drag and Drop
Message-ID: <91DE62DB-1EB7-11D9-A7E8-00039357F62A@wilcoxd.com>

Hi All,
  I was just wondering if anyone has had success implementing drag and 
drop functionality in an NSTableView using PyObjc. I've been trying to 
get a simple example to work without much luck. I can select a row to 
drag and even drag it, but I cannot complete the drag operation (move 
the dragged row).
  I'm on OS 10.3.5. using PyObjc from CVS.
  Any suggestions would be greatly appreciated.

Thanks,
  Jared

From bhutten at ns.sympatico.ca  Fri Oct 15 17:06:59 2004
From: bhutten at ns.sympatico.ca (Bill Hutten)
Date: Fri Oct 15 17:07:02 2004
Subject: [Pythonmac-SIG] How to get OSX startup volume name?
Message-ID: <BD956DE3.23E0%bhutten@ns.sympatico.ca>



As the subject says - how do I do this?  I assume I'm missing something
obvious...


- bill
-- 
bill@hutten.org


From njriley at uiuc.edu  Fri Oct 15 17:40:12 2004
From: njriley at uiuc.edu (Nicholas Riley)
Date: Fri Oct 15 17:40:25 2004
Subject: [Pythonmac-SIG] How to get OSX startup volume name?
In-Reply-To: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
References: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
Message-ID: <20041015154012.GA94822@uiuc.edu>

On Fri, Oct 15, 2004 at 12:06:59PM -0300, Bill Hutten wrote:
> As the subject says - how do I do this?  I assume I'm missing something
> obvious...

Typically you'd use CFURLCopyFileSystemPath with kCFURLHFSPathStyle,
or FSGetCatalogInfo, but neither of these are wrapped in Python that I
can see.  If you have PyObjC installed, you could do:

Foundation.NSFileManager.defaultManager().displayNameAtPath_('/')

although it's possible that name could be a localized variant.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
From mjb at uma.pt  Fri Oct 15 17:41:34 2004
From: mjb at uma.pt (Michael J. Barber)
Date: Fri Oct 15 17:42:17 2004
Subject: [Pythonmac-SIG] How to get OSX startup volume name?
In-Reply-To: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
References: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
Message-ID: <B1B916CA-1EC0-11D9-8ABE-0050E4794D0F@uma.pt>

Amongst other ways:

import os
os.system("""osascript -e 'tell app "finder" to get the name of the 
startup disk'""")

Hope that helps.

On Oct 15, 2004, at 4:06 PM, Bill Hutten wrote:

>
>
> As the subject says - how do I do this?  I assume I'm missing something
> obvious...
>
>
> - bill
> -- 
> bill@hutten.org
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From bob at redivi.com  Fri Oct 15 17:45:38 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 15 17:46:17 2004
Subject: [Pythonmac-SIG] How to get OSX startup volume name?
In-Reply-To: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
References: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
Message-ID: <4324F330-1EC1-11D9-951D-000A95686CD8@redivi.com>


On Oct 15, 2004, at 11:06 AM, Bill Hutten wrote:

> As the subject says - how do I do this?  I assume I'm missing something
> obvious...

There are plenty of other ways but this is the one that occurred to me 
first that does not require PyObjC:

import Carbon.File
startupVolumeName = Carbon.File.FSRef('/').FSGetCatalogInfo()[1]

and here is a PyObjC example:

from Foundation import *
startupVolumeName = 
NSFileManager.defaultManager().displayNameAtPath_(u'/')

-bob
From bob at redivi.com  Fri Oct 15 17:46:23 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 15 17:46:31 2004
Subject: [Pythonmac-SIG] How to get OSX startup volume name?
In-Reply-To: <20041015154012.GA94822@uiuc.edu>
References: <BD956DE3.23E0%bhutten@ns.sympatico.ca>
	<20041015154012.GA94822@uiuc.edu>
Message-ID: <5DCF055A-1EC1-11D9-951D-000A95686CD8@redivi.com>


On Oct 15, 2004, at 11:40 AM, Nicholas Riley wrote:

> On Fri, Oct 15, 2004 at 12:06:59PM -0300, Bill Hutten wrote:
>> As the subject says - how do I do this?  I assume I'm missing 
>> something
>> obvious...
>
> Typically you'd use CFURLCopyFileSystemPath with kCFURLHFSPathStyle,
> or FSGetCatalogInfo, but neither of these are wrapped in Python that I
> can see.  If you have PyObjC installed, you could do:
>
> Foundation.NSFileManager.defaultManager().displayNameAtPath_('/')
>
> although it's possible that name could be a localized variant.

FSGetCatalogInfo is wrapped by Python.. it's a method of FSRef.

-bob

From enrike at altern.org  Fri Oct 15 17:46:19 2004
From: enrike at altern.org (altern)
Date: Fri Oct 15 17:47:04 2004
Subject: [Pythonmac-SIG] installing wxpython on panther
In-Reply-To: <721CE2DD-1EAB-11D9-BADD-000A95686CD8@redivi.com>
References: <AE7AF2F8-1E95-11D9-BE99-0003930EC1EA@ixi-software.net>
	<416FAC00.3000504@ixi-software.net>
	<721CE2DD-1EAB-11D9-BADD-000A95686CD8@redivi.com>
Message-ID: <416FF0CB.2070305@altern.org>

hi

i removed 2.3.3 (or at least i think i did it by following the 
instructions on the FAQ). Now i managed to install pyopengl and wxpython 
but i also need numeric and PIL. I am using the package manager but it 
doesnt download them properly. I discovered that PIL and numeric went 
into this folder

/library/frameworks/python.framework/versions/2.3/lib/python2.3/site-packages

while OpenGL and wx are in

/library/python/2.3

then i run python and i can import wx or opengl but not numeric or PIL.

i would have thoght that all packages should be installed in the default 
directory.

again, any tips?
thanks ...


Bob Ippolito wrote:
> 
> On Oct 15, 2004, at 6:52 AM, r2d2 wrote:
> 
>> hi
>>
>>>         i am trying to install wxpython on panther. My problem is that
>>>         because i installed python 3.3.3 and the default installer for
>>>         wxpython goes into the panther python version instead of the
>>>         latest version i installed.
>>>         i downloaded the source but i am not sure what i should do to
>>>         avoid this problem, i also tried the package manager but seems
>>>         to just download the .dmg so back to square one.
>>>         Any suggestions would be apreciated.
>>>     I suggest just sticking with the stock Python 2.3.0 and using the
>>>     binary installer. Otherwise you will have to compile everything  
>>> from
>>>     source, and you will certainly run into Version Mismatch 
>>> problems  at
>>>     some time or another.
>>
>>
>> i see.
>> but i need it together with other packages like opengl and they are  
>> already installed for the 2.3.3 python by the package manager, how 
>> can  i set the package manager to install the packages to the python  
>> version i want?. or maybe it would be easier to get rid of the python  
>> 2.3.3 i installed? but how to do it?
>>
>> Sorry if all this questions are very stupid but i have been using all  
>> this on windows and it was dead easy to set up, now i am still quite  
>> confused with the unix way to do things.
> 
> 
> Remove 2.3.3.
> 
> http://pythonmac.org/wiki/ 
> FAQ#head-45464eef844e198e465151f3b3953a4c15b9eacb
> 


-- 
enrike
From bob at redivi.com  Fri Oct 15 18:01:22 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 15 18:02:03 2004
Subject: [Pythonmac-SIG] installing wxpython on panther
In-Reply-To: <416FF0CB.2070305@altern.org>
References: <AE7AF2F8-1E95-11D9-BE99-0003930EC1EA@ixi-software.net>
	<416FAC00.3000504@ixi-software.net>
	<721CE2DD-1EAB-11D9-BADD-000A95686CD8@redivi.com>
	<416FF0CB.2070305@altern.org>
Message-ID: <756210B7-1EC3-11D9-951D-000A95686CD8@redivi.com>

On Oct 15, 2004, at 11:46 AM, altern wrote:

> Bob Ippolito wrote:
>> On Oct 15, 2004, at 6:52 AM, r2d2 wrote:
>>> hi
>>>
>>>>         i am trying to install wxpython on panther. My problem is  
>>>> that
>>>>         because i installed python 3.3.3 and the default installer  
>>>> for
>>>>         wxpython goes into the panther python version instead of the
>>>>         latest version i installed.
>>>>         i downloaded the source but i am not sure what i should do  
>>>> to
>>>>         avoid this problem, i also tried the package manager but  
>>>> seems
>>>>         to just download the .dmg so back to square one.
>>>>         Any suggestions would be apreciated.
>>>>     I suggest just sticking with the stock Python 2.3.0 and using  
>>>> the
>>>>     binary installer. Otherwise you will have to compile everything  
>>>>  from
>>>>     source, and you will certainly run into Version Mismatch  
>>>> problems  at
>>>>     some time or another.
>>>
>>>
>>> i see.
>>> but i need it together with other packages like opengl and they are   
>>> already installed for the 2.3.3 python by the package manager, how  
>>> can  i set the package manager to install the packages to the python  
>>>  version i want?. or maybe it would be easier to get rid of the  
>>> python  2.3.3 i installed? but how to do it?
>>>
>>> Sorry if all this questions are very stupid but i have been using  
>>> all  this on windows and it was dead easy to set up, now i am still  
>>> quite  confused with the unix way to do things.
>> Remove 2.3.3.
>> http://pythonmac.org/wiki/  
>> FAQ#head-45464eef844e198e465151f3b3953a4c15b9eacb
> i removed 2.3.3 (or at least i think i did it by following the  
> instructions on the FAQ). Now i managed to install pyopengl and  
> wxpython but i also need numeric and PIL. I am using the package  
> manager but it doesnt download them properly. I discovered that PIL  
> and numeric went into this folder
>
> /library/frameworks/python.framework/versions/2.3/lib/python2.3/site- 
> packages
>
> while OpenGL and wx are in
>
> /library/python/2.3
>
> then i run python and i can import wx or opengl but not numeric or PIL.
>
> i would have thoght that all packages should be installed in the  
> default directory.

Something broke your site-packages symlink!  It wasn't anything from  
PackageManager, perhaps the wxPython installer is broken?

the site-packages folder should be a symlink to /Library/Python/2.3.   
Move everything from the site-packages folder to /Library/Python/2.3  
and then recreate the symlink.

-bob
From brad.allen at omsdal.com  Fri Oct 15 19:07:42 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 15 19:08:40 2004
Subject: [Pythonmac-SIG] Dock: adding/removing/checking
Message-ID: <OFADB1242C.24EE427C-ON86256F2E.005C7B18-86256F2E.005E1712@omsdal.com>

What is the most appropriate way to interact with the Dock using Python? I
don't think my current method using the "defaults" command is optimal. It
only works when run as the user; however, most of my scripts are designed
to run as root/sudo because they are used for administering Macs on our LAN
at work. I'm wondering if there is a way to use a native API instead, but
didn't find what I was looking for at
http://developer.apple.com/documentation.

Thanks!

Below is my currently somewhat misguided approach:

(this relies on a function called getCommandOutput which I found in the
Python Cookbook at ActiveState)

def restartDock(username):
      cmd = 'killall -u ' + username + ' Dock'
      common.getCommandOutput(cmd)


def addAppToDock(pathToApp,username,verbose=False):
      #example: addAppToDock('/Applications/Microsoft Office 2004/Microsoft
Word','bonnie')
      assert os.path.exists(pathToApp)
      dockPrefPath =
os.path.join('/Users',username,'Library/Preferences/com.apple.dock')
      cmd = (
            "defaults write " + dockPrefPath + " persistent-apps
-array-add" + SPACE + SINGLEQUOTE +

"<dict><key>tile-data</key><dict><key>file-data</key><dict><key>_CFURLString</key><string>"
            + pathToApp +

"</string><key>_CFURLStringType</key><integer>0</integer></dict></dict></dict>"
            + SINGLEQUOTE
            )
      if verbose: print 'Executing:',cmd
      common.getCommandOutput(cmd)
      restartDock()

From bob at redivi.com  Fri Oct 15 19:26:54 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 15 19:27:32 2004
Subject: [Pythonmac-SIG] Dock: adding/removing/checking
In-Reply-To: <OFADB1242C.24EE427C-ON86256F2E.005C7B18-86256F2E.005E1712@omsdal.com>
References: <OFADB1242C.24EE427C-ON86256F2E.005C7B18-86256F2E.005E1712@omsdal.com>
Message-ID: <68A3E530-1ECF-11D9-A004-000A95686CD8@redivi.com>


On Oct 15, 2004, at 1:07 PM, brad.allen@omsdal.com wrote:

> What is the most appropriate way to interact with the Dock using 
> Python? I
> don't think my current method using the "defaults" command is optimal. 
> It
> only works when run as the user; however, most of my scripts are 
> designed
> to run as root/sudo because they are used for administering Macs on 
> our LAN
> at work. I'm wondering if there is a way to use a native API instead, 
> but
> didn't find what I was looking for at
> http://developer.apple.com/documentation.

I don't believe there's a "native API" for manipulating the dock 
because software applications are not "allowed" (by convention) to 
modify the dock.

I have two comments about what you're doing though:

- The way you call the defaults application is HORRENDOUS!  Wow.  I 
highly suggest using the subprocess module (formerly process, formerly 
popen5) that is going to be in Python 2.4, or at least 
os.spawnl/os.spawnv:
	(reference implementation) http://www.lysator.liu.se/~astrand/popen5/
	(proposal) http://www.python.org/peps/pep-0324.html

- You can also read/write plist files with PyObjC, using the 
NSUserDefaults and/or NSDictionary's plist 
serialization/deserialization methods instead of the defaults command, 
which is about as native as you're going to get.  The standard 
library's plistlib might also work, but it's not the most complete and 
accurate implementation out there, so I don't know how much I'd trust 
it for this purpose.

-bob
From Jack.Jansen at cwi.nl  Fri Oct 15 21:41:43 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Oct 15 21:41:44 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f0cbd94b092d6f1@[81.103.145.108]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
Message-ID: <3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>


On 15 Oct 2004, at 12:36, has wrote:
>> You then provide a default set of engines in a default order, but the 
>> users can change this order, or add their own special-purpose engine 
>> to the front, etc.
>
> I think pluggable engines would be overkill. There's only two places 
> terminology data could come from: the original application or the 
> cache. And there's only one resolution order that really makes sense: 
> if a cache is available then get the terminology from that, otherwise 
> get it from the application (or raise an error if that's not possible, 
> i.e. the application is remote).

I was thinking here of getting cached terminology from different 
places. For example, think of an option in py2app, where it would 
optionally precompile all the terminology needed and stuff it into the 
application bundle.

But I guess this could just as easily be handled by the caching engine 
searching multiple (configurable) places,
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From hengist.podd at virgin.net  Fri Oct 15 22:01:45 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 15 22:02:09 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
Message-ID: <a05200f0fbd95da1fb0d0@[81.103.145.108]>

Jack wrote:

>I was thinking here of getting cached terminology from different 
>places. For example, think of an option in py2app, where it would 
>optionally precompile all the terminology needed and stuff it into 
>the application bundle.

Terminology resources belong to installed applications, not client 
scripts, so it wouldn't make sense to bundle it with the latter. 
(i.e. It's specific to a machine, not to a script.)


>But I guess this could just as easily be handled by the caching 
>engine searching multiple (configurable) places,

site-packages/appscript_cache would be one option. 
/Library/Caches/appscript and/or(?) ~/Library/Caches/appscript would 
be another. There may be others. Not sure where would be best. Not 
sure if it needs to be user configurable or not. (Think of 
use-cases?) Not sure about write permissions. Any thoughts?

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From kevino at tulane.edu  Fri Oct 15 22:02:01 2004
From: kevino at tulane.edu (Kevin Ollivier)
Date: Fri Oct 15 22:02:12 2004
Subject: [Pythonmac-SIG] installing wxpython on panther
In-Reply-To: <416FF0CB.2070305@altern.org>
References: <AE7AF2F8-1E95-11D9-BE99-0003930EC1EA@ixi-software.net>
	<416FAC00.3000504@ixi-software.net>
	<721CE2DD-1EAB-11D9-BADD-000A95686CD8@redivi.com>
	<416FF0CB.2070305@altern.org>
Message-ID: <14091036-1EE5-11D9-A92B-000393CB1C86@tulane.edu>

Hi,

On Oct 15, 2004, at 8:46 AM, altern wrote:

> hi
>
> i removed 2.3.3 (or at least i think i did it by following the  
> instructions on the FAQ). Now i managed to install pyopengl and  
> wxpython but i also need numeric and PIL. I am using the package  
> manager but it doesnt download them properly. I discovered that PIL  
> and numeric went into this folder
>
> /library/frameworks/python.framework/versions/2.3/lib/python2.3/site- 
> packages

It looks like you still have parts of 2.3.3 installed.  
/Library/Frameworks/Python.Framework is where a user-installed Python  
puts it's extension modules.

Even though you built your own Python from source, you should follow  
the uninstallation instructions here:

http://homepages.cwi.nl/~jack/macpython/uninstall.html

Once that's done, make sure to get the MacPython for Panther additions  
from the download page to get Package Manager back. Then re-install the  
PIL and Numeric extension modules. Hopefully this should resolve your  
problem.

Kevin

> Bob Ippolito wrote:
>> On Oct 15, 2004, at 6:52 AM, r2d2 wrote:
>>> hi
>>>
>>>>         i am trying to install wxpython on panther. My problem is  
>>>> that
>>>>         because i installed python 3.3.3 and the default installer  
>>>> for
>>>>         wxpython goes into the panther python version instead of the
>>>>         latest version i installed.
>>>>         i downloaded the source but i am not sure what i should do  
>>>> to
>>>>         avoid this problem, i also tried the package manager but  
>>>> seems
>>>>         to just download the .dmg so back to square one.
>>>>         Any suggestions would be apreciated.
>>>>     I suggest just sticking with the stock Python 2.3.0 and using  
>>>> the
>>>>     binary installer. Otherwise you will have to compile everything  
>>>>  from
>>>>     source, and you will certainly run into Version Mismatch  
>>>> problems  at
>>>>     some time or another.
>>>
>>>
>>> i see.
>>> but i need it together with other packages like opengl and they are   
>>> already installed for the 2.3.3 python by the package manager, how  
>>> can  i set the package manager to install the packages to the python  
>>>  version i want?. or maybe it would be easier to get rid of the  
>>> python  2.3.3 i installed? but how to do it?
>>>
>>> Sorry if all this questions are very stupid but i have been using  
>>> all  this on windows and it was dead easy to set up, now i am still  
>>> quite  confused with the unix way to do things.
>> Remove 2.3.3.
>> http://pythonmac.org/wiki/  
>> FAQ#head-45464eef844e198e465151f3b3953a4c15b9eacb
>
>
> -- 
> enrike
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From bob at redivi.com  Fri Oct 15 22:56:04 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 15 22:56:44 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f0fbd95da1fb0d0@[81.103.145.108]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
Message-ID: <A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>


On Oct 15, 2004, at 4:01 PM, has wrote:

> Jack wrote:
>
>> I was thinking here of getting cached terminology from different 
>> places. For example, think of an option in py2app, where it would 
>> optionally precompile all the terminology needed and stuff it into 
>> the application bundle.
>
> Terminology resources belong to installed applications, not client 
> scripts, so it wouldn't make sense to bundle it with the latter. (i.e. 
> It's specific to a machine, not to a script.)

I'm not sure I agree with this.  I'm pretty sure that compiled 
applescripts do not depend on the terminology of the applications they 
talk to, and I would imagine that the vast majority of applications 
written in compiled languages that use AppleScript to talk to one 
another do not parse terminologies before they start talking.

>> But I guess this could just as easily be handled by the caching 
>> engine searching multiple (configurable) places,
>
> site-packages/appscript_cache would be one option. 
> /Library/Caches/appscript and/or(?) ~/Library/Caches/appscript would 
> be another. There may be others. Not sure where would be best. Not 
> sure if it needs to be user configurable or not. (Think of use-cases?) 
> Not sure about write permissions. Any thoughts?

I don't think transparent caching should happen at all.  Caching should 
be entirely explicit, there's just too many problems (having multiple 
versions of an application installed, write permissions on cache, cache 
getting out of sync with applications, client scripts written for 
version X of an application running on another machine that has a 
version Y terminology cached, etc.) and not enough benefits (faster 
startup for "free").

In other words, if implicit caching of AppleScript terminologies made 
sense, Script Editor would do it.  It doesn't.

-bob
From berkowit at silcom.com  Fri Oct 15 23:33:50 2004
From: berkowit at silcom.com (Paul Berkowitz)
Date: Fri Oct 15 23:33:55 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
Message-ID: <BD95904E.76A9A%berkowit@silcom.com>

On 10/15/04 1:56 PM, "Bob Ippolito" <bob@redivi.com> wrote:

> I'm not sure I agree with this.  I'm pretty sure that compiled
> applescripts do not depend on the terminology of the applications they
> talk to, and I would imagine that the vast majority of applications
> written in compiled languages that use AppleScript to talk to one
> another do not parse terminologies before they start talking.

Absolutely they do. It's not something you "agree to" or not. It's a fact.
Compiled applescripts DO depend on the terminology of the applications they
talk to.

Behind every keyword in AppleScript lies a hidden "raw code" which is the
real command. class or property. It appears in its own right as
?guillemets?, like that. They are always ?class xxxx? - 4 characters, or
?event xxxxxxxx?.- 8 characters. There are all sorts of rules about them,
such as that only Apple can use all lower-case. There are some English
keywords belonging to the AppleScript language itself. which will always
compile and decompile. But keywords belonging to an application will only
compile and decompile within a "tell application" block, and where the
application has to be present on the machine. If a script has been properly
compiled, it will not decompile or run on another machine if it can't find
an application of the correct name. What you seen then, if you open it in a
script editor, are the raw codes. And the script will not run. It asks the
user where the application in question is, and if the user cannot find it
correctly (it may be under another name), it fails.  As has mentioned,
there's a clever 'using terms from' block you can use when you compile a
script that lets you direct a tell block to an application by variable. That
allows the script to compile (with raw codes) on another machine, and if the
script is designed to allow the Finder to find the application, under
whatever name, by its creator code or CFBundleIdentifier in a plist, it will
run.

I'm startled that someone of your acuity in your own area, Python, would
imagine that has doesn't know what he's talking about in AppleScript. He's
an expert, one of the very, very few who knows its inner workings. Unless
you somehow know better for certain, I think that a good working policy
would be to take has's word for everything to do with how AppleScript works.

-- 
Paul Berkowitz
(an AppleScripter)


From bob at redivi.com  Sat Oct 16 00:01:22 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct 16 00:02:02 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <BD95904E.76A9A%berkowit@silcom.com>
References: <BD95904E.76A9A%berkowit@silcom.com>
Message-ID: <C054E9D1-1EF5-11D9-BD19-000A95686CD8@redivi.com>


On Oct 15, 2004, at 5:33 PM, Paul Berkowitz wrote:

> On 10/15/04 1:56 PM, "Bob Ippolito" <bob@redivi.com> wrote:
>
>> I'm not sure I agree with this.  I'm pretty sure that compiled
>> applescripts do not depend on the terminology of the applications they
>> talk to, and I would imagine that the vast majority of applications
>> written in compiled languages that use AppleScript to talk to one
>> another do not parse terminologies before they start talking.
>
> Absolutely they do. It's not something you "agree to" or not. It's a 
> fact.
> Compiled applescripts DO depend on the terminology of the applications 
> they
> talk to.
>
> Behind every keyword in AppleScript lies a hidden "raw code" which is 
> the
> real command. class or property. It appears in its own right as
> ?guillemets?, like that. They are always ?class xxxx? - 4 characters, 
> or
> ?event xxxxxxxx?.- 8 characters. There are all sorts of rules about 
> them,
> such as that only Apple can use all lower-case. There are some English
> keywords belonging to the AppleScript language itself. which will 
> always
> compile and decompile. But keywords belonging to an application will 
> only
> compile and decompile within a "tell application" block, and where the
> application has to be present on the machine. If a script has been 
> properly
> compiled, it will not decompile or run on another machine if it can't 
> find
> an application of the correct name. What you seen then, if you open it 
> in a
> script editor, are the raw codes. And the script will not run. It asks 
> the
> user where the application in question is, and if the user cannot find 
> it
> correctly (it may be under another name), it fails.  As has mentioned,
> there's a clever 'using terms from' block you can use when you compile 
> a
> script that lets you direct a tell block to an application by 
> variable. That
> allows the script to compile (with raw codes) on another machine, and 
> if the
> script is designed to allow the Finder to find the application, under
> whatever name, by its creator code or CFBundleIdentifier in a plist, 
> it will
> run.
>
> I'm startled that someone of your acuity in your own area, Python, 
> would
> imagine that has doesn't know what he's talking about in AppleScript. 
> He's
> an expert, one of the very, very few who knows its inner workings. 
> Unless
> you somehow know better for certain, I think that a good working policy
> would be to take has's word for everything to do with how AppleScript 
> works.

You misinterpreted what I had said.  I'll restate it in a more precise 
manner:

I'm pretty sure that compiled applescripts do not depend on acquiring 
and parsing an aete from the target application(s) at runtime, and I'm 
even more sure that most applications that use apple events for IAC do 
not acquire and parse an aete at runtime from their target 
application(s).

-bob
From Jack.Jansen at cwi.nl  Sat Oct 16 01:00:31 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sat Oct 16 01:00:36 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
Message-ID: <03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>


On 15 Oct 2004, at 22:56, Bob Ippolito wrote:
>> Terminology resources belong to installed applications, not client 
>> scripts, so it wouldn't make sense to bundle it with the latter. 
>> (i.e. It's specific to a machine, not to a script.)
>
> I'm not sure I agree with this.  I'm pretty sure that compiled 
> applescripts do not depend on the terminology of the applications they 
> talk to, and I would imagine that the vast majority of applications 
> written in compiled languages that use AppleScript to talk to one 
> another do not parse terminologies before they start talking.

I agree with this (with Bob, that is). It would be very nice if we 
could have this same behaviour for Python. And while we can't in the 
general case, because there's no "compile step" for Python, it would be 
good to have it at least for py2app packaged programs.

I'm toying with an idea to abuse Python's import mechanism for this, 
something along the lines that when you need the terminology for MyApp 
you import MagicTerminologyGenerator.MyApp, and when 
MagicTerminologyGenerator/MyApp.pyc exists it'll be used automatically, 
but if it doesn't exist then the magic importer will create it (there's 
no MagicTerminologyGenerator/MyApp.py, that's somehow how the magic 
kicks in). But then you're storing the cached terminology in the 
MagicTerminologyGenerator package, and that's not really where you want 
it.

Hmm, could it be that if module foo.py uses the terminology for MyApp, 
and that terminology has not been created yet, you want the compiled 
terminology in the same place where you have foo.pyc?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From wtbridgman at radix.net  Sat Oct 16 01:11:39 2004
From: wtbridgman at radix.net (W.T. Bridgman)
Date: Sat Oct 16 01:11:39 2004
Subject: [Pythonmac-SIG] Re: Attempted SciPy 0.3.2 build on MacOS X
In-Reply-To: <416FBF6D.9060505@ucsd.edu>
References: <AD739580-1E58-11D9-AEFB-000A95ACFF76@radix.net>
	<A3D6FC8E-1EA2-11D9-81F9-000A956FDAC0@mac.com>
	<416FBF6D.9060505@ucsd.edu>
Message-ID: <91F57471-1EFF-11D9-863F-000A95ACFF76@radix.net>

Zowie!

I just tried a straight install and it built and passed the tests.

Thanks!

Tom
On Oct 15, 2004, at 8:15 AM, Robert Kern wrote:

> Christopher Fonnesbeck wrote:
>
>>> 3) The build seemed to run to completion, so I ran the tests.  Some 
>>> of the messages were really cryptic as to whether the test was 
>>> successful, but the run finally failed with:
>> Some stats tests are known to fail -- they are not a big deal.
>
> Not anymore. They have been fixed.
>
> -- 
> Robert Kern
> rkern@ucsd.edu
>
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From enrike at altern.org  Sat Oct 16 11:31:00 2004
From: enrike at altern.org (altern)
Date: Sat Oct 16 11:33:21 2004
Subject: [Pythonmac-SIG] installing wxpython on panther
In-Reply-To: <756210B7-1EC3-11D9-951D-000A95686CD8@redivi.com>
References: <AE7AF2F8-1E95-11D9-BE99-0003930EC1EA@ixi-software.net>
	<416FAC00.3000504@ixi-software.net>
	<721CE2DD-1EAB-11D9-BADD-000A95686CD8@redivi.com>
	<416FF0CB.2070305@altern.org>
	<756210B7-1EC3-11D9-951D-000A95686CD8@redivi.com>
Message-ID: <4170EA54.3090707@altern.org>

Bob Ippolito wrote:
> On Oct 15, 2004, at 11:46 AM, altern wrote:
> 
>> Bob Ippolito wrote:
>>
>>> On Oct 15, 2004, at 6:52 AM, r2d2 wrote:
>>>
>>>> hi
>>>>
>>>>>         i am trying to install wxpython on panther. My problem is  
>>>>> that
>>>>>         because i installed python 3.3.3 and the default installer  
>>>>> for
>>>>>         wxpython goes into the panther python version instead of the
>>>>>         latest version i installed.
>>>>>         i downloaded the source but i am not sure what i should do  to
>>>>>         avoid this problem, i also tried the package manager but  
>>>>> seems
>>>>>         to just download the .dmg so back to square one.
>>>>>         Any suggestions would be apreciated.
>>>>>     I suggest just sticking with the stock Python 2.3.0 and using  the
>>>>>     binary installer. Otherwise you will have to compile 
>>>>> everything   from
>>>>>     source, and you will certainly run into Version Mismatch  
>>>>> problems  at
>>>>>     some time or another.
>>>>
>>>>
>>>>
>>>> i see.
>>>> but i need it together with other packages like opengl and they 
>>>> are   already installed for the 2.3.3 python by the package manager, 
>>>> how  can  i set the package manager to install the packages to the 
>>>> python   version i want?. or maybe it would be easier to get rid of 
>>>> the  python  2.3.3 i installed? but how to do it?
>>>>
>>>> Sorry if all this questions are very stupid but i have been using  
>>>> all  this on windows and it was dead easy to set up, now i am still  
>>>> quite  confused with the unix way to do things.
>>>
>>> Remove 2.3.3.
>>> http://pythonmac.org/wiki/  
>>> FAQ#head-45464eef844e198e465151f3b3953a4c15b9eacb
>>
>> i removed 2.3.3 (or at least i think i did it by following the  
>> instructions on the FAQ). Now i managed to install pyopengl and  
>> wxpython but i also need numeric and PIL. I am using the package  
>> manager but it doesnt download them properly. I discovered that PIL  
>> and numeric went into this folder
>>
>> /library/frameworks/python.framework/versions/2.3/lib/python2.3/site- 
>> packages
>>
>> while OpenGL and wx are in
>>
>> /library/python/2.3
>>
>> then i run python and i can import wx or opengl but not numeric or PIL.
>>
>> i would have thoght that all packages should be installed in the  
>> default directory.
> 
> 
> Something broke your site-packages symlink!  It wasn't anything from  
> PackageManager, perhaps the wxPython installer is broken?
> 
> the site-packages folder should be a symlink to /Library/Python/2.3.   
> Move everything from the site-packages folder to /Library/Python/2.3  
> and then recreate the symlink.
> 
> -bob

well. now its working. But i dont know how i did it. Suddently they were 
all in the right place and i could import them. I tried to connect the 
package manager to other urls provided by python.org but whenever i 
wanted to download and install some package i always got a message 
saying that i needed to install those packages manually. After that 
everything was working ok. Weird.

anyway, its working and my problems are finally coding problems and not 
installation issues :-) I am porting to mac some opengl+wxpython stuff i 
developed under windows.

I get a "bus error" caused by this opengl code (it didnt happen on windows)
q = gluNewQuadric()
anyone knows if this is a bug? but maybe i would be better to ask in 
pyopengl mailing list.

finally, i am trying to find a nice environment to code. under windows i 
was quite happy with IDLE but the mac version dowsnt color the syntax 
and there are some other featurtes missing.

thanks!!!

-- 
enrike

From hengist.podd at virgin.net  Sat Oct 16 14:46:09 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct 16 17:10:01 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
Message-ID: <a05200f10bd96994cb669@[81.103.145.108]>

Bob wrote:

>>Terminology resources belong to installed applications, not client 
>>scripts, so it wouldn't make sense to bundle it with the latter. 
>>(i.e. It's specific to a machine, not to a script.)
>
>I'm not sure I agree with this.

It's a matter of perspective.


>I'm pretty sure that compiled applescripts do not depend on the 
>terminology of the applications they talk to,

Correct: when an AS script is compiled, the AS compiler translates 
application keywords into raw AE codes. Thus compiled AppleScripts do 
not need terminology to execute. This was done for efficiency's sake, 
since AppleScript 1.0 was designed to run on memory-starved 16MHz 
Macs. It also explains why Apple never bothered to optimise the 
terminology system: they didn't need it to be fast because it's not 
normally invoked at runtime. There are tradeoffs in converting 
identifiers to AE codes at runtime, however - I can list the various 
problems with it if anyone wants.


>and I would imagine that the vast majority of applications written 
>in compiled languages that use AppleScript

[You meant 'Apple events', yes?]


>to talk to one another do not parse terminologies before they start talking.

Apps using the Carbon Apple Event Manager API won't use terminology 
at all, just raw AE codes. The Cocoa API doesn't support sending 
events, so that's academic, but uses terminology in Cocoa Scripting.

---

As a sidenote, something to remember here is that Apple events were 
deliberately designed to sacrifice ease of use for raw efficiency 
(binary encoding data, using 32-bit ints instead of human-readable 
names as keys, etc). Nowadays we can afford to burn some extra 
cycles, thus newer RPC mechanisms will encode data as XML, use 
arbitrary-length strings as keys and verbose mini-languages to 
construct references; Cocoa Scripting hides a lot of the Apple Event 
Manager's gnarliness beneath a terminology-driven layer; etc. In 
other words, there's no reason we must follow the same 15 year-old 
design compromises today, and it would be short-sighted to do so 
simply because "that's the way they did it". Remember, I came to 
Python precisely to escape from AppleScript. :)

---

>I don't think transparent caching should happen at all.

In a perfect world we wouldn't need caching at all: Apple's APIs 
would be comprehensive and fast (also, network latency would always 
be zero, pigs would fly, etc...).

This not being a perfect world, we use caching to compensate for its 
inadequacies. Now, from a usability POV, an ideal caching system 
_would_ be completely automatic, requiring no user interaction at all.

Again, this not being a perfect world, a 100% automatic caching 
system of the kind we're currently discussing is not possible. At the 
very minimum, remote application scripting requires that the remote 
application's terminology is manually created and locally cached 
since there's no way to retrieve it automatically across a network. 
So the sysadmin will have to do at least some work to keep things 
running smoothly.


>Caching should be entirely explicit, there's just too many problems 
>(having multiple versions of an application installed, write 
>permissions on cache, cache getting out of sync with applications, 
>client scripts written for version X of an application running on 
>another machine that has a version Y terminology cached, etc.)

Yes. Exactly the sort of real-world problems I'm struggling over, 
trying to see if there's any way to resolve some or all of them.

One note here: there are two _separate_ operations to consider:

1. adding terminologies to the cache

2. retrieving terminologies from the cache.

We already know that it's impossible to automate #1 entirely, but 
whether #1 is fully-manual/semi-automatic/fully-automatic has no 
bearing whatsoever on #2. Even if #1 were fully manual it could still 
be possible to make #2 fully automatic, and an automatic #2 would 
still have considerable worth from a usability POV since it would 
mean caching would remain transparent to the client scripts that its 
main beneficiaries.



>In other words, if implicit caching of AppleScript terminologies 
>made sense, Script Editor would do it.  It doesn't.

Like AppleScript, Script Editor doesn't do it because it doesn't need 
to. We, however, are neither AppleScript nor Script Editor. 
Fortunately. :)

Many thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Sat Oct 16 15:39:45 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct 16 17:10:24 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
Message-ID: <a05200f11bd96bc22e091@[81.103.145.108]>

Jack Jansen wrote:

>>>Terminology resources belong to installed applications, not client 
>>>scripts, so it wouldn't make sense to bundle it with the latter. 
>>>(i.e. It's specific to a machine, not to a script.)
>>
>>I'm not sure I agree with this.  I'm pretty sure that compiled 
>>applescripts do not depend on the terminology of the applications 
>>they talk to, and I would imagine that the vast majority of 
>>applications written in compiled languages that use AppleScript to 
>>talk to one another do not parse terminologies before they start 
>>talking.
>
>I agree with this (with Bob, that is). It would be very nice if we 
>could have this same behaviour for Python.

Having not that long ago escaped from the mind-melting mess that is 
AppleScript, I can pretty much guarantee that you _don't_ want Python 
to behave just like AS does. :)

There are a lot of things AppleScript does because it had to make 
severe compromises, mostly due to processor and memory constraints, 
then that we're not forced to make today. There's a lot of other 
mistakes it makes because its designers' ambitions far outstripped 
the existing knowledge and resources available at the time, and which 
were never rectified over time for one reason or another (sudden 
disbandment of the original dev team by management; fundamental flaws 
that can't be foxed short of a 100% redesign+rewrite, etc). So while 
it's a useful source of design lessons, most are lessons in how you 
SHOULDN'T to do things rather than how you should.


>And while we can't in the general case, because there's no "compile 
>step" for Python, it would be good to have it at least for py2app 
>packaged programs.

I assume you're not referring to AS's hideous habit of baking AE 
codes right into the bytecode, but a rather less toxic solution of 
merely attaching a bunch of runtime translation tables to a script, 
yes?

However, I still can't see the value in binding a server 
application's terminology translation tables to client programs. All 
that happens is your system swims with lots of terminology modules 
that may or may not have any relation to the applications that are 
actually installed. Wouldn't it make more sense to have one 
terminology module per installed application?

Another thing to consider: if you're going to have breakage caused by 
a mismatch between the version of application the script was authored 
for and the version of application actually installed, wouldn't it be 
better to break at a higher level, eg:

	Error: application "Foo" doesn't understand command "do_something"

which is what happens when appscript encounters an identifier for 
which no terminology definition exists, rather than:

	Error: application "Foo" doesn't understand <<event FooADsom>>

which happens when aem sends an unrecognised event.


>I'm toying with an idea to abuse Python's import mechanism for this, 
>something along the lines that when you need the terminology for 
>MyApp you import MagicTerminologyGenerator.MyApp, and when 
>MagicTerminologyGenerator/MyApp.pyc exists it'll be used 
>automatically,

There's a problem with that inasmuch as Python identifiers are 
limited to alphanumeric characters, thus you often won't be able to 
use an app's real name, e.g. Acrobat_Reader_5_0 rather than 'Acrobat 
Reader 5.0'. Otherwise I don't see any real advantage in this over 
something like:

	itunes = app('eppc://20.20.20.20/iTunes', usingtermsfrom='iTunes.app')

where the terminology module associated with 'iTunes.app' (presumably 
this association is specified by the user when creating the cached 
terminology) is retrieved as part of the app() constructor's duties.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Sat Oct 16 17:06:17 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct 16 17:10:25 2004
Subject: [Pythonmac-SIG] appscript terminology caching
Message-ID: <a05200f14bd96c4a5df21@[81.103.145.108]>

Paul wrote:

>  > I'm not sure I agree with this.  I'm pretty sure that compiled
>  > applescripts do not depend on the terminology of the applications they
>  > talk to
>
>Absolutely they do. It's not something you "agree to" or not. It's a fact.
>Compiled applescripts DO depend on the terminology of the applications they
>talk to.

Woah - steady there, tiger. :)

Bob is correct, even if his original statement is a bit ambiguous*. A 
compiled AppleScript does not require access to an application's 
terminology in order to run; only compilation and decompilation use 
it.

* i.e. Bob's comment makes sense in context of the discussion, which 
is about how appscript should translate between terminology keywords 
and AE codes at runtime. Personally I understood it just fine, though 
as past master of the faux-pas myself I can easily see how it could 
be read wrongly. Honest misunderstanding; nothing anyone should get 
steamed about, least of all on my account. :)



>I think that a good working policy
>would be to take has's word for everything to do with how AppleScript works.

Err, I _definitely_ wouldn't go that far myself <g> (see past AS 
mailing list posts ad-infinitum;). I've certainly never seen 
AppleScript's inner workings and what I know about them I've gleaned 
partly from folk who have but mostly from obsessively observing 
external behaviour and waiting for my hypotheses about why it works 
the way it works to break (or be broken). Given all the effort sunk 
into this, it's probably true I understand AS better than 99.9% of 
its users - but then the great majority of AS users aren't hugely 
computer literate; nor (quite rightly) could they give a flying crap 
about what's really going on (as long as it does what they meant it 
to do).

One thing I am pretty certain of: if anyone is looking for a good 
role model for how Python's application scripting support should 
work, at this stage AppleScript is just about the last thing you want 
to pick. I've already nicked every good idea it has so whatever's 
still left is the absolute dross, and you don't wanna touch that. ;p


Basically, we're more or less on our own from here in, and stuck with 
outdated, obtuse and ill-fitting AppleScript-biased system APIs that 
we just have to make the best of. Our best hope is that the result is 
good enough to garner a solid and sizeable userbase, which we can 
then use to lean on Apple to make their APIs a bit more egalitarian, 
if not outright chummy, towards the more Unix-oriented languages such 
as Python and Perl. I see all this as an opportunity though: for 
MacPython to come up with the best damn scripting support of _any_ 
language, and become _the_ role model for others to follow. Hence 
this discussion, to shake out the good ideas from bad and see if 
anything's left standing by the end of it. <g>

Regards,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From joaoleao at gmx.net  Sat Oct 16 20:40:13 2004
From: joaoleao at gmx.net (=?ISO-8859-1?Q?Jo=E3o_Le=E3o?=)
Date: Sat Oct 16 20:40:26 2004
Subject: [Pythonmac-SIG] Accented characters and Python
Message-ID: <D13909B8-1FA2-11D9-8EAC-000393967AF4@gmx.net>

Hi everyone

I'm having some trouble with accented characters (or non ascii 
characters).
Everything works fine when I just want to print or save to a file. For 
example:

 >>> s = '?'  ------> accented a
 >>> print s
?                  ------> output is fine
 >>> s
'\x87\x8e'

Even when the string is read from a function like os.listdir(), the 
output with 'print' will work preserving the acented characters.

The problem comes when I have to pass this string to some function not 
so smart as 'print'.
For the sake of example, here is a small snippet of code that draws 
some text in a CoreGraphics's BitmapContext:

This will workfine:
_
s = '<some_accented_characters>'
c.showText (s, len(s))
_

But this won't work (the output will show other strange accented 
characters):
_
s = os.listdir('.')[1]   #suppose s is again a string of accented 
characters
c.showText (s, len(s))

This function is obviously using the wrong encodement for the output 
(the right one would be iso-8859-1, I suppose) and I can' figure a way 
to tell it which to use.
I found some articles about encodements but I don't really know what is 
the right thing to do. Then I tried several things like converting the 
string to unicode and then decode it to latin-1, but that was not the 
answer.

Thanks for any help.
_
jo?o

From bob at redivi.com  Sat Oct 16 21:50:15 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct 16 21:50:55 2004
Subject: [Pythonmac-SIG] Accented characters and Python
In-Reply-To: <D13909B8-1FA2-11D9-8EAC-000393967AF4@gmx.net>
References: <D13909B8-1FA2-11D9-8EAC-000393967AF4@gmx.net>
Message-ID: <999F5878-1FAC-11D9-B97B-000A95686CD8@redivi.com>


On Oct 16, 2004, at 2:40 PM, Jo?o Le?o wrote:

> Hi everyone
>
> I'm having some trouble with accented characters (or non ascii 
> characters).
> Everything works fine when I just want to print or save to a file. For 
> example:
>
> >>> s = '?'  ------> accented a

It's generally a bad idea to ever keep non-ascii text in strings, use 
unicode whenever possible.  With an OS X terminal, you know that the 
strings are in utf-8, so s = '?'.decode('utf8') is a better way to do 
it.  Normally you could just do u'?', however Python defaults to ascii 
default encoding so it won't know what to do with that.  In a Python 
script, you can set the encoding as you see fit and do u'?' with 
correct results.

#!/usr/bin/python
# -*- coding: utf-8 -*-

(see http://www.python.org/peps/pep-0263.html for more information 
about Python source encodings)

> >>> print s
> ?                  ------> output is fine

When you're using unicode strings, this won't work by default since the 
default encoding is ascii, so you should wrap stdout with something 
unicode-aware

import sys, codecs
sys.stdout = codecs.getwriter('utf-8')(sys.stdout)

then printing unicode will work just fine.  The alternative is to set 
the defaultencoding to utf-8 in a sitecustomize.py (it can not 
typically be changed at runtime).. but I recommend against that because 
it makes it more difficult to redistribute correct code (what works on 
your machine may not work elsewhere b/c of the different default 
encoding).

> >>> s
> '\x87\x8e'
>
> Even when the string is read from a function like os.listdir(), the 
> output with 'print' will work preserving the acented characters.

Convert it to unicode first..  If you pass a unicode path to os.listdir 
it will return unicode paths.

s = os.listdir(u'.')

If you have a regular string for whatever reason, it's probably in the 
filesystem encoding (utf-8 on OS X), so do:
s = os.listdir(path.decode(sys.getfilesystemencoding()))

> The problem comes when I have to pass this string to some function not 
> so smart as 'print'.
> For the sake of example, here is a small snippet of code that draws 
> some text in a CoreGraphics's BitmapContext:
>
> This will workfine:
> _
> s = '<some_accented_characters>'
> c.showText (s, len(s))
> _
>
> But this won't work (the output will show other strange accented 
> characters):
> _
> s = os.listdir('.')[1]   #suppose s is again a string of accented 
> characters
> c.showText (s, len(s))
>
> This function is obviously using the wrong encodement for the output 
> (the right one would be iso-8859-1, I suppose) and I can' figure a way 
> to tell it which to use.
> I found some articles about encodements but I don't really know what 
> is the right thing to do. Then I tried several things like converting 
> the string to unicode and then decode it to latin-1, but that was not 
> the answer.

Nope, Windows uses latin-1, Mac OS X certainly does not.  It uses 
utf-8, which is very similar to latin-1 for some characters, but can 
represent arbitrary unicode characters.

-bob
From smiles at saysomething.com  Sat Oct 16 21:56:39 2004
From: smiles at saysomething.com (Christopher Smith)
Date: Sat Oct 16 22:35:17 2004
Subject: [Pythonmac-SIG] PyOXIDE 0.7.0 on 10.2.8
Message-ID: <7E31423A-1FAD-11D9-BC5E-000393C0D100@saysomething.com>

> PyOXIDE 0.7.0 has only been tested with 10.3, but should work with  
> 10.2 (assuming it can find the python framework).

I just downloaded this new version, did a restart and tried to run 
PyOxide on 10.2.8.  It starts, I can see the Release Notes text, but 
the application quits after about 3 seconds.

Any idea what the problem might be? Is it a 10.3/10.2 issue?

/c

From Jack.Jansen at cwi.nl  Sat Oct 16 22:48:35 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sat Oct 16 22:48:36 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f11bd96bc22e091@[81.103.145.108]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
Message-ID: <BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>


On 16 Oct 2004, at 15:39, has wrote:
>> And while we can't in the general case, because there's no "compile 
>> step" for Python, it would be good to have it at least for py2app 
>> packaged programs.
>
> I assume you're not referring to AS's hideous habit of baking AE codes 
> right into the bytecode, but a rather less toxic solution of merely 
> attaching a bunch of runtime translation tables to a script, yes?

I was indeed thinking of the latter, really pretty similar to what the 
gensuitemodule stuff did but a bit less "manual".

But now that we're on the subject, and given that you're the resident 
AS/OSA expert: could you explain what is so bad about baking the AE 
codes into the bytecode? Because to me it seems perfectly sensible: as 
the AE codes are the "real" language you insulate your program from 
whatever changes happen to the human-readable version of the language 
afterwards. Up to and including Apple's (luckily long abolished) 
translation of AppleScript into French.

Moreover, I think that binary/ascii doesn't really make much of a 
difference here. XML documents need an exact DTD URI to remain valid, 
so they might as well be binary for that matter.

Of course, if some misguided vendor subsequently changes the 
interpretation of the AE codes in an incompatible way you're hosed. But 
the same is true for AppleScript-the-language: I remember that 
MetroWerks at one point completely redesigned their suites and re-used 
some of the old verbs in completely incompatible ways...
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From sw at wordtech-software.com  Sat Oct 16 23:13:55 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Sat Oct 16 23:13:59 2004
Subject: [Pythonmac-SIG] appscript
In-Reply-To: <20041016204835.ED5831E4008@bag.python.org>
References: <20041016204835.ED5831E4008@bag.python.org>
Message-ID: <41718F13.1070009@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been following the threads on AppleScript and appscript with a lot
of interest, and a bit of awe at has's expertise with AppleScript: it's
very impressive.

This has brought me, though, to what is perhaps a dumb question: is the
purpose of appscript to render AppleScript commands in Python syntax?
I'm a bit confused on this point.

I'm approaching this question from the perspective of Tcl, where it's
possible to drop into AppleScript directly (if you have the
TclAppleScript extension installed) using this command/syntax:


AppleScript execute {
	tell application "foo"
		do foo
	end tell
}

One can do something similar in a shell script, if I'm not mistaken, via
osascript (something like <<EOF osascript -"blah blah blah"<<EOF

I certainly don't mind learning another way to work with AppleScript,
I'm probably a bit spoiled by the simplicity of calling it in a Tcl
script. Anyway, any illumination on this point is appreciated.

Kevin


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBcY8SJmdQs+6YVcoRAuDFAJ9qGJMhs6oy3vgn2qP2KZtI+89SxQCfR6Lq
nCrJ4dd5QTVEigX6EMLb0mQ=
=uA/5
-----END PGP SIGNATURE-----
From Jack.Jansen at cwi.nl  Sat Oct 16 23:30:17 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sat Oct 16 23:30:19 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f14bd96c4a5df21@[81.103.145.108]>
References: <a05200f14bd96c4a5df21@[81.103.145.108]>
Message-ID: <92BB5CCD-1FBA-11D9-B80D-000D934FF6B4@cwi.nl>


On 16 Oct 2004, at 17:06, has wrote:
>  I see all this as an opportunity though: for MacPython to come up 
> with the best damn scripting support of _any_ language, and become 
> _the_ role model for others to follow. Hence this discussion, to shake 
> out the good ideas from bad and see if anything's left standing by the 
> end of it. <g>

Yeah! Towards World Domination!

I've been giving the whole subject (caching, precompiling, etc) a 
little more thought (over the last cigarette:-), and I think there are 
really two types of users. Or, actually, two types of use cases, 
probably with most users going from one to the other.

The first use case is throwaway scripts, or the development stage of a 
longer lived script. At this stage ease of use is the most important 
feature. This seems to point towards dynamic compilation of 
terminology.

The second use case is anything from a production script to a 
distributable binary application. Now you are much more interested in 
stability and efficiency. This points towards static precompilation of 
terminology.

Notice that the wrong type of compilation is actually detrimental to 
the use cases:
- if you have precompiled terminology while developing a script and 
that terminology is outdated the user will be wondering why s/he cannot 
access the same features of yesterday's release of SampleApplication.
- if we compile terminology on the fly Python scripts will not only be 
less efficient than AppleScripts, but they'll also be prone to more 
incompatibilities. AppleScripts continue running as long as the 
underlying codes remain valid, and if that isn't true then it's the 
vendor of SampleApplication who's gonna get the blame.

Assuming we agree on the previous bits there's one difficult question 
remaining: when and how do you switch from dynamic to static 
compilation? My feeling is that the user (the script developer) should 
somehow do this explicitly, as the user is the only person who knows 
when the script goes from development stage to production stage. I 
think it's clear that py2app should precompile terminology. The same is 
probably true when you save your script as an applet. At the other end 
of the spectrum there's running your script in the IDE, an which case 
you definitely don't want it. But in-between (double-clickable or 
commandline script) things are a bit less clear, because we don't 
really know what stage the user is in. Maybe we should use the MacOS9 
Script Editor distinction (Script, Runnable Script, Applet) with the 
latter two using precompiled terminology?

Note that there's one thing here that I haven't said explicitly yet, 
but that I think is important: the distinction between development and 
production is per-script, not per-user or systemwide or whatever. And a 
module counts as a script too. And I have no clear idea yet how to 
implement this (aside from yesterday's half-baked idea of storing the 
terminology somewhere alongside the .pyc file for the module/script 
using the terminology, but that's only half-baked because it ignores 
reuse).
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From Jack.Jansen at cwi.nl  Sat Oct 16 23:43:48 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sat Oct 16 23:43:48 2004
Subject: [Pythonmac-SIG] appscript
In-Reply-To: <41718F13.1070009@wordtech-software.com>
References: <20041016204835.ED5831E4008@bag.python.org>
	<41718F13.1070009@wordtech-software.com>
Message-ID: <761CE2C6-1FBC-11D9-B80D-000D934FF6B4@cwi.nl>


On 16 Oct 2004, at 23:13, Kevin Walzer wrote:

> This has brought me, though, to what is perhaps a dumb question: is the
> purpose of appscript to render AppleScript commands in Python syntax?
> I'm a bit confused on this point.
>
> I'm approaching this question from the perspective of Tcl, where it's
> possible to drop into AppleScript directly (if you have the
> TclAppleScript extension installed) using this command/syntax:
>
>
> AppleScript execute {
> 	tell application "foo"
> 		do foo
> 	end tell
> }
>
> One can do something similar in a shell script, if I'm not mistaken, 
> via
> osascript (something like <<EOF osascript -"blah blah blah"<<EOF

That's fine for simple scripts, but it breaks as soon as you want to 
communicate data. What AppScript does (like gensuitemodule and aeve 
before it) is expose the full OSA object model to Python. This allows 
you to use the power of Python to do things that are pretty much 
impossible in a "little language" like AppleScript.

As a somewhat contrived example (can't think of a non-contrived one 
right now:-): think of a script that asks iTunes for the contents of 
your music library and formats that as an HTML page. With AppScript and 
Python this is probably 20 lines or so. With only a construct like 
"AppleScript execute" it'll be much longer due to all the parsing of 
the script output you have to do. With standalone AppleScript I don't 
even want to ponder the question;-)
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From hengist.podd at virgin.net  Sun Oct 17 09:55:46 2004
From: hengist.podd at virgin.net (has)
Date: Sun Oct 17 10:30:56 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
Message-ID: <a05200f02bd97ce3e14d0@[81.101.66.68]>

Hey,

>>I assume you're not referring to AS's hideous habit of baking AE 
>>codes right into the bytecode, but a rather less toxic solution of 
>>merely attaching a bunch of runtime translation tables to a script, 
>>yes?
>
>I was indeed thinking of the latter, really pretty similar to what 
>the gensuitemodule stuff did but a bit less "manual".
>
>But now that we're on the subject, and given that you're the 
>resident AS/OSA expert: could you explain what is so bad about 
>baking the AE codes into the bytecode? Because to me it seems 
>perfectly sensible: as the AE codes are the "real" language you 
>insulate your program from whatever changes happen to the 
>human-readable version of the language afterwards.

If you mean the AppleScript way, it breaks WYSIWYG. I can give you a 
list of problems it causes, but don't have time today; will send it 
Wednesday.

If you mean the way you're suggesting, it adds complexity to users' 
projects (yet more files to track), adds inconsistency in behaviour 
(may use terminology from application OR terminology from projects), 
slightly breaks WYSIWYG (may override an application's own 
terminology) and doesn't seem to provide any benefit over an "ideal" 
caching system. It's not awful by any means, but I think we could 
(and should!) do better.

Appscript deliberately draws the line between script and application 
at the higher level than AppleScript, at the terminology level. Folks 
who want to work with AE codes can use aem.

I guess it's about what you consider the formal application interface 
definition. As far as appscript users are concerned, it's the 
keyword-based definitions in the terminology resource, and it's those 
keywords they use to write their code. They don't care about AE 
codes, etc. and shouldn't have to be bothered about dealing with them.


My position is simply this: appscript should simply "work". Anything 
that falls short of this goal (e.g. by requiring manual user 
intervention) should be beaten until it does, or until we run out of 
better options. So far, all caching approaches seem to have their 
fair share of problems. Whatever turns out to be the "least 
undesireable" option we should go with, but I think there's plenty 
still to be explored before we have to make a decision.

Anyway, I'll be back Wednesday if you can manage to hold out till 
then. If I have time, I'll try experimenting with the 'terminology 
server' idea I just had and let you know if/how that turns out.

Many thanks, this is being a big help,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Sun Oct 17 10:31:32 2004
From: hengist.podd at virgin.net (has)
Date: Sun Oct 17 10:31:41 2004
Subject: [Pythonmac-SIG] appscript
Message-ID: <a05200f03bd97d62af052@[81.101.66.68]>

Jack Jansen wrote:

>On 16 Oct 2004, at 23:13, Kevin Walzer wrote:
>
>  > This has brought me, though, to what is perhaps a dumb question: is the
>  > purpose of appscript to render AppleScript commands in Python syntax?
>  > I'm a bit confused on this point.
>  >
>  > I'm approaching this question from the perspective of Tcl, where it's
>  > possible to drop into AppleScript directly (if you have the
>  > TclAppleScript extension installed) using this command/syntax:
>  >
>  >
>  > AppleScript execute {
>  >	tell application "foo"
>  >		do foo
>  >	end tell
>  > }
>  >
>  > One can do something similar in a shell script, if I'm not mistaken,
>  > via
>  > osascript (something like <<EOF osascript -"blah blah blah"<<EOF
>
>That's fine for simple scripts, but it breaks as soon as you want to
>communicate data.

Yep. The shell lacks datatypes: everything basically has to be 
handled as strings. Which is fine for Tcl which does this anyway, but 
for typed languages like AS and Python it means a lot of work in 
converting non-text input and output.

You can also execute OSA scripts (including AppleScript) from Python 
using the osax module's runscript() function. This supports non-text 
input and output.

Main problem with both approaches: they rely on pre-written 
AppleScript scripts, or code generators to generate AS source, to get 
anything done. It would be much nicer to write _everything_ in pure 
Python - which is what appscript lets you do.


>What AppScript does (like gensuitemodule and aeve
>before it) is expose the full OSA object model to Python. This allows
>you to use the power of Python to do things that are pretty much
>impossible in a "little language" like AppleScript.

What Jack says: appscript hooks into the same IAC APIs as AppleScript 
uses. (Cuts out the middleman, so to speak.:)


>As a somewhat contrived example (can't think of a non-contrived one
>right now:-): think of a script that asks iTunes for the contents of
>your music library and formats that as an HTML page. With AppScript and
>Python this is probably 20 lines or so. With only a construct like
>"AppleScript execute" it'll be much longer due to all the parsing of
>the script output you have to do. With standalone AppleScript I don't
>even want to ponder the question;-)

http://freespace.virgin.net/hamish.sanderson/iac_examples/iTunes_albums_to_HTML.html

http://applemods.sourceforge.net/mods/Internet/HTMLTemplate.php 
(includes a demo, iTunesToWeb)

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From brad.allen at omsdal.com  Sun Oct 17 15:57:10 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Sun Oct 17 15:58:00 2004
Subject: [Pythonmac-SIG] Dock: adding/removing/checking
In-Reply-To: <68A3E530-1ECF-11D9-A004-000A95686CD8@redivi.com>
Message-ID: <OF679C7859.681BF5BE-ON86256F30.00497618-86256F30.004CA5C8@omsdal.com>



Bob Ippolito <bob@redivi.com> wrote on 10/15/2004 12:26:54 PM:

> I don't believe there's a "native API" for manipulating the dock
> because software applications are not "allowed" (by convention) to
> modify the dock.

I see. No wonder it's been so difficult to find documentation on this.
Still, some software installers do add icons to the Dock. Example: MS
Office 2004.


> I have two comments about what you're doing though:
>
> - The way you call the defaults application is HORRENDOUS!  Wow.  I
> highly suggest using the subprocess module (formerly process, formerly
> popen5) that is going to be in Python 2.4, or at least
> os.spawnl/os.spawnv:

I've used this "getCommandOutput" function fairly extensively with success,
so I'd like to find out what's wrong with it.


#--------------begin Python Cookbook popen example code---------
#because FCNTL has been deprecated in favor of fcntl, I found changes
posted by a commenter
#at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296
#I don't really understand the nonBlocking stuff, but it seems to work --BA


def makeNonBlocking(fd):
    fl = fcntl.fcntl(fd, fcntl.F_GETFL)
    try:
      fcntl.fcntl(fd, fcntl.F_SETFL, fl | os.O_NDELAY)
    except AttributeError:
      fcntl.fcntl(fd, fcntl.F_SETFL, fl | os.FNDELAY)

def getCommandOutput(command):
    child = popen2.Popen3(command, 1) # Capture stdout and stderr from
command
    child.tochild.close(  )             # don't need to write to child's
stdin
    outfile = child.fromchild
    outfd = outfile.fileno(  )
    errfile = child.childerr
    errfd = errfile.fileno(  )
    makeNonBlocking(outfd)            # Don't deadlock! Make fd's
nonblocking.
    makeNonBlocking(errfd)
    outdata = errdata = ''
    outeof = erreof = 0
    while 1:
        ready = select.select([outfd,errfd],[],[]) # Wait for input
        if outfd in ready[0]:
            outchunk = outfile.read(  )
            if outchunk == '': outeof = 1
            outdata = outdata + outchunk
        if errfd in ready[0]:
            errchunk = errfile.read(  )
            if errchunk == '': erreof = 1
            errdata = errdata + errchunk
        if outeof and erreof: break
        select.select([],[],[],.1) # Allow a little time for buffers to
fill
    err = child.wait(  )
    if err != 0:
        raise RuntimeError, '%s failed with exit code %d\n%s' % (
            command, err, errdata)
    return outdata

#--------------end Python Cookbook popen example code-----------


> - You can also read/write plist files with PyObjC, using the
> NSUserDefaults and/or NSDictionary's plist
> serialization/deserialization methods instead of the defaults command,
> which is about as native as you're going to get.  The standard
> library's plistlib might also work, but it's not the most complete and
> accurate implementation out there, so I don't know how much I'd trust
> it for this purpose.


Ok, thanks. I will look into this.


From bob at redivi.com  Sun Oct 17 19:22:07 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sun Oct 17 19:22:49 2004
Subject: [Pythonmac-SIG] Dock: adding/removing/checking
In-Reply-To: <OF679C7859.681BF5BE-ON86256F30.00497618-86256F30.004CA5C8@omsdal.com>
References: <OF679C7859.681BF5BE-ON86256F30.00497618-86256F30.004CA5C8@omsdal.com>
Message-ID: <1278357E-2061-11D9-8278-000A95686CD8@redivi.com>


On Oct 17, 2004, at 9:57 AM, brad.allen@omsdal.com wrote:

> Bob Ippolito <bob@redivi.com> wrote on 10/15/2004 12:26:54 PM:
>
>> - The way you call the defaults application is HORRENDOUS!  Wow.  I
>> highly suggest using the subprocess module (formerly process, formerly
>> popen5) that is going to be in Python 2.4, or at least
>> os.spawnl/os.spawnv:
>
> I've used this "getCommandOutput" function fairly extensively with 
> success,
> so I'd like to find out what's wrong with it.
>
> #at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296

It uses a string for the command line, instead of an array, which makes 
for really ugly and fragile code.  Subprocess wouldn't be going into 
Python 2.4 if it wasn't a vast improvement over the existing 
facilities.

-bob
From eric.nieuwland at xs4all.nl  Mon Oct 18 00:47:52 2004
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Mon Oct 18 00:47:55 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f02bd97ce3e14d0@[81.101.66.68]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
Message-ID: <941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>

A small question to all you gurus on this topic.

How will the caching system handle updates to an application of which 
the terminology is cached?

--eric

From Jack.Jansen at cwi.nl  Mon Oct 18 11:21:15 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Mon Oct 18 11:21:14 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
Message-ID: <0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>


On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:

> A small question to all you gurus on this topic.
>
> How will the caching system handle updates to an application of which 
> the terminology is cached?

That's one of the problems we're trying to sort out. Has wants to do it 
automatically whereas Bob and myself seem to tend towards a more manual 
solution, whereby the script writer somehow explicitly triggers it.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From brad.allen at omsdal.com  Mon Oct 18 23:36:51 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Mon Oct 18 23:37:49 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <1278357E-2061-11D9-8278-000A95686CD8@redivi.com>
Message-ID: <OF93EF3559.FF143E1A-ON86256F31.007000CD-86256F31.0076BC88@omsdal.com>

This is a bit of a sidetrack from the original topic involving the OS X
dock, so I changed the subject header for this thread. My reply to Bob is
posted below:

Bob Ippolito <bob@redivi.com> wrote on 10/17/2004 12:22:07 PM:
>
> On Oct 17, 2004, at 9:57 AM, brad.allen@omsdal.com wrote:
>
> > Bob Ippolito <bob@redivi.com> wrote on 10/15/2004 12:26:54 PM:
> >
> >> - The way you call the defaults application is HORRENDOUS!  Wow.  I
> >> highly suggest using the subprocess module (formerly process, formerly
> >> popen5) that is going to be in Python 2.4, or at least
> >> os.spawnl/os.spawnv:
> >
> > I've used this "getCommandOutput" function fairly extensively with
> > success,
> > so I'd like to find out what's wrong with it.
> >
> > #at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296
>
> It uses a string for the command line, instead of an array, which makes
> for really ugly and fragile code.  Subprocess wouldn't be going into
> Python 2.4 if it wasn't a vast improvement over the existing
> facilities.

Ok; that's a useful criticism. Using os.spawnv looks like a good way to
execute some commands in which I need to don't need capture output, such as
the defaults command. In those cases just need to know the exit status (1
or 0), which os.spawnv does provide. However, the os.popen approach appears
more useful when I want to capture the output of a command. Unfortunately,
the popen variants only accept a string argument.

Most of the time when I need to capture the output of a command, it's
because I don't know how to use the native APIs. I really need to find a
better way to do these things. For instance, check out these beauties
excepted from my maclib module (feel free to throw rotten fruit at me):


def getBuiltinEthernetAddress():
      en0 = common.getCommandOutput("/sbin/ifconfig en0")
      #we have data from ifconfig en0; now we need to parse it
      cleanAddress = '' #initialize this variable in case it fails to
populate
      try:
            etherLine = ''
            for line in en0.split('\n'):
                  if (line.count('ether') > 0):
                        etherLine = line
                        break
            address = (etherLine.strip()).split(' ')[1]
            #get rid of colon separators because they cause problems in Mac
filenames; replace with '-'
            cleanAddress = address.replace(':','-')
      except Exception, thisErr:
            raise thisErr
      if len(cleanAddress) == 17:
            return cleanAddress
      else:
            raise Exception,'bad address: ' + str(cleanAddress)

def getMacOSXversion():
      sw_vers = common.getCommandOutput('/usr/bin/sw_vers')
      sw_vers_dict = common.colonTextListToDict(sw_vers)
      return sw_vers_dict['ProductVersion']



def printerIsSetup (printerName):
      cupsDeviceDump = common.getCommandOutput('lpstat -s')
      """Example output:
      device for 2804_HP42: lpd://10.100.28.97/2804_HP42
      device for _3213overIP_on_10.100.32.18: lpd://10.100.32.18/3213overIP
      device for _3223_XDC: pap://OMS/3223_XDC/LaserWriter
      device for Approval_Direct_150_4C:
pap://TLP_Dallas/Approval_Direct_150_4C/LaserWriter
      device for TEST_XE_2:
EZIP_backend://pa-test-xe-2.omsdal.com:515/TEST_XE_2
      device for TLP_2807_55c: pap://Harwood_Printers/2807_55c/Laserwriter
      """
      if cupsDeviceDump.count(printerName) > 1:
            return True
      else:
            return False

def getSystemProfilerHardwareDict ():
      if getMacOSXversion()[:4] == '10.2':
            return '{}' #not supported under 10.2
      hardwareText = common.getCommandOutput('system_profiler
SPHardwareDataType')
      hardwareDict = common.colonTextListToDict(hardwareText)
      return hardwareDict

From bob at redivi.com  Tue Oct 19 00:02:48 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 00:03:22 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <OF93EF3559.FF143E1A-ON86256F31.007000CD-86256F31.0076BC88@omsdal.com>
References: <OF93EF3559.FF143E1A-ON86256F31.007000CD-86256F31.0076BC88@omsdal.com>
Message-ID: <72A7F7C3-2151-11D9-9236-000A95BA5446@redivi.com>


On Oct 18, 2004, at 17:36, brad.allen@omsdal.com wrote:

> This is a bit of a sidetrack from the original topic involving the OS X
> dock, so I changed the subject header for this thread. My reply to Bob 
> is
> posted below:
>
> Bob Ippolito <bob@redivi.com> wrote on 10/17/2004 12:22:07 PM:
>>
>> On Oct 17, 2004, at 9:57 AM, brad.allen@omsdal.com wrote:
>>
>>> Bob Ippolito <bob@redivi.com> wrote on 10/15/2004 12:26:54 PM:
>>>
>>>> - The way you call the defaults application is HORRENDOUS!  Wow.  I
>>>> highly suggest using the subprocess module (formerly process, 
>>>> formerly
>>>> popen5) that is going to be in Python 2.4, or at least
>>>> os.spawnl/os.spawnv:
>>>
>>> I've used this "getCommandOutput" function fairly extensively with
>>> success,
>>> so I'd like to find out what's wrong with it.
>>>
>>> #at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296
>>
>> It uses a string for the command line, instead of an array, which 
>> makes
>> for really ugly and fragile code.  Subprocess wouldn't be going into
>> Python 2.4 if it wasn't a vast improvement over the existing
>> facilities.
>
> Ok; that's a useful criticism. Using os.spawnv looks like a good way to
> execute some commands in which I need to don't need capture output, 
> such as
> the defaults command. In those cases just need to know the exit status 
> (1
> or 0), which os.spawnv does provide. However, the os.popen approach 
> appears
> more useful when I want to capture the output of a command. 
> Unfortunately,
> the popen variants only accept a string argument.

That is why I presented os.spawnv as a "worst case" alternative to the 
subprocess module!  Please stop using popen, getCommandOutput, etc.  
They all suck, use subprocess.

-bob

From jerry.levan at eku.edu  Tue Oct 19 00:29:25 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Tue Oct 19 00:29:29 2004
Subject: [Pythonmac-SIG] Couple'o Tkinter Questions...
In-Reply-To: <20041014100037.4BBC71E4004@bag.python.org>
References: <20041014100037.4BBC71E4004@bag.python.org>
Message-ID: <2ACB13C2-2155-11D9-B9A2-000393779D9C@eku.edu>

Hi,

I am using apple's python with the "apple extensions" to get pythonw.
My Tk is the TclTk Aqua Batteries Included version 8.4.7 by Dan Steffen.

1) Is there anyway to get rid of the white box that surrounds buttons?

2) This might be foolish, but I can't seem to find the magic incantation
    that allows a single frame to expand to fill a top level window via
    the grid manager...

    I can do it via pack ie:

     form = Frame(root)   # root is a Toplevel window
     #form.grid(row=0,column=0,sticky='NSEW',padx=20,pady=10)
     #form.rowconfigure(0,weight=1)
     #
     form.pack(side=TOP,expand=YES,fill=BOTH,padx=20,pady=10)
     form.configure(bg='light blue')

     But I just can't seem to find the magic for the grid geometry
     manager....

Thanks,

Jerry

From brad.allen at omsdal.com  Tue Oct 19 01:25:17 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Tue Oct 19 01:26:14 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <72A7F7C3-2151-11D9-9236-000A95BA5446@redivi.com>
Message-ID: <OFDE9572B6.D5099547-ON86256F31.007D58A1-86256F31.0080AA18@omsdal.com>


Bob Ippolito <bob@redivi.com> wrote on 10/18/2004 05:02:48 PM:

> That is why I presented os.spawnv as a "worst case" alternative to the
> subprocess module!  Please stop using popen, getCommandOutput, etc.
> They all suck, use subprocess.

Doesn't that require Python 2.4, or is it a separate module I can import? I
understand Python 2.4 is still in beta, so I'd have a lot of questions
about deploying that in our production environment.

From bob at redivi.com  Tue Oct 19 01:40:08 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 01:40:42 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <OFDE9572B6.D5099547-ON86256F31.007D58A1-86256F31.0080AA18@omsdal.com>
References: <OFDE9572B6.D5099547-ON86256F31.007D58A1-86256F31.0080AA18@omsdal.com>
Message-ID: <0B7CC777-215F-11D9-9236-000A95BA5446@redivi.com>


On Oct 18, 2004, at 19:25, brad.allen@omsdal.com wrote:

>
> Bob Ippolito <bob@redivi.com> wrote on 10/18/2004 05:02:48 PM:
>
>> That is why I presented os.spawnv as a "worst case" alternative to the
>> subprocess module!  Please stop using popen, getCommandOutput, etc.
>> They all suck, use subprocess.
>
> Doesn't that require Python 2.4, or is it a separate module I can 
> import? I
> understand Python 2.4 is still in beta, so I'd have a lot of questions
> about deploying that in our production environment.

No it does not require Python 2.4.  If you look at PEP 291 it says that 
subprocess shall remain backwards compatible with Python 2.2.

-bob

From eichin at metacarta.com  Tue Oct 19 01:51:55 2004
From: eichin at metacarta.com (eichin@metacarta.com)
Date: Tue Oct 19 01:52:05 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <72A7F7C3-2151-11D9-9236-000A95BA5446@redivi.com>
References: <OF93EF3559.FF143E1A-ON86256F31.007000CD-86256F31.0076BC88@omsdal.com>
	<72A7F7C3-2151-11D9-9236-000A95BA5446@redivi.com>
Message-ID: <7g8ya3vb38.fsf@pikespeak.metacarta.com>

Mmm, looks like subprocess.call() does what os.system should have done
all along, namely what perl does - if you give it an array, it doesn't
do any unsafe string or shell manipulation, it just slots the
arguments into the relevant underlying syscall.  (On the other hand,
spawnv already did that...)

None of the PEP 324 examples deal with actual pipelines, though, so I
can't tell yet if it'll help with my pipeline class (which does
explicit pipe/fork/exec/wait and returns a list of the exit statuses
of the entire pipe - and works with lists, not strings, so it's again
argument-safe.)

I actually use commands.getoutput on ifconfig in some code because
it's a lot more *portable* than doing the GIFCONF ioctls, and if I'm
not allowing any user specified arguments the call is safe enough (I
can tell if it failed simply because the output is verbose enough that
if the parser fails, Something Went Wrong and I can just report that.)
For shell-script-equivalent stuff, it is actually *far* more readable
than any of the Popen.communicate examples in the PEP, and that's
worth a great deal in some contexts.  If anything, I'd like to see the
stuff in commands implemented using subprocess, and then extended to
handle list-arguments; ifconfoutput = commands.getoutput(["ifconfig", "en0"])
would be readable *and* safe, if it were implemented :-)

From bob at redivi.com  Tue Oct 19 02:31:26 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 02:32:06 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <7g8ya3vb38.fsf@pikespeak.metacarta.com>
References: <OF93EF3559.FF143E1A-ON86256F31.007000CD-86256F31.0076BC88@omsdal.com>
	<72A7F7C3-2151-11D9-9236-000A95BA5446@redivi.com>
	<7g8ya3vb38.fsf@pikespeak.metacarta.com>
Message-ID: <368D248A-2166-11D9-9236-000A95BA5446@redivi.com>

On Oct 18, 2004, at 19:51, eichin@metacarta.com wrote:

> Mmm, looks like subprocess.call() does what os.system should have done
> all along, namely what perl does - if you give it an array, it doesn't
> do any unsafe string or shell manipulation, it just slots the
> arguments into the relevant underlying syscall.  (On the other hand,
> spawnv already did that...)

and execv, etc.  popen and system are the problem children :)

> None of the PEP 324 examples deal with actual pipelines, though, so I
> can't tell yet if it'll help with my pipeline class (which does
> explicit pipe/fork/exec/wait and returns a list of the exit statuses
> of the entire pipe - and works with lists, not strings, so it's again
> argument-safe.)

Well Popen is a relatively low level primitive, if you want to do 
pipelines you have hooks to set the stdin/stdout/stderr filehandles.

> I actually use commands.getoutput on ifconfig in some code because
> it's a lot more *portable* than doing the GIFCONF ioctls, and if I'm
> not allowing any user specified arguments the call is safe enough (I
> can tell if it failed simply because the output is verbose enough that
> if the parser fails, Something Went Wrong and I can just report that.)
> For shell-script-equivalent stuff, it is actually *far* more readable
> than any of the Popen.communicate examples in the PEP, and that's
> worth a great deal in some contexts.  If anything, I'd like to see the
> stuff in commands implemented using subprocess, and then extended to
> handle list-arguments; ifconfoutput = commands.getoutput(["ifconfig", 
> "en0"])
> would be readable *and* safe, if it were implemented :-)

So write it and submit it.. it's pretty trivial stuff, the patch might 
even be accepted.. maybe not for 2.4, though.

-bob

From jerry.levan at eku.edu  Tue Oct 19 04:23:19 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Tue Oct 19 04:23:22 2004
Subject: [Pythonmac-SIG] Re: Couple'o Tkinter Questions...
In-Reply-To: <2ACB13C2-2155-11D9-B9A2-000393779D9C@eku.edu>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<2ACB13C2-2155-11D9-B9A2-000393779D9C@eku.edu>
Message-ID: <D75681CE-2175-11D9-B9A2-000393779D9C@eku.edu>

Well, question 2 is easy after all..

     root.rowconfigure(0,weight=1)
     root.columnconfigure(0,weight=1)
     form = Frame(root)
     form.grid(row=0,column=0,sticky='NSEW',padx=20,pady=10)
     form.configure(bg='light green')

Does the trick...

Jerry
On Oct 18, 2004, at 6:29 PM, Jerry LeVan wrote:

> Hi,
>
> I am using apple's python with the "apple extensions" to get pythonw.
> My Tk is the TclTk Aqua Batteries Included version 8.4.7 by Dan 
> Steffen.
>
> 1) Is there anyway to get rid of the white box that surrounds buttons?
>
> 2) This might be foolish, but I can't seem to find the magic 
> incantation
>    that allows a single frame to expand to fill a top level window via
>    the grid manager...
>
>    I can do it via pack ie:
>
>     form = Frame(root)   # root is a Toplevel window
>     #form.grid(row=0,column=0,sticky='NSEW',padx=20,pady=10)
>     #form.rowconfigure(0,weight=1)
>     #
>     form.pack(side=TOP,expand=YES,fill=BOTH,padx=20,pady=10)
>     form.configure(bg='light blue')
>
>     But I just can't seem to find the magic for the grid geometry
>     manager....
>
> Thanks,
>
> Jerry
>

From eric.nieuwland at xs4all.nl  Tue Oct 19 10:51:28 2004
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Tue Oct 19 10:51:32 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
Message-ID: <10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>

On 18-okt-04, at 11:21, Jack Jansen wrote:
> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>> How will the caching system handle updates to an application of which 
>> the terminology is cached?
>
> That's one of the problems we're trying to sort out. Has wants to do 
> it automatically whereas Bob and myself seem to tend towards a more 
> manual solution, whereby the script writer somehow explicitly triggers 
> it.

Haven't lost the gift of asking the obvious ;-)

Why not add a parameter to the indicate whether or not to check for 
changes if the terminology is cached?
You'll have to rely on version numbers in the app to decide if the app 
was updated, but that should be OK.

--eric

From mwh at python.net  Tue Oct 19 11:28:03 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Oct 19 11:28:06 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <a05200f14bd96c4a5df21@[81.103.145.108]> (has's message of
	"Sat, 16 Oct 2004 16:06:17 +0100")
References: <a05200f14bd96c4a5df21@[81.103.145.108]>
Message-ID: <2mmzyjgiqk.fsf@starship.python.net>

has <hengist.podd@virgin.net> writes:

> ... but then the great majority of AS users aren't hugely computer
> literate; nor (quite rightly) could they give a flying crap about
> what's really going on (as long as it does what they meant it to
> do).

This is of course the problem with AppleScript: it never does what I
meant it to do, so I do give a crap about what's really going on but
have never been able to figure it out (despite being rather more than
just "computer literate").

Good luck on doing better :)

Cheers,
mwh

-- 
  > I'm a little confused.
  That's because you're Australian!  So all the blood flows to
  your head, away from the organ most normal guys think with.
                        -- Mark Hammond & Tim Peters, comp.lang.python
From mwh at python.net  Tue Oct 19 11:31:59 2004
From: mwh at python.net (Michael Hudson)
Date: Tue Oct 19 11:32:02 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <7g8ya3vb38.fsf@pikespeak.metacarta.com> (eichin@metacarta.com's
	message of "18 Oct 2004 19:51:55 -0400")
References: <OF93EF3559.FF143E1A-ON86256F31.007000CD-86256F31.0076BC88@omsdal.com>
	<72A7F7C3-2151-11D9-9236-000A95BA5446@redivi.com>
	<7g8ya3vb38.fsf@pikespeak.metacarta.com>
Message-ID: <2mis97gik0.fsf@starship.python.net>

eichin@metacarta.com writes:

> Mmm, looks like subprocess.call() does what os.system should have done
> all along, 

Bah.  os.system wraps the C call system().  It's possible that Python
should have provided The One Obvious Way of doing this better before
now (on unix, at least, there have been a bewildering array of ways of
doing better for a Long Time), but, well, os.system isn't the place to
hang it.  So There :-)

Cheers,
mwh

-- 
  <sjj> dash: you certainly are an enigma wrapped in a riddle
        wrapped in a hat.                       -- from Twisted.Quotes
From bob at redivi.com  Tue Oct 19 15:15:18 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 15:15:57 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
Message-ID: <EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>

On Oct 19, 2004, at 4:51, Eric Nieuwland wrote:

> On 18-okt-04, at 11:21, Jack Jansen wrote:
>> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>>> How will the caching system handle updates to an application of 
>>> which the terminology is cached?
>>
>> That's one of the problems we're trying to sort out. Has wants to do 
>> it automatically whereas Bob and myself seem to tend towards a more 
>> manual solution, whereby the script writer somehow explicitly 
>> triggers it.
>
> Haven't lost the gift of asking the obvious ;-)
>
> Why not add a parameter to the indicate whether or not to check for 
> changes if the terminology is cached?
> You'll have to rely on version numbers in the app to decide if the app 
> was updated, but that should be OK.

The reason cached terminologies are useful is because *asking* for 
terminologies is slow.  If you have to ask if it's updated, you might 
as well not have cached it in the first place.  If you don't ask if 
it's updated, then it's impossible to know for sure whether or not your 
cached terminology is stale.

-bob

From eric.nieuwland at xs4all.nl  Tue Oct 19 17:03:10 2004
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Tue Oct 19 17:03:14 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
Message-ID: <FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>

On 19-okt-04, at 15:15, Bob Ippolito wrote:
> On Oct 19, 2004, at 4:51, Eric Nieuwland wrote:
>> On 18-okt-04, at 11:21, Jack Jansen wrote:
>>> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>>>> How will the caching system handle updates to an application of 
>>>> which the terminology is cached?
>>>
>>> That's one of the problems we're trying to sort out. Has wants to do 
>>> it automatically whereas Bob and myself seem to tend towards a more 
>>> manual solution, whereby the script writer somehow explicitly 
>>> triggers it.
>>
>> Why not add a parameter to the indicate whether or not to check for 
>> changes if the terminology is cached?
>> You'll have to rely on version numbers in the app to decide if the 
>> app was updated, but that should be OK.
>
> The reason cached terminologies are useful is because *asking* for 
> terminologies is slow.  If you have to ask if it's updated, you might 
> as well not have cached it in the first place.  If you don't ask if 
> it's updated, then it's impossible to know for sure whether or not 
> your cached terminology is stale.

OK. But to check the version you can access the app's Info.plist. Is 
that slow as well?

--eric

From bob at redivi.com  Tue Oct 19 17:15:31 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 17:16:04 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
Message-ID: <B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>


On Oct 19, 2004, at 11:03, Eric Nieuwland wrote:

> On 19-okt-04, at 15:15, Bob Ippolito wrote:
>> On Oct 19, 2004, at 4:51, Eric Nieuwland wrote:
>>> On 18-okt-04, at 11:21, Jack Jansen wrote:
>>>> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>>>>> How will the caching system handle updates to an application of 
>>>>> which the terminology is cached?
>>>>
>>>> That's one of the problems we're trying to sort out. Has wants to 
>>>> do it automatically whereas Bob and myself seem to tend towards a 
>>>> more manual solution, whereby the script writer somehow explicitly 
>>>> triggers it.
>>>
>>> Why not add a parameter to the indicate whether or not to check for 
>>> changes if the terminology is cached?
>>> You'll have to rely on version numbers in the app to decide if the 
>>> app was updated, but that should be OK.
>>
>> The reason cached terminologies are useful is because *asking* for 
>> terminologies is slow.  If you have to ask if it's updated, you might 
>> as well not have cached it in the first place.  If you don't ask if 
>> it's updated, then it's impossible to know for sure whether or not 
>> your cached terminology is stale.
>
> OK. But to check the version you can access the app's Info.plist. Is 
> that slow as well?

Info.plist isn't guaranteed to change when the application does.  Heck, 
it's not even totally guaranteed to exist (remote apple events, CFM 
apps, OS9 apps running in Classic).

-bob

From eric.nieuwland at xs4all.nl  Tue Oct 19 17:44:47 2004
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Tue Oct 19 17:44:51 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
Message-ID: <CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>

On 19-okt-04, at 17:15, Bob Ippolito wrote:
> On Oct 19, 2004, at 11:03, Eric Nieuwland wrote:
>> On 19-okt-04, at 15:15, Bob Ippolito wrote:
>>> On Oct 19, 2004, at 4:51, Eric Nieuwland wrote:
>>>> On 18-okt-04, at 11:21, Jack Jansen wrote:
>>>>> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>>>>>> How will the caching system handle updates to an application of 
>>>>>> which the terminology is cached?
>>>>>
>>>>> That's one of the problems we're trying to sort out. Has wants to 
>>>>> do it automatically whereas Bob and myself seem to tend towards a 
>>>>> more manual solution, whereby the script writer somehow explicitly 
>>>>> triggers it.
>>>>
>>>> Why not add a parameter to the indicate whether or not to check for 
>>>> changes if the terminology is cached?
>>>> You'll have to rely on version numbers in the app to decide if the 
>>>> app was updated, but that should be OK.
>>>
>>> The reason cached terminologies are useful is because *asking* for 
>>> terminologies is slow.  If you have to ask if it's updated, you 
>>> might as well not have cached it in the first place.  If you don't 
>>> ask if it's updated, then it's impossible to know for sure whether 
>>> or not your cached terminology is stale.
>>
>> OK. But to check the version you can access the app's Info.plist. Is 
>> that slow as well?
>
> Info.plist isn't guaranteed to change when the application does.  
> Heck, it's not even totally guaranteed to exist (remote apple events, 
> CFM apps, OS9 apps running in Classic).

:-(

Would adding a parameter with values 'always', 'if there is none', 
'never' to control when the terminology is to be generated do the 
trick?

From bob at redivi.com  Tue Oct 19 17:51:28 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 17:52:04 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
Message-ID: <BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>

On Oct 19, 2004, at 11:44, Eric Nieuwland wrote:

> On 19-okt-04, at 17:15, Bob Ippolito wrote:
>> On Oct 19, 2004, at 11:03, Eric Nieuwland wrote:
>>> On 19-okt-04, at 15:15, Bob Ippolito wrote:
>>>> On Oct 19, 2004, at 4:51, Eric Nieuwland wrote:
>>>>> On 18-okt-04, at 11:21, Jack Jansen wrote:
>>>>>> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>>>>>>> How will the caching system handle updates to an application of 
>>>>>>> which the terminology is cached?
>>>>>>
>>>>>> That's one of the problems we're trying to sort out. Has wants to 
>>>>>> do it automatically whereas Bob and myself seem to tend towards a 
>>>>>> more manual solution, whereby the script writer somehow 
>>>>>> explicitly triggers it.
>>>>>
>>>>> Why not add a parameter to the indicate whether or not to check 
>>>>> for changes if the terminology is cached?
>>>>> You'll have to rely on version numbers in the app to decide if the 
>>>>> app was updated, but that should be OK.
>>>>
>>>> The reason cached terminologies are useful is because *asking* for 
>>>> terminologies is slow.  If you have to ask if it's updated, you 
>>>> might as well not have cached it in the first place.  If you don't 
>>>> ask if it's updated, then it's impossible to know for sure whether 
>>>> or not your cached terminology is stale.
>>>
>>> OK. But to check the version you can access the app's Info.plist. Is 
>>> that slow as well?
>>
>> Info.plist isn't guaranteed to change when the application does.  
>> Heck, it's not even totally guaranteed to exist (remote apple events, 
>> CFM apps, OS9 apps running in Classic).
>
> Would adding a parameter with values 'always', 'if there is none', 
> 'never' to control when the terminology is to be generated do the 
> trick?

How is that better than having the option to explicitly "freeze" a 
terminology into an importable python module?

Remember - the ONLY reason to cache terminologies is to save ~0.5 
seconds per run.  If you have a script that you need to run very often 
or redistribute, you can spend a minute to freeze the terminology.

-bob

From bob at redivi.com  Tue Oct 19 21:29:56 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 21:30:32 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
Message-ID: <427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com>

On Oct 19, 2004, at 15:15, Eric Nieuwland wrote:

> On 19-okt-04, at 17:51, Bob Ippolito wrote:
>> On Oct 19, 2004, at 11:44, Eric Nieuwland wrote:
>>> Would adding a parameter with values 'always', 'if there is none', 
>>> 'never' to control when the terminology is to be generated do the 
>>> trick?
>>
>> How is that better than having the option to explicitly "freeze" a 
>> terminology into an importable python module?
>>
>> Remember - the ONLY reason to cache terminologies is to save ~0.5 
>> seconds per run.  If you have a script that you need to run very 
>> often or redistribute, you can spend a minute to freeze the 
>> terminology.
>
> Well, why not optionally freeze the terminology in advance into a 
> specific area like .../site-packages/terminology. Let's call it a 
> cache to keep has happy.
> Then, from your program you could use (extending has' example):
>
> 	itunes = app('eppc://20.20.20.20/iTunes', 
> usingtermsfrom='iTunes.app', terminology=X)
>
> where X is:
> 	frozen		to get Bob's preferred system
> 	cached		to get has' idea
> 	application	to always obtain the terminology from the current 
> application (possibly putting in the cache)

But *why* put it there?  Why not with your application?  You need admin 
access to touch site-packages, and considering that multiple 
terminology-using applications and possibly multiple users would use 
the same cache area makes it rather problematic.

I'm not at all convinced that it's worth doing.  For the cases where 
you need the efficiency, you freeze it to a particular python module 
named whatever you want, wherever you need it to be.  This has the 
added bonus of being discoverable by dependency walking (mostly 
packaging) utilities since you will be importing it explicitly.  
Otherwise, you look it up dynamically and take the speed hit.  Why make 
it more complicated?

The only situation I can come up with where you would really notice is 
if you had some throwaway python script that you were spawning a whole 
bunch of times to do something (a la shell script).  The solution is to 
not do that.  Make the script long-running and take a bunch of 
parameters on argv or from stdin, or make it a module and use it 
directly from the calling script (assuming its Python as well).  Either 
way will be a whole heck of a lot faster because (a) you've make the 
terminology lookup constant time (b) you've made the python interpreter 
startup/shutdown constant time.

-bob

From brad.allen at omsdal.com  Tue Oct 19 22:36:35 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Tue Oct 19 22:37:36 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <0B7CC777-215F-11D9-9236-000A95BA5446@redivi.com>
Message-ID: <OF44F81C59.FE7D68C3-ON86256F32.006E1520-86256F32.007136E9@omsdal.com>

Bob Ippolito <bob@redivi.com> wrote on 10/18/2004 06:40:08 PM:

> No it does not require Python 2.4.  If you look at PEP 291 it says that
> subprocess shall remain backwards compatible with Python 2.2.

That sounds promising, but I haven't had much luck finding where to
download it or instructions on how to install it. Is it a simple pure
Python module with no outside dependencies? Can I simply distribute this
module in a directory alongside my other Python modules & packages?

Thanks!

From bob at redivi.com  Tue Oct 19 22:40:47 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 19 22:41:22 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <OF44F81C59.FE7D68C3-ON86256F32.006E1520-86256F32.007136E9@omsdal.com>
References: <OF44F81C59.FE7D68C3-ON86256F32.006E1520-86256F32.007136E9@omsdal.com>
Message-ID: <2807195C-220F-11D9-B5C9-000A95BA5446@redivi.com>


On Oct 19, 2004, at 16:36, brad.allen@omsdal.com wrote:

> Bob Ippolito <bob@redivi.com> wrote on 10/18/2004 06:40:08 PM:
>
>> No it does not require Python 2.4.  If you look at PEP 291 it says 
>> that
>> subprocess shall remain backwards compatible with Python 2.2.
>
> That sounds promising, but I haven't had much luck finding where to
> download it or instructions on how to install it. Is it a simple pure
> Python module with no outside dependencies? Can I simply distribute 
> this
> module in a directory alongside my other Python modules & packages?

The URL I provided tells you exactly where to get it from: a CVS 
repository.  It has a setup.py, so you install it like you install 
anything else.. though you could just copy subprocess.py wherever it 
needs to go.  Alternatively you can get it from Python 2.4 CVS.

Yes it is a simple Python module with no dependencies (on win32 it 
requires a _subprocess extension).

Yes you can simply distribute the module in a directory alongside your 
other modules/packages.

-bob

From kevin at macosx.com  Wed Oct 20 08:02:20 2004
From: kevin at macosx.com (kevin parks)
Date: Wed Oct 20 08:02:34 2004
Subject: [Pythonmac-SIG] (novice query) plots, graphs,
	charts on Mac w/ python
In-Reply-To: <20041017100005.E14F71E400E@bag.python.org>
References: <20041017100005.E14F71E400E@bag.python.org>
Message-ID: <9A962846-225D-11D9-8DF6-003065555ABC@macosx.com>

Hi,

What are the standard modules that work on mac for making charts and 
plotting data, etc. I need something that is easy to use, versitle, and 
WELL DOCUMENTED with examples, tutorials and documentation.

Anyone know a package that fits the bill? Is pil the way to go?

Sorry, i am kind of new to this type of computing and i know mac has 
it's own graphics issues..


-kevin


--^----------------------------------------


Virginia Center for Computer Music
University of Virginia

From eric.nieuwland at xs4all.nl  Wed Oct 20 08:05:21 2004
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Wed Oct 20 08:05:24 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com>
Message-ID: <068A4DD8-225E-11D9-B065-000393894CEA@xs4all.nl>

On 19-okt-04, at 21:29, Bob Ippolito wrote:
> On Oct 19, 2004, at 15:15, Eric Nieuwland wrote:
>> Well, why not optionally freeze the terminology in advance into a 
>> specific area like .../site-packages/terminology. Let's call it a 
>> cache to keep has happy.
>> Then, from your program you could use (extending has' example):
>>
>> 	itunes = app('eppc://20.20.20.20/iTunes', 
>> usingtermsfrom='iTunes.app', terminology=X)
>>
>> where X is:
>> 	frozen		to get Bob's preferred system
>> 	cached		to get has' idea
>> 	application	to always obtain the terminology from the current 
>> application (possibly putting in the cache)
>
> But *why* put it there?  Why not with your application?  You need 
> admin access to touch site-packages, and considering that multiple 
> terminology-using applications and possibly multiple users would use 
> the same cache area makes it rather problematic.
>
> I'm not at all convinced that it's worth doing.  For the cases where 
> you need the efficiency, you freeze it to a particular python module 
> named whatever you want, wherever you need it to be.  This has the 
> added bonus of being discoverable by dependency walking (mostly 
> packaging) utilities since you will be importing it explicitly.  
> Otherwise, you look it up dynamically and take the speed hit.  Why 
> make it more complicated?
>
> The only situation I can come up with where you would really notice is 
> if you had some throwaway python script that you were spawning a whole 
> bunch of times to do something (a la shell script).  The solution is 
> to not do that.  Make the script long-running and take a bunch of 
> parameters on argv or from stdin, or make it a module and use it 
> directly from the calling script (assuming its Python as well).  
> Either way will be a whole heck of a lot faster because (a) you've 
> make the terminology lookup constant time (b) you've made the python 
> interpreter startup/shutdown constant time.

I really don't know what "the best" solution would be. In such cases I 
try not to force myself into any direction and come up with a solution 
that supports most variants.

--eric

From mjb at uma.pt  Wed Oct 20 10:35:35 2004
From: mjb at uma.pt (Michael J. Barber)
Date: Wed Oct 20 10:35:45 2004
Subject: [Pythonmac-SIG] (novice query) plots, graphs,
	charts on Mac w/ python
In-Reply-To: <9A962846-225D-11D9-8DF6-003065555ABC@macosx.com>
References: <20041017100005.E14F71E400E@bag.python.org>
	<9A962846-225D-11D9-8DF6-003065555ABC@macosx.com>
Message-ID: <034B039F-2273-11D9-8ABE-0050E4794D0F@uma.pt>

Kevin,

I use gnuplot. There is a downloadable Gnuplot.py interface that is 
adequate. For gnuplot itselt, you can use a variety of plotting 
backends; the AquaTerm backend is nice for interactive work, and there 
are several good options for hardcopies. The documentation is solid, 
and there is a large selection of examples. I don't know about a 
tutorial, although there must be some -- I found it simplest to just 
adapt the examples to my needs.

Hope that helps,
Michael

On Oct 20, 2004, at 7:02 AM, kevin parks wrote:

> Hi,
>
> What are the standard modules that work on mac for making charts and 
> plotting data, etc. I need something that is easy to use, versitle, 
> and WELL DOCUMENTED with examples, tutorials and documentation.
>
> Anyone know a package that fits the bill? Is pil the way to go?
>
> Sorry, i am kind of new to this type of computing and i know mac has 
> it's own graphics issues..
>
>
> -kevin
>
>
> --^----------------------------------------
>
>
> Virginia Center for Computer Music
> University of Virginia
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From kevin at macosx.com  Wed Oct 20 12:47:00 2004
From: kevin at macosx.com (kevin parks)
Date: Wed Oct 20 12:47:10 2004
Subject: [Pythonmac-SIG] gnuplot.py on osx
In-Reply-To: <20041020100102.A310D1E4007@bag.python.org>
References: <20041020100102.A310D1E4007@bag.python.org>
Message-ID: <5EFE8698-2285-11D9-9C32-003065555ABC@macosx.com>

hi... I downloaded and installed the gnuplot, gnuplot.py and aquaterm  
stuff from sourceforge and have teh Panther addons, etc. I get the  
following after the python ./setup.py install dance when i try to run  
the gnuplot-py-1.7 demo.py

I wonder, where did i screw up? Is it my Python that is not cool, or  
have i messed up on the gnuplot side? I am not sure how to interpret  
what i have printed there below

cheers

kevin




snowcat:~/gnuplot-py-1.7 kevin$ python ./demo.py
sh: line 1: gnuplot: command not found
Traceback (most recent call last):
   File "./demo.py", line 113, in ?
     demo()
   File "./demo.py", line 31, in demo
     g = Gnuplot.Gnuplot(debug=1)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/Gnuplot/_Gnuplot.py", line 188, in __init__
     self('set terminal %s' % (gp.GnuplotOpts.default_term,))
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/Gnuplot/_Gnuplot.py", line 199, in __call__
     self.gnuplot(s)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/Gnuplot/gp_macosx.py", line 136, in __call__
     self.flush()
IOError: [Errno 32] Broken pipe

From rkern at ucsd.edu  Wed Oct 20 13:28:23 2004
From: rkern at ucsd.edu (Robert Kern)
Date: Wed Oct 20 13:28:30 2004
Subject: [Pythonmac-SIG] (novice query) plots, graphs,	charts on Mac w/
	python
In-Reply-To: <9A962846-225D-11D9-8DF6-003065555ABC@macosx.com>
References: <20041017100005.E14F71E400E@bag.python.org>
	<9A962846-225D-11D9-8DF6-003065555ABC@macosx.com>
Message-ID: <41764BD7.3070002@ucsd.edu>

kevin parks wrote:
> Hi,
> 
> What are the standard modules that work on mac for making charts and 
> plotting data, etc. I need something that is easy to use, versitle, and 
> WELL DOCUMENTED with examples, tutorials and documentation.
> 
> Anyone know a package that fits the bill? Is pil the way to go?
> 
> Sorry, i am kind of new to this type of computing and i know mac has 
> it's own graphics issues..

I recommend matplotlib.

http://matplotlib.sourceforge.net/

Raw PIL is almost certainly not the way to go.

-- 
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter
From fonnesbeck at gmail.com  Wed Oct 20 14:31:00 2004
From: fonnesbeck at gmail.com (Chris Fonnesbeck)
Date: Wed Oct 20 14:31:02 2004
Subject: [Pythonmac-SIG] (novice query) plots, graphs, charts on Mac w/ python
In-Reply-To: <20041020100102.A310D1E4007@bag.python.org>
References: <20041020100102.A310D1E4007@bag.python.org>
Message-ID: <723eb69304102005312da9ec05@mail.gmail.com>

> 
> What are the standard modules that work on mac for making charts and
> plotting data, etc. I need something that is easy to use, versitle, and
> WELL DOCUMENTED with examples, tutorials and documentation.
> 
> Anyone know a package that fits the bill? Is pil the way to go?
> 
> Sorry, i am kind of new to this type of computing and i know mac has
> it's own graphics issues..

I highly recommend Matpotlib (http://matplotlib.sourceforge.net/) they
definitely look the nicest, particularly if you are doing complex
graphics, or even histograms (the gnuplot histograms are very ugly in
comparison). Lots of examples on the site.
From marcus.h.mendenhall at vanderbilt.edu  Wed Oct 20 14:58:19 2004
From: marcus.h.mendenhall at vanderbilt.edu (Marcus Mendenhall)
Date: Wed Oct 20 14:58:36 2004
Subject: [Pythonmac-SIG] charts & graphs
In-Reply-To: <20041020100102.7F4091E4010@bag.python.org>
References: <20041020100102.7F4091E4010@bag.python.org>
Message-ID: <B716ECCA-2297-11D9-A9CF-000A95E89E1C@vanderbilt.edu>


> Hi,
>
> What are the standard modules that work on mac for making charts and 
> plotting data, etc. I need something that is easy to use, versitle, 
> and WELL DOCUMENTED with examples, tutorials and documentation.
>
> Anyone know a package that fits the bill? Is pil the way to go?
>
> Sorry, i am kind of new to this type of computing and i know mac has 
> it's own graphics issues..
>
>
> -kevin
I use PyX ( http://pyx.sourceforge.net ) and graceplot.  PyX is  
generates extremely pretty graphs, with modest effort.  Its strong 
point is the underlying postscript generating architecture, and its use 
of LaTeX to process text.  You must have LaTeX installed to use it.  
This gives it the ability to generate very well-laid-out labels and 
special captioning. It has extremely strong capabilities in the 
generation of custom axes.  For an example of dynamically-generated PyX 
graphs, see
http://arago.fel.vanderbilt.edu/~zlabpro/Environmental.html
and note the date/time axis on the graphs, which is a custom labeling 
system based on the extensibility of PyX axes. Note that if you push 
the 'update graphs' link, it takes a long time.  This is not PyX taking 
the tijme.  The data are being resampled via a fairly slow algorithm 
which detects  local extrema before plotting the sparsified set.

I also use graceplot, which is a front end to xmgrace, an X11-based 
interactive graphics package along similar lines to gnuplot.  I find 
xmgrace a little easier to handle than gnuplot.  It is quite useful if 
you want to very quickly pop up a graph, and then hand-adjust the 
layout when you get one which is ready for publication.  It has 
extensive internal data manipulation capabilities, so you can also do 
things like fitting and smoothing of data one the graph is displayed.  
It is extremely easy (easier than PyX, e.g.) to get a graph out of 
graceplot.  You need to have fink and xmgrace installed, and have X11 
running.

Marcus Mendenhall

From jdhunter at ace.bsd.uchicago.edu  Wed Oct 20 15:00:02 2004
From: jdhunter at ace.bsd.uchicago.edu (John Hunter)
Date: Wed Oct 20 15:48:13 2004
Subject: [Pythonmac-SIG] (novice query) plots, graphs,	charts on Mac w/
	python
In-Reply-To: <41764BD7.3070002@ucsd.edu> (Robert Kern's message of "Wed, 20
	Oct 2004 04:28:23 -0700")
References: <20041017100005.E14F71E400E@bag.python.org>
	<9A962846-225D-11D9-8DF6-003065555ABC@macosx.com>
	<41764BD7.3070002@ucsd.edu>
Message-ID: <m2brexsfxp.fsf@nitace.bsd.uchicago.edu>

>>>>> "Robert" == Robert Kern <rkern@ucsd.edu> writes:

    Robert> kevin parks wrote:
    >> Hi, What are the standard modules that work on mac for making
    >> charts and plotting data, etc. I need something that is easy to
    >> use, versitle, and WELL DOCUMENTED with examples, tutorials and
    >> documentation.  Anyone know a package that fits the bill? Is
    >> pil the way to go?  Sorry, i am kind of new to this type of
    >> computing and i know mac has it's own graphics issues..

    Robert> I recommend matplotlib.

    Robert> http://matplotlib.sourceforge.net/

    Robert> Raw PIL is almost certainly not the way to go.

I'll second that recommendation :-)

matplotlib supports many graphical user interfaces, unfortunately none
of them are native to OS X (this will change, I just don't know when).
SO you want to be a little careful when making the choice of which GUI
you will use.  For OS X, I recommend using either TkAgg which uses
Tkinter or GTKAgg which uses pygtk, because there are some problems in
the way the buttons are rendered on OS X with the wxpython backends.
There is also an FLTK backend, but as far as I know this has never
been tested on OS X.  Personally, I use GTKAgg on my powerbook, having
installed GTK and pygtk from src -- this approach is not for the faint
of heart.  I think the path of least resistance is TkAgg, especially
since you can get Tkinter from the python application manager
doohitchie.

Also, take a look at recent versions of ipython with --pylab option,
which is a nice platform for interactive work with matplotlib
plotting.

On the subject of a Cocoa/Aqua (pardon my naivete but what is the
difference?)  backend, this would be quite easy to implement using the
*Agg model of GTKAgg, WXAgg, TkAgg and FLTKAgg.  Basically, you just
need to grab a GUI window, plug an agg image into it, and wrap some
basic the event handling; the rest you get for free.  The Agg backend
provides both string and buffer access to it's image data, so you can
probably do it without any extension code.  I think a person who knew
the Cocoa GUI well could do it in a day, at most two.  If anyone
decides to take this on, please contact me because I have some advice
about things you can leave out (Eg, I don't see any reason to support
the classic toolbar, since the new one is so much better) that will
make this easier.  One could do a full blown backend with native
drawing, but there is not much incentive to since AquaAgg would be so
much easier, look just as good, and is much less of a burden to
maintain.

JDH

From jim at ibang.com  Wed Oct 20 16:08:06 2004
From: jim at ibang.com (Jim Allman)
Date: Wed Oct 20 16:08:17 2004
Subject: [Pythonmac-SIG] gnuplot.py on osx
In-Reply-To: <5EFE8698-2285-11D9-9C32-003065555ABC@macosx.com>
References: <20041020100102.A310D1E4007@bag.python.org>
	<5EFE8698-2285-11D9-9C32-003065555ABC@macosx.com>
Message-ID: <76E53A01-22A1-11D9-A842-000A95BC64B8@ibang.com>

On Oct 20, 2004, at 6:47 AM, kevin parks wrote:
> sh: line 1: gnuplot: command not found

This looks like an error from the shell. Is it possible that gnuplot is 
installed, but it's not in your $PATH?

   =jimA=

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . . . .
Jim Allman
Interrobang Digital Media
http://www.ibang.com/
(919) 649-5760

From qdecavel at wanadoo.fr  Wed Oct 20 17:40:11 2004
From: qdecavel at wanadoo.fr (Quentin DECAVEL)
Date: Wed Oct 20 17:40:13 2004
Subject: [Pythonmac-SIG] Problem
Message-ID: <28915495.1098286811805.JavaMail.www@wwinf0201>

Hi,

I have just discovered py2app, which seems to be quite an improvement of bundlebuilder. I have 
downloaded the package,but I cannot find any installation instruction. Should I suppose it is a 
module and should be put as pygame and some others in /Library/Python/2.3/ ? Is there a 
clearer way to install, for example with PackageManager ?

Thanks in advance

Quentin
From njriley at uiuc.edu  Wed Oct 20 18:23:43 2004
From: njriley at uiuc.edu (Nicholas Riley)
Date: Wed Oct 20 18:23:46 2004
Subject: [Pythonmac-SIG] Problem
In-Reply-To: <28915495.1098286811805.JavaMail.www@wwinf0201>
References: <28915495.1098286811805.JavaMail.www@wwinf0201>
Message-ID: <20041020162343.GA23667@uiuc.edu>

On Wed, Oct 20, 2004 at 05:40:11PM +0200, Quentin DECAVEL wrote:
> Hi,
> 
> I have just discovered py2app, which seems to be quite an
> improvement of bundlebuilder. I have downloaded the package,but I
> cannot find any installation instruction. Should I suppose it is a
> module and should be put as pygame and some others in
> /Library/Python/2.3/ ? Is there a clearer way to install, for
> example with PackageManager ?

python setup.py install, the usual distutils setup should work.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
From hengist.podd at virgin.net  Wed Oct 20 21:33:23 2004
From: hengist.podd at virgin.net (has)
Date: Wed Oct 20 21:35:15 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <068A4DD8-225E-11D9-B065-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com>
	<068A4DD8-225E-11D9-B065-000393894CEA@xs4all.nl>
Message-ID: <a05200f0abd9c6540b607@[81.101.66.68]>

Hi all,

Spent a bit of time experimenting with the AppscriptTerminologyServer 
idea. This uses a bundlebuilder-based FBA that can be left 
permanently running to manage application terminology on behalf of 
appscript. I can post a demo in a day or so if anyone wants to try 
it, but meantime let's see what folks make of the general concept.

Advantages:
- 99.5% automatic
- fast (terminology is parsed once, then internally cached [keys = 
application paths/urls] for efficient reuse)
- works with both local and remote apps (terminology servers can 
share terminology data across the network)
- language-agnostic (a Tcl/Perl/Ruby port of appscript could share 
the existing terminology server)

Disadvantages:
- ATS must be running on every machine whose applications are being 
scripted (installation issues? permissions issues? add to startup 
items?)
- if applications are updated, ATS cache must be manually cleared 
(either by restarting ATS or sending it a 'reset' event)
- currently OS X-only, so no remote scripting of OS9 machines unless 
someone else wants to port it (not too worried as this is a shrinking 
market and aem can always be used instead)
- anything else? (in particular, any show-stoppers?)


Thoughts, criticisms, etc?

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From bob at redivi.com  Wed Oct 20 21:44:25 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct 20 21:45:01 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f0abd9c6540b607@[81.101.66.68]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com>
	<068A4DD8-225E-11D9-B065-000393894CEA@xs4all.nl>
	<a05200f0abd9c6540b607@[81.101.66.68]>
Message-ID: <72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>


On Oct 20, 2004, at 15:33, has wrote:

> Hi all,
>
> Spent a bit of time experimenting with the AppscriptTerminologyServer 
> idea. This uses a bundlebuilder-based FBA that can be left permanently 
> running to manage application terminology on behalf of appscript. I 
> can post a demo in a day or so if anyone wants to try it, but meantime 
> let's see what folks make of the general concept.
>
> Advantages:
> - 99.5% automatic
> - fast (terminology is parsed once, then internally cached [keys = 
> application paths/urls] for efficient reuse)
> - works with both local and remote apps (terminology servers can share 
> terminology data across the network)
> - language-agnostic (a Tcl/Perl/Ruby port of appscript could share the 
> existing terminology server)
>
> Disadvantages:
> - ATS must be running on every machine whose applications are being 
> scripted (installation issues? permissions issues? add to startup 
> items?)
> - if applications are updated, ATS cache must be manually cleared 
> (either by restarting ATS or sending it a 'reset' event)
> - currently OS X-only, so no remote scripting of OS9 machines unless 
> someone else wants to port it (not too worried as this is a shrinking 
> market and aem can always be used instead)
> - anything else? (in particular, any show-stoppers?)

appscript can install the FBA into its package, start it on on demand 
and just leave it running.  Perhaps it should have a time to live of a 
few hours, and the application terminologies probably should expire as 
well.

-bob

From hengist.podd at virgin.net  Thu Oct 21 00:46:18 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 21 00:46:31 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com> <068A4DD8-225E-11
	<72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
Message-ID: <a05200f0bbd9c8fa2a4e0@[81.101.66.68]>

Bob wrote:

>appscript can install the FBA into its package,

Fine with me. I'm not sure how to package it for distribution though 
- AFAIK distutils isn't resource fork/creator code-friendly. Advice?


>start it on on demand and just leave it running.

This would work fine for scripting local apps; not sure about remote 
apps though (remote application scripting depends on the remote 
applications already being running). Is there a way to remotely start 
ATS running on another machine? If not, manually/automatically 
putting it in startup items and never quitting it is probably the 
best solution.


>Perhaps it should have a time to live of a few hours, and the 
>application terminologies probably should expire as well.

Notes: ATS's terminology cache is in-memory, so will always expire 
when ATS is quit.

Question: what would be the benefits of limiting ATS's running time, 
as opposed to just letting it run until system shutdown?

Own thoughts: the longer ATS stays alive, the more benefit is gained 
from caching (good) though there's also more risk of the cache 
growing stale (bad). Regarding automatic expiry of cache: ATS could 
easily flush individual entries in the cache after [e.g.] 48 hours 
even if the application itself stays permanently running.

Then again, periodically flushing the cache is probably a bit 
hit-or-miss affair as far as keeping it in-sync with an application; 
sure as guns users will update their apps precisely 30 minutes after 
ATS last reset its cache and 25 minutes after they last scripted 
those apps.:) Possible memory leaks aside, ATS also shouldn't impact 
much on system memory since each cache entry is just a few KB. What 
other advantages would there be to auto expiry of cache?


Another idea: would checking an application's creation/modification 
date be a viable way to avoid the cache going bad when a newer 
version of the app is installed in exactly the same location?

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From garbanzito at mac.com  Thu Oct 21 00:37:44 2004
From: garbanzito at mac.com (steve harley)
Date: Thu Oct 21 00:47:50 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
Message-ID: <A8971AAE-22E8-11D9-BC56-000393C5ED50@mac.com>

on 18 Oct 2004, at 3:21 AM, Jack Jansen wrote:
>
> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>
>> A small question to all you gurus on this topic.
>>
>> How will the caching system handle updates to an application of which 
>> the terminology is cached?
>
> That's one of the problems we're trying to sort out. Has wants to do 
> it automatically whereas Bob and myself seem to tend towards a more 
> manual solution, whereby the script writer somehow explicitly triggers 
> it.

one small consideration to add: some apps update their terminology 
without a version change.. the means i have in mind is that some 
XTensions to QuarkXPress (4.x, at least) would dynamically extend the 
dictionary when the app launched.. the new terminology could only be 
obtained when the app was running, not from parsing the AETE in the 
resource fork.. i don't  how or whether this situation has changed with 
Mac OS X versions of XPress or other apps.. Frontier did a parse of the 
static AETE, and so i had to hand add entries to the glue table, but if 
the AETE API that appscript uses ensures that dynamic entries are 
returned to queries, then i guess this isn't an issue

From bob at redivi.com  Thu Oct 21 00:58:36 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct 21 00:59:12 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com> <068A4DD8-225E-11
	<72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
	<a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
Message-ID: <93548AC7-22EB-11D9-B95B-000A95BA5446@redivi.com>


On Oct 20, 2004, at 18:46, has wrote:

> Bob wrote:
>
>> appscript can install the FBA into its package,
>
> Fine with me. I'm not sure how to package it for distribution though - 
> AFAIK distutils isn't resource fork/creator code-friendly. Advice?

It's not.  Don't use resource forks.  What do you need them for?  
Bundlebuilder doesn't preserve resource forks either.  You should be 
using py2app instead of bundlebuilder, though it doesn't preserve 
resource forks either.

>> start it on on demand and just leave it running.
>
> This would work fine for scripting local apps; not sure about remote 
> apps though (remote application scripting depends on the remote 
> applications already being running). Is there a way to remotely start 
> ATS running on another machine? If not, manually/automatically putting 
> it in startup items and never quitting it is probably the best 
> solution.

This should be done explicitly.. it's a potential security hole, DOS 
attack, etc.  Remote scripting isn't *that* common anyway.

>> Perhaps it should have a time to live of a few hours, and the 
>> application terminologies probably should expire as well.
>
> Notes: ATS's terminology cache is in-memory, so will always expire 
> when ATS is quit.
>
> Question: what would be the benefits of limiting ATS's running time, 
> as opposed to just letting it run until system shutdown?
>
> Own thoughts: the longer ATS stays alive, the more benefit is gained 
> from caching (good) though there's also more risk of the cache growing 
> stale (bad). Regarding automatic expiry of cache: ATS could easily 
> flush individual entries in the cache after [e.g.] 48 hours even if 
> the application itself stays permanently running.
>
> Then again, periodically flushing the cache is probably a bit 
> hit-or-miss affair as far as keeping it in-sync with an application; 
> sure as guns users will update their apps precisely 30 minutes after 
> ATS last reset its cache and 25 minutes after they last scripted those 
> apps.:) Possible memory leaks aside, ATS also shouldn't impact much on 
> system memory since each cache entry is just a few KB. What other 
> advantages would there be to auto expiry of cache?

Well if you're not using it very often, there isn't really any gain to 
saving 0.5 sec once a day.  I often leave my machine on for weeks at a 
time, it just seems a lot safer not to leave it running forever.

> Another idea: would checking an application's creation/modification 
> date be a viable way to avoid the cache going bad when a newer version 
> of the app is installed in exactly the same location?

For bundled applications you would have to walk the whole application 
tree to see if anything has changed.. It's possible to update resources 
without touching the outer folder.

-bob

From bob at redivi.com  Thu Oct 21 01:05:10 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct 21 01:05:45 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <A8971AAE-22E8-11D9-BC56-000393C5ED50@mac.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<A8971AAE-22E8-11D9-BC56-000393C5ED50@mac.com>
Message-ID: <7DE22FD1-22EC-11D9-B95B-000A95BA5446@redivi.com>


On Oct 20, 2004, at 18:37, steve harley wrote:

> on 18 Oct 2004, at 3:21 AM, Jack Jansen wrote:
>>
>> On 18 Oct 2004, at 00:47, Eric Nieuwland wrote:
>>
>>> A small question to all you gurus on this topic.
>>>
>>> How will the caching system handle updates to an application of 
>>> which the terminology is cached?
>>
>> That's one of the problems we're trying to sort out. Has wants to do 
>> it automatically whereas Bob and myself seem to tend towards a more 
>> manual solution, whereby the script writer somehow explicitly 
>> triggers it.
>
> one small consideration to add: some apps update their terminology 
> without a version change.. the means i have in mind is that some 
> XTensions to QuarkXPress (4.x, at least) would dynamically extend the 
> dictionary when the app launched.. the new terminology could only be 
> obtained when the app was running, not from parsing the AETE in the 
> resource fork.. i don't  how or whether this situation has changed 
> with Mac OS X versions of XPress or other apps.. Frontier did a parse 
> of the static AETE, and so i had to hand add entries to the glue 
> table, but if the AETE API that appscript uses ensures that dynamic 
> entries are returned to queries, then i guess this isn't an issue

appscript shouldn't be reading anything directly from resources, so 
that's not an issue.  However, if appscript gets ahold of the 
QuarkXPress aete before it's loaded all of its extensions (which might 
happen if appscript does the launching, I guess), then you have an 
issue.

-bob

From cohar at conncoll.edu  Thu Oct 21 02:40:12 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Thu Oct 21 02:40:16 2004
Subject: [Pythonmac-SIG] Problem
In-Reply-To: <28915495.1098286811805.JavaMail.www@wwinf0201>
References: <28915495.1098286811805.JavaMail.www@wwinf0201>
Message-ID: <C49CB642-22F9-11D9-AE78-000393A37396@conncoll.edu>

I had the same problem. Bob Ippolito's response:

% cd py2app-0.1.1		[now 0.1.4]
% sudo python setup.py install

That worked for me.

Charles Hartman


On Oct 20, 2004, at 11:40 AM, Quentin DECAVEL wrote:

> Hi,
>
> I have just discovered py2app, which seems to be quite an improvement 
> of bundlebuilder. I have
> downloaded the package,but I cannot find any installation instruction. 
> Should I suppose it is a
> module and should be put as pygame and some others in 
> /Library/Python/2.3/ ? Is there a
> clearer way to install, for example with PackageManager ?
>
> Thanks in advance
>
> Quentin
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From kevin at macosx.com  Thu Oct 21 03:28:34 2004
From: kevin at macosx.com (kevin parks)
Date: Thu Oct 21 03:28:44 2004
Subject: [Pythonmac-SIG] Re: gnuplot.py on osx
In-Reply-To: <76E53A01-22A1-11D9-A842-000A95BC64B8@ibang.com>
References: <20041020100102.A310D1E4007@bag.python.org>
	<5EFE8698-2285-11D9-9C32-003065555ABC@macosx.com>
	<76E53A01-22A1-11D9-A842-000A95BC64B8@ibang.com>
Message-ID: <86622820-2300-11D9-AE80-003065555ABC@macosx.com>


On Oct 20, 2004, at 10:08 AM, Jim Allman wrote:

> On Oct 20, 2004, at 6:47 AM, kevin parks wrote:
>> sh: line 1: gnuplot: command not found
>
> This looks like an error from the shell. Is it possible that gnuplot 
> is installed, but it's not in your $PATH?
>
>


Jim,

You were right on the money! The $PATH in /private/etc/profile does not 
include /usr/local/bin and i had neglected to add that to ye ol' path, 
or rather i had, but it only works if you actually spell it right 
(oops!)

Thanks! I am gnuplotting away now! (well kind of, i still have to 
figure out how to plot my actual data)


cheers,

kp

From bob at redivi.com  Thu Oct 21 06:35:17 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct 21 06:35:56 2004
Subject: [Pythonmac-SIG] ANN: py2app / bdist_mpkg 0.1.5 preview
Message-ID: <9BAA7798-231A-11D9-A940-000A95BA5446@redivi.com>

I've put together a little preview of py2app 0.1.5, which has MAJOR 
feature enhancements over 0.1.4.
	http://undefined.org/python/py2app-0.1.5.mpkg.zip (installer for Mac 
OS X 10.3)

	http://svn.red-bean.com/bob/py2app/trunk (source repository)
	http://svn.red-bean.com/pyobjc/branches/py2app-branch/ (PyObjC 
repository refactored to use py2app and bdist_mpkg)

py2app:
	non-ascii application names works now (e.g. J?ger)
	support for non-framework builds of Python (e.g. darwinports)
	slightly more documentation (INSTALLING.txt, README.txt)
	PyPI information
	enhanced setup.py that can use bdist_mpkg
	builds and installs the py2applet tool as part of its bdist_mpkg 
script (to /Developer/Applications/Python Tools/py2app/)
	installs the examples to /Developer/Python/py2app/Examples

bdist_mpkg:
	It's new!  bdist_mpkg is a distutils command that builds a metapackage 
for Installer.app (or /usr/sbin/installer).  It's part of the py2app 
suite.
	It should work with ANY distutils-using Python module or application 
that uses distutils and doesn't really screw up their "install" command
	When using bdist_mpkg with a framework Python, it will default the 
scripts installation dir to /usr/local/bin instead of the middle of 
nowhere inside the Python framework
	It installs a script, /usr/local/bin/bdist_mpkg, which you can use to 
build metapackages from any setup.py.  When the metapackage is built, 
it will even open Installer for you (unless you pass it any --options, 
or just --).  This is a great alternative to using python setup.py 
install.  You can just customize and uncheck scripts, headers, etc. if 
you don't want to install them.
	You can subclass bdist_mpkg and make it do crazy things, like install 
documentation, code examples, or applications.  See py2app's 
setup-lib/py2app_mpkg.py or PyObjC's setup-lib/pyobjc_mpkg.py (on the 
py2app-branch)
	bdist_mpkg should become the "guts" of the next generation 
PackageManager instead of bdist_dumb tarballs.
	will automatically determine if root permissions are required to 
install the package (make sure you haven't mucked with your permissions 
your build machine if you plan on distributing the metapackages)


After the dust settles a bit, probably this weekend, I'll do a more 
official release... but I would like to get some feedback in the 
meantime.

-bob

From lanceboyle at cwazy.co.uk  Thu Oct 21 07:01:37 2004
From: lanceboyle at cwazy.co.uk (Lance Boyle)
Date: Thu Oct 21 07:01:34 2004
Subject: [Pythonmac-SIG] charts & graphs
In-Reply-To: <B716ECCA-2297-11D9-A9CF-000A95E89E1C@vanderbilt.edu>
References: <20041020100102.7F4091E4010@bag.python.org>
	<B716ECCA-2297-11D9-A9CF-000A95E89E1C@vanderbilt.edu>
Message-ID: <49A178E2-231E-11D9-B237-003065F93FF0@cwazy.co.uk>


On Oct 20, 2004, at 5:58 AM, Marcus Mendenhall wrote:

> Hi,
>
> What are the standard modules that work on mac for making charts and 
> plotting data, etc. I need something that is easy to use, versitle, 
> and WELL DOCUMENTED with examples, tutorials and documentation.
>
> Anyone know a package that fits the bill? Is pil the way to go?
>
> Sorry, i am kind of new to this type of computing and i know mac has 
> it's own graphics issues..
>
>
> -kevin
>
Someone should probably put together an annotated list of 
Python-appropriate plotting options, since this gets asked a lot (I 
suppose).

Consider R at www.r-project.org, and don't be put off if statistics 
isn't your main thing. R is a general purpose environment and might 
even ease your need to use Python for technical stuff 8^).

And there's the on-going Chaco project.

Gnuplot with AquaTerm is pretty nice and simple. (Someone else 
mentioned it but I'll mention it again.) Here's a program (not mine) 
that pretty much makes the entire gnuplot language available in Python.



import os
class gnuplot:
	def __init__(self):
		print "opening new gnuplot session..."
		self.session = os.popen("gnuplot","w")
	def __del__(self):
		print "closing gnuplot session..."
		self.session.close()
	def send(self, cmd):
		self.session.write(cmd+'\n')
		self.session.flush()
if __name__=="__main__":
	g1 = gnuplot()
	g1.send("set terminal aqua 0")
	
	# Your code here
	g1.send("plot sin(x)")
	
	del g1


Jerry

From eric.nieuwland at xs4all.nl  Thu Oct 21 10:37:27 2004
From: eric.nieuwland at xs4all.nl (Eric Nieuwland)
Date: Thu Oct 21 10:37:31 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com> <068A4DD!
	8-225E-11 <72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
	<a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
Message-ID: <7056C57A-233C-11D9-B065-000393894CEA@xs4all.nl>

has wrote:
> Another idea: would checking an application's creation/modification 
> date be a viable way to avoid the cache going bad when a newer version 
> of the app is installed in exactly the same location?

How are you going to check "an application's creation/modification 
date"? Don't use the file/directory attributes for this! 'ctime' is 
unreliable for this to say the least. And 'mtime' is often tricky on 
directories.

--eric

From hengist.podd at virgin.net  Thu Oct 21 11:11:29 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 21 11:12:22 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <93548AC7-22EB-11D9-B95B-000A95BA5446@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com> <068A4DD8-225E-11
	<72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
	<a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
	<93548AC7-22EB-11D9-B95B-000A95BA5446@redivi.com>
Message-ID: <a05200f0cbd9ca7442ee5@[81.101.66.68]>

Bob wrote:

>>>appscript can install the FBA into its package,
>>
>>Fine with me. I'm not sure how to package it for distribution 
>>though - AFAIK distutils isn't resource fork/creator code-friendly. 
>>Advice?
>
>It's not.  Don't use resource forks.

I've not. I do have a creator code though - makes it easier for 
appscript to identify ATS.


>You should be using py2app instead of bundlebuilder,

My eventual aim, yes.


>>>start it on on demand and just leave it running.
>>
>>This would work fine for scripting local apps; not sure about 
>>remote apps though (remote application scripting depends on the 
>>remote applications already being running). Is there a way to 
>>remotely start ATS running on another machine? If not, 
>>manually/automatically putting it in startup items and never 
>>quitting it is probably the best solution.
>
>This should be done explicitly.. it's a potential security hole, DOS 
>attack, etc.

Remote Apple events are just one huge hole waiting to happen. :)

Not sure that ATS introduces any holes of its own - can't think of 
any anyway. I think the assumption is that if you've turned on Remote 
AEs then you _want_ the machine to be remotely scripted, so if we say 
to users "you can manually add ATS to Startup Items" then we're 
probably covered.

Was responding to the suggestion that appscript could start ATS on 
demand: it can do this easily enough for a local copy of ATS used for 
local scripting, but for remote scripting it would need to start the 
local copy of ATS which would in turn need to start the remote copy 
before asking it for the remote application's terminology. i.e. A 
'start on demand' strategy isn't entirely straightforward, and a 
permanently running ATS might be the better option on balance despite 
having potential issues of its own.


>   Remote scripting isn't *that* common anyway.

True. Still, it's important that it work as smoothly as local 
scripting... which should work at least as smoothly as AppleScript, 
since that's what everyone is going to judge us against. It's the old 
problem of having to be at least twice as good as the opposition just 
to be acknowledged.


>>>Perhaps it should have a time to live of a few hours, and the 
>>>application terminologies probably should expire as well.
>>
>>Notes: ATS's terminology cache is in-memory, so will always expire 
>>when ATS is quit.
>>
>>Question: what would be the benefits of limiting ATS's running 
>>time, as opposed to just letting it run until system shutdown?
>
>Well if you're not using it very often, there isn't really any gain 
>to saving 0.5 sec once a day.

It's a slightly bigger saving that that, since there's also the time 
taken to fetch and parse each new application's terminology (~0.1-1.0 
sec each), but yeah, the advantage mostly comes from being able to 
quickly run the same script repeatedly in a session (e.g. during 
development), and having to rebuild the cache on a daily basis 
shouldn't cause noticeable pain.


>I often leave my machine on for weeks at a time, it just seems a lot 
>safer not to leave it running forever.

Yeah, you never know for sure what embarrassing things a really 
long-running program might get up to (e.g. leaving the memory taps 
running). I'd be happy enough for ATS to automatically shut down 
after a time - as long as we could find an easy way to get a remote 
ATS application back up again when needed. I really need to do some 
more research on this and am open to suggestions.


>>Another idea: would checking an application's creation/modification 
>>date be a viable way to avoid the cache going bad when a newer 
>>version of the app is installed in exactly the same location?
>
>For bundled applications you would have to walk the whole 
>application tree to see if anything has changed.. It's possible to 
>update resources without touching the outer folder.

Good point. Also, Steve's point that an application can gain or lose 
terminology as scriptable extensions are added or removed. Definitely 
puts the kibosh on that one.

How about process id? As in: "When ATS receives a request for an 
application's terminology, if the application's process id has 
changed since the terminology was last cached, reload it." Would that 
cover the updated application scenario okay? It won't cover the 
extensible terminology situation, but even that might be partially 
addressable, e.g. by having appscript request 'fresh' terminology if 
it encounters a keyword it's not familiar with.


Many thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Thu Oct 21 11:12:05 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 21 11:12:25 2004
Subject: [Pythonmac-SIG] appscript terminology caching
Message-ID: <a05200f0dbd9cb242c285@[81.101.66.68]>

steve harley wrote:

>one small consideration to add: some apps update their terminology
>without a version change.. the means i have in mind is that some
>XTensions to QuarkXPress (4.x, at least) would dynamically extend the
>dictionary when the app launched.. the new terminology could only be
>obtained when the app was running,

Thanks for reminding me of this. (Ah <<event ascrgdte>>, I knew there 
was a reason for ye...)


>not from parsing the AETE in the resource fork..

Perish the thought... ;p


>i don't  how or whether this situation has changed with
>Mac OS X versions of XPress or other apps.. Frontier did a parse of the
>static AETE, and so i had to hand add entries to the glue table, but if
>the AETE API that appscript uses ensures that dynamic entries are
>returned to queries, then i guess this isn't an issue

appscript uses the OSAGetAppTerminology system call; no idea why 
Frontier would have done any differently, but no accounting for some 
folks I guess. Yeah, 'glues' and their attendant issues are something 
I'm trying hard to avoid, though it's not easy to do when the system 
APIs are so clearly biased against us. :p I'd love to be able to fire 
off a fresh system call and get back exactly the data I need in a few 
ms each time, but Apple engineers obviously weren't thinking of me 
when they designed their system; hence the need for efficiency 
measures like caching... which then introduce problems of their own 
that require workarounds, and so on...

With ATS there's various options: e.g. require the user to manually 
reset it after updating apps (we could provide them with a 
script/applet that would do this when run), figure out a way to make 
it keep a cache in-sync, automatically flush the old cache after X 
hours/days, don't cache at all (slooow), or prevent caching for 
certain apps (slooow for those apps). The task of the moment is 
working out what all the normal uses and corner cases are, then 
figuring out the best overall solution will be; i.e. we come up with 
lots of ideas, then try our damndest to break them.:)


Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Thu Oct 21 12:12:11 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 21 12:12:34 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <7056C57A-233C-11D9-B065-000393894CEA@xs4all.nl>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com> <068A4DD! 8-225E-11
	<72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
	<a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
	<7056C57A-233C-11D9-B065-000393894CEA@xs4all.nl>
Message-ID: <a05200f10bd9d3bb25429@[81.101.66.68]>

Eric Nieuwland wrote:

>>Another idea: would checking an application's creation/modification 
>>date be a viable way to avoid the cache going bad when a newer 
>>version of the app is installed in exactly the same location?
>
>How are you going to check "an application's creation/modification 
>date"? Don't use the file/directory attributes for this! 'ctime' is 
>unreliable for this to say the least. And 'mtime' is often tricky on 
>directories.

Yeah, it's a non-starter. Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From Jack.Jansen at cwi.nl  Thu Oct 21 13:08:39 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Thu Oct 21 13:10:37 2004
Subject: [Pythonmac-SIG] charts & graphs
In-Reply-To: <49A178E2-231E-11D9-B237-003065F93FF0@cwazy.co.uk>
References: <20041020100102.7F4091E4010@bag.python.org>
	<B716ECCA-2297-11D9-A9CF-000A95E89E1C@vanderbilt.edu>
	<49A178E2-231E-11D9-B237-003065F93FF0@cwazy.co.uk>
Message-ID: <8FA4347C-2351-11D9-B6BF-000A958D1666@cwi.nl>


On 21-okt-04, at 7:01, Lance Boyle wrote:

> Someone should probably put together an annotated list of 
> Python-appropriate plotting options, since this gets asked a lot (I 
> suppose).

Yes, please do! A good place to put this is in the FAQ, or (if there's 
a lot of information) in another document on the Wiki, with a reference 
in the FAQ.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From Jack.Jansen at cwi.nl  Thu Oct 21 13:59:48 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Thu Oct 21 13:59:51 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f0abd9c6540b607@[81.101.66.68]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com>
	<068A4DD8-225E-11D9-B065-000393894CEA@xs4all.nl>
	<a05200f0abd9c6540b607@[81.101.66.68]>
Message-ID: <B4F8CB80-2358-11D9-B6BF-000A958D1666@cwi.nl>


On 20-okt-04, at 21:33, has wrote:
> Disadvantages:
> - ATS must be running on every machine whose applications are being 
> scripted (installation issues? permissions issues? add to startup 
> items?)

This I would consider a showstopper, specifically the "must" bit. 
There's all sorts of issues with starting daemons (like: will the 
daemon be system-wide or per-user? What are the security-implications? 
And what if different users have different versions of a program 
installed? Different appscript versions? And that's only what I can 
come up with in a few minutes of thinking).

I do think, though, that the daemon is a good solution to the caching 
question. So I would propose to make the daemon optional, and continue 
without caching if it isn't there.

Hmm, maybe the search order for terminology should be the following:
1. Check whether the developer has included precompiled terminology 
(which could be an option to py2app)
2. Otherwise, check whether the ATS is running and obtain terminology 
from there
3. Otherwise do the whole generation yourself.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From bob at redivi.com  Thu Oct 21 14:27:44 2004
From: bob at redivi.com (Bob Ippolito)
Date: Thu Oct 21 14:28:19 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f0cbd9ca7442ee5@[81.101.66.68]>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<10B87644-21AC-11D9-B266-000393894CEA@xs4all.nl>
	<EC458A25-21D0-11D9-8B44-000A95BA5446@redivi.com>
	<FDEB5BA3-21DF-11D9-B065-000393894CEA@xs4all.nl>
	<B7572D08-21E1-11D9-8B44-000A95BA5446@redivi.com>
	<CE53EFA3-21E5-11D9-B065-000393894CEA@xs4all.nl>
	<BD5C8FEE-21E6-11D9-8B44-000A95BA5446@redivi.com>
	<2EBCF0C6-2203-11D9-B065-000393894CEA@xs4all.nl>
	<427D095B-2205-11D9-B5C9-000A95BA5446@redivi.com> <068A4DD8-225E-11
	<72569519-22D0-11D9-B95B-000A95BA5446@redivi.com>
	<a05200f0bbd9c8fa2a4e0@[81.101.66.68]>
	<93548AC7-22EB-11D9-B95B-000A95BA5446@redivi.com>
	<a05200f0cbd9ca7442ee5@[81.101.66.68]>
Message-ID: <9C11B49C-235C-11D9-A940-000A95BA5446@redivi.com>


On Oct 21, 2004, at 5:11, has wrote:

> Bob wrote:
>
>>>> appscript can install the FBA into its package,
>>>
>>> Fine with me. I'm not sure how to package it for distribution though 
>>> - AFAIK distutils isn't resource fork/creator code-friendly. Advice?
>>
>> It's not.  Don't use resource forks.
>
> I've not. I do have a creator code though - makes it easier for 
> appscript to identify ATS.

Your creator code should be declared in the PkgInfo and Info.plist 
files.. BSD copying sure won't screw up text files.

>>> Another idea: would checking an application's creation/modification 
>>> date be a viable way to avoid the cache going bad when a newer 
>>> version of the app is installed in exactly the same location?
>>
>> For bundled applications you would have to walk the whole application 
>> tree to see if anything has changed.. It's possible to update 
>> resources without touching the outer folder.
>
> Good point. Also, Steve's point that an application can gain or lose 
> terminology as scriptable extensions are added or removed. Definitely 
> puts the kibosh on that one.
>
> How about process id? As in: "When ATS receives a request for an 
> application's terminology, if the application's process id has changed 
> since the terminology was last cached, reload it." Would that cover 
> the updated application scenario okay? It won't cover the extensible 
> terminology situation, but even that might be partially addressable, 
> e.g. by having appscript request 'fresh' terminology if it encounters 
> a keyword it's not familiar with.

That sounds like a good idea.  Actually.. you could register for all 
application start/termination notifications and get/parse terminologies 
for any application that starts.  You should be able to do this with 
PyObjC via NSWorkspace: 
http://developer.apple.com/technotes/tn/tn2050.html

-bob

From hengist.podd at virgin.net  Thu Oct 21 13:12:09 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 21 16:27:25 2004
Subject: [Pythonmac-SIG] appscript terminology caching
In-Reply-To: <7DE22FD1-22EC-11D9-B95B-000A95BA5446@redivi.com>
References: <a05200f07bd92eb902d7c@[81.103.145.108]>
	<a05200f0abd9456c5d66a@[81.103.145.108]>
	<A6A8C9CA-1E1B-11D9-A9E0-000D934FF6B4@cwi.nl>
	<a05200f0cbd94b092d6f1@[81.103.145.108]>
	<3DC10EF6-1EE2-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f0fbd95da1fb0d0@[81.103.145.108]>
	<A0DAA196-1EEC-11D9-BD19-000A95686CD8@redivi.com>
	<03B3AB44-1EFE-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f11bd96bc22e091@[81.103.145.108]>
	<BF90932B-1FB4-11D9-B80D-000D934FF6B4@cwi.nl>
	<a05200f02bd97ce3e14d0@[81.101.66.68]>
	<941B06E2-208E-11D9-B266-000393894CEA@xs4all.nl>
	<0FB3871B-20E7-11D9-82E8-000D934FF6B4@cwi.nl>
	<A8971AAE-22E8-11D9-BC56-000393C5ED50@mac.com>
	<7DE22FD1-22EC-11D9-B95B-000A95BA5446@redivi.com>
Message-ID: <a05200f12bd9d42e50410@[81.101.66.68]>

Bob wrote:

>>one small consideration to add: some apps update their terminology 
>>without a version change.. the means i have in mind is that some 
>>XTensions to QuarkXPress (4.x, at least) would dynamically extend 
>>the dictionary when the app launched.. the new terminology could 
>>only be obtained when the app was running, not from parsing the 
>>AETE in the resource fork.. i don't  how or whether this situation 
>>has changed with Mac OS X versions of XPress or other apps.. 
>>Frontier did a parse of the static AETE, and so i had to hand add 
>>entries to the glue table, but if the AETE API that appscript uses 
>>ensures that dynamic entries are returned to queries, then i guess 
>>this isn't an issue
>
>appscript shouldn't be reading anything directly from resources, so 
>that's not an issue.  However, if appscript gets ahold of the 
>QuarkXPress aete before it's loaded all of its extensions (which 
>might happen if appscript does the launching, I guess), then you 
>have an issue.

Appscript uses OSAGetAppTerminology, so supply the right aete(s) is 
the OS's responsibility.

One scenario where it would have a problem is when the user adds or 
removes scriptable application extensions while the app is running - 
this change wouldn't be picked up by appscript/ATS so it wouldn't 
know the cached terminology has gotten out of date.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Thu Oct 21 16:26:07 2004
From: hengist.podd at virgin.net (has)
Date: Thu Oct 21 16:27:28 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
Message-ID: <a05200f14bd9d7159e723@[81.101.66.68]>

Hi all,

I've posted a demonstration of appscript + ATS for folks to try:

http://freespace.virgin.net/hamish.sanderson/appscript-0.8.0.tar.gz
http://freespace.virgin.net/hamish.sanderson/aem-0.3.2.tar.gz

Notes:

- You'll need to install ATS, appscript, etc. on every machine you 
intend to script.


- For now you'll need to unstuff and launch ATS yourself. Suggest 
using Process Viewer to check it's running ok before you start using 
it.


-  ATS'll write message to Console when caching and clearing 
terminology, just to keep you informed.


- To clear the ATS cache, use:

tell application "AppscriptTerminologyServer" to ?event ATSrClrC? -- local

tell application 
"eppc://user:pass@ip-address/AppscriptTerminologyServer" to ?event 
ATSrClrC? -- remote


- Local application scripting works exactly the same as before, only faster.


- Remote scripting now works, e.g.:

#!/usr/local/bin/pythonw
from appscript import *
print app('eppc://has:foobar@0.0.0.10/TextEdit').documents[1].text.get()


- help() and htmldoc currently only work with local apps. If we go 
with ATS I'll add support for remote apps too.


Let me know what you think.

Cheers,

has

p.s. Appscript's help() method is also becoming a nice unique selling 
point. Currently AppleScripters have to shell out $$$ on Script 
Debugger to get inheritance and containment tree graphical viewers; 
appscript now has built-in text-based versions that work well in the 
interactive interpreter. Give it a spin and see what you think; 
suggestions for improvements and additions very welcome.
-- 
http://freespace.virgin.net/hamish.sanderson/
From Chris.Barker at noaa.gov  Thu Oct 21 20:16:21 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Thu Oct 21 20:17:20 2004
Subject: [Pythonmac-SIG] charts & graphs
In-Reply-To: <8FA4347C-2351-11D9-B6BF-000A958D1666@cwi.nl>
References: <20041020100102.7F4091E4010@bag.python.org>	<B716ECCA-2297-11D9-A9CF-000A95E89E1C@vanderbilt.edu>	<49A178E2-231E-11D9-B237-003065F93FF0@cwazy.co.uk>
	<8FA4347C-2351-11D9-B6BF-000A958D1666@cwi.nl>
Message-ID: <4177FCF5.6020106@noaa.gov>

Jack Jansen wrote:
> On 21-okt-04, at 7:01, Lance Boyle wrote:
>> Someone should probably put together an annotated list of 
>> Python-appropriate plotting options, since this gets asked a lot (I 
>> suppose).
> 
> Yes, please do! A good place to put this is in the FAQ, or (if there's a 
> lot of information) in another document on the Wiki, with a reference in 
> the FAQ.

Definitely the Wiki. This is the kind of list that will need a lot of 
annotation, addition and updating.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov
From brad.allen at omsdal.com  Fri Oct 22 01:31:27 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 22 01:32:23 2004
Subject: [Pythonmac-SIG] interaction with OS X commands
In-Reply-To: <2807195C-220F-11D9-B5C9-000A95BA5446@redivi.com>
Message-ID: <OFDB1EA7E0.C298207F-ON86256F34.0080B611-86256F34.00813996@omsdal.com>



Thanks for the advice, Bob. The subprocess.py module is indeed turning out
to be more elegant and user-friendly than the os.popen and os.spawnv way of
doing things.

Bob Ippolito <bob@redivi.com> wrote on 10/19/2004 03:40:47 PM:

>
> On Oct 19, 2004, at 16:36, brad.allen@omsdal.com wrote:
>
> > Bob Ippolito <bob@redivi.com> wrote on 10/18/2004 06:40:08 PM:
> >
> >> No it does not require Python 2.4.  If you look at PEP 291 it says
> >> that
> >> subprocess shall remain backwards compatible with Python 2.2.
> >
> > That sounds promising, but I haven't had much luck finding where to
> > download it or instructions on how to install it. Is it a simple pure
> > Python module with no outside dependencies? Can I simply distribute
> > this
> > module in a directory alongside my other Python modules & packages?
>
> The URL I provided tells you exactly where to get it from: a CVS
> repository.  It has a setup.py, so you install it like you install
> anything else.. though you could just copy subprocess.py wherever it
> needs to go.  Alternatively you can get it from Python 2.4 CVS.
>
> Yes it is a simple Python module with no dependencies (on win32 it
> requires a _subprocess extension).
>
> Yes you can simply distribute the module in a directory alongside your
> other modules/packages.
>
> -bob
>

From brad.allen at omsdal.com  Fri Oct 22 02:00:44 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 22 02:01:36 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <4177FCF5.6020106@noaa.gov>
Message-ID: <OFD29F9509.77DAD5BD-ON86256F34.008142D9-86256F35.0000121D@omsdal.com>

I'm looking for a good way to obtain the versions of Mac OS X application
bundles. The osascript/Applescript approach has serious problems, because
sometimes the Finder isn't running.

The info.plist file in the application bundle usually contains version
info. However, I'm not sure I want to get into parsing plists. Is this the
best approach, or is there a way to do it using native APIs?

Thanks for any help or ideas on this!

(here is my test attempt to obtain a version of an application bundle using
the Applescript approach--various bad things happened when run via ssh on a
Mac sitting at the login prompt)

import subprocess

#determine the version of Timbuktu, as an example
appleScript = """
tell application "Finder"
      version of file "Applications:Timbuktu Pro:Timbuktu Pro" of startup
disk
end tell
"""

PIPE = subprocess.PIPE
args = ('osascript','-e',appleScript)
child =
subprocess.Popen(args,executable='/usr/bin/osascript',stdin=PIPE,stdout=PIPE,stderr=PIPE)
version = child.stdout.read()
print version

From hengist.podd at virgin.net  Fri Oct 22 01:26:52 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 22 02:03:51 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
Message-ID: <a05200f17bd9dae1f0508@[81.101.66.68]>

Jack Jansen wrote:

>  > Disadvantages:
>  > - ATS must be running on every machine whose applications are being
>  > scripted (installation issues? permissions issues? add to startup
>  > items?)
>
>This I would consider a showstopper, specifically the "must" bit.

I don't think it's going to be that bad myself, but that's what we're 
here to find out, so onwards... :)


>There's all sorts of issues with starting daemons (like: will the
>daemon be system-wide or per-user?

It's a user-level process, so I guess that makes it per-user. Out of 
interest, does [Mac]Python run anything at any other level?

Question: what are the rules for Python.app? ATS occupies a position 
equivalent to that of Python.app, so presumably we can apply any 
rules for the latter to the former.


>What are the security-implications?

An important issue, and one I'm hoping other folks can tell me. :)

Thoughts: While I'm no security expert, I can't see ATS introducing 
any holes myself simply because it's so limited in what it can do. 
ATS's philosophy is effectively "Don't do anything your parents 
wouldn't do." Mostly it just performs tasks that are already 
doable/being done, though more efficiently. The only new behaviour it 
introduces to a system is the ability to request the terminology of a 
remotely running application, which it does via a standard channel - 
Remote Apple Events.

Now, RAE security is a system-level, not application-level, issue, so 
I can't see how ATS can do any damage there. Anyone who's breached 
your system security is going straight to Finder or Terminal to 
delete your hard disk, not ATS which has no facility for writing to 
disk or launching processes.

Therefore I'm feeling as confident as I can be not being a security 
whizz, but obviously would like some comment from those who are. I'll 
also sling this topic over to the AppleScript-Implementors list at 
some point; sound out folks there. (Particularly the Apple engineers 
who are presumably responsible for RAE and its attendant security 
issues.) I'll let you all know what comes of that.


>And what if different users have different versions of a program
>installed?

Don't understand this one; can you clarify?

(Note that the purpose of ATS is to return the terminology for a 
specified application. With local applications, the application is 
specified by path; with remote applications, by machine IP and 
process name. In either case, it's the user's responsibility to 
specify the right app; additionally, in the latter case it's the 
remote machine's job also to have the right app running. Neither is 
[fortunately] ATS/appscript's problem; they just take what they're 
given.:)


>Different appscript versions?

Pretty much a non-issue. ATS's Apple event interface is the only 
point of contact, and both it and the data formats it returns should 
be stable across versions.

The only thing that's likely to change is if/when Apple introduce an 
OSAGetAppSDEF call, which would affect ATS's planned 'get terminology 
[in raw form]' option. When that happens, we'll need a further option 
'get terminology [in raw form [using best available format]]' which 
would return a raw SDEF if the newer call is available and all 
parties how to use an SDEF, otherwise it'll call good old 
OSAGetAppTerminology to get and return a raw AETE (which is also the 
default when the 'best available format' option isn't included).


>So I would propose to make the daemon optional, and continue
>without caching if it isn't there.
>
>Hmm, maybe the search order for terminology should be the following:
>1. Check whether the developer has included precompiled terminology
>(which could be an option to py2app)

I think we should provide an optional 'terms' keyword argument to the 
app() constructor, allowing users to pass in an object containing the 
name-code translation dicts themselves (this seems the easiest point 
to add an 'in').

This would provide a penultimate fallback for users working with 
applications whose aetes are just too bolloxed up to work without 
manual patching, in which case the desperate user can dump() what's 
usable to file and replace the corrupted/missing bits by hand. For 
example, Smile's dictionary is a good example of this, lacking 
definitions for some basic commands and classes (AppleScript can use 
the default definitions from its aeut resource, but we're not 
AppleScript and want nothing to do with such kludgery), and 
forgetting to supply a keyword for at least one raw code. It would 
also bail out users who wish to use appscript to control a remote 
application on, say, an OS9 machine.

(BTW, since this wouldn't involve a custom file/module management 
mechanism as was being considered for the appscript-based caching 
system, it can use the standard Python module system so won't require 
special knowledge to use or tools like py2app to provide additional 
support.)

One other thing to note: let's not forget that users can always 
resort to using aem instead of appscript. I don't think it's 
appscript's job to bend over backwards to accommodate the few 
completely psychotic applications that spoil the air for everyone 
else. Appscript makes simple things simple; aem ensures that hard 
things are possible. AEM's API is deliberately unsophisticated but 
still designed to allow human use, and once you throw in some tools 
to auto-generate constants modules from aetes it should be a 
perfectly reasonable, if workman-like, option. Each tool to its own 
use.

Thoughts?


>2. Otherwise, check whether the ATS is running and obtain terminology
>from there

Easy enough for appscript.terminology to trap the MacOS.Error -600 
that occurs if ATS isn't running when it tries to call it.


>3. Otherwise do the whole generation yourself.

Trapping the above error and importing and calling the ATS 
terminologyparser module would add 4 lines to appscript.terminology, 
so wouldn't be hard to implement. This would only be good for local 
applications, however, and frankly, if you're allowed to run 
Python.app but not ATS then there's something a bit funny about your 
setup IMO. Being seriously anti-gratuitous feature creep, I'd still 
want some sort of justification for adding the extra rule. We have to 
balance the added complexity the extra search options introduces for 
the user: with an ATS-only solution they only have one rule to 
follow; more options means more rules to remember. (i.e. Don't forget 
the Python philosophy of "There should be one, and preferably only 
one, way to do it" - too many options can be worse than not enough.)

Many thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Fri Oct 22 01:33:59 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 22 02:03:54 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
Message-ID: <a05200f18bd9ddee97452@[81.101.66.68]>

Bob Ippolito bwrote:

>  > I do have a creator code though
>
>Your creator code should be declared in the PkgInfo and Info.plist
>files.. BSD copying sure won't screw up text files.

Oh, cool. Thanks.


>  >>> a viable way to avoid the cache going bad when a newer
>  >>> version of the app is installed in exactly the same location?
>  >>
>  > How about process id? As in: "When ATS receives a request for an
>  > application's terminology, if the application's process id has changed
>  > since the terminology was last cached, reload it."
>
>That sounds like a good idea.  Actually.. you could register for all
>application start/termination notifications and get/parse terminologies
>for any application that starts.

Heh, sounds almost too slick - users will think we aren't working 
hard enough if we make things look completely effortless. ;)

Certainly worth exploring - except for any applications that 
add/remove terminology without restarting, I can see it keeping the 
cache completely fresh. If it doesn't require a large amount of code 
I'm all for trying it.


>You should be able to do this with
>PyObjC via NSWorkspace:
>http://developer.apple.com/technotes/tn/tn2050.html

Can it be done without PyObjC? It's a great piece of kit, but until 
it becomes part of the standard library I'd feel a little more 
comfortable sticking to standard APIs as it's one less dependency to 
deal with. (Or am I just being too neurotic?)

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From bob at redivi.com  Fri Oct 22 02:08:49 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 02:09:24 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <OFD29F9509.77DAD5BD-ON86256F34.008142D9-86256F35.0000121D@omsdal.com>
References: <OFD29F9509.77DAD5BD-ON86256F34.008142D9-86256F35.0000121D@omsdal.com>
Message-ID: <8CF63BAC-23BE-11D9-9963-000A95BA5446@redivi.com>

On Oct 21, 2004, at 20:00, brad.allen@omsdal.com wrote:

> I'm looking for a good way to obtain the versions of Mac OS X  
> application
> bundles. The osascript/Applescript approach has serious problems,  
> because
> sometimes the Finder isn't running.
>
> The info.plist file in the application bundle usually contains version
> info. However, I'm not sure I want to get into parsing plists. Is this  
> the
> best approach, or is there a way to do it using native APIs?
>
> Thanks for any help or ideas on this!
>
> (here is my test attempt to obtain a version of an application bundle  
> using
> the Applescript approach--various bad things happened when run via ssh  
> on a
> Mac sitting at the login prompt)
>
> import subprocess
>
> #determine the version of Timbuktu, as an example
> appleScript = """
> tell application "Finder"
>       version of file "Applications:Timbuktu Pro:Timbuktu Pro" of  
> startup
> disk
> end tell
> """
>
> PIPE = subprocess.PIPE
> args = ('osascript','-e',appleScript)
> child =
> subprocess.Popen(args,executable='/usr/bin/ 
> osascript',stdin=PIPE,stdout=PIPE,stderr=PIPE)
> version = child.stdout.read()
> print version

(note that neither of these approaches will work for CFM applications  
that are not an application bundle.. you would need to read the  
resource fork and get the plist resource.. I think it's 'plst',..)

With PyObjC:

 >>> from Foundation import *
 >>> bndl = NSBundle.bundleWithPath_(u'/Applications/iTunes.app')
 >>> bndl.infoDictionary()[u'CFBundleVersion']
u'4.6'

Without:

 >>> import plistlib
 >>>  
plistlib.Plist.fromFile(u'/Applications/iTunes.app/Contents/ 
Info.plist')[u'CFBundleVersion']
'4.6'

Finding an application if you don't know its path more or less requires  
using LaunchServices.. which isn't included with Python 2.3 (but I  
think you can get it from Jack's PackageManager repository, and I  
believe appscript may also install it).

-bob

From bob at redivi.com  Fri Oct 22 02:14:31 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 02:15:38 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f18bd9ddee97452@[81.101.66.68]>
References: <a05200f18bd9ddee97452@[81.101.66.68]>
Message-ID: <588548A6-23BF-11D9-9963-000A95BA5446@redivi.com>

On Oct 21, 2004, at 19:33, has wrote:

> Bob Ippolito wrote:
>
>> You should be able to do this with
>> PyObjC via NSWorkspace:
>> http://developer.apple.com/technotes/tn/tn2050.html
>
> Can it be done without PyObjC? It's a great piece of kit, but until it 
> becomes part of the standard library I'd feel a little more 
> comfortable sticking to standard APIs as it's one less dependency to 
> deal with. (Or am I just being too neurotic?)

You **MIGHT** be able to do it with Carbon Events, but you can't be 
sure if the Python wrappers for that have all the functionality 
required.  Otherwise you either have to buck up and use PyObjC, or 
write a C or ObjC extension that does it.  I guarantee the former is a 
better option.

You are being too neurotic.  Everyone who develops Python applications 
for the Mac either already has PyObjC or should install it immediately. 
  If they don't, they're missing out on damn near everything :)

-bob

From bob at redivi.com  Fri Oct 22 02:21:24 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 02:21:58 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f17bd9dae1f0508@[81.101.66.68]>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
Message-ID: <4E6D6B0D-23C0-11D9-9963-000A95BA5446@redivi.com>

On Oct 21, 2004, at 19:26, has wrote:

> Jack Jansen wrote:
>
>> There's all sorts of issues with starting daemons (like: will the
>> daemon be system-wide or per-user?
>
> It's a user-level process, so I guess that makes it per-user. Out of 
> interest, does [Mac]Python run anything at any other level?

Python runs at whatever level you run it at, and it dies when the 
script is over.  Python is not a daemon (unless your script is).

> Question: what are the rules for Python.app? ATS occupies a position 
> equivalent to that of Python.app, so presumably we can apply any rules 
> for the latter to the former.

There is no real Python.app.  Python.app is just a trick that puts the 
interpreter inside of an application bundle so pythonw will work.  
PythonLauncher is the closest thing to a "Python.app" and it doesn't 
have an ounce of Python code in it (written in Objective C), it just 
runs the Python interpreter in a subprocess or it will tell Terminal to 
run a certain command in a new window.

-bob

From cohar at conncoll.edu  Fri Oct 22 03:30:58 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Fri Oct 22 03:31:04 2004
Subject: [Pythonmac-SIG] IDEs, debugging, and wxPython
Message-ID: <06874FC0-23CA-11D9-B541-000393A37396@conncoll.edu>

I've been writing wxPython-based apps happily enough (especially once 
py2app came along!), but I'm doing it in a clumsy way: using one or 
another text editor, running with pythonw from the editor or from a 
Terminal command line. PythonCard has an editor, so does PyOXIDE, and 
there are many others, all well and good.

What I can't find is a GUI-based debugger integrated with an editor. 
Call me a wuss, but I don't want to do command-line debugging of GUI 
apps when I can help it. All I need is to be able to watch a few 
variables, set the occasional breakpoint, and so on. Xcode assumes I 
want to write a Cocoa app; PyOXIDE's debugger crashes on me; telling 
PythonCard to run the app with a Debug menu does nothing (gets 
overriden by my own app's menus?); IDLE wants TKinter which I don't 
use; and so on, and so on.

What are people using? What's handy? What obvious thing am I, as usual, 
missing?

Charles Hartman

From hengist.podd at virgin.net  Fri Oct 22 03:40:46 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 22 03:52:09 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <4E6D6B0D-23C0-11D9-9963-000A95BA5446@redivi.com>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<4E6D6B0D-23C0-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <a05200f1cbd9e1212720d@[81.101.66.68]>

Bob wrote:

>>>There's all sorts of issues with starting daemons (like: will the
>>>daemon be system-wide or per-user?
>>
>>It's a user-level process, so I guess that makes it per-user. Out 
>>of interest, does [Mac]Python run anything at any other level?
>
>Python runs at whatever level you run it at, and it dies when the 
>script is over.  Python is not a daemon (unless your script is).

Was a dumb question.:) Perhaps a slightly less dumb one: can 
application scripting be done at any level other than user-level?


>>Question: what are the rules for Python.app? ATS occupies a 
>>position equivalent to that of Python.app, so presumably we can 
>>apply any rules for the latter to the former.
>
>There is no real Python.app.  Python.app is just a trick that puts 
>the interpreter inside of an application bundle so pythonw will work.

Yeah, basically both are tools to facilitate execution of Python 
scripts. In Python.app's case, scripts that require a GUI connection; 
in ATS's case, scripts that require a call to OSAGetAppTerminology. 
How they're implemented isn't really important; it's more about what 
they do and why. Does that make sense?

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Fri Oct 22 03:50:40 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 22 03:52:11 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <588548A6-23BF-11D9-9963-000A95BA5446@redivi.com>
References: <a05200f18bd9ddee97452@[81.101.66.68]>
	<588548A6-23BF-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <a05200f1dbd9e1587415d@[81.101.66.68]>

Bob Ippolito wrote:

>>>You should be able to do this with
>>>PyObjC via NSWorkspace:
>>>http://developer.apple.com/technotes/tn/tn2050.html
>>
>>Can it be done without PyObjC? It's a great piece of kit, but until 
>>it becomes part of the standard library I'd feel a little more 
>>comfortable sticking to standard APIs as it's one less dependency 
>>to deal with. (Or am I just being too neurotic?)
>
>You **MIGHT** be able to do it with Carbon Events, but you can't be 
>sure if the Python wrappers for that have all the functionality 
>required.  Otherwise you either have to buck up and use PyObjC, or 
>write a C or ObjC extension that does it.  I guarantee the former is 
>a better option.

Heh, can totally believe that. :)


>You are being too neurotic.  Everyone who develops Python 
>applications for the Mac either already has PyObjC or should install 
>it immediately.  If they don't, they're missing out on damn near 
>everything

Absolutely. However, appscript is geared at least as much towards 
casual scripters as application developers. Just worrying about all 
the crap that can go wrong when you start setting AppleScripters 
loose on MacPython+appscript; merely getting them through the 
installation successfully may be a challenge....

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From bob at redivi.com  Fri Oct 22 04:18:04 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 04:18:40 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f1dbd9e1587415d@[81.101.66.68]>
References: <a05200f18bd9ddee97452@[81.101.66.68]>
	<588548A6-23BF-11D9-9963-000A95BA5446@redivi.com>
	<a05200f1dbd9e1587415d@[81.101.66.68]>
Message-ID: <9B1A8BF8-23D0-11D9-9963-000A95BA5446@redivi.com>

On Oct 21, 2004, at 21:50, has wrote:

> Bob Ippolito wrote:
>
>>>> You should be able to do this with
>>>> PyObjC via NSWorkspace:
>>>> http://developer.apple.com/technotes/tn/tn2050.html
>>>
>>> Can it be done without PyObjC? It's a great piece of kit, but until 
>>> it becomes part of the standard library I'd feel a little more 
>>> comfortable sticking to standard APIs as it's one less dependency to 
>>> deal with. (Or am I just being too neurotic?)
>>
>> You **MIGHT** be able to do it with Carbon Events, but you can't be 
>> sure if the Python wrappers for that have all the functionality 
>> required.  Otherwise you either have to buck up and use PyObjC, or 
>> write a C or ObjC extension that does it.  I guarantee the former is 
>> a better option.
>
> Heh, can totally believe that. :)
>
>
>> You are being too neurotic.  Everyone who develops Python 
>> applications for the Mac either already has PyObjC or should install 
>> it immediately.  If they don't, they're missing out on damn near 
>> everything
>
> Absolutely. However, appscript is geared at least as much towards 
> casual scripters as application developers. Just worrying about all 
> the crap that can go wrong when you start setting AppleScripters loose 
> on MacPython+appscript; merely getting them through the installation 
> successfully may be a challenge....

Not really, you can have a metapackage (which you should build with 
bdist_mpkg, of course) that includes PyObjC, appscript, py2app, etc. 
that they just double-click to install.  Of course you would need to 
maintain separate ones for Panther and Jaguar users, but nothing more 
complicated than using Installer.app for the user.

If you check out my py2app-branch of PyObjC, you'll see that when you 
build a bdist_mpkg from it, it includes all of PyObjC (packages, 
documentation, source, examples, scripts) PLUS all of py2app as a 
sub-metapackage.  Of course making bdist_mpkg do such complex things 
isn't the most straightforward thing in the world because I just wrote 
it this week and distutils gets in the way in a lot of respects -- 
there is a working example out there that does it.

screenshot: http://redivi.com/~bob/py2app_bdist_mpkg_pyobjc.pdf

Worst case (if you can't figure out how to do it, or you're lazy), you 
could have a disk image that includes the appscript and PyObjC 
metapackages separately and tell them to install both.

-bob

From brad.allen at omsdal.com  Fri Oct 22 06:58:30 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 22 06:59:09 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <8CF63BAC-23BE-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <OF7E98AB3B.19DECB3C-ON86256F35.0016B2CA-86256F35.001B5525@omsdal.com>


Bob Ippolito <bob@redivi.com> wrote on 10/21/2004 07:08:49 PM:

> With PyObjC:
>
>  >>> from Foundation import *
>  >>> bndl = NSBundle.bundleWithPath_(u'/Applications/iTunes.app')
>  >>> bndl.infoDictionary()[u'CFBundleVersion']
> u'4.6'
>
> Without:
>
>  >>> import plistlib
>  >>>
> plistlib.Plist.fromFile(u'/Applications/iTunes.app/Contents/
> Info.plist')[u'CFBundleVersion']
> '4.6'

Thanks! I'm glad to know there's an easy way to get this done in the short
term without having to install PyObjC, even though long term I will
probably want to have PyObjC deployed as part of our standard Mac
configuration.

> (note that neither of these approaches will work for CFM applications
> that are not an application bundle.. you would need to read the
> resource fork and get the plist resource.. I think it's 'plst',..)

We have already crossed that bridge by hiring a developer (Walker Hale) to
build a Python module to do that. He came up with a way to do it using
Python's built-in support for Carbon on OS X. I'm hoping my employer will
allow me to post more of the project code publicly, because we can benefit
from "open source" scrutiny, and because some of it may prove useful to
others.


From bob at redivi.com  Fri Oct 22 07:48:34 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 07:49:10 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <OF7E98AB3B.19DECB3C-ON86256F35.0016B2CA-86256F35.001B5525@omsdal.com>
References: <OF7E98AB3B.19DECB3C-ON86256F35.0016B2CA-86256F35.001B5525@omsdal.com>
Message-ID: <033B9B3C-23EE-11D9-9963-000A95BA5446@redivi.com>

On Oct 22, 2004, at 0:58, brad.allen@omsdal.com wrote:

>
> Bob Ippolito <bob@redivi.com> wrote on 10/21/2004 07:08:49 PM:
>
>> With PyObjC:
>>
>>>>> from Foundation import *
>>>>> bndl = NSBundle.bundleWithPath_(u'/Applications/iTunes.app')
>>>>> bndl.infoDictionary()[u'CFBundleVersion']
>> u'4.6'
>>
>> Without:
>>
>>>>> import plistlib
>>>>>
>> plistlib.Plist.fromFile(u'/Applications/iTunes.app/Contents/
>> Info.plist')[u'CFBundleVersion']
>> '4.6'
>
> Thanks! I'm glad to know there's an easy way to get this done in the 
> short
> term without having to install PyObjC, even though long term I will
> probably want to have PyObjC deployed as part of our standard Mac
> configuration.

Do it!  If not now, then when 1.2 is released.  1.2 adds a couple 
useful things that let you have more control from Python (a la ctypes). 
  A big one is that you can bridge a certain class of functions that 
aren't even Obj-C, as long as they are in a bundle (current somewhat 
arbitrary restriction).. for example, I was able to get access to 
LaunchServices today using only this bridge.

>> (note that neither of these approaches will work for CFM applications
>> that are not an application bundle.. you would need to read the
>> resource fork and get the plist resource.. I think it's 'plst',..)
>
> We have already crossed that bridge by hiring a developer (Walker 
> Hale) to
> build a Python module to do that. He came up with a way to do it using
> Python's built-in support for Carbon on OS X. I'm hoping my employer 
> will
> allow me to post more of the project code publicly, because we can 
> benefit
> from "open source" scrutiny, and because some of it may prove useful to
> others.

Yeah, Carbon is annoying.. It would look something like this:

from Carbon.File import FSRef, FSGetResourceForkName
from Carbon.Files import fsRdPerm
from Carbon.Res import FSOpenResourceFile, CloseResFile, UseResFile, 
Get1Resource
from cStringIO import StringIO
import os, plistlib

def getInfoPlistForApp(app):
     if os.path.isdir(app):
         return plistlib.Plist.fromFile(os.path.join(app, 'Contents', 
'Info.plist'))
     fsRef = FSRef('/Applications/Remote Desktop Connection/Remote 
Desktop Connection')
     resId = FSOpenResourceFile(fsRef, FSGetResourceForkName(), fsRdPerm)
     UseResFile(resId)
     plistData = StringIO(Get1Resource('plst', 0).data)
     CloseResFile(resId)
     return plistlib.Plist.fromFile(plistData)

def appVersion(app):
     return getInfoPlistForApp(app)['CFBundleVersion']

# Mach-O
 >>> appVersion('/Applications/iTunes.app')
'4.6'

# CFM
 >>> appVersion('/Applications/Remote Desktop Connection/Remote Desktop 
Connection')
'1.0.3'

... though I would use LaunchServices, not paths, to find applications, 
which you *can't* do with a standard MacPython distribution without 
fetching at least one extension :)

-bob

From Jack.Jansen at cwi.nl  Fri Oct 22 10:37:19 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Oct 22 10:37:18 2004
Subject: [Pythonmac-SIG] IDEs, debugging, and wxPython
In-Reply-To: <06874FC0-23CA-11D9-B541-000393A37396@conncoll.edu>
References: <06874FC0-23CA-11D9-B541-000393A37396@conncoll.edu>
Message-ID: <9636EAE6-2405-11D9-9BAE-000A958D1666@cwi.nl>


On 22-okt-04, at 3:30, Charles Hartman wrote:
> What I can't find is a GUI-based debugger integrated with an editor. 
> Call me a wuss, but I don't want to do command-line debugging of GUI 
> apps when I can help it. All I need is to be able to watch a few 
> variables, set the occasional breakpoint, and so on. Xcode assumes I 
> want to write a Cocoa app; PyOXIDE's debugger crashes on me; telling 
> PythonCard to run the app with a Debug menu does nothing (gets 
> overriden by my own app's menus?); IDLE wants TKinter which I don't 
> use; and so on, and so on.

The problem with the debuggers in the current IDEs is that you cannot 
use them to debug GUI applications that use a different GUI toolkit. 
The reason for this is that the various GUI toolkits don't work 
together very well (if at all), so they'll be getting into a fight over 
who owns what window, which redraw requests get sent where, and so on.

The one exception may be Idle, which can debug in a separate process, 
so it should theoretically be possible to debug a wxPython script with 
Idle. But: I don't know of anyone who tried this. So if you do please 
report back your findings.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From Jack.Jansen at cwi.nl  Fri Oct 22 10:45:23 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Oct 22 10:45:27 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f17bd9dae1f0508@[81.101.66.68]>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
Message-ID: <B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>


On 22-okt-04, at 1:26, has wrote:

>> There's all sorts of issues with starting daemons (like: will the
>> daemon be system-wide or per-user?
>
> It's a user-level process, so I guess that makes it per-user. Out of 
> interest, does [Mac]Python run anything at any other level?

No, what I meant was "if user Jack starts ATS, then user Has logs in 
(either via the net or with fast user switching), will he use Jack's 
ATS?". Because that could have security implications (such as allowing 
access to terminology for apps to which Jack has access but Has not).

But it turns out this is probably not a problem: as ATS uses OSA any 
problem will exist with AppleScript without ATS too.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From Jack.Jansen at cwi.nl  Fri Oct 22 11:21:25 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Oct 22 11:21:31 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <OF7E98AB3B.19DECB3C-ON86256F35.0016B2CA-86256F35.001B5525@omsdal.com>
References: <OF7E98AB3B.19DECB3C-ON86256F35.0016B2CA-86256F35.001B5525@omsdal.com>
Message-ID: <BF59A8F2-240B-11D9-9BAE-000A958D1666@cwi.nl>


On 22-okt-04, at 6:58, brad.allen@omsdal.com wrote:
> We have already crossed that bridge by hiring a developer (Walker 
> Hale) to
> build a Python module to do that. He came up with a way to do it using
> Python's built-in support for Carbon on OS X. I'm hoping my employer 
> will
> allow me to post more of the project code publicly, because we can 
> benefit
> from "open source" scrutiny, and because some of it may prove useful to
> others.

Getting this plist from a 'plst' resource should be 10 lines at most 
(but the challenge is of course finding the correct 10 lines:-).

If you structure this as an addition to plistlib (such as 
plistlib.Plist.fromResource(filename, restype='plst', resid=0)) and you 
can live with the rules for donating code to Python (basically that you 
transfer ownership to the Python Software Foundation, www.python.org 
has the details) I'd be happy to incorporate it into the standard 
distribution.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From sw at wordtech-software.com  Fri Oct 22 16:12:02 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Fri Oct 22 16:12:08 2004
Subject: [Pythonmac-SIG] Successful build of PyQt and Eric3 IDE
Message-ID: <41791532.9000703@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have successfully gotten PyQt built on OS X, and I have cobbled
together a little applet bundle of the Eric3 IDE for PyQt. Bob had
attempted this about a year ago, but decided not to add PyQt to the
PackMan database because of various problems. I'm not sure what problems
he encountered, but I haven't yet run into any (I built my stuff against
version 3.3.3 of Qt).

I'm wondering if there would be any interest in making these packages
available in some fashion. Building them is straightforward, but they
take a long time. Part of the problem is that Qt has to be patched to
support QScintilla (the text component of PyQt), so a vanilla
installation of Qt from, say, DarwinPorts won't work (though you
probably could patch the qt_mac.h file after the fact). I'd be reluctant
to make the entire package available from my server, as everything would
be a massive download; Eric3 is 12 megabytes by itself, and I could make
that package available with no problem.


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBeRUxJmdQs+6YVcoRAqMNAJ0Tyhf3cK3Upw2vUVEPO1TSo6BTIACeJw0Z
GlYX8s8QlCKL+mprKTKtlhc=
=C6px
-----END PGP SIGNATURE-----
From hengist.podd at virgin.net  Fri Oct 22 16:16:16 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 22 16:22:52 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <8CF63BAC-23BE-11D9-9963-000A95BA5446@redivi.com>
References: <OFD29F9509.77DAD5BD-ON86256F34.008142D9-86256F35.0000121D@omsdal.com>
	<8CF63BAC-23BE-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <a05200f1fbd9ec0a9f6c3@[81.101.66.68]>

Brad Allen wrote:

>>I'm looking for a good way to obtain the versions of Mac OS X  application
>>bundles. The osascript/Applescript approach has serious problems,  because
>>sometimes the Finder isn't running.

I'd like to suggest using System Events which should always be 
available on OS 10.2 onward, but at least on the version I'm using, 
SE 1.2, several of the file class's properties appear to be broken 
including version and product version. Standard Additions doesn't 
look a better prospect; while the dictionary says it one of its 
return values is a version number, in practice SA 1.9.1 doesn't seem 
to do this. I don't know if the situation's any better under 10.3, 
but so far it's not exactly promising.


>Finding an application if you don't know its path more or less 
>requires  using LaunchServices.. which isn't included with Python 
>2.3 (but I  think you can get it from Jack's PackageManager 
>repository, and I  believe appscript may also install it).

For the benefit of one-stop shoppers who don't already have it, 
there's a distutils-based LS package provided as a separate install 
on my appscript page. Jack's copy may be more up to date though, I 
dunno.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Fri Oct 22 20:18:44 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 22 20:25:22 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
Message-ID: <a05200f1ebd9ea8774b22@[81.101.66.68]>

Jack wrote:

>>>There's all sorts of issues with starting daemons (like: will the
>>>daemon be system-wide or per-user?
>>
>>It's a user-level process, so I guess that makes it per-user.
>
>No, what I meant was "if user Jack starts ATS, then user Has logs in 
>(either via the net or with fast user switching), will he use Jack's 
>ATS?".

Ah, I get you now. Hmm, good question.

I don't know about fast user switching (since I'm on 10.2), but as 
far as networked use goes. I think Remote Apple Events allow user HAS 
to remotely control the running applications of Jack, the locally 
logged-in user, if Jack has RAE enabled and HAS has an account with 
admin privileges on that machine (or else found Jack's password on a 
Post-It note;). e.g.:

	tell application "finder" of machine "eppc://has:foobar@0.0.0.11"
		get name of home
	end tell
	--> "Jack"

So in the Python equivalent, ATS on HAS's machine will use Jack's ATS 
to get the terminology for Jack's running applications, allowing HAS 
to script Jack's applications using appscript. I'm not sure there's 
any other way you can do it; since Apple events are tied up with 
GUI-based Mac apps, which are designed for running by a locally 
logged-in user rather than a remotely logged-in one. (This is about 
the point I start getting confused by the whole issue and think 
myself fortunate for not normally having to deal with this stuff 
myself.;)

I've not had much luck finding info on RAEs and related security 
issues (e.g. searching apple.com turned up nothing very useful), but 
I'll keep looking and see what turns up.

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From bob at redivi.com  Fri Oct 22 20:52:26 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 20:53:03 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <BF59A8F2-240B-11D9-9BAE-000A958D1666@cwi.nl>
References: <OF7E98AB3B.19DECB3C-ON86256F35.0016B2CA-86256F35.001B5525@omsdal.com>
	<BF59A8F2-240B-11D9-9BAE-000A958D1666@cwi.nl>
Message-ID: <84404EF3-245B-11D9-9963-000A95BA5446@redivi.com>


On Oct 22, 2004, at 5:21, Jack Jansen wrote:

>
> On 22-okt-04, at 6:58, brad.allen@omsdal.com wrote:
>> We have already crossed that bridge by hiring a developer (Walker 
>> Hale) to
>> build a Python module to do that. He came up with a way to do it using
>> Python's built-in support for Carbon on OS X. I'm hoping my employer 
>> will
>> allow me to post more of the project code publicly, because we can 
>> benefit
>> from "open source" scrutiny, and because some of it may prove useful 
>> to
>> others.
>
> Getting this plist from a 'plst' resource should be 10 lines at most 
> (but the challenge is of course finding the correct 10 lines:-).
>
> If you structure this as an addition to plistlib (such as 
> plistlib.Plist.fromResource(filename, restype='plst', resid=0)) and 
> you can live with the rules for donating code to Python (basically 
> that you transfer ownership to the Python Software Foundation, 
> www.python.org has the details) I'd be happy to incorporate it into 
> the standard distribution.

Ok, I'll bite:
- added plistlib.readPlistFromResource and plistlib.writePlistToResource
- changed aliasing of builtin (file -> fileobj)
- made float use the correct accuracy (str -> repr)
- fixed date parsing (current version requires PyXML, and it was wrong 
even then.. fixed to use stdlib and correct semantics)
- changed internal representation of dates to datetime.datetime instead 
of float timestamp

http://svn.red-bean.com/bob/plistlib/trunk/plistlib.py

I'll add a patch to sourceforge, would you like me to assign it to you 
or someone else?  ;)

-bob

From just at letterror.com  Fri Oct 22 21:24:50 2004
From: just at letterror.com (Just van Rossum)
Date: Fri Oct 22 21:24:31 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <84404EF3-245B-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <r01050400-1026-0CB0AC75246011D988BE003065D5E7E4@[10.0.0.23]>

Bob Ippolito wrote:

> Ok, I'll bite:
> - added plistlib.readPlistFromResource and
plistlib.writePlistToResource
> - changed aliasing of builtin (file -> fileobj)
> - made float use the correct accuracy (str -> repr)
> - fixed date parsing (current version requires PyXML, and it was wrong 
> even then.. fixed to use stdlib and correct semantics)
> - changed internal representation of dates to datetime.datetime
instead 
> of float timestamp
> 
> http://svn.red-bean.com/bob/plistlib/trunk/plistlib.py
> 
> I'll add a patch to sourceforge, would you like me to assign it to you 
> or someone else?  ;)

Assign it to me if you also patch the __all__ list...

Just
From bob at redivi.com  Fri Oct 22 21:41:00 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 21:41:34 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <r01050400-1026-0CB0AC75246011D988BE003065D5E7E4@[10.0.0.23]>
References: <r01050400-1026-0CB0AC75246011D988BE003065D5E7E4@[10.0.0.23]>
Message-ID: <4D106FCD-2462-11D9-9963-000A95BA5446@redivi.com>


On Oct 22, 2004, at 15:24, Just van Rossum wrote:

> Bob Ippolito wrote:
>
>> Ok, I'll bite:
>> - added plistlib.readPlistFromResource and
> plistlib.writePlistToResource
>> - changed aliasing of builtin (file -> fileobj)
>> - made float use the correct accuracy (str -> repr)
>> - fixed date parsing (current version requires PyXML, and it was wrong
>> even then.. fixed to use stdlib and correct semantics)
>> - changed internal representation of dates to datetime.datetime
> instead
>> of float timestamp
>>
>> http://svn.red-bean.com/bob/plistlib/trunk/plistlib.py
>>
>> I'll add a patch to sourceforge, would you like me to assign it to you
>> or someone else?  ;)
>
> Assign it to me if you also patch the __all__ list...

Done, and done.  http://python.org/sf/1052399

-bob

From brad.allen at omsdal.com  Fri Oct 22 22:40:58 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 22 22:42:13 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <033B9B3C-23EE-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <OF18F61750.626BFACA-ON86256F35.006FF107-86256F35.00719E0D@omsdal.com>


> Yeah, Carbon is annoying.. It would look something like this:


Well, I don't know if this will be useful to you, but I did get permission
to publicly post code from our project. Below is Walker's VersionResource
module. This approach reads from the 'vers' resource, not the 'plst'
resource. The 'plst' resource is easier to parse, I guess. Can we expect it
to be present in every CFM app?


#     File:       VersionResource.py
#
#     Contains:   Class that exposes the information stored in Mac OS
Classic
#                       version resources.
#
#     Version:    Technology: Python 2.2
#                       Group:      sequence
#                       Tag:        $Name:  $ <== explicit checkout
#
#     $Author: walker $ <== last changed by
#     $Date$
#     $Revision$
#     $Source$
#
#     Copyright:  2004 by Omnicom Management Services, all rights reserved

"""Class that exposes the information stored in Mac OS Classic
version resources.
"""

from Carbon import File as F # File Manager
from Carbon import Files as Fs # File Manager constants
from Carbon import Res as R # Resource Manager


#fPath = 'Documents/test_resource'

def getVersionResourceData(fPath):
      """
      Given a file path, return the binary data for the pair of version
resources.

      For historical reasons, a Mac OS Classic file with version info will
      contain two version resources. Both resources have resource type
'vers'.
      One has an ID of 1 and the other has an ID of 2. Normally, the
contents of
      the two resources are identical up to the string data. In resource 1,
the
      string data contains the short and long versions as strings. (The
long
      string usually contains a copyright.) In resource 2, the string data
      contains information about the set that contains this file. Older
files may
      not contain the second resource. Some files may contain identical
resources.


<http://developer.apple.com/documentation/mac/Toolbox/Toolbox-454.html>

      The result is a pair (tuple) of strings or None if the file doesn't
contain
      the matching resource. In most cases, this tuple is sufficient to
compare
      the version info between two files with version resources.

      Will throw exceptions if the file doesn't exist or doesn't contain a
resource
      fork.
      """
      spec = F.FSSpec(fPath)
      num = R.FSpOpenResFile(spec, Fs.fsRdPerm) # file reference number
      assert R.CurResFile() == num
      try:
            h1 = R.Get1IndResource('vers', 1)
            result1 = h1.data[:] # make a copy
            del(h1)
      except:
            result1 = None
      try:
            h2 = R.Get1IndResource('vers', 2)
            result2 = h2.data[:] # make a copy
            del(h2)
      except:
            result2 = None
      R.CloseResFile(num)
      return (result1, result2)


def bcd2Decimal(char):
      """
      Given a char of a single byte of binary data, convert from BCD.

      BCD is binary coded decimal -- where you 'spell out' a decimal
      number using hex digits. Four bits --> one decimal digit.
      """
      bcd = ord(char)
      high = bcd / 16
      low = bcd % 16
      return high * 10 + low


class VersResource(object):
      """
      A parsed form of the raw vers resource data.

      A vers resource has the following format (see TechNote 1132
      <http://developer.apple.com/technotes/tn/tn1132.html>):

      type 'vers' {
            hex byte;                       /* Major revision in BCD*/
            hex byte;                       /* Minor revision in BCD*/
            hex byte    development = 0x20, /* Release stage        */
                              alpha = 0x40,
                              beta = 0x60,
                              final = 0x80, /* or */ release = 0x80;
            hex byte;                       /* Non-final release #  */
            integer;                        /* Region code          */
            pstring;                        /* Short version number */
            pstring;                        /* Long version number  */
      };
      """
      __slots__ = 'major', 'minor', 'stage', 'buildNum', 'regionCode', \
            'shortStr', 'longStr', 'raw'
      def __init__(self, rawData):
            self.major      = bcd2Decimal(rawData[0])
            self.minor      = bcd2Decimal(rawData[1])
            self.stage      = ord(rawData[2]) / 32 # final --> 4, beta -->
3, etc.
            self.buildNum   = ord(rawData[3]) # == 0 for released products
            self.regionCode = ord(rawData[4]) * 256 + ord(rawData[5])
            len1 = ord(rawData[6])
            self.shortStr   = rawData[7:7+len1]
            len2 = ord(rawData[7+len1])
            self.longStr    = rawData[8+len1:8+len1+len2]
            self.raw        = rawData
      def __eq__(self, other):
            return (self.raw == other.raw)
      def __str__(self):
            if self.stage == 1:
                  stage = 'd'
            elif self.stage == 2:
                  stage = 'a'
            elif self.stage == 3:
                  stage = 'b'
            else:
                  stage = ''
            if self.buildNum > 0:
                  build = str(self.buildNum)
            else:
                  build = ''
            return '%d.%d%s%s; %s; %s' % \
                  (self.major, self.minor, stage, build, self.shortStr,
self.longStr)


def getVersionResourceStrings(fPath):
      """
      Given a file path, return the parsed data for the pair of version
resources.

      For historical reasons, a Mac OS Classic file with version info will
      contain two version resources. Both resources have resource type
'vers'.
      One has an ID of 1 and the other has an ID of 2. Normally, the
contents of
      the two resources are identical up to the string data. In resource 1,
the
      string data contains the short and long versions as strings. (The
long
      string usually contains a copyright.) In resource 2, the string data
      contains information about the set that contains this file. Older
files may
      not contain the second resource. Some files may contain identical
resources.


<http://developer.apple.com/documentation/mac/Toolbox/Toolbox-454.html>

      The result is a pair (tuple) of strings or None if the file doesn't
contain
      the matching resource.

      Will throw exceptions if the file doesn't exist or doesn't contain a
resource
      fork.
      """
      data1, data2 = getVersionResourceData(fPath)
      if data1 is None:
            str1 = None
      else:
            v1 = VersResource(data1)
            str1 = str(v1)
      if data2 is None:
            str2 = None
      else:
            v2 = VersResource(data2)
            str2 = str(v2)
      return (str1, str2)


# Change Record
#
# $Log$

From brad.allen at omsdal.com  Fri Oct 22 23:34:55 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 22 23:35:51 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
Message-ID: <OF9201BB68.D8C69297-ON86256F35.0076801B-86256F35.00768D93@omsdal.com>

> > Bob Ippolito wrote:
> Done, and done.  http://python.org/sf/1052399


Cool! I will download the full version at
http://svn.red-bean.com/bob/plistlib/trunk/plistlib.py, add it to my module
package under a different name, and start putting it through a few paces.

From brad.allen at omsdal.com  Fri Oct 22 23:48:48 2004
From: brad.allen at omsdal.com (brad.allen@omsdal.com)
Date: Fri Oct 22 23:49:41 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <033B9B3C-23EE-11D9-9963-000A95BA5446@redivi.com>
Message-ID: <OF04AC502A.3360FA09-ON86256F35.00769932-86256F35.0077D2E9@omsdal.com>

It looks like there are some CFM apps where the 'plst' resource doesn't
agree with the 'vers' resource. In the case of Lotus Notes 6.5.1, the
developer must have failed to keep the data in the 'plst' resource current,
but it is current in the 'vers' resource. The 'plst' resource reports
version 6.0. (see below).


#this is a slightly edited version of Bob Ippolito's appVersion function
posted on the Pythonmac mailing list

from Carbon.File import FSRef, FSGetResourceForkName
from Carbon.Files import fsRdPerm
from Carbon.Res import FSOpenResourceFile, CloseResFile, UseResFile,
Get1Resource
from cStringIO import StringIO
import os, plistlibTest #this is a test version of plistlib by Bob Ippolito

def getInfoPlistForApp(app):
     if os.path.isdir(app):
         return plistlibTest.Plist.fromFile(os.path.join(app, 'Contents',
'Info.plist'))
     fsRef = FSRef(app)
     resId = FSOpenResourceFile(fsRef, FSGetResourceForkName(), fsRdPerm)
     UseResFile(resId)
     plistData = StringIO(Get1Resource('plst', 0).data)
     CloseResFile(resId)
     return plistlibTest.Plist.fromFile(plistData)

def getAppVersion(app):
     return getInfoPlistForApp(app)['CFBundleVersion']

if __name__ == '__main__':
      #for testing
      print 'Mach-O example:
Timbuktu',getAppVersion('/Applications/Timbuktu Pro/Timbuktu Pro.app')
      print '   Correct answer: 7.03'

      print 'CFM example: Lotus Notes',getAppVersion('/Users/ballen/Lotus
Notes/Notes')
      print '   Correct answer: 6.5.1'


#---------------output posted below------------------------

Mach-O example: Timbuktu 7.0.3
   Correct answer: 7.03
CFM example: Lotus Notes 6.0
   Correct answer: 6.5.1


From bob at redivi.com  Fri Oct 22 23:51:37 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 22 23:52:11 2004
Subject: [Pythonmac-SIG] obtaining versions of application bundles
In-Reply-To: <OF18F61750.626BFACA-ON86256F35.006FF107-86256F35.00719E0D@omsdal.com>
References: <OF18F61750.626BFACA-ON86256F35.006FF107-86256F35.00719E0D@omsdal.com>
Message-ID: <8C24C24E-2474-11D9-B689-000A95BA5446@redivi.com>


On Oct 22, 2004, at 16:40, brad.allen@omsdal.com wrote:

>
>> Yeah, Carbon is annoying.. It would look something like this:
>
>
> Well, I don't know if this will be useful to you, but I did get  
> permission
> to publicly post code from our project. Below is Walker's  
> VersionResource
> module. This approach reads from the 'vers' resource, not the 'plst'
> resource. The 'plst' resource is easier to parse, I guess. Can we  
> expect it
> to be present in every CFM app?

*Nearly* every CFM application that is natively compatible with OS X  
should have a 'plst' resource.  If the application doesn't have a  
'plst' resource, it would have to be extremely old and is probably  
barely compatible with OS X.

http://developer.apple.com/documentation/Carbon/Conceptual/ 
carbon_porting_guide/cpg_prepstruct/chapter_2_section_3.html

-bob

From joshua at rothbard.net  Sat Oct 23 03:24:08 2004
From: joshua at rothbard.net (Joshua Kifer)
Date: Sat Oct 23 06:17:56 2004
Subject: [Pythonmac-SIG] Re: [Pyobjc-dev] ANN: py2app / bdist_mpkg 0.1.5
	preview
In-Reply-To: <9BAA7798-231A-11D9-A940-000A95BA5446@redivi.com>
References: <9BAA7798-231A-11D9-A940-000A95BA5446@redivi.com>
Message-ID: <3CD35A49-2492-11D9-A4E4-00039398AC98@rothbard.net>

Bob,

I just switched over to using py2app -- and it's working great!  Now I 
can toss all that XCode garbage.

Joshua


On Oct 20, 2004, at 9:35 PM, Bob Ippolito wrote:

> I've put together a little preview of py2app 0.1.5, which has MAJOR 
> feature enhancements over 0.1.4.
> 	http://undefined.org/python/py2app-0.1.5.mpkg.zip (installer for Mac 
> OS X 10.3)
>
> 	http://svn.red-bean.com/bob/py2app/trunk (source repository)
> 	http://svn.red-bean.com/pyobjc/branches/py2app-branch/ (PyObjC 
> repository refactored to use py2app and bdist_mpkg)
>
> py2app:
> 	non-ascii application names works now (e.g. J?ger)
> 	support for non-framework builds of Python (e.g. darwinports)
> 	slightly more documentation (INSTALLING.txt, README.txt)
> 	PyPI information
> 	enhanced setup.py that can use bdist_mpkg
> 	builds and installs the py2applet tool as part of its bdist_mpkg 
> script (to /Developer/Applications/Python Tools/py2app/)
> 	installs the examples to /Developer/Python/py2app/Examples
>
> bdist_mpkg:
> 	It's new!  bdist_mpkg is a distutils command that builds a 
> metapackage for Installer.app (or /usr/sbin/installer).  It's part of 
> the py2app suite.
> 	It should work with ANY distutils-using Python module or application 
> that uses distutils and doesn't really screw up their "install" 
> command
> 	When using bdist_mpkg with a framework Python, it will default the 
> scripts installation dir to /usr/local/bin instead of the middle of 
> nowhere inside the Python framework
> 	It installs a script, /usr/local/bin/bdist_mpkg, which you can use to 
> build metapackages from any setup.py.  When the metapackage is built, 
> it will even open Installer for you (unless you pass it any --options, 
> or just --).  This is a great alternative to using python setup.py 
> install.  You can just customize and uncheck scripts, headers, etc. if 
> you don't want to install them.
> 	You can subclass bdist_mpkg and make it do crazy things, like install 
> documentation, code examples, or applications.  See py2app's 
> setup-lib/py2app_mpkg.py or PyObjC's setup-lib/pyobjc_mpkg.py (on the 
> py2app-branch)
> 	bdist_mpkg should become the "guts" of the next generation 
> PackageManager instead of bdist_dumb tarballs.
> 	will automatically determine if root permissions are required to 
> install the package (make sure you haven't mucked with your 
> permissions your build machine if you plan on distributing the 
> metapackages)
>
>
> After the dust settles a bit, probably this weekend, I'll do a more 
> official release... but I would like to get some feedback in the 
> meantime.
>
> -bob
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

From jschull at softlock.com  Sat Oct 23 03:26:53 2004
From: jschull at softlock.com (Jon Schull)
Date: Sat Oct 23 06:17:57 2004
Subject: [Pythonmac-SIG] Successful build of PyQt and Eric3 IDE
In-Reply-To: <20041022213549.E72271E4008@bag.python.org>
References: <20041022213549.E72271E4008@bag.python.org>
Message-ID: <9F098848-2492-11D9-BC60-0003939F0DC0@softlock.com>

speaking for myself, there is great interest in the Eric3 IDE and 
exploring PyQT !
--Jon Schull

From ronaldoussoren at mac.com  Sat Oct 23 08:31:46 2004
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sat Oct 23 08:33:11 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
Message-ID: <364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>


On 22-okt-04, at 10:45, Jack Jansen wrote:

>
> On 22-okt-04, at 1:26, has wrote:
>
>>> There's all sorts of issues with starting daemons (like: will the
>>> daemon be system-wide or per-user?
>>
>> It's a user-level process, so I guess that makes it per-user. Out of 
>> interest, does [Mac]Python run anything at any other level?
>
> No, what I meant was "if user Jack starts ATS, then user Has logs in 
> (either via the net or with fast user switching), will he use Jack's 
> ATS?". Because that could have security implications (such as allowing 
> access to terminology for apps to which Jack has access but Has not).
>
> But it turns out this is probably not a problem: as ATS uses OSA any 
> problem will exist with AppleScript without ATS too.

Depending on how ATS works there could be other problem: there is no 
reason to assume that user Jack started a real ATS. What if he started 
a modified version of ATS that returns garbage?

What happens when two users are logged on at the same time (Fast User 
Switching)?

I don't like a hidden daemon, especially when it accesses the network 
and can be accessed across the network.

What about writing the cache in ~/Library/Python/appscript.cache? Or 
why use a cache at all? I agree with Bob: if you want the extra 
performance you can explicitly create a cache module.

Ronald

From hengist.podd at virgin.net  Sat Oct 23 12:23:28 2004
From: hengist.podd at virgin.net (has)
Date: Sat Oct 23 12:24:35 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
Message-ID: <a05200f20bd9fd00dfffb@[81.101.66.68]>

Ronald Oussoren wrote:

>>>>There's all sorts of issues with starting daemons (like: will the
>>>>daemon be system-wide or per-user?
>>>
>>>It's a user-level process, so I guess that makes it per-user. Out 
>>>of interest, does [Mac]Python run anything at any other level?
>>
>>No, what I meant was "if user Jack starts ATS, then user Has logs 
>>in (either via the net or with fast user switching), will he use 
>>Jack's ATS?". Because that could have security implications (such 
>>as allowing access to terminology for apps to which Jack has access 
>>but Has not).
>>
>>But it turns out this is probably not a problem: as ATS uses OSA 
>>any problem will exist with AppleScript without ATS too.
>
>Depending on how ATS works there could be other problem: there is no 
>reason to assume that user Jack started a real ATS. What if he 
>started a modified version of ATS that returns garbage?

Then appscript will fail. But this would be true for any scriptable 
application. You can only use Remote Apple Events when both client 
and server can be completely trusted, otherwise it's a massive 
security hole.


>What happens when two users are logged on at the same time (Fast 
>User Switching)?

Don't know how FUS works, so hoping somebody else can tell me how 
application scripting, RAE, etc. work under it. It's a question that 
definitely needs answered.


>I don't like a hidden daemon, especially when it accesses the 
>network and can be accessed across the network.

ATS only operates across the network when an ATS client such as 
appscript asks it to, and provides it with IP address, username and 
password for the remote machine in question. And ATS can only be 
accessed from the network when the machine it's running on has RAE 
enabled and the other party has valid access permissions. It has no 
independent network access priviledges - it's merely a gopher for 
priviledged third parties.

Again, this is an issue that applies to _all_ scriptable 
applications. In remote scripting, ATS and other scriptable 
applications never open their own ports, they use a port that's been 
explicitly opened by the sysadmin with (one hopes!) full knowledge of 
the security implications of doing so. I suspect you're addressing 
your security concerns to ATS when they actually belong to RAE. With 
RAE there is no application-level security, only system-level. If a 
hostile party breaches your system-level RAE security, you're screwed 
regardless of whatever apps you're running.


Note: All these security questions are absolutely valid so please 
keep raising them, and it's essential that we bang out some 
convincing answers to them 'cos if folk here are asking them then 
sure as hell every future appscript user is going to ask them too. 
(BTW, I'm really quite peeved Apple doesn't have a decent discussion 
of RAE security issues prominently located on their site, especially 
when they like to rattle on about how much more secure MacOS X is 
compared to Windows, etc. I'll definitely mention this as well when I 
raise the concerns discussed here on AS-Implementors next week.)


>What about writing the cache in ~/Library/Python/appscript.cache?

Because nobody's yet managed to come up with a solution for a 
file-based cache that didn't require lots of manual maintenance work 
by the user, which completely defeats the point of something like 
appscript whose whole raison-d'etre is ease of use. :)


>Or why use a cache at all?

1. As a useful performance enhancer that gives us a fighting chance 
at matching AppleScript for application scripting speed.

2. As an essential source of terminology data for remote application 
scripting (as Apple's APIs do not currently support retrieving 
terminology from a remote machine).

ATS takes care of both tasks with a minimum of fuss and complexity 
and requires near-zero user interaction, which is why I'm currently 
preferring it to a file-based cache.


>I agree with Bob: if you want the extra performance you can 
>explicitly create a cache module.

Except this creates extra maintenance hassles for the user, and we're 
back to having inferior application scripting support compared to 
AppleScript. Which simply isn't good enough: either we kick 
AppleScript's butt or else we're just wasting our time, because 
nobody is going to use a second-rate technology. That's the problem 
we gotta solve, and it's a bit bigger than simply finding 'something 
that works'. But then, isn't that half the fun o' programming anyway? 
;)


Many thanks,

has


p.s. Here's an idea for an interesting side project if somebody was 
interested in pursuing it: an XML-RPC/Apple event bridge. (I read it 
off some Lisp guy's blog entries while googling for RAE info so can't 
claim originality, but they were dated 2003 so I guess he never 
pursued it himself.) Something that hooks a Python-based XML-RPC 
server to aem, allowing any language that speaks XML-RPC to control 
applications, and, unlike Remote Apple Events, is designed 
specifically for use in untrusted environments.

p.p.s. Another nifty-cool idea is a CGI frontend to iTunes; e.g. 
there's a guy sells an Apache ACGI extension for OS X, and this is 
one of the demo projects he includes. With Python's excellent (and 
free!) support for web programming and a copy of appscript, we could 
easily go one better.
-- 
http://freespace.virgin.net/hamish.sanderson/
From ronaldoussoren at mac.com  Sat Oct 23 14:10:31 2004
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sat Oct 23 14:11:48 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f20bd9fd00dfffb@[81.101.66.68]>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
	<a05200f20bd9fd00dfffb@[81.101.66.68]>
Message-ID: <89228549-24EC-11D9-AB1B-000A95C77748@mac.com>


On 23-okt-04, at 12:23, has wrote:

> Ronald Oussoren wrote:
>
>>>>> There's all sorts of issues with starting daemons (like: will the
>>>>> daemon be system-wide or per-user?
>>>>
>>>> It's a user-level process, so I guess that makes it per-user. Out 
>>>> of interest, does [Mac]Python run anything at any other level?
>>>
>>> No, what I meant was "if user Jack starts ATS, then user Has logs in 
>>> (either via the net or with fast user switching), will he use Jack's 
>>> ATS?". Because that could have security implications (such as 
>>> allowing access to terminology for apps to which Jack has access but 
>>> Has not).
>>>
>>> But it turns out this is probably not a problem: as ATS uses OSA any 
>>> problem will exist with AppleScript without ATS too.
>>
>> Depending on how ATS works there could be other problem: there is no 
>> reason to assume that user Jack started a real ATS. What if he 
>> started a modified version of ATS that returns garbage?
>
> Then appscript will fail. But this would be true for any scriptable 
> application. You can only use Remote Apple Events when both client and 
> server can be completely trusted, otherwise it's a massive security 
> hole.

Fail in what way? Could this be used to compromise another account? If 
you send pickles from ATS to the application a fake ATS could execute 
arbitrary code in the application.

>
>
>> What happens when two users are logged on at the same time (Fast User 
>> Switching)?
>
> Don't know how FUS works, so hoping somebody else can tell me how 
> application scripting, RAE, etc. work under it. It's a question that 
> definitely needs answered.

I'd hope that application scripting works in the context of one user 
session.

>
>
>> I don't like a hidden daemon, especially when it accesses the network 
>> and can be accessed across the network.
>
> ATS only operates across the network when an ATS client such as 
> appscript asks it to, and provides it with IP address, username and 
> password for the remote machine in question. And ATS can only be 
> accessed from the network when the machine it's running on has RAE 
> enabled and the other party has valid access permissions. It has no 
> independent network access priviledges - it's merely a gopher for 
> priviledged third parties.

Ah, I hadn't noticed that ATS is only accessed using OSA. I assumed 
that you communicated using some private protocol.
>
>> What about writing the cache in ~/Library/Python/appscript.cache?
>
> Because nobody's yet managed to come up with a solution for a 
> file-based cache that didn't require lots of manual maintenance work 
> by the user, which completely defeats the point of something like 
> appscript whose whole raison-d'etre is ease of use. :)

Most schemes that work for ATS should also work for a manual cache.

>
>
>> Or why use a cache at all?
>
> 1. As a useful performance enhancer that gives us a fighting chance at 
> matching AppleScript for application scripting speed.
>
> 2. As an essential source of terminology data for remote application 
> scripting (as Apple's APIs do not currently support retrieving 
> terminology from a remote machine).
>
> ATS takes care of both tasks with a minimum of fuss and complexity and 
> requires near-zero user interaction, which is why I'm currently 
> preferring it to a file-based cache.
>
>
>> I agree with Bob: if you want the extra performance you can 
>> explicitly create a cache module.
>
> Except this creates extra maintenance hassles for the user, and we're 
> back to having inferior application scripting support compared to 
> AppleScript. Which simply isn't good enough: either we kick 
> AppleScript's butt or else we're just wasting our time, because nobody 
> is going to use a second-rate technology. That's the problem we gotta 
> solve, and it's a bit bigger than simply finding 'something that 
> works'. But then, isn't that half the fun o' programming anyway? ;)

py2app (or a gui wrapper around it) could automaticly perform the 
maintenance hassles: You write a script that uses appscript, drop it on 
"Build Py2Applet" and this scans your script for calls to 
appscript.Application("iTunes.app") (or whatever the call is) and adds 
the relevant terminoligies(sp?) to the .app bundle.

>
>
> Many thanks,
>
> has
>
>
> p.s. Here's an idea for an interesting side project if somebody was 
> interested in pursuing it: an XML-RPC/Apple event bridge. (I read it 
> off some Lisp guy's blog entries while googling for RAE info so can't 
> claim originality, but they were dated 2003 so I guess he never 
> pursued it himself.) Something that hooks a Python-based XML-RPC 
> server to aem, allowing any language that speaks XML-RPC to control 
> applications, and, unlike Remote Apple Events, is designed 
> specifically for use in untrusted environments.

regarding "untrusted environments": only when you add explicit checks 
for security. If the server bridges to all of Apple events you wouldn't 
get a more secure solution.

Ronald

From cohar at conncoll.edu  Sat Oct 23 17:05:27 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Sat Oct 23 17:05:31 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
Message-ID: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>

In my bumbling search for an environment in which to write Python GUI  
apps (about two steps short of deserting to Java), I've been trying  
PythonCard. To use its debugging (etc) facilities, one has to use its  
framework (another layer! along with wxPython, my GUI framework). I  
worked through a tutorial app so as to see what a final executable  
might look like in terms of size. But py2app gives this traceback,  
which I'm too ignorant to make very much sense of:

   File "setup.py", line 23, in ?
     setup(
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/distutils/core.py", line 149, in setup
     dist.run_commands()
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/distutils/dist.py", line 907, in run_commands
     self.run_command(cmd)
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/distutils/dist.py", line 927, in run_command
     cmd_obj.run()
   File "/purelib/py2app/build_app.py", line 264, in run
   File "/purelib/py2app/build_app.py", line 315, in _run
   File "/purelib/py2app/recipes/PIL/__init__.py", line 41, in check
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/posixpath.py", line 119, in dirname
     return split(p)[0]
   File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/posixpath.py", line 77, in split
     i = p.rfind('/') + 1
AttributeError: 'NoneType' object has no attribute 'rfind'

Is this a simple problem, or a stumbling block? Any kind advice  
appreciated.

Charles Hartman

From bob at redivi.com  Sat Oct 23 17:48:53 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct 23 17:49:27 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
In-Reply-To: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
References: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
Message-ID: <0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>

This is sort of a bug in py2app.  You are using software that uses PIL,  
but you do not have PIL installed.  You'll need to install PIL or wait  
for the next release of PIL which will resolve this issue.

On Oct 23, 2004, at 11:05, Charles Hartman wrote:

> In my bumbling search for an environment in which to write Python GUI  
> apps (about two steps short of deserting to Java), I've been trying  
> PythonCard. To use its debugging (etc) facilities, one has to use its  
> framework (another layer! along with wxPython, my GUI framework). I  
> worked through a tutorial app so as to see what a final executable  
> might look like in terms of size. But py2app gives this traceback,  
> which I'm too ignorant to make very much sense of:
>
>   File "setup.py", line 23, in ?
>     setup(
>   File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/distutils/core.py", line 149, in setup
>     dist.run_commands()
>   File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/distutils/dist.py", line 907, in run_commands
>     self.run_command(cmd)
>   File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/distutils/dist.py", line 927, in run_command
>     cmd_obj.run()
>   File "/purelib/py2app/build_app.py", line 264, in run
>   File "/purelib/py2app/build_app.py", line 315, in _run
>   File "/purelib/py2app/recipes/PIL/__init__.py", line 41, in check
>   File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/posixpath.py", line 119, in dirname
>     return split(p)[0]
>   File  
> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/posixpath.py", line 77, in split
>     i = p.rfind('/') + 1
> AttributeError: 'NoneType' object has no attribute 'rfind'
>
> Is this a simple problem, or a stumbling block? Any kind advice  
> appreciated.
>
> Charles Hartman
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

From bob at redivi.com  Sat Oct 23 18:09:41 2004
From: bob at redivi.com (Bob Ippolito)
Date: Sat Oct 23 18:09:45 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
In-Reply-To: <0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>
References: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
	<0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>
Message-ID: <F28A3042-250D-11D9-A658-000A95BA5446@redivi.com>

er wait for the next release of py2app, not PIL.  sorry.

On Oct 23, 2004, at 11:48, Bob Ippolito wrote:

> This is sort of a bug in py2app.  You are using software that uses  
> PIL, but you do not have PIL installed.  You'll need to install PIL or  
> wait for the next release of PIL which will resolve this issue.
>
> On Oct 23, 2004, at 11:05, Charles Hartman wrote:
>
>> In my bumbling search for an environment in which to write Python GUI  
>> apps (about two steps short of deserting to Java), I've been trying  
>> PythonCard. To use its debugging (etc) facilities, one has to use its  
>> framework (another layer! along with wxPython, my GUI framework). I  
>> worked through a tutorial app so as to see what a final executable  
>> might look like in terms of size. But py2app gives this traceback,  
>> which I'm too ignorant to make very much sense of:
>>
>>   File "setup.py", line 23, in ?
>>     setup(
>>   File  
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/distutils/core.py", line 149, in setup
>>     dist.run_commands()
>>   File  
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/distutils/dist.py", line 907, in run_commands
>>     self.run_command(cmd)
>>   File  
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/distutils/dist.py", line 927, in run_command
>>     cmd_obj.run()
>>   File "/purelib/py2app/build_app.py", line 264, in run
>>   File "/purelib/py2app/build_app.py", line 315, in _run
>>   File "/purelib/py2app/recipes/PIL/__init__.py", line 41, in check
>>   File  
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/posixpath.py", line 119, in dirname
>>     return split(p)[0]
>>   File  
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/posixpath.py", line 77, in split
>>     i = p.rfind('/') + 1
>> AttributeError: 'NoneType' object has no attribute 'rfind'
>>
>> Is this a simple problem, or a stumbling block? Any kind advice  
>> appreciated.
>>
>> Charles Hartman
>>
>> _______________________________________________
>> 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

From sw at wordtech-software.com  Sat Oct 23 21:48:07 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Sat Oct 23 21:48:12 2004
Subject: [Pythonmac-SIG] PyQt-Mac project
Message-ID: <417AB577.2030003@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

I've gotten some good feedback on my build of PyQt and Eric3--it seems
like there's a fair amount of interest. Given this, I'd like to put
together a package for download somewhere. The bandwidth on my server is
too small for such a large download (it may top 100 megabytes), so I'd
like to put it at a more central location.

Sourceforge is an obvious place, but I'd also like to include the
MacPython add-ons in the bundle--just so everyone only has to do one
download. Jack, would you have a problem with my doing this, and then
putting everything at Sourceforge? Or should I just put up a link to the
MacPython download, as Robin Dunn does with wxPython?

Thanks for any advice.
- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBerV2JmdQs+6YVcoRAlgoAJ9pslHJQt2mzJnZ6qw6UtYm0kuiaQCeOGzd
J6cacQp0X2cmLUBnwveP4I0=
=5NKb
-----END PGP SIGNATURE-----
From zcorb at fluidarch.com  Sun Oct 24 05:35:35 2004
From: zcorb at fluidarch.com (Zachery Corbiere)
Date: Sun Oct 24 05:35:42 2004
Subject: [Pythonmac-SIG] Compiling Python 2.3.4 on OSX
Message-ID: <C4137072-256D-11D9-A495-000A95C729A2@fluidarch.com>

In trying to compile my own Python 2.3.4 on OSX (non-framework build) I 
failed with numerous errors around 'stat.h'.  I did the standard 
./configure...make routine, with my own custom prefix.

I hacked around it by commenting out the following lines in 
Mac/Include/pyconfig.h
/*
#ifndef USE_GUSI
#define DONT_HAVE_SYS_TYPES_H
#define DONT_HAVE_SYS_STAT_H
#define HAVE_STAT_H
#endif
*/

but that just feels wrong.  I looked in various READMEs and googled for 
the 'right thing to do' but got nowhere.

Is my environment subtly broken or is there some piece of information I 
completely blew past?

(By the way, I'm just playing around here - no particular reason for 
rebuilding Python other than that)

Thanks!
Zac

From Jack.Jansen at cwi.nl  Sun Oct 24 21:36:50 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sun Oct 24 21:36:53 2004
Subject: [Pythonmac-SIG] PyQt-Mac project
In-Reply-To: <417AB577.2030003@wordtech-software.com>
References: <417AB577.2030003@wordtech-software.com>
Message-ID: <0D484C7D-25F4-11D9-97D4-000D934FF6B4@cwi.nl>


On 23 Oct 2004, at 21:48, Kevin Walzer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everyone,
>
> I've gotten some good feedback on my build of PyQt and Eric3--it seems
> like there's a fair amount of interest. Given this, I'd like to put
> together a package for download somewhere. The bandwidth on my server 
> is
> too small for such a large download (it may top 100 megabytes), so I'd
> like to put it at a more central location.
>
> Sourceforge is an obvious place, but I'd also like to include the
> MacPython add-ons in the bundle--just so everyone only has to do one
> download. Jack, would you have a problem with my doing this, and then
> putting everything at Sourceforge? Or should I just put up a link to 
> the
> MacPython download, as Robin Dunn does with wxPython?

I have no problems with you including the MacPython additions, as long 
as (a) you make very clear which version it is (second build, 
currently) and (b) tell people where it came from, and where they 
should check for upgrades.

But personally I'm more interested in the reverse situation: I already 
have Python and the additions, including Package Manager, and I want to 
install PyQt (and possibly Eric3).

I'd like to make this accessible through the Package Manager, even if 
it is going to be a mostly-manual process (at least for PyQt, don't 
know about Eric3) as which wxPython. So an installer that only installs 
your PyQt build and another one that installs only Eric3 would be very 
welcome. And, of course, if either or both of these could be 
distutils-based I would be really happy;-)
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From Jack.Jansen at cwi.nl  Sun Oct 24 21:39:01 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sun Oct 24 21:39:04 2004
Subject: [Pythonmac-SIG] Compiling Python 2.3.4 on OSX
In-Reply-To: <C4137072-256D-11D9-A495-000A95C729A2@fluidarch.com>
References: <C4137072-256D-11D9-A495-000A95C729A2@fluidarch.com>
Message-ID: <5AF3FB60-25F4-11D9-97D4-000D934FF6B4@cwi.nl>


On 24 Oct 2004, at 05:35, Zachery Corbiere wrote:

> In trying to compile my own Python 2.3.4 on OSX (non-framework build) 
> I failed with numerous errors around 'stat.h'.  I did the standard 
> ./configure...make routine, with my own custom prefix.
>
> I hacked around it by commenting out the following lines in 
> Mac/Include/pyconfig.h
> /*
> #ifndef USE_GUSI
> #define DONT_HAVE_SYS_TYPES_H
> #define DONT_HAVE_SYS_STAT_H
> #define HAVE_STAT_H
> #endif
> */

Mac/Include/pyconfig.h is for MacPython-OS9, not for MacPython-OSX. I'm 
not sure why it has (erroneously) picked it up for you.

What is the exact configure invocation you used?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From sw at wordtech-software.com  Sun Oct 24 22:41:41 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Sun Oct 24 23:10:57 2004
Subject: [Pythonmac-SIG] PyQt-Mac project
In-Reply-To: <0D484C7D-25F4-11D9-97D4-000D934FF6B4@cwi.nl>
References: <417AB577.2030003@wordtech-software.com>
	<0D484C7D-25F4-11D9-97D4-000D934FF6B4@cwi.nl>
Message-ID: <417C1385.9010801@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jack Jansen wrote:


| I'd like to make this accessible through the Package Manager, even if it
| is going to be a mostly-manual process (at least for PyQt, don't know
| about Eric3) as which wxPython. So an installer that only installs your
| PyQt build and another one that installs only Eric3 would be very
| welcome. And, of course, if either or both of these could be
| distutils-based I would be really happy;-)
| --

I'm willing to give distutils a try--though I don't know how to use it
at present. I'll do some digging and hacking and follow up if I have
questions. Does wxPython make use of distutils, or just the Apple pkg
installer?

Another thing to keep in mind is that PyQt requires a full installation
of Qt and QScintilla to be useful. These could be included in Package
Manager, but that will add considerably to the download time. Is that a
problem? And can distutils handle Qt, or just the Python parts?



- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBfBOFJmdQs+6YVcoRAhkHAJ9qy1ORqMOjFuCAiUQ7Q2xAiMsh3wCfSWDK
LyXbepXT30AATIDLeDc6BhU=
=HjFB
-----END PGP SIGNATURE-----
From jerry.levan at eku.edu  Mon Oct 25 05:27:39 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Mon Oct 25 05:27:42 2004
Subject: [Pythonmac-SIG] Menu Question...
Message-ID: <D2E83048-2635-11D9-AC82-000393779D9C@eku.edu>

Hi,

I am try to wade through some menu stuff....I want to have
a menu with a check mark that toggles each time the menu
item is selected.

I can't seem to get the hang of it...

whatever = IntVar()
whatever.set(1)

def checkit():
	value= whatever.get()
	print "Value:", value	#whatever.set(0)
	
< some more code...>

helpmenu = Menu(menubar, tearoff=0)
helpmenu.add_checkbutton(label="About",
                command=checkit, onvalue=1,offvalue=0,
                accelerator='Command-A',
                variable=whatever)
menubar.add_cascade(label="Help", menu=helpmenu)
<more stuff>

When the program runs and the "help" menu is selected
the  "about" item shows a checkmark and the checkit
procedure displays zero.

Repeatedly selecting the about item always returns zero
and the check mark does not go away...

I have tried changing the check mark by using the
whatever.set() command but nothing seems to happen...

What am I missing?

Thanks

Jerry

From Jack.Jansen at cwi.nl  Mon Oct 25 10:34:33 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Mon Oct 25 10:34:16 2004
Subject: [Pythonmac-SIG] PyQt-Mac project
In-Reply-To: <417C1385.9010801@wordtech-software.com>
References: <417AB577.2030003@wordtech-software.com>
	<0D484C7D-25F4-11D9-97D4-000D934FF6B4@cwi.nl>
	<417C1385.9010801@wordtech-software.com>
Message-ID: <B299D5C3-2660-11D9-9BAE-000A958D1666@cwi.nl>


On 24-okt-04, at 22:41, Kevin Walzer wrote:

> | I'd like to make this accessible through the Package Manager, even 
> if it
> | is going to be a mostly-manual process (at least for PyQt, don't know
> | about Eric3) as which wxPython. So an installer that only installs 
> your
> | PyQt build and another one that installs only Eric3 would be very
> | welcome. And, of course, if either or both of these could be
> | distutils-based I would be really happy;-)
> | --
>
> I'm willing to give distutils a try--though I don't know how to use it
> at present. I'll do some digging and hacking and follow up if I have
> questions. Does wxPython make use of distutils, or just the Apple pkg
> installer?

Rebuilding the Qt and QScintilla installers with distutils is probably 
impossible, and definitely a lot of work, so I wouldn't try to tackle 
that if I were you. But PyQt may be a different matter, I don't know.

But Package Manager has some support for externally installed packages. 
For example, it knows about Tcl/Tk, and while it doesn't know how to 
install it it does know how to test whether it has been installed. And 
if it isn't installed it can point you to the website where you can 
find the installer and help you to run it (if applicable).

And because it knows whether tcl/tk is installed it can handle packages 
that depend on it, such as Idle: if you try to install Idle it will 
tell you that you first need to installl Tcl/Tk.

> Another thing to keep in mind is that PyQt requires a full installation
> of Qt and QScintilla to be useful. These could be included in Package
> Manager, but that will add considerably to the download time. Is that a
> problem? And can distutils handle Qt, or just the Python parts?

As to handling Qt and QScintilla: see above. As to download time: the 
intention is PackMan lowers this download time, because there'd be 4 
different things to download (Qt, QScintilla, PyQt, Eric3) and you'd 
only download those that you want. Moreover, you can decide on a 
per-package basis whether you want a source or binary install. I can 
imagine that someone would want to have source for eric3 but simply 
install the other three packages from binary distributions.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From cohar at conncoll.edu  Mon Oct 25 17:10:31 2004
From: cohar at conncoll.edu (Charles Hartman)
Date: Mon Oct 25 17:10:35 2004
Subject: [Pythonmac-SIG] the "special" menus
Message-ID: <02F6051C-2698-11D9-8939-000393A37396@conncoll.edu>

How can I get at (change, add things to) those "special" menus the 
system adds without my intervention? I mean the one that gets the app's 
name (which happens in a plist object, right?) and usually has an About 
box, and the Help menu at the right end. The wxMenu... series doesn't 
seem to have a place for this, so I assume there's an OS hook somewhere 
-- right? I haven't been able to find documentation on this in the wx 
world, though I imagine it's there.

From bob at redivi.com  Mon Oct 25 18:05:53 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct 25 18:06:28 2004
Subject: [Pythonmac-SIG] the "special" menus
In-Reply-To: <02F6051C-2698-11D9-8939-000393A37396@conncoll.edu>
References: <02F6051C-2698-11D9-8939-000393A37396@conncoll.edu>
Message-ID: <BF2C72C3-269F-11D9-959B-000A95BA5446@redivi.com>

On Oct 25, 2004, at 11:10, Charles Hartman wrote:

> How can I get at (change, add things to) those "special" menus the 
> system adds without my intervention? I mean the one that gets the 
> app's name (which happens in a plist object, right?) and usually has 
> an About box, and the Help menu at the right end. The wxMenu... series 
> doesn't seem to have a place for this, so I assume there's an OS hook 
> somewhere -- right? I haven't been able to find documentation on this 
> in the wx world, though I imagine it's there.

It's not in a plist, but can be in a nib.  I have no idea how to get to 
them through wxPython.

-bob

From jerry.levan at eku.edu  Mon Oct 25 18:35:05 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Mon Oct 25 18:35:10 2004
Subject: [Pythonmac-SIG] [Solved] Re: Menu Question...
In-Reply-To: <20040930100003.CF2021E400E@bag.python.org>
References: <20040930100003.CF2021E400E@bag.python.org>
Message-ID: <D3BC4C46-26A3-11D9-9D7E-000393779D9C@eku.edu>

I was having problems with "checkbutton" menuitems.
They would flip once and never again.

The problem was that I had specified an accelerator
key. ( Me trying to do too much with a small example...)

If not accelerator is specified then the behavior is
proper.

Jerry

From Chris.Barker at noaa.gov  Mon Oct 25 18:44:08 2004
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Mon Oct 25 18:45:09 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
In-Reply-To: <3F80CA93-26A3-11D9-959B-000A95BA5446@redivi.com>
References: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
	<0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>
	<417D2827.3010409@noaa.gov>
	<3F80CA93-26A3-11D9-959B-000A95BA5446@redivi.com>
Message-ID: <417D2D58.6070204@noaa.gov>

Bob Ippolito wrote:
> On Oct 25, 2004, at 12:21, Chris Barker wrote:
>> Bob Ippolito wrote:
>>> This is sort of a bug in py2app.  You are using software that uses 
>>> PIL,  but you do not have PIL installed.
>>
>> Huh? does py2app use PIL? why?
> 
> No.  His software uses PIL (indirectly via PythonCard, it seems), py2app 
> detected this and tried to include PIL, but PIL was not present.  svn 
> trunk has been changed such that now py2app only tries to use recipes 
> for packages that are actually present (a change to the recipes, not 
> anything in py2app's core).

Ah, I see. So this is really the same problem we can get with packages 
that conditionally import stuff. If you're not using it, Py2app doesn't 
know that. In fact, PIL is (or was, last I checked), whenever I've tried 
to Py2exe an app that uses PIL, I get all if tkinter too, even though I 
wasn't using it. It sounds like you're solving at least half the problem.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov
From bob at redivi.com  Mon Oct 25 19:16:46 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct 25 19:17:20 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
In-Reply-To: <417D2D58.6070204@noaa.gov>
References: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
	<0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>
	<417D2827.3010409@noaa.gov>
	<3F80CA93-26A3-11D9-959B-000A95BA5446@redivi.com>
	<417D2D58.6070204@noaa.gov>
Message-ID: <A63A9894-26A9-11D9-959B-000A95BA5446@redivi.com>


On Oct 25, 2004, at 12:44, Chris Barker wrote:

> Bob Ippolito wrote:
>> On Oct 25, 2004, at 12:21, Chris Barker wrote:
>>> Bob Ippolito wrote:
>>>> This is sort of a bug in py2app.  You are using software that uses 
>>>> PIL,  but you do not have PIL installed.
>>>
>>> Huh? does py2app use PIL? why?
>> No.  His software uses PIL (indirectly via PythonCard, it seems), 
>> py2app detected this and tried to include PIL, but PIL was not 
>> present.  svn trunk has been changed such that now py2app only tries 
>> to use recipes for packages that are actually present (a change to 
>> the recipes, not anything in py2app's core).
>
> Ah, I see. So this is really the same problem we can get with packages 
> that conditionally import stuff. If you're not using it, Py2app 
> doesn't know that. In fact, PIL is (or was, last I checked), whenever 
> I've tried to Py2exe an app that uses PIL, I get all if tkinter too, 
> even though I wasn't using it. It sounds like you're solving at least 
> half the problem.

If you py2exe an app that uses PIL you'll probably have an application 
that doesn't work.  One of the things that makes py2app more generally 
useful than py2exe is that it includes special exceptions, called 
recipes, that allow additional things to happen when certain packages 
are detected.  In cases like PIL or docutils, plugins need to be 
detected and added to the zip, or else they won't work.  py2app 
includes recipes that do these things.  Also, in PIL, it eliminates the 
implicit dependency on Tkinter (by means of FixTk), so if you don't use 
Tkinter elsewhere, then it won't be included.

py2app includes everything it sees, even if you don't think you're 
using it.  If you know you're not using a particular module or package, 
and you see that it is getting included anyway, then simply exclude it 
explicitly.  It's not very hard to do.  I would say that a whole lot 
more than half the problem is solved by py2app.

-bob

From altis at semi-retired.com  Mon Oct 25 19:52:03 2004
From: altis at semi-retired.com (Kevin Altis)
Date: Mon Oct 25 19:52:04 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
In-Reply-To: <A63A9894-26A9-11D9-959B-000A95BA5446@redivi.com>
References: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
	<0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>
	<417D2827.3010409@noaa.gov>
	<3F80CA93-26A3-11D9-959B-000A95BA5446@redivi.com>
	<417D2D58.6070204@noaa.gov>
	<A63A9894-26A9-11D9-959B-000A95BA5446@redivi.com>
Message-ID: <940BCEF2-26AE-11D9-B7A6-000A9598382A@semi-retired.com>

On Oct 25, 2004, at 10:16 AM, Bob Ippolito wrote:

>
> On Oct 25, 2004, at 12:44, Chris Barker wrote:
>
>> Bob Ippolito wrote:
>>> On Oct 25, 2004, at 12:21, Chris Barker wrote:
>>>> Bob Ippolito wrote:
>>>>> This is sort of a bug in py2app.  You are using software that uses 
>>>>> PIL,  but you do not have PIL installed.
>>>>
>>>> Huh? does py2app use PIL? why?
>>> No.  His software uses PIL (indirectly via PythonCard, it seems), 
>>> py2app detected this and tried to include PIL, but PIL was not 
>>> present.  svn trunk has been changed such that now py2app only tries 
>>> to use recipes for packages that are actually present (a change to 
>>> the recipes, not anything in py2app's core).
>>
>> Ah, I see. So this is really the same problem we can get with 
>> packages that conditionally import stuff. If you're not using it, 
>> Py2app doesn't know that. In fact, PIL is (or was, last I checked), 
>> whenever I've tried to Py2exe an app that uses PIL, I get all if 
>> tkinter too, even though I wasn't using it. It sounds like you're 
>> solving at least half the problem.
>
> If you py2exe an app that uses PIL you'll probably have an application 
> that doesn't work.  One of the things that makes py2app more generally 
> useful than py2exe is that it includes special exceptions, called 
> recipes, that allow additional things to happen when certain packages 
> are detected.  In cases like PIL or docutils, plugins need to be 
> detected and added to the zip, or else they won't work.  py2app 
> includes recipes that do these things.  Also, in PIL, it eliminates 
> the implicit dependency on Tkinter (by means of FixTk), so if you 
> don't use Tkinter elsewhere, then it won't be included.
>
> py2app includes everything it sees, even if you don't think you're 
> using it.  If you know you're not using a particular module or 
> package, and you see that it is getting included anyway, then simply 
> exclude it explicitly.  It's not very hard to do.  I would say that a 
> whole lot more than half the problem is solved by py2app.
>

Sorry, I'm late to the the party. I was at the Seattle coding sprint 
last weekend and I'm just now catching up on email. I haven't tried 
py2app yet as last week I was wrapping up the PythonCard 0.8.1 release. 
There are bundlebuilder scripts for a variety of samples and tools:

     PythonCard/samples/minimalStandalone/macbuild.py
     PythonCard/tools/codeEditor/macbuild.py
     PythonCard/tools/findfiles/macbuild.py

I'm hoping to convert them to py2app, though I have no idea what is 
involved yet.

Both PythonCard/graphic.py and PythonCard/components/bitmapcanvas.py 
have conditional imports for PIL, and bitmapcanvas.py has one for 
Numeric as well.

try:
     import Image
     # necessary to avoid name collision with Image class
     from Image import fromstring
     PIL_FOUND = True
except ImportError:
     PIL_FOUND = False

try:
     from Numeric import ArrayType
     NUMERIC_FOUND = True
except ImportError:
     NUMERIC_FOUND = False

In the short term, you could just comment out the imports and force the 
FOUND constants to False and that will avoid the conditional import. 
The readme.txt gives the py2exe option to exclude libraries you don't 
want included in your standalone.

"""
Use the following command-line to build the minimal.exe file.
    python setup.py py2exe --excludes=Image
"""

I don't know if py2app has something similar, but it would be nice for 
the apps that know they aren't using particular libraries like PIL 
which are imported optionally. The reason the imports are there in the 
first place, is that PythonCard supports drawing and converting PIL and 
Numeric arrays.

ka

From bob at redivi.com  Mon Oct 25 20:00:12 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct 25 20:00:47 2004
Subject: [Pythonmac-SIG] py2app and PythonCard
In-Reply-To: <940BCEF2-26AE-11D9-B7A6-000A9598382A@semi-retired.com>
References: <F8E8E535-2504-11D9-AEAD-000393A37396@conncoll.edu>
	<0A7E5258-250B-11D9-A658-000A95BA5446@redivi.com>
	<417D2827.3010409@noaa.gov>
	<3F80CA93-26A3-11D9-959B-000A95BA5446@redivi.com>
	<417D2D58.6070204@noaa.gov>
	<A63A9894-26A9-11D9-959B-000A95BA5446@redivi.com>
	<940BCEF2-26AE-11D9-B7A6-000A9598382A@semi-retired.com>
Message-ID: <B75B69D1-26AF-11D9-959B-000A95BA5446@redivi.com>


On Oct 25, 2004, at 13:52, Kevin Altis wrote:

> On Oct 25, 2004, at 10:16 AM, Bob Ippolito wrote:
>
>>
>> On Oct 25, 2004, at 12:44, Chris Barker wrote:
>>
>>> Bob Ippolito wrote:
>>>> On Oct 25, 2004, at 12:21, Chris Barker wrote:
>>>>> Bob Ippolito wrote:
>>>>>> This is sort of a bug in py2app.  You are using software that 
>>>>>> uses PIL,  but you do not have PIL installed.
>>>>>
>>>>> Huh? does py2app use PIL? why?
>>>> No.  His software uses PIL (indirectly via PythonCard, it seems), 
>>>> py2app detected this and tried to include PIL, but PIL was not 
>>>> present.  svn trunk has been changed such that now py2app only 
>>>> tries to use recipes for packages that are actually present (a 
>>>> change to the recipes, not anything in py2app's core).
>>>
>>> Ah, I see. So this is really the same problem we can get with 
>>> packages that conditionally import stuff. If you're not using it, 
>>> Py2app doesn't know that. In fact, PIL is (or was, last I checked), 
>>> whenever I've tried to Py2exe an app that uses PIL, I get all if 
>>> tkinter too, even though I wasn't using it. It sounds like you're 
>>> solving at least half the problem.
>>
>> If you py2exe an app that uses PIL you'll probably have an 
>> application that doesn't work.  One of the things that makes py2app 
>> more generally useful than py2exe is that it includes special 
>> exceptions, called recipes, that allow additional things to happen 
>> when certain packages are detected.  In cases like PIL or docutils, 
>> plugins need to be detected and added to the zip, or else they won't 
>> work.  py2app includes recipes that do these things.  Also, in PIL, 
>> it eliminates the implicit dependency on Tkinter (by means of FixTk), 
>> so if you don't use Tkinter elsewhere, then it won't be included.
>>
>> py2app includes everything it sees, even if you don't think you're 
>> using it.  If you know you're not using a particular module or 
>> package, and you see that it is getting included anyway, then simply 
>> exclude it explicitly.  It's not very hard to do.  I would say that a 
>> whole lot more than half the problem is solved by py2app.
>>
>
> Sorry, I'm late to the the party. I was at the Seattle coding sprint 
> last weekend and I'm just now catching up on email. I haven't tried 
> py2app yet as last week I was wrapping up the PythonCard 0.8.1 
> release. There are bundlebuilder scripts for a variety of samples and 
> tools:
>
>     PythonCard/samples/minimalStandalone/macbuild.py
>     PythonCard/tools/codeEditor/macbuild.py
>     PythonCard/tools/findfiles/macbuild.py
>
> I'm hoping to convert them to py2app, though I have no idea what is 
> involved yet.

Very likely you can just take your py2exe scripts and change 
windows=[...] to app=[...] and py2exe to py2app.. you may also be able 
to remove some cruft.  The scripts will certainly be a lot shorter than 
the bundlebuilder versions.  If you run into any issues, let me know on 
or off list and I'll help you.

> Both PythonCard/graphic.py and PythonCard/components/bitmapcanvas.py 
> have conditional imports for PIL, and bitmapcanvas.py has one for 
> Numeric as well.

<conditional import example>

> In the short term, you could just comment out the imports and force 
> the FOUND constants to False and that will avoid the conditional 
> import. The readme.txt gives the py2exe option to exclude libraries 
> you don't want included in your standalone.
>
> """
> Use the following command-line to build the minimal.exe file.
>    python setup.py py2exe --excludes=Image
> """
>
> I don't know if py2app has something similar, but it would be nice for 
> the apps that know they aren't using particular libraries like PIL 
> which are imported optionally. The reason the imports are there in the 
> first place, is that PythonCard supports drawing and converting PIL 
> and Numeric arrays.

py2app supports identical syntax for the excludes hook... though it may 
not work for PIL with py2app 0.1.4 due to the bug in the recipe.  SVN 
trunk (or 0.2.0, when I release it) should work fine.

-bob

From jerry.levan at eku.edu  Mon Oct 25 23:09:47 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Mon Oct 25 23:09:54 2004
Subject: [Pythonmac-SIG] Starting Up Front.
In-Reply-To: <20041014100037.4BBC71E4004@bag.python.org>
References: <20041014100037.4BBC71E4004@bag.python.org>
Message-ID: <33B859C6-26CA-11D9-9D7E-000393779D9C@eku.edu>

Hi,

I am using Aqua Tcl/Tk BI distribution ( most recent). The
Aqua version does not naturally start with the application
being brought to the front. In Tk I can do any of:

# any of the following three "includes" will work with aqua
# to insure that the wish window is frontmost.

#package require tclAE
#tclAE::send -s misc actv

catch {
package require Tclapplescript
AppleScript execute {tell me to activate}
}

#exec osascript \
#      -e "tell app \"Finder\" to set frontmost of process \"Wish 
Shell\" to true"

How can I do any/all of the above in Python?

Thanks,

Jerry

From jerry.levan at eku.edu  Mon Oct 25 23:22:00 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Mon Oct 25 23:22:03 2004
Subject: [Pythonmac-SIG] Targeting Object Instances from a menu?
In-Reply-To: <20041014100037.4BBC71E4004@bag.python.org>
References: <20041014100037.4BBC71E4004@bag.python.org>
Message-ID: <E86A8876-26CB-11D9-9D7E-000393779D9C@eku.edu>

Hi,

As a learning project I am creating a class PGBrowser. Creating
an instance of a PGBrowser will bring up a gui with an editor,
status area and a table area connected to a user specified
Postgresql database.

The basic functionality is in place, I can connect to my postgresql
databases and execute sql commands against the database and
get the results displayed nicely in the table area.

I am getting ready to add "enhancements" via a menu and it just
occurred to me that if I have more than one instance of a PGBrowser,
how can I target the appropriate one.

"Regular" mac applications target the "First Responder" chain, in
this case it is generally the frontmost window...

So if I have two browser instances, can I identify the "frontmost"?

If this  is not possible, then it appears that I might have to use
a row of button menus set in each browser window... not a very
mac like solution.

Any suggestions?

Thanks

Jerry

From bob at redivi.com  Mon Oct 25 23:30:59 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct 25 23:31:36 2004
Subject: [Pythonmac-SIG] Starting Up Front.
In-Reply-To: <33B859C6-26CA-11D9-9D7E-000393779D9C@eku.edu>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<33B859C6-26CA-11D9-9D7E-000393779D9C@eku.edu>
Message-ID: <29B23C29-26CD-11D9-959B-000A95BA5446@redivi.com>

On Oct 25, 2004, at 17:09, Jerry LeVan wrote:

> I am using Aqua Tcl/Tk BI distribution ( most recent). The
> Aqua version does not naturally start with the application
> being brought to the front. In Tk I can do any of:
>
> # any of the following three "includes" will work with aqua
> # to insure that the wish window is frontmost.
>
> #package require tclAE
> #tclAE::send -s misc actv
>
> catch {
> package require Tclapplescript
> AppleScript execute {tell me to activate}
> }
>
> #exec osascript \
> #      -e "tell app \"Finder\" to set frontmost of process \"Wish 
> Shell\" to true"
>
> How can I do any/all of the above in Python?

The first one would be this (call activate):

from Carbon import AE, AppleEvents

def currentProcessDesc():
     kCurrentProcess = '\x00\x00\x00\x00\x00\x00\x00\x02'
     return AE.AECreateDesc(
         AppleEvents.typeProcessSerialNumber,
         kCurrentProcess)

def activateDesc():
     return AE.AECreateAppleEvent(
         AppleEvents.kAEMiscStandards,
         AppleEvents.kAEActivate,
         currentProcessDesc(),
         AppleEvents.kAutoGenerateReturnID,
         AppleEvents.kAnyTransactionID)

def activate():
     return activateDesc().AESend(
         AppleEvents.kAEWaitReply,
         AppleEvents.kAENormalPriority,
         AppleEvents.kAEDefaultTimeout)


Are you sure that bundled applications don't start in front?

-bob

From bob at redivi.com  Mon Oct 25 23:32:55 2004
From: bob at redivi.com (Bob Ippolito)
Date: Mon Oct 25 23:33:30 2004
Subject: [Pythonmac-SIG] Targeting Object Instances from a menu?
In-Reply-To: <E86A8876-26CB-11D9-9D7E-000393779D9C@eku.edu>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<E86A8876-26CB-11D9-9D7E-000393779D9C@eku.edu>
Message-ID: <6EDF328A-26CD-11D9-959B-000A95BA5446@redivi.com>

On Oct 25, 2004, at 17:22, Jerry LeVan wrote:

> As a learning project I am creating a class PGBrowser. Creating
> an instance of a PGBrowser will bring up a gui with an editor,
> status area and a table area connected to a user specified
> Postgresql database.
>
> The basic functionality is in place, I can connect to my postgresql
> databases and execute sql commands against the database and
> get the results displayed nicely in the table area.
>
> I am getting ready to add "enhancements" via a menu and it just
> occurred to me that if I have more than one instance of a PGBrowser,
> how can I target the appropriate one.
>
> "Regular" mac applications target the "First Responder" chain, in
> this case it is generally the frontmost window...
>
> So if I have two browser instances, can I identify the "frontmost"?
>
> If this  is not possible, then it appears that I might have to use
> a row of button menus set in each browser window... not a very
> mac like solution.
>
> Any suggestions?

This is totally different depending on which GUI framework you are 
using.  You didn't bother to mention that :)

-bob

From jerry.levan at eku.edu  Tue Oct 26 00:22:44 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Tue Oct 26 00:22:48 2004
Subject: [Pythonmac-SIG] Targeting Object Instances from a menu?
In-Reply-To: <6EDF328A-26CD-11D9-959B-000A95BA5446@redivi.com>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<E86A8876-26CB-11D9-9D7E-000393779D9C@eku.edu>
	<6EDF328A-26CD-11D9-959B-000A95BA5446@redivi.com>
Message-ID: <64716521-26D4-11D9-9D7E-000393779D9C@eku.edu>

Tkinter based on Aqua Tcl/Tk BI, sorry about that :)

Jerry

On Oct 25, 2004, at 5:32 PM, Bob Ippolito wrote:

> On Oct 25, 2004, at 17:22, Jerry LeVan wrote:
>
>> As a learning project I am creating a class PGBrowser. Creating
>> an instance of a PGBrowser will bring up a gui with an editor,
>> status area and a table area connected to a user specified
>> Postgresql database.
>>
>> The basic functionality is in place, I can connect to my postgresql
>> databases and execute sql commands against the database and
>> get the results displayed nicely in the table area.
>>
>> I am getting ready to add "enhancements" via a menu and it just
>> occurred to me that if I have more than one instance of a PGBrowser,
>> how can I target the appropriate one.
>>
>> "Regular" mac applications target the "First Responder" chain, in
>> this case it is generally the frontmost window...
>>
>> So if I have two browser instances, can I identify the "frontmost"?
>>
>> If this  is not possible, then it appears that I might have to use
>> a row of button menus set in each browser window... not a very
>> mac like solution.
>>
>> Any suggestions?
>
> This is totally different depending on which GUI framework you are 
> using.  You didn't bother to mention that :)
>
> -bob
>

From bob at redivi.com  Tue Oct 26 00:44:56 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 26 00:45:38 2004
Subject: [Pythonmac-SIG] Targeting Object Instances from a menu?
In-Reply-To: <64716521-26D4-11D9-9D7E-000393779D9C@eku.edu>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<E86A8876-26CB-11D9-9D7E-000393779D9C@eku.edu>
	<6EDF328A-26CD-11D9-959B-000A95BA5446@redivi.com>
	<64716521-26D4-11D9-9D7E-000393779D9C@eku.edu>
Message-ID: <7E73BD96-26D7-11D9-959B-000A95BA5446@redivi.com>


On Oct 25, 2004, at 18:22, Jerry LeVan wrote:

> On Oct 25, 2004, at 5:32 PM, Bob Ippolito wrote:
>
>> On Oct 25, 2004, at 17:22, Jerry LeVan wrote:
>>
>>> As a learning project I am creating a class PGBrowser. Creating
>>> an instance of a PGBrowser will bring up a gui with an editor,
>>> status area and a table area connected to a user specified
>>> Postgresql database.
>>>
>>> The basic functionality is in place, I can connect to my postgresql
>>> databases and execute sql commands against the database and
>>> get the results displayed nicely in the table area.
>>>
>>> I am getting ready to add "enhancements" via a menu and it just
>>> occurred to me that if I have more than one instance of a PGBrowser,
>>> how can I target the appropriate one.
>>>
>>> "Regular" mac applications target the "First Responder" chain, in
>>> this case it is generally the frontmost window...
>>>
>>> So if I have two browser instances, can I identify the "frontmost"?
>>>
>>> If this  is not possible, then it appears that I might have to use
>>> a row of button menus set in each browser window... not a very
>>> mac like solution.
>>>
>>> Any suggestions?
>>
>> This is totally different depending on which GUI framework you are 
>> using.  You didn't bother to mention that :)
>>
> Tkinter based on Aqua Tcl/Tk BI, sorry about that :)

Well, however you find out what the front window is in Tk.  I have no 
idea, I avoid Tk, it doesn't look very good on the Mac.

I find that PyObjC requires a whole lot less code, especially for 
something like this where you could use NSTableView, etc.  These sorts 
of issues are handled in a sane way with Cocoa because it was designed 
for the GUI you're using.  The responder chain is a native concept in 
Cocoa.

-bob

From hengist.podd at virgin.net  Tue Oct 26 00:27:36 2004
From: hengist.podd at virgin.net (has)
Date: Tue Oct 26 01:00:46 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <89228549-24EC-11D9-AB1B-000A95C77748@mac.com>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
	<a05200f20bd9fd00dfffb@[81.101.66.68]>
	<89228549-24EC-11D9-AB1B-000A95C77748@mac.com>
Message-ID: <a05200f24bda050718798@[81.101.66.68]>

Ronald Oussoren wrote:

>>>Depending on how ATS works there could be other problem: there is 
>>>no reason to assume that user Jack started a real ATS. What if he 
>>>started a modified version of ATS that returns garbage?
>>
>>Then appscript will fail. But this would be true for any scriptable 
>>application. You can only use Remote Apple Events when both client 
>>and server can be completely trusted, otherwise it's a massive 
>>security hole.
>
>Fail in what way?

ATS returns a list containing five code-name translation tables in 
string format which the appscript.terminology module then parses into 
dicts for consumption by appscript.specifier. If appscript received 
anything else, the parser would choke. You can see these tables for 
yourself by running the following AppleScript:

tell application "AppscriptTerminologyServer" to ?event ATSrTerm? 
"/Applications/TextEdit.app"


>>>What happens when two users are logged on at the same time (Fast 
>>>User Switching)?
>>
>>Don't know how FUS works, so hoping somebody else can tell me how 
>>application scripting, RAE, etc. work under it. It's a question 
>>that definitely needs answered.
>
>I'd hope that application scripting works in the context of one user session.

I've not turned up any info so far, but will try to find out.


>>>I don't like a hidden daemon, especially when it accesses the 
>>>network and can be accessed across the network.
>>
>>ATS [...] has no independent network access priviledges - it's 
>>merely a gopher for priviledged third parties.
>
>Ah, I hadn't noticed that ATS is only accessed using OSA.

Well, Apple events [1]. It's just a simple bundlebuilder-based app 
built using MiniApplication and aem.receive. Sorry if I wasn't more 
clear about this - I'll add an explanation of how ATS works to the 
documentation (soon as I get around to writing it).


>  I assumed that you communicated using some private protocol.

Oh, I'm far to dim and lazy to invent anything like that. ;)


>Most schemes that work for ATS should also work for a manual cache.

Sure, but the problem isn't whether the cache is file-based or 
in-memory; it's how much work the user has to do to maintain it. The 
objective is to have a system that provides appscript with 
application terminologies for both local and remote applications 
while requiring the least possible amount of user interaction and, 
ideally, providing the best possible performance. ATS does pretty 
well on both counts;


>>Except this creates extra maintenance hassles for the user, and 
>>we're back to having inferior application scripting support 
>>compared to AppleScript.
>
>py2app (or a gui wrapper around it) could automaticly perform the 
>maintenance hassles: You write a script that uses appscript, drop it 
>on "Build Py2Applet" and this scans your script for calls to 
>appscript.Application("iTunes.app")

That's almost exactly what the AppleScript compiler does when it 
looks for 'tell application "Some App"' blocks in source code to work 
out what keywords to use while parsing that block. It's a really 
smelly hack and a regular pain (e.g. it can't cope with stuff like 
'tell application nameStr' and 'tell applicationObj').

Also, we need something that works equally well in all situations, 
not just for py2app-based applications. A lot of AppleScripting is 
just quick, small, throwaway scripts, or typing and executing 
commands in an interactive text window/console if you're using Smile 
[2] or SD.

Using compile-time kludges to what's clearly a runtime problem is one 
of the things that's really wrong with how AppleScript implements its 
application scripting support. It's one of the things I specifically 
set out to avoid with appscript, so no chance I'd support it I'm 
afraid. :/


>>p.s. Here's an idea for an interesting side project if somebody was 
>>interested in pursuing it: an XML-RPC/Apple event bridge [...] that 
>>hooks a Python-based XML-RPC server to aem, allowing any language 
>>that speaks XML-RPC to control applications, and, unlike Remote 
>>Apple Events, is designed specifically for use in untrusted 
>>environments.
>
>regarding "untrusted environments": only when you add explicit 
>checks for security. If the server bridges to all of Apple events 
>you wouldn't get a more secure solution.

Yes. I suspect designing the permissions system will be rather more 
work than implementing the bridge itself.:) Perhaps a system that 
allows you to explicitly declare which applications you wish to 
expose and which commands and classes should be accessible? I dunno, 
but it's a tasty challenge for anyone that fancies taking it on.

Cheers,

has


[1] The term OSA refers either to a specific API used to build 
pluggable language components or an umbrella term for 
scripting-related APIs, which kinda includes AEM although it has 
other uses too. (Blame Apple for any confusion this causes.) Only 
thing appscript/ATS uses the OSA API for is the OSAGetAppTerminology 
function, which is kinda out of place even there.

[2] Incidentally, I really wish Python had something equivalent to 
Smile's text windows: a really nice implementation, perhaps as a mode 
on regular script windows, could pummel the older CLI-oriented 
interpreters into the ground, imnsho. Maybe something Glenn might 
like to look at?
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Tue Oct 26 01:06:32 2004
From: hengist.podd at virgin.net (has)
Date: Tue Oct 26 01:06:40 2004
Subject: [Pythonmac-SIG] Starting Up Front.
In-Reply-To: <33B859C6-26CA-11D9-9D7E-000393779D9C@eku.edu>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<33B859C6-26CA-11D9-9D7E-000393779D9C@eku.edu>
Message-ID: <a05200f2ebda33699a09c@[81.101.66.68]>

Jerry LeVan wrote:

>I am using Aqua Tcl/Tk BI distribution ( most recent). The
>Aqua version does not naturally start with the application
>being brought to the front. In Tk I can do any of:
>
># any of the following three "includes" will work with aqua
># to insure that the wish window is frontmost.
>
>#package require tclAE
>#tclAE::send -s misc actv

To bring the Wish application to the front:

#!/usr/local/bin/pythonw
from appscript import *
app('Wish Shell.app').activate()

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From jerry.levan at eku.edu  Tue Oct 26 01:10:31 2004
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Tue Oct 26 01:10:34 2004
Subject: [Pythonmac-SIG] Targeting Object Instances from a menu?
In-Reply-To: <7E73BD96-26D7-11D9-959B-000A95BA5446@redivi.com>
References: <20041014100037.4BBC71E4004@bag.python.org>
	<E86A8876-26CB-11D9-9D7E-000393779D9C@eku.edu>
	<6EDF328A-26CD-11D9-959B-000A95BA5446@redivi.com>
	<64716521-26D4-11D9-9D7E-000393779D9C@eku.edu>
	<7E73BD96-26D7-11D9-959B-000A95BA5446@redivi.com>
Message-ID: <114DA4FF-26DB-11D9-9D7E-000393779D9C@eku.edu>


On Oct 25, 2004, at 6:44 PM, Bob Ippolito wrote:

>>>
>>> This is totally different depending on which GUI framework you are 
>>> using.  You didn't bother to mention that :)
>>>
>> Tkinter based on Aqua Tcl/Tk BI, sorry about that :)
>
> Well, however you find out what the front window is in Tk.  I have no 
> idea, I avoid Tk, it doesn't look very good on the Mac.

I have found that Aqua Tk is getting better. With a little tweaking 
with color, font selection, and
padx/y directives one can generate very nice looking interfaces that 
are almost indistinguishable
from Carbon apps ( not surprisingly ...).

>
> I find that PyObjC requires a whole lot less code, especially for 
> something like this where you could use NSTableView, etc.  These sorts 
> of issues are handled in a sane way with Cocoa because it was designed 
> for the GUI you're using.  The responder chain is a native concept in 
> Cocoa.
>

PyObjC is on the "To Do" list. Actually I rather like the TkTable 
module, I think it is at least
as flexible as NSTableView, tain't clear to me why it is not in the 
standard Python distribution
of Tkinter. I have used it in Perl/Tk, Tcl/Tk and Python/Tkinter to 
good advantage.

> -bob
>
>
Jerry

From bob at redivi.com  Tue Oct 26 01:20:54 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 26 01:21:29 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f24bda050718798@[81.101.66.68]>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
	<a05200f20bd9fd00dfffb@[81.101.66.68]>
	<89228549-24EC-11D9-AB1B-000A95C77748@mac.com>
	<a05200f24bda050718798@[81.101.66.68]>
Message-ID: <84D1D556-26DC-11D9-959B-000A95BA5446@redivi.com>


On Oct 25, 2004, at 18:27, has wrote:

> Also, we need something that works equally well in all situations,
> not just for py2app-based applications. A lot of AppleScripting is
> just quick, small, throwaway scripts, or typing and executing
> commands in an interactive text window/console if you're using Smile
> [2] or SD.
---
> [2] Incidentally, I really wish Python had something equivalent to
> Smile's text windows: a really nice implementation, perhaps as a mode
> on regular script windows, could pummel the older CLI-oriented
> interpreters into the ground, imnsho. Maybe something Glenn might
> like to look at?

It would help if you mentioned where to get Smile or a bit more about 
what it is.  It's not exactly a good name for googling.

-bob

From hengist.podd at virgin.net  Tue Oct 26 03:26:42 2004
From: hengist.podd at virgin.net (has)
Date: Tue Oct 26 03:27:51 2004
Subject: [Pythonmac-SIG] Re: Smile (appscript terminology caching #2)
In-Reply-To: <84D1D556-26DC-11D9-959B-000A95BA5446@redivi.com>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
	<a05200f20bd9fd00dfffb@[81.101.66.68]>
	<89228549-24EC-11D9-AB1B-000A95C77748@mac.com>
	<a05200f24bda050718798@[81.101.66.68]>
	<84D1D556-26DC-11D9-959B-000A95BA5446@redivi.com>
Message-ID: <a05200f2fbda34c11a8ba@[81.101.66.68]>

Bob wrote:

>>[2] Incidentally, I really wish Python had something equivalent to
>>Smile's text windows: a really nice implementation, perhaps as a mode
>>on regular script windows, could pummel the older CLI-oriented
>>interpreters into the ground, imnsho. Maybe something Glenn might
>>like to look at?
>
>It would help if you mentioned where to get Smile or a bit more 
>about what it is.

Oops. Forget. :)

http://www.satimage.fr/software/en/index.html

Nominally an AppleScript editor but a highly customisable base 
(Satimage build CAD/CAM solutions). Smile is the free version, but 
they also sell a commercial version, SmileLab, with a bunch of extra 
data analysis and visualisation tools. Once you get past the initial 
quirkiness it's probably the best demonstration of the [mostly 
untapped] potential of OSA I'm aware of: while the application's core 
is C/C++(?), large chunks of it are written in AppleScript, all 
completely hackable, and all tied together via AEM and OSA. I only 
wish many more applications were built like this.

Smile text windows allow source to be entered, selected and executed 
in a persistent context at any time; much less linear than Python's 
interactive interpreter and making proper use of  windows' GUI nature 
(find, styles, drag-n-drop, standard keyboard navigation, etc.). 
Reminiscent of PythonIDE's 'Run selection' option, but more 
interpreter-like; less formal and more flexible in what can be 
selected and executed and where results are output to (end of same 
window, console, some other window) and the window itself is, of 
course, scriptable. Windows can be set to delegate commands to other 
applications and can directly call handlers built into Smile, you can 
select an application keyword and pull up its definition, (albeit 
with varying degrees of success). Windows can have scripts attached 
to them, and the OS 9 version also allowed you to attach buttons, 
themselves with scripts attached, to the window toolbar for further 
customisation. Good bang for very little buck and minimal learning 
curve, since it's basically just a standard text editor. Several nice 
ideas, and plenty potential to come up with something better. Closest 
comparison I can think of is to text windows in Squeak.

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From terry at bizarsoftware.com.au  Tue Oct 26 09:19:28 2004
From: terry at bizarsoftware.com.au (Terry Kerr)
Date: Tue Oct 26 09:23:57 2004
Subject: [Pythonmac-SIG] Large lib-dynload on OS X 10.1 with Python 2.3.4
Message-ID: <417DFA80.2060903@bizarsoftware.com.au>

Hi,

I recently compiled Python2.3.4 on our package building machine which 
runs OS X 10.1.  I noticed that the lib-dynload directory is 54 meg!  An 
older Python2.1.1 build has a lib-dynload directory which is only 4 meg. 
The number of files in each is the same, its just that all the .so files 
in the python2.3.4 build are much bigger.

I just run ./configure; make; make install with both distros.

Is there any compiler options that I can tweak to bring the size back 
down?  The reason I want this is because I package the python distro up 
with our product when we ship it.

Just as a test, I built python2.3.4 on an osx10.3 machine we have here, 
and it produces a lib-dynload directory which is only 4 meg as expected.

terry


From ronaldoussoren at mac.com  Tue Oct 26 21:36:31 2004
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue Oct 26 21:36:27 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <a05200f24bda050718798@[81.101.66.68]>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
	<a05200f20bd9fd00dfffb@[81.101.66.68]>
	<89228549-24EC-11D9-AB1B-000A95C77748@mac.com>
	<a05200f24bda050718798@[81.101.66.68]>
Message-ID: <56728218-2786-11D9-A920-000D93AD379E@mac.com>


On 26-okt-04, at 0:27, has wrote:

> Ronald Oussoren wrote:
>
>>>> Depending on how ATS works there could be other problem: there is
>>>> no reason to assume that user Jack started a real ATS. What if he
>>>> started a modified version of ATS that returns garbage?
>>>
>>> Then appscript will fail. But this would be true for any scriptable
>>> application. You can only use Remote Apple Events when both client
>>> and server can be completely trusted, otherwise it's a massive
>>> security hole.
>>
>> Fail in what way?
>
> ATS returns a list containing five code-name translation tables in
> string format which the appscript.terminology module then parses into
> dicts for consumption by appscript.specifier. If appscript received
> anything else, the parser would choke. You can see these tables for
> yourself by running the following AppleScript:
>
> tell application "AppscriptTerminologyServer" to ?event ATSrTerm?
> "/Applications/TextEdit.app"

I finally download appscript, but haven't looked at the code yet.

But I have a new question anyway: how do you ensure that you get the 
right version of ATS? What if the user has installed appscript 0.8 and 
I create a py2app-ed application containing appscript 4.2, will this 
start both ATS-es or just one of them?

>
>
>>>> What happens when two users are logged on at the same time (Fast
>>>> User Switching)?
>>>
>>> Don't know how FUS works, so hoping somebody else can tell me how
>>> application scripting, RAE, etc. work under it. It's a question
>>> that definitely needs answered.
>>
>> I'd hope that application scripting works in the context of one user 
>> session.
>
> I've not turned up any info so far, but will try to find out.
>
>
>>>> I don't like a hidden daemon, especially when it accesses the
>>>> network and can be accessed across the network.
>>>
>>> ATS [...] has no independent network access priviledges - it's
>>> merely a gopher for priviledged third parties.
>>
>> Ah, I hadn't noticed that ATS is only accessed using OSA.
>
> Well, Apple events [1]. It's just a simple bundlebuilder-based app
> built using MiniApplication and aem.receive. Sorry if I wasn't more
> clear about this - I'll add an explanation of how ATS works to the
> documentation (soon as I get around to writing it).

AppleScript, Apple events, OSA, ... makes my head spin. I guess we 
should be gratefull that Apple at least designed the system in such way 
that we can write scripts in multiple languages.

>
>
>>  I assumed that you communicated using some private protocol.
>
> Oh, I'm far to dim and lazy to invent anything like that. ;)

and I wouldn't have dreamt of writing a scriptable application for this 
:-)

>
>
>> Most schemes that work for ATS should also work for a manual cache.
>
> Sure, but the problem isn't whether the cache is file-based or
> in-memory; it's how much work the user has to do to maintain it. The
> objective is to have a system that provides appscript with
> application terminologies for both local and remote applications
> while requiring the least possible amount of user interaction and,
> ideally, providing the best possible performance. ATS does pretty
> well on both counts;

ATS only does well with remote scripting if you install ATS on the 
remote system. This means automatic terminoligy retrieval for remote 
scripting with appscript will work only in some situations.

As I said before cache maintainance shouldn't be an issue: a file-based 
cache could use the same heuristics as a memory-based cache to decide 
when to refresh the cache.

>
>
>>> Except this creates extra maintenance hassles for the user, and
>>> we're back to having inferior application scripting support
>>> compared to AppleScript.
>>
>> py2app (or a gui wrapper around it) could automaticly perform the
>> maintenance hassles: You write a script that uses appscript, drop it
>> on "Build Py2Applet" and this scans your script for calls to
>> appscript.Application("iTunes.app")
>
> That's almost exactly what the AppleScript compiler does when it
> looks for 'tell application "Some App"' blocks in source code to work
> out what keywords to use while parsing that block. It's a really
> smelly hack and a regular pain (e.g. it can't cope with stuff like
> 'tell application nameStr' and 'tell applicationObj').
>
> Also, we need something that works equally well in all situations,
> not just for py2app-based applications. A lot of AppleScripting is
> just quick, small, throwaway scripts, or typing and executing
> commands in an interactive text window/console if you're using Smile
> [2] or SD.

Sure, but you don't need a cache *server* for that. A python IDE could 
maintain an in-process cache. For most people that would be good enough 
(tm).

>
> Using compile-time kludges to what's clearly a runtime problem is one
> of the things that's really wrong with how AppleScript implements its
> application scripting support. It's one of the things I specifically
> set out to avoid with appscript, so no chance I'd support it I'm
> afraid. :/

The real solution would be to nag Apple to improve the performance of
the OSAGetAppTerminology API :-).

Any chance for you adding an API that would allow others to write their 
own cache?


Ronald
From bob at redivi.com  Tue Oct 26 21:41:23 2004
From: bob at redivi.com (Bob Ippolito)
Date: Tue Oct 26 22:10:31 2004
Subject: [Pythonmac-SIG] ATS is a bad name for Appscript Terminology Server
Message-ID: <04862245-2787-11D9-959B-000A95BA5446@redivi.com>

has,

Can you come up with another name for the appscript terminology caching 
server?  ATS is already Apple Type Services.

-bob

From hengist.podd at virgin.net  Tue Oct 26 22:15:18 2004
From: hengist.podd at virgin.net (has)
Date: Tue Oct 26 22:36:55 2004
Subject: [Pythonmac-SIG] Re: ATS is a bad name for Appscript Terminology
	Server
In-Reply-To: <04862245-2787-11D9-959B-000A95BA5446@redivi.com>
References: <04862245-2787-11D9-959B-000A95BA5446@redivi.com>
Message-ID: <a05200f34bda45fb14663@[81.101.66.68]>

Bob wrote:

>Can you come up with another name for the appscript terminology 
>caching server?  ATS is already Apple Type Services.

Rats. Yeah, would be better to avoid TLA overloading. Open to 
suggestions. 'STS'? 'ASTS'? 'ATRS'? 'PTS'? 'APTS'?

Thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
From hengist.podd at virgin.net  Wed Oct 27 01:15:40 2004
From: hengist.podd at virgin.net (has)
Date: Wed Oct 27 01:18:54 2004
Subject: [Pythonmac-SIG] appscript terminology caching #2
In-Reply-To: <56728218-2786-11D9-A920-000D93AD379E@mac.com>
References: <a05200f17bd9dae1f0508@[81.101.66.68]>
	<B6A059DE-2406-11D9-9BAE-000A958D1666@cwi.nl>
	<364E0F2E-24BD-11D9-AB1B-000A95C77748@mac.com>
	<a05200f20bd9fd00dfffb@[81.101.66.68]>
	<89228549-24EC-11D9-AB1B-000A95C77748@mac.com>
	<a05200f24bda050718798@[81.101.66.68]>
	<56728218-2786-11D9-A920-000D93AD379E@mac.com>
Message-ID: <a05200f35bda46fe8134a@[81.101.66.68]>

Ronald Oussoren wrote:

>But I have a new question anyway: how do you ensure that you get the 
>right version of ATS? What if the user has installed appscript 0.8 
>and I create a py2app-ed application containing appscript 4.2, will 
>this start both ATS-es or just one of them?

Right now, deciding which application to launch when you've multiple 
instances installed is the OS's problem. You've the same problem when 
you've multiple versions of any app installed. I can't mind what the 
OS's rules for resolving these situations is (most recently 
installed? newest version?); anyone else know? At any rate, there's 
not much point in launching multiple versions of the same app since 
how will the Apple Event Manager know which one it's meant to use. 
ATS's interface should be stable by appscript 1.0.0 with the 
exception of its SDEF support; we can't implement that until Apple 
does, obviously.:) To prevent conflicts, we could even register the 
revised version under a different creator type.


Damn good question though: how will appscript/ATS behave in 
[semi-]standalone Python-based applications, which are responsible 
for supplying and managing their own dependencies rather than using 
the system-installed Python and maybe even installing the required 
modules into it if older or no existing versions are found?

It shouldn't really matter if there's a copy of ATS on the system 
that happens to get used instead, as long as that version isn't 
lacking functionality needed by the application or its own version of 
appscript. (Which is unlikely, though you can never be 100% sure.)


I think this can be framed as a general question: how does a 
bundlebuilder/py2app/any other kind of application deal with having 
sub-applications hidden inside the application bundle; how do they 
launch them and communicate with them, and avoid conflicts with other 
versions of themselves? This surely can't be the first time anyone's 
ever had to do this sort of thing, so there must be answers to it 
somewhere.


>AppleScript, Apple events, OSA, ... makes my head spin. I guess we 
>should be gratefull that Apple at least designed the system in such 
>way that we can write scripts in multiple languages.

Apple events - a high-level, serialised message-based interprocess 
communication mechanism

Open Scripting Architecture - 1. an API used to implement swappable 
scripting language components, and, in applications, to load and 
execute scripts written in any of those languages; 2. a group name 
for all of the Mac OS's application scripting-related technologies 
[note: Apple could have avoided a lot of confusion here if they'd 
called the API something like 'Scripting Component Support' instead]

AppleScript - 1. a simple scripting language with built-in support 
for constructing and sending Apple events, implemented as an OSA 
language component; 2. a misnomer for Apple event-based application 
scripting, as used in phrases such as 'AppleScriptable application' 
[note: also Apple's fault for conflating the two technologies in 
their marketing and other literature]

See also 
<http://www.cs.utexas.edu/users/wcook/papers/AppleScript/AppleScript95.pdf>

[I should probably post this summary on the pythonmac.org wiki for 
reference, but it seems to be getting overrun by scuzzball spambots 
right now so hardly seems worth it. Damn shame, but it's probably 
time it went subscription-based like the python.org wiki.]


>>>  I assumed that you communicated using some private protocol.
>>
>>Oh, I'm far to dim and lazy to invent anything like that. ;)
>
>and I wouldn't have dreamt of writing a scriptable application for this :-)

It just seemed an obvious choice. Daemons/FBAs seem a common solution 
when you've lots of short-term processes requiring some kind of 
support over a long period of time (e.g. cron), as are distributed 
applications when you've a job to perform that's spread across a 
network. And scriptable FBAs are an absolute doddle to write; while 
rewriting MiniAEFrame as aem.receive, I couldn't believe myself how 
little code it takes to handle Apple events (the real complexity is 
in evaluating Object Specifiers against an application's object 
model, but since ATS doesn't have an object model this isn't a 
problem).


>ATS only does well with remote scripting if you install ATS on the 
>remote system. This means automatic terminoligy retrieval for remote 
>scripting with appscript will work only in some situations.

To be precise: appscript can _only_ be used for remote scripting if 
it's installed on _both_ local and remote machines. (Though bear in 
mind that remote scripting will generally be used between trusted 
machines on a LAN and chances are these machines will all be 
administered by the same person/people, so this may not be a big deal 
for them.) It's a burden, but so is having to serialise each 
application's terminology on the server and copy the resulting files 
over to each client machine (something that would probably need to be 
done manually), as is grabbing the terminology from a locally 
installed copy of the same application (AppleScript's similarly 
less-than-satisfactory solution).

We have to accept that no solution we come up with will be perfect. 
This is all Apple's fault, after all, for providing sorely inadequate 
APIs, and all we're doing is putting a band-aid over it so we can 
stay in the game.


>As I said before cache maintainance shouldn't be an issue: a 
>file-based cache could use the same heuristics as a memory-based 
>cache to decide when to refresh the cache.

Right now the only refresh heuristics ATS uses is "manual reset" 
(which includes restarts). :)

I agree that caching for efficiency can be reproduced as a file-based 
cache, and could provide an equivalent manually initiated "rebuild 
cache now" command. That's the easy half though; figuring out a way 
for a file-based - or any other - system to get the terminology for a 
remote application is the hard half. And _that's_ the problem I 
couldn't solve except by switching to a distributed application-based 
solution, but if you can find a way to reproduce ATS's remote 
scripting benefits without recourse to such a system then go for it.


>>Also, we need something that works equally well in all situations,
>>not just for py2app-based applications. A lot of AppleScripting is
>>just quick, small, throwaway scripts, or typing and executing
>>commands in an interactive text window/console if you're using Smile
>>[2] or SD.
>
>Sure, but you don't need a cache *server* for that. A python IDE 
>could maintain an in-process cache. For most people that would be 
>good enough (tm).

I don't use an IDE; all my scripts get run in pythonw. So it wouldn't 
be good enough for me, for starters. :)


>>Using compile-time kludges to what's clearly a runtime problem is one
>>of the things that's really wrong with how AppleScript implements its
>>application scripting support. It's one of the things I specifically
>>set out to avoid with appscript, so no chance I'd support it I'm
>>afraid. :/
>
>The real solution would be to nag Apple to improve the performance of
>the OSAGetAppTerminology API :-).
>
>Any chance for you adding an API that would allow others to write 
>their own cache?

I'm going to add a 'terms' argument to the 'app' constructor, and put 
the dump() function from 0.7.1's appscript.terminology module into 
the new version. That's really so folk have a fallback option with 
applications whose aetes are too broken to work without manual 
patching, but you could just as easily subclass 'app' to use your own 
custom terminology management system.

...

So anyway - by all means go experiment; this is certainly the ideal 
time for it. Spend some time comparing AppleScript and appscript, 
particularly in terms of performance and usability, since AppleScript 
is the baseline we have to beat at least. Get some experience in 
doing application scripting if you've not yet done much/any. ATS is 
the best solution I've managed to come up with myself, but I'd be the 
first say there's a lot smarter folk in the world than me, so maybe 
they can maybe do better. Just mind that it's not enough to solve 
only one part of the problem; y'gotta come up with something that 
equals and/or betters ATS all round. Best o' British! :)

Cheers,

has

-- 
http://freespace.virgin.net/hamish.sanderson/
From cmeesters at ucdavis.edu  Wed Oct 27 20:35:57 2004
From: cmeesters at ucdavis.edu (Christian Meesters)
Date: Wed Oct 27 20:36:04 2004
Subject: [Pythonmac-SIG] wxPython on the Mac - one function with Bus Error
Message-ID: <0B0FA756-2847-11D9-9017-000393D8EC3A@ucdavis.edu>

Hi,

This is my first post here, so please apologize if the problem has been 
brought up before - I just feel MacUsers might know an answer to this 
question, rather than people at the wxPython list.

Well, I am using a Mac (OS 10.3.5), Python(2.3), and wx.Python(2.5.8). 
When creating a ListBox in wxPython with a multiple choice option I 
cannot quit my application properly. A Bus Error will be raised and 
printed on the shell - unfortunately without further information. This 
does not happen when I a) do not open the dialog with the ListBox, or 
b) do not enable the multiple choice option, or c) do not bind the 
event. I do not see the error unless I quit the application.

However, the same thing happens when using the demo application, not 
only by invoking main.py in the demos, but also when using the build 
demo. In the latter case I don't see the error message on the shell, of 
course, but the program crashes. All that only associated with the 
muliple choice option.

It doesn't matter whether I'm dealing with a MultipleChoiseDialog 
directly or a ListBox with multiple choice option: Same thing.

Is this a known problem? And, is there any solution known? I noted this 
problem a few days ago in the wxPython user list and got no response, 
so I would be glad if somebody could give me a hint - anything: I don't 
even know what possibly could cause a Bus Error here.

Thanks a lot in advance.
Cheers
Chris

From sw at wordtech-software.com  Wed Oct 27 21:26:40 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Wed Oct 27 21:26:45 2004
Subject: [Pythonmac-SIG] py2app and PyQt
Message-ID: <417FF670.80804@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been playing with py2app and a PyQt app I donwloaded, just trying
to see if I could package it up., but have failed. The app runs when
launched from the command line with pythonw, but dies when launched from
the py2app-generated bundle. The console tells me, "Can't find PyQt
module." The Qt libs do get copied to the bundle, so I'm not sure what
the problem is.

- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBf/ZvJmdQs+6YVcoRAuwqAJ4rCGigQ4nx5MeFYtVsn/KhlcJ8TQCffNJ7
9BmyJ77Ti8pJH6Y8icpkgEI=
=Vj/b
-----END PGP SIGNATURE-----
From bob at redivi.com  Wed Oct 27 21:32:18 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct 27 21:32:27 2004
Subject: [Pythonmac-SIG] py2app and PyQt
In-Reply-To: <417FF670.80804@wordtech-software.com>
References: <417FF670.80804@wordtech-software.com>
Message-ID: <EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>

On Oct 27, 2004, at 15:26, Kevin Walzer wrote:

> I've been playing with py2app and a PyQt app I donwloaded, just trying
> to see if I could package it up., but have failed. The app runs when
> launched from the command line with pythonw, but dies when launched 
> from
> the py2app-generated bundle. The console tells me, "Can't find PyQt
> module." The Qt libs do get copied to the bundle, so I'm not sure what
> the problem is.

Neither am I.  You didn't give enough information for me to even guess.

-bob

From sw at wordtech-software.com  Wed Oct 27 21:43:23 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Wed Oct 27 21:43:26 2004
Subject: [Pythonmac-SIG] py2app and PyQt
In-Reply-To: <EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>
References: <417FF670.80804@wordtech-software.com>
	<EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>
Message-ID: <417FFA5B.3030903@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

What other information would be helpful?


Bob Ippolito wrote:

| On Oct 27, 2004, at 15:26, Kevin Walzer wrote:
|
|> I've been playing with py2app and a PyQt app I donwloaded, just trying
|> to see if I could package it up., but have failed. The app runs when
|> launched from the command line with pythonw, but dies when launched from
|> the py2app-generated bundle. The console tells me, "Can't find PyQt
|> module." The Qt libs do get copied to the bundle, so I'm not sure what
|> the problem is.
|
|
| Neither am I.  You didn't give enough information for me to even guess.
|
| -bob
|
|
|


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBf/pbJmdQs+6YVcoRAqJ2AJ90fdThtTERpCwezUb99+dFAENg/QCfXLuI
lxfkPBQL5g0euNAlHvAQjhA=
=ID+v
-----END PGP SIGNATURE-----
From bob at redivi.com  Wed Oct 27 21:51:07 2004
From: bob at redivi.com (Bob Ippolito)
Date: Wed Oct 27 21:51:15 2004
Subject: [Pythonmac-SIG] py2app and PyQt
In-Reply-To: <417FFA5B.3030903@wordtech-software.com>
References: <417FF670.80804@wordtech-software.com>
	<EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>
	<417FFA5B.3030903@wordtech-software.com>
Message-ID: <8AF4B0F0-2851-11D9-9BED-000A95BA5446@redivi.com>

On Oct 27, 2004, at 15:43, Kevin Walzer wrote:

> Bob Ippolito wrote:
>
> | On Oct 27, 2004, at 15:26, Kevin Walzer wrote:
> |
> |> I've been playing with py2app and a PyQt app I donwloaded, just 
> trying
> |> to see if I could package it up., but have failed. The app runs when
> |> launched from the command line with pythonw, but dies when launched 
> from
> |> the py2app-generated bundle. The console tells me, "Can't find PyQt
> |> module." The Qt libs do get copied to the bundle, so I'm not sure 
> what
> |> the problem is.
> |
> |
> | Neither am I.  You didn't give enough information for me to even 
> guess.
> |
> What other information would be helpful?

Most helpful is complete instructions on how to reproduce it (how to 
get and install PyQt, this app, its dependencies, the setup.py used).  
Otherwise, useful things include but are not limited to: a copy of the 
broken .app, a full traceback, a list of files in the bundle, any crash 
reporter errors, otool -L output on any extensions and libraries in the 
bundle, etc.

-bob

From sw at wordtech-software.com  Wed Oct 27 22:45:44 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Wed Oct 27 22:45:47 2004
Subject: [Pythonmac-SIG] py2app and PyQt
In-Reply-To: <8AF4B0F0-2851-11D9-9BED-000A95BA5446@redivi.com>
References: <417FF670.80804@wordtech-software.com>
	<EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>
	<417FFA5B.3030903@wordtech-software.com>
	<8AF4B0F0-2851-11D9-9BED-000A95BA5446@redivi.com>
Message-ID: <418008F8.3050103@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bob Ippolito wrote:

| On Oct 27, 2004, at 15:43, Kevin Walzer wrote:
|
|> Bob Ippolito wrote:
|>
|> | On Oct 27, 2004, at 15:26, Kevin Walzer wrote:
|> |
|> |> I've been playing with py2app and a PyQt app I donwloaded, just trying
|> |> to see if I could package it up., but have failed. The app runs when
|> |> launched from the command line with pythonw, but dies when launched
|> from
|> |> the py2app-generated bundle. The console tells me, "Can't find PyQt
|> |> module." The Qt libs do get copied to the bundle, so I'm not sure what
|> |> the problem is.
|> |
|> |
|> | Neither am I.  You didn't give enough information for me to even guess.
|> |
|> What other information would be helpful?
|
|
| Most helpful is complete instructions on how to reproduce it (how to get
| and install PyQt, this app, its dependencies, the setup.py used).
| Otherwise, useful things include but are not limited to: a copy of the
| broken .app, a full traceback, a list of files in the bundle, any crash
| reporter errors, otool -L output on any extensions and libraries in the
| bundle, etc.
|
| -bob
|
|
|
The message I gave before--"cannot find PyQt module"--is all I got from
stderr/console. Given how long it takes to build and install Qt/PyQt (a
day at least), I don't want to waste anyone else's time on that front.
I'll see if there's anything else I can do to figure this out--it's kind
~ of important that I gain some expertise here as I'm working on putting
together a binary distribution of PyQt. (I have to rebuild Qt anyway
because of a patch that I incorrectly made, so who knows, this bug may
go away on its own.)



- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgAj3JmdQs+6YVcoRAgoxAKCBwCVtM72VkI6Zn1K8psBadKX2JgCgibdt
vjpToO0kTE5Ob7owfLrZC2Q=
=3s5b
-----END PGP SIGNATURE-----
From sw at wordtech-software.com  Fri Oct 29 05:38:20 2004
From: sw at wordtech-software.com (Kevin Walzer)
Date: Fri Oct 29 05:38:24 2004
Subject: [Pythonmac-SIG] py2app and PyQt
In-Reply-To: <8AF4B0F0-2851-11D9-9BED-000A95BA5446@redivi.com>
References: <417FF670.80804@wordtech-software.com>
	<EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>
	<417FFA5B.3030903@wordtech-software.com>
	<8AF4B0F0-2851-11D9-9BED-000A95BA5446@redivi.com>
Message-ID: <4181BB2C.10105@wordtech-software.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, I rebuilt Qt and PyQt, plus all the supporting libraries, because
another app I was running from the command line and in an applet bundle
was crashing also. Now the applet bundle ("save as applet" plus all
other app files copied into the app bundle) runs fine, but I still get
an error message when I try to build the same stuff into a standalone
bundle.

Are there any architectural differences between save as applet and save
as standalone bundle? I thought the main thing was that the applet only
saved a single script. Throwing all the other modules from the app is a
hack, I know. I'm asking because the internals of py2app are as
mysterious to me as bundlebuilder. Understanding a little about the
architecture might allow me to go through save as applet, trial and
error, and debug it that way, because clearly it's able to see the PyQt
stuff when it's running as a supporting library on the system, but
somehow that gets lost when the Qt libaries are copied into the
standalone bundle. (Or maybe they aren't? I'll look at that as well...)

Kevin

Bob Ippolito wrote:

| On Oct 27, 2004, at 15:43, Kevin Walzer wrote:
|
|> Bob Ippolito wrote:
|>
|> | On Oct 27, 2004, at 15:26, Kevin Walzer wrote:
|> |
|> |> I've been playing with py2app and a PyQt app I donwloaded, just trying
|> |> to see if I could package it up., but have failed. The app runs when
|> |> launched from the command line with pythonw, but dies when launched
|> from
|> |> the py2app-generated bundle. The console tells me, "Can't find PyQt
|> |> module." The Qt libs do get copied to the bundle, so I'm not sure what
|> |> the problem is.
|> |
|> |
|> | Neither am I.  You didn't give enough information for me to even guess.
|> |
|> What other information would be helpful?
|
|
| Most helpful is complete instructions on how to reproduce it (how to get
| and install PyQt, this app, its dependencies, the setup.py used).
| Otherwise, useful things include but are not limited to: a copy of the
| broken .app, a full traceback, a list of files in the bundle, any crash
| reporter errors, otool -L output on any extensions and libraries in the
| bundle, etc.
|
| -bob
|
|
|


- --
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw@wordtech-software.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBgbssJmdQs+6YVcoRAh15AJ9urwwKTqdEaYfsTv70YsE4qHHJhACeJ5df
t26i+VtZtMdVu3NZPyIA/wM=
=gaK/
-----END PGP SIGNATURE-----
From bob at redivi.com  Fri Oct 29 06:58:24 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri Oct 29 06:58:33 2004
Subject: [Pythonmac-SIG] py2app and PyQt
In-Reply-To: <4181BB2C.10105@wordtech-software.com>
References: <417FF670.80804@wordtech-software.com>
	<EA03487D-284E-11D9-8E1F-000A95BA5446@redivi.com>
	<417FFA5B.3030903@wordtech-software.com>
	<8AF4B0F0-2851-11D9-9BED-000A95BA5446@redivi.com>
	<4181BB2C.10105@wordtech-software.com>
Message-ID: <2A21F334-2967-11D9-878B-000A95BA5446@redivi.com>

Save as applet??  py2app doesn't have anything called that.

I can't help you without more information, or good instructions on how 
to reproduce this environment, as I mentioned before.

On Oct 28, 2004, at 23:38, Kevin Walzer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Well, I rebuilt Qt and PyQt, plus all the supporting libraries, because
> another app I was running from the command line and in an applet bundle
> was crashing also. Now the applet bundle ("save as applet" plus all
> other app files copied into the app bundle) runs fine, but I still get
> an error message when I try to build the same stuff into a standalone
> bundle.
>
> Are there any architectural differences between save as applet and save
> as standalone bundle? I thought the main thing was that the applet only
> saved a single script. Throwing all the other modules from the app is a
> hack, I know. I'm asking because the internals of py2app are as
> mysterious to me as bundlebuilder. Understanding a little about the
> architecture might allow me to go through save as applet, trial and
> error, and debug it that way, because clearly it's able to see the PyQt
> stuff when it's running as a supporting library on the system, but
> somehow that gets lost when the Qt libaries are copied into the
> standalone bundle. (Or maybe they aren't? I'll look at that as well...)
>
> Kevin
>
> Bob Ippolito wrote:
>
> | On Oct 27, 2004, at 15:43, Kevin Walzer wrote:
> |
> |> Bob Ippolito wrote:
> |>
> |> | On Oct 27, 2004, at 15:26, Kevin Walzer wrote:
> |> |
> |> |> I've been playing with py2app and a PyQt app I donwloaded, just 
> trying
> |> |> to see if I could package it up., but have failed. The app runs 
> when
> |> |> launched from the command line with pythonw, but dies when 
> launched
> |> from
> |> |> the py2app-generated bundle. The console tells me, "Can't find 
> PyQt
> |> |> module." The Qt libs do get copied to the bundle, so I'm not 
> sure what
> |> |> the problem is.
> |> |
> |> |
> |> | Neither am I.  You didn't give enough information for me to even 
> guess.
> |> |
> |> What other information would be helpful?
> |
> |
> | Most helpful is complete instructions on how to reproduce it (how to 
> get
> | and install PyQt, this app, its dependencies, the setup.py used).
> | Otherwise, useful things include but are not limited to: a copy of 
> the
> | broken .app, a full traceback, a list of files in the bundle, any 
> crash
> | reporter errors, otool -L output on any extensions and libraries in 
> the
> | bundle, etc.
> |
> | -bob
> |
> |
> |
>
>
> - --
> Kevin Walzer, PhD
> WordTech Software--Open Source Applications and Packages for OS X
> http://www.wordtech-software.com
> http://www.smallbizmac.com
> http://www.kevin-walzer.com
> mailto:sw@wordtech-software.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBgbssJmdQs+6YVcoRAh15AJ9urwwKTqdEaYfsTv70YsE4qHHJhACeJ5df
> t26i+VtZtMdVu3NZPyIA/wM=
> =gaK/
> -----END PGP SIGNATURE-----
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

From Jack.Jansen at cwi.nl  Fri Oct 29 10:08:27 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri Oct 29 10:09:57 2004
Subject: [Pythonmac-SIG] Re: ATS is a bad name for Appscript Terminology
	Server
In-Reply-To: <a05200f34bda45fb14663@[81.101.66.68]>
References: <04862245-2787-11D9-959B-000A95BA5446@redivi.com>
	<a05200f34bda45fb14663@[81.101.66.68]>
Message-ID: <B6833DA8-2981-11D9-A585-000A958D1666@cwi.nl>


On 26-okt-04, at 22:15, has wrote:

> Bob wrote:
>
>> Can you come up with another name for the appscript terminology 
>> caching server?  ATS is already Apple Type Services.
>
> Rats. Yeah, would be better to avoid TLA overloading. Open to 
> suggestions. 'STS'? 'ASTS'? 'ATRS'? 'PTS'? 'APTS'?

Why do you want a TLA? This is not something you're gonna refer to all 
that often. And, actually, as this is a hidden process usually it may 
be better to give it a descriptive name, so people can guess what it is 
if they see it in Process Viewer.

Python OSA Terminology Server?
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

From jeremy.knope at gmail.com  Fri Oct 29 16:19:33 2004
From: jeremy.knope at gmail.com (Jerome)
Date: Fri Oct 29 16:19:38 2004
Subject: [Pythonmac-SIG] Pygame & PyObjC , NSTextFields
Message-ID: <2c9aa7fe04102907197ac00ebd@mail.gmail.com>

How do I let an NSTextField get key downs?  pygame is capturing them,
wondering how i can either detect them and forward them on to cocoa or
avoid key events from getting to pygame instead...
  any help appreciated :)
 --jerome
From cdamundsen at gmail.com  Fri Oct 29 16:49:32 2004
From: cdamundsen at gmail.com (Craig Amundsen)
Date: Fri Oct 29 16:49:37 2004
Subject: [Pythonmac-SIG] Re: ATS is a bad name for Appscript Terminology
	Server
In-Reply-To: <B6833DA8-2981-11D9-A585-000A958D1666@cwi.nl>
References: <04862245-2787-11D9-959B-000A95BA5446@redivi.com>
	<a05200f34bda45fb14663@81.101.66.68>
	<B6833DA8-2981-11D9-A585-000A958D1666@cwi.nl>
Message-ID: <8dc0c28f041029074931de4265@mail.gmail.com>

Hi -


Jack Jansen wrote:
> has wrote:
> > Bob wrote:
> >> Can you come up with another name for the appscript terminology
> >> caching server?  ATS is already Apple Type Services.

> > Rats. Yeah, would be better to avoid TLA overloading. Open to
> > suggestions. 'STS'? 'ASTS'? 'ATRS'? 'PTS'? 'APTS'?

> Why do you want a TLA? This is not something you're gonna refer to all
> that often. And, actually, as this is a hidden process usually it may
> be better to give it a descriptive name, so people can guess what it is
> if they see it in Process Viewer.
> 
> Python OSA Terminology Server?

POSATS?

POTS?

- Craig
From hengist.podd at virgin.net  Fri Oct 29 16:20:26 2004
From: hengist.podd at virgin.net (has)
Date: Fri Oct 29 18:14:55 2004
Subject: [Pythonmac-SIG] Re: ATS is a bad name for Appscript
	Terminology Server
In-Reply-To: <B6833DA8-2981-11D9-A585-000A958D1666@cwi.nl>
References: <04862245-2787-11D9-959B-000A95BA5446@redivi.com>
	<a05200f34bda45fb14663@[81.101.66.68]>
	<B6833DA8-2981-11D9-A585-000A958D1666@cwi.nl>
Message-ID: <a05200f48bda7f9c7b00f@[81.101.66.68]>

Jack wrote:

>>>  ATS is already Apple Type Services.
>>
>>Rats. Yeah, would be better to avoid TLA overloading. Open to 
>>suggestions. 'STS'? 'ASTS'? 'ATRS'? 'PTS'? 'APTS'?
>
>Why do you want a TLA?

Presumably for convenience when we're discussing it? The full name, 
AppscriptTerminologyServer, is too much of a mouthful to use every 
time. Doesn't matter what length our acronym is, just as long as it 
doesn't collide with one already in use as that's where confusion 
arises.


>Python OSA Terminology Server?

Well, it's not specific to Python and I'm always leery of using 'OSA' 
in anything as it has two very different usages and it's never clear 
which one is meant. (e.g. ATS has nothing to do with the OSA API 
apart from it being where the 'GetAppTerminology' system call happens 
to reside.) It might also be confused with the Python OSA scripting 
component, which is something completely different and not a 
prerequisite of application scripting. How about just plain 
'ScriptingTerminologyServer'? It's not as self-explanatory as having 
'appscript' in the title, but I can't immediately think of anything 
'STS' might be confused with; can anyone else?

Ta,

has


p.s. On mention of 'Python OSA', anyone checked out Philip Aker's 
work recently? (http://homepage.mac.com/philip_aker/osa/osa.html) 
Looks like he's done some good work on OSA-ifying several OSS 
languages so far but the proprietary licence definitely impacts on 
its usefulness. Dunno about the other languages, but Python has the 
PSF and I know they like to give periodic handouts to worthy 
projects... don't suppose you think they might take an interest in 
offering him a modest amount of wealth, wine and women if he could be 
persuaded to open-source everything in return?
-- 
http://freespace.virgin.net/hamish.sanderson/
From berkowit at silcom.com  Fri Oct 29 18:34:01 2004
From: berkowit at silcom.com (Paul Berkowitz)
Date: Fri Oct 29 18:34:08 2004
Subject: [Pythonmac-SIG] Re: ATS is a bad name for Appscript
	Terminology Server
In-Reply-To: <a05200f48bda7f9c7b00f@[81.101.66.68]>
Message-ID: <BDA7BF09.782AC%berkowit@silcom.com>

On 10/29/04 7:20 AM, "has" <hengist.podd@virgin.net> wrote:

>  How about just plain
> 'ScriptingTerminologyServer'? It's not as self-explanatory as having
> 'appscript' in the title, but I can't immediately think of anything
> 'STS' might be confused with; can anyone else?

STS is used over on Windows for "SharePoint Team Services", a fairly big
deal. I don't suppose this could ever cause any sort of direct conflict
although it might cause the odd moment of confusion.

-- 
Paul Berkowitz


From cdamundsen at gmail.com  Sat Oct 30 19:12:26 2004
From: cdamundsen at gmail.com (Craig Amundsen)
Date: Sat Oct 30 19:12:30 2004
Subject: [Pythonmac-SIG] Numeric headers
Message-ID: <8dc0c28f0410301012721b9d8d@mail.gmail.com>

Hi -

I'm trying to install rpy on my 10.3.5 system. I've gotten R to
complile (woo!). Now I'm trying to get rpy installed. It needs to
compile against the Numeric headers. I've got Bob's Numeric 23.1
binary installed, but alas it does not include the headers. I've tried
to compile 23.6 but it can't find lapack.

I've read multiple discussions about getting compliling Numeric on OS
X, but the closest I've gotten to a howto is the observation that the
setup.py from 23.x is broken for OS X and that examination of the 22.0
setup.py should provide sufficient clues to fix the 23.x file. I've
tried this and while it takes longer to fail, it still fails.

Has anyone out there managed to modify the 23.x setup.py to get a
successful build? If so, could you share your secrets with a
distutil-er of very small brain?

TIA,
- Craig
From delza at livingcode.org  Sat Oct 30 22:23:14 2004
From: delza at livingcode.org (Dethe Elza)
Date: Sat Oct 30 22:23:14 2004
Subject: [Pythonmac-SIG] Nib-less program success
Message-ID: <86D42CF1-2AB1-11D9-84FF-0003939B59E8@livingcode.org>

Hi folks,

I just wanted to share some recent successes I've had with PyObjC.   
First, Bob, I've been using py2app and it's working wonderfully.  I'm  
very happy with the improvements you've made over the old bundlebuilder  
method.

I've also decided it was time to take a look at Renaissance more  
closely.  I really like the way it's designed, much more like HTML than  
most XML UI resource tools, which tend to be more like Java with XML  
syntax.  So far I have only scratched the surface, but I'm already  
impressed.

I was not able to find any examples of using Renaissance from PyObjC  
without using Nibs as well.  One of the (at least 4) forks of DrawBot  
uses Renaissance to build UI widgets and sheets, but it still uses Nibs  
for the main application.  I was trying to get Renaissance working  
without Nibs and crashing Python, about to give up when I tried one  
more thing and it worked, so I thought I'd share.

First, here is the main menu file, which can be re-used as the basis  
for most applications, and is mostly copied directly from the  
Renaissance CurrencyConverter example.

============ begin file MainMenu.gsmarkup ===================

<?xml version="1.0"?>
<!DOCTYPE gsmarkup>
<gsmarkup>
<objects>
   <menu type="main">
     <menu title="RenTest" type="apple">
       <menuItem title="About RenTest"  
action="orderFrontStandardAboutPanel:"/>
       <menuSeparator/>
       <menu title="Services" type="services"/>
       <menuSeparator/>
       <menuItem title="Hide RenTest" action="hide:" key="h"/>
       <menuItem title="Hide Others" action="hideOtherApplications:"/>
       <menuItem title="Show All" action="unhideAllApplications:"/>
       <menuSeparator/>
       <menuItem title="Quit RenTest" action="terminate:" key="q"/>
     </menu>
     <menu title="Edit">
       <menuItem title="Cut" action="cut:" key="x"/>
       <menuItem title="Copy" action="copy:" key="c"/>
       <menuItem title="Paste" action="paste:" key="v"/>
       <menuItem title="Delete" action="delete:"/>
       <menuItem title="Select All" action="selectAll:" key="a"/>
     </menu>
     <menu title="Window" type="windows">
       <menuItem title="Minimize Window" action="performMiniatureize:"  
key="m"/>
       <menuSeparator/>
       <menuItem title="Bring All to Front" action="arrangeInFront:"/>
     </menu>
   </menu>
</objects>
</gsmarkup>

============ end file MainMenu.gsmarkup ===================

Next is the small test window, drawn directly from Renaissance  
documentation:

============ begin file MainWindow.gsmarkup ===================

<?xml version="1.0"?>
<!DOCTYPE gsmarkup>
<gsmarkup>
<objects>
   <window title="Button Test" closable="NO" frameAutosaveName="main" >
     <button title="Click this button to quit" action="terminate:"/>
   </window>
</objects>
</gsmarkup>

============ end file MainWindow.gsmarkup ===================

And here is the Python code to run it.  The cut: command is implemented  
as a no-op to demonstrate how the menu commands automatically become  
enabled when their controller implements the selector specified in the  
gsmarkup file.  The two gsmarkup files are loaded in separate areas of  
the code to demonstrate how easy it is to load from markup.

============ begin file RenTest.py ===================

from Foundation import *
from AppKit import *
from Renaissance import *
from PyObjCTools.AppHelper import runEventLoop

class MyApplicationDelegate(NSObject):
   def cut_(self, sender):
     pass
   def applicationDidFinishLaunching_(self, notification):
     NSBundle.loadGSMarkupNamed_owner_('MainWindow', self)

def main():
   app = NSApplication.sharedApplication()
   delegate = MyApplicationDelegate.alloc().init()
   app.setDelegate_(delegate)
   NSBundle.loadGSMarkupNamed_owner_('MainMenu', delegate)
   NSApp().run()

if __name__ == '__main__': main()

============ end file RenTest.py ===================

Putting it all together is done using py2app:

============ begin file setup.py ===================

'''
Minimal setup.py example, run with:
% python setup.py py2app
'''

from distutils.core import setup
import py2app
setup(
   data_files = ['MainMenu.gsmarkup', 'MainWindow.gsmarkup'],
   app = ['RenTest.py'],
)

============ end file setup.py ===================

Finally, after putting the Renaissance.framework in /Library/Frameworks  
I've also put the following in  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages/Renaissance/ to enable Renaissance globally on my system.

============ begin file __init__.py ===================

import objc, AppKit, Foundation
objc.loadBundle('Renaissance', globals(),  
bundle_path='/Library/Frameworks/Renaissance.framework')
del objc, AppKit, Foundation

============ end file __init__.py ===================

OK, that's it.  About 79 lines of code to have a simple app with menus  
and a window and basic Mac app behaviour (hide, minimize, Cmd-H, Cmd-Q,  
etc.).

Why do I care about avoiding Nibs?  Two main reasons.  Interface  
Builder is great as far as it goes, but it has a steep learning curve  
to use it well.  And when I'm developing an application and want to  
refactor it, or rapidly iterate through several tests, I have trouble  
finding everywhere in Interface Builder that a certain outlet or  
selector is used, to change the target or the selector.  And because it  
stores serialized objects, it doesn't pick up changes to my code unless  
I force it to.  I'm afraid I prefer a format I can grep to a visual one  
(IB for Renaissance is in progress I understand, which would be great  
-- I'm not constitutionally opposed to graphic layout tools, I just  
don't like them being enforced).  So using Renaissance addresses my  
problems in using IB.

The second reason is that I see Cocoa examples on the web (either ObjC  
or PyObjC) which go like this:  "Look, I can make an [editor,  
web-browser, etc.] with only 5 lines of code!" followed by 25 screen  
shots of IB with paragraphs of instructions for wiring up the widgets  
and outlets to the 5 lines of code.  This seems disingenuous to me, and  
it's fragile because the examples which worked with the last version of  
IB don't necessarily reflect the current (or next) version.  Maybe it's  
just me, but I have a lot easier time following the 79 lines of code  
above versus the 5 lines + screen shots + talking you through the  
screen shots.

Anyway, I found this very exciting and hope I haven't bored y'all too  
much.  I'm loving PyObjC even more than usual now, which is something.   
Now to write something more substantial...

--Dethe

Excel is the Awk of Windows --Joel Spolsky

From Jack.Jansen at cwi.nl  Sat Oct 30 23:06:14 2004
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sat Oct 30 23:06:09 2004
Subject: [Pythonmac-SIG] Numeric headers
In-Reply-To: <8dc0c28f0410301012721b9d8d@mail.gmail.com>
References: <8dc0c28f0410301012721b9d8d@mail.gmail.com>
Message-ID: <88A3B538-2AB7-11D9-A508-000D934FF6B4@cwi.nl>


On 30 Oct 2004, at 19:12, Craig Amundsen wrote:

> Hi -
>
> I'm trying to install rpy on my 10.3.5 system. I've gotten R to
> complile (woo!). Now I'm trying to get rpy installed. It needs to
> compile against the Numeric headers. I've got Bob's Numeric 23.1
> binary installed, but alas it does not include the headers. I've tried
> to compile 23.6 but it can't find lapack.

If you take Numeric from the standard PackMan database (not sure about  
Bob's, though) it will install the headers if you first make  
/System/Library/Frameworks/Python.framework/Versions/Current/include/ 
python2.3 writable.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman

From cookedm at physics.mcmaster.ca  Sun Oct 31 21:58:59 2004
From: cookedm at physics.mcmaster.ca (David M.Cooke)
Date: Sun Oct 31 21:59:01 2004
Subject: [Pythonmac-SIG] Numeric headers
In-Reply-To: <8dc0c28f0410301012721b9d8d@mail.gmail.com>
References: <8dc0c28f0410301012721b9d8d@mail.gmail.com>
Message-ID: <AFB73C45-2B7F-11D9-87BE-000A95BE5E0A@physics.mcmaster.ca>

On Oct 30, 2004, at 13:12, Craig Amundsen wrote:
> I've read multiple discussions about getting compliling Numeric on OS
> X, but the closest I've gotten to a howto is the observation that the
> setup.py from 23.x is broken for OS X and that examination of the 22.0
> setup.py should provide sufficient clues to fix the 23.x file. I've
> tried this and while it takes longer to fail, it still fails.
>
> Has anyone out there managed to modify the 23.x setup.py to get a
> successful build? If so, could you share your secrets with a
> distutil-er of very small brain?

I've attached the diff that I use to compile Numeric with LAPACK 
support on OS X. It compiles it with -faltivec and links agains the 
vecLib framework. Hope this helps.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|cookedm@physics.mcmaster.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: numeric-setup-osx.diff
Type: application/octet-stream
Size: 2172 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20041031/798b56e5/numeric-setup-osx.obj