From tom@othermedia.com  Tue Jan  2 10:10:19 2001
From: tom@othermedia.com (tom smith)
Date: Tue, 02 Jan 2001 10:10:19 +0000
Subject: [Pythonmac-SIG] love python, but Discouraged with Mac IDLE
In-Reply-To: <PKHHFEGMPDDDBAAA@mailcity.com>
Message-ID: <B677598B.3BA7%tom@othermedia.com>

on 30/12/00 6:11 pm, kevin parks at cpsoct@lycos.com wrote:
> It was meant to be constructive. Like when your
> wife, whom you love to no end, tries something with her hair that just isn't
> working....

Well dear, maybe if you hunt down pyAdvancedEditor (:mac:tools:ide:) Follow
the instructions...http://www.strout.net/python/mac/

..and darling, there is a plug-in for Alpha because I've tried it...you'll
have to search for it, but I prefer MacPython.

...with regards to pretty printing, if you mean in the output window, try...

import pprint
pprint.pprint(dir(pprint))

...if you have a PC, give pythonWin or (I like this one) Komodo a whirl...

It's true that MacPython sometimes has a bad hair day, but then again,
what's the alternative? Perl in BBEdit? ugh?!

cheers

tom



From redbird@rbisland.cx  Wed Jan  3 03:59:34 2001
From: redbird@rbisland.cx (Gordon Worley)
Date: Tue, 02 Jan 2001 22:59:34 -0500
Subject: [Pythonmac-SIG] building extensions on OSX
In-Reply-To: <20001231122932.0F7DD143DD5@oratrix.oratrix.nl>
References: <20001231122932.0F7DD143DD5@oratrix.oratrix.nl>
Message-ID: <f05001902b677bc23385d@[10.50.227.20]>

At 1:29 PM +0100 12/31/2000, Jack Jansen wrote:
>I haven't played with OSX a lot yet, but I have heard the rumour that
>it is extremely picky about multiple definitions (on most systems,
>include MacOS9 and most Unixes Im familiar with, this would be a
>warning at most, and Python and mysql would happily use their local
>copy of Pickler_setattr).

In some ways, I wish that it were a rumor (it just means I have to be 
careful with the include statements).  At the moment I'm taking an 
Advanced Placement Computer Science A (this is the first year it was 
offered, but fortunately most colleges that I've seen won't give 
credit for AB anyway) and have to write command line programs in C++ 
(I don't like C++ that much, but it is okay, except for when they 
want us to do string manipulation and I get frustrated with the fact 
that my 10 lines of C++ could be 2 in Python).  Anyway, some of the 
labs that we have to do (where we get some code and have to extend it 
in a specific way to learn about features of C++), sometimes programs 
refuse to compile because a header file was included twice (first 
included in file x, then file x included in file y, but file y also 
includes the header file, thus resulting in duplicate name errors). 
When I am under SuSE Linux, this never happens.  So, it's not just 
rumor, OS X is picky in this area.
-- 
Gordon Worley
http://www.rbisland.cx/
mailto:redbird@rbisland.cx
PGP:  C462 FA84 B811 3501 9010  20D2 6EF3 77F7 BBD3 B003


From tmk@easynet.be  Wed Jan  3 14:24:59 2001
From: tmk@easynet.be (Tattoo Mabonzo K.)
Date: Wed, 3 Jan 2001 15:24:59 +0100
Subject: [Pythonmac-SIG] Re: Python 2.0 and MultiUser
Message-ID: <200101031424.f03EOxI00279@metis.usertalk.com>

On Thursday, December 28, 2000, at 05:04 PM, Jack Jansen wrote:

> Bingo!=20
> when you run Python as another user you don't have the preference=20
> file, apparently each user has a completely distinct set of=20
> preferences files. Therefore, each user that wants to use Python must=20=


You're right indeed. I kept deleting the Python Prefs for the computer =
owner instead of those of the current user %-(...

> run InstalPython first. Otherwise the default sys.prefix will be set=20=

> to whereever the first Python applet was run from.=20

An alternative is to trash the user spefic python prefs (which lives @ =
'<startup disk>:Users:<username>:Preferences:Python:Python 2.0') and =
simply run ConfigurePython.

> I'll add a note to the readme file, and I'll also add some code to be=20=

> a bit more intelligent about setting the sys.prefix preference (I=20
> could for instance skip this if the folder from which we're run does=20=

> not contain  :Lib and :Mac subfolders).

Sounds like a good idea.

Thanks a lot Jack!

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


From ranch1@earthlink.net  Sun Jan  7 00:25:35 2001
From: ranch1@earthlink.net (Tom Fetherston)
Date: Sat, 6 Jan 2001 19:25:35 -0500
Subject: [Pythonmac-SIG] Simulating a Remote shell
Message-ID: <v03102801b67d64ce71ba@[38.38.56.221]>

Hi,

I've been working a bit on the communication between the Alpha editor and
Python via PythonSlave.py (Written to facilatate such between BBedit and
Python).  Well I been wondering if it would be possible to mimic python
running in a shell (under Alpha).

On the python side of things I need to have it accept an appleEvent from
Alpha that contains a line of input, run that 'input' and send back the
result to alpha so it can print it out in the mock shell.  Is there a way
to do this?  Whats there already should allow me to write the AppleEvent
handler, I just need a way to execute a line and store the result in a
string as if it where being typed into the interpreter.

An other area where I could use some help is to come up with some way to
pass an argument line into python via an AppleEvent so it mimics a normal,
unix-like command line.

Anyway I can stuff them into the global or local namespace so a program
could see them in argv?  Other ideas?

Thanks for any help.

Tom





From jack@oratrix.nl  Sun Jan  7 22:49:02 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Sun, 07 Jan 2001 23:49:02 +0100
Subject: [Pythonmac-SIG] Simulating a Remote shell
In-Reply-To: Message by Tom Fetherston <ranch1@earthlink.net> ,
 Sat, 6 Jan 2001 19:25:35 -0500 , <v03102801b67d64ce71ba@[38.38.56.221]>
Message-ID: <20010107224907.5B3CE14ADD7@oratrix.oratrix.nl>

Tom,
why not emulate the Python-shell in Python itself? Most of the
emulated-mainloop code is available in IDE (and in IDLE too, and in
various other places), and you could then just put, say, a socket
wrapper around it, or an AppleScript wrapper, or whatever you would
want. 
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From ranch1@earthlink.net  Mon Jan  8 02:26:23 2001
From: ranch1@earthlink.net (Tom Fetherston)
Date: Sun, 7 Jan 2001 21:26:23 -0500
Subject: [Pythonmac-SIG] Simulating a Remote shell
In-Reply-To: <20010107224907.5B3CE14ADD7@oratrix.oratrix.nl>
References: Message by Tom Fetherston <ranch1@earthlink.net> ,	     Sat, 6
 Jan 2001 19:25:35 -0500 , <v03102801b67d64ce71ba@[38.38.56.221]>
Message-ID: <v03102801b67ed32f948b@[38.26.141.187]>

Jack Jansen wrote:
>Tom,
>why not emulate the Python-shell in Python itself? Most of the
>emulated-mainloop code is available in IDE (and in IDLE too, and in
>various other places), and you could then just put, say, a socket
>wrapper around it, or an AppleScript wrapper, or whatever you would
>want.

I suspected that was the case, but can't sya that I have much more than are
reading familiarity with python yet.  Most of my coding in it so far is cut
paste and modify stuff, so help just locating the above mentioned code
would be helpful.

As to the other thing I would like to do with PythonSlave.py, provide an
appleEvent to fake up a command line invocation with arguments, I been
thinking that using the optional namespace parameters of exec would be part
of the solution, after all once it is parsed the command line exists as a
list; sys.argv at the global level.  How can I create a namespace with at
least sys.argv initialized to pass to exec?  I tried just writting:
exec { sys.argv = ['test.py', 'a', b'] }
but that did not do the trick.

Tom




From richard@richardgordon.net  Mon Jan  8 05:42:31 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Mon, 8 Jan 2001 00:42:31 -0500
Subject: [Pythonmac-SIG] jython on Mac problem
Message-ID: <v04205500b67f01c50014@[64.1.38.58]>

hi-

I recently stumbled across Jython (http://jython.sourceforge.net), 
the apparent successor to JPython, downloaded it, and followed the 
Mac install instructions. I can get it to run, but once the java 
console comes up, it shows the usual version stuff then the >>> 
prompt, then drops another line, and I can't type anything in the 
console or otherwise make any use of it. The menus do work and I'm 
able to quit, but this is pretty frustrating.

I don't have an email address for the guy who posted the Mac 
instructions (L. Humbert?), so I thought I'd see if anyone here has 
run into this and, ideally, found a solution? I am running OS8.6 on 
an 8100->G3 and have tried rebooting with only Apple base extensions 
with no luck. Thanks for any help.

Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From jhrsn@pitt.edu  Mon Jan  8 11:55:25 2001
From: jhrsn@pitt.edu (Jim Harrison)
Date: Mon, 08 Jan 2001 06:55:25 -0500
Subject: [Pythonmac-SIG] jython on Mac problem
In-Reply-To: <v04205500b67f01c50014@[64.1.38.58]>
Message-ID: <B67F14DC.22064%jhrsn@pitt.edu>

on 1/8/01 12:42 AM, Richard Gordon at richard@richardgordon.net wrote:

> I recently stumbled across Jython (http://jython.sourceforge.net),
> the apparent successor to JPython, downloaded it, and followed the
> Mac install instructions. I can get it to run, but once the java
> console comes up, it shows the usual version stuff then the >>>
> prompt, then drops another line, and I can't type anything in the
> console or otherwise make any use of it.

When you build the app in JBindery, make sure the popup menus for "redirect
stin" and "redirect stout" are both set to "message window." The default for
redirect stin in "nowhere," which is why your input typing isn't accepted.

Jim Harrison
Univ. of Pittsburgh


From richard@richardgordon.net  Tue Jan  9 03:49:44 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Mon, 8 Jan 2001 22:49:44 -0500
Subject: [Pythonmac-SIG] jython on Mac problem
In-Reply-To: <B67F14DC.22064%jhrsn@pitt.edu>
References: <B67F14DC.22064%jhrsn@pitt.edu>
Message-ID: <v04205500b68038859d66@[64.1.38.58]>

>When you build the app in JBindery, make sure the popup menus for "redirect
>stin" and "redirect stout" are both set to "message window." The default for
>redirect stin in "nowhere," which is why your input typing isn't accepted.
>
>Jim Harrison
>Univ. of Pittsburgh

hey, thanks a lot, that did the trick. Now my only problem is that 
when I import re, I get an "inconsistent dedent":
>>> import re
Traceback (innermost last):
   File "<console>", line 1, in ?
   File "/Conkie/System Folder/Preferences/jython-2.0b1/Lib/re.py", 
line 28, in ?
   File "/Conkie/System Folder/Preferences/jython-2.0b1/Lib/sre.py", 
line 20, in ?
   File "/Conkie/System 
Folder/Preferences/jython-2.0b1/Lib/sre_parse.py", line 504
SyntaxError: inconsistent dedent
>>>

Since I haven't run into this with MacPython, I tried copying my sre 
files from my normal Lib into the Jython Lib, but it didn't help. I 
couldn't find any glaring errors on a visual scan and if you've got a 
guess about what's going on here, I'd be interested.

Thanks again.


Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From brady@mmm.com  Wed Jan 10 21:47:16 2001
From: brady@mmm.com (mark brady)
Date: Wed, 10 Jan 2001 13:47:16 -0800
Subject: [Pythonmac-SIG] Can't quit
Message-ID: <B6821864.10E9%brady@mmm.com>

I'm new to the sig, so pardon me if this is an old question.

When I import Tkinter and use it to create any window, I am
unable to quit Python IDE (version 1.5.2c1).  I have to reboot
to get out.  Sometimes, when the close box is clicked the created
window will not go away, other times it will.

-Mark 


From cbarker@jps.net  Wed Jan 10 21:22:36 2001
From: cbarker@jps.net (Chris Barker)
Date: Wed, 10 Jan 2001 13:22:36 -0800
Subject: [Pythonmac-SIG] Can't quit
References: <B6821864.10E9%brady@mmm.com>
Message-ID: <3A5CD29C.D20B51E1@jps.net>

mark brady wrote:
> I'm new to the sig, so pardon me if this is an old question.

Yes, it is, but I'll give you a short answer anyway.

> When I import Tkinter and use it to create any window, I am
> unable to quit Python IDE (version 1.5.2c1).  I have to reboot
> to get out.  Sometimes, when the close box is clicked the created
> window will not go away, other times it will.

You can't use tkinter with the IDE, their mainloops get al confused with
each other.

To use use tkinter on the Mac, your best bet is to write your scripts in
an editor, save them as type "PYTH", and double click them to run them
in the interpreter. You can't use the interactive interpretter very well
with tkinter either. For more suggestions, take a look at the achives.

-Chris




-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From ranch1@earthlink.net  Fri Jan 12 03:38:18 2001
From: ranch1@earthlink.net (Tom Fetherston)
Date: Thu, 11 Jan 2001 22:38:18 -0500
Subject: [Pythonmac-SIG] fragment in pyhton ref doc's
Message-ID: <v03102801b68423d73fa4@[38.26.141.41]>

Hi,

Not exactly an html list, but believe it or not this involves Python.  I
cam accross a program that would provide keyword look-ups into the Python
Html doc.  It came in too parts, a python program to parse the url's in the
genindex.html file (in the ref sub directory), it created a dictionary
(keyword : url), then it pickled that dictionary.

I updated it to use the 're' module and to handle the 2.0 doc's, instead of
pickling the dictionary, I have it write out a .tcl file, which when
sourced, provide a Tcl equivalent of the dictionary.  The second part of
this system was a elisp function to initiated a lookup from within emacs.

Noe, I changed this so command-double clicking a keyword in Alpha sends an
AppleEvent to a browser containg the Url.  Most of the urls contain
fragments (e.g. #12h-110) after the filename that are supposed to position
the relevant section in the browser for viewing, however, only Netscape
seems to accept this correctly.  ICab and IE just open the file at the top.
This is also what they do if you click the hyperlink in the index file.

!) Am I stuck with specifying Netscape as the only browser to use?

2) What is this fragment specifying?  My Html 4 ref book does not list this
kind of fragment, is it purely a Netscape extension?

Tom




From richard@richardgordon.net  Fri Jan 12 23:33:20 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Fri, 12 Jan 2001 18:33:20 -0500
Subject: [Pythonmac-SIG] fragment in pyhton ref doc's
In-Reply-To: <v03102801b68423d73fa4@[38.26.141.41]>
References: <v03102801b68423d73fa4@[38.26.141.41]>
Message-ID: <v04205500b68541fd928d@[64.1.38.58]>

>Most of the urls contain
>fragments (e.g. #12h-110) after the filename that are supposed to position
>the relevant section in the browser for viewing, however, only Netscape
>seems to accept this correctly.  ICab and IE just open the file at the top.
>This is also what they do if you click the hyperlink in the index file.
>
>!) Am I stuck with specifying Netscape as the only browser to use?
>
>2) What is this fragment specifying?  My Html 4 ref book does not list this
>kind of fragment, is it purely a Netscape extension?

hi-

I'm not convinced that I am really following you, but maybe this will 
help a little anyway. Generally, a url ending with # followed by a 
string is supposed to seek a named anchor, so #12h-110 would look for 
<a name="12h-110> in the target document. This works pretty much the 
same from one browser to another, so I don't think that's what's 
going on here. Another possibility is that this syntax is somehow 
being used to call the find() javascript function that is supported 
by Netscape but the last time I checked, was not supported by IE and 
probably isn't supported by iCab. This basically just triggers the 
find menu command, fills in the search string, and does the seek 
transparently once the entire target document is loaded.

So, that's my best guess and if it's correct, there's not much you 
can do but go in and hack together something in javascript that would 
trap for IE and maybe try to use textRange or something to emulate 
the find function.


Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From etienne@alias.it  Mon Jan 15 17:13:56 2001
From: etienne@alias.it (Etienne Antoniutti Di Muro)
Date: Mon, 15 Jan 2001 18:13:56 +0100
Subject: [Pythonmac-SIG] INCREMENTING & DECREMENTING PyObjects
References: <20010113170103.B2A5CEC55@mail.python.org>
Message-ID: <3A632FD4.3B21C494@alias.it>

Dear List members,

    I'm developping a GUI application (C++) with a python kernel (using
PythonCore 1.5.2 for embedding/extending).

    One issue in not perfectly clear: how to manage reference counts, when it
is required, when not, when  completely wrong.

    Some questions:
        If I Py_DECREF a Class Instance held by the C++ GUI, do I have to
Py_DECREF all its fields?

        If I do not create PyObject in the C++ GUI, but I ask its reference to
the  Python Interpreter, what do I get : A copy of the reference of the
                object? What reference count does it hold?? Do I have to
Py_INCREF , for further use into the C++ GUI?? And what to do when i dispose
                the object?
       .....


that's it !!  :-))

thanks  in advance
etienne





--
      it's time to leave this town
      it's time to steal away
      let's  go get lost
      anywhere in the U.S.A.   (RHCP)





From jack@oratrix.nl  Tue Jan 16 09:11:46 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 16 Jan 2001 10:11:46 +0100
Subject: [Pythonmac-SIG] INCREMENTING & DECREMENTING PyObjects
In-Reply-To: Message by Etienne Antoniutti Di Muro <etienne@alias.it> ,
 Mon, 15 Jan 2001 18:13:56 +0100 , <3A632FD4.3B21C494@alias.it>
Message-ID: <20010116091147.06C6A3C2031@snelboot.oratrix.nl>

>     Some questions:
>         If I Py_DECREF a Class Instance held by the C++ GUI, do I have to
> Py_DECREF all its fields?

In general: yes. Normally if you store a reference to an object anywhere you 
should INCCREF it, if you delete the reference again you DECREF it.

>         If I do not create PyObject in the C++ GUI, but I ask its reference to
> the  Python Interpreter, what do I get : A copy of the reference of the
>                 object? What reference count does it hold?? Do I have to
> Py_INCREF , for further use into the C++ GUI??

Normally not, but it depends on the function you use to obtain the reference. 
Almost all of the core Python functions will do the INCREF before returning 
the object.

You should probably read "Extending and Embedding Python", which you can find 
on www.python.org, which has the exact details about increffing and decreffing.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From cbarker@jps.net  Tue Jan 16 21:08:55 2001
From: cbarker@jps.net (Chris Barker)
Date: Tue, 16 Jan 2001 13:08:55 -0800
Subject: [Pythonmac-SIG] NumPy extensions on the Mac: the solution!
References: <B677598B.3BA7%tom@othermedia.com>
Message-ID: <3A64B866.EBE22187@jps.net>

Hi all,

For any of you that may have fopllowed my whining about not being able
to get NumPy extensions working, Jack found the solution! (thank you ,
thank you ,thank you!)

Jack Jansen Wrote:
> The current Numeric uses a global (C) array of pointers to all sorts
> of interesting things, PyArray_API. Each module that uses array *must* 
> initialize this pointer by calling import_array() (which is a macro
> defined in arrayobject.h). If your arrayobject.h has this macro that
> is probably the solution (call it in your init routine). On unix the
> ommission of calling import_array() would immedeately result in a bus
> error from dereferencing a null pointer, but not so on the Mac, alas.
> 
> Older Numeric releases did not have this import_array() magic, but I
> think you would have gotten a link error then: all you extensions had
> to link against the .slb with arrayobject in it.

Adding import_array() to my init routine did indeed fix the problem. The
od thing is that it works just fine on Linux without it, perhaps I have
a newer version of NumPy on Linux. There was also no mention of it in
the NumPy docs, but again, maybe a newer version there as well (no
version number in the docs I'm using)

Thanks to everyone that has helped me with this.

-Chris





-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From tjsulli@hatch.sonalysts.com  Wed Jan 17 02:51:54 2001
From: tjsulli@hatch.sonalysts.com (Timothy Sullivan)
Date: Tue, 16 Jan 2001 21:51:54 -0500 (EST)
Subject: [Pythonmac-SIG] possible bug with division operator and floating point numbers
Message-ID: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>

Hello All,
	I am just starting out learning python, and have only
just subscribed to this list when I found this "feature." I am going
through O'Reilly's Learning python and duitifully put in one of the
examples into the interactive prompt. it basically worked out to 4.0/5.0 .
which came back with the answer, "0.80000000000000004." Now I have been
out of school for a bit, but Ilearned that should be 0.8. I tried
different variations of the equation, and the same answer results. i tried
similar equations, 3.0/4, 1/2.0 and came up with the expected results. I
am using the 2.0 version of pythonmac from python.org. Am I being stupid
and this is expected, or perhaps there is an update to this problem I
could not find. Sorry if this has been covered previously, but any
thoughts would be appreciated.

Regards,
T.J. Sullivan 



From richard@richardgordon.net  Wed Jan 17 05:01:06 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Wed, 17 Jan 2001 00:01:06 -0500
Subject: [Pythonmac-SIG] possible bug with division operator and
 floating point numbers
In-Reply-To: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
Message-ID: <v04205503b68ad59d7703@[64.1.38.58]>

> it basically worked out to 4.0/5.0 .
>which came back with the answer, "0.80000000000000004." Now I have been
>out of school for a bit, but Ilearned that should be 0.8.

Maybe this has been covered here & I missed it, but you are certainly 
correct and it's certainly strange. The same thing happens on NT, so 
it's not a Mac thing and doing 4.0/5.0 yielded .8 on Debian Linux 
running Python 1.5.2, so my conclusion is that something is broken in 
Python 2. Altho the practical consequences of an error that small 
don't seem like much to me, I'm not doing astronomy calculations or 
other things where it might matter and it suggests that some other 
stuff needs to be examined as well.


Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From johannh@uclink.berkeley.edu  Wed Jan 17 08:03:14 2001
From: johannh@uclink.berkeley.edu (Johann Hibschman)
Date: Wed, 17 Jan 2001 00:03:14 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and floating point numbers
In-Reply-To: <v04205503b68ad59d7703@[64.1.38.58]>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com> <v04205503b68ad59d7703@[64.1.38.58]>
Message-ID: <01011700071600.30757@random>

On Tue, 16 Jan 2001, Richard Gordon wrote:
> > it basically worked out to 4.0/5.0 .
> >which came back with the answer, "0.80000000000000004." Now I have been
> >out of school for a bit, but Ilearned that should be 0.8.
> 
> Maybe this has been covered here & I missed it, but you are certainly 
> correct and it's certainly strange.

No, this is correct.  Python 2.0 has switched to using the exact printable
representation of numbers in interactive mode.  It now prints out what repr
printed before, the number to all decimal places.  I do suspect that a better
algorithm exists for this, though.

What you're seeing is the fact that floating-point numbers aren't exact.
That's just the way that floats are, on any platform.  Before, the interpreter
hid this from you.  Now, it displays it in all its glory.

You should never count on a float to be exact, and never test a float for
equality.  The last digit is effectively random.

-- 
Johann Hibschman
johannh@uclink.berkeley.edu


From cbarker@jps.net  Wed Jan 17 18:20:05 2001
From: cbarker@jps.net (Chris Barker)
Date: Wed, 17 Jan 2001 10:20:05 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and floating
 point numbers
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com> <v04205503b68ad59d7703@[64.1.38.58]> <01011700071600.30757@random>
Message-ID: <3A65E255.5D8D9169@jps.net>

Johann Hibschman wrote:
> On Tue, 16 Jan 2001, Richard Gordon wrote:
> > > it basically worked out to 4.0/5.0 .
> > >which came back with the answer, "0.80000000000000004." Now I have been
> > >out of school for a bit, but Ilearned that should be 0.8.
> No, this is correct.  Python 2.0 has switched to using the exact printable
> representation of numbers in interactive mode.  It now prints out what repr
> printed before, the number to all decimal places.  I do suspect that a better
> algorithm exists for this, though.
> 
> What you're seeing is the fact that floating-point numbers aren't exact.
> That's just the way that floats are, on any platform.  Before, the interpreter
> hid this from you.  Now, it displays it in all its glory.

This is right, but there is a little more to it. Not only are floating
point calculations not neccesarily exact, but they are are done in base
2, so that numbers that you would expect to be exact in base ten are not
exact in base 2. The classic example is 1/10 which can be represented
exactly in base ten as 0.1, but can't be exactly represented in base
two. this is what Python 2.0 gives:

>>> 1.0/10.0
0.10000000000000001 

> You should never count on a float to be exact, and never test a float for
> equality.  The last digit is effectively random.

quite true. I don't know how many "bug reports" I've seen that have code
something like
x = 0.0
while not x == 1:
    print x  
    x = x+0.1

And then someone complains that the loop never terminates.

This, of course, works fine:
x = 0.0
while x < 1:
    print x
    x = x+0.1       

-Chris



-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From jwblist@olympus.net  Thu Jan 18 03:28:06 2001
From: jwblist@olympus.net (John W Baxter)
Date: Wed, 17 Jan 2001 19:28:06 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and
 floating   point numbers
In-Reply-To: <3A65E255.5D8D9169@jps.net>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
 <v04205503b68ad59d7703@[64.1.38.58]> <01011700071600.30757@random>
 <3A65E255.5D8D9169@jps.net>
Message-ID: <p05010404b68c12697d4f@[207.149.192.229]>

At 10:20 -0800 1/17/01, Chris Barker wrote:
>quite true. I don't know how many "bug reports" I've seen that have code
>something like
>x = 0.0
>while not x == 1:
>    print x
>    x = x+0.1
>
>And then someone complains that the loop never terminates.
>
>This, of course, works fine:
>x = 0.0
>while x < 1:
>    print x
>    x = x+0.1

Indeed, which is why my habit is to avoid writing the loop terminator as an
equality (there are other examples in which it is bad) unless absolutely
necessary.   (Actually, I'd write your termination test above as x < 1.005
or something, just in case there are more high values than low in .0 .1 ...
.9 .)

The fact that I still possess the habit clearly shows I haven't used the
C++ Standard Template Library much, where the iterations work with equality
tests (and can fail with anything else).

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


From richard@richardgordon.net  Thu Jan 18 04:19:19 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Wed, 17 Jan 2001 23:19:19 -0500
Subject: [Pythonmac-SIG] possible bug with division operator and
 floating   point numbers
In-Reply-To: <3A65E255.5D8D9169@jps.net>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
 <v04205503b68ad59d7703@[64.1.38.58]> <01011700071600.30757@random>
 <3A65E255.5D8D9169@jps.net>
Message-ID: <v04205500b68c1c222dd1@[64.1.38.58]>

>This is right, but there is a little more to it. Not only are floating
>point calculations not neccesarily exact, but they are are done in base
>2, so that numbers that you would expect to be exact in base ten are not
>exact in base 2. The classic example is 1/10 which can be represented
>exactly in base ten as 0.1, but can't be exactly represented in base
>two.

Well, thanks to you and the others who've expounded on this a bit. I 
learn something new everyday, or at least identify new things that I 
don't understand.  :->

Altho this isn't a significant issue in itself for most people, it is 
a curiosity that I could see causing some hapless hack like myself to 
waste hours trying to resolve if it incidentally showed up while 
debugging a script. Note to self: round final results off so you 
won't be flummoxed by this in the future.


Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From redbird@rbisland.cx  Wed Jan 17 22:02:55 2001
From: redbird@rbisland.cx (Gordon Worley)
Date: Wed, 17 Jan 2001 17:02:55 -0500
Subject: [Pythonmac-SIG] possible bug with division operator and floating
 point numbers
In-Reply-To: <01011700071600.30757@random>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
 <v04205503b68ad59d7703@[64.1.38.58]> <01011700071600.30757@random>
Message-ID: <f05001902b68bc61faa8a@[10.50.227.19]>

At 12:03 AM -0800 1/17/2001, Johann Hibschman wrote:
>On Tue, 16 Jan 2001, Richard Gordon wrote:
>>  > it basically worked out to 4.0/5.0 .
>>  >which came back with the answer, "0.80000000000000004." Now I have been
>>  >out of school for a bit, but Ilearned that should be 0.8.
>>
>>  Maybe this has been covered here & I missed it, but you are certainly
>>  correct and it's certainly strange.
>
>No, this is correct.  Python 2.0 has switched to using the exact printable
>representation of numbers in interactive mode.  It now prints out what repr
>printed before, the number to all decimal places.  I do suspect that a better
>algorithm exists for this, though.
>
>What you're seeing is the fact that floating-point numbers aren't exact.
>That's just the way that floats are, on any platform.  Before, the interpreter
>hid this from you.  Now, it displays it in all its glory.
>
>You should never count on a float to be exact, and never test a float for
>equality.  The last digit is effectively random.

Since the original poster mentioned being new to Python, a bit of 
slicing will take care of display problems, though won't fix the 
number as a float:

num = 4.0 / 5.0
`num`[:-1]

slices off that last 4, which is easy enough.  Something is the 
matter, though, because:

float(`num`[:-1])

yields

0.80000000000000004

and even just typing 0.8 in the interpreter returns the above number. 
There is bound to be a work around, but should be discussed 
elsewhere, since it isn't Mac specific.
-- 
Gordon Worley
http://www.rbisland.cx/
mailto:redbird@rbisland.cx
PGP:  C462 FA84 B811 3501 9010  20D2 6EF3 77F7 BBD3 B003


From etienne@alias.it  Thu Jan 18 09:04:25 2001
From: etienne@alias.it (Etienne Antoniutti Di Muro)
Date: Thu, 18 Jan 2001 10:04:25 +0100
Subject: [Pythonmac-SIG] INCREMENTING & DECREMENTING PyObjects
References: <20010116091147.06C6A3C2031@snelboot.oratrix.nl>
Message-ID: <3A66B198.222AA147@alias.it>

Dear Jack & List Members:
2 - Questions (#1 is a personal note experience-based,#2 is the heavy stuff )

Jack Jansen wrote:

> [.....]
> Almost all of the core Python functions will do the INCREF before returning
> the object.

> You should probably read "Extending and Embedding Python", which you can find
> on www.python.org, which has the exact details about increffing and decreffing.
>

1-
Yes, I noticed, but some differences apply, ie:

"""
  PyObject *result, *aPythonClass;
  char* aMethodName,*aFieldName,*aClassName;

  result = PyObject_GetAttrString(aPythonClass, aFieldName); // ie a aPythonClass
field that is a string;
  // is "reference-count-neutral" respect to aPythonClass

 result = PyObject_GetAttrString(aPythonClass, aClassName); // ie a aPythonClass
fiels that is a Python Class;
  // is "reference-count-neutral" respect to aPythonClass

 result = PyObject_GetAttrString(aPythonClass, aMethodName); // ie a aPythonClass
method
 // Py_INCREFS aPythonClass, thus Py_DECREF(aPythonClass) is needed  to mantain ref
count correct within the C code.

// anyway this makes a lot of sense.

"""

I'm wondering if I'll find similar behaviours with different embedding
funcitons......i.e. PyObject_CallMethod(PyObject *o, char *name, char *format, ...)

This is a pretty interesting and handy function, and I intensively use it , but it
is scarcely referenced in Python manuals & companions, while PyEval_CallObject is
exaustively described.

2-
The INCREMENTING & DECREMENTING PyObjects question in this Thread title was because
i'm running into problems with
Python memory management.The set of python functions I run, is embedded into a C
GUI on the Macintosh. Since the interpreter does *NOT DEALLOCATES* memory when I
release PyObjects used either by the gui and the interpreter, I was supposing that
it was my fault in increffing and decreffing objects.
That's why I've deeply investigated into the object reference counts, guessing I
was coding wrong somewhere.Now I'm sure the C GUI increffs and (most important)
decreffs PyObjects properly.
The result is that the Python Interpreter sucks all the application memory causing
the application to crash (exit).
*BUT* I performed the following tests:
1 -  I've run my python code from the python ide (notice: same code without the C
embedding api).Result: It sucks all the memory allocated by the python ide, causing
it to except a Memory error;
2- I've run my python code on a Linux OS.Result: It worked perfectly, deallocating
memory as espected.

This convinced me that it is due to the Python garbage collector, is this correct?

Is there a way to force the PythonCore garbage collector to deallocate memory when
objects are disposed??
There's a path you can suggest for further investigation??
I'm using PythonCore 1.5.2, Is there any resonable chance that Python 2.0 will do a
better job?



thanks
etienne
--
      it's time to leave this town
      it's time to steal away
      let's  go get lost
      anywhere in the U.S.A.   (RHCP)





From etienne@alias.it  Thu Jan 18 11:52:27 2001
From: etienne@alias.it (Etienne Antoniutti Di Muro)
Date: Thu, 18 Jan 2001 12:52:27 +0100
Subject: [Pythonmac-SIG] Re:INCREMENTING & DECREMENTING PyObjects
Message-ID: <3A66D8FB.F2191755@alias.it>

Dear Jack & List Members:
2 - Questions (#1 is a personal note experience-based,#2 is the heavy
stuff )

Jack Jansen wrote:

> [.....]
> Almost all of the core Python functions will do the INCREF before returning
> the object.

> You should probably read "Extending and Embedding Python", which you can find
> on www.python.org, which has the exact details about increffing and decreffing.
>

1-
Yes, I noticed, but some differences apply, ie:

"""
  PyObject *result, *aPythonClass;
  char* aMethodName,*aFieldName,*aClassName;

  result = PyObject_GetAttrString(aPythonClass, aFieldName); // ie a aPythonClass
field that is a string;
  // is "reference-count-neutral" respect to aPythonClass

 result = PyObject_GetAttrString(aPythonClass, aClassName); // ie a aPythonClass
fiels that is a Python Class;
  // is "reference-count-neutral" respect to aPythonClass

 result = PyObject_GetAttrString(aPythonClass, aMethodName); // ie a aPythonClass
method
 // Py_INCREFS aPythonClass, thus Py_DECREF(aPythonClass) is needed  to
mantain ref
count correct within the C code.

// anyway this makes a lot of sense.

"""

I'm wondering if I'll find similar behaviours with different embedding
funcitons......i.e. PyObject_CallMethod(PyObject *o, char *name, char
*format, ...)

This is a pretty interesting and handy function, and I intensively use
it , but it
is scarcely referenced in Python manuals & companions, while
PyEval_CallObject is
exaustively described.

2-
The INCREMENTING & DECREMENTING PyObjects question in this Thread title
was because
i'm running into problems with
Python memory management.The set of python functions I run, is embedded
into a C
GUI on the Macintosh. Since the interpreter does *NOT DEALLOCATES*
memory when I
release PyObjects used either by the gui and the interpreter, I was
supposing that
it was my fault in increffing and decreffing objects.
That's why I've deeply investigated into the object reference counts,
guessing I
was coding wrong somewhere.Now I'm sure the C GUI increffs and (most important)
decreffs PyObjects properly.
The result is that the Python Interpreter sucks all the application
memory causing
the application to crash (exit).
*BUT* I performed the following tests:
1 -  I've run my python code from the python ide (notice: same code
without the C
embedding api).Result: It sucks all the memory allocated by the python
ide, causing
it to except a Memory error;
2- I've run my python code on a Linux OS.Result: It worked perfectly, deallocating
memory as espected.

This convinced me that it is due to the Python garbage collector, is
this correct?

Is there a way to force the PythonCore garbage collector to deallocate
memory when
objects are disposed??
There's a path you can suggest for further investigation??
I'm using PythonCore 1.5.2, Is there any resonable chance that Python
2.0 will do a
better job?



thanks
etienne
--
      it's time to leave this town
      it's time to steal away
      let's  go get lost
      anywhere in the U.S.A.   (RHCP)



From landauer@apple.com  Thu Jan 18 19:56:37 2001
From: landauer@apple.com (Doug Landauer)
Date: Thu, 18 Jan 2001 11:56:37 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and floating point numbers
In-Reply-To: <v04205500b68c1c222dd1@[64.1.38.58]>
Message-ID: <200101181956.LAA09476@scv3.apple.com>

> Well, thanks to you and the others who've expounded on this a bit. I 
> learn something new everyday, or at least identify new things that I 
> don't understand.  :->
>
> Altho this isn't a significant issue in itself for most people, it is a 
> curiosity that I could see causing some hapless hack like myself to 
> waste hours trying to resolve...

The use of floating point in Python should come along with a suggestion
to go to deja.com and read everything that Tim Peters has written in
comp.lang.python, about floating point.  That gives one a much better
appreciation of just how much there is to know about floating point.

Basically, the summary is:  it's subtler and more complex than you
thought.  But Tim says that so entertainingly ...

    -- Doug



From brady@mmm.com  Thu Jan 18 20:15:14 2001
From: brady@mmm.com (mark brady)
Date: Thu, 18 Jan 2001 12:15:14 -0800
Subject: [Pythonmac-SIG] Double CLickable
Message-ID: <B68C8ED2.113C%brady@mmm.com>

I noticed that the demos execute upon double clicking.  How do I
make my source file (BBEdit) so that it will execute in this way.

-Mark 


From johannh@uclink.berkeley.edu  Thu Jan 18 20:38:17 2001
From: johannh@uclink.berkeley.edu (Johann Hibschman)
Date: Thu, 18 Jan 2001 12:38:17 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and floating point numbers
In-Reply-To: <v04205500b68c1c222dd1@[64.1.38.58]>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com> <3A65E255.5D8D9169@jps.net> <v04205500b68c1c222dd1@[64.1.38.58]>
Message-ID: <01011812444900.02826@random>

On Wed, 17 Jan 2001, Richard Gordon wrote:

> Altho this isn't a significant issue in itself for most people, it is 
> a curiosity that I could see causing some hapless hack like myself to 
> waste hours trying to resolve if it incidentally showed up while 
> debugging a script. Note to self: round final results off so you 
> won't be flummoxed by this in the future.

Right.  It is confusing.  One thing you can do is always print numbers
using "str" rather than "repr".  The interpreter now defaults to repr,
which I don't like.  I'll have to argue this again with Ping tonight.

>>> 0.8
0.80000000000000004
>>> repr(0.8)
'0.80000000000000004'
>>> str(0.8)
'0.8'                                                                           

The problem is that there are two different philosophical positions for
repr.  One, that it should print something with enough information to
exactly reconstruct the object.  Two, that it should print what you want
to see from the interpreter.

I tend to side with 2, but that's the debate.

-- 
Johann Hibschman
johannh@uclink.berkeley.edu


From cbarker@jps.net  Thu Jan 18 19:06:28 2001
From: cbarker@jps.net (Chris Barker)
Date: Thu, 18 Jan 2001 11:06:28 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and
 floatingpoint numbers
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
 <v04205503b68ad59d7703@[64.1.38.58]> <01011700071600.30757@random> <f05001902b68bc61faa8a@[10.50.227.19]>
Message-ID: <3A673EB4.BD1AB5B8@jps.net>

Gordon Worley wrote:
>  Something is the
> matter, though, because:
> 
> float(`num`[:-1])
> 
> yields
> 
> 0.80000000000000004
> 
> and even just typing 0.8 in the interpreter returns the above number.
> There is bound to be a work around, but should be discussed
> elsewhere, since it isn't Mac specific.

Yes, it should, but since we're here now:

Nothing is the matter. eight tenths can not be exactly represented as a
float in base two, even though it can be with only 2 digits in base ten.
See my previous post. This, by the way has nothing to do with Python,
and you will have the same effect in any language on all binary
arithmetic machines, which is most, unless the language has specific
support for base ten arithmetic (I have never heard of one that does,
but I wouldn't be surprised if it exists)

By the way, another solution to at least the interation problem is to
generate your list ahead of time with arrayrange (need Numeric, but I
really wish Python had a standard range that could deal with floats)

from Numeric import *

for x in arange(0,1.1,.1):
	print x


Note another interesting thing about how Python 2.0 prints:

>>> 0.1
0.10000000000000001
>>> x = 0.1
>>> print x
0.1
>>>                    

So, if you print a variable, rather than a direct computation, you get
it reaonably rounded. It's the difference between repr and str:

>>> print repr(0.1)
0.10000000000000001
>>> print str(0.1)
0.1
>>>            

Curious.

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From jack@oratrix.nl  Thu Jan 18 22:01:36 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Thu, 18 Jan 2001 23:01:36 +0100
Subject: [Pythonmac-SIG] Re: INCREMENTING & DECREMENTING PyObjects
In-Reply-To: Message by Etienne Antoniutti Di Muro <etienne@alias.it> ,
 Thu, 18 Jan 2001 12:52:27 +0100 , <3A66D8FB.F2191755@alias.it>
Message-ID: <20010118220141.5570E16235D@oratrix.oratrix.nl>

Recently, Etienne Antoniutti Di Muro <etienne@alias.it> said:
>  result = PyObject_GetAttrString(aPythonClass, aMethodName); // ie a aPythonC
> lass
> method
>  // Py_INCREFS aPythonClass, thus Py_DECREF(aPythonClass) is needed  to
> mantain ref
> count correct within the C code.


No, please don't do that! The reference count to aPythonClass indeed
increments, but that has a completely different reason. The method
object carries a reference to the class.
> 
> // anyway this makes a lot of sense.
> 
> """
> 
> I'm wondering if I'll find similar behaviours with different embedding
> funcitons......i.e. PyObject_CallMethod(PyObject *o, char *name, char
> *format, ...)
> 
> This is a pretty interesting and handy function, and I intensively use
> it , but it
> is scarcely referenced in Python manuals & companions, while
> PyEval_CallObject is
> exaustively described.

Probably because it wasn't written by Guido:-). It is a convenience
function in Object/abstract.c. You can always download the source (or
browse it on python.sourceforge.org), but in this case I'l tell you
that it does it's refcounting correctly. You are of course responsible 
for decreffing the return value.

> 2-
> The INCREMENTING & DECREMENTING PyObjects question in this Thread title
> was because
> i'm running into problems with
> Python memory management.The set of python functions I run, is embedded
> into a C
> GUI on the Macintosh. Since the interpreter does *NOT DEALLOCATES*
> memory when I
> release PyObjects used either by the gui and the interpreter, I was
> supposing that
> it was my fault in increffing and decreffing objects.

This is a question that has many answers. A general answer is that it
could be caused by circular references. Python has no "real" garbage
collection, so if a number of objects have circular references to each 
other they will never be released.

Another answer is that under MacPython 1.5.2 (not under 2.0 anymore)
it used its own malloc(). This used to be quite a bit faster (about a
20% increase in Python's speed), but memory that was once allocated to 
Python's malloc would never be returned to the system pool. (It would
be re-used for other Python objects, but usually only for objects of a 
similar size). Recently the CodeWarrior malloc() has gotten a lot
better, so as of 2.0 MacPython uses the standard malloc().

If you use MacPython 1.5.2 then MetroWerks ZoneRanger can provide
quite a bit of insight. You can also recompile MacPython with
MALLOC_DEBUG, which not only makes malloc/free do consistency checks
but also gives you a dump routine you can call through a method in the 
MacOS module (sorry, forgot the name). Under 2.0 all this doesn't work 
anymore, but you could probably re-enable the private malloc (the
sources are still there).

What may be even better (and also works under 2.0) is recompiling
Python with Py_REF_DEBUG or Py_TRACE_REFS.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From jwblist@olympus.net  Thu Jan 18 22:49:14 2001
From: jwblist@olympus.net (John W Baxter)
Date: Thu, 18 Jan 2001 14:49:14 -0800
Subject: [Pythonmac-SIG] possible bug with division operator and
 floating  point numbers
In-Reply-To: <f05001902b68bc61faa8a@[10.50.227.19]>
References: <Pine.BSI.3.96.1010116214329.16696B-100000@hatch.sonalysts.com>
 <v04205503b68ad59d7703@[64.1.38.58]> <01011700071600.30757@random>
 <f05001902b68bc61faa8a@[10.50.227.19]>
Message-ID: <p05010407b68d2143c09d@[207.149.192.229]>

At 17:02 -0500 1/17/01, Gordon Worley wrote:
>Since the original poster mentioned being new to Python, a bit of
>slicing will take care of display problems, though won't fix the
>number as a float:
>
>num = 4.0 / 5.0
>`num`[:-1]
>
>slices off that last 4, which is easy enough.  Something is the
>matter, though, because:
>
>float(`num`[:-1])
>
>yields
>
>0 .80000000000000004
>
>and even just typing 0.8 in the interpreter returns the above number.
>There is bound to be a work around, but should be discussed
>elsewhere, since it isn't Mac specific.

Nothing is wrong, except that binary floating point is being used.  0.8 is
not exactly representable (at any number of bits) in binary floating point.
(20% of the single digit decimals are:  x.0 and x.5...the others are not.)

To make things more fun, some computations which "we know" result in .8
won't result in .80000000000000004

Consider
>>> 0.3 + 0.3 + 0.3 - 0.1
0.79999999999999993

(which [I think] at least shows that the .8...04 value is closer than the
next lower possible value, a Good Thing, since that's how it's supposed to
be).

The above example along with
>>> .03
0.029999999999999999

make slicing NOT the way to do it in general.

The solution is to use the right tool.  Which often isn't floating point.
(Or, for money, decimal floating point:  in the early days when BASIC was
Microsoft's primary product, they shipped two versions, one using binary
floating point for speed, the other using decimal floating point for
sanity.)

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


From jbmoody@oakland.edu  Thu Jan 18 22:53:16 2001
From: jbmoody@oakland.edu (Jon Moody)
Date: Thu, 18 Jan 2001 17:53:16 -0500
Subject: [Pythonmac-SIG] Behavior of os.path.join() on the Mac
Message-ID: <20010118175315.B11247@oakland.edu>

I'm familiar with Python on Linux, but the behavior of os.path.join()
in MacPython is confusing me:

<Linux>
>>> r = 'a/b/c'
>>> s = 'd/e/f'
>>> os.path.join(r,s)
'a/b/c/d/e/f'
>>> t = '/x/y/z'
>>> os.path.join(r,t)
'/x/y/z'
>>> os.path.join(t,r)
'/x/y/z/a/b/c'
>>> os.path.join(t,s,r)
'/x/y/z/d/e/f/a/b/c'

<Mac>
>>> r = 'a:b:c'
>>> s = 'd:e:f'
>>> os.path.join(r,s)
'd:e:f'
>>> t = 'Startup Disk:y:z'
>>> os.path.join(r,t)
'Startup Disk:y:z'
>>> os.path.join(t,r)
'a:b:c'
>>> os.path.join(t,s,r)
'a:b:c'


Is it wrong to think of the Mac's Startup Disk as sort of like a root
directory?  Even so, why would MacPython's os.path.join() just throw
away all the path component arguments except the last one with a ':'
inside it? 

Jon


From richard@richardgordon.net  Fri Jan 19 03:28:10 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Thu, 18 Jan 2001 22:28:10 -0500
Subject: [Pythonmac-SIG] Double CLickable
In-Reply-To: <B68C8ED2.113C%brady@mmm.com>
References: <B68C8ED2.113C%brady@mmm.com>
Message-ID: <v04205500b68d622ac7a0@[64.1.38.58]>

>I noticed that the demos execute upon double clicking.  How do I
>make my source file (BBEdit) so that it will execute in this way.

One way is to go into the File Exchange control panel and associate 
.py, .pyc, and .pyo extensions with Python.

This brings to mind a minor gripe that I've developed in the course 
of several months of working in Python on NT- I've set things up so 
that .py is an executable and a script will run when double-clicked, 
but if I right-click instead, I have the option to edit it instead, 
either in PythonWin by default or in vim or visual studio as other 
choices. I find that I miss this choice when working on the Mac and 
am forever launching scripts that I really intended to edit. Does 
anyone happen to know of a Mac contextual menu module that emulates 
this behavior? Assuming yes but you can only choose among apps, how 
would you get it to let you edit in the Mac python IDE- maybe with an 
AppleScript that had been saved as an applet or something?


Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From jack@oratrix.nl  Fri Jan 19 08:54:16 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 19 Jan 2001 09:54:16 +0100
Subject: [Pythonmac-SIG] Behavior of os.path.join() on the Mac
In-Reply-To: Message by Jon Moody <jbmoody@oakland.edu> ,
 Thu, 18 Jan 2001 17:53:16 -0500 , <20010118175315.B11247@oakland.edu>
Message-ID: <20010119085416.CD110373C95@snelboot.oratrix.nl>

> I'm familiar with Python on Linux, but the behavior of os.path.join()
> in MacPython is confusing me:
> [...]

Jon,
I think that what confuses you is Mac pathnames. Whereas on unix "a/b" is a 
relative path and "/a/b" is an absolute path on the mac it's the other way 
around: "a:b" is an absolute path and ":a:b" is a relative path. So in your 
example you're joining all absolute paths, and the join of two absolute paths 
is by definition the second path.

There is an exception to this rule, by the way: a filename without any colon 
at all is a relative path.

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




From mjb@thp.Uni-Koeln.DE  Fri Jan 19 08:58:22 2001
From: mjb@thp.Uni-Koeln.DE (Michael J Barber)
Date: Fri, 19 Jan 2001 09:58:22 +0100
Subject: [Pythonmac-SIG] Double CLickable
References: <B68C8ED2.113C%brady@mmm.com> <v04205500b68d622ac7a0@[64.1.38.58]>
Message-ID: <3A6801AE.1C8E4273@thp.uni-koeln.de>

There are several possibilities to do this.  Probably the best known is
a control panel called Finderpop.  It does a lot more than that as well,
and is "pintware."  

I personally use a CMM called "OpenUsing."  You can set things up so
that the Python IDE will appear at the top of the contextual menu when
you click on a file that ends with .py or has the right file type.  You
have to do some playing around with folders and aliases, but the result
is rather nice.  I wrote some AppleScripts to make setting up the
type-sensitive folders easier; the author of OpenUsing said he would
like to include them in the OU distribution, but I'm not sure if he's
done that yet -- email me if you want them.  Freeware.

There are a number of other CMMs like this, but I haven't tried them. 
You can find them on VersionTracker, of course.

Richard Gordon wrote:
> 
> of several months of working in Python on NT- I've set things up so
> that .py is an executable and a script will run when double-clicked,
> but if I right-click instead, I have the option to edit it instead,
> either in PythonWin by default or in vim or visual studio as other
> choices. I find that I miss this choice when working on the Mac and
> am forever launching scripts that I really intended to edit. Does
> anyone happen to know of a Mac contextual menu module that emulates
> this behavior? Assuming yes but you can only choose among apps, how
> would you get it to let you edit in the Mac python IDE- maybe with an
> AppleScript that had been saved as an applet or something?
>


From jack@oratrix.nl  Fri Jan 19 09:00:54 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Fri, 19 Jan 2001 10:00:54 +0100
Subject: [Pythonmac-SIG] Double CLickable
In-Reply-To: Message by Richard Gordon <richard@richardgordon.net> ,
 Thu, 18 Jan 2001 22:28:10 -0500 , <v04205500b68d622ac7a0@[64.1.38.58]>
Message-ID: <20010119090054.80C1B373C95@snelboot.oratrix.nl>

> >I noticed that the demos execute upon double clicking.  How do I
> >make my source file (BBEdit) so that it will execute in this way.
> 
> One way is to go into the File Exchange control panel and associate 
> .py, .pyc, and .pyo extensions with Python.

I'm not sure that this will help a lot (unless newer version of BBEdit look in 
the File Exchange panel, my trusty old BBEdit Lite 4.1 doesn't). In 4.1 I have 
to go to the BBEdit preferences, File Types, and there add a PythonInterpreter 
file type.

> This brings to mind a minor gripe that I've developed in the course 
> of several months of working in Python on NT- I've set things up so 
> that .py is an executable and a script will run when double-clicked, 
> but if I right-click instead, I have the option to edit it instead, 
> either in PythonWin by default or in vim or visual studio as other 
> choices. I find that I miss this choice when working on the Mac and 
> am forever launching scripts that I really intended to edit. Does 
> anyone happen to know of a Mac contextual menu module that emulates 
> this behavior?

I looked into this when CM first came out and decided that it was doable, but 
never got around to actually doing it. If someone can provide the method to do 
this I'll gladly put it in the installer. The same, by the way, goes for 
adding the .py extension to the File Exchange (and the Internet Config) 
control panels.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From ybenita@mac.com  Fri Jan 19 10:10:38 2001
From: ybenita@mac.com (Yair Benita)
Date: Fri, 19 Jan 2001 11:10:38 +0100
Subject: [Pythonmac-SIG] Writing excel macros
Message-ID: <B68DD12E.524%ybenita@mac.com>

Is there any way to use python for writing excel macros on the Macintosh?
Yair



From Lindsay.Davies@moonshine.co.uk  Fri Jan 19 12:08:34 2001
From: Lindsay.Davies@moonshine.co.uk (Lindsay Davies)
Date: Fri, 19 Jan 2001 12:08:34 +0000
Subject: [Pythonmac-SIG] Behavior of os.path.join() on the Mac
In-Reply-To: <20010118175315.B11247@oakland.edu>
References: <20010118175315.B11247@oakland.edu>
Message-ID: <a05010416b68ddb96c4cb@[195.102.186.233]>

The 'gotcha' here is that whereas on unix you would write a 
root-relative path as...

	/a/b/c/d

...on a Mac (ignoring the path separator differences) it's equivalent to...

	a:b:c:d

where root DOESN'T start with a file separator, but the top-level 
partition's name. This is because in fact you don't have the 
equivalent of root on a Mac. You can have any number of disk 
partitions mounted at the top level of your system - it just so 
happens that most people only have one partition (so the assumption 
is that it's similar to root).

Your code is trying to do the equivalent on a unix system of...

	r = '/a/b/c'
	s = '/d/e/f'
	os.path.join(r,s)

...that is to join two conflicting root-relative paths. You need to 
rewrite the Mac paths as...

	r = ':a:b:c'
	s = ':d:e:f'

...so that they are now relative, as indicated by the leading colon 
(or the second is relative and the first is root-relative).

Best wishes,

Lindsay


On 1/18/01, Jon Moody wrote about '[Pythonmac-SIG] Behavior of 
os.path.join() on the Mac':
>I'm familiar with Python on Linux, but the behavior of os.path.join()
>in MacPython is confusing me:
>
><Linux>
>  >>> r = 'a/b/c'
>>>>  s = 'd/e/f'
>  >>> os.path.join(r,s)
>'a/b/c/d/e/f'
>>>>  t = '/x/y/z'
>>>>  os.path.join(r,t)
>'/x/y/z'
>>>>  os.path.join(t,r)
>'/x/y/z/a/b/c'
>>>>  os.path.join(t,s,r)
>'/x/y/z/d/e/f/a/b/c'
>
><Mac>
>  >>> r = 'a:b:c'
>  >>> s = 'd:e:f'
>>>>  os.path.join(r,s)
>'d:e:f'
>>>>  t = 'Startup Disk:y:z'
>>>>  os.path.join(r,t)
>'Startup Disk:y:z'
>>>>  os.path.join(t,r)
>'a:b:c'
>>>>  os.path.join(t,s,r)
>'a:b:c'
>
>
>Is it wrong to think of the Mac's Startup Disk as sort of like a root
>directory?  Even so, why would MacPython's os.path.join() just throw
>away all the path component arguments except the last one with a ':'
>inside it?
>
>Jon
>
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig



From anewcombe@earthlink.net  Fri Jan 19 12:26:11 2001
From: anewcombe@earthlink.net (Amos Newcombe)
Date: Fri, 19 Jan 2001 07:26:11 -0500
Subject: [Pythonmac-SIG] Double CLickable
In-Reply-To: <20010119090054.80C1B373C95@snelboot.oratrix.nl>
References: <20010119090054.80C1B373C95@snelboot.oratrix.nl>
Message-ID: <a05001902b68ddee4741c@[38.26.127.40]>

>  > am forever launching scripts that I really intended to edit.

I solve this problem by using BBEdit group files. These are files 
that contain, not text, but just a list of other files. The group 
file window shows the file names, with buttons for maintaining the 
list. For each project I create such a file including all the source 
files, as well as other group files, or library source files, 
whatever I want to have quickly available when working on that 
project. Double-clicking on any of these in the group file window 
opens up the file in BBEdit. (Even binary files, if that floats your 
boat.)

Double-click on the file in the finder to launch the script. Or drag 
it to the IDE alias conveniently sitting on the desktop. Whatever.

Something of a PITA, but I like to have the group window there to 
remind me of what I can look at, even from distant folders.

My BBEdit is 5.1, but I think group files have been around for awhile.

Amos
-- 
The difference between theory and practice is that, in theory, there 
is no difference between theory and practice. 


From richard@richardgordon.net  Sat Jan 20 15:33:44 2001
From: richard@richardgordon.net (Richard Gordon)
Date: Sat, 20 Jan 2001 10:33:44 -0500
Subject: [Pythonmac-SIG] Writing excel macros
In-Reply-To: <B68DD12E.524%ybenita@mac.com>
References: <B68DD12E.524%ybenita@mac.com>
Message-ID: <v04205500b68f5c95c2f6@[64.1.38.58]>

>Is there any way to use python for writing excel macros on the Macintosh?

I doubt if you could do this directly, but since you can control 
execution of excel VBA macros via applescript and you can do raw 
apple events from MacPython, then I would expect that with enough 
head scratching you could probably figure this out. I haven't messed 
with Excel Mac in a long time but am under the impression that what 
M$ wants you to do is set up the subs and functions in Excel using 
VBA, then call them externally with Evaluate which can pass 
parameters, etc. Frankly I've never gotten a handle on python's apple 
event support and don't know exactly how to pull this off, but I'd 
start by writing an AppleScript that worked and watching what it was 
doing via the Capture AE control panel to get the Apple event syntax 
that you will need for your python stuff.

I'm kind of interested in the topic because I have been doing a lot 
of work in Office for windoze using python entirely in lieu of VB and 
there are so many things about the Office applications that really 
blow that I can see where there is a need for a suite of utilities to 
make up for some of their more grotesque omissions. In that 
environment, you can manipulate the baroque object models directly 
with the win32 extensions for python because they provide COM 
support, but I don't think that there is a clean way to do this in 
the Mac environment (somebody tell me I'm wrong, please).


Richard Gordon
--------------------
Gordon Design
Web Design/Database Development
http://www.richardgordon.net


From rwklee@home.com  Sat Jan 20 20:28:03 2001
From: rwklee@home.com (Rick Lee)
Date: Sat, 20 Jan 2001 15:28:03 -0500
Subject: [Pythonmac-SIG] Thread not unblocked by socket's accept, recv
Message-ID: <3A69F4D2.185F65DC@home.com>

Hi,

I am running MacPython 2.0 on MacOS 8.5.1.

After much experimentation, I come to the conclusion that on my machine,
a thread does not get unblocked by a socket's accept() method, even when
a condition to cause the unblocking has occurred.  Same thing with a
socket's recv() method.  I have this thread running inside a .py file,
which is executed with an execfile command in the interpreter.

Is this intended behaviour, a limitation, or a bug?  Is there a
workaround?

Note, same thing also happens with time.sleep(); so it leads me to
believe that this problem is not limited to sockets.  Some other
experimentation also leads to this conclusion: if a thread is blocked by
time.sleep(), some other code calling time.sleep() will unblock this
thread.  I have a hunch this would also with the above socket's methods;
but I have not set up this experiment.

Thanks.

- Rick Lee



From tom@othermedia.com  Mon Jan 22 11:14:16 2001
From: tom@othermedia.com (tom smith)
Date: Mon, 22 Jan 2001 11:14:16 +0000
Subject: [Pythonmac-SIG] Double CLickable
In-Reply-To: <a05001902b68ddee4741c@[38.26.127.40]>
Message-ID: <B691BD7C.3CE2%tom@othermedia.com>

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

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

on 19/1/01 12:26 pm, Amos Newcombe at anewcombe@earthlink.net wrote:

>>> am forever launching scripts that I really intended to edit.

Attached is an applescript that "Makes a file type like..." another. Drop a
file on it and it asks you to choose what sort of file you'd like it to be
like...



--MS_Mac_OE_3063006856_387242_MIME_Part
Content-type: application/applefile; name="Make FileType like..."
Content-transfer-encoding: base64
Content-disposition: attachment

AAUWAAACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAACAAAAADAAAAXgAAABUAAAAC
AAAAcwAAMA9BUFBMZHBsdCEAAj8AKQAAAAAAAAAAAAAAAAAAAAAAAE1ha2UgRmlsZVR5cGUg
bGlrZS4uLgAAAQAAACxRAAArUQAAA74AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKWOAA
H0AAAAMgAAAAAEZUaGlzIHNjcmlwdCBpcyB0byBxdWlja2x5IG1ha2UgYSBmaWxlJ3MgdHlw
ZSBsaWtlIGFub3RoZXIuLi4NVG9tIFNtaXRoAAAAFgABAAAAAAAQAAwAAAAAAAwAAAAAAAAA
AAACAAAAAAAUACoAIALsAzoAKgAgAuwDOgAAAAEAABcORmFzZFVBUyAxLjEwMS4xMA4AAAAE
D///AAEAAgADAf//AAANAAEAAWsAAAAAAAAABAIABAACAAUABg0ABQACagAAAAAAAv/+AAcL
//4AGDAACnRoZWNyZWF0b3IACnRoZUNyZWF0b3INAAcAAW0AAAAAAAEACAwACAAKAAQqKioq
AAIAAAIABgACAAkACg0ACQACagAAAAMABf/9AAsL//0AGjAAC3RoZWZpbGV0eXBlAAt0aGVG
aWxlVHlwZQ0ACwABbQAAAAMABAAMDAAMAAoABCoqKioAAgAAAgAKAAIADQAODQANAAJsAAEA
AAAA//z/+wH//AAAAf/7AAACAA4AAgAPABANAA8AAmwAAgAAAAD/+v/5Af/6AAAB//kAAAIA
EAACABEAEg0AEQACaQAAAAYACQATABQNABMAA0kAAgAAAAD/+P/3//YK//gAGC5hZXZ0b2Fw
cG51bGwAAIAAAACQACoqKioB//cAAAL/9gAADQAUAAJsAAIAAAAA//X/9AH/9QAAAf/0AAAC
ABIAAgAVABYNABUAAmwAAgAAAAD/8//yAf/zAAAB//IAAAIAFgACABcAGA0AFwACbAACAAAA
AP/x//AB//EAAAH/8AAAAgAYAAIAGQAaDQAZAAJpAAAACgANABsAHA0AGwADSQACAAAAAP/v
AB3/7gr/7wAYLmFldnRvZG9jbnVsbAAAgAAAABAAYWxpcw0AHQABbwAAAAAAAP/tC//tAAcw
AANkb2MAAAL/7gAADQAcAAFrAAAAAACFAB4CAB4AAgAfACANAB8AAmwAAQAAAAD/7AAhAf/s
AAAMACEAMAAqZmluZCBpbmZvIGFib3V0IGl0ZW1zIGRyb3BwZWQgb250byBkcm9wbGV0AAIA
AAIAIAACACIAIw0AIgAEWgAAAAAAEQAkACX/6//qDQAkAAI+AQAAAAAFACYAJw0AJgACbgAD
AAAAAwAoACkNACgAAW0AAAABAAP/6Qr/6QAECnBjbHMNACkAAW8AAAAAAAH/6Av/6AAHMAAD
ZG9jAAANACcAAW0AAAADAAT/5wr/5wAECmxpc3QNACUAAnIAAAAIAA0AKgArDQAqAAFKAAAA
CAALACwCACwAAgAt/+YNAC0AAW8AAAAIAAn/5Qv/5QAHMAADZG9jAAAC/+YAAA0AKwABbwAA
AAAAAP/kC//kAAcwAANkb2MAAAL/6wAAAf/qAAACACMAAgAuAC8NAC4AAmwAAQASABL/4wAw
Af/jAAAMADAAIQAbaWYgdGhlQ3JlYXRvciA9ICIqKioqIiB0aGVuAAIAAAIALwACADEAMg0A
MQACcgAAABIAHAAzADQNADMAA0kAAgASABr/4gA1ADYK/+IAGC5zeXNvc3RkZmFsaXMAAAAA
//+AAG51bGwNADUAAUoAAAASABT/4QL/4QAABgA2AAP/4AA3/98K/+AABApwcm1wDQA3AAFt
AAAAFQAWADgMADgAHQAXTWFrZSB0aGlzIGZpbGUgbGlrZS4uLj8AAgAABv/fAAANADQAAW8A
AAAAAAD/3gv/3gASMAAHdGhlZmlsZQAHdGhlRmlsZQIAMgACADkAOg0AOQACbAABAB0AHf/d
ADsB/90AAAwAOwAMAAZlbmQgaWYAAgAAAgA6AAIAPAA9DQA8AAJsAAIAHQAd/9z/2wH/3AAA
Af/bAAACAD0AAgA+AD8NAD4AAmwAAgAdAB3/2v/ZAf/aAAAB/9kAAAIAPwACAEAAQQ0AQAAC
TwAAAB0AOwBCAEMNAEIAAWsAAAAhADoARAIARAACAEUARg0ARQACcgAAACEALQBHAEgNAEcA
Am4AAAAhACcASQBKDQBJAAExAAAAJQAn/9gK/9gABApmY3J0DQBKAAI0AAAAIQAl/9cASwr/
1wAECmZpbGUNAEsAAW8AAAAjACT/1gv/1gASMAAHdGhlZmlsZQAHdGhlRmlsZQ0ASAABbwAA
AAAAAP/VC//VABgwAAp0aGVjcmVhdG9yAAp0aGVDcmVhdG9yAgBGAAIATP/UDQBMAAJyAAAA
LgA6AE0ATg0ATQACbgAAAC4ANABPAFANAE8AATEAAAAyADT/0wr/0wAECmZpdHANAFAAAjQA
AAAuADL/0gBRCv/SAAQKZmlsZQ0AUQABbwAAADAAMf/RC//RABIwAAd0aGVmaWxlAAd0aGVG
aWxlDQBOAAFvAAAAAAAA/9AL/9AAGjAAC3RoZWZpbGV0eXBlAAt0aGVGaWxlVHlwZQL/1AAA
DQBDAAFtAAAAHQAeAFIPAFIBMghudWxsAAAAAAAB3wD//wAAAB4GRmluZGVyBOUgAJZBoAFk
2SgAAAABDATlMEIABIj/0ZLgDATurAwE5UBKAARE/9Gb3AwE7qwAUJwqAMlGwAAATUFDUwAA
EQBhbGlzAAAAAADUAAIAAAZzeXN0ZW0AAAAAAAAAAAAAAAAAAAAAAAAAAAC1p92/QkQAAAAA
AB4GRmluZGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABp7QEykBGTkRSTUFDU/////8AAAAAAAAAAAAAAAAAAAAAAAAADVN5
c3RlbSBGb2xkZXIAAAEABAAAAB4AAgAbc3lzdGVtOlN5c3RlbSBGb2xkZXI6RmluZGVyAP//
AAACAEEAAgBTAFQNAFMAAmwAAQA8ADz/zwBVAf/PAAAMAFUALQAnZGlzcGxheSBkaWFsb2cg
dGhlQ3JlYXRvciAmIHRoZUZpbGVUeXBlAAIAAAIAVAACAFYAVw0AVgACbAACADwAPP/O/80B
/84AAAH/zQAAAgBXAAIAWABZDQBYAAJsAAIAPAA8/8z/ywH/zAAAAf/LAAACAFkAAgBaAFsN
AFoAA1gAAAA8AIMAXP/KAF0NAFwAAWsAAABMAH4AXgIAXgACAF8AYA0AXwADUQAAAEwAfABh
AGIAYw0AYQACTwAAAE8AbQBkAGUNAGQAAWsAAABTAGwAZgIAZgACAGcAaA0AZwACbAACAFMA
U//J/8gB/8kAAAH/yAAAAgBoAAIAaQBqDQBpAAJyAAAAUwBfAGsAbA0AawABbwAAAFMAWP/H
C//HABgwAAp0aGVjcmVhdG9yAAp0aGVDcmVhdG9yDQBsAAJuAAAAAAAAAG0Abg0AbQABMQAA
AFwAXv/GCv/GAAQKZmNydA0AbgACNAAAAFgAXP/FAG8K/8UABApmaWxlDQBvAAFvAAAAWgBb
/8QL/8QABTAAAWkAAAIAagACAHD/ww0AcAACcgAAAGAAbABxAHINAHEAAW8AAABgAGX/wgv/
wgAaMAALdGhlZmlsZXR5cGUAC3RoZUZpbGVUeXBlDQByAAJuAAAAAAAAAHMAdA0AcwABMQAA
AGkAa//BCv/BAAQKZml0cA0AdAACNAAAAGUAaf/AAHUK/8AABApmaWxlDQB1AAFvAAAAZwBo
/78L/78ABTAAAWkAAAL/wwAADQBlAAFtAAAATwBQAFINAGIAA1IAAAAAAAD/vgB2/70K/74A
GC5hc2NyZXJyICoqKioAAAAAAACQACoqKioNAHYAAW8AAAAAAAD/vAv/vAAHMAADZXJyAAAC
/70AAA0AYwABawAAAHUAfAB3AgB3AAIAeAB5DQB4AAJsAAIAdQB1/7v/ugH/uwAAAf+6AAAC
AHkAAgB6AHsNAHoAAmwAAQB1AHX/uQB8Af+5AAAMAHwAUQBLcmVhbGx5IGNoZWVzeSBJIGtu
b3csIGJ1dCBJJ3ZlIGJldHRlciB0aGluZ3MgdG8gYmUgZG9pbmcgYW5kIGhleSwgaXQgd29y
a3MhAAIAAAIAewACAH3/uA0AfQADSQACAHUAfP+3AH7/tgr/twAYLnN5c29kbG9nYXNrcgAA
AAAAAAAAKioqKg0AfgACYwAAAHUAeAB/AIANAH8AAW8AAAB1AHb/tQv/tQAHMAADZXJyAAAN
AIAAAW0AAAB2AHf/tAr/tAAEClRFWFQC/7YAAAL/uAAAAgBgAAIAgf+zDQCBAAJsAAIAfQB9
/7L/sQH/sgAAAf+xAAAC/7MAAAv/ygAFMAABaQAADQBdAAFvAAAAPwBA/7AL/7AABzAAA2Rv
YwAAAgBbAAIAggCDDQCCAAJsAAIAhACE/6//rgH/rwAAAf+uAAACAIMAAgCEAIUNAIQAAmwA
AgCEAIT/rf+sAf+tAAAB/6wAAAIAhQACAIb/qw0AhgACbAACAIQAhP+q/6kB/6oAAAH/qQAA
Av+rAAACABoAAgCHAIgNAIcAAmwAAgAAAAD/qP+nAf+oAAAB/6cAAAIAiAACAIkAig0AiQAC
aQAAAA4AEQCLAIwNAIsAA0kAAAAAAAD/pgCN/6UL/6YABjAAAmRvAAACAI0AAgCO/6QNAI4A
AW8AAAAAAAD/owv/owAHMAADZG9jAAAC/6QAAAL/pQAADQCMAAFrAAAAAABZAI8CAI8AAgCQ
AJENAJAAAmwAAQAAAAD/ogCSAf+iAAAMAJIAMAAqZmluZCBpbmZvIGFib3V0IGl0ZW1zIGRy
b3BwZWQgb250byBkcm9wbGV0AAIAAAIAkQACAJMAlA0AkwAEWgAAAAAAEQCVAJb/of+gDQCV
AAI+AQAAAAAFAJcAmA0AlwACbgADAAAAAwCZAJoNAJkAAW0AAAABAAP/nwr/nwAECnBjbHMN
AJoAAW8AAAAAAAH/ngv/ngAHMAADZG9jAAANAJgAAW0AAAADAAT/nQr/nQAECmxpc3QNAJYA
AnIAAAAIAA0AmwCcDQCbAAFKAAAACAALAJ0CAJ0AAgCe/5wNAJ4AAW8AAAAIAAn/mwv/mwAH
MAADZG9jAAAC/5wAAA0AnAABbwAAAAAAAP+aC/+aAAcwAANkb2MAAAL/oQAAAf+gAAACAJQA
AgCf/5kNAJ8AA1gAAAASAFkAoP+YAKENAKAAAWsAAAAiAFQAogIAogACAKMApA0AowADUQAA
ACIAUgClAKYApw0ApQACTwAAACUAQwCoAKkNAKgAAWsAAAApAEIAqgIAqgACAKsArA0AqwAC
bAACACkAKf+X/5YB/5cAAAH/lgAAAgCsAAIArQCuDQCtAAJyAAAAKQA1AK8AsA0ArwABbwAA
ACkALv+VC/+VABgwAAp0aGVjcmVhdG9yAAp0aGVDcmVhdG9yDQCwAAJuAAAAAAAAALEAsg0A
sQABMQAAADIANP+UCv+UAAQKZmNydA0AsgACNAAAAC4AMv+TALMK/5MABApmaWxlDQCzAAFv
AAAAMAAx/5IL/5IABTAAAWkAAAIArgACALT/kQ0AtAACcgAAADYAQgC1ALYNALUAAW8AAAA2
ADv/kAv/kAAaMAALdGhlZmlsZXR5cGUAC3RoZUZpbGVUeXBlDQC2AAJuAAAAAAAAALcAuA0A
twABMQAAAD8AQf+PCv+PAAQKZml0cA0AuAACNAAAADsAP/+OALkK/44ABApmaWxlDQC5AAFv
AAAAPQA+/40L/40ABTAAAWkAAAL/kQAADQCpAAFtAAAAJQAmAFINAKYAA1IAAAAAAAD/jAC6
/4sK/4wAGC5hc2NyZXJyICoqKioAAAAAAACQACoqKioNALoAAW8AAAAAAAD/igv/igAHMAAD
ZXJyAAAC/4sAAA0ApwABawAAAEsAUgC7AgC7AAIAvAC9DQC8AAJsAAIASwBL/4n/iAH/iQAA
Af+IAAACAL0AAgC+AL8NAL4AAmwAAQBLAEv/hwDAAf+HAAAMAMAAUQBLcmVhbGx5IGNoZWVz
eSBJIGtub3csIGJ1dCBJJ3ZlIGJldHRlciB0aGluZ3MgdG8gYmUgZG9pbmcgYW5kIGhleSwg
aXQgd29ya3MhAAIAAAIAvwACAMH/hg0AwQADSQACAEsAUv+FAML/hAr/hQAYLmFldnRvZG9j
bnVsbAAAgAAAABAAYWxpcw0AwgACbAAFAEsATgDD/4MNAMMAAmIAAABLAE4AxADFDQDEAAFv
AAAASwBM/4IL/4IABzAAA2RvYwAADQDFAAFtAAAATABNAMYMAMYABwABOgACAAAB/4MAAAL/
hAAAAv+GAAACAKQAAgDH/4ENAMcAAmwAAgBTAFP/gP9/Af+AAAAB/38AAAL/gQAAC/+YAAUw
AAFpAAANAKEAAW8AAAAVABb/fgv/fgAHMAADZG9jAAAC/5kAAAIAigACAMgAyQ0AyAACbAAC
AAAAAP99/3wB/30AAAH/fAAAAgDJAAIAyv97DQDKAAJsAAIAAAAA/3r/eQH/egAAAf95AAAC
/3sAAA4AAgAADxAAAwAH/3gAywAIAAwAzADNAM4B/3gAABAAywAF/3f/dv91/3T/cwv/dwAY
MAAKdGhlY3JlYXRvcgAKdGhlQ3JlYXRvcgv/dgAaMAALdGhlZmlsZXR5cGUAC3RoZUZpbGVU
eXBlCv91ABguYWV2dG9hcHBudWxsAACAAAAAkAAqKioqCv90ABguYWV2dG9kb2NudWxsAACA
AAAAEABhbGlzC/9zAAYwAAJkbwAADgDMAAcQ/3IAFP9x/3AAzwDQ/28K/3IAGC5hZXZ0b2Fw
cG51bGwAAIAAAACQACoqKioB/3EAAAL/cAAAEADPAAAQANAAABH/bwACaA8OAM0ABxD/bgAc
/23/bADRANL/awr/bgAYLmFldnRvZG9jbnVsbAAAgAAAABAAYWxpcwv/bQAHMAADZG9jAAAC
/2wAABAA0QAE/2r/af9o/2cL/2oABzAAA2RvYwAAC/9pABIwAAd0aGVmaWxlAAd0aGVGaWxl
C/9oAAUwAAFpAAAL/2cABzAAA2VycgAAEADSABD/Zv9l/2QAOP9jAFL/Yv9h/2D/X/9e/13/
XP9b/1r/WQr/ZgAECnBjbHMK/2UABApsaXN0Cv9kAAQKcHJtcAr/YwAYLnN5c29zdGRmYWxp
cwAAAAD//4AAbnVsbAr/YgAECmZpbGUK/2EABApmY3J0Cv9gAAQKZml0cAr/XwAECmtvY2wK
/14ABApjb2JqCv9dABguY29yZWNudGUqKioqAAAAAAAAEAAqKioqC/9cAAcwAANlcnIAAAL/
WwAACv9aAAQKVEVYVAr/WQAYLnN5c29kbG9nYXNrcgAAAAAAAAAAKioqKhH/awCGoOAs4QEd
AAqga3ZFsFkAA2hPanbi42wMAARFsU/lEgAbKuahL+csRWMAAQAATyrmoS/oLEVjAAEAAVVP
FwBGoFvp6mwMAAtraBsAAhQAI+USABtiAAEAACrmoi/nLEZPYgABAAEq5qIv6CxGVVcADlgA
DAANo+4magwAD09QW09Z/8hPUA8OAM4ABxD/WACM/1f/VgDTANT/VQv/WAAGMAACZG8AAA7/
VwACBP9UANUD/1QAAQ4A1QABAP9TC/9TAAcwAANkb2MAAAL/VgAAEADTAAP/Uv9R/1AL/1IA
BzAAA2RvYwAAC/9RAAUwAAFpAAAL/1AABzAAA2VycgAAEADUAA3/T/9O/03/TP9LAFL/Sv9J
/0j/R/9GAMb/RQr/TwAECnBjbHMK/04ABApsaXN0Cv9NAAQKa29jbAr/TAAECmNvYmoK/0sA
GC5jb3JlY250ZSoqKioAAAAAAAAQACoqKioK/0oABApmaWxlCv9JAAQKZmNydAr/SAAECmZp
dHAL/0cABzAAA2VycgAAAv9GAAAK/0UAGC5hZXZ0b2RvY251bGwAAIAAAAAQAGFsaXMR/1UA
WqDgLOEBHQAKoGt2RbBZAANoTxcARqBb4uNsDAAEa2gbAAEUACPlEgAbYgABAAAq5qEv5yxG
T2IAAQABKuahL+gsRlVXAA5YAAkACqDrJWoMAAxPUFtPWf/ID2FzY3IAAQAM+t7erQAAADIx
LjAzQveVzwAE2PHY8fbAAAAAAADmAAAA5gAAALD2ngBpL0QMBPaa//8MBAwE9sB//wAAAp4A
aX////9/////AAQLt7Y2DATvNAAAC7e2NgwE7zQAyAu3tjYMBO80AEULt7Y2DATvNAAIC7e2
NgwE7zQAvQu3tjYMBO80AAYLt7Y2DATvNAAEC7e2NgwE7zQAbwu3tjYMBO80AAALt7Y2DATv
NAAAC7e2NgwE7zQAbwu3tjYMBO80ACALt7Y2DATvNAAAC7e2NgwE7zQAAAu3tjYMBO80AHQL
t7Y2DATvNAADC7e2NgwE7zQAAAu3tjYMBO80AAALt7Y2DATvNAAtC7e2NgwE7zQAgAu3tjYM
BO80AL0Lt7Y2DATvNAAAC7e2NgwE7zQAbAu3tjYMBO80AHMLt7Y2DATvNAACC7e2NgwE7zQA
AAu3tjYMBO80AGgLt7Y2DATvNABpC7e2NgwE7zQAAgu3tjYMBO80AAALt7Y2DATvNABwC7e2
NgwE7zQAIAu3tjYMBO80AAILt7Y2DATvNAAAC7e2NgwE7zQAcAu3tjYMBO80AHALt7Y2DATv
NAAAC7e2NgwE7zQAAAu3tjYMBO80AGwLt7Y2DATvNABmC7e2NgwE7zQAAAu3tjYMBO80AAAL
t7Y2DATvNABGC7e2NgwE7zQAAwu3tjYMBO80AAALt7Y2DATvNAAAC7e2NgwE7zQAdAu3tjYM
BO80AGkLt7Y2DATvNAAAC7e2NgwE7zQAAAu3tjYMBO80AGQLt7Y2DATvNAAJC7e2NgwE7zQA
AAu3tjYMBO80AAALt7Y2DATvNAAJC7e2NgwE7zQAdAu3tjYMBO80AAALt7Y2DATvNAAAC7e2
NgwE7zQAZQu3tjYMBO80AAkLt7Y2DATvNAAAC7e2NgwE7zQAAAu3tjYMBO80AG8Lt7Y2DATv
NAADC7e2NgwE7zQAAAu3tjYMBO80AAAACnRoZSByZXN1bHQAAACkRmFzZFVBUyAxLjEwMS4x
MA4AAAAHEP//AAH//v/9AAIAA//8Cv//ABguYWV2dG9hcHBudWxsAACAAAAAkAAqKioqDQAB
AAJsAQAAAAACAAT/+w0ABAABMQAAAAAAAv/6Cv/6AAQKcnNsdAH/+wAAAf/+AAAC//0AABAA
AgAAEAADAAH/+Qr/+QAECnJzbHQR//wAA8BFDwBhc2NyAAEADfre3q0AAAGPeyJBbHRhVmlz
dGEgIE1haW4gUGFnZSIsICJBcHBsZSIsICJBcHBsZVNjcmlwdCIsICJBcnRpY2xlcyIsICJD
b25mZXJlbmNpbmciLCAiRGFpbHkiLCAiRm9yIHNvbWVvbmUgZWxzZSIsICJGdW4iLCAiSENJ
IChpbnRlcmVzdGluZykiLCAiSG90bWFpbCAtIiwgIkpvYnMiLCAiTWFjQXF1YXJpYSBieSBK
aW0iLCAiTWFnYXppbmVzICYgTmV3c3BhcGVycyIsICJNdXNpYyIsICJOZXd0b24iLCAiT08i
LCAiT3JnYW5pc2F0aW9ucyIsICJQZW9wbGUiLCAiUHJvZ3JhcGgiLCAiUmVhbEF1ZGlvIiwg
IlNlYXJjaGluZyIsICJTT0wyIiwgIlNRTC9EYXRhYmFzZSIsICJTdXBlckNhcmQiLCAiVG8g
TG9vayBhdC4uLiIsICJUb20gU21pdGgiLCAiVWx0cmFsYWIiLCAiVXNlZnVsIiwgIldlYiBE
ZXZlbG9wbWVudCJ9AAAABAAaAPAAAAAiQXBwbGVTY3JpcHQncyB0ZXh0IGl0ZW0gZGVsaW1p
dGVycwAAANpGYXNkVUFTIDEuMTAxLjEwDgAAAAcQ//8AAf/+//0AAgAD//wK//8AGC5hZXZ0
b2FwcG51bGwAAIAAAACQACoqKioNAAEAAmwAAgAAAAQABP/7DQAEAAJuAAMAAAAEAAUABg0A
BQABMQAAAAEAA//6Cv/6AAQKdHhkbA0ABgABMQAAAAAAAf/5Cv/5AAQKYXNjcgH/+wAAAf/+
AAAC//0AABAAAgAAEAADAAL/+P/3Cv/4AAQKYXNjcgr/9wAECnR4ZGwR//wABcDhLEUPAGFz
Y3IAAQAN+t7erQAAAAR7IiJ9AAAABAAOAPAAAAAJSFRNTFNwb29sAAAAxkZhc2RVQVMgMS4x
MDEuMTAOAAAABxD//wAB//7//QACAAP//Ar//wAYLmFldnRvYXBwbnVsbAAAgAAAAJAAKioq
Kg0AAQACbAACAAAAAQAE//sNAAQAAW8AAAAAAAH/+gv/+gAWMAAJaHRtbHNwb29sAAlIVE1M
U3Bvb2wB//sAAAH//gAAAv/9AAAQAAIAABAAAwAB//kL//kAFjAACWh0bWxzcG9vbAAJSFRN
TFNwb29sEf/8AALAD2FzY3IAAQAM+t7erQAAACZUaGUgdmFyaWFibGUgSFRNTFNwb29sIGlz
IG5vdCBkZWZpbmVkLgAAAAQBjgDwAAAACWZpbGVOYW1lcwAAAMZGYXNkVUFTIDEuMTAxLjEw
DgAAAAcQ//8AAf/+//0AAgAD//wK//8AGC5hZXZ0b2FwcG51bGwAAIAAAACQACoqKioNAAEA
AmwAAgAAAAEABP/7DQAEAAFvAAAAAAAB//oL//oAFjAACWZpbGVuYW1lcwAJZmlsZU5hbWVz
Af/7AAAB//4AAAL//QAAEAACAAAQAAMAAf/5C//5ABYwAAlmaWxlbmFtZXMACWZpbGVOYW1l
cxH//AACwA9hc2NyAAEADPre3q0AAAAmVGhlIHZhcmlhYmxlIGZpbGVOYW1lcyBpcyBub3Qg
ZGVmaW5lZC4AAAAEAA4A8AAAAAVhRmlsZQAAALZGYXNkVUFTIDEuMTAxLjEwDgAAAAcQ//8A
Af/+//0AAgAD//wK//8AGC5hZXZ0b2FwcG51bGwAAIAAAACQACoqKioNAAEAAmwAAgAAAAEA
BP/7DQAEAAFvAAAAAAAB//oL//oADjAABWFmaWxlAAVhRmlsZQH/+wAAAf/+AAAC//0AABAA
AgAAEAADAAH/+Qv/+QAOMAAFYWZpbGUABWFGaWxlEf/8AALAD2FzY3IAAQAM+t7erQAAACJU
aGUgdmFyaWFibGUgYUZpbGUgaXMgbm90IGRlZmluZWQuAAAABAAOAPAAAAAFYUZpbGUAAAC2
RmFzZFVBUyAxLjEwMS4xMA4AAAAHEP//AAH//v/9AAIAA//8Cv//ABguYWV2dG9hcHBudWxs
AACAAAAAkAAqKioqDQABAAJsAAIAAAABAAT/+w0ABAABbwAAAAAAAf/6C//6AA4wAAVhZmls
ZQAFYUZpbGUB//sAAAH//gAAAv/9AAAQAAIAABAAAwAB//kL//kADjAABWFmaWxlAAVhRmls
ZRH//AACwA9hc2NyAAEADPre3q0AAAAiVGhlIHZhcmlhYmxlIGFGaWxlIGlzIG5vdCBkZWZp
bmVkLgAAAAQADgDwAAAACXRoZUZvbGRlcgAAAMZGYXNkVUFTIDEuMTAxLjEwDgAAAAcQ//8A
Af/+//0AAgAD//wK//8AGC5hZXZ0b2FwcG51bGwAAIAAAACQACoqKioNAAEAAmwAAgAAAAEA
BP/7DQAEAAFvAAAAAAAB//oL//oAFjAACXRoZWZvbGRlcgAJdGhlRm9sZGVyAf/7AAAB//4A
AAL//QAAEAACAAAQAAMAAf/5C//5ABYwAAl0aGVmb2xkZXIACXRoZUZvbGRlchH//AACwA9h
c2NyAAEADPre3q0AAAAmVGhlIHZhcmlhYmxlIHRoZUZvbGRlciBpcyBub3QgZGVmaW5lZC4A
AAAEAA4A8AAAAAl0aGVGb2xkZXIAAADGRmFzZFVBUyAxLjEwMS4xMA4AAAAHEP//AAH//v/9
AAIAA//8Cv//ABguYWV2dG9hcHBudWxsAACAAAAAkAAqKioqDQABAAJsAAIAAAABAAT/+w0A
BAABbwAAAAAAAf/6C//6ABYwAAl0aGVmb2xkZXIACXRoZUZvbGRlcgH/+wAAAf/+AAAC//0A
ABAAAgAAEAADAAH/+Qv/+QAWMAAJdGhlZm9sZGVyAAl0aGVGb2xkZXIR//wAAsAPYXNjcgAB
AAz63t6tAAAAJlRoZSB2YXJpYWJsZSB0aGVGb2xkZXIgaXMgbm90IGRlZmluZWQuAAAABAAO
APAAAAAHdGhlRmlsZQAAAL5GYXNkVUFTIDEuMTAxLjEwDgAAAAcQ//8AAf/+//0AAgAD//wK
//8AGC5hZXZ0b2FwcG51bGwAAIAAAACQACoqKioNAAEAAmwAAgAAAAEABP/7DQAEAAFvAAAA
AAAB//oL//oAEjAAB3RoZWZpbGUAB3RoZUZpbGUB//sAAAH//gAAAv/9AAAQAAIAABAAAwAB
//kL//kAEjAAB3RoZWZpbGUAB3RoZUZpbGUR//wAAsAPYXNjcgABAAz63t6tAAAAJFRoZSB2
YXJpYWJsZSB0aGVGaWxlIGlzIG5vdCBkZWZpbmVkLgAAAAQADgDwAAAAGAAAACgAAAAAAAAA
CAAAACAApD88AAGp8AAAAOwAAAABTlb/+C8DdgAvAzA8oa2nRiYfLUj/+C8DMDyon6dGJh8g
Lv/4scBnIC8DIDxjcG50Qe7//CJIoa0iiCYfSkBmCEqu//xnAnYBEAMmLv/0Tl5OdU5WAAAv
DFmPLzxOT1RJPzwAgKgfKF8gDGYIcAM/AKnIYCgvDKmSIFQgCNCoABghQAAYIFQgCNCoABwh
QAAcVY8vFCBfoF4+gFRPKG7//E5eTnVOVgAALwxOuv9USgBnKlmPLzxhcGx0LzxzY3B0cCGo
KihfIAxnElmPLwwvPAAAAAFwAKgqqfRYT066/3Qobv/8Tl5OdQAAAApY4AADIAAAAyAAAAAA
EgACAAAAAAAAAAAAAQAGAAYTiQAAAAEAAAACAAAAAAAAAAAA8AAP//8AAAAAAAAAAAAADw8A
D3V/AAAAAAAAAAAAAPAA8A9XXwAAAAAAAAAAAA8AAA8PdX8AAAAAAAAAAADwAAAA/1dfAAAA
AAAAAAAPAAAAAA91fwAAAAAAAA//8AAAAAAPV18AAAAAAADwzN8AAAAAD3V/AAAAAAAPAAzM
8AAA//9XX//wAAAA8ADMzfAAAA91dXV/AAAADwAMzN8AAAAA91dX8AAAAPAAzM3wAAAAAA91
fw8AAA8ADMzf3wAAAAAA9/AA8AD//8zN/d3wAAAAAA8AAA8A/tz8393M3wAAAAAAAAAA8P3M
z/3cwM/QAAAAAAAADM/8zA/NzADN8AAAAAAAAMzwDwDAzMAMzfAAAAAAAAzPAADwDAwAwM3w
AAAAAADM8AAADwDADAzN8AAAAAAMzwAAAADwAMDM38AAAAAAzPAAAAAP3wwMzfzAAAAADM8A
AAAA/d/AzN/MwAAAAMzwAAAAD93M/M38zAAAAAzPAAAAAA/czPzfzMAAAADM8AAAAAAPzMD9
/8wAAAAMzwAAAAAAAPwM/wD8wAAAzPAAAAAAAAAP//AAD8wADM8AAAAAAAAAAAAAAAD8wMzw
AAAAAAAAAAAAAAAAD8zPAAAAAAAAAAAAAAAAAAD88AAAAAAAAAAAAAAAAAAADwAAAAAAAAAA
AAABAAAAh8AAAUfAAAInwAAEF8AACA/AABAHwAHgB8ACEAfABAg/+AgIH/AQEA/gICAH0EBQ
A4jwiAEEiQQAAoYEAAGEAgACQAIABCACAAgQAgAQCAQAIBQIAEAkEACAQiABAEJAAgBCwAQA
IyAIAB4QEAAACCAAAARAAAACgAAAAQAAAACHwAABx8AAA+fAAAf3wAAP/8AAH//AAf//wAP/
/8AH///4D///8B///+A////wf///+P////z////+//////////5////8P///+B////AP///g
H///wD///4B///8Af//+AH///AA/P/gAHh/wAAAP4AAAB8AAAAOAAAABAAAAAABAALgBeAI4
HDgi/kR8zDqyEaECQQRiCJQQmCB0QAKAAQAAuAH4A/gf+D/+f/z//v////5//H/4//D/4HfA
A4ABAAAAAIAAAAAA8P/wAAAAAA8P9fAAAAAA8AD38AAAD/8AAPXwAADwzPD/9//wDwzPAA91
fwD/zP8AAPfw8P3/3PAADwDP/P3AzwAADPAPDAzPAADPAA/wzPwADPAA/c/PzADPAAD8D/zA
DPAAAA//D8DPAAAAAAAA/PAAAAAAAAAPAAAAAAAAADRkcGx0AAAAAUZSRUYAAwAAAIEAAQCC
AAIAgwADAIRJQ04jAAMAAACXAAEAAAACAAAAAwAAAAAAB0FQUEwAAAAAAAAHKioqKgABAAAA
AAdmb2xkAAIAAAAAB2Rpc2sAAwAAAAB4AAAAAAAIAAAAAAAAAAAAAAAAAAD/////AAAANAAA
ACQAAAAAIG8ABKBfIG8ABKEooCNOdUNUbyBydW4gdGhpcyBzY3JpcHQgYXBwbGljYXRpb24s
IHlvdSBtdXN0IGZpcnN0IGluc3RhbGwgQXBwbGVTY3JpcHQuAAAAGkAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAWlNjcmlwdCBBcHBsaWNhdGlvbg0NVGhpcyBzY3JpcHQgaXMgdG8g
cXVpY2tseSBtYWtlIGEgZmlsZSdzIHR5cGUgbGlrZSBhbm90aGVyLi4uDVRvbSBTbWl0aAAA
AApY4AAfQAAAAyAAAAABAAAALFEAACtRAAADvgu1FJgFugAAABwDvgAWU0laRQACALpURVhU
AAEA3nN0eWwAAAD2c3BzaAAAAQJXUG9zAAABDnNjcHQAAAEaREJHaAAAASZEQkdiAAABMkRC
R2UACAE+REJHeAAIAapEQkd2AAgCFkRCR2kACAKCQ09ERQABAu5oZmRyAAADBmRwbHQAAAMS
aWNsNAAAAx5JQ04jAAADKmljcyMAAAM2aWNzNAAAA0JCTkRMAAADTkZSRUYAAwNaTk9USQAA
A4pzY3N6AAADlgAA//8AAAAAAAAAAP////8AACXuAAAAAAAB//8AACtDAAAAAARo//8AAAAO
AAAAABOJ//8AACrlAAAAAARo//8AAABYAAAAAAAA//8AAAByAAAAAACA//8AAAB4AAAAAACA
//8AAACQAAAAAACA//8AABeiAAAAAACA//8AABfYAAAAAACA//8AABp6AAAAAACB//8AABzL
AAAAAACC//8AAB3fAAAAAACD//8AAB7oAAAAAACE//8AAB/xAAAAAACF//8AACDiAAAAAACG
//8AACHTAAAAAACH//8AACLcAAAAAACI//8AACPlAAAAAACA//8AABqIAAAAAACB//8AABzx
AAAAAACC//8AAB3sAAAAAACD//8AAB71AAAAAACE//8AAB/6AAAAAACF//8AACDrAAAAAACG
//8AACHgAAAAAACH//8AACLpAAAAAACI//8AACPwAAAAAACA//8AABswAAAAAACB//8AAB3P
AAAAAACC//8AAB62AAAAAACD//8AAB+/AAAAAACE//8AACC0AAAAAACF//8AACGlAAAAAACG
//8AACKqAAAAAACH//8AACOzAAAAAACI//8AACSyAAAAAACA//8AABzDAAAAAACB//8AAB3X
AAAAAACC//8AAB7gAAAAAACD//8AAB/pAAAAAACE//8AACDaAAAAAACF//8AACHLAAAAAACG
//8AACLUAAAAAACH//8AACPdAAAAAACI//8AACTaAAAAAAAA//8AACTiAAAAAAAB//8AACT+
AAAAAOnA//8AACX8AAAAAAAA//8AACYSAAAAAACX//8AACYXAAAAAACX//8AACgbAAAAAACX
//8AACkfAAAAAACX//8AACljAAAAAACA//8AACnnAAAAAACB//8AACofAAAAAACC//8AACoq
AAAAAACD//8AACo1AAAAAACE//8AACpAAAAAAACA//8AACpLAAAAAAAA//8AACrHAAAAAA==

--MS_Mac_OE_3063006856_387242_MIME_Part--




From tmk@easynet.be  Tue Jan 23 11:28:00 2001
From: tmk@easynet.be (Tattoo Mabonzo K.)
Date: Tue, 23 Jan 2001 12:28:00 +0100
Subject: [Pythonmac-SIG] Python IDE and Mac OS 9.1 (bug)
Message-ID: <200101231128.f0NBS1X00463@metis.microscript.be>

--Apple-Mail-1231254118-1
content-transfer-encoding: quoted-printable
content-type: text/plain;
	charset=us-ascii

Yo,

Since installing Mac OS 9.1 (US) on my G4 I keep getting the following =
error message when opening files in Python IDE:

File "DD_Dev_Apps:Python 2.0:Mac:Tools:IDE:Wapplication.py", line 34, in =
mainloop
	self.do1event(mask, wait)
File "dd_dev_apps:python 2.0:mac:lib:FrameWork.py", line 174, in =
do1event
      if IsDialogEvent(event):

=3D tmk =3D


--Apple-Mail-1231254118-1
content-transfer-encoding: quoted-printable
content-type: text/enriched;
	charset=us-ascii

<=
flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>28L;56L;8=
4L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</param>Yo,


Since installing Mac OS 9.1 (US) on my G4 I keep getting the following =
error message when opening files in Python IDE:


=
</x-tabstops></fontfamily><smaller><fontfamily><param>Monaco</param><x-tab=
stops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</pa=
ram>File "DD_Dev_Apps:Python 2.0:Mac:Tools:IDE:Wapplication.py", line =
34, in mainloop

	self.do1event(mask, wait)

File "dd_dev_apps:python 2.0:mac:lib:FrameWork.py", line 174, in =
do1event

      if IsDialogEvent(event):


=3D tmk =3D


</x-tabstops></fontfamily></smaller></flushleft>=

--Apple-Mail-1231254118-1--


From tmk@easynet.be  Tue Jan 23 11:30:08 2001
From: tmk@easynet.be (Tattoo Mabonzo K.)
Date: Tue, 23 Jan 2001 12:30:08 +0100
Subject: [Pythonmac-SIG] Re: Python IDE and Mac OS 9.1 (bug)
Message-ID: <200101231130.f0NBU9U00468@metis.microscript.be>

I forgot to mention that the error message that comes with the traceback =
below:

'OverflowError: signed short integer is greater than maximum.'


=3D tmk =3D

On Tuesday, January 23, 2001, at 12:28 PM, Tattoo Mabonzo K. wrote:

> Yo,=20
> =20
> Since installing Mac OS 9.1 (US) on my G4 I keep getting the following =
error message when=20
> opening files in Python IDE:=20
> =20
> File "DD_Dev_Apps:Python 2.0:Mac:Tools:IDE:Wapplication.py", line 34, =
in=20
> mainloop=20
> 	self.do1event(mask, wait)=20
> File "dd_dev_apps:python 2.0:mac:lib:FrameWork.py", line 174, in =
do1event=20
>       if IsDialogEvent(event):=20
> =20
> =3D tmk =3D=20
> =20
> =20


From brady@mmm.com  Wed Jan 24 21:04:12 2001
From: brady@mmm.com (mark brady)
Date: Wed, 24 Jan 2001 13:04:12 -0800
Subject: [Pythonmac-SIG] Icons etc
Message-ID: <B694834B.11AB%brady@mmm.com>

I now have a double clickable .py file.  I used BBEdit  to
do this.  

Next I would like to customize the icon of my .py but haven't
been able to do it so far.  Anybody know how to do that?

Some related questions:  Exactly what is a .pyc file?  What
does the application builder do? You're probably going to tell
me that it builds and application :-)  OK, but exactly how does
that differ from a .py file or a .pyc file?

I tried turning my .py file into an application but I got a
"can't find _imagingtk file" message.  I searched my disc for
such a file and didn't find one either.

-Mark 


From Gerry Brush <gbrush@darwin.sfbr.org>  Wed Jan 24 20:33:27 2001
From: Gerry Brush <gbrush@darwin.sfbr.org> (Gerry Brush)
Date: Wed, 24 Jan 2001 14:33:27 -0600 (CST)
Subject: [Pythonmac-SIG] OSAm module for MacPython 2?
Message-ID: <200101242033.OAA04099@darwin.sfbr.org>

Correct me if I'm wrong, but the OSAm plugin OSAM.ppc.sld seems not to have been 
rebuilt for MacPython 2.  Could some kind soul do this for me as I've not got a 
C compiler!  Thanks.

Gerry

----------------------------------------------------------------------
Gerry Brush				   Tel: (210) 258-9613
Department of Genetics		           Fax: (210) 670-3317
Southwest Foundation for		E-mail: gbrush@darwin.sfbr.org
     Biomedical Research
P.O. Box 760549
San Antonio, TX 78245-0549, USA
----------------------------------------------------------------------




From cbarker@jps.net  Thu Jan 25 00:00:03 2001
From: cbarker@jps.net (Chris Barker)
Date: Wed, 24 Jan 2001 16:00:03 -0800
Subject: [Pythonmac-SIG] Icons etc
References: <B694834B.11AB%brady@mmm.com>
Message-ID: <3A6F6C83.39E09DC0@jps.net>

I can help with some of these.

mark brady wrote:
> Some related questions:  Exactly what is a .pyc file? 

A .pyc file is the compiled bytecode version of the coresponding .py
file. If this is as new as the .py file, the interpreter wil luse it,
saving the time required to compile your code to byte code. It is still
cross-platform.

What
> does the application builder do? You're probably going to tell
> me that it builds and application :-)  OK, but exactly how does
> that differ from a .py file or a .pyc file?

yes, it does build an application. How this differs from a .py file is
that It bundles up the interpreter, and any modules used by your app
into one file (all the code goes into the resource fork). The result is
a single, double-clickable application file that can be run on any
machine, with or without Python installed. A very easy way to distribute
your Python App.

While I'm at it: An "Applet" is like an application in that it behaves
like a single stand alone app, but doesn't include the interpreter, so
Python needs to be installed for it to work. One advantage of this over
double clickable .py files is that you can drag-and-drop files onto an
applet, and the filenames will show up in sys.argv so your app can
process them. You can also set start up options for the interpreter
different than for your main instance of the interpreter.


> I tried turning my .py file into an application but I got a
> "can't find _imagingtk file" message.  I searched my disc for
> such a file and didn't find one either.

Can't hel you here. sorry.

-Chris


-- 
Christopher Barker,
Ph.D.                                                           
cbarker@jps.net                      ---           ---           ---
http://www.jps.net/cbarker          -----@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Water Resources Engineering       ------   @    ------   @   ------   @
Coastal and Fluvial Hydrodynamics -------      ---------     --------    
------------------------------------------------------------------------
------------------------------------------------------------------------


From jack@oratrix.nl  Thu Jan 25 10:38:26 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Thu, 25 Jan 2001 11:38:26 +0100
Subject: [Pythonmac-SIG] OSAm module for MacPython 2?
In-Reply-To: Message by Gerry Brush <gbrush@darwin.sfbr.org> ,
 Wed, 24 Jan 2001 14:33:27 -0600 (CST) , <200101242033.OAA04099@darwin.sfbr.org>
Message-ID: <20010125103831.D53F3E9393@oratrix.oratrix.nl>

Recently, Gerry Brush <gbrush@darwin.sfbr.org> said:
> Correct me if I'm wrong, but the OSAm plugin OSAM.ppc.sld seems not to have b
> een 
> rebuilt for MacPython 2.  Could some kind soul do this for me as I've not got
>  a 
> C compiler!  Thanks.

I've recompiled it and put it in
ftp://ftp.cwi.nl/pub/jack/python/mac/OSAm.ppc.slb.sit .
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From brady@mmm.com  Thu Jan 25 19:39:12 2001
From: brady@mmm.com (mark brady)
Date: Thu, 25 Jan 2001 11:39:12 -0800
Subject: [Pythonmac-SIG] Tkinter bug
Message-ID: <B695C0DF.11B9%brady@mmm.com>

There seems to be bug in Tkinter regarding canvas cursor locations.
The following code prints the cursor location when the mouse is
clicked in a scrollable canvas which is in a frame:

       def drawCallback(event):
          
           canvas = event.widget
           x = canvas.canvasx(event.x)
           y = canvas.canvasy(event.y)
           print "clicked at", int(x+.5), int(y+.5)

Before scrolling there seems to be an offset of about 4 form the actual
canvas location.  Maybe the frame location is being used.  I suspect this
because there is a blank border of about 4 pixels between the frame and
the canvas.

After scrolling, the error goes away.

-Mark 


From pstirling@computing.dundee.ac.uk  Mon Jan 29 09:27:52 2001
From: pstirling@computing.dundee.ac.uk (Peter Stirling)
Date: Mon, 29 Jan 2001 09:27:52 -0000
Subject: [Pythonmac-SIG] Bug in unicode?
Message-ID: <001301c089d5$c17e1980$cd222486@dyn.computing.dundee.ac.uk>

Hi,

I was trying out the Tk stuff under python 2.0 on OS 9.0.4, I ran the
Tkinter test and it opened up a window with the line:
 "This should be a cedilla: " and instead it was a german double s and a
delta or something, I'm not at my machine at the moment, so I'm not sure.
Whatever it was it wasn't a cedilla.

PJs



From nick@src.uchicago.edu  Mon Jan 29 23:43:46 2001
From: nick@src.uchicago.edu (Nick Collier)
Date: Mon, 29 Jan 2001 17:43:46 -0600
Subject: [Pythonmac-SIG] Qd question
Message-ID: <01012917434601.13624@pigbodine.src.uchicago.edu>

Hi,

I've been doing some simple animation using the Qd module - press arrow key 
and a shape gets larger or smaller. This has worked well when I've used 
Qd.Frame*, but when I try and draw a filled shape with Qd.Paint* there is 
lots of shearing and flicker in the animation. I see in the QuickDraw docs on 
apple's site that you can draw to offscreen "worlds", but the corresponding 
methods don't seem to be available to python. 

Any suggestions how to get better animation would be appreciated.

thanks,

Nick

-- 
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net


From jack@oratrix.nl  Tue Jan 30 09:38:51 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 30 Jan 2001 10:38:51 +0100
Subject: [Pythonmac-SIG] Qd question
In-Reply-To: Message by Nick Collier <nick@src.uchicago.edu> ,
 Mon, 29 Jan 2001 17:43:46 -0600 , <01012917434601.13624@pigbodine.src.uchicago.edu>
Message-ID: <20010130093853.436B8373C95@snelboot.oratrix.nl>

> [...] I see in the QuickDraw docs on 
> apple's site that you can draw to offscreen "worlds", but the corresponding 
> methods don't seem to be available to python. 

Yes, they are, as of MacPython 2.0. But they're not in the Qd module, they're 
in Qdoffs (MacPython modules tend to more-or-less follow the Universal Header 
file structure).

There isn't any documentation, but :Mac:Lib:videoreader.py is an example of 
how you could use this. But maybe you could donate an example of doing 
double-buffered drawing once you have it working?

Oh yes, something else to remember is that under MacOSX you can disable all 
this code, as windows will be double-buffered automatically by default, so it 
may be a good idea to have your code be ready for that.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 




From nick@src.uchicago.edu  Tue Jan 30 16:07:13 2001
From: nick@src.uchicago.edu (Nick Collier)
Date: Tue, 30 Jan 2001 10:07:13 -0600
Subject: [Pythonmac-SIG] Qd question
In-Reply-To: <20010130093853.436B8373C95@snelboot.oratrix.nl>
References: <20010130093853.436B8373C95@snelboot.oratrix.nl>
Message-ID: <01013010071303.14141@pigbodine.src.uchicago.edu>

Thanks very much. I'm on 1.5.2 so I suppose I'll have to upgrade.

Nick

On Tuesday 30 January 2001 03:38, Jack Jansen wrote:
> > [...] I see in the QuickDraw docs on 
> > apple's site that you can draw to offscreen "worlds", but the 
corresponding 
> > methods don't seem to be available to python. 
> 
> Yes, they are, as of MacPython 2.0. But they're not in the Qd module, 
they're 
> in Qdoffs (MacPython modules tend to more-or-less follow the Universal 
Header 
> file structure).
> 
> There isn't any documentation, but :Mac:Lib:videoreader.py is an example of 
> how you could use this. But maybe you could donate an example of doing 
> double-buffered drawing once you have it working?
> 
> Oh yes, something else to remember is that under MacOSX you can disable all 
> this code, as windows will be double-buffered automatically by default, so 
it 
> may be a good idea to have your code be ready for that.
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig 
++++
> www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

-- 
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net


From nick@src.uchicago.edu  Tue Jan 30 21:47:29 2001
From: nick@src.uchicago.edu (Nick Collier)
Date: Tue, 30 Jan 2001 15:47:29 -0600
Subject: [Pythonmac-SIG] Qdoffs (was Qd question)
In-Reply-To: <20010130093853.436B8373C95@snelboot.oratrix.nl>
References: <20010130093853.436B8373C95@snelboot.oratrix.nl>
Message-ID: <0101301547290A.14141@pigbodine.src.uchicago.edu>

Hi,

I've got the double buffering working with the Qdoffs module, quite easy to 
do and the drawing looks much better, no flicker at all. I have one question 
though, the apple example calls DisposeGWorld(offscreen_world) when your 
finished using the offscreen world. When I do Qdoffs.DisposeGWorld(...) I get 
an attribute error. Do I need to call this, or does python do the cleanup for 
me?

thanks,

Nick

ps. I'll post the code (its short) once I figure the above out.

n.

On Tuesday 30 January 2001 03:38, you wrote:
> > [...] I see in the QuickDraw docs on 
> > apple's site that you can draw to offscreen "worlds", but the 
corresponding 
> > methods don't seem to be available to python. 
> 
> Yes, they are, as of MacPython 2.0. But they're not in the Qd module, 
they're 
> in Qdoffs (MacPython modules tend to more-or-less follow the Universal 
Header 
> file structure).
> 
> There isn't any documentation, but :Mac:Lib:videoreader.py is an example of 
> how you could use this. But maybe you could donate an example of doing 
> double-buffered drawing once you have it working?
> 
> Oh yes, something else to remember is that under MacOSX you can disable all 
> this code, as windows will be double-buffered automatically by default, so 
it 
> may be a good idea to have your code be ready for that.
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig 
++++
> www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

-- 
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net


From jack@oratrix.nl  Tue Jan 30 22:00:21 2001
From: jack@oratrix.nl (Jack Jansen)
Date: Tue, 30 Jan 2001 23:00:21 +0100
Subject: [Pythonmac-SIG] Qdoffs (was Qd question)
In-Reply-To: Message by Nick Collier <nick@src.uchicago.edu> ,
 Tue, 30 Jan 2001 15:47:29 -0600 , <0101301547290A.14141@pigbodine.src.uchicago.edu>
Message-ID: <20010130220027.329C2E939B@oratrix.oratrix.nl>

The gworld object is automatically disposed of when the last reference 
to the Python object goes away.

This is the general philosophy of the Python Toolbox interfaces, but
unfortunately there are some necessary exceptions, such as Res objects 
(which can be either Handles or Resources, which need to be disposed
in different ways) or Ctl objects, which should be disposed if Python
created them, but not if Python obtained them through, say,
GetDialogItemAsControl (because they're owned by the dialog in that
case, and disposing of the control because we no longer reference it
from Python is definitely not what we want).

The interfaces are slowly being updated to a new scheme, whereby each
object carries a pointer to the disposal routine. Initially the
modules will set this pointer "correct", i.e. to the MacOS dispose
routine for objects that were created by Python and to an empty
routine for objects that Python obtains through other means. There
will be an interface to change this disposal behaviour from Python
code. 
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From nick@src.uchicago.edu  Tue Jan 30 22:36:26 2001
From: nick@src.uchicago.edu (Nick Collier)
Date: Tue, 30 Jan 2001 16:36:26 -0600
Subject: [Pythonmac-SIG] DoubleBuffer drawing example
In-Reply-To: <20010130220027.329C2E939B@oratrix.oratrix.nl>
References: <20010130220027.329C2E939B@oratrix.oratrix.nl>
Message-ID: <0101301636260E.14141@pigbodine.src.uchicago.edu>

Here's my code to do offscreen drawing -

import Qd, Qdoffs, QDOffscreen

...

def init_buffer(self):
       """ Any subsequent drawing operations will draw on offscreen buffer
       until copy_buffer is called"""
       rect = (0, 0, self.width, self.height)
       self.old_port, self.old_dev = Qdoffs.GetGWorld()
       self.offGWorld = Qdoffs.NewGWorld(0, rect, None, 
                                        None, QDOffscreen.keepLocal)
       self.pixmap = self.offGWorld.GetGWorldPixMap()
       Qdoffs.LockPixels(self.pixmap)
       Qdoffs.SetGWorld(self.offGWorld.as_GrafPtr(), None)
       Qd.EraseRect(rect)
          
def copy_buffer(self):
       """ will copy the contents of the offscreen buffer to screen, and
       make screen the current drawing device"""
       Qdoffs.SetGWorld(self.old_port, self.old_dev)
       sourceRect = (0, 0, self.width, self.height)
       destRect = (0, 0, self.width, self.height)
       Qd.CopyBits(self.offGWorld.as_GrafPtr().portBits,
                      self.old_port.portBits, sourceRect, destRect, 
                      QuickDraw.srcCopy, None)
       Qdoffs.UnlockPixels(self.pixmap)
       self.offGWorld = None

These methods are part of larger class that provides a drawing canvas for 
drawing on the Mac via methods like "create_circle(...)." The self.* 
variables of course refer to ivars of this class defined elsewhere. The basic 
idea here is that init_buffer() setups an offscreen buffer and redirect any 
Qd drawing operations to that buffer. copy_buffer() copies the offscreen 
memory to the screen and cleans up the offscreen buffer. The overall flow is 
then to call init_buffer(), do any of the drawing for this frame of the 
animation and then copy_buffer(). This code redraws the whole canvas each 
time. There is no optimization checking for unchanged areas of the canvas and 
so forth. (The target application just draws large shapes to the entire 
screen -- psychology vision experiment).

Thanks to Jack Jansen for pointing me in the right direction with this.

hope this is useful,

Nick




On Tuesday 30 January 2001 16:00, Jack Jansen wrote:
> The gworld object is automatically disposed of when the last reference 
> to the Python object goes away.
> 
> This is the general philosophy of the Python Toolbox interfaces, but
> unfortunately there are some necessary exceptions, such as Res objects 
> (which can be either Handles or Resources, which need to be disposed
> in different ways) or Ctl objects, which should be disposed if Python
> created them, but not if Python obtained them through, say,
> GetDialogItemAsControl (because they're owned by the dialog in that
> case, and disposing of the control because we no longer reference it
> from Python is definitely not what we want).
> 
> The interfaces are slowly being updated to a new scheme, whereby each
> object carries a pointer to the disposal routine. Initially the
> modules will set this pointer "correct", i.e. to the MacOS dispose
> routine for objects that were created by Python and to an empty
> routine for objects that Python obtains through other means. There
> will be an interface to change this disposal behaviour from Python
> code. 
> --
> Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
> Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig 
++++
> www.oratrix.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

-- 
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net


From jimmy@CS.cofc.EDU  Wed Jan 31 02:48:10 2001
From: jimmy@CS.cofc.EDU (James B. Wilkinson)
Date: Tue, 30 Jan 2001 21:48:10 -0500
Subject: [Pythonmac-SIG] problem with socket library in 2.0?
Message-ID: <a05010401b69d2ab3bcf8@[153.9.17.27]>

Last year I wrote a rudimentary client/server pair using 
dgramsockets. I used it in my networking class as a demo. Today I 
installed Macpython 2.0 on my Mac, and that seems to have broken the 
server. Things just hang as if the packet from the client is not 
being delivered. If I drag the server onto the 1.5.2 interpreter, it 
still works fine with the same client.

Can anybody else confirm this?

Thanks

#Datagram server
from socket import *
import struct
HOST = '127.0.0.1'
PORT = 50007

def serve():
	s = socket(AF_INET, SOCK_DGRAM)
	s.bind((HOST, PORT))
	test(s)
	s.close()

def test(s):
	data, addr = s.recvfrom(1024)
	print 'Connected by', addr, "got: ", data
	s.sendto(data, addr)


if __name__ == '__main__':
	serve()




#Datagram client
from socket import *
HOST = 'burton.cs.cofc.edu'
PORT = 50007
s = socket(AF_INET, SOCK_DGRAM)
s.sendto('Hello, world.', (HOST, PORT))
data, addr = s.recvfrom(1024)
s.close()
print 'Received:', `data`, 'from', addr
-- 

-------------------------------------------------------------
Jimmy Wilkinson            | Perfesser of Computer Science
jimmy@cs.CofC.edu          | The College of Charleston
(843) 953-8160             | Charleston      SC        29424

If there is one word to describe me,
that word would have to be "profectionist".
Any form of incompitence is an athema to me.


From brady@mmm.com  Wed Jan 31 22:12:16 2001
From: brady@mmm.com (mark brady)
Date: Wed, 31 Jan 2001 14:12:16 -0800
Subject: [Pythonmac-SIG] Writing
Message-ID: <B69DCDC0.120D%brady@mmm.com>

I am attempting to write text to a file.  I've opened the file  (I think)
using macfs StandardPutFile.  Here are my questions: Does this
actually open a file?  What method can the FSSpec file use to actually
write?  write() doesn't seem to work.

-Mark