From niel_mayhew@mac.com  Fri Nov  1 05:19:59 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Thu, 31 Oct 2002 22:19:59 -0700
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <15809.29749.543037.456228@montanaro.dyndns.org>
Message-ID: <B9E75D0F.3440%niel_mayhew@mac.com>

on 31/10/2002 11:19 AM, Skip Montanaro at skip@pobox.com wrote:

> Do you perhaps have a complex site.py file or have PYTHONSTARTUP set and
> pointing to a pythonrc.py that does a lot of heavy lifting...

No, this is a vanilla Python installation, freshly installed from Jack's
installer. I haven't touched anything in the Python folder.

After Jack posted his fix recently (2.2.2b1 on 11 Oct, I think), the problem
went away, but now it's back. I don't get it on my G4 iMac at home, only on
my 2xG4 at work.

--Neil





From Jack.Jansen@oratrix.com  Fri Nov  1 14:16:17 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 1 Nov 2002 15:16:17 +0100
Subject: [Pythonmac-SIG] Re: Strange MacPython (2.2.1) Behavior
In-Reply-To: <B9E6D018.472D%jharmon@adobe.com>
Message-ID: <7C63215A-EDA4-11D6-9BA7-000A27B19B96@oratrix.com>

JR,
my first guess is that you get two different versions of "module", 
maybe because there's one in the folder where your script lives (the 
folder where the script lives gets prepended to sys.path, but that 
doesn't happen when you run interactively.

First thing to try would be to option-run PythonInterpreter, select the 
"verbose import" option and keep the output. Then option-drag your 
scrip to the interpreter, select "verbose import" again, and compare 
the output to what you got previously.

If that all looks normal then see what happens if you import your 
script into an interactive interpreter, i.e. something like
 >>> sys.path.append("path:to:script:dir")
 >>> import _test

You can also try option-dragging your script to the interpreter and 
selecting "interactive mode after script". Then doing "import pdb; 
pdb.pm()" lets you do post-mortem debugging, and you can look at the 
value of session, try to run session_class_stor() again and seeing what 
that value is, etc.

You might also want to look closely at your C code looking at 
INCREF/DECREFs, return values (you aren't forgetting to return a value 
somewhere? That can lead to transient errors like these), etc.

On donderdag, okt 31, 2002, at 21:18 Europe/Amsterdam, JR wrote:

>> I'm running into some odd behavior from MacPython and was hoping that 
>> someone
>> (here) might be able to provide some guidance...
>
> Oops.  I hit send a tad early...
>
> Here is the complete note:
>
> I'm running into some odd behavior from MacPython (Python 2.2.1 (#134, 
> Apr
> 9 2002, 21:16:52)  [CW CARBON GUSI2 THREADS GC] on mac natively on OS X
> 10.1.5) and was hoping that someone (here) might be able to provide 
> some
> guidance...
>
> I've built a module that seemingly loads correctly, etc.  If I import 
> that
> module (e.g., from module import *) and then line by line enter Python 
> code
> in the Interpreter everything behaves fine.  Yet, the same Python code 
> read
> in from a text file (e.g., drag _test.py to PythonInterpreter) 
> exhibits what
> I can only describe as structural failures (possibly a result of 
> garbage
> collection?).  Here is some sample code:
>
> from module import *
>
> def _test():
>     session = session_class_ctor()
>     dict = session.create_dict()
>     field = dict.Get("key")
>
>
> _test()
>
> ...if I enter code like this interactively everything works fine.  
> session,
> dict and field all remain uncollected (with >0 ref counts) and exhibit 
> valid
> module defined types (i.e., type(dict) => <type 'foodict'>).  Yet, if I
> encapsulate the same code in a .py file and drag/drop it on the 
> interpreter
> the interpreter complains that instance 'dict' has no Get attribute 
> because
> it is of type None.  As in...
>
> AttributeError: 'NoneType' object has no attribute 'Get'
>
> Ideas?
> Thoughts?
>
> JR
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Fri Nov  1 15:00:48 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 1 Nov 2002 16:00:48 +0100
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <B9E6BEA6.7057%niel_mayhew@mac.com>
Message-ID: <B4E91132-EDAA-11D6-9BA7-000A27B19B96@oratrix.com>

On donderdag, okt 31, 2002, at 19:04 Europe/Amsterdam, Neil Mayhew 
wrote:

> If I start up with 'Trace import statements' and 'Also show failed 
> attempts'
> checked, there is a very noticeable pause after 'import __future__ #
> precompiled from ... Python 2.2.2:Lib:__future__.pyc' and before '# 
> trying
> .. Python 2.2.2:sitecustomize.carbon.slb'

Some things to try:
- Run Python with site disabled, then manually import __future__, and 
see how slow that is.
- Run Python site site disabled, then manually import types (which is 
what imports __future__).

I don't think either of these are to blame, but they're easy to test so 
do that first.

Next, if these both run fast enough, rig up site.py with print 
statements and see where the delay occurs.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From Chris.Barker@noaa.gov  Fri Nov  1 18:10:13 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Fri, 01 Nov 2002 10:10:13 -0800
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
References: <B9E6BEA6.7057%niel_mayhew@mac.com>
Message-ID: <3DC2C385.24D05DBC@noaa.gov>

Neil Mayhew wrote:
> if I double-click
> PythonInterpreter, the console window comes up but there is a pause of up to
> 6 seconds before the >>> appears.

OK, I just tried this too. After a vanilla install, If I double click
the interpreter, the window comes up right away, but it can be 10-20
seconds! before I get the prompt.

I'm running a very new Dual 867Mhz G4, OS-X version 10.2.1

EditPythonPrefs take a while to start up as well.

Like Neil, if I disable site-Python, it only takes a second to see the
prompt. By the way, I don't seem to ahve a site-python file anywhere
anyway. Where should it be? and is the lack of one the problem?

With site-python disabled, it's a lot faster, but still at least a
second delay. Why might this be? Unix-python starts up essentially
instantly.


Side note: I can't move the EditPythonPrefs dialog around at all. Is
this still standard Carbon behaviour? Yuck! Also, the layout of the
radio button of the Startup Options dialog is pretty bad under OS-X, the
buttons overlap each other and obscure some of the text.

Sorry, I don't have a single processor machine to test on at the moment.

-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 jharmon@adobe.com  Fri Nov  1 18:51:00 2002
From: jharmon@adobe.com (JR)
Date: Fri, 01 Nov 2002 10:51:00 -0800
Subject: [Pythonmac-SIG] JR's Python problem solved...
Message-ID: <B9E80D14.476E%jharmon@adobe.com>

> my first guess is that you get two different versions of "module",
> maybe because there's one in the folder where your script lives (the
> folder where the script lives gets prepended to sys.path, but that
> doesn't happen when you run interactively.

UDaMan Jack!

You were right.  It was importing an old (backup) module that happened to be
in the .py script's folder.  Is there a way one can configure MacPython such
that it doesn't do this (i.e., picks up resources in the app's dir _before_
the script's dir)?

On to bigger and better (and less perplexing) debugging activities,
JR



From Chris.Barker@noaa.gov  Sat Nov  2 00:47:36 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Fri, 1 Nov 2002 16:47:36 -0800
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <B4E91132-EDAA-11D6-9BA7-000A27B19B96@oratrix.com>
Message-ID: <AE35C028-EDFC-11D6-8695-000393A96660@noaa.gov>

--Apple-Mail-2--91202036
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Friday, November 1, 2002, at 07:00 AM, Jack Jansen wrote:

>
> On donderdag, okt 31, 2002, at 19:04 Europe/Amsterdam, Neil Mayhew 
> wrote:
>
>> If I start up with 'Trace import statements' and 'Also show failed 
>> attempts'
>> checked, there is a very noticeable pause after 'import __future__ #
>> precompiled from ... Python 2.2.2:Lib:__future__.pyc' and before '# 
>> trying
>> .. Python 2.2.2:sitecustomize.carbon.slb'

I get exactly the same results.

> Some things to try:
> - Run Python with site disabled, then manually import __future__, and 
> see how slow that is.

essentially instant

> - Run Python site site disabled, then manually import types (which is 
> what imports __future__).

also instant

> I don't think either of these are to blame, but they're easy to test 
> so do that first.

apparently not.

> Next, if these both run fast enough, rig up site.py with print 
> statements and see where the delay occurs.

OK, I added a bunch of print and timing statements to site.py and got 
this:

starting site.py
elapsed time is: 0.00 seconds
defining makepath
elapsed time is: 0.01 seconds
running sys.modules loop
elapsed time is: 0.01 seconds
starting absolute path routine
elapsed time is: 0.00 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 2.2.2:
elapsed time is: 0.01 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Mac:Lib
elapsed time is: 0.82 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Mac:Lib:lib-compat
elapsed time is: 0.21 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Mac:Lib:lib-scriptpackages
elapsed time is: 0.00 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Lib:lib-dynload
elapsed time is: 0.11 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Lib
elapsed time is: 10.88 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Extensions:img:Mac
elapsed time is: 0.11 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Extensions:img:Lib
elapsed time is: 0.01 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Extensions:Imaging
elapsed time is: 0.01 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Lib:lib-tk
elapsed time is: 0.11 seconds
Inside absolute path loop, dir = Macintosh HD:Applications:Python 
2.2.2:Lib:site-packages
elapsed time is: 0.01 seconds
running " append ./build...
elapsed time is: 0.00 seconds
running prefixes...
elapsed time is: 2.54 seconds
defining quit and exit
elapsed time is: 0.00 seconds
printing credits
elapsed time is: 0.01 seconds
defining new help
elapsed time is: 0.00 seconds
setting string encoding
elapsed time is: 0.00 seconds
trying to import sitecustomize
elapsed time is: 0.11 seconds
removing sys.setdefaultencoding()
elapsed time is: 0.00 seconds


so, it looks like it is taking a long time to process: Macintosh 
HD:Applications:Python 2.2.2:Lib in the absolute path routine

It also takes a while to run  the prefixes code as well.

I've enclosed the altered site.py file, if anyone else want to try it. 
I don't have any more time to look at this for the next week, but maybe 
jack (or someone) will get an idea from my results.

-Chris


--Apple-Mail-2--91202036
Content-Disposition: attachment;
	filename=site.py
Content-Transfer-Encoding: quoted-printable
Content-Type: application/text;
	x-mac-creator=522A6368;
	x-unix-mode=0644;
	x-mac-type=54455854;
	name="site.py"

"""Append=20module=20search=20paths=20for=20third-party=20packages=20to=20=
sys.path.=0D=0D=
****************************************************************=0D*=20=
This=20module=20is=20automatically=20imported=20during=20initialization.=20=
*=0D****************************************************************=0D=0D=
In=20earlier=20versions=20of=20Python=20(up=20to=201.5a3),=20scripts=20=
or=20modules=20that=0Dneeded=20to=20use=20site-specific=20modules=20=
would=20place=20``import=20site''=0Dsomewhere=20near=20the=20top=20of=20=
their=20code.=20=20Because=20of=20the=20automatic=0Dimport,=20this=20is=20=
no=20longer=20necessary=20(but=20code=20that=20does=20it=20still=0D=
works).=0D=0DThis=20will=20append=20site-specific=20paths=20to=20to=20=
the=20module=20search=20path.=20=20On=0DUnix,=20it=20starts=20with=20=
sys.prefix=20and=20sys.exec_prefix=20(if=20different)=20and=0Dappends=20=
lib/python<version>/site-packages=20as=20well=20as=20lib/site-python.=0D=
On=20other=20platforms=20(mainly=20Mac=20and=20Windows),=20it=20uses=20=
just=20sys.prefix=0D(and=20sys.exec_prefix,=20if=20different,=20but=20=
this=20is=20unlikely).=20=20The=0Dresulting=20directories,=20if=20they=20=
exist,=20are=20appended=20to=20sys.path,=20and=0Dalso=20inspected=20for=20=
path=20configuration=20files.=0D=0DA=20path=20configuration=20file=20is=20=
a=20file=20whose=20name=20has=20the=20form=0D<package>.pth;=20its=20=
contents=20are=20additional=20directories=20(one=20per=20line)=0Dto=20be=20=
added=20to=20sys.path.=20=20Non-existing=20directories=20(or=0D=
non-directories)=20are=20never=20added=20to=20sys.path;=20no=20directory=20=
is=20added=20to=0Dsys.path=20more=20than=20once.=20=20Blank=20lines=20=
and=20lines=20beginning=20with=0D'#'=20are=20skipped.=20Lines=20starting=20=
with=20'import'=20are=20executed.=0D=0DFor=20example,=20suppose=20=
sys.prefix=20and=20sys.exec_prefix=20are=20set=20to=0D/usr/local=20and=20=
there=20is=20a=20directory=20/usr/local/lib/python1.5/site-packages=0D=
with=20three=20subdirectories,=20foo,=20bar=20and=20spam,=20and=20two=20=
path=0Dconfiguration=20files,=20foo.pth=20and=20bar.pth.=20=20Assume=20=
foo.pth=20contains=20the=0Dfollowing:=0D=0D=20=20#=20foo=20package=20=
configuration=0D=20=20foo=0D=20=20bar=0D=20=20bletch=0D=0Dand=20bar.pth=20=
contains:=0D=0D=20=20#=20bar=20package=20configuration=0D=20=20bar=0D=0D=
Then=20the=20following=20directories=20are=20added=20to=20sys.path,=20in=20=
this=20order:=0D=0D=20=20/usr/local/lib/python1.5/site-packages/bar=0D=20=
=20/usr/local/lib/python1.5/site-packages/foo=0D=0DNote=20that=20bletch=20=
is=20omitted=20because=20it=20doesn't=20exist;=20bar=20precedes=20foo=0D=
because=20bar.pth=20comes=20alphabetically=20before=20foo.pth;=20and=20=
spam=20is=0Domitted=20because=20it=20is=20not=20mentioned=20in=20either=20=
path=20configuration=20file.=0D=0DAfter=20these=20path=20manipulations,=20=
an=20attempt=20is=20made=20to=20import=20a=20module=0Dnamed=20=
sitecustomize,=20which=20can=20perform=20arbitrary=20additional=0D=
site-specific=20customizations.=20=20If=20this=20import=20fails=20with=20=
an=0DImportError=20exception,=20it=20is=20silently=20ignored.=0D=0D"""=0D=
=0Dimport=20sys,=20os,=20time=0D=0Dstart=20=3D=20time.time()=0Dprint=20=
"starting=20site.py"=0D=0D=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20)=0Dprint=20"defining=20makepath"=0D=0D=
def=20makepath(*paths):=0D=20=20=20=20dir=20=3D=20=
os.path.abspath(os.path.join(*paths))=0D=20=20=20=20return=20dir,=20=
os.path.normcase(dir)=0D=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20);=20start=20=3D=20time.time()=0Dprint=20=
"running=20sys.modules=20loop"=0D=0Dfor=20m=20in=20sys.modules.values():=0D=
=20=20=20=20if=20hasattr(m,=20"__file__")=20and=20m.__file__:=0D=20=20=20=
=20=20=20=20=20m.__file__=20=3D=20os.path.abspath(m.__file__)=0Ddel=20m=0D=
=0D#=20This=20ensures=20that=20the=20initial=20path=20provided=20by=20=
the=20interpreter=20contains=0D#=20only=20absolute=20pathnames,=20even=20=
if=20we're=20running=20from=20the=20build=20directory.=0Dprint=20=
"elapsed=20time=20is:=20%.2f=20seconds"%(time.time()-start,=20);=20start=20=
=3D=20time.time()=0Dprint=20"starting=20absolute=20path=20routine"=0D=0D=
L=20=3D=20[]=0D_dirs_in_sys_path=20=3D=20{}=0Dfor=20dir=20in=20sys.path:=0D=
=20=20=20=20print=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20);=20start=20=3D=20time.time()=0D=20=20=20=
=20print=20"Inside=20absolute=20path=20loop,=20dir=20=3D=20%s"%dir=0D=0D=20=
=20=20=20#=20Filter=20out=20paths=20that=20don't=20exist,=20but=20leave=20=
in=20the=20empty=20string=0D=20=20=20=20#=20since=20it's=20a=20special=20=
case.=20We=20also=20need=20to=20special-case=20the=20Mac,=0D=20=20=20=20=
#=20as=20file=20names=20are=20allowed=20on=20sys.path=20there.=0D=20=20=20=
=20if=20sys.platform=20!=3D=20'mac':=0D=20=20=20=20=20=20=20=20if=20dir=20=
and=20not=20os.path.isdir(dir):=0D=20=20=20=20=20=20=20=20=20=20=20=20=
continue=0D=20=20=20=20else:=0D=20=20=20=20=20=20=20=20if=20dir=20and=20=
not=20os.path.exists(dir):=0D=20=20=20=20=20=20=20=20=20=20=20=20=
continue=0D=20=20=20=20dir,=20dircase=20=3D=20makepath(dir)=0D=20=20=20=20=
if=20not=20_dirs_in_sys_path.has_key(dircase):=0D=20=20=20=20=20=20=20=20=
L.append(dir)=0D=20=20=20=20=20=20=20=20_dirs_in_sys_path[dircase]=20=3D=20=
1=0Dsys.path[:]=20=3D=20L=0Ddel=20dir,=20L=0D=0Dprint=20"elapsed=20time=20=
is:=20%.2f=20seconds"%(time.time()-start,=20);=20start=20=3D=20=
time.time()=0Dprint=20'running=20"=20append=20./build...'=0D=0D=0D#=20=
Append=20./build/lib.<platform>=20in=20case=20we're=20running=20in=20the=20=
build=20dir=0D#=20(especially=20for=20Guido=20:-)=0Dif=20(os.name=20=3D=3D=
=20"posix"=20and=20sys.path=20and=0D=20=20=20=20=
os.path.basename(sys.path[-1])=20=3D=3D=20"Modules"):=0D=20=20=20=20from=20=
distutils.util=20import=20get_platform=0D=20=20=20=20s=20=3D=20=
"build/lib.%s-%.3s"=20%=20(get_platform(),=20sys.version)=0D=20=20=20=20=
s=20=3D=20os.path.join(os.path.dirname(sys.path[-1]),=20s)=0D=20=20=20=20=
sys.path.append(s)=0D=20=20=20=20del=20get_platform,=20s=0D=0Ddef=20=
_init_pathinfo():=0D=20=20=20=20global=20_dirs_in_sys_path=0D=20=20=20=20=
_dirs_in_sys_path=20=3D=20d=20=3D=20{}=0D=20=20=20=20for=20dir=20in=20=
sys.path:=0D=20=20=20=20=20=20=20=20if=20dir=20and=20not=20=
os.path.isdir(dir):=0D=20=20=20=20=20=20=20=20=20=20=20=20continue=0D=20=20=
=20=20=20=20=20=20dir,=20dircase=20=3D=20makepath(dir)=0D=20=20=20=20=20=20=
=20=20d[dircase]=20=3D=201=0D=0Ddef=20addsitedir(sitedir):=0D=20=20=20=20=
global=20_dirs_in_sys_path=0D=20=20=20=20if=20_dirs_in_sys_path=20is=20=
None:=0D=20=20=20=20=20=20=20=20_init_pathinfo()=0D=20=20=20=20=20=20=20=20=
reset=20=3D=201=0D=20=20=20=20else:=0D=20=20=20=20=20=20=20=20reset=20=3D=20=
0=0D=20=20=20=20sitedir,=20sitedircase=20=3D=20makepath(sitedir)=0D=20=20=
=20=20if=20not=20_dirs_in_sys_path.has_key(sitedircase):=0D=20=20=20=20=20=
=20=20=20sys.path.append(sitedir)=20=20=20=20=20=20=20=20#=20Add=20path=20=
component=0D=20=20=20=20try:=0D=20=20=20=20=20=20=20=20names=20=3D=20=
os.listdir(sitedir)=0D=20=20=20=20except=20os.error:=0D=20=20=20=20=20=20=
=20=20return=0D=20=20=20=20names.sort()=0D=20=20=20=20for=20name=20in=20=
names:=0D=20=20=20=20=20=20=20=20if=20name[-4:]=20=3D=3D=20os.extsep=20+=20=
"pth":=0D=20=20=20=20=20=20=20=20=20=20=20=20addpackage(sitedir,=20name)=0D=
=20=20=20=20if=20reset:=0D=20=20=20=20=20=20=20=20_dirs_in_sys_path=20=3D=20=
None=0D=0Ddef=20addpackage(sitedir,=20name):=0D=20=20=20=20global=20=
_dirs_in_sys_path=0D=20=20=20=20if=20_dirs_in_sys_path=20is=20None:=0D=20=
=20=20=20=20=20=20=20_init_pathinfo()=0D=20=20=20=20=20=20=20=20reset=20=
=3D=201=0D=20=20=20=20else:=0D=20=20=20=20=20=20=20=20reset=20=3D=200=0D=20=
=20=20=20fullname=20=3D=20os.path.join(sitedir,=20name)=0D=20=20=20=20=
try:=0D=20=20=20=20=20=20=20=20f=20=3D=20open(fullname)=0D=20=20=20=20=
except=20IOError:=0D=20=20=20=20=20=20=20=20return=0D=20=20=20=20while=20=
1:=0D=20=20=20=20=20=20=20=20dir=20=3D=20f.readline()=0D=20=20=20=20=20=20=
=20=20if=20not=20dir:=0D=20=20=20=20=20=20=20=20=20=20=20=20break=0D=20=20=
=20=20=20=20=20=20if=20dir[0]=20=3D=3D=20'#':=0D=20=20=20=20=20=20=20=20=20=
=20=20=20continue=0D=20=20=20=20=20=20=20=20if=20=
dir.startswith("import"):=0D=20=20=20=20=20=20=20=20=20=20=20=20exec=20=
dir=0D=20=20=20=20=20=20=20=20=20=20=20=20continue=0D=20=20=20=20=20=20=20=
=20if=20dir[-1]=20=3D=3D=20'\n':=0D=20=20=20=20=20=20=20=20=20=20=20=20=
dir=20=3D=20dir[:-1]=0D=20=20=20=20=20=20=20=20dir,=20dircase=20=3D=20=
makepath(sitedir,=20dir)=0D=20=20=20=20=20=20=20=20if=20not=20=
_dirs_in_sys_path.has_key(dircase)=20and=20os.path.exists(dir):=0D=20=20=20=
=20=20=20=20=20=20=20=20=20sys.path.append(dir)=0D=20=20=20=20=20=20=20=20=
=20=20=20=20_dirs_in_sys_path[dircase]=20=3D=201=0D=20=20=20=20if=20=
reset:=0D=20=20=20=20=20=20=20=20_dirs_in_sys_path=20=3D=20None=0D=0D=
print=20"elapsed=20time=20is:=20%.2f=20seconds"%(time.time()-start,=20);=20=
start=20=3D=20time.time()=0Dprint=20"running=20prefixes..."=0D=0D=
prefixes=20=3D=20[sys.prefix]=0Dif=20sys.exec_prefix=20!=3D=20=
sys.prefix:=0D=20=20=20=20prefixes.append(sys.exec_prefix)=0Dfor=20=
prefix=20in=20prefixes:=0D=20=20=20=20if=20prefix:=0D=20=20=20=20=20=20=20=
=20if=20os.sep=20=3D=3D=20'/':=0D=20=20=20=20=20=20=20=20=20=20=20=20=
sitedirs=20=3D=20[os.path.join(prefix,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20"lib",=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"python"=20+=20=
sys.version[:3],=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
"site-packages"),=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20os.path.join(prefix,=20"lib",=20"site-python")]=0D=20=20=
=20=20=20=20=20=20else:=0D=20=20=20=20=20=20=20=20=20=20=20=20sitedirs=20=
=3D=20[prefix,=20os.path.join(prefix,=20"lib",=20"site-packages")]=0D=20=20=
=20=20=20=20=20=20for=20sitedir=20in=20sitedirs:=0D=20=20=20=20=20=20=20=20=
=20=20=20=20if=20os.path.isdir(sitedir):=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20addsitedir(sitedir)=0D=0D_dirs_in_sys_path=20=3D=20=
None=0D=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20);=20start=20=3D=20time.time()=0Dprint=20=
"defining=20quit=20and=20exit"=0D=0D#=20Define=20new=20built-ins=20=
'quit'=20and=20'exit'.=0D#=20These=20are=20simply=20strings=20that=20=
display=20a=20hint=20on=20how=20to=20exit.=0Dif=20os.sep=20=3D=3D=20':':=0D=
=20=20=20=20exit=20=3D=20'Use=20Cmd-Q=20to=20quit.'=0Delif=20os.sep=20=3D=3D=
=20'\\':=0D=20=20=20=20exit=20=3D=20'Use=20Ctrl-Z=20plus=20Return=20to=20=
exit.'=0Delse:=0D=20=20=20=20exit=20=3D=20'Use=20Ctrl-D=20(i.e.=20EOF)=20=
to=20exit.'=0Dimport=20__builtin__=0D__builtin__.quit=20=3D=20=
__builtin__.exit=20=3D=20exit=0Ddel=20exit=0D=0D#=20interactive=20prompt=20=
objects=20for=20printing=20the=20license=20text,=20a=20list=20of=0D#=20=
contributors=20and=20the=20copyright=20notice.=0Dclass=20_Printer:=0D=20=20=
=20=20MAXLINES=20=3D=2023=0D=0D=20=20=20=20def=20__init__(self,=20name,=20=
data,=20files=3D(),=20dirs=3D()):=0D=20=20=20=20=20=20=20=20self.__name=20=
=3D=20name=0D=20=20=20=20=20=20=20=20self.__data=20=3D=20data=0D=20=20=20=
=20=20=20=20=20self.__files=20=3D=20files=0D=20=20=20=20=20=20=20=20=
self.__dirs=20=3D=20dirs=0D=20=20=20=20=20=20=20=20self.__lines=20=3D=20=
None=0D=0D=20=20=20=20def=20__setup(self):=0D=20=20=20=20=20=20=20=20if=20=
self.__lines:=0D=20=20=20=20=20=20=20=20=20=20=20=20return=0D=20=20=20=20=
=20=20=20=20data=20=3D=20None=0D=20=20=20=20=20=20=20=20for=20dir=20in=20=
self.__dirs:=0D=20=20=20=20=20=20=20=20=20=20=20=20for=20file=20in=20=
self.__files:=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20file=20=3D=
=20os.path.join(dir,=20file)=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20try:=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
fp=20=3D=20open(file)=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20data=20=3D=20fp.read()=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20fp.close()=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20break=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20except=20IOError:=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20pass=0D=20=20=20=20=20=20=20=20=20=20=20=20if=20data:=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20break=0D=20=20=20=20=20=20=20=20=
if=20not=20data:=0D=20=20=20=20=20=20=20=20=20=20=20=20data=20=3D=20=
self.__data=0D=20=20=20=20=20=20=20=20self.__lines=20=3D=20=
data.split('\n')=0D=20=20=20=20=20=20=20=20self.__linecnt=20=3D=20=
len(self.__lines)=0D=0D=20=20=20=20def=20__repr__(self):=0D=20=20=20=20=20=
=20=20=20self.__setup()=0D=20=20=20=20=20=20=20=20if=20len(self.__lines)=20=
<=3D=20self.MAXLINES:=0D=20=20=20=20=20=20=20=20=20=20=20=20return=20=
"\n".join(self.__lines)=0D=20=20=20=20=20=20=20=20else:=0D=20=20=20=20=20=
=20=20=20=20=20=20=20return=20"Type=20%s()=20to=20see=20the=20full=20%s=20=
text"=20%=20((self.__name,)*2)=0D=0D=20=20=20=20def=20__call__(self):=0D=20=
=20=20=20=20=20=20=20self.__setup()=0D=20=20=20=20=20=20=20=20prompt=20=3D=
=20'Hit=20Return=20for=20more,=20or=20q=20(and=20Return)=20to=20quit:=20=
'=0D=20=20=20=20=20=20=20=20lineno=20=3D=200=0D=20=20=20=20=20=20=20=20=
while=201:=0D=20=20=20=20=20=20=20=20=20=20=20=20try:=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20for=20i=20in=20range(lineno,=20lineno=20+=20=
self.MAXLINES):=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20print=20self.__lines[i]=0D=20=20=20=20=20=20=20=20=20=20=20=20except=20=
IndexError:=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20break=0D=20=
=20=20=20=20=20=20=20=20=20=20=20else:=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20lineno=20+=3D=20self.MAXLINES=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20key=20=3D=20None=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20while=20key=20is=20None:=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20key=20=3D=20raw_input(prompt)=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20if=20key=20not=20in=20('',=20=
'q'):=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20key=20=3D=20None=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
if=20key=20=3D=3D=20'q':=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20break=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20);=20start=20=3D=20time.time()=0Dprint=20=
"printing=20credits"=0D=0D__builtin__.copyright=20=3D=20=
_Printer("copyright",=20sys.copyright)=0Dif=20sys.platform[:4]=20=3D=3D=20=
'java':=0D=20=20=20=20__builtin__.credits=20=3D=20_Printer(=0D=20=20=20=20=
=20=20=20=20"credits",=0D=20=20=20=20=20=20=20=20"Jython=20is=20=
maintained=20by=20the=20Jython=20developers=20(www.jython.org).")=0D=
else:=0D=20=20=20=20__builtin__.credits=20=3D=20_Printer("credits",=20=
"""\=0DThanks=20to=20CWI,=20CNRI,=20BeOpen.com,=20Digital=20Creations=20=
and=20a=20cast=20of=20thousands=0Dfor=20supporting=20Python=20=
development.=20=20See=20www.python.org=20for=20more=20information.""")=0D=
here=20=3D=20os.path.dirname(os.__file__)=0D__builtin__.license=20=3D=20=
_Printer(=0D=20=20=20=20"license",=20"See=20=
http://www.python.org/%.3s/license.html"=20%=20sys.version,=0D=20=20=20=20=
["LICENSE.txt",=20"LICENSE"],=0D=20=20=20=20[os.path.join(here,=20=
os.pardir),=20here,=20os.curdir])=0D=0D=0D#=20Define=20new=20built-in=20=
'help'.=0D#=20This=20is=20a=20wrapper=20around=20pydoc.help=20(with=20a=20=
twist).=0Dclass=20_Helper:=0D=20=20=20=20def=20__repr__(self):=0D=20=20=20=
=20=20=20=20=20return=20"Type=20help()=20for=20interactive=20help,=20"=20=
\=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20"or=20help(object)=20=
for=20help=20about=20object."=0D=20=20=20=20def=20__call__(self,=20=
*args,=20**kwds):=0D=20=20=20=20=20=20=20=20import=20pydoc=0D=20=20=20=20=
=20=20=20=20return=20pydoc.help(*args,=20**kwds)=0Dprint=20"elapsed=20=
time=20is:=20%.2f=20seconds"%(time.time()-start,=20);=20start=20=3D=20=
time.time()=0Dprint=20"defining=20new=20help"=0D=0D__builtin__.help=20=3D=20=
_Helper()=0D=0D=0D#=20Set=20the=20string=20encoding=20used=20by=20the=20=
Unicode=20implementation.=20=20The=0D#=20default=20is=20'ascii',=20but=20=
if=20you're=20willing=20to=20experiment,=20you=20can=0D#=20change=20=
this.=0D=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20);=20start=20=3D=20time.time()=0Dprint=20=
"setting=20string=20encoding"=0D=0Dencoding=20=3D=20"ascii"=20#=20=
Default=20value=20set=20by=20_PyUnicode_Init()=0D=0Dif=200:=0D=20=20=20=20=
#=20Enable=20to=20support=20locale=20aware=20default=20string=20=
encodings.=0D=20=20=20=20import=20locale=0D=20=20=20=20loc=20=3D=20=
locale.getdefaultlocale()=0D=20=20=20=20if=20loc[1]:=0D=20=20=20=20=20=20=
=20=20encoding=20=3D=20loc[1]=0D=0Dif=200:=0D=20=20=20=20#=20Enable=20to=20=
switch=20off=20string=20to=20Unicode=20coercion=20and=20implicit=0D=20=20=
=20=20#=20Unicode=20to=20string=20conversion.=0D=20=20=20=20encoding=20=3D=
=20"undefined"=0D=0Dif=20encoding=20!=3D=20"ascii":=0D=20=20=20=20#=20On=20=
Non-Unicode=20builds=20this=20will=20raise=20an=20AttributeError...=0D=20=
=20=20=20sys.setdefaultencoding(encoding)=20#=20Needs=20Python=20Unicode=20=
build=20!=0D=0D#=0D#=20Run=20custom=20site=20specific=20code,=20if=20=
available.=0D#=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20);=20start=20=3D=20time.time()=0Dprint=20=
"trying=20to=20import=20sitecustomize"=0D=0Dtry:=0D=20=20=20=20import=20=
sitecustomize=0Dexcept=20ImportError:=0D=20=20=20=20pass=0D=0D#=0D#=20=
Remove=20sys.setdefaultencoding()=20so=20that=20users=20cannot=20change=20=
the=0D#=20encoding=20after=20initialization.=20=20The=20test=20for=20=
presence=20is=20needed=20when=0D#=20this=20module=20is=20run=20as=20a=20=
script,=20because=20this=20code=20is=20executed=20twice.=0D#=0Dprint=20=
"elapsed=20time=20is:=20%.2f=20seconds"%(time.time()-start,=20);=20start=20=
=3D=20time.time()=0Dprint=20"removing=20sys.setdefaultencoding()"=0Dif=20=
hasattr(sys,=20"setdefaultencoding"):=0D=20=20=20=20del=20=
sys.setdefaultencoding=0D=0Ddef=20_test():=0D=20=20=20=20print=20=
"sys.path=20=3D=20["=0D=20=20=20=20for=20dir=20in=20sys.path:=0D=20=20=20=
=20=20=20=20=20print=20"=20=20=20=20%s,"=20%=20`dir`=0D=20=20=20=20print=20=
"]"=0Dprint=20"elapsed=20time=20is:=20%.2f=20=
seconds"%(time.time()-start,=20)=0D=0Dif=20__name__=20=3D=3D=20=
'__main__':=0D=20=20=20=20_test()=0D=

--Apple-Mail-2--91202036
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed





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


--Apple-Mail-2--91202036--



From jimleff@chowhound.com  Sat Nov  2 07:53:28 2002
From: jimleff@chowhound.com (Jim Leff)
Date: Sat, 2 Nov 2002 02:53:28 -0500
Subject: [Pythonmac-SIG] Cool Script, Not Sure What To Do With It
Message-ID: <v04220801b9e932203ec2@[12.89.159.48]>

Hi guys

I'm not a programmer, and am sitting here with thousands of 
unfathomable macpython components and no idea how to make it do what 
I want: run one very cool script.

It's a script of great interest to writers, who are afflicted by 
overused words. It's really easy to repeat a word once or more within 
a paragraph or two, which makes things read fuzzy and amateurish. 
It's notoriously difficult to detect such repetition even upon 
careful checking, and there are no tools I know of to help with this. 
But this ingenious script does it.

Can anyone tell me how to use Macpython (2.2.1) to make it run and 
check out text files? I'm not a subscriber to the list, so please 
copy me if you reply. The script is by Jeremy Osner, and it's 
freeware. Feel free to distribute/use as you like. If you write, 
checking for repetition will improve your output significantly, I 
promise (I'm a published author FWIW).


Instructions from Jeremy:

>To use it, just type at the command prompt (or whatever the Mac OS 
>equivalent of a command prompt is), "python <filename> <interval> 
><exclude> < <input>" where <filename> is the name you saved the 
>script file as, <interval> is the max. number of words between 
>repetitions to be flagged, <exclude> is the name of a file with a 
>list of words you want to have excluded from being flagged, and 
><input> is the file you want to parse. The commands output will be 
>the same as input except all pertinent repetitions will be enclosed 
>in a pair of asterisks.


Here's the script. If anyone prefers it as a text file, let me know.


#! /usr/bin/env python
import sys
import string

def simplify(word):
     return string.lower(string.translate(word, string.maketrans('', 
''), string.punctuation))

def words(str):
     result = string.split(str)
     for i in range(len(result)):
         result[i] = simplify(result[i])
     return result

recentWords = []
excludeWords = []
queueSize = 10
if len(sys.argv) > 1:
     queueSize = int(sys.argv[1])
     if len(sys.argv) > 2:
         excludeWords = words(open(sys.argv[2]).read())
input = sys.stdin.readline()
while input != "":
     a = input.split()
     for word in a:
         simp = simplify(word)
         if excludeWords.count(simp) == 0:
             if recentWords.count(simp) > 0:
                 recentWords.remove(simp)
                 word = "*" + word + "*"
             recentWords.append(simp)
             if len(recentWords) > queueSize:
                 recentWords.pop(0)
         sys.stdout.write(word + " ")
     sys.stdout.write("\n")
     input = sys.stdin.readline()



From jjb5@cornell.edu  Sun Nov  3 23:42:32 2002
From: jjb5@cornell.edu (Joel Bender)
Date: Sun, 3 Nov 2002 18:42:32 -0500
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <B9E473E9.7001%niel_mayhew@mac.com>
References: <B9E473E9.7001%niel_mayhew@mac.com>
Message-ID: <p05100300b9eb601cdd1a@[192.168.1.100]>

Here are my test results, PowerBook G4, 500MHz, MacOS 9.2.2, 256M 
RAM.  The first time I did the 'import test.regrtest; 
test.regrtest.main()' dance everything quit and the machine froze. 
After rebooting and trying again, the test froze after displaying 
test_xmlrpc.  Third time is a charm, here are the results:


153 tests OK.
5 tests failed:
     test_frozen test_longexp test_socket test_unicode test_zlib
35 tests skipped:
     test_al test_atexit test_bsddb test_cd test_cl test_commands
     test_crypt test_curses test_dbm test_dl test_email_codecs
     test_fcntl test_fork1 test_gl test_grp test_imgfile test_largefile
     test_linuxaudiodev test_locale test_mmap test_nis test_openpty
     test_poll test_popen2 test_pty test_pwd test_signal
     test_socket_ssl test_socketserver test_sunaudiodev
     test_threaded_import test_timing test_unicode_file test_winreg
     test_winsound
2 skips unexpected on mac:
     test_threaded_import test_atexit
Traceback (most recent call last):
   File "<input>", line 1, in ?
   File "Macintosh HD:Applications (Mac OS 9):Python 
2.2.2:Lib:test:regrtest.py", line 249, in main
     sys.exit(len(bad) > 0)
SystemExit: 1
>>>


Joel
-- 


From dev@brotsky.com  Mon Nov  4 07:32:17 2002
From: dev@brotsky.com (Dan Brotsky)
Date: Sun, 3 Nov 2002 23:32:17 -0800
Subject: [Pythonmac-SIG] MacPython 2.2.2 - third final candidate
In-Reply-To: <3DC025D1.43A7B852@noaa.gov>
Message-ID: <8BD5B852-EFC7-11D6-A56A-0003931036B4@brotsky.com>

On Wednesday, October 30, 2002, at 10:32 AM, Chris Barker wrote:
>>> 3 tests failed:
>>>     test_frozen test_math test_socket
>
> test_math failed? That's wierd, and I'd think something to be concerned
> about!

I'll leave it to others to figure if I should be concerned:

 >>> math.sqrt(-1)
nan

which suggests that the following comment from the math_test lib is 
relevant:

     # If this fails, it could be a puzzle.  One odd possibility is that
     # mathmodule.c's macros are getting confused while comparing
     # Inf (HUGE_VAL) to a NaN, and artificially setting errno to ERANGE
     # as a result (and so raising OverflowError instead).

Jack, should I be worried?

     dan



From kevino@tulane.edu  Mon Nov  4 16:45:03 2002
From: kevino@tulane.edu (Kevin Ollivier)
Date: Mon, 4 Nov 2002 11:45:03 -0500
Subject: [Pythonmac-SIG] MachoPython and os.getbootvol()?
Message-ID: <C46AD106-F014-11D6-BE6F-003065F40094@tulane.edu>

Hi all,

Let me start off by explaining what I am trying to do. =) I'm running 
MachoPython downloaded from the wxPython sourceforge site. I have a 
wxPython application (that's why I'm using MachoPython) and I'm working 
on an "import" function which imports an HTML page into the user's 
project folder. When I do this, I would like to also copy over any 
associated image or http links stored locally so the links don't break. 
(if the file is an internet link, like www.address.com, I don't mess 
with it.)

I'm now trying to implement support for absolute links. (i.e. 
file:///mydir/myfile.ext) The problem is that packages like Dreamweaver 
create links like so: "file:///Macintosh HD/Users/myname/myfile.ext". Of 
course, "Macintosh HD" is not used to denote the root of the volume 
under OS X, although on OS 9 it is. I tried URLParse and urlretrieve but 
they both fail, so I considered stripping out the boot volume name, if 
it exists in the path. I also tried switching the path separator to ":" 
(i.e. "Macintosh HD:Users:myname:myfile.ext") but os.path.isfile() 
returned false, meaning that I don't think Unix Python interprets Mac 
paths yet.

I know this is still alpha-level (pre-alpha?) software, so I realize 
it's not quite there yet. =) (I'm also trying to see if I can get 
wxPython running on MacPython 2.2.2.) I just thought I'd throw this out 
to see if there are any easy answers I'm missing!

Thanks,

Kevin



From Chris.Barker@noaa.gov  Mon Nov  4 17:59:10 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Mon, 4 Nov 2002 09:59:10 -0800
Subject: [Pythonmac-SIG] MachoPython and os.getbootvol()?
In-Reply-To: <C46AD106-F014-11D6-BE6F-003065F40094@tulane.edu>
Message-ID: <1E9DC99E-F01F-11D6-9D30-000393A96660@noaa.gov>

On Monday, November 4, 2002, at 08:45 AM, Kevin Ollivier wrote:
> I'm now trying to implement support for absolute links. (i.e. 
> file:///mydir/myfile.ext) The problem is that packages like 
> Dreamweaver create links like so: "file:///Macintosh 
> HD/Users/myname/myfile.ext".

Your fundamental problem is that you shouldn't use absolute pathnames 
at all, except for the call into the project dir in the beginning.

That being said, you certianly are faced with dealing with them once in 
a while.

>  Of course, "Macintosh HD" is not used to denote the root of the 
> volume under OS X, although on OS 9 it is.

"Macintosh HD" is the essentially "/" from the Unix side. I'd do a 
simple: filepath.replace("/Macintosh HD/", "/")

that, of course will break as soon as someone re-names theor main HD, 
but that's a problem with the old-style mac path as well. all I can 
say, is that the Unix standard for paths, and mounting drives on one 
big file system, really is a much better way to go!

>  I tried URLParse and urlretrieve but they both fail, so I considered 
> stripping out the boot volume name

did this really not work?? What happened? are you trying to do an 
os.path.something on a pathname with the "file://" st the beginning? 
this will fail, at the file://.. is a url, not a pathname. try stipping 
off the file:// as well.


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 niel_mayhew@mac.com  Mon Nov  4 19:15:33 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Mon, 04 Nov 2002 12:15:33 -0700
Subject: [Pythonmac-SIG] Re: MacPython 2.2.2 final candidate
In-Reply-To: <AE35C028-EDFC-11D6-8695-000393A96660@noaa.gov>
Message-ID: <B9EC1565.70D4%niel_mayhew@mac.com>

Chris (and anyone else with a DP machine),

Try this:

import sys, os, time

for dir in sys.path:
    start = time.time()
    os.stat(dir)
    print "%.2f %s" % (time.time() - start, dir)

I created a file with these lines in it (test.py), used EditPythonPrefs to
permanently set the options for PythonInterpreter to ignore site-python, and
dropped the test.py file onto PythonInterpreter. The average over five runs
was:

1.59  ...:Applications:Developer:Python 2.2.2:Lib
0.81  ...:Applications:Developer:Python 2.2.2:Mac:Lib
0.61  ...:Applications:Developer:Python 2.2.2:Lib:lib-dynload
0.35  ...:Applications:Developer:Python 2.2.2:
0.08  ...:Applications:Developer:Python 2.2.2:Extensions:img:Mac
0.06  ...:Applications:Developer:Python 2.2.2:Extensions:Imaging
0.06  ...:Applications:Developer:Python 2.2.2:Lib:lib-tk
0.05  ...:Applications:Developer:Python 2.2.2:Mac:Lib:lib-compat
0.04  ...:Desktop:
0.00  ...:Applications:Developer:Python 2.2.2:Mac:Lib:lib-scriptpackages
0.00  ...:Applications:Developer:Python 2.2.2:Extensions:img:Lib
0.00  ...:Applications:Developer:Python 2.2.2:Lib:site-packages
----
3.65

Since os.stat is a builtin, I can't analyze this any further.

I have tried it with 2.2.1, and I get similar results (when it works). I
feel sure this didn't happen with one of the pre-releases that Jack sent
out, but I can't remember which one, and the installers aren't there any
more. The 222b1 installer I do still have has expired and won't run.

I am using a 2x1.25GHz machine with 1Gb of RAM.

--Neil

--
Neil Mayhew
Calgary, Alberta, Canada
niel_mayhew@mac.com

(Email address deliberately misspelled to foil spammers)



From Jack.Jansen@cwi.nl  Tue Nov  5 10:46:17 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 5 Nov 2002 11:46:17 +0100
Subject: [Pythonmac-SIG] MacPython 2.2.2 multiprocessor slowdown
In-Reply-To: <B9EC1565.70D4%niel_mayhew@mac.com>
Message-ID: <CFE20683-F0AB-11D6-8433-0030655234CE@cwi.nl>

I tried Neil's script on a uniprocessor, and I don't see such drastic 
times, but still stat() can take a long time:
0.01 Sap-extra:Users:jack:Desktop:
0.01 Sap-extra:Applications:Python 2.2.2
0.02 Sap-extra:Applications:Python 2.2.2:Mac:Lib
0.02 Sap-extra:Applications:Python 2.2.2:Mac:Lib:lib-compat
0.00 Sap-extra:Applications:Python 2.2.2:Mac:Lib:lib-scriptpackages
0.01 Sap-extra:Applications:Python 2.2.2:Lib:lib-dynload
0.11 Sap-extra:Applications:Python 2.2.2:Lib
0.01 Sap-extra:Applications:Python 2.2.2:Extensions:img:Mac
0.00 Sap-extra:Applications:Python 2.2.2:Extensions:img:Lib
0.01 Sap-extra:Applications:Python 2.2.2:Extensions:Imaging
0.01 Sap-extra:Applications:Python 2.2.2:Lib:lib-tk
0.00 Sap-extra:Applications:Python 2.2.2:Lib:site-packages
0.01 Sap-extra:Applications:Python 2.2.2:lib:site-packages:Numeric

At least, I think that .1 second for an os.stat() call is rather a long 
time...

I also tried the test script with with the Carbon PythonInterpreter 
running under classic, and I tried it with the classic interpreter. All 
three results were more or less the same. As a sanity check I tried it 
with the unix interpreter, and of course there all times were 0.00 
seconds.

Maybe someone with a multiprocessor can try the timing script with both 
the carbon and the classic interpreter running under the classic 
environment?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From niel_mayhew@mac.com  Tue Nov  5 19:02:03 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Tue, 05 Nov 2002 12:02:03 -0700
Subject: [Pythonmac-SIG] MacPython 2.2.2 multiprocessor slowdown
In-Reply-To: <CFE20683-F0AB-11D6-8433-0030655234CE@cwi.nl>
Message-ID: <B9ED63BB.7109%niel_mayhew@mac.com>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3119342523_31064981
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

on 05/11/2002 3:46 AM, Jack Jansen wrote:

> Maybe someone with a multiprocessor can try the timing script with both
> the carbon and the classic interpreter running under the classic
> environment?

Yikes! Look at these times (averaged over several runs):

Carbon-in-Classic (Carbon Python running in Classic)
21.23 $(PYTHON):Lib
 5.65 $(PYTHON):Mac:Lib
 4.56 $(PYTHON):Mac:Lib:lib-compat
 3.58 $(PYTHON):Lib:lib-dynload
 2.42 $(PYTHON):Extensions:img:Mac
 1.46 $(PYTHON)
 1.45 $(PYTHON):Lib:lib-tk
 1.39 $(PYTHON):
 1.31 $(PYTHON):lib:site-packages:Numeric
 0.94 :
 0.84 $(PYTHON):Extensions:Imaging
 0.74 $(PYTHON):Lib:site-packages
 0.71 $(PYTHON):Mac:Lib:lib-scriptpackages
 0.66 $(PYTHON):Extensions:img:Lib
46.93

The other results are as follows:

Classic-in-Classic (Classic Python running in Classic)
 0.07 $(PYTHON):Lib
 0.02 $(PYTHON):Mac:Lib:lib-compat
 0.02 $(PYTHON):Mac:Lib
 0.01 $(PYTHON):Extensions:img:Mac
 0.01 $(PYTHON):lib:site-packages:Numeric
 0.01 $(PYTHON)
 0.01 $(PYTHON):Lib:lib-dynload
 0.01 $(PYTHON):Lib:lib-tk
 0.00 $(PYTHON):Lib:site-packages
 0.00 $(PYTHON):Extensions:img:Lib
 0.00 $(PYTHON):Extensions:Imaging
 0.00 :
 0.00 $(PYTHON):Mac:Lib:lib-scriptpackages
 0.17

Carbon-in-X (Carbon Python running in X)
 1.46 $(PYTHON):Lib
 0.65 $(PYTHON):Mac:Lib
 0.60 $(PYTHON):Lib:lib-dynload
 0.30 $(PYTHON):
 0.07 $(PYTHON):Lib:lib-tk
 0.07 $(PYTHON):Mac:Lib:lib-compat
 0.06 $(PYTHON):Extensions:img:Mac
 0.05 $(PYTHON):Extensions:Imaging
 0.05 :
 0.01 $(PYTHON):Mac:Lib:lib-scriptpackages
 0.00 $(PYTHON):Lib:site-packages
 0.00 $(PYTHON):Extensions:img:Lib
 3.34

So the Classic-in-Classic results are pretty much as they should be.

However, I did notice that the Carbon-in-Classic times are greatly affected
by switching back and forth between PythonInterpreter and (eg) Finder during
the run, bringing them into line with the X-Carbon results, and sometimes a
good bit better.

Could this be due to PythonInterpreter running on the second processor, or
due to the different WaitNextEvent timeslicing that Mac OS 9 uses for
foreground and background processes?

One other tiny detail that I noticed: for Classic-in-Classic, sys.path[1],
which is the top-level Python directory, does not end in a colon, whereas
for the two Carbon ones it does.

In case anyone else wants to try these tests, I have attached my collation
script.

HTH,

--Neil

--
Neil Mayhew
Calgary, Alberta, Canada
niel_mayhew@mac.com

(Email address deliberately misspelled to foil spammers)


--B_3119342523_31064981
Content-type: multipart/appledouble; boundary="B_3119342249_31077220"


--B_3119342249_31077220
Content-type: application/applefile; name="Collate.py"
Content-transfer-encoding: base64
Content-disposition: attachment

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAACAAAAADAAAAXgAAAAoAAAAC
AAAAaAAAAhxURVhUUGlkZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENvbGxhdGUucHkAAAEA
AAAB2gAAANoAAABCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1ntzCwAAAHJ1bl9hc19t
YWluaQAAAABzCQAAAHNlbGVjdGlvbigCAAAAaQMCAABpAwIAAHMHAAAAdGFic2l6ZSgCAAAA
aQQAAABpAQAAAHMMAAAAd2luZG93Ym91bmRzKAQAAABpHAAAAGlUAAAAaeACAABpjwMAAHMM
AAAAZm9udHNldHRpbmdzKAQAAABzBgAAAEdlbmV2YWkAAAAAaQoAAAAoAwAAAGkAAAAAaQAA
AABpAAAAAHMUAAAAcnVuX3dpdGhfaW50ZXJwcmV0ZXJpAAAAADAAAAEAAAAB2gAAANoAAABC
AA6ODAFfAIAAHAAyAABQeVdTAAAACgCAAAAAAAAAAcUbuA93aW5kb3cgc2V0dGluZ3M=

--B_3119342249_31077220
Content-type: text/plain; name="Collate.py";
 x-mac-creator="50696465";
 x-mac-type="54455854"
Content-disposition: attachment
Content-transfer-encoding: base64

IyEvdXNyL2Jpbi9lbnYgcHl0aG9uDQ0iIiJDb2xsYXRlIHRpbWluZyByZXN1bHRzDQ1JbnN0
cnVjdGlvbnM6DQkNUnVuIHRoZSB0aW1pbmcgdGVzdCBzZXZlcmFsIHRpbWVzLCBhbmQgc2F2
ZSB0aGUgb3V0cHV0IGluIGZpbGVzIG5hbWVkDU91dHB1dDEsIE91dHB1dDIgZXRjLiwgdXNp
bmcgYSBzZXBhcmF0ZSBkaXJlY3RvcnkgZm9yIGVhY2ggdHlwZSBvZiB0ZXN0Lg1UaGVuIHJ1
biB0aGlzIHNjcmlwdC4gVGhlIHJlc3VsdHMgZm9yIGVhY2ggZGlyZWN0b3J5IHdpbGwgYmUg
d3JpdHRlbiB0bw1hIGZpbGUgbmFtZWQgUmVzdWx0cy4NDUlmIHlvdSBydW4gdGhpcyBzY3Jp
cHQgZnJvbSB0aGUgSURFLCBpdCB3aWxsIGxvb2sgZm9yIHRoZSBmb2xsb3dpbmcgZGlyZWN0
b3JpZXM6DVsiQ2FyYm9uLWluLVgiLCAiQ2FyYm9uLWluLUNsYXNzaWMiLCAiQ2xhc3NpYy1p
bi1DbGFzc2ljIl0NDUlmIHlvdSBjcmVhdGUgYW4gYXBwbGV0LCBqdXN0IGRyb3AgdGhlIHN1
YmRpcmVjdG9yaWVzIG9udG8gaXQuDQ1OZWlsIE1heWhld0BtYWMuY29tIC0gNSBOb3YgMjAw
MiIiIg0NaW1wb3J0IHN5cywgb3MNaW1wb3J0IGdsb2INaW1wb3J0IHN0cmluZw0NZGVmIHBy
b2Nlc3MoZGlyKToNCXJlc3VsdHMgPSBvcGVuKG9zLnBhdGguam9pbihkaXIsICJSZXN1bHRz
IiksICJ3IikNCQ0JUFlUSE9OID0gc3lzLnByZWZpeFs6LTFdDQlET1QgPSBzeXMucGF0aFsw
XQ0JDQlwcmludCA+PiByZXN1bHRzLCBkaXINCXByaW50ID4+IHJlc3VsdHMsICIkKFBZVEhP
TikgPSAlcyIgJSBQWVRIT04NCXByaW50ID4+IHJlc3VsdHMsICIkKERPVCkgPSAlcyIgJSBE
T1QNDQlzdGF0cyA9IHt9DQlmaWxlcyA9ICBnbG9iLmdsb2Iob3MucGF0aC5qb2luKGRpciwg
Ik91dHB1dCoiKSkNCWNvdW50ID0gbGVuKGZpbGVzKQ0JDQlmb3IgbyBpbiBmaWxlczoNCQlm
ID0gb3BlbihvKQ0JCWZvciBsIGluIGYucmVhZGxpbmVzKCk6DQkJCWwgPSBzdHJpbmcuc3Ry
aXAobCkNCQkJdCwgZCA9IHN0cmluZy5zcGxpdChsLCBOb25lLCAxKQ0JCQl0ID0gZmxvYXQo
dCkNCQkJaWYgbm90IHN0YXRzLmhhc19rZXkoZCk6DQkJCQlzdGF0c1tkXSA9IHQNCQkJZWxz
ZToNCQkJCXN0YXRzW2RdICs9IHQNCQlmLmNsb3NlKCkNCQ0JZGVmIHNpZ24oeCk6DQkJaWYg
eCA+IDA6DQkJCXJldHVybiAxDQkJZWxpZiB4IDwgMDoNCQkJcmV0dXJuIC0xDQkJZWxzZToN
CQkJcmV0dXJuIDANCQ0JZGVmIHNvcnRfdmFsdWVzKGRpY3QpOg0JCWtleXMgPSBkaWN0Lmtl
eXMoKQ0JCWtleXMuc29ydChsYW1iZGEgYSwgYjogY21wKGRpY3RbYV0sIGRpY3RbYl0pKQ0J
CXJldHVybiBrZXlzDQkNCWRpcnMgPSBzb3J0X3ZhbHVlcyhzdGF0cykNCWRpcnMucmV2ZXJz
ZSgpDQkNCXRvdGFsID0gMA0JDQlmb3IgZCBpbiBkaXJzOg0JCXQgPSBzdGF0c1tkXQ0JCWlm
IHN0cmluZy5maW5kKGQsIFBZVEhPTikgPT0gMDoNCQkJZCA9IHN0cmluZy5yZXBsYWNlKGQs
IFBZVEhPTiwgJyQoUFlUSE9OKScsIDEpDQkJaWYgc3RyaW5nLmZpbmQoZCwgRE9UKSA9PSAw
Og0JCQlkID0gc3RyaW5nLnJlcGxhY2UoZCwgRE9ULCAnJykNCQlwcmludCA+PiByZXN1bHRz
LCAiJTUuMmYgJXMiICUgKHQgLyBjb3VudCwgZCkNCQl0b3RhbCArPSB0IC8gY291bnQNCQ0J
cHJpbnQgPj4gcmVzdWx0cywgIiU1LjJmIiAlIHRvdGFsDQkNCXJlc3VsdHMuY2xvc2UoKQ0N
ZGVmIG1haW4oKToNCWRpcnMgPSBzeXMuYXJndlsxOl0gb3IgJy4nDQlmb3IgZCBpbiBkaXJz
Og0JCXByb2Nlc3MoZCkNDWRlZiB0ZXN0KCk6DQlzeXMuYXJndi5leHRlbmQoWyJDYXJib24t
aW4tWCIsICJDYXJib24taW4tQ2xhc3NpYyIsICJDbGFzc2ljLWluLUNsYXNzaWMiXSkNCW1h
aW4oKQ0NaWYgX19uYW1lX18gPT0gIl9fbWFpbl9fIjoNCW1haW4oKQ1lbHNlOg0JdGVzdCgp
DQ==


--B_3119342249_31077220--


--B_3119342523_31064981--




From owen@astro.washington.edu  Wed Nov  6 00:54:57 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Tue, 5 Nov 2002 16:54:57 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
Message-ID: <p05200f00b9ee175a1be1@[128.95.99.44]>

I tried to build MachoPython 2.2.2 with aqua Tk and ran into a snag: 
Tkinter acts oddly.

- Tcl/Tk 8.4.1 built just fine and Wish Shell seems to run (I've not 
done anything much with it, just launched it).
- Python built just fine, as well. I modified setup.py to what I 
believe are the CVS patches to setup.py so it can find aqua Tk and 
then did the usual ./configure, make, sudo make install dance.
- make test worked fine (just as well as for 2.2.1; test_sax and test_pyexpat
are unexpectedly skipped)

- However, the aqua Tkinter fails strangely:
% python
Python 2.2.2 (#1, Nov  5 2002, 15:52:41)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>  from Tkinter import *
>>>  root = Tk()
this puts up a Tk root window, as usual, but whenever I try to click 
on the Tk window, I get:
>>>  SetFrontProcess failed,-606

I've tried running larger Tkinter applications and get the same 
thing. The Tkinter application occasionally responds if you click 
often enough, but basically it always stays in the background.

Any hints?

-- Russell

P.S. I plan to post instructions if/when I figure this out. I have 
the page all ready to go except for this serious setback.


From jwblist@olympus.net  Wed Nov  6 03:49:08 2002
From: jwblist@olympus.net (John W Baxter)
Date: Tue, 5 Nov 2002 19:49:08 -0800
Subject: [Pythonmac-SIG] MachoPython and os.getbootvol()?
In-Reply-To: <1E9DC99E-F01F-11D6-9D30-000393A96660@noaa.gov>
References: <1E9DC99E-F01F-11D6-9D30-000393A96660@noaa.gov>
Message-ID: <p05200f02b9ee4093b0ee@[192.168.1.50]>

At 9:59 -0800 11/4/2002, Chris Barker wrote:
>"Macintosh HD" is the essentially "/" from the Unix side. I'd do a
>simple: filepath.replace("/Macintosh HD/", "/")
>
>that, of course will break as soon as someone re-names theor main HD,
>but that's a problem with the old-style mac path as well. all I can
>say, is that the Unix standard for paths, and mounting drives on one
>big file system, really is a much better way to go!

I've never had a "Macintosh HD" for more than 10 minutes or so.

  --John

-- 
John Baxter   jwblist@olympus.net      Port Ludlow, WA, USA


From brian_l@mac.com  Wed Nov  6 04:38:39 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Tue, 5 Nov 2002 20:38:39 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <p05200f00b9ee175a1be1@[128.95.99.44]>
Message-ID: <9F2AC21A-F141-11D6-9BD6-003065F88956@mac.com>

On Tuesday, November 5, 2002, at 04:54  PM, Russell E Owen wrote:

> I tried to build MachoPython 2.2.2 with aqua Tk and ran into a snag:  
> Tkinter acts oddly.

> this puts up a Tk root window, as usual, but whenever I try to click  
> on the Tk window, I get:
>>>>  SetFrontProcess failed,-606

Add add a shell script named pythonw to /usr/local/bin or somewhere  
else in your PATH

#!/bin/sh
exec  
/Library/Frameworks/Python.framework/Versions/Current/Resources/ 
Python.app/Contents/MacOS/python "$@"

use pythonw to launch GUI apps.



From stever@gate.net  Wed Nov  6 05:58:52 2002
From: stever@gate.net (Steve Reeves)
Date: Wed, 6 Nov 2002 00:58:52 -0500
Subject: [Pythonmac-SIG] Adding OS X frameworks to sys.path
Message-ID: <20021106055852.GA24142@skree.com>

In the README for the OS X native Aqua port of Tcl/Tk, I found this:

> - Tcl extensions will be found in any of:
>     $HOME/Library/Tcl /Library/Tcl /Network/Library/Tcl /System/Library/Tcl
>     $HOME/Library/Frameworks /Library/Frameworks /Network/Library/Frameworks
>     /System/Library/Frameworks (searched in that order).
> Given a potential package directory $pkg, Tcl on OSX checks for the file
> $pkg/Resources/Scripts/pkgIndex.tcl as well as $pkg/pkgIndex.tcl (as usual).
> This allows building extensions as frameworks with all script files contained
> in the Resources/Scripts directory of the framework.

Can something like this be added to MachoPython?  The idea of packaging
Python extensions as separate frameworks has a certain appeal.

-- 
Steve Reeves
stever@gate.net


From help@python.org  Wed Nov  6 08:58:54 2002
From: help@python.org (help)
Date: Wed, 6 Nov 2002 09:58:54 +0100 (added by postmaster@dns-oi.com)
Subject: [Pythonmac-SIG] History and License
Message-ID: <3D946F6400026E35@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com)

------=_NextPartTM-000-24d965e4-f031-11d6-a148-0010b586b16d
Content-Type: multipart/alternative;
	boundary=ZBha3QQ5r2566454O1G3BI00SZ12K3qqSpfc

--ZBha3QQ5r2566454O1G3BI00SZ12K3qqSpfc
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:OII55A8G5 height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--ZBha3QQ5r2566454O1G3BI00SZ12K3qqSpfc
--ZBha3QQ5r2566454O1G3BI00SZ12K3qqSpfc
Content-Type: application/octet-stream;
	name=node80.html
Content-Transfer-Encoding: base64
Content-ID: <OII55A8G5>

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+Qi4gSGlzdG9yeSBhbmQgTGljZW5z
ZTwvdGl0bGU+DQo8TUVUQSBOQU1FPSJkZXNjcmlwdGlvbiIgQ09OVEVOVD0iQi4gSGlzdG9y
eSBhbmQgTGljZW5zZSI+DQo8TUVUQSBOQU1FPSJrZXl3b3JkcyIgQ09OVEVOVD0iYXBpIj4N
CjxNRVRBIE5BTUU9InJlc291cmNlLXR5cGUiIENPTlRFTlQ9ImRvY3VtZW50Ij4NCjxNRVRB
IE5BTUU9ImRpc3RyaWJ1dGlvbiIgQ09OVEVOVD0iZ2xvYmFsIj4NCjxtZXRhIGh0dHAtZXF1
aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5
LTEiPg0KPGxpbmsgcmVsPSJTVFlMRVNIRUVUIiBocmVmPSJhcGkuY3NzIj4NCjxsaW5rIHJl
bD0iZmlyc3QiIGhyZWY9ImFwaS5odG1sIj4NCjxsaW5rIHJlbD0iY29udGVudHMiIGhyZWY9
ImNvbnRlbnRzLmh0bWwiIHRpdGxlPSJDb250ZW50cyI+DQo8bGluayByZWw9ImluZGV4IiBo
cmVmPSJnZW5pbmRleC5odG1sIiB0aXRsZT0iSW5kZXgiPg0KPExJTksgUkVMPSJuZXh0IiBo
cmVmPSJnZW5pbmRleC5odG1sIj4NCjxMSU5LIFJFTD0icHJldmlvdXMiIGhyZWY9InJlcG9y
dGluZy1idWdzLmh0bWwiPg0KPExJTksgUkVMPSJ1cCIgSFJFRj0iYXBpLmh0bWwiPg0KPExJ
TksgUkVMPSJuZXh0IiBIUkVGPSJub2RlODEuaHRtbCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxE
SVYgQ0xBU1M9Im5hdmlnYXRpb24iPg0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRoPSIx
MDAlIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiPg0KPHRyPg0KPHRkPjxBIGhy
ZWY9InJlcG9ydGluZy1idWdzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9wcmV2aW91cy5n
aWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJQcmV2aW91cyBQYWdlIiB3
aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxBIEhSRUY9ImFwaS5odG1sIj48aW1nIHNyYz0i
Li4vaWNvbnMvdXAuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iVXAg
T25lIExldmVsIiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxBIEhSRUY9Im5vZGU4MS5o
dG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0
PSIzMiINCiAgYWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQgYWxp
Z249ImNlbnRlciIgd2lkdGg9IjEwMCUiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFs
PC90ZD4NCjx0ZD48QSBocmVmPSJjb250ZW50cy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMv
Y29udGVudHMuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iQ29udGVu
dHMiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PGltZyBzcmM9Ii4uL2ljb25zL2JsYW5r
LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IiIgd2lkdGg9IjMyIj48
L3RkPg0KPHRkPjxBIGhyZWY9ImdlbmluZGV4Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9p
bmRleC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJJbmRleCIgd2lk
dGg9IjMyIj48L0E+PC90ZD4NCjwvdHI+PC90YWJsZT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+
UHJldmlvdXM6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJlZj0icmVwb3J0aW5nLWJ1Z3Mu
aHRtbCI+QS4gUmVwb3J0aW5nIEJ1Z3M8L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPlVwOjwv
Yj4gPGEgY2xhc3M9InNlY3RyZWYiIEhSRUY9ImFwaS5odG1sIj5QeXRob24vQyBBUEkgUmVm
ZXJlbmNlIE1hbnVhbDwvQT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+TmV4dDo8L2I+IDxhIGNs
YXNzPSJzZWN0cmVmIiBIUkVGPSJub2RlODEuaHRtbCI+Qi4xIEhpc3Rvcnkgb2YgdGhlPC9B
Pg0KPGJyPjxocj4NCjwvRElWPg0KPCEtLUVuZCBvZiBOYXZpZ2F0aW9uIFBhbmVsLS0+DQoN
CjxIMT48QSBOQU1FPSJTRUNUSU9OMDAxNDAwMDAwMDAwMDAwMDAwMDAwMCI+DQpCLiBIaXN0
b3J5IGFuZCBMaWNlbnNlPC9BPg0KPC9IMT4NCg0KPHA+PGhyPg0KPCEtLVRhYmxlIG9mIENo
aWxkLUxpbmtzLS0+DQo8QSBOQU1FPSJDSElMRF9MSU5LUyI+PFNUUk9ORz5TdWJzZWN0aW9u
czwvU1RST05HPjwvYT4NCg0KPFVMIENMQVNTPSJDaGlsZExpbmtzIj4NCjxMST48QSBocmVm
PSJub2RlODEuaHRtbCI+Qi4xIEhpc3Rvcnkgb2YgdGhlIHNvZnR3YXJlPC9hPg0KPExJPjxB
IGhyZWY9Im5vZGU4Mi5odG1sIj5CLjIgVGVybXMgYW5kIGNvbmRpdGlvbnMgZm9yIGFjY2Vz
c2luZyBvciBvdGhlcndpc2UgdXNpbmcgUHl0aG9uPC9hPg0KPC91bD4NCjwhLS1FbmQgb2Yg
VGFibGUgb2YgQ2hpbGQtTGlua3MtLT4NCg0KPERJViBDTEFTUz0ibmF2aWdhdGlvbiI+DQo8
cD48aHI+DQo8dGFibGUgYWxpZ249ImNlbnRlciIgd2lkdGg9IjEwMCUiIGNlbGxwYWRkaW5n
PSIwIiBjZWxsc3BhY2luZz0iMiI+DQo8dHI+DQo8dGQ+PEEgaHJlZj0icmVwb3J0aW5nLWJ1
Z3MuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL3ByZXZpb3VzLmdpZiINCiAgYm9yZGVyPSIw
IiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlByZXZpb3VzIFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwv
dGQ+DQo8dGQ+PEEgSFJFRj0iYXBpLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy91cC5naWYi
DQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJVcCBPbmUgTGV2ZWwiIHdpZHRo
PSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEgSFJFRj0ibm9kZTgxLmh0bWwiPjxpbWcgc3JjPSIu
Li9pY29ucy9uZXh0LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9Ik5l
eHQgUGFnZSIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZCBhbGlnbj0iY2VudGVyIiB3aWR0
aD0iMTAwJSI+UHl0aG9uL0MgQVBJIFJlZmVyZW5jZSBNYW51YWw8L3RkPg0KPHRkPjxBIGhy
ZWY9ImNvbnRlbnRzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9jb250ZW50cy5naWYiDQog
IGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJDb250ZW50cyIgd2lkdGg9IjMyIj48
L0E+PC90ZD4NCjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lmIg0KICBib3JkZXI9
IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+DQo8dGQ+PEEgaHJl
Zj0iZ2VuaW5kZXguaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2luZGV4LmdpZiINCiAgYm9y
ZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkluZGV4IiB3aWR0aD0iMzIiPjwvQT48L3Rk
Pg0KPC90cj48L3RhYmxlPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5QcmV2aW91czo8L2I+IDxh
IGNsYXNzPSJzZWN0cmVmIiBocmVmPSJyZXBvcnRpbmctYnVncy5odG1sIj5BLiBSZXBvcnRp
bmcgQnVnczwvQT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+VXA6PC9iPiA8YSBjbGFzcz0ic2Vj
dHJlZiIgSFJFRj0iYXBpLmh0bWwiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFsPC9B
Pg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5OZXh0OjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIEhS
RUY9Im5vZGU4MS5odG1sIj5CLjEgSGlzdG9yeSBvZiB0aGU8L0E+DQo8aHI+DQo8c3BhbiBj
bGFzcz0icmVsZWFzZS1pbmZvIj5SZWxlYXNlIDIuMi4xLCBkb2N1bWVudGF0aW9uIHVwZGF0
ZWQgb24gQXByaWwgMTAsIDIwMDIuPC9zcGFuPg0KPC9ESVY+DQo8IS0tRW5kIG9mIE5hdmln
YXRpb24gUGFuZWwtLT4NCjxBRERSRVNTPg0KU2VlIDxpPjxhIGhyZWY9ImFib3V0Lmh0bWwi
PkFib3V0IHRoaXMgZG9jdW1lbnQuLi48L2E+PC9pPiBmb3IgaW5mb3JtYXRpb24gb24gc3Vn
Z2VzdGluZyBjaGFuZ2VzLg0KPC9BRERSRVNTPg0KPC9CT0RZPg0KPC9IVE1MPg0K
--ZBha3QQ5r2566454O1G3BI00SZ12K3qqSpfc--



------=_NextPartTM-000-24d965e4-f031-11d6-a148-0010b586b16d
Content-Type: text/plain;
	name="InterScan_SafeStamp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_SafeStamp.txt"

****** Message from InterScan E-Mail VirusWall NT ******

** WARNING! Attached file One.pif contains:

     WORM_KLEZ.H virus

   Attempted to clean the file but it is not cleanable.
   It has been deleted.

Message : Virus detecté
*****************     End of message     ***************


------=_NextPartTM-000-24d965e4-f031-11d6-a148-0010b586b16d--


From melbohince@attbi.com  Wed Nov  6 16:21:53 2002
From: melbohince@attbi.com (Mel Bohince)
Date: Wed, 06 Nov 2002 11:21:53 -0500
Subject: [Pythonmac-SIG] Changing PATH to python2.2.2
In-Reply-To: <9F2AC21A-F141-11D6-9BD6-003065F88956@mac.com>
Message-ID: <B9EEABD1.DE08%melbohince@attbi.com>

How/What do I change so that when I enter '%python' the version 2.2.2 that
is in /usr/local/bin launches instead of the version 2.2 in the /usr/bin
directory. 
TIA
-:  -:  -:  -: -:  -:  -:  -:    \|/
  -:  -:  -:  -: -:  -:  -:  -:  cU
Mel Bohince
Pjt Mgr, 
Arkay Packaging Corporation
melbohince@att.net
http://home.att.net/~melbohince/



From owen@astro.washington.edu  Wed Nov  6 18:03:24 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Wed, 6 Nov 2002 10:03:24 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <9F2AC21A-F141-11D6-9BD6-003065F88956@mac.com>
References: <9F2AC21A-F141-11D6-9BD6-003065F88956@mac.com>
Message-ID: <p05200f04b9ef0506d026@[128.95.99.44]>

>On Tuesday, November 5, 2002, at 04:54  PM, Russell E Owen wrote:
>
>>I tried to build MachoPython 2.2.2 with aqua Tk and ran into a 
>>snag: Tkinter acts oddly.
>
>>this puts up a Tk root window, as usual, but whenever I try to 
>>click on the Tk window, I get:
>>>>>  SetFrontProcess failed,-606
>
>Add add a shell script named pythonw to /usr/local/bin or somewhere 
>else in your PATH
>
>#!/bin/sh
>exec 
>/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app/Contents/MacOS/python 
>"$@"
>
>use pythonw to launch GUI apps.

Thank you very much. That pretty much did the trick.

However, most of my files start with #!/usr/local/bin/python. Is 
there any way to get that to work? At present, running such files as 
commands leads to unusable windows, an ugly pitfall.

I tried the obvious (delete /usr/local/bin/python and rename 
/usr/local/bin/pythonw to it); typing python at the prompt does bring 
up a copy of python that can be used for Tkinter. However, any files 
that start with #!/usr/local/bin/python will *NOT* run (and it looks 
as if the #! line is totally failing to run).

While I'm on the subject of 2.2.2, should I be worried that test_sax 
and test_pyexpat are unexpectedly skipped after a "make test"? I fear 
this means that the xml stuff is broken, but am not certain. (I'm not 
using xml anyway, but do want to be sure that any unknown bugs are 
reported.)

I'm thrilled to finally have aqua Tk support working (though still 
hope to get execution-as-a-command working again). I have posted 
instructions for building Python 2.2.2 with readlines and aqua 
Tkinter support on MacOS 10.2; see the link at: 
<http://www.astro.washington.edu/owen>.

-- Russell

P.S. when Python is via exec... it claims to be Python 2.3a0 (#1, Sep 
6 2002, 20:20:16), even though I built 2.2.2. I suspect this is a 
quirk of the 2.2.2 source code.


From melbohince@attbi.com  Wed Nov  6 19:14:57 2002
From: melbohince@attbi.com (Mel Bohince)
Date: Wed, 06 Nov 2002 14:14:57 -0500
Subject: [Pythonmac-SIG] Changing PATH to python2.2.2
In-Reply-To: <B9EEABD1.DE08%melbohince@attbi.com>
Message-ID: <B9EED461.DE17%melbohince@attbi.com>

never mind, found the answer in the excellent direction at:
<<http://www.astro.washington.edu/owen>>

> How/What do I change so that when I enter '%python' the version 2.2.2 that
> is in /usr/local/bin launches instead of the version 2.2 in the /usr/bin
> directory. 
> TIA
> -:  -:  -:  -: -:  -:  -:  -:    \|/
> -:  -:  -:  -: -:  -:  -:  -:  cU
> Mel Bohince
> Pjt Mgr, 
> Arkay Packaging Corporation
> melbohince@att.net
> http://home.att.net/~melbohince/



From brian_l@mac.com  Thu Nov  7 05:06:12 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Wed, 6 Nov 2002 21:06:12 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <p05200f04b9ef0506d026@[128.95.99.44]>
Message-ID: <A28878A6-F20E-11D6-AEE1-003065F88956@mac.com>

On Wednesday, November 6, 2002, at 10:03  AM, Russell E Owen wrote:
>
> Thank you very much. That pretty much did the trick.
>
> However, most of my files start with #!/usr/local/bin/python. Is there 
> any way to get that to work? At present, running such files as 
> commands leads to unusable windows, an ugly pitfall.

Change your Tk scripts to use #!/usr/local/bin/pythonw or 
#!/usr/bin/env pythonw


> I tried the obvious (delete /usr/local/bin/python and rename 
> /usr/local/bin/pythonw to it); typing python at the prompt does bring 
> up a copy of python that can be used for Tkinter. However, any files 
> that start with #!/usr/local/bin/python will *NOT* run (and it looks 
> as if the #! line is totally failing to run).

You want to leave /usr/local/bin/python alone so regular scripts can 
run.  Make a symlink to python in /usr/local/bin

ln -sf /Library/Frameworks/Python.framework/Versions/2.2/bin/python

> While I'm on the subject of 2.2.2, should I be worried that test_sax 
> and test_pyexpat are unexpectedly skipped after a "make test"? I fear 
> this means that the xml stuff is broken, but am not certain. (I'm not 
> using xml anyway, but do want to be sure that any unknown bugs are 
> reported.)
>
> I'm thrilled to finally have aqua Tk support working (though still 
> hope to get execution-as-a-command working again). I have posted 
> instructions for building Python 2.2.2 with readlines and aqua Tkinter 
> support on MacOS 10.2; see the link at: 
> <http://www.astro.washington.edu/owen>.
>
> -- Russell
>
> P.S. when Python is via exec... it claims to be Python 2.3a0 (#1, Sep 
> 6 2002, 20:20:16), even though I built 2.2.2. I suspect this is a 
> quirk of the 2.2.2 source code.

Are you sure you don't have 2.3 installed?  Did you do ./configure 
--enable-framework? I'm guessing you have pythonw using 2.3 and your 
2.2.2 binary was in /usr/local/bin (the libs would be in 
/usr/local/lib/python2.2)

Take a peek in /Library/Frameworks/Python.framework/Versions




From AShearer@Lifespan.org  Thu Nov  7 17:58:09 2002
From: AShearer@Lifespan.org (Shearer, Andrew)
Date: Thu, 7 Nov 2002 12:58:09 -0500
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
Message-ID: <B01A4BD10D40D411883200508BC2889001251477@tmexchange.lifespan.org>

I had the same problem with XML. Unix Pythons before 2.3, including Jaguar's
build of Python 2.2, don't include expat or any other XML parser (except
xmllib's pure Python implementation, which xml.sax doesn't find).

To add expat support, download expat from
<http://sourceforge.net/projects/expat/>, do its ./configure, sudo make
install dance, then re-run Python's make command.

Andrew Shearer
Web Infrastructure Analyst
Medical Computing, IS

http://www.shearersoftware.com/

> ----------
> From: 	Russell E Owen
> Sent: 	Wednesday, November 6, 2002 1:03 PM
> To: 	Mac Python mailing list
> Cc: 	Brian Lenihan
> Subject: 	Re: [Pythonmac-SIG] MachoPython 2.2.2 build question
> 
> >On Tuesday, November 5, 2002, at 04:54  PM, Russell E Owen wrote:
> >
> >>I tried to build MachoPython 2.2.2 with aqua Tk and ran into a 
> >>snag: Tkinter acts oddly.
> >
> >>this puts up a Tk root window, as usual, but whenever I try to 
> >>click on the Tk window, I get:
> >>>>>  SetFrontProcess failed,-606
> >
> >Add add a shell script named pythonw to /usr/local/bin or somewhere 
> >else in your PATH
> >
> >#!/bin/sh
> >exec 
> >/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.ap
> p/Contents/MacOS/python 
> >"$@"
> >
> >use pythonw to launch GUI apps.
> 
> Thank you very much. That pretty much did the trick.
> 
> However, most of my files start with #!/usr/local/bin/python. Is 
> there any way to get that to work? At present, running such files as 
> commands leads to unusable windows, an ugly pitfall.
> 
> I tried the obvious (delete /usr/local/bin/python and rename 
> /usr/local/bin/pythonw to it); typing python at the prompt does bring 
> up a copy of python that can be used for Tkinter. However, any files 
> that start with #!/usr/local/bin/python will *NOT* run (and it looks 
> as if the #! line is totally failing to run).
> 
> While I'm on the subject of 2.2.2, should I be worried that test_sax 
> and test_pyexpat are unexpectedly skipped after a "make test"? I fear 
> this means that the xml stuff is broken, but am not certain. (I'm not 
> using xml anyway, but do want to be sure that any unknown bugs are 
> reported.)
> 
> I'm thrilled to finally have aqua Tk support working (though still 
> hope to get execution-as-a-command working again). I have posted 
> instructions for building Python 2.2.2 with readlines and aqua 
> Tkinter support on MacOS 10.2; see the link at: 
> <http://www.astro.washington.edu/owen>.
> 
> -- Russell
> 
> P.S. when Python is via exec... it claims to be Python 2.3a0 (#1, Sep 
> 6 2002, 20:20:16), even though I built 2.2.2. I suspect this is a 
> quirk of the 2.2.2 source code.
> 
> 
> 


From owen@astro.washington.edu  Thu Nov  7 18:55:19 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Thu, 7 Nov 2002 10:55:19 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <A28878A6-F20E-11D6-AEE1-003065F88956@mac.com>
References: <A28878A6-F20E-11D6-AEE1-003065F88956@mac.com>
Message-ID: <p05200f06b9f064f34ba0@[128.95.99.44]>

Damn, I thought I had it figured out, but now I'm really confused.

Somehow I got a partial framework build of 2.3a0 installed (probably 
when testing IDLE for somebody). My first attempt to build 2.2.2 
apparently ended up with the working python in /usr/local/bin that 
can launch aqua Tk but one cannot actually interact with the windows 
that are produced.

So I deleted /Library/Frameworks/Python.framework and tried again.

Since then I've tried to build Python 2.2.2 in two different ways, 
both of which have failed as far as a working framework goes.

- First try: unpack 2.2.2 and:
./configure --enable-framework
make
sudo make install

This results in a Library/Frameworks/Python.framework/Versions/2.2
which contains, among other things: bin/python
(Note that the contents of 2.2 are totally unlike those of 2.3, and 
that no Current directory was created.)

This runs if I do the following (though it kills my Terminal session 
when I exit Python):
cd /Library/Frameworks/Python.framework/Versions/2.2/bin/
exec python

However, I cannot get exec to run from any other directory. For example:
% exec /Library/Frameworks/Python.framework/Versions/2.2/bin/python
dyld: /Library/Frameworks/Python.framework/Versions/2.2/bin/python 
can't open library: Python.framework/Versions/2.2/Python  (No such 
file or directory, errno = 2)
Trace/BPT trap
(at which point my Terminal session exits, or my subshell if I start 
by issuing the "sh" command).

- Second try: unpack 2.2.2, modify setup.py to match that from 2.3a0, 
then repeat the process above. The result is identical.

Any suggestions? Can 2.2.2 be made to work with aqua Tk or should I 
give up and wait for 2.3 to be released?

(Also, this brings up some questions about plans for 2.3, but I'll 
put those in a separate message.)

-- Russell


>On Wednesday, November 6, 2002, at 10:03  AM, Russell E Owen wrote:
>>
>>Thank you very much. That pretty much did the trick.
>>
>>However, most of my files start with #!/usr/local/bin/python. Is 
>>there any way to get that to work? At present, running such files 
>>as commands leads to unusable windows, an ugly pitfall.
>
>Change your Tk scripts to use #!/usr/local/bin/pythonw or 
>#!/usr/bin/env pythonw
>
>>I tried the obvious (delete /usr/local/bin/python and rename 
>>/usr/local/bin/pythonw to it); typing python at the prompt does 
>>bring up a copy of python that can be used for Tkinter. However, 
>>any files that start with #!/usr/local/bin/python will *NOT* run 
>>(and it looks as if the #! line is totally failing to run).
>
>You want to leave /usr/local/bin/python alone so regular scripts can 
>run.  Make a symlink to python in /usr/local/bin
>
>ln -sf /Library/Frameworks/Python.framework/Versions/2.2/bin/python
>
>>While I'm on the subject of 2.2.2, should I be worried that 
>>test_sax and test_pyexpat are unexpectedly skipped after a "make 
>>test"? I fear this means that the xml stuff is broken, but am not 
>>certain. (I'm not using xml anyway, but do want to be sure that any 
>>unknown bugs are reported.)
>>
>>I'm thrilled to finally have aqua Tk support working (though still 
>>hope to get execution-as-a-command working again). I have posted 
>>instructions for building Python 2.2.2 with readlines and aqua 
>>Tkinter support on MacOS 10.2; see the link at: 
>><http://www.astro.washington.edu/owen>.
>>
>>-- Russell
>>
>>P.S. when Python is via exec... it claims to be Python 2.3a0 (#1, 
>>Sep 6 2002, 20:20:16), even though I built 2.2.2. I suspect this is 
>>a quirk of the 2.2.2 source code.
>
>Are you sure you don't have 2.3 installed?  Did you do ./configure 
>--enable-framework? I'm guessing you have pythonw using 2.3 and your 
>2.2.2 binary was in /usr/local/bin (the libs would be in 
>/usr/local/lib/python2.2)
>
>Take a peek in /Library/Frameworks/Python.framework/Versions



From owen@astro.washington.edu  Thu Nov  7 19:02:22 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Thu, 7 Nov 2002 11:02:22 -0800
Subject: [Pythonmac-SIG] Question about plans for Python 2.3
Message-ID: <p05200f07b9f06798ea7d@[128.95.99.44]>

After various trials with trying to get 2.2.2 built to talk to aqua 
Tk, I have a question about plans for 2.3.

I assume 2.3 will be able to work with aqua Tk. If so...can one 
installation (i.e. one interpreter) be used both for that purpose and 
also for other typical Python development? It seems as if 2.2.2 may 
want a copy in /Library/Frameworks/... for aqua Tk development and 
somehow may want another copy in /usr/local/bin for normal unix-ey 
stuff. Naah, that can't be right.

- Russell


From Jack.Jansen@oratrix.com  Thu Nov  7 21:04:03 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 7 Nov 2002 22:04:03 +0100
Subject: [Pythonmac-SIG] Question about plans for Python 2.3
In-Reply-To: <p05200f07b9f06798ea7d@[128.95.99.44]>
Message-ID: <71E41D75-F294-11D6-91F5-000A27B19B96@oratrix.com>

On donderdag, nov 7, 2002, at 20:02 Europe/Amsterdam, Russell E Owen 
wrote:

> After various trials with trying to get 2.2.2 built to talk to aqua 
> Tk, I have a question about plans for 2.3.
>
> I assume 2.3 will be able to work with aqua Tk. If so...can one 
> installation (i.e. one interpreter) be used both for that purpose and 
> also for other typical Python development? It seems as if 2.2.2 may 
> want a copy in /Library/Frameworks/... for aqua Tk development and 
> somehow may want another copy in /usr/local/bin for normal unix-ey 
> stuff. Naah, that can't be right.

The framework Python can be used for normal unix-type development work. 
Simply put a symlink to /Library/Frameworks/..../bin/python into, say, 
/usr/local/bin/python.

In 2.2.2 some key parts may be missing, though. Let me know if things 
don't work, they should be easy enough to backport from 2.3.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Thu Nov  7 22:29:26 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Thu, 7 Nov 2002 14:29:26 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <3834891.1036698327608.JavaMail.brian_l@mac.com>
References: <3834891.1036698327608.JavaMail.brian_l@mac.com>
Message-ID: <p05200f0bb9f094ec8a15@[128.95.99.44]>

I cleared out everything Brian Lenihan suggested (except I left my 
MacPython 2.2 installation, which is in /Applications/Python 2.2) and 
tried again. After many attempts I am much closer. Python 2.2.2 
builds and can find aqua Tk, but I cannot figure out which file to 
exec to be able to bring Tk windows forward.

The trick was:
- Replace setup.py with the one from CVS
- Build as Brian Lenihan suggested:
./configure --framework-enable
make
sudo make frameworkinstall

As I say, that builds just fine (it puts no symlinks in 
/usr/local/bin, but that's easy to fix). Everything works just fine 
except that I cannot bring a Tkinter window to the front.

I tried to adapt Brian's pythonw shell script, but fear I am trying 
to exec the wrong file. Brian suggested the following (which works 
for 2.3a0):
exec 
/Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app/Contents/MacOS/python

However, although 2.2.2 builds a directory:
/Library/Frameworks/Python.framework/Versions/Current/Resources
it doesn't contain a Python.app (it only contains three files: 
English.lproj Info.plist    version.plist).

So I tried:
exec /Library/Frameworks/Python/Versions/Current/bin/python
this works, but doesn't allow me to bring Tk windows forward.

Then I did a search for Python.app, but didn't find it. Nothing got 
stuffed in Applications, either. So at the moment I'm stumped.

If anyone has any suggestions, please let me know.

Also, thanks to Andrew Shearer for his suggestions about XML. I've 
updated the 2.2.2 build instructions to include that. (But the 
instructions are clearly not yet read for prime time.)

-- Russell


From owen@astro.washington.edu  Fri Nov  8 00:26:29 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Thu, 7 Nov 2002 16:26:29 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build works; 3 minor
 questions
In-Reply-To: <BDCC46E8-F2A2-11D6-88CC-000393A96660@noaa.gov>
References: <BDCC46E8-F2A2-11D6-88CC-000393A96660@noaa.gov>
Message-ID: <p05200f0db9f0a887226f@[128.95.99.44]>

Thank you. That did the trick! Robin's file 
<http://wxpython.org/BUILD.osx.txt> had the instructions.

Updated instructions for building Python 2.2.2 on MacOS 10.2 are at 
<http://www.astro.washington.edu/owen/> (including XML support, 
thanks to Andrew Shearer).

There are a few fairly minor unresolved issues:

1) Readlines support is missing when python is run via the shell 
script in pythonw, though one can activate it by doing "import 
readline". Any idea how to get that done automatically at startup?

2) Is it possible to make a Python/Tkinter source file that can be 
run as a command (i.e. that has a working #! line in it)? I tried the 
obvious, but it fails. Example:

#!/usr/local/bin/pythonw
"""Test of #!/usr/local/bin/pythonw; the file does exist and does work"""

Results in:
/usr/local/bin/pythonw: Event not found.

I suspect the failure may be something to do with the fact that 
pythonw executes in a sub shell.

Ideally, I'd like to set it up so /usr/local/bin/python could be used 
for *everything* involving the command line, meaning I could type 
"python" at the command line or use #!/usr/local/bin/python in my 
source code and it would all work (including with Tkinter).

3) pythonw does the following when run with a source file as its argument:
% pythonw TUI.py
original argc=2
original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
original argv[1] = "TUI.py"
modified argc=2
modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
modified argv[1] = "TUI.py"

I'm guessing this is a known oddity in 2.2.2 that is resolved in 2.3, 
but if there's some trivial way to stop it, I'll put it in the 
documentation.

-- Russell


>On Thursday, November 7, 2002, at 02:29 PM, Russell E Owen wrote:
>>If anyone has any suggestions, please let me know.
>
>check out what the wxMacPython folks are doing. Robin is 
>distributing a build that they are using with wxPython. I imagine 
>the issues are similar, so I'd find out how he's building 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 webmaster@python.org  Fri Nov  8 09:02:19 2002
From: webmaster@python.org (webmaster)
Date: Fri, 8 Nov 2002 10:02:19 +0100 (added by postmaster@dns-oi.com)
Subject: [Pythonmac-SIG] For information on suggesting changes.
Message-ID: <3D946F6400029757@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com)

------=_NextPartTM-000-86ecd4fb-f199-11d6-a148-0010b586b16d
Content-Type: multipart/alternative;
	boundary=U8imG7k49Z55l8lwz155N3WU3

--U8imG7k49Z55l8lwz155N3WU3
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:YDjK03n35 height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--U8imG7k49Z55l8lwz155N3WU3
--U8imG7k49Z55l8lwz155N3WU3
Content-Type: application/octet-stream;
	name=node80.html
Content-Transfer-Encoding: base64
Content-ID: <YDjK03n35>

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+Qi4gSGlzdG9yeSBhbmQgTGljZW5z
ZTwvdGl0bGU+DQo8TUVUQSBOQU1FPSJkZXNjcmlwdGlvbiIgQ09OVEVOVD0iQi4gSGlzdG9y
eSBhbmQgTGljZW5zZSI+DQo8TUVUQSBOQU1FPSJrZXl3b3JkcyIgQ09OVEVOVD0iYXBpIj4N
CjxNRVRBIE5BTUU9InJlc291cmNlLXR5cGUiIENPTlRFTlQ9ImRvY3VtZW50Ij4NCjxNRVRB
IE5BTUU9ImRpc3RyaWJ1dGlvbiIgQ09OVEVOVD0iZ2xvYmFsIj4NCjxtZXRhIGh0dHAtZXF1
aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5
LTEiPg0KPGxpbmsgcmVsPSJTVFlMRVNIRUVUIiBocmVmPSJhcGkuY3NzIj4NCjxsaW5rIHJl
bD0iZmlyc3QiIGhyZWY9ImFwaS5odG1sIj4NCjxsaW5rIHJlbD0iY29udGVudHMiIGhyZWY9
ImNvbnRlbnRzLmh0bWwiIHRpdGxlPSJDb250ZW50cyI+DQo8bGluayByZWw9ImluZGV4IiBo
cmVmPSJnZW5pbmRleC5odG1sIiB0aXRsZT0iSW5kZXgiPg0KPExJTksgUkVMPSJuZXh0IiBo
cmVmPSJnZW5pbmRleC5odG1sIj4NCjxMSU5LIFJFTD0icHJldmlvdXMiIGhyZWY9InJlcG9y
dGluZy1idWdzLmh0bWwiPg0KPExJTksgUkVMPSJ1cCIgSFJFRj0iYXBpLmh0bWwiPg0KPExJ
TksgUkVMPSJuZXh0IiBIUkVGPSJub2RlODEuaHRtbCI+DQo8L2hlYWQ+DQo8Ym9keT4NCjxE
SVYgQ0xBU1M9Im5hdmlnYXRpb24iPg0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRoPSIx
MDAlIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiPg0KPHRyPg0KPHRkPjxBIGhy
ZWY9InJlcG9ydGluZy1idWdzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9wcmV2aW91cy5n
aWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJQcmV2aW91cyBQYWdlIiB3
aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxBIEhSRUY9ImFwaS5odG1sIj48aW1nIHNyYz0i
Li4vaWNvbnMvdXAuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iVXAg
T25lIExldmVsIiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxBIEhSRUY9Im5vZGU4MS5o
dG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvbmV4dC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0
PSIzMiINCiAgYWx0PSJOZXh0IFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQgYWxp
Z249ImNlbnRlciIgd2lkdGg9IjEwMCUiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFs
PC90ZD4NCjx0ZD48QSBocmVmPSJjb250ZW50cy5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMv
Y29udGVudHMuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iQ29udGVu
dHMiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PGltZyBzcmM9Ii4uL2ljb25zL2JsYW5r
LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IiIgd2lkdGg9IjMyIj48
L3RkPg0KPHRkPjxBIGhyZWY9ImdlbmluZGV4Lmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9p
bmRleC5naWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJJbmRleCIgd2lk
dGg9IjMyIj48L0E+PC90ZD4NCjwvdHI+PC90YWJsZT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+
UHJldmlvdXM6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgaHJlZj0icmVwb3J0aW5nLWJ1Z3Mu
aHRtbCI+QS4gUmVwb3J0aW5nIEJ1Z3M8L0E+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPlVwOjwv
Yj4gPGEgY2xhc3M9InNlY3RyZWYiIEhSRUY9ImFwaS5odG1sIj5QeXRob24vQyBBUEkgUmVm
ZXJlbmNlIE1hbnVhbDwvQT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+TmV4dDo8L2I+IDxhIGNs
YXNzPSJzZWN0cmVmIiBIUkVGPSJub2RlODEuaHRtbCI+Qi4xIEhpc3Rvcnkgb2YgdGhlPC9B
Pg0KPGJyPjxocj4NCjwvRElWPg0KPCEtLUVuZCBvZiBOYXZpZ2F0aW9uIFBhbmVsLS0+DQoN
CjxIMT48QSBOQU1FPSJTRUNUSU9OMDAxNDAwMDAwMDAwMDAwMDAwMDAwMCI+DQpCLiBIaXN0
b3J5IGFuZCBMaWNlbnNlPC9BPg0KPC9IMT4NCg0KPHA+PGhyPg0KPCEtLVRhYmxlIG9mIENo
aWxkLUxpbmtzLS0+DQo8QSBOQU1FPSJDSElMRF9MSU5LUyI+PFNUUk9ORz5TdWJzZWN0aW9u
czwvU1RST05HPjwvYT4NCg0KPFVMIENMQVNTPSJDaGlsZExpbmtzIj4NCjxMST48QSBocmVm
PSJub2RlODEuaHRtbCI+Qi4xIEhpc3Rvcnkgb2YgdGhlIHNvZnR3YXJlPC9hPg0KPExJPjxB
IGhyZWY9Im5vZGU4Mi5odG1sIj5CLjIgVGVybXMgYW5kIGNvbmRpdGlvbnMgZm9yIGFjY2Vz
c2luZyBvciBvdGhlcndpc2UgdXNpbmcgUHl0aG9uPC9hPg0KPC91bD4NCjwhLS1FbmQgb2Yg
VGFibGUgb2YgQ2hpbGQtTGlua3MtLT4NCg0KPERJViBDTEFTUz0ibmF2aWdhdGlvbiI+DQo8
cD48aHI+DQo8dGFibGUgYWxpZ249ImNlbnRlciIgd2lkdGg9IjEwMCUiIGNlbGxwYWRkaW5n
PSIwIiBjZWxsc3BhY2luZz0iMiI+DQo8dHI+DQo8dGQ+PEEgaHJlZj0icmVwb3J0aW5nLWJ1
Z3MuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL3ByZXZpb3VzLmdpZiINCiAgYm9yZGVyPSIw
IiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlByZXZpb3VzIFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwv
dGQ+DQo8dGQ+PEEgSFJFRj0iYXBpLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy91cC5naWYi
DQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJVcCBPbmUgTGV2ZWwiIHdpZHRo
PSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEgSFJFRj0ibm9kZTgxLmh0bWwiPjxpbWcgc3JjPSIu
Li9pY29ucy9uZXh0LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9Ik5l
eHQgUGFnZSIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZCBhbGlnbj0iY2VudGVyIiB3aWR0
aD0iMTAwJSI+UHl0aG9uL0MgQVBJIFJlZmVyZW5jZSBNYW51YWw8L3RkPg0KPHRkPjxBIGhy
ZWY9ImNvbnRlbnRzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9jb250ZW50cy5naWYiDQog
IGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJDb250ZW50cyIgd2lkdGg9IjMyIj48
L0E+PC90ZD4NCjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lmIg0KICBib3JkZXI9
IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+DQo8dGQ+PEEgaHJl
Zj0iZ2VuaW5kZXguaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2luZGV4LmdpZiINCiAgYm9y
ZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkluZGV4IiB3aWR0aD0iMzIiPjwvQT48L3Rk
Pg0KPC90cj48L3RhYmxlPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5QcmV2aW91czo8L2I+IDxh
IGNsYXNzPSJzZWN0cmVmIiBocmVmPSJyZXBvcnRpbmctYnVncy5odG1sIj5BLiBSZXBvcnRp
bmcgQnVnczwvQT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+VXA6PC9iPiA8YSBjbGFzcz0ic2Vj
dHJlZiIgSFJFRj0iYXBpLmh0bWwiPlB5dGhvbi9DIEFQSSBSZWZlcmVuY2UgTWFudWFsPC9B
Pg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5OZXh0OjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIEhS
RUY9Im5vZGU4MS5odG1sIj5CLjEgSGlzdG9yeSBvZiB0aGU8L0E+DQo8aHI+DQo8c3BhbiBj
bGFzcz0icmVsZWFzZS1pbmZvIj5SZWxlYXNlIDIuMi4xLCBkb2N1bWVudGF0aW9uIHVwZGF0
ZWQgb24gQXByaWwgMTAsIDIwMDIuPC9zcGFuPg0KPC9ESVY+DQo8IS0tRW5kIG9mIE5hdmln
YXRpb24gUGFuZWwtLT4NCjxBRERSRVNTPg0KU2VlIDxpPjxhIGhyZWY9ImFib3V0Lmh0bWwi
PkFib3V0IHRoaXMgZG9jdW1lbnQuLi48L2E+PC9pPiBmb3IgaW5mb3JtYXRpb24gb24gc3Vn
Z2VzdGluZyBjaGFuZ2VzLg0KPC9BRERSRVNTPg0KPC9CT0RZPg0KPC9IVE1MPg0K
--U8imG7k49Z55l8lwz155N3WU3--



------=_NextPartTM-000-86ecd4fb-f199-11d6-a148-0010b586b16d
Content-Type: text/plain;
	name="InterScan_SafeStamp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_SafeStamp.txt"

****** Message from InterScan E-Mail VirusWall NT ******

** WARNING! Attached file width.pif contains:

     WORM_KLEZ.H virus

   Attempted to clean the file but it is not cleanable.
   It has been deleted.

Message : Virus detecté
*****************     End of message     ***************


------=_NextPartTM-000-86ecd4fb-f199-11d6-a148-0010b586b16d--


From Jack.Jansen@cwi.nl  Fri Nov  8 09:17:36 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 8 Nov 2002 10:17:36 +0100
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build works; 3 minor questions
In-Reply-To: <p05200f0db9f0a887226f@[128.95.99.44]>
Message-ID: <EB9204CE-F2FA-11D6-8B9B-0030655234CE@cwi.nl>

On Friday, Nov 8, 2002, at 01:26 Europe/Amsterdam, Russell E Owen wrote:
> 1) Readlines support is missing when python is run via the shell 
> script in pythonw, though one can activate it by doing "import 
> readline". Any idea how to get that done automatically at startup?

Put it in your PYTHONSTARTUP file. Or add it to sitecustomize.py. Or 
there are probably many other ways...

> 2) Is it possible to make a Python/Tkinter source file that can be run 
> as a command (i.e. that has a working #! line in it)? I tried the 
> obvious, but it fails. Example:
>
> #!/usr/local/bin/pythonw
> """Test of #!/usr/local/bin/pythonw; the file does exist and does 
> work"""
>
> Results in:
> /usr/local/bin/pythonw: Event not found.

#!/Applications/Python.app/Contents/MacOS/python
Not pretty, but it works.

> Ideally, I'd like to set it up so /usr/local/bin/python could be used 
> for *everything* involving the command line, meaning I could type 
> "python" at the command line or use #!/usr/local/bin/python in my 
> source code and it would all work (including with Tkinter).

Under 10.2 you could create a minimal C program that does an execve() 
of /Applications/Python.app/Contents/MacOS/python, I think that will 
work okay. On 10.1 this will not work for all situations: on 10.1 the 
window server is contacted as soon as you start a program (on 10.2 it 
seems to be delayed until you actually use the window server), so using 
the windowing Python will likely fail if you don't have a windowing 
environment.

> 3) pythonw does the following when run with a source file as its 
> argument:
> % pythonw TUI.py
> original argc=2
> original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
> original argv[1] = "TUI.py"
> modified argc=2
> modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
> modified argv[1] = "TUI.py"
>
> I'm guessing this is a known oddity in 2.2.2 that is resolved in 2.3, 
> but if there's some trivial way to stop it, I'll put it in the 
> documentation.

Remove the silly debug prints from macmain.c and rebuild. Could you do 
me a favor and file a bug report for this?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From blhscomputerprogramming@yahoo.com  Fri Nov  8 15:46:35 2002
From: blhscomputerprogramming@yahoo.com (ang blank)
Date: Fri, 8 Nov 2002 07:46:35 -0800 (PST)
Subject: [Pythonmac-SIG] Using custom DLOGs with EasyDialogs
Message-ID: <20021108154635.43426.qmail@web13204.mail.yahoo.com>

I would like to know where I am supposed to put custom
DLOG resources so they can be called by EasyDialogs. 
I would also like to know where I can find the correct
item numbers for the items within the DLOG.

I would imagine that I could copy the appropriate DLOG
from the Python Core and modify it and give it a
different ID number.  My only problem, I think, is
that I don't know where to put my modified DLOG
resource.

I have tried putting it into an applet, but it will
just throw this error:

Traceback (most recent call last):
  File "Macintosh HD:Desktop Folder:EasyDialogs", line
5, in ?
    EasyDialogs.Message('EasyDialogs.Message in
action', id=512, ok='OK!')
  File "Macintosh HD:Applications (Mac OS 9):Python
2.2.1:Mac:Lib:EasyDialogs.py", line 55, in Message
    h = d.GetDialogItemAsControl(2)
MacOS.Error: (-30596, 'errItemNotControl')

If I try putting the DLOG into a script file, the
output window will say

Can't get DLOG resource with id = 512

Thank you for your help.

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2


From owen@astro.washington.edu  Fri Nov  8 17:56:52 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Fri, 8 Nov 2002 09:56:52 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build works; 3 minor
 questions
In-Reply-To: <EB9204CE-F2FA-11D6-8B9B-0030655234CE@cwi.nl>
References: <EB9204CE-F2FA-11D6-8B9B-0030655234CE@cwi.nl>
Message-ID: <p05200f01b9f1a2049bb1@[128.95.99.44]>

>On Friday, Nov 8, 2002, at 01:26 Europe/Amsterdam, Russell E Owen wrote:
>>1) Readlines support is missing when python is run via the shell 
>>script in pythonw, though one can activate it by doing "import 
>>readline". Any idea how to get that done automatically at startup?
>
>Put it in your PYTHONSTARTUP file. Or add it to sitecustomize.py. Or 
>there are probably many other ways...

Thanks. I added it to sitecustomize.py and it worked beautifully.

As a warning to others:

I was NOT able to get PYTHONPATH working. There are two problems (the 
first expected, the second may be a bug):

I defined a file ~/pythonstartup.py that had a print statement, so I 
could see immediately if it worked.

(problem 1) Defining PYTHONSTARTUP in ~/.cshrc worked fine for python 
but was not seen by pythonw, as verified by examining os.environ. 
This is not surprising, because aqua applications cannot see 
environment variables defined in .cshrc.

I then removed the definition from ~/.cshrc, added it to 
~/.MacOSX/environment.plist (which is where environment variables 
should be defined if you want aqua applications to see them -- a 
handy trick for using BBEdit with Python) and logged out and back in 
again....

(problem 2) This time the variable showed up just fine in os.environ, 
both in pythonw and python. However, in NEITHER case did the startup 
file it pointed to actually get run! I suspect this is a bug.

Finally, just for completeness, I manually defined PYTHONSTARTUP 
using "setenv" and again the startup file worked in python but not 
pythonw.

>>2) Is it possible to make a Python/Tkinter source file that can be 
>>run as a command (i.e. that has a working #! line...
>
>#!/Applications/Python.app/Contents/MacOS/python
>Not pretty, but it works.

Unfortunately, it works exactly like #!/usr/local/lib/python: the 
Python code runs (which is a big step forward from 
#!/usr/local/bin/pythonw), but one cannot bring Tk windows to the 
front!

>(or)...Under 10.2 you could create a minimal C program that does an 
>execve() of /Applications/Python.app/Contents/MacOS/python, I think 
>that will work okay.

I also tried this. It did work, but unfortunately it worked exactly 
the same as python itself: one cannot bring Tk windows to the front.

Thank you for all your help. I'll try to fix the debug print 
statements as you suggested and I filed a bug report on it as you 
requested.

Regards,

-- Russell


From Chris.Barker@noaa.gov  Fri Nov  8 22:06:32 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Fri, 08 Nov 2002 14:06:32 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build works; 3 minorquestions
References: <EB9204CE-F2FA-11D6-8B9B-0030655234CE@cwi.nl> <p05200f01b9f1a2049bb1@[128.95.99.44]>
Message-ID: <3DCC3568.234BB282@noaa.gov>

Russell E Owen wrote:
 
> I also tried this. It did work, but unfortunately it worked exactly
> the same as python itself: one cannot bring Tk windows to the front.

This brings up a question I've had for along time:

Why is this a issue at all? On Unixes with X, you can start a program
from anywhere, and if it needs X, it uses X, if it doesn't it doesn't.
You can start it from a command line, or from another program, it makes
no difference. All any program needs is stdin and stdout, and those
don't actually have to display anything.

Even on Windows, the only difference between python and pythonw is that
pythonw doesn't bring up a terminal window. python will still run the
program just fine (and if you want to see stdout, having the terminal
window is just fine.

-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 gherman@darwin.in-berlin.de  Sat Nov  9 09:09:08 2002
From: gherman@darwin.in-berlin.de (Dinu Gherman)
Date: Sat, 9 Nov 2002 10:09:08 +0100
Subject: [Pythonmac-SIG] MacPython listed in ADC News #326
Message-ID: <E73503FD-F3C2-11D6-BB4E-00039345C610@darwin.in-berlin.de>

Apple Developer Connection:

> ----------------------------------------
> [15] Mac OS X Tool News: MacPython 2.2.2
>
> MacPython 2.2.2 by Jack Jansen is a port of Guido van Rossum's
> Python high-level object-oriented language. In includes an IDE and
> access to native functionality. This release now runs on
> multiprocessor CPUs and the IDE is now fully functional on Mac OS X.
> http://www.cwi.nl/~jack/macpython.html
>
> ----------------------------------------

Congratulation, Jack! MacPython 2.2.2 made it to yesterday's
"Apple Developper Connection" News!

Regards,

Dinu

--
Dinu C. Gherman
......................................................................
"Patriotism is the willingness to kill and be killed for trivial
reasons." (Bertrand Russell)



From Jack.Jansen@oratrix.com  Fri Nov  8 08:19:29 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 8 Nov 2002 09:19:29 +0100
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <p05200f06b9f064f34ba0@[128.95.99.44]>
Message-ID: <CD61C55D-F2F2-11D6-B55E-000A27B19B96@oratrix.com>

On donderdag, nov 7, 2002, at 19:55 Europe/Amsterdam, Russell E Owen 
wrote:
> - First try: unpack 2.2.2 and:
> ./configure --enable-framework
> make
> sudo make install
>
> This results in a Library/Frameworks/Python.framework/Versions/2.2
> which contains, among other things: bin/python
> (Note that the contents of 2.2 are totally unlike those of 2.3, and 
> that no Current directory was created.)

This sounds like a bug. Could you file a report at sourceforge so that 
I get to look at it before (if ever) 2.2.3 comes out?

As a workaround, go to /Library/Frameworks/Python.framework/Versions 
and type "ln -s 2.2 Current".

>
> This runs if I do the following (though it kills my Terminal session 
> when I exit Python):
> cd /Library/Frameworks/Python.framework/Versions/2.2/bin/
> exec python

That's what "exec" does. It says "replace the current shell with this 
command". You use it in shell scripts to get rid of the shell that runs 
the script, but you shouldn't use it on the command line. Simply type 
"python".

> However, I cannot get exec to run from any other directory. For 
> example:
> % exec /Library/Frameworks/Python.framework/Versions/2.2/bin/python
> dyld: /Library/Frameworks/Python.framework/Versions/2.2/bin/python 
> can't open library: Python.framework/Versions/2.2/Python  (No such 
> file or directory, errno = 2)
> Trace/BPT trap

This is probably a result of Current missing, the problem above.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Sat Nov  9 18:41:56 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Sat, 9 Nov 2002 10:41:56 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <CD61C55D-F2F2-11D6-B55E-000A27B19B96@oratrix.com>
References: <CD61C55D-F2F2-11D6-B55E-000A27B19B96@oratrix.com>
Message-ID: <p05200f02b9f304997af8@[140.142.183.50]>

>On donderdag, nov 7, 2002, at 19:55 Europe/Amsterdam, Russell E Owen wrote:
>>- First try: unpack 2.2.2 and:
>>./configure --enable-framework
>>make
>>sudo make install
>>
>>This results in a Library/Frameworks/Python.framework/Versions/2.2
>>which contains, among other things: bin/python
>>(Note that the contents of 2.2 are totally unlike those of 2.3, and 
>>that no Current directory was created.)
>
>This sounds like a bug. Could you file a report at sourceforge so 
>that I get to look at it before (if ever) 2.2.3 comes out?
>
>As a workaround, go to /Library/Frameworks/Python.framework/Versions 
>and type "ln -s 2.2 Current".

This was entirely my fault. I mishandled the framework build of 
2.2.2. Thanks to all the help I got that figured out and the build 
works correctly. (I also removed the debug statements that you 
mentioned and rebuilt again and that worked perfectly.)

Regarding an earlier post about trouble with PYTHONSTARTUP, I have 
more info on it. Defining the environment variable in 
~/.MacOSX/environment.plist does work fine for plain "python" 
(despite my earlier report to the contrary); however it still does 
*NOT* work for pythonw (it shows up in os.environ but the file is not 
actually run when pythonw starts up).

What I did wrong the first time was use ~ in my definition of the 
environment variable. I'd forgotten that ~ is not expanded when it 
appears in ~/.MacOSX/environment.plist. (I've also posted a page 
about using this file to define environment variables for MacOS X 
native applications, and have linked to it from my "how to build 
Python 2.2.2" page).

Just for fun, I presently have both a PYTHONSTARTUP file defined in 
~/.MacOSX/environment.plist (which does nothing more than print 
"running startup", since it's not run by pythonw) and also a 
"sitecustomize.py" on my PYTHONPATH (which works fine; it does the 
actual setup and also prints a different diagnostic statement). That 
way I can easily test variations, new versions of Python, etc.

I've noticed a quirk that may be relevant: pythonw starts up slightly 
differently than python -- it reports the same version number, but it 
prints out slightly different help text and the sitecustomize.py's 
print statement shows up at a different point during startup. If 
there's interest, I'll post the full output of each startup here (I'm 
not at work and so cannot do it right now).

-- Russell


From guess-who@kevin-masako.com  Sat Nov  9 13:36:27 2002
From: guess-who@kevin-masako.com (Kevin Ollivier)
Date: Sat, 9 Nov 2002 05:36:27 -0800
Subject: [Pythonmac-SIG] Compiling wxPython for CFM (OS 9 support)
Message-ID: <3F79EA58-F3E8-11D6-AEBD-00039384E8D4@kevin-masako.com>

--Apple-Mail-37-559729229
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Hi all,

I've been trying to build the wxPython libraries for MacPython 2.2.2 
(CFM) using CodeWarrior 7 and MacPython 2.2.2. I built wxMac Carbon 
shlb without problems and am now trying to build the wxPython shared 
libraries. MacPython created and loaded the wxc shared library project, 
but when I try to build I am getting "undefined identifier" errors in 
src/mac/cmndlgs.cpp for 'wxFindReplaceDialog', 'wxFindDialogEvent' and 
'wxFindReplaceData' which all exist in include/wx/fdrepdlg.h. The 
source file src/mac/printfw.cpp also gives undefined identifier errors 
for wxPostScriptDC. (gridc compiles, but spits out nearly 50 link 
errors) I've tried compiling both from the wxPythonSrc-2.3.3.1 package 
that Robin has available at wxpython.org as well as from the wxWindows 
CVS and both are giving me the same results.

Here is what I have done to get this far:

1. After building wx_Carbon_d.shlb, I modified wxPython/setup.py to 
give it a Mac section separate from the 'darwin' OS X section it has 
now. I set up the include and library directories as well as defines. 
(I have attached the latest version with this message. the "os.name == 
'mac'" section is where the new defines are.) I added in the 
wx_Carbon.rsrc file as well, although I'm not sure if that was 
necessary or not.

2. I downloaded GUSI2 for MacPython and the source for MacPython. I got 
these from Jack's MacPython site. 
(http://www.cwi.nl/~jack/macpython.html) I then put them inside 
Applications/MacPython 2.2.2 which is where distutils seems to want 
them.

3. I added a MacPython type and creator to wxPython/setup.py and then 
ran setup.py. distutils starts and creates CW projects for gridc and 
wxc. I had to manually modify the project files though... CW strangely 
does not seem to be interpreting the "::" path properly - it reads it 
as a single ":". So to get GUSI2 to show up I had to include it in the 
same directory as the Python interpreter (Applications/MacPython 
2.2.2/), not a directory above it. I then had to turn off the "include 
subfolders" option for "Apps:MacPython 2.2.2" in the User Paths to keep 
sys/time.h from being recursively included. I also had to hard-code the 
path to WXDIR in setup.py because using "::" resulted in "directory not 
found" errors. Of course, this could simply be that I am not very 
familiar with OS 9 style paths, but I thought "::" specified the 
previous directory.

4. Now it starts compiling, but I get errors about "strdup" in 
includes/wx/buffer.h. Seems this is a problem with CodeWarrior not 
including strdup in string.h and can be fixed by adding #include 
<extras.h>.

5. Once I've done this, I get the results mentioned above. wxc gives 
errors for cmndlgs.cpp and gridc gives link errors (for many of, if not 
all, the functions).

I'm pretty sure that I'm doing something wrong here, but I think I need 
another pair of eyes to see what it is! If someone could take a look at 
this I would really appreciate it. I updated to CW 7.2 this morning but 
did not see any change in behavior.

Thanks,

Kevin


--Apple-Mail-37-559729229
Content-Disposition: attachment
Content-Type: multipart/appledouble;
	boundary=Apple-Mail-38-559729230


--Apple-Mail-38-559729230
Content-Disposition: attachment;
	filename=setup.py
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
	name="setup.py"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAAAoAAAADAAAASAAAAAgAAAACAAAA
UAAAAhxURVhUUHl0aAAAc2V0dXAucHkAAAEAAAAB2gAAANoAAABCAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1ntz
CwAAAHJ1bl9hc19tYWluaQAAAABzCQAAAHNlbGVjdGlvbigCAAAAaTIsAABpMiwAAHMHAAAAdGFi
c2l6ZSgCAAAAaQgAAABpAQAAAHMMAAAAd2luZG93Ym91bmRzKAQAAABphgAAAGncAAAAaXUDAABp
ygIAAHMMAAAAZm9udHNldHRpbmdzKAQAAABzBgAAAEdlbmV2YWkAAAAAaQoAAAAoAwAAAGkAAAAA
aQAAAABpAAAAAHMUAAAAcnVuX3dpdGhfaW50ZXJwcmV0ZXJpAAAAADAAAAEAAAAB2gAAANoAAABC
ABKDtAEqAAAAHAAyAABQeVdTAAAACgCAAAAAAAAAAW4aKA93aW5kb3cgc2V0dGluZ3M=

--Apple-Mail-38-559729230
Content-Disposition: attachment;
	filename=setup.py
Content-Transfer-Encoding: quoted-printable
Content-Type: application/text;
	x-mac-creator=50797468;
	x-unix-mode=0755;
	x-mac-type=54455854;
	name="setup.py"

#!/usr/bin/env=20python=0D=
#----------------------------------------------------------------------=0D=
=0Dimport=20sys,=20os,=20string,=20glob=0Dfrom=20distutils.core=20=20=20=20=
=20=20import=20setup,=20Extension=0Dfrom=20distutils.file_util=20import=20=
copy_file=0Dfrom=20distutils.dir_util=20=20import=20mkpath=0Dfrom=20=
distutils.dep_util=20=20import=20newer=0D=0Dfrom=20my_distutils=20import=20=
run_swig,=20contrib_copy_tree=0D=0D=
#----------------------------------------------------------------------=0D=
#=20flags=20and=20values=20that=20affect=20this=20script=0D=
#----------------------------------------------------------------------=0D=
=0DVERSION=20=20=20=20=20=20=20=20=20=20=3D=20"2.3.3.1"=0DDESCRIPTION=20=20=
=20=20=20=20=3D=20"Cross=20platform=20GUI=20toolkit=20for=20Python"=0D=
AUTHOR=20=20=20=20=20=20=20=20=20=20=20=3D=20"Robin=20Dunn"=0D=
AUTHOR_EMAIL=20=20=20=20=20=3D=20"Robin=20Dunn=20<robin@alldunn.com>"=0D=
URL=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20=
"http://wxPython.org/"=0DLICENSE=20=20=20=20=20=20=20=20=20=20=3D=20=
"wxWindows=20(LGPL=20derivative)"=0DLONG_DESCRIPTION=20=3D=20"""\=0D=
wxPython=20is=20a=20GUI=20toolkit=20for=20Python=20that=20is=20a=20=
wrapper=20around=20the=0DwxWindows=20C++=20GUI=20library.=20=20wxPython=20=
provides=20a=20large=20variety=20of=0Dwindow=20types=20and=20controls,=20=
all=20implemented=20with=20a=20native=20look=20and=0Dfeel=20(and=20=
native=20runtime=20speed)=20on=20the=20platforms=20it=20is=20supported=0D=
on.=0D"""=0D=0D=0DBUILD_GLCANVAS=20=3D=200=20#=20If=20true,=20build=20=
the=20contrib/glcanvas=20extension=20module=0DBUILD_OGL=20=3D=200=20=20=20=
=20=20=20#=20If=20true,=20build=20the=20contrib/ogl=20extension=20module=0D=
BUILD_STC=20=3D=200=20=20=20=20=20=20#=20If=20true,=20build=20the=20=
contrib/stc=20extension=20module=0DBUILD_XRC=20=3D=200=20=20=20=20=20=20=
#=20XML=20based=20resource=20system=0DBUILD_GIZMOS=20=3D=200=20=20=20#=20=
Build=20a=20module=20for=20the=20gizmos=20contrib=20library=0D=
BUILD_DLLWIDGET=20=3D=200#=20Build=20a=20module=20that=20enables=20=
unknown=20wx=20widgets=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20#=20to=20be=20loaded=20from=20a=20DLL=20and=20to=20be=20used=20=
from=20Python.=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20#=20Internet=20Explorer=20wrapper=20(experimental)=0DBUILD_IEWIN=20=3D=20=
(os.name=20=3D=3D=20'nt')=0D=0DCORE_ONLY=20=3D=201=20=20=20=20=20=20#=20=
if=20true,=20don't=20build=20any=20of=20the=20above=0D=0DGL_ONLY=20=3D=20=
0=20=20=20=20=20=20=20=20#=20Only=20used=20when=20making=20the=20-gl=20=
RPM.=20=20See=20the=20"b"=20script=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20#=20for=20the=20ugly=20details=0D=0DUSE_SWIG=20=3D=20=
0=20=20=20=20=20=20=20#=20Should=20we=20actually=20execute=20SWIG,=20or=20=
just=20use=20the=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20#=20files=20already=20in=20the=20distribution?=0D=0DUNICODE=20=3D=200=20=
=20=20=20=20=20=20=20#=20This=20will=20pass=20the=20'wxUSE_UNICODE'=20=
flag=20to=20SWIG=20and=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20#=20will=20ensure=20that=20the=20right=20headers=20are=20found=20=
and=20the=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20=
right=20libs=20are=20linked.=0D=0DIN_CVS_TREE=20=3D=200=20=20=20=20#=20=
Set=20to=20true=20if=20building=20in=20a=20full=20wxWindows=20CVS=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20tree,=20otherwise=20=
will=20assume=20all=20needed=20files=20are=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20#=20available=20in=20the=20wxPython=20source=20=
distribution=0D=0DUNDEF_NDEBUG=20=3D=200=20=20=20#=20Python=202.2=20on=20=
Unix/Linux=20by=20default=20defines=20NDEBUG,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20#=20and=20distutils=20will=20pick=20this=20=
up=20and=20use=20it=20on=20the=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20#=20compile=20command-line=20for=20the=20extensions.=20=20=
This=20could=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
#=20conflict=20with=20how=20wxWindows=20was=20built.=20=20If=20NDEBUG=20=
is=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20set=20=
then=20wxWindows'=20__WXDEBUG__=20setting=20will=20be=20turned=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20off.=20=20If=20=
wxWindows=20was=20actually=20built=20with=20it=20turned=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20on=20then=20you=20end=20up=20=
with=20mismatched=20class=20structures,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20#=20and=20wxPython=20will=20crash.=0D=0D=
NO_SCRIPTS=20=3D=201=20=20=20=20=20#=20Don't=20install=20the=20tool=20=
scripts=0D=0D=0DWX_CONFIG=20=3D=20"wx-config"=20=20=20=20#=20Usually=20=
you=20shouldn't=20need=20to=20touch=20this,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20but=20you=20=
can=20set=20it=20to=20pass=20an=20alternate=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20version=20of=20=
wx-config=20or=20alternate=20flags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20eg.=20as=20required=20=
by=20the=20.deb=20in-tree=20build.=0D=0DBUILD_BASE=20=3D=20"build"=0D=0D=
#=20Some=20MSW=20build=20settings=0D=0DFINAL=20=3D=200=20=20=20=20=20=20=20=
=20=20=20#=20Mirrors=20use=20of=20same=20flag=20in=20wx=20makefiles,=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20(0=20or=201=20=
only)=20should=20probably=20find=20a=20way=20to=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20#=20autodetect=20this...=0D=0DHYBRID=20=
=3D=201=20=20=20=20=20=20=20=20=20#=20If=20set=20and=20not=20debug=20or=20=
FINAL,=20then=20build=20a=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20#=20hybrid=20extension=20that=20can=20be=20used=20by=20the=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20non-debug=20=
version=20of=20python,=20but=20contains=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20#=20debugging=20symbols=20for=20wxWindows=20and=20=
wxPython.=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20=
wxWindows=20must=20have=20been=20built=20with=20/MD,=20not=20/MDd=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20(using=20=
FINAL=3Dhybrid=20will=20do=20it.)=0D=0DWXDLLVER=20=3D=20'233'=20=20=20#=20=
Version=20part=20of=20wxWindows=20DLL=20name=0D=0D=0D=
#----------------------------------------------------------------------=0D=
=0Ddef=20msg(text):=0D=20=20=20=20if=20__name__=20=3D=3D=20"__main__":=0D=
=20=20=20=20=20=20=20=20print=20text=0D=0D=0Ddef=20opj(*args):=0D=20=20=20=
=20path=20=3D=20apply(os.path.join,=20args)=0D=20=20=20=20return=20=
os.path.normpath(path)=0D=0D=0Ddef=20libFlag():=0D=20=20=20=20if=20=
FINAL:=0D=20=20=20=20=20=20=20=20rv=20=3D=20''=0D=20=20=20=20elif=20=
HYBRID:=0D=20=20=20=20=20=20=20=20rv=20=3D=20'h'=0D=20=20=20=20else:=0D=20=
=20=20=20=20=20=20=20rv=20=3D=20'd'=0D=20=20=20=20if=20UNICODE:=0D=20=20=20=
=20=20=20=20=20rv=20=3D=20'u'=20+=20rv=0D=20=20=20=20return=20rv=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Some=20other=20globals=0D=
#----------------------------------------------------------------------=0D=
=0DPKGDIR=20=3D=20'wxPython'=0DwxpExtensions=20=3D=20[]=0D=0Dforce=20=3D=20=
'--force'=20in=20sys.argv=20or=20'-f'=20in=20sys.argv=0Ddebug=20=3D=20=
'--debug'=20in=20sys.argv=20or=20'-g'=20in=20sys.argv=0D=0D=
bcpp_compiling=20=3D=20'-c'=20in=20sys.argv=20and=20'my_bcpp'=20in=20=
sys.argv=20#=20Bad=20heuristic=0D=0Dif=20bcpp_compiling:=0D=20=20=20=20=
msg("Compiling=20wxPython=20by=20Borland=20C/C++=20Compiler")=0D=20=20=20=
=20HYBRID=3D0=0D=20=20=20=20WXBCPPLIBVER=20=3D=20=
string.replace(WXDLLVER,"_","")=0D=20=20=20=20#=20Version=20part=20of=20=
BCPP=20build=20LIBRARY=20name=0D=20=20=20=20WXDLLVER=3D""=20#=20no=20dll=20=
ver=20path=20avaible=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Check=20for=20build=20flags=20on=20the=20command=20line=0D=
#----------------------------------------------------------------------=0D=
=0D#=20Boolean=20(int)=20flags=0Dfor=20flag=20in=20['BUILD_GLCANVAS',=20=
'BUILD_OGL',=20'BUILD_STC',=20'BUILD_XRC',=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20'BUILD_GIZMOS',=20'BUILD_DLLWIDGET',=20'BUILD_IEWIN',=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20'CORE_ONLY',=20'USE_SWIG',=20=
'IN_CVS_TREE',=20'UNICODE',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
'UNDEF_NDEBUG',=20'NO_SCRIPTS',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
'FINAL',=20'HYBRID',=20]:=0D=20=20=20=20for=20x=20in=20=
range(len(sys.argv)):=0D=20=20=20=20=20=20=20=20if=20=
string.find(sys.argv[x],=20flag)=20=3D=3D=200:=0D=20=20=20=20=20=20=20=20=
=20=20=20=20pos=20=3D=20string.find(sys.argv[x],=20'=3D')=20+=201=0D=20=20=
=20=20=20=20=20=20=20=20=20=20if=20pos=20>=200:=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20vars()[flag]=20=3D=20eval(sys.argv[x][pos:])=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20sys.argv[x]=20=3D=20''=0D=0D=
#=20String=20options=0Dfor=20option=20in=20['WX_CONFIG',=20'WXDLLVER',=20=
'BUILD_BASE']:=0D=20=20=20=20for=20x=20in=20range(len(sys.argv)):=0D=20=20=
=20=20=20=20=20=20if=20string.find(sys.argv[x],=20option)=20=3D=3D=200:=0D=
=20=20=20=20=20=20=20=20=20=20=20=20pos=20=3D=20string.find(sys.argv[x],=20=
'=3D')=20+=201=0D=20=20=20=20=20=20=20=20=20=20=20=20if=20pos=20>=200:=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20vars()[option]=20=3D=20=
sys.argv[x][pos:]=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
sys.argv[x]=20=3D=20''=0D=0Dsys.argv=20=3D=20filter(None,=20sys.argv)=0D=0D=
=0D=0D=
#----------------------------------------------------------------------=0D=
#=20sanity=20checks=0D=0Dif=20CORE_ONLY:=0D=20=20=20=20BUILD_GLCANVAS=20=
=3D=200=0D=20=20=20=20BUILD_OGL=20=3D=200=0D=20=20=20=20BUILD_STC=20=3D=20=
0=0D=20=20=20=20BUILD_XRC=20=3D=200=0D=20=20=20=20BUILD_GIZMOS=20=3D=200=0D=
=20=20=20=20BUILD_DLLWIDGET=20=3D=200=0D=20=20=20=20BUILD_IEWIN=20=3D=20=
0=0D=0D=0Dif=20UNICODE=20and=20os.name=20!=3D=20'nt':=0D=20=20=20=20=
print=20"UNICODE=20is=20currently=20only=20supported=20on=20Win32"=0D=20=20=
=20=20sys.exit()=0D=0D=0Dif=20UNICODE:=0D=20=20=20=20BUILD_BASE=20=3D=20=
BUILD_BASE=20+=20'.unicode'=0D=20=20=20=20VERSION=20=3D=20VERSION=20+=20=
'u'=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Setup=20some=20platform=20specific=20stuff=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20os.name=20=3D=3D=20'nt':=0D=20=20=20=20#=20Set=20compile=20flags=20=
and=20such=20for=20MSVC.=20=20These=20values=20are=20derived=0D=20=20=20=20=
#=20from=20the=20wxWindows=20makefiles=20for=20MSVC,=20other=20compilers=20=
settings=0D=20=20=20=20#=20will=20probably=20vary...=0D=20=20=20=20if=20=
os.environ.has_key('WXWIN'):=0D=20=20=20=20=20=20=20=20WXDIR=20=3D=20=
os.environ['WXWIN']=0D=20=20=20=20else:=0D=20=20=20=20=20=20=20=20=
msg("WARNING:=20WXWIN=20not=20set=20in=20environment.")=0D=20=20=20=20=20=
=20=20=20WXDIR=20=3D=20'..'=20=20#=20assumes=20in=20CVS=20tree=0D=20=20=20=
=20WXPLAT=20=3D=20'__WXMSW__'=0D=20=20=20=20GENDIR=20=3D=20'msw'=0D=0D=20=
=20=20=20if=20debug:=0D=20=20=20=20=20=20=20=20FINAL=20=20=3D=200=0D=20=20=
=20=20=20=20=20=20HYBRID=20=3D=200=0D=0D=20=20=20=20if=20HYBRID:=0D=20=20=
=20=20=20=20=20=20FINAL=20=3D=200=0D=0D=20=20=20=20includes=20=3D=20=
['src',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20opj(WXDIR,=20=
'lib',=20'mswdll'=20+=20libFlag()),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20opj(WXDIR,=20'include'),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20]=0D=0D=20=20=20=20defines=20=3D=20[=20('WIN32',=20None),=20=20=
=20=20=20=20=20=20#=20Some=20of=20these=20are=20no=20longer=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20('__WIN32__',=20None),=20=20=20=20#=20=
necessary.=20=20Anybody=20know=20which?=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20('_WINDOWS',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('__WINDOWS__',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('WINVER',=20'0x0400'),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('__WIN95__',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('STRICT',=20None),=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20(WXPLAT,=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20('WXUSINGDLL',=20'1'),=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20('SWIG_GLOBAL',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20('HAVE_CONFIG_H',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20('WXP_USE_THREAD',=20'1'),=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20]=0D=0D=20=20=20=20if=20bcpp_compiling:=20=20#=20=
overwrite=20it=0D=20=20=20=20=20=20=20=20defines=20=3D=20[=0D=20=20=20=20=
=20=20=20=20=20=20=20=20('_WINDOWS',=20None),=0D=20=20=20=20=20=20=20=20=20=
=20=20=20('WINVER',=20'0x0400'),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('STRICT',=20None),=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('WXUSINGDLL',=20'1'),=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('SWIG_GLOBAL',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('HAVE_CONFIG_H',=20None),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('WXP_USE_THREAD',=20'1'),=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('WXUSE_DEFINE','1'),=0D=20=20=20=20=20=20=20=20=20=20=20=20=
('_RTLDLL',None),=0D=20=20=20=20=20=20=20=20=20=20=20=20]=0D=0D=0D=20=20=20=
=20if=20not=20FINAL=20or=20HYBRID:=0D=20=20=20=20=20=20=20=20=
defines.append(=20('__WXDEBUG__',=20None)=20)=0D=0D=20=20=20=20libdirs=20=
=3D=20[=20opj(WXDIR,=20'lib')=20]=0D=20=20=20=20wxdll=20=3D=20'wxmsw'=20=
+=20WXDLLVER=20+=20libFlag()=0D=20=20=20=20libs=20=3D=20[=20wxdll=20]=0D=0D=
=20=20=20=20if=20bcpp_compiling:=0D=20=20=20=20=20=20=20=20libs=20=3D=20=
[=20'wx'+WXBCPPLIBVER=20]=0D=0D=20=20=20=20libs=20=3D=20libs=20+=20=
['kernel32',=20'user32',=20'gdi32',=20'comdlg32',=0D=20=20=20=20=20=20=20=
=20=20=20=20=20'winspool',=20'winmm',=20'shell32',=20'oldnames',=20=
'comctl32',=0D=20=20=20=20=20=20=20=20=20=20=20=20'ctl3d32',=20'odbc32',=20=
'ole32',=20'oleaut32',=20'uuid',=20'rpcrt4',=0D=20=20=20=20=20=20=20=20=20=
=20=20=20'advapi32',=20'wsock32']=0D=0D=0D=20=20=20=20cflags=20=3D=20[=20=
'/Gy',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20#=20'/GX-'=20=20#=20=
workaround=20for=20internal=20compiler=20error=20in=20MSVC=20on=20some=20=
machines=0D=20=20=20=20=20=20=20=20=20=20=20=20=20]=0D=20=20=20=20lflags=20=
=3D=20None=0D=0D=0D=20=20=20=20if=20bcpp_compiling:=20=20#=20BCC=20flags=0D=
=20=20=20=20=20=20=20=20cflags=20=3D=20['-5',=20'-VF',=20=20###=20To=20=
support=20MSVC=20spurious=20semicolons=20in=20the=20class=20scope=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20###=20else,=20all=20=
semicolons=20at=20the=20end=20of=20all=20DECLARE_...CALLBACK...=20macros=20=
must=20be=20eliminated=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20'-Hc',=20'-H=3D'=20+=20opj(WXDIR,=20'\src\msw\wx32.csm'),=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'@'=20+=20opj(WXDIR,=20=
'\src\msw\wxwin32.cfg')=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20]=0D=20=20=20=20=20=20=20=20if=20not=20FINAL:=0D=20=20=20=20=20=20=20=
=20=20=20=20=20cflags=20=3D=20cflags=20+=20['/Od',=20'/v',=20'/y']=0D=20=20=
=20=20=20=20=20=20=20=20=20=20lflags=20=3D=20lflags=20+=20['/v',=20]=0D=0D=
=20=20=20=20else:=20=20#=20MSVC=20flags=0D=20=20=20=20=20=20=20=20if=20=
FINAL:=0D=20=20=20=20=20=20=20=20=20=20=20=20pass=20#cflags=20=3D=20=
cflags=20+=20['/O1']=0D=20=20=20=20=20=20=20=20elif=20HYBRID=20:=0D=20=20=
=20=20=20=20=20=20=20=20=20=20pass=20#cflags=20=3D=20cflags=20+=20=
['/Ox']=0D=20=20=20=20=20=20=20=20else:=0D=20=20=20=20=20=20=20=20=20=20=20=
=20pass=20#=20cflags=20=3D=20cflags=20+=20['/Od',=20'/Z7']=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20#=20lflags=20=3D=20['/DEBUG',=20]=0D=
=0D=0D=0D=0Delif=20os.name=20=3D=3D=20'posix'=20and=20sys.platform[:6]=20=
=3D=3D=20"darwin":=0D=20=20=20=20#=20Flags=20and=20such=20for=20a=20=
Darwin=20(Max=20OS=20X)=20build=20of=20Python=0D=0D=20=20=20=20WXDIR=20=3D=
=20'..'=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20assumes=20=
IN_CVS_TREE=0D=20=20=20=20WXPLAT=20=3D=20'__WXMAC__'=0D=20=20=20=20=
GENDIR=20=3D=20'mac'=0D=0D=20=20=20=20includes=20=3D=20['src']=0D=20=20=20=
=20defines=20=3D=20[('SWIG_GLOBAL',=20None),=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20('HAVE_CONFIG_H',=20None),=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20('WXP_USE_THREAD',=20'1'),=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20]=0D=20=20=20=20libdirs=20=3D=20[]=0D=20=20=20=20libs=20=
=3D=20[]=0D=0D=20=20=20=20cflags=20=3D=20os.popen(WX_CONFIG=20+=20'=20=
--cxxflags',=20'r').read()[:-1]=0D=20=20=20=20cflags=20=3D=20=
string.split(cflags)=0D=20=20=20=20if=20UNDEF_NDEBUG:=0D=20=20=20=20=20=20=
=20=20cflags.append('-UNDEBUG')=0D=20=20=20=20if=20debug:=0D=20=20=20=20=20=
=20=20=20cflags.append('-g')=0D=20=20=20=20=20=20=20=20=
cflags.append('-O0')=0D=0D=20=20=20=20lflags=20=3D=20os.popen(WX_CONFIG=20=
+=20'=20--libs',=20'r').read()[:-1]=0D=20=20=20=20lflags=20=3D=20=
string.split(lflags)=0D=0D=20=20=20=20NO_SCRIPTS=20=3D=201=0D=0D=0Delif=20=
os.name=20=3D=3D=20'posix':=0D=20=20=20=20#=20Set=20flags=20for=20Unix=20=
type=20platforms=0D=0D=20=20=20=20WXDIR=20=3D=20'..'=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20#=20assumes=20IN_CVS_TREE=0D=20=20=20=20WXPLAT=20=3D=20=
'__WXGTK__'=20=20=20=20=20=20#=20and=20assumes=20GTK...=0D=20=20=20=20=
GENDIR=20=3D=20'gtk'=20=20=20=20=20=20=20=20=20=20=20=20#=20Need=20to=20=
allow=20for=20Motif=20eventually=20too=0D=0D=20=20=20=20includes=20=3D=20=
['src']=0D=0D=20=20=20=20defines=20=3D=20[('SWIG_GLOBAL',=20None),=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20('HAVE_CONFIG_H',=20None),=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20('WXP_USE_THREAD',=20'1'),=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20]=0D=20=20=20=20libdirs=20=3D=20=
[]=0D=20=20=20=20libs=20=3D=20[]=0D=0D=20=20=20=20cflags=20=3D=20=
os.popen(WX_CONFIG=20+=20'=20--cxxflags',=20'r').read()[:-1]=20+=20'=20'=20=
+=20\=0D=20=20=20=20=20=20=20=20=20=20=20=20=20os.popen('gtk-config=20=
--cflags',=20'r').read()[:-1]=0D=20=20=20=20cflags=20=3D=20=
string.split(cflags)=0D=20=20=20=20if=20UNDEF_NDEBUG:=0D=20=20=20=20=20=20=
=20=20cflags.append('-UNDEBUG')=0D=20=20=20=20if=20debug:=0D=20=20=20=20=20=
=20=20=20cflags.append('-g')=0D=20=20=20=20=20=20=20=20=
cflags.append('-O0')=0D=0D=20=20=20=20lflags=20=3D=20os.popen(WX_CONFIG=20=
+=20'=20--libs',=20'r').read()[:-1]=0D=20=20=20=20lflags=20=3D=20=
string.split(lflags)=0D=0D=0Delif=20os.name=20=3D=3D=20"mac":=0D=09=
#WXDIR=20=3D=20'::'=20=20=20=20=20=20=20=20=20=20=20=20=20=20#=20assumes=20=
IN_CVS_TREE=20-=20not=20working=20with=20CodeWarrior??=0D=09WXDIR=20=3D=20=
'Macintosh=20HD:Users:kevino:oss:wxPythonSrc-2.3.3.1'=0D=20=09WXPLAT=20=3D=
=20'__WXMAC__'=0D=09GENDIR=20=3D=20'mac'=0D=0D=20=09includes=20=3D=20=
['src',=20=20opj(WXDIR,=20'lib'),=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20opj(WXDIR,=20'include'),=20"Macintosh=20HD:Applications:Python=20=
2.2.2:Mac:mwerks:",=20"Macintosh=20HD:Applications:Python=20=
2.2.2:Mac:include:"=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=0D=
=0D=09defines=20=3D=20[('SWIG_GLOBAL',=20None),=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20('HAVE_CONFIG_H',=20None),=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20('WXP_USE_THREAD',=20'1'),(WXPLAT,=20'1'),=20=
('__WXDEBUG__',=20'1'),=20('WXMAKINGDLL',=20'1')=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20]=0D=20=09libdirs=20=3D=20[opj(WXDIR,=20'lib')]=0D=09=
libs=20=3D=20['wx_Carbon_d.shlb',=20'wx_Carbon.rsrc',=20'jpeg_PPC.lib',=20=
'png_PPC.lib',=20'tif_PPC_d.lib',=20'zlib_PPC.lib'=20]=0D=09=0D=09cflags=20=
=3D=20[]=0D=09lflags=20=3D=20[]=0D=0D=20=20=20=20=09NO_SCRIPTS=20=3D=201=0D=
=0D=
#----------------------------------------------------------------------=0D=
#=20Check=20if=20the=20version=20file=20needs=20updated=0D=
#----------------------------------------------------------------------=0D=
=0D#if=20IN_CVS_TREE=20and=20newer('setup.py',=20'src/__version__.py'):=0D=
open('src/__version__.py',=20'w').write("ver=20=3D=20'%s'\n"=20%=20=
VERSION)=0D=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20SWIG=20defaults=0D=
#----------------------------------------------------------------------=0D=
=0Dswig_force=20=3D=20force=0Dswig_args=20=3D=20['-c++',=20'-shadow',=20=
'-python',=20'-keyword',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
'-dnone',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20#'-dascii',=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20#'-docstring',=20'-Sbefore',=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20'-I./src',=20'-D'+WXPLAT,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20]=0Dif=20UNICODE:=0D=20=20=20=20=
swig_args.append('-DwxUSE_UNICODE')=0D=0Dswig_deps=20=3D=20=
['src/my_typemaps.i']=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20CORE=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY:=0D=20=20=20=20msg('Preparing=20CORE...')=0D=20=20=20=
=20swig_files=20=3D=20[=20'wx.i',=20'windows.i',=20'windows2.i',=20=
'windows3.i',=20'events.i',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20'misc.i',=20'misc2.i',=20'gdi.i',=20'mdi.i',=20'controls.i',=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'controls2.i',=20=
'cmndlgs.i',=20'stattool.i',=20'frames.i',=20'image.i',=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20'printfw.i',=20'sizers.i',=20=
'clip_dnd.i',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'filesys.i',=20'streams.i',=20'utils.i',=20'fonts.i'=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20]=0D=0D=20=20=20=20swig_sources=20=
=3D=20run_swig(swig_files,=20'src',=20GENDIR,=20PKGDIR,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
USE_SWIG,=20swig_force,=20swig_args,=20swig_deps)=0D=0D=20=20=20=20=
copy_file(os.path.join('src',=20'__init__.py'),=20PKGDIR,=20update=3D1,=20=
verbose=3D0)=0D=20=20=20=20copy_file(os.path.join('src',=20=
'__version__.py'),=20PKGDIR,=20update=3D1,=20verbose=3D0)=0D=20=20=20=20=
copy_file(os.path.join('src',=20'wxc.pyd.manifest'),=20PKGDIR,=20=
update=3D1,=20verbose=3D0)=0D=0D=20=20=20=20if=20IN_CVS_TREE:=20=20=20#=20=
update=20the=20license=20files=0D=20=20=20=20=20=20=20=20=
mkpath('licence')=0D=20=20=20=20=20=20=20=20for=20file=20in=20=
['preamble.txt',=20'licence.txt',=20'licendoc.txt',=20'lgpl.txt']:=0D=20=20=
=20=20=20=20=20=20=20=20=20=20copy_file(opj(WXDIR,=20'docs',=20file),=20=
opj('licence',file),=20update=3D1,=20verbose=3D0)=0D=0D=0D=20=20=20=20if=20=
os.name=20=3D=3D=20'nt':=0D=20=20=20=20=20=20=20=20rc_file=20=3D=20=
['src/wxc.rc']=0D=20=20=20=20else:=0D=20=20=20=20=20=20=20=20rc_file=20=3D=
=20[]=0D=0D=0D=20=20=20=20ext=20=3D=20Extension('wxc',=20=
['src/helpers.cpp',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20'src/libpy.c',=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20+=20=
rc_file=20+=20swig_sources,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20include_dirs=20=3D=20includes,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20defines,=0D=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20library_dirs=20=
=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20libraries=20=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=3D=20=
lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20)=0D=
=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=20=20=20=20#=20Extension=20=
for=20the=20grid=20module=0D=20=20=20=20swig_sources=20=3D=20=
run_swig(['grid.i'],=20'src',=20GENDIR,=20PKGDIR,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20USE_SWIG,=20=
swig_force,=20swig_args,=20swig_deps)=0D=20=20=20=20ext=20=3D=20=
Extension('gridc',=20swig_sources,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20include_dirs=20=3D=20=20includes,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=20=20=20=20#=20=
Extension=20for=20the=20html=20modules=0D=20=20=20=20swig_sources=20=3D=20=
run_swig(['html.i',=20'htmlhelp.i'],=20'src',=20GENDIR,=20PKGDIR,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20USE_SWIG,=20swig_force,=20swig_args,=20swig_deps)=0D=20=20=20=20ext=20=
=3D=20Extension('htmlc',=20swig_sources,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20include_dirs=20=3D=20=20includes,=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=20=20=20=20#=20=
Extension=20for=20the=20calendar=20module=0D=20=20=20=20swig_sources=20=3D=
=20run_swig(['calendar.i'],=20'src',=20GENDIR,=20PKGDIR,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
USE_SWIG,=20swig_force,=20swig_args,=20swig_deps)=0D=20=20=20=20ext=20=3D=20=
Extension('calendarc',=20swig_sources,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20include_dirs=20=3D=20=20includes,=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=20=20=20=20#=20=
Extension=20for=20the=20help=20module=0D=20=20=20=20swig_sources=20=3D=20=
run_swig(['help.i'],=20'src',=20GENDIR,=20PKGDIR,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20USE_SWIG,=20=
swig_force,=20swig_args,=20swig_deps)=0D=20=20=20=20ext=20=3D=20=
Extension('helpc',=20swig_sources,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20include_dirs=20=3D=20=20includes,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=20=20=20=20#=20=
Extension=20for=20the=20wizard=20module=0D=20=20=20=20swig_sources=20=3D=20=
run_swig(['wizard.i'],=20'src',=20GENDIR,=20PKGDIR,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20USE_SWIG,=20=
swig_force,=20swig_args,=20swig_deps)=0D=20=20=20=20ext=20=3D=20=
Extension('wizardc',=20swig_sources,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20include_dirs=20=3D=20=20includes,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20GLCanvas=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0DCTRB_SRC=20=3D=20=20opj(WXDIR,=20'contrib/src')=0DCTRB_INC=20=3D=20=20=
opj(WXDIR,=20'contrib/include/wx')=0D=0Dif=20BUILD_GLCANVAS=20or=20=
GL_ONLY:=0D=20=20=20=20msg('Preparing=20GLCANVAS...')=0D=20=20=20=20=
location=20=3D=20'contrib/glcanvas'=0D=20=20=20=20swig_files=20=3D=20=
['glcanvas.i']=0D=20=20=20=20other_sources=20=3D=20[]=0D=0D=20=20=20=20=
swig_sources=20=3D=20run_swig(swig_files,=20location,=20GENDIR,=20=
PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20USE_SWIG,=20swig_force,=20swig_args,=20swig_deps)=0D=
=0D=20=20=20=20gl_libs=20=3D=20[]=0D=20=20=20=20if=20os.name=20=3D=3D=20=
'posix':=0D=20=20=20=20=20=20=20=20gl_config=20=3D=20os.popen(WX_CONFIG=20=
+=20'=20--gl-libs',=20'r').read()[:-1]=0D=20=20=20=20=20=20=20=20=
gl_lflags=20=3D=20string.split(gl_config)=20+=20lflags=0D=20=20=20=20=20=20=
=20=20gl_libs=20=3D=20libs=0D=20=20=20=20else:=0D=20=20=20=20=20=20=20=20=
other_sources=20=3D=20[opj(location,=20'msw/myglcanvas.cpp')]=0D=20=20=20=
=20=20=20=20=20gl_libs=20=3D=20libs=20+=20['opengl32',=20'glu32']=0D=20=20=
=20=20=20=20=20=20gl_lflags=20=3D=20lflags=0D=0D=20=20=20=20ext=20=3D=20=
Extension('glcanvasc',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20swig_sources=20+=20other_sources,=0D=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20include_dirs=20=3D=20includes,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20gl_libs,=0D=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
extra_link_args=20=3D=20gl_lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20)=0D=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=
=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20OGL=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY=20and=20BUILD_OGL:=0D=20=20=20=20msg('Preparing=20=
OGL...')=0D=20=20=20=20location=20=3D=20'contrib/ogl'=0D=20=20=20=20=
OGLLOC=20=3D=20opj(location,=20'contrib/src/ogl')=0D=20=20=20=20OGLINC=20=
=3D=20opj(location,=20'contrib/include')=0D=0D=20=20=20=20swig_files=20=3D=
=20['ogl.i',=20'oglbasic.i',=20'oglshapes.i',=20'oglshapes2.i',=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'oglcanvas.i']=0D=0D=20=20=20=
=20swig_sources=20=3D=20run_swig(swig_files,=20location,=20'',=20PKGDIR,=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20USE_SWIG,=20swig_force,=20swig_args,=20swig_deps)=0D=0D=20=20=20=
=20if=20IN_CVS_TREE:=0D=20=20=20=20=20=20=20=20#=20make=20sure=20local=20=
copy=20of=20contrib=20files=20are=20up=20to=20date=0D=20=20=20=20=20=20=20=
=20contrib_copy_tree(opj(CTRB_INC,=20'ogl'),=20opj(OGLINC,=20'wx/ogl'))=0D=
=20=20=20=20=20=20=20=20contrib_copy_tree(opj(CTRB_SRC,=20'ogl'),=20=
OGLLOC)=0D=0D=20=20=20=20ext=20=3D=20Extension('oglc',=20['%s/basic.cpp'=20=
%=20OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20'%s/bmpshape.cpp'=20%=20OGLLOC,=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/composit.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/divided.cpp'=20%=20=
OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20'%s/lines.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/misc.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/basic2.cpp'=20%=20OGLLOC,=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20'%s/canvas.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/constrnt.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/drawn.cpp'=20%=20=
OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20'%s/mfutils.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/ogldiag.cpp'=20%=20OGLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20+=20swig_sources,=0D=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20include_dirs=20=
=3D=20=20[OGLINC]=20+=20includes,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20define_macros=20=3D=20defines,=0D=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20library_dirs=20=3D=20libdirs,=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20libraries=20=
=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20extra_compile_args=20=3D=20cflags,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20extra_link_args=20=3D=20lflags,=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20)=0D=0D=20=20=20=20=
wxpExtensions.append(ext)=0D=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20STC=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY=20and=20BUILD_STC:=0D=20=20=20=20msg('Preparing=20=
STC...')=0D=20=20=20=20location=20=3D=20'contrib/stc'=0D=20=20=20=20=
STCLOC=20=3D=20opj(location,=20'contrib/src/stc')=0D=20=20=20=20STCINC=20=
=3D=20opj(location,=20'contrib/include')=0D=20=20=20=20STC_H=20=3D=20=20=
opj(location,=20'contrib/include/wx/stc')=0D=0D=20=20=20=20if=20=
IN_CVS_TREE:=0D=20=20=20=20=20=20=20=20#=20Check=20if=20gen_iface=20=
needs=20to=20be=20run=20for=20the=20wxSTC=20sources=0D=20=20=20=20=20=20=20=
=20if=20(newer(opj(CTRB_SRC,=20'stc/stc.h.in'),=20=20=20=20=20=
opj(CTRB_INC,=20'stc/stc.h'=20=20))=20or=0D=20=20=20=20=20=20=20=20=20=20=
=20=20newer(opj(CTRB_SRC,=20'stc/stc.cpp.in'),=20=20=20opj(CTRB_SRC,=20=
'stc/stc.cpp'))=20or=0D=20=20=20=20=20=20=20=20=20=20=20=20=
newer(opj(CTRB_SRC,=20'stc/gen_iface.py'),=20opj(CTRB_SRC,=20=
'stc/stc.cpp'))):=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20msg('Running=20=
gen_iface.py,=20regenerating=20stc.h=20and=20stc.cpp...')=0D=20=20=20=20=20=
=20=20=20=20=20=20=20cwd=20=3D=20os.getcwd()=0D=20=20=20=20=20=20=20=20=20=
=20=20=20os.chdir(opj(CTRB_SRC,=20'stc'))=0D=20=20=20=20=20=20=20=20=20=20=
=20=20import=20gen_iface=0D=20=20=20=20=20=20=20=20=20=20=20=20=
gen_iface.main([])=0D=20=20=20=20=20=20=20=20=20=20=20=20os.chdir(cwd)=0D=
=0D=0D=20=20=20=20=20=20=20=20#=20make=20sure=20local=20copy=20of=20=
contrib=20files=20are=20up=20to=20date=0D=20=20=20=20=20=20=20=20=
contrib_copy_tree(opj(CTRB_INC,=20'stc'),=20opj(STCINC,=20'wx/stc'))=0D=20=
=20=20=20=20=20=20=20contrib_copy_tree(opj(CTRB_SRC,=20'stc'),=20STCLOC)=0D=
=0D=0D=0D=20=20=20=20swig_files=20=3D=20['stc_.i']=0D=20=20=20=20=
swig_sources=20=3D=20run_swig(swig_files,=20location,=20GENDIR,=20=
PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20USE_SWIG,=20swig_force,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20swig_args=20+=20=
['-I'+STC_H,=20'-I'+location],=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20[opj(STC_H,=20'stc.h')]=20+=20=
swig_deps)=0D=0D=20=20=20=20#=20copy=20a=20contrib=20project=20specific=20=
py=20module=20to=20the=20main=20package=20dir=0D=20=20=20=20=
copy_file(opj(location,=20'stc.py'),=20PKGDIR,=20update=3D1,=20=
verbose=3D0)=0D=0D=20=20=20=20#=20add=20some=20include=20dirs=20to=20the=20=
standard=20set=0D=20=20=20=20stc_includes=20=3D=20includes[:]=0D=20=20=20=
=20stc_includes.append('%s/scintilla/include'=20%=20STCLOC)=0D=20=20=20=20=
stc_includes.append('%s/scintilla/src'=20%=20STCLOC)=0D=20=20=20=20=
stc_includes.append(STCINC)=0D=0D=20=20=20=20#=20and=20some=20macro=20=
definitions=0D=20=20=20=20stc_defines=20=3D=20defines[:]=0D=20=20=20=20=
stc_defines.append(=20('__WX__',=20None)=20)=0D=20=20=20=20=
stc_defines.append(=20('SCI_LEXER',=20None)=20)=0D=20=20=20=20=
stc_defines.append(=20('LINK_LEXERS',=20None)=20)=0D=0D=0D=20=20=20=20=
ext=20=3D=20Extension('stc_c',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20['%s/scintilla/src/AutoComplete.cxx'=20%=20STCLOC,=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/CallTip.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/CellBuffer.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/ContractionState.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/Document.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/DocumentAccessor.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/Editor.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/Indicator.cxx'=20%=20=
STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/KeyMap.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/KeyWords.cxx'=20%=20=
STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/LineMarker.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/PropSet.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/RESearch.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/ScintillaBase.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/Style.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/StyleContext.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/UniConversion.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/ViewStyle.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/WindowAccessor.cxx'=20%=20STCLOC,=0D=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/LexAda.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexAVE.cxx'=20%=20=
STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/LexBaan.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexBullant.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/LexCPP.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexConf.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/LexCrontab.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/LexEiffel.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexHTML.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/LexLisp.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexLua.cxx'=20%=20=
STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/scintilla/src/LexMatlab.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexOthers.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/LexPascal.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexPerl.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/LexPython.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexRuby.cxx'=20=
%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/scintilla/src/LexSQL.cxx'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/scintilla/src/LexVB.cxx'=20%=20=
STCLOC,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/PlatWX.cpp'=20%=20STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20'%s/ScintillaWX.cpp'=20%=20STCLOC,=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/stc.cpp'=20%=20=
STCLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
]=20+=20swig_sources,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20include_dirs=20=3D=20stc_includes,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20stc_defines,=0D=
=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20IEWIN=20extension=20module=20(experimental)=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY=20and=20BUILD_IEWIN:=0D=20=20=20=20msg('Preparing=20=
IEWIN...')=0D=20=20=20=20location=20=3D=20'contrib/iewin'=0D=0D=20=20=20=20=
swig_files=20=3D=20['iewin.i',=20]=0D=0D=20=20=20=20swig_sources=20=3D=20=
run_swig(swig_files,=20location,=20'',=20PKGDIR,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20USE_SWIG,=20=
swig_force,=20swig_args,=20swig_deps)=0D=0D=0D=20=20=20=20ext=20=3D=20=
Extension('iewinc',=20['%s/IEHtmlWin.cpp'=20%=20location,=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/wxactivex.cpp'=20%=20location,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20+=20=
swig_sources,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20include_dirs=20=3D=20=20includes,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20define_macros=20=3D=20defines,=0D=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20library_dirs=20=3D=20=
libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
libraries=20=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=3D=20lflags,=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20)=0D=0D=20=20=
=20=20wxpExtensions.append(ext)=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20XRC=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY=20and=20BUILD_XRC:=0D=20=20=20=20msg('Preparing=20=
XRC...')=0D=20=20=20=20location=20=3D=20'contrib/xrc'=0D=20=20=20=20=
XMLLOC=20=3D=20opj(location,=20'contrib/src/xrc')=0D=20=20=20=20XMLINC=20=
=3D=20opj(location,=20'contrib/include')=0D=0D=20=20=20=20swig_files=20=3D=
=20['xrc.i']=0D=0D=20=20=20=20swig_sources=20=3D=20run_swig(swig_files,=20=
location,=20'',=20PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20USE_SWIG,=20swig_force,=20=
swig_args,=20swig_deps)=0D=0D=20=20=20=20xmlres_includes=20=3D=20=
includes[:]=0D=20=20=20=20xmlres_includes.append('%s/expat/xmlparse'=20%=20=
XMLLOC)=0D=20=20=20=20xmlres_includes.append('%s/expat/xmltok'=20%=20=
XMLLOC)=0D=20=20=20=20xmlres_includes.append(XMLINC)=0D=0D=0D=20=20=20=20=
#=20make=20sure=20local=20copy=20of=20contrib=20files=20are=20up=20to=20=
date=0D=20=20=20=20if=20IN_CVS_TREE:=0D=20=20=20=20=20=20=20=20=
contrib_copy_tree(opj(CTRB_INC,=20'xrc'),=20opj(XMLINC,=20'wx/xrc'))=0D=20=
=20=20=20=20=20=20=20contrib_copy_tree(opj(CTRB_SRC,=20'xrc'),=20XMLLOC)=0D=
=0D=20=20=20=20ext=20=3D=20Extension('xrcc',=20=
['%s/expat/xmlparse/xmlparse.c'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/expat/xmltok/xmlrole.c'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/expat/xmltok/xmltok.c'=20%=20XMLLOC,=0D=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_bmp.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_bmpbt.cpp'=20=
%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_bttn.cpp'=20%=20XMLLOC,=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20'%s/xh_cald.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_chckb.cpp'=20%=20XMLLOC,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_chckl.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_choic.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_combo.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_dlg.cpp'=20=
%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_frame.cpp'=20%=20XMLLOC,=0D=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20'%s/xh_gauge.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/xh_gdctl.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_html.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_listb.cpp'=20=
%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_listc.cpp'=20%=20XMLLOC,=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20'%s/xh_menu.cpp'=20%=20XMLLOC,=0D=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_notbk.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_panel.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_radbt.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_radbx.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_scrol.cpp'=20%=20XMLLOC,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_sizer.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_slidr.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_spin.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_stbmp.cpp'=20=
%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_stbox.cpp'=20%=20XMLLOC,=0D=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20'%s/xh_stlin.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20'%s/xh_sttxt.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xh_text.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_toolb.cpp'=20=
%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20'%s/xh_tree.cpp'=20%=20XMLLOC,=0D=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20'%s/xh_unkwn.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/xml.cpp'=20%=20XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20'%s/xmlres.cpp'=20%=20=
XMLLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20'%s/xmlrsall.cpp'=20%=20XMLLOC,=0D=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20]=20+=20swig_sources,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20include_dirs=20=3D=20=20xmlres_includes,=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20=
defines,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
library_dirs=20=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20libraries=20=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=
=3D=20lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20)=0D=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20GIZMOS=20=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY=20and=20BUILD_GIZMOS:=0D=20=20=20=20msg('Preparing=20=
GIZMOS...')=0D=20=20=20=20location=20=3D=20'contrib/gizmos'=0D=20=20=20=20=
GIZMOLOC=20=3D=20opj(location,=20'contrib/src/gizmos')=0D=20=20=20=20=
GIZMOINC=20=3D=20opj(location,=20'contrib/include')=0D=0D=20=20=20=20=
swig_files=20=3D=20['gizmos.i']=0D=0D=20=20=20=20swig_sources=20=3D=20=
run_swig(swig_files,=20location,=20'',=20PKGDIR,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20USE_SWIG,=20=
swig_force,=20swig_args,=20swig_deps)=0D=0D=20=20=20=20gizmos_includes=20=
=3D=20includes[:]=0D=20=20=20=20gizmos_includes.append(GIZMOINC)=0D=0D=0D=
=20=20=20=20#=20make=20sure=20local=20copy=20of=20contrib=20files=20are=20=
up=20to=20date=0D=20=20=20=20if=20IN_CVS_TREE:=0D=20=20=20=20=20=20=20=20=
contrib_copy_tree(opj(CTRB_INC,=20'gizmos'),=20opj(GIZMOINC,=20=
'wx/gizmos'))=0D=20=20=20=20=20=20=20=20contrib_copy_tree(opj(CTRB_SRC,=20=
'gizmos'),=20GIZMOLOC)=0D=0D=20=20=20=20ext=20=3D=20Extension('gizmosc',=20=
[=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20'%s/dynamicsash.cpp'=20%=20GIZMOLOC,=0D=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20'%s/editlbox.cpp'=20%=20GIZMOLOC,=0D=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
#'%s/multicell.cpp'=20%=20GIZMOLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/splittree.cpp'=20%=20GIZMOLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/ledctrl.cpp'=20=20=20%=20GIZMOLOC,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20+=20=
swig_sources,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20include_dirs=20=3D=20=20gizmos_includes,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20define_macros=20=3D=20defines,=0D=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20library_dirs=20=
=3D=20libdirs,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20libraries=20=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20extra_compile_args=20=3D=20cflags,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20extra_link_args=20=3D=20=
lflags,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20)=0D=
=0D=20=20=20=20wxpExtensions.append(ext)=0D=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Define=20the=20DLLWIDGET=20=20extension=20module=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20not=20GL_ONLY=20and=20BUILD_DLLWIDGET:=0D=20=20=20=20=
msg('Preparing=20DLLWIDGET...')=0D=20=20=20=20location=20=3D=20=
'contrib/dllwidget'=0D=20=20=20=20swig_files=20=3D=20['dllwidget_.i']=0D=0D=
=20=20=20=20swig_sources=20=3D=20run_swig(swig_files,=20location,=20'',=20=
PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20USE_SWIG,=20swig_force,=20swig_args,=20swig_deps)=0D=
=0D=20=20=20=20#=20copy=20a=20contrib=20project=20specific=20py=20module=20=
to=20the=20main=20package=20dir=0D=20=20=20=20copy_file(opj(location,=20=
'dllwidget.py'),=20PKGDIR,=20update=3D1,=20verbose=3D0)=0D=0D=20=20=20=20=
ext=20=3D=20Extension('dllwidget_c',=20[=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
'%s/dllwidget.cpp'=20%=20location,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20]=20+=20swig_sources,=0D=
=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
include_dirs=20=3D=20=20includes,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20define_macros=20=3D=20defines,=0D=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20library_dirs=20=3D=20libdirs,=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20libraries=20=
=3D=20libs,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20extra_compile_args=20=3D=20cflags,=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20extra_link_args=20=3D=20lflags,=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20)=0D=0D=20=20=20=20=
wxpExtensions.append(ext)=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Tools=20and=20scripts=0D=
#----------------------------------------------------------------------=0D=
=0D##=20TOOLS=20=3D=20[("wxPython/tools",=20=20=20=20=20=20=20=20=
glob.glob("tools/*.py")),=0D##=20=20=20=20=20=20=20=20=20=20=
("wxPython/tools/XRCed",=20=20glob.glob("tools/XRCed/*.py")=20+=0D##=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20glob.glob("tools/XRCed/*.xrc")=20+=0D##=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20["tools/XRCed/CHANGES",=0D##=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20"tools/XRCed/TODO",=0D##=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
"tools/XRCed/README"]),=0D##=20=20=20=20=20=20=20=20=20=20]=0D=0D=0Dif=20=
NO_SCRIPTS:=0D=20=20=20=20SCRIPTS=20=3D=20None=0Delse:=0D=20=20=20=20=
SCRIPTS=20=3D=20[opj(os.path.join('scripts',=20'img2png')),=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20opj(os.path.join('scripts','img2xpm')),=0D=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
opj(os.path.join('scripts','img2py')),=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20opj(os.path.join('scripts','xrced')),=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20opj(os.path.join('scripts',=20'pyshell')),=0D=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=
opj(os.path.join('scripts','pycrust')),=0D=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20]=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#=20Do=20the=20Setup/Build/Install/Whatever=0D=
#----------------------------------------------------------------------=0D=
=0Dif=20__name__=20=3D=3D=20"__main__":=0D=20=20=20=20if=20not=20=
GL_ONLY:=0D=20=20=20=20=20=20=20=20setup(name=20=20=20=20=20=20=20=20=20=20=
=20=20=20=3D=20PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
version=20=20=20=20=20=20=20=20=20=20=3D=20VERSION,=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20description=20=20=20=20=20=20=3D=20DESCRIPTION,=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20long_description=20=3D=20=
LONG_DESCRIPTION,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20author=20=20=
=20=20=20=20=20=20=20=20=20=3D=20AUTHOR,=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20author_email=20=20=20=20=20=3D=20AUTHOR_EMAIL,=0D=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20url=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=3D=20URL,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20license=20=20=20=20=
=20=20=20=20=20=20=3D=20LICENSE,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20packages=20=3D=20[PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20PKGDIR+'.lib',=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
PKGDIR+'.lib.editor',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20PKGDIR+'.lib.mixins',=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
PKGDIR+'.lib.PyCrust',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20PKGDIR+'.tools',=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
PKGDIR+'.tools.XRCed',=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20],=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20ext_package=20=3D=20PKGDIR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20ext_modules=20=3D=20wxpExtensions,=0D=0D=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20options=20=3D=20{=20'build'=20:=20{=20'build_base'=20:=20=
BUILD_BASE=20}})=0D=0D=20=20=20=20else:=0D=0D=20=20=20=20=20=20=20=20=
setup(name=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20"wxPython-gl",=0D=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20version=20=20=20=20=20=20=20=20=20=
=20=3D=20VERSION,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
description=20=20=20=20=20=20=3D=20"wxGLCanvas=20class=20for=20=
wxPython",=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20author=20=20=20=20=
=20=20=20=20=20=20=20=3D=20AUTHOR,=0D=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20author_email=20=20=20=20=20=3D=20AUTHOR_EMAIL,=0D=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20url=20=20=20=20=20=20=20=20=20=20=20=20=20=20=3D=20=
URL,=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20license=20=20=20=20=20=20=
=20=20=20=20=3D=20LICENSE,=0D=0D=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
py_modules=20=3D=20[=20"wxPython.glcanvas"=20],=0D=0D=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20ext_package=20=3D=20PKGDIR,=0D=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20ext_modules=20=3D=20wxpExtensions,=0D=0D=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20)=0D=0D=0D=0D=0D=
#----------------------------------------------------------------------=0D=
#----------------------------------------------------------------------=0D=

--Apple-Mail-38-559729230--

--Apple-Mail-37-559729229--



From Jack.Jansen@oratrix.com  Sun Nov 10 20:02:50 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 10 Nov 2002 21:02:50 +0100
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build question
In-Reply-To: <p05200f02b9f304997af8@[140.142.183.50]>
Message-ID: <63BBC384-F4E7-11D6-B589-000A27B19B96@oratrix.com>

On zaterdag, nov 9, 2002, at 19:41 Europe/Amsterdam, Russell E Owen 
wrote:
> Regarding an earlier post about trouble with PYTHONSTARTUP, I have 
> more info on it. Defining the environment variable in 
> ~/.MacOSX/environment.plist does work fine for plain "python" (despite 
> my earlier report to the contrary); however it still does *NOT* work 
> for pythonw (it shows up in os.environ but the file is not actually 
> run when pythonw starts up).

The problem is that in 2.2.2 pythonw is based on the macmain.c main 
program, the same as used for MacPython. python uses the standard Unix 
main.c main program. The macmain.c code doesn't know about environment 
variables. As of 2.3a0 this has been changed and the two binaries are 
now actually identical.

For pythonw you could put the startup code in a file called 
"PythonStartup", but unfortunately that file has to live in the current 
directory.
>
> What I did wrong the first time was use ~ in my definition of the 
> environment variable. I'd forgotten that ~ is not expanded when it 
> appears in ~/.MacOSX/environment.plist. (I've also posted a page about 
> using this file to define environment variables for MacOS X native 
> applications, and have linked to it from my "how to build Python 
> 2.2.2" page).

Boo! Hiss!
I would file an Apple bug report for this if I were you.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Sun Nov 10 20:08:41 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 10 Nov 2002 21:08:41 +0100
Subject: [Pythonmac-SIG] Using custom DLOGs with EasyDialogs
In-Reply-To: <20021108154635.43426.qmail@web13204.mail.yahoo.com>
Message-ID: <35456F86-F4E8-11D6-B589-000A27B19B96@oratrix.com>

On vrijdag, nov 8, 2002, at 16:46 Europe/Amsterdam, ang blank wrote:

> I would like to know where I am supposed to put custom
> DLOG resources so they can be called by EasyDialogs.
> I would also like to know where I can find the correct
> item numbers for the items within the DLOG.
>
> I would imagine that I could copy the appropriate DLOG
> from the Python Core and modify it and give it a
> different ID number.  My only problem, I think, is
> that I don't know where to put my modified DLOG
> resource.

That should work, but don't forget the copy the DITL as well.

> I have tried putting it into an applet, but it will
> just throw this error:
>
> Traceback (most recent call last):
>   File "Macintosh HD:Desktop Folder:EasyDialogs", line
> 5, in ?
>     EasyDialogs.Message('EasyDialogs.Message in
> action', id=512, ok='OK!')
>   File "Macintosh HD:Applications (Mac OS 9):Python
> 2.2.1:Mac:Lib:EasyDialogs.py", line 55, in Message
>     h = d.GetDialogItemAsControl(2)
> MacOS.Error: (-30596, 'errItemNotControl')

Either you forgot the DITL (or didn't renumber it correctly, it's hell 
to get these resources that refer to each other right manually), or 
you've changed the order of the items in the dialog so item 2 is indeed 
no longer a control.
>
> If I try putting the DLOG into a script file, the
> output window will say
>
> Can't get DLOG resource with id = 512

That won't work, at least not automatically. What you could do is put 
the resource into a resource file and manually open that with 
macresource.need(). Or even completely manually with OpenResFile() or 
one of it's friends. If your module is called foo.py, you call your 
resource file foo.rsrc and use macresource.need() then everything will 
automagically work for applets (i.e. foo.rsrc will be copied to the 
applet resource fork, and macresource.need will detect this and not try 
to open the .rsrc file anymore).

You could put the resource into the resource fork of the .py file, but 
I wouldn't advice it. There's all sorts of tools that think .py files 
are data-fork-only, so there's a good chance of losing your resources 
when you transfer your file over the internet or something.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Sun Nov 10 20:15:01 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 10 Nov 2002 21:15:01 +0100
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build works; 3 minor questions
In-Reply-To: <p05200f01b9f1a2049bb1@[128.95.99.44]>
Message-ID: <1759786E-F4E9-11D6-B589-000A27B19B96@oratrix.com>

On vrijdag, nov 8, 2002, at 18:56 Europe/Amsterdam, Russell E Owen 
wrote:
>>> 2) Is it possible to make a Python/Tkinter source file that can be 
>>> run as a command (i.e. that has a working #! line...
>>
>> #! /Applications/Python.app/Contents/MacOS/python
>> Not pretty, but it works.
>
> Unfortunately, it works exactly like #!/usr/local/lib/python: the 
> Python code runs (which is a big step forward from 
> #!/usr/local/bin/pythonw), but one cannot bring Tk windows to the 
> front!

Strange... The first thing to check is whether this thing behaves as a 
"real" application. If it is a real application it should have a dock 
icon and a menubar. My guess is that it won't. (I.e. if you *do* have 
an icon and a menubar but you cannot bring windows to the front you've 
found a problem that is new to me).

If it doesn't have an icon the problem is that the program isn't 
properly registered with the window server, and we have to find out why 
not. Try printing sys.executable at the top of your script. It should 
be /Applications/Python.app/Contents/MacOS/python . If it isn't: let us 
know what it is. If it is then somehow your python.app bundle is 
broken. Try rmoving it and building it again.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From seanh@unforgettable.com  Mon Nov 11 20:39:31 2002
From: seanh@unforgettable.com (Sean Hummel)
Date: Mon, 11 Nov 2002 12:39:31 -0800
Subject: [Pythonmac-SIG] Can't complete Install on Mac OSX 10.2
Message-ID: <AE379E6B-F5B5-11D6-886D-003065428512@unforgettable.com>

Don't know why this is, but when the ConfigureCarbon Applet runs after 
the completion of the file copy, sntea dof doing aything it just comes 
up with a window with the title of "Terminated".  This probably is in 
some FAQ somewhere, but I couldn't find it.

This is a brand new install of 10.2 as well.



From brian_l@mac.com  Tue Nov 12 10:48:01 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Tue, 12 Nov 2002 02:48:01 -0800
Subject: [Pythonmac-SIG] Can't complete Install on Mac OSX 10.2
In-Reply-To: <AE379E6B-F5B5-11D6-886D-003065428512@unforgettable.com>
Message-ID: <3721380A-F62C-11D6-8478-003065F88956@mac.com>

On Monday, November 11, 2002, at 12:39  PM, Sean Hummel wrote:

> Don't know why this is, but when the ConfigureCarbon Applet runs after 
> the completion of the file copy, sntea dof doing aything it just comes 
> up with a window with the title of "Terminated".  This probably is in 
> some FAQ somewhere, but I couldn't find it.
>
> This is a brand new install of 10.2 as well.

Hi Sean,

Which version of Python? This sounds like a bug Jack fixed in 2.2.2.



From owen@astro.washington.edu  Tue Nov 12 16:39:51 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Tue, 12 Nov 2002 08:39:51 -0800
Subject: [Pythonmac-SIG] MachoPython 2.2.2 build works; 3 minor
 questions
In-Reply-To: <1759786E-F4E9-11D6-B589-000A27B19B96@oratrix.com>
References: <1759786E-F4E9-11D6-B589-000A27B19B96@oratrix.com>
Message-ID: <p05200f00b9f6dd6d549b@[128.95.99.44]>

>On vrijdag, nov 8, 2002, at 18:56 Europe/Amsterdam, Russell E Owen wrote:
>>>>2) Is it possible to make a Python/Tkinter source file that can 
>>>>be run as a command (i.e. that has a working #! line...
>>>
>>>#! /Applications/Python.app/Contents/MacOS/python
>>>Not pretty, but it works.
>>
>>Unfortunately, it works exactly like #!/usr/local/lib/python: the 
>>Python code runs (which is a big step forward from 
>>#!/usr/local/bin/pythonw), but one cannot bring Tk windows to the 
>>front!
>
>Strange... The first thing to check is whether this thing behaves as 
>a "real" application. If it is a real application it should have a 
>dock icon and a menubar. My guess is that it won't. (I.e. if you 
>*do* have an icon and a menubar but you cannot bring windows to the 
>front you've found a problem that is new to me).

You are correct: a Tk application works if and only if the Python 
icon shows up in the  toolbar.

>If it doesn't have an icon the problem is that the program isn't 
>properly registered with the window server, and we have to find out 
>why not. Try printing sys.executable at the top of your script. It 
>should be /Applications/Python.app/Contents/MacOS/python . If it 
>isn't: let us know what it is. If it is then somehow your python.app 
>bundle is broken. Try rmoving it and building it again.

I tried that and the answer is indeed wrong:
% ./tkshbang.py
running sitecustomize.py
/usr/local/bin/python

where tkshbang.py is as follows:

#!/Applications/Python.app/Contents/MacOS/python
"""A minimal test of Tk"""
import sys
import Tkinter
print sys.executable
root = Tkinter.Tk()
text  = Tkinter.Button(root, text="Test")
text.pack()
root.mainloop()

Any suggestions on what to try next? I suppose I may have screwed up 
the build somehow, but I thought I was careful to follow the 
instructions in the /Mac/OSX/README.


From stephenm@humongous.com  Wed Nov 13 01:53:57 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Tue, 12 Nov 2002 17:53:57 -0800
Subject: [Pythonmac-SIG] question about event handlers
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE8A7@sea-horse.seattle.infogrames.loc>

I am using the Python as the basis for a cross platform game. For the most
part we are using Python and make calls to C libraries to handle platform
dependent tasks. To this point, I have used the stock Python Core. I have
installed some Carbon event handler code, such as mouse moving, mouse down,
keyboard stuff. The problem is even though I am moving the mouse around, I
am only getting mouse move event if the moue if moving slowly enough, or
come to stop after a long move.  Anyone have any ideas how I can achieve
smooth mouse motion by installer Carbon Event Handlers?




From aparente@adobe.com  Wed Nov 13 01:59:43 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Tue, 12 Nov 2002 17:59:43 -0800
Subject: [Pythonmac-SIG] question about event handlers
In-Reply-To: <151590CD351823429A7EBA135BEEAD5801ADE8A7@sea-horse.seattle.infogrames.loc>
Message-ID: <B9F6F20F.9030%aparente@adobe.com>

Hi Stephen,

I would think polling aggressively, but on a timer basis, for the mouse
location (and then finding the underlying window) is probably the most
appropriate way to achieve a smooth mouse move handling.

Although you're right, it could be a carbon event that does that already.

Alex.

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166


> I am using the Python as the basis for a cross platform game. For the most
> part we are using Python and make calls to C libraries to handle platform
> dependent tasks. To this point, I have used the stock Python Core. I have
> installed some Carbon event handler code, such as mouse moving, mouse down,
> keyboard stuff. The problem is even though I am moving the mouse around, I
> am only getting mouse move event if the moue if moving slowly enough, or
> come to stop after a long move.  Anyone have any ideas how I can achieve
> smooth mouse motion by installer Carbon Event Handlers?
> 
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From Jack.Jansen@cwi.nl  Wed Nov 13 09:40:10 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 13 Nov 2002 10:40:10 +0100
Subject: [Pythonmac-SIG] question about event handlers
In-Reply-To: <B9F6F20F.9030%aparente@adobe.com>
Message-ID: <E718E54A-F6EB-11D6-80A2-0030655234CE@cwi.nl>

On Wednesday, Nov 13, 2002, at 02:59 Europe/Amsterdam, Alexandre 
Parenteau wrote:

> Hi Stephen,
>
> I would think polling aggressively, but on a timer basis, for the mouse
> location (and then finding the underlying window) is probably the most
> appropriate way to achieve a smooth mouse move handling.

Another problem may be that the MacPython event loop is in your way 
(Python uses a classical WaitNextEvent()-style mainloop in the inner 
interpreter, to handle clicks on other windows, command-., etc.). Try 
disabling the Python event handling code by calling 
MacOS.SchedParams(0, 0).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From Michel Sanner <sanner@scripps.edu>  Wed Nov 13 18:11:20 2002
From: Michel Sanner <sanner@scripps.edu> (Michel Sanner)
Date: Wed, 13 Nov 2002 10:11:20 -0800 (PST)
Subject: [Pythonmac-SIG] Tkinter under Mac OSX
Message-ID: <200211131811.KAA11278@goliath.scripps.edu>

Dear Bob,

I saw your message on the Pythonmac SIG mailing list. I have been trying to 
support macOSX for my applications for quite some time now without much success. 
The main problem coming from Tkinter and using Togl. The closest I got so far 
was using a rootless X server. Since then it seems that support for macOSX has 
grown so I decided to give it a try again.

I got Tcl/tk 8.4.1 (since they claim AQUA support). I manage to compile and 
install it as a framework.
I got Python 2.2.2 compiled it and installed it as a Framework.

The first problem I had was that Tkinter had not been built. Since I am not sure 
how to alter setup.py for it to detect that it should build _tkinter.so I 
created Modules/Setup.local for this.

I tried several things (None of which worked) and tried the following code

>>> import Tkinter
>>> r = Tkinter.Tk()

1 - build without using -DTK_AQUA. The window appears but clicking on it or 
doing anything in the window prints an error message: failed to setFrontProcess

2 - build using TK_AQUA. For this to link I had to replace 
Tk_MacOSXOpenBundleResources by Tcl_MacOSXOpenBundleResources, but the code 
fails with a bus error on  Tcl_MacOSXOpenBundleResources.

The other approach I tried was to use a Python 2.2.1 interpreter built using 
fink and tcltk8.3 built using fink. This seemed to work as far as Tk goes but 
failed when I was adding Togl.
I built togl.so that work with tclsh. I am able to "package require Togl" 
successfully. But when I try to do this from within Tkinter it fails telling 
that togl.so is a badly formed mach 0 dynlib.

Any hint/advise would be very much appreciated.

-Michel

-----------------------------------------------------------------------

Michel F. Sanner Ph.D.                   The Scripps Research Institute
Assistant Professor			Department of Molecular Biology
					  10550 North Torrey Pines Road
Tel. (858) 784-2341				     La Jolla, CA 92037
Fax. (858) 784-2860
sanner@scripps.edu                        http://www.scripps.edu/sanner
-----------------------------------------------------------------------





From owen@astro.washington.edu  Wed Nov 13 18:34:52 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Wed, 13 Nov 2002 10:34:52 -0800
Subject: [Pythonmac-SIG] Bringing Tkinter windows to the front: some new info
Message-ID: <p05200f01b9f84b2175ef@[128.95.99.44]>

I received the following from a Tcl/Tk discussion list about problems 
bringing Tk windows to the front. I've edited it a bit:

>>this is a know problem that we hope to solve eventually, but according
>>to Jim Ingham it needs an SPI that's not publicly available yet.
>
>...we use 'wish' as a back-end for creating GUI applications from 
>Erlang and had the same error message. For us the patch
>
>   http://www.erlang.org/ml-archive/erlang-questions/200210/msg00148.html
>
>seem to solve the problem,
>
>kent


...CPSEnableForegroundOperation is really an SPI, not an API, and the 
CPS guys asked me not to use it in Tcl/Tk.  They may make it public 
or not, hard to say.  That is why I didn't add this to Tk...

The more likely solution to this problem, at least for us, stems from 
the fact that it is really a bug that when the CPS goes to figure out 
whether a binary it has been handed is a GUI App or not, it doesn't 
notice that the app it has been given is actually a link, and resolve 
the link before looking around to see if it is in an App package.  If 
they did this, then the link would point back to the real wish which 
actually IS in an app package, it would get registered as a GUI app, 
and everything would be fine...

The CPS folks agree this is a bug, and they are going to fix it. 
Dunno when it will get into a release, however...

Jim


From Jack.Jansen@oratrix.com  Wed Nov 13 21:36:26 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 13 Nov 2002 22:36:26 +0100
Subject: [Pythonmac-SIG] Tkinter under Mac OSX
In-Reply-To: <200211131811.KAA11278@goliath.scripps.edu>
Message-ID: <F6C2BF33-F74F-11D6-A059-000A27B19B96@oratrix.com>

On woensdag, nov 13, 2002, at 19:11 Europe/Amsterdam, Michel Sanner 
wrote:
> 1 - build without using -DTK_AQUA. The window appears but clicking on 
> it or
> doing anything in the window prints an error message: failed to 
> setFrontProcess

This message usually means that you're trying to execute your Tkinter 
script with python in stead of pythonw. All windowing applications 
*must* be run from a .app bundle otherwise they will not work. Pythonw 
is a workaround that enables you to runwindowing scripts from the 
commandline.

> 2 - build using TK_AQUA. For this to link I had to replace
> Tk_MacOSXOpenBundleResources by Tcl_MacOSXOpenBundleResources, but the 
> code
> fails with a bus error on  Tcl_MacOSXOpenBundleResources.

This sounds like it could also be related to not running from a .app 
bundle, but I'm not sure.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Wed Nov 13 21:57:33 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 13 Nov 2002 22:57:33 +0100
Subject: [Pythonmac-SIG] Re: [MACTCL] Re: Building tcl/tk 8.4 aqua
In-Reply-To: <12762CE5-F735-11D6-B39B-00039379E320@apple.com>
Message-ID: <E9C3C648-F752-11D6-A059-000A27B19B96@oratrix.com>

As Russell reposted this bit on the PythonMac-SIG I'm cc'ing that list 
too.

On woensdag, nov 13, 2002, at 19:23 Europe/Amsterdam, Jim Ingham wrote:
> The more likely solution to this problem, at least for us, stems from 
> the fact that it is really a bug that when the CPS goes to figure out 
> whether a binary it has been handed is a GUI App or not, it doesn't 
> notice that the app it has been given is actually a link, and resolve 
> the link before looking around to see if it is in an App package.  If 
> they did this, then the link would point back to the real wish which 
> actually IS in an app package, it would get registered as a GUI app, 
> and everything would be fine...

This would be very bad news for the Python crowd, as we plan on using a 
symlink for exact the opposite purpose. We have a Python.app bundle 
where the executable is merely a symlink to /usr/bin/python. Users use 
a shell script pythonw (in stead of python) to run scripts that need 
the window manager, and the pythonw script is basically
#!/bin/sh
exec /...../Python.app/Contents/MacOS/python $@

This gives python an argv[0] that points into a .app bundle and 
everything is hunky-dory.

I've stayed away from CPSEnableForegroundOperation also because it 
isn't documented, and I don't want Python to stop working because Apple 
takes away an undocumented interface at some release, but the 
functionality would be very welcome. The PyObjC crowd are also running 
into this.

How many scripting languages would you need behind you to make a 
successful appeal to the systems folks to open up this interface? I 
haven't checked, but I would assume that the Perl or Ruby people could 
be having the same problem. After all we all have a single interpreter 
that is sometimes used from command-line scripting, sometimes for GUI 
programming.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From aparente@adobe.com  Wed Nov 13 23:45:13 2002
From: aparente@adobe.com (Alexandre Parenteau)
Date: Wed, 13 Nov 2002 15:45:13 -0800
Subject: [Pythonmac-SIG] Re: [MACTCL] Re: Building tcl/tk 8.4 aqua
In-Reply-To: <E9C3C648-F752-11D6-A059-000A27B19B96@oratrix.com>
Message-ID: <B9F82409.90AB%aparente@adobe.com>

Hi,

> be having the same problem. After all we all have a single interpreter
> that is sometimes used from command-line scripting, sometimes for GUI
> programming.

Oh yeah... That's why I've been struggling with wxMacPython for some time,
because of some events disappearing. And you seem to say the command line
start-up messes up it all.

It looks like a bug, may be Apple is ignoring the problem because they don't
deliver a script that kicks an interface (but don't they distribute tcl/tk,
huh ?).

They need absolutely to know this is central feature for scripting and
terminals. All script on Win and Unix have this ability to potentially kick
in an interface. I fail to even understand the need to use yet another
function API to allow that to happen.

Alex.

> As Russell reposted this bit on the PythonMac-SIG I'm cc'ing that list
> too.
> 
> On woensdag, nov 13, 2002, at 19:23 Europe/Amsterdam, Jim Ingham wrote:
>> The more likely solution to this problem, at least for us, stems from
>> the fact that it is really a bug that when the CPS goes to figure out
>> whether a binary it has been handed is a GUI App or not, it doesn't
>> notice that the app it has been given is actually a link, and resolve
>> the link before looking around to see if it is in an App package.  If
>> they did this, then the link would point back to the real wish which
>> actually IS in an app package, it would get registered as a GUI app,
>> and everything would be fine...
> 
> This would be very bad news for the Python crowd, as we plan on using a
> symlink for exact the opposite purpose. We have a Python.app bundle
> where the executable is merely a symlink to /usr/bin/python. Users use
> a shell script pythonw (in stead of python) to run scripts that need
> the window manager, and the pythonw script is basically
> #!/bin/sh
> exec /...../Python.app/Contents/MacOS/python $@
> 
> This gives python an argv[0] that points into a .app bundle and
> everything is hunky-dory.
> 
> I've stayed away from CPSEnableForegroundOperation also because it
> isn't documented, and I don't want Python to stop working because Apple
> takes away an undocumented interface at some release, but the
> functionality would be very welcome. The PyObjC crowd are also running
> into this.
> 
> How many scripting languages would you need behind you to make a
> successful appeal to the systems folks to open up this interface? I
> haven't checked, but I would assume that the Perl or Ruby people could
> be having the same problem. After all we all have a single interpreter
> that is sometimes used from command-line scripting, sometimes for GUI
> programming.
> --
> - Jack Jansen        <Jack.Jansen@oratrix.com>
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma
> Goldman -
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166



From stephenm@humongous.com  Thu Nov 14 03:09:13 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Wed, 13 Nov 2002 19:09:13 -0800
Subject: [Pythonmac-SIG] problem with PyMac_PreferenceOptions?
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE8B3@sea-horse.seattle.infogrames.loc>

I am needing to set up a application that uses the Python Core but has no
reliance on
Python preferences. The existing code is mostly set up to handle this. I
have run into
one problem, though.


The problem  is with PyMac_PreferenceOptions. Early on in the function in
gets the "Popt"
with a resource ID of  PYTHONOPTIONSOVERRIDE_ID using Get1Resource. The
UseRefFile sets the
rez file to the global value PyMac_AppRefNum in that function. 

Problem is PyMac_PreferenceOptions get called two different times, both
times from
init_common. init_common is called both from PyMac_InitApplication and
PyMac_Initialize.
PyMac_Initialize  is also called by  PyMac_InitApplication. Here is the call
stack:

PyMac_InitApplication
 init_common
  PyMac_PreferenceOptions
 PyMac_Initialize
 	init_common
 	 PyMac_PreferenceOptions
 	 
 	 
The first time through init_common, but after the call to
PyMac_PreferenceOptions, if
USE_MAC_SHARED_LIBRARY is defined, there is a call to PyMac_AddLibResources.
It does a
FSpOpenResFile to add the library's resources and does not restore current
resource file,
(and probably should not). 


At the top of init_common, there is the code PyMac_AppRefNum = CurResFile().
So the 
first time through init_common, PyMac_PreferenceOptions gets the "Popt"
resource
from the application. The second time through, CurResFile() now points to
the resource
of the library file. So in  PyMac_PreferenceOptions, the Get1Resource
fails when trying to get PYTHONOPTIONSOVERRIDE_ID. Since it fails, The
Python preferences
gets read. I do not want that.


To fix the problem, I have initialized PyMac_AppRefNum to -1. The first time
through
init_common, I have changed the code as follows:


--begin old code-----
	PyMac_AppRefNum = CurResFile();
-- end old code -----


--begin new code-----
	if (-1 == PyMac_AppRefNum)
	{
		PyMac_AppRefNum = CurResFile();
	}
-- end new code -----


Does this seem clean?



From stephenm@humongous.com  Thu Nov 14 17:29:34 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Thu, 14 Nov 2002 09:29:34 -0800
Subject: [Pythonmac-SIG] Python based App free of Python Preferences
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE8B5@sea-horse.seattle.infogrames.loc>

Recently, I have been trying to put together an app, really a game, that
uses the Python Core,
but has no reliance on the Python Prefs. The reason being two fold, we may
have more that one
game and want to include different libraries. The second being, I do not
want to screw up 
someone's hard created prefs just by running one of our games. This means
that we have a lib 
folder per game, and our 'STR#' 229 to point to them, but since we know what
lib folder we 
ship with, we can better guarantee long term stability.

Thankfully, the Python Core is mostly set up to handle this. I ran into two
problems in the 
process. First, there was the problem I discovered with
PyMac_PreferenceOptions (see 
yesterday's post). The second problem was I could not get relative path
aliases working
correctly. I followed the guildlines from
http://developer.apple.com/technotes/tn/tn1188.html
using the Finder to create a relative alias. I then copied the 'alis'
resource and pasted it
into my app, 'alis',id # 229. The Python Core even found the resource. I
must of built my 
relative alias incorrectly, because ResolveAlias didn't resolve to the
expected location. 
Because of that, I made a minor change to the source code.

I do not have CVS access, though I have tried. The problem is mostly on our
server side, I
think. I have had other problems with are firewall. So if I may I would like
to give you 
the source code changes I needed to make to be added to the release stream.


-- add near the top of macgetpath.c ---------

 /* Use this if you want to use the current directory your app is running
from
** as your $(PYTHON) folder. You will have to make sure that you use the
STR# 229
** resource to properly point to the files that are need in the Python boot
process.
*/
#define USE_APP_DIR_AS_PYTHON_DIR 1

----------


-- Replace PyMac_GetPythonDir with this -------
char *
PyMac_GetPythonDir()
{
#if USE_APP_DIR_AS_PYTHON_DIR
	static int diditbefore = 0;
	static char name[PATHNAMELEN] = {':', '\0'};

	if ( diditbefore )
		return name;

	name[0] = 0;
	/* just use the current apps directory as the Python Directory */
	(void)getcwd(name, sizeof(name));

	diditbefore = 1;
	return name;
#else
	static int diditbefore = 0;
	static char name[PATHNAMELEN] = {':', '\0'};

	AliasHandle handle;
	FSSpec dirspec;
	Boolean modified = 0;
	short oldrh, prefrh = -1, homerh;
	
	if ( diditbefore )
		return name;
		
	oldrh = CurResFile();

	/* First look for an override in the application file */
	UseResFile(PyMac_AppRefNum);
	handle = (AliasHandle)Get1Resource('alis', PYTHONHOMEOVERRIDE_ID);
	UseResFile(oldrh);
	if ( handle != NULL ) {
		homerh = PyMac_AppRefNum;
	} else {   
		/* Try to open preferences file in the preferences folder.
*/
		prefrh = PyMac_OpenPrefFile();
		handle = (AliasHandle)Get1Resource('alis', PYTHONHOME_ID);
		if ( handle == NULL ) {
			/* (void)StopAlert(BADPREFFILE_ID, NULL); */
			diditbefore=1;
			return ":";
		}
		homerh = prefrh;
	}
	/* It exists. Resolve it (possibly updating it) */
	if ( ResolveAlias(NULL, handle, &dirspec, &modified) != noErr ) {
		(void)StopAlert(BADPREFFILE_ID, NULL);
		diditbefore=1;
		return ":";
	}
	if ( modified ) {
   		ChangedResource((Handle)handle);
		UpdateResFile(homerh);
	}
	if ( prefrh != -1 ) CloseResFile(prefrh);
	UseResFile(oldrh);
   	if ( PyMac_GetFullPathname(&dirspec, name, PATHNAMELEN) == 0 ) {
   		strcat(name, ":");
	} else {
 		/* If all fails, we return the current directory */
   		printf("Python home dir exists but I cannot find the
pathname!!\n");
		name[0] = 0;
		(void)getcwd(name, sizeof(name));
	}
	diditbefore = 1;
	return name;
#endif
}
-----------

I didn't change the existing code, at least not meaningfully. I just added
my #if block of code.

Could some review this and summit it properly? I would be much appreciated.

Thanks,

Stephen Magladry

  
 


From stephenm@humongous.com  Thu Nov 14 19:40:43 2002
From: stephenm@humongous.com (Magladry, Stephen)
Date: Thu, 14 Nov 2002 11:40:43 -0800
Subject: [Pythonmac-SIG] Python based App free of Python Preferences
Message-ID: <151590CD351823429A7EBA135BEEAD5801ADE8B8@sea-horse.seattle.infogrames.loc>

Bill,

Thanks for the reply. I saw that, too. File sharing was off while =
making the
alias.=20

Stephen
-----Original Message-----

"When creating aliases using either the Finder's "Make=A0Alias" =
command,=20
or the method shown in Figure=A01, be sure that File Sharing is turned=20
off. If file sharing is turned on, then full path information such as=20
the server name, etc., is stored in the alias making it unsuitable for=20
use in packages. Be sure file sharing is turned off before creating any =

aliases used in packages."

-----Original Message-----


From kmarek@sbcglobal.net  Thu Nov 14 23:36:57 2002
From: kmarek@sbcglobal.net (Kurt Marek)
Date: Thu, 14 Nov 2002 15:36:57 -0800
Subject: [Pythonmac-SIG] Getting started with Python on a Mac.
Message-ID: <F73D40DC-F829-11D6-96EB-000393B59764@sbcglobal.net>

I took a class on Python and OOP in grad school a year ago. The class 
was geared toward UNIX and Windows and I did all of my coding in IDLE 
on X. I'm running Jaguar now and am quite confused about some of the 
Mac-specific and OSX-specific issues of running Python. I'll try to 
distill my confusion down into a few basic questions.

1) I would like to use an IDLE setup. What's the best way to accomplish 
this on OSX?
2) Since I am just learning Python, I would like my learning 
'experience' (and my code) to be as compatible as possible with other 
platforms so that I will be comfortable switching to another platform. 
Specifically, what are the issues surrounding Tcl/TK, IDLE on OSX, etc. 
Reading these threads makes things seem pretty confusing to a beginner.
3) Is there a book or a web site geared toward beginning Python 
programming on OSX so I don't have to bug you guys? :) The docs don't 
seem to have been updated for OSX and a google search hasn't returned 
anything terribly useful.

I posted a somewhat similar thread a couple months ago about the future 
of Python on OSX, but most of the answers were a bit over my head and I 
got quite discouraged trying to figure out the best way to get started. 
I've decided that the best way to learn is to just get some of these 
beginner questions answered, find a good beginner's list or resource, 
and start to work. Any help would be appreciated.

thanks,
Kurt



From tony@lownds.com  Fri Nov 15 01:28:40 2002
From: tony@lownds.com (Tony Lownds)
Date: Thu, 14 Nov 2002 17:28:40 -0800
Subject: [Pythonmac-SIG] Getting started with Python on a Mac.
In-Reply-To: <F73D40DC-F829-11D6-96EB-000393B59764@sbcglobal.net>
References: <F73D40DC-F829-11D6-96EB-000393B59764@sbcglobal.net>
Message-ID: <a0511170fb9f9f7f23806@[10.0.1.8]>

At 3:36 PM -0800 11/14/02, Kurt Marek wrote:
>I took a class on Python and OOP in grad school a year ago. The 
>class was geared toward UNIX and Windows and I did all of my coding 
>in IDLE on X. I'm running Jaguar now and am quite confused about 
>some of the Mac-specific and OSX-specific issues of running Python. 
>I'll try to distill my confusion down into a few basic questions.

Your questions are really well-worded. I doubt I will clear anything 
up however - the fact is that some things are in flux regarding IDLE 
and Python on OSX. If you want to use python on OSX today, just fire 
up Terminal.app and type "python". You won't be able to make GUI 
applications but you will be able to make useful programs, including 
CGI scripts. Switching from IDLE to another text editor (the TextEdit 
program works fine) will be less confusing than trying to get IDLE to 
work, today.

>1) I would like to use an IDLE setup. What's the best way to 
>accomplish this on OSX?

Wait for Python 2.3. The next best alternative is to download Python 
2.3 from CVS, and idlefork from CVS. Python 2.3 builds Tkinter 
smoothly, and will include idlefork, which has Mac OS X specific 
fixes.

>2) Since I am just learning Python, I would like my learning 
>'experience' (and my code) to be as compatible as possible with 
>other platforms so that I will be comfortable switching to another 
>platform. Specifically, what are the issues surrounding Tcl/TK, IDLE 
>on OSX, etc. Reading these threads makes things seem pretty 
>confusing to a beginner.

The main platform quirks I have run into are:

1. When running GUI apps run using "pythonw" not "python". Error 
messages like "SetFrontProcess failed, -600" and windows that do not 
respond are symptoms of this.

2. Python and threads work fine; but Python and threads and Tcl/Tk does not.

>3) Is there a book

No

>or a web site geared toward beginning Python programming on OSX

Nothing specific to *beginning* programming on OSX, but Russel Owen's 
web site is well written:

   http://www.astro.washington.edu/owen/

Thanks,
-Tony


From mwh@python.net  Fri Nov 15 10:20:59 2002
From: mwh@python.net (Michael Hudson)
Date: 15 Nov 2002 10:20:59 +0000
Subject: [Pythonmac-SIG] Getting started with Python on a Mac.
In-Reply-To: Kurt Marek's message of "Thu, 14 Nov 2002 15:36:57 -0800"
References: <F73D40DC-F829-11D6-96EB-000393B59764@sbcglobal.net>
Message-ID: <2mk7jfgmlw.fsf@starship.python.net>

Kurt Marek <kmarek@sbcglobal.net> writes:

> 3) Is there a book or a web site geared toward beginning Python 
> programming on OSX so I don't have to bug you guys? :)

At the moment, that would be a bit like trying to nail jelly to the
wall.  It would be a very cool topic for a book once things have
settled down a bit, though.

Cheers,
M.

-- 
  ... when all the programmes on all the channels actually were made
  by actors with cleft pallettes speaking lines by dyslexic writers
  filmed by blind cameramen instead of merely seeming like that, it
  somehow made the whole thing more worthwhile.   -- HHGTG, Episode 11


From dietergyselinck@pandora.be  Mon Nov 18 12:14:30 2002
From: dietergyselinck@pandora.be (Dieter Gyselinck)
Date: Mon, 18 Nov 2002 13:14:30 +0100
Subject: [Pythonmac-SIG] Install MySQLdb module on mac os x
Message-ID: <4A1F994F-FAEF-11D6-B0BC-0003938B87E2@pandora.be>

Hi,

     I'm trying to install the python MySQLdb module on os x 10.2 but 
when I try to run 'setup.py build' I get this error message :
ld: can't locate file for: -lmysqlclient
error: command 'gcc' failed with exit status 1

I have installed binary mysql-3.23.52 package and it seems to be 
working fine, I can access my db via php.  I am trying to run the 
MySQL-python-0.9.2 setup.  I have changed 'thread_safe_library' to 'NO' 
but that does not solve the problem.  Anyone can help me out with this 
problem???

This is the output when I run setup.py build :
running build
running build_py
not copying CompatMysqldb.py (output up-to-date)
not copying _mysql_exceptions.py (output up-to-date)
not copying MySQLdb/__init__.py (output up-to-date)
not copying MySQLdb/converters.py (output up-to-date)
not copying MySQLdb/connections.py (output up-to-date)
not copying MySQLdb/cursors.py (output up-to-date)
not copying MySQLdb/sets.py (output up-to-date)
not copying MySQLdb/times.py (output up-to-date)
not copying MySQLdb/constants/__init__.py (output up-to-date)
not copying MySQLdb/constants/CR.py (output up-to-date)
not copying MySQLdb/constants/FIELD_TYPE.py (output up-to-date)
not copying MySQLdb/constants/ER.py (output up-to-date)
not copying MySQLdb/constants/FLAG.py (output up-to-date)
not copying MySQLdb/constants/REFRESH.py (output up-to-date)
not copying MySQLdb/constants/CLIENT.py (output up-to-date)
running build_ext
building '_mysql' extension
skipping _mysql.c (build/temp.darwin-6.0-Power Macintosh-2.2/_mysql.o 
up-to-date)
gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress 
build/temp.darwin-6.0-Power Macintosh-2.2/_mysql.o -L/usr/lib/mysql 
-L/usr/local/lib/mysql -L/usr/local/mysql/lib/mysql -L/sw/lib 
-lmysqlclient -lz -o build/lib.darwin-6.0-Power Macintosh-2.2/_mysql.so 
-flat_namespace
ld: for architecture i386
ld: warning -L: directory name (/usr/lib/mysql) does not exist
ld: warning -L: directory name (/sw/lib) does not exist
ld: warning /usr/lib/bundle1.o cputype (18, architecture ppc) does not 
match cputype (7) for specified -arch flag: i386 (file not loaded)
ld: warning build/temp.darwin-6.0-Power Macintosh-2.2/_mysql.o cputype 
(18, architecture ppc) does not match cputype (7) for specified -arch 
flag: i386 (file not loaded)
ld: can't locate file for: -lmysqlclient
error: command 'gcc' failed with exit status 1

Thanx,
Dieter



From Jack.Jansen@oratrix.com  Mon Nov 18 13:52:08 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Mon, 18 Nov 2002 14:52:08 +0100
Subject: [Pythonmac-SIG] Install MySQLdb module on mac os x
In-Reply-To: <4A1F994F-FAEF-11D6-B0BC-0003938B87E2@pandora.be>
Message-ID: <EDE293B1-FAFC-11D6-9B18-000A27B19B96@oratrix.com>

On maandag, nov 18, 2002, at 13:14 Europe/Amsterdam, Dieter Gyselinck 
wrote:

> Hi,
>
>     I'm trying to install the python MySQLdb module on os x 10.2 but 
> when I try to run 'setup.py build' I get this error message :
> ld: can't locate file for: -lmysqlclient
> gcc -arch i386 -arch ppc -bundle -flat_namespace -undefined suppress 
> build/temp.darwin-6.0-Power Macintosh-2.2/_mysql.o -L/usr/lib/mysql 
> -L/usr/local/lib/mysql -L/usr/local/mysql/lib/mysql -L/sw/lib 
> -lmysqlclient -lz -o build/lib.darwin-6.0-Power 
> Macintosh-2.2/_mysql.so -flat_namespace
> ld: for architecture i386

This probably isn't the problem, but you should fix it anyway: Apple 
distributes a /usr/lib/python2.2/config/Makefile that isn't 100% 
correct. Edit it (with sudo) and remove the "-arch i386".

> ld: warning -L: directory name (/usr/lib/mysql) does not exist
> ld: warning -L: directory name (/sw/lib) does not exist

This is the problem, I think: the build procedure doesn't know where 
your mysql library is located. You can probably edit the setup.py file 
to tell it where it is.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Mon Nov 18 17:14:01 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Mon, 18 Nov 2002 09:14:01 -0800
Subject: [Pythonmac-SIG] Re: Install MySQLdb module on mac os x (Dieter Gyselinck)
In-Reply-To: <20021118170004.14061.311.Mailman@mail.python.org>
References: <20021118170004.14061.311.Mailman@mail.python.org>
Message-ID: <p05200f02b9fece203eb0@[128.95.99.44]>

>From: Dieter Gyselinck <dietergyselinck@pandora.be>
>...
>     I'm trying to install the python MySQLdb module on os x 10.2 but 
>when I try to run 'setup.py build' I get this error message :
>ld: can't locate file for: -lmysqlclient
>error: command 'gcc' failed with exit status 1
>
>I have installed binary mysql-3.23.52 package and it seems to be 
>working fine, I can access my db via php.  I am trying to run the 
>MySQL-python-0.9.2 setup.  I have changed 'thread_safe_library' to 
>'NO' but that does not solve the problem.  Anyone can help me out 
>with this problem???

Here's how I mySQL running with Python:

1) I used Marc Liyanage's mySQL binary and installer. This put 
everything in  /usr/local/mysql (actually that's a link to a similar 
item with the version # appended).

2) I got MySQL-python-0.9.2 and found I had to modify setup.py to get 
it to work. It had the problem with thread_safe_library that you 
already noted and also was missing the appropriate directories from 
setup.py. Here are mininal fixes:

# set this to YES if you have the thread-safe mysqlclient library
thread_safe_library = NO

...

# include files and library locations should cover most platforms
include_dirs = [
     '/usr/include/mysql',
     '/usr/local/include/mysql',
     '/usr/local/mysql/include',  # added by RO for MacOS X
     '/usr/local/mysql/include/mysql' # is this real? it looks suspicious
     ]
library_dirs = [
     '/usr/lib/mysql',
     '/usr/local/lib/mysql',
     '/usr/local/mysql/lib',  # added by RO for MacOS X
     '/usr/local/mysql/lib/mysql' # is this real? it looks suspicious
     ]

My full setup.py also filters the two directory lists above to remove 
any that don't exist -- that is entirely optional but saves a lot of 
warning messages. I sent email to the developer of MySQL-python-0.9.2 
that included my full setup.py; we'll see if it gets incorporated. If 
you want a copy, let me know and I'll email it to you; I didn't want 
to clutter up the mailing list.

-- Russell


From lars-pythonmac@pixar.com  Mon Nov 18 18:29:48 2002
From: lars-pythonmac@pixar.com (Lars Damerow)
Date: Mon, 18 Nov 2002 10:29:48 -0800
Subject: [Pythonmac-SIG] Python and resource forks under Mac OS X
Message-ID: <20021118182948.GA32546@pixar.com>

Hello Python-mac folks!

I sent this question to comp.lang.python and got no response, so I'll target a
narrower audience. :)

Do the resource fork manipulation tools in the standard library work under
OS X?

I'm hoping to use them to copy the resource fork out of one file and into
a regular file, and also to copy that file into the resource fork of
another file. I looked at macostools.py, specifically at the copy()
function, and wrote these functions to do the job:

import MacOS
from macostools import BUFSIZ

def joinResources(args):
    source, target = args
    infile = open(source, "rb")
    rf = infile.read(BUFSIZ)
    if rf != '':
        outfile = MacOS.openrf(target, "wb")
        while rf:
            outfile.write(rf)
            rf = infile.read(BUFSIZ)
        outfile.close()
    infile.close()

def splitResources(args):
    source, target = args
    infile = MacOS.openrf(source, "*rb")
    rf = infile.read(BUFSIZ)
    if rf != '':
        outfile = open(target, "wb")
        while rf:
            outfile.write(rf)
            rf = infile.read(BUFSIZ)
        outfile.close()
    infile.close()

I tried using them to copy the icon from one file to another, but the
Finder doesn't seem to notice the new resource fork; the target file's
icon doesn't change. When I open the target file in a program like
Resourcer, though, it looks like the resource fork was copied correctly.
Baffling!

I also tried using the macostools.copy() to copy a file that had an icon,
and the resulting file was icon-less. :)

Am I doing something wrong? Any tips would be greatly appreciated!

Thanks,
lars

___________________________________________________________
lars damerow
button pusher
lars-pythonmac@pixar.com

"During the brief interview I was asked why I wanted to work for UPS and I
answered that I wanted to work for UPS because I like the brown uniforms.
What did they expect me to say?"            -David Sedaris


From kevino@tulane.edu  Mon Nov 18 23:58:12 2002
From: kevino@tulane.edu (Kevin Ollivier)
Date: Mon, 18 Nov 2002 15:58:12 -0800
Subject: [Pythonmac-SIG] Error trying to run extension
Message-ID: <98D07C02-FB51-11D6-9CD7-00039384E8D4@tulane.edu>

I've been working on building wxPython for MacPython 2.2.2 using 
distutils, and I have got the software building without errors. The 
libraries are created, and all the necessary files are put into 
Applications/MacPython 2.2.2/Lib/site-packages/wxPython. However, when 
I try to run a wxPython script, I get the following message:

"Fatal Error: Mismatch between the program and library build versions 
detected."

To build the extension, I downloaded the compiled MacPython 2.2.2 and 
installed it, then downloaded the GUSI2 and MacPython source, and 
copied the downloaded files into the Applications/MacPython 2.2.2/ 
directory relative to where the PythonInterpreter was looking for them. 
(Include, Mac/Include, GUSI2) What am I doing wrong here?

Many thanks for any help you can give! I did a Google on this error 
message and came up with nothing so I'm wondering if I've done 
something quite unique. ^_^;

Kevin



From Jack.Jansen@cwi.nl  Tue Nov 19 10:13:48 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 19 Nov 2002 11:13:48 +0100
Subject: [Pythonmac-SIG] Error trying to run extension
In-Reply-To: <98D07C02-FB51-11D6-9CD7-00039384E8D4@tulane.edu>
Message-ID: <97E83662-FBA7-11D6-AA99-0030655234CE@cwi.nl>

On Tuesday, Nov 19, 2002, at 00:58 Europe/Amsterdam, Kevin Ollivier 
wrote:

> I've been working on building wxPython for MacPython 2.2.2 using 
> distutils, and I have got the software building without errors. The 
> libraries are created, and all the necessary files are put into 
> Applications/MacPython 2.2.2/Lib/site-packages/wxPython. However, when 
> I try to run a wxPython script, I get the following message:
>
> "Fatal Error: Mismatch between the program and library build versions 
> detected."

First thing to do is to find out who produces this error message. It 
doesn't occur in the MacPython sources, so my guess would be that it's 
either wxWindows (which would suggest that it has a version number in 
it's .h files or so, and that this version number is compared to the 
runtime version number in the library) or wxPython. Next I would 
suggest printing the two version numbers, if possible, that might give 
some insight.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From mwh@python.net  Tue Nov 19 10:16:13 2002
From: mwh@python.net (Michael Hudson)
Date: 19 Nov 2002 10:16:13 +0000
Subject: [Pythonmac-SIG] Python and resource forks under Mac OS X
In-Reply-To: Lars Damerow's message of "Mon, 18 Nov 2002 10:29:48 -0800"
References: <20021118182948.GA32546@pixar.com>
Message-ID: <2mbs4ln9ua.fsf@starship.python.net>

Lars Damerow <lars-pythonmac@pixar.com> writes:

> I sent this question to comp.lang.python and got no response, so I'll target a
> narrower audience. :)
> 
> Do the resource fork manipulation tools in the standard library work under
> OS X?

I haven't tried anything like what you're doing, but I have done some
simple resource forky stuff with OS X & macho-python, so you should
have some hope of getting it to work...

Cheers,
M.

-- 
  We've had a lot of problems going from glibc 2.0 to glibc 2.1.
  People claim binary compatibility.  Except for functions they
  don't like.                       -- Peter Van Eynde, comp.lang.lisp


From Jack.Jansen@cwi.nl  Tue Nov 19 10:46:16 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 19 Nov 2002 11:46:16 +0100
Subject: [Pythonmac-SIG] Python and resource forks under Mac OS X
In-Reply-To: <20021118182948.GA32546@pixar.com>
Message-ID: <21380E34-FBAC-11D6-AA99-0030655234CE@cwi.nl>

On Monday, Nov 18, 2002, at 19:29 Europe/Amsterdam, Lars Damerow wrote:
> I sent this question to comp.lang.python and got no response, so I'll 
> target a
> narrower audience. :)
>
> Do the resource fork manipulation tools in the standard library work 
> under
> OS X?

Under MacPython 2.2.X everything should work fine, but you have to 
remember to use
mac style :-separated pathnames.

Under unix-Python 2.2.X things are messy. Some routines expect 
mac-style pathnames,
some expect unix-style pathnames. I'm still hunting these down, so if 
you find
instances where a mac-style pathname is required please file a 
sourceforge bug report.

--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Tue Nov 19 22:20:41 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Tue, 19 Nov 2002 14:20:41 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
Message-ID: <p05200f07ba0068313485@[128.95.99.44]>

Anybody know how to build Python for MacOS X with socket.ssl support? 
Ideally I'd like to compile the framework build of Python 2.2.2 under 
MacOS X 10.2. The default way of doing it (as documented in 
/Mac/OSX/README) works but doesn't seem to include ssl support. If 
that's not reasonable, then I am willing to go with the normal unix 
build instead.

Also, anybody tried to use this combo (with or without ssl) with 
PostgreSQL? I tried building PostgreSQL from source and the make 
fails if I try to build it with python support. I have thought of a 
few things to try (such as seeing if I could find a separate 
PostgreSQL Python interface and attaching it to a non-Python 
PostgreSQL) but I figured I'd see if anybody had any wisdom on the 
subject before flailing around too much.

-- Russell


From caw@cs.mu.oz.au  Wed Nov 20 01:34:20 2002
From: caw@cs.mu.oz.au (Chris Wright)
Date: Wed, 20 Nov 2002 12:34:20 +1100
Subject: [Pythonmac-SIG] python and pythonw in python-mode emacs
Message-ID: <31256DFB-FC28-11D6-A26D-00039388D92A@cs.mu.oz.au>

Running a python interpreter (2.2.2) as a subprocess of emacs 
(21.3.50.4) under jaguar 10.2.2 built accoring to Owen's instructions 
(TkAqua  etc):

all is well, except we get SetFrontProcess failed, -606 error when 
trying to run a Tkinter program from within emacs (either with C-c C-c 
or from a C-C ! python shell)

so....

changing py-python-command in python-mode.el from
python to pythonw (to try and get rid of the SetFrontProcess failed, 
-606 error) causes the following to be displayed:

original argc=2
original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
original argv[1] = "-i"
modified argc=2
modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
modified argv[1] = "-i"
-i: can't open file '-i'



Process Python exited abnormally with code 2

(Fortunately, I hadn't followed Jack's advice and cleaned up the top of 
macmain.c yet ;)

All works just fine from a terminal


any advice would be appreciated

thank

Chris



Dr Chris Wright
Medical Director, ICU
Monash Medical Centre
Clayton VIC 3168



From Jack.Jansen@cwi.nl  Wed Nov 20 12:02:20 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 20 Nov 2002 13:02:20 +0100
Subject: [Pythonmac-SIG] python and pythonw in python-mode emacs
In-Reply-To: <31256DFB-FC28-11D6-A26D-00039388D92A@cs.mu.oz.au>
Message-ID: <EBD885D2-FC7F-11D6-BBB5-0030655234CE@cwi.nl>

On Wednesday, Nov 20, 2002, at 02:34 Europe/Amsterdam, Chris Wright 
wrote:

> Running a python interpreter (2.2.2) as a subprocess of emacs 
> (21.3.50.4) under jaguar 10.2.2 built accoring to Owen's instructions 
> (TkAqua  etc):
>
> all is well, except we get SetFrontProcess failed, -606 error when 
> trying to run a Tkinter program from within emacs (either with C-c C-c 
> or from a C-C ! python shell)
>
> so....
>
> changing py-python-command in python-mode.el from
> python to pythonw (to try and get rid of the SetFrontProcess failed, 
> -606 error) causes the following to be displayed:
>
[...]
> -i: can't open file '-i'

Try not only setting py-python-command to pythonw but also clearing 
py-python-command-args. The 2.2.2 pythonw interpreter doesn't 
understand the -i argument (nor any other argument, for that matter).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@cwi.nl  Wed Nov 20 12:17:10 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 20 Nov 2002 13:17:10 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <p05200f07ba0068313485@[128.95.99.44]>
Message-ID: <FE4930A4-FC81-11D6-BBB5-0030655234CE@cwi.nl>

On Tuesday, Nov 19, 2002, at 23:20 Europe/Amsterdam, Russell E Owen 
wrote:

> Anybody know how to build Python for MacOS X with socket.ssl support? 
> Ideally I'd like to compile the framework build of Python 2.2.2 under 
> MacOS X 10.2. The default way of doing it (as documented in 
> /Mac/OSX/README) works but doesn't seem to include ssl support. If 
> that's not reasonable, then I am willing to go with the normal unix 
> build instead.

Ssl support is automatic is ssl is located in either /usr/local/ssl or 
/usr/contrib/ssl. If it is elsewhere: edit setup.py in the main python 
source folder, and look at the lines where ssl_incs and ssl_libs are 
set and add the place where you've installed ssl.

This should enable ssl support for both framework and static builds.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Wed Nov 20 16:34:18 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Wed, 20 Nov 2002 08:34:18 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <FE4930A4-FC81-11D6-BBB5-0030655234CE@cwi.nl>
References: <FE4930A4-FC81-11D6-BBB5-0030655234CE@cwi.nl>
Message-ID: <p05200f05ba016817ec4c@[128.95.99.44]>

I hunted around and found /usr/lib/libssl.dylib
(as well as /usr/libexec/httpd/libssl.so)

This is on a pretty vanilla MacOS X system, so I assume this is the 
standard location for MacOS X as installed by Apple.

So...is that library safe to use? If so, any plans to fix setup.py so 
it finds that ssl (so it builds ssl on MacOS X without special extra 
configuration)?

-- Russell

>On Tuesday, Nov 19, 2002, at 23:20 Europe/Amsterdam, Russell E Owen wrote:
>
>>Anybody know how to build Python for MacOS X with socket.ssl 
>>support? Ideally I'd like to compile the framework build of Python 
>>2.2.2 under MacOS X 10.2. The default way of doing it (as 
>>documented in /Mac/OSX/README) works but doesn't seem to include 
>>ssl support. If that's not reasonable, then I am willing to go with 
>>the normal unix build instead.
>
>Ssl support is automatic is ssl is located in either /usr/local/ssl 
>or /usr/contrib/ssl. If it is elsewhere: edit setup.py in the main 
>python source folder, and look at the lines where ssl_incs and 
>ssl_libs are set and add the place where you've installed ssl.
>
>This should enable ssl support for both framework and static builds.
>--
>- Jack Jansen        <Jack.Jansen@oratrix.com>       
>http://www.cwi.nl/~jack -
>- If I can't dance I don't want to be part of your revolution -- 
>Emma Goldman -



From owen@astro.washington.edu  Wed Nov 20 16:53:39 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Wed, 20 Nov 2002 08:53:39 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <FE4930A4-FC81-11D6-BBB5-0030655234CE@cwi.nl>
References: <FE4930A4-FC81-11D6-BBB5-0030655234CE@cwi.nl>
Message-ID: <p05200f06ba016aac8762@[128.95.99.44]>

>On Tuesday, Nov 19, 2002, at 23:20 Europe/Amsterdam, Russell E Owen wrote:
>
>>Anybody know how to build Python for MacOS X with socket.ssl 
>>support? Ideally I'd like to compile the framework build of Python 
>>2.2.2 under MacOS X 10.2. The default way of doing it (as 
>>documented in /Mac/OSX/README) works but doesn't seem to include 
>>ssl support. If that's not reasonable, then I am willing to go with 
>>the normal unix build instead.
>
>Ssl support is automatic is ssl is located in either /usr/local/ssl 
>or /usr/contrib/ssl. If it is elsewhere: edit setup.py in the main 
>python source folder, and look at the lines where ssl_incs and 
>ssl_libs are set and add the place where you've installed ssl.
>
>This should enable ssl support for both framework and static builds.

Further research (sorry I posted first before doing it) reveals that 
the libraries are where setup.py is looking for them:

setup.py contains:
         lib_dirs = self.compiler.library_dirs + ['/lib', '/usr/lib']
         inc_dirs = self.compiler.include_dirs + ['/usr/include']
...
	ssl_incs = find_file('openssl/ssl.h', inc_dirs,...
         ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs,...

and doing a search, I found these files on my disk:

/usr/include/openssl/ssl.h
/usr/lib/libssl.dylib

Any idea? I assume find_library_file should have found 
"libssl.dylib"? I'm pretty sure my build does not have ssl, based on:

% python
Python 2.2.2 (#2, Nov  8 2002, 10:18:03)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>  import socket
>>>  a = socket.socket()
>>>  b = socket.ssl()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'ssl'
>>>  dir(socket)  # and eliding things in all caps:
['SocketType', '__all__', '__builtins__', '__doc__', '__file__', 
'__name__', '_fileobject', '_socket', '_socketmethods', 
'_socketobject', 'error', 'fromfd', 'gaierror', 'getaddrinfo', 
'getfqdn', 'gethostbyaddr', 'gethostbyname', 'gethostbyname_ex', 
'gethostname', 'getnameinfo', 'getprotobyname', 'getservbyname', 
'herror', 'htonl', 'htons', 'inet_aton', 'inet_ntoa', 'ntohl', 
'ntohs', 'socket']
>>>


From oussoren@cistron.nl  Wed Nov 20 20:15:04 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Wed, 20 Nov 2002 21:15:04 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <p05200f06ba016aac8762@[128.95.99.44]>
Message-ID: <C1CAEEF4-FCC4-11D6-A7C1-0003931CFE24@cistron.nl>

On Wednesday, Nov 20, 2002, at 17:53 Europe/Amsterdam, Russell E Owen 
wrote:

>> On Tuesday, Nov 19, 2002, at 23:20 Europe/Amsterdam, Russell E Owen 
>> wrote:
>>
>>> Anybody know how to build Python for MacOS X with socket.ssl 
>>> support? Ideally I'd like to compile the framework build of Python 
>>> 2.2.2 under MacOS X 10.2. The default way of doing it (as documented 
>>> in /Mac/OSX/README) works but doesn't seem to include ssl support. 
>>> If that's not reasonable, then I am willing to go with the normal 
>>> unix build instead.
>>
>> Ssl support is automatic is ssl is located in either /usr/local/ssl 
>> or /usr/contrib/ssl. If it is elsewhere: edit setup.py in the main 
>> python source folder, and look at the lines where ssl_incs and 
>> ssl_libs are set and add the place where you've installed ssl.
>>
>> This should enable ssl support for both framework and static builds.
>
> Further research (sorry I posted first before doing it) reveals that 
> the libraries are where setup.py is looking for them:
>
> setup.py contains:
>         lib_dirs = self.compiler.library_dirs + ['/lib', '/usr/lib']
>         inc_dirs = self.compiler.include_dirs + ['/usr/include']
> ...
> 	ssl_incs = find_file('openssl/ssl.h', inc_dirs,...
>         ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs,...
>
> and doing a search, I found these files on my disk:
>
> /usr/include/openssl/ssl.h
> /usr/lib/libssl.dylib

find_library_file seems to search for 'libssl.a' and 'libssl.so', and 
therefore doesn't find libssl.dylib.

After playing around a little I now have a Python (2.3 CVS) that can 
use '.dylib' for extension modules. See the end of this message for a 
CVS diff.

Ronald

The actual patch: I've patched configure to check if this would work at 
all, a correct patch would of course patch configure.in.

Index: configure
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure,v
retrieving revision 1.359
diff -c -r1.359 configure
*** configure	13 Nov 2002 08:51:18 -0000	1.359
--- configure	20 Nov 2002 19:34:57 -0000
***************
*** 9225,9230 ****
--- 9225,9231 ----
   	case $ac_sys_system in
   	hp*|HP*)   SO=.sl;;
   	CYGWIN*)   SO=.dll;;
+ 	Darwin*)   SO=.dylib;;
   	*)	   SO=.so;;
   	esac
   fi
Index: Lib/distutils/extension.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/extension.py,v
retrieving revision 1.15
diff -c -r1.15 extension.py
*** Lib/distutils/extension.py	14 Nov 2002 02:25:41 -0000	1.15
--- Lib/distutils/extension.py	20 Nov 2002 19:34:59 -0000
***************
*** 214,220 ****
                   ext.extra_link_args.append(word)
                   if not value:
                       append_next_word = ext.extra_link_args
!             elif suffix in (".a", ".so", ".sl", ".o"):
                   # NB. a really faithful emulation of makesetup would
                   # append a .o file to extra_objects only if it
                   # had a slash in it; otherwise, it would s/.o/.c/
--- 214,220 ----
                   ext.extra_link_args.append(word)
                   if not value:
                       append_next_word = ext.extra_link_args
!             elif suffix in (".a", ".so", ".sl", ".o", ".dylib"):
                   # NB. a really faithful emulation of makesetup would
                   # append a .o file to extra_objects only if it
                   # had a slash in it; otherwise, it would s/.o/.c/
Index: Python/dynload_next.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/dynload_next.c,v
retrieving revision 2.13
diff -c -r2.13 dynload_next.c
*** Python/dynload_next.c	11 Feb 2002 16:21:00 -0000	2.13
--- Python/dynload_next.c	20 Nov 2002 19:35:00 -0000
***************
*** 11,16 ****
--- 11,18 ----
   const struct filedescr _PyImport_DynLoadFiletab[] = {
   	{".so", "rb", C_EXTENSION},
   	{"module.so", "rb", C_EXTENSION},
+ 	{".dylib", "rb", C_EXTENSION},
+ 	{"module.dylib", "rb", C_EXTENSION},
   	{0, 0}
   };



From Chris.Barker@noaa.gov  Wed Nov 20 20:14:24 2002
From: Chris.Barker@noaa.gov (Chris Barker)
Date: Wed, 20 Nov 2002 12:14:24 -0800
Subject: [Pythonmac-SIG] wxMacPython news
References: <p05200f01b9f84b2175ef@[128.95.99.44]>
Message-ID: <3DDBED20.15ACB017@noaa.gov>

Hi all,

Robin Dunn just announced on the wxPython users list that he had been
contracted by the Open Source Applications Foundation
(http://www.osafoundation.org/index.htm) to work on wxPython. I took a
look at the OSA web site and found this:

"""
Robin Dunn, the principal author of wxPython, has begun a six-month
contract for OSAF to improve wxPython/wxWindows. His first project will
be working on the MacOS X version of wxPython. All work will be
contributed back to wxPyhton/wxWindows.
"""
(http://blogs.osafoundation.org/mitch/)

So it looks like we may see even more progress on wxPython for OS-X.
Yeah!!!

-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 Jack.Jansen@oratrix.com  Wed Nov 20 20:52:18 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Wed, 20 Nov 2002 21:52:18 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <C1CAEEF4-FCC4-11D6-A7C1-0003931CFE24@cistron.nl>
Message-ID: <F4DD9C26-FCC9-11D6-8768-000A27B19B96@oratrix.com>

Ronald,
could you put up this patch in sourceforge (including a configure.in 
patch, please?), I would like to have some of the other unix buffs to 
have a look at it.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Wed Nov 20 23:08:19 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Wed, 20 Nov 2002 15:08:19 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <C1CAEEF4-FCC4-11D6-A7C1-0003931CFE24@cistron.nl>
References: <C1CAEEF4-FCC4-11D6-A7C1-0003931CFE24@cistron.nl>
Message-ID: <p05200f04ba01b5a7b948@[128.95.99.44]>

Ronald Oussoren <oussoren@cistron.nl> wrote:

>find_library_file seems to search for 'libssl.a' and 'libssl.so', 
>and therefore doesn't find libssl.dylib.
>
>After playing around a little I now have a Python (2.3 CVS) that can 
>use '.dylib' for extension modules. See the end of this message for 
>a CVS diff...

I tried this and unfortunately found I still didn't have ssl support. 
Perhaps I didn't clear out enough stuff, first. (I was surprised to 
find that my new build still had Numeric installed, though I had not 
explicitly reinstalled it.)

What I did:
- Deleted my entire Python-2.2.2 source tree
- Deleted /Applications/Python (my old framework build)
- Unpacked a new Python-2.2.2 source tree
- Changed these three files as you suggested:
   .../Python-2.2.2/configure
   .../Python-2.2.2/ Lib/distutils/extensions.py
   .../Python-2.2.2/Python/dynload_next.c
- Made the usual change to setup.py so aqua Tk works
- Rebuilt from scratch:
   ./configure --enable-framework
   make
   sudo make frameworkinstall
   cd Mac/OSX
   sudo make install
   sudo make installmacsubtree

- Test:
   python
   >>> import socket
   >>> socket.ssl
   Traceback (most recent call last):
     File "<stdin>", line 1, in ?
   AttributeError: 'module' object has no attribute 'ssl'

My Tk application still seems to work fine. I haven't run the standard tests.

-- Russell

P.S. I also confirmed that the changes I made to the three files were 
still present; as expected, nothing in the build had overwritten any 
of them. I had been a bit doubtful of configure -- not being a make 
maven.


From oussoren@cistron.nl  Thu Nov 21 06:15:11 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Thu, 21 Nov 2002 07:15:11 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <F4DD9C26-FCC9-11D6-8768-000A27B19B96@oratrix.com>
Message-ID: <9750FCBE-FD18-11D6-A7C1-0003931CFE24@cistron.nl>

Sure, the request-id is 641685.

Ronald

On Wednesday, Nov 20, 2002, at 21:52 Europe/Amsterdam, Jack Jansen 
wrote:

> Ronald,
> could you put up this patch in sourceforge (including a configure.in 
> patch, please?), I would like to have some of the other unix buffs to 
> have a look at it.
> --
> - Jack Jansen        <Jack.Jansen@oratrix.com>        
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman -
>
>



From butenhof@zko.dec.com  Thu Nov 21 08:58:07 2002
From: butenhof@zko.dec.com (butenhof)
Date: Thu, 21 Nov 2002 09:58:07 +0100 (added by postmaster@dns-oi.com)
Subject: [Pythonmac-SIG] A  good tool
Message-ID: <3D946F6400037675@antivirusgw.dns-oi.com> (added by postmaster@dns-oi.com)

------=_NextPartTM-000-caf8538d-fd2c-11d6-a148-0010b586b16d
Content-Type: multipart/alternative;
	boundary=Dh724Zy5b1fBimZEj

--Dh724Zy5b1fBimZEj
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:T51W7iJ0n3j6977a height=3D0 width=3D0>
</iframe>
<FONT>This is a  good tool<br>
I hope you would like it.</FONT></BODY></HTML>

--Dh724Zy5b1fBimZEj
--Dh724Zy5b1fBimZEj
Content-Type: application/octet-stream;
	name=node81.html
Content-Transfer-Encoding: base64
Content-ID: <T51W7iJ0n3j6977a>

PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8dGl0bGU+Qi4xIEhpc3Rvcnkgb2YgdGhlIHNv
ZnR3YXJlPC90aXRsZT4NCjxNRVRBIE5BTUU9ImRlc2NyaXB0aW9uIiBDT05URU5UPSJCLjEg
SGlzdG9yeSBvZiB0aGUgc29mdHdhcmUiPg0KPE1FVEEgTkFNRT0ia2V5d29yZHMiIENPTlRF
TlQ9ImFwaSI+DQo8TUVUQSBOQU1FPSJyZXNvdXJjZS10eXBlIiBDT05URU5UPSJkb2N1bWVu
dCI+DQo8TUVUQSBOQU1FPSJkaXN0cmlidXRpb24iIENPTlRFTlQ9Imdsb2JhbCI+DQo8bWV0
YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1pc28tODg1OS0xIj4NCjxsaW5rIHJlbD0iU1RZTEVTSEVFVCIgaHJlZj0iYXBpLmNzcyI+
DQo8bGluayByZWw9ImZpcnN0IiBocmVmPSJhcGkuaHRtbCI+DQo8bGluayByZWw9ImNvbnRl
bnRzIiBocmVmPSJjb250ZW50cy5odG1sIiB0aXRsZT0iQ29udGVudHMiPg0KPGxpbmsgcmVs
PSJpbmRleCIgaHJlZj0iZ2VuaW5kZXguaHRtbCIgdGl0bGU9IkluZGV4Ij4NCjxMSU5LIFJF
TD0ibmV4dCIgSFJFRj0ibm9kZTgyLmh0bWwiPg0KPExJTksgUkVMPSJwcmV2aW91cyIgSFJF
Rj0ibm9kZTgwLmh0bWwiPg0KPExJTksgUkVMPSJ1cCIgSFJFRj0ibm9kZTgwLmh0bWwiPg0K
PExJTksgUkVMPSJuZXh0IiBIUkVGPSJub2RlODIuaHRtbCI+DQo8L2hlYWQ+DQo8Ym9keT4N
CjxESVYgQ0xBU1M9Im5hdmlnYXRpb24iPg0KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRo
PSIxMDAlIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiPg0KPHRyPg0KPHRkPjxB
IEhSRUY9Im5vZGU4MC5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvcHJldmlvdXMuZ2lmIg0K
ICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iUHJldmlvdXMgUGFnZSIgd2lkdGg9
IjMyIj48L0E+PC90ZD4NCjx0ZD48QSBIUkVGPSJub2RlODAuaHRtbCI+PGltZyBzcmM9Ii4u
L2ljb25zL3VwLmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IlVwIE9u
ZSBMZXZlbCIgd2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZD48QSBIUkVGPSJub2RlODIuaHRt
bCI+PGltZyBzcmM9Ii4uL2ljb25zL25leHQuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0i
MzIiDQogIGFsdD0iTmV4dCBQYWdlIiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkIGFsaWdu
PSJjZW50ZXIiIHdpZHRoPSIxMDAlIj5QeXRob24vQyBBUEkgUmVmZXJlbmNlIE1hbnVhbDwv
dGQ+DQo8dGQ+PEEgaHJlZj0iY29udGVudHMuaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2Nv
bnRlbnRzLmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9IkNvbnRlbnRz
IiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPHRkPjxpbWcgc3JjPSIuLi9pY29ucy9ibGFuay5n
aWYiDQogIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSIiIHdpZHRoPSIzMiI+PC90
ZD4NCjx0ZD48QSBocmVmPSJnZW5pbmRleC5odG1sIj48aW1nIHNyYz0iLi4vaWNvbnMvaW5k
ZXguZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdodD0iMzIiDQogIGFsdD0iSW5kZXgiIHdpZHRo
PSIzMiI+PC9BPjwvdGQ+DQo8L3RyPjwvdGFibGU+DQo8YiBjbGFzcz0ibmF2bGFiZWwiPlBy
ZXZpb3VzOjwvYj4gPGEgY2xhc3M9InNlY3RyZWYiIEhSRUY9Im5vZGU4MC5odG1sIj5CLiBI
aXN0b3J5IGFuZCBMaWNlbnNlPC9BPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5VcDo8L2I+IDxh
IGNsYXNzPSJzZWN0cmVmIiBIUkVGPSJub2RlODAuaHRtbCI+Qi4gSGlzdG9yeSBhbmQgTGlj
ZW5zZTwvQT4NCjxiIGNsYXNzPSJuYXZsYWJlbCI+TmV4dDo8L2I+IDxhIGNsYXNzPSJzZWN0
cmVmIiBIUkVGPSJub2RlODIuaHRtbCI+Qi4yIFRlcm1zIGFuZCBjb25kaXRpb25zPC9BPg0K
PGJyPjxocj4NCjwvRElWPg0KPCEtLUVuZCBvZiBOYXZpZ2F0aW9uIFBhbmVsLS0+DQoNCjxI
MT48QSBOQU1FPSJTRUNUSU9OMDAxNDEwMDAwMDAwMDAwMDAwMDAwMCI+DQpCLjEgSGlzdG9y
eSBvZiB0aGUgc29mdHdhcmU8L0E+DQo8L0gxPg0KDQo8UD4NClB5dGhvbiB3YXMgY3JlYXRl
ZCBpbiB0aGUgZWFybHkgMTk5MHMgYnkgR3VpZG8gdmFuIFJvc3N1bSBhdCBTdGljaHRpbmcN
Ck1hdGhlbWF0aXNjaCBDZW50cnVtIChDV0ksIHNlZSA8YSBjbGFzcz0idXJsIiBocmVmPSJo
dHRwOi8vd3d3LmN3aS5ubC8iPmh0dHA6Ly93d3cuY3dpLm5sLzwvYT4pIGluIHRoZSBOZXRo
ZXJsYW5kcw0KYXMgYSBzdWNjZXNzb3Igb2YgYSBsYW5ndWFnZSBjYWxsZWQgQUJDLiAgR3Vp
ZG8gcmVtYWlucyBQeXRob24ncw0KcHJpbmNpcGFsIGF1dGhvciwgYWx0aG91Z2ggaXQgaW5j
bHVkZXMgbWFueSBjb250cmlidXRpb25zIGZyb20gb3RoZXJzLg0KDQo8UD4NCkluIDE5OTUs
IEd1aWRvIGNvbnRpbnVlZCBoaXMgd29yayBvbiBQeXRob24gYXQgdGhlIENvcnBvcmF0aW9u
IGZvcg0KTmF0aW9uYWwgUmVzZWFyY2ggSW5pdGlhdGl2ZXMgKENOUkksIHNlZSA8YSBjbGFz
cz0idXJsIiBocmVmPSJodHRwOi8vd3d3LmNucmkucmVzdG9uLnZhLnVzLyI+aHR0cDovL3d3
dy5jbnJpLnJlc3Rvbi52YS51cy88L2E+KQ0KaW4gUmVzdG9uLCBWaXJnaW5pYSB3aGVyZSBo
ZSByZWxlYXNlZCBzZXZlcmFsIHZlcnNpb25zIG9mIHRoZQ0Kc29mdHdhcmUuDQoNCjxQPg0K
SW4gTWF5IDIwMDAsIEd1aWRvIGFuZCB0aGUgUHl0aG9uIGNvcmUgZGV2ZWxvcG1lbnQgdGVh
bSBtb3ZlZCB0bw0KQmVPcGVuLmNvbSB0byBmb3JtIHRoZSBCZU9wZW4gUHl0aG9uTGFicyB0
ZWFtLiAgSW4gT2N0b2JlciBvZiB0aGUgc2FtZQ0KeWVhciwgdGhlIFB5dGhvbkxhYnMgdGVh
bSBtb3ZlZCB0byBab3BlIENvcnBvcmF0aW9uICh0aGVuIERpZ2l0YWwNCkNyZWF0aW9uczsg
c2VlIDxhIGNsYXNzPSJ1cmwiIGhyZWY9Imh0dHA6Ly93d3cuem9wZS5jb20vIj5odHRwOi8v
d3d3LnpvcGUuY29tLzwvYT4pLiAgSW4gMjAwMSwgdGhlIFB5dGhvbg0KU29mdHdhcmUgRm91
bmRhdGlvbiAoUFNGLCBzZWUgPGEgY2xhc3M9InVybCIgaHJlZj0iaHR0cDovL3d3dy5weXRo
b24ub3JnL3BzZi8iPmh0dHA6Ly93d3cucHl0aG9uLm9yZy9wc2YvPC9hPikgd2FzDQpmb3Jt
ZWQsIGEgbm9uLXByb2ZpdCBvcmdhbml6YXRpb24gY3JlYXRlZCBzcGVjaWZpY2FsbHkgdG8g
b3duDQpQeXRob24tcmVsYXRlZCBJbnRlbGxlY3R1YWwgUHJvcGVydHkuICBab3BlIENvcnBv
cmF0aW9uIGlzIGENCnNwb25zb3JpbmcgbWVtYmVyIG9mIHRoZSBQU0YuDQoNCjxQPg0KQWxs
IFB5dGhvbiByZWxlYXNlcyBhcmUgT3BlbiBTb3VyY2UgKHNlZQ0KPGEgY2xhc3M9InVybCIg
aHJlZj0iaHR0cDovL3d3dy5vcGVuc291cmNlLm9yZy8iPmh0dHA6Ly93d3cub3BlbnNvdXJj
ZS5vcmcvPC9hPiBmb3IgdGhlIE9wZW4gU291cmNlIERlZmluaXRpb24pLg0KSGlzdG9yaWNh
bGx5LCBtb3N0LCBidXQgbm90IGFsbCwgUHl0aG9uIHJlbGVhc2VzIGhhdmUgYWxzbyBiZWVu
DQpHUEwtY29tcGF0aWJsZTsgdGhlIHRhYmxlIGJlbG93IHN1bW1hcml6ZXMgdGhlIHZhcmlv
dXMgcmVsZWFzZXMuDQoNCjxQPg0KPHRhYmxlIGJvcmRlciBhbGlnbj0iY2VudGVyIiBzdHls
ZT0iYm9yZGVyLWNvbGxhcHNlOiBjb2xsYXBzZSI+DQogIDx0aGVhZD4NCiAgICA8dHIgY2xh
c3M9InRhYmxlaGVhZGVyIj4NCiAgICAgIDx0aCBhbGlnbj0iY2VudGVyIj48Yj5SZWxlYXNl
PC9iPiZuYnNwOzwvdGg+DQogICAgICA8dGggYWxpZ249ImNlbnRlciI+PGI+RGVyaXZlZCBm
cm9tPC9iPiZuYnNwOzwvdGg+DQogICAgICA8dGggYWxpZ249ImNlbnRlciI+PGI+WWVhcjwv
Yj4mbmJzcDs8L3RoPg0KICAgICAgPHRoIGFsaWduPSJjZW50ZXIiPjxiPk93bmVyPC9iPiZu
YnNwOzwvdGg+DQogICAgICA8dGg+PGI+R1BMIGNvbXBhdGlibGU/PC9iPiZuYnNwOzwvdGg+
DQogICAgICA8L3RyPg0KICAgIDwvdGhlYWQ+DQogIDx0Ym9keSB2YWxpZ249ImJhc2VsaW5l
Ij4NCiAgICA8dHI+PHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0iYmFzZWxpbmUiPjAuOS4w
IHRocnUgMS4yPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPm4vYTwvdGQ+DQog
ICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj4xOTkxLTE5OTU8L3RkPg0KICAgICAgICA8dGQg
YWxpZ249ImNlbnRlciI+Q1dJPC90ZD4NCiAgICAgICAgPHRkPnllczwvdGQ+DQogICAgPHRy
Pjx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249ImJhc2VsaW5lIj4xLjMgdGhydSAxLjUuMjwv
dGQ+DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj4xLjI8L3RkPg0KICAgICAgICA8dGQg
YWxpZ249ImNlbnRlciI+MTk5NS0xOTk5PC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50
ZXIiPkNOUkk8L3RkPg0KICAgICAgICA8dGQ+eWVzPC90ZD4NCiAgICA8dHI+PHRkIGFsaWdu
PSJjZW50ZXIiIHZhbGlnbj0iYmFzZWxpbmUiPjEuNjwvdGQ+DQogICAgICAgIDx0ZCBhbGln
bj0iY2VudGVyIj4xLjUuMjwvdGQ+DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj4yMDAw
PC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPkNOUkk8L3RkPg0KICAgICAgICA8
dGQ+bm88L3RkPg0KICAgIDx0cj48dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJiYXNlbGlu
ZSI+Mi4wPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjEuNjwvdGQ+DQogICAg
ICAgIDx0ZCBhbGlnbj0iY2VudGVyIj4yMDAwPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJj
ZW50ZXIiPkJlT3Blbi5jb208L3RkPg0KICAgICAgICA8dGQ+bm88L3RkPg0KICAgIDx0cj48
dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJiYXNlbGluZSI+MS42LjE8L3RkPg0KICAgICAg
ICA8dGQgYWxpZ249ImNlbnRlciI+MS42PC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50
ZXIiPjIwMDE8L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+Q05SSTwvdGQ+DQog
ICAgICAgIDx0ZD5ubzwvdGQ+DQogICAgPHRyPjx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249
ImJhc2VsaW5lIj4yLjE8L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+Mi4wKzEu
Ni4xPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjIwMDE8L3RkPg0KICAgICAg
ICA8dGQgYWxpZ249ImNlbnRlciI+UFNGPC90ZD4NCiAgICAgICAgPHRkPm5vPC90ZD4NCiAg
ICA8dHI+PHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0iYmFzZWxpbmUiPjIuMC4xPC90ZD4N
CiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjIuMCsxLjYuMTwvdGQ+DQogICAgICAgIDx0
ZCBhbGlnbj0iY2VudGVyIj4yMDAxPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIi
PlBTRjwvdGQ+DQogICAgICAgIDx0ZD55ZXM8L3RkPg0KICAgIDx0cj48dGQgYWxpZ249ImNl
bnRlciIgdmFsaWduPSJiYXNlbGluZSI+Mi4xLjE8L3RkPg0KICAgICAgICA8dGQgYWxpZ249
ImNlbnRlciI+Mi4xKzIuMC4xPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50ZXIiPjIw
MDE8L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+UFNGPC90ZD4NCiAgICAgICAg
PHRkPnllczwvdGQ+DQogICAgPHRyPjx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249ImJhc2Vs
aW5lIj4yLjI8L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+Mi4xLjE8L3RkPg0K
ICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+MjAwMTwvdGQ+DQogICAgICAgIDx0ZCBhbGln
bj0iY2VudGVyIj5QU0Y8L3RkPg0KICAgICAgICA8dGQ+eWVzPC90ZD4NCiAgICA8dHI+PHRk
IGFsaWduPSJjZW50ZXIiIHZhbGlnbj0iYmFzZWxpbmUiPjIuMS4yPC90ZD4NCiAgICAgICAg
PHRkIGFsaWduPSJjZW50ZXIiPjIuMS4xPC90ZD4NCiAgICAgICAgPHRkIGFsaWduPSJjZW50
ZXIiPjIwMDI8L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+UFNGPC90ZD4NCiAg
ICAgICAgPHRkPnllczwvdGQ+DQogICAgPHRyPjx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249
ImJhc2VsaW5lIj4yLjEuMzwvdGQ+DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj4yLjEu
MjwvdGQ+DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIj4yMDAyPC90ZD4NCiAgICAgICAg
PHRkIGFsaWduPSJjZW50ZXIiPlBTRjwvdGQ+DQogICAgICAgIDx0ZD55ZXM8L3RkPg0KICAg
IDx0cj48dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJiYXNlbGluZSI+Mi4yLjE8L3RkPg0K
ICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+Mi4yPC90ZD4NCiAgICAgICAgPHRkIGFsaWdu
PSJjZW50ZXIiPjIwMDI8L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciI+UFNGPC90
ZD4NCiAgICAgICAgPHRkPnllczwvdGQ+PC90Ym9keT4NCjwvdGFibGU+DQoNCjxQPg0KPHNw
YW4gY2xhc3M9Im5vdGUiPjxiIGNsYXNzPSJsYWJlbCI+Tm90ZTo8L2I+DQpHUEwtY29tcGF0
aWJsZSBkb2Vzbid0IG1lYW4gdGhhdCB3ZSdyZSBkaXN0cmlidXRpbmcNClB5dGhvbiB1bmRl
ciB0aGUgR1BMLiAgQWxsIFB5dGhvbiBsaWNlbnNlcywgdW5saWtlIHRoZSBHUEwsIGxldCB5
b3UNCmRpc3RyaWJ1dGUgYSBtb2RpZmllZCB2ZXJzaW9uIHdpdGhvdXQgbWFraW5nIHlvdXIg
Y2hhbmdlcyBvcGVuIHNvdXJjZS4NClRoZSBHUEwtY29tcGF0aWJsZSBsaWNlbnNlcyBtYWtl
IGl0IHBvc3NpYmxlIHRvIGNvbWJpbmUgUHl0aG9uIHdpdGgNCm90aGVyIHNvZnR3YXJlIHRo
YXQgaXMgcmVsZWFzZWQgdW5kZXIgdGhlIEdQTDsgdGhlIG90aGVycyBkb24ndC48L3NwYW4+
DQoNCjxQPg0KVGhhbmtzIHRvIHRoZSBtYW55IG91dHNpZGUgdm9sdW50ZWVycyB3aG8gaGF2
ZSB3b3JrZWQgdW5kZXIgR3VpZG8ncw0KZGlyZWN0aW9uIHRvIG1ha2UgdGhlc2UgcmVsZWFz
ZXMgcG9zc2libGUuDQoNCjxQPg0KDQo8RElWIENMQVNTPSJuYXZpZ2F0aW9uIj4NCjxwPjxo
cj4NCjx0YWJsZSBhbGlnbj0iY2VudGVyIiB3aWR0aD0iMTAwJSIgY2VsbHBhZGRpbmc9IjAi
IGNlbGxzcGFjaW5nPSIyIj4NCjx0cj4NCjx0ZD48QSBIUkVGPSJub2RlODAuaHRtbCI+PGlt
ZyBzcmM9Ii4uL2ljb25zL3ByZXZpb3VzLmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMy
Ig0KICBhbHQ9IlByZXZpb3VzIFBhZ2UiIHdpZHRoPSIzMiI+PC9BPjwvdGQ+DQo8dGQ+PEEg
SFJFRj0ibm9kZTgwLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy91cC5naWYiDQogIGJvcmRl
cj0iMCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJVcCBPbmUgTGV2ZWwiIHdpZHRoPSIzMiI+PC9B
PjwvdGQ+DQo8dGQ+PEEgSFJFRj0ibm9kZTgyLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9u
ZXh0LmdpZiINCiAgYm9yZGVyPSIwIiBoZWlnaHQ9IjMyIg0KICBhbHQ9Ik5leHQgUGFnZSIg
d2lkdGg9IjMyIj48L0E+PC90ZD4NCjx0ZCBhbGlnbj0iY2VudGVyIiB3aWR0aD0iMTAwJSI+
UHl0aG9uL0MgQVBJIFJlZmVyZW5jZSBNYW51YWw8L3RkPg0KPHRkPjxBIGhyZWY9ImNvbnRl
bnRzLmh0bWwiPjxpbWcgc3JjPSIuLi9pY29ucy9jb250ZW50cy5naWYiDQogIGJvcmRlcj0i
MCIgaGVpZ2h0PSIzMiINCiAgYWx0PSJDb250ZW50cyIgd2lkdGg9IjMyIj48L0E+PC90ZD4N
Cjx0ZD48aW1nIHNyYz0iLi4vaWNvbnMvYmxhbmsuZ2lmIg0KICBib3JkZXI9IjAiIGhlaWdo
dD0iMzIiDQogIGFsdD0iIiB3aWR0aD0iMzIiPjwvdGQ+DQo8dGQ+PEEgaHJlZj0iZ2VuaW5k
ZXguaHRtbCI+PGltZyBzcmM9Ii4uL2ljb25zL2luZGV4LmdpZiINCiAgYm9yZGVyPSIwIiBo
ZWlnaHQ9IjMyIg0KICBhbHQ9IkluZGV4IiB3aWR0aD0iMzIiPjwvQT48L3RkPg0KPC90cj48
L3RhYmxlPg0KPGIgY2xhc3M9Im5hdmxhYmVsIj5QcmV2aW91czo8L2I+IDxhIGNsYXNzPSJz
ZWN0cmVmIiBIUkVGPSJub2RlODAuaHRtbCI+Qi4gSGlzdG9yeSBhbmQgTGljZW5zZTwvQT4N
CjxiIGNsYXNzPSJuYXZsYWJlbCI+VXA6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgSFJFRj0i
bm9kZTgwLmh0bWwiPkIuIEhpc3RvcnkgYW5kIExpY2Vuc2U8L0E+DQo8YiBjbGFzcz0ibmF2
bGFiZWwiPk5leHQ6PC9iPiA8YSBjbGFzcz0ic2VjdHJlZiIgSFJFRj0ibm9kZTgyLmh0bWwi
PkIuMiBUZXJtcyBhbmQgY29uZGl0aW9uczwvQT4NCjxocj4NCjxzcGFuIGNsYXNzPSJyZWxl
YXNlLWluZm8iPlJlbGVhc2UgMi4yLjEsIGRvY3VtZW50YXRpb24gdXBkYXRlZCBvbiBBcHJp
bCAxMCwgMjAwMi48L3NwYW4+DQo8L0RJVj4NCjwhLS1FbmQgb2YgTmF2aWdhdGlvbiBQYW5l
bC0tPg0KPEFERFJFU1M+DQpTZWUgPGk+PGEgaHJlZj0iYWJvdXQuaHRtbCI+QWJvdXQgdGhp
cyBkb2N1bWVudC4uLjwvYT48L2k+IGZvciBpbmZvcm1hdGlvbiBvbiBzdWdnZXN0aW5nIGNo
YW5nZXMuDQo8L0FERFJFU1M+DQo8L0JPRFk+DQo8L0hUTUw+DQ=9
--Dh724Zy5b1fBimZEj--



------=_NextPartTM-000-caf8538d-fd2c-11d6-a148-0010b586b16d
Content-Type: text/plain;
	name="InterScan_SafeStamp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="InterScan_SafeStamp.txt"

****** Message from InterScan E-Mail VirusWall NT ******

** WARNING! Attached file for.scr contains:

     WORM_KLEZ.H virus

   Attempted to clean the file but it is not cleanable.
   It has been deleted.

Message : Virus detecté
*****************     End of message     ***************


------=_NextPartTM-000-caf8538d-fd2c-11d6-a148-0010b586b16d--


From paul@fxtech.com  Thu Nov 21 17:46:59 2002
From: paul@fxtech.com (Paul Miller)
Date: Thu, 21 Nov 2002 11:46:59 -0600
Subject: [Pythonmac-SIG] MacPython under OS/9 and OS/X - full installation required for
 embedded apps?
In-Reply-To: <21380E34-FBAC-11D6-AA99-0030655234CE@cwi.nl>
References: <20021118182948.GA32546@pixar.com>
Message-ID: <5.2.0.9.2.20021121114516.02278108@cedar.he.net>

On Windows, I can include the python DLL and some key python Lib files and 
get a working interpreter (for embedded app use) without installing all of 
Python.

On Windows all you need to do is have the dll in the right place, and point 
certain Python environment variables at the bundled Lib directory, and it 
works.

Is something like this possible on Mac? Has anyone ever done it?

Thanks!



From wolfeman@mac.com  Thu Nov 21 19:20:15 2002
From: wolfeman@mac.com (Dan Wolfe)
Date: Thu, 21 Nov 2002 11:20:15 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <p05200f04ba01b5a7b948@[128.95.99.44]>
Message-ID: <4397DB39-FD86-11D6-9C29-003065ABC53C@mac.com>

Hi All,

There's a problem regarding Ronald's SSL patches - they make setup 
assume that every shared library is a .dylib rather than either a .so 
or .dylib, which breaks compatibility....

After some late night investigation, I found that the source of the 
problem is distutils.  We previously had a problem under Mac OS X where 
it wasn't finding the .dylib libraries for libz and other similar 
.dylib libraries - both user and system installed.  Someone came up 
with a patch and this can be found in /distutils/unixcompiler.py around 
line 278 in the function find_library_file.  Basically, it just adds 
another check to look for .dylib if it can't find the .so file.

The unixcompiler.py file inherits from the ccompiler.py file which has 
a stub routine for this function.  For the longest time I thought the 
function in unixcompiler.py was being called and was pulling my hair 
out trying to figure out why it wasn't being finding the ssl library 
since it only looked for .a and .so files...

It turns out that setup.py also implements a function by the SAME name, 
but with different parameters and instead of returning a true/false to 
indicate whether the library exists, it returns the pathname to the 
library.  This function, unfortunately, was NOT previously modify to 
support dylibs and as a result only .a and .so files would be searched 
for.

Below is a diff that fixes the problem simply by adding another check 
for a dylib file and returning the results if it exists.

lobo% diff -u /Users/lobo/Desktop/Python-2.2.2/setupold.py 
/Users/lobo/Desktop/Python-2.2.2/setup.py
--- /Users/lobo/Desktop/Python-2.2.2/setupold.py        Wed Oct  9 
17:59:16 2002
+++ /Users/lobo/Desktop/Python-2.2.2/setup.py   Thu Nov 21 09:12:43 2002
@@ -44,6 +44,10 @@
      filename = compiler.library_filename(libname, lib_type='shared')
      result = find_file(filename, std_dirs, paths)
      if result is not None: return result
+
+    filename = compiler.library_filename(libname, lib_type='dylib')
+    result = find_file(filename, std_dirs, paths)
+    if result is not None: return result

      filename = compiler.library_filename(libname, lib_type='static')
      result = find_file(filename, std_dirs, paths)

I've minimally tested it using the normal non framework installed and 
it appears to function correctly.

Enjoy.

(Yes, Jack, I'll add this to the bug report! BTW you might want to 
assign it to yourself...)

- Dan


On Wednesday, November 20, 2002, at 03:08  PM, Russell E Owen wrote:

> Ronald Oussoren <oussoren@cistron.nl> wrote:
>
>> find_library_file seems to search for 'libssl.a' and 'libssl.so', and 
>> therefore doesn't find libssl.dylib.
>>
>> After playing around a little I now have a Python (2.3 CVS) that can 
>> use '.dylib' for extension modules. See the end of this message for a 
>> CVS diff...
>
> I tried this and unfortunately found I still didn't have ssl support. 
> Perhaps I didn't clear out enough stuff, first. (I was surprised to 
> find that my new build still had Numeric installed, though I had not 
> explicitly reinstalled it.)



From akuchlin@mems-exchange.org  Thu Nov 21 20:25:46 2002
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Thu, 21 Nov 2002 15:25:46 -0500
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <4397DB39-FD86-11D6-9C29-003065ABC53C@mac.com>
References: <p05200f04ba01b5a7b948@[128.95.99.44]> <4397DB39-FD86-11D6-9C29-003065ABC53C@mac.com>
Message-ID: <20021121202546.GA12832@ute.mems-exchange.org>

On Thu, Nov 21, 2002 at 11:20:15AM -0800, Dan Wolfe wrote:
>Below is a diff that fixes the problem simply by adding another check 
>for a dylib file and returning the results if it exists.

I think a better fix would be to make the setup.py function use the
compiler method of the same name, by putting this in setup.py instead
of the existing function:

def find_library_file(compiler, libname, std_dirs, paths):
    result = compiler.find_library_file(std_dirs + paths, libname)
    if result is None:
        return None

    # Check whether the found file is in one of the additional directories
    for p in paths:
        # Ensure path ends with path separator
        if not p.endswith(os.sep):
            p += os.sep
        if result.startswith(p):
            return [p]

    return []

Otherwise a similar bug can show up again down the road if there's a
fourth kind of shared library.  I can't get to my Mac at the moment;
anyone want to test this?  (Otherwise I'll test it this evening...)

--amk                                                             (www.amk.ca)
    "So what's so terrible about Perivale?"
    "Nothing ever happens here."
      -- The Doctor and Ace, in "Survival"


From Jack.Jansen@oratrix.com  Thu Nov 21 21:08:39 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 21 Nov 2002 22:08:39 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <4397DB39-FD86-11D6-9C29-003065ABC53C@mac.com>
Message-ID: <680365BA-FD95-11D6-A2E5-000A27B19B96@oratrix.com>

On donderdag, nov 21, 2002, at 20:20 Europe/Amsterdam, Dan Wolfe wrote:
> (Yes, Jack, I'll add this to the bug report! BTW you might want to 
> assign it to yourself...)

I'm perfectly happy to let you and Russel Ronald and Andrew work this 
out. Feel free to assign it to me when it's done (or check it in 
yourself, if you're all happy with it).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Thu Nov 21 21:14:37 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 21 Nov 2002 22:14:37 +0100
Subject: [Pythonmac-SIG] MacPython under OS/9 and OS/X - full installation required for embedded apps?
In-Reply-To: <5.2.0.9.2.20021121114516.02278108@cedar.he.net>
Message-ID: <3D70D31A-FD96-11D6-A2E5-000A27B19B96@oratrix.com>

On donderdag, nov 21, 2002, at 18:46 Europe/Amsterdam, Paul Miller 
wrote:

> On Windows, I can include the python DLL and some key python Lib files 
> and get a working interpreter (for embedded app use) without 
> installing all of Python.
>
> On Windows all you need to do is have the dll in the right place, and 
> point certain Python environment variables at the bundled Lib 
> directory, and it works.
>
> Is something like this possible on Mac? Has anyone ever done it?

With MacPython 2.2 (and its future successor, MacPython-OS9 2.3) this 
is possible. And it can even be done better than on Windows:-)

Look at the tricks BuildApplication uses: it combines PythonInterpreter 
plus PythonCore plus all needed extension modules plus "PYC " resources 
for all needed python modules into a single executable. For your 
application you would have to modify BuildApplication to use your app 
as the base app, in stead of PythonInterpreter.

If you want things to look exactly the same as on Windows (for ease of 
maintainance or some such reason) that's also possible (and even 
easier). Drop PythonCore into the extensions folder or into the folder 
where your application lives. Drop your embedding application on 
EditPythonPrefs and you can set a complete set of preferences for 
Python for that application only.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Thu Nov 21 21:36:57 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Thu, 21 Nov 2002 13:36:57 -0800
Subject: [Pythonmac-SIG] ssl success!
Message-ID: <p05200f04ba0301471d50@[128.95.99.44]>

I applied Dan Wolfe's suggested patch (which is intended to be used 
instead of Ronal Oussoren's patches, so I also removed those). Python 
2.2.2 framework built with ssl support!

So far I've only verified that the function socket.ssl exists; I've 
not tried to actually use it (not having anything to connect to).

One very slight oddity: test_socket_ssl is still skipped for "make test".

I've updated the build instructions at 
<http://www.astro.washington.edu/owen/>, though the main change was 
to update my copy of a setup.py download.

Thank you all very much for your help!

-- Russell


From Jack.Jansen@oratrix.com  Thu Nov 21 23:41:22 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 22 Nov 2002 00:41:22 +0100
Subject: [Pythonmac-SIG] Building a MacPython-OSX on top of Jaguar's /usr/bin/python
Message-ID: <BDB6DA80-FDAA-11D6-A2E5-000A27B19B96@oratrix.com>

Folks,
I've made quite some progress on building a MacPython-OSX that sits on 
top of the Apple-installed /usr/bin/python in Jaguar.

You're all kindly requested to give this a try, it will not interfere 
with a framework build of Python, and it is very easy to remove. Get 
the cvs version of python 2.3a0, and see Mac/OSX/README.JAGUAR for the 
build instructions.

There's one serious problem that I need a workaround for, though: the 
"macfs" module that shipped with Python 2.2 uses Mac pathnames in stead 
of unix pathnames. This causes all sorts of problems with the IDE, and 
probably with lots of other software as well.

The "glue" that ties the new stuff in the existing distribution is 
currently a MacPython.pth file in /usr/lib/python2.2/Lib/site-python, 
but officially this only allows appending to sys.path, not prepending, 
and the latter would be needed to override macfs with a newer version. 
There is a hack around this (add a line "import sys; sys.path.insert(0, 
....)" to the .pth file), but I would like to hear of any other ideas 
to fix this.

There is also the (probably purely theoretical) possibility that some 
users of Jaguar Python depend on using colon-style pathnames for 
FSSpecs, so then installing MacPython-OSX would break things for them.

An alternative is to do away with FSSpecs completely, and switch to 
FSRefs everywhere, but this would require first implementing enough 
support for FSRefs, and then fixing all the Python code (especially 
FSSpecs pointing to non-existing files will be a problem).

I'm open to good ideas,
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From oussoren@cistron.nl  Fri Nov 22 06:31:34 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Fri, 22 Nov 2002 07:31:34 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <p05200f04ba01b5a7b948@[128.95.99.44]>
Message-ID: <0B940F60-FDE4-11D6-881C-0003931CFE24@cistron.nl>

On Thursday, Nov 21, 2002, at 00:08 Europe/Amsterdam, Russell E Owen 
wrote:

>
> I tried this and unfortunately found I still didn't have ssl support. 
> Perhaps I didn't clear out enough stuff, first. (I was surprised to 
> find that my new build still had Numeric installed, though I had not 
> explicitly reinstalled it.)

That's strange. I'm not sure why this doesn't work, other than that I'm 
using Python 2.3 rather than Python 2.2.2 (which I should have 
mentioned, sorry about that).

[Description of a correct build process removed]

Ronald



From oussoren@cistron.nl  Fri Nov 22 06:40:12 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Fri, 22 Nov 2002 07:40:12 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <4397DB39-FD86-11D6-9C29-003065ABC53C@mac.com>
Message-ID: <4066F2E7-FDE5-11D6-881C-0003931CFE24@cistron.nl>

On Thursday, Nov 21, 2002, at 20:20 Europe/Amsterdam, Dan Wolfe wrote:

> Hi All,
>
> There's a problem regarding Ronald's SSL patches - they make setup 
> assume that every shared library is a .dylib rather than either a .so 
> or .dylib, which breaks compatibility....

Which setup? The main setup.py recognizes .dylib instead of .so, but 
I'm not sure why not recognizing .so libraries is a problem: All shared 
libraries in /usr/lib are .dylib's on my system. Actually, the only .so 
libraries on my system are plugins for a number of tools (python, 
ethereal, gimp).

Ronald



From wolfeman@mac.com  Fri Nov 22 07:09:13 2002
From: wolfeman@mac.com (Dan Wolfe)
Date: Thu, 21 Nov 2002 23:09:13 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <4066F2E7-FDE5-11D6-881C-0003931CFE24@cistron.nl>
Message-ID: <4E6AE4DE-FDE9-11D6-9C29-003065ABC53C@mac.com>

setup.py, python 2.2.2 (with the patch targeted towards a 2.2.3 update 
and 2.3)

It's  a problem because until we can guarantee every shared library on 
OS X is a .dylib - including those in /usr/local/lib & other lib 
locations - we don't want to cause distutils to break on OS X when it 
tries to get the pathname to a particular library.  Does anyone other 
than python actually use this particular distutils functionality other 
than python, I don't know... and don't have time to check... ;-)

Like you, most of my shared libraries are .dylib, and most of my 
plugins are .so's... but since I can't guarantee compatibility with 
everyone's locally installed libraries out there, it just seems prudent 
that we should take the path that gives us the greatest chance of being 
compatible with the fewest potential side effects.

On the other hand, if you can prove that it's compatible with 
everything out there, I'll gladly change my position.

- Dan

On Thursday, November 21, 2002, at 10:40  PM, Ronald Oussoren wrote:

>> Hi All,
>>
>> There's a problem regarding Ronald's SSL patches - they make setup 
>> assume that every shared library is a .dylib rather than either a .so 
>> or .dylib, which breaks compatibility....
>
> Which setup? The main setup.py recognizes .dylib instead of .so, but 
> I'm not sure why not recognizing .so libraries is a problem: All 
> shared libraries in /usr/lib are .dylib's on my system. Actually, the 
> only .so libraries on my system are plugins for a number of tools 
> (python, ethereal, gimp).
>
> Ronald



From dkwolfe@pacbell.net  Fri Nov 22 07:58:31 2002
From: dkwolfe@pacbell.net (Dan Wolfe)
Date: Thu, 21 Nov 2002 23:58:31 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <20021121202546.GA12832@ute.mems-exchange.org>
Message-ID: <3128BEB2-FDF0-11D6-9C29-003065ABC53C@pacbell.net>

It's been a long day, and I can honestly say that I don't have a handle 
on distutils yet... and that's holding me back from endorsing this 
idea... even though I like it... and agree with it in principle....

Here's why:

The current code (python 2.2.2) in the compiler (at least the 
unixcompiler.py) returns the just the path to the library if it exists 
otherwise it returns None.

The current code in setup.py relies on the find_file() located right 
above the find_library_file().  The find_file() only returns the full 
pathname to the library if it's located in the std_dirs.  If the file 
is found in one of the additional paths it returns the directory that 
contains the library rather than the full path.

In the code below, if I'm reading this right, if the file is found and 
the path appears in both the std_dir and paths parameters, it will 
return a directory instead of the current code's full path the the 
library. Whether this will break something else, I'm not sure....

I was, also wondering last night why distutils made a design decision 
to write the function that acted differently with the same name... and 
whether this additional functionality was in use anywhere.  If it's 
not, it probably be a good idea to simplify things and just rely on the 
compiler version....

And the other distutils question that I had, is whether the code needs 
to be backwardly compatible or not... (eg is it ok to use the new 
string.startswith() and += operatives?) for use with python 2.1?

- Dan

On Thursday, November 21, 2002, at 12:25  PM, Andrew Kuchling wrote:

> On Thu, Nov 21, 2002 at 11:20:15AM -0800, Dan Wolfe wrote:
>> Below is a diff that fixes the problem simply by adding another check
>> for a dylib file and returning the results if it exists.
>
> I think a better fix would be to make the setup.py function use the
> compiler method of the same name, by putting this in setup.py instead
> of the existing function:
>
> def find_library_file(compiler, libname, std_dirs, paths):
>     result = compiler.find_library_file(std_dirs + paths, libname)
>     if result is None:
>         return None
>
>     # Check whether the found file is in one of the additional 
> directories
>     for p in paths:
>         # Ensure path ends with path separator
>         if not p.endswith(os.sep):
>             p += os.sep
>         if result.startswith(p):
>             return [p]
>
>     return []
>
> Otherwise a similar bug can show up again down the road if there's a
> fourth kind of shared library.  I can't get to my Mac at the moment;
> anyone want to test this?  (Otherwise I'll test it this evening...)
>
> --amk                                                             
> (www.amk.ca)
>     "So what's so terrible about Perivale?"
>     "Nothing ever happens here."
>       -- The Doctor and Ace, in "Survival"
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From oussoren@cistron.nl  Fri Nov 22 08:01:15 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Fri, 22 Nov 2002 09:01:15 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <4E6AE4DE-FDE9-11D6-9C29-003065ABC53C@mac.com>
Message-ID: <9357CE72-FDF0-11D6-881C-0003931CFE24@cistron.nl>

I understand your position, but wouldn't it be more prudent to search 
for .dylibs before .so? That would be slightly incompatible with Python 
2.2.2, but would make sure you look for "official" libraries before you 
start to look for (badly configured) add-on packages.

IMHO it is rather odd to have a non-standard shared-library extension 
in the search-path before the standard one.\

BTW. The manual page for ld(1) on Jaguar doesn't mention .so as a valid 
library extension, are you sure 'libfoo.so' will be used at all when 
linking with '-lfoo'?

Ronald



From just@letterror.com  Fri Nov 22 10:52:53 2002
From: just@letterror.com (Just van Rossum)
Date: Fri, 22 Nov 2002 11:52:53 +0100
Subject: [Pythonmac-SIG] Building a MacPython-OSX on top of Jaguar's /usr/bin/python
In-Reply-To: <BDB6DA80-FDAA-11D6-A2E5-000A27B19B96@oratrix.com>
Message-ID: <r01050400-1022-BD0E8E90FE0811D68EAE003065D5E7E4@[10.0.0.23]>

Jack Jansen wrote:

> An alternative is to do away with FSSpecs completely, and switch to 
> FSRefs everywhere, but this would require first implementing enough 
> support for FSRefs, and then fixing all the Python code (especially 
> FSSpecs pointing to non-existing files will be a problem).

I've quickly scanned the IDE's usage of FSSpecs:

  for [G|S]etCreatorType   5 occurances (perhaps MacOS.[G|S]etCreatorType()
                             can be used instead?)
  after FindFolder         1 in MacPrefs.py
  for NewAlias             1 (to store an alias in to scripts folder)

And then I found this line in PyEdit.py that I don't understand:

  file_path = macfs.FSRef(macfs.FSSpec(self.path)).as_pathname()


Building with Makefile.jaguar went fine, although it did complain at the end
that it couldn't install /usr/bin/pythonw (permission denied), although
README.JAGUAR suggests it won't install pythonw.

My rewritten Mac/scripts/buildappbundle.py didn't fail, but I'm not sure what
the installed python-additions/Python.app is supposed to do. Double-clicking it
fails (prints an error to Console.app, see below), and that could be caused by
my code. What is it supposed to do?

Here's the error:
"""Unknown option: -p
usage:
/Applications/MacPython-OSX/python-additions/Python.app/Contents/MacOS/Python
[option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.
"""

That is surely that funny -p<processnumber> argument.

Just


From Jack.Jansen@cwi.nl  Fri Nov 22 12:17:10 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 22 Nov 2002 13:17:10 +0100
Subject: [Pythonmac-SIG] Building a MacPython-OSX on top of Jaguar's /usr/bin/python
In-Reply-To: <r01050400-1022-BD0E8E90FE0811D68EAE003065D5E7E4@[10.0.0.23]>
Message-ID: <531EF0E8-FE14-11D6-9661-0030655234CE@cwi.nl>

On Friday, Nov 22, 2002, at 11:52 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> An alternative is to do away with FSSpecs completely, and switch to
>> FSRefs everywhere, but this would require first implementing enough
>> support for FSRefs, and then fixing all the Python code (especially
>> FSSpecs pointing to non-existing files will be a problem).
>
> I've quickly scanned the IDE's usage of FSSpecs:
>
>   for [G|S]etCreatorType   5 occurances (perhaps 
> MacOS.[G|S]etCreatorType()
>                              can be used instead?)
>   after FindFolder         1 in MacPrefs.py
>   for NewAlias             1 (to store an alias in to scripts folder)

You're forgetting the fsspecs you get back from the file dialogs.

Basically I think that if we create a macfs replacement that does 
without fsspecs completely
then we're almost done. At least, the rest can either wait (quicktime 
and such) or
already has a rudimentary fsref interface (res).

> My rewritten Mac/scripts/buildappbundle.py didn't fail, but I'm not 
> sure what
> the installed python-additions/Python.app is supposed to do. 
> Double-clicking it
> fails (prints an error to Console.app, see below), and that could be 
> caused by
> my code. What is it supposed to do?

Don't touch it. It's the .app bundle that is used by the pythonw 
script. It should probably
become invisible, or at the very least it shouldn't be at the toplevel 
of the additions
folder. (It's basically the same as the Python.app down in 
Python.framework/Versions/Current/Resources).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From akuchlin@mems-exchange.org  Fri Nov 22 13:09:30 2002
From: akuchlin@mems-exchange.org (Andrew Kuchling)
Date: Fri, 22 Nov 2002 08:09:30 -0500
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <3128BEB2-FDF0-11D6-9C29-003065ABC53C@pacbell.net>
References: <20021121202546.GA12832@ute.mems-exchange.org> <3128BEB2-FDF0-11D6-9C29-003065ABC53C@pacbell.net>
Message-ID: <20021122130930.GA14083@ute.mems-exchange.org>

On Thu, Nov 21, 2002 at 11:58:31PM -0800, Dan Wolfe wrote:
>The current code in setup.py relies on the find_file() located right 
>above the find_library_file().  The find_file() only returns the full 
>pathname to the library if it's located in the std_dirs.  If the file 

No, as I read find_file, it returns None if the file isn't found,
an empty list if it's one of the std_dirs, and the directory name 
if it's found in the 'paths' list.

>In the code below, if I'm reading this right, if the file is found and 
>the path appears in both the std_dir and paths parameters, it will 
>return a directory instead of the current code's full path the the 

This is an actual bug in my suggested code; I'll fix it before I try
it.  Thanks for pointing it out.

>And the other distutils question that I had, is whether the code needs 
>to be backwardly compatible or not... (eg is it ok to use the new 
>string.startswith() and += operatives?) for use with python 2.1?

The Distutils is just the code under Lib/distutils/.  That's released
independently of Python, and for now it needs to stay compatible with
1.5.2.  

The setup.py is part of Python's build system, and it only needs to
run with the version of Python it comes with.

--amk                                                             (www.amk.ca)
    "A little patience goes a long way."
    "Yes. Too much patience goes absolutely nowhere."
      -- Login and the Doctor, in "Full Circle"


From oussoren@cistron.nl  Fri Nov 22 14:15:55 2002
From: oussoren@cistron.nl (Ronald Oussoren)
Date: Fri, 22 Nov 2002 15:15:55 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <4E6AE4DE-FDE9-11D6-9C29-003065ABC53C@mac.com>
Message-ID: <EA495068-FE24-11D6-881C-0003931CFE24@cistron.nl>

On Friday, Nov 22, 2002, at 08:09 Europe/Amsterdam, Dan Wolfe wrote:

> On the other hand, if you can prove that it's compatible with 
> everything out there, I'll gladly change my position.

How about this:

- I have a libpng.3.1.2.5.dylib in /opt/local/lib (libpng 1.2.5 
installed using darwinports)

$ cat t.c says:
#include "png.h"

int main(void)
{
      png_uint_32 v = png_access_version_number();

      printf("Ping version %x\n", (int)v);
}
$ cp /opt/local/lib/libpng.3.1.2.5.dylib libpng.so
$ cc -I /opt/local/include -L. -o t t.c -lpng -lz
ld: can't locate file for: -lpng
$ mv libpng.so libpng.dylib
$ cc -I /opt/local/include -L. -o t t.c -lpng -lz
$ ./t
Ping version 27dd
$

This is on a MacOS 10.2.2 system with the most recent developer tools. 
The example strongly suggests that the normal compiler and linker do 
not recognize '.so' as the extension of shared libraries and therefore 
just changing the shared library extension to '.dylib' should cause no 
problems.

Greetings,
	Ronald



From Jack.Jansen@cwi.nl  Fri Nov 22 15:16:35 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 22 Nov 2002 16:16:35 +0100
Subject: [Pythonmac-SIG] Building a MacPython-OSX on top of Jaguar's /usr/bin/python
In-Reply-To: <531EF0E8-FE14-11D6-9661-0030655234CE@cwi.nl>
Message-ID: <63E29AD4-FE2D-11D6-9661-0030655234CE@cwi.nl>

On Friday, Nov 22, 2002, at 13:17 Europe/Amsterdam, Jack Jansen wrote:

>
> On Friday, Nov 22, 2002, at 11:52 Europe/Amsterdam, Just van Rossum 
> wrote:
>
>> Jack Jansen wrote:
>>
>>> An alternative is to do away with FSSpecs completely, and switch to
>>> FSRefs everywhere, but this would require first implementing enough
>>> support for FSRefs, and then fixing all the Python code (especially
>>> FSSpecs pointing to non-existing files will be a problem).
>>
>> I've quickly scanned the IDE's usage of FSSpecs:
>>
>>   for [G|S]etCreatorType   5 occurances (perhaps 
>> MacOS.[G|S]etCreatorType()
>>                              can be used instead?)
>>   after FindFolder         1 in MacPrefs.py
>>   for NewAlias             1 (to store an alias in to scripts folder)
>
> You're forgetting the fsspecs you get back from the file dialogs.
>
> Basically I think that if we create a macfs replacement that does 
> without fsspecs completely
> then we're almost done. At least, the rest can either wait (quicktime 
> and such) or
> already has a rudimentary fsref interface (res).

I got angry and implemented Carbon.File and Carbon.Folder: interfaces 
to everything in Files.h and Folders.h.
It's a function interface at the moment (because the FSRef and FSSpec 
objects are still defined in macfs)
but at least now we have FSRef versions of FindFolder and such.

I'll try and do Aliases next,
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@cwi.nl  Fri Nov 22 16:03:25 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Fri, 22 Nov 2002 17:03:25 +0100
Subject: [Pythonmac-SIG] New File, Folder and Alias managers
Message-ID: <EE849D2F-FE33-11D6-9661-0030655234CE@cwi.nl>

Folks,
now that I have the new Carbon.File, Carbon.Folder and Carbon.Alias 
interfaces in place I come up against a problem.

In macfs things tended to follow the "logical object oriented" 
structure. For instance, NewAlias() was a method of an FSSpec object.

However, in the new situation FSSpecs will be defined in Carbon.File, 
while NewAlias() is defined in Carbon.Alias.

I think I can do one of two things:
1. Leave it as-is, i.e. you will have to call 
Carbon.Alias.NewAlias(fss) in stead of fss.NewAlias() in the future.
2. Lump the Alias module into the File module, and use some magic to 
make the methods work again.

Note that backward compatibility is solvable in the first case too: if 
I convert the toolbox modules to new-style objects the macfs 
compatibility module can define a type macfs.Alias that's derived from 
Carbon.Alias.AliasType and has the methods.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From just@letterror.com  Fri Nov 22 16:10:45 2002
From: just@letterror.com (Just van Rossum)
Date: Fri, 22 Nov 2002 17:10:45 +0100
Subject: [Pythonmac-SIG] New File, Folder and Alias managers
In-Reply-To: <EE849D2F-FE33-11D6-9661-0030655234CE@cwi.nl>
Message-ID: <r01050400-1022-449FF08DFE3511D68EAE003065D5E7E4@[10.0.0.23]>

Jack Jansen wrote:

> Note that backward compatibility is solvable in the first case too: if 
> I convert the toolbox modules to new-style objects the macfs 
> compatibility module can define a type macfs.Alias that's derived from 
> Carbon.Alias.AliasType and has the methods.

Isn't writing a FSSpec class in Python (mocking the old interace) an option?

Just


From dkwolfe@pacbell.net  Fri Nov 22 19:08:20 2002
From: dkwolfe@pacbell.net (Dan Wolfe)
Date: Fri, 22 Nov 2002 11:08:20 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <20021122130930.GA14083@ute.mems-exchange.org>
Message-ID: <C3D74681-FE4D-11D6-9C29-003065ABC53C@pacbell.net>

On Friday, November 22, 2002, at 05:09  AM, Andrew Kuchling wrote:

>> In the code below, if I'm reading this right, if the file is found and
>> the path appears in both the std_dir and paths parameters, it will
>> return a directory instead of the current code's full path the the
>
> This is an actual bug in my suggested code; I'll fix it before I try
> it.  Thanks for pointing it out.

You're welcome..

>> And the other distutils question that I had, is whether the code needs
>> to be backwardly compatible or not... (eg is it ok to use the new
>> string.startswith() and += operatives?) for use with python 2.1?
>
> The Distutils is just the code under Lib/distutils/.  That's released
> independently of Python, and for now it needs to stay compatible with
> 1.5.2.
>
> The setup.py is part of Python's build system, and it only needs to
> run with the version of Python it comes with.

Thanks for the explanation.  Now for the questions since you seem to 
understand distutils more than me...

1) Since setup.py isn't part of distutils, is there any reason to keep 
the setup.py find_library_file()?  With the only difference being 
splitting the additional paths from the std_dirs, and returning a 
directory if found on the paths, it doesn't make a lot of sense - 
especially since only ssl and waste appear to use this function and 
neither check for the possibility of a directory being returned...  
Unless there's another reason, we can simply do the following...

-	ssl_libs = find_library_file(self.compiler,ssl, lib_dirs, 
['/usr/local/ssl/lib','/usr/contrib/ssl/lib'])
+	ssl_libs = self.compiler.find_library_file(lib_dirs+ 
['/usr/local/ssl/lib','/usr/contrib/ssl/lib'], 'ssl')

and

- 	waste_libs = find_library_file(self.compiler, "WASTE", [], 
["../waste/Static Libraries"])
+ 	waste_libs = self.compiler.find_library_file(["../waste/Static 
Libraries"], "WASTE", )

and eliminate the entire find_library_file function from the setup.py 
file.

2) Is there any reason in particular that fine_file() function returns 
a directory if found on the additional paths parameter? None of the 
setup.py uses of it seem to make any usage of the additional 
information - some - like the lzip library and find_module_name() for 
example just seem to reconstruct the path... from a distutil newbie's 
perspective, it seems like this is a latent bug just waiting to happen 
because a directory was return instead of a path to the file... of 
course it could just be that it then includes the entire directory 
instead....

oooh I need another cup of coffee. ;-)

- Dan



From dkwolfe@pacbell.net  Fri Nov 22 22:03:48 2002
From: dkwolfe@pacbell.net (Dan Wolfe)
Date: Fri, 22 Nov 2002 14:03:48 -0800
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <EA495068-FE24-11D6-881C-0003931CFE24@cistron.nl>
Message-ID: <470A1FCF-FE66-11D6-9C29-003065ABC53C@pacbell.net>

Looks like you're right... there's nothing in the man pages - ld, cc, 
or libtool - that indicates the current linker understands .so files... 
and given that my original objection based on seeing the search pattern 
go from .so, .dylib, .a to .dylib, .a, and the linker not understanding 
.so files, I'll change my position. : -)

I also did a closer review of your non configure file patches, I'd 
hazard a guess that while they're not needed for the ssl problem, we 
are going to need them as they appear to fix problems that we have yet 
to run into...

Have you considered that, by changing the configure file with "Darwin*) 
   SO=.dylib;;" you apparently no longer have to have the dylib blocks 
in unixcompiler.py find_library_file function? with SO = .dylib, it now 
executes the 'shared' block and ignores the 'dylib' block?  It probably 
be a good idea to remove this cruft...

And last, it doesn't look like your patch got uploaded to source forge 
- can you upload it up again?

Thanks for taking the time to convince me,

- Dan


On Friday, November 22, 2002, at 06:15  AM, Ronald Oussoren wrote:

>
> On Friday, Nov 22, 2002, at 08:09 Europe/Amsterdam, Dan Wolfe wrote:
>
>> On the other hand, if you can prove that it's compatible with 
>> everything out there, I'll gladly change my position.
>
> How about this:
>
> - I have a libpng.3.1.2.5.dylib in /opt/local/lib (libpng 1.2.5 
> installed using darwinports)
>
> $ cat t.c says:
> #include "png.h"
>
> int main(void)
> {
>      png_uint_32 v = png_access_version_number();
>
>      printf("Ping version %x\n", (int)v);
> }
> $ cp /opt/local/lib/libpng.3.1.2.5.dylib libpng.so
> $ cc -I /opt/local/include -L. -o t t.c -lpng -lz
> ld: can't locate file for: -lpng
> $ mv libpng.so libpng.dylib
> $ cc -I /opt/local/include -L. -o t t.c -lpng -lz
> $ ./t
> Ping version 27dd
> $
>
> This is on a MacOS 10.2.2 system with the most recent developer tools. 
> The example strongly suggests that the normal compiler and linker do 
> not recognize '.so' as the extension of shared libraries and therefore 
> just changing the shared library extension to '.dylib' should cause no 
> problems.
>
> Greetings,
> 	Ronald
>



From Jack.Jansen@oratrix.com  Fri Nov 22 22:43:26 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 22 Nov 2002 23:43:26 +0100
Subject: [Pythonmac-SIG] Another build question: ssl?
In-Reply-To: <C3D74681-FE4D-11D6-9C29-003065ABC53C@pacbell.net>
Message-ID: <D09F6515-FE6B-11D6-A306-000A27B19B96@oratrix.com>

On vrijdag, nov 22, 2002, at 20:08 Europe/Amsterdam, Dan Wolfe wrote:

> 2) Is there any reason in particular that fine_file() function returns 
> a directory if found on the additional paths parameter? None of the 
> setup.py uses of it seem to make any usage of the additional 
> information - some - like the lzip library and find_module_name() for 
> example just seem to reconstruct the path... from a distutil newbie's 
> perspective, it seems like this is a latent bug just waiting to happen 
> because a directory was return instead of a path to the file... of 
> course it could just be that it then includes the entire directory 
> instead....

This could have been designed in this way with runtime loader search 
paths in mind. On MacOSX this doesn't make a difference (if you give 
the full pathname to the linker it'll find the file at runtime) but it 
may be different on other platforms.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Fri Nov 22 23:21:43 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Fri, 22 Nov 2002 15:21:43 -0800
Subject: [Pythonmac-SIG] On-line help; webbrowser problems
Message-ID: <p05200f05ba0465c9abc8@[128.95.99.44]>

I'm trying to write an on-line help system for a cross-platform (unix 
and MacOS X at least, Windows would also be helpful) Python app. The 
sort of help needed tends to be verbose; tool tips aren't going to be 
useful.

My first thought was to write the help in HTML and use the webbrowser 
module to access it.

Unfortunately, I'm having trouble with webbrowser on MacOS X 10.2. I 
suspect it's intrinsic to limitations in the way the OS tries to do 
things. For example:
   webbrowser.open("file://...html#anchor")  # in Python
% open -a icab file://...html#anchor  # on the command line
open location "file://...html#anchor"  -- AppleScript in the Script Editor
all do the same two wrong things:
- The file is opened in whatever application created it, rather than 
in the default web browser. I can live with this, but it's not good. 
(A pain for users, and a pain for me as I usually have the creator as 
Pepper, my text editor).
- Even if it does open in a web brwoser, the anchor is ignored!!! 
This is nasty, as I don't want a hundred different tiny html files, 
one per help item.

So...any advice would be welcome.

- Any suggestions of a way to open an html file pointing to a given 
anchor within Python? Ideally I'd like the default Internet Config 
browser to be used, but at this point just about anything will do.

I fear I'm looking at learning how to send GetURL apple events from 
within python to a user-chosen browser. The docs suggest I'll need to 
create some sort of apple event dictionary for every possible 
browser, which sounds ghastly.

An alternative is to use a web server (I'm assuming http:// URLs are 
handled correctly). But that sounds horrible. Who'd serve the data? 
And to avoid synch problems, I'd have to keep a help set for every 
version of the software, and my URLs would have to include the 
version #.

- Any suggestions for a better way to do help?

I started out by putting the help text directly in the code. But then 
the help gets displayed in a dialog box of some kind. Modal dialogs 
are pretty gross but easy to do. Non-modal means a lot of clutter, 
unless I use one window and just replace the text when new help is 
requested. But that brings up the issue of navigation (it'll be 
frustrating to have none), which suggests a web browser...sigh.

- Should I report the problem with "open -a" and "open location" as a 
bug? (Anyone know how to report bugs to Apple?).

-- Russell

P.S. in case you've not stumbled across this gem: different browsers 
handle file:// URLs in different ways. Carbon apps (such as iCab) 
tend to favor file://localhost/HardDiskName/path whereas Cocoa apps 
(such as OmniWeb) leave out the hard disk name, making for a 
unix-like path.


From dkwolfe@pacbell.net  Sat Nov 23 05:13:55 2002
From: dkwolfe@pacbell.net (Dan Wolfe)
Date: Fri, 22 Nov 2002 21:13:55 -0800
Subject: [Pythonmac-SIG] ssl success!
In-Reply-To: <p05200f04ba0301471d50@[128.95.99.44]>
Message-ID: <5D02B558-FEA2-11D6-889F-003065ABC53C@pacbell.net>

Not an oddity...

you need to specify -u network on the regression test command.  It's 
not turned by default.

- Dan

On Thursday, November 21, 2002, at 01:36  PM, Russell E Owen wrote:

> One very slight oddity: test_socket_ssl is still skipped for "make 
> test".



From Jack.Jansen@oratrix.com  Sat Nov 23 12:42:28 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sat, 23 Nov 2002 13:42:28 +0100
Subject: [Pythonmac-SIG] On-line help; webbrowser problems
In-Reply-To: <p05200f05ba0465c9abc8@[128.95.99.44]>
Message-ID: <068F35B8-FEE1-11D6-B8D0-000A27B19B96@oratrix.com>

On zaterdag, nov 23, 2002, at 00:21 Europe/Amsterdam, Russell E Owen 
wrote:

> I'm trying to write an on-line help system for a cross-platform (unix 
> and MacOS X at least, Windows would also be helpful) Python app. The 
> sort of help needed tends to be verbose; tool tips aren't going to be 
> useful.
>
> My first thought was to write the help in HTML and use the webbrowser 
> module to access it.
>
> Unfortunately, I'm having trouble with webbrowser on MacOS X 10.2. I 
> suspect it's intrinsic to limitations in the way the OS tries to do 
> things.

First of all: if you've installed the Mac-specific stuff then 
webbrowser should use Internet Config to open your URL. This way, the # 
bit and such should work. First thing to find out is why it doesn't use 
Internet Config, try what "import ic" does for you.

Second, for me it does use Internet Config, but it still doesn't work 
(I get a strange error from IC: "PathTooLongErr". I will investigate 
this.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From owen@astro.washington.edu  Mon Nov 25 16:52:58 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Mon, 25 Nov 2002 08:52:58 -0800
Subject: [Pythonmac-SIG] Re: On-line help; webbrowser problems
Message-ID: <p05200f00ba07fb3cb28d@[128.95.99.44]>

I reported that I could not get file://...#anchor URLs (such as 
"file:///Users/rowen/PythonRO/TUI/TUIHelp/Telescope.html#skywidget" 
or 
"file://localhost/Users/rowen/PythonRO/TUI/TUIHelp/Telescope.html#skywidget") 
to open in a web browser. I tried the webbrowser package, the "open 
location <url>" applescript and "open -a <browser> <url>" in the 
command line and all did the same thing:
- opened the file in its original creator (which might be a text 
editor or a browser, but is not the favored browser in Internet 
settings).
- ignored the #anchor portion of <url>.

Jack Jansen (I believe; I can't get to the mail right now) suggested 
I try the ic module. I actually had already found that on Friday 
after I posted my message (in the process of trying to learn how to 
send applescript commands directly to a web browser--something I'm 
still looking into). Unfortunately, ic.launchurl(<url>) works the 
same as all the other solutions. MacOS seems hell-bent on treating 
file://...#anchor as opening a file as if from Finder, rather than 
telling a browser to open a file and passing it the #anchor. 
Consistency is good, but clearly it can be overdone.

Any suggestions on workarounds or alternate ways to convince a 
browser to open a file at a particular anchor (thus avoiding the need 
for a web server)?

Other ideas include:
- modify pydoc to serve the data; at least that web server is built 
in and preconfigured (I've only looked very briefly into this)
- implement on-line help in some entirely different way (such pity to 
have to recreate or lose all the great HTML navigation)
- use applescript to talk directly to a user-specified browser. I'm 
sure this would work, but not sure if I can make it tolerably 
maintainable (apparently I'll have to create an apple event 
dictionary object for any browser my users may want to use, which 
sounds like a pain)

-- Russell


From loredo@astrosun.astro.cornell.edu  Mon Nov 25 17:56:15 2002
From: loredo@astrosun.astro.cornell.edu (Tom Loredo)
Date: Mon, 25 Nov 2002 12:56:15 -0500 (EST)
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1289 - 1 msg
Message-ID: <200211251756.gAPHuFI00735@laplace.astro.cornell.edu>

Thanks for the streaming link---I'll have to try that at home!

-TL


From Jack.Jansen@cwi.nl  Tue Nov 26 10:29:56 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 26 Nov 2002 11:29:56 +0100
Subject: [Pythonmac-SIG] Re: On-line help; webbrowser problems
In-Reply-To: <p05200f00ba07fb3cb28d@[128.95.99.44]>
Message-ID: <01E2D363-012A-11D7-9731-0030655234CE@cwi.nl>

On Monday, Nov 25, 2002, at 17:52 Europe/Amsterdam, Russell E Owen 
wrote:
> Any suggestions on workarounds or alternate ways to convince a browser 
> to open a file at a particular anchor (thus avoiding the need for a 
> web server)?

Send the AppleEvent to the browser yourself, using the OpenURL() 
appleevent. You can find this in both the Explorer and the Netscape 
suite, so either of
import Netscape
x = Netscape.Netscape(start=1)
x.OpenURL(url)
or the same with Explorer will work. And you can pass a 
signature="MOSS" argument to the Netscape.Netscape call to start a 
different webbrowser.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From blhscomputerprogramming@yahoo.com  Tue Nov 26 16:11:22 2002
From: blhscomputerprogramming@yahoo.com (BLHS)
Date: Tue, 26 Nov 2002 08:11:22 -0800 (PST)
Subject: [Pythonmac-SIG] Beginners Questions
Message-ID: <20021126161122.21990.qmail@web13207.mail.yahoo.com>

Hello, I am a teaching MacPython to 11th and 12th
graders.  This is my first year teaching it, or any
programming class.  I am very happy with what we have
been able to do with python, but would like to do
more!  Currently most students are working with Mac OS
9.1, MacPython v. 2.2.1.  I would like do more with
graphics and just the appearance of the output(GUI's).
 What do I need to do to get Tkinter to work? or is it
possible to use pygame or something similar?  Also, if
all the students were using OS X, would we be better
off?
Thanks,  Angela Blank


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


From owen@astro.washington.edu  Tue Nov 26 17:37:23 2002
From: owen@astro.washington.edu (Russell E Owen)
Date: Tue, 26 Nov 2002 09:37:23 -0800
Subject: [Pythonmac-SIG] Beginners Questions
Message-ID: <p05200f07ba095a27f1d3@[128.95.99.44]>

Angela Blank wrote:

>...Currently most students are working with Mac OS 9.1, MacPython v. 
>2.2.1.  I would like do more with graphics and just the appearance 
>of the output(GUI's).
>  What do I need to do to get Tkinter to work? or is it possible to 
>use pygame or something similar?  Also, if all the students were 
>using OS X, would we be better off?

I think you can still get Tkinter working under MacOS 9 using the 
classic version of the interpreter (but definitely NOT the carbon 
version!). It has some limitations (Menus are somewhat broken; file 
events definitely are broken, which is only an issue if you are doing 
networked GUIs).

For now this is probably your best best. When Python 2.3 is 
available, I suggest you consider switching to MacOS X. Python 
already runs pretty well on OS X, but installation is difficult, it 
cannot read files with Mac line endings, and things are still 
evolving (including the aqua version of Tk). OS X has some 
advantages, including:
- unix, always a good thing to teach programmers
- a command line with readline support (command history)
- it can wxPython (a nice competitor to the Tkinter GUI package)
- it can probably run significantly more 3rd party Python packages than MacOS 9

I don't know about pygame, though I believe it was discussed on the 
list awhile back (to Those in the Know: is there a searchable version 
of the mailing list archives? All I've seen is the ability to look at 
a month at a time).

-- Russell

P.S. This is radically off-topic, but if GUI is an issue, another 
option is teaching Smalltalk. Squeak (free, includes the wonderful 
Morphic graphical environment) and VisualWorks (very solid and 
polished; the NC version is free) both run well on MacOS. It's a 
language that shares many strengths with Python (including 
simplicity, power and an excellent implementation of objects), the 
GUI is totally integrated and the development environment is first 
rate (editor, brwoser, debugger and object inspectors are always 
instantly available).


From njriley@uiuc.edu  Tue Nov 26 19:39:31 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Tue, 26 Nov 2002 13:39:31 -0600
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
Message-ID: <20021126193931.GB2710512@uiuc.edu>

Hi,

I just tried following the Python installation instructions here:

<http://www.astro.washington.edu/owen/InstallingPythonOnJaguar.html>

I had many problems, some of which I was able to overcome.

- I needed to use the CVS Tcl/Tk build instructions the page linked to
instead of yours.  The Tcl and Tk source directories needed to be
renamed 'tcl' and 'tk' in order for the installation process to work
correctly, otherwise it dies while building HTML documentation.

- There are 'chmod's in the project file script which expects the
Apple-supplied chmod instead of the GNU chmod I had in my path; it
should be changed to '/bin/chmod' in the project.pbxproj files.

- After fixing the above, I still couldn't get a functional Tcl/Tk
installation:

[p3:5147] ~/src%tclsh
application-specific initialization failed: Can't find a usable init.tcl in the following directories:
    @TCL_IN_FRAMEWORK@ /usr/lib/tcl8.4 /lib/tcl8.4 /usr/library
    /library /tcl8.4a5/library @TCL_IN_FRAMEWORK@

I found this problem documented:

<http://www.geocrawler.com/archives/3/7933/2002/7/0/9107415/>

I didn't understand the proposed resolutions in that mailing list
thread, so I gave up on the source and installed TclTkAqua 8.4.1
binary distribution from here:

<http://prdownloads.sourceforge.net/tcl/TclTkAqua-8.4.1.dmg?download>

This is a really nicely put-together installer which worked in about 5
seconds (modulo prebinding :) and seems to include everything I need.

The remainder of the installation went as described, but the 'python'
and 'pythonw' programs were both broken in different ways with respect
to module loading and Tk.

If I run python.exe directly from the build tree, Tk works, except for
the window activation problems:

[p6:5153] ~/src/Python-2.2.2%./python.exe
Python 2.2.2 (#6, Nov 26 2002, 12:39:08)
[GCC 3.1 20020105 (experimental)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
>>> x = Tk()
>>> RCNE SendEventToEventTarget (Caml 1                   ) failed, -128
[a window appears]

But running python from the framework doesn't work:

[p6:5154] ~/src/Python-2.2.2%python
in sitecustomize.py
Python 2.2.2 (#6, Nov 26 2002, 12:39:08)
[GCC 3.1 20020105 (experimental)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/lib-tk/Tkinter.py", line 35, in ?
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter

And pythonw gives me even stranger messages:

[p6:5155] ~/src/Python-2.2.2%pythonw
original argc=1
original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
modified argc=1
modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
Python 2.2.2 (#6, Nov 26 2002, 12:39:08)
[GCC 3.1 20020105 (experimental)] on darwin
Type "copyright", "credits" or "license" for more information.
in sitecustomize.py
>>> from Tkinter import *
LookupError: no codec search functions registered: can't find encoding
>>> x = Tk()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'Tk' is not defined
>>> import sys
>>> sys.path
['', '/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2', '/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/plat-darwin', '/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/lib-tk', '/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/lib-dynload', '/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site-packages', '/Library/Frameworks/Python.framework/Versions/2.2/Mac/Lib']

Everything looks to be OK with the path; any ideas as to what is
wrong?

Thanks,

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From Jack.Jansen@oratrix.com  Tue Nov 26 22:37:41 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Tue, 26 Nov 2002 23:37:41 +0100
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <20021126193931.GB2710512@uiuc.edu>
Message-ID: <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com>

Nicholas,
can you try running pythonw outside of the build directory and report 
your findings back? It could be that something goes wrong because the 
algorithm that finds sys.path knows about the build directory.

The error about the codec search function is very weird, has anyone 
else seen anything like it?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From njriley@uiuc.edu  Wed Nov 27 00:08:20 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Tue, 26 Nov 2002 18:08:20 -0600
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com>
References: <20021126193931.GB2710512@uiuc.edu> <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com>
Message-ID: <20021127000820.GA2808351@uiuc.edu>

On Tue, Nov 26, 2002 at 11:37:41PM +0100, Jack Jansen wrote:
> can you try running pythonw outside of the build directory and report 
> your findings back? It could be that something goes wrong because the 
> algorithm that finds sys.path knows about the build directory.

Sorry, I should have mentioned that.  It does the same thing.

> The error about the codec search function is very weird, has anyone 
> else seen anything like it?

Thanks for suggesting that I take another look at this; I've found the
problem!

>From searching Google with the text of the error message it appears
'import codecs' is necessary.  Here's what happened when I ran it with
each of the three Pythons (build dir python.exe, python, pythonw):

python.exe: 
>>> import codecs
>>> codecs
<module 'codecs' from '/Users/nicholas/src/Python-2.2.2/Lib/codecs.py'>

python:
>>> import codecs
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/codecs.py", line 10, in ?
    import struct, __builtin__
ImportError: No module named struct

pythonw:
>>> import codecs
LookupError: no codec search functions registered: can't find encoding

The second example gave me a clue.  It was a permissions problem;
struct.so was installed like this:

  -rwx--x--x    1 root     admin         61k Nov 26 12:39 struct.so*

After fixing the permissions, codecs and Tk in pythonw work properly.
Hooray!

What needs fixing in Python, IMO, is:

- The permissions on installed files in lib/dynload should be properly
  set.  Perhaps it picked up my umask, which is 077?  But then they'd
  be rwx------, so I don't know...).  Using the 'install' program to
  install files is usually the right way to do this, as it uses
  rwxr-xr-x by default.

  I did a 'find . -perm 711' in Python.framework and the only other
  file I found outside lib/dynload that had the wrong permissions was
  pydoc.

- "no module named struct" should be distinguished from "can't access
  struct module to import it".

- In the third case of pythonw, the import error was somehow
  suppressed; it should be displayed.  If it were, the resultant
  error would not be so cryptic.

Now onto fixing metakit's native code module, which somehow outputs a
.dylib (shared lib) instead of a .so (bundle)...

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From Jack.Jansen@cwi.nl  Wed Nov 27 09:40:17 2002
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 27 Nov 2002 10:40:17 +0100
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <20021127000820.GA2808351@uiuc.edu>
Message-ID: <3C8D3C34-01EC-11D7-B74D-0030655234CE@cwi.nl>

On Wednesday, Nov 27, 2002, at 01:08 Europe/Amsterdam, Nicholas Riley 
wrote:

> The second example gave me a clue.  It was a permissions problem;
> struct.so was installed like this:
>
>   -rwx--x--x    1 root     admin         61k Nov 26 12:39 struct.so*
>
> After fixing the permissions, codecs and Tk in pythonw work properly.
> Hooray!
>
> What needs fixing in Python, IMO, is:
>
> - The permissions on installed files in lib/dynload should be properly
>   set.  Perhaps it picked up my umask, which is 077?  But then they'd
>   be rwx------, so I don't know...).  Using the 'install' program to
>   install files is usually the right way to do this, as it uses
>   rwxr-xr-x by default.

Could you check that you can reproduce this (i.e. if umask is 077 you 
get rwx--x--x files and
if umask is, say, 022, you get rwxr-xr-x)? If so, post a sourgeforge 
bug report on this, please.
I'll have to investigate what goes on, and whether it's MacOSX-specific 
and whether we want to fix it.

> - "no module named struct" should be distinguished from "can't access
>   struct module to import it".

That's difficult. After the import failed (due to the file being 
unreadable) import will continue
looking in other sys.path entries, so by the time it gets to the end it 
will have forgotten
about any intermediate errors.

Have you tried what "python -v" and "python -vv" report in this case?
>
> - In the third case of pythonw, the import error was somehow
>   suppressed; it should be displayed.  If it were, the resultant
>   error would not be so cryptic.

Agreed. I'd also be interested in the python -vv output of this.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From mwh@python.net  Wed Nov 27 10:21:15 2002
From: mwh@python.net (Michael Hudson)
Date: 27 Nov 2002 10:21:15 +0000
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: Nicholas Riley's message of "Tue, 26 Nov 2002 18:08:20 -0600"
References: <20021126193931.GB2710512@uiuc.edu> <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com> <20021127000820.GA2808351@uiuc.edu>
Message-ID: <2mk7izmhyc.fsf@starship.python.net>

Nicholas Riley <njriley@uiuc.edu> writes:

> What needs fixing in Python, IMO, is:
> 
> - The permissions on installed files in lib/dynload should be properly
>   set.  Perhaps it picked up my umask, which is 077?  But then they'd
>   be rwx------, so I don't know...).  Using the 'install' program to
>   install files is usually the right way to do this, as it uses
>   rwxr-xr-x by default.

There's a patch on sf about this.  It'll get fixed (hopefully within a
few weeks).

>   I did a 'find . -perm 711' in Python.framework and the only other
>   file I found outside lib/dynload that had the wrong permissions was
>   pydoc.

pydoc had rwx--x--x?  That seems surprising.

> - "no module named struct" should be distinguished from "can't access
>   struct module to import it".

Patches welcome :)

Cheers,
M.

-- 
  I don't remember any dirty green trousers.
                                             -- Ian Jackson, ucam.chat


From daniellord@telocity.com  Wed Nov 27 21:36:02 2002
From: daniellord@telocity.com (Daniel Lord)
Date: Wed, 27 Nov 2002 13:36:02 -0800
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
Message-ID: <3A1003E0-0250-11D7-9814-003065D5C90C@telocity.com>

Here is an example of what we'd all like to see from the Mac Python  
Community (those Perl folks are way ahead of us):

http://www.macdevcenter.com/pub/a/mac/2002/11/22/itunes_perl.html

And, as the saying goes, if you want it done--do it yourself. Okay I  
will--I have the time to learn and document and I will. But..
I need some help and pointers first:
1) I have a framework install of Python-2.2.2 and AquaTk on 10.2.1 but
I get simple errors even after hand-copying the Mac/Lib modules  
(including lib-scriptpackages) See ERROR 1 below for an example.

2) osam looks interesting but...the project file is corrupted so I  
don't have a template of what to include to build it. Any docs any  
where?

3) Is any of this fixed in 2.3a0--I retrieved it from CVS yesterday but  
hesitate to install it and ruin my framework install or,
  worse yet, pester you all with defects I induced by doing that.

4) Jack wrote message about installing MacPython innocuously over a  
framework install. Before I do this, does it work for 2.3a0?

5) any other docs, examples, etc. on how to use Applescript with  
Python--send me a pointer please.

ERROR 1
========
[anduril:~/Learning/python/Applescript] daniello% pythonw  
codewarrior1.py
original argc=2
original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
original argv[1] = "codewarrior1.py"
modified argc=2
modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
modified argv[1] = "codewarrior1.py"
running sitecustomize.py
Traceback (most recent call last):
   File "codewarrior1.py", line 1, in ?
     import CodeWarrior
   File  
"/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site- 
packages/CodeWarrior/__init__.py", line 5, in ?
     import aetools
   File  
"/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site- 
packages/aetools.py", line 31, in ?
     from aepack import pack, unpack, coerce, AEDescType
   File  
"/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site- 
packages/aepack.py", line 61, in ?
     _sample_fss = macfs.FSSpec(':')
MacOS.Error: (-43, 'File not found')

** I think Jack Jansen commented about this in a thread, but I cannot  
find the fix now.



From daniellord@telocity.com  Thu Nov 28 07:00:46 2002
From: daniellord@telocity.com (Daniel Lord)
Date: Wed, 27 Nov 2002 23:00:46 -0800
Subject: [Pythonmac-SIG] CVS compile error: bz2 --> out of date; rerun ranlib(1) (can't load from it)
Message-ID: <1E66CF1D-029F-11D7-BDDE-003065D5C90C@telocity.com>

Anybody,

I got the error below and it says to run ranlib (which I thought was 
superceded on OSX by libtool so that's what I'd use). But I don't know 
exactly what options to give libtool and reading the voluminous man 
page didn't clear it up. Anybody care to give me a hint? I've been 
trying to figure out how to compile a simple C extension to python as a 
dynamic library and cannot get that to work with libtool either.

building 'bz2' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double 
-no-cpp-precomp -fno-common -dynamic -I. 
-I/usr/local/src/python/dist/src/./Include 
-I/usr/local/src/python/dist/src/./Mac/Include -I/usr/local/include 
-I/usr/local/src/python/dist/src/Include 
-I/usr/local/src/python/dist/src -c 
/usr/local/src/python/dist/src/Modules/bz2module.c -o 
/usr/local/src/python/dist/src/Modules/bz2module.o
cc1: warning: changing search order for system directory 
"/usr/local/include"
cc1: warning:   as it has already been specified as a non-system 
directory
gcc -Wl,-F. -bundle -framework Python 
/usr/local/src/python/dist/src/Modules/bz2module.o -L/usr/local/lib 
-lbz2 -o build/lib.darwin-6.2-Power Macintosh-2.3/bz2.so
ld: table of contents for archive: /usr/lib/libbz2.a is out of date; 
rerun ranlib(1) (can't load from it)

Cheers,
Daniel



From brian_l@mac.com  Thu Nov 28 08:03:48 2002
From: brian_l@mac.com (Brian Lenihan)
Date: Thu, 28 Nov 2002 00:03:48 -0800
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <3A1003E0-0250-11D7-9814-003065D5C90C@telocity.com>
Message-ID: <EC9CA634-02A7-11D7-9180-003065F88956@mac.com>

On Wednesday, November 27, 2002, at 01:36  PM, Daniel Lord wrote:

I'm in the middle of packing, so I'll have to make this brief.

> 2) osam looks interesting but...the project file is corrupted so I 
> don't have a template of what to include to build it. Any docs any 
> where?

My advice is to forget about osam.  It was written as part of our 
internal build system (which is now named ribosome and available at 
helixcommunity.org) and we stopped using it in favor of 
osascript/osacompile.  If you really want osam, we can probably send 
you an updated version, albeit with a CW7 project file.

The man pages for osacompile and osascript should get you headed in the 
right direction.

> 3) Is any of this fixed in 2.3a0--I retrieved it from CVS yesterday 
> but hesitate to install it and ruin my framework install or,
>  worse yet, pester you all with defects I induced by doing that.

If you want to use AquaTK, you will find the going much easier with 
2.3a0, although there are plenty of pointers in the archives for using 
AquaTk with 2.2.x.



From Jack.Jansen@oratrix.com  Thu Nov 28 10:20:07 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 28 Nov 2002 11:20:07 +0100
Subject: [Pythonmac-SIG] CVS compile error: bz2 --> out of date; rerun ranlib(1) (can't load from it)
In-Reply-To: <1E66CF1D-029F-11D7-BDDE-003065D5C90C@telocity.com>
Message-ID: <F7E7B257-02BA-11D7-83AC-000A27B19B96@oratrix.com>

On donderdag, nov 28, 2002, at 08:00 Europe/Amsterdam, Daniel Lord 
wrote:
> ld: table of contents for archive: /usr/lib/libbz2.a is out of date; 
> rerun ranlib(1) (can't load from it)

This is happening to me too, and also for some other Apple-shipped 
libraries. Fortunately the fix is to do just what the error message 
says: run "sudo ranlib /usr/lib/libbz2.a" to fix it.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Thu Nov 28 10:27:09 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 28 Nov 2002 11:27:09 +0100
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <3A1003E0-0250-11D7-9814-003065D5C90C@telocity.com>
Message-ID: <F311FAFA-02BB-11D7-83AC-000A27B19B96@oratrix.com>

On woensdag, nov 27, 2002, at 22:36 Europe/Amsterdam, Daniel Lord wrote:

> Here is an example of what we'd all like to see from the Mac Python  
> Community (those Perl folks are way ahead of us):
>
> http://www.macdevcenter.com/pub/a/mac/2002/11/22/itunes_perl.html
>
> And, as the saying goes, if you want it done--do it yourself. Okay I  
> will--I have the time to learn and document and I will. But..
> I need some help and pointers first:
> 1) I have a framework install of Python-2.2.2 and AquaTk on 10.2.1 but
> I get simple errors even after hand-copying the Mac/Lib modules  
> (including lib-scriptpackages) See ERROR 1 below for an example.
>
> 2) osam looks interesting but...the project file is corrupted so I  
> don't have a template of what to include to build it. Any docs any  
> where?

Osam is really a stopgap. The preferred way to control OSA applications  
from Python is to use the fullblown OSA interface, this gives you  
complete access to all features from Python, in a "pythonic" way.  
Unfortunately you first have to create the interface module for the  
specific program you want to control. This is done with  
Mac/scripts/gensuitemodule.py. For some common applications the suites  
are pre-generated, you'll find these in Mac/Lib/lib-scriptpackages.

There is some minimal documentation, see Mac/Demo/applescript.html.

>
> 3) Is any of this fixed in 2.3a0--I retrieved it from CVS yesterday  
> but hesitate to install it and ruin my framework install or,
>  worse yet, pester you all with defects I induced by doing that.

Actually, I would guess that the mac-specific stuff in 2.3a0 may well  
be more stable than that in 2.2.X.

> 4) Jack wrote message about installing MacPython innocuously over a  
> framework install. Before I do this, does it work for 2.3a0?

If you mean "MacPython 2.2.X", i.e. the version that also runs on OS9:  
this version is indeed 100% separate from either the framework or  
non-framework unix-install.

> 5) any other docs, examples, etc. on how to use Applescript with  
> Python--send me a pointer please.

Apart from the things mentioned above, also look at  
Mac/Lib/findertools, or Mac/Lib/mkcwproject for examples that use the  
OSA stuff.

> ERROR 1
> ========
> [anduril:~/Learning/python/Applescript] daniello% pythonw  
> codewarrior1.py
> original argc=2
> original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
> original argv[1] = "codewarrior1.py"
> modified argc=2
> modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
> modified argv[1] = "codewarrior1.py"
> running sitecustomize.py
> Traceback (most recent call last):
>   File "codewarrior1.py", line 1, in ?
>     import CodeWarrior
>   File  
> "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site- 
> packages/CodeWarrior/__init__.py", line 5, in ?
>     import aetools
>   File  
> "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site- 
> packages/aetools.py", line 31, in ?
>     from aepack import pack, unpack, coerce, AEDescType
>   File  
> "/Library/Frameworks/Python.framework/Versions/2.2/lib/python2.2/site- 
> packages/aepack.py", line 61, in ?
>     _sample_fss = macfs.FSSpec(':')
> MacOS.Error: (-43, 'File not found')

That's a bug that's fixed in 2.3a0. The quick workaround is to change  
the ':' to os.curdir.

If you want this fixed in 2.2.3 please submit a sourceforge bugreport  
so I won't forget.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>         
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma  
Goldman -



From mjb@uma.pt  Thu Nov 28 11:40:18 2002
From: mjb@uma.pt (Michael J. Barber)
Date: Thu, 28 Nov 2002 11:40:18 +0000
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <F311FAFA-02BB-11D7-83AC-000A27B19B96@oratrix.com>
Message-ID: <2BEC5739-02C6-11D7-93C6-0050E4794D0F@uma.pt>

On Thursday, November 28, 2002, at 10:27  AM, Jack Jansen wrote:

>
> On woensdag, nov 27, 2002, at 22:36 Europe/Amsterdam, Daniel Lord wrote:
>
>> [Daniel wants to script iTunes]
> Osam is really a stopgap. The preferred way to control OSA 
> applications  from Python is to use the fullblown OSA interface, this 
> gives you  complete access to all features from Python, in a "pythonic" 
> way.  Unfortunately you first have to create the interface module for 
> the  specific program you want to control. This is done with  
> Mac/scripts/gensuitemodule.py. For some common applications the suites  
> are pre-generated, you'll find these in Mac/Lib/lib-scriptpackages.
>
> There is some minimal documentation, see Mac/Demo/applescript.html.
>
I would like very much to agree with this suggestion, but I just tried 
it out and gensuitemodule doesn't let me select iTunes as a "package 
generation target." This is MacPython 2.2.1, more recent versions may 
work. I ran into exactly this problem when trying to come up with a 
replacement example for the documentation that Jack mentions. It seems 
that the Mac OS X package structure interferes with gensuitemodule in a 
way that I don't understand. I don't know whether this should be viewed 
as a bug, or just a sign of limited understanding on my part.

Daniel, hopefully you won't have this problem, but if you do, it's well 
worth taking a look at how the packages are set up in one of the 
existing OSA packages (maybe for the Finder, it's got a rich enough 
structure to show some of the potential problems). The automatically 
generated OSA interfaces are a good model for what you will want to do.

>> 5) any other docs, examples, etc. on how to use Applescript with  
>> Python--send me a pointer please.
>
> Apart from the things mentioned above, also look at  
> Mac/Lib/findertools, or Mac/Lib/mkcwproject for examples that use the  
> OSA stuff.
>
I'll second this suggestion without reservations! The approach taken in 
findertools seems to be the most common one for OSA scripting from 
python: do as much in Python as possible, and only use OSA when you 
really need to communicate with another application. The functions in 
findertools are also pretty short and easy to understand.

Other sources:
The archives for this list. There have been periodic discussions of 
AppleScript/OSA on the mailing list. There was a discussion in January 
which I learned quite a lot from, and a more recent discussion in 
August. There have been others, too; I just happen to know when those 
two took place, because I took part in the discussions.

I have an example for OSAm that I provided in response to a list message 
with the subject 'Determining the name of the "root" drive (startup 
disk)'. You need to adjust your path to include the OSAm module, and 
using 'dir' is probably the easiest way to find out what functions 
you've got available.
Python 2.2.1 (#134, Apr  9 2002, 21:16:52)  [CW CARBON GUSI2 THREADS GC]
Type "copyright", "credits" or "license" for more information.
MacPython IDE 1.0.1
 >>> import OSAm
 >>> OSAm.CompileAndExecute('tell app "Finder" to return the name of the 
startup disk')
'"Macintosh HD"'
 >>>

Finally, I'd like to make a suggestion for Daniel and anyone else who 
takes part in this project: document what you're doing and turn it into 
a tutorial. I struggled when learning how to do OSA scripting from 
Python, others have said that they struggled, and I've seen the painful 
learning process that at least one person has gone through on this 
mailing list. Python is a lot nicer than AppleScript for OSA scripting, 
but it's pretty hard to get started. In my opinion, this is in part due 
to the small number of examples.



From daniellord@telocity.com  Thu Nov 28 14:01:07 2002
From: daniellord@telocity.com (Daniel Lord)
Date: Thu, 28 Nov 2002 06:01:07 -0800
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <2BEC5739-02C6-11D7-93C6-0050E4794D0F@uma.pt>
Message-ID: <D724A3EF-02D9-11D7-BDDE-003065D5C90C@telocity.com>

Thank you all--I have my advice and pointers and I am off. I will 
document my successes and the list will hear about the road blocks 
along the way. I actually put iTunes down on my list ranked by priority 
behind scripting Mail and Address Book to do interesting things like 
archiving mail in MySQL and writing a common format XML for Address 
book one might use XLT with to print nicely formatted address list and 
books and to allow people with Exchange address books at work to 
synchronize them with their address books on OS X at home, etc., etc.

Perhaps I am biased, but I prefer the object-oriented core and base of 
Python and it's readability and extensibility (look at Jython as an 
example) over arcane, inconsistent, non-orthongonal, idiosyncratic 
listing processing Perl (told you I was biased ;-). Perl's richest 
asset is the availability of copious documentation and CPAN and, 
conversely, the lack of an analog for Python is Python's poorest asset 
and greatest inhibitor to widespread adoption (although ActiveState's 
Cookbook is helping despite its obvious Windows slant). Perl has 
stretched beyond it's intentions or design (like adding pseudo OOP) 
because access to a evolutionary language has been limited. It is my 
personal belief that, although Python has been mostly successful on it 
merits alone, its adoption has been slowed by a access barriers 
including a lack of documentation and repositories such as CPAN. 
Perhaps I can help in a small way on OS X. Python OSA is what Apple 
should have done before they created Applescript IMHO. Imagine the 
system and applications administration possibilities. Oh well, back to 
Earth and the reality distortion field.

And as Michael Barber said and it is worth repeating and remembering:
> Finally, I'd like to make a suggestion for Daniel and anyone else who 
> takes part in this project: document what you're doing and turn it 
> into a tutorial. I struggled when learning how to do OSA scripting 
> from Python, others have said that they struggled, and I've seen the 
> painful learning process that at least one person has gone through on 
> this mailing list. Python is a lot nicer than AppleScript for OSA 
> scripting, but it's pretty hard to get started. In my opinion, this is 
> in part due to the small number of examples.

Michael, I intend to work on it.  Guido, Jack, and Just and so many 
others are busy adding to Python, so some of us need to start adding to 
it's application and documentation. And, of course, I will write it up 
for what it's worth.

P.S. And BTW, can the SIG archives be setup so they are searchable on 
line? That would have saved me from mailing all of you with these 
questions.

Daniel Lord
--
daniellordATtelocityDOTcom                                             
"My  dancing, drinking, and singing weave me the mat
GPG Fingerprint: C59E 59F5 1C63 5CFB 6161  067E FF00 A4E8 684A 16BB    
upon which my soul will sleep in the world of spirits"
                                                                         
                   -- Old Man of Halmahera, Indonesia



From mwh@python.net  Thu Nov 28 16:04:16 2002
From: mwh@python.net (Michael Hudson)
Date: 28 Nov 2002 16:04:16 +0000
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: Daniel Lord's message of "Thu, 28 Nov 2002 06:01:07 -0800"
References: <D724A3EF-02D9-11D7-BDDE-003065D5C90C@telocity.com>
Message-ID: <2my97d3clb.fsf@starship.python.net>

Daniel Lord <daniellord@telocity.com> writes:

> P.S. And BTW, can the SIG archives be setup so they are searchable on 
> line? That would have saved me from mailing all of you with these 
> questions.

ActiveState have quite a nice mailing list archive interface:

http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/pythonmac-sig

Or there's gmane:

http://news.gmane.org/thread.php?group=gmane.comp.python.apple    
news://news.gmane.org/gmane.comp.python.apple

(which seems to have all the archives).  Or you can download the
entire history of the pythonmac-sig:

http://mail.python.org/pipermail/pythonmac-sig.mbox/pythonmac-sig.mbox

and use grepmail or whatever.

HTH,
M.

-- 
  One of the great skills in using any language is knowing what not
  to use, what not to say.  ... There's that simplicity thing again.
                                                       -- Ron Jeffries


From Jack.Jansen@oratrix.com  Thu Nov 28 20:23:27 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Thu, 28 Nov 2002 21:23:27 +0100
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <2BEC5739-02C6-11D7-93C6-0050E4794D0F@uma.pt>
Message-ID: <40BD90E4-030F-11D7-83AC-000A27B19B96@oratrix.com>

On donderdag, nov 28, 2002, at 12:40 Europe/Amsterdam, Michael J. 
Barber wrote:

> On Thursday, November 28, 2002, at 10:27  AM, Jack Jansen wrote:
>
>>
>> On woensdag, nov 27, 2002, at 22:36 Europe/Amsterdam, Daniel Lord 
>> wrote:
>>
>>> [Daniel wants to script iTunes]
>> Osam is really a stopgap. The preferred way to control OSA 
>> applications  from Python is to use the fullblown OSA interface, this 
>> gives you  complete access to all features from Python, in a 
>> "pythonic" way.  Unfortunately you first have to create the interface 
>> module for the  specific program you want to control. This is done 
>> with  Mac/scripts/gensuitemodule.py. For some common applications the 
>> suites  are pre-generated, you'll find these in 
>> Mac/Lib/lib-scriptpackages.
>>
>> There is some minimal documentation, see Mac/Demo/applescript.html.
>>
> I would like very much to agree with this suggestion, but I just tried 
> it out and gensuitemodule doesn't let me select iTunes as a "package 
> generation target."

Try selecting the file iTunes.app/Contents/Resources/iTunes.rsrc. Some 
OSX applications have their AETE resource in there (Terminal is an 
example). Some other apps, however, have no AETE resource, but in stead 
have their applescript dictionaries encoded in plist files. At the 
moment you are out of luck if you want to script one of these.

If I understand things correctly, however, there should be a API call 
to get the AETE resource of a given application (or maybe present the 
user with a dialog allowing selection of such an app, and then getting 
its AETE), either from the file or from a running process. If anyone 
knows how this works: please explain.
I assume this is somewhat like the dialog Script Editor shows when you 
ask it to open a dictionary.

Or, even better, adapt gensuitemodule to use this method to get at the 
AETE (I have enough on my plate, really).
> --
- Jack Jansen        <Jack.Jansen@oratrix.com>        
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@oratrix.com  Thu Nov 28 23:11:26 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Fri, 29 Nov 2002 00:11:26 +0100
Subject: [Pythonmac-SIG] Warning: incompatible change in 2.3a0
Message-ID: <B850E454-0326-11D7-83AC-000A27B19B96@oratrix.com>

Folks,
I'm about to check in an incompatible change in the CVS trunk for users 
of Carbon.Qd: no longer will direct access to attributes of grafports 
be allowed, only the accessor functions will work. Also, the 
Carbon.Qd.qd object, the Quickdraw global variables, will disappear and 
you will have to use the accessor functions here also. To give an 
example, in stead of "port.bounds" you'll have to use 
"port.GetPortBounds()", and in stead of "Carbon.Qd.qd.arrow" you'll 
have to use "Carbon.Qd.GetQDGlobalsArrow()".

If this causes major inconvenience: clamor loudly and I'll try to 
create a workaround. But I would rather not: the accessor functions 
have been required for C programmers since Carbon, and using them will 
make Python code more readable with the Apple documentation in hand.

And, Just, don't worry: I've converted the IDE and the Lib directory to 
use accessor functions already, I'll check that in before I check in 
the incompatible change.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -



From njriley@uiuc.edu  Fri Nov 29 00:37:28 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Thu, 28 Nov 2002 18:37:28 -0600
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <3C8D3C34-01EC-11D7-B74D-0030655234CE@cwi.nl>
References: <20021127000820.GA2808351@uiuc.edu> <3C8D3C34-01EC-11D7-B74D-0030655234CE@cwi.nl>
Message-ID: <20021129003728.GA2790563@uiuc.edu>

On Wed, Nov 27, 2002 at 10:40:17AM +0100, Jack Jansen wrote:
> That's difficult. After the import failed (due to the file being
> unreadable) import will continue looking in other sys.path entries,
> so by the time it gets to the end it will have forgotten about any
> intermediate errors.

Yeah, there'd have to be some kind of error accumulation buffer.  I'd
love to work on this but don't have the time...

> Have you tried what "python -v" and "python -vv" report in this case?

I don't see any messages that make it appear as if an error occurs.
Since there's apparently a bug report on this, I'm hopeful it'll be
fixed.
 
> >- In the third case of pythonw, the import error was somehow
> >  suppressed; it should be displayed.  If it were, the resultant
> >  error would not be so cryptic.
> 
> Agreed. I'd also be interested in the python -vv output of this.

I can't use python -vv because the launcher won't accept it.

[p6:5015] ~%pythonw -vv
original argc=2
original argv[0] = "/Applications/Python.app/Contents/MacOS/python"
original argv[1] = "-vv"
modified argc=2
modified argv[0] = "/Applications/Python.app/Contents/MacOS/python"
modified argv[1] = "-vv"
-vv: can't open file '-vv'

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From njriley@uiuc.edu  Fri Nov 29 00:44:47 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Thu, 28 Nov 2002 18:44:47 -0600
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <2mk7izmhyc.fsf@starship.python.net>
References: <20021126193931.GB2710512@uiuc.edu> <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com> <20021127000820.GA2808351@uiuc.edu> <2mk7izmhyc.fsf@starship.python.net>
Message-ID: <20021129004447.GB2790563@uiuc.edu>

On Wed, Nov 27, 2002 at 10:21:15AM +0000, Michael Hudson wrote:
> 
> >   I did a 'find . -perm 711' in Python.framework and the only other
> >   file I found outside lib/dynload that had the wrong permissions was
> >   pydoc.
> 
> pydoc had rwx--x--x?  That seems surprising.

Pydoc seems to be in a class by itself in setup.py, 'scripts',
different from the python executable, which is installed by the
'altbininstall' target of the Makefile properly using $(INSTALL_PROGRAM).

> > - "no module named struct" should be distinguished from "can't access
> >   struct module to import it".
> 
> Patches welcome :)

Yeah, wish I had the time.  I've submitted enough patches to random
projects this week already, I've spent more time on them than my own
work... :(

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From borgempath@Phreaker.net  Fri Nov 29 08:50:48 2002
From: borgempath@Phreaker.net (Joel Rodrigues)
Date: Fri, 29 Nov 2002 14:20:48 +0530
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
Message-ID: <A7C4A53C-0377-11D7-BF2C-0005024EF27F@Phreaker.net>

Hi,

I'm also attempting to get Python 2.2.2 & Tkinter working with 
TclTkAqua 8.4.1, but don't know quite how to go about it.

I've seen some instructions for something called MachoPython 
which requires X windows, as in This bit:

     5. Append the following to Modules/Setup.local

*shared*
_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
          -I/Library/Frameworks/Tcl.framework/Headers/ \
          
-I/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders/ \
          -I/Library/Frameworks/Tk.framework/Headers/ \
          
-I/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders/ \
          -I/usr/X11R6/include/ \
          -framework Tcl -framework Tk



I've also seen something about how this may not be a problem 
once Python 2.3 is out.

Anyway, like Nicholas, I've installed the TclTkAqua 8.4.1 binary 
distribution.

I've also got Python 2.2.2 as far as :

  setenv OPT '-no-cpp-precomp -O3'
  ./configure --enable-framework


I also have had Python 2.2 installed and in use for a while now, 
not as a Framework, just the regular Unix style install.

So what do I do now ? Any help would be greatly appreciated.

Cheers,
Joel




From mjb@uma.pt  Fri Nov 29 10:39:56 2002
From: mjb@uma.pt (Michael J. Barber)
Date: Fri, 29 Nov 2002 10:39:56 +0000
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <40BD90E4-030F-11D7-83AC-000A27B19B96@oratrix.com>
Message-ID: <E7148822-0386-11D7-93C6-0050E4794D0F@uma.pt>

On Thursday, November 28, 2002, at 08:23  PM, Jack Jansen wrote:

> On donderdag, nov 28, 2002, at 12:40 Europe/Amsterdam, Michael J. 
> Barber wrote:
>
>> I would like very much to agree with this suggestion, but I just tried 
>> it out and gensuitemodule doesn't let me select iTunes as a "package 
>> generation target."
>
> Try selecting the file iTunes.app/Contents/Resources/iTunes.rsrc. Some 
> OSX applications have their AETE resource in there (Terminal is an 
> example). Some other apps, however, have no AETE resource, but in stead 
> have their applescript dictionaries encoded in plist files. At the 
> moment you are out of luck if you want to script one of these.
>
Odd, the dialog brought up by gensuitemodule won't let me into the 
package at all.

I suppose I should mention that this is iTunes 2, not iTunes 3. Don't 
know if that matters.



From mwh@python.net  Fri Nov 29 11:49:50 2002
From: mwh@python.net (Michael Hudson)
Date: 29 Nov 2002 11:49:50 +0000
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: Nicholas Riley's message of "Thu, 28 Nov 2002 18:44:47 -0600"
References: <20021126193931.GB2710512@uiuc.edu> <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com> <20021127000820.GA2808351@uiuc.edu> <2mk7izmhyc.fsf@starship.python.net> <20021129004447.GB2790563@uiuc.edu>
Message-ID: <2mu1i0lhnl.fsf@starship.python.net>

Nicholas Riley <njriley@uiuc.edu> writes:

> On Wed, Nov 27, 2002 at 10:21:15AM +0000, Michael Hudson wrote:
> > 
> > >   I did a 'find . -perm 711' in Python.framework and the only other
> > >   file I found outside lib/dynload that had the wrong permissions was
> > >   pydoc.
> > 
> > pydoc had rwx--x--x?  That seems surprising.
> 
> Pydoc seems to be in a class by itself in setup.py, 'scripts',
> different from the python executable, which is installed by the
> 'altbininstall' target of the Makefile properly using $(INSTALL_PROGRAM).

Yeah, I know that, but I thought distutils set script's permissions
properly -- don't you get a 'changing permissions of pydoc to 0755'
message during the install?

> > > - "no module named struct" should be distinguished from "can't access
> > >   struct module to import it".
> > 
> > Patches welcome :)
> 
> Yeah, wish I had the time.  I've submitted enough patches to random
> projects this week already, I've spent more time on them than my own
> work... :(

Join the club :(

Cheers,
M.

-- 
8. A programming language is low level when its programs require
   attention to the irrelevant.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html


From mjb@uma.pt  Fri Nov 29 13:50:26 2002
From: mjb@uma.pt (Michael J. Barber)
Date: Fri, 29 Nov 2002 13:50:26 +0000
Subject: [Pythonmac-SIG] Okay folks--show me how and I'll write it up...
In-Reply-To: <1038566768.48A2C16@r5.dngr.org>
Message-ID: <83FB336F-03A1-11D7-93C6-0050E4794D0F@uma.pt>

On Friday, November 29, 2002, at 10:46  AM, Nicholas Riley wrote:

> On Fri, 29 Nov 2002 5:40AM -0500, Michael J. Barber wrote:
>> On Thursday, November 28, 2002, at 08:23  PM, Jack Jansen wrote:
>>
>>> On donderdag, nov 28, 2002, at 12:40 Europe/Amsterdam, Michael J. 
>>> Barber wrote:
>>>
>>> Try selecting the file iTunes.app/Contents/Resources/iTunes.rsrc. 
>>> Some OSX applications
>> Odd, the dialog brought up by gensuitemodule won't let me into the 
>> package at all.
>
> You need to specify a special flag for Nav Services dialogs so they 
> permit you to navigate into packages, which gensuitemodule is 
> apparently not supplying.  Try copying the .rsrc file out of the 
> package first.
>
That did it! Thanks.



From Nicholas Riley" <njriley@uiuc.edu  Fri Nov 29 17:14:29 2002
From: Nicholas Riley" <njriley@uiuc.edu (Nicholas Riley)
Date: Fri, 29 Nov 2002 09:14:29 -0800
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <2mu1i0lhnl.fsf@starship.python.net>
References: <20021126193931.GB2710512@uiuc.edu> <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com> <20021127000820.GA2808351@uiuc.edu> <2mk7izmhyc.fsf@starship.python.net> <20021129004447.GB2790563@uiuc.edu> <2mu1i0lhnl.fsf@starship.python.net>
Message-ID: <1038590156.103A8011@r5.dngr.org>

On Fri, 29 Nov 2002 6:50AM -0500, Michael Hudson wrote:
> Nicholas Riley <njriley@uiuc.edu> writes:
>
>>  On Wed, Nov 27, 2002 at 10:21:15AM +0000, Michael Hudson wrote:
>>  >
>>  > >   I did a 'find . -perm 711' in Python.framework and the only 
>> other
>>  > >   file I found outside lib/dynload that had the wrong permissions 
>> was
>>  > >   pydoc.
>>  >
>>  > pydoc had rwx--x--x?  That seems surprising.
>>
>>  Pydoc seems to be in a class by itself in setup.py, 'scripts',
>>  different from the python executable, which is installed by the
>>  'altbininstall' target of the Makefile properly using 
>> $(INSTALL_PROGRAM).
>
> Yeah, I know that, but I thought distutils set script's permissions
> properly -- don't you get a 'changing permissions of pydoc to 0755'
> message during the install?

It appears to depend on the initially installed permissions: if they're 
700, then you get:

Changing mode of 
/Library/Frameworks/Python.framework/Versions/2.2/bin/pydoc to 711

This is rather obviously a bug in install_scripts.py: it does 'perm OR 
0111' (sorry, no pipe key on this keyboard and I don't remember the 
Unicode correspondence :) instead of 0555, which is necessary for 
scripts to be read by the Python interpreter.
--
Nicholas Riley <njriley@uiuc.edu>


From amk@amk.ca  Fri Nov 29 20:17:39 2002
From: amk@amk.ca (A.M. Kuchling)
Date: Fri, 29 Nov 2002 15:17:39 -0500
Subject: [Pythonmac-SIG] Python 2.2.2 and Tkinter installation problems on OS X
In-Reply-To: <1038590156.103A8011@r5.dngr.org>; from njriley@uiuc.edu on Fri, Nov 29, 2002 at 09:14:29AM -0800
References: <20021126193931.GB2710512@uiuc.edu> <AC4CEE93-018F-11D7-978B-000A27B19B96@oratrix.com> <20021127000820.GA2808351@uiuc.edu> <2mk7izmhyc.fsf@starship.python.net> <20021129004447.GB2790563@uiuc.edu> <2mu1i0lhnl.fsf@starship.python.net> <1038590156.103A8011@r5.dngr.org>
Message-ID: <20021129151739.A14822@nyman.amk.ca>

On Fri, Nov 29, 2002 at 09:14:29AM -0800, Nicholas Riley wrote:
>This is rather obviously a bug in install_scripts.py: it does 'perm OR 
>0111' (sorry, no pipe key on this keyboard and I don't remember the 
>Unicode correspondence :) instead of 0555, which is necessary for 
>scripts to be read by the Python interpreter.

Good point; corrected in CVS.

--amk


From p.thibault@bigfoot.com  Fri Nov 29 22:39:12 2002
From: p.thibault@bigfoot.com (Pierre Thibault)
Date: Fri, 29 Nov 2002 17:39:12 -0500
Subject: [Pythonmac-SIG] How to make IDLE for Mac OS X works
Message-ID: <61B73A05-03EB-11D7-81DF-000393C54658@bigfoot.com>

Hello,

I am new to Python programming. I have Mac OS 10.2.2 on my machine. I 
also have IDLE for OS X on it but I am unable to launch the 
application. From there, I don't know what to do. Can someone help me?

Regards.

---------------------
Pierre



From berkowit@silcom.com  Sat Nov 30 03:49:25 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Fri, 29 Nov 2002 19:49:25 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
Message-ID: <BA0D7545.27549%berkowit@silcom.com>

Hello. I'm brand new to Python, in OS 10.2.2, but an experienced
AppleScripter. (I'm quite amazed by the similarities of the syntax of the
two languages, which is making it easy to learn Python. I predict there will
be a lot of new converts.) I hope you don't mind a newbie setup question.
I'm brand new to Unix as well, and that's probably where I'm going wrong.

I was directed to pythonmac-sig when I was trying to find out how to import
a module with the Interactive interpreter. I saw a reference to Russell
Owen's webpage in the archives, where I found the solution to the problem
(which is Mac OS X-only): making my own 'environment.plist' XML file in
~/.MacOSX. The website URL is

    http://www.astro.washington.edu/owen/AquaEnvVar.html

This should be added to the Python FAQ.

Now I'm stumped again. Russell's solution works for importing modules from
directories that I've added to PYTHONPATH. But I can't get the shell to run
script files without the file's full path or having to cd to the file's
directory first, even though I've now added the directory to the path shell
variable, which in turn has automatically added it to the PATH environment.
I can import the script as a module with only the module name in the
Interactive interpreter:

>>> import module1
Hello module world!


This (very simple) script does run when I give its full or relative path
name or cd to its directory first, in the shell:

[250-166:~] berkowit% python Library/Scripts/Python/module1.py
Hello module world!



But it won't work like this:

[250-166:~] berkowit% python module1.py
python: can't open file 'module1.py'


The shell does know about its directory now (I set path to include it):

[250-166:~] berkowit% printenv PATH
/Users/berkowit/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:
/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/Users/berkowit/Library/Script
s/Python:.

That next-to-last directory:

    /Users/berkowit/Library/Scripts/Python

is the one with module1.py.  Why doesn't the shell find it? Or why doesn't
Python find it since it too knows where it is now, as the module import
makes clear?

Is this another Mac-only problem? Maybe I need to add another key to the
environment.plist file? Or am I just doing something wrong?

Many thanks for any guidance.


-- 
Paul Berkowitz




From mjb@uma.pt  Sat Nov 30 15:45:05 2002
From: mjb@uma.pt (Michael J. Barber)
Date: Sat, 30 Nov 2002 15:45:05 +0000
Subject: [Pythonmac-SIG] Announce: OSATools
Message-ID: <B26936E2-047A-11D7-93C6-0050E4794D0F@uma.pt>

The recent discussion of AppleScript and OSA inspired me to finally 
write a package I've been thinking about for a while. I'm calling it 
OSATools, and it basically is a set of wrappers for the 'osascript' and 
'osacompile' OS X system calls. There are convenience functions for 
several cases, and a basic but useful class modeling an AppleScript 
interface.

You can do things like:

Python 2.2.1 (#1, 09/14/02, 00:14:43)
[GCC Apple devkit-based CPP 6.02] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from OSATools import AppModels
 >>> finder = AppModels.AppleScriptApp("Finder")
 >>> finder.tell('get the name of the startup disk')
'Macintosh HD\n'
 >>> finder.tellBlock(['set countList to {}',
...    'set the end of countList to the count of the folder "Library" of 
the startup disk',
...    'set the end of countList to the count of folder "Applications" 
of the startup disk',
...    'return the countList'])
'36, 88\n'
 >>>

Written quickly and only tested a bit, so there are probably bugs. Seems 
to work ok, though.

One caveat: OSATools uses pipes to talk to osascript and friends. In 
other words, it won't work with MacPython just yet, you need a Unix 
python.

Anyone who is interested can get it here:
<http://www.artsci.wustl.edu/~mjbarber/OSATools.tgz>

Hope this is useful for someone.

Michael



From niel_mayhew@mac.com  Sat Nov 30 16:06:42 2002
From: niel_mayhew@mac.com (Neil Mayhew)
Date: Sat, 30 Nov 2002 09:06:42 -0700
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0D7545.27549%berkowit@silcom.com>
Message-ID: <BA0E3022.44FE%niel_mayhew@mac.com>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_rDJT56v7D7RWz8+KgS1ngg)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Paul,

If you put #!/usr/bin/python as the first line of your scripts, then you can
just type the name of the script at the command line -- no need to put
python in front. Then the shell will find the script using the PATH
environment variable. The shell will know to run it using python because of
the first line. However, you will have to give the script execute
permission, using chmod a+x <script>, or via the Finder's Get Info.

HTH,

--Neil



--Boundary_(ID_rDJT56v7D7RWz8+KgS1ngg)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<HTML>
<HEAD>
<TITLE>Re: [Pythonmac-SIG] Running Python scripts without full paths</TITLE>
</HEAD>
<BODY>
<FONT FACE="Arial">Paul,<BR>
<BR>
If you put #!/usr/bin/python as the first line of your scripts, then you can just type the name of the script at the command line -- no need to put python in front. Then the shell will find the script using the PATH environment variable. The shell will know to run it using python because of the first line. However, you will have to give the script execute permission, using chmod a+x &lt;script&gt;, or via the Finder's Get Info.<BR>
<BR>
HTH,<BR>
<BR>
--Neil<BR>
<BR>
</FONT>
</BODY>
</HTML>


--Boundary_(ID_rDJT56v7D7RWz8+KgS1ngg)--


From berkowit@silcom.com  Sat Nov 30 16:58:18 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 08:58:18 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E3022.44FE%niel_mayhew@mac.com>
Message-ID: <BA0E2E2A.275F2%berkowit@silcom.com>

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3121491500_1394054
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

On 11/30/02 8:06 AM, "Neil Mayhew" <niel_mayhew@mac.com> wrote:

> If you put #!/usr/bin/python as the first line of your scripts, then you can
> just type the name of the script at the command line -- no need to put python
> in front. Then the shell will find the script using the PATH environment
> variable. The shell will know to run it using python because of the first
> line. However, you will have to give the script execute permission, using
> chmod a+x <script>, or via the Finder's Get Info.

Thanks, Neil. That's the odd thing. I did all that (sorry I forgot to
mention it), except I left a space between after the #! , before
'usr/bin/env python'. I've now tried it all ways:

    #!/usr/bin/python
    #!/ usr/bin/python
    #!/usr/bin/env python
    #!/ usr/bin/env python

Even when I give the full path to the file:

[250-166:~] berkowit% ~/Library/Scripts/Python/module1.py
/Users/berkowit/Library/Scripts/Python/module1.py: Command not found.



I get "Command not found."every time.  What am I doing wrong?

Here are the permissions:

-rwxr-xr-x  1 berkowit  wheel    48 Nov 30 08:47 module1.py

Here's the current version of the file (with Unix newlines):

#!usr/bin/python
print 'Hello module world!'


-- 
Paul Berkowitz


--B_3121491500_1394054
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Pythonmac-SIG] Running Python scripts without full paths</TITLE=
>
</HEAD>
<BODY>
<FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:12.0px'><TT>On 11/30/02 8=
:06 AM, &quot;Neil Mayhew&quot; &lt;niel_mayhew@mac.com&gt; wrote:<BR>
<BR>
</TT></SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"A=
rial">If you put #!/usr/bin/python as the first line of your scripts, then y=
ou can just type the name of the script at the command line -- no need to pu=
t python in front. Then the shell will find the script using the PATH enviro=
nment variable. The shell will know to run it using python because of the fi=
rst line. However, you will have to give the script execute permission, usin=
g chmod a+x &lt;script&gt;, or via the Finder's Get Info.<BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:12.0px'><FONT FACE=3D"Arial=
"><BR>
</FONT><FONT FACE=3D"Verdana">Thanks, Neil. That's the odd thing. I did all t=
hat (sorry I forgot to mention it), except I left a space between after the =
#! , before 'usr/bin/env python'. I've now tried it all ways:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;#!/usr/bin/python<BR>
&nbsp;&nbsp;&nbsp;&nbsp;#!/ usr/bin/python<BR>
&nbsp;&nbsp;&nbsp;&nbsp;#!/usr/bin/env python<BR>
&nbsp;&nbsp;&nbsp;&nbsp;#!/ usr/bin/env python<BR>
<BR>
Even when I give the full path to the file:<BR>
<BR>
[250-166:~] berkowit% ~/Library/Scripts/Python/module1.py<BR>
/Users/berkowit/Library/Scripts/Python/module1.py: Command not found.<BR>
<BR>
<BR>
<BR>
I get &quot;Command not found.&quot;every time. &nbsp;What am I doing wrong=
?<BR>
<BR>
Here are the permissions:<BR>
<BR>
-rwxr-xr-x &nbsp;1 berkowit &nbsp;wheel &nbsp;&nbsp;&nbsp;48 Nov 30 08:47 m=
odule1.py<BR>
<BR>
Here's the current version of the file (with Unix newlines):<BR>
<BR>
#!usr/bin/python<BR>
print 'Hello module world!'<BR>
<BR>
<BR>
-- <BR>
Paul Berkowitz<BR>
</FONT></SPAN>
</BODY>
</HTML>


--B_3121491500_1394054--




From njriley@uiuc.edu  Sat Nov 30 18:11:37 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 12:11:37 -0600
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E2E2A.275F2%berkowit@silcom.com>
References: <BA0E3022.44FE%niel_mayhew@mac.com> <BA0E2E2A.275F2%berkowit@silcom.com>
Message-ID: <20021130181137.GB2833820@uiuc.edu>

On Sat, Nov 30, 2002 at 08:58:18AM -0800, Paul Berkowitz wrote:
>     #!/usr/bin/python
>     #!/ usr/bin/python
>     #!/usr/bin/env python
>     #!/ usr/bin/env python

You've got a slash before 'usr' here...

> #!usr/bin/python

but not here.  Does /usr/bin/python really exist?

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From kevin@macosx.com  Sat Nov 30 18:33:44 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 03:33:44 +0900
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130170002.16628.1096.Mailman@mail.python.org>
Message-ID: <41E75E9E-0492-11D7-91E4-003065555ABC@macosx.com>

For what it is worth i have never ever ever found a solution to this=20
problem My path is set in the

~/Library/init/tcsh/environment.mine

by adding:
setenv PATH "~/bin:/Users/kevin:${PATH}"

since path is an environmental variable i am not sure why there is a=20
path file (and why it is not called path.mine) and a separate=20
environment.mine file.

Should i have set this in:

~/Library/init/tcsh/path    ??? and if so how? it is a mystery and=20
Apple is not going to tell you either.

I also have the sbang set all fine and the file set to executable and=20
no go. I have asked this on the list over and over and many fine folks=20=

have tried to help me but to no avail. If i execute the script with the=20=

full path it is fine if i just move to the directory (which *IS* in my=20=

path), make a script and then try to execute it i get "command not=20
found". I checked my sanity and did the same thing on a linux box and=20
everything works, so i have no clue. The weirdest thing of all is if=20
you hop into the terminal and print your path from the command line it=20=

show that the dir is listed in the path after all.

Intensely frustrating. I have no idea why this is.

I have just bit the bullet and type the whole freaking path for now. I=20=

hate this part of Mach-o python and really dislike how Apple keeps=20
changing the unixy things with the terminal and not giving anything but=20=

the most terse instructions on how to customize tcsh. It changed from=20
10.1 to 10.2. The system they have is very nice and BSD-y but it takes=20=

days of investigation to get your stupid ~/Library/init/tcsh/ files=20
working. Once you figure out what the are and what they do. I suspect=20
that most folks have ignored the BSD way and just put a .tcshrc file in=20=

their home directory which overrides.

If i am right what the OS X ~/Library/init/tcsh/ system tries to do is=20=

have a system wide set-up with the shell which you then amend with your=20=

own ~/Library/init/tcsh files, but if you just put a .tcshrc file in=20
your home the system wide startup log-in log-out aliases and path files=20=

get clobbered, no? Who knows? Someone at Apple ought to make this clear=20=

instead of just that dumb single cryptic file that the give you in

/usr/share/tcsh/examples/README

You know the files they moved from /usr/share/init/tcsh without telling=20=

anyone making sure that anyone who used the terminal had a few days of=20=

frustration after moving to Jaguar.

Frankly i still can't figure out for sure what is going on with tcsh on=20=

OS X. On the NeXT is was simple you had your
.tcshrc .login and .logout files in your home and that was it. Plus=20
they were documented.  I am still not sure what is supposed to go in the

	aliases.mine		- shell aliases
	completions.mine	- completions
	environment.mine	- environment
	rc.mine			- run commands
	path			- command search path

files exactly. I realize that this is just .tcshrc broken up into=20
separate files, but what is rc.mine (is that supposed to be a=20
substitute for the .cshrc file?) and why is path not path.mine? and as=20=

i stated above since path is an environmental variable i am not sure=20
why there is a path file and a separate environment.mine file. The=20
whole thing is a mess and not at all documented. REAL examples would=20
have been nice. I am not sure who Fred Massachusetts Institute of=20
Technology  tritan@mit.edu is but i sure wish he would have written a=20
less terse readme.


I realize that i am a freak in that 1) i want actually write scripts to=20=

execute from the shell (heaven forbid!)
2) i like the terminal and actually want to use it.

But Apple hates users like me apparently since the do all they can to=20
make sure you don't use the shell, including moving stuff around and=20
not giving you any documentation on how to set up your shell. The csh=20
books out there are not any use either since they have nothing on the=20
new BSD ways. I hate this! I would love to know once and for all how to=20=

set up my shell so that i can add directories to my path like ~/bin
and type

% foo.py

and get a result. But i guess that is just never going to happen.




> Thanks, Neil. That's the odd thing. I did all that (sorry I forgot to=20=

> mention it), except I left a space between after the #! , before=20
> 'usr/bin/env python'. I've now tried it all ways:
>
> =A0=A0=A0=A0#!/usr/bin/python
> =A0=A0=A0=A0#!/ usr/bin/python
> =A0=A0=A0=A0#!/usr/bin/env python
> =A0=A0=A0=A0#!/ usr/bin/env python
>
> Even when I give the full path to the file:
>
> [250-166:~] berkowit% ~/Library/Scripts/Python/module1.py
> /Users/berkowit/Library/Scripts/Python/module1.py: Command not found.
>
>
>
> I get "Command not found."every time. =A0What am I doing wrong?
>
> Here are the permissions:
>
> -rwxr-xr-x =A01 berkowit =A0wheel =A0=A0=A048 Nov 30 08:47 module1.py
>
> Here's the current version of the file (with Unix newlines):
>
> #!usr/bin/python
> print 'Hello module world!



From berkowit@silcom.com  Sat Nov 30 18:34:37 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 10:34:37 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130181137.GB2833820@uiuc.edu>
Message-ID: <BA0E44BD.27609%berkowit@silcom.com>

On 11/30/02 10:11 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> On Sat, Nov 30, 2002 at 08:58:18AM -0800, Paul Berkowitz wrote:
>>     #!/usr/bin/python
>>     #!/ usr/bin/python
>>     #!/usr/bin/env python
>>     #!/ usr/bin/env python
> 
> You've got a slash before 'usr' here...
> 
>> #!usr/bin/python
> 
> but not here.  Does /usr/bin/python really exist?

That's it! Thanks, Nicholas. yes, that's where python and python2.2 are in
OS 10.2.2. I've wondered about that, I must say; it seems odd for something
called "usr" to be computer-wide (local), but that's where it is.

Everything works now, with or without space. I think 'env python' is best,
as new OS updates will also update the python version as time goes on.

Now, back to my original question, which has now turned into;

What's the approved way to add a directory to the existing PATH environment
variable, in the Terminal (tcsh) of Mac OS 10.2, in a way that will be
"permanent" - will be operative in all future calls in Terminal windows?

I've tried
    setenv PATH PATH:/Users/berkowit/Library/Scripts/Python:

(with or without the final colon)

but it doesn't take. I don't want to wipe out my existing PATH.

I've tried

    set path=($path /Users/berkowit/Library/Scripts/Python)

and that actually works, and resets PATH too, as I can see when I printenv.

But the next day, after opening a new Terminal session, the new directory is
gone. That _may_ be because I had a kernel panic late last night and had to
force-restart the computer. Is it? In any case, I hope you don't mind my
newbie questions - I'd like to know the best way of doing this. None of my
Unix books tell me, because they are annoyed that every Unix system does it
a different way, and just give up. How do we do it in OS X's BSD?

Many thanks for the help so far.

-- 
Paul Berkowitz




From berkowit@silcom.com  Sat Nov 30 18:56:34 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 10:56:34 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <41E75E9E-0492-11D7-91E4-003065555ABC@macosx.com>
Message-ID: <BA0E49E2.27612%berkowit@silcom.com>

It works for me now! First of all, thank you for

setenv PATH "~/bin:/Users/kevin:${PATH}"

syntax. (I didn't trust the ~ to resolve within quotes so I spelled it out.=
)

What you're missing is the .MacOSX folder and the XML file you have you mak=
e
there. That's how it's done in OS X, it seems, not with .tcshrc or init
files. See=20


    http://www.astro.washington.edu/owen/AquaEnvVar.html


That's how to do it. I had already used it to import modules within the
Interactive interpreter. Now that I've got the shebang and PATH variable
correct, it also works to run .py files from the Terminal.

That's the solution. Russell says he got it from the people at BBEdit.
Obviously, Apple needs to document it somewhere. I believe it will soon be
added to the FAQ at python.org: I had some correspondence on this last
night.


--=20
Paul Berkowitz



> From: kevin parks <kevin@macosx.com>
> Date: Sun, 1 Dec 2002 03:33:44 +0900
> To: pythonmac-sig@python.org
> Subject: Re: [Pythonmac-SIG] Running Python scripts without full paths
>=20
> For what it is worth i have never ever ever found a solution to this
> problem My path is set in the
>=20
> ~/Library/init/tcsh/environment.mine
>=20
> by adding:
> setenv PATH "~/bin:/Users/kevin:${PATH}"
>=20
> since path is an environmental variable i am not sure why there is a
> path file (and why it is not called path.mine) and a separate
> environment.mine file.
>=20
> Should i have set this in:
>=20
> ~/Library/init/tcsh/path    ??? and if so how? it is a mystery and
> Apple is not going to tell you either.
>=20
> I also have the sbang set all fine and the file set to executable and
> no go. I have asked this on the list over and over and many fine folks
> have tried to help me but to no avail. If i execute the script with the
> full path it is fine if i just move to the directory (which *IS* in my
> path), make a script and then try to execute it i get "command not
> found". I checked my sanity and did the same thing on a linux box and
> everything works, so i have no clue. The weirdest thing of all is if
> you hop into the terminal and print your path from the command line it
> show that the dir is listed in the path after all.
>=20
> Intensely frustrating. I have no idea why this is.
>=20
> I have just bit the bullet and type the whole freaking path for now. I
> hate this part of Mach-o python and really dislike how Apple keeps
> changing the unixy things with the terminal and not giving anything but
> the most terse instructions on how to customize tcsh. It changed from
> 10.1 to 10.2. The system they have is very nice and BSD-y but it takes
> days of investigation to get your stupid ~/Library/init/tcsh/ files
> working. Once you figure out what the are and what they do. I suspect
> that most folks have ignored the BSD way and just put a .tcshrc file in
> their home directory which overrides.
>=20
> If i am right what the OS X ~/Library/init/tcsh/ system tries to do is
> have a system wide set-up with the shell which you then amend with your
> own ~/Library/init/tcsh files, but if you just put a .tcshrc file in
> your home the system wide startup log-in log-out aliases and path files
> get clobbered, no? Who knows? Someone at Apple ought to make this clear
> instead of just that dumb single cryptic file that the give you in
>=20
> /usr/share/tcsh/examples/README
>=20
> You know the files they moved from /usr/share/init/tcsh without telling
> anyone making sure that anyone who used the terminal had a few days of
> frustration after moving to Jaguar.
>=20
> Frankly i still can't figure out for sure what is going on with tcsh on
> OS X. On the NeXT is was simple you had your
> .tcshrc .login and .logout files in your home and that was it. Plus
> they were documented.  I am still not sure what is supposed to go in the
>=20
> aliases.mine        - shell aliases
> completions.mine    - completions
> environment.mine    - environment
> rc.mine            - run commands
> path            - command search path
>=20
> files exactly. I realize that this is just .tcshrc broken up into
> separate files, but what is rc.mine (is that supposed to be a
> substitute for the .cshrc file?) and why is path not path.mine? and as
> i stated above since path is an environmental variable i am not sure
> why there is a path file and a separate environment.mine file. The
> whole thing is a mess and not at all documented. REAL examples would
> have been nice. I am not sure who Fred Massachusetts Institute of
> Technology  tritan@mit.edu is but i sure wish he would have written a
> less terse readme.
>=20
>=20
> I realize that i am a freak in that 1) i want actually write scripts to
> execute from the shell (heaven forbid!)
> 2) i like the terminal and actually want to use it.
>=20
> But Apple hates users like me apparently since the do all they can to
> make sure you don't use the shell, including moving stuff around and
> not giving you any documentation on how to set up your shell. The csh
> books out there are not any use either since they have nothing on the
> new BSD ways. I hate this! I would love to know once and for all how to
> set up my shell so that i can add directories to my path like ~/bin
> and type
>=20
> % foo.py
>=20
> and get a result. But i guess that is just never going to happen.
>=20
>=20
>=20
>=20
>> Thanks, Neil. That's the odd thing. I did all that (sorry I forgot to
>> mention it), except I left a space between after the #! , before
>> 'usr/bin/env python'. I've now tried it all ways:
>>=20
>> =A0=A0=A0=A0#!/usr/bin/python
>> =A0=A0=A0=A0#!/ usr/bin/python
>> =A0=A0=A0=A0#!/usr/bin/env python
>> =A0=A0=A0=A0#!/ usr/bin/env python
>>=20
>> Even when I give the full path to the file:
>>=20
>> [250-166:~] berkowit% ~/Library/Scripts/Python/module1.py
>> /Users/berkowit/Library/Scripts/Python/module1.py: Command not found.
>>=20
>>=20
>>=20
>> I get "Command not found."every time. =A0What am I doing wrong?
>>=20
>> Here are the permissions:
>>=20
>> -rwxr-xr-x =A01 berkowit =A0wheel =A0=A0=A048 Nov 30 08:47 module1.py
>>=20
>> Here's the current version of the file (with Unix newlines):
>>=20
>> #!usr/bin/python
>> print 'Hello module world!
>=20
>=20
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>=20




From berkowit@silcom.com  Sat Nov 30 19:22:59 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 11:22:59 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <41E75E9E-0492-11D7-91E4-003065555ABC@macosx.com>
Message-ID: <BA0E5013.2761D%berkowit@silcom.com>

On 11/30/02 10:56 AM, I wrote:

> It works for me now!


Well, sort of. It works in the same ttyp terminal window/session where I
modifies the PATH. But when I open a new window, printenv PATH doesn't know
anything about the directory I added in the other window. so it's still not
"taking" except in that one session. It's a tolerable workaround to modify
the PATH every time, although I might as well just cd to the directory.

Perhaps another key needs to be included in the XML file for PATH variable?
Or does anyone have another way to get the new PATH to stick?

-- 
Paul Berkowitz




From njriley@uiuc.edu  Sat Nov 30 19:33:52 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 13:33:52 -0600
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E44BD.27609%berkowit@silcom.com>
References: <20021130181137.GB2833820@uiuc.edu> <BA0E44BD.27609%berkowit@silcom.com>
Message-ID: <20021130193352.GC2833820@uiuc.edu>

On Sat, Nov 30, 2002 at 10:34:37AM -0800, Paul Berkowitz wrote:
> That's it! Thanks, Nicholas. yes, that's where python and python2.2 are in
> OS 10.2.2. I've wondered about that, I must say; it seems odd for something
> called "usr" to be computer-wide (local), but that's where it is.

I'm pretty sure that home directories used to be /usr/<uid> - at least
I've seen such things in old books - instead of being in /usr/home or
/home or /Users wherever they are now.  Most BSDs (though not Mac OS
X) have a 'bin' user, so in some bizarre way I guess you could
consider /usr/bin to be bin's home directory.  Though on FreeBSD where
I checked, bin's home directory is /, so that dashes that theory. :-)
Eventually you just learn these things and don't bother asking why any
more...  Check the hier(7) man page for a quick overview.

> What's the approved way to add a directory to the existing PATH environment
> variable, in the Terminal (tcsh) of Mac OS 10.2, in a way that will be
> "permanent" - will be operative in all future calls in Terminal windows?

Before taking Terminal out of the picture, understand what it does
when you create a new Terminal window.  This is a lot clearer in 10.2
than it was in earlier versions - see Terminal Preferences.  By
default 10.2's Terminal will run 'login', which executes your default
shell (as well as printing the MOTD and other such login-type
activities), or it'll run whatever command you specify in Preferences.
If the command happens to be a shell, then that shell will also be a
login shell.  Personally I have the 'execute this command' set to be
/bin/zsh because I don't want the additional overhead of 'login'.

>     set path=($path /Users/berkowit/Library/Scripts/Python)
> 
> and that actually works, and resets PATH too, as I can see when I printenv.

Yes, that's one of the weirdnesses of tcsh.  Something set by setenv
or set is only set in that shell until the next time you set/setenv
that variable.  The shell's environment is inherited by processes you
start from it.

If you want to see the starting environment of a process, try 'ps
-eww'.  For example, here it is for the zsh process Terminal just
started (to display that for the shell you're in now, try 'ps -Teww').

14555 std  Rs     0:00.76 -zsh HOME=/Users/nicholas SHELL=/bin/zsh USER=nicholas PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/nicholas RSYNC_RSH=ssh QDTEXT_ANTIALIASING=1 QDTEXT_MINSIZE=14 OMNI_INSTALLED_PRODUCTS=/Users/nicholas/Library/Frameworks DISPLAY=localhost SSH_ASKPASS=/Applications/Utilities/SSHPassKey.app/Contents/MacOS/SSHPassKey CVS_RSH=ssh __CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=M-??M-V  TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81     (zsh)

Note that this is not the -current- environment of the zsh process,
which you can display with 'printenv'.  The ps process that produced
the above, however, inherited the shell's current environment.  The
zsh process received its initial environment from its parent process,
Terminal (if you use login, then the shell's parent process will
be login, and login's parent process will be Terminal).

The reason for ~/.MacOSX/environment.plist being necessary is that
shells are not the parent processes of normally launched GUI apps on
OS X: the WindowServer is.  Look at Terminal as an example:

% ps -ejwwp 481
USER       PID  PPID  PGID   SESS JOBC STAT  TT       TIME COMMAND
nicholas   481   251   251 2787a38    0 S     ??   42:04.23 /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal -psn_0_2752513 HOME=/Users/nicholas SHELL=/bin/zsh USER=nicholas PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/nicholas RSYNC_RSH=ssh QDTEXT_ANTIALIASING=1 QDTEXT_MINSIZE=14 OMNI_INSTALLED_PRODUCTS=/Users/nicholas/Library/Frameworks DISPLAY=localhost SSH_ASKPASS=/Applications/Utilities/SSHPassKey.app/Contents/MacOS/SSHPassKey CVS_RSH=ssh       
% ps -ejwwp 251
USER       PID  PPID  PGID   SESS JOBC STAT  TT       TIME COMMAND
nicholas   251     1   251 2787a38    0 Ss    ??   98:28.04 /System/Library/CoreServices/WindowServer -daemon PWD=/ SHLVL=1 PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/System/Library/CoreServices _=/System/Library/CoreServices/WindowServer       
% pl < .MacOSX/environment.plist
{
    "CVS_RSH" = ssh; 
    DISPLAY = localhost; 
    "OMNI_INSTALLED_PRODUCTS" = "/Users/nicholas/Library/Frameworks"; 
    "QDTEXT_ANTIALIASING" = 1; 
    "QDTEXT_MINSIZE" = 14; 
    "RSYNC_RSH" = ssh; 
    "SSH_ASKPASS" = "/Applications/Utilities/SSHPassKey.app/Contents/MacOS/SSHPassKey"; 
}

Most of Terminal's environment is what is in ~/.MacOSX/environment.plist.
That file is only read on login, which is a real pain, but until
there's some way to force WindowServer to reread it, you're stuck with
trial and error.  A temporary workaround is to run the app you want
directly from the shell instead of using LaunchServices to do it (as
with the 'open' command, the Finder, etc.)  The 'pythonw' script does
exactly this.

> But the next day, after opening a new Terminal session, the new directory is
> gone. That _may_ be because I had a kernel panic late last night and had to
> force-restart the computer. Is it? In any case, I hope you don't mind my
> newbie questions - I'd like to know the best way of doing this. None of my
> Unix books tell me, because they are annoyed that every Unix system does it
> a different way, and just give up. How do we do it in OS X's BSD?

tcsh is the same program (pretty much) on all platforms where it runs,
and reads its config files the same way.  There's not much magic going
on if you understand it.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From kevin@macosx.com  Sat Nov 30 19:35:38 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 04:35:38 +0900
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <20021130170002.16628.1096.Mailman@mail.python.org>
Message-ID: <E7AD794C-049A-11D7-A0FF-003065555ABC@macosx.com>

[snowcat:~/scripts] kevin% ./foo.py
hello kevin
[snowcat:~/scripts] kevin% more foo.py
#!/usr/bin/python
print 'hello kevin'
[snowcat:~/scripts] kevin% foo.py
foo.py: Command not found.
[snowcat:~/scripts] kevin%
On Sunday, December 1, 2002, at 02:00  AM, 
pythonmac-sig-request@python.org wrote:


Ok, i set my path in /Users/kevin/Library/init/tcsh/environment.mine 
like so:

setenv PATH "/Users/kevin:/Users/kevin/bin:/Users/kevin/scripts:${PATH}"

I set ~/.MacOSX/environment.plist (which if you type % open 
environment.plist opens in
the Property Editor app and you can edit via the GUI!)


to have the same three paths and i type:

#!/usr/bin/python
print 'hello kevin'

into a file called foo.py and i chmod a+x it so we should be cool.

[snowcat:~/scripts] kevin% ./foo.py
hello kevin

groovy, now here is the big test, DOES THIS SEE /Users/kevin/scripts in 
my path and ...

[snowcat:~/scripts] kevin% foo.py
foo.py: Command not found.

so there you go. it still doesn't work.

UGHHHHH!







From berkowit@silcom.com  Sat Nov 30 19:42:00 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 11:42:00 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130193352.GC2833820@uiuc.edu>
Message-ID: <BA0E5488.27627%berkowit@silcom.com>

On 11/30/02 11:33 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> Most of Terminal's environment is what is in ~/.MacOSX/environment.plist.
> That file is only read on login, which is a real pain, but until
> there's some way to force WindowServer to reread it, you're stuck with
> trial and error.  A temporary workaround is to run the app you want
> directly from the shell instead of using LaunchServices to do it (as
> with the 'open' command, the Finder, etc.)  The 'pythonw' script does
> exactly this.

Thanks again, Nicholas. So can/should I add a new PATH key to my
~/.MacOSX/environment.plist, to get all future tcsh shell Terminal windows
to inherit my scripts folder, as PYTHONPATH now does in the interactive
interpreter? Will that work? (I understand that I'll need to log out and in,
as OS X user, before it takes effect. I can put up with that for now.)

-- 
Paul Berkowitz




From njriley@uiuc.edu  Sat Nov 30 19:45:32 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 13:45:32 -0600
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E5488.27627%berkowit@silcom.com>
References: <20021130193352.GC2833820@uiuc.edu> <BA0E5488.27627%berkowit@silcom.com>
Message-ID: <20021130194532.GD2833820@uiuc.edu>

On Sat, Nov 30, 2002 at 11:42:00AM -0800, Paul Berkowitz wrote:
> On 11/30/02 11:33 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:
> 
> > Most of Terminal's environment is what is in ~/.MacOSX/environment.plist.
> > That file is only read on login, which is a real pain, but until
> > there's some way to force WindowServer to reread it, you're stuck with
> > trial and error.  A temporary workaround is to run the app you want
> > directly from the shell instead of using LaunchServices to do it (as
> > with the 'open' command, the Finder, etc.)  The 'pythonw' script does
> > exactly this.
> 
> Thanks again, Nicholas. So can/should I add a new PATH key to my
> ~/.MacOSX/environment.plist, to get all future tcsh shell Terminal windows
> to inherit my scripts folder, as PYTHONPATH now does in the interactive
> interpreter? Will that work? (I understand that I'll need to log out and in,
> as OS X user, before it takes effect. I can put up with that for now.)

Yes, that's one way to do it.  If you just want stuff launched from
tcsh to be affected, then use ~/.tcshrc instead.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From kevin@macosx.com  Sat Nov 30 19:48:38 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 04:48:38 +0900
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <20021130170002.16628.1096.Mailman@mail.python.org>
Message-ID: <B891D097-049C-11D7-9E76-003065555ABC@macosx.com>

I think that i got it to work.

Apparently you can *NOT* set your path in 
~/Library/init/tcsh/environment.mine.

I looked at:

/usr/share/tcsh/examples/login

and that is where the path is set and if you want to append it it has 
to be in

/Users/kevin/Library/init/tcsh/path

because that where it looks for appended items.

[snowcat:~] kevin% cd scripts/
[snowcat:~/scripts] kevin% ls
--     foo.py
[snowcat:~/scripts] kevin% ./foo.py
hello kevin
[snowcat:~/scripts] kevin% foo.py
hello kevin

So maybe it does work after all.

I am not sure that ~/.MacOSX/environment.plist

even needs to be set if you are not using an interface or framework.



From berkowit@silcom.com  Sat Nov 30 19:52:53 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 11:52:53 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130193352.GC2833820@uiuc.edu>
Message-ID: <BA0E5715.2762D%berkowit@silcom.com>

On 11/30/02 11:33 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> If you want to see the starting environment of a process, try 'ps
> -eww'.  For example, here it is for the zsh process Terminal just
> started (to display that for the shell you're in now, try 'ps -Teww').
> 
> 14555 std  Rs     0:00.76 -zsh HOME=/Users/nicholas SHELL=/bin/zsh
> USER=nicholas PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/nicholas RSYNC_RSH=ssh
> QDTEXT_ANTIALIASING=1 QDTEXT_MINSIZE=14
> OMNI_INSTALLED_PRODUCTS=/Users/nicholas/Library/Frameworks DISPLAY=localhost
> SSH_ASKPASS=/Applications/Utilities/SSHPassKey.app/Contents/MacOS/SSHPassKey
> CVS_RSH=ssh __CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=M-??M-V
> TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81     (zsh)
> 
> Note that this is not the -current- environment of the zsh process,
> which you can display with 'printenv'.  The ps process that produced
> the above, however, inherited the shell's current environment.  The
> zsh process received its initial environment from its parent process,
> Terminal (if you use login, then the shell's parent process will
> be login, and login's parent process will be Terminal).


What I get (before trying anything else) is:

[250-166:~] berkowit% ps -eww
  PID  TT  STAT      TIME COMMAND
  621  p1  S+     0:00.38 -tcsh HOME=/Users/berkowit SHELL=/bin/tcsh
USER=berkowit PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/berkowit
PYTHONPATH=/Users/berkowit/Library/Scripts/Python: DISPLAY=:0.0
__CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=M-??M-WM-@
TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=berkowit
(tcsh)
  643 std  S      0:00.21 -tcsh HOME=/Users/berkowit SHELL=/bin/tcsh
USER=berkowit PATH=/usr/bin:/bin:/usr/sbin:/sbin:/Users/berkowit
PYTHONPATH=/Users/berkowit/Library/Scripts/Python: DISPLAY=:0.0
__CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=M-??M-WM-@
TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=berkowit
(tcsh)


Just the default PATH, not the Library/Scripts/Python folder I added.

It does look as if maybe I can add a new PATH key in
~/.MacOS/environment.plist to do what PYTHONPATH does now. Worth a try?

-- 
Paul Berkowitz




From kevin@macosx.com  Sat Nov 30 20:00:20 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 05:00:20 +0900
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130194600.14455.63374.Mailman@mail.python.org>
Message-ID: <5AF76872-049E-11D7-9E76-003065555ABC@macosx.com>

Someone who really understands this ought to put something up on the 
web on this! I know that it is not exclusively a python item, but it is 
relevent. Thanks to the folks on the list i have it working but i am 
still digesting the reasons why it does and what the relationship is 
between the OS X, Terminal.app, the ~/Library/init/tcsh/, files are, 
whether you need a ~/.tcshrc file at all, the
/usr/share/tcsh/examples/ files, /etc, and PYTHONPATH (where is this 
set exactly? for macho and for the other python? is it even needed) and 
the evil mysterious  ~/.MacOSX/environment.plist.
file.

The whole thing is terrible if you ask me. Too complex and not 
documented at all. Someone
said that it is easy if you understand it. Well *if* is the key word 
there and how you get to understand it is another thing all together. A 
look in the bookstore  through OS X books makes
no mention of this.


>>> Most of Terminal's environment is what is in 
>>> ~/.MacOSX/environment.plist.
>>> That file is only read on login, which is a real pain, but until
>>> there's some way to force WindowServer to reread it, you're stuck 
>>> with
>>> trial and error.  A temporary workaround is to run the app you want
>>> directly from the shell instead of using LaunchServices to do it (as
>>> with the 'open' command, the Finder, etc.)  The 'pythonw' script does
>>> exactly this.
>>
>> Thanks again, Nicholas. So can/should I add a new PATH key to my
>> ~/.MacOSX/environment.plist, to get all future tcsh shell Terminal 
>> windows
>> to inherit my scripts folder, as PYTHONPATH now does in the 
>> interactive
>> interpreter? Will that work? (I understand that I'll need to log out 
>> and in,
>> as OS X user, before it takes effect. I can put up with that for now.)
>
> Yes, that's one way to do it.  If you just want stuff launched from
> tcsh to be affected, then use ~/.tcshrc instead.



From berkowit@silcom.com  Sat Nov 30 20:11:32 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 12:11:32 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130194532.GD2833820@uiuc.edu>
Message-ID: <BA0E5B74.27634%berkowit@silcom.com>

On 11/30/02 11:45 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> On Sat, Nov 30, 2002 at 11:42:00AM -0800, Paul Berkowitz wrote:
>> On 11/30/02 11:33 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:
>> 
>>> Most of Terminal's environment is what is in ~/.MacOSX/environment.plist.
>>> That file is only read on login, which is a real pain, but until
>>> there's some way to force WindowServer to reread it, you're stuck with
>>> trial and error.  A temporary workaround is to run the app you want
>>> directly from the shell instead of using LaunchServices to do it (as
>>> with the 'open' command, the Finder, etc.)  The 'pythonw' script does
>>> exactly this.
>> 
>> Thanks again, Nicholas. So can/should I add a new PATH key to my
>> ~/.MacOSX/environment.plist, to get all future tcsh shell Terminal windows
>> to inherit my scripts folder, as PYTHONPATH now does in the interactive
>> interpreter? Will that work? (I understand that I'll need to log out and in,
>> as OS X user, before it takes effect. I can put up with that for now.)
> 
> Yes, that's one way to do it.  If you just want stuff launched from
> tcsh to be affected, then use ~/.tcshrc instead.

It doesn't work. I would have preferred to have it work for all shells, so I
added this to my ~/.MacOSX/environment.plist file:

    <key>PATH</key>
    <string>/Users/berkowit/Library/Scripts/Python:</string>

That's exactly the same as :

    <key>PYTHONPATH</key>
    <string>/Users/berkowit/Library/Scripts/Python:</string>

which does work. But the PATH key doesn't. I logged out for  OS X and back
in again. here's what I see:

[250-166:~] berkowit% printenv PATH
~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:/bin:
/usr/local/sbin:/usr/sbin:/sbin


What am I doing wrong/ I can try it Kevin's way just for tcsh, but I also
want to 'do shell script' from AppleScript, which uses bash in OS 10.2.
Anyway, why doesn't it work? I added the PATH key and string below DISPLAY
and PYTHONPATH. Since it's an (XML) Dictionary, order shouldn't matter,
should it?

-- 
Paul Berkowitz




From dmlsj@yahoo.com  Sat Nov 30 20:19:35 2002
From: dmlsj@yahoo.com (Daniel Lord)
Date: Sat, 30 Nov 2002 12:19:35 -0800
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <B891D097-049C-11D7-9E76-003065555ABC@macosx.com>
Message-ID: <0B00E3E0-04A1-11D7-A27B-003065D5C90C@yahoo.com>

On Saturday, Nov 30, 2002, at 11:48 US/Pacific, kevin parks wrote:

> I think that i got it to work.
>
> Apparently you can *NOT* set your path in 
> ~/Library/init/tcsh/environment.mine.
>
>

Au contraire, one can with this trick--put the following lines in 
~/.tcshrc:

# 
-----------------------------------------------------------------------
# Personal Environment
# 
-----------------------------------------------------------------------
source ~/Library/init/tcsh/path
source ~/Library/init/tcsh/rc.mine
source ~/Library/init/tcsh/environment.mine

It works for me and I don't have to logout to get the OSX plist to be 
re-read. Nota bene: a tech note I saw stated that the plist is what 
official applications read and they ignore the unix environment. So I 
put important environment variables for them in there as well. But 
Java, Python, Perl, bash, tcsh, fink, ant, etc.--all read the shell 
variables so those files work. I use them to set ANT_HOME, JAVA_HOME, 
CLASSPATH, aliases, etc., etc.

If you want to understand the reasoning and structure of the init 
files, check out "/usr/share/tcsh/examples/README" on your system. 
There are examples in there as well.

Prior to 10.2 Apple called the ~/Library/init files, but in 10.2 they 
stopped so you have to call them yourself. I suspect they were worried 
about conflicts between the init files snd the plist, but through 
perhaps dumb luck, I have not encountered any so far.

Daniel Lord

--
daniellordATtelocityDOTcom                                             
"My  dancing, drinking, and singing weave me the mat
GPG Fingerprint: C59E 59F5 1C63 5CFB 6161  067E FF00 A4E8 684A 16BB    
upon which my soul will sleep in the world of spirits"
                                                                         
                   -- Old Man of Halmahera, Indonesia



From njriley@uiuc.edu  Sat Nov 30 20:22:06 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 14:22:06 -0600
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E5B74.27634%berkowit@silcom.com>
References: <20021130194532.GD2833820@uiuc.edu> <BA0E5B74.27634%berkowit@silcom.com>
Message-ID: <20021130202206.GA2868232@uiuc.edu>

On Sat, Nov 30, 2002 at 12:11:32PM -0800, Paul Berkowitz wrote:
> On 11/30/02 11:45 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:
> > Yes, that's one way to do it.  If you just want stuff launched from
> > tcsh to be affected, then use ~/.tcshrc instead.
> 
> It doesn't work. I would have preferred to have it work for all shells, so I
> added this to my ~/.MacOSX/environment.plist file:
> 
>     <key>PATH</key>
>     <string>/Users/berkowit/Library/Scripts/Python:</string>

You seem to be including the trailing colon because you think it means
something??  You need to at least include the default PATH
(/usr/bin:/bin:[home dir]) in the PATH you set in
~/.MacOSX/environment.plist, otherwise bad things can happen.
WindowServer could be throwing out your PATH in an effort to sanity
check, in fact.

I just added /blah/bin to my PATH in ~/.MacOSX/environment.plist,
logged out, logged back in, and there it was.  When I put only
/blah/bin in there, my shell started complaining that it couldn't find
anything (not surprisingly).  So be careful.

> which does work. But the PATH key doesn't. I logged out for  OS X and back
> in again. here's what I see:
> 
> [250-166:~] berkowit% printenv PATH
> ~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:/bin:
> /usr/local/sbin:/usr/sbin:/sbin

Something else might be overwriting your path.  Remember that you're
using tcsh whose parent is login whose parent is Terminal whose parent
is the WindowServer.  Check the initial environment of Terminal using
'ps -eww'.  If that contains your PATH as you've set it, then follow
the chain of initial environments until you find the one that doesn't
contain your set PATH.

> What am I doing wrong/ I can try it Kevin's way just for tcsh, but I also
> want to 'do shell script' from AppleScript, which uses bash in OS 10.2.
> Anyway, why doesn't it work? I added the PATH key and string below DISPLAY
> and PYTHONPATH. Since it's an (XML) Dictionary, order shouldn't matter,
> should it?

No.  It's better to use Property List Editor than editing the file
directly, that way you don't have the potential of XML syntax errors
causing problems.  If in doubt, use the 'pl' program (see my previous
email) to print out the contents of the property list in old-style
plist format, which happens to be much more compact and human-readable
than the XML format.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From njriley@uiuc.edu  Sat Nov 30 20:25:06 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 14:25:06 -0600
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <0B00E3E0-04A1-11D7-A27B-003065D5C90C@yahoo.com>
References: <B891D097-049C-11D7-9E76-003065555ABC@macosx.com> <0B00E3E0-04A1-11D7-A27B-003065D5C90C@yahoo.com>
Message-ID: <20021130202506.GB2868232@uiuc.edu>

On Sat, Nov 30, 2002 at 12:19:35PM -0800, Daniel Lord wrote:
> Prior to 10.2 Apple called the ~/Library/init files, but in 10.2 they 
> stopped so you have to call them yourself. I suspect they were worried 
> about conflicts between the init files snd the plist, but through 
> perhaps dumb luck, I have not encountered any so far.

No, in fact they removed them because it made tcsh on OS X behave
differently to every other Unix.  Believe it or not, Apple cares about
this kind of thing.  Other Unices with GUIs have similar issues with
setting the environment of programs which aren't launched from the
command line.

What needs fixing, IMO, is that WindowServer's environment cannot be
edited through the GUI and requires a logout/login to change.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From berkowit@silcom.com  Sat Nov 30 20:25:10 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 12:25:10 -0800
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <0B00E3E0-04A1-11D7-A27B-003065D5C90C@yahoo.com>
Message-ID: <BA0E5EA6.2763E%berkowit@silcom.com>

On 11/30/02 12:19 PM, "Daniel Lord" <dmlsj@yahoo.com> wrote:

> Prior to 10.2 Apple called the ~/Library/init files, but in 10.2 they
> stopped so you have to call them yourself. I suspect they were worried
> about conflicts between the init files snd the plist, but through
> perhaps dumb luck, I have not encountered any so far.

As a brand new Unix user in OS 10.2 (I never tried any of this in 10.2), I
can tell you that _there is no ~/Library/init directory_ in 10.2 (you all
must have inherited yours from 10.1). I'll have to create one if I need to
go this route. So it's a visible folder in the Finder?

-- 
Paul Berkowitz




From dmlsj@yahoo.com  Sat Nov 30 20:30:31 2002
From: dmlsj@yahoo.com (Daniel Lord)
Date: Sat, 30 Nov 2002 12:30:31 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E5B74.27634%berkowit@silcom.com>
Message-ID: <92606F71-04A2-11D7-A27B-003065D5C90C@yahoo.com>

Another trick I used to figure out what was called when was to put 
something like "setenv DL_FILE `date +%y%m%d-%H%M%S`" (substitute your 
initials and the file name for DL_FILE) at the top of the .tcshrc and 
init files. Then I could see when things were being called and if 
source commands, exports, etc. worked. A simple little hack but it 
worked from my purposes.



From kevin@macosx.com  Sat Nov 30 20:36:03 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 05:36:03 +0900
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <0B00E3E0-04A1-11D7-A27B-003065D5C90C@yahoo.com>
Message-ID: <584E66C6-04A3-11D7-BFCC-003065555ABC@macosx.com>

On Sunday, December 1, 2002, at 05:19  AM, Daniel Lord wrote:

>
> On Saturday, Nov 30, 2002, at 11:48 US/Pacific, kevin parks wrote:
>
>> I think that i got it to work.
>>
>> Apparently you can *NOT* set your path in  
>> ~/Library/init/tcsh/environment.mine.
>>
>>
>
> Au contraire, one can with this trick--put the following lines in  
> ~/.tcshrc:
>
> #  
> -----------------------------------------------------------------------
> # Personal Environment
> #  
> -----------------------------------------------------------------------
> source ~/Library/init/tcsh/environment.mine
> source ~/Library/init/tcsh/rc.mine
> source ~/Library/init/tcsh/environment.mine


I tried setting that already. That wasn't the issue for me. What i was  
pointing out was that you can't try to
append your path in ~/Library/init/tcsh/environment.mine, but rather in  
~/Library/init/tcsh/path, since looking at
.login in /etc that shows that ~/Library/init/tcsh/path is where it  
looks next.

anyway it works and it works all the time now, so i got it all set in  
~/Library/init/tcsh/path
and it works.


> If you want to understand the reasoning and structure of the init  
> files, check out "/usr/share/tcsh/examples/README" on your system.  
> There are examples in there as well.

I mention this in my post. The problem was not that i didn't know about  
this file, but that it was almost completely
useless! and cryptic.


> Prior to 10.2 Apple called the ~/Library/init files, but in 10.2 they  
> stopped so you have to call them yourself.
>  I suspect they were worried about conflicts between the init files  
> snd the plist, but through perhaps dumb luck,


Maybe who knows?, but i wish that they would get it sorted out and just  
leave it! OS X is not beta anymore. folks are actually trying to use it  
for work!


cheers,

kevin




From dmlsj@yahoo.com  Sat Nov 30 20:39:41 2002
From: dmlsj@yahoo.com (Daniel Lord)
Date: Sat, 30 Nov 2002 12:39:41 -0800
Subject: [Pythonmac-SIG] Announce: OSATools
Message-ID: <D9DD3B45-04A3-11D7-A27B-003065D5C90C@yahoo.com>

--Apple-Mail-4-252039089
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Michael,


> The recent discussion of AppleScript and OSA inspired me to finally
> write a package I've been thinking about for a while. I'm calling it
> OSATools, and it basically is a set of wrappers for the 'osascript' and
> 'osacompile' OS X system calls. There are convenience functions for
> several cases, and a basic but useful class modeling an AppleScript
> interface.
>
> ***
>
> Hope this is useful for someone.
>

While most of us agree that using the OSA interface is the right way to 
go in the long run, this 'quick and dirty" interface is useful for 
testing and RAD. Thank you for producing this. Your solution is 
well-encapsulated OOP and more elegant than my newbie Python skill was 
creating. Very nicely done IMHO. Thank you again. Of ocurse I still 
want to do it old-fashioned and more powerful way as well, but the 
learning curve is much more steep.

Daniel
--
daniellordATtelocityDOTcom                                             
"My  dancing, drinking, and singing weave me the mat
GPG Fingerprint: C59E 59F5 1C63 5CFB 6161  067E FF00 A4E8 684A 16BB    
upon which my soul will sleep in the world of spirits"
                                                                         
                   -- Old Man of Halmahera, Indonesia

--Apple-Mail-4-252039089
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Michael,


<fontfamily><param>Courier</param><bigger>

<excerpt>The recent discussion of AppleScript and OSA inspired me to
finally 

write a package I've been thinking about for a while. I'm calling it 

OSATools, and it basically is a set of wrappers for the 'osascript'
and 

'osacompile' OS X system calls. There are convenience functions for 

several cases, and a basic but useful class modeling an AppleScript 

interface.


***


Hope this is useful for someone.


</excerpt></bigger></fontfamily>

While most of us agree that using the OSA interface is the right way
to go in the long run, this 'quick and dirty" interface is useful for
testing and RAD. Thank you for producing this. Your solution is
well-encapsulated OOP and more elegant than my newbie Python skill was
creating. Very nicely done IMHO. Thank you again. Of ocurse I still
want to do it old-fashioned and more powerful way as well, but the
learning curve is much more steep.


Daniel

--

daniellordATtelocityDOTcom                                            
"My  dancing, drinking, and singing weave me the mat

GPG Fingerprint: C59E 59F5 1C63 5CFB 6161  067E FF00 A4E8 684A 16BB   
upon which my soul will sleep in the world of spirits"

                                                                                         
-- Old Man of Halmahera, Indonesia


--Apple-Mail-4-252039089--



From berkowit@silcom.com  Sat Nov 30 20:43:47 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 12:43:47 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130202206.GA2868232@uiuc.edu>
Message-ID: <BA0E6303.27647%berkowit@silcom.com>

On 11/30/02 12:22 PM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> On Sat, Nov 30, 2002 at 12:11:32PM -0800, Paul Berkowitz wrote:
>> On 11/30/02 11:45 AM, "Nicholas Riley" <njriley@uiuc.edu> wrote:
>>> Yes, that's one way to do it.  If you just want stuff launched from
>>> tcsh to be affected, then use ~/.tcshrc instead.
>> 
>> It doesn't work. I would have preferred to have it work for all shells, so I
>> added this to my ~/.MacOSX/environment.plist file:
>> 
>>     <key>PATH</key>
>>     <string>/Users/berkowit/Library/Scripts/Python:</string>
> 
> You seem to be including the trailing colon because you think it means
> something??  

I thought it was an error in Russell's webpage, but it worked for
PYTHONPATH, so I left it in for "good luck". I removed it from both strings
now, makes no difference to either, but it's cleaner now without it.


>You need to at least include the default PATH
> (/usr/bin:/bin:[home dir]) in the PATH you set in
> ~/.MacOSX/environment.plist, otherwise bad things can happen.
> WindowServer could be throwing out your PATH in an effort to sanity
> check, in fact.

Thank you. I was a little hasty there, but I had saved a text copy of my
full PATH in TextEdit .txt file, just in case. Since it was overwritten, I
was more careful this time. thank you. This time I just added
:/Users/berkowit/Library/Scripts/Python to my existing PATH and put it all
in.
> 
> I just added /blah/bin to my PATH in ~/.MacOSX/environment.plist,
> logged out, logged back in, and there it was.  When I put only
> /blah/bin in there, my shell started complaining that it couldn't find
> anything (not surprisingly).  So be careful.
> 
>> which does work. But the PATH key doesn't. I logged out for  OS X and back
>> in again. here's what I see:
>> 
>> [250-166:~] berkowit% printenv PATH
>> ~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:/bin:
>> /usr/local/sbin:/usr/sbin:/sbin
> 
> Something else might be overwriting your path.  Remember that you're
> using tcsh whose parent is login whose parent is Terminal whose parent
> is the WindowServer.  Check the initial environment of Terminal using
> 'ps -eww'.  If that contains your PATH as you've set it, then follow
> the chain of initial environments until you find the one that doesn't
> contain your set PATH.

After logging out and in again, it _is_ now included in 'ps-eww' but not in
'printenv PATH'. What's the nest step(s) to check?

[250-166:~] berkowit% ps -eww
  PID  TT  STAT      TIME COMMAND
  721 std  S      0:00.20 -tcsh HOME=/Users/berkowit SHELL=/bin/tcsh
USER=berkowit 
PATH=~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:
/bin:/usr/local/sbin:/usr/sbin:/sbin:/Users/berkowit/Library/Scripts/Python
PYTHONPATH=/Users/berkowit/Library/Scripts/Python DISPLAY=:0.0
__CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=M-??M-W`
TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=berkowit
(tcsh)


[250-166:~] berkowit% printenv PATH
~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:/bin:
/usr/local/sbin:/usr/sbin:/sbin



> 
>> What am I doing wrong/ I can try it Kevin's way just for tcsh, but I also
>> want to 'do shell script' from AppleScript, which uses bash in OS 10.2.
>> Anyway, why doesn't it work? I added the PATH key and string below DISPLAY
>> and PYTHONPATH. Since it's an (XML) Dictionary, order shouldn't matter,
>> should it?
> 
> No.  It's better to use Property List Editor than editing the file
> directly, that way you don't have the potential of XML syntax errors
> causing problems.  If in doubt, use the 'pl' program (see my previous
> email) to print out the contents of the property list in old-style
> plist format, which happens to be much more compact and human-readable
> than the XML format.


OK, I did it that way this time. Thank you. pretty neat, once I figured out
to click "New Sibling". (!) - not entirely obvious.

Where should I check for what's overwriting the .plist?

-- 
Paul Berkowitz




From kevin@macosx.com  Sat Nov 30 20:58:51 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 05:58:51 +0900
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #1296 - 12 msgs
In-Reply-To: <20021130204502.6252.57191.Mailman@mail.python.org>
Message-ID: <875834F0-04A6-11D7-97D2-003065555ABC@macosx.com>


You are right there is none i had to make mine too. I found out about 
this
from poking around the system. That is the infamous 
/usr/share/tcsh/examples/README
file that i am talking about. It tells you that if you want to custmize 
tcsh you should make
these files and the ~/Library/init/tcsh directory.

-kp--


ps. the property list editor is better to use to muck with the xml 
file, but make sure
that you save the changes, i didn't at first somehow and had to edit it 
again.



On Sunday, December 1, 2002, at 05:45  AM, 
pythonmac-sig-request@python.org wrote:

> From: Paul Berkowitz <berkowit@silcom.com>
> Date: Sun Dec 1, 2002  5:25:10  AM Asia/Seoul
> To: PythonMac <pythonmac-sig@python.org>
> Subject: Re: [Pythonmac-SIG] Re: Running Python scripts without full 
> paths
>
>
> On 11/30/02 12:19 PM, "Daniel Lord" <dmlsj@yahoo.com> wrote:
>
>> Prior to 10.2 Apple called the ~/Library/init files, but in 10.2 they
>> stopped so you have to call them yourself. I suspect they were worried
>> about conflicts between the init files snd the plist, but through
>> perhaps dumb luck, I have not encountered any so far.
>
> As a brand new Unix user in OS 10.2 (I never tried any of this in 
> 10.2), I
> can tell you that _there is no ~/Library/init directory_ in 10.2 (you 
> all
> must have inherited yours from 10.1). I'll have to create one if I 
> need to
> go this route. So it's a visible folder in the Finder?



From kevin@macosx.com  Sat Nov 30 21:04:07 2002
From: kevin@macosx.com (kevin parks)
Date: Sun, 1 Dec 2002 06:04:07 +0900
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <20021130204502.6252.57191.Mailman@mail.python.org>
Message-ID: <441E1FAF-04A7-11D7-97D2-003065555ABC@macosx.com>

I didn't hit new sibling i just added stuff to the path after hitting 
the little triangle on the Root thingy.
just point click and type in the additional path elements and all was 
groovy.



> OK, I did it that way this time. Thank you. pretty neat, once I 
> figured out
> to click "New Sibling". (!) - not entirely obvious.
>
> Where should I check for what's overwriting the .plist?
>
> -- 
> Paul Berkowitz



From njriley@uiuc.edu  Sat Nov 30 21:08:10 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 15:08:10 -0600
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E6303.27647%berkowit@silcom.com>
References: <20021130202206.GA2868232@uiuc.edu> <BA0E6303.27647%berkowit@silcom.com>
Message-ID: <20021130210810.GA126378@uiuc.edu>

On Sat, Nov 30, 2002 at 12:43:47PM -0800, Paul Berkowitz wrote:
> > Something else might be overwriting your path.  Remember that you're
> > using tcsh whose parent is login whose parent is Terminal whose parent
> > is the WindowServer.  Check the initial environment of Terminal using
> > 'ps -eww'.  If that contains your PATH as you've set it, then follow
> > the chain of initial environments until you find the one that doesn't
> > contain your set PATH.
> 
> After logging out and in again, it _is_ now included in 'ps-eww' but not in
> 'printenv PATH'. What's the nest step(s) to check?
> 
> [250-166:~] berkowit% ps -eww
>   PID  TT  STAT      TIME COMMAND
>   721 std  S      0:00.20 -tcsh HOME=/Users/berkowit SHELL=/bin/tcsh
> USER=berkowit 
> PATH=~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:
> /bin:/usr/local/sbin:/usr/sbin:/sbin:/Users/berkowit/Library/Scripts/Python
> PYTHONPATH=/Users/berkowit/Library/Scripts/Python DISPLAY=:0.0
> __CF_USER_TEXT_ENCODING=0x1F5:0:0 TERM=vt100 TERMCAP=M-??M-W`
> TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=81 LOGNAME=berkowit
> (tcsh)
>
> Where should I check for what's overwriting the .plist?

Great!  So tcsh is changing your path, probably because of something
in one of the startup files.  Try setting the "execute this command"
box in Terminal's Preferences temporarily to '/bin/tcsh -V' and see
what it prints - somewhere in there will be a path change, I hope.
It'll be in one of tcsh's startup files - check the tcsh man page for
a list.

> OK, I did it that way this time. Thank you. pretty neat, once I figured out
> to click "New Sibling". (!) - not entirely obvious.

Yeah, long since past are the times when even Apple's developer tools
were easy to use.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From rbl@hal.epbi.cwru.edu  Sat Nov 30 21:20:25 2002
From: rbl@hal.epbi.cwru.edu (Robin B. Lake)
Date: Sat, 30 Nov 2002 16:20:25 -0500 (EST)
Subject: [Pythonmac-SIG] Environment from the tcsh shell
Message-ID: <200211302120.gAULKPDg020928@hal.epbi.cwru.edu>

Following the discussion between Paul and Nicholas --- just what I've
been waiting for!

The problem of the shell "losing" the environment came in with Jaguar.  I
used to be able to execute my nightly modeling runs from cron via a crontab
set of entries.  No more!  Cron, running under the shell, has no clue
as to what my environment PATH is.  Furthermore, one program that uses
very large arrays won't run under cron, generating "segmentation fault" 
errors, perhaps because the shell has different 'limit' settings?  All
totally undocumented and Apple Care tells me the $200+ I spent on the
support package doesn't cover Terminal!

I've been doing UNIX for 30+ years on 20+ different machines and Apple
has screwed up a Very Good Thing for developers with a careless or
carelessly-documented release.

Rob Lake
lake@cwru.edu


From berkowit@silcom.com  Sat Nov 30 21:23:25 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 13:23:25 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130210810.GA126378@uiuc.edu>
Message-ID: <BA0E6C4D.27652%berkowit@silcom.com>

On 11/30/02 1:08 PM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> Great!  So tcsh is changing your path, probably because of something
> in one of the startup files.  Try setting the "execute this command"
> box in Terminal's Preferences temporarily to '/bin/tcsh -V' and see
> what it prints - somewhere in there will be a path change, I hope.
> It'll be in one of tcsh's startup files - check the tcsh man page for
> a list.

That was easier said than done, too. Terminal Prefs kept reverting, but I
got it to stick in the end. OK. there's a lot there, including this snippet:
---------------------------------

set host = `hostname`
set host = `echo $host | tr A-Z a-z`

set user=`whoami`

setenv HOST "${host}"
setenv USER "${user}"

---------------------------------

and somewhat later on:

--------------------------------

if ( ! $?ENV_SET ) then
if ( -r "${default_tcsh_initdir}/environment" && ( $?prompt || $?XSESSION )
) then
source "${default_tcsh_initdir}/environment"


setenv ENV_SET

umask 022




if ( -r "${tcsh_initdir}/environment.mine" ) then
endif
else


if ( $?interactive ) then
if ( "${version}" =~ "tcsh"* ) bindkey "^R" i-search-back
endif


if ( -r "${tcsh_initdir}/rc.mine" ) source "${tcsh_initdir}/rc.mine"

if ( $?interactive ) then

if ( -r "${default_tcsh_initdir}/aliases" && ! $?noalias ) then
source "${default_tcsh_initdir}/aliases"

---------------------------------------------

later again:

----------------------------------

complete printenv 'p/1/e/'
complete set 'c/*=/f/' 'p/1/s/=' 'n/=/f/'
complete unset 'p/*/s/'
complete setenv 'p/1/e/'
complete unsetenv 'p/*/e/'

-----------------------------------

Later, there seems to be an entire history of everything I have ever typed
in the shell! Do you need to see the whole thing?



-- 
Paul Berkowitz




From njriley@uiuc.edu  Sat Nov 30 21:30:07 2002
From: njriley@uiuc.edu (Nicholas Riley)
Date: Sat, 30 Nov 2002 15:30:07 -0600
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <BA0E6C4D.27652%berkowit@silcom.com>
References: <20021130210810.GA126378@uiuc.edu> <BA0E6C4D.27652%berkowit@silcom.com>
Message-ID: <20021130213007.GC126378@uiuc.edu>

On Sat, Nov 30, 2002 at 01:23:25PM -0800, Paul Berkowitz wrote:
> Later, there seems to be an entire history of everything I have ever typed
> in the shell! Do you need to see the whole thing?

No, just everything that sets your path - that's what we're after!
Terminal does have a 'find' command which you can use to search its
scrollback buffer.

-- 
=Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
        Pablo Research Group, Department of Computer Science and
  Medical Scholars Program, University of Illinois at Urbana-Champaign


From berkowit@silcom.com  Sat Nov 30 21:50:30 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 13:50:30 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130213007.GC126378@uiuc.edu>
Message-ID: <BA0E72A6.27676%berkowit@silcom.com>

On 11/30/02 1:30 PM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> On Sat, Nov 30, 2002 at 01:23:25PM -0800, Paul Berkowitz wrote:
>> Later, there seems to be an entire history of everything I have ever typed
>> in the shell! Do you need to see the whole thing?
> 
> No, just everything that sets your path - that's what we're after!
> Terminal does have a 'find' command which you can use to search its
> scrollback buffer.

There's nothing with "path" or "PATH" above the buffer (?) except: stuff
that doesn't seem to have anything to do with my PATH environment:

----------------------

complete find 'n/-fstype/(nfs 4.2)/' 'n/-name/f/' 'n/-user/u/' 'n/-group/g/'
'n/-type/(c b d f p l s)/' 'n/-exec/c/' 'n/-ok/c/' 'n/-cpio/f/'
'n/-ncpio/f/' 'n/-newer/f/' 'c/-/(fstype name perm prune type user nouser
group    \
                nogroup size inum atime mtime ctime exec ok     \
                print ls cpio ncpio newer xdev depth daystart   \
                follow maxdepth mindepth noleaf version anewer  \
                cnewer amin cmin mmin true false uid gid ilname \
                iname ipath iregex links lname empty path regex \
                used xtype fprint fprint0 fprintf print0 printf \
                not a and o or)/' 'n/*/d/'

if ( ! $?framework_path ) then
set framework_path = ( )


foreach dir ( /Network/Library/Frameworks /Local/Library/Frameworks
/Library/Frameworks /System/Library/Frameworks /LocalLibrary/Frameworks
/NextLibrary/Frameworks ~/Library/Frameworks )
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
if ( -d "${dir}" ) set framework_path = ( ${framework_path} "${dir}" )
end
endif



------------------

complete nicl 'c/-/(ro p u P raw t q x500
\
                        read create delete rename list append merge insert
\
                        move copy search path setrdn history stats
domainname  \
                        rparent resync auth refs)/' 'n/-u/u/' 'n/-auth/u/'
'n/-P/n/' 'n/-raw/d/'


----------------------------------------




There are various failed attempts of mine in the buffer:


zprint $path

setenv PATH $PATH:/Users/berkowit/Library/Scripts/Python::

echo "$path"

setenv PATH PATH:/Users/berkowit/Library/Scripts/Python::

printenv PATH

-----------

setenv PATH 
~/bin/powerpc-apple-darwin:/Users/berkowit/bin:/usr/local/bin:/usr/bin:/bin:
/usr/local/sbin:/usr/sbin:/sbin:/Users/berkowit/Library/Scripts/Python::

----------

$path

echo $path



setenv PATH "${PATH}:/Users/berkowit/Library/Scripts/Python"

----------------


That's about it. What does buffer do, if anything?

-- 
Paul Berkowitz




From berkowit@silcom.com  Sat Nov 30 21:55:18 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 13:55:18 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130213007.GC126378@uiuc.edu>
Message-ID: <BA0E73C6.27679%berkowit@silcom.com>

On 11/30/02 1:30 PM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> On Sat, Nov 30, 2002 at 01:23:25PM -0800, Paul Berkowitz wrote:
>> Later, there seems to be an entire history of everything I have ever typed
>> in the shell! Do you need to see the whole thing?
> 
> No, just everything that sets your path - that's what we're after!

I noticed this near the top:

if ( -r "${default_tcsh_initdir}/tcsh.defaults" ) then
source "${default_tcsh_initdir}/tcsh.defaults"



Is something being reset to defaults here?

-- 
Paul Berkowitz




From berkowit@silcom.com  Sat Nov 30 22:09:24 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 14:09:24 -0800
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <20021130213007.GC126378@uiuc.edu>
Message-ID: <BA0E7714.2767C%berkowit@silcom.com>

On 11/30/02 1:30 PM, "Nicholas Riley" <njriley@uiuc.edu> wrote:

> No, just everything that sets your path - that's what we're after!

The man pages for tcsh say this:

       A login shell begins by executing commands from the system
       files /etc/csh.cshrc and /etc/csh.login.  It then executes
       commands  from  files  in the user's home directory: first
       ~/.tcshrc (+) or, if ~/.tcshrc  is  not  found,  ~/.cshrc,
       then  ~/.history (or the value of the histfile shell vari-
       able), then ~/.login, and finally ~/.cshdirs (or the value
       of  the  dirsfile shell variable) (+).  The shell may read
       /etc/csh.login before instead of after /etc/csh.cshrc, and
       ~/.login before instead of after ~/.tcshrc or ~/.cshrc and
       ~/.history, if so compiled; see the  version  shell  vari-
       able. (+)


The "infamous" /usr/share/tcsh/examples/README says:

----------

In order to use this configuration:

    echo "source /usr/share/tcsh/examples/rc"     > ~/.tcshrc
    echo "source /usr/share/tcsh/examples/login"  > ~/.login
    echo "source /usr/share/tcsh/examples/logout" > ~/.logout

To do this system-wide, do the same instead to /etc/csh.cshrc,
/etc/csh.login, and /etc/csh.logout.


----------------------

(which is not English and doesn't make any sense. "In order to use this
configuration", do what? Which configuration? Makes no sense.)

It also says:

-------
See the corresponding file in /usr/share/init/tcsh for more information
about the role of each file.

--------------

There _is no such file_. In fact, there is no /usr/share/init/ directory at
all.


It look like I'll have to do what Kevin did (thanks, Kevin). From the
README:

-----------------

In order to customize tcsh:

    mkdir ~/Library/init/tcsh

and create the following files there as necessary:

    aliases.mine        - shell aliases
    completions.mine    - completions
    environment.mine    - environment
    rc.mine            - run commands
    path            - command search path

-------------

using 'path', and just trust that some other shells don't overwrite the PATH
environment variable as set in ~/.MacOS/environment.plist.

There's certainly something messy here.

-- 
Paul Berkowitz




From berkowit@silcom.com  Sat Nov 30 22:35:13 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 14:35:13 -0800
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <B891D097-049C-11D7-9E76-003065555ABC@macosx.com>
Message-ID: <BA0E7D21.2767E%berkowit@silcom.com>

On 11/30/02 11:48 AM, "kevin parks" <kevin@macosx.com> wrote:

> I think that i got it to work.
> 
> Apparently you can *NOT* set your path in
> ~/Library/init/tcsh/environment.mine.
> 
> I looked at:
> 
> /usr/share/tcsh/examples/login
> 
> and that is where the path is set and if you want to append it it has
> to be in
> 
> /Users/kevin/Library/init/tcsh/path
> 
> because that where it looks for appended items.

Kevin, 

I did this, and I still can't get it to work. Perhaps I'm not appending
correctly. I typed out the whole thing, and it's not working. How did you do
it?


-- 
Paul Berkowitz




From berkowit@silcom.com  Sat Nov 30 22:46:13 2002
From: berkowit@silcom.com (Paul Berkowitz)
Date: Sat, 30 Nov 2002 14:46:13 -0800
Subject: [Pythonmac-SIG] Re: Running Python scripts without full paths
In-Reply-To: <BA0E7D21.2767E%berkowit@silcom.com>
Message-ID: <BA0E7FB5.27683%berkowit@silcom.com>

On 11/30/02 2:35 PM, "Paul Berkowitz" <berkowit@silcom.com> wrote:

> I did this, and I still can't get it to work. Perhaps I'm not appending
> correctly. I typed out the whole thing, and it's not working. How did you do
> it?

OK, it works! I had to log out and in, now it works. I confirm that it just
needs path, not environment.mine.

-- 
Paul Berkowitz




From Jack.Jansen@oratrix.com  Sat Nov 30 23:06:11 2002
From: Jack.Jansen@oratrix.com (Jack Jansen)
Date: Sun, 1 Dec 2002 00:06:11 +0100
Subject: [Pythonmac-SIG] Running Python scripts without full paths
In-Reply-To: <5AF76872-049E-11D7-9E76-003065555ABC@macosx.com>
Message-ID: <5142AA4A-04B8-11D7-A154-000A27B19B96@oratrix.com>

On zaterdag, nov 30, 2002, at 21:00 Europe/Amsterdam, kevin parks wrote:

> Someone who really understands this ought to put something up on the 
> web on this!

The problem is that noone really understands it:-(

As I have my historian's hat on today anyway, let me explain a bit how 
we got in the mess we are now.

Initially there was .profile for /bin/sh (only read when a login shell 
started), .login for csh (only read when a login shell started) and 
.cshrc for csh (only read when the shell was *not* a login shell). To 
simplify matters we'll forget about the bourne shell and its brethren 
(bash, zsh, esh, many more).

The csh and its descendents (like tcsh) added system-wide default 
initialization files (/etc/csh.login and /etc/csh.cshrc). Tcsh 
complicated matters, because whereas it shared .login with csh, it 
would prefer a .tcshrc file over a .cshrc file (but fallback to the 
latter if the former didn't exist). Then came windowing systems like 
X11, which would start up applications before anything resembling a 
"login shell" appeared, and you wanted to be able to set environment 
variables there too. So now there were three initialization files: 
.login (login shells), .cshrc (non-login shells) and something else for 
the windowing system (often .xinitrc, but there's other possibilities 
too:-). At this point some systems tried to rationalize things and 
provided /etc/profile.d, which was read by /etc/csh.login as well as 
the equivalents for all other shells as well as by the window system 
startup. At least: each read the bits it thought it required. And each 
of the files in /etc/profile.d could be overridden in your home 
directory (just as /etc/csh.login could be overridden by .login). But 
then people who wanted a custom .login needed to get bits and pieces 
from /etc/profile.d themselves, because .login replaces /etc/csh.login, 
in doesn't add to it. So by this time it was one big giant mess, and 
the only surefire way to get a working set of initialization files was 
to keep experimenting until you had something that worked, and then 
*never* *ever* touch that again (at least not structurally).

And then Apple appeared on the Unix front and made things even more 
difficult because they didn't want to mimic their 
window-system-initialization on X11, probably because they didn't want 
to depend on /bin/sh or /bin/csh in the login sequence, and they 
invented environment.plist.

And, of course, this is only the part of the story that I understand:-)
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -