From smithsm@samuelsmith.org  Thu Nov  1 01:01:30 2001
From: smithsm@samuelsmith.org (Samuel Smith)
Date: Wed, 31 Oct 2001 18:01:30 -0700
Subject: [Pythonmac-SIG] Ignore this test post
Message-ID: <p05100302b8064f420496@[10.0.2.215]>

Sorry, but ignore this message I am having troubles getting posts.
this is just a test
-- 
**********************************************

Samuel M. Smith Ph.D.

360 W. 920 N.
Orem, Utah 84057

801-226-7607 x112 (voice)
801-226-7608 (fax)
http://www.samuelsmith.org (web)

*********************************************


From smithsm@adeptsystemsinc.com  Thu Nov  1 01:02:39 2001
From: smithsm@adeptsystemsinc.com (Samuel Smith)
Date: Wed, 31 Oct 2001 18:02:39 -0700
Subject: [Pythonmac-SIG] Ignore Test Post
Message-ID: <p05100303b8064f9c19c1@[10.0.2.215]>

-- 
**********************************************************

Adept Systems Incorporated
360 W. 920 N.
Orem, Utah 84042
801.226.7607 x112 (voice)
801.226.7608 (fax)


smithsm@adeptsystemsinc.com (email)
http://www.adeptsystemsinc.com/ (web)


*********************************************************


From just@letterror.com  Thu Nov  1 07:47:07 2001
From: just@letterror.com (Just van Rossum)
Date: Thu,  1 Nov 2001 08:47:07 +0100
Subject: [Pythonmac-SIG] debugging problem
In-Reply-To: <20011030223429.82DD0FB04A@oratrix.oratrix.nl>
Message-ID: <20011101084709-r01010800-53104dd0-0910-010c@10.0.0.23>

Jack Jansen wrote:

> What seems to fix it for me is calling Widget.__init__ in stead of
> ClickableWidget.__init__, but it could well be that the correct fix is
> to inherit ClickableWidget in stead.
>
> Just, could you investigate this and commit a fix?

I did. (Turned out I had fixed the problem a while back, but forgot to check it
in. Oops and sorry.)

Just


From kaffeen@mac.com  Thu Nov  1 21:17:37 2001
From: kaffeen@mac.com (Chris Scott)
Date: Thu, 01 Nov 2001 16:17:37 -0500
Subject: [Pythonmac-SIG] Frustration building, please help...
Message-ID: <B8072621.35B%kaffeen@mac.com>

Well, so far Python hasn't been too hard to start learning, except that it
doesn't really seem to work. I'm working on a Mac G4 OS9 and can't even seem
to read, write, or manipulate files. Here's what I get, just trying to do
some simple stuff right out of the tutorial...

>>> f=open('blah', 'r+')
>>> f.write('testing 123')
>>> f.read()
Traceback (most recent call last):
  File "<input>", line 1, in ?
IOError: (0, 'Error')
>>> f.readline()
''
>>> f.write('testing again')
>>> f.readline()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00widths\x06\x00\x00\x00\x06\xd0\x00\x00\x17\
xa0\x12m<\x81\x12n\x13X\x12mO\xb8lls\x01\x00\x00\x00Ws\n'
>>> f.read()
Traceback (most recent call last):
  File "<input>", line 1, in ?
IOError: (0, 'Error')
>>> 

Help and calming words assuring that I haven't chosen the wrong scripting
language would be much appreciated. Thanks.

- Chris



From me@davidglasser.net  Thu Nov  1 21:38:16 2001
From: me@davidglasser.net (David Glasser)
Date: Thu, 1 Nov 2001 16:38:16 -0500
Subject: [Pythonmac-SIG] Frustration building, please help...
In-Reply-To: <B8072621.35B%kaffeen@mac.com>
Message-ID: <l03130301b8076ff27d87@[67.160.135.47]>

>Well, so far Python hasn't been too hard to start learning, except that it
>doesn't really seem to work. I'm working on a Mac G4 OS9 and can't even seem
>to read, write, or manipulate files. Here's what I get, just trying to do
>some simple stuff right out of the tutorial...

I'm not quite sure what exactly you're trying to do.  However, I'll note
that using open modes like 'r+' in any  language is usually not "some
simple stuff".  I'll try to walk through what you have.

Note that when using 'r+' mode, the file is opened with the current
position at the beginning; both reading and writing advances this current
position.  This means that after you write something, trying to read from
the file gives you what is *after* what you just wrote.  You can find out
your position in the file with f.tell, and set it with f.seek.

>>>> f=open('blah', 'r+')

You open a preexisting file.

>>>> f.write('testing 123')

You change its first eleven bytes, leaving your position after those bytes.

>>>> f.read()
>Traceback (most recent call last):
>  File "<input>", line 1, in ?
>IOError: (0, 'Error')

I'm not sure why this happens.

>>>> f.readline()
>''

You read to the end of the line, which seems to be nothing (i.e., you were
at the end of the line already).

>>>> f.write('testing again')

You change thirteen more bytes.

>>>> f.readline()
>'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00widths\x06\x00\x00\x00\x06\xd0\x00\x00\x17\
>xa0\x12m<\x81\x12n\x13X\x12mO\xb8lls\x01\x00\x00\x00Ws\n'

You read the (binary, it seems) file up untill the next newline.


You might want to start with text files instead of binary files, and avoid
'r+' mode unless it is absolutely necessary.

--David Glasser

me@davidglasser.net




From jack@oratrix.nl  Thu Nov  1 21:51:43 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Thu, 01 Nov 2001 22:51:43 +0100
Subject: [Pythonmac-SIG] Frustration building, please help...
In-Reply-To: Message by David Glasser <me@davidglasser.net> ,
 Thu, 1 Nov 2001 16:38:16 -0500 , <l03130301b8076ff27d87@[67.160.135.47]>
Message-ID: <20011101215148.8AF6AD52D8@oratrix.oratrix.nl>

To expand on David's excellent explanation of why what you're doing
probably isn't what you intended: you also happened to stumble across
two distinct bugs. But they're bugs that only happen in rare cases, I
wasn't aware of them (i.e. nobody reported them) until very recently.

Recently, David Glasser <me@davidglasser.net> said:
> >>>> f.read()
> >Traceback (most recent call last):
> >  File "<input>", line 1, in ?
> >IOError: (0, 'Error')

You cannot switch from reading to writing without doing a seek() or
rewind(). But: the underlying stdio library (MSL) is sloppy with its
error codes, it should have returned "Illegal operation" here.

> >>>> f.readline()
> >'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00widths\x06\x00\x00\x00\x06\xd0\x00\x00\x17\
> >xa0\x12m<\x81\x12n\x13X\x12mO\xb8lls\x01\x00\x00\x00Ws\n'

Here you're stumbling across a second bug. You should have gotten the
"illegal operation" again, but due to a bug in the I/O library that
lies even under the MSL stdio I/O library, GUSI, you don't. This bug is being
worked on, so in the next release you should get the (erronuous:-)
"Error 0" again. I have no idea where these bytes come from, but
probably not from your file.

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From bs1535@sbc.com  Thu Nov  1 21:50:55 2001
From: bs1535@sbc.com (SNYDER, BARRON F. (AIT))
Date: Thu, 1 Nov 2001 16:50:55 -0500
Subject: [Pythonmac-SIG] Wing IDE on OS X?
Message-ID: <35BD410BA148D411A7ED00508BCFFBDA0C16C59D@msgil65170u05.nbk2305.il.ameritech.com>

Has anyone out there tried to install/use Archaeopteryx Software's Wing IDE
( http://archaeopteryx.com/wingide ) on OS X? What are (if any) problems
related to the install?

Thanks,
Barron


From smithsm@samuelsmith.org  Thu Nov  1 22:01:30 2001
From: smithsm@samuelsmith.org (Samuel Smith)
Date: Thu, 1 Nov 2001 15:01:30 -0700
Subject: [Pythonmac-SIG] Test Ignore
Message-ID: <p05100303b80776abe50b@[10.0.2.215]>

-- 
**********************************************

Samuel M. Smith Ph.D.

360 W. 920 N.
Orem, Utah 84057

801-226-7607 x112 (voice)
801-226-7608 (fax)
http://www.samuelsmith.org (web)

*********************************************


From smithsm@samuelsmith.org  Thu Nov  1 22:05:06 2001
From: smithsm@samuelsmith.org (Samuel Smith)
Date: Thu, 1 Nov 2001 15:05:06 -0700
Subject: [Pythonmac-SIG] Test Post Ignore
Message-ID: <p05100305b8077781177a@[10.0.2.215]>

-- 
**********************************************

Samuel M. Smith Ph.D.

360 W. 920 N.
Orem, Utah 84057

801-226-7607 x112 (voice)
801-226-7608 (fax)
http://www.samuelsmith.org (web)

*********************************************


From jack@oratrix.nl  Thu Nov  1 22:09:41 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Thu, 01 Nov 2001 23:09:41 +0100
Subject: [Pythonmac-SIG] test - please ignore
Message-ID: <20011101220946.92025D52D8@oratrix.oratrix.nl>

Everyone but Samuel please ignore this message.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | ++++ see http://www.xs4all.nl/~tank/ ++++


From nathan@vividworks.com  Thu Nov  1 22:29:00 2001
From: nathan@vividworks.com (Nathan Heagy)
Date: Thu, 1 Nov 2001 16:29:00 -0600 (CST)
Subject: [Pythonmac-SIG] test - please ignore
In-Reply-To: <20011101220946.92025D52D8@oratrix.oratrix.nl>
Message-ID: <Pine.OSX.4.33.0111011628360.9129-100000@vividworks.com>

This is getting out of hand.

But please ignore.

Nathan



On Thu, 1 Nov 2001, Jack Jansen wrote:

> Everyone but Samuel please ignore this message.
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
> www.cwi.nl/~jack        | ++++ see http://www.xs4all.nl/~tank/ ++++
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From jack@oratrix.nl  Thu Nov  1 22:51:10 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Thu, 01 Nov 2001 23:51:10 +0100
Subject: [Pythonmac-SIG] test - please ignore
In-Reply-To: Message by Nathan Heagy <nathan@vividworks.com> ,
 Thu, 1 Nov 2001 16:29:00 -0600 (CST) , <Pine.OSX.4.33.0111011628360.9129-100000@vividworks.com>
Message-ID: <20011101225116.0BE61D52D8@oratrix.oratrix.nl>

Recently, Nathan Heagy <nathan@vividworks.com> said:
> This is getting out of hand.
> 
> But please ignore.

And what if I don't? :-)





But, to clue you all in on these funny test messages: Samuel had a
very funny problem in that he could get mail from and to me fine, but
not from the list. We think we have the problem nailed down and solved
now, though. Otherwise we'll happily send out a new flurry of test
messages next week:-)
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jack@oratrix.nl  Fri Nov  2 15:14:16 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 02 Nov 2001 16:14:16 +0100
Subject: [Pythonmac-SIG] What does CFStringGetSystemEncoding() return?
Message-ID: <20011102151416.B1A1C303181@snelboot.oratrix.nl>

Folks,
I need to know what CFStringGetSystemEncoding() returns on non-roman systems.

if someone with a non-MacRoman Carbon-capable system could please run the 
following code for me:
>>> import Carbon.CF
>>> enc = Carbon.CF.CFStringGetSystemEncoding()
>>> print "Encoding", enc
>>> name = Carbon.CF.CFStringGetNameOfEncoding()
>>> print "Name", name.CFStringGetString()

I'm interested in the output on both OS X and OS 9, by the way, but OSX is the 
most interesting. Oh yes, please supply system version/language info with your 
answer:-)
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | ++++ see http://www.xs4all.nl/~tank/ ++++




From owen@astro.washington.edu  Fri Nov  2 17:34:08 2001
From: owen@astro.washington.edu (Russell E Owen)
Date: Fri, 2 Nov 2001 09:34:08 -0800
Subject: [Pythonmac-SIG] Frustration building, please help...
Message-ID: <p05100303b80887ef211f@[128.95.99.44]>

Others have already answered the overall question, but there is one more point I'd like to note: if you are going to use 'r+' mode, you must be sure to flush all output to the file before attempting to read the file.

I don't believe that f.write() and f.writelines() are guaranteed to flush their output, so I would recommend you do it explicitly with f.flush() before attempting any read (and then seek to the beginning of the file). In other words:
f.write...
f.flush()
f.seek(0)
f.read...

If you don't mind writing more, I'd be curious what application you have, for which you are using a file that is simultaneously open for read and write. (Both out of curiosity -- it's something I've thought about using over the years but never actually ended up doing -- and because we might be able to suggest a simpler design).

-- Russell


From kaffeen@mac.com  Fri Nov  2 17:45:24 2001
From: kaffeen@mac.com (Chris Scott)
Date: Fri, 02 Nov 2001 12:45:24 -0500
Subject: [Pythonmac-SIG] Frustration gone, for now...
Message-ID: <B80845E4.374%kaffeen@mac.com>

Thanks for the help. Actually, I discovered the whole f.seek() thing quite
soon after I sent my message of frustration. Nice to know I'm discovering
bugs, though. And me a total newbie!

Sorry to vent on the list... (head hanging sheepishly)
- Chris

From: David Glasser <me@davidglasser.net>
Date: Thu, 1 Nov 2001 16:38:16 -0500
To: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Frustration building, please help...

>Well, so far Python hasn't been too hard to start learning, except that it
>doesn't really seem to work. I'm working on a Mac G4 OS9 and can't even seem
>to read, write, or manipulate files. Here's what I get, just trying to do
>some simple stuff right out of the tutorial...

I'm not quite sure what exactly you're trying to do.  However, I'll note
that using open modes like 'r+' in any  language is usually not "some
simple stuff".  I'll try to walk through what you have.

Note that when using 'r+' mode, the file is opened with the current
position at the beginning; both reading and writing advances this current
position.  This means that after you write something, trying to read from
the file gives you what is *after* what you just wrote.  You can find out
your position in the file with f.tell, and set it with f.seek.

>>>> f=open('blah', 'r+')

You open a preexisting file.

>>>> f.write('testing 123')

You change its first eleven bytes, leaving your position after those bytes.

>>>> f.read()
>Traceback (most recent call last):
>  File "<input>", line 1, in ?
>IOError: (0, 'Error')

I'm not sure why this happens.

>>>> f.readline()
>''

You read to the end of the line, which seems to be nothing (i.e., you were
at the end of the line already).

>>>> f.write('testing again')

You change thirteen more bytes.

>>>> f.readline()
>'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
>0\x00\x00\x00\x00\x00\x00\x00\x00widths\x06\x00\x00\x00\x06\xd0\x00\x00\x17\
>xa0\x12m<\x81\x12n\x13X\x12mO\xb8lls\x01\x00\x00\x00Ws\n'

You read the (binary, it seems) file up untill the next newline.


You might want to start with text files instead of binary files, and avoid
'r+' mode unless it is absolutely necessary.

--David Glasser

me@davidglasser.net






From: Jack Jansen <jack@oratrix.nl>
Date: Thu, 01 Nov 2001 22:51:43 +0100
To: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Frustration building, please help...

To expand on David's excellent explanation of why what you're doing
probably isn't what you intended: you also happened to stumble across
two distinct bugs. But they're bugs that only happen in rare cases, I
wasn't aware of them (i.e. nobody reported them) until very recently.

Recently, David Glasser <me@davidglasser.net> said:
> >>>> f.read()
> >Traceback (most recent call last):
> >  File "<input>", line 1, in ?
> >IOError: (0, 'Error')

You cannot switch from reading to writing without doing a seek() or
rewind(). But: the underlying stdio library (MSL) is sloppy with its
error codes, it should have returned "Illegal operation" here.

> >>>> f.readline()
> >'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> >0\x00\x00\x00\x00\x00\x00\x00\x00widths\x06\x00\x00\x00\x06\xd0\x00\x00\x17\
> >xa0\x12m<\x81\x12n\x13X\x12mO\xb8lls\x01\x00\x00\x00Ws\n'

Here you're stumbling across a second bug. You should have gotten the
"illegal operation" again, but due to a bug in the I/O library that
lies even under the MSL stdio I/O library, GUSI, you don't. This bug is
being
worked on, so in the next release you should get the (erronuous:-)
"Error 0" again. I have no idea where these bytes come from, but
probably not from your file.

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm



From kevino@tulane.edu  Fri Nov  2 18:17:30 2001
From: kevino@tulane.edu (Kevin Ollivier)
Date: Fri, 2 Nov 2001 13:17:30 -0500
Subject: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
References: <008001c16238$87c4d940$2101a8c0@kevinnew> <04a901c16239$70177d10$0100a8c0@Rogue>
Message-ID: <009901c163ca$a6df9a20$2101a8c0@kevinnew>

Getting closer...!

This morning I re-built wxMac and wxPython with the changes Robin made.
Everything builds OK, and I do not get any errors. When I run the demo now
it runs without errors also but I do not get any "visuals." That is, no
picture of John Cleese, no tree view window, etc. However, I get no errors
either, so I'm not sure that the code is failing. This has occurred with a
number of scripts, not just the demo script. In fact, I've thrown in some
print statements to debug various scripts inside the init methods and so far
they've all run without a hitch. Any ideas? I plan on checking into it more
later but thought I'd shoot it out to the group to see if anyone else has
built the software successfully and found a way around this problem.

Also, I've noticed that with my build of Python (2.1.1 built from python.org
source) there isn't multiple thread support. If I have Python running in one
terminal and try to start it in another, I get a "Bus error." Anyone know a
way around this?

Thanks!

Kevin

----- Original Message -----
From: "Robin Dunn" <robin@alldunn.com>
To: <wxpython-users@lists.wxwindows.org>
Cc: "Wx-Users" <wx-users@lists.wxwindows.org>
Sent: Wednesday, October 31, 2001 1:25 PM
Subject: Re: [wxPython] Compiling wxPython on OS X 10.1


> >
> > I'm cross-posting this in case some of the people working on building
> wxMac
> > might have some input. I have been able to successfully compile the
latest
> > CVS of wxMac and wxPython on Mac OS X 10.1. (Thanks to all of Robin's
hard
> > work!) In wxMac, most of the samples compile and run fine. However, when
I
> > try to run the demo.py script, or any other script in the demo or
samples
> > directories, I get the following error message:
> >
> > dyld: python Undefined symbols:
> > _wxEntryCleanup__Fv
> > _wxEntryInitGui__Fv
> > _wxEntryStart__FiPPc
> >
> > Any clues as to how I can fix this? =)
> >
>
> Oops, I forgot to check in my changes to src/mac/app.cpp.  I'll do it the
> next time I fire up the machine (later today probably.)
>
> --
> Robin Dunn
> Software Craftsman
> robin@AllDunn.com       Java give you jitters?
> http://wxPython.org      Relax with wxPython!
>
>
>
>
>
> _______________________________________________
> wxpython-users mailing list
> wxpython-users@lists.wxwindows.org
> http://lists.wxwindows.org/mailman/listinfo/wxpython-users
>



From kaffeen@mac.com  Fri Nov  2 18:55:22 2001
From: kaffeen@mac.com (Chris Scott)
Date: Fri, 02 Nov 2001 13:55:22 -0500
Subject: [Pythonmac-SIG] Building stuff - another silly newbie question!
Message-ID: <B808564A.377%kaffeen@mac.com>

I'm sure this is a silly question - but how do you build modules? I've been
trying like phooey to build the modules that come with pygame in a
non-carbon format, but I can't seem to do it. Likewise, I've been unable to
get PyOpenGL to build (version 1.5.7) without errors. So far, the only thing
I've been able to successfully install is Numeric. Is there some trick to
this that I'm not getting? I've been able to find a tutorial on just about
everything else python related, but not building and installing modules. Any
suggestions? Thanks.

- Chris



From robin@alldunn.com  Fri Nov  2 19:03:00 2001
From: robin@alldunn.com (Robin Dunn)
Date: Fri, 2 Nov 2001 11:03:00 -0800
Subject: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
References: <008001c16238$87c4d940$2101a8c0@kevinnew> <04a901c16239$70177d10$0100a8c0@Rogue> <009901c163ca$a6df9a20$2101a8c0@kevinnew>
Message-ID: <0ba601c163d0$fe9109b0$0100a8c0@Rogue>

> Getting closer...!
>
> This morning I re-built wxMac and wxPython with the changes Robin made.
> Everything builds OK, and I do not get any errors. When I run the demo now
> it runs without errors also but I do not get any "visuals." That is, no
> picture of John Cleese, no tree view window, etc. However, I get no errors
> either, so I'm not sure that the code is failing. This has occurred with a
> number of scripts, not just the demo script. In fact, I've thrown in some
> print statements to debug various scripts inside the init methods and so
far
> they've all run without a hitch. Any ideas?

This is exactly what I was seeing as well.  I havn't had time yet to dig any
further.

--
Robin Dunn
Software Craftsman
robin@AllDunn.com       Java give you jitters?
http://wxPython.org      Relax with wxPython!






From maskedrider@earthlink.net  Sun Nov  4 02:17:59 2001
From: maskedrider@earthlink.net (Bryce)
Date: Sat, 3 Nov 2001 19:17:59 -0700
Subject: [Pythonmac-SIG] Install problem
Message-ID: <2AB1EF5E-D0CA-11D5-A810-00050237A0D6@earthlink.net>

Greetings,

I installed the OS X.1 Darwin version of Python ok (BSD and all of that 
command line stuff). I installed Numeric 20.2.0 into /usr/loca/ and set 
the PYTHONPATH to include the lib directories in Numeric. When I run 
test.py in the Test directory of Numeric, I get this error:

 >/usr/local/Numeric-20.2.0/Test-282% python llstest.py

Traceback (most recent call last):
   File "llstest.py", line 1, in ?
     from Numeric import dot,sum
   File "/usr/local/Numeric-20.2.0/Lib/Numeric.py", line 86, in ?
     import multiarray
ImportError: No module named multiarray

I could not find multiarray anywhere.

Here is the Python version info:

Python 2.1 (#4, 05/17/01, 18:34:21)
[GCC Apple DevKit-based CPP 6.0alpha] on darwin1

Can anyone out there please tell me what I'm doing wrong ??? Do I need 
to install yet another distribution of another python app .. like 
imaging or something?

thanks ....

Bryce



From kaffeen@mac.com  Sun Nov  4 04:45:58 2001
From: kaffeen@mac.com (Chris Scott)
Date: Sat, 03 Nov 2001 23:45:58 -0500
Subject: [Pythonmac-SIG] Frustration building, please help...
Message-ID: <3BE4C805.FD60C38E@mac.com>

Hi Russell -
Thanks for the input, no question can ever be fully answered. At least,
not for the Python newbie! And if you must know, I was opening the file
as "r+" because the tutorial said I could. So, if I can, then I want
to:) There's no application, I'm just trying to get through the
text/file IO/rules and regs stuff so I can start working on games. I
suppose, somewhere in the back of my head, was an idea of a simple word
processor. Again, thanks for the help. I look forward to asking more
questions!
- Chris


 Subject:
         Re: [Pythonmac-SIG] Frustration building, please help...
    Date:
         Fri, 2 Nov 2001 09:34:08 -0800
   From:
         Russell E Owen <owen@astro.washington.edu>
     To:
         Mac Python mailing list <pythonmac-sig@python.org>



Others have already answered the overall question, but there is one more
point I'd like to note: if you are going to use 'r+' mode, you must be
sure to flush all output to the file before attempting to read the file.

I don't believe that f.write() and f.writelines() are guaranteed to
flush their output, so I would recommend you do it explicitly with
f.flush() before attempting any read (and then seek to the beginning of
the file). In other words:
f.write...
f.flush()
f.seek(0)
f.read...

If you don't mind writing more, I'd be curious what application you
have, for which you are using a file that is simultaneously open for
read and write. (Both out of curiosity -- it's something I've thought
about using over the years but never actually ended up doing -- and
because we might be able to suggest a simpler design).

-- Russell



From just@letterror.com  Sun Nov  4 07:38:01 2001
From: just@letterror.com (Just van Rossum)
Date: Sun,  4 Nov 2001 08:38:01 +0100
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: <2AB1EF5E-D0CA-11D5-A810-00050237A0D6@earthlink.net>
Message-ID: <20011104083811-r01010800-9cd4faa4-0920-010c@10.0.0.23>

Bryce wrote:

> I installed the OS X.1 Darwin version of Python ok (BSD and all of that 
> command line stuff). I installed Numeric 20.2.0 into /usr/loca/ and set 
> the PYTHONPATH to include the lib directories in Numeric. When I run 
> test.py in the Test directory of Numeric, I get this error:

I have NumPy working under Python 2.1.1 & 10.0.4. If I remember correctly, all I
did was run 

sudo python setup.py install

in the appropriate Numeric directory. I didn't have to muck with PYTHONPATH,
didn't install "by hand". Using Numeric's setup.py a directory called Numeric
and a file called Numeric.pth will be installed in site-packages. That should be
all there is to it, but I haven't tried this with 2.1 under 10.1...

Just


From wtbridgman@Radix.Net  Sun Nov  4 14:25:09 2001
From: wtbridgman@Radix.Net (W.T. Bridgman)
Date: Sun, 4 Nov 2001 09:25:09 -0500
Subject: [Pythonmac-SIG] Python 2.2b1 on OS X
Message-ID: <p05001900b80afddc753f@[207.192.130.188]>

Okay, I've finally got an OS X partition on my laptop and have run 
the installer for Python 2.2b1.

The installer seemed to run fine but when I ran the tests, it crashed 
when it hit the socket test (I was not connected at the time).  Note 
that this was running Python by double-clicking the icon.

I wondered whether the tests would run better if performed from a 
terminal window but the installer doesn't seem to do a setup for 
command-line use.  I suspect I need to do a 'ln -s' on something to 
somewhere, but what?

Also, I understand Apple was involved in getting the latest Tcl/Tk 
ported to OS X.  How does this impact Tkinter running natively under 
OS X?  Would it be a 'drop-in' installation or is everyone just 
waiting for wxPython to be ready for prime time?

I've dealt with Unix as a user, but never as an admin.  This strange 
creature arising from the merger of Unix and MacOS will take some 
getting used to.

Thanks,
Tom
-- 
Tom Bridgman, Ph.D. 
wtbridgman@radix.net                         Physics & Astronomy  


From maskedrider@earthlink.net  Sun Nov  4 17:23:40 2001
From: maskedrider@earthlink.net (Bryce)
Date: Sun, 4 Nov 2001 10:23:40 -0700
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: <20011104083811-r01010800-9cd4faa4-0920-010c@10.0.0.23>
Message-ID: <B0BF2F5E-D148-11D5-BC9D-00050237A0D6@earthlink.net>

Hi Just,

Recall: python 2.1, OSX.1, and Numerc 20.2.0.

Well I ran the installer again for Numeric and this time I noticed an 
error, here is the dump:

running install
running build
running build_py
creating build
creating build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/ArrayPrinter.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/LinearAlgebra.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/Matrix.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/MLab.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/Numeric.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/numeric_version.py -> build/lib.darwin-1.4-Power 
Macintosh-2.1
copying Lib/Precision.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/RandomArray.py -> build/lib.darwin-1.4-Power Macintosh-2.1
copying Lib/UserArray.py -> build/lib.darwin-1.4-Power Macintosh-2.1
running build_ext
building '_numpy' extension
creating build/temp.darwin-1.4-Power Macintosh-2.1
cc -g -O2 -Wall -Wstrict-prototypes -IInclude 
-I/usr/local/include/python2.1 -c Src/_numpymodule.c -o 
build/temp.darwin-1.4-Power Macintosh-2.1/_numpymodule.o
In file included from /usr/local/include/python2.1/pyport.h:84,
                  from /usr/local/include/python2.1/Python.h:54,
                  from Src/_numpymodule.c:2:
/usr/include/math.h:191: warning: function declaration isn't a prototype
In file included from Src/_numpymodule.c:4:
Include/Numeric/arrayobject.h:228: warning: function declaration isn't a 
prototype
Src/_numpymodule.c:18: warning: function declaration isn't a prototype
cc -g -O2 -Wall -Wstrict-prototypes -IInclude 
-I/usr/local/include/python2.1 -c Src/arrayobject.c -o 
build/temp.darwin-1.4-Power Macintosh-2.1/arrayobject.o
In file included from /usr/local/include/python2.1/pyport.h:84,
                  from /usr/local/include/python2.1/Python.h:54,
                  from Src/arrayobject.c:18:
/usr/include/math.h:191: warning: function declaration isn't a prototype
In file included from Src/arrayobject.c:25:
Include/Numeric/arrayobject.h:228: warning: function declaration isn't a 
prototype
cc -g -O2 -Wall -Wstrict-prototypes -IInclude 
-I/usr/local/include/python2.1 -c Src/ufuncobject.c -o 
build/temp.darwin-1.4-Power Macintosh-2.1/ufuncobject.o
In file included from /usr/local/include/python2.1/pyport.h:84,
                  from /usr/local/include/python2.1/Python.h:54,
                  from Src/ufuncobject.c:14:
/usr/include/math.h:191: warning: function declaration isn't a prototype
In file included from Src/ufuncobject.c:21:
Include/Numeric/arrayobject.h:228: warning: function declaration isn't a 
prototype
Src/ufuncobject.c:406: warning: function declaration isn't a prototype
Src/ufuncobject.c: In function `PyUFunc_GenericReduceAt':
Src/ufuncobject.c:634: warning: `os' might be used uninitialized in this 
function
Src/ufuncobject.c: In function `ufunc_generic_call':
Src/ufuncobject.c:765: warning: suggest explicit braces to avoid 
ambiguous `else'

cc -bundle -undefined suppress build/temp.darwin-1.4-Power 
Macintosh-2.1/_numpymodule.o build/temp.darwin-1.4-Power 
Macintosh-2.1/arrayobject.o build/temp.darwin-1.4-Power 
Macintosh-2.1/ufuncobject.o -o build/lib.darwin-1.4-Power 
Macintosh-2.1/_numpy.so

/usr/bin/ld: -undefined error must be used when -twolevel_namespace is 
in effect
error: command 'cc' failed with exit status 1
----------

Then when I check the sites-packages there is no Numeric directory or 
Numeric.pth file in that directory.

Any suggestions.  Thanks !!!

Bryce


On Sunday, November 4, 2001, at 12:38 AM, Just van Rossum wrote:

> Bryce wrote:
>
>> I installed the OS X.1 Darwin version of Python ok (BSD and all of that
>> command line stuff). I installed Numeric 20.2.0 into /usr/loca/ and set
>> the PYTHONPATH to include the lib directories in Numeric. When I run
>> test.py in the Test directory of Numeric, I get this error:
>
> I have NumPy working under Python 2.1.1 & 10.0.4. If I remember 
> correctly, all I
> did was run
>
> sudo python setup.py install
>
> in the appropriate Numeric directory. I didn't have to muck with 
> PYTHONPATH,
> didn't install "by hand". Using Numeric's setup.py a directory called 
> Numeric
> and a file called Numeric.pth will be installed in site-packages. That 
> should be
> all there is to it, but I haven't tried this with 2.1 under 10.1...
>
> Just
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>



From prastawa@cs.unc.edu  Sun Nov  4 17:36:14 2001
From: prastawa@cs.unc.edu (Marcelinus Prastawa)
Date: Sun, 4 Nov 2001 12:36:14 -0500
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: <B0BF2F5E-D148-11D5-BC9D-00050237A0D6@earthlink.net>
Message-ID: <71F274D0-D14A-11D5-9C1A-000A27942780@cs.unc.edu>

FYI, Numeric 20.2.1 is available. It fixes a problem with complex 
eigenvalues.

I have no problems building NumPy with Python 2.2 on OS X 10.1. You might 
want to consider switching to 2.2.

The compiler/linker complained because some symbols are undefined. I 
noticed that the compiler uses the flag '-undefined suppress'. This won't 
work unless you also use the flag '-flat_namespace'. OS X (starting from 
10.1?) has two-level vs flat namespace for binaries. I don't really 
understand dynamic loading / linking under OS X, somebody else could 
probably give you a better idea.

Marcel



From mdunn@cantares.on.ca  Sun Nov  4 17:52:49 2001
From: mdunn@cantares.on.ca (Michael Dunn)
Date: Sun, 4 Nov 2001 12:52:49 -0500
Subject: [Pythonmac-SIG] Intercepting kbd ints
Message-ID: <a05100301b80b2fcd8c9f@[64.7.131.36]>

    There seems to be a bug in 2.1.  On a number of occasions, I've 
had a program running in the background, and when I've come back to 
it, it's crapped out with a KeyboardInterrupt.  Could background pgms 
be intercepting cmd-periods?  Very frustrating when it's been running 
for an hour!!!

    Speaking of funny kbd behaviour, should the 'end' key act as a 
quit?  Mine does...



From maskedrider@earthlink.net  Sun Nov  4 18:15:29 2001
From: maskedrider@earthlink.net (Bryce)
Date: Sun, 4 Nov 2001 11:15:29 -0700
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: <71F274D0-D14A-11D5-9C1A-000A27942780@cs.unc.edu>
Message-ID: <EDB53138-D14F-11D5-BC9D-00050237A0D6@earthlink.net>

Thank you Marcelinus. I will take your suggestion and begin again with 
python 2.2.

Bryce


On Sunday, November 4, 2001, at 10:36 AM, Marcelinus Prastawa wrote:

> FYI, Numeric 20.2.1 is available. It fixes a problem with complex 
> eigenvalues.
>
> I have no problems building NumPy with Python 2.2 on OS X 10.1. You 
> might want to consider switching to 2.2.
>
> The compiler/linker complained because some symbols are undefined. I 
> noticed that the compiler uses the flag '-undefined suppress'. This 
> won't work unless you also use the flag '-flat_namespace'. OS X 
> (starting from 10.1?) has two-level vs flat namespace for binaries. I 
> don't really understand dynamic loading / linking under OS X, somebody 
> else could probably give you a better idea.
>
> Marcel
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>
--------------------------------------------------------------------------------------------------
"This rotten little race of men measures the world by its own standard. 
It is
lost in the vastness of the Universe, and is consequently afraid of
everything that doesn't happen to fit its own limits."

-- Aleister Crowley, from "Diary of a Drug Fiend."



From maskedrider@earthlink.net  Mon Nov  5 02:53:33 2001
From: maskedrider@earthlink.net (Bryce)
Date: Sun, 4 Nov 2001 19:53:33 -0700
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: <EDB53138-D14F-11D5-BC9D-00050237A0D6@earthlink.net>
Message-ID: <4D3527D9-D198-11D5-9455-00050237A0D6@earthlink.net>

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

Marcel,

Great !!!  Success !!!

I installed Python 2.2 with the magical instructions that you gave to me 
and then I installed Numeric, and then I ran the test.py --->


/usr/local/Numeric-20.2.1/Test-156% python test.py
...............................
----------------------------------------------------------------------
Ran 31 tests in 0.299s

OK


Wow !!! Everything is working !!! I'm so happy !!! Thanks for the 
help !!! You're the best !!!

Bryce


+++++++++++++++++++++++++++++


It seems that the pre-compiled OS X distribution is set up for OS X 
10.0. That's
why it's still complaining about the two level namespace thingy.

Here's what I did to compile Python 2.2:
1. cd <Python dir>
2. ./configure --with-dyld --with-suffix=.exe
3. Edit Modules/Setup, uncomment the single line that says '*shared*'
     (this doesn't seem to be necessary, but others have recommended it)
4. make
5. sudo make install

Numeric is built via the distutils extension in Python. It's located at 
/usr/local/lib/python<version #>/distutils
If you want to change the parameters to cc you'll need to modify the 
Python script(s) in that directory. This is also where cc gets invoked...

Compiling anything on OS X is a bit of a nightmare, I long for the day 
when everything builds out of the box on OS X... and I am still waiting 
for a Python GUI on OS X.

Marcel





On Sunday, November 4, 2001, at 11:15 AM, Bryce wrote:

> Thank you Marcelinus. I will take your suggestion and begin again with 
> python 2.2.
>
> Bryce
>
>
> On Sunday, November 4, 2001, at 10:36 AM, Marcelinus Prastawa wrote:
>
>> FYI, Numeric 20.2.1 is available. It fixes a problem with complex 
>> eigenvalues.
>>
>> I have no problems building NumPy with Python 2.2 on OS X 10.1. You 
>> might want to consider switching to 2.2.
>>
>> The compiler/linker complained because some symbols are undefined. I 
>> noticed that the compiler uses the flag '-undefined suppress'. This 
>> won't work unless you also use the flag '-flat_namespace'. OS X 
>> (starting from 10.1?) has two-level vs flat namespace for binaries. I 
>> don't really understand dynamic loading / linking under OS X, somebody 
>> else could probably give you a better idea.
>>
>> Marcel
>>
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

--Apple-Mail-1-851810022
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Marcel,


Great !!!  Success !!! 


I installed Python 2.2 with the magical instructions that you gave to
me and then I installed Numeric, and then I ran the test.py --->



/usr/local/Numeric-20.2.1/Test-156% python test.py

...............................

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

Ran 31 tests in 0.299s


OK



Wow !!! Everything is working !!! I'm so happy !!! Thanks for the help
!!! You're the best !!!


Bryce



+++++++++++++++++++++++++++++


<color><param>18C6,56BF,FFFF</param>

It seems that the pre-compiled OS X distribution is set up for OS X
10.0. That's

why it's still complaining about the two level namespace thingy.


Here's what I did to compile Python 2.2:

1. cd <<Python dir>

2. ./configure --with-dyld --with-suffix=.exe

3. Edit Modules/Setup, uncomment the single line that says '*shared*'

    (this doesn't seem to be necessary, but others have recommended it)

4. make

5. sudo make install


Numeric is built via the distutils extension in Python. It's located
at /usr/local/lib/python<<version #>/distutils

If you want to change the parameters to cc you'll need to modify the
Python script(s) in that directory. This is also where cc gets
invoked...


Compiling anything on OS X is a bit of a nightmare, I long for the day
when everything builds out of the box on OS X... and I am still
waiting for a Python GUI on OS X.


Marcel




</color>


On Sunday, November 4, 2001, at 11:15 AM, Bryce wrote:


<excerpt>Thank you Marcelinus. I will take your suggestion and begin
again with python 2.2.


Bryce



On Sunday, November 4, 2001, at 10:36 AM, Marcelinus Prastawa wrote:


<excerpt>FYI, Numeric 20.2.1 is available. It fixes a problem with
complex eigenvalues.


I have no problems building NumPy with Python 2.2 on OS X 10.1. You
might want to consider switching to 2.2.


The compiler/linker complained because some symbols are undefined. I
noticed that the compiler uses the flag '-undefined suppress'. This
won't work unless you also use the flag '-flat_namespace'. OS X
(starting from 10.1?) has two-level vs flat namespace for binaries. I
don't really understand dynamic loading / linking under OS X, somebody
else could probably give you a better idea.


Marcel



_______________________________________________

Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org

http://mail.python.org/mailman/listinfo/pythonmac-sig



</excerpt>_______________________________________________

Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org

http://mail.python.org/mailman/listinfo/pythonmac-sig


</excerpt>
--Apple-Mail-1-851810022--



From doug@sonosphere.com  Sun Nov  4 22:21:00 2001
From: doug@sonosphere.com (Doug Wyatt)
Date: Sun, 4 Nov 2001 14:21:00 -0800
Subject: [Pythonmac-SIG] crashes on OS X
Message-ID: <39F247C9-D172-11D5-AD31-00039301A6E6@sonosphere.com>

I used the Unix flavor of 2.1 on X for some time.  I recently installed 
2.2b1 from source, tweaking things only very minimally (I think I only 
added GNU readline).

If I start the Python interpreter in one terminal window, then execute a 
Python script in another, the script bombs (backtrace below).

Before I spend some time trying to debug this, is it a known issue?

If not, first thing I'll try is removing all the Carbon/Toolbox 
modules -- I don't know why _InitHLTB should be on the stack (HLTB = 
High-Level Toolbox); I'm suspecting that one of the Mac-specific dynamic 
modules is invoking Carbon at initialization time.

Failing that I'll spend some time in gdb...

Doug


Date/Time:  2001-11-03 14:16:54 -0800
OS Version: 10.1 (Build 5L9)

Command:    python
PID:        537

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

Thread 0:
  #0   0x70006040 in _spin_lock_try
  #1   0x70197b74 in CFMessagePortCreateRunLoopSource
  #2   0x7319e5f8 in INIT_Processes
  #3   0x7319b794 in _InitHLTB
  #4   0x41108ac0 in call_image_init_routines
  #5   0x41112b0c in _dyld_make_delayed_module_initializer_calls
  #6   0x00001d78 in _call_mod_init_funcs
  #7   0x00001bf8 in _start
  #8   0x00001b6c in start


--
Doug Wyatt
work:  dwyatt@apple.com  (CoreAudio)
personal:  doug@sonosphere.com   http://www.sonosphere.com

"Music and Living----"
"The same thing," said Pooh.
	-- Benjamin Hoff, The Tao of Pooh



From jack@oratrix.nl  Mon Nov  5 09:51:44 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 10:51:44 +0100
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: Message by Just van Rossum <just@letterror.com> ,
 Sun, 4 Nov 2001 08:38:01 +0100 , <20011104083811-r01010800-9cd4faa4-0920-010c@10.0.0.23>
Message-ID: <20011105095144.6B48D303181@snelboot.oratrix.nl>

> I have NumPy working under Python 2.1.1 & 10.0.4. If I remember correctly, all I
> did was run 
> 
> sudo python setup.py install
> 
> in the appropriate Numeric directory. I didn't have to muck with PYTHONPATH,
> didn't install "by hand". Using Numeric's setup.py a directory called Numeric
> and a file called Numeric.pth will be installed in site-packages. That should be
> all there is to it, but I haven't tried this with 2.1 under 10.1...

Just,
why did you use "sudo"? I would advise against that, as it installs stuff as 
root. If you run the setup.py as the same user who installed Python there 
should be no reason to use sudo...
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Mon Nov  5 09:56:19 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 10:56:19 +0100
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: Message by Michael Dunn <mdunn@cantares.on.ca> ,
 Sun, 4 Nov 2001 12:52:49 -0500 , <a05100301b80b2fcd8c9f@[64.7.131.36]>
Message-ID: <20011105095619.80F92303181@snelboot.oratrix.nl>

>     There seems to be a bug in 2.1.  On a number of occasions, I've 
> had a program running in the background, and when I've come back to 
> it, it's crapped out with a KeyboardInterrupt. 

If you're running the Carbon interpreter: this is in the release notes. For 
some unknown reason Carbon MacPython can get spurious KeyboardInterrupts. I 
would very much like to get to the bottom of this, but for reasons unknown it 
has stopped happening to me altogheter since about 2-3 months:-( I'm now 
suspecting some sort of an extension conflict.

Are any other people still seeing these spurious KeyboardInterrupts? If so it 
might be a good idea to compare ASP outputs...

If you're running the classic interpreter this is a new bug, and I'd like to 
hear more.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Mon Nov  5 10:00:56 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 11:00:56 +0100
Subject: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
In-Reply-To: Message by "Kevin Ollivier" <kevino@tulane.edu> ,
 Fri, 2 Nov 2001 13:17:30 -0500 , <009901c163ca$a6df9a20$2101a8c0@kevinnew>
Message-ID: <20011105100056.DB508303181@snelboot.oratrix.nl>

> Also, I've noticed that with my build of Python (2.1.1 built from python.org
> source) there isn't multiple thread support. If I have Python running in one
> terminal and try to start it in another, I get a "Bus error." Anyone know a
> way around this?

This is a nasty Mac OS X 10.1 bug (or a Python bug triggered by 10.1). I fixed 
it in the sourceforge CVS repository, so try building from CVS and the problem 
should be gone.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From just@letterror.com  Mon Nov  5 10:02:04 2001
From: just@letterror.com (Just van Rossum)
Date: Mon,  5 Nov 2001 11:02:04 +0100
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: <20011105095144.6B48D303181@snelboot.oratrix.nl>
Message-ID: <20011105110207-r01010800-17d33ad3-0920-010c@10.0.0.23>

Jack Jansen wrote:

> why did you use "sudo"? I would advise against that, as it installs stuff as 
> root. If you run the setup.py as the same user who installed Python there 
> should be no reason to use sudo...

Erm, I always seem to get "permission denied" errors if I install without sudo.
I haven't a clue...

Just


From jack@oratrix.nl  Mon Nov  5 10:05:11 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 11:05:11 +0100
Subject: [Pythonmac-SIG] Building stuff - another silly newbie question!
In-Reply-To: Message by Chris Scott <kaffeen@mac.com> ,
 Fri, 02 Nov 2001 13:55:22 -0500 , <B808564A.377%kaffeen@mac.com>
Message-ID: <20011105100511.42078303181@snelboot.oratrix.nl>

> I'm sure this is a silly question - but how do you build modules? I've been
> trying like phooey to build the modules that come with pygame in a
> non-carbon format, but I can't seem to do it. Likewise, I've been unable to
> get PyOpenGL to build (version 1.5.7) without errors.

Are you trying to build extensions under MacPython or under OSX commandline 
Python?

For the latter everything should work by simply running setup.py (assuming the 
extension module has one).

For the former that should also work, but distutils support in MacPython is 
not as good as in Unix Python. I would definitely like to hear about problems 
with it. What would work best is a report of what you're trying to install 
(URL where I can download the distribution, please, so I can try for myself) 
and how the build failed.

There's about a 80% chance that the problem is in the setup.py that comes with 
the module, though: often people hard-code Unix pathnames (which also happen 
to sort-of work on Windows) and such. In that case you'll be morally obliged 
to send my feedback on to the module authors:-)
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Mon Nov  5 10:14:39 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 11:14:39 +0100
Subject: [Pythonmac-SIG] Python 2.2b1 on OS X
In-Reply-To: Message by "W.T. Bridgman" <wtbridgman@Radix.Net> ,
 Sun, 4 Nov 2001 09:25:09 -0500 , <p05001900b80afddc753f@[207.192.130.188]>
Message-ID: <20011105101439.8CC9F303181@snelboot.oratrix.nl>

> Okay, I've finally got an OS X partition on my laptop and have run 
> the installer for Python 2.2b1.

I smell confusion here. For OS X there are two distinct Python's:
- MacPython, which comes with an installer, and is essentially the same
  as MacPython on OS 9.
- OS X command line Python (which I tend to also refer to as MachoPython)
  which comes as a tar file with sources for you to compile.

For the time being the two are very different beasts. There are converging, 
but a lot of work remains to be done. They also live in pretty different 
"universes": MacPython has access to all the MacOS windowing, dialog, 
quicktime, etc code, MachoPython less so (for now). MacPython  uses Mac-style 
colon:separated:pathnames, MachoPython /standard/unix/pathnames. They also use 
different low-level runtime architectures (MacOS9-style CFM for MacPython,
the new Mach-O for MachoPython).

> The installer seemed to run fine but when I ran the tests, it crashed 
> when it hit the socket test (I was not connected at the time).  Note 
> that this was running Python by double-clicking the icon.

That's normal, both in MacPYthon and in MachoPython.

> I wondered whether the tests would run better if performed from a 
> terminal window but the installer doesn't seem to do a setup for 
> command-line use.  I suspect I need to do a 'ln -s' on something to 
> somewhere, but what?

This seems to suggest you use MacPython. And for MacPython there is no 
commandline, see the comment above.

> Also, I understand Apple was involved in getting the latest Tcl/Tk 
> ported to OS X.  How does this impact Tkinter running natively under 
> OS X?  Would it be a 'drop-in' installation or is everyone just 
> waiting for wxPython to be ready for prime time?

Well, "drop in" is a bit too easy, but there is work being done to get Tkinter 
working in MachoPython, Tony Lownds is looking at it.

> I've dealt with Unix as a user, but never as an admin.  This strange 
> creature arising from the merger of Unix and MacOS will take some 
> getting used to.

Don't worry, in another year or so most programs will be "Unix Inside", but as 
a Mac-head you'll never notice, because all developers (including us:-) will 
have worked out how to do the .app magic and such.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Mon Nov  5 10:16:01 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 11:16:01 +0100
Subject: [Pythonmac-SIG] crashes on OS X
In-Reply-To: Message by Doug Wyatt <doug@sonosphere.com> ,
 Sun, 4 Nov 2001 14:21:00 -0800 , <39F247C9-D172-11D5-AD31-00039301A6E6@sonosphere.com>
Message-ID: <20011105101601.8A7BF303181@snelboot.oratrix.nl>

> I used the Unix flavor of 2.1 on X for some time.  I recently installed 
> 2.2b1 from source, tweaking things only very minimally (I think I only 
> added GNU readline).
> 
> If I start the Python interpreter in one terminal window, then execute a 
> Python script in another, the script bombs (backtrace below).

This is probably the same Mac OS X 10.1 bug I referred to in a previous 
message. Could you try building from the CVS repository and seeing whether the 
bug is gone then (it should be)?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Mon Nov  5 10:22:10 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 11:22:10 +0100
Subject: [Pythonmac-SIG] Install problem
In-Reply-To: Message by Just van Rossum <just@letterror.com> ,
 Mon, 5 Nov 2001 11:02:04 +0100 , <20011105110207-r01010800-17d33ad3-0920-010c@10.0.0.23>
Message-ID: <20011105102211.2E56F303181@snelboot.oratrix.nl>

> > why did you use "sudo"? I would advise against that, as it installs stuff as 
> > root. If you run the setup.py as the same user who installed Python there 
> > should be no reason to use sudo...
> 
> Erm, I always seem to get "permission denied" errors if I install without sudo.
> I haven't a clue...

Did you install Python under sudo as well? If you did then you indeed have to 
install everything else as root too, but I think this isn't a good idea.

It's then better to remove your whole Python from /usr/local (you'll have to 
use sudo here) and re-install as yourself.

Hmm, I now vaguely seem to remember that there's no /usr/local when you 
install a virgin OS X. If this is indeed the case that this is the one 
directory you have to create as superuser:
  sudo mkdir /usr/local
  sudo chown root.admin /usr/local
  sudo chmod 775 /usr/local
(The "admin" is a guess, not on OSX right now. You should use the 
administrator group).

>From then on any administrator user can install new packages into /usr/local. 
And they'll be owned by that administrative user.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From spierre@altern.org  Mon Nov  5 10:27:09 2001
From: spierre@altern.org (=?ISO-8859-1?Q?S=E9bastien_Pierre?=)
Date: Mon, 5 Nov 2001 11:27:09 +0100
Subject: [Pythonmac-SIG] Command line
Message-ID: <AB53E2FE-D1D7-11D5-8A17-00039344BB54@altern.org>

Hi all,

I would like to know how to get access to the command-line version of=20
MacPython. I have programs that I want to call from the command-line=20
(eg. python Script.py), but it seems like there is no non-GUI=20
interpreter... Does anybody know of such a thing (apart from fink's=20
packages)?

Cheers,

   -- S=E9bastien.



From kaffeen@mac.com  Mon Nov  5 15:43:26 2001
From: kaffeen@mac.com (Chris Scott)
Date: Mon, 05 Nov 2001 10:43:26 -0500
Subject: [Pythonmac-SIG] Building stuff - another silly newbie
 question!
In-Reply-To: <20011105100511.42078303181@snelboot.oratrix.nl>
Message-ID: <B80C1DCE.391%kaffeen@mac.com>

Hi Jack -
Thanks for trying to help, I appreciate it. It's kind of funny, I've found a
whole bunch of tutorials on how to write Python. But not a single one on how
to use it... All this building, installing modules stuff is really quite
foreign to me. Anyway, here goes -

I'm running Python 2.2b1 on a G4 Mac, OS9. I've got Python configured for
Classic since I'm trying to learn Tkinter as well.

I downloaded this file - http://www.pygame.org/ftp/pygame-1.1-src.sit and
let it unstuff automatically.

I run setup_mac.py and it pulls that dialog box and I add the verbose and
build commands (since they're the defaults and I'm not sure what else to do)
and this is what I get:


No Arguments Given, Perform Default Install? [Y/n]y
running build
running build_py
creating build
creating :build:lib.mac-2.2
creating :build:lib.mac-2.2:pygame
copying :lib:__init__.py -> :build:lib.mac-2.2:pygame
copying :lib:cursors.py -> :build:lib.mac-2.2:pygame
copying :lib:locals.py -> :build:lib.mac-2.2:pygame
copying :lib:UserRect.py -> :build:lib.mac-2.2:pygame
copying :lib:version.py -> :build:lib.mac-2.2:pygame
running build_ext
building 'pygame.imageext' extension
    Create export file 244 HD:Applications:Python
2.2b1:pygame-1.1.1:build:temp.mac-2.2:imageext.mcp.exp
    Create XML file 244 HD:Applications:Python
2.2b1:pygame-1.1.1:build:temp.mac-2.2:imageext.xml
    Create project file 244 HD:Applications:Python
2.2b1:pygame-1.1.1:build:temp.mac-2.2:imageext.mcp
Traceback (most recent call last):
  File "244 HD:Applications:Python 2.2b1:pygame-1.1.1:setup_mac.py", line
146, in ?
    apply(setup, [], PACKAGEDATA)
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:core.py", line 138,
in setup
    dist.run_commands()
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:dist.py", line 896,
in run_commands
    self.run_command(cmd)
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:dist.py", line 916,
in run_command
    cmd_obj.run()
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:command:build.py",
line 106, in run
    self.run_command(cmd_name)
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:cmd.py", line 330, in
run_command
    self.distribution.run_command(command)
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:dist.py", line 916,
in run_command
    cmd_obj.run()
  File "244 HD:Applications:Python
2.2b1:Lib:distutils:command:build_ext.py", line 256, in run
    self.build_extensions()
  File "244 HD:Applications:Python
2.2b1:Lib:distutils:command:build_ext.py", line 383, in build_extensions
    self.build_extension(ext)
  File "244 HD:Applications:Python
2.2b1:Lib:distutils:command:build_ext.py", line 475, in build_extension
    build_temp=self.build_temp)
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:ccompiler.py", line
663, in link_shared_object
    extra_preargs, extra_postargs, build_temp)
  File "244 HD:Applications:Python 2.2b1:Lib:distutils:mwerkscompiler.py",
line 195, in link
    mkcwproject.makeproject(xmlfilename, projectfilename)
  File "244 HD:Applications:Python 2.2b1:Mac:Lib:mkcwproject:__init__.py",
line 71, in makeproject
    cw.my_mkproject(prjfss, xmlfss)
  File "244 HD:Applications:Python 2.2b1:Mac:Lib:mkcwproject:cwtalker.py",
line 36, in my_mkproject
    self.make(new=project_document, with_data=xmlfile, as=prjfile)
  File "244 HD:Applications:Python
2.2b1:Mac:Lib:lib-scriptpackages:CodeWarrior:Standard_Suite.py", line 124,
in make
    raise aetools.Error, aetools.decodeerror(_arguments)
aetools.Error: (-1708, 'the AppleEvent was not handled by any handler',
None)

Once that's done I have a "build" folder that contains two other folders:
lib.mac-2.2 and temp.mac-2.2. The lib folder contains a pygame folder with 5
pygame modules (there should be around 20) and the temp folder contains
three files: imageext.mcp.exp, imageext.xml, and mwerks_imageext_config.h.

I copy the pygame folder and it's five modules into my Python folder and add
that folder to the Python prefs file.

When I try to import pygame into Python, I get this:
>>> from pygame import *
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "244 HD:Applications:Python 2.2b1:pygame:__init__.py", line 27, in ?
    from pygame.base import *
ImportError: No module named base

And there I am. It seems like I run into trouble with every module I try to
build. I mentioned before having trouble with pyopengl too. Any help is much
appreciated, and any pointers to where I can go to learn how to actually
work this stuff would be appreciated as well. Thanks!
- Chris




on 11/5/01 5:05 AM, Jack Jansen at jack@oratrix.nl wrote:

>> I'm sure this is a silly question - but how do you build modules? I've been
>> trying like phooey to build the modules that come with pygame in a
>> non-carbon format, but I can't seem to do it. Likewise, I've been unable to
>> get PyOpenGL to build (version 1.5.7) without errors.
> 
> Are you trying to build extensions under MacPython or under OSX commandline
> Python?
> 
> For the latter everything should work by simply running setup.py (assuming the
> extension module has one).
> 
> For the former that should also work, but distutils support in MacPython is
> not as good as in Unix Python. I would definitely like to hear about problems
> with it. What would work best is a report of what you're trying to install
> (URL where I can download the distribution, please, so I can try for myself)
> and how the build failed.
> 
> There's about a 80% chance that the problem is in the setup.py that comes with
> the module, though: often people hard-code Unix pathnames (which also happen
> to sort-of work on Windows) and such. In that case you'll be morally obliged
> to send my feedback on to the module authors:-)
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
> www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
> 
> 



From jack@oratrix.nl  Mon Nov  5 16:01:08 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 05 Nov 2001 17:01:08 +0100
Subject: [Pythonmac-SIG] Building stuff - another silly newbie question!
In-Reply-To: Message by Chris Scott <kaffeen@mac.com> ,
 Mon, 05 Nov 2001 10:43:26 -0500 , <B80C1DCE.391%kaffeen@mac.com>
Message-ID: <20011105160109.7ACE3303181@snelboot.oratrix.nl>

> building 'pygame.imageext' extension
>     Create export file 244 HD:Applications:Python
> 2.2b1:pygame-1.1.1:build:temp.mac-2.2:imageext.mcp.exp
>     Create XML file 244 HD:Applications:Python
> 2.2b1:pygame-1.1.1:build:temp.mac-2.2:imageext.xml
>     Create project file 244 HD:Applications:Python
> 2.2b1:pygame-1.1.1:build:temp.mac-2.2:imageext.mcp
> Traceback (most recent call last):
>   [... traceback removed]

This is where things go wrong: when distutils tries to build the 
pygame.imageext extension this fails. The other problems you see (like not all 
modules being in your install directory) are a result of this: distutils gives 
up after the compile error.

What you should do is manually open the .mcp file in CodeWarrior, try the 
"build" command and seeing why it fails.

The reason you probably overlooked this is because from your message it 
appears that after the build you copy the files manually. This isn't a good 
idea: you should let disutils do the copying with the "install" command. In 
this case it wouldn't have worked, because the build failed, so you would have 
known that things are awry. In general you should let distutils do the 
installing, as it may do more things than just copy the modules over (install 
data files, for instance).
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From wtbridgman@Radix.Net  Mon Nov  5 23:24:54 2001
From: wtbridgman@Radix.Net (W.T. Bridgman)
Date: Mon, 5 Nov 2001 18:24:54 -0500
Subject: [Pythonmac-SIG] Python 2.2b1 on OS X
In-Reply-To: <20011105101439.8CC9F303181@snelboot.oratrix.nl>
References: <20011105101439.8CC9F303181@snelboot.oratrix.nl>
Message-ID: <p05001900b80ccf39e16b@[207.192.129.3]>

Jack,

Thanks for the response.  Before I had OS X running, I didn't pay too 
much attention to threads with OS X focus and didn't catch the change 
in development path.  I did see a mention of it in an ADC e-mail I 
received today.  I've retrieved the other installer and should 
attempt this next.

Thanks,
Tom

>  > Okay, I've finally got an OS X partition on my laptop and have run
>>  the installer for Python 2.2b1.
>
>I smell confusion here. For OS X there are two distinct Python's:
>- MacPython, which comes with an installer, and is essentially the same
>   as MacPython on OS 9.
>- OS X command line Python (which I tend to also refer to as MachoPython)
>   which comes as a tar file with sources for you to compile.
>
>For the time being the two are very different beasts. There are converging,
>but a lot of work remains to be done. They also live in pretty different
>"universes": MacPython has access to all the MacOS windowing, dialog,
>quicktime, etc code, MachoPython less so (for now). MacPython  uses Mac-style
>colon:separated:pathnames, MachoPython /standard/unix/pathnames. They also use
>different low-level runtime architectures (MacOS9-style CFM for MacPython,
>the new Mach-O for MachoPython).
>
>>  The installer seemed to run fine but when I ran the tests, it crashed
>>  when it hit the socket test (I was not connected at the time).  Note
>>  that this was running Python by double-clicking the icon.
>
>That's normal, both in MacPYthon and in MachoPython.
>
>>  I wondered whether the tests would run better if performed from a
>>  terminal window but the installer doesn't seem to do a setup for
>>  command-line use.  I suspect I need to do a 'ln -s' on something to
>>  somewhere, but what?
>
>This seems to suggest you use MacPython. And for MacPython there is no
>commandline, see the comment above.
>
>>  Also, I understand Apple was involved in getting the latest Tcl/Tk
>>  ported to OS X.  How does this impact Tkinter running natively under
>>  OS X?  Would it be a 'drop-in' installation or is everyone just
>>  waiting for wxPython to be ready for prime time?
>
>Well, "drop in" is a bit too easy, but there is work being done to get Tkinter
>working in MachoPython, Tony Lownds is looking at it.
>
>>  I've dealt with Unix as a user, but never as an admin.  This strange
>>  creature arising from the merger of Unix and MacOS will take some
>>  getting used to.
>
>Don't worry, in another year or so most programs will be "Unix Inside", but as
>a Mac-head you'll never notice, because all developers (including us:-) will
>have worked out how to do the .app magic and such.
>--
>Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
>Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
>www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm



From doug@sonosphere.com  Tue Nov  6 06:07:48 2001
From: doug@sonosphere.com (Doug Wyatt)
Date: Mon, 5 Nov 2001 22:07:48 -0800
Subject: [Pythonmac-SIG] crashes on OS X
In-Reply-To: <20011105101601.8A7BF303181@snelboot.oratrix.nl>
Message-ID: <9A2D0566-D27C-11D5-B6D5-00039301A6E6@sonosphere.com>

Jack,

Yes, I raised the issue on an internal mailing list this morning ... the 
questions in the responses led me to go look at SourceForge where I saw 
what you'd fixed recently about linking against CoreServices vs. 
Carbon.  I'll do a CVS checkout soon; I'm pretty sure the problem will 
have gone away.

Thanks!

Doug


On Monday, November 5, 2001, at 02:16 , Jack Jansen wrote:

>> I used the Unix flavor of 2.1 on X for some time.  I recently installed
>> 2.2b1 from source, tweaking things only very minimally (I think I only
>> added GNU readline).
>>
>> If I start the Python interpreter in one terminal window, then 
>> execute a
>> Python script in another, the script bombs (backtrace below).
>
> This is probably the same Mac OS X 10.1 bug I referred to in a previous
> message. Could you try building from the CVS repository and seeing 
> whether the
> bug is gone then (it should be)?
--
Doug Wyatt
work:  dwyatt@apple.com  (CoreAudio)
personal:  doug@sonosphere.com   http://www.sonosphere.com

"to be nobody but yourself in a world which is doing its best night and
  day to make you like everybody else means to fight the hardest battle
  any human being can fight and never stop fighting."
	-- e. e. cummings



From jack@oratrix.nl  Tue Nov  6 10:03:44 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 06 Nov 2001 11:03:44 +0100
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: Message by Michael Dunn <mdunn@cantares.on.ca> ,
 Tue, 6 Nov 2001 02:06:31 -0500 , <a05100302b80d3bf8c5e5@[64.7.130.192]>
Message-ID: <20011106100345.2B195303181@snelboot.oratrix.nl>

> Python 2.1 (#92, Apr 24 2001, 23:59:23)  [CW PPC GUSI2 THREADS] on mac
> Type "copyright", "credits" or "license" for more information.
> >>>

Hmm. So this is either a new bug, or it means that the KeyboardInterrupt bug I 
saw with Carbon-Python is actually a broader problem, and it was pure chance 
that I've only seen it with Carbon-Python.

How repeatable is the problem?
will it always happen when you run your job in the background, or not?
Will it also happen if you run the job in the foreground?
What other programs are you running?
Could you send me your Apple System Profiler output?

Let's end with a question for the whole mailing list: has _anyone_ but Michael 
or me ever seen these spurious KeyboardInterrupts?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From dma@andrew.cmu.edu  Tue Nov  6 15:57:11 2001
From: dma@andrew.cmu.edu (David Andersen)
Date: Tue, 06 Nov 2001 10:57:11 -0500
Subject: [Pythonmac-SIG] RE: Learning on the Mac
In-Reply-To: <B805B088.340%kaffeen@mac.com>
Message-ID: <30782.3214033031@pc48482.mac.cc.cmu.edu>

Has anyone compiled MacPython 2.1.1 with CodeWarrior 7.0 ?

I get (at least) the following compile errors when I try:

Error   : macro 'EDEADLK' redefined
errno.h line 55   #define EDEADLK  11  /* Resource deadlock avoided */

Error   : macro 'EAGAIN' redefined
errno.h line 83   #define EAGAIN  35  /* Resource temporarily unavailable */

Error   : identifier 'int8_t' redeclared
was declared as: 'signed char'
now declared as: 'char'
inttypes.h line 11   typedef char    int8_t;

Error   : illegal function overloading
fcntl.h line 126   FILE * fdopen(int fildes, char *type);






From dma@andrew.cmu.edu  Tue Nov  6 16:05:20 2001
From: dma@andrew.cmu.edu (David Andersen)
Date: Tue, 06 Nov 2001 11:05:20 -0500
Subject: [Pythonmac-SIG] Code Warrior 7.0 ?
Message-ID: <60185.3214033520@pc48482.mac.cc.cmu.edu>

(Sorry if this is a duplicate post)

Has anyone compiled MacPython 2.1.1 with CodeWarrior 7.0 ?

I get (at least) the following compile errors when I try:

Error   : macro 'EDEADLK' redefined
errno.h line 55   #define EDEADLK  11  /* Resource deadlock avoided */

Error   : macro 'EAGAIN' redefined
errno.h line 83   #define EAGAIN  35  /* Resource temporarily unavailable */

Error   : identifier 'int8_t' redeclared
was declared as: 'signed char'
now declared as: 'char'
inttypes.h line 11   typedef char    int8_t;

Error   : illegal function overloading
fcntl.h line 126   FILE * fdopen(int fildes, char *type);








From tony@metanet.com  Tue Nov  6 16:39:00 2001
From: tony@metanet.com (Tony Lownds)
Date: Tue, 6 Nov 2001 08:39:00 -0800
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: <20011106100345.2B195303181@snelboot.oratrix.nl>
References: <20011106100345.2B195303181@snelboot.oratrix.nl>
Message-ID: <a05101000b80dc21a6c96@[204.162.121.110]>

>
>Let's end with a question for the whole mailing list: has _anyone_ but Michael
>or me ever seen these spurious KeyboardInterrupts?

When force-quitting Python.app on OS X I get a KeyboardInterrupt.

-Tony


-- 


From just@letterror.com  Tue Nov  6 16:42:57 2001
From: just@letterror.com (Just van Rossum)
Date: Tue,  6 Nov 2001 17:42:57 +0100
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: <20011106100345.2B195303181@snelboot.oratrix.nl>
Message-ID: <20011106174300-r01010800-8696387f-0920-010c@10.0.0.23>

Jack Jansen wrote:

> Let's end with a question for the whole mailing list: has _anyone_ but Michael 
> or me ever seen these spurious KeyboardInterrupts?

Oh yes. Not yet under X, but in 9.1 definitely.

Just


From mdunn@cantares.on.ca  Tue Nov  6 17:17:49 2001
From: mdunn@cantares.on.ca (Michael Dunn)
Date: Tue, 6 Nov 2001 12:17:49 -0500
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: <20011106100345.2B195303181@snelboot.oratrix.nl>
References: <20011106100345.2B195303181@snelboot.oratrix.nl>
Message-ID: <a05100301b80dc7d83286@[64.7.130.192]>

    At 11:03 AM +0100 2001/11/6, Jack Jansen wrote:
>  > Python 2.1 (#92, Apr 24 2001, 23:59:23)  [CW PPC GUSI2 THREADS] on mac
>>  Type "copyright", "credits" or "license" for more information.
>>  >>>
>
>Hmm. So this is either a new bug, or it means that the KeyboardInterrupt bug I
>saw with Carbon-Python is actually a broader problem, and it was pure chance
>that I've only seen it with Carbon-Python.
>
>How repeatable is the problem?

    I just did some experimentation.  Pressing cmd-period from any app 
I tried (Eudora, Netscape, Finder!) caused a kbd int!  Oddly, when in 
Netscape, all I got was a single-level (outermost) traceback -- no 
kbd int message.  Generally, I see a full (eg 2-level) traceback and 
the int msg.

>will it always happen when you run your job in the background, or not?

    As long as I'm careful about what I press, it will run okay in the 
background.


>Will it also happen if you run the job in the foreground?

    Cmd-period breaks into the program.  Hmmmm, interesting, I get the 
same results as under Netscape (outermost traceback, NO kbdint msg).


>Could you send me your Apple System Profiler output?

    For some reason, the edit and save commands are greyed out, even 
after gathering all information.


    Just for reference, here's the full version:

Traceback (most recent call last):
   File "Big Blue 40GB:User:TmpDL:PythonProgs:UHJEncoder.py", line 512, in ?
     doBtoUHJ(Win,Xin,Yin,UHJout)
   File "Big Blue 40GB:User:TmpDL:PythonProgs:UHJEncoder.py", line 
386, in doBtoUHJ
     SR[c1,:,6]    = sum(SR[c,:,:]*MasterPhaseShiftCoef,1)
KeyboardInterrupt
>>>


From Benjamin.Schollnick@usa.xerox.com  Tue Nov  6 19:57:55 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Tue, 06 Nov 2001 14:57:55 -0500
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
Message-ID: <E2D1934575D1D411973D00508BB02F1730248D@usa0129ms1.ess.mc.xerox.com>

Folks,

	I've mentioned this before, but final found a solution?

	I was getting "Menu ID 256: Already in use
				Fatal TCL/TK Error"....

	(I believe that was the error, I'm paraphrasing, since I don't
	have my notes here...)

	I was using MacPython v2.0, I just installed v2.11, and the
	"Wizard" TK package, is working fine....Without any errors
	(at this point).

	I'm assuming it was either a fix in Python, or a fix in the
	TK/TCL libraries.... Either way, good work Just & the rest
	of the MacPython team.... and the TK folks... But they 
	probably won't see this message...

			- Benjamin


From jack@oratrix.nl  Tue Nov  6 20:27:05 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 06 Nov 2001 21:27:05 +0100
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: Message by Tony Lownds <tony@metanet.com> ,
 Tue, 6 Nov 2001 08:39:00 -0800 , <a05101000b80dc21a6c96@[204.162.121.110]>
Message-ID: <20011106202710.7C94D11E4A1@oratrix.oratrix.nl>

Recently, Tony Lownds <tony@metanet.com> said:
> >
> >Let's end with a question for the whole mailing list: has _anyone_ but Micha
> el
> >or me ever seen these spurious KeyboardInterrupts?
> 
> When force-quitting Python.app on OS X I get a KeyboardInterrupt.

Oops, I was talking about MacPython, and on OS9. That's where I used
to get the spurious KeyboardInterrupts. And I _think_ Michael was also
talking about MacPython on OS9, right?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From Benjamin.Schollnick@usa.xerox.com  Tue Nov  6 20:37:15 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Tue, 06 Nov 2001 15:37:15 -0500
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
Message-ID: <E2D1934575D1D411973D00508BB02F1730248F@usa0129ms1.ess.mc.xerox.com>

Is there any known issues with the following modules?

	tkMessageBox
	tkFileDialog

I realize there are true Macintosh replacements/ equivalents, but I'm
attempting to make cross-platform code, which means that I'm limited by the
PC python code.

    if handle == None:
        rootWindow = Tkinter.Tk()
        rootWindow.withdraw()
        flag = tkMessageBox.askyesno (title = "Modify Previous INI File?",
                                      message = "Do you wish to load a
previously created INI File?")
        if flag:
            filename = tkFileDialog.askopenfilename()
            if filename <> "":
                handle = ConfigParser.ConfigParser()
                handle.read (filename)

The above code, will cause a TK/Tcl panic on the macintosh (Macpython v2.11,
OS v9.21), which forces me to Force Quit the program...

If I comment out the entire sequence, we're fine....

The error is:

	Menu ID 256 is already in use! Fatal Python Error: Tcl/Tk Panic

Any suggestions are MORE than welcome...

		- Benjamin



-----Original Message-----
From: Schollnick, Benjamin [mailto:Benjamin.Schollnick@usa.xerox.com]
Sent: Tuesday, November 06, 2001 2:58 PM
To: pythonmac-sig@python.org
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?


Folks,

	I've mentioned this before, but final found a solution?

	I was getting "Menu ID 256: Already in use
				Fatal TCL/TK Error"....

	(I believe that was the error, I'm paraphrasing, since I don't
	have my notes here...)

	I was using MacPython v2.0, I just installed v2.11, and the
	"Wizard" TK package, is working fine....Without any errors
	(at this point).

	I'm assuming it was either a fix in Python, or a fix in the
	TK/TCL libraries.... Either way, good work Just & the rest
	of the MacPython team.... and the TK folks... But they 
	probably won't see this message...

			- Benjamin

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


From jack@oratrix.nl  Tue Nov  6 20:39:46 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 06 Nov 2001 21:39:46 +0100
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: Message by Michael Dunn <mdunn@cantares.on.ca> ,
 Tue, 6 Nov 2001 12:17:49 -0500 , <a05100301b80dc7d83286@[64.7.130.192]>
Message-ID: <20011106203951.DFB0D11E4A1@oratrix.oratrix.nl>

Recently, Michael Dunn <mdunn@cantares.on.ca> said:
> >How repeatable is the problem?
> 
>     I just did some experimentation.  Pressing cmd-period from any app 
> I tried (Eudora, Netscape, Finder!) caused a kbd int!  Oddly, when in 
> Netscape, all I got was a single-level (outermost) traceback -- no 
> kbd int message.  Generally, I see a full (eg 2-level) traceback and 
> the int msg.

Bingo!

You've just found a bug that is approximately 9 years old and that
apparently has never bothered anyone: MacPythons check-for-interrupt
code does a dirty job (actually, it's the dirty job that Apple
suggested long long ago), it scans through the low-level event queue
looking for Command-period. But, of course, it happily ignores whether
it is in the foreground or the background, so any command-period to
any program will also interrupt MacPython.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jack@oratrix.nl  Tue Nov  6 20:52:25 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 06 Nov 2001 21:52:25 +0100
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
In-Reply-To: Message by "Schollnick, Benjamin" <Benjamin.Schollnick@usa.xerox.com> ,
 Tue, 06 Nov 2001 15:37:15 -0500 , <E2D1934575D1D411973D00508BB02F1730248F@usa0129ms1.ess.mc.xerox.com>
Message-ID: <20011106205230.6EFA711E4A1@oratrix.oratrix.nl>

Benjamin,
what you could try is seeing if you can find out who created this menu
256, then we can try to resolve the conflict. If you do
>>> import Carbon.Menu (or import Menu in 2.1.1)
>>> h = Carbon.Menu.GetMenuHandle(256)
>>> print `h.as_Resource().data`

*after* Tk complains (use the "inter interactive mode after script" if
needed) you should see the raw data of the menu with ID 256. This may
tell you who created the menu.

My guess: a third-party menu extension (I've seen Palm Menu
misbehave), but we'll see.

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From dpreston@intersight.com  Tue Nov  6 21:20:27 2001
From: dpreston@intersight.com (Donovan Preston)
Date: Tue, 6 Nov 2001 13:20:27 -0800
Subject: [Pythonmac-SIG] Carbon events in an interrupt-level routine
Message-ID: <1998784C-D2FC-11D5-B361-0050E425C324@intersight.com>

This is part of a message I got from Carbon-dev:

From: "Paul Lalonde" <paullalonde@mac.com>
<snip>
 >>From: Jim Myers <jim@transcena.com>
<snip>
 >>No where can I find any documentation telling me which Carbon calls are
 >>interrupt safe (if any). Can someone point me to the resource somewhere
 >>telling me which Carbon and/or Carbon event calls are interrupt safe?
 >>Finding this type of info has proven fruitless after many hours of
 >>searching.
 >
 >AFAIK, none of the Carbon Event calls are documented to be 
interrupt-safe,
 >although as Eric S. said in a previous post, on X it's not an issue.  
OTOH,
 >a handful of MP calls *are* interrupt-safe (MPSignalSemaphore & co.), 
which
 >is why I used them in my solution.

Well, there goes my idea of having GUSI send MacPython a Carbon Event 
upon I/O completion. In retrospect, it wasn't really the greatest idea 
anyway. So, the likelihood of removing all WaitNextEvent calls from 
MacPython (on OS 9 anyway) seems rather low. However, since it is 
possible to install Carbon Event handlers and still run a WaitNextEvent 
loop, that's OK.

However, there remains the issue of GUSI not being threadsafe on OS X. 
This means that MacPython CFM on Mac OS X is continually generating race 
conditions that probably cause it to eventually crash even on 
single-processor machines. There are two solutions to this problem 
(remember, this is only a problem on X, not on 9):

1) Fix GUSI so that it is thread safe on X by installing mutex locks 
around critical code sections.

2) Swap out GUSI for the native BSD socket libraries. This is the path 
that Mach-O MacPython will take us to.

Personally I vote for #2, as it's a desirable goal anyway because of all 
the other benefits it gives us. As I mentioned to Jack before, as soon 
as the WASTE and Scrap modules are available to Mach-O MacPython, we 
should be able to just run the IDE from a bundled Mach-O python binary. 
Very cool.

Jack: I am going to hopefully have some time this week to spend on this 
task. My goal is to have the IDE up and running in a Bundle, and then we 
can take a look at converting the W code to CarbonEvents. I'm not sure 
how much of a benefit this will be as it complicates the code base 
tremendously if we want to continue to support non-carbon CFM. We'll 
have to wait and see.

Donovan



From erik@letterror.com  Tue Nov  6 21:15:40 2001
From: erik@letterror.com (Erik van Blokland)
Date: Tue,  6 Nov 2001 22:15:40 +0100
Subject: [Pythonmac-SIG] Intercepting kbd ints
In-Reply-To: <20011106203951.DFB0D11E4A1@oratrix.oratrix.nl>
Message-ID: <20011106221545-r01010800-5b5e65d6-0910-0108@192.168.128.6>

jack@oratrix.nl (Jack Jansen): [11/6/01 at 9:39 PM]

> it scans through the low-level event queue
> looking for Command-period. But, of course, it happily ignores whether
> it is in the foreground or the background, so any command-period to
> any program will also interrupt MacPython.

Hot Dang! this would explain a couple of things...

Erik
--
www.letterror.com
Type & Typography


From just@letterror.com  Tue Nov  6 23:17:58 2001
From: just@letterror.com (Just van Rossum)
Date: Wed,  7 Nov 2001 00:17:58 +0100
Subject: [Pythonmac-SIG] Carbon events in an interrupt-level routine
In-Reply-To: <1998784C-D2FC-11D5-B361-0050E425C324@intersight.com>
Message-ID: <20011107001833-r01010800-12e862a4-0920-010c@10.0.0.23>

Donovan Preston wrote:

> Jack: I am going to hopefully have some time this week to spend on this 
> task. My goal is to have the IDE up and running in a Bundle, and then we 

That would be awesome! Today I built the Python.framework and Python.app, for
fun dropped the IDE main file onto it. It tracebacked on
MacOS.EnableAppswitch()... (These calls should go away anyway.) Maybe the
hardest part is to get Waste up and running? Dunno. Let me know if you have any
luck with that.

> can take a look at converting the W code to CarbonEvents. I'm not sure 
> how much of a benefit this will be as it complicates the code base 
> tremendously if we want to continue to support non-carbon CFM. We'll 
> have to wait and see.

Hm, I can see not supporting classic anymore in some near future...

Just


From jack@oratrix.nl  Tue Nov  6 23:57:49 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 07 Nov 2001 00:57:49 +0100
Subject: [Pythonmac-SIG] Carbon events in an interrupt-level routine
In-Reply-To: Message by Just van Rossum <just@letterror.com> ,
 Wed, 7 Nov 2001 00:17:58 +0100 , <20011107001833-r01010800-12e862a4-0920-010c@10.0.0.23>
Message-ID: <20011106235754.7BFEF11E4A1@oratrix.oratrix.nl>

Recently, Just van Rossum <just@letterror.com> said:
> > can take a look at converting the W code to CarbonEvents. I'm not sure 
> > how much of a benefit this will be as it complicates the code base 
> > tremendously if we want to continue to support non-carbon CFM. We'll 
> > have to wait and see.
> 
> Hm, I can see not supporting classic anymore in some near future...

I haven't looked at it closely, but I think most of the CarbonEvents
vs. Classic Events differences will be in FrameWork. So a possible
route to take would be to duplicate FrameWork (FrameWork_Classic and
FrameWork_Carbon, with a modeul FrameWork that simply does an import *
from either, based on the value of MacOS.runtimemodel).

The Carbon framework could then be modified to use carbon events. If
this turns out to change the FrameWork API and it is easy to backport
this API change to classic framework: fine. If it turns out this is
not easy we skip it, but we don't commit the changes to FrameWork
until after the 2.2 release. 2.2 will then be the last classic release
(which it will probably be anyway).

Another change FrameWork would benefit from is if it adopted the
Carbon Menu/Command stuff.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From Benjamin.Schollnick@usa.xerox.com  Wed Nov  7 12:31:33 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 07 Nov 2001 07:31:33 -0500
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
Message-ID: <E2D1934575D1D411973D00508BB02F17302491@usa0129ms1.ess.mc.xerox.com>

Jack,

	I was going to do some more experimentation before I
	replied...But...

	The problem with this is, that MacPython lockups the
	entire system after the Panic message.

	I am forced to "Force-Quit" the MacPython application
	to regain control...

	But before I left work, I found something out...

    if handle == None:
        rootWindow = Tkinter.Tk()
        rootWindow.withdraw()

	If I comment out the    rootWindow.withdraw()
	everything works, without any evident problems...

	Now I see this being a slight problem....

		1) It works on CPython on the PC...
		2) The "Rootwindow", aka the Tkinter Console
			window, is visible.... I don't like that
			extra window being visible...

	Is there some reason that code should be causing a problem?
	(Am I coding something wrong with the withdraw?  Is there
	a better way?)

	(BTW Jack, thanks for the quick reply, hopefully this isn't
	too bad of a issue...)

			- Benjamin

-----Original Message-----
From: Jack Jansen [mailto:jack@oratrix.nl]
Sent: Tuesday, November 06, 2001 3:52 PM
To: Schollnick, Benjamin
Cc: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?


Benjamin,
what you could try is seeing if you can find out who created this menu
256, then we can try to resolve the conflict. If you do
>>> import Carbon.Menu (or import Menu in 2.1.1)
>>> h = Carbon.Menu.GetMenuHandle(256)
>>> print `h.as_Resource().data`

*after* Tk complains (use the "inter interactive mode after script" if
needed) you should see the raw data of the menu with ID 256. This may
tell you who created the menu.

My guess: a third-party menu extension (I've seen Palm Menu
misbehave), but we'll see.

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


From jack@oratrix.nl  Wed Nov  7 13:47:15 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 07 Nov 2001 14:47:15 +0100
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
In-Reply-To: Message by "Schollnick, Benjamin" <Benjamin.Schollnick@usa.xerox.com> ,
 Wed, 07 Nov 2001 07:31:33 -0500 , <E2D1934575D1D411973D00508BB02F17302491@usa0129ms1.ess.mc.xerox.com>
Message-ID: <20011107134716.80333303181@snelboot.oratrix.nl>

> 	But before I left work, I found something out...
> 
>     if handle == None:
>         rootWindow = Tkinter.Tk()
>         rootWindow.withdraw()
> 
> 	If I comment out the    rootWindow.withdraw()
> 	everything works, without any evident problems...

Benjamin,
I'm completely out of my depth here. Maybe you should ask the MacTk crowd 
whether they know of any problems in this area?

Now that you say that rootWindow.withdraw() is involved it could be some sort 
of a mess up inside Tk (something along the lines that the rootwindow actually 
created the menu with ID 256, but that Tk forgot all about this when it did 
the withdraw(), or so).
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From Benjamin.Schollnick@usa.xerox.com  Wed Nov  7 14:10:06 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 07 Nov 2001 09:10:06 -0500
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
Message-ID: <E2D1934575D1D411973D00508BB02F17302495@usa0129ms1.ess.mc.xerox.com>

Jack,

	So am I completely out of my depth...

	Where can I reach the MacTK crowd?  I haven't investigated
	TK seriously, so I don't know where to look...

		- Benjamin

-----Original Message-----
From: Jack Jansen [mailto:jack@oratrix.nl]
Sent: Wednesday, November 07, 2001 8:47 AM
To: Schollnick, Benjamin
Cc: 'Jack Jansen'; pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?



> 	But before I left work, I found something out...
> 
>     if handle == None:
>         rootWindow = Tkinter.Tk()
>         rootWindow.withdraw()
> 
> 	If I comment out the    rootWindow.withdraw()
> 	everything works, without any evident problems...

Benjamin,
I'm completely out of my depth here. Maybe you should ask the MacTk crowd 
whether they know of any problems in this area?

Now that you say that rootWindow.withdraw() is involved it could be some
sort 
of a mess up inside Tk (something along the lines that the rootwindow
actually 
created the menu with ID 256, but that Tk forgot all about this when it did 
the withdraw(), or so).
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm




_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


From Benjamin.Schollnick@usa.xerox.com  Wed Nov  7 15:11:33 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 07 Nov 2001 10:11:33 -0500
Subject: [Pythonmac-SIG] BuildApplication not terminating?
Message-ID: <E2D1934575D1D411973D00508BB02F17302496@usa0129ms1.ess.mc.xerox.com>

Anyone else seeing any problems with BuildApplication (classic) with Python
v2.11?

Basically, I attempted to build the TK application that I'm fighting with...
(I finally found a scenario where it'll work... But I'm going to research
the TK side, I dislike the work arounds I'm using)....

The first time, I resulted with a Out of Memory error... But the
BuildApplication didn't seem to fully quit... The Window said
"Terminated..." but the system (File, edit, etc) menu bar, didn't return...I
was unable to quit  through the hotkey or Cmd-. .

I ended up Force Quiting....I increased the memory partition, and it build
the application fine.... But once again, it said it terminated but didn't
display the menu bar, etc.... With the same results... (ended up force
quiting).

Now the application is built fine, and works....

But has anyone else seen this?

Other notable issues:

	- Build Application (app) has a generic icon, and 
		doesn't accept drag 'n drop.  (Haven't yet rebuilt the
desktop)

	- The Build Application (script) is significantly faster in
		detecting the list of modules used by application.

	- The Script also seems to finish fine.  So I suspect that there
		maybe a damaged BuildApplication Applet?

		- Benjamin


From Benjamin.Schollnick@usa.xerox.com  Wed Nov  7 15:12:24 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 07 Nov 2001 10:12:24 -0500
Subject: [Pythonmac-SIG] Tkinter Version?
Message-ID: <E2D1934575D1D411973D00508BB02F17302497@usa0129ms1.ess.mc.xerox.com>

Is there a simple way for me to tell what version of Tkinter is included
in the MacPython packages?

		- Benjamin


From jack@oratrix.nl  Wed Nov  7 15:16:53 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 07 Nov 2001 16:16:53 +0100
Subject: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?
In-Reply-To: Message by "Schollnick, Benjamin" <Benjamin.Schollnick@usa.xerox.com> ,
 Wed, 07 Nov 2001 09:10:06 -0500 , <E2D1934575D1D411973D00508BB02F17302495@usa0129ms1.ess.mc.xerox.com>
Message-ID: <20011107151653.81C24303181@snelboot.oratrix.nl>

> 	Where can I reach the MacTK crowd?  I haven't investigated
> 	TK seriously, so I don't know where to look...

The mailing list where all the action is (well... what little action there 
is:-) is tcl-mac@lists.sourceforge.net . You might want to check out the 
archives first, I follow the list with half an eye, and I remember having seen 
things over the years about menu problems on the Mac.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From Benjamin.Schollnick@usa.xerox.com  Wed Nov  7 16:25:52 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 07 Nov 2001 11:25:52 -0500
Subject: [Pythonmac-SIG] Red Herring Alert!  Found core issue w/Tk...
Message-ID: <E2D1934575D1D411973D00508BB02F1730249B@usa0129ms1.ess.mc.xerox.com>

Jack,

	Quick question...

	And you might not be able to help with this one...

	Is there any reason that Tkinter (Tkinter.Tk()) Initialization
	might fail, if it already exists?

	i.e.

		Test = Tkinter.Tk()
		Test2 = Tkinter.Tk()

	What was happening was that I initialized Tk, and then
	I didn't pass the Root to the Wizard GUI package... Which
	then initialized it again...

	But, as I am apt to do, this does not cause an issue on the
	PC Python (Cpython)....

	I already posted a (incorrect) inquiry on the mac-tcl list,
	but will follow that up....

	But, I assume this is a Tcl core issue?  And what version of
	Tcl did Python v2.11 ship with?

			- Benjamin

-----Original Message-----
From: Jack Jansen [mailto:jack@oratrix.nl]
Sent: Wednesday, November 07, 2001 10:17 AM
To: Schollnick, Benjamin
Cc: 'Jack Jansen'; pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Macintosh TK / Fatal Error, fix?



> 	Where can I reach the MacTK crowd?  I haven't investigated
> 	TK seriously, so I don't know where to look...

The mailing list where all the action is (well... what little action there 
is:-) is tcl-mac@lists.sourceforge.net . You might want to check out the 
archives first, I follow the list with half an eye, and I remember having
seen 
things over the years about menu problems on the Mac.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm




_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


From alexp@strata.com  Wed Nov  7 17:41:06 2001
From: alexp@strata.com (Alexandre Parenteau)
Date: Wed, 07 Nov 2001 09:41:06 -0800
Subject: [Pythonmac-SIG] Code Warrior 7.0 ?
In-Reply-To: <60185.3214033520@pc48482.mac.cc.cmu.edu>
Message-ID: <B80EB232.3E2C%alexp@strata.com>

David,

I can try to reply to this one.

We've been working this couple of days with Matthias Neeracher (GUSI) and
Jack in order to add support for CW7 and Carbon to GUSI and we asked
Matthias to help us figuring out the major problem we have on OSX right now
which is due to a thread synchronization problem inside GUSI.

In fact if you feel adventurous, you can try to compile GUSI yourself from
CVS using the branch 'CARBON-BRANCH' (gusi is on SourceForge).

I'm confident we should have support for CW7 soon, Jack told the list he
should receive a copy of CW7 pretty soon.

Hope it answers your question.

Alex.

> (Sorry if this is a duplicate post)
> 
> Has anyone compiled MacPython 2.1.1 with CodeWarrior 7.0 ?
> 
> I get (at least) the following compile errors when I try:
> 
> Error   : macro 'EDEADLK' redefined
> errno.h line 55   #define EDEADLK  11  /* Resource deadlock avoided */
> 
> Error   : macro 'EAGAIN' redefined
> errno.h line 83   #define EAGAIN  35  /* Resource temporarily unavailable */
> 
> Error   : identifier 'int8_t' redeclared
> was declared as: 'signed char'
> now declared as: 'char'
> inttypes.h line 11   typedef char    int8_t;
> 
> Error   : illegal function overloading
> fcntl.h line 126   FILE * fdopen(int fildes, char *type);
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From Benjamin.Schollnick@usa.xerox.com  Thu Nov  8 13:08:02 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Thu, 08 Nov 2001 08:08:02 -0500
Subject: [Pythonmac-SIG] TK Issues, answer from mac-tk list
Message-ID: <E2D1934575D1D411973D00508BB02F173024A0@usa0129ms1.ess.mc.xerox.com>

Jack (& Everyone else),

> First off, Tcl/Tk is not designed to allow you to load two independent 
> copies of Tk into an application.  There is global state in the 
> libraries that will cause conflicts.  So you have to make sure that you 
> unload the first copy completely before you try to load the second 
> copy.  You can create two tcl interpreters, both running Tk, but the way 
> you are supposed to do that is to create one interpreter, and then load 
> Tk into the second interpreter by running "package require Tk" in the 
> second interpreter.  This is, for example, how the console window in 
> MacTk works.  But we never intended you to be able to actually load the 
> Tk library twice.

> Theoretically, you could load Tk, then unload it. However, I never 
> worked very hard to make sure that you could unload Tcl/Tk from an app, 
> and then reload it again cleanly.  There are finalization routines for 
> all the subsystems, but I would have no problem believing they don't 
> clean up everything.  The only things I really cared about was 
> non-shared state, and resources that the system would not reap when the 
> process exited.  You could probably fix this - since the mechanism to 
> handle finalization is present.

We definetly have a difference between MacPython & Cpython here...

import Tkinter
test = Tkinter.Tk()
test2 = Tkinter.Tk()

On the PC, this will work fine...

On the Mac, it reports a Tcl/Tk Fatal error, and Panic's.... Locking up the
entire Macintosh (But it does allow a Force Quit)...

I now have an answer and can effectively code around this, but if we're
trying to allow platform indepence for our code, this may need to be
addressed.
At least now, we know it's a Tcl/Tk issue and not a MacPython issue (that
happens to occur in the Tcl/Tk code).

I haven't really examined the Python code in the Tkinter module to closely,
but....

>From what I see in the code, it each Tkinter.Tk() call creates a total new
interpreter, etc....  I'm not sure what we can do, to prevent this error
from occurring...

	* Patch the code, to prevent an 2nd initialization of the Tk
routines.
		That would involve creating a global counter in the Tkinter
module
		and incrementing / decrementing per initialization /
destroy.

	* Formalize a "shutdown" mechanism for Tkinter, that is called as
part
		of the initialization routine.  (To ensure any previous
Tkinter
		sessions are de-activated.)  The closest I could find was
the
		destroy command, but that appears to be a per window
basis...
		(How do you clean up after a Tkinter session?)

Either way, I see these "work arounds" causing code issues between the other
Tkinter/Python platforms. Sadly, I'm not versed enough in Tkinter to be
confident that any of these work arounds would be useful...

			- Benjamin


From Benjamin.Schollnick@usa.xerox.com  Thu Nov  8 15:30:42 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Thu, 08 Nov 2001 10:30:42 -0500
Subject: [Pythonmac-SIG] (no subject)
Message-ID: <E2D1934575D1D411973D00508BB02F173024A2@usa0129ms1.ess.mc.xerox.com>

How's in charge of the Documentation?

I'd suggest a slight change in FINDERTOOLS.py.

The Move function is documented as:

"Copy a file to a folder"

I'd suggest a change

"""Copy a File to a folder, src = full filepathname, dst = full path to
folder"""

I misunderstood and was trying to pass the destination as the full
filepathname of the new file.

(i.e.

src = os v9.1:desktop:shirow:arms1.jpg
dst = os v9.1:desktop:shirow:new folder:arms1.jpg

)

Simple but frustrating, until I re-read the comment...

		- Benjamin


From alillich@adobe.com  Thu Nov  8 18:42:03 2001
From: alillich@adobe.com (Alan Lillich)
Date: Thu, 08 Nov 2001 10:42:03 -0800
Subject: [Pythonmac-SIG] Python & MPW ToolServer
Message-ID: <B81011FB.CC%alillich@adobe.com>

I need to port a simple testing framework and am looking at both Perl and
Python.  One of the things I need to do is run simple C stdio programs,
passing in command line arguments and getting a numeric status back.  This
is obvious for UNIX (including Mac OS X) and Windows in either language.
For Mac OS 9 the Perl system function lets you invoke an MPW tool or script
via ToolServer, exactly what I want.  Looking through the Python
documentation and SIG archive, it looks like the Python fork and exec
functions aren't implemented on Mac OS 9, at all let alone using ToolServer.

thanks,
Alan Lillich
Adobe Systems Incorporated



From kevino@tulane.edu  Thu Nov  8 23:51:42 2001
From: kevino@tulane.edu (Kevin Ollivier)
Date: Thu, 8 Nov 2001 18:51:42 -0500
Subject: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
References: <20011105100056.DB508303181@snelboot.oratrix.nl>
Message-ID: <00ec01c168b0$51ecf0e0$2101a8c0@kevinnew>

> This is a nasty Mac OS X 10.1 bug (or a Python bug triggered by 10.1). I
fixed
> it in the sourceforge CVS repository, so try building from CVS and the
problem
> should be gone.

Sorry for the late response! I built from CVS just fine, but the problem
persists. I think it may be an issue with the wxWindows shared library
though - not Python. I can start up two copies of the Python interactive
terminal just fine. It is only when I try to run a wxPython script in two
terminals that I get the bus error. I haven't done extensive testing, but
this is what I have found so far. Is there any way to track down what "Bus
error" means exactly? =)

Thanks,

Kevin



From jack@oratrix.nl  Fri Nov  9 09:20:14 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 09 Nov 2001 10:20:14 +0100
Subject: [wxPython-mac] Re: [Pythonmac-SIG] Re: [wxPython] Compiling
 wxPython on OS X 10.1
In-Reply-To: Message by "Kevin Ollivier" <kevino@tulane.edu> ,
 Thu, 8 Nov 2001 18:51:42 -0500 , <00ec01c168b0$51ecf0e0$2101a8c0@kevinnew>
Message-ID: <20011109092015.6F4EF303181@snelboot.oratrix.nl>

> Sorry for the late response! I built from CVS just fine, but the problem
> persists. I think it may be an issue with the wxWindows shared library
> though - not Python. I can start up two copies of the Python interactive
> terminal just fine. It is only when I try to run a wxPython script in two
> terminals that I get the bus error. I haven't done extensive testing, but
> this is what I have found so far. Is there any way to track down what "Bus
> error" means exactly? =)

Then this may be another example of the bug I ran into, but then again it may 
be something completely different. I'll explain my findings, this may help you 
along.

As of 10.1 Mac OS X is a lot more critical about using Carbon in non-.app 
programs. Apparently this was already officially illegal in 10.0, but only 
since 10.1 are there real problems. One thing you cannot do is include 
window-related portions of Carbon.framework (such as WindowMgr or DialogMgr 
calls) if no window manager is available (ssh connection as another user than 
the person logged in on the desktop, OS X Server, >console style login). You 
will immedeately get
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorInvalidConnection : CGSGetEventPort: Invalid connection
and then a crash.

Even if you do have a window manager it seems calling using Carbon from a 
non-.app program is dangerous. If you call the program once from a terminal 
window everything seems fine. Except of course that a non-.app program can 
open windows, but it can't interact with them, show up in the toolbar, etc 
(you were aware of this, by the way, that you must be a .app style bundle to 
interact with the user?).

But: if you call that same program a second time from a different window you 
will probably get a coredump. Trying to debug this is difficult (when either 
copy is run under gdb everything works fine!), but by tracing library loading 
it seems that the crash is in the initialization of the HIToolbox portion of 
Carbon.

The conclusion of all this is that it seems unsafe to link anything that could 
be run from the commandline against Carbon. If this appears to be the problem 
with wxWindows too the solution is simple: use a .app. If you're hosting this 
in Python already (I think you are, right?) then build the Python.app 
according to the instructions in Mac/OSX/README in the python disitrbuiton.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From Benjamin.Schollnick@usa.xerox.com  Fri Nov  9 12:53:18 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Fri, 09 Nov 2001 07:53:18 -0500
Subject: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.	1
Message-ID: <E2D1934575D1D411973D00508BB02F173024A5@usa0129ms1.ess.mc.xerox.com>

It does sound like a wxWindows library issue...

This is very similiar to the Tkinter issue, that I raised...
(Which is definetly a Tkinter library issue)...
Where two copies of the Tkinter library are used at
once, it kills the system....

		- Benjamin


-----Original Message-----
From: Kevin Ollivier [mailto:kevino@tulane.edu]
Sent: Thursday, November 08, 2001 6:52 PM
To: wxpython-users@lists.wxwindows.org
Cc: wxpython-users@lists.wxwindows.org; Wx-Users;
pythonmac-sig@python.org; wxpython-mac@lists.wxwindows.org
Subject: Re: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X
10.1


> This is a nasty Mac OS X 10.1 bug (or a Python bug triggered by 10.1). I
fixed
> it in the sourceforge CVS repository, so try building from CVS and the
problem
> should be gone.

Sorry for the late response! I built from CVS just fine, but the problem
persists. I think it may be an issue with the wxWindows shared library
though - not Python. I can start up two copies of the Python interactive
terminal just fine. It is only when I try to run a wxPython script in two
terminals that I get the bus error. I haven't done extensive testing, but
this is what I have found so far. Is there any way to track down what "Bus
error" means exactly? =)

Thanks,

Kevin


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig


From kevino@tulane.edu  Fri Nov  9 22:37:14 2001
From: kevino@tulane.edu (Kevin Ollivier)
Date: Fri, 9 Nov 2001 17:37:14 -0500
Subject: [wxPython-mac] Re: [Pythonmac-SIG] Re: [wxPython] Compiling  wxPython on OS X 10.1
References: <20011109092015.6F4EF303181@snelboot.oratrix.nl>
Message-ID: <008301c1696f$154033e0$2101a8c0@kevinnew>

<<snip>>

> The conclusion of all this is that it seems unsafe to link anything that
could
> be run from the commandline against Carbon. If this appears to be the
problem
> with wxWindows too the solution is simple: use a .app. If you're hosting
this
> in Python already (I think you are, right?) then build the Python.app
> according to the instructions in Mac/OSX/README in the python
disitrbuiton.

Thanks for your detailed response!! It was very informative, and as you
already know, this was *exactly* the problem. Like Robin said, it is still
somewhat flaky but at least now we can see that it is flaky. =) And of
course, if we can actually see what the bugs are its easier to trace down
and fix the problem. =) One error I thought I'd throw out to you and the
groups. Messages like the ones below pop up from time to time in the console
when running wxPython apps:

--------------------------------------------------
Nov  9 10:25:54 localhost
/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder:
kCGErrorFailure : _CGSLockAndUpdateWindow: cannot map visRegion shmem

Nov  9 10:25:54 localhost
/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder:
kCGErrorFailure : _CGSLockAndUpdateWindow: cannot map shapeRegion shmem

Nov  9 10:25:54 localhost
/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder:
kCGErrorFailure : _CGSLockAndUpdateWindow: cannot map shapeRegion shmem
----------------------------------------------------

I haven't yet figured out how to reproduce them (it seems to be behaving at
the moment), but my suspicion (since it's the finder throwing errors) is
that this has something to do with the top menubar and it being 'registered'
as an app. Python does not list its name in the top menubar, even when
running a wxPython script, and also the menubars for the wxPython app do not
appear. (Menubars do appear for compiled wxMac applications.) The error
messages (kCGErrorFailure) looked familiar to the ones that occurred with
command line Python, and I thought this may be related to Python.app itself
so I thought I would see if this meant anything to anyone. It also will only
run one copy of Python at a time - it "beeps" if you try to run another
Python script. Any thoughts? Is there a place where code specifying Python's
"behavior" as an app are specified, or are the limitations due to the fact
that it is a CLI app?

I don't yet know too much about building app bundles on OS X, but it looks
like it would be good to learn, so I'll probably do some more poking around
on the subject in the next week or so. Too bad I don't have a Mac at home,
although since I have school work that is probably a VERY bad idea. ^_^;
(One I will no doubt indulge myself in sometime soon though...!)

Thanks again to you, Robin and everyone else for all your help!! It feels
*really* good to get over this hurdle! =) Still more to get through, but
this is one big step closer to making wxPython on Mac a reality!

Kevin





From gherman@darwin.in-berlin.de  Sat Nov 10 11:00:03 2001
From: gherman@darwin.in-berlin.de (Dinu Gherman)
Date: Sat, 10 Nov 2001 12:00:03 +0100
Subject: [Pythonmac-SIG] Python package maker for OS X Installer.app
Message-ID: <3BED08B3.9DEB3176@darwin.in-berlin.de>

Hi,

I'm working on a little Python tool creating OS X packages
(extension .pkg), that Installer.app can use to install any-
thing, sources or binary files, anywhere. These packages are
basically directory wrappers containing an archive created
with pax (instead of tar) plus a few additional resources and 
option files presented and/or used during installation.

If anybody is keen on giving it a try, please email me. There
are a couple of issues left, like generating multi-volume
packages that some more experienced people might be able to
help me with, localised installation resources, and the like. 

Sooner or later, I'd like to include that into distutils, but 
I'm not sure this will be an easy thing to do...

Regards,

Dinu

-- 
Dinu C. Gherman
................................................................
"The world becomes a better place as a result of the refusal
to bend to authority and doctrine." (Noam Chomsky)


From just@letterror.com  Sat Nov 10 11:20:26 2001
From: just@letterror.com (Just van Rossum)
Date: Sat, 10 Nov 2001 12:20:26 +0100
Subject: [Pythonmac-SIG] Python package maker for OS X Installer.app
In-Reply-To: <3BED08B3.9DEB3176@darwin.in-berlin.de>
Message-ID: <20011110122029-r01010800-e6333576-0920-010c@10.0.0.23>

Dinu Gherman wrote:

> I'm working on a little Python tool creating OS X packages
> (extension .pkg), that Installer.app can use to install any-
> thing, sources or binary files, anywhere. These packages are
> basically directory wrappers containing an archive created
> with pax (instead of tar) plus a few additional resources and 
> option files presented and/or used during installation.
> 
> If anybody is keen on giving it a try, please email me. There
> are a couple of issues left, like generating multi-volume
> packages that some more experienced people might be able to
> help me with, localised installation resources, and the like. 

I'd like to learn more about it: right now I know zip about packages. It would
be really nice to have a .pkg that installs UnixPython 2.1.1 (especially now
that it doesn't build anymore under 10.1...).

(OT: I bought BBEdit 6.5 yesterday and am having a blast: you can run unix
scripts directly from BBEdit, and it comes with a tool that lets you open files
with BBEdit from the command line. There's plenty of room for improvement, but
I'm already quite impressed. Very nice Mac/Unix integration. Python syntax
coloring!)

Just


From redbird@rbisland.cx  Sat Nov 10 17:25:44 2001
From: redbird@rbisland.cx (Gordon Worley)
Date: Sat, 10 Nov 2001 12:25:44 -0500
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #893 - 3 msgs
In-Reply-To: <E162bV8-0001mA-00@mail.python.org>
Message-ID: <F893FEDE-D5FF-11D5-9F2D-000A27B4DEFC@rbisland.cx>

http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html
On Saturday, November 10, 2001, at 12:20:26 +0100, Just van Rossum wrote:

> Dinu Gherman wrote:
>
>> I'm working on a little Python tool creating OS X packages
>> (extension .pkg), that Installer.app can use to install any-
>> thing, sources or binary files, anywhere. These packages are
>> basically directory wrappers containing an archive created
>> with pax (instead of tar) plus a few additional resources and
>> option files presented and/or used during installation.
>>
>> If anybody is keen on giving it a try, please email me. There
>> are a couple of issues left, like generating multi-volume
>> packages that some more experienced people might be able to
>> help me with, localised installation resources, and the like.
>
> I'd like to learn more about it: right now I know zip about packages. 
> It would
> be really nice to have a .pkg that installs UnixPython 2.1.1 
> (especially now
> that it doesn't build anymore under 10.1...).

Well, don't get to excited.  You should probably read this Stepwise 
article first:  
http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html.  
Due to some of the reasons mentioned in the article, the Mac GPG project 
was forced to abandon the .pkg and go with good old fashion tar 
installers.  Not that nice, but it's safe.  One thing we have discussed, 
but not done yet, is use the installer's ability to run a script that is 
supposed to be for cleanup and use it instead to install via tar like we 
do now, but so that the user doesn't have to figure out how to use 
gnutar (we try to keep it simple, but there are always a few ...).  The 
effects of packages are real and have affected mine and other user's 
systems, too many to safely ignore.  I should note all the problems lie 
in pax and those .bom files, not the rest of the installer.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From gherman@darwin.in-berlin.de  Sat Nov 10 17:50:51 2001
From: gherman@darwin.in-berlin.de (Dinu Gherman)
Date: Sat, 10 Nov 2001 18:50:51 +0100
Subject: [Pythonmac-SIG] Python package maker for OS X Installer.app
References: <F893FEDE-D5FF-11D5-9F2D-000A27B4DEFC@rbisland.cx>
Message-ID: <3BED68FB.108B17AF@darwin.in-berlin.de>

Gordon Worley wrote:
> 
> Well, don't get to excited.  You should probably read this Stepwise
> article first:
> http://www.stepwise.com/Articles/Technical/Packages/InstallerOnX.html.
> Due to some of the reasons mentioned in the article, the Mac GPG project
> was forced to abandon the .pkg and go with good old fashion tar
> installers.  Not that nice, but it's safe.  One thing we have discussed,
> but not done yet, is use the installer's ability to run a script that is
> supposed to be for cleanup and use it instead to install via tar like we
> do now, but so that the user doesn't have to figure out how to use
> gnutar (we try to keep it simple, but there are always a few ...).  The
> effects of packages are real and have affected mine and other user's
> systems, too many to safely ignore.  I should note all the problems lie
> in pax and those .bom files, not the rest of the installer.

I'm aware of the article, but just have not enough practice
to say how serious that is. So far, I know that I did in-
stall plenty of stuff using Installer.app and haven't en-
countered any problem whatsoever, but ok, maybe I was just
lucky?! In any case, it seems like Apple uses that for more
or less everything, isn't it?

Ironically, it is said that pax was written to fix many 
of the problems of tar... (but not gnutar?) I don't quite 
get why Installer.app could not just execute the "approp-
riate" Unix tool to unarchive whatever the package does
contain...?

Dinu


From dan@biznesshosting.com  Sat Nov 10 19:53:03 2001
From: dan@biznesshosting.com (Dan Grassi)
Date: Sat, 10 Nov 2001 14:53:03 -0500
Subject: [Pythonmac-SIG] Python package maker for OS X Installer.app
In-Reply-To: <3BED68FB.108B17AF@darwin.in-berlin.de>
Message-ID: <8D52A166-D614-11D5-BE31-003065F99F04@grassi.org>

On Saturday, November 10, 2001, at 12:50 PM, Dinu Gherman wrote:

> Ironically, it is said that pax was written to fix many
> of the problems of tar... (but not gnutar?) I don't quite
> get why Installer.app could not just execute the "approp-
> riate" Unix tool to unarchive whatever the package does
> contain...?

Actually it is not necessary to use pax, tar can be used but I'm not 
sure if gnutar can be used other than in a script called by the 
installer.  There are several scripts that are available including 
pre-flight, pre-install/upgrade and post-install/upgrade.

Also, AFAIK the .bom file is not necessary.  The .bom file does provide 
information in the receipt file of what has been installed.

One aspect that is handled is internationalization.

Dan



From jack@oratrix.nl  Sat Nov 10 23:30:25 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Sun, 11 Nov 2001 00:30:25 +0100
Subject: [Pythonmac-SIG] Python package maker for OS X Installer.app
In-Reply-To: Message by Dinu Gherman <gherman@darwin.in-berlin.de> ,
 Sat, 10 Nov 2001 12:00:03 +0100 , <3BED08B3.9DEB3176@darwin.in-berlin.de>
Message-ID: <20011110233031.23A6A1162D7@oratrix.oratrix.nl>

Recently, Dinu Gherman <gherman@darwin.in-berlin.de> said:
> Sooner or later, I'd like to include that into distutils, but 
> I'm not sure this will be an easy thing to do...

Wow, this would be nice! If you look at
Lib/distutils/commands/dist_dumb.py it shouldn't be too hard to model
your installer builder so  that it should easily plug into distutils...
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jack@oratrix.nl  Sat Nov 10 23:37:31 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Sun, 11 Nov 2001 00:37:31 +0100
Subject: [Pythonmac-SIG] Installer builder
In-Reply-To: Message by Gordon Worley <redbird@rbisland.cx> ,
 Sat, 10 Nov 2001 12:25:44 -0500 , <F893FEDE-D5FF-11D5-9F2D-000A27B4DEFC@rbisland.cx>
Message-ID: <20011110233736.BAD071162D7@oratrix.oratrix.nl>

Oh yes, one thing that would be really nice for the installer builder
for OSX: if you can build the installers so that they can install
either into the users home directory or (if the user has the right
permissions) into /. Or, in Apple parlance, into the user domain or
the local domain. The network domain may or may not be interesting
too, I'm not sure, but I think installers behave such that you get
that for free.

For building installers that install Python extensions there's still a
problem, but I don't think we can solve that (so give me hints if you
think we can): if an administrator installed Python into the local
domain and then a Mere Mortal User wants to install a private
extension package Python currently has no good way to deal with
this. Python packages are always installed into the Python tree. The
workaround would be to install into an almost-empty shadow copy of the
Python tree in the users home directory and tell the user to add the
relevant directories to their PYTHONPATH.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jack@oratrix.nl  Sat Nov 10 23:45:51 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Sun, 11 Nov 2001 00:45:51 +0100
Subject: [wxPython-mac] Re: [Pythonmac-SIG] Re: [wxPython] Compiling wxPython on OS X 10.1
In-Reply-To: Message by "Kevin Ollivier" <kevino@tulane.edu> ,
 Fri, 9 Nov 2001 17:37:14 -0500 , <008301c1696f$154033e0$2101a8c0@kevinnew>
Message-ID: <20011110234556.CA27C1162D7@oratrix.oratrix.nl>

Recently, "Kevin Ollivier" <kevino@tulane.edu> said:
> --------------------------------------------------
> Nov  9 10:25:54 localhost
> /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder:
> kCGErrorFailure : _CGSLockAndUpdateWindow: cannot map visRegion shmem
> 
> I haven't yet figured out how to reproduce them (it seems to be behaving at
> the moment), but my suspicion (since it's the finder throwing errors) is
> that this has something to do with the top menubar and it being 'registered'
> as an app. Python does not list its name in the top menubar, even when
> running a wxPython script, and also the menubars for the wxPython app do not
> appear. (Menubars do appear for compiled wxMac applications.)

Interesting. This probably has to do with Python.app not going through
the correct initialization sequence. The main program of Python.app is
simply the main program for MacPython with everything that didn't work
imedeately #ifdeffed out.

If someone could look at the code (Mac/Python/macmain.c) and the
releant Apple documentation and tell me what to do that would be
great. For one, MacPython doesn't initialize the menubar because that
is (a) delayed and (b) handled by SIOUX when it's needed. So we
probably need some stuff for that, but there may be more missing.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From zen@shangri-la.dropbear.id.au  Sun Nov 11 03:11:07 2001
From: zen@shangri-la.dropbear.id.au (Stuart Bishop)
Date: Sun, 11 Nov 2001 14:11:07 +1100
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
In-Reply-To: <20011110122029-r01010800-e6333576-0920-010c@10.0.0.23>
Message-ID: <BFA0480A-D651-11D5-904E-000393031882@shangri-la.dropbear.id.au>

On Saturday, November 10, 2001, at 10:20  PM, Just van Rossum wrote:
> I'd like to learn more about it: right now I know zip about packages. 
> It would
> be really nice to have a .pkg that installs UnixPython 2.1.1 
> (especially now
> that it doesn't build anymore under 10.1...).

I can build 2.1.1 fine under 10.1 (on a UFS partition) using:

env LDFLAGS='-flat_namespace' OPT='-no-cpp-precomp' \
     ./configure --with-dyld
make
make test
sudo make install

Have I missed something?
--
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/



From wolfeman@apple.com  Sun Nov 11 17:44:41 2001
From: wolfeman@apple.com (Dan Wolfe)
Date: Sun, 11 Nov 2001 09:44:41 -0800
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #894 - 7 msgs
In-Reply-To: <E162xye-0003Ke-00@mail.python.org>
Message-ID: <C8F16BC2-D6CB-11D5-8EED-000A27E48932@apple.com>

On Sunday, November 11, 2001, at 09:01 AM, pythonmac-sig-
request@python.org wrote:

> On Saturday, November 10, 2001, at 10:20  PM, Just van Rossum wrote:
>> I'd like to learn more about it: right now I know zip about packages.
>> It would
>> be really nice to have a .pkg that installs UnixPython 2.1.1
>> (especially now
>> that it doesn't build anymore under 10.1...).
>
> I can build 2.1.1 fine under 10.1 (on a UFS partition) using:
>
> env LDFLAGS=3D'-flat_namespace' OPT=3D'-no-cpp-precomp' \
>      ./configure --with-dyld
> make
> make test
> sudo make install
>
> Have I missed something?

a few things... Namely most people are running HFS+, have a limited=20
stack space, have an old ncurses version, etc.  Here's the recipe that I=20=

use to build it... note that I muck with the makefile vs using=20
environmentals... which have an annoying tendency to be forgotten=20
several days later.  The patches are for a) dylibs --> allow zlib to be=20=

found, b) prevent ncurses from building.  I have not pulled the patches=20=

for the thread redefine from the new 2.2 CVS repository (but it doesn't=20=

hurt anyone), nor have I fixed the fcntl case problem yet (haven't=20
needed it - but it apparently it needs to be made part of the core=20
Python vs dynamcially loaded)... :-( These patches should probably make=20=

it into Python 2.1.2....

Installed Python-2.1.1.tgz
=AD gnutar -xvzf Python-2.1.1.tgz
=AD apply the following patchs via % patch
Python-2.1.1/Lib/distutils/unixccompiler.py unixccompiler.py

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file:
/cvsroot/python/python/dist/src/Lib/distutils/unixccompiler.py,v
retrieving revision 1.35
retrieving revision 1.36
diff -c -r1.35 -r1.36
*** python/python/dist/src/Lib/distutils/unixccompiler.py 2001/07/16=20
14:46:
13    1.35
--- python/python/dist/src/Lib/distutils/unixccompiler.py 2001/08/27=20
15:08:
16    1.36
***************
*** 71,77 ****
        obj_extension =3D ".o"
        static_lib_extension =3D ".a"
        shared_lib_extension =3D ".so"
!     static_lib_format =3D shared_lib_format =3D "lib%s%s"



--- 71,78 ----
        obj_extension =3D ".o"
        static_lib_extension =3D ".a"
        shared_lib_extension =3D ".so"
!     dylib_lib_extension =3D ".dylib"
!     static_lib_format =3D shared_lib_format =3D dylib_lib_format =3D
"lib%s%s"



***************
*** 259,264 ****
--- 260,267 ----
            for dir in dirs:
                shared =3D os.path.join(
                    dir, self.library_filename(lib, lib_type=3D'shared'))
+             dylib =3D os.path.join(
+                 dir, self.library_filename(lib, lib_type=3D'dylib'))
                static =3D os.path.join(
                    dir, self.library_filename(lib, lib_type=3D'static'))

***************
*** 266,272 ****
                # data to go on: GCC seems to prefer the shared library,=20=

so I'm
                # assuming that *all* Unix C compilers do.  And of =
course=20
I'm
                # ignoring even GCC's "-static" option.  So sue me.
!             if os.path.exists(shared):
                    return shared
                elif os.path.exists(static):
                    return static
--- 269,277 ----
                # data to go on: GCC seems to prefer the shared library,=20=

so I'm
                # assuming that *all* Unix C compilers do.  And of =
course=20
I'm
                # ignoring even GCC's "-static" option.  So sue me.
!             if os.path.exists(dylib):
!                 return dylib
!             elif os.path.exists(shared):
                    return shared
                elif os.path.exists(static):
                    return static

=AD apply the following patch via % patch
Python-2.1.1/Lib/distutils/ccompiler.py ccompiler.py

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/python/python/dist/src/Lib/distutils/ccompiler.py,v
retrieving revision 1.39
retrieving revision 1.40
diff -c -r1.39 -r1.40
*** python/python/dist/src/Lib/distutils/ccompiler.py 2001/02/27
19:13:15  1.39
--- python/python/dist/src/Lib/distutils/ccompiler.py 2001/08/27
15:08:16  1.40
***************
*** 792,799 ****
                              output_dir=3D''):

            if output_dir is None: output_dir =3D ''
!         if lib_type not in ("static","shared"):
!             raise ValueError, "'lib_type' must be \"static\" or
\"shared\""
            fmt =3D getattr (self, lib_type + "_lib_format")
            ext =3D getattr (self, lib_type + "_lib_extension")

--- 792,799 ----
                              output_dir=3D''):

            if output_dir is None: output_dir =3D ''
!         if lib_type not in ("static","shared","dylib"):
!             raise ValueError, "'lib_type' must be \"static\",
\"shared\" or \"dylib\""
            fmt =3D getattr (self, lib_type + "_lib_format")
            ext =3D getattr (self, lib_type + "_lib_extension")

=AD patch Python-2.1.1/setup.py setup.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.52
retrieving revision 1.53
diff -c -r1.52 -r1.53
*** python/python/dist/src/setup.py   2001/08/22 19:24:42 1.52
--- python/python/dist/src/setup.py   2001/09/04 09:05:11 1.53
***************
*** 451,457 ****
                curses_libs =3D ['ncurses']
                exts.append( Extension('_curses', ['_cursesmodule.c'],
                                       libraries =3D curses_libs) )
!         elif (self.compiler.find_library_file(lib_dirs, 'curses')):
                if (self.compiler.find_library_file(lib_dirs,=20
'terminfo')):
                    curses_libs =3D ['curses', 'terminfo']
                else:
--- 451,458 ----
                curses_libs =3D ['ncurses']
                exts.append( Extension('_curses', ['_cursesmodule.c'],
                                       libraries =3D curses_libs) )
!         elif (self.compiler.find_library_file(lib_dirs, 'curses')) and=20=

platform !=3D 'darwin1':
!             # OSX has an old Berkeley curses, not good enough for the=20=

_curses module.
                if (self.compiler.find_library_file(lib_dirs,=20
'terminfo')):
                    curses_libs =3D ['curses', 'terminfo']
                else:


=AD cd Python-2.1.1/
=AD ./configure --with-dyld --with-suffix=3D.x
=AD change Makefile lines

      OPT=3D            -g -O3 -Wall -Wstrict-prototypes
to
      OPT=3D            -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp
--> Fixes the BSD header problems that have been written up in Apple's=20=

internal bug tracking system and

      LDSHARED=3D       $(CC) $(LDFLAGS) -bundle -undefined suppress
      BLDSHARED=3D      $(CC) $(LDFLAGS) -bundle -undefined suppress
to
      LDSHARED=3D       $(CC) $(LDFLAGS) -bundle -undefined error=20
-bundle_loader ./python.x
      BLDSHARED=3D      $(CC) $(LDFLAGS) -bundle -undefined error=20
-bundle_loader ./python.x
--> Allows linking in two-level namespace world.  Resulting binary will=20=

work under 10.0.x until prebinding tool is run at which time it will=20
barf. Not a big deal as anyone who's running 10.0.x should seriously=20
consider upgrading.  Core OS says that the use of the -flat-namespace is=20=

discouraged and that the use of the bundle_loader is preferred.  There=20=

is no linkage between the bundle_loader name and the library so we can=20=

rename the binary without causing problems....
=AD make
=AD Work around small stack size (512k) which causes test_re and =
test_sre=20
to seg fault
     limit stacksize 2M
=AD make test
=AD sudo make install
=AD cd /usr/local/bin/
=AD sudo mv python.x python
=AD sudo mv python2.1.x python2.1



From jack@oratrix.nl  Mon Nov 12 10:54:38 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 12 Nov 2001 11:54:38 +0100
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker
 for OS X Installer.app]
In-Reply-To: Message by Stuart Bishop <zen@shangri-la.dropbear.id.au> ,
 Sun, 11 Nov 2001 14:11:07 +1100 , <BFA0480A-D651-11D5-904E-000393031882@shangri-la.dropbear.id.au>
Message-ID: <20011112105439.23CC7303181@snelboot.oratrix.nl>

> I can build 2.1.1 fine under 10.1 (on a UFS partition) using:
> 
> env LDFLAGS='-flat_namespace' OPT='-no-cpp-precomp' \
>      ./configure --with-dyld

Ah, great!

> make
> make test
> sudo make install

Why are so many people using "sudo make install"? This is a really bad idea, I 
think, to install Python owned by root, but a lot of people seem to do this. 
Is there something in the documentation somewhere that suggests this? Another 
reason?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Mon Nov 12 11:04:51 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 12 Nov 2001 12:04:51 +0100
Subject: [Pythonmac-SIG] Re: Pythonmac-SIG digest, Vol 1 #894 - 7 msgs
In-Reply-To: Message by Dan Wolfe <wolfeman@apple.com> ,
 Sun, 11 Nov 2001 09:44:41 -0800 , <C8F16BC2-D6CB-11D5-8EED-000A27E48932@apple.com>
Message-ID: <20011112110452.30B1A303181@snelboot.oratrix.nl>

> a few things... Namely most people are running HFS+, have a limited =

> stack space, have an old ncurses version, etc.  Here's the recipe that =
I =

> use to build it... note that I muck with the makefile vs using =

> environmentals... which have an annoying tendency to be forgotten =

> several days later.  The patches are for a) dylibs --> allow zlib to be=
 =

> found, b) prevent ncurses from building.  I have not pulled the patches=
 =

> for the thread redefine from the new 2.2 CVS repository (but it doesn't=
 =

> hurt anyone), nor have I fixed the fcntl case problem yet (haven't =

> needed it - but it apparently it needs to be made part of the core =

> Python vs dynamcially loaded)... :-( These patches should probably make=
 =

> it into Python 2.1.2....

Please submit them to the sourceforge repository for inclusion in 2.1.2. =
Or, =

what would be even better: locate the corresponding fixes in the CVS =

repository and propse that these be included in 2.1.2. Andrew Kuchling is=
 =

working on 2.1.2.

All of the changes you're making are already in the CVS repository (or, a=
t =

least, there are solutions for all the problems your patch solves), if I'=
m not =

mistaken, with one exception: your patch to recognize .dylib. I think a b=
etter =

solution here would be to simply set the extension for shared libraries t=
o =

".dylib" on OSX, in stead of the more common ".so". After all, they're re=
ally =

the same thing, and there are no .so's on OSX.

What do you think?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++=

Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig =
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.=
htm =





From steve@spvi.com  Mon Nov 12 11:37:21 2001
From: steve@spvi.com (Steve Spicklemire)
Date: Mon, 12 Nov 2001 06:37:21 -0500
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker  for OS X Installer.app]
In-Reply-To: <20011112105439.23CC7303181@snelboot.oratrix.nl>
Message-ID: <A2372C50-D761-11D5-B1BC-0050E480B13C@spvi.com>

Hi Jack,

	My naive guess is that folks try "make install", and when that 
fails (since "normal" users aren't allowed to create directories in the 
default area: /usr/local/...) they decide to run the install as root so 
that it will be allowed. Isn't this what most folks do on most unixish 
systems anyway? Is there some security problem with this?

thanks,
-steve

On Monday, November 12, 2001, at 05:54 AM, Jack Jansen wrote:

>
>> I can build 2.1.1 fine under 10.1 (on a UFS partition) using:
>>
>> env LDFLAGS='-flat_namespace' OPT='-no-cpp-precomp' \
>>      ./configure --with-dyld
>
> Ah, great!
>
>> make
>> make test
>> sudo make install
>
> Why are so many people using "sudo make install"? This is a really bad 
> idea, I
> think, to install Python owned by root, but a lot of people seem to do 
> this.
> Is there something in the documentation somewhere that suggests this? 
> Another
> reason?
> --
> Jack Jansen             | ++++ stop the execution of Mumia 
> Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your 
> sig ++++
> www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-
> l/sigaction.htm
>
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig



From jack@oratrix.nl  Mon Nov 12 13:57:49 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 12 Nov 2001 14:57:49 +0100
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker
 for OS X Installer.app]
In-Reply-To: Message by Steve Spicklemire <steve@spvi.com> ,
 Mon, 12 Nov 2001 06:37:21 -0500 , <A2372C50-D761-11D5-B1BC-0050E480B13C@spvi.com>
Message-ID: <20011112135844.1D74C303181@snelboot.oratrix.nl>

> Hi Jack,
> 
> 	My naive guess is that folks try "make install", and when that 
> fails (since "normal" users aren't allowed to create directories in the 
> default area: /usr/local/...) they decide to run the install as root so 
> that it will be allowed. Isn't this what most folks do on most unixish 
> systems anyway? Is there some security problem with this?

Bingo! I knew that I knew why people did this, but I had forgotten. I'll add a 
note to the README that people just do the "sudo mkdir/sudo chown" and then a 
plain make install.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From rellaa@earthlink.net  Mon Nov 12 16:14:33 2001
From: rellaa@earthlink.net (Robert Abernathy)
Date: Mon, 12 Nov 2001 09:14:33 -0700
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker  for OS X Installer.app]
In-Reply-To: <20011112135844.1D74C303181@snelboot.oratrix.nl>
Message-ID: <5C2A8EE8-D788-11D5-AA9E-000393575B76@earthlink.net>

On Monday, November 12, 2001, at 06:57 AM, Jack Jansen wrote:

>> Hi Jack,
>>
>> 	My naive guess is that folks try "make install", and when that
>> fails (since "normal" users aren't allowed to create directories in the
>> default area: /usr/local/...) they decide to run the install as root so
>> that it will be allowed. Isn't this what most folks do on most unixish
>> systems anyway? Is there some security problem with this?
>
> Bingo! I knew that I knew why people did this, but I had forgotten. 
> I'll add a
> note to the README that people just do the "sudo mkdir/sudo chown" and 
> then a
> plain make install.
> --
>
As a unix type program on a mac, I install python into /usr/local.  All 
of the files under
this directory are and should be owned by root.  For the situation of a 
single user, if
they don't want to install as root, they could do a local install in ~/ 
somewhere and this
wouldn't be an issue.  If I were installing a graphical OS Xish version 
of python, I'd
put it in /Applications.  All of the files that go there are still owned 
by root.

Is there a reason I wouldn't want to install the python files as owned 
by root?



From jack@oratrix.nl  Mon Nov 12 20:41:50 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 12 Nov 2001 21:41:50 +0100
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
In-Reply-To: Message by Robert Abernathy <rellaa@earthlink.net> ,
 Mon, 12 Nov 2001 09:14:33 -0700 , <5C2A8EE8-D788-11D5-AA9E-000393575B76@earthlink.net>
Message-ID: <20011112204156.115251162D7@oratrix.oratrix.nl>

Recently, Robert Abernathy <rellaa@earthlink.net> said:
> Is there a reason I wouldn't want to install the python files as owned 
> by root?

Yes, a very good reason. The Unix adagium is (and has always been) to
do as little as humanly possible as root. Taking the /usr/local/python
as an example, if you do a single
   sudo mkdir -m 775 /usr/local
then from that time on you can install anything into /usr/local using
your own account (administrators are allowed to write to directories
owned by group "wheel", the same group as root is in, but with no
inherent extra security risks).

The alternative is that you do a "sudo make install" for every package
you will ever want to install in /usr/local. This means that for every
package you install you have to trust the authors of the (often very
complex) makefiles to not have put a trojan horse in there. Or (why
blame on malevolence what you can blame on stupidity:-) not to have
made stupid errors. And stupid errors happen: Apple's own iTunes 2.0
installer wiped your disk if you happened to install it on a
non-system-disk with a space in the name just last weekend!
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From wolfeman@apple.com  Tue Nov 13 00:00:08 2001
From: wolfeman@apple.com (Dan Wolfe)
Date: Mon, 12 Nov 2001 16:00:08 -0800
Subject: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
In-Reply-To: <20011112110452.30B1A303181@snelboot.oratrix.nl>
Message-ID: <66B8EC5E-D7C9-11D5-A744-003065E3B1C6@apple.com>

On Monday, November 12, 2001, at 03:04 AM, Jack Jansen wrote:

>> a few things... Namely most people are running HFS+, have a limited
>> stack space, have an old ncurses version, etc.  Here's the recipe 
>> that I
>> use to build it... note that I muck with the makefile vs using
>> environmentals... which have an annoying tendency to be forgotten
>> several days later.  The patches are for a) dylibs --> allow zlib to be
>> found, b) prevent ncurses from building.  I have not pulled the patches
>> for the thread redefine from the new 2.2 CVS repository (but it doesn't
>> hurt anyone), nor have I fixed the fcntl case problem yet (haven't
>> needed it - but it apparently it needs to be made part of the core
>> Python vs dynamcially loaded)... :-( These patches should probably make
>> it into Python 2.1.2....
>
> Please submit them to the sourceforge repository for inclusion in 
> 2.1.2. Or,
> what would be even better: locate the corresponding fixes in the CVS
> repository and propse that these be included in 2.1.2. Andrew Kuchling 
> is
> working on 2.1.2.

done.  Humm I'm not sure how people prefer to reference particular 
patches but  this should be good enough to let Andrew know which patches 
need to be included. (FYI, there are three patches - one for the source 
patches, one for the makefile changes - which need to be converted to 
configure changes and one for the readme....)

> All of the changes you're making are already in the CVS repository (or, 
> at
> least, there are solutions for all the problems your patch solves), if 
> I'm not
> mistaken, with one exception: your patch to recognize .dylib.

Nope it's in CVS... Bill Noon suggested it...

> I think a better solution here would be to simply set the extension for 
> shared libraries to
> ".dylib" on OSX, in stead of the more common ".so". After all, they're 
> really
> the same thing, and there are no .so's on OSX.
>
> What do you think?

Well, I just did a quick search of my drive and the only .so's that I 
have other than Python are
	a) apache modules that came with the system and
	b) those unix packages that I've installed myself (readline, bzip, 
expat).

While it's probably a great idea to use the ".dylib" extension for all 
Mac OS X shared libraries, I'm not sure if I'm up to modifying all the 
Unix packages that use .so's so that python or some other package looks 
for for them can find them. ;-)  In other words, if we modified python 
to handle only dylibs then we need to modify every other package to emit 
dylibs so that python can find them.  And since both of them work, I'll 
take the easy way out and just go for allowing both .so and .dylibs on 
Mac OS X.  I think this is the reason that I think Fred didn't convert 
the apache modules to .dylibs....

Bottom line only reason that I included this patch was that it allows 
the system zlib dylib to be used and therefore my zlib tests don't 
fail.  :-)

- Dan




From zen@shangri-la.dropbear.id.au  Tue Nov 13 00:06:59 2001
From: zen@shangri-la.dropbear.id.au (Stuart Bishop)
Date: Tue, 13 Nov 2001 11:06:59 +1100
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker  for OS X Installer.app]
In-Reply-To: <20011112105439.23CC7303181@snelboot.oratrix.nl>
Message-ID: <5BB34F92-D7CA-11D5-9F4B-000393031882@shangri-la.dropbear.id.au>

On Monday, November 12, 2001, at 09:54  PM, Jack Jansen wrote:
> Why are so many people using "sudo make install"? This is a really bad 
> idea, I
> think, to install Python owned by root, but a lot of people seem to do 
> this.
> Is there something in the documentation somewhere that suggests this? 
> Another
> reason?
>

The idea is to have all the binaries owned by the root user, so a 
standard account
cannot modify them. This way they cannot be corrupted accidently, 
converted to
trojans or infected by a virus without knowing the superuser password.

A better approach is to install the software as a seperate user (eg. 
'bin' was
a common one under many Unix systems), as this protects like above and 
has the
added advantage of protecting against malicious or just badly written 
install
programs. However, running the installer as the 'bin' user will often 
fail
as installers frequently require root privileges. For example, installing
Python into the standard location will fail, as on a correctly setup 
system
it will be unable to create the directory /usr/local/lib/python2.1.

--
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/



From rellaa@earthlink.net  Tue Nov 13 07:31:32 2001
From: rellaa@earthlink.net (Robert Abernathy)
Date: Tue, 13 Nov 2001 00:31:32 -0700
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker for OS X Installer.app]
In-Reply-To: <20011112204156.115251162D7@oratrix.oratrix.nl>
Message-ID: <75D99458-D808-11D5-AA9E-000393575B76@earthlink.net>

I had to argue back and forth with myself on this for a little bit.  A 
few
years back, the place I was working was cracked by some script
kiddies.  One of the things they did was drop fake versions of ps, ls,
top, and such all over the place.  One of the reasons they could do this
was that the account they cracked was in the developers group.  The
developers group had access to writing in /usr/local.  This made me
a little overly sensitive to opening write access to anyone but root.

Anyway, we didn't fix the security hole by closing access to the 
developer
group.  I went out and bought a firewall and set it up so that developers
couldn't telnet in over an insecure connection.  With that in place, then
I'd say that your plan is much better than mine.  I'll have to think 
about it a
little more, but I think by tomorrow I'll convert over to your practice.

Thanks for the tip,
Rob

On Monday, November 12, 2001, at 01:41 PM, Jack Jansen wrote:

>
> Recently, Robert Abernathy <rellaa@earthlink.net> said:
>> Is there a reason I wouldn't want to install the python files as owned
>> by root?
>
> Yes, a very good reason. The Unix adagium is (and has always been) to
> do as little as humanly possible as root. Taking the /usr/local/python
> as an example, if you do a single
>    sudo mkdir -m 775 /usr/local
> then from that time on you can install anything into /usr/local using
> your own account (administrators are allowed to write to directories
> owned by group "wheel", the same group as root is in, but with no
> inherent extra security risks).
>
> The alternative is that you do a "sudo make install" for every package
> you will ever want to install in /usr/local. This means that for every
> package you install you have to trust the authors of the (often very
> complex) makefiles to not have put a trojan horse in there. Or (why
> blame on malevolence what you can blame on stupidity:-) not to have
> made stupid errors. And stupid errors happen: Apple's own iTunes 2.0
> installer wiped your disk if you happened to install it on a
> non-system-disk with a space in the name just last weekend!
> --
> Jack Jansen             | ++++ stop the execution of Mumia 
> Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your 
> sig ++++
> www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-
> l/sigaction.htm
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From jack@oratrix.nl  Tue Nov 13 12:52:44 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 13 Nov 2001 13:52:44 +0100
Subject: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
In-Reply-To: Message by Dan Wolfe <wolfeman@apple.com> ,
 Mon, 12 Nov 2001 16:00:08 -0800 , <66B8EC5E-D7C9-11D5-A744-003065E3B1C6@apple.com>
Message-ID: <20011113125244.D4678303183@snelboot.oratrix.nl>

> > I think a better solution here would be to simply set the extension for 
> > shared libraries to
> > ".dylib" on OSX, in stead of the more common ".so". After all, they're 
> > really
> > the same thing, and there are no .so's on OSX.
> >
> > What do you think?
> 
> Well, I just did a quick search of my drive and the only .so's that I 
> have other than Python are
> 	a) apache modules that came with the system and
> 	b) those unix packages that I've installed myself (readline, bzip, 
> expat).
> 
> While it's probably a great idea to use the ".dylib" extension for all 
> Mac OS X shared libraries, I'm not sure if I'm up to modifying all the 
> Unix packages that use .so's so that python or some other package looks 
> for for them can find them. ;-)  In other words, if we modified python 
> to handle only dylibs then we need to modify every other package to emit 
> dylibs so that python can find them.  And since both of them work, I'll 
> take the easy way out and just go for allowing both .so and .dylibs on 
> Mac OS X.

Hmm you're right, of course. Bah, bah, bah. I wonder whether a better solution 
then wouldn't be to have a allow two extensions (.so and .dylib) for shared 
libraries, in stead of adding a new type dylib, which is really 100% the same 
as "shared" but only with a different extension.

Should we drop this on the distutils mailing list, or is it too minor an issue 
to bother about?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From jack@oratrix.nl  Tue Nov 13 13:19:26 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 13 Nov 2001 14:19:26 +0100
Subject: [Pythonmac-SIG] Re: 2.1.1 under 10.1 [was Python package maker
 for OS X Installer.app]
In-Reply-To: Message by Robert Abernathy <rellaa@earthlink.net> ,
 Tue, 13 Nov 2001 00:31:32 -0700 , <75D99458-D808-11D5-AA9E-000393575B76@earthlink.net>
Message-ID: <20011113131927.65F93303183@snelboot.oratrix.nl>

Hmm, I may be revising my standpoint on how to install, as superuser or as 
yourself. Robert and Stuart both give examples of how installing as yourself 
may be more dangerous in some cases (because a virus or trojan could overwrite 
the programs in /usr/local you know and love). The "bin" user in the "bin" 
group would be the best solution, but Apple doesn't have it:-(
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From Benjamin.Schollnick@usa.xerox.com  Tue Nov 13 16:30:49 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Tue, 13 Nov 2001 11:30:49 -0500
Subject: [Pythonmac-SIG] Stupid OS.WALK tricks?
Message-ID: <E2D1934575D1D411973D00508BB02F173024B8@usa0129ms1.ess.mc.xerox.com>

Folks,

	I'm attempting to optimize a quick program, but os.walk
	is sort of interferring...
	
	I'm searching a directory tree for graphic file.... using
	os.walk, and when it finds the file, it copies it to a local
	directory...

	The "problem" here, is that I can't figure out how to
	stop OS.walk (in the visit function) from "continuing" 
	through the rest of the directories, and to just move 
	on to the next file... (There should only be one match)..

	I figure I'm going to have to write a custom walk to
	deal with this scenario....  Does anyone have anything
	similiar?  Or suggestions on dealing with this?

	Doing a "return" or "Break" during the search doesn't seem
	to do this....

			- Benjamin
			- Benjamin


From gherman@darwin.in-berlin.de  Tue Nov 13 17:01:35 2001
From: gherman@darwin.in-berlin.de (Dinu Gherman)
Date: Tue, 13 Nov 2001 18:01:35 +0100 (CET)
Subject: [Pythonmac-SIG] Stupid OS.WALK tricks?
In-Reply-To: <E2D1934575D1D411973D00508BB02F173024B8@usa0129ms1.ess.mc.xerox.com>
References: <E2D1934575D1D411973D00508BB02F173024B8@usa0129ms1.ess.mc.xerox.com>
Message-ID: <1005670895.3bf151ef8e021@webmail.in-berlin.de>

"Schollnick, Benjamin" <Benjamin.Schollnick@usa.xerox.com>:

> Folks,
> 
> 	I'm attempting to optimize a quick program, but os.walk
> 	is sort of interferring...
> 	
> 	I'm searching a directory tree for graphic file.... using
> 	os.walk, and when it finds the file, it copies it to a local
> 	directory...
> 
> 	The "problem" here, is that I can't figure out how to
> 	stop OS.walk (in the visit function) from "continuing" 
> 	through the rest of the directories, and to just move 
> 	on to the next file... (There should only be one match)..
> 
> 	I figure I'm going to have to write a custom walk to
> 	deal with this scenario....  Does anyone have anything
> 	similiar?  Or suggestions on dealing with this?
> 
> 	Doing a "return" or "Break" during the search doesn't seem
> 	to do this....
> 
> 			- Benjamin


Not exactly a Mac issue, but how about this code written by
/F that you can extend as you like with filters, etc (have
not bothered to remove all unneeded imports):

"""
import os, sys, glob, fnmatch, string
from os.path import basename, dirname, join, islink, isdir, isfile

# Convenience class, as suggested by /F.

class GlobDirectoryWalker:
    "A forward iterator that traverses files in a directory tree."

    def __init__(self, directory, pattern="*"):
        self.stack = [directory]
        self.pattern = pattern
        self.files = []
        self.index = 0

    def __getitem__(self, index):
        while 1:
            try:
                file = self.files[self.index]
                self.index = self.index + 1
            except IndexError:
                # pop next directory from stack
                self.directory = self.stack.pop()
                self.files = os.listdir(self.directory)
                self.index = 0
            else:
                # got a filename
                fullname = join(self.directory, file)
                if isdir(fullname) and not islink(fullname):
                    self.stack.append(fullname)
                if fnmatch.fnmatch(file, self.pattern):
                    return fullname

files = GlobDirectoryWalker(f)
for file in files:
    handle(file) # not implemented
"""

I know os.walk can make you bang your head against the wall in
unexpected ways...

Dinu


--
Dinu C. Gherman
................................................................
"They made a desert and called it peace." (Tacitus)


From jpaint@sculpin.com  Tue Nov 13 17:38:15 2001
From: jpaint@sculpin.com (Jay Painter)
Date: Tue, 13 Nov 2001 09:38:15 -0800 (PST)
Subject: [Pythonmac-SIG] Stupid OS.WALK tricks?
In-Reply-To: <E2D1934575D1D411973D00508BB02F173024B8@usa0129ms1.ess.mc.xerox.com>
Message-ID: <Pine.LNX.3.96.1011113093729.2418B-100000@server.sculpin.com>

Just raise an exception in you os.walk callback like:

raise os.error, "stop it!!!"


On Tue, 13 Nov 2001, Schollnick, Benjamin wrote:

> Folks,
> 
> 	I'm attempting to optimize a quick program, but os.walk
> 	is sort of interferring...
> 	
> 	I'm searching a directory tree for graphic file.... using
> 	os.walk, and when it finds the file, it copies it to a local
> 	directory...
> 
> 	The "problem" here, is that I can't figure out how to
> 	stop OS.walk (in the visit function) from "continuing" 
> 	through the rest of the directories, and to just move 
> 	on to the next file... (There should only be one match)..
> 
> 	I figure I'm going to have to write a custom walk to
> 	deal with this scenario....  Does anyone have anything
> 	similiar?  Or suggestions on dealing with this?
> 
> 	Doing a "return" or "Break" during the search doesn't seem
> 	to do this....
> 
> 			- Benjamin
> 			- Benjamin
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From wolfeman@apple.com  Tue Nov 13 20:18:59 2001
From: wolfeman@apple.com (Dan Wolfe)
Date: Tue, 13 Nov 2001 12:18:59 -0800
Subject: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
In-Reply-To: <20011113125244.D4678303183@snelboot.oratrix.nl>
Message-ID: <ABFE87A2-D873-11D5-A744-003065E3B1C6@apple.com>

On Tuesday, November 13, 2001, at 04:52 AM, Jack Jansen wrote:

>> While it's probably a great idea to use the ".dylib" extension for all
>> Mac OS X shared libraries, I'm not sure if I'm up to modifying all the
>> Unix packages that use .so's so that python or some other package looks
>> for for them can find them. ;-)  In other words, if we modified python
>> to handle only dylibs then we need to modify every other package to 
>> emit
>> dylibs so that python can find them.  And since both of them work, I'll
>> take the easy way out and just go for allowing both .so and .dylibs on
>> Mac OS X.
>
> Hmm you're right, of course. Bah, bah, bah. I wonder whether a better 
> solution
> then wouldn't be to have a allow two extensions (.so and .dylib) for 
> shared
> libraries, in stead of adding a new type dylib, which is really 100% 
> the same
> as "shared" but only with a different extension.

That's the path that I started down and was pulling my hair out until I 
saw Bill's patch. I was mostly pulling my hair out because I'm not up to 
speed on distutils and don't know where to look.... walking the source 
code is like walking a maze of twisty little passages all alike... and 
that's something that I was never very good at that. :-)

> Should we drop this on the distutils mailing list, or is it too minor 
> an issue
> to bother about?

If it were me, I'd drop Greg Ward or the maintainer of distutils a note 
indicating what we need and what Bill Noon did to  allow us to fix the 
problem and see if he agrees that's the direction he wants to take the 
code or if he has a better idea. Actually, I thought you already did 
this before committing the code to CVS.....

- Dan



From noon@snow.cit.cornell.edu  Tue Nov 13 21:09:13 2001
From: noon@snow.cit.cornell.edu (William Noon)
Date: Tue, 13 Nov 2001 16:09:13 -0500
Subject: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
In-Reply-To: Your message of "Tue, 13 Nov 2001 12:18:59 PST."
 <ABFE87A2-D873-11D5-A744-003065E3B1C6@apple.com>
Message-ID: <200111132109.QAA10413@snow.cit.cornell.edu>

Dan and Jack -- You have followed my thinking exactly.  I ended up makeing
limited changes so they would have a greater chance of being accepted.

I also just needed zlib.

--Bill Noon
> 
> 
> On Tuesday, November 13, 2001, at 04:52 AM, Jack Jansen wrote:
> 
> >> While it's probably a great idea to use the ".dylib" extension for all
> >> Mac OS X shared libraries, I'm not sure if I'm up to modifying all the
> >> Unix packages that use .so's so that python or some other package looks
> >> for for them can find them. ;-)  In other words, if we modified python
> >> to handle only dylibs then we need to modify every other package to 
> >> emit
> >> dylibs so that python can find them.  And since both of them work, I'll
> >> take the easy way out and just go for allowing both .so and .dylibs on
> >> Mac OS X.
> >
> > Hmm you're right, of course. Bah, bah, bah. I wonder whether a better 
> > solution
> > then wouldn't be to have a allow two extensions (.so and .dylib) for 
> > shared
> > libraries, in stead of adding a new type dylib, which is really 100% 
> > the same
> > as "shared" but only with a different extension.
> 
> That's the path that I started down and was pulling my hair out until I 
> saw Bill's patch. I was mostly pulling my hair out because I'm not up to 
> speed on distutils and don't know where to look.... walking the source 
> code is like walking a maze of twisty little passages all alike... and 
> that's something that I was never very good at that. :-)
> 
> > Should we drop this on the distutils mailing list, or is it too minor 
> > an issue
> > to bother about?
> 
> If it were me, I'd drop Greg Ward or the maintainer of distutils a note 
> indicating what we need and what Bill Noon did to  allow us to fix the 
> problem and see if he agrees that's the direction he wants to take the 
> code or if he has a better idea. Actually, I thought you already did 
> this before committing the code to CVS.....
> 
> - Dan
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From jack@oratrix.nl  Tue Nov 13 21:54:29 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 13 Nov 2001 22:54:29 +0100
Subject: [Pythonmac-SIG] Re: Mac OS X 10.1 build changes
In-Reply-To: Message by William Noon <noon@snow.cit.cornell.edu> ,
 Tue, 13 Nov 2001 16:09:13 -0500 , <200111132109.QAA10413@snow.cit.cornell.edu>
Message-ID: <20011113215434.1C8481162D7@oratrix.oratrix.nl>

Recently, William Noon <noon@snow.cit.cornell.edu> said:
> Dan and Jack -- You have followed my thinking exactly.  I ended up makeing
> limited changes so they would have a greater chance of being accepted.

I had a look at the code again, and I don't think it's worth
changing. It would indeed change stuff in many more places, and your
dylib/shared dichotomy does the trick.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jgitomer@erols.com  Thu Nov 15 04:42:04 2001
From: jgitomer@erols.com (Jerry Gitomer)
Date: Wed, 14 Nov 2001 23:42:04 -0500
Subject: [Pythonmac-SIG] How do I install Macpython?
Message-ID: <01111423420400.01073@localhost.localdomain>

I am a complete newbie when it comes to Macintosh.  I have downloaded 
Macpython152.bin.  In my ignorance I assumed that doubleclicking on the file 
name would start up the installation.  No such luck.  What do I have to do to 
get python installed?

-- 
Jerry Gitomer
Once I learned how to spell DBA, I became one 


From ryanwilcox@mac.com  Thu Nov 15 06:11:43 2001
From: ryanwilcox@mac.com (Ryan Wilcox)
Date: Thu, 15 Nov 2001 01:11:43 -0500
Subject: [Pythonmac-SIG] How do I install Macpython?
In-Reply-To: <01111423420400.01073@localhost.localdomain>
Message-ID: <20011115011156-r01010800-f2841c3e-0920-010c@129.21.139.101>

On Wednesday, November 14, 2001, at 11:42 PM, jgitomer@erols.com (Jerry Gitomer)
wrote:

>I am a complete newbie when it comes to Macintosh.  I have downloaded 
>Macpython152.bin.  In my ignorance I assumed that doubleclicking on the file 
>name would start up the installation.  No such luck.  What do I have to do to 
>get python installed?


.bin is a "compression" format. There's more to it, but I won't complicate
matters further.

Drag and Drop that file onto StuffIt Expander. This will "decompress" the file. 

By default, StuffIt Expander will will create the "decompressed" file in the
same directory as the encoded file. (it -should- be named MacPython152, or
something like that). That application should install the needed components,
giving you a working Python install.

HTH,
-Ryan Wilcox

PGP key available on keyserver.pgg.com
PGP fingerprint: 2B1D 8B69 318C F876 A6ED  FE0B 6D83 B4A8 2F4E 9C31


From dev@brotsky.com  Fri Nov  9 21:17:31 2001
From: dev@brotsky.com (Daniel Brotsky)
Date: Fri, 9 Nov 2001 13:17:31 -0800
Subject: [Pythonmac-SIG] Python & MPW ToolServer
In-Reply-To: <B81011FB.CC%alillich@adobe.com>
References: <B81011FB.CC%alillich@adobe.com>
Message-ID: <p05100302b811eeda9a2f@[192.168.1.19]>

At 10:42 AM -0800 11/8/01, Alan Lillich wrote:
>I need to port a simple testing framework and am looking at both Perl and
>Python.  One of the things I need to do is run simple C stdio programs,
>passing in command line arguments and getting a numeric status back.  This
>is obvious for UNIX (including Mac OS X) and Windows in either language.
>For Mac OS 9 the Perl system function lets you invoke an MPW tool or script
>via ToolServer, exactly what I want.  Looking through the Python
>documentation and SIG archive, it looks like the Python fork and exec
>functions aren't implemented on Mac OS 9, at all let alone using ToolServer.

Alan,

Since the macos module doesn't define system(), I'm guessing that 
Jack didn't feel there was any "obviously right" way in the Mac world 
to simulate the "unix standard C" approach to how apps work.  I'd 
have to say I agree with this, but also that Perl's approach (to use 
MPW/ToolServer) seems as good as any.

The easiest way in MacPython to use ToolServer like this is to use 
the (quite well-developed) AppleEvent infrastructure.  Below I've 
attached source for a simple "aesystem" module I use frequently for 
what you describe needing to do.  Once you've imported aesystem, you 
can do things like:

>>>  aesystem.system('echo "This is a test."')
0
>>>  aesystem.lastOutput
'This is a test.\r'
>>>  aesystem.system('Search -nf -e "nowayjack"', infile=":QuitTS", 
>>>outfile="Dev:Null")
2
>>>  aesystem.lastErrorOutput
'### Search - Pattern not found.\r'

(Notice that the scripts/tools run in ToolServer's curdir, not in Python's.)

Hope this helps.  Contact me off-list if you want something more sophisticated.

     dan

------------
"""aesystem -
A simple example of how to use Apple Events to implement a "system()"
call that invokes ToolServer on the command.

system(cmd, infile = None, outfile = None, errfile = None)

1. Every call to system sets "lastStatus" and "lastOutput" to the 
status and output
produced by the command when executed in ToolServer.  (lastParameters 
and lastAttributes
are set to the values of the AppleEvent result.)

2. system returns lastStatus unless the command result indicates a MacOS error,
in which case os.Error is raised with the errnum as associated value.

3. You can specify ToolServer-understandable pathnames for 
redirection of input,
output, and error streams.  By default, input is Dev:Null, output is captured
and returned to the caller, diagnostics are captured and returned to 
the caller.
(There's a 64K limit to how much can be captured and returned this way.)"""

import os
import aetools

try: server
except NameError: server = aetools.TalkTo("MPSX", 1)

lastStatus = None
lastOutput = None
lastErrorOutput = None
lastScript = None
lastEvent = None
lastReply = None
lastParameters = None
lastAttributes = None

def system(cmd, infile = None, outfile = None, errfile = None):
	global lastStatus, lastOutput, lastErrorOutput
	global lastScript, lastEvent, lastReply, lastParameters, lastAttributes
	cmdline = cmd
	if infile: cmdline += " <" + infile
	if outfile: cmdline += " >" + outfile
	if errfile: cmdline += " " + str(chr(179)) + errfile
	lastScript = "set Exit 0\r" + cmdline + "\rexit {Status}"
	lastEvent = server.newevent("misc", "dosc", {"----" : lastScript})
	(lastReply, lastParameters, lastAttributes) = 
server.sendevent(lastEvent)
	if lastParameters.has_key('stat'): lastStatus = lastParameters['stat']
	else: lastStatus = None
	if lastParameters.has_key('----'): lastOutput = lastParameters['----']
	else: lastOutput = None
	if lastParameters.has_key('diag'): lastErrorOutput = 
lastParameters['diag']
	else: lastErrorOutput = None
	if lastParameters['errn'] != 0:
		raise os.Error, lastParameters['errn']
	return lastStatus


From kelvin.chu@uvm.edu  Fri Nov 16 04:56:49 2001
From: kelvin.chu@uvm.edu (Kelvin Chu)
Date: Thu, 15 Nov 2001 23:56:49 -0500
Subject: [Pythonmac-SIG] Native Tk/TCL on MacOSX.
Message-ID: <20011115235649.A74052@zoo.uvm.edu>

Greetings, MacPythonians.

I've installed the latest Tcl/Tk from Tk.sf.net which has built-in
Aqua support on MacOSX.  I'm currently running Python from the fink
build, but I can dl the source.  My question is: How can I get python
to use the Tk bundle that has just been released?  Do I need to
rebuild Python?  We're one step closer to getting reasonable
applications now...

Thanks for read this and for any suggestions you have.

-k

-- 

  kelvin.chu@uvm.edu				     (802) 656-0064
  http://www.uvm.edu/~kchu/			FAX: (802) 656-0817



From jack@oratrix.nl  Fri Nov 16 09:05:56 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 16 Nov 2001 10:05:56 +0100
Subject: [Pythonmac-SIG] Python & MPW ToolServer
In-Reply-To: Message by Daniel Brotsky <dev@brotsky.com> ,
 Fri, 9 Nov 2001 13:17:31 -0800 , <p05100302b811eeda9a2f@[192.168.1.19]>
Message-ID: <20011116090556.BBECC303183@snelboot.oratrix.nl>

Wow,
that's a very useful routine! Is it OK if I add it to the distribution?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From patrick@swdev.com  Sat Nov 17 07:12:31 2001
From: patrick@swdev.com (Patrick Curtain)
Date: Fri, 16 Nov 2001 23:12:31 -0800
Subject: [Pythonmac-SIG] XDarwin, Python and Tkinter
Message-ID: <778940F2-DB2A-11D5-A95A-00039315F03C@swdev.com>

Hello All!

Has anyone gotten a build of python working that taps into the Tcl/Tk 
(via Tkinter) under XDarwin (rootless X Windows on Aqua)?

Haven't been able to myself, several compile errors.  Mostly I'm looking 
to see if it's been done yet or I'm out at the bleed.  :-)

God Bless!
--p

Patrick Curtain, Husband & Father (i also write software)
SWDev, Co.         503 781 6199       patrick@swdev.com



From bobsavage@mac.com  Sat Nov 17 15:34:25 2001
From: bobsavage@mac.com (Bob Savage)
Date: Sat, 17 Nov 2001 09:34:25 -0600
Subject: [Pythonmac-SIG] XDarwin, Python and Tkinter
In-Reply-To: <778940F2-DB2A-11D5-A95A-00039315F03C@swdev.com>
Message-ID: <B81BDFA1.19DE8%bobsavage@mac.com>

on 11/17/01 1:12 AM, Patrick Curtain wrote:
> 
> Has anyone gotten a build of python working that taps into the Tcl/Tk
> (via Tkinter) under XDarwin (rootless X Windows on Aqua)?
> 

Patrick, (or anyone else) if you do get this to work, please post a summary
to the list of what you did to get it to work.

THX,

Bob




From prastawa@cs.unc.edu  Sat Nov 17 20:55:29 2001
From: prastawa@cs.unc.edu (Marcel Prastawa)
Date: Sat, 17 Nov 2001 15:55:29 -0500
Subject: [Pythonmac-SIG] XDarwin, Python and Tkinter
In-Reply-To: <778940F2-DB2A-11D5-A95A-00039315F03C@swdev.com>
Message-ID: <Pine.SGI.4.10.10111171532290.239295-100000@evans.cs.unc.edu>

I have gotten Tkinter to work with XDarwin once. I have switched to
Tenon's Xtools (a bit faster, but not free), so far it works just fine.

I don't think that I encountered any big problems... Tkinter should work
with XDarwin. What kind of errors are you getting?

Additionally: Which versions of Python and Tcl/Tk are you using? What
parameters did you use for _tkinter in 'Modules/Setup'?

Marcel

On Fri, 16 Nov 2001, Patrick Curtain wrote:

> Hello All!
> 
> Has anyone gotten a build of python working that taps into the Tcl/Tk 
> (via Tkinter) under XDarwin (rootless X Windows on Aqua)?
> 
> Haven't been able to myself, several compile errors.  Mostly I'm looking 
> to see if it's been done yet or I'm out at the bleed.  :-)
> 
> God Bless!
> --p
> 
> Patrick Curtain, Husband & Father (i also write software)
> SWDev, Co.         503 781 6199       patrick@swdev.com
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From patrick@swdev.com  Sun Nov 18 23:53:09 2001
From: patrick@swdev.com (Patrick Curtain)
Date: Sun, 18 Nov 2001 15:53:09 -0800
Subject: [Pythonmac-SIG] XDarwin, Python and Tkinter
In-Reply-To: <Pine.SGI.4.10.10111171532290.239295-100000@evans.cs.unc.edu>
Message-ID: <6B3E235E-DC7F-11D5-96C4-00039315F03C@swdev.com>

Hello All!  And thank you Marcel, for offering to help.

On Saturday, November 17, 2001, at 12:55 PM, Marcel Prastawa wrote:

> I have gotten Tkinter to work with XDarwin once. I have switched to
> Tenon's Xtools (a bit faster, but not free), so far it works just fine.

That's good to hear.

> I don't think that I encountered any big problems... Tkinter should work
> with XDarwin. What kind of errors are you getting?

When I try to build, I get the messages:
./Modules/_tkinter.c:45: tk.h: No such file or directory
./Modules/_tkinter.c:50: #error "Tk older than 8.0 not supported"
make: *** [Modules/_tkinter.o] Error 1
(which ends the build process.)

> Additionally: Which versions of Python and Tcl/Tk are you using?

Python 2.1.1 building from source.
Tcl and Tk were download as packages and seem to work with XDarwin.  
Funny part (not knowing better) is that it installed Tcl version 8.2 and 
Tk version 8.3.  Should these match?

> What parameters did you use for _tkinter in 'Modules/Setup'?

First, I started with simply un-commenting the lines provided.  Then I 
tried explicitly setting the Tcl/Tk libraries to /usr/local/lib/tcl8.2 
( a dir in lib) and /usr/local/lib/tk8.3 (also a dir).  There are 
libraries -in- the /usr/local/lib dir named libtcl82.a and libtk83.a, so 
this may not be necessary.  None of those adjustments seemed to help.

I did a similar change for the include dir as well. Changing the -I line 
of the Setup file took care of locating 'tk.h' (i set it to 
/usr/local/include/tk8.3).  Still doesn't build.   I got variations of:
/usr/bin/ld: can't locate file for: -ltk8.3

Any suggestions about what to try next?  Perhaps I should be obtaining 
Tcl/Tk from another source?  Or...

Thanks again, for any help at all!
--p



> On Fri, 16 Nov 2001, Patrick Curtain wrote:
>
>> Hello All!
>>
>> Has anyone gotten a build of python working that taps into the Tcl/Tk
>> (via Tkinter) under XDarwin (rootless X Windows on Aqua)?
>>
>> Haven't been able to myself, several compile errors.  Mostly I'm 
>> looking
>> to see if it's been done yet or I'm out at the bleed.  :-)
>>
>> God Bless!
>> --p

Patrick Curtain, Husband & Father (i also write software)
SWDev, Co.         503 781 6199       patrick@swdev.com
>>
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From patrick@swdev.com  Mon Nov 19 00:44:40 2001
From: patrick@swdev.com (Patrick Curtain)
Date: Sun, 18 Nov 2001 16:44:40 -0800
Subject: [Pythonmac-SIG] XDarwin, Python and Tkinter
In-Reply-To: <6B3E235E-DC7F-11D5-96C4-00039315F03C@swdev.com>
Message-ID: <9D5DD3E4-DC86-11D5-96C4-00039315F03C@swdev.com>

Update:

I modified the -l line that had read:
	# *** Uncomment and edit to reflect your Tcl/Tk versions:
	-ltk8.3 -ltcl8.2 \
changing it to:
	# *** Uncomment and edit to reflect your Tcl/Tk versions:
	-ltk83 -ltcl82 \

And that allowed it to get past the last error listed in my last 
message, not finding the library tk8.3.  The actual file, in 
/usr/local/lib  was libtk83.a.

Now the error that stops the build is:
ranlib libpython2.1.a
cc  -u __dummy -framework System -framework Foundation -o python.exe \
                 Modules/python.o \
                 libpython2.1.a -lpthread -ldl  -L/usr/local/ssl/lib 
-lssl -lcrypto  -L/usr/local/lib/tcl8.2 -L/usr/local/lib/tk8.3 -ltk83 
-ltcl82 -L/usr/X11R6/lib -lX11
/usr/bin/ld: Undefined symbols:
_TclGetStartupScriptFileName
make: *** [python.exe] Error 1

Does that seem to be any closer?  :-)

Again, python-mac folks and Marcel, thank you for the help!
--p

On Sunday, November 18, 2001, at 03:53 PM, Patrick Curtain wrote:

> Hello All!  And thank you Marcel, for offering to help.
>
> On Saturday, November 17, 2001, at 12:55 PM, Marcel Prastawa wrote:
>
>> I have gotten Tkinter to work with XDarwin once. I have switched to
>> Tenon's Xtools (a bit faster, but not free), so far it works just fine.
>
> That's good to hear.
>
>> I don't think that I encountered any big problems... Tkinter should 
>> work
>> with XDarwin. What kind of errors are you getting?
>
> When I try to build, I get the messages:
> ./Modules/_tkinter.c:45: tk.h: No such file or directory
> ./Modules/_tkinter.c:50: #error "Tk older than 8.0 not supported"
> make: *** [Modules/_tkinter.o] Error 1
> (which ends the build process.)
>
>> Additionally: Which versions of Python and Tcl/Tk are you using?
>
> Python 2.1.1 building from source.
> Tcl and Tk were download as packages and seem to work with XDarwin.  
> Funny part (not knowing better) is that it installed Tcl version 8.2 
> and Tk version 8.3.  Should these match?
>
>> What parameters did you use for _tkinter in 'Modules/Setup'?
>
> First, I started with simply un-commenting the lines provided.  Then I 
> tried explicitly setting the Tcl/Tk libraries to /usr/local/lib/tcl8.2 
> ( a dir in lib) and /usr/local/lib/tk8.3 (also a dir).  There are 
> libraries -in- the /usr/local/lib dir named libtcl82.a and libtk83.a, 
> so this may not be necessary.  None of those adjustments seemed to help.
>
> I did a similar change for the include dir as well. Changing the -I 
> line of the Setup file took care of locating 'tk.h' (i set it to 
> /usr/local/include/tk8.3).  Still doesn't build.   I got variations of:
> /usr/bin/ld: can't locate file for: -ltk8.3
>
> Any suggestions about what to try next?  Perhaps I should be obtaining 
> Tcl/Tk from another source?  Or...
>
> Thanks again, for any help at all!
> --p
>
>
>
>> On Fri, 16 Nov 2001, Patrick Curtain wrote:
>>
>>> Hello All!
>>>
>>> Has anyone gotten a build of python working that taps into the Tcl/Tk
>>> (via Tkinter) under XDarwin (rootless X Windows on Aqua)?
>>>
>>> Haven't been able to myself, several compile errors.  Mostly I'm 
>>> looking
>>> to see if it's been done yet or I'm out at the bleed.  :-)
>>>
>>> God Bless!
>>> --p
>
> Patrick Curtain, Husband & Father (i also write software)
> SWDev, Co.         503 781 6199       patrick@swdev.com
>>>
>>>
>>> _______________________________________________
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>>
>>
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

Patrick Curtain,  Husband & Father  ( i also write software )
http://www.swdev.com/  We Build the SERVER Side  503.781.6199



From prastawa@cs.unc.edu  Mon Nov 19 16:34:56 2001
From: prastawa@cs.unc.edu (Marcelinus Prastawa)
Date: Mon, 19 Nov 2001 11:34:56 -0500
Subject: [Pythonmac-SIG] XDarwin, Python and Tkinter
In-Reply-To: <9D5DD3E4-DC86-11D5-96C4-00039315F03C@swdev.com>
Message-ID: <5DE8FCE6-DD0B-11D5-AF1F-000A27942780@cs.unc.edu>

I think that you don't need to specify/use -L/usr/local/lib/tk8.3 and 
-L/usr/local/lib/tcl8.2, you should use -L/usr/local/lib instead (the 
files in those directories are not used for linking).

I am using tcl8.3, the symbol is defined in libtcl8.3 (it's probably not a 
good idea to use tcl8.2 with tk8.3). I recommend using Tcl/Tk version 8.3.
3 (or the latest stable version). Apple also provides tcl8.3 (look under 
/usr/{bin, lib} and /System/Library/Tcl). I don't know if the one they 
provide will work without a glitch.

It might be easier to install the latest stable Tcl/Tk (for me at least) 
and do everything from scratch. Oh, and you might want to use the latest 
Python source from CVS, it works great for OS X. I remember having some 
problems with 2.1.1 and 2.2b1...

Marcel



From JasonRandHarper@compuserve.com  Tue Nov 20 06:27:09 2001
From: JasonRandHarper@compuserve.com (Jason Harper)
Date: Tue, 20 Nov 2001 01:27:09 -0500
Subject: [Pythonmac-SIG] Embedding in code resource
Message-ID: <200111200127_MC3-E78B-5879@compuserve.com>

I'm trying to embed MacPython (Classic) in a plug-in code resource for
another application.  Basically, I need to be able to start up an
interactive interpreter, let the user play around in it, then exit cleanl=
y
to the calling application.  I had little difficulty getting the first pa=
rt
of that working, by linking against PythonCore and calling
PyMac_Initialize, etc.  However, there's a big problem when trying to
return - all ways of exiting the interpreter seem to eventually involve a=
 C
exit() call, which is a complete disaster from a code resource.  Does
anyone know of a way to get the interpreter to exit cleanly to its caller=
?

The only solution I could think of was to register an atexit() handler
(registered before any Python calls were made, so it should therefore
execute after all of Python's atexit() handlers had run) that did a
longjmp() back to my code.  This crashed my machine hard, although I
haven't yet tried to figure out why (I don't think this can possibly work=

more than once anyway, and I need to allow the user to invoke my plug-in
multiple times).
        Jason Harper


From dev@brotsky.com  Fri Nov 16 09:50:52 2001
From: dev@brotsky.com (Daniel Brotsky)
Date: Fri, 16 Nov 2001 01:50:52 -0800
Subject: [Pythonmac-SIG] Python & MPW ToolServer
In-Reply-To: <20011116090556.BBECC303183@snelboot.oratrix.nl>
References: <20011116090556.BBECC303183@snelboot.oratrix.nl>
Message-ID: <p05101008b81a91c460fc@[192.168.1.1]>

At 1:05 AM -0800 11/16/01, Jack Jansen wrote:
>Wow,
>that's a very useful routine! Is it OK if I add it to the distribution?

Sure.  Do you need anything else from me to do so?

     dan


From doug@sonosphere.com  Wed Nov 21 15:40:24 2001
From: doug@sonosphere.com (Doug Wyatt)
Date: Wed, 21 Nov 2001 10:40:24 -0500
Subject: [Pythonmac-SIG] Embedding in code resource
In-Reply-To: <200111200127_MC3-E78B-5879@compuserve.com>
Message-ID: <1433FDB2-DE96-11D5-9EAE-00039301A6E6@sonosphere.com>

It may be possible to define your own exit() function and have it 
override the one in the standard library.  If I remember correctly, 
CodeWarrior will issue a link warning, but it should use the one in your 
program in preference to one defined in a library -- at worst, you may 
have to change the link order.

I believe there are also ways to access the interpreter through 
lower-level functions that won't call exit().  I haven't tried this, but 
perhaps the InteractiveInterpreter or InteractiveConsole library 
classes ... ?

One thing to watch out for is the library's malloc() implementation -- 
you may need to make an extra call to have it clean up after itself.  
I've written a lot of code resources, but it's been a couple of years so 
I'm working from fading memory...

Doug


On Tuesday, November 20, 2001, at 01:27 , Jason Harper wrote:

> I'm trying to embed MacPython (Classic) in a plug-in code resource for
> another application.  Basically, I need to be able to start up an
> interactive interpreter, let the user play around in it, then exit 
> cleanly
> to the calling application.  I had little difficulty getting the first 
> part
> of that working, by linking against PythonCore and calling
> PyMac_Initialize, etc.  However, there's a big problem when trying to
> return - all ways of exiting the interpreter seem to eventually involve 
> a C
> exit() call, which is a complete disaster from a code resource.  Does
> anyone know of a way to get the interpreter to exit cleanly to its 
> caller?
>
> The only solution I could think of was to register an atexit() handler
> (registered before any Python calls were made, so it should therefore
> execute after all of Python's atexit() handlers had run) that did a
> longjmp() back to my code.  This crashed my machine hard, although I
> haven't yet tried to figure out why (I don't think this can possibly 
> work
> more than once anyway, and I need to allow the user to invoke my plug-in
> multiple times).
>         Jason Harper
--
Doug Wyatt
work:  dwyatt@apple.com  (CoreAudio)
personal:  doug@sonosphere.com   http://www.sonosphere.com

"Temporal = temporary".
	-- dsw



From jack@oratrix.nl  Wed Nov 21 16:15:12 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 21 Nov 2001 17:15:12 +0100
Subject: [Pythonmac-SIG] Embedding in code resource
In-Reply-To: Message by Jason Harper <JasonRandHarper@compuserve.com> ,
 Tue, 20 Nov 2001 01:27:09 -0500 , <200111200127_MC3-E78B-5879@compuserve.com>
Message-ID: <20011121161513.5910F303183@snelboot.oratrix.nl>

> I'm trying to embed MacPython (Classic) in a plug-in code resource for
> another application.  Basically, I need to be able to start up an
> interactive interpreter, let the user play around in it, then exit clea=
nly
> to the calling application.  I had little difficulty getting the first =
part
> of that working, by linking against PythonCore and calling
> PyMac_Initialize, etc.  However, there's a big problem when trying to
> return - all ways of exiting the interpreter seem to eventually involve=
 a C
> exit() call, which is a complete disaster from a code resource.  Does
> anyone know of a way to get the interpreter to exit cleanly to its call=
er?

what you want to do is probably
  PyMac_Initialize();
  PyRun_AnyFile(stdin_for_python, "<stdin>");
I think this should never call exit(), but always return.

Depending on how your code resource is linked against PythonCore you may =
be =

able to do simply "stdin" for stdin_for_python, but it could also be more=
 work =

to get at that.

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++=

Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig =
++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.=
htm =





From Benjamin.Schollnick@usa.xerox.com  Wed Nov 21 16:27:26 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 21 Nov 2001 11:27:26 -0500
Subject: [Pythonmac-SIG] Problems with Findertools in OS x v.10.1.1?  (Move)
Message-ID: <E2D1934575D1D411973D00508BB02F173024D7@usa0129ms1.ess.mc.xerox.com>

I'm using a file copy routine that I just finished, and
started to notice some oddities...

Namely the findertools.move () command appears to work,
but is returning an exception.......

This may have just started with OS X v10.1.1, but I'm
not positive... I just booted back to OS v9.21 and do 
*NOT* see this problem occuring there... So it's certainly
an Mac OS X issue...

Since the file copy does appear to work, I may have missed
it when I added the exception coding.... (It appears to work
so maybe I just wasn't observant enough).

Anyone else notice this?

		- Benjamin

def	move_file ( old_path, new_path, filename ):
	try:
		if os.path.exists (new_path + os.sep + filename):
			Ask = EasyDialogs.AskYesNoCancel("Duplicate File
Detected (%s), Overwrite?" % filename, default = 1, yes=None, no=None,
cancel=None, id=262)
			if Ask == 1:
				if mac_mode:
					# Overwrite, by removing the old
file
					#
					os.remove(new_path + os.sep +
filename)
					
				elif Ask == 0:
					#
					#	Do not overwrite, end
routine, by returning
					#
					return 0
						
				elif Ask == -1:
					#
					#	Abort program, return error
code
					#
					return -1
				
				if mac_mode:
					findertools.move (old_path +
filename, new_path)
					print old_path + filename,  " -->
Moved.."
			except:
				print "error"
			
			return None

# of Files found :  6
filename : WAITING.JPG
filename : WALL
filename : WALL_1.JPG
-------------------------------------
old:  OS v9.1:Desktop Folder:python work:test:
new: OS v9.1:Desktop Folder:python work:test:Wall
filename: WALL_1.JPG
old + file: OS v9.1:Desktop Folder:python work:test:WALL_1.JPG
Traceback (most recent call last):
  File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 104, in ?
    move_file ( pathname, new_dir, filename )
  File "OS v9.1:Desktop Folder:python work:re-dup-file.py", line 53, in
move_file
    findertools.move (old_path + filename, new_path)
  File "OS v9.1:Applications (Mac OS 9):Python
2.1.1:Mac:Lib:findertools.py", line 74, in move
    return finder.move(src_fss, to=dst_fss)
  File "OS v9.1:Applications (Mac OS 9):Python
2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py", line 293, in
move
    raise aetools.Error, aetools.decodeerror(_arguments)
aetools.Error: (0, 'component result = no error', None)



From paul@fxtech.com  Wed Nov 21 17:22:27 2001
From: paul@fxtech.com (Paul Miller)
Date: Wed, 21 Nov 2001 11:22:27 -0600
Subject: [Pythonmac-SIG] Hiding embedded Python console - revisited
In-Reply-To: <E2D1934575D1D411973D00508BB02F173024D7@usa0129ms1.ess.mc.x
 erox.com>
Message-ID: <5.1.0.14.2.20011121112050.01c2ece0@cedar.he.net>

I was wondering if someone has found a reliable way to disable the Python 
console that appears after calling PyMac_Initialize()? I have hooked my own 
I/O functions and I don't want the console to appear at all.

-- 
Paul T. Miller | paul@fxtech.com | http://www.fxtech.com



From JasonRandHarper@compuserve.com  Wed Nov 21 19:43:14 2001
From: JasonRandHarper@compuserve.com (Jason Harper)
Date: Wed, 21 Nov 2001 14:43:14 -0500
Subject: [Pythonmac-SIG] Embedding in code resource
Message-ID: <200111211443_MC3-E7D9-663@compuserve.com>

Jack Jansen wrote:
> what you want to do is probably
>   PyMac_Initialize();
>   PyRun_AnyFile(stdin_for_python, "<stdin>");
> I think this should never call exit(), but always return.
> =

> Depending on how your code resource is linked against PythonCore you ma=
y
be =

> able to do simply "stdin" for stdin_for_python, but it could also be mo=
re
work =

> to get at that.

Running an interactive loop isn't the problem, it's what happens
afterwards...  When my plug-in is deselected by the user, I need to clean=
ly
finalize the interpreter (free at least most of its memory, close the SIO=
UX
console if it was opened, etc.), and let the parent application continue
running.  Py_Exit() and PyMac_Exit() eventually call exit(), and I'm not
sure that can be avoided anyway - it appears that SIOUX's cleanup is done=

by an atexit() handler.  I guess what I really need is a way to intercept=

the exit() in PythonCore before it can exit the parent application.
        Jason Harper


From jack@oratrix.nl  Wed Nov 21 23:11:02 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Thu, 22 Nov 2001 00:11:02 +0100
Subject: [Pythonmac-SIG] Embedding in code resource
In-Reply-To: Message by Jason Harper <JasonRandHarper@compuserve.com> ,
 Wed, 21 Nov 2001 14:43:14 -0500 , <200111211443_MC3-E7D9-663@compuserve.com>
Message-ID: <20011121231107.38754DB4A0@oratrix.oratrix.nl>

Recently, Jason Harper <JasonRandHarper@compuserve.com> said:
> Running an interactive loop isn't the problem, it's what happens
> afterwards...  When my plug-in is deselected by the user, I need to clean=
> ly
> finalize the interpreter (free at least most of its memory, close the SIO=
> UX
> console if it was opened, etc.), and let the parent application continue
> running.  Py_Exit() and PyMac_Exit() eventually call exit(), and I'm not
> sure that can be avoided anyway - it appears that SIOUX's cleanup is done=
> 
> by an atexit() handler.

Ah, sorry, now I understand. As to the main interpreter state:
Py_Finalize() should clean up most things. What then remains to be
cleaned up is stdio, GUSI, SIOUX and thereby the console window.

Hmm, this doesn't seem to be simple. MSL's exit() does a lot of useful
things, like cleaning up global chains and stdio and such.

But: MSL has an __atexit() function (same signature as atexit), and
these handlers are called really really late in the cleanup process,
just before ExitToShell(). So maybe registering such a handler would
help? But beware that at this point all sorts of useful things (like
C++ global chain for destroying objects) have been cleaned up beyond
repair, so you should probably immedeately unload your plugin.

An alternative might be to call __stdio_atexit() to clean up
stdio. This should also clean up GUSI, I think. And I think the
cleanup is done in such a way that things might be re-initializable
again.  However, any file opened with os.open() or socket.socket() will
probably stay open....
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From rbl@hal.cwru.edu  Thu Nov 22 01:55:10 2001
From: rbl@hal.cwru.edu (Robin B. Lake)
Date: Wed, 21 Nov 2001 20:55:10 -0500 (EST)
Subject: [Pythonmac-SIG] Problem making Python2.2 on OS 10.1.1
Message-ID: <200111220155.fAM1tAtZ029819@hal.cwru.edu>

"make"-ing python gives:

cc  -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python \
                Modules/python.o \
                libpython2.2.a      
/usr/bin/ld: can't create output file: python (Is a directory, errno = 21)
make: *** [python] Error 1


Any clues, please?

Thanks,
Rob Lake
lake@cwru.edu


From steve@spvi.com  Thu Nov 22 02:06:45 2001
From: steve@spvi.com (Steve Spicklemire)
Date: Wed, 21 Nov 2001 21:06:45 -0500
Subject: [Pythonmac-SIG] Problem making Python2.2 on OS 10.1.1
References: <200111220155.fAM1tAtZ029819@hal.cwru.edu>
Message-ID: <3BFC5DB6.B2D1F94D@spvi.com>

./configure --with-suffix --with-dyld

I think.... (from memory)

-steve

"Robin B. Lake" wrote:
> 
> "make"-ing python gives:
> 
> cc  -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python \
>                 Modules/python.o \
>                 libpython2.2.a
> /usr/bin/ld: can't create output file: python (Is a directory, errno = 21)
> make: *** [python] Error 1
> 
> Any clues, please?
> 
> Thanks,
> Rob Lake
> lake@cwru.edu
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From hummelsean@mac.com  Sat Nov 24 15:56:25 2001
From: hummelsean@mac.com (Sean Hummel)
Date: Sat, 24 Nov 2001 07:56:25 -0800
Subject: [Pythonmac-SIG] Macintosh Distribution of PIL ?
Message-ID: <D098FC85-E0F3-11D5-B474-003065428512@mac.com>

I know there used to be a distribution of the Python Imaging Library for 
the Macintosh version of Python.  However I don't seem to be able to 
find a distribution for it any longer.

Anyone still have a working distribution somewhere out there?



From jack@oratrix.nl  Sat Nov 24 22:24:59 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Sat, 24 Nov 2001 23:24:59 +0100
Subject: [Pythonmac-SIG] Macintosh Distribution of PIL ?
In-Reply-To: Message by Sean Hummel <hummelsean@mac.com> ,
 Sat, 24 Nov 2001 07:56:25 -0800 , <D098FC85-E0F3-11D5-B474-003065428512@mac.com>
Message-ID: <20011124222504.C10A9E2677@oratrix.oratrix.nl>

Recently, Sean Hummel <hummelsean@mac.com> said:
> I know there used to be a distribution of the Python Imaging Library for 
> the Macintosh version of Python.  However I don't seem to be able to 
> find a distribution for it any longer.

PIL has been included in te standard MacPython distribution for quite
some time already, so that's probably why you can't find the
distirbution anymore:-)
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From gr_vaughan@ev1.net  Sat Nov 24 23:40:46 2001
From: gr_vaughan@ev1.net (Gordon R. Vaughan)
Date: Sat, 24 Nov 2001 17:40:46 -0600
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
Message-ID: <200111241742828.SM00138@[207.218.205.180]>

I'm still pretty new to Python but looking to do some basic database work on
the Mac.  I'm aware of PostgreSQL and MySQL for example but not sure how
well they actually work with Python at present.  Are these good choices for
Mac OS 9?

Also, I'm concerned about practical stuff such as reporting and label
printing.  Are there Python modules for these tasks that work well, or other
means for accomplishing this?  From what I can tell printing is still one of
the weaknesses of Python.

Any help would be appreciated.

Thanks,
Gordon R. Vaughan


From jack@oratrix.nl  Sun Nov 25 23:03:59 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Mon, 26 Nov 2001 00:03:59 +0100
Subject: [Pythonmac-SIG] MacPython 2.2b2 available
Message-ID: <20011125230404.8FDC8E2677@oratrix.oratrix.nl>

Folks,
MacPython 2.2b2 is available. For your eyes only for the next 24
hours, and then I'll announce it to the rest of the world. Download it
from http://www.cwi.nl/ftp/jack/python/mac .

I'd really like people to beta test this release, as there are two
changes to the lowlevel infrastructure that may have more consequences
than intended (i.e. bad ones:-): there's a new GUSI library used for
I/O and the handling of events and command-. has been changed
significantly to fix some really old bugs.

Please let me know about problems ASAP,
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | ++++ see http://www.xs4all.nl/~tank/ ++++


From marcus.h.mendenhall@vanderbilt.edu  Mon Nov 26 14:16:45 2001
From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall)
Date: Mon, 26 Nov 2001 08:16:45 -0600
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
In-Reply-To: <200111241742828.SM00138@[207.218.205.180]>
References: <200111241742828.SM00138@[207.218.205.180]>
Message-ID: <p04330100b827fe50506b@[129.59.235.75]>

>
>Also, I'm concerned about practical stuff such as reporting and label
>printing.  Are there Python modules for these tasks that work well, or other
>means for accomplishing this?  From what I can tell printing is still one of
>the weaknesses of Python.

the Piddle module is your friend for printing.  It is in the process 
of being superseded by Sping, but I don't think the quickdraw backend 
is in Sping, and it works great in Piddle.

Piddle is a platform-independent (reasonably) graphics interface for 
Python.  The most important part of it is that it generates pdf's 
beautifully, which gives a nice interface for printing documents.  I 
use it for label printing, etc. routinely.  I have a (very crude) 
label printing package built on Piddle (it's only about 3 lines of 
code) which, if you are interested, I can send along as an example of 
using Piddle.

Marcus Mendenhall



>Any help would be appreciated.
>
>Thanks,
>Gordon R. Vaughan



From loredo@astrosun.astro.cornell.edu  Mon Nov 26 18:53:46 2001
From: loredo@astrosun.astro.cornell.edu (Tom Loredo)
Date: Mon, 26 Nov 2001 13:53:46 -0500 (EST)
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
Message-ID: <200111261853.NAA14246@laplace.astro.cornell.edu>

Hi-

If you need SQL-ish capability, this won't help you.  But if you
just need a handy and very Pythonic way to store and retrieve
objects, I've compiled the Zope Object Database (ZODB) for
the Mac.  I will put it online soon, but I'm swamped this week
(and out of town most of it), so it won't happen for at least
a week.  If you need it more quickly, drop me an email and
I'll try to email you a Stuffit file.  It is for MacPython 2.1.1
on the PPC.

-Tom Loredo


From Aureli.Soria_Frisch@ipk.fhg.de  Mon Nov 26 19:31:32 2001
From: Aureli.Soria_Frisch@ipk.fhg.de (Aureli Soria Frisch)
Date: Mon, 26 Nov 2001 20:31:32 +0100
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
In-Reply-To: <200111261853.NAA14246@laplace.astro.cornell.edu>
Message-ID: <l03010d01b8284868d5f2@[153.97.92.109]>

Hi,

 if you are looking for a module to work with already built databases in
.DBF format, there is a module "dbfreader.py" which works perfectly.

You can find it in the 'Vault of Parnasus' under Database:

http://www.vex.net/parnassus/

Regards

#################################
Aureli Soria Frisch
Fraunhofer IPK
Dept. Pattern Recognition

post: Pascalstr. 8-9, 10587 Berlin, Germany
e-mail:aureli@ipk.fhg.de
fon: +49 30 39006-150
fax: +49 30 3917517
web: http://vision.fhg.de/~aureli/web-aureli_en.html
#################################




From english@spiritone.com  Mon Nov 26 20:50:50 2001
From: english@spiritone.com (Josh English)
Date: 26 Nov 2001 12:50:50 -0800
Subject: [Pythonmac-SIG] Problem with W and shelve (Python 2.11)
Message-ID: <3C02AB2A.7D5A74A7@spiritone.com>

Hello all,

After my Mac crashed I had to reinstall Python 2.1.1 from scratch, and
now my old files aren't working properly. I had a database of my books
in a shelve file, and I had created a program using W to give me a GUI
editor for the database. It worked fine before the crash, now the IDE
just quits as soon as I run the file. 

I started over and this file shuts the IDE down as soon as I hit run:

import W
import shelve

def endprogram():
    db.close()
    root.close()

db = shelve.open('mybooks')
l = len(db)

root = W.Window((500,340), "Booklist", minsize = (240,180))
root.closebtn = W.Button((-74,-54,58,20),"Save&Quit",endprogram)
root.open()

It seems that any code that accesses the database file causes this
problem. I can access the 'mybooks' file in the interpreter without any difficulty.

Does anyone have any suggestions to trouble shoot this one. I think an
error message pops up in it's own window, but it is just a flash before
it all disappears.

Josh English
english@spiritone.com


From mis@creazone.com  Tue Nov 27 04:13:42 2001
From: mis@creazone.com (Michal Seta)
Date: Mon, 26 Nov 2001 23:13:42 -0500
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
In-Reply-To: <200111261853.NAA14246@laplace.astro.cornell.edu>
Message-ID: <B8287D26.7CBE%mis@creazone.com>

And how about gadfly?
it works on a Mac and it's SQL-aware.  It's called kwP now.  And isn't ZODB
based on gadfly?
Sorry if I'm completely off.

./MiS

On 11/26/01 1:53 PM, Tom Loredo @ loredo@astrosun.astro.cornell.edu wrote:

> 
> Hi-
> 
> If you need SQL-ish capability, this won't help you.  But if you
> just need a handy and very Pythonic way to store and retrieve
> objects, I've compiled the Zope Object Database (ZODB) for
> the Mac.  I will put it online soon, but I'm swamped this week
> (and out of town most of it), so it won't happen for at least
> a week.  If you need it more quickly, drop me an email and
> I'll try to email you a Stuffit file.  It is for MacPython 2.1.1
> on the PPC.
> 
> -Tom Loredo
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 



From jack@oratrix.nl  Tue Nov 27 10:00:52 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 27 Nov 2001 11:00:52 +0100
Subject: [Pythonmac-SIG] Problem with W and shelve (Python 2.11)
In-Reply-To: Message by "Josh English" <english@spiritone.com> ,
 26 Nov 2001 12:50:50 -0800 , <3C02AB2A.7D5A74A7@spiritone.com>
Message-ID: <20011127100052.C6111303183@snelboot.oratrix.nl>

> After my Mac crashed I had to reinstall Python 2.1.1 from scratch, and
> now my old files aren't working properly. I had a database of my books
> in a shelve file, and I had created a program using W to give me a GUI
> editor for the database. It worked fine before the crash, now the IDE
> just quits as soon as I run the file. 
> [...]
> Does anyone have any suggestions to trouble shoot this one. I think an
> error message pops up in it's own window, but it is just a flash before
> it all disappears.

Ah, this last sentence gives a lead! At least something knows that something 
is wrong. You should try and get to read this error message, or try to get a 
stack trace from your program and/or the IDE.

What you could try doing is running the IDE from source, with a couple of 
runtime options turned on that may allow you to see the output. Option-drag 
PythonIDE.py (it's in :Mac:Tools:IDE) to the PythonInterpreter, and in the 
initial options dialog set at least "interactive after script" and "keep 
console open always". There's a chance that this is good enough to make the 
flashing dialog stay. If it doesn't there's a good chance that after the IDE 
crashes you'll get a normal interpreter prompt in the normal interpreter 
window. Type "import pdb ; pdb.pm()" and you can start doing post-mortem 
debugging.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From steve@spvi.com  Tue Nov 27 10:38:45 2001
From: steve@spvi.com (Steve Spicklemire)
Date: Tue, 27 Nov 2001 05:38:45 -0500
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
In-Reply-To: <B8287D26.7CBE%mis@creazone.com>
Message-ID: <EEE18109-E322-11D5-A20E-0050E480B13C@spvi.com>

Hi Michal,

I think Gadfly is a great SQL database for testing, prototyping and 
small/simple production systems. If I recall correctly Aaron Watters 
originally developed it as a teaching tool for a SQL class he was 
teaching. It's provided as an example SQL database (with adaptor) in 
Zope, but is not otherwise used in Zope's internals (e.g., ZODB). It's 
nice since it's written completely in python so you can easily embed it 
in any python application with (essentially) no installation/maintenance 
headaches. It's also pretty darn fast, considering there are no 
extensions involved in it's implementation! It's limitations include the 
fact that all the database data is memory resident, and it doesn't live 
happily in heavily threaded environments (i.e., you can test with it in 
Zope, but don't expect it to work when multiple Zope threads need access 
to the database at the same time!).

Anyway.. all from memory, but I think mostly right.

take care,
-steve

On Monday, November 26, 2001, at 11:13 PM, Michal Seta wrote:

> And how about gadfly?
> it works on a Mac and it's SQL-aware.  It's called kwP now.  And isn't 
> ZODB
> based on gadfly?
> Sorry if I'm completely off.
>
> ./MiS
>
> On 11/26/01 1:53 PM, Tom Loredo @ loredo@astrosun.astro.cornell.edu 
> wrote:
>
>>
>> Hi-
>>
>> If you need SQL-ish capability, this won't help you.  But if you
>> just need a handy and very Pythonic way to store and retrieve
>> objects, I've compiled the Zope Object Database (ZODB) for
>> the Mac.  I will put it online soon, but I'm swamped this week
>> (and out of town most of it), so it won't happen for at least
>> a week.  If you need it more quickly, drop me an email and
>> I'll try to email you a Stuffit file.  It is for MacPython 2.1.1
>> on the PPC.
>>
>> -Tom Loredo
>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig



From marcus.h.mendenhall@vanderbilt.edu  Tue Nov 27 14:53:33 2001
From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall)
Date: Tue, 27 Nov 2001 08:53:33 -0600
Subject: [Pythonmac-SIG] sample Piddle code
Message-ID: <p04330100b82956ea473e@[129.59.235.75]>

--============_-1205249677==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>
>Also, I'm concerned about practical stuff such as reporting and label
>printing.  Are there Python modules for these tasks that work well, or other
>means for accomplishing this?  From what I can tell printing is still one of
>the weaknesses of Python.

the Piddle module is your friend for printing.  It is in the process 
of being superseded by Sping, but I don't think the quickdraw backend 
is in Sping, and it works great in Piddle.

Piddle is a platform-independent (reasonably) graphics interface for 
Python.  The most important part of it is that it generates pdf's 
beautifully, which gives a nice interface for printing documents.  I 
use it for label printing, etc. routinely.  I have a (very crude) 
label printing package built on Piddle (it's only about 30 lines of 
code) which, if you are interested, I can send along as an example of 
using Piddle.

In this round of the message, I have attached a sample label-printing 
utility.  I gzipped it to prevent line-break problems that mailers 
tend to create.  It should be moderately self-explanatory, but I can 
give help as needed.

Marcus Mendenhall



>Any help would be appreciated.
>
>Thanks,
>Gordon R. Vaughan

--============_-1205249677==_============
Content-Id: <p04330100b82956ea473e@[129.59.235.75].0.0>
Content-Type: multipart/appledouble; boundary="============_-1205249677==_D============"


--============_-1205249677==_D============
Content-Transfer-Encoding: base64
Content-Type: application/applefile; name="%labels.py.gz"
Content-Disposition: attachment; filename="%labels.py.gz"
 ; modification-date="Mon, 26 Nov 2001 18:15:33 -0600"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAAwAAAAJAAAASgAAACAA
AAAIAAAAagAAABBsYWJlbHMucHkuZ3pTSVQhU0lUeAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAOVQ0UDlUNFS20MAAOWERM=
--============_-1205249677==_D============
Content-Type: application/octet-stream; name="labels.py.gz"
 ; x-mac-type="53495421"
 ; x-mac-creator="53495478"
Content-Disposition: attachment; filename="labels.py.gz"
Content-Transfer-Encoding: base64

H4sICBXNAjwAA2xhYmVscy5weQDFVVtv2zYUfhZ/BacgkxSrKmUnTmpAD12LPgxLUWB9
Sw2Fk6iYmEw5Ep1ILfrfd3gRJbfD0D7NgAWe+8dzPpJ8f2haiQ+8LGuG+Fz68PadU9AH
1vHPrEOoapu9dcDWykWxQ6imf7G6pJJmX5Dn+fSJtcPN1fra3+Av2G+b5w5WSxJjv2jq
416AeAlCT/wNSVbXVxcqDSgGUGCSrJdOUw5aM8m9v1kmZJVOLgocODmcSc2kZO3XGDss
6+UqPcGSnmBZ/QSWNCGnWK5/BshVuib/HxD0FaGipl2H9cA6Jo+HDfJKVuE854LLPA87
VlexsQu6ZzHuJG0loM2IXQNatWa9bGneT8tBLS8uCiqeaNccZBdBbk/lS4xODgeWOX4l
8H+j9aOXKjJWc5FQbKwKOi6qJnNsu3Mwt7McXaa87gK1DLazRKPBtjvYet5oLQdjU611
IWU/KvtJ2ROrhDltF7YJo3EYjcNkHJAuwyssGhlO3Ul2tMv/ZkMYqBkFke6WN9nvjH5r
QRsBnXqMEwav7wPRtD1jzOjhUA/hNxOJcRjFGM/GhjzDibKlz4Yoc1YUzVHIGO8HZY61
k57K+0YwvYeqaeFaKFkPX9xS8cDCKdDs0gTPkcQmBChmh3VhR7CwXbcWGKq1DAvb8glD
pHKPCRZZqkTouyNS5pigUTjGWNeJcUSLY6jiZebYZUInxpKZbPaSVPWx24WRNzYyz0tW
27M1OxR107Ew0mNSXkZ2PrPqv2QEQ1NHeCBu0L+XRN8hO90T4gqNOjF5nmVBnu8pF3ke
QD59ue/Lq/Fmh+VEAz4y181JTeSk9wrS2WMGYRrG2WNyPMAhZeG9jrhf3I+u98ae1Y14
CB+THetLDjyWYXT34mazjXG61h52ayrsT9lycFZauEqLpmQbfE5ScnxxTi5LH5/j8NFC
iyZsVSOkvXCSd7AOK1qwLJB8z7oACAXHJLuJvq11e6wl/4MLdlr092Yn8K/4lrYDftuw
T2K5Tlf4tRjw6yeQboePzbOI8cf3mKifr299CDRgFjc/CAd2IWnNiyzVwP4bF8C6ZVQC
rN8YFfjNjtf8k3j1Mn25JCQ1EByCyx9D8MohIBqBoqciTObTttjxJ7Yxd0JyKCsfeXCr
To9JOHv6Zy9EQpb2aXIvBTzhRqUq6PTqo45MbXZrL57lSDEZKSBnlpyVGnUrGzjKoJxJ
yQfojQxNMnOyaqyc0D+xmbTX7ggAAA==
--============_-1205249677==_D============--
--============_-1205249677==_============--


From marcus.h.mendenhall@vanderbilt.edu  Tue Nov 27 14:57:54 2001
From: marcus.h.mendenhall@vanderbilt.edu (Marcus H. Mendenhall)
Date: Tue, 27 Nov 2001 08:57:54 -0600
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
In-Reply-To: <l03130300b828b774105e@[217.4.158.203]>
References: <200111241742828.SM00138@[207.218.205.180]>
 <200111241742828.SM00138@[207.218.205.180]>
 <l03130300b828b774105e@[217.4.158.203]>
Message-ID: <p04330101b82959b3eeba@[129.59.235.75]>

First, note the 3 line count was an embarrassing typo I noticed when 
I got the message back from the list.  It's about 30 lines.  In 
another message to the list, I have posted the code, though. h

>Hello,
>
>"Marcus H. Mendenhall" <marcus.h.mendenhall@vanderbilt.edu> wrote on
>Mon, 26 Nov 2001 08:16:45 -0600:
>
>>beautifully, which gives a nice interface for printing documents.  I
>>use it for label printing, etc. routinely.  I have a (very crude)
>>label printing package built on Piddle (it's only about 3 lines of
>>code) which, if you are interested, I can send along as an example of
>>using Piddle.
>
>oh yes. Please could you send these few lines to the list, or perhaps the
>full Python script?
>
>I'm using Piddle too and want to point to ReportLab, which can create
>pdf-files (-reports) too.
>
>>the Piddle module is your friend for printing.  It is in the process
>>of being superseded by Sping.
>
>Can you tell more about the coming successor of Piddle, Sping? Last time I
>looked at it at sourceforge.net I didn't find any working package or only a
>clone of an elder Piddle package afair.

The reason I haven't said more about sping is that I am still using 
Piddle.  I couldn't get Sping to work without a bunch of messing 
around and, as I mentioned, the last time I tried the QD backed 
didn't exist.  Since Piddle works awfully well (after one figures out 
how to use it and its sidekick, graphite, a scientific graphing 
package).

Marcus


From bobsavage@mac.com  Tue Nov 27 21:56:56 2001
From: bobsavage@mac.com (Bob Savage)
Date: Tue, 27 Nov 2001 15:56:56 -0600
Subject: [Pythonmac-SIG] Python-friendly Databases for the Mac
In-Reply-To: <EEE18109-E322-11D5-A20E-0050E480B13C@spvi.com>
Message-ID: <B8296848.19E7C%bobsavage@mac.com>

'Lo, all.

I did a small program using Gadfly and it worked quite nicely at first, but
as my data collection revved up I blew out the engine's capability, due to
its "in memory" model. If I remember correctly I was adding 10,000
datapoints (records) per month. If you aren't going to have anything near
that number of records, it should be fine. One great thing is it uses the
standard Python database interface, so you could use it to start, and switch
to a different backend that is compliant with Python-DB API 2.0 without much
trouble, if you need to do so later.


best of luck,

Bob

on 11/27/01 4:38 AM, Steve Spicklemire wrote:

> Hi Michal,
> 
> I think Gadfly is a great SQL database for testing, prototyping and
> small/simple production systems. If I recall correctly Aaron Watters
> originally developed it as a teaching tool for a SQL class he was
> teaching. It's provided as an example SQL database (with adaptor) in
> Zope, but is not otherwise used in Zope's internals (e.g., ZODB). It's
> nice since it's written completely in python so you can easily embed it
> in any python application with (essentially) no installation/maintenance
> headaches. It's also pretty darn fast, considering there are no
> extensions involved in it's implementation! It's limitations include the
> fact that all the database data is memory resident, and it doesn't live
> happily in heavily threaded environments (i.e., you can test with it in
> Zope, but don't expect it to work when multiple Zope threads need access
> to the database at the same time!).
> 
> Anyway.. all from memory, but I think mostly right.
> 
> take care,
> -steve




From Benjamin.Schollnick@usa.xerox.com  Wed Nov 28 13:07:16 2001
From: Benjamin.Schollnick@usa.xerox.com (Schollnick, Benjamin)
Date: Wed, 28 Nov 2001 08:07:16 -0500
Subject: [Pythonmac-SIG] EasyDialog? ID Values?
Message-ID: <E2D1934575D1D411973D00508BB02F173024D8@usa0129ms1.ess.mc.xerox.com>

Folks,

	I have noticed that in EasyDialogs, there are ID numbers, that
	appear to be associated with each dialog style?

	Is there any place, I can lookup these ID's?  To see if there is
	a different dialog window style, I'd like to implement?

		- Benjamin


From jack@oratrix.nl  Wed Nov 28 13:30:07 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 28 Nov 2001 14:30:07 +0100
Subject: [Pythonmac-SIG] EasyDialog? ID Values?
In-Reply-To: Message by "Schollnick, Benjamin" <Benjamin.Schollnick@usa.xerox.com> ,
 Wed, 28 Nov 2001 08:07:16 -0500 , <E2D1934575D1D411973D00508BB02F173024D8@usa0129ms1.ess.mc.xerox.com>
Message-ID: <20011128133008.13640303183@snelboot.oratrix.nl>

> 	I have noticed that in EasyDialogs, there are ID numbers, that
> 	appear to be associated with each dialog style?
> 
> 	Is there any place, I can lookup these ID's?  To see if there is
> 	a different dialog window style, I'd like to implement?

The DLOG resources are stored in PythonCore. If you're building from source 
you can find the "sources" in :Mac:Resources:Dialogs.rsrc.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From dsp@mac.com  Wed Nov 28 16:06:31 2001
From: dsp@mac.com (Donovan Preston)
Date: Wed, 28 Nov 2001 08:06:31 -0800
Subject: [Pythonmac-SIG] sys.executable not set properly when running as a framework
Message-ID: <E3760AE5-E419-11D5-B475-000502EE274C@mac.com>

Hey,

I've run in to this a couple of times since I have been using Python 
exclusively on OS X built as a Framework. When built and installed as a 
framework, python reports that sys.executable is:

/Library/Frameworks/Python.framework/Versions/2.2/Python

Which may or may not be technically right. But since certain scripts 
assume they can execute the value of sys.executable to get a new python 
interpreter, they fail. Instead, they need to be pointed to

/Library/Frameworks/Python.framework/Versions/Current/bin/python.exe

Not sure if and how this can be fixed, but it would be nice.

Donovan



From jack@oratrix.nl  Wed Nov 28 20:29:19 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 28 Nov 2001 21:29:19 +0100
Subject: [Pythonmac-SIG] sys.executable not set properly when running as a framework
In-Reply-To: Message by Donovan Preston <dsp@mac.com> ,
 Wed, 28 Nov 2001 08:06:31 -0800 , <E3760AE5-E419-11D5-B475-000502EE274C@mac.com>
Message-ID: <20011128202924.8D650E2677@oratrix.oratrix.nl>

Donovan,
could you submit a bug report about this through
python.sourceforge.net? That way it'll remain on my to do list (or
I'll offload it to someone else:-) and it won't get lost...
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jack@oratrix.nl  Wed Nov 28 20:36:22 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Wed, 28 Nov 2001 21:36:22 +0100
Subject: [Pythonmac-SIG] New MacPython 2.2b2 installer
Message-ID: <20011128203627.2FDC2E2677@oratrix.oratrix.nl>

Folks,
a new MacPython 2.2b2 installer (build 116) is available at
http://www.cwi.nl/ftp/jack/python/mac . The version of last weekend
had 3 serious problems that should be solved in this one:
- PythonCore was compiled with debug, making it slow
- MacOS 8.1 support was broken, this should be fixed
- Edit->Copy from the console window didn't work.
If you installed the previous 2.2b2 you can install this one over it
without any special precautions (I hope:-).

Again, report serious problems within 24 hours, after that I'll
announce this one wider.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | ++++ see http://www.xs4all.nl/~tank/ ++++


From nathan@vividworks.com  Wed Nov 28 20:40:28 2001
From: nathan@vividworks.com (Nathan Heagy)
Date: Wed, 28 Nov 2001 14:40:28 -0600 (CST)
Subject: [Pythonmac-SIG] sys.executable not set properly when running as
 a framework
In-Reply-To: <20011128202924.8D650E2677@oratrix.oratrix.nl>
Message-ID: <Pine.OSX.4.33.0111281438180.3338-100000@vividworks.com>

Hate to jump in here with something so nearly off-topic, but are there any
good documents on using Python as a framework? Not just how (which is
important too) but why?

I'm particularly interested in developing real OS X apps with Python, so
anything that suggests where the framework's progress affects that would
be great.

Nathan



On Wed, 28 Nov 2001, Jack Jansen wrote:

> Donovan,
> could you submit a bug report about this through
> python.sourceforge.net? That way it'll remain on my to do list (or
> I'll offload it to someone else:-) and it won't get lost...
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
> www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From TattooMabonzoK.  Thu Nov 29 07:51:15 2001
From: TattooMabonzoK. (TattooMabonzoK.)
Date: Thu, 29 Nov 2001 08:51:15 +0100
Subject: [Pythonmac-SIG] sys.executable not set properly when running as a framework
In-Reply-To: <E3760AE5-E419-11D5-B475-000502EE274C@mac.com>
Message-ID: <DD4AEE2C-E49D-11D5-9B27-003065C18BA0@easynet.be>

On Wednesday, November 28, 2001, at 05:06 PM, Donovan Preston wrote:

> Hey,
>
> I've run in to this a couple of times since I have been using 
> Python exclusively on OS X built as a Framework. When built and 
> installed as a framework, python reports that sys.executable is:
>
> /Library/Frameworks/Python.framework/Versions/2.2/Python
>
> Which may or may not be technically right. But since certain 
> scripts assume they can execute the value of sys.executable to get 
> a new python interpreter, they fail. Instead, they need to be

I've *just* noticed this too while compiling mxTools.

> pointed to
>
> /Library/Frameworks/Python.framework/Versions/Current/bin/python.exe

Don't you think it rather point to

/Library/Frameworks/Python.framework/Versions/2.2/bin/python.exe

(ie a specific python interpreter instead of the "current" (ie more 
latest rev) one)

Maybe I'm mistaken here (I haven't tested it, will try and do it 
tonight though) that this would allow for multiple python 
installations to co-exist.

>
> Not sure if and how this can be fixed, but it would be nice.
>
> Donovan
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>



From robb@sophitia.tera-byte.com  Thu Nov 29 19:26:03 2001
From: robb@sophitia.tera-byte.com (Robert Brown)
Date: Thu, 29 Nov 2001 12:26:03 -0700
Subject: [Pythonmac-SIG] Installing modules
Message-ID: <200111291926.MAA08733@sophitia.tera-byte.com>

How do I install modules in MacPython?  I see Numpy is already there, but I'd like to use Scientific Python and VTK too.  I'm setting up both Mac Python and command line Python.  I've already got Scipy working with the command line version, now I'd like to have it in MacPython as well.

Thanks,

Robb Brown
Seaman Family MR Research Centre
Calgary, Alberta, Canada


From jakob.spies@spmtechnologies.com  Fri Nov 30 09:08:00 2001
From: jakob.spies@spmtechnologies.com (Jakob Spies)
Date: Fri, 30 Nov 2001 10:08:00 +0100
Subject: [Pythonmac-SIG] copy() in macostools.py
Message-ID: <75FE1C8FE217E945AFBF635BFB505D3106749C@fallback.spmtechnologies.com>

The implementation of file copying in macostools.copy() looks like this

	d = ifp.read(BUFSIZ)
	while d:
		ofp.write(d)
		d = ifp.read(BUFSIZ)
		
It should, however, look similar to this:
	
	d = ifp.read(BUFFER_SIZE)
	while d:
		ofp.write(d)
		if (len(d) >= BUFFER_SIZE):
			# last read did not encounter EOF
			d = ifp.read(BUFFER_SIZE)
		else:
			# save useless but expensive read attempt
			break;

I think you get the point. 
I have tried this in a Python program mainly concerned with copying files
that are smaller than 512 KB (=BUFSIZ), and the speed improved significantly
(because of half as much file input accesses).


From jack@oratrix.nl  Fri Nov 30 10:42:22 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 30 Nov 2001 11:42:22 +0100
Subject: [Pythonmac-SIG] copy() in macostools.py
In-Reply-To: Message by Jakob Spies <jakob.spies@spmtechnologies.com> ,
 Fri, 30 Nov 2001 10:08:00 +0100 , <75FE1C8FE217E945AFBF635BFB505D3106749C@fallback.spmtechnologies.com>
Message-ID: <20011130104222.CCE92303183@snelboot.oratrix.nl>

If you're sure that the speed of macostools.copy() improves significantly by 
getting rid of the single read() call then there's something much more serious 
going on.

Even though a Python function call is not trivial the whole process of going 
into read(), calling stdio fread(), seeing that we're at end-of-file and 
returning "" should not take more than a microsecond or two.

Could you maybe do some measurements to see how expensive a read() call is 
while at end of file?

> The implementation of file copying in macostools.copy() looks like this
> 
> 	d = ifp.read(BUFSIZ)
> 	while d:
> 		ofp.write(d)
> 		d = ifp.read(BUFSIZ)
> 		
> It should, however, look similar to this:
> 	
> 	d = ifp.read(BUFFER_SIZE)
> 	while d:
> 		ofp.write(d)
> 		if (len(d) >= BUFFER_SIZE):
> 			# last read did not encounter EOF
> 			d = ifp.read(BUFFER_SIZE)
> 		else:
> 			# save useless but expensive read attempt
> 			break;
> 
> I think you get the point. 
> I have tried this in a Python program mainly concerned with copying files
> that are smaller than 512 KB (=BUFSIZ), and the speed improved significantly
> (because of half as much file input accesses).
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 

--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.cwi.nl/~jack        | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From dpreston@intersight.com  Mon Nov 12 23:21:42 2001
From: dpreston@intersight.com (Donovan Preston)
Date: Mon, 12 Nov 2001 15:21:42 -0800
Subject: [Pythonmac-SIG] Re: CarbonEvents -> MacPython
In-Reply-To: <20011212192238-r01010800-6a8c7a12-0922-010c@10.0.0.23>
Message-ID: <081E921B-D7C4-11D5-89BA-003065B33450@intersight.com>

Hi Just,

I wanted to respond to this publicly to let everyone know that yes, I am 
very interested in this module and am using it fairly heavily in some OS 
X desktop applications. I apologize to everyone that I've either been 
too busy or too lazy to report on my general progress building killer 
Carbon Events-based applications on both OS X and OS 9. :-)

On Wednesday, December 12, 2001, at 10:22 AM, Just van Rossum wrote:
>
> Hi Donovan,
>
>> From the CVS log msgs I understand that you're the original author of 
>> the
> CarbonEvt module. I'm doing some work on it (like making it build under 
> CW), but
> there is at least one issue that's beyond me: this MP stuff in the 
> event handler
> code and in RunApplicationEventLoop(). I see USE_MAC_MP_MULTITHREADING 
> is
> manually defined. However, if it _is_ defined, at least
> RunApplicationEventLoop() doesn't work under OS 9.x (it throws a 
> SystemError
> exception, which is bad all by itself...). So for now I've simply 
> disabled it.
> Are you still interested in the module? If so, maybe we can sort out a 
> few
> things together. Most of my changes are already in CVS.

I also have a few changes to the module on my local hard drive at home 
which make the module build properly under OS X. I have been unable to 
figure out how to create a diff and this is the reason why I haven't 
submitted the changes to Jack (they are quite trivial, however.) If 
someone could tell me how I could generate a diff from the terminal on 
OS X, on a CVS checkout which I have modified locally, I would 
appreciate it. Perhaps then this module can become part of the standard 
build process and I can stop worrying about making sure it is there 
separately.

Here's the issue I had with RunApplicationEventLoop which I tried to 
solve with the code between USE_MAC_MP_MULTITHREADING: (I put it between 
that define specifically so someone could turn it off if it was 
problematic)

When python calls a C function, it assumes that C function COULD be 
calling the C Python api to manipulate python objects, call functions, 
etc. Therefore it hands the global interpreter lock to the C function 
and waits until the function returns before executing any more python 
code. Simple enough for doing most things in C like calculating the 
value of 2 + 2, building a python object out of the result, and 
returning it to python.

But when you call RunApplicationEventLoop, you are entering into a black 
hole from which control will not be returned until your app exits.

Also, if you have registered any event handlers before calling 
RunApplicationEventLoop (your app would be pretty boring if you hadn't), 
the OS will call your code from within the black hole of 
RunApplicationEventLoop and the python interpreter will be kicked off 
again.

Problem is, the OS sometimes likes to call an event handler __while__ 
another event is still being handled. This causes two threads of 
execution to try to execute python code in the same interpreter at the 
same time. Bad news.

So, I needed a mutex lock. I can't use a python lock, because acquiring 
it requires executing python code, which would be bad if some python 
code is already running (somebody correct me if I'm wrong here.) Apple 
never needed to define traditional mutex locks because the toolbox API 
is a cooperative one UNTIL Apple came out with MultiProcessor machines, 
so the mutex lock API I picked (for the very reason that it IS 
compatible with OS 9, as opposed to some BSD call...) is 
MPCreateCriticalRegion/MPDeleteCriticalRegion/MPEnterCriticalRegion/MPExitCriticalRegion.

To make a long story short, I specifically chose this API for it's OS 9 
compatibility. As a matter of fact, I had at one time (months ago) 
compiled it on OS 9 as a proof-of-concept for my boss to prove that yes 
indeed the apps I am developing will be (eventually) deployable on OS 9. 
So it surprises me that you are getting an error. Sigh.

I also see just now (three hours after I started writing this message) 
that you've put some error handling code into the event handler. That's 
one of the pieces of code that's sitting on my hard drive waiting to be 
diffed to the CVS. (I believe that may be all, actually.)

Also, while I have your attention, has anyone made any progress on the 
two remaining modules needed to be built in order to run the IDE on pure 
Mach-O/Framework enabled python? (Scrap and WASTE, I believe) If not I 
may tackle it soon.

I'm very excited about helping make MacPython kick ass, and sorry that I 
don't take more time out to give a progress report on what I'm doing to 
the list.

Donovan