From ronaldoussoren at mac.com  Fri Jun  1 16:41:10 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 01 Jun 2007 07:41:10 -0700
Subject: [Pythonmac-SIG] mdutils
In-Reply-To: <p06200704c282f56135a4@[192.168.100.147]>
References: <p06200704c282f56135a4@[192.168.100.147]>
Message-ID: <A36855DF-0112-1000-9C68-397372AD24FF-Webmail-10024@mac.com>

 
On Friday, June 01, 2007, at 03:53PM, "Jan H. Jensen" <jhjensen at kemi.ku.dk> wrote:
>Hi,
>
>has anyone managed to use mdutils on a mac?

Could you be a bit more specific, such as: what is mdutils in the first place? If you mean the system tool mdutil ("manage the metadata stores used by Spotlight"), I've used it without problems but that's not related to Python.

Ronald
>
>Thanks, Jan
>-- 
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Jan H. Jensen				Associate Research Professor
>Department of Chemistry			jhjensen at kemi.ku.dk
>University of Copenhagen		Phone: +45 35 32 02 39
>Universitetsparken 5			FAX:   +45 35 32 02 14
>2100 Copenhagen				Denmark
>http://propka.ki.ku.dk/~jhjensen
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

From Chris.Barker at noaa.gov  Fri Jun  1 22:12:39 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Fri, 01 Jun 2007 13:12:39 -0700
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <20070530051821.B1927581@jazz.ncnr.nist.gov>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
Message-ID: <46607DB7.60808@noaa.gov>

Paul Kienzle wrote:
> The gfortran at http://r.research.att.com/exp claims to build Universal 
> Binaries, 

I agree that that is implied, but it also looks like there are passing 
only one architecture flag in their build instructions. I haven't seen 
any other reference to gfortran building Universal binaries.

>  but I haven't tested it extensively.

Have you tested it at all?

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From goedman at mac.com  Sat Jun  2 00:10:55 2007
From: goedman at mac.com (Rob J Goedman)
Date: Fri, 1 Jun 2007 15:10:55 -0700
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <46607DB7.60808@noaa.gov>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
	<46607DB7.60808@noaa.gov>
Message-ID: <0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>

I don't think that is implied on Simon's R website. The context of  
the statement is building universal
packages for the R statistical software system.

Within that context the compiler inter-works with the latest set of  
Xcode tools to build a package (if the
package includes Fortran in addition to C/C++). These packages are  
then installed in R's library and after
loading into R, methods in the package can be called from R. I think  
it is the install step of both packages
and R/R.app that makes sure the matching architecture is chosen.

Most packages are available in binary, universal form (and include  
both binaries), but installing a package
from source will pass the correct architecture flag.

Hope this helps a bit,
Rob


On Jun 1, 2007, at 1:12 PM, Christopher Barker wrote:

> Paul Kienzle wrote:
>> The gfortran at http://r.research.att.com/exp claims to build  
>> Universal
>> Binaries,
>
> I agree that that is implied, but it also looks like there are passing
> only one architecture flag in their build instructions. I haven't seen
> any other reference to gfortran building Universal binaries.
>
>>  but I haven't tested it extensively.
>
> Have you tested it at all?
>
> -CHB
>
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From Chris.Barker at noaa.gov  Sat Jun  2 00:25:06 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Fri, 01 Jun 2007 15:25:06 -0700
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
	<46607DB7.60808@noaa.gov>
	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
Message-ID: <46609CC2.3020500@noaa.gov>

Rob J Goedman wrote:
> Hope this helps a bit,

not much, but I don't need to get  how R works.

It seems there is still no Fortran compiler for OS-X that build 
universal binary libs -- too bad.

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From robert.kern at gmail.com  Sat Jun  2 03:05:42 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 01 Jun 2007 20:05:42 -0500
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <46609CC2.3020500@noaa.gov>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>	<465C5CC6.8080800@noaa.gov>	<20070530051821.B1927581@jazz.ncnr.nist.gov>	<46607DB7.60808@noaa.gov>	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
	<46609CC2.3020500@noaa.gov>
Message-ID: <f3qfpf$sj4$1@sea.gmane.org>

Christopher Barker wrote:
> Rob J Goedman wrote:
>> Hope this helps a bit,
> 
> not much, but I don't need to get  how R works.
> 
> It seems there is still no Fortran compiler for OS-X that build 
> universal binary libs -- too bad.

The gfortran binary that Paul pointed you to does make Universal binaries. I
don't know why you think it doesn't. If you want an explicit statement to that
effect:

  http://r.research.att.com/tools/

If you want a demonstration:

[fitpack]$ gfortran -arch i386 -arch ppc -c bispev.f
[fitpack]$ file bispev.o
bispev.o: Mach-O universal binary with 2 architectures
bispev.o (for architecture i386):       Mach-O object i386
bispev.o (for architecture ppc):        Mach-O object ppc

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From goedman at mac.com  Sat Jun  2 17:54:48 2007
From: goedman at mac.com (Rob J Goedman)
Date: Sat, 2 Jun 2007 08:54:48 -0700
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <f3qfpf$sj4$1@sea.gmane.org>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
	<46607DB7.60808@noaa.gov>
	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
	<46609CC2.3020500@noaa.gov> <f3qfpf$sj4$1@sea.gmane.org>
Message-ID: <35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>

Agreed, the compiler can compile binaries for multiple architectures  
(we use that all the time). On that same website ( http:// 
r.research.att.com/ ):

"Building universal R is done by compliling two R binaries and  
setting r_arch parameter to ppc and i386 respectively, along with the  
proper compiler flags. Those two builds can then be installed into  
the same framework location, R install process merges them  
correspondingly."

The issue is in the link step not the compile phase.

Rob


On Jun 1, 2007, at 6:05 PM, Robert Kern wrote:

> Christopher Barker wrote:
>> Rob J Goedman wrote:
>>> Hope this helps a bit,
>>
>> not much, but I don't need to get  how R works.
>>
>> It seems there is still no Fortran compiler for OS-X that build
>> universal binary libs -- too bad.
>
> The gfortran binary that Paul pointed you to does make Universal  
> binaries. I
> don't know why you think it doesn't. If you want an explicit  
> statement to that
> effect:
>
>   http://r.research.att.com/tools/
>
> If you want a demonstration:
>
> [fitpack]$ gfortran -arch i386 -arch ppc -c bispev.f
> [fitpack]$ file bispev.o
> bispev.o: Mach-O universal binary with 2 architectures
> bispev.o (for architecture i386):       Mach-O object i386
> bispev.o (for architecture ppc):        Mach-O object ppc
>
> -- 
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a  
> harmless enigma
>  that is made terrible by our own mad attempt to interpret it as  
> though it had
>  an underlying truth."
>   -- Umberto Eco
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

On Jun 1, 2007, at 3:10 PM, Rob J Goedman wrote:
> I don't think that is implied on Simon's R website. The context of  
> the statement is building universal
> packages for the R statistical software system.
>
> Within that context the compiler inter-works with the latest set of  
> Xcode tools to build a package (if the
> package includes Fortran in addition to C/C++). These packages are  
> then installed in R's library and after
> loading into R, methods in the package can be called from R. I  
> think it is the install step of both packages
> and R/R.app that makes sure the matching architecture is chosen.
>
> Most packages are available in binary, universal form (and include  
> both binaries), but installing a package
> from source will pass the correct architecture flag.
>
> Hope this helps a bit,
> Rob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070602/b7cd2f90/attachment.html 

From Chris.Barker at noaa.gov  Sun Jun  3 08:52:46 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sat, 02 Jun 2007 23:52:46 -0700
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
	<46607DB7.60808@noaa.gov>
	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
	<46609CC2.3020500@noaa.gov> <f3qfpf$sj4$1@sea.gmane.org>
	<35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>
Message-ID: <4662653E.9060806@noaa.gov>

Rob J Goedman wrote:
> "Building universal R is done by compliling two R binaries and setting 
> r_arch parameter to ppc and i386 respectively, along with the proper 
> compiler flags. Those two builds can then be installed into the same 
> framework location, R install process merges them correspondingly."

Which looks a whole lot to me like you have to build the Intel and PPC 
binaries separate, then the R installer selects the right one for you 
when you install. This is a smart installer, NOT a universal binary.

However, this isn't an R list. Universal python requires Universal 
binary libs (if you want a Universal install and/or want to build 
universal py2app bundles), rather than a smart installer.

>>   http://r.research.att.com/tools/

great, thanks. That wasn't the page previously linked, and I didn't find 
that statement anywhere.

So does that mean we can build Universal binaries of Scipy now?

And back to the original question -- is the binary at python mac (only 
2.4 at my last look) Universal?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

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

From robert.kern at gmail.com  Sun Jun  3 09:05:23 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 03 Jun 2007 02:05:23 -0500
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <4662653E.9060806@noaa.gov>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>	<465C5CC6.8080800@noaa.gov>	<20070530051821.B1927581@jazz.ncnr.nist.gov>	<46607DB7.60808@noaa.gov>	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>	<46609CC2.3020500@noaa.gov>
	<f3qfpf$sj4$1@sea.gmane.org>	<35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>
	<4662653E.9060806@noaa.gov>
Message-ID: <f3tp7r$9qm$1@sea.gmane.org>

Christopher Barker wrote:

> So does that mean we can build Universal binaries of Scipy now?

With some fiddling, probably.

> And back to the original question -- is the binary at python mac (only 
> 2.4 at my last look) Universal?

Almost certainly not.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From robert.kern at gmail.com  Sun Jun  3 09:24:35 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 03 Jun 2007 02:24:35 -0500
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <f3tp7r$9qm$1@sea.gmane.org>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>	<465C5CC6.8080800@noaa.gov>	<20070530051821.B1927581@jazz.ncnr.nist.gov>	<46607DB7.60808@noaa.gov>	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>	<46609CC2.3020500@noaa.gov>	<f3qfpf$sj4$1@sea.gmane.org>	<35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>	<4662653E.9060806@noaa.gov>
	<f3tp7r$9qm$1@sea.gmane.org>
Message-ID: <f3tqbr$chj$1@sea.gmane.org>

Robert Kern wrote:
> Christopher Barker wrote:
> 
>> So does that mean we can build Universal binaries of Scipy now?
> 
> With some fiddling, probably.

Namely,

  $ LDFLAGS="-undefined dynamic_lookup -bundle -arch i386 -arch ppc" python
setup.py config_fc --fcompiler=gnu95 --arch="-arch i386 -arch ppc" build

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From robert.kern at gmail.com  Sun Jun  3 13:19:55 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 03 Jun 2007 06:19:55 -0500
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <f3tqbr$chj$1@sea.gmane.org>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>	<465C5CC6.8080800@noaa.gov>	<20070530051821.B1927581@jazz.ncnr.nist.gov>	<46607DB7.60808@noaa.gov>	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>	<46609CC2.3020500@noaa.gov>	<f3qfpf$sj4$1@sea.gmane.org>	<35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>	<4662653E.9060806@noaa.gov>	<f3tp7r$9qm$1@sea.gmane.org>
	<f3tqbr$chj$1@sea.gmane.org>
Message-ID: <f3u854$c75$1@sea.gmane.org>

Robert Kern wrote:
> Robert Kern wrote:
>> Christopher Barker wrote:
>>
>>> So does that mean we can build Universal binaries of Scipy now?
>> With some fiddling, probably.
> 
> Namely,
> 
>   $ LDFLAGS="-undefined dynamic_lookup -bundle -arch i386 -arch ppc" python
> setup.py config_fc --fcompiler=gnu95 --arch="-arch i386 -arch ppc" build

And, if you copy the libgfortran.a file to somewhere else, say ~/staticlibs/,
you can force the linker to use it instead of the .dylib such that your users
don't need to install gfortran.

  $ export LDFLAGS="-undefined dynamic_lookup -bundle -arch i386 -arch ppc
-Wl,-search_paths_first"
  $ python setup.py config_fc --fcompiler=gnu95 --arch="-arch i386 -arch ppc"
build_ext -L ~/staticlibs/ build
  ...
  $ file build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so
  build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so: Mach-O universal binary
with 2 architectures
  build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so (for architecture i386):
  Mach-O bundle i386
  build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so (for architecture ppc):
  Mach-O bundle ppc
  $ otool -L build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so

  build/lib.macosx-10.3-fat-2.5/scipy/odr/__odrpack.so:
        /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
(compatibility version 1.0.0, current version 4.0.0)
        /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
88.3.7)

The pointer to /usr/local/lib/libgcc_s.1.dylib is innocuous. That's just the
first place it will look for that library at runtime. There's one in /usr/lib
that appears to be picked up and used just fine.

Problem solved. Finally.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From Chris.Barker at noaa.gov  Mon Jun  4 20:01:29 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Mon, 04 Jun 2007 11:01:29 -0700
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <f3u854$c75$1@sea.gmane.org>
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
	<46607DB7.60808@noaa.gov>
	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
	<46609CC2.3020500@noaa.gov> <f3qfpf$sj4$1@sea.gmane.org>
	<35D9A4FF-84CD-4F16-96D5-6009B8D7A055@mac.com>
	<4662653E.9060806@noaa.gov>
	<f3tp7r$9qm$1@sea.gmane.org> <f3tqbr$chj$1@sea.gmane.org>
	<f3u854$c75$1@sea.gmane.org>
Message-ID: <46645379.8040306@noaa.gov>

Robert Kern wrote:

> And, if you copy the libgfortran.a file to somewhere else, say ~/staticlibs/,
> you can force the linker to use it instead of the .dylib such that your users
> don't need to install gfortran.

> Problem solved. Finally.

Fabulous! Thanks Robert.

Is anyone planning on building a Universal SciPy for pythonmac? (or the 
SciPy site, I guess). If not, maybe I'll give it a try next week.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From iayork at iayork.com  Mon Jun  4 21:14:57 2007
From: iayork at iayork.com (Ian York)
Date: Mon, 4 Jun 2007 15:14:57 -0400
Subject: [Pythonmac-SIG] Py2App intel/PPC: "
Message-ID: <ce6888f30706041214p4826e2a2jaed42cfbbdddd701@mail.gmail.com>

I've been packaging a set of scripts using py2app, and until now the app
that results has run without issues on MacOS10.4, either intel or ppc.  The
latest version, however, only runs on intel (on which I made the py2app
package).  The problem seems to be with eGenix mx base package (which is
needed for BioPython).  The package run on PPC gets the error "No module
named TextTools", although TextTools is included and works fine on intel.
If I include TextTools specifically with --include TextTools (or if I
--include mx), instead I get an error "ImportError: Inappropriate file type
for dynamic loading".  Again, these errors only appear on the ppc platform,
not on intel.

What am I doing wrong, and how do I fix it?

Ian

-- 
       Ian York   (iayork at panix.com)  <http://www.iayork.com/>
    "-but as he was a York, I am rather inclined to suppose him a
     very respectable Man." -Jane Austen, The History of England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070604/25d354c5/attachment.html 

From telliott99 at mac.com  Tue Jun  5 03:06:30 2007
From: telliott99 at mac.com (Tom Elliott)
Date: Mon, 4 Jun 2007 21:06:30 -0400
Subject: [Pythonmac-SIG] newbie:  threads in PyObjC
Message-ID: <E05D0168-CC1C-4ED1-9C3E-89BBEB8C1F65@mac.com>

I'm using the PyObjC bridge.  I have a computation that will be  
triggered by a user.  It takes about 2 minutes depending on the  
database we're using.  I'd like the user to be able to kill it if he  
decides it's taking too long.

It seems like threading should be  the solution.  My simple demo  
based on what I read in NSThread related docs is as follows.  (I've  
put the NSAutoreleasePool call in twice here, but tried it in either  
place, separately).

from Foundation import *
from AppKit import *
import objc, time

from PyObjCTools import NibClassBuilder

class PyThreadAppDelegate(NibClassBuilder.AutoBaseClass):
     def init(self):
         self = super(PyThreadAppDelegate, self).init()
         return self

     def go_(self, sender):
         print 'go_'
         pool = NSAutoreleasePool.alloc().init()
         NSThread.detachNewThreadSelector_toTarget_withObject_(
             'newThread:', Threaded, None)
         del pool

     def kill_(self, sender):
         pass

class Threaded(NSObject):

     @objc.signature('v:@')
     def newThread_(obj):
         print 'Threaded'
         pool = NSAutoreleasePool.alloc().init()
         for i in range(5):
             time.sleep(1)
             print i
         del pool

This dies with:

===== Monday, June 4, 2007 8:53:09 PM US/Eastern =====
go_
2007-06-04 20:53:11.414 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x1419cc0 of class NSCFString autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]:  
selector not recognized
2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x146cb10 of class NSCFString autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x146c9a0 of class NSCFString autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x146c980 of class NSException autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] An uncaught exception was raised
2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]:  
selector not recognized
2007-06-04 20:53:11.415 PyThread[555] *** Uncaught exception:  
<NSInvalidArgumentException> *** +[Threaded newThread:]: selector not  
recognized
Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: PyThread crashed
Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: crash report  
written to: /Users/jolson/Library/Logs/CrashReporter/PyThread.crash.log

In addition, I don't know how to talk to the thread to kill it.

Thanks for any help,

Tom Elliott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070604/5fdfd898/attachment.html 

From ibaird at gmail.com  Tue Jun  5 04:07:44 2007
From: ibaird at gmail.com (Ian Baird)
Date: Mon, 4 Jun 2007 21:07:44 -0500
Subject: [Pythonmac-SIG] newbie: threads in PyObjC
In-Reply-To: <a341e3240706041903p72add723kd7a9155efe48efed@mail.gmail.com>
References: <E05D0168-CC1C-4ED1-9C3E-89BBEB8C1F65@mac.com>
	<a341e3240706041903p72add723kd7a9155efe48efed@mail.gmail.com>
Message-ID: <a341e3240706041907l50dd58ecm30b9e0ff711acc1d@mail.gmail.com>

Tom,

One problem you have here is that you need to create an instance of
the Threaded class to point to as your selector's target object. This
error is causing the message:

2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]:
selector not recognized

Plus, you have an unneeded NSAutoreleasePool instance, so I'd rewrite
the code as follows:

---

def go_(self, sender):
        print 'go_'
        self.myNewThreadedInst = Threaded.alloc().init()
        NSThread.detachNewThreadSelector_toTarget_withObject_(
            'newThread:', myNewThreadedInst, None)

---

Try that out, it should work.

Ian

On 6/4/07, Tom Elliott <telliott99 at mac.com> wrote:
> I'm using the PyObjC bridge.  I have a computation that will be triggered by
> a user.  It takes about 2 minutes depending on the database we're using.
> I'd like the user to be able to kill it if he decides it's taking too long.
>
> It seems like threading should be  the solution.  My simple demo based on
> what I read in NSThread related docs is as follows.  (I've put the
> NSAutoreleasePool call in twice here, but tried it in either place,
> separately).
>
> from Foundation import *
> from AppKit import *
> import objc, time
>
> from PyObjCTools import NibClassBuilder
>
> class PyThreadAppDelegate(NibClassBuilder.AutoBaseClass):
>     def init(self):
>         self = super(PyThreadAppDelegate, self).init()
>         return self
>
>
>     def go_(self, sender):
>         print 'go_'
>         pool = NSAutoreleasePool.alloc().init()
>
> NSThread.detachNewThreadSelector_toTarget_withObject_(
>             'newThread:', Threaded, None)
>         del pool
>
>
>     def kill_(self, sender):
>         pass
>
>
> class Threaded(NSObject):
>
>     @objc.signature('v:@')
>     def newThread_(obj):
>         print 'Threaded'
>         pool = NSAutoreleasePool.alloc().init()
>         for i in range(5):
>             time.sleep(1)
>             print i
>         del pool
>
> This dies with:
>
> ===== Monday, June 4, 2007 8:53:09 PM US/Eastern =====
> go_
> 2007-06-04 20:53:11.414 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> 0x1419cc0 of class NSCFString autoreleased with no pool in place - just
> leaking
> 2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]: selector
> not recognized
> 2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> 0x146cb10 of class NSCFString autoreleased with no pool in place - just
> leaking
> 2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> 0x146c9a0 of class NSCFString autoreleased with no pool in place - just
> leaking
> 2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> 0x146c980 of class NSException autoreleased with no pool in place - just
> leaking
> 2007-06-04 20:53:11.415 PyThread[555] An uncaught exception was raised
> 2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]: selector
> not recognized
> 2007-06-04 20:53:11.415 PyThread[555] *** Uncaught exception:
> <NSInvalidArgumentException> *** +[Threaded newThread:]: selector not
> recognized
> Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: PyThread crashed
> Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: crash report written
> to:
> /Users/jolson/Library/Logs/CrashReporter/PyThread.crash.log
>
> In addition, I don't know how to talk to the thread to kill it.
>
> Thanks for any help,
>
> Tom Elliott
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

From pkienzle at jazz.ncnr.nist.gov  Mon Jun  4 21:24:05 2007
From: pkienzle at jazz.ncnr.nist.gov (Paul Kienzle)
Date: Mon, 4 Jun 2007 15:24:05 -0400
Subject: [Pythonmac-SIG] which fortran for pythonmac.org binaries?
In-Reply-To: <0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>;
	from goedman@mac.com on Fri, Jun 01, 2007 at 03:10:55PM -0700
References: <20070529025607.A1906835@jazz.ncnr.nist.gov>
	<465C5CC6.8080800@noaa.gov>
	<20070530051821.B1927581@jazz.ncnr.nist.gov>
	<46607DB7.60808@noaa.gov>
	<0C7804A0-2382-451B-A9A3-3E3989D92270@mac.com>
Message-ID: <20070604152405.A2016951@jazz.ncnr.nist.gov>

On Fri, Jun 01, 2007 at 03:10:55PM -0700, Rob J Goedman wrote:
> On Jun 1, 2007, at 1:12 PM, Christopher Barker wrote:
> 
> > Paul Kienzle wrote:
> >> The gfortran at http://r.research.att.com/exp claims to build  
> >> Universal Binaries,
> >
> > I agree that that is implied, but it also looks like there are passing
> > only one architecture flag in their build instructions. I haven't seen
> > any other reference to gfortran building Universal binaries.
> >
> >>  but I haven't tested it extensively.
> >
> > Have you tested it at all?

I built the following program:

       print *, 'hello'
       end

and confirmed that the resulting binary works on 10.4 i386 
and ppc systems.

I built a considerably large piece of code and linked it
successfully against pythonmac 2.4, whose distutils insists
on including "-arch i386 -arch ppc" on the link line.

This code works on i386.  I have not tested it on ppc.

So as far as my limited testing is concerned there is a
working universal fortran available.

- Paul

From iayork at iayork.com  Tue Jun  5 13:23:39 2007
From: iayork at iayork.com (Ian York)
Date: Tue, 5 Jun 2007 07:23:39 -0400
Subject: [Pythonmac-SIG] mxtextools, py2app, and intel vs. PPC
Message-ID: <ce6888f30706050423x6efccbf2s45a66ccadffe0edc@mail.gmail.com>

(This is an updated version of my question from yesterday, hopefully with
more, and more useful, information)

I've been packaging a set of scripts using py2app, and until now the app
that results has run without issues on MacOS10.4, either intel or ppc.

The latest version made by py2app, however, only runs on intel (on which I
made the py2app package).  The problem seems to be with eGenix mx base
package (which is needed for BioPython; specifically mxtexttools,
TextTools).  The package when run on PPC gets the error "No module named
TextTools", although TextTools is included and works fine on intel. If I
include TextTools specifically in the Resources folder within the package,
instead I get an error "ImportError: Inappropriate file type for dynamic
loading".  Again, these errors only  appeared on the ppc platform, not on
intel.

I worked around the problem by including (in the Resources folder) the
TextTools folder from a PPC machine, and the package then runs on both
machines. This isn't a great solution, because I don't always have easy
access to a PPC machine running MacOS10.4.

I presume that the problem is that the mx package I have on the Intel
machine isn't actually a Universal binary, and so the PPC has no access to
that module.  I've tried installing the mx package from source, or from the
prebuilt binary, without fixing the problem.

Anyone know if my guess is right, that the mx package isn't coming in as a
universal?  And if so, if there's a way to force it to be universal, or some
other simple fix for my problem?

Thanks,

Ian

-- 
       Ian York   (iayork at panix.com)  <http://www.iayork.com/>
    "-but as he was a York, I am rather inclined to suppose him a
     very respectable Man." -Jane Austen, The History of England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070605/e1e53bf8/attachment.html 

From vivacarlie at gmail.com  Tue Jun  5 15:57:40 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Tue, 5 Jun 2007 08:57:40 -0500
Subject: [Pythonmac-SIG] newbie: threads in PyObjC
In-Reply-To: <a341e3240706041907l50dd58ecm30b9e0ff711acc1d@mail.gmail.com>
References: <E05D0168-CC1C-4ED1-9C3E-89BBEB8C1F65@mac.com>
	<a341e3240706041903p72add723kd7a9155efe48efed@mail.gmail.com>
	<a341e3240706041907l50dd58ecm30b9e0ff711acc1d@mail.gmail.com>
Message-ID: <65fadfc30706050657h71e31bdj23d916617f7e73f@mail.gmail.com>

why does your Kill() method just have a pass statement?

On 6/4/07, Ian Baird <ibaird at gmail.com> wrote:
> Tom,
>
> One problem you have here is that you need to create an instance of
> the Threaded class to point to as your selector's target object. This
> error is causing the message:
>
> 2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]:
> selector not recognized
>
> Plus, you have an unneeded NSAutoreleasePool instance, so I'd rewrite
> the code as follows:
>
> ---
>
> def go_(self, sender):
>         print 'go_'
>         self.myNewThreadedInst = Threaded.alloc().init()
>         NSThread.detachNewThreadSelector_toTarget_withObject_(
>             'newThread:', myNewThreadedInst, None)
>
> ---
>
> Try that out, it should work.
>
> Ian
>
> On 6/4/07, Tom Elliott <telliott99 at mac.com> wrote:
> > I'm using the PyObjC bridge.  I have a computation that will be triggered by
> > a user.  It takes about 2 minutes depending on the database we're using.
> > I'd like the user to be able to kill it if he decides it's taking too long.
> >
> > It seems like threading should be  the solution.  My simple demo based on
> > what I read in NSThread related docs is as follows.  (I've put the
> > NSAutoreleasePool call in twice here, but tried it in either place,
> > separately).
> >
> > from Foundation import *
> > from AppKit import *
> > import objc, time
> >
> > from PyObjCTools import NibClassBuilder
> >
> > class PyThreadAppDelegate(NibClassBuilder.AutoBaseClass):
> >     def init(self):
> >         self = super(PyThreadAppDelegate, self).init()
> >         return self
> >
> >
> >     def go_(self, sender):
> >         print 'go_'
> >         pool = NSAutoreleasePool.alloc().init()
> >
> > NSThread.detachNewThreadSelector_toTarget_withObject_(
> >             'newThread:', Threaded, None)
> >         del pool
> >
> >
> >     def kill_(self, sender):
> >         pass
> >
> >
> > class Threaded(NSObject):
> >
> >     @objc.signature('v:@')
> >     def newThread_(obj):
> >         print 'Threaded'
> >         pool = NSAutoreleasePool.alloc().init()
> >         for i in range(5):
> >             time.sleep(1)
> >             print i
> >         del pool
> >
> > This dies with:
> >
> > ===== Monday, June 4, 2007 8:53:09 PM US/Eastern =====
> > go_
> > 2007-06-04 20:53:11.414 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> > 0x1419cc0 of class NSCFString autoreleased with no pool in place - just
> > leaking
> > 2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]: selector
> > not recognized
> > 2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> > 0x146cb10 of class NSCFString autoreleased with no pool in place - just
> > leaking
> > 2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> > 0x146c9a0 of class NSCFString autoreleased with no pool in place - just
> > leaking
> > 2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool(): Object
> > 0x146c980 of class NSException autoreleased with no pool in place - just
> > leaking
> > 2007-06-04 20:53:11.415 PyThread[555] An uncaught exception was raised
> > 2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]: selector
> > not recognized
> > 2007-06-04 20:53:11.415 PyThread[555] *** Uncaught exception:
> > <NSInvalidArgumentException> *** +[Threaded newThread:]: selector not
> > recognized
> > Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: PyThread crashed
> > Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: crash report written
> > to:
> > /Users/jolson/Library/Logs/CrashReporter/PyThread.crash.log
> >
> > In addition, I don't know how to talk to the thread to kill it.
> >
> > Thanks for any help,
> >
> > Tom Elliott
> > _______________________________________________
> > Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> > http://mail.python.org/mailman/listinfo/pythonmac-sig
> >
> >
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>


-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703

From telliott99 at mac.com  Tue Jun  5 03:06:30 2007
From: telliott99 at mac.com (Tom Elliott)
Date: Mon, 4 Jun 2007 21:06:30 -0400
Subject: [Pythonmac-SIG] newbie:  threads in PyObjC
Message-ID: <E05D0168-CC1C-4ED1-9C3E-89BBEB8C1F65@mac.com>

I'm using the PyObjC bridge.  I have a computation that will be  
triggered by a user.  It takes about 2 minutes depending on the  
database we're using.  I'd like the user to be able to kill it if he  
decides it's taking too long.

It seems like threading should be  the solution.  My simple demo  
based on what I read in NSThread related docs is as follows.  (I've  
put the NSAutoreleasePool call in twice here, but tried it in either  
place, separately).

from Foundation import *
from AppKit import *
import objc, time

from PyObjCTools import NibClassBuilder

class PyThreadAppDelegate(NibClassBuilder.AutoBaseClass):
     def init(self):
         self = super(PyThreadAppDelegate, self).init()
         return self

     def go_(self, sender):
         print 'go_'
         pool = NSAutoreleasePool.alloc().init()
         NSThread.detachNewThreadSelector_toTarget_withObject_(
             'newThread:', Threaded, None)
         del pool

     def kill_(self, sender):
         pass

class Threaded(NSObject):

     @objc.signature('v:@')
     def newThread_(obj):
         print 'Threaded'
         pool = NSAutoreleasePool.alloc().init()
         for i in range(5):
             time.sleep(1)
             print i
         del pool

This dies with:

===== Monday, June 4, 2007 8:53:09 PM US/Eastern =====
go_
2007-06-04 20:53:11.414 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x1419cc0 of class NSCFString autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]:  
selector not recognized
2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x146cb10 of class NSCFString autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x146c9a0 of class NSCFString autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] *** _NSAutoreleaseNoPool():  
Object 0x146c980 of class NSException autoreleased with no pool in  
place - just leaking
2007-06-04 20:53:11.415 PyThread[555] An uncaught exception was raised
2007-06-04 20:53:11.415 PyThread[555] *** +[Threaded newThread:]:  
selector not recognized
2007-06-04 20:53:11.415 PyThread[555] *** Uncaught exception:  
<NSInvalidArgumentException> *** +[Threaded newThread:]: selector not  
recognized
Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: PyThread crashed
Jun  4 20:53:12 joan-olsons-computer-2 crashdump[556]: crash report  
written to: /Users/jolson/Library/Logs/CrashReporter/PyThread.crash.log

In addition, I don't know how to talk to the thread to kill it.

Thanks for any help,

Tom Elliott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070604/5fdfd898/attachment-0001.html 

From telliott99 at mac.com  Thu Jun  7 02:37:01 2007
From: telliott99 at mac.com (Tom Elliott)
Date: Wed, 6 Jun 2007 20:37:01 -0400
Subject: [Pythonmac-SIG]  newbie: threads in PyObjC
Message-ID: <4C64FA8D-58D1-45BB-A7FF-027F67F8D03B@mac.com>

The kill() method is just a stub, written back when I thought the way  
to do this is for the main thread to terminate the worker thread.   
Now, after more reading, I realize it's better to have the worker  
test a condition periodically and exit (gracefully) if necessary.

The withObject_ parameter can be used to pass a reference back to the  
original thread.  This is useful when the new thread executes a  
method in a different class.  I ended up just calling a method in the  
same class, like this:

from Foundation import *
from AppKit import *
import objc, time

from PyObjCTools import NibClassBuilder

class PyThreadAppDelegate(NibClassBuilder.AutoBaseClass):
     def init(self):
         self = super(PyThreadAppDelegate, self).init()
         return self

     def go_(self, sender):
         print 'go_'
         self.continueFlag = True
         #t = Threaded.alloc().init()
         NSThread.detachNewThreadSelector_toTarget_withObject_(
             'newThread:', self, None)

     def kill_(self, sender):
         print 'kill_'
         self.continueFlag = False

     @objc.signature('v:@')
     def newThread_(sender):
         pool = NSAutoreleasePool.alloc().init()
         print 'Threaded', sender
         for i in range(10):
             if sender.continueFlag:
                 time.sleep(1)
                 print i
         del pool

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070606/316d57c9/attachment-0001.htm 

From drew at getdropbox.com  Fri Jun  8 09:28:43 2007
From: drew at getdropbox.com (Drew Houston)
Date: Fri, 08 Jun 2007 03:28:43 -0400
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
Message-ID: <4669052B.2090502@getdropbox.com>

hi there,

i was wondering if anyone else has seen this behavior with the 
findertools.launch() function. the docs indicate that when given a 
pathname, launch(path) will launch a Finder window with that path. but 
when i try to launch any valid path i get this error:

 >>> os.path.exists("/Users/drew/Documents")
True
 >>> findertools.launch("/Users/drew/Documents")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File 
"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/findertools.py", 
line 45, in launch
    return finder.open(fss)
  File 
"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/lib-scriptpackages/Finder/Standard_Suite.py", 
line 248, in open
    _arguments, _attributes)
  File 
"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py", 
line 226, in send
    return self.sendevent(self.newevent(code, subcode, parameters, 
attributes))
  File 
"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py", 
line 220, in sendevent
    self.send_timeout)
MacOS.Error: (-600, 'no eligible process with specified descriptor')
 >>>

i get the same error across reboots, on real hardware (x86) or a VM; 
from a Terminal window or IDLE; with directories or files or 
applications, etc. -- all this -600 error; (if i specify an invalid path 
i do get a file not found error.) i mostly come from windows land (and 
basically looking for a stand-in for ShellExecute), so if i'm doing 
something horribly wrong please let me know :)

i'm using OS X 10.4.9 and MacPython 2.4.4 and can't think of anything 
unusual that might be causing it. (killing the finder and restarting it 
also does not help; the process is certainly running.)

thanks!

drew


From ronaldoussoren at mac.com  Fri Jun  8 10:49:04 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 08 Jun 2007 01:49:04 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <4669052B.2090502@getdropbox.com>
References: <4669052B.2090502@getdropbox.com>
Message-ID: <DCF38607-0113-1000-8B98-1DED6003921E-Webmail-10025@mac.com>

 
On Friday, June 08, 2007, at 09:55AM, "Drew Houston" <drew at getdropbox.com> wrote:
>hi there,
>
>i was wondering if anyone else has seen this behavior with the 
>findertools.launch() function. the docs indicate that when given a 
>pathname, launch(path) will launch a Finder window with that path. but 
>when i try to launch any valid path i get this error:

Please file a bug at http://sourceforge.net/projects/python, this seems to be yet another byteorder bug in the OSA support in the core python distribution.

Findertools seem to work correcty on PPC, but fails on Intel systems. The session below forces a run of the PPC version of python on my macbook:

ronald at rivendell[0]$ /usr/libexec/oah/translate /Library/Frameworks/Python.framework/Versions/Current/Resources/Python.app/Contents/MacOS/Python 
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.byteorder
'big'
>>> import findertools
>>> findertools.launch("/tmp")
>>> 

This does indeed open the /tmp folder in the finder.


BTW. appscript (http://appscript.sourceforge.net/) is in general a much more useful OSA/AppleScript interface for use in python.

>
> >>> os.path.exists("/Users/drew/Documents")
>True
> >>> findertools.launch("/Users/drew/Documents")
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File 
>"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/findertools.py", 
>line 45, in launch
>    return finder.open(fss)
>  File 
>"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/lib-scriptpackages/Finder/Standard_Suite.py", 
>line 248, in open
>    _arguments, _attributes)
>  File 
>"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py", 
>line 226, in send
>    return self.sendevent(self.newevent(code, subcode, parameters, 
>attributes))
>  File 
>"/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/plat-mac/aetools.py", 
>line 220, in sendevent
>    self.send_timeout)
>MacOS.Error: (-600, 'no eligible process with specified descriptor')
> >>>
>
>i get the same error across reboots, on real hardware (x86) or a VM; 
>from a Terminal window or IDLE; with directories or files or 
>applications, etc. -- all this -600 error; (if i specify an invalid path 
>i do get a file not found error.) i mostly come from windows land (and 
>basically looking for a stand-in for ShellExecute), so if i'm doing 
>something horribly wrong please let me know :)
>
>i'm using OS X 10.4.9 and MacPython 2.4.4 and can't think of anything 
>unusual that might be causing it. (killing the finder and restarting it 
>also does not help; the process is certainly running.)
>
>thanks!
>
>drew
>
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

From hengist.podd at virgin.net  Fri Jun  8 13:19:14 2007
From: hengist.podd at virgin.net (has)
Date: Fri, 8 Jun 2007 12:19:14 +0100
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
Message-ID: <B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>

Ronald Oussoren wrote:

>> i was wondering if anyone else has seen this behavior with the
>> findertools.launch() function. the docs indicate that when given a
>> pathname, launch(path) will launch a Finder window with that path.  
>> but
>> when i try to launch any valid path i get this error:
>
> Please file a bug at http://sourceforge.net/projects/python, this  
> seems to be yet another byteorder bug in the OSA support in the  
> core python distribution.

You might add a note that since findertools uses aetools which is  
[over]due for deprecation, findertools should be deprecated as well.

Anyway, simplest solution here is:

	import subprocess
	subprocess.call(['open', '/Users/drew/Documents'])

Or you can do it with appscript if you prefer:

	from appscript import *
	from mactypes import Alias

	path = '/Users/drew/Documents'

	app('Finder').items[Alias(path)].open()

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From kent37 at tds.net  Fri Jun  8 14:55:55 2007
From: kent37 at tds.net (Kent Johnson)
Date: Fri, 08 Jun 2007 08:55:55 -0400
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
Message-ID: <466951DB.2020305@tds.net>

has wrote:
> Anyway, simplest solution here is:
> 
> 	import subprocess
> 	subprocess.call(['open', '/Users/drew/Documents'])

or
import open
os.system('open /Users/drew/Documents')

Kent

From ronaldoussoren at mac.com  Fri Jun  8 15:33:44 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 08 Jun 2007 06:33:44 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <466951DB.2020305@tds.net>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
	<466951DB.2020305@tds.net>
Message-ID: <DCF38607-0113-1000-8F91-1DED6003921E-Webmail-10025@mac.com>

 
On Friday, June 08, 2007, at 02:57PM, "Kent Johnson" <kent37 at tds.net> wrote:
>has wrote:
>> Anyway, simplest solution here is:
>> 
>> 	import subprocess
>> 	subprocess.call(['open', '/Users/drew/Documents'])
>
>or
>import open
import os # ;-)
>os.system('open /Users/drew/Documents')

That works but is non-trivial to get entirely correct due to quoting. Using subprocess is much better because you don't have to worry about quoting for the shell.  Os.popen and os.system should basically be deprecated, but that will probably not happen anytime soon because they are used a lot in existing code.

Ronald

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

From kw at codebykevin.com  Fri Jun  8 16:33:57 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Fri, 08 Jun 2007 10:33:57 -0400
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <DCF38607-0113-1000-8F91-1DED6003921E-Webmail-10025@mac.com>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>	<466951DB.2020305@tds.net>
	<DCF38607-0113-1000-8F91-1DED6003921E-Webmail-10025@mac.com>
Message-ID: <466968D5.30708@codebykevin.com>

Ronald Oussoren wrote:

  Using subprocess is much better because you don't have to worry about 
quoting for the shell.  Os.popen and os.system should basically be 
deprecated, but that will probably not happen anytime soon because they 
are used a lot in existing code.
> 

I use os.popen because it supports non-blocking output: subprocess does 
not, at least not without some additional hacks. I'm glad it will still 
be around for a while.


-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From Jack.Jansen at cwi.nl  Fri Jun  8 23:34:38 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Fri, 8 Jun 2007 23:34:38 +0200
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
Message-ID: <6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>


On  8-Jun-2007, at 13:19 , has wrote:
> You might add a note that since findertools uses aetools which is
> [over]due for deprecation, findertools should be deprecated as well.
>
[...]
> Or you can do it with appscript if you prefer:
>
> 	from appscript import *
> 	from mactypes import Alias
>
> 	path = '/Users/drew/Documents'
>
> 	app('Finder').items[Alias(path)].open()

Problem with deprecating aetools is that there is a truckload of  
modules that depend on it, findertools among them. I'd love to  
rewrite them to use appscript, and it wouldn't even be all that much  
work, but I simply don't have the time (and probably won't have the  
time in the coming few years).
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070608/ce0098f8/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2255 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070608/ce0098f8/attachment.bin 

From hengist.podd at virgin.net  Sat Jun  9 11:55:45 2007
From: hengist.podd at virgin.net (has)
Date: Sat, 9 Jun 2007 10:55:45 +0100
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
	<6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
Message-ID: <62B57513-CCA8-4174-8B2D-D7280C833312@virgin.net>

On 8 Jun 2007, at 22:34, Jack Jansen wrote:

> Problem with deprecating aetools is that there is a truckload of  
> modules that depend on it, findertools among them.

Which ones? Apart from the other OSA modules (which should also be  
deprecated), findertools is the only standard library module that I  
can see. (argvemulator used to use it, but has already been fixed.)

Bear in mind that aetools is completely broken on i386. If there were  
really a need for it, there'd have been constant howls of complaint  
over the last year.

Python 3.0 is coming. 64-bit support is needed. Able bodies are in  
limited supply. Dumping deadweight will improve the Python  
distribution and reduce the amount of upgrade/maintenance work that  
needs to be done. It is the best and easiest way forward and timing  
it right - i.e. deprecated in 2.6, removed in Python 3.0 - will  
minimise the workload for maintainers and the disruption to users.

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From ronaldoussoren at mac.com  Sun Jun 10 19:19:21 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 10 Jun 2007 10:19:21 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <62B57513-CCA8-4174-8B2D-D7280C833312@virgin.net>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
	<6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
	<62B57513-CCA8-4174-8B2D-D7280C833312@virgin.net>
Message-ID: <A33587F0-D922-49EB-B83B-3803D6F7AD09@mac.com>


On 9 Jun, 2007, at 2:55, has wrote:

> On 8 Jun 2007, at 22:34, Jack Jansen wrote:
>
>> Problem with deprecating aetools is that there is a truckload of
>> modules that depend on it, findertools among them.
>
> Which ones? Apart from the other OSA modules (which should also be
> deprecated), findertools is the only standard library module that I
> can see. (argvemulator used to use it, but has already been fixed.)
>
> Bear in mind that aetools is completely broken on i386. If there were
> really a need for it, there'd have been constant howls of complaint
> over the last year.
>
> Python 3.0 is coming. 64-bit support is needed. Able bodies are in
> limited supply. Dumping deadweight will improve the Python
> distribution and reduce the amount of upgrade/maintenance work that
> needs to be done. It is the best and easiest way forward and timing
> it right - i.e. deprecated in 2.6, removed in Python 3.0 - will
> minimise the workload for maintainers and the disruption to users.

I'm more tempted to remove aetools in 2.6 if it cannot be fixed with  
a small amount of work. Leaving code that is fundamentally broken is  
just lame.

Ronald
>
> has
> -- 
> http://appscript.sourceforge.net
> http://rb-appscript.rubyforge.org
> http://appscript.sourceforge.net/objc-appscript.html
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070610/c2871230/attachment.bin 

From hengist.podd at virgin.net  Mon Jun 11 14:30:22 2007
From: hengist.podd at virgin.net (has)
Date: Mon, 11 Jun 2007 13:30:22 +0100
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <A33587F0-D922-49EB-B83B-3803D6F7AD09@mac.com>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
	<6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
	<62B57513-CCA8-4174-8B2D-D7280C833312@virgin.net>
	<A33587F0-D922-49EB-B83B-3803D6F7AD09@mac.com>
Message-ID: <BDBCE824-38B3-4A80-94E5-7050A26010DD@virgin.net>

On 10 Jun 2007, at 18:19, Ronald Oussoren wrote:

> I'm more tempted to remove aetools in 2.6 if it cannot be fixed  
> with a small amount of work. Leaving code that is fundamentally  
> broken is just lame.

Fine by me - I'm all for an aggressive houseclean, as you know. I've  
no interest in fixing these modules, or even vetting them to see what  
needs done. Like I say, if users actually cared about this stuff,  
they'd have been complaining/doing something about it by now.

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From Jack.Jansen at cwi.nl  Mon Jun 11 15:30:40 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Mon, 11 Jun 2007 15:30:40 +0200
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <BDBCE824-38B3-4A80-94E5-7050A26010DD@virgin.net>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
	<6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
	<62B57513-CCA8-4174-8B2D-D7280C833312@virgin.net>
	<A33587F0-D922-49EB-B83B-3803D6F7AD09@mac.com>
	<BDBCE824-38B3-4A80-94E5-7050A26010DD@virgin.net>
Message-ID: <7174C9D5-4982-42AA-B418-091C1FB009F8@cwi.nl>


On 11-jun-2007, at 14:30, has wrote:

> On 10 Jun 2007, at 18:19, Ronald Oussoren wrote:
>
>> I'm more tempted to remove aetools in 2.6 if it cannot be fixed
>> with a small amount of work. Leaving code that is fundamentally
>> broken is just lame.
>
> Fine by me - I'm all for an aggressive houseclean, as you know. I've
> no interest in fixing these modules, or even vetting them to see what
> needs done. Like I say, if users actually cared about this stuff,
> they'd have been complaining/doing something about it by now.

Then please zap it now (at least in the trunk) so that problems show  
up sooner rather than later. I'm reasonably sure that there's various  
things that depend on it (possibly indirectly), these would need  
fixing then.

At least if the module is scrapped now we should find out what breaks,
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



From ronaldoussoren at mac.com  Mon Jun 11 21:36:26 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 11 Jun 2007 12:36:26 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
References: <mailman.6.1181296802.15361.pythonmac-sig@python.org>
	<B4A9CC69-49F4-4999-9B2E-EA02FD1C3DE2@virgin.net>
	<6310186E-0DE9-4508-A774-98CB82C40116@cwi.nl>
Message-ID: <323AFC77-3B27-4DDB-90E6-478B38F0D91C@mac.com>


On 8 Jun, 2007, at 14:34, Jack Jansen wrote:

>
> On  8-Jun-2007, at 13:19 , has wrote:
>> You might add a note that since findertools uses aetools which is
>> [over]due for deprecation, findertools should be deprecated as well.
>>
> [...]
>> Or you can do it with appscript if you prefer:
>>
>> 	from appscript import *
>> 	from mactypes import Alias
>>
>> 	path = '/Users/drew/Documents'
>>
>> 	app('Finder').items[Alias(path)].open()
>
> Problem with deprecating aetools is that there is a truckload of  
> modules that depend on it, findertools among them. I'd love to  
> rewrite them to use appscript, and it wouldn't even be all that  
> much work, but I simply don't have the time (and probably won't  
> have the time in the coming few years).

IIRC at least one of the ae* modules seems to have assumptions on the  
byteorder engrained into its design.  Fixing that may well be  
possible but there doesn't seem to be anyone around that both wants  
to have these modules fixed and has enough time (or money) to  
actually get this done.

I'm pretty sure that I the current version of argvemulator no longer  
depends on aetools because I looked at the ae* code and decided it  
wasn't worth my time to try to fix these.

This doesn't mean ae* is crappy code, just that an important design  
assumption changed.

Ronald
> --
> Jack Jansen, <Jack.Jansen at cwi.nl>, 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 at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070611/f7b47543/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070611/f7b47543/attachment.bin 

From hengist.podd at virgin.net  Tue Jun 12 16:07:23 2007
From: hengist.podd at virgin.net (has)
Date: Tue, 12 Jun 2007 15:07:23 +0100
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
Message-ID: <63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>

Ronald Oussoren wrote:

> IIRC at least one of the ae* modules seems to have assumptions on  
> the byteorder engrained into its design.  Fixing that may well be  
> possible but there doesn't seem to be anyone around that both wants  
> to have these modules fixed and has enough time (or money) to  
> actually get this done.

Not just that - there's other modernisation work required too. All of  
which would be a complete waste of time and effort since nobody uses  
these modules any more.

Anyway, the items to remove from plat-mac are:

aepack
aetools
aetypes
findertools
gensuitemodule
lib_scriptpackages
MiniAEFrame

You can also remove OSATerminology from lib-dynload - it's only used  
by gensuitemodule and will have to go sooner or later anyway.

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From Jack.Jansen at cwi.nl  Tue Jun 12 17:17:30 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Tue, 12 Jun 2007 17:17:30 +0200
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
Message-ID: <17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>


On 12-jun-2007, at 16:07, has wrote:

> Not just that - there's other modernisation work required too. All of
> which would be a complete waste of time and effort since nobody uses
> these modules any more.
>
> Anyway, the items to remove from plat-mac are:
>
> aepack
> aetools
> aetypes
> findertools
> gensuitemodule
> lib_scriptpackages
> MiniAEFrame

You missed EasyDialogs, which is also the one we may want to keep. It  
uses aepack for the file dialogs.
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



From ed.hartley at gmail.com  Mon Jun 11 13:31:02 2007
From: ed.hartley at gmail.com (Edward Hartley)
Date: Mon, 11 Jun 2007 12:31:02 +0100
Subject: [Pythonmac-SIG] QuickTime: BeginFullScreen
Message-ID: <66c67b670706110431w28b80f69k41556140d592be5f@mail.gmail.com>

Hi
I've been examining the functions exposed in the PythonMac Qt and
QuickTime libraries
and it seems that whilst the EndFullScreen call and the appropriate
flags are exposed
as can be seen from this snip from ipython help(Qt)

 EndFullScreen(...)
        (Ptr fullState, long flags) -> None

however the corresponding BeginFullScreen is not available.
My question is what is needed to make BeginFullScreen available to the
MacPython API.
I am willing to commit time to doing the development and have
comnsiderable experience of using SWIG under Linux. I am not familiar
with the build mechanism for MacPython but I am willing to learn.

I had initially thought that this might depend on having QuickTime Pro
but further investigation
shows that BeginFullScreen is an integral part of the framework and
available in from
Movies.h which I'm assuming is the basis for the MacPython Quicktime wrapper
The declaration is in /System/Frameworks/QuickTime.framework/Headers as follows:

/*
 *  BeginFullScreen()
 *
 *  Availability:
 *    Mac OS X:         in version 10.0 and later in QuickTime.framework
 *    CarbonLib:        in CarbonLib 1.0 and later
 *    Non-Carbon CFM:   in QuickTimeLib 2.5 and later
 *    Windows:          in qtmlClient.lib 3.0 and later
 */
extern OSErr
BeginFullScreen(
  Ptr *        restoreState,
  GDHandle     whichGD,
  short *      desiredWidth,
  short *      desiredHeight,
  WindowRef *  newWindow,
  RGBColor *   eraseColor,
  long         flags)
AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;


Interestingly the Java Quicktime quicktime bridge has  BeginFullScreen
available.
http://developer.apple.com/documentation/Java/Reference/1.4.1/Java141API_QTJ/quicktime/std/movies/FullScreen.html

Also there is an example of the use of the C API available in the
developer documentation:
http://developer.apple.com/samplecode/qtfullscreen/listing1.html

So I'm assuming that any restrictions on exposing BeginFullScreen that
may have applied in the past are no longer in force.
TIA
Ed Hartley

From Jack.Jansen at cwi.nl  Tue Jun 12 23:28:23 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Tue, 12 Jun 2007 23:28:23 +0200
Subject: [Pythonmac-SIG] QuickTime: BeginFullScreen
In-Reply-To: <66c67b670706110431w28b80f69k41556140d592be5f@mail.gmail.com>
References: <66c67b670706110431w28b80f69k41556140d592be5f@mail.gmail.com>
Message-ID: <98263798-2B84-4941-AA60-1F5F0D44FFBC@cwi.nl>

The problem is the "Ptr*" argument: BeginFullScreen returns an opaque  
pointer (Ptr) through a reference parameter, and the automatic  
interface code generator doesn't know how to treat this.

It thinks it knows how to treat the companion "Ptr" argument to  
EndFullScreen (representing it as a string on the Python side and  
passing the address to EndFullScreen) but it actually gets it wildly  
wrong.

As the pointer is opaque we could represent it as a cobject on the  
Python side.

I can do the magic incantations to have bgen generate a new Qt  
interface module, but I'd need your help to test it. Ideal would be  
if you're building Python from svn source (then I'll just send you a  
replacement _Qtmodule.c, and if it works I'll check it in to the  
repository) otherwise we'd have to work out some other way, contact  
me by private email.

On  11-Jun-2007, at 13:31 , Edward Hartley wrote:

> Hi
> I've been examining the functions exposed in the PythonMac Qt and
> QuickTime libraries
> and it seems that whilst the EndFullScreen call and the appropriate
> flags are exposed
> as can be seen from this snip from ipython help(Qt)
>
>  EndFullScreen(...)
>         (Ptr fullState, long flags) -> None
>
> however the corresponding BeginFullScreen is not available.
> My question is what is needed to make BeginFullScreen available to the
> MacPython API.
> I am willing to commit time to doing the development and have
> comnsiderable experience of using SWIG under Linux. I am not familiar
> with the build mechanism for MacPython but I am willing to learn.
>
> I had initially thought that this might depend on having QuickTime Pro
> but further investigation
> shows that BeginFullScreen is an integral part of the framework and
> available in from
> Movies.h which I'm assuming is the basis for the MacPython  
> Quicktime wrapper
> The declaration is in /System/Frameworks/QuickTime.framework/ 
> Headers as follows:
>
> /*
>  *  BeginFullScreen()
>  *
>  *  Availability:
>  *    Mac OS X:         in version 10.0 and later in  
> QuickTime.framework
>  *    CarbonLib:        in CarbonLib 1.0 and later
>  *    Non-Carbon CFM:   in QuickTimeLib 2.5 and later
>  *    Windows:          in qtmlClient.lib 3.0 and later
>  */
> extern OSErr
> BeginFullScreen(
>   Ptr *        restoreState,
>   GDHandle     whichGD,
>   short *      desiredWidth,
>   short *      desiredHeight,
>   WindowRef *  newWindow,
>   RGBColor *   eraseColor,
>   long         flags)
> AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;
>
>
> Interestingly the Java Quicktime quicktime bridge has  BeginFullScreen
> available.
> http://developer.apple.com/documentation/Java/Reference/1.4.1/ 
> Java141API_QTJ/quicktime/std/movies/FullScreen.html
>
> Also there is an example of the use of the C API available in the
> developer documentation:
> http://developer.apple.com/samplecode/qtfullscreen/listing1.html
>
> So I'm assuming that any restrictions on exposing BeginFullScreen that
> may have applied in the past are no longer in force.
> TIA
> Ed Hartley
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070612/95f07d98/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2255 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070612/95f07d98/attachment-0001.bin 

From kw at codebykevin.com  Wed Jun 13 17:03:53 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 13 Jun 2007 11:03:53 -0400
Subject: [Pythonmac-SIG] Porting a Tkinter application to Cocoa: question
	about datatypes
Message-ID: <46700759.5000207@codebykevin.com>

I'm looking at the possibility of porting a Tkinter-based application to 
Cocoa, and since my app is already written in Python, PyObjC is the 
logical starting point for me. However, what I'm not sure about is how 
much translation I'd have to do between Python datatypes and Objective-C 
datatypes. For instance, the code below reads data as a list, massages 
the data a bit, then returns a tuple that is then inserted into a 
Tkinter table display.

             if self.catname == 'All':
                 self.catlist = os.popen('/sw/bin/fink list', 'r', 
os.O_NONBLOCK)
             else:
                 self.catlist = os.popen('/sw/bin/fink list 
--section=%s' % self.catname, 'r', os.O_NONBLOCK)
             for line in self.catlist:
                 newline = line.split('\t')
                 rawcat = newline[0]
                 if rawcat == '(i)':
                     firstcat=rawcat.replace('(i)', 'outdated')
                 elif rawcat == ' i ':
                     firstcat=rawcat.replace('i', 'current')
                 elif rawcat == ' p ':
                     firstcat=rawcat.replace('p', 'provided')
                 else:
                     firstcat = rawcat
                 newlist = (firstcat, newline[1], newline[2], 
newline[3].strip('\n')) #finalline)
                 self.infotable.insert('end' , newlist)

Except for the line "self.infotable.insert('end' , newlist)", there is 
nothing Tkinter-specific in this code.

If I used Interface Builder for the table view, would this data import 
cleanly into the GUI, or would I have to set up some sort of NS-prefixed 
datatype (NSMutableArray?) to parse and display the data correctly? If 
so, how could this snippet be rewritten?

My preference in porting my application is to refactor the GUI layer 
from Tkinter to PyObjC, but otherwise retain as much of my code as 
possible in its present (Python-generic) form. Is this a feasible 
approach, or does using PyObjC require adopting more of an "Objective-C" 
mindset, designing the entire app from the top down to use 
NS*-datatypes? That's a lot more work and I might as well learn 
Objective-C and just use that.

TIA,
Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From ronaldoussoren at mac.com  Wed Jun 13 18:14:52 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 13 Jun 2007 09:14:52 -0700
Subject: [Pythonmac-SIG] Porting a Tkinter application to Cocoa:
	question	about datatypes
In-Reply-To: <46700759.5000207@codebykevin.com>
References: <46700759.5000207@codebykevin.com>
Message-ID: <7AA1DB18-99A4-4779-B19A-A32E1797D4EA@mac.com>


On 13 Jun, 2007, at 8:03, Kevin Walzer wrote:

> I'm looking at the possibility of porting a Tkinter-based  
> application to
> Cocoa, and since my app is already written in Python, PyObjC is the
> logical starting point for me. However, what I'm not sure about is how
> much translation I'd have to do between Python datatypes and  
> Objective-C
> datatypes. For instance, the code below reads data as a list, massages
> the data a bit, then returns a tuple that is then inserted into a
> Tkinter table display.
>
>              if self.catname == 'All':
>                  self.catlist = os.popen('/sw/bin/fink list', 'r',
> os.O_NONBLOCK)
>              else:
>                  self.catlist = os.popen('/sw/bin/fink list
> --section=%s' % self.catname, 'r', os.O_NONBLOCK)
>              for line in self.catlist:
>                  newline = line.split('\t')
>                  rawcat = newline[0]
>                  if rawcat == '(i)':
>                      firstcat=rawcat.replace('(i)', 'outdated')
>                  elif rawcat == ' i ':
>                      firstcat=rawcat.replace('i', 'current')
>                  elif rawcat == ' p ':
>                      firstcat=rawcat.replace('p', 'provided')
>                  else:
>                      firstcat = rawcat
>                  newlist = (firstcat, newline[1], newline[2],
> newline[3].strip('\n')) #finalline)
>                  self.infotable.insert('end' , newlist)
>
> Except for the line "self.infotable.insert('end' , newlist)", there is
> nothing Tkinter-specific in this code.
>
> If I used Interface Builder for the table view, would this data import
> cleanly into the GUI, or would I have to set up some sort of NS- 
> prefixed
> datatype (NSMutableArray?) to parse and display the data correctly? If
> so, how could this snippet be rewritten?

There is a tablemodel example included with PyObjC.

Python lists, tuples and dictionaries are proxied using a subclass of  
the corresponding NS* type. You almost never have to use the NS*  
types explictly.

The major exception to this is Key-Value Observing (also known as  
Cocoa bindings).  Cocoa bindings requires that objects emit events  
when they are mutated (append an item, set the value for a key in a  
dict, ...). Sadly enough Python doesn't have the hooks that are  
required to emit these events for pure python objects.  Adding this  
support requires some low-level changes to python and I'm not sure if  
this can be done without adversely affecting the performance of the  
interpreter.

>
> My preference in porting my application is to refactor the GUI layer
> from Tkinter to PyObjC, but otherwise retain as much of my code as
> possible in its present (Python-generic) form. Is this a feasible
> approach, or does using PyObjC require adopting more of an  
> "Objective-C"
> mindset, designing the entire app from the top down to use
> NS*-datatypes? That's a lot more work and I might as well learn
> Objective-C and just use that.

Learning a little Objective-C might not be a bad idea anyway, you can  
find a lot of examples and code snippets on the web and most of those  
are written in ObjC.  The major reasons for not switching to ObjC are  
the normal reasons for liking Python over compiled languages and the  
enormous amount of libraries available in Python. Something like  
Twisted beats all available networking libraries for Cocoa with a  
huge margin and simular advantages are available for other use cases.

Ronald

>
> TIA,
> Kevin
>
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070613/bf041322/attachment.bin 

From kw at codebykevin.com  Thu Jun 14 02:33:00 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Wed, 13 Jun 2007 20:33:00 -0400
Subject: [Pythonmac-SIG] Porting a Tkinter application to Cocoa:
 question about datatypes
In-Reply-To: <7AA1DB18-99A4-4779-B19A-A32E1797D4EA@mac.com>
References: <46700759.5000207@codebykevin.com>
	<7AA1DB18-99A4-4779-B19A-A32E1797D4EA@mac.com>
Message-ID: <46708CBC.7070904@codebykevin.com>

Ronald Oussoren wrote:
> 

> The major exception to this is Key-Value Observing (also known as Cocoa 
> bindings).  Cocoa bindings requires that objects emit events when they 
> are mutated (append an item, set the value for a key in a dict, ...). 
> Sadly enough Python doesn't have the hooks that are required to emit 
> these events for pure python objects.  Adding this support requires some 
> low-level changes to python and I'm not sure if this can be done without 
> adversely affecting the performance of the interpreter.

Interesting. Are Cocoa bindings analogous to the updating and binding 
mechanism in Tk? For instance, in Tkinter, I can assign a value to an 
object, then update that value later in another function via the 
StringVar() mechanism. For instance, in in my self.drawGUI function, I 
can do this:

         self.status = StringVar()
         self.status.set('Ready')

then in another function, I can call this:

         self.status.set('Process terminated')

and the value of the label widget will be updated. Was this 
functionality hard to manage or missing in Objective-C/Cocoa before the 
"Cocoa Binding" stuff was added?

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From ronaldoussoren at mac.com  Thu Jun 14 03:39:03 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 13 Jun 2007 18:39:03 -0700
Subject: [Pythonmac-SIG] Porting a Tkinter application to Cocoa:
	question about datatypes
In-Reply-To: <46708CBC.7070904@codebykevin.com>
References: <46700759.5000207@codebykevin.com>
	<7AA1DB18-99A4-4779-B19A-A32E1797D4EA@mac.com>
	<46708CBC.7070904@codebykevin.com>
Message-ID: <DE48B871-0209-4378-AF99-F070CB341B7F@mac.com>


On 13 Jun, 2007, at 17:33, Kevin Walzer wrote:

> Ronald Oussoren wrote:
>
>> The major exception to this is Key-Value Observing (also known as  
>> Cocoa bindings).  Cocoa bindings requires that objects emit events  
>> when they are mutated (append an item, set the value for a key in  
>> a dict, ...). Sadly enough Python doesn't have the hooks that are  
>> required to emit these events for pure python objects.  Adding  
>> this support requires some low-level changes to python and I'm not  
>> sure if this can be done without adversely affecting the  
>> performance of the interpreter.
>
> Interesting. Are Cocoa bindings analogous to the updating and  
> binding mechanism in Tk? For instance, in Tkinter, I can assign a  
> value to an object, then update that value later in another  
> function via the StringVar() mechanism. For instance, in in my  
> self.drawGUI function, I can do this:
>
>         self.status = StringVar()
>         self.status.set('Ready')
>
> then in another function, I can call this:
>
>         self.status.set('Process terminated')
>
> and the value of the label widget will be updated. Was this  
> functionality hard to manage or missing in Objective-C/Cocoa before  
> the "Cocoa Binding" stuff was added?

That seems to be simular to Cocoa Bindings, except that arbitrary  
objects can participate in Cocoa Bindings/KVO. You basicly have to  
implement an interface for getting and setting attributes (simular to  
getattr/setattr in Python) and you have to emit events when changing  
attributes, which is done automaticly by the __setattr__  
implementation for NSObject. The framework does the legwork for  
actually routing the events and making sure that this is done as  
efficiently as possible.

Bindings are explained here: <http://developer.apple.com/ 
documentation/Cocoa/Conceptual/CocoaBindings/index.html?http:// 
developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/ 
CocoaBindings.html>

Bindings are really powerfull when used in NIB files (basically GUI  
design files), you can connect controls to data in your model  
entirely in the GUI builder tool without writing a single line of  
code. There is a risk for creating greatly obfuscated programs,  
because important parts of your program aren't actually in code.

Ronald

>
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070613/67137a58/attachment.bin 

From hengist.podd at virgin.net  Thu Jun 14 16:06:22 2007
From: hengist.podd at virgin.net (has)
Date: Thu, 14 Jun 2007 15:06:22 +0100
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
Message-ID: <1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>

On 12 Jun 2007, at 16:17, Jack Jansen wrote:

> You missed EasyDialogs, which is also the one we may want to keep.  
> It uses aepack for the file dialogs.

Yep, didn't notice the 'import' statement buried down in the body  
there. I agree that ED should stay, at least for now. I'll see about  
submitting a patch in the next few days - it won't be a big job to fix.

In the longer term, EasyDialogs definitely needs to be substantially  
rewritten or removed sometime within the next couple of major Python  
releases as it lacks things like Unicode and long string support and  
uses some ancient APIs that almost certainly won't exist on 64-bit.  
The file dialog APIs might be okay, and I think CFUserNotification  
could replace most of the rest with minimal effort - the only one  
that might need a bit more work is the progress dialog. Also, if ED  
does end up getting rewritten, there may be an argument for  
redesigning the API, which is pretty crusty, doesn't follow standard  
conventions, and probably doesn't take full advantage of the  
functionality provided by the more modern OS X APIs. Not much point  
doing anything until Leopard is out though.

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From Chris.Barker at noaa.gov  Thu Jun 14 18:56:09 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 14 Jun 2007 09:56:09 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
Message-ID: <46717329.1060208@noaa.gov>

has wrote:
> In the longer term, EasyDialogs definitely needs to be substantially  
> rewritten

shouldn't EasyDialogs be re-written to use Cocoa? Or would that require 
the full pyObjC package -- speaking of which is that ever going to be 
part of the 'standard" MacPython package?

I suppose it could use wxPython instead -- Apple has delivered wxPython 
by default in the past -- I don't know if they are committed to doing so 
in the future.

-CHB



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Thu Jun 14 21:46:21 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Jun 2007 12:46:21 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <46717329.1060208@noaa.gov>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
Message-ID: <18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>

 
On Thursday, June 14, 2007, at 06:57PM, "Christopher Barker" <Chris.Barker at noaa.gov> wrote:
>has wrote:
>> In the longer term, EasyDialogs definitely needs to be substantially  
>> rewritten
>
>shouldn't EasyDialogs be re-written to use Cocoa? Or would that require 
>the full pyObjC package -- speaking of which is that ever going to be 
>part of the 'standard" MacPython package?

That's unlikely, I have no plans for trying to get pyobjc in the stdlib. Having it outside of the stdlib has one pretty major advantage: not being restricted by the Python release cycle and hence having the possibility of closely tracking whatever Apple is doing. In a hypothetical world where pyobjc is part of the stdlib you'd have to wait until Python 2.6 before getting access to the frameworks that Apple will introduce in Leopard.

It might be useful to make MacPython a kitchensink distribution of Python for Mac OSX instead of just the standard library, but that would require some people that want to invest into building this. It should also be more than an .mpkg that installs Python, PyObjC, appscript, wxPython and whatever else is deemed useful, a MacPython that's separate from the standard python.org distribution should strive for being the best possible Python environment for the Mac (including a proper IDE, software management tools, ...). 

Building such a beast is certainly possible, but takes a lot of developer time and is hence rather unlikely to happen unless someone has too much money and wants to fund this :-)


>
>I suppose it could use wxPython instead -- Apple has delivered wxPython 
>by default in the past -- I don't know if they are committed to doing so 
>in the future.

I have no idea what Apple plans to do, but if you're using Apple's build of Python you should consider PyObjC as well (wink, wink).

Ronald

>
>-CHB
>
>
>
>-- 
>Christopher Barker, Ph.D.
>Oceanographer
>
>Emergency Response Division
>NOAA/NOS/OR&R            (206) 526-6959   voice
>7600 Sand Point Way NE   (206) 526-6329   fax
>Seattle, WA  98115       (206) 526-6317   main reception
>
>Chris.Barker at noaa.gov
>_______________________________________________
>Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>

From Chris.Barker at noaa.gov  Thu Jun 14 22:16:08 2007
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 14 Jun 2007 13:16:08 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
Message-ID: <4671A208.1020209@noaa.gov>

Ronald Oussoren wrote:
> That's unlikely, I have no plans for trying to get pyobjc in the
> stdlib.

Fair enough -- I don't really like platform dependent stuff in the 
standard lib anyway.

> It might be useful to make MacPython a kitchensink distribution of
> Python for Mac OSX instead of just the standard library,

> a MacPython
> that's separate from the standard python.org distribution should
> strive for being the best possible Python environment for the Mac
> (including a proper IDE, software management tools, ...).

Well, sure, but wouldn't an uber-package be useful anyway? As you said, 
I don't see anyone clambering to build the full enchilada.

> I have no idea what Apple plans to do, but if you're using Apple's
> build of Python you should consider PyObjC as well (wink, wink).

Ah, I didn't know if had been included -- good idea, I think. Build 
Easy-Dialogs with PyObjC, and people will have it out of the box, or can 
install PyObj to get it.

However, if was nice to have some stuff without any external 
dependencies -- is there a lightweight way to do just Easy Dialogs, 
without all of PyObjC?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From njriley at uiuc.edu  Thu Jun 14 22:21:31 2007
From: njriley at uiuc.edu (Nicholas Riley)
Date: Thu, 14 Jun 2007 15:21:31 -0500
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <4671A208.1020209@noaa.gov>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov>
Message-ID: <20070614202131.GA54599@uiuc.edu>

On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote:
> However, if was nice to have some stuff without any external 
> dependencies -- is there a lightweight way to do just Easy Dialogs, 
> without all of PyObjC?

It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation
in C to construct a traditional Python module, but it make ssense to
wait and see how much of Carbon is no longer going to be supported in
64-bit on Leopard (probably the WWDC attendees find out today but it's
NDA'd).  Cocoa doesn't have a generic API that matches that of
EasyDialogs as much as Carbon does.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>

From ronaldoussoren at mac.com  Thu Jun 14 22:42:31 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 14 Jun 2007 13:42:31 -0700
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <20070614202131.GA54599@uiuc.edu>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
Message-ID: <1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>


On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote:

> On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote:
>> However, if was nice to have some stuff without any external
>> dependencies -- is there a lightweight way to do just Easy Dialogs,
>> without all of PyObjC?
>
> It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation
> in C to construct a traditional Python module, but it make ssense to
> wait and see how much of Carbon is no longer going to be supported in
> 64-bit on Leopard (probably the WWDC attendees find out today but it's
> NDA'd).  Cocoa doesn't have a generic API that matches that of
> EasyDialogs as much as Carbon does.

The WWDC attendees (me included) already know but as you say that info  
is under NDA ;-).

Ronald

>
>
> -- 
> Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley 
> >
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From hengist.podd at virgin.net  Fri Jun 15 15:53:49 2007
From: hengist.podd at virgin.net (has)
Date: Fri, 15 Jun 2007 14:53:49 +0100
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <mailman.8.1181901602.2857.pythonmac-sig@python.org>
References: <mailman.8.1181901602.2857.pythonmac-sig@python.org>
Message-ID: <05F0EB83-0C90-4719-8F83-C31CC5BBD026@virgin.net>

I wrote:

>  I agree that ED should stay, at least for now. I'll see about  
> submitting a patch in the next few days - it won't be a big job to  
> fix.

Patch is here:

http://sourceforge.net/tracker/index.php? 
func=detail&aid=1737832&group_id=5470&atid=305470

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From santagada at gmail.com  Fri Jun 15 23:03:46 2007
From: santagada at gmail.com (Leonardo Santagada)
Date: Fri, 15 Jun 2007 18:03:46 -0300
Subject: [Pythonmac-SIG] Error trying to build a extension on python 2.5
	(stdarg.h problem)
Message-ID: <70C4EED2-9BF9-4134-B4A2-AC59D38C68F9@gmail.com>

I read the archives of the list, but I have XCode and the universal  
SDK. I'm having a problem trying to build an extension, here is the  
output:

retype at Apfelstrudel:/tmp/usession-4/testing_1$ python setup.py build
running build
running build_ext
building 'testing_1' extension
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - 
fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - 
fno-common -dynamic -DNDEBUG -g -O3 -I/Users/retype/pypy-dist/pypy/ 
translator/c -I/Library/Frameworks/Python.framework/Versions/2.5/ 
include/python2.5 -c testing_1.c -o build/temp.macosx-10.3-fat-2.5/ 
testing_1.o
In file included from /Developer/SDKs/MacOSX10.4u.sdk/usr/include/ 
wchar.h:112,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/include/python2.5/unicodeobject.h:118,
                  from /Library/Frameworks/Python.framework/Versions/ 
2.5/include/python2.5/Python.h:83,
                  from /Users/retype/pypy-dist/pypy/translator/c/src/ 
g_prerequisite.h:10,
                  from common_header.h:2,
                  from testing_1.c:1:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:  
stdarg.h: No such file or directory
In file included from /Users/retype/pypy-dist/pypy/translator/c/src/ 
g_include.h:19,
                  from testing_1.c:554:
/Users/retype/pypy-dist/pypy/translator/c/src/support.h: In function  
?PyList_Pack?:
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:145: error:  
parse error before ?PyObject?
/Users/retype/pypy-dist/pypy/translator/c/src/support.h: In function  
?PyDict_Pack?:
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:166: error:  
parse error before ?PyObject?
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:167: error:  
parse error before ?PyObject?
/Users/retype/pypy-dist/pypy/translator/c/src/support.h: In function  
?CallWithShape?:
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:309: error:  
parse error before ?PyObject?
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:318: error:  
parse error before ?PyObject?
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:325: error:  
parse error before ?PyObject?
/Users/retype/pypy-dist/pypy/translator/c/src/support.h:338: error:  
parse error before ?PyObject?
lipo: can't figure out the architecture type of: /var/tmp//ccoT8b3x.out
error: command 'gcc' failed with exit status 1

and the setup.py file is here:


from distutils.core import setup
from distutils.extension import Extension
from distutils.ccompiler import get_default_compiler

PYPY_INCLUDE_DIR = '/Users/retype/pypy-dist/pypy/translator/c'

extra_compile_args = []
if get_default_compiler() == "unix":
     extra_compile_args.extend(["-Wno-unused-label",
                                "-Wno-unused-variable"])

setup(name="testing_1",
       ext_modules = [Extension(name = "testing_1",
                             sources = ["testing_1.c"],
                  extra_compile_args = extra_compile_args,
                        include_dirs = [PYPY_INCLUDE_DIR])])


so although this came from pypy, I really think the problem is either  
on my machine or on distutils (probably my machine, as I don't  
believe this could break with such a simple script).
do anyone know how can I fix this?

--
Leonardo Santagada
"If it looks like a duck, and quacks like a duck, we have at least to  
consider the possibility that we have a small aquatic bird of the  
family anatidae on our hands." - Douglas Adams




From ivilata at carabos.com  Sat Jun 16 18:08:05 2007
From: ivilata at carabos.com (Ivan Vilata i Balaguer)
Date: Sat, 16 Jun 2007 18:08:05 +0200
Subject: [Pythonmac-SIG] py2app and existing system libraries
Message-ID: <20070616160805.GB24076@tardis.terramar.selidor.net>

Hi list, nice to see that py2app keeps on going and it gets better day
by day. :)

I'd like to point out a problem I've come accross recently.  I've looked
up the web and found no info about it (BTW, undefined.org refers to a
py2app Trac instance I've not been able to find).  This mail looks
longish because i includes some text snippets.

I'm packaging a semi-standalone Python app which uses and includes PyQt.
These are the options for py2app::

    setup_args['app'] = ['main_application_script.py']
    setup_args['options'] = dict(
        py2app=dict(
            # Do not include system or vendor Python.
            semi_standalone=True,
            argv_emulation=True,
            iconfile='application_icons.icns',
            # Use the following system packages, do not include them.
            site_packages=True,
            excludes=['foo', 'bar'],
            )
        )

(Where none of the excluded packages is PyQt.)  When investigating the
app directory, everything seems to be in place (the ``qt.so`` file, the
``libqt.3.dylib``, the archived modules...); however, when running the
app, I get this error:

    MyApp Error

    MyApp Error
    An unexpected error has occurred during execution of the main script

    ImportError: '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/qt.so' not found

In the first place, it looks like it's trying to load the PyQt *on the
system* instead of that in the app dir.  Then, it's not using the right
dir (``qt.so`` it's right under ``site-packages``), which makes some
sense to me since ``Contents/Resources/lib/python2.5/lib-dynload/qt.so``
is its path under the app dir.

Maybe that is a meditated design decision, but I strongly think that
apps should look for their own versions of libraries before using the
system one, since they may carry specially tailored versions (but I may
be wrong).

Based on that premise, I hacked ``_run()`` from ``__boot__.py`` to check
if the needed path was there but it had a lower precedence than the
system one, and these are the paths in ``sys.path`` I got::

    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c5-py2.5.egg
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bdist_mpkg-0.4.3-py2.5.egg
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/py2app-0.3.6-py2.5.egg
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/macholib-1.1-py2.5.egg
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/modulegraph-0.7-py2.5.egg
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/altgraph-0.6.7-py2.5.egg
    /path_to.app/Contents/Resources
    /path_to.app/Contents/Resources
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload
    /path_to.app/Contents/Resources/lib/python2.5/site-packages.zip
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
    /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Numeric
    /Users/ivan/Library/Python/2.5/site-packages
    /path_to.app/Contents/Resources/Python/site-packages

I.e. none of them the place where the ``qt.so`` in the app dir is to be
found, so I hacked the following into ``_run()`` of ``__boot__.py``::

    sys.path.insert(0, '/path_to.app/Contents/Resources/lib/python2.5/lib-dynload')

Now running the app resulted in an application crash form regarding an
EXC_BAD_ACCESS error in ``libqt.3.dylib``.  Since I suspected it was
still using the system libs (though running ``otool -L qt.so`` shows a
ref to ``@executable_path/../Frameworks/libqt.3.dylib``), I got the
dylib out of my ``/usr/local/lib``.  Then the app ran flawlessly.

In short, I think there are three problems here with semi-standalone
apps using extensions:

1. The ``lib-dynload`` directory is not added to the path.
2. As a result, included extensions have lower precedence over system
   ones (i.e. when adding the previous path it should have a higher
   precedence).
3. Even when using the included extensions, those don't use included
   libraries if these are also in the system (this may be harder to fix).

I may also be getting the following all wrong, but I suspect that in
semi-stadalone apps the included paths should have precedence over
system ones in ``sys.path``.

Well, I think that's all.  Sorry for not being more synthetic, I try to
do my best. :)  Has anyone here experienced the same problems?  Have you
gotten to fix them?  I'm particularly interested on your opinion about
path precedence and possible solutions for point 3.  If you need more
information, don't hesitate to ask.

Thank you and best regards,

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C?rabos Coop. V.  V  V   Enjoy Data
	                          ""
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070616/01f8019b/attachment.pgp 

From Jack.Jansen at cwi.nl  Sat Jun 16 23:41:56 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sat, 16 Jun 2007 23:41:56 +0200
Subject: [Pythonmac-SIG] Democracy player
Message-ID: <BF1203FF-42A0-4D5F-A3B3-08D8A270F8B8@cwi.nl>

Maybe everyone but me knew this already (even though I don't remember  
seeing any posts on this), but the new Democracy Player, which is a  
really convenient way to watch and share video over the net, with an  
outstanding user interface too, is almost completely written in  
Python. The website is <http://www.getdemocracy.com/>.

And the Mac version is (of course) PyObjC-based. I also downloaded  
the code, and while I haven't tried to build it yet (it needs boost  
and pyrex and a couple of other things that I don't have time to  
install right now) it is well-structured and a joy to read.

Definitely worth a look if you have a couple of hours to burn,
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070616/e8361cb7/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2255 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070616/e8361cb7/attachment.bin 

From ronaldoussoren at mac.com  Sun Jun 17 11:36:08 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 17 Jun 2007 11:36:08 +0200
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
Message-ID: <6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>


On 14 Jun, 2007, at 22:42, Ronald Oussoren wrote:

>
> On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote:
>
>> On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote:
>>> However, if was nice to have some stuff without any external
>>> dependencies -- is there a lightweight way to do just Easy Dialogs,
>>> without all of PyObjC?
>>
>> It shouldn't be hard to simply wrap a Cocoa EasyDialogs  
>> implementation
>> in C to construct a traditional Python module, but it make ssense to
>> wait and see how much of Carbon is no longer going to be supported in
>> 64-bit on Leopard (probably the WWDC attendees find out today but  
>> it's
>> NDA'd).  Cocoa doesn't have a generic API that matches that of
>> EasyDialogs as much as Carbon does.
>
> The WWDC attendees (me included) already know but as you say that info
> is under NDA ;-).

But luckily the situation is explained on a mailinglist:

http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00260.html

The summary: no 64-bit Carbon GUI libraries. I haven't even tried to  
compile Python's Carbon wrapper in 64-bit mode, I'd be surprised if  
they compiled cleanly because Apple has done some serious spring- 
cleaning in 64-bit mode.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070617/b3c746e0/attachment.bin 

From kw at codebykevin.com  Sun Jun 17 17:57:29 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Sun, 17 Jun 2007 11:57:29 -0400
Subject: [Pythonmac-SIG] findertools.launch reports "no eligible process"
In-Reply-To: <6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>	<46717329.1060208@noaa.gov>	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>	<4671A208.1020209@noaa.gov>
	<20070614202131.GA54599@uiuc.edu>	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
	<6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
Message-ID: <467559E9.7050500@codebykevin.com>

Ronald Oussoren wrote:
> 
> On 14 Jun, 2007, at 22:42, Ronald Oussoren wrote:
> 
>>
>> On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote:
>>
>>> On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote:
>>>> However, if was nice to have some stuff without any external
>>>> dependencies -- is there a lightweight way to do just Easy Dialogs,
>>>> without all of PyObjC?
>>>
>>> It shouldn't be hard to simply wrap a Cocoa EasyDialogs implementation
>>> in C to construct a traditional Python module, but it make ssense to
>>> wait and see how much of Carbon is no longer going to be supported in
>>> 64-bit on Leopard (probably the WWDC attendees find out today but it's
>>> NDA'd).  Cocoa doesn't have a generic API that matches that of
>>> EasyDialogs as much as Carbon does.
>>
>> The WWDC attendees (me included) already know but as you say that info
>> is under NDA ;-).
> 
> But luckily the situation is explained on a mailinglist:
> 
> http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00260.html
> 
> The summary: no 64-bit Carbon GUI libraries. I haven't even tried to 
> compile Python's Carbon wrapper in 64-bit mode, I'd be surprised if they 
> compiled cleanly because Apple has done some serious spring-cleaning in 
> 64-bit mode.
> 
> Ronald
> 

A couple of questions:

1. Will applications that are 32 bit have any problems running under 
Leopard?
2. Would Python have to be specifically compiled as 64-bit to support 
PyObjC, or would 32-bit Python be OK?

--Kevin


-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From santagada at gmail.com  Sun Jun 17 18:18:55 2007
From: santagada at gmail.com (Leonardo Santagada)
Date: Sun, 17 Jun 2007 13:18:55 -0300
Subject: [Pythonmac-SIG] Error trying to build a extension on python 2.5
	(stdarg.h problem)
In-Reply-To: <70C4EED2-9BF9-4134-B4A2-AC59D38C68F9@gmail.com>
References: <70C4EED2-9BF9-4134-B4A2-AC59D38C68F9@gmail.com>
Message-ID: <3DD62DEE-2D05-49CD-9F02-20D24FDC1D94@gmail.com>

just to wrap this up, my problem had to do with having llvm binaries  
in my path, I don't know why it came with a i686-darwin...-gcc4.0.0  
and that probably conflicted with the real gcc.

Em 15/06/2007, ?s 18:03, Leonardo Santagada escreveu:

> I read the archives of the list, but I have XCode and the universal  
> SDK. I'm having a problem trying to build an extension, here is the  
> output:
>
> retype at Apfelstrudel:/tmp/usession-4/testing_1$ python setup.py build
> running build
> running build_ext
> building 'testing_1' extension
> gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - 
> fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- 
> madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Users/retype/pypy-dist/ 
> pypy/translator/c -I/Library/Frameworks/Python.framework/Versions/ 
> 2.5/include/python2.5 -c testing_1.c -o build/temp.macosx-10.3- 
> fat-2.5/testing_1.o
> In file included from /Developer/SDKs/MacOSX10.4u.sdk/usr/include/ 
> wchar.h:112,
>                  from /Library/Frameworks/Python.framework/Versions/ 
> 2.5/include/python2.5/unicodeobject.h:118,
>                  from /Library/Frameworks/Python.framework/Versions/ 
> 2.5/include/python2.5/Python.h:83,
>                  from /Users/retype/pypy-dist/pypy/translator/c/src/ 
> g_prerequisite.h:10,
>                  from common_header.h:2,
>                  from testing_1.c:1:
> /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:  
> stdarg.h: No such file or directory
> In file included from /Users/retype/pypy-dist/pypy/translator/c/src/ 
> g_include.h:19,
>                  from testing_1.c:554:
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h: In  
> function ?PyList_Pack?:
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:145: error:  
> parse error before ?PyObject?
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h: In  
> function ?PyDict_Pack?:
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:166: error:  
> parse error before ?PyObject?
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:167: error:  
> parse error before ?PyObject?
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h: In  
> function ?CallWithShape?:
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:309: error:  
> parse error before ?PyObject?
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:318: error:  
> parse error before ?PyObject?
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:325: error:  
> parse error before ?PyObject?
> /Users/retype/pypy-dist/pypy/translator/c/src/support.h:338: error:  
> parse error before ?PyObject?
> lipo: can't figure out the architecture type of: /var/tmp// 
> ccoT8b3x.out
> error: command 'gcc' failed with exit status 1
>
> and the setup.py file is here:
>
>
> from distutils.core import setup
> from distutils.extension import Extension
> from distutils.ccompiler import get_default_compiler
>
> PYPY_INCLUDE_DIR = '/Users/retype/pypy-dist/pypy/translator/c'
>
> extra_compile_args = []
> if get_default_compiler() == "unix":
>     extra_compile_args.extend(["-Wno-unused-label",
>                                "-Wno-unused-variable"])
>
> setup(name="testing_1",
>       ext_modules = [Extension(name = "testing_1",
>                             sources = ["testing_1.c"],
>                  extra_compile_args = extra_compile_args,
>                        include_dirs = [PYPY_INCLUDE_DIR])])
>
>
> so although this came from pypy, I really think the problem is  
> either on my machine or on distutils (probably my machine, as I  
> don't believe this could break with such a simple script).
> do anyone know how can I fix this?
>
> --
> Leonardo Santagada
> "If it looks like a duck, and quacks like a duck, we have at least  
> to consider the possibility that we have a small aquatic bird of  
> the family anatidae on our hands." - Douglas Adams
>
>
>

--
Leonardo Santagada
"If it looks like a duck, and quacks like a duck, we have at least to  
consider the possibility that we have a small aquatic bird of the  
family anatidae on our hands." - Douglas Adams




From ronaldoussoren at mac.com  Sun Jun 17 18:26:38 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 17 Jun 2007 18:26:38 +0200
Subject: [Pythonmac-SIG] 64-bit code
In-Reply-To: <467559E9.7050500@codebykevin.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
	<6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
	<467559E9.7050500@codebykevin.com>
Message-ID: <8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>


On 17 Jun, 2007, at 17:57, Kevin Walzer wrote:

> Ronald Oussoren wrote:
>> On 14 Jun, 2007, at 22:42, Ronald Oussoren wrote:
>>>
>>> On Jun 14, 2007, at 1:21 PM, Nicholas Riley wrote:
>>>
>>>> On Thu, Jun 14, 2007 at 01:16:08PM -0700, Christopher Barker wrote:
>>>>> However, if was nice to have some stuff without any external
>>>>> dependencies -- is there a lightweight way to do just Easy  
>>>>> Dialogs,
>>>>> without all of PyObjC?
>>>>
>>>> It shouldn't be hard to simply wrap a Cocoa EasyDialogs  
>>>> implementation
>>>> in C to construct a traditional Python module, but it make  
>>>> ssense to
>>>> wait and see how much of Carbon is no longer going to be  
>>>> supported in
>>>> 64-bit on Leopard (probably the WWDC attendees find out today  
>>>> but it's
>>>> NDA'd).  Cocoa doesn't have a generic API that matches that of
>>>> EasyDialogs as much as Carbon does.
>>>
>>> The WWDC attendees (me included) already know but as you say that  
>>> info
>>> is under NDA ;-).
>> But luckily the situation is explained on a mailinglist:
>> http://lists.apple.com/archives/Carbon-dev/2007/Jun/msg00260.html
>> The summary: no 64-bit Carbon GUI libraries. I haven't even tried  
>> to compile Python's Carbon wrapper in 64-bit mode, I'd be  
>> surprised if they compiled cleanly because Apple has done some  
>> serious spring-cleaning in 64-bit mode.
>> Ronald
>
> A couple of questions:
>
> 1. Will applications that are 32 bit have any problems running  
> under Leopard?

Apple has a rather good track record with respect to backward  
compatibility, so I expect that all 32-bit programs that work  
properly on Tiger will do the same on Leopard (except for problems  
that are caused by using private interfaces).

As was mentioned in the keynote, Leopard will by 4-way universal  
throughout except for some exceptions. This means that 32-bit builds  
for applications will run on all Leopard machines, there are no  
seperate Leopard builds for 32-bit and 64-bit machines. This in turn  
means you don't have to provide a 64-bit build unless you want to,  
which would most likely be because you can make use of the additional  
resources that a 64-bit build brings (both a larger addressspace and  
on Intel more registers).

> 2. Would Python have to be specifically compiled as 64-bit to  
> support PyObjC, or would 32-bit Python be OK?

Porting PyObjC to 64-bit is a work in progress, but one that I expect  
to finish soon. The biggest problem is 64-bit support in libffi, but  
luckily I can build on someone else's work there.

32-bit support in PyObjC is already there and won't disappear.  
Likewise for support for Tiger systems.

Speaking of PyObjC: I'm working on a new major release of PyObjC. The  
code is not yet available in the public repository because I'm  
targetting Leopard (with a backward compatibility layer for Tiger and  
Panther) and didn't want to have to think too much about which parts  
of the code are covered by the Leopard NDA.  I'll starting writing  
more about this in the near future, but let me say I'm really excited  
about the enhancements in the 2.0 tree.

Ronald

>
> --Kevin
>
>
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070617/0a2ef3c6/attachment.bin 

From delza at livingcode.org  Sun Jun 17 19:41:17 2007
From: delza at livingcode.org (Dethe Elza)
Date: Sun, 17 Jun 2007 10:41:17 -0700
Subject: [Pythonmac-SIG] 64-bit code
In-Reply-To: <8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
	<6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
	<467559E9.7050500@codebykevin.com>
	<8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>
Message-ID: <0F75B037-D0D2-4DBA-903D-5DAAACAB8252@livingcode.org>

On 17-Jun-07, at 9:26 AM, Ronald Oussoren wrote:

> Speaking of PyObjC: I'm working on a new major release of PyObjC.  
> The code is not yet available in the public repository because I'm  
> targetting Leopard (with a backward compatibility layer for Tiger  
> and Panther) and didn't want to have to think too much about which  
> parts of the code are covered by the Leopard NDA.  I'll starting  
> writing more about this in the near future, but let me say I'm  
> really excited about the enhancements in the 2.0 tree.
>
> Ronald

That's good to hear.  I'm very excited about Leopard, which in many  
ways seems to be for developers more than for end users.  I suspected  
that the quiet on the PyObjC front may have had to do with Leopard  
development, but it's nice to have confirmation of that.  I can  
hardly wait.

--Dethe


"It goes against the grain of modern education to teach children to  
program. What fun is there in making plans, acquiring discipline in  
organizing thoughts, devoting attention to detail and learning to be  
self-critical?" --Alan Perlis



From kw at codebykevin.com  Sun Jun 17 20:06:03 2007
From: kw at codebykevin.com (Kevin Walzer)
Date: Sun, 17 Jun 2007 14:06:03 -0400
Subject: [Pythonmac-SIG] 64-bit code
In-Reply-To: <8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
	<6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
	<467559E9.7050500@codebykevin.com>
	<8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>
Message-ID: <4675780B.8010106@codebykevin.com>

Ronald Oussoren wrote:

> 
> As was mentioned in the keynote, Leopard will by 4-way universal 
> throughout except for some exceptions. This means that 32-bit builds for 
> applications will run on all Leopard machines, there are no seperate 
> Leopard builds for 32-bit and 64-bit machines. This in turn means you 
> don't have to provide a 64-bit build unless you want to, which would 
> most likely be because you can make use of the additional resources that 
> a 64-bit build brings (both a larger addressspace and on Intel more 
> registers).

OK, I guess this means that 32-bit isn't going away any time soon. The 
Carbon-dev list seems to think that this announcement means Carbon is 
going the way of Classic. At least some of the people on that list say 
that they will drop Mac support rather than port to Cocoa, because they 
need 64-bit. That's not directly germane to my concerns, as I don't 
think I need 64-bit for what I do. If I port to Cocoa, I want it to be 
my choice, not one coerced by Apple,  i.e., not supporting anything but 
Cocoa.

Tk/Tkinter, my current GUI toolkit of choice, builds on Carbon and in 
fact has in recent months undergone a huge amount of modernization to 
bring it in line with modern Carbon standards (no more QuickDraw, 
support for ATUSI, etc.). I haven't pushed my applications to the latest 
versions of the Tk frameworks, but will be doing so soon.

I still can't believe that Carbon won't be 64-bit eventually...does 
anyone really expect Adobe to port Photoshop or Microsoft to port Office 
to Objective-C?

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From Jack.Jansen at cwi.nl  Sun Jun 17 23:30:01 2007
From: Jack.Jansen at cwi.nl (Jack Jansen)
Date: Sun, 17 Jun 2007 23:30:01 +0200
Subject: [Pythonmac-SIG] 64-bit code
In-Reply-To: <4675780B.8010106@codebykevin.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
	<6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
	<467559E9.7050500@codebykevin.com>
	<8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>
	<4675780B.8010106@codebykevin.com>
Message-ID: <E1D4FE42-C4DC-465A-B4DD-ACFF77443B28@cwi.nl>


On  17-Jun-2007, at 20:06 , Kevin Walzer wrote:
> OK, I guess this means that 32-bit isn't going away any time soon. The
> Carbon-dev list seems to think that this announcement means Carbon is
> going the way of Classic. At least some of the people on that list say
> that they will drop Mac support rather than port to Cocoa, because  
> they
> need 64-bit. That's not directly germane to my concerns, as I don't
> think I need 64-bit for what I do.

The last sentence is the pit you'll fall in. At least, it's the pit  
that I'm scared of falling in.

Even though my own code would benefit little from 64 bits, it depends  
on all sorts of third party libraries (mainly media stuff in my case,  
but the same holds for many other fields). As soon as such a library  
gets a twofold performance increase from switching to 64bits it's  
going to be very tempting for me to follow suit.

And this works iteratively: as soon as I switch to 64bits then people  
using my stuff will have to follow too. And even the tiniest  
application nowadays uses layer upon layer of third party software.  
Indeed, 32 bit support isn't going to go away in the next 2 years,  
but the bell has tolled. Compare what happened to Windows programs  
when they switched from win16 to win32: even though win16 programs  
could technically continue to be run for a pretty long time they were  
cut off from new developments and either were ported or died.

But, all that said, I'm not scared of the 32-64 transition. For my  
own code it'll probably be comparable to the PPC-Intel transition:  
more work than you hope for but nothing as drastic as the OS9-OSX  
switch or the 68K-PPC switch. The only thing I'm a bit scared of is  
Apple's own useful toolkits that depend on Carbon, specifically  
QuickTime and AppleEvents. I'm not too sure about AE, but for  
QuickTime I know that you have to leave QTKit and switch to the old  
QuickTime API's very often if you do more than play a simple video.  
So effectively this'll mean that the "single toolkit for everything"  
paradigm will break, because Oldstyle-C-Quicktime will (in 64 bit  
space) lose it's ability to tweak the rendering so it'll be an edit- 
only API and QTKit will have to be used for rendering.
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070617/c1df0e2b/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2255 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070617/c1df0e2b/attachment.bin 

From ronaldoussoren at mac.com  Mon Jun 18 07:03:30 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 18 Jun 2007 07:03:30 +0200
Subject: [Pythonmac-SIG] 64-bit code
In-Reply-To: <4675780B.8010106@codebykevin.com>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<17E611A3-700E-4D29-8813-802F396CFF6F@cwi.nl>
	<1D2C72ED-A0B5-4465-8E0D-1D4399AC478A@virgin.net>
	<46717329.1060208@noaa.gov>
	<18208B22-0113-1000-A429-D7CE71F16789-Webmail-10017@mac.com>
	<4671A208.1020209@noaa.gov> <20070614202131.GA54599@uiuc.edu>
	<1CC09904-5F41-4BDA-AD7E-C65A13C20587@mac.com>
	<6444B3CD-E11A-44C9-BA0B-C8C204EBF85E@mac.com>
	<467559E9.7050500@codebykevin.com>
	<8DB46AD3-884C-496C-BE3D-17FDC6CDDC68@mac.com>
	<4675780B.8010106@codebykevin.com>
Message-ID: <6DB17EF2-D779-40EC-B711-2D2348EF43BF@mac.com>


On 17 Jun, 2007, at 20:06, Kevin Walzer wrote:

> Ronald Oussoren wrote:
>
>> As was mentioned in the keynote, Leopard will by 4-way universal  
>> throughout except for some exceptions. This means that 32-bit  
>> builds for applications will run on all Leopard machines, there  
>> are no seperate Leopard builds for 32-bit and 64-bit machines.  
>> This in turn means you don't have to provide a 64-bit build unless  
>> you want to, which would most likely be because you can make use  
>> of the additional resources that a 64-bit build brings (both a  
>> larger addressspace and on Intel more registers).
>
> OK, I guess this means that 32-bit isn't going away any time soon.  
> The Carbon-dev list seems to think that this announcement means  
> Carbon is going the way of Classic. At least some of the people on  
> that list say that they will drop Mac support rather than port to  
> Cocoa, because they need 64-bit. That's not directly germane to my  
> concerns, as I don't think I need 64-bit for what I do. If I port  
> to Cocoa, I want it to be my choice, not one coerced by Apple,   
> i.e., not supporting anything but Cocoa.

I'm not very interested in Carbon and have therefore not paid a lot  
of attention to this, but anyone that has a pressing need for 64-bit  
Carbon should at least file bugreport at Apple and preferably one  
that includes a bussiness case.

>
> Tk/Tkinter, my current GUI toolkit of choice, builds on Carbon and  
> in fact has in recent months undergone a huge amount of  
> modernization to bring it in line with modern Carbon standards (no  
> more QuickDraw, support for ATUSI, etc.). I haven't pushed my  
> applications to the latest versions of the Tk frameworks, but will  
> be doing so soon.
>
> I still can't believe that Carbon won't be 64-bit eventually...does  
> anyone really expect Adobe to port Photoshop or Microsoft to port  
> Office to Objective-C?

32-bit programs run just fine on an 64-bit system, unlike a certain  
OS from the northern part of the US (AFAIK). Photoshop should be a  
program that can make use of the additional memory space that you're  
getting in a 64-bit build.

Ronald
>
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070618/1a0d7ac0/attachment.bin 

From airdrummer at wheel.org  Tue Jun 19 01:43:20 2007
From: airdrummer at wheel.org (tom wible)
Date: Mon, 18 Jun 2007 19:43:20 -0400
Subject: [Pythonmac-SIG] creating a dictionary for an applescript app?
In-Reply-To: <63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
Message-ID: <46771898.3010106@wheel.org>

i'm trying to access a function in an applescript.app i've written...in 
applescript it's:

    tell application "playRec"
	initRecList(false)
	set recList to listRecDict() -- returns a list of records
    end tell

but i want to do it in py-appscript (so i can use cheetah) but ASTranslate 
errors: Untranslated event 'ascrpsbr'

i've set NSAppleScriptEnabled in my app's info.plist, and created an sdef as 
suggested in 
http://lists.apple.com/archives/applescript-implementors/2004/Feb/msg00028.html
but i've not found any docs showing how to link the sdef to my applescript...

can someone point me there?
thanx

From hengist.podd at virgin.net  Tue Jun 19 15:50:48 2007
From: hengist.podd at virgin.net (has)
Date: Tue, 19 Jun 2007 14:50:48 +0100
Subject: [Pythonmac-SIG] creating a dictionary for an applescript app?
In-Reply-To: <46771898.3010106@wheel.org>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>
	<46771898.3010106@wheel.org>
Message-ID: <1601DC6A-E248-441B-875C-23F1764ABE7C@virgin.net>

On 19 Jun 2007, at 00:43, tom wible wrote:

> i'm trying to access a function in an applescript.app i've  
> written...in applescript it's:
>
>    tell application "playRec"
> 	initRecList(false)
> 	set recList to listRecDict() -- returns a list of records
>    end tell
>
> but i want to do it in py-appscript (so i can use cheetah) but  
> ASTranslate errors: Untranslated event 'ascrpsbr'

Appscript doesn't provide an API for calling user-defined  
subroutines. You need to drop into aem and use raw AE codes to do that.


> i've set NSAppleScriptEnabled in my app's info.plist, and created  
> an sdef as suggested in http://lists.apple.com/archives/applescript- 
> implementors/2004/Feb/msg00028.html
> but i've not found any docs showing how to link the sdef to my  
> applescript...

The simplest thing would probably be to call your applet's user- 
defined subroutines via aem:

#!/usr/local/bin/python

from aem import *

playRec = Application(findapp.byname('playRec'))

playRec.event('ascrpsbr', {'snam': 'initRecList', '----':  
[False]}).send()
recList = playRec.event('ascrpsbr', {'snam': 'listRecDict', '----':  
[]}).send()


If you really want to add a dictionary, assuming you've saved your  
applet as a bundle, use sdp to convert your sdef to a .r file, then  
use Rez to append it to your applet's applet.rsrc file:

sdp -fa playRec.sdef
Rez playRec.r -a -o applet.rsrc -useDF


You'll need to define your applet's handlers using the raw AE codes  
given in your dictionary, of course, e.g.

on ?event PRecIntL? arg
    ...
end ?event PRecILst?

<command name="init rec list" code="PRecIntL" description="">
	<direct-parameter type="boolean" description=""/>
</command>


HTH

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From daniel at keystonewood.com  Tue Jun 19 17:38:52 2007
From: daniel at keystonewood.com (Daniel Miller)
Date: Tue, 19 Jun 2007 11:38:52 -0400
Subject: [Pythonmac-SIG] Send a fax or email via PDF workflow with PyObjC
Message-ID: <3DA627AC-0985-44D6-9E3F-ADD4127DFA3E@keystonewood.com>

I'm using PyObjC to print a PDF document in an application I'm  
building. I've got the print feature working with a custom NSView  
subclass and NSPrintOperation (I can print and preview PDF documents  
generated by my application). However, I would like to provide a fax  
number and and email address to be used if the user chooses to Fax or  
Email the document from the PDF workflow menu. Is there any way to  
set those values programatically?

I tried setting the NSPrintFaxNumber option of NSPrintInfo, but that  
had no effect (I also set page margins in the NSPrintInfo and they  
were observed, so I know my NSPrintInfo is working...at least  
partially).

Thanks in advance for any help given.

~ Daniel.

From hengist.podd at virgin.net  Wed Jun 20 14:03:26 2007
From: hengist.podd at virgin.net (has)
Date: Wed, 20 Jun 2007 13:03:26 +0100
Subject: [Pythonmac-SIG] creating a dictionary for an applescript app?
In-Reply-To: <46784963.2050703@wheel.org>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>	<46771898.3010106@wheel.org>
	<1601DC6A-E248-441B-875C-23F1764ABE7C@virgin.net>
	<46784963.2050703@wheel.org>
Message-ID: <C99BCE8E-CAE8-4685-82BB-FE72282333DB@virgin.net>

On 19 Jun 2007, at 22:23, tom wible wrote:

> btw, the aem complication increases my motivation to rewrite the  
> applescript...i only used a/s because ired & vdvhs are a/s-able,  
> and appscript solves that problem;-)

aem's easy enough to use if you know a little bit about how Apple  
events work, and you can easily extend its Application class to call  
user-defined subroutines with positional parameters, e.g.:

#!/usr/local/bin/python

import aem

class Applet(aem.Application):
	def initwithname(klass, name):
		return klass(aem.findapp.byname(name))
	initwithname = classmethod(initwithname)

	def callsub(self, name, *args):
		self.event('ascrpsbr', {'snam': name, '----': args}).send()


playRec = Applet.initwithname('playRec')
playRec.callsub('initRecList', False)
recList = playRec.callsub('listRecDict')


Adding convenience methods for calling standard event handlers (run,  
reopen, quit, etc.) and extending callsub to support labelled  
parameters wouldn't be too hard if you want to make a general-purpose  
module out of it.

HTH

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From hengist.podd at virgin.net  Fri Jun 22 10:38:46 2007
From: hengist.podd at virgin.net (has)
Date: Fri, 22 Jun 2007 09:38:46 +0100
Subject: [Pythonmac-SIG] creating a dictionary for an applescript app?
In-Reply-To: <467B1F61.2000404@wheel.org>
References: <mailman.10.1181642403.9991.pythonmac-sig@python.org>
	<63BE76D1-B240-47B4-86D7-8DC2F9CDE999@virgin.net>	<46771898.3010106@wheel.org>
	<1601DC6A-E248-441B-875C-23F1764ABE7C@virgin.net>
	<467B1F61.2000404@wheel.org>
Message-ID: <CC086905-B29C-4FEC-B92F-ECF99C863031@virgin.net>

On 22 Jun 2007, at 02:01, tom wible wrote:

> tried your applet code:
>
> >>> playRec = praem.Applet.initwithname('playRec')
> >>> recList = playRec.callsub('listRecDict')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "praem.py", line 9, in callsub
>     self.event('ascrpsbr', {'snam': name, '----': args}).send()
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/site-packages/aeosa/aem/send/send.py", line 101, in send
>     raise CommandError(err[0], err.args[1:] and err[1] or '', None)
> aem.send.send.CommandError: CommandError -1708: the AppleEvent was  
> not handled by any handler
>
> but i do have a handler:
>
>
> on listRecDict()
> 	set tdl to {}
> 	set n to 0
> 	repeat with rec in recList
> 		set n to n + 1
> 		set end of tdl to rec's toDict(n)
> 	end repeat
> 	return tdl
> end listRecDict
>
> is there something else that has to be done to get the handler  
> recognized?
> thanx

My bad, I forgot to lowercase the subroutine names in my Python  
script. Internally, AppleScript lowercases subroutine names unless  
they're written within pipes, e.g. 'FooBar' should be called as  
'foobar', '|FooBar|' as 'FooBar'. So the correct code should be:

playRec = Applet.initwithname('playRec')
playRec.callsub('initreclist', False)
recList = playRec.callsub('listrecdict')

HTH

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html


From phystad at mac.com  Fri Jun 22 18:31:16 2007
From: phystad at mac.com (Phil Hystad)
Date: Fri, 22 Jun 2007 09:31:16 -0700
Subject: [Pythonmac-SIG] 64 bit python on G5 Mac OS X
Message-ID: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>

Is there a 64 bit version of Python for a dual-G5 running Mac OS X (Tiger)?

From bob at redivi.com  Fri Jun 22 19:19:02 2007
From: bob at redivi.com (Bob Ippolito)
Date: Fri, 22 Jun 2007 10:19:02 -0700
Subject: [Pythonmac-SIG] 64 bit python on G5 Mac OS X
In-Reply-To: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>
References: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>
Message-ID: <6a36e7290706221019k76e1a51ar3ada12c6d2f509cf@mail.gmail.com>

No. Last time I tried it I managed to get it to build, but it crashed.
I don't think 64-bit works properly in Tiger.

-bob

On 6/22/07, Phil Hystad <phystad at mac.com> wrote:
> Is there a 64 bit version of Python for a dual-G5 running Mac OS X (Tiger)?
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

From phystad at mac.com  Fri Jun 22 19:35:46 2007
From: phystad at mac.com (Phil Hystad)
Date: Fri, 22 Jun 2007 10:35:46 -0700
Subject: [Pythonmac-SIG] 64 bit python on G5 Mac OS X
In-Reply-To: <EB912619-9A12-46BA-867C-B9D8FF34C69E@xsupport.nl>
References: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>
	<6a36e7290706221019k76e1a51ar3ada12c6d2f509cf@mail.gmail.com>
	<EB912619-9A12-46BA-867C-B9D8FF34C69E@xsupport.nl>
Message-ID: <A590B44D-0113-1000-A29E-46969343B6CC-Webmail-10008@mac.com>

OK, looking good then.

Offhand, although I could look this up I presume, are there 64-bit versions of python available on
the various 64 bit Unix platforms?  Silly question, I assume there are and I can easily look this
up.



On Friday, June 22, 2007, at 10:26AM, "Frans Schippers" <frans.schippers at xsupport.nl> wrote:
>Ronald managed to get a 64bit version working for me,
>Ik think he will respond to the mailing list.
>
>
>On 22-jun-2007, at 19:19, Bob Ippolito wrote:
>
>> No. Last time I tried it I managed to get it to build, but it crashed.
>> I don't think 64-bit works properly in Tiger.
>>
>> -bob
>>
>> On 6/22/07, Phil Hystad <phystad at mac.com> wrote:
>>> Is there a 64 bit version of Python for a dual-G5 running Mac OS X  
>>> (Tiger)?
>>> _______________________________________________
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>>
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
>
>
>

From shawnmiranda2 at comcast.net  Fri Jun 22 20:13:03 2007
From: shawnmiranda2 at comcast.net (Shawn Miranda)
Date: Fri, 22 Jun 2007 11:13:03 -0700
Subject: [Pythonmac-SIG] NEVER MIND! Re: Another report on py2app error with
Message-ID: <aa92e3c66a14e819a0858bb6240f40fd@comcast.net>

Perhaps Daniel or someone else could tell me why I'm getting a syntax 
error when I run py2app.  I have used it successfully with some simple 
scripts including a couple of Tkinter GUI scripts, but I'm fairly new 
to Python and py2app so it could be something quite simple. The scripts 
do run when I run them from the command line.  For example:

from Tkinter import Label

widget = Label(None, text = "It works!")

widget.pack()

widget.mainloop()

Thanks, Shawn

I'm currently running Python 2.3 on OS 10.3.9.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 598 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070622/c7474584/attachment.bin 

From frans at xsupport.nl  Fri Jun 22 20:00:52 2007
From: frans at xsupport.nl (Frans Schippers)
Date: Fri, 22 Jun 2007 20:00:52 +0200
Subject: [Pythonmac-SIG] 64 bit python on G5 Mac OS X
In-Reply-To: <6a36e7290706221019k76e1a51ar3ada12c6d2f509cf@mail.gmail.com>
References: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>
	<6a36e7290706221019k76e1a51ar3ada12c6d2f509cf@mail.gmail.com>
Message-ID: <1A498795-687A-4088-BAD3-D22A340A07B1@xsupport.nl>

Ronald managed to get a 64bit version working for me,
Ik think he will respond to the mailing list.


On 22-jun-2007, at 19:19, Bob Ippolito wrote:

> No. Last time I tried it I managed to get it to build, but it crashed.
> I don't think 64-bit works properly in Tiger.
>
> -bob
>
> On 6/22/07, Phil Hystad <phystad at mac.com> wrote:
>> Is there a 64 bit version of Python for a dual-G5 running Mac OS X  
>> (Tiger)?
>> _______________________________________________
>> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>


From shawnmiranda2 at comcast.net  Sat Jun 23 08:27:45 2007
From: shawnmiranda2 at comcast.net (Shawn Miranda)
Date: Fri, 22 Jun 2007 23:27:45 -0700
Subject: [Pythonmac-SIG]  Py2app syntax error
Message-ID: <93810c8a427b762ee94c4b29b3d99aa7@comcast.net>

Hello,

I'm reposting this just to make the subject heading clearer.  The 
previous post was my first and I didn't quite realize how it works.

Perhaps someone could tell me why I'm getting a syntax error when I run 
py2app.  I have used it successfully with some simple scripts including 
a couple of Tkinter GUI scripts, but I'm fairly new to Python and 
py2app so it could be something quite simple. The scripts do run when I 
run them from the command line.  For example:

from Tkinter import Label

widget = Label(None, text = "It works!")

widget.pack()

widget.mainloop()

Thanks, Shawn

I'm currently running Python 2.3 on OS 10.3.9.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 731 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070622/4b2ee056/attachment.bin 

From ronaldoussoren at mac.com  Mon Jun 25 07:57:06 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 25 Jun 2007 07:57:06 +0200
Subject: [Pythonmac-SIG] 64 bit python on G5 Mac OS X
In-Reply-To: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>
References: <A590B44D-0113-1000-A178-46969343B6CC-Webmail-10008@mac.com>
Message-ID: <A1E9D0B9-30A5-4CE3-B6E2-912666A495AD@mac.com>


On 22 Jun, 2007, at 18:31, Phil Hystad wrote:

> Is there a 64 bit version of Python for a dual-G5 running Mac OS X  
> (Tiger)?

I posted about this a while back, with a (rather hackish) procedure  
to get it to compile:

<quote>
The build is universal, but for me only one of the two archictures
actually worked: I did my build on an Intel system and the 64-bit
build worked on that machine, but didn't work on a G5 mac. That's
probably something shallow, but as that machine doesn't have the
Xcode installed and is on the other side of a slow network connection
I haven't tried to debug this yet.

1) Edit the configure script, look for "-arch i386" and "-arch ppc"
and change that those to  "-arch ppc64" and "-arch x86_64". You'll
have to make multiple changes to the configure file.

2) Build using:

        $ mkdir build
        $ cd build
        $ CFLAGS="-arch ppc64 -arch x86_64" ../configure \
            --enable-universalsdk \
            --disable-toolbox-glue --prefix=/opt/python25-64bit
        $ make
        $ make install

3) Optionally: run "make testall" to run the unittests and check
pyconfig.h to check the various SIZEOF definitions.

You now have a 64-bit build of python in /opt/python25-64bit.

</quote>

The resulting binary is 2-way universal, but will actually only work  
correctly on the architecture where you did the build (that is, if  
you run the build on a PPC64 system the binary won't work correctly  
on x86-64 and v.v.).  I'm pretty sure this is a shallow problem,  
caused by differences in vararg handling that are detected by the  
configure script.

Note that these instructions will give you an incomplete  
installation, a number of extensions in the standard library won't be  
build because they use a C library that is not available in 64-bit  
mode. If you want to use those libraries (openssl, zlib, bz2 and  
possibly others as well) you have to build the required C libraries  
in 64-bit mode as well.

And a final note: you can probably get the same effect by supplying  
the right OPT, CFLAGS and LDFLAGS arguments to configure instead of  
editing the configure script. I used the procedure mentioned earlier  
because I hoped to get a universal build as the development and test  
systems I was using at the time had different architectures (a  
macbook pro vs. a G5 xserve).

Ronald

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070625/f7b7612b/attachment.bin 

From ronaldoussoren at mac.com  Mon Jun 25 08:05:55 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 25 Jun 2007 08:05:55 +0200
Subject: [Pythonmac-SIG] Py2app syntax error
In-Reply-To: <93810c8a427b762ee94c4b29b3d99aa7@comcast.net>
References: <93810c8a427b762ee94c4b29b3d99aa7@comcast.net>
Message-ID: <262754CC-F593-4871-8E53-EF3D75AB62E7@mac.com>


On 23 Jun, 2007, at 8:27, Shawn Miranda wrote:

> Hello,
>
> I'm reposting this just to make the subject heading clearer.  The  
> previous post was my first and I didn't quite realize how it works.
>
> Perhaps someone could tell me why I'm getting a syntax error when I  
> run py2app.  I have used it successfully with some simple scripts  
> including a couple of Tkinter GUI scripts, but I'm fairly new to  
> Python and py2app so it could be something quite simple. The  
> scripts do run when I run them from the command line.  For example:
>
> from Tkinter import Label
>
> widget = Label(None, text = "It works!")
>
> widget.pack()
>
> widget.mainloop()
>
> Thanks, Shawn
>
> I'm currently running Python 2.3 on OS 10.3.9.

What is the error that you're getting? I cannot reproduce this on  
10.4.10 with Python 2.5. Including the setup.py file you're using to  
build the example you included would also be helpfull.

Ronald

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070625/2c5dfa28/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070625/2c5dfa28/attachment.bin 

From shawnmiranda2 at comcast.net  Mon Jun 25 08:46:13 2007
From: shawnmiranda2 at comcast.net (Shawn Miranda)
Date: Sun, 24 Jun 2007 23:46:13 -0700
Subject: [Pythonmac-SIG]  Py2app syntax error
Message-ID: <440be828702b23b84ac4873271f60080@comcast.net>

On 23 Jun, 2007, at 8:27, Shawn Miranda wrote:

Hello,

I'm reposting this just to make the subject heading clearer.? The 
previous post was my first and I didn't quite realize how it works.

Perhaps someone could tell me why I'm getting a syntax error when I run 
py2app.? I have used it successfully with some simple scripts including 
a couple of Tkinter GUI scripts, but I'm fairly new to Python and 
py2app so it could be something quite simple. The scripts do run when I 
run them from the command line.? For example:

from Tkinter import Label

widget = Label(None, text = "It works!")

widget.pack()

widget.mainloop()

Thanks, Shawn

I'm currently running Python 2.3 on OS 10.3.9.

What is the error that you're getting? I cannot reproduce this on 
10.4.10 with Python 2.5. Including the setup.py file you're using to 
build the example you included would also be helpfull.

Ronald


Thanks, Ronald, for taking an interest in this.

The error I get is:

SyntaxError: invalid syntax

The terminal shows the script and points to the last brace of 
widget.pack()

The setup.py file I'm using is:

#!/usr/bin/env python
"""
py2app build script for MyApplication

Usage:
     python setup.py py2app
"""
from distutils.core import setup
setup(
		app=["/Users/shawnmiranda/Desktop/Label.py"],
)


This same setup script works just fine with:

# File: hello1.py

from Tkinter import *

root = Tk()

w = Label(root, text="Hello, world!")
w.pack()

root.mainloop()


Both GUI scripts work just fine from the command line.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2685 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070624/7a02efae/attachment.bin 

From jerry.levan at eku.edu  Mon Jun 25 19:25:20 2007
From: jerry.levan at eku.edu (Jerry LeVan)
Date: Mon, 25 Jun 2007 13:25:20 -0400
Subject: [Pythonmac-SIG] Build Applet Environ problem...
Message-ID: <176B99C3-E993-41CC-A843-3FCCCFB18C98@eku.edu>

Hi,

This weekend I got a MBP and started to transition to the Intel from  
PPC.

I use the "Build Applet" tool to make lightweight apps that I can  
launch from
the Dock.

Some of my apps use environmental variables to simplify the  
environment setup.

On the PPC G4 the applets would pick up the environmental variables  
when launched
from the dock. On the Intel side this does not appear to be the case.

If I launch the app from the command line "open -a" the environment  
vars will
be picked up.

Is this problem somehow my fault or is this a PythonMac/Intel problem?

Jerry


From njriley at uiuc.edu  Mon Jun 25 19:40:19 2007
From: njriley at uiuc.edu (Nicholas Riley)
Date: Mon, 25 Jun 2007 12:40:19 -0500
Subject: [Pythonmac-SIG] Build Applet Environ problem...
In-Reply-To: <176B99C3-E993-41CC-A843-3FCCCFB18C98@eku.edu>
References: <176B99C3-E993-41CC-A843-3FCCCFB18C98@eku.edu>
Message-ID: <20070625174019.GA61859@uiuc.edu>

On Mon, Jun 25, 2007 at 01:25:20PM -0400, Jerry LeVan wrote:
> Hi,
> 
> This weekend I got a MBP and started to transition to the Intel from  
> PPC.
> 
> I use the "Build Applet" tool to make lightweight apps that I can  
> launch from
> the Dock.
> 
> Some of my apps use environmental variables to simplify the  
> environment setup.
> 
> On the PPC G4 the applets would pick up the environmental variables  
> when launched
> from the dock. On the Intel side this does not appear to be the case.
> 
> If I launch the app from the command line "open -a" the environment  
> vars will
> be picked up.
> 
> Is this problem somehow my fault or is this a PythonMac/Intel problem?

Stuff you launch from the dock shouldn't read your shell rc files.
You'll need to use ~/.MacOSX/environment.plist instead.

-- 
Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>

From vivacarlie at gmail.com  Wed Jun 27 18:40:54 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Wed, 27 Jun 2007 11:40:54 -0500
Subject: [Pythonmac-SIG] Py2app syntax error
In-Reply-To: <440be828702b23b84ac4873271f60080@comcast.net>
References: <440be828702b23b84ac4873271f60080@comcast.net>
Message-ID: <65fadfc30706270940s154aef5aq785ef2175922a03b@mail.gmail.com>

are you sure you can't post the entire traceback? just copy/paste from the
terminal into the browser window.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070627/592568e6/attachment.htm 

From vivacarlie at gmail.com  Wed Jun 27 18:51:24 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Wed, 27 Jun 2007 11:51:24 -0500
Subject: [Pythonmac-SIG] newbie: threads in PyObjC
In-Reply-To: <4C64FA8D-58D1-45BB-A7FF-027F67F8D03B@mac.com>
References: <4C64FA8D-58D1-45BB-A7FF-027F67F8D03B@mac.com>
Message-ID: <65fadfc30706270951r1db61682kea78e2064496bedd@mail.gmail.com>

is this a question or an answer? is this a cocoa question or a PyObjC
question?

On 6/6/07, Tom Elliott <telliott99 at mac.com> wrote:
>
> The kill() method is just a stub, written back when I thought the way to
> do this is for the main thread to terminate the worker thread.  Now, after
> more reading, I realize it's better to have the worker test a condition
> periodically and exit (gracefully) if necessary.
> The withObject_ parameter can be used to pass a reference back to the
> original thread.  This is useful when the new thread executes a method in a
> different class.  I ended up just calling a method in the same class, like
> this:
>
> from Foundation import *
> from AppKit import *
> import objc, time
>
> from PyObjCTools import NibClassBuilder
>
> class PyThreadAppDelegate(NibClassBuilder.AutoBaseClass):
>     def init(self):
>         self = super(PyThreadAppDelegate, self).init()
>         return self
>
>
>     def go_(self, sender):
>         print 'go_'
>         self.continueFlag = True
>         #t = Threaded.alloc().init()
>         NSThread.detachNewThreadSelector_toTarget_withObject_(
>             'newThread:', self, None)
>
>
>     def kill_(self, sender):
>         print 'kill_'
>         self.continueFlag = False
>
>
>     @objc.signature('v:@')
>     def newThread_(sender):
>         pool = NSAutoreleasePool.alloc().init()
>         print 'Threaded', sender
>         for i in range(10):
>             if sender.continueFlag:
>                 time.sleep(1)
>                 print i
>         del pool
>
> Thanks.
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>


-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070627/28f3d7a0/attachment.html 

From lists at collab.nl  Thu Jun 28 00:56:16 2007
From: lists at collab.nl (Thijs Triemstra|Collab)
Date: Thu, 28 Jun 2007 00:56:16 +0200
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
Message-ID: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>

hi,

I'm trying to bundle the Adobe AIR framework and my Python  
application with py2app. But I'm getting the error below as soon as  
macholib (1.1 or 1.2-dev) starts to analyze the executable in the AIR  
framework.

      [exec] copying /Developer/SDKs/flex3/runtimes/air/mac/Adobe  
AIR.framework/Adobe AIR -> /Users/thijstriemstra/Sites/software/rtmpy/ 
samples/branches/rtmpyapp-py2app/dist/RTMPyApp.app/Contents/Frameworks
      [exec] Traceback (most recent call last):
      [exec]   File "/Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/py2app-0.3.6-py2.5.egg/py2app/ 
build_app.py", line 548, in _run
      [exec]     self.run_normal()
      [exec]   File "/Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/py2app-0.3.6-py2.5.egg/py2app/ 
build_app.py", line 619, in run_normal
      [exec]     self.create_binaries(py_files, pkgdirs, extensions,  
loader_files)
      [exec]   File "/Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5/site-packages/py2app-0.3.6-py2.5.egg/py2app/ 
build_app.py", line 731, in create_binaries
      [exec]     mm.mm.run_file(fmwk)
      [exec]   File "/private/tmp/trunk/macholib/MachOGraph.py", line  
66, in run_file
      [exec]     m = self.createNode(MachO, pathname)
      [exec]   File "/private/tmp/trunk/macholib/MachOStandalone.py",  
line 23, in createNode
      [exec]     res = super(FilteredMachOGraph, self).createNode 
(cls, name)
      [exec]   File "build/bdist.macosx-10.3-fat/egg/altgraph/ 
ObjectGraph.py", line 148, in createNode
      [exec]     m = cls(name, *args, **kw)
      [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 61,  
in __init__
      [exec]     self.load(file(filename, 'rb'))
      [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 71,  
in load
      [exec]     self.load_fat(fh)
      [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 82,  
in load_fat
      [exec]     self.load_header(fh, arch.offset, arch.size)
      [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 106,  
in load_header
      [exec]     hdr = MachOHeader(self, fh, offset, size, magic,  
hdr, endian)
      [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 146,  
in __init__
      [exec]     self.load(fh)
      [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 178,  
in load
      [exec]     raise ValueError("Unknown load command: %d" %  
(cmd_load.cmd,))
      [exec] ValueError: Unknown load command: 27
      [exec] > /private/tmp/trunk/macholib/MachO.py(178)load()
      [exec] -> raise ValueError("Unknown load command: %d" %  
(cmd_load.cmd,))
      [exec] (Pdb)

The .app file is created but I'm not sure if it will work with this  
error.

This is how the setup.cfg looks like:
[py2app]
argv-emulation=1
argv-inject=server
optimize=2
plist=mac/Info.plist
includes=twisted
xref=1
debug-skip-macholib=0

Any ideas?

Regards,

Thijs


From vivacarlie at gmail.com  Thu Jun 28 06:57:47 2007
From: vivacarlie at gmail.com (Nehemiah Dacres)
Date: Thu, 28 Jun 2007 00:57:47 -0400
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
In-Reply-To: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
References: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
Message-ID: <65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>

sounds like another endianness problem, which architecture are u running?


      [exec]     hdr = MachOHeader(self, fh, offset, size, magic,
> hdr, endian)




>       [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 146,
> in __init__
>       [exec]     self.load(fh)
>       [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 178,
> in load
>       [exec]     raise ValueError("Unknown load command: %d" %
> (cmd_load.cmd,)) # and some bad exception handeling in my opinion. This
> should be encapsulated in a function call shouldn't it?
>       [exec] ValueError: Unknown load command: 27
>       [exec] > /private/tmp/trunk/macholib/MachO.py(178)load()
>       [exec] -> raise ValueError("Unknown load command: %d" %
> (cmd_load.cmd,))
>       [exec] (Pdb)
>
-- 

"lalalalala! it's not broken because I can use it"

http://linux.slashdot.org/comments.pl?sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070628/d6c75800/attachment.html 

From lists at collab.nl  Thu Jun 28 15:03:40 2007
From: lists at collab.nl (Thijs Triemstra|Collab)
Date: Thu, 28 Jun 2007 15:03:40 +0200
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
In-Reply-To: <65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>
References: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
	<65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>
Message-ID: <5D91ECB5-AD16-493D-B738-7939A36B28F9@collab.nl>

Hi Nehemiah,

thanks for your reply. I'm using an Intel Macbook Pro, osx 10.4.10  
with the trunk version of macholib. macholib isn't PPC only is it?

Thijs


On Jun 28, 2007, at 6:57 AM, Nehemiah Dacres wrote:

> sounds like another endianness problem, which architecture are u  
> running?
>
>
>       [exec]     hdr = MachOHeader(self, fh, offset, size, magic,
> hdr, endian)
>
>
>       [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 146,
> in __init__
>       [exec]     self.load(fh)
>       [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 178,
> in load
>       [exec]     raise ValueError("Unknown load command: %d" %
> (cmd_load.cmd,)) # and some bad exception handeling in my opinion.  
> This should be encapsulated in a function call shouldn't it?
>       [exec] ValueError: Unknown load command: 27
>       [exec] > /private/tmp/trunk/macholib/MachO.py(178)load()
>       [exec] -> raise ValueError("Unknown load command: %d" %
> (cmd_load. cmd,))
>       [exec] (Pdb)
> -- 
>
> "lalalalala! it's not broken because I can use it"
>
> http://linux.slashdot.org/comments.pl? 
> sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070628/1cd15409/attachment.html 

From ronaldoussoren at mac.com  Thu Jun 28 15:58:48 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 28 Jun 2007 15:58:48 +0200
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
In-Reply-To: <5D91ECB5-AD16-493D-B738-7939A36B28F9@collab.nl>
References: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
	<65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>
	<5D91ECB5-AD16-493D-B738-7939A36B28F9@collab.nl>
Message-ID: <82A16237-24A6-4693-BA77-16309E85CE77@mac.com>


On 28 Jun, 2007, at 15:03, Thijs Triemstra|Collab wrote:

> Hi Nehemiah,
>
> thanks for your reply. I'm using an Intel Macbook Pro, osx 10.4.10  
> with the trunk version of macholib. macholib isn't PPC only is it?

Macholib is universal capable. It's problably a MachO loader command  
that isn't support yet. Do you have a link to the framework that  
doesn't work with macholib (assuming that it is freely available)?

Ronald

>
> Thijs
>
>
> On Jun 28, 2007, at 6:57 AM, Nehemiah Dacres wrote:
>
>> sounds like another endianness problem, which architecture are u  
>> running?
>>
>>
>>       [exec]     hdr = MachOHeader(self, fh, offset, size, magic,
>> hdr, endian)
>>
>>
>>       [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 146,
>> in __init__
>>       [exec]     self.load(fh)
>>       [exec]   File "/private/tmp/trunk/macholib/MachO.py", line 178,
>> in load
>>       [exec]     raise ValueError("Unknown load command: %d" %
>> (cmd_load.cmd,)) # and some bad exception handeling in my opinion.  
>> This should be encapsulated in a function call shouldn't it?
>>       [exec] ValueError: Unknown load command: 27
>>       [exec] > /private/tmp/trunk/macholib/MachO.py(178)load()
>>       [exec] -> raise ValueError("Unknown load command: %d" %
>> (cmd_load. cmd,))
>>       [exec] (Pdb)
>> -- 
>>
>> "lalalalala! it's not broken because I can use it"
>>
>> http://linux.slashdot.org/comments.pl? 
>> sid=194281&threshold=1&commentsort=0&mode=thread&cid=15927703
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070628/f7dfdb63/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070628/f7dfdb63/attachment.bin 

From lists at collab.nl  Thu Jun 28 16:23:06 2007
From: lists at collab.nl (Thijs Triemstra|Collab)
Date: Thu, 28 Jun 2007 16:23:06 +0200
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
In-Reply-To: <82A16237-24A6-4693-BA77-16309E85CE77@mac.com>
References: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
	<65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>
	<5D91ECB5-AD16-493D-B738-7939A36B28F9@collab.nl>
	<82A16237-24A6-4693-BA77-16309E85CE77@mac.com>
Message-ID: <BE5DE2AE-1E95-451B-8E0F-C8E4C2C9304F@collab.nl>

Hi Ronald,

>> thanks for your reply. I'm using an Intel Macbook Pro, osx 10.4.10  
>> with the trunk version of macholib. macholib isn't PPC only is it?
>
> Macholib is universal capable. It's problably a MachO loader  
> command that isn't support yet. Do you have a link to the framework  
> that doesn't work with macholib (assuming that it is freely  
> available)?

The framework is freely available but the source isn't (hopefully it  
will be in the future). You can download the framework from http:// 
labs.adobe.com/downloads/airsdk.html (it's in the /runtimes/air/mac  
folder).

Thanks!

Thijs



From telliott99 at mac.com  Sat Jun 30 17:04:37 2007
From: telliott99 at mac.com (Tom Elliott)
Date: Sat, 30 Jun 2007 11:04:37 -0400
Subject: [Pythonmac-SIG] loading bundles
Message-ID: <AD649796-8221-48BB-AED5-0B4F64510EE3@mac.com>

Hi,

I have a question about PyObjC.  I used XCode to build a bundle  
(written in Objective C) which I then placed in the resources  
directory of an XCode PyObjC application and added to that project.   
I build the application from the command line with either of these  
two lines:

/usr/local/bin/python setup.py py2app
/usr/local/bin/python setup.py py2app -A


With -A, when I load the bundle and look for the principal class it  
works fine:

self.threadBundle = NSBundle.bundleWithPath_('Threaded.bundle')
self.threadBundle.load()
principalClass = self.threadBundle.principalClass()


Without the -A flag, the bundle loads, but the last call returns  
None, and this fails also:

namedClass = self.threadBundle.classNamed_('threaded')


If I modify the info.plist of the Threaded.bundle to add this:
NSPrincipalClass = threaded

Now I can build the standalone app and it works.  What's the correct  
way to do this?

Thanks for any help.

Tom Elliott

From telliott99 at mac.com  Sat Jun 30 19:01:04 2007
From: telliott99 at mac.com (Tom Elliott)
Date: Sat, 30 Jun 2007 13:01:04 -0400
Subject: [Pythonmac-SIG]  loading bundles
Message-ID: <AB9D0DCD-613A-4DF3-A4D5-548243A095CB@mac.com>

my bad...

The Objective C project template can't know the name of the principal  
class when the project is set up, so naturally you have to edit the  
info.plist and add it later.  So then the miracle is that the code  
does work when called with the -A flag.  I guess that must be some  
py2app magic going on...

Tom Elliott

From lists at collab.nl  Sat Jun 30 23:11:16 2007
From: lists at collab.nl (Thijs Triemstra|Collab)
Date: Sat, 30 Jun 2007 23:11:16 +0200
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
In-Reply-To: <BE5DE2AE-1E95-451B-8E0F-C8E4C2C9304F@collab.nl>
References: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
	<65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>
	<5D91ECB5-AD16-493D-B738-7939A36B28F9@collab.nl>
	<82A16237-24A6-4693-BA77-16309E85CE77@mac.com>
	<BE5DE2AE-1E95-451B-8E0F-C8E4C2C9304F@collab.nl>
Message-ID: <98D61412-A6E2-49A2-A37E-58DDE1212E10@collab.nl>

Hi,

so I found out that Apple added a new load command in oct 2006 that  
macholib didn't have yet. I created a patch that fixes the problem  
that you can find here:
http://dev.collab.com/rtmpy/ticket/7

Thanks,

Thijs

On Jun 28, 2007, at 4:23 PM, Thijs Triemstra|Collab wrote:

> Hi Ronald,
>
>>> thanks for your reply. I'm using an Intel Macbook Pro, osx 10.4.10
>>> with the trunk version of macholib. macholib isn't PPC only is it?
>>
>> Macholib is universal capable. It's problably a MachO loader
>> command that isn't support yet. Do you have a link to the framework
>> that doesn't work with macholib (assuming that it is freely
>> available)?
>
> The framework is freely available but the source isn't (hopefully it
> will be in the future). You can download the framework from http://
> labs.adobe.com/downloads/airsdk.html (it's in the /runtimes/air/mac
> folder).
>
> Thanks!
>
> Thijs
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig


From bob at redivi.com  Sat Jun 30 23:20:29 2007
From: bob at redivi.com (Bob Ippolito)
Date: Sat, 30 Jun 2007 14:20:29 -0700
Subject: [Pythonmac-SIG] py2app and Adobe AIR problem
In-Reply-To: <98D61412-A6E2-49A2-A37E-58DDE1212E10@collab.nl>
References: <2B381AFC-7E8C-45C8-94DC-47FD93C27722@collab.nl>
	<65fadfc30706272157oad13533l763591f5adf9428@mail.gmail.com>
	<5D91ECB5-AD16-493D-B738-7939A36B28F9@collab.nl>
	<82A16237-24A6-4693-BA77-16309E85CE77@mac.com>
	<BE5DE2AE-1E95-451B-8E0F-C8E4C2C9304F@collab.nl>
	<98D61412-A6E2-49A2-A37E-58DDE1212E10@collab.nl>
Message-ID: <6a36e7290706301420m7982998dh62f2e8de585f014b@mail.gmail.com>

I just applied this patch to the trunk.

-bob

On 6/30/07, Thijs Triemstra | Collab <lists at collab.nl> wrote:
> Hi,
>
> so I found out that Apple added a new load command in oct 2006 that
> macholib didn't have yet. I created a patch that fixes the problem
> that you can find here:
> http://dev.collab.com/rtmpy/ticket/7
>
> Thanks,
>
> Thijs
>
> On Jun 28, 2007, at 4:23 PM, Thijs Triemstra|Collab wrote:
>
> > Hi Ronald,
> >
> >>> thanks for your reply. I'm using an Intel Macbook Pro, osx 10.4.10
> >>> with the trunk version of macholib. macholib isn't PPC only is it?
> >>
> >> Macholib is universal capable. It's problably a MachO loader
> >> command that isn't support yet. Do you have a link to the framework
> >> that doesn't work with macholib (assuming that it is freely
> >> available)?
> >
> > The framework is freely available but the source isn't (hopefully it
> > will be in the future). You can download the framework from http://
> > labs.adobe.com/downloads/airsdk.html (it's in the /runtimes/air/mac
> > folder).
> >
> > Thanks!
> >
> > Thijs
> >
> >
> > _______________________________________________
> > Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> > http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>