Re: [Pythonmac-SIG] RE: Python 2.4 & wxPython

[Lee Cullens]

Probably only news to me, but a Mac OS 10.3 wxPython (2.5.5.1) binary 
is now up for Python 2.4 
(http://wxpython.sourceforge.net/download.php#prerequisites).

I don't see it yet on the list Bob referred me to 
(http://pythonmac.org/packages/), but perhaps it will be soon.

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

Re: [Pythonmac-SIG] RE: Python 2.4 & wxPython

[Bob Ippolito]

On Apr 10, 2005, at 12:13 AM, Lee Cullens wrote:
Probably only news to me, but a Mac OS 10.3 wxPython (2.5.5.1) binary 
is now up for Python 2.4 
(http://wxpython.sourceforge.net/download.php#prerequisites).

I don't see it yet on the list Bob referred me to 
(http://pythonmac.org/packages/), but perhaps it will be soon.
It's new, you're the first I've heard it from.  I'll try and remember 
to wrap it up and post it next week.

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

[Pythonmac-SIG] [ann] MacPythonOSA 0.1.0

[has]

Hi all,

Just a quick heads-up on my latest venture into the wild and wonderful world of 
the Open Scripting Architecture, MacPythonOSA:

http://freespace.virgin.net/hamish.sanderson/MacPythonOSA_project.dmg.gz

Only semi-complete and minimally documented, and functioning more at 
proof-of-concept than production-quality level, but you should be able to build 
it and get a taste of Python a-la OSA. See the Tests folder for example scripts.

Basic stuff like compilation, execution and display is fairly complete, and 
event sending and handling is mostly working at the raw AE code level. Other 
things like terminology support and recording are still to do, along with 
somehow insulating scripts from one another by providing each with its own 
module namespace, stdout and stderr.


Please make sure you read the docs and install the latest version of aem before 
use:

http://freespace.virgin.net/hamish.sanderson/aem-0.6.0.tar.gz

If there's any problems getting it going then drop me a note. 

I will definitely need expert advice on the finer points of OSA component 
implementation in order to complete it, so if someone can help me out there it 
would be hugely appreciated.

Regards,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0

[Bob Ippolito]

On Apr 10, 2005, at 11:40 AM, has wrote:
Just a quick heads-up on my latest venture into the wild and wonderful 
world of the Open Scripting Architecture, MacPythonOSA:
..
I will definitely need expert advice on the finer points of OSA 
component implementation in order to complete it, so if someone can 
help me out there it would be hugely appreciated.
In the implementation, you do this:
#define MAX_CSTRING_PATH_SIZE 32768 /* Because 32KB should be enough 
for anyone... */

32KB is *way* oversized and could actually cause a problem because the 
default stack size on Mac OS X is rather small.  The right way is to 
just use MAXPATHLEN.  MAXPATHLEN is defined in , but 
you're already including python.h -- which should guarantee that it is 
defined (even on platforms that don't on their own).

You #include  -- which should actually be #include 
"MacPythonOSA.h" -- because it's not a system header.  Though obviously 
it doesn't make a difference in this case.

The style you use for C code is totally whack, especially the 
indentation.  It would be a lot more readable if you wrote it in a 
standard style, the obvious choice would be PEP 7 
.

You should refactor this so that it doesn't link to Python.framework 
directly, and instead loads up all of the symbols at runtime based upon 
a configurable Python library.  The biggest reason for this is: if the 
process is already linked to Python, and you link in a different one by 
virtue of this component being loaded into the process (not even 
initialized), it could very well crash.  The py2app plugin template 
doesn't currently look for an existing linked interpreter, but it will 
at some point soon because I have to refactor it anyway.  If you detect 
an interpreter other than the one you expected, it should probably 
prevent the component from being initialized -- since you need the aem 
extension to be present.

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

Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0

[has]

Bob Ippolito wrote:

>In the implementation, you do this:
>
>#define MAX_CSTRING_PATH_SIZE 32768 /* Because 32KB should be enough for 
>anyone... */
>
>32KB is *way* oversized and could actually cause a problem because the default 
>stack size on Mac OS X is rather small.  The right way is to just use 
>MAXPATHLEN.  MAXPATHLEN is defined in , but you're already 
>including python.h -- which should guarantee that it is defined (even on 
>platforms that don't on their own).

Yeah, it's pretty goofy; didn't know what to make it so just stuck in something 
big for the meantime. Fixed. (BTW, needed to include  for some 
reason; compiler wasn't finding it without.)


>You #include  -- which should actually be #include 
>"MacPythonOSA.h" -- because it's not a system header.  Though obviously it 
>doesn't make a difference in this case.

Fixed. Much appreciated; my C is not exactly great, as you can tell. Project's 
re-uploaded.


>The style you use for C code is totally whack, especially the indentation.  It 
>would be a lot more readable if you wrote it in a standard style, the obvious 
>choice would be PEP 7 .

That's just me; really don't care for either PEP7 or C syntax in general. It 
can always get run through a pretty printer later on. Spite just makes it 
tolerable in the meantime.:)


>You should refactor this so that it doesn't link to Python.framework directly, 
>and instead loads up all of the symbols at runtime based upon a configurable 
>Python library.  The biggest reason for this is: if the process is already 
>linked to Python, and you link in a different one by virtue of this component 
>being loaded into the process (not even initialized), it could very well 
>crash.  The py2app plugin template doesn't currently look for an existing 
>linked interpreter, but it will at some point soon because I have to refactor 
>it anyway.  If you detect an interpreter other than the one you expected, it 
>should probably prevent the component from being initialized -- since you need 
>the aem extension to be present.

Good advice, though I'm not sufficiently up on C programming or OS internals to 
have a clue how to do it. Any pointers?

Many thanks,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] problems with installing scipy on mac

[Benjamin Abecassis]

Hi all,
I had to re-install macosX and i'm struggling to re)install scipy...
I think i have installed everything necessary but the installation exits with

sh: line 1: f95: command not found
sh: line 1: f95: command not found
error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o
build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/dcosqb.o"
failed with exit status 127

furthermore it says
Could not locate executable g77
Could not locate executable f77

whereas g77 is installed and present in usr/local/bin   !!!???
another problem is thath gnuplot does not start when i simply type
'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot' for
it to work.
May these problem be related ??

thanks a lot in advance...


B.A.

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

[Pythonmac-SIG] Fwd: PPC OSX vs. x86 Linux

[Joshua Ginsberg]

Sorry for the crosspost, but perhaps some of you more familiar with the 
OS X Python guts might have some theories. Thanks!

-jag
<>Joshua Ginsberg -- [EMAIL PROTECTED]
Brainstorm Internet Network Operations
970-247-1442 x131
Begin forwarded message:
From: Joshua Ginsberg <[EMAIL PROTECTED]>
Date: April 8, 2005 11:02:38 AM MDT
To: [EMAIL PROTECTED]
Cc: Subject: PPC OSX vs. x86 Linux
Hello --
I writing some python code to do some analysis of my mail logs. I took 
a 10,000 line snippet from them (the files are about 5-6 million 
usually) to test my code with. I'm developing it on a Powerbook G4 
1.2GHz with 1.25GB of RAM and the Apple distributed Python* and I 
tested my code on the 10,000 line snippet. It took 2 minutes and 10 
seconds to process that snippet. Way too slow -- I'd be looking at 
about 20 hours to process a single daily log file.

Just for fun, I copied the same code and the same log snippet to a 
dual-proc P3 500MHz machine running Fedora Core 2* with 1GB of RAM and 
tested it there. This machine provides web services and domain control 
for my network, so it's moderately utilized. The same code took six 
seconds to execute.

Granted I've got the GUI and all of that bogging down my Mac. However, 
I had nothing else fighting for CPU cycles and 700MB of RAM free when 
my testing was done. Even still, what would account for such a wide, 
wide, wide variation in the time required to process the data file? 
The code is 90% regular expressions and string finds.

Theories? Thanks!
-jag
* versions are:
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
and
Python 2.3.3 (#1, May  7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
<>Joshua Ginsberg -- [EMAIL PROTECTED]
Brainstorm Internet Network Operations
970-247-1442 x131--
http://mail.python.org/mailman/listinfo/python-list___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Audio I/O

[Jack Jansen]

On 2-apr-05, at 17:24, J. Devaney wrote:
I'm working on a python project that requires audio I/O (via the
soundcard) - I basically just need a stream that can be analyzed in
real-time and stored to a file.  I've looked into various options -
such as portaudio using a python wrapper - but since portability
isn't really I issue I was wondering if there was a more direct
(and simpler approach).
There's the Carbon.Snd module, which interfaces to the old Sound 
Manager, and there's the Quicktime module.
I don't think the Quicktime module as shipped with Python 2.3 (which 
Apple ships with 10.3) supports capturing, but I think that the 
Quicktime module in 2.4 should support it. But: I don't know of people 
who have tried it, so please report back here whether it works.

You can also download and install the new Quicktime for Python 2.3: if 
you open the experimental database in Package Manager you'll see it 
listed.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Fwd: PPC OSX vs. x86 Linux

[Bob Ippolito]

On Apr 10, 2005, at 2:46 PM, Joshua Ginsberg wrote:
I writing some python code to do some analysis of my mail logs. I 
took a 10,000 line snippet from them (the files are about 5-6 million 
usually) to test my code with. I'm developing it on a Powerbook G4 
1.2GHz with 1.25GB of RAM and the Apple distributed Python* and I 
tested my code on the 10,000 line snippet. It took 2 minutes and 10 
seconds to process that snippet. Way too slow -- I'd be looking at 
about 20 hours to process a single daily log file.

Just for fun, I copied the same code and the same log snippet to a 
dual-proc P3 500MHz machine running Fedora Core 2* with 1GB of RAM 
and tested it there. This machine provides web services and domain 
control for my network, so it's moderately utilized. The same code 
took six seconds to execute.

Granted I've got the GUI and all of that bogging down my Mac. 
However, I had nothing else fighting for CPU cycles and 700MB of RAM 
free when my testing was done. Even still, what would account for 
such a wide, wide, wide variation in the time required to process the 
data file? The code is 90% regular expressions and string finds.

* versions are:
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
and
Python 2.3.3 (#1, May  7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Try it with a newer version of Python on Mac OS X.  I had a similar 
problem, and it turned out to be Python 2.3.0's fault.  Specifically, 
the implementation of the datetime module's parser was really, really, 
really stupid and slow in early versions of Python 2.3.

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

Re: [Pythonmac-SIG] problems with installing scipy on mac

[Bob Ippolito]

On Apr 10, 2005, at 12:19 PM, Benjamin Abecassis wrote:
I had to re-install macosX and i'm struggling to re)install scipy...
I think i have installed everything necessary but the installation  
exits with

sh: line 1: f95: command not found
sh: line 1: f95: command not found
error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o
build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/ 
dcosqb.o"
failed with exit status 127

furthermore it says
Could not locate executable g77
Could not locate executable f77
whereas g77 is installed and present in usr/local/bin   !!!???
another problem is thath gnuplot does not start when i simply type
'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot'  
for
it to work.
May these problem be related ??
These problems are definitely related.  You need to manipulate your  
PATH environment variable in order to include /usr/local/bin.

If you need more information about the PATH environment variable,  
search the archives.. I posted something related in the past few days.

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

Re: [Pythonmac-SIG] problems with installing scipy on mac

[Robert Kern]

Benjamin Abecassis wrote:
Hi all,
I had to re-install macosX and i'm struggling to re)install scipy...
I think i have installed everything necessary but the installation exits with
sh: line 1: f95: command not found
sh: line 1: f95: command not found
error: Command "f95 -fixed -O4 -c -c Lib/fftpack/dfftpack/dcosqb.f -o
build/temp.darwin-7.3.1-Power_Macintosh-2.3/Lib/fftpack/dfftpack/dcosqb.o"
failed with exit status 127
furthermore it says
Could not locate executable g77
Could not locate executable f77
whereas g77 is installed and present in usr/local/bin   !!!???
another problem is thath gnuplot does not start when i simply type
'gnuplot' in a terminal window i have to type 'usr/local/bin/gnuplot' for
it to work.
May these problem be related ??
Probably you don't have /usr/local/bin in your PATH environment variable.
--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0

[Bob Ippolito]

On Apr 10, 2005, at 3:53 PM, has wrote:
A multi-process model would be a lot more robust overall.  Linking to 
Python is problematic if there's even a remote possibility the 
process might also be using a Python interpreter.

If you remove the need for that and communicate with existing Python 
interpreters exclusively, it would probably be much better overall 
(though much more work).
Yep, removing Python from the component would require quite a lot more 
in C, which I'm not keen on for maintenance's sake. Even if each 
script runs as a seperate process, I really want the OSA component and 
script daemon to remain written in Python where it's manageable. 
Besides, I'm simply not willing to pursue it as a sizeable C project 
myself - I've other things to do - so if C-ifying it is the only 
option then someone else will have to adopt it.
Not as much extra code as you'd think.  The easiest way to do it would 
be as an apple event "router".  You receive the events from the OSA 
interface, start up a Python process running code that can accept apple 
events from your router (if it's not already running), and then toss 
the events to the correct process (each component instance could 
correspond to a pid, maybe).

Threading sounds like a bad idea, given the constraints on them, the 
difficulty to do it correctly, and the pain they are to debug when 
not behaving correctly.
Yep, I suspect there's no easy solution and it's going to be a 
struggle either way. Stupid Python. Just how painful are Python 
threads anyway (sub-interpreters specifically)?

The only other option would be to find some way to provide each script 
with an independent module namespace and std I/O objects despite 
Python's global obsession, in which case we could safely run all 
scripts in the main thread (still not ideal, but good enough for most 
situations). I've no idea if that's practical or not though; it'd need 
someone familiar with Python's internals to answer it.
Nope, not practical.  Sub-interpreters are going to cause problems with 
extension modules, and there is no way to have separate module 
namespaces for different code running in the same interpreter.  
Redirecting I/O at all sounds like a bad idea in the first place.

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

[Pythonmac-SIG] ANN: MacEnthon 0.1

[Robert Kern]

MacEnthon is the OS X counterpart to the popular "Enthought Edition" of 
Python: a convenient bundling of a number of packages geared for the 
scientific community. Right now, it targets the Apple-installed Python 
2.3.0. Once I am satisfied with this release, I will consider cutting a 
release for Python 2.4.1. This is still just a test release. Please do 
not tell newbies to go install it, yet.

New in this release:
 - some updates to packages from CVS/SVN
 - all documentation is now under /Developer/Python
 - enthonutil.py, a module that allows you to easily make your own 
"sumo" distribution; see /Developer/Python/MacEnthon/enthonutil-example.py

For a full list of packages, please see the ReadMe:
  http://download.enthought.com/MacEnthon/ReadMe.html
To download:
  http://download.enthought.com/MacEnthon/MacEnthon-0.1.dmg
Included is a CLI uninstaller, enthonbegone.py . It may leave a few 
empty directories some .pyc's hanging about, but otherwise it works 
fairly well. See its help for more information.

When you encounter problems, packaging/build bugs, or missing 
documentation, please log it on the Enthon issue tracker and assign the 
issue to "rkern":

  https://www.enthought.com/roundup/enthon/
I haven't gotten much feedback, so I can only assume that it's perfect. 
Barring anything particularly idiotic that I've done, I will probably 
only make one more "final" MacEnthon for Python 2.3.0. When I recover 
from that, I'll start thinking about 2.4.1.

--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig