Re: [Pythonmac-SIG] Universal build launches as Intel on M1

[jack . jansen]

I can’t check right now (I don’t have a universal Python installed, just to 
separate intel and M1 pythons), but if you use Finder “Get Info” on the 
application bundle: does it show the “Open using Rosetta” checkbox?

If it does: ensure it is unchecked.
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



> On 28 Mar 2022, at 10:08, Aivar Annamaa  wrote:
> 
> Hi!
> 
> I have an app bundle, with embedded python.org <http://python.org/>'s 
> universal build of Python 3.10.2 framework and a Tkinter-based GUI 
> (https://github.com/thonny/thonny/releases/tag/v4.0.0b1 
> <https://github.com/thonny/thonny/releases/tag/v4.0.0b1>)
> 
> I've used IDLE's approach in the Info.plist, and the launcher script. 
> Functionally all is working fine, but a M1 user reported, that when opened 
> from Finder, the app is launched in "Intel" mode. When the launcher is 
> invoked in Terminal (/Applications/Thonny.app/Contents/MacOS/thonny), the app 
> gets run in AMD64 mode. I don't have a M1 myself, so I haven't reproduced it 
> myself.
> 
> The same user now said that latest IDLE (3.10.4) runs in AMD64 mode even when 
> launched from Finder.
> 
> Any ideas what to check or try in order to make my app run in native mode?
> 
> My launcher script template is here: 
> https://github.com/thonny/thonny/blob/master/packaging/mac/Thonny.app.initial_template/Contents/MacOS/thonny
>  
> <https://github.com/thonny/thonny/blob/master/packaging/mac/Thonny.app.initial_template/Contents/MacOS/thonny>
>  (shebang becomes gets set to 
> .../Thonny.app/Contents/Frameworks/Python.framework/Versions/3.10/Resources/Python.app/Contents/MacOS/Python
>  by the postinstall script)
> 
> Info.plist template is here: 
> https://github.com/thonny/thonny/blob/master/packaging/mac/Thonny.app.initial_template/Contents/Info.plist
>  
> <https://github.com/thonny/thonny/blob/master/packaging/mac/Thonny.app.initial_template/Contents/Info.plist>
> 
> Best regards,
> Aivar
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

Re: [Pythonmac-SIG] Need M1 Mac to Test

[jack . jansen]

No worries, you can do Python development during the Intel->Arm transition. And 
then in umpteen years during the Arm->RiscV transition, and after that: who 
knows….

(And you probably weren’t born for the 68000->PowerPC transition)

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



> On 12 Jan 2022, at 23:56, Brian Herman  wrote:
> 
> I wish i was doing python development during the PowerPC->Intel transition.
> I was in high school and into macs but not python at the time.
> 
> 
> On Wed, Jan 12, 2022 at 4:48 PM  <mailto:jack.jan...@cwi.nl>> wrote:
> 
>> On 12 Jan 2022, at 22:54, Ned Deily > <mailto:n...@python.org>> wrote:
>>  In theory it is possible to select which architecture a multi-arch 
>> executable is to run under when there is more than one option by using the 
>> "arch" command, like here to force running in Intel emulation mode under 
>> Rosetta2 on an M1 Mac:
>> 
>> arch -x86_64 /path/to/python3{x}
>> 
>> But there is a big gotcha with that: if anything running under that 
>> non-default arch Python spins off another Python in a subprocess by using 
>> the value of sys.executable to find the running interpreter binary, the 
>> "arch -x86_64" is effectively lost and the interpreter in the subprocess 
>> will run in the default architecture. This happens, for instance, when 
>> running Python's own test suite: the top-level Python process running 
>> regrtest will be running in Intel emulation but tests running in 
>> subprocesses will still be running in the default arm64 arch, possibly 
>> giving errors or silently producing misleading results. Running the tests 
>> using python3{}-intel64 avoids that problem.
> 
> Yeah, that’s why I’m staying away from universal builds for now. Often I have 
> a situation where I run cmake which runs make which runs python to create a 
> venv and then somebody higher up will use that venv to create something using 
> “python" that something else will then use to build something against. The 
> chances of this working with “arch -x86_64” are slim, if that:-)
> 
> Looking at the timeline of the PowerPC->Intel transition I think most of the 
> problem will be solved in another year, because pretty much everything will 
> be available for arm natively.
> 
> --
> Jack Jansen, mailto:jack.jan...@cwi.nl>>, 
> http://www.cwi.nl/~jack <http://www.cwi.nl/~jack>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org 
> <mailto:Pythonmac-SIG@python.org>
> https://mail.python.org/mailman/listinfo/pythonmac-sig 
> <https://mail.python.org/mailman/listinfo/pythonmac-sig>
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG 
> <https://mail.python.org/mailman/options/Pythonmac-SIG>
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

Re: [Pythonmac-SIG] Need M1 Mac to Test

[jack . jansen]

> On 12 Jan 2022, at 22:54, Ned Deily  wrote:
>  In theory it is possible to select which architecture a multi-arch 
> executable is to run under when there is more than one option by using the 
> "arch" command, like here to force running in Intel emulation mode under 
> Rosetta2 on an M1 Mac:
> 
> arch -x86_64 /path/to/python3{x}
> 
> But there is a big gotcha with that: if anything running under that 
> non-default arch Python spins off another Python in a subprocess by using the 
> value of sys.executable to find the running interpreter binary, the "arch 
> -x86_64" is effectively lost and the interpreter in the subprocess will run 
> in the default architecture. This happens, for instance, when running 
> Python's own test suite: the top-level Python process running regrtest will 
> be running in Intel emulation but tests running in subprocesses will still be 
> running in the default arm64 arch, possibly giving errors or silently 
> producing misleading results. Running the tests using python3{}-intel64 
> avoids that problem.

Yeah, that’s why I’m staying away from universal builds for now. Often I have a 
situation where I run cmake which runs make which runs python to create a venv 
and then somebody higher up will use that venv to create something using 
“python" that something else will then use to build something against. The 
chances of this working with “arch -x86_64” are slim, if that:-)

Looking at the timeline of the PowerPC->Intel transition I think most of the 
problem will be solved in another year, because pretty much everything will be 
available for arm natively.

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



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

Re: [Pythonmac-SIG] Need M1 Mac to Test

[jack . jansen]

Python runs just fine natively on M1 Macs. The python.org <http://python.org/> 
installer will install a Universal2 binary (a single binary containing both the 
i386 and arm architectures).

If you install through brew you get the architecture your brew has been 
configured for.

But there _is_ a problem with native arm Python, and that is that not all 
extension packages (think: from pypi) have M1 versions available yet. This is 
especially true for packages that depend on external libraries (which may not 
have been ported to M1 yet).

The way I handle this on my (M1) development machine is that I have both 
versions of brew installed, which is easy because arm-brew installs into 
/opt/homebrew by default and intel-brew installs into /usr/local.

If I open a Terminal window it has /opt/homebrew/bin before /usr/local/bin in 
my $PATH, and the background is white.

If I open an iTerm window it runs in Rosetta intel emulation mode, it has 
/usr/local/bin before /opt/homebrew/bin, and the background is a creamy 
old-fashioned looking off-white color.

As long as I do builds in the window of the correct color, and the correct 
tools I need for building have been installed in the correct directory 
everything works fine.The white windows will use python3 for arm, the cream 
windows will use python3 for intel.
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



> On 12 Jan 2022, at 17:29, Brian Herman  wrote:
> 
> Do you guys need an M1 mac to test out the latest python?
> I have an extra macbook air m1 I would be willing to give people access to it 
> so they can test the latest python and compile things or I could do it 
> manually.
> My brother said you guys didn't have one yet.
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

Re: [Pythonmac-SIG] Error with mimetype on OS-X 11 (Big Sur)

[jack . jansen]

I googled the "file system relative paths not allowed in hardened programs” and 
the results made me remember a similar issue I have seen recently.

I was loading a dylib through ctypes, and suddenly this stopped working. The 
problem eventually turned out to be that another dylib (a dependency of the 
dylib I was loading) had its quarantine flag set. That was never a problem 
before, but suddenly (last summer?) it has started to be a problem.

The solution turned out to be to run `xattr -d com.apple.quarantine 
blablabla.dylib` on the problem library.

Not sure whether this is your problem or not, but it’s worth a shot. If (big 
if) this is a dynamic loader problem you’re in for a hard time: it used to be 
possible to debug these by setting the various DYLD_ environment variables to 
“look over the shoulder” of the dynamic loader to see what it is doing, but 
nowadays these environment variables are always cleared automatically (unless 
you have the com.apple.security.cs.allow-dyld-environment-variables 
entitlement, so if there’s a third party app somewhere in the chain that’s a 
no-no).
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



> On 6 Jan 2022, at 19:57, Chris Barker via Pythonmac-SIG 
>  wrote:
> 
> OK,
> 
> I've gotten a bit farther into debugging this.
> 
> Turns out it's not about that particular error, it's probably about the fact 
> that modules couldn't be loaded at start up due to security checks in the new 
> OS.
> 
> We've signed the app but that's not fixing it :-( 
> 
> Starting the app at the command line at least gets me output, and I see a lot 
> of errors like this:
> 
>   File "PyInstaller-3.4-py3.6.egg/PyInstaller/loader/pyiboot01_bootstrap.py", 
> line 149, in __init__
>   File "ctypes/__init__.py", line 348, in __init__
> OSError: dlopen(OpenGL, 10): no suitable image found.  Did find:
> file system relative paths not allowed in hardened programs
> 
> I am really confused as to how they could disallow relative paths -- how else 
> could you bundle a library?
> 
> though maybe it's a lib outside the bundle that's using relative paths ?
> 
> More digging needed, but if anyone has any ideas, I'm all ears.
> 
> Also:
> 
> - Has anyone gotten a PyInstaller App to work on OS-X 11 ?
> 
> - Even better, one that uses OpenGL?
> 
> Thanks,
> 
> -CHB
> 
> 
> 
> On Thu, Dec 16, 2021 at 11:21 AM Chris Barker  wrote:
> I've just got a new mac with OS-X 11.6 (still Intel).
> 
> But when I try to run a PyInstaller built application, I get this error:
> 
> No document available for {'mime': 'application/x-maproom-project-zip', 
> 'loader':  0x7f9669ce6e10>, 'uri': 'template://default_project.maproom'}
> 
> And the app won't start.
> 
> This has worked just fine on numerous previous OS-X versions.
> 
> I have the source code, but the developer that built it is no longer with us, 
> so it'll take b e a bit to get up to speed, and I don't even know where to 
> start! Is this a PyInstaller issue? or a code issue, or ???
> 
> Hints:
> 
> The application is called MapRoom (maproom) it works with "projects" that are 
> essentially a zip file with all the info required in it.
> 
> I think, on startup, it loads a empty default project, presumably 
> "default_project.maproom"
> 
> So I think that's where the app startup code is barfing, not having the mime 
> type registered properly. But where / how am I supposed to do that?
> 
> or maybe it's not a mime type registration issue, but simply that the 
> template can't be found -- so a path issue in the App bundle??
> 
> Anyway, I'll be digging into this deeper in the source code, but if anyone 
> has seen anything like this, any hints would be appreciated!
> 
> Thanks,
> 
> -CHB
> 
> 
> 
> 
> 
> 
> 
>  
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

Re: [Pythonmac-SIG] py2app fails to build PyQt5 apps anymore

[jack . jansen]

I think the man page for `code sign` is pretty clear (unlike the —help, 
indeed:-).

 --entitlements path
 When signing, take the file at the given path and embed its 
contents in the signature as
 entitlement data. If the data at path does not already begin with 
a suitable binary ("blob")
 header, one is attached automatically.
 When displaying a signature, extract any entitlement data from the 
signature and write it to the
 path given in an abstract representation. If needed --xml or --der 
may be passed in to output the
 entitlements in a desired format, if you pass in both then DER 
will be printed. Use "-" as the
 path to write to standard output.  If the signature has no 
entitlement data, nothing is written
 (this is not an error).

So I read that as: if you use the —entitlement option when displaying you 
supply a path here where the entitlement will be stored. And you can pass —xml 
or —der to specify how you want it to be stored.

And it seems to work. `codesign --display --entitlement - --xml 
/Applications/Xcode.app` gives me:

```
Executable=/Applications/Xcode.app/Contents/MacOS/Xcode
https://www.apple.com/DTDs/PropertyList-1.0.dtd;>com.apple.developer.mapscom.apple.sysmond.clientcom.apple.PairingManager.Readcom.apple.dt.simulator.clientcom.apple.PairingManager.Writecom.apple.authkit.client.privatecom.apple.PairingManager.RemovePeercom.apple.private.OAHSoftwareUpdatecom.apple.private.feedback.draftingcom.apple.springboard.debugapplicationscom.apple.private.corespotlight.internalcom.apple.runningboard.assertions.chronodcom.apple.developer.aps-environmentproductioncom.apple.corespotlight.privateindex.unsandboxedcom.apple.private.syspolicy.execution-policy-bypasscom.apple.private.tcc.allow-promptingkTCCServiceAllcom.apple.private.coreservices.definesExtensionPointcom.apple.application-identifier59GAB85EFG.com.apple.dt.Xcodecom.apple.private.dt.xcode.set-responsible-process-for-ui-testingcom.apple.private.AuthorizationServicescom.apple.trust-settings.admincom.apple.private.MobileContainerManager.lookupappDatapluginDatacom.apple.private.tcc.allowkTCCServiceAppleEventskTCCServicePhotoskTCCServiceDeveloperTool
```

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



> On 2 Jan 2022, at 14:02, Barry Scott  wrote:
> 
> 
> 
>> On 22 Dec 2021, at 23:36, jack.jan...@cwi.nl <mailto:jack.jan...@cwi.nl> 
>> wrote:
>> 
>> Hmm, my guess is that it fails when it fails when Qt tries to access the 
>> window manager (the `QtWidgets.QApplication( argv )` call). But why it would 
>> fail when built with pyinstaller and not with py2app I have absolutely no 
>> clue…
>> 
>> Could it be that a new entitlement or something was added by Apple for 
>> Monterey, maybe for accessing the window manager, and py2app doesn’t know 
>> about this? Anyone (Ronald, probably) have any idea?
> 
> I have been trying to check the entitlements that each version of the App has
> on the assumption that I could add any missing ones to the y2app version and
> see if that is indeed the issue.
> 
> But the Apple suggested command:
> 
> $ codesign --display --entitlements  tmp.pyinstaller/dist/gui_test.app
> Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # 
> sign
>codesign -v [-v*] [-R=|-R ] path|[+]pid ... 
> # verify
>codesign -d [options] path ... # display contents
>codesign -h pid ... # display hosting paths
> 
> As you see just prints its usage. man codesign is no more helpful.
> 
> Do you know what the  for the --entitlements option is should be?
> 
> There is talk of a entitlemts.plist but I do seem to have that file at all.
> 
> Barry
> 
> 
>> 
>> --
>> Jack Jansen, mailto:jack.jan...@cwi.nl>>, 
>> http://www.cwi.nl/~jack <http://www.cwi.nl/~jack>
>> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>> 
>> 
>> 
>>> On 21 Dec 2021, at 12:46, Barry Scott >> <mailto:ba...@barrys-emacs.org>> wrote:
>>> 
>>> For a long time I have been happily building my App bundles using py2app.
>>> At some point that stopped working. I do not have a record of exactly
>>> when. Last time I saw everything work was Feb 2021.
>>> 
>>> I have reduced the problem to a simple test program and scripts to
>>> build and run the test code to show the issue.
>>> 
>>> As a comparison I have py2app and pyinstaller versions of the tests.
>>> The pyinstaller version works and the py2app version fails.
>>> 
>>> The code is on git

Re: [Pythonmac-SIG] py2app fails to build PyQt5 apps anymore

[jack . jansen]

Hmm, my guess is that it fails when it fails when Qt tries to access the window 
manager (the `QtWidgets.QApplication( argv )` call). But why it would fail when 
built with pyinstaller and not with py2app I have absolutely no clue…

Could it be that a new entitlement or something was added by Apple for 
Monterey, maybe for accessing the window manager, and py2app doesn’t know about 
this? Anyone (Ronald, probably) have any idea?

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



> On 21 Dec 2021, at 12:46, Barry Scott  wrote:
> 
> For a long time I have been happily building my App bundles using py2app.
> At some point that stopped working. I do not have a record of exactly
> when. Last time I saw everything work was Feb 2021.
> 
> I have reduced the problem to a simple test program and scripts to
> build and run the test code to show the issue.
> 
> As a comparison I have py2app and pyinstaller versions of the tests.
> The pyinstaller version works and the py2app version fails.
> 
> The code is on github here:
> 
> https://github.com/barry-scott/scm-workbench/tree/master/Source/Experiments
> 
> Run ./build-py2app.sh to build and run the py2app version.
> Run ./build-pyinstaller.sh to build and runt he pyinstaller version.
> 
> The scripts:
> 1. build a venv
> 2. run gui_test.py from the command line
> 3. build the app using py2app or pyinstaller
> 4. run the app.
> 
> I am using macOS 12.1 on Intel MacBook Pro (15-inch, 2016).
> Python 3.10.1 from python.org.
> 
> The gui_test.py code logs to ~/gui_test.log at key points.
> 
> Here is the source:
> 
> 
> #!/usr/bin/env python
> import sys
> import os
> 
> log_filename = '%s/gui_test.log' % (os.environ['HOME'],)
> sys.stdout = open( log_filename, 'a' )
> sys.stderr = sys.stdout
> print(' gui_test.py ', flush=True)
> 
> from PyQt5 import QtCore, QtWidgets
> from PyQt5.QtWidgets import QMainWindow, QLabel, QGridLayout, QWidget
> from PyQt5.QtCore import QSize
> 
> class HelloWindow(QMainWindow): 
>def __init__( self ):
>super().__init__()
> 
>if sys.maxsize > (2**31):
>size_int_t = 64
>else:
>size_int_t = 32
> 
>py_ver = '%d.%d-%d' % (sys.version_info.major, sys.version_info.minor, 
> size_int_t)
> 
>self.setMinimumSize( QSize(350, 100) )
>self.setWindowTitle( 'GUI test - python %s' % (py_ver,) )
> 
>self.setCentralWidget( QLabel( ' GUI test - python %s ' % (py_ver,), 
> self ) )
> 
> def main( argv ):
>print('QtWidgets.QApplication()', flush=True)
>app = QtWidgets.QApplication( argv )
> 
>print('HelloWindow()', flush=True)
>main_win = HelloWindow()
> 
>print('main_win.show()', flush=True)
>main_win.show()
> 
>print('app.exec_()', flush=True)
>rc = app.exec_()
> 
>print('rc', rc, flush=True)
>return rc
> 
> if __name__ == "__main__":
>sys.exit( main( sys.argv ) )
> 
> 
> On a successful run the log shows:
> 
>  gui_test.py 
> QtWidgets.QApplication()
> HelloWindow()
> main_win.show()
> app.exec_()
> rc 0
> 
> When it fails it shows:
> 
>  gui_test.py 
> QtWidgets.QApplication()
> 
> Here is the problem report that is generated:
> 
> REGION TYPESIZECOUNT (non-coalesced) 
> === ===  === 
> Activity Tracing   256K1 
> Kernel Alloc Once8K1 
> MALLOC   192.1M   30 
> MALLOC guard page   16K4 
> MALLOC_LARGE (reserved)128K1 reserved VM address 
> space (unallocated)
> MALLOC_NANO (reserved)   384.0M1 reserved VM address 
> space (unallocated)
> STACK GUARD   56.0M3 
> Stack 9232K3 
> VM_ALLOCATE   6156K9 
> __DATA17.4M  265 
> __DATA_CONST  10.9M  152 
> __DATA_DIRTY   492K   86 
> __FONT_DATA  4K1 
> __LINKEDIT   651.4M   26 
> __OBJC_RO 81.8M1 
> __OBJC_RW 3136K2 
> __TEXT   205.4M  280 
> __UNICODE  588K1 
> dyld private memory   1024K1 
> mapped file   28.3M2 
> shared memory  592K7 
> ===

Re: [Pythonmac-SIG] How to include or install a Python runtime in an AppleScript applet

[jack . jansen]

Another option would be that the AppleScript checks whether the correct Python 
is installed (or maybe one of several usable Pythons, for example the official 
Python 3.x installer or a brew installation) and use that if it is. And if no 
suitable Python is found it could redirect the user to a web page with 
instructions on how to install a compatible Python.

That is sort-of what Kevin suggests (Point users to a Python installation), but 
with a bit of automation added.

Jack


> On 2 Oct 2021, at 16:22, Kevin Walzer  wrote:
> 
> 
> On 9/28/21 1:12 AM, Vincentius Vincentius wrote:
>> 
>> Can anyone help me with advice on how to create and distribute a Python 
>> runtime (with my applet) ?
>> 
> Point your users to the installer for the Mac version of Python:
> 
> https://www.python.org/ftp/python/3.9.7/python-3.9.7-macosx10.9.pkg 
> 
> There is no simple way to embed a Python installation within an AppleScript 
> applet. If you're doing that, you might as well all the way and deploy your 
> script as a full Mac application with Python libraries bundled using a tool 
> like py2app. 
> 
> --Kevin 
> 
> -- 
> Kevin Walzer
> Code by Kevin
> http://www.codebykevin.com 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

Re: [Pythonmac-SIG] py2app: Can successfully create app with alias mode but version built for deployment returns an error message

[jack . jansen]

A quick guess: maybe pandas doesn’t like to be included into a py2app 
application in this way? I think `.pyx` files are Cython sources, and I think 
these need to be compiled on installation (which should have happend during 
py2app?).

When you google for “pandas py2app” you’ll find people reporting similar (but 
not identical) problems to what you report.

But note that some of the stuff google finds is very old, so use your common 
sense, the world may have changed a lot since the link was written.



> On 15 Jun 2021, at 23:37, Paul Fishback  wrote:
> 
> I'm using Python 3.9 on a Mac running Big Sur and am trying to create an app, 
> MyApplication.app, from a script using py2app. I'm following the process 
> outlined at https://py2app.readthedocs.io/en/latest/tutorial.html 
>  . The app itself uses 
> tkinter for creating a GUI. My setup file looks like the following, where 
> 'background.png' is an image that appears on the screen at program startup, 
> and 'pandas' and 'cmath' are included due to previous error messages:
> 
> from setuptools import setup
> 
> APP = ['MyApplication_6_14.py']
> DATA_FILES = []
> OPTIONS = {'resources':['background.png'],'packages': ['pandas','cmath']}
> 
> setup(
> app=APP,
> data_files=DATA_FILES,
> options={'py2app': OPTIONS},
> setup_requires=['py2app'],
> )
> I can create and run the application in alias mode, and no error messages 
> arise when I build for deployment. However, when I attempt to run the 
> deployed version from the command line via,
> 
> ./dist/MyApplication.app/Contents/MacOS/MyApplication
> 
> I receive a fairly lengthy error message below, where Python_May_2021 is the 
> file location:
> 
> fishbacp@fishbacpK0ML85 Python_May_2021 % 
> ./dist/MyApplication_6_15.app/Contents/MacOS/MyApplication_6_15
> Traceback (most recent call last):
>   File 
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/__boot__.py",
>  line 115, in 
> _run()
>   File 
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/__boot__.py",
>  line 84, in _run
> exec(compile(source, path, "exec"), globals(), globals())
>   File 
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/MyApplication_6_15.py",
>  line 6, in 
> import pandas as pd
>   File 
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/lib/python3.9/pandas/__init__.py",
>  line 179, in 
> import pandas.testing
>   File 
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/lib/python3.9/pandas/testing.py",
>  line 5, in 
> from pandas._testing import (
>   File 
> "/Users/fishbacp/Desktop/Python_May_2021/dist/MyApplication_6_15.app/Contents/Resources/lib/python3.9/pandas/_testing.py",
>  line 29, in 
> import pandas._libs.testing as _testing
>   File "pandas/_libs/testing.pyx", line 1, in init pandas._libs.testing
> ValueError: source code string cannot contain null bytes
> 
> I'm curious to know if anyone has insights regarding the last line in the 
> above message.
> 
> Thanks
> 
> PaulF
> -- 
> Professor of Mathematics, Grand Valley State University 
> Past-President, Pi Mu Epsilon National Honorary Mathematics Society, Inc.
> 
> Department of Mathematics (MAK C-2-408)
> Grand Valley State University
> 1 Campus Dr.
> Allendale, MI 49401
> fishb...@mail.gvsu.edu 
> 616.331.2040
> 616.331.3120 (fax)
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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

Re: [Pythonmac-SIG] "pythonw" in a Unix build

[Jack Jansen]

Christopher,
it still isn't clear to me _why_ you wouldn’t want to use a framework build…

The whole exercise feels a bit like discussions from 15 years ago, with Unix 
wizards who wanted MacOS to behave as if it was plain vanilla Unix without all 
the things Apple changed. And that is much less true today than it was then… 

Jack

> On  18-Jan-2021, at 18:38 , Christopher Barker  wrote:
> 
> On Mon, Jan 18, 2021 at 1:34 AM Ronald Oussoren  <mailto:ronaldousso...@mac.com>> wrote:
> As mentioned on python-dev adding the “pythonw” functionality to the unix 
> build is not very hard. I expect that integrating with the build system 
> (Makefile/configure script) will be the hardest part due to introducing 
> different behaviour for the macOS platform. 
> 
> Thanks Ronald, that confirms my suspicions that this is really an autoconf 
> issue. Which makes it an utter mystery to me :-(
>> And we already have a work around in the core python code, it's just that 
>> the build system needs to be set up to build it outside of a Framework.
> The framework build does not have a workaround for these problems, it has a 
> proper solution ;-). 
> 
> Glad to hear that -- in earlier conversations, I got the impression that you 
> thought the executable wrapper was kind of a hack :-).
> 
> Anyway -- if any of you have autoconf expertise and the inclination, I'd love 
> to see this get done, and would be glad to help as best I can.
> 
> -CHB
>  
> -- 
> Christopher Barker, PhD (Chris)
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython

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



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

Re: [Pythonmac-SIG] "pythonw" in a Unix build

[Jack Jansen]

I’m not sure there is a point anymore?

For example, the brew Python is installed into a framework tucked away deep in 
/usr/local/Cellar but you don’t notice this at all: you can just use “python 
foo.py” and the moment the script does GUI calls it’ll get an icon in the doc 
and all that.

What problem are you trying to solve?

Jack

> On  14-Jan-2021, at 23:07 , Chris Barker via Pythonmac-SIG 
>  wrote:
> 
> Ned suggested I bring this conversation over here from python-dev, so here it 
> is.
> 
> What I'd like to see done is have the "pythonw" wrapper buildable in an 
> otherwise non-framework build.
> 
> I *think* there are no real technical show stoppers, but it would take some 
> auto-conf magic, which I am fully unqualified to take on.
> 
> Anyone interested in helping make this happen ?
> 
> -CHB
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
> 
> chris.bar...@noaa.gov 
> <mailto:chris.bar...@noaa.gov>___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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



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

Re: [Pythonmac-SIG] Using Python on Mac

[Jack Jansen]

Guido,
if I googled correctly that “Python and Arduino” series is from 2014. At that 
time there was something to be said for using Python 2.7, but in 2020 that is 
no longer true. And, actually, since Python 2.7 has finally been moved to 
end-of-life last year many tutorials that refer to Python 2.7 specifically will 
stop to work (as you have found out).

Your best bet is to ignore all the version numbers Paul McWorther mentions in 
his tutorial, and try to download the latest version of everything. See how far 
that gets you.

You’re not the first one to run into this problem, as you can see from the 
comments under the video, but unfortunately none of the people that came across 
the Python 2.7 issues added comments saying what they had to do to run the 
tutorial in 2020. If you get it to work: maybe add a comment to the video to 
say what you had to change to make it work?

And feel free to post problems here,

Jack

> On  29-Dec-2020, at 19:29 , Guido Deboeck  wrote:
> 
> In Lesson 2 of Python and Arduino by Paul McWhorter he suggest downloading 
> Python 2.7 rather than the more recent version 3.x. He also suggests to 
> download pyserial 2.7 as well as vPhython. I have search for pyserial 2.7 and 
> have not been able to find it on the web As to vPhython I found PyCharm, but 
> that is not for free. Could you pls help me to find pyserial 2.7 as well as 
> vPhython for use on a Mac. Thank you.
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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



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

[Pythonmac-SIG] Apple Silicon, anyone?

[Jack Jansen]

Is anyone planning to track the Apple Silicon stuff and/or get a developer 
system, and see what needs to be done for Python?

I can help out, if wanted, but I won’t be trying to get a developer system 
myself because I won’t be able to spend a lot of time.
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



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

Re: [Pythonmac-SIG] Building plans .....

[Jack Jansen]

> 
> but "conda" is a package management tool, a bit like yum or apt in the Linux 
> world, or Brew, for that matter. except that:
> 
> * It is platform independent -- it attempts to work the same way on all all 
> platforms to the degree possible.
> * It provides management of isolated "environments", so you can have a 
> different collection of software and libraries, all with a different 
> combination of version on the same system, isolated from one another.


So how does conda handle things that must be installed in “special” locations 
on some platforms? For example, if you install some package that contains a 
kernel driver, undoubtedly on windows this’ll have to go somewhere deep down in 
c:\system32 or something.

Because in a way Python on the mac (if you want to use a framework/app/bundle 
Python) is like that: it has some platform-specific installation requirements 
(that bits of it go into /Library/Frameworks and other bits in /Application), 
and in the end you setup a few symlinks in the conda bin directory (or the 
conda per-environment bin directory, or however that works) and for a conda 
user the situation will be exactly the same on Mac as on Linux…..
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



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

Re: [Pythonmac-SIG] Building plans .....

[Jack Jansen]

orge/python-feedstock/issues/23>).
> 
> But I'll turn around the question: "What is the problem with using a 
> non-framework build for conda on the Mac" (or even outside of conda, e.g.brew 
> or macports)
> 
> It's unclear to me is what the advantages of a Framework Build are in this 
> context. Other than it being the "Mac way of doing things". It's my 
> impression that Apple simply has not thought out how it should support things 
> like Python -- the whole system is very much designed around "Applications", 
> but the Python interpreter is not an application in the usual sense. But it 
> is also not a library in the usual sense, either. So I'm not sure there IS an 
> obvious right way to support Python on a a Mac.
> 
> And I understand the idea behind frameworks, and like them. I've never much 
> liked the scattering of things all over the filesystem approach that *nix 
> usually does. But in this case, conda is doing a similar thing, but in a more 
> powerful and flexible way. So cramming a Framework into conda seems 
> gratuitous.
> 
> As far as I know, the only issue people have had with using a standard Unix 
> build in conda is the whole GUI thing.Jack mentioned a lot of others, 
> essentially interacting the the non-kernel part of the OS, but I haven't 
> heard complaints about that -- maybe because no one's doing that with conda.
> 
> But the key technical question I'm still not totally clear on is:
> 
> I understand (vaguely) what having Python running from a App bundle provides 
> -- and these are important features, so we do want to support that.
> 
> And I I thought that the executable re-directs to one in a bundle could be 
> done independently of the Framework, and the fact that the two is essentially 
> and accident of how they build scripts were set up (and probably easier to 
> do). If I'm correct, then Python could be built to provide an app bundle, but 
> otherwise be just like a "normal" unix build.
> 
> But what does having Python built as a Framework actually provide, other than 
> making more like the usual Mac setup? As far as I can tell, it would provide 
> no new functionality. In which case, given a choice, for, e.g. a conda build, 
> I'd rather have it be more like the other *nixes than more like other Mac 
> software.
> 
> In short: as far as I can tell, the only reason to use a Framework build in 
> conda is that it's the only configuration that's already set up to make 
> pythonw in the build scripts, and autoconf is enough of a pain that one wants 
> to make a new configuration.
> 
> By the way, I chatted with Ned Diely a few years ago about this, and I think 
> he was thinking of moving away form Frameworks for python.org 
> <http://python.org/> builds, though I don't know if he decided not to make 
> that change, or simply hasn't gotten around to it.
> 
> -CHB
> 
> References to Discussions:
> 
> https://github.com/conda-forge/python-feedstock/issues/23 
> <https://github.com/conda-forge/python-feedstock/issues/23>
> 
> 
> 
> 
> 
> Jack
> 
>> On  14-Mar-2020, at 14:54 , Ronald Oussoren > <mailto:ronaldousso...@mac.com>> wrote:
>> 
>> 
>> 
>>> On 13 Mar 2020, at 20:36, Christopher Barker >> <mailto:python...@gmail.com>> wrote:
>>> 
>>> There is a private API that makes it possible to use GUI libraries outside 
>>> of an app bundle and that’s used by a number of projects, but I wouldn’t 
>>> want to use that in Python.
>>> 
>>> Is that what TK is doing? 
>> 
>> I don’t know.
>>> 
>>> And while probably not good to build it into Python itself, what about 
>>> building into the GUI toolkits? 
>>> 
>>> Do you have a reference to that API?
>> 
>> I don’t have a reference handy, it has come up before either on this list or 
>> the python tracker (years back). IIRC someone found the API by checking how 
>> the bundled java VM managed to use GUI APIs without being in an app bundle.
>> 
>> Apple is clearly preferring application code packaged as app bundles, and 
>> effectively doesn’t care about traditional Unix-y use of macOS. The need for 
>> an app bundle when using frameworks is just one example of that. Another 
>> example are the issues that keep popping up when trying to use Apple 
>> frameworks in child processes after calling os.fork(). 
>> 
>> Because of this I don’t think it is worthwhile to try to work around this 
>> limitation by calling private APIs. That’s even before considering use cases 
>> that involve distributing code through the

Re: [Pythonmac-SIG] Building plans .....

[Jack Jansen]

I’m having an incredible amount of deja-vu in this conversation. We seem to be 
heading down the path of talking about little-documented APIs and such the same 
way we were doing 15 or 18 years ago….

Christopher,
can you explain what the problem is that you’re running into? Why is there a 
problem with the Mac Python builds having a different structure than other Unix 
Python builds? Windows Python builds also have a different structure, does the 
problem occur there as well?

From your original post it seems that the problems are with the 
Anaconda/Conda-forge distribution treating MacOS as “just another unix 
distribution”, with the idea that “Mac GUI compatibility” wouldn’t be too 
important for the Anaconda users, or could be handled with the pythonw 
workaround shellscript.

But actually “MacOS-compatible” would be a more accurate term here, because I’m 
pretty sure there are a whole lot of APIs that have nothing to do with the GUI 
but won’t work unless you’re running from a bundle: definitely Open Scripting, 
but probably also audio/video capture, probably anything using keychain like 
crypto serveices, maybe bluetooth, maybe USB, probably anything using the GPU 
for computations….. 

So basically if you build Python for MacOS as if it is “just another BSD 
distribution” then that is indeed what you get: a Python for just another BSD 
distribution.

Hmm, that was a long sentence for what was intended to be the question: “What 
is the problem with using a normal MacOS Framework build of Python for 
Anaconda”?

Jack

> On  14-Mar-2020, at 14:54 , Ronald Oussoren  wrote:
> 
> 
> 
>> On 13 Mar 2020, at 20:36, Christopher Barker > <mailto:python...@gmail.com>> wrote:
>> 
>> There is a private API that makes it possible to use GUI libraries outside 
>> of an app bundle and that’s used by a number of projects, but I wouldn’t 
>> want to use that in Python.
>> 
>> Is that what TK is doing? 
> 
> I don’t know.
>> 
>> And while probably not good to build it into Python itself, what about 
>> building into the GUI toolkits? 
>> 
>> Do you have a reference to that API?
> 
> I don’t have a reference handy, it has come up before either on this list or 
> the python tracker (years back). IIRC someone found the API by checking how 
> the bundled java VM managed to use GUI APIs without being in an app bundle.
> 
> Apple is clearly preferring application code packaged as app bundles, and 
> effectively doesn’t care about traditional Unix-y use of macOS. The need for 
> an app bundle when using frameworks is just one example of that. Another 
> example are the issues that keep popping up when trying to use Apple 
> frameworks in child processes after calling os.fork(). 
> 
> Because of this I don’t think it is worthwhile to try to work around this 
> limitation by calling private APIs. That’s even before considering use cases 
> that involve distributing code through the macOS app store.
> 
> Ronald
> —
> 
> Twitter: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/>

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



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

Re: [Pythonmac-SIG] Building plans .....

[Jack Jansen]

bit anymore? Do we 
> need Universal builds anymore? Should we abandon the Framework build option 
> altogether?
> 
> My proposal: Add a build option that builds Intel, 64bit, fairly recent SDK, 
> and the pythonw hack, into an otherwise "standard" unix-like build. 
> 
> Then that could become the default OS-X build in the future, exactly when TBD.
> 
> The problem is that I *really* don't have the autoconf skills to do that!
> 
> But I'm hoping with some prodding and show of support, someone with take it 
> on :-)
> 
> -CHB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Christopher Barker, PhD
> 
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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



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

Re: [Pythonmac-SIG] Problems with the pythonmac-sig mailing list

[Jack Jansen]

Well, turns out the problem isn’t with the whole list, it’s just with that 
Criollo thread. Apparently the messages in that thread have gotten so big 
(>40K) because of all the code fragments and topquoting.

So nothing to worry about.

Jack

> On  09-Jan-2020, at 00:16 , Jack Jansen  wrote:
> 
> Folks,
> as of yesterday every posting to the list is held for approval. I’ve asked 
> the mailman maintainers what could be going on.
> 
> I the mean time I’ll approve all posts as quickly as possible, but I trust 
> you understand that I’m not sitting here waiting to approve things 24 hours a 
> day, so things may be a bit slow:-)
> --
> Jack Jansen, , http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
> 
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

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



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

[Pythonmac-SIG] Problems with the pythonmac-sig mailing list

[Jack Jansen]

Folks,
as of yesterday every posting to the list is held for approval. I’ve asked the 
mailman maintainers what could be going on.

I the mean time I’ll approve all posts as quickly as possible, but I trust you 
understand that I’m not sitting here waiting to approve things 24 hours a day, 
so things may be a bit slow:-)
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



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

Re: [Pythonmac-SIG] Tkinter and PyObjC

[Jack Jansen]

From memory (and cobwebbed memory, at that:-) I recall that I never got Tkinter 
and Cocoa to work together. The runloops got into each others’ ways. Similar 
for other GUI toolkits (Gtk, for example).

I did (with lots of pulling of hairs and gnashing of teeth) get Cocoa GUI to 
work together with other NSFoundation stuff (as long as it didn’t touch the 
gui) by giving it a runloop in a different thread.

But: this was about 6 years ago, things may have progressed since then…

Jack

> On  06-Sep-2017, at 22:57 , Ronald Oussoren <ronaldousso...@mac.com> wrote:
> 
> Hi,
> 
> I’m kind of hoping that a Tkinter or Tk expert is reading this…
> 
> A PyObjC user tries to call Tkinter from a Cocoa program (that is, the Cocoa 
> runloop starts before the Tkinter one) and gets an error message:
> 
>-[NSApplication _setup:]: unrecognized selector sent to instance
> 
> Furthermore the Tkinter GUI doesn’t work. PyObjC’s issue about this: 
> 
>
> https://bitbucket.org/ronaldoussoren/pyobjc/issues/201/tkinter-method-tk-failed-with-error
> 
> I’ve done some quick browsing of the Tk source code and it appears that Tk 
> assumes that -[NSApplication sharedApplication] returns an instance of a 
> Tk-specific private subclass of NSApplication and that won’t be true when the 
> Tk runloop is started before the Cocoa one.
> 
> My question: is my analysis correct? And has anyone successfully mixed PyObjC 
> and Tkinter in this way? I guess this issue could be avoided by initialising 
> Tk before calling into Cocoa.
> 
> Ronald
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Uninstalling

[Jack Jansen]

I think the /usr/bin/python executable you’re seeing is the Apple-supplied one.

Here’s what I have in /usr/bin, which is all from Apple:

$ ls -l /usr/bin/pyth*
-rwxr-xr-x  1 root  wheel  66576 Apr 29 02:29 /usr/bin/python
-rwxr-xr-x  5 root  wheel925 Jul 31  2016 /usr/bin/python-config
lrwxr-xr-x  1 root  wheel 75 Jun 22 13:26 /usr/bin/python2.6 -> 
../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6
lrwxr-xr-x  1 root  wheel 82 Jun 22 13:26 /usr/bin/python2.6-config -> 
../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-config
lrwxr-xr-x  1 root  wheel 75 Jun 22 13:26 /usr/bin/python2.7 -> 
../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x  1 root  wheel 82 Jun 22 13:26 /usr/bin/python2.7-config -> 
../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
-rwxr-xr-x  1 root  wheel  66576 Apr 29 02:30 /usr/bin/pythonw
lrwxr-xr-x  1 root  wheel 76 Jun 22 13:26 /usr/bin/pythonw2.6 -> 
../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/pythonw2.6
lrwxr-xr-x  1 root  wheel 76 Jun 22 13:26 /usr/bin/pythonw2.7 -> 
../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
$

Homebrew puts everything in /usr/local/bin, and I think so does the official 
Python Mac installer (it did when I was still responsible for it:-).


> On 18 Jul 2017, at 21:37, Pito Salas <pitosa...@brandeis.edu> wrote:
> 
> I’m new to Python. I seem to have three partially installed Pythons on my Mac 
> Sierra.
> 
> One from Apple
> One from Homebrew
> And one from the Python Mac installer
> 
> In particular, for example, I have a python executable in /usr/bin:
> 
> $ which python
> /usr/bin/python
> 
> This is an actual executable not a symkink. There are a whole bunch of python 
> related files in that directory:
> 
> python   python-configpython2.6python2.6-config python2.7 
>python2.7-config pythonw  pythonw2.6   pythonw2.7
> 
> 
> I think they all came from the python.org python installer.
> 
> I would like to fully uninstall the Python (and related files) that I got 
> from the Mac Python Installer from the python web site. I can’t find up to 
> date instructions. 
> 
> Does anyone know how to do this? Thanks!
> 
> Pito Salas
> 
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] py2app .app crashes... but only when downloaded (quarantine)

[Jack Jansen]

0x7fff8b424e75 CFRunLoopRunSpecific 
> + 309
> 20  com.apple.HIToolbox   0x7fff92fa5a0d 
> RunCurrentEventLoopInMode + 226
> 21  com.apple.HIToolbox   0x7fff92fa57b7 
> ReceiveNextEventCommon + 479
> 22  com.apple.HIToolbox   0x7fff92fa55bc 
> _BlockUntilNextEventMatchingListInModeWithFilter + 65
> 23  com.apple.AppKit  0x7fff9020a24e _DPSNextEvent + 1434
> 24  com.apple.AppKit  0x7fff9020989b -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> 25  Tk0x000102bdba2a 0x102b25000 + 748074
> 26  com.apple.AppKit  0x7fff90568e2e -[NSApplication 
> _realDoModalLoop:peek:] + 642
> 27  com.apple.AppKit  0x7fff9056754e -[NSApplication 
> runModalForWindow:] + 117
> 28  com.apple.AppKit  0x7fff905978a2 
> _NXDoLocalRunAlertPanel + 427
> 29  com.apple.AppKit  0x7fff905976df NSRunAlertPanel + 157
> 30  com.myotisoft.transect0x00014009 0x1 + 16393
> 31  com.myotisoft.transect0x000113ff main + 1375
> 32  com.myotisoft.transect0x00010ce4 start + 52
> 
> Thread 1:
> 0   libsystem_kernel.dylib0x7fff8ccd6e6a __workq_kernreturn + 
> 10
> 1   libsystem_pthread.dylib   0x7fff8d4b3f08 _pthread_wqthread + 
> 330
> 2   libsystem_pthread.dylib   0x7fff8d4b6fb9 start_wqthread + 13
> 
> Thread 2:: Dispatch queue: com.apple.libdispatch-manager
> 0   libsystem_kernel.dylib0x7fff8ccd7662 kevent64 + 10
> 1   libdispatch.dylib 0x7fff92ce1421 _dispatch_mgr_invoke 
> + 239
> 2   libdispatch.dylib 0x7fff92ce1136 _dispatch_mgr_thread 
> + 52
> 
> Thread 3:
> 0   libsystem_kernel.dylib0x7fff8ccd6e6a __workq_kernreturn + 
> 10
> 1   libsystem_pthread.dylib   0x7fff8d4b3f08 _pthread_wqthread + 
> 330
> 2   libsystem_pthread.dylib   0x7fff8d4b6fb9 start_wqthread + 13
> 
> Thread 4:
> 0   libsystem_kernel.dylib0x7fff8ccd6e6a __workq_kernreturn + 
> 10
> 1   libsystem_pthread.dylib   0x7fff8d4b3f08 _pthread_wqthread + 
> 330
> 2   libsystem_pthread.dylib   0x7fff8d4b6fb9 start_wqthread + 13
> 
> Thread 5:
> 0   libsystem_kernel.dylib0x7fff8ccd6e6a __workq_kernreturn + 
> 10
> 1   libsystem_pthread.dylib   0x7fff8d4b3f08 _pthread_wqthread + 
> 330
> 2   libsystem_pthread.dylib   0x7fff8d4b6fb9 start_wqthread + 13
> 
> Thread 6:
> 0   libsystem_kernel.dylib0x7fff8ccd69aa __select + 10
> 1   Tcl   0x000102ae77e9 0x102a4 + 686057
> 2   libsystem_pthread.dylib   0x7fff8d4b2899 _pthread_body + 138
> 3   libsystem_pthread.dylib   0x7fff8d4b272a _pthread_start + 137
> 4   libsystem_pthread.dylib   0x7fff8d4b6fc9 thread_start + 13
> 
> Thread 7:: com.apple.appkit-heartbeat
> 0   libsystem_kernel.dylib0x7fff8ccd6a3a __semwait_signal + 10
> 1   libsystem_c.dylib 0x7fff89b23dc0 nanosleep + 200
> 2   libsystem_c.dylib 0x7fff89b23cb2 usleep + 54
> 3   com.apple.AppKit  0x7fff9046e17d -[NSUIHeartBeat 
> _heartBeatThread:] + 2132
> 4   com.apple.Foundation  0x7fff93f0cdfb __NSThread__main__ + 
> 1318
> 5   libsystem_pthread.dylib   0x7fff8d4b2899 _pthread_body + 138
> 6   libsystem_pthread.dylib   0x7fff8d4b272a _pthread_start + 137
> 7   libsystem_pthread.dylib   0x7fff8d4b6fc9 thread_start + 13
> 
> Thread 0 crashed with X86 Thread State (64-bit):
>   rax: 0x  rbx: 0x7fff7a160310  rcx: 0x7fff5fbfb7b8  
> rdx: 0x
>   rdi: 0x0707  rsi: 0x0006  rbp: 0x7fff5fbfb7e0  
> rsp: 0x7fff5fbfb7b8
>r8: 0x0040   r9: 0x7fff5fbfb700  r10: 0x0800  
> r11: 0x0206
>   r12: 0x  r13: 0x0001  r14: 0x0006  
> r15: 0x0001031516a0
>   rip: 0x7fff8ccd6866  rfl: 0x0206  cr2: 0x000107e22100
>   
> Logical CPU: 0
> Error Code:  0x02000148
> Trap Number: 133
> 
> 
> 
> -- 
> David A. Riggs <david.a.ri...@gmail.com>
> 
>  1.1.4_2017-01-26-215534_Davids-MacBook-Pro.crash>___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] apple-Python and TLS 1.0

[Jack Jansen]

Ok, so this is a real problem:-(

Again, I’m not deep enough into the SSL stuff to really understand this (and 
specifically whether it needs a new openssl module, a new libssl, both, 
something else, ….), but I’d like to think of ways to fix this before the shit 
hits the fan for all poor mac Python users out there, if possible. And that 
includes people who aren’t even aware they’re macPython users because they use 
some app that uses Python under the hood…..

So a couple of questions:

1. Is this fixable by Apple, by providing a security update to various OSX 
versions that would include a newer python/libssl/whatever? 
1a. Would this still fall under Apple’s idea of “security update”?
1b. Do we have any chance of making Apple interested in fixing this?

2. Is this fixable with an installer that would somehow override the openssl 
module, so that installing this one thing would make the whole Apple-Python 
installation work again?

3. Failing that, I assume its the end of the line for Apple-Python, and we’ll 
have to steer end users towards installing a python.org version. Right?
3a. If that’s the case, is there something we could ask of the pip developers, 
the PyPi maintainers, whoever else to help the poor end users? I.e. get them to 
release a version that would not say “ssl v1 invalid foobar get lost” but in 
stead “you appear to be using Apple Python which does not support current 
security measures, please see www.example.com for more information”.

Actually, question 3a to some extent also is 2a.

Regards,
Jack


> On 10 Jan 2017, at 20:54, Ronald Oussoren <ronaldousso...@mac.com> wrote:
> 
> 
>> On 10 Jan 2017, at 20:43, Ronald Oussoren <ronaldousso...@mac.com> wrote:
>> 
>> 
>>> On 10 Jan 2017, at 17:05, Jack Jansen <jack.jan...@cwi.nl> wrote:
>>> 
>>> I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate 
>>> until know, but just now the following post came in on python-announce, 
>>> which seems to suggest that TLS 1.0 is really about to be phased out: 
>>> https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html
>>> 
>>> I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped 
>>> Pythons) don’t support TLS 1.2 by default, which would seem to suggest that 
>>> things like pip will stop working as of this summer.
>>> 
>>> Or am I overreacting?
>> 
>> You are not. Annoyingly Donald Stufft already noticed that Apple’s Python is 
>> problematic, but breaking for users on a major OS is apparently not a 
>> problem :-(
> 
> Breaking Python tools is probably not really on Fastly’s radar and not 
> something that the PyPI folks can easily avoid.
> 
>> 
>> This shouldn’t be a problem for most serious development as those users 
>> likely use a separate python installation anyway, but this will affect 
>> casual users including at least some new users. 
> 
> BTW. This doesn’t just break /usr/bin/python but also the Python.org 
> installation of 2.7 (including 2.7.13), and likely any Python.org install 
> exception 3.6 as  all installers upto 3.6 use the system OpenSSL that doesn’t 
> support anything beyond TLS 1.0.
> 
> Ronald
> 

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] apple-Python and TLS 1.0

[Jack Jansen]

I have completely ignored this whole TLS 1.0 versus TLS 1.2 security debate 
until know, but just now the following post came in on python-announce, which 
seems to suggest that TLS 1.0 is really about to be phased out: 
https://mail.python.org/pipermail/python-announce-list/2017-January/011437.html

I think Python 2.7 older that 2.7.13 (i.e. including the apple-shipped Pythons) 
don’t support TLS 1.2 by default, which would seem to suggest that things like 
pip will stop working as of this summer.

Or am I overreacting?
--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Jack Jansen]

It’s hardcoded in the Python executable, I’m afraid:-(

Just tried “python -s -S -v”, and the Extras/lib/python is still in sys.path.

That wasn’t a very smart move by the Apple engineers, I guess….

What you could do (but this is getting rather hacky) is create a 
/Library/Python/2.7/site-packages/removeSystemExtras.pth where you import sys 
and manually remove the Extras entries. Be careful, putting code (as opposed to 
pathnames) into a .pth file requires the line to start with “import “.

Jack

> On  13-Sep-2016, at 23:37 , Andrew Jaffe <a.h.ja...@gmail.com> wrote:
> 
> Hi,
> 
> 
>> On 13 Sep 2016, at 22:26, Jack Jansen <jack.jan...@cwi.nl> wrote:
>> 
>> You’re absolutely right (both on SIP and on 
>> /Library/Frameworks/Python.framework probably being a python.org install), 
>> sorry for the confusion.
>> 
>> This seems to be due to the way Apple has done the “Extras” directory, and 
>> adding things there to sys.path.
>> 
>> See for example https://github.com/pypa/pip/issues/2468
>> 
>> If you can get rid of 
>> /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python 
>> in sys.path you should be all set.
> 
> Thanks, guys.
> 
> Indeed, these /System/Library dirs are in sys.path:
> 
>In [1]: import sys
>In [2]: print [p for p in sys.path if 'System' in p]
>
> ['/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python',
>  
> '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC’]
> 
> But I’m still confused: why is this problem only showing up now? Is the same 
> setup that everyone has? Or is it just me for some reason? How and where 
> would sys.path be set to this, and how and where should I change it? (Without 
> disabling SIP, please!)
> 
> Andrew
> 
> 
> 
> 
> 
> 
> 
>>> On  13-Sep-2016, at 22:59 , Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
>>> 
>>> 
>>>> On Sep 13, 2016, at 12:05 PM, Jack Jansen <jack.jan...@cwi.nl> wrote:
>>>> 
>>>> I think 
>>>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>>>  is a very old location for storing Python packages. Recently things have 
>>>> been installed in /Library/Python/2.7/site-packages.
>>>> 
>>>> Could it be that you’ve installed pyobjc a couple of OSX releases ago?
>>> 
>>> This is always worth checking ;).  Particularly if it was a few Setuptools 
>>> releases ago.  Also worth checking: ~/Library/Python.
>>> 
>>>> And could it be that the OSX upgrade that introduced SIP somehow didn’t 
>>>> clean out user-installed things from /Library/Frameworks before turning 
>>>> off write permission?
>>> 
>>> SIP locks down /System, not /Library.
>>> 
>>>> A possible workaround is to turn off SIP (or boot from the recovery 
>>>> partition), record what is in 
>>>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>>>  and then clean it out. Then after a reboot re-install the packages you’re 
>>>> still using.
>>> 
>>> This should be an _absolute_ last resort, though.  You should be able to 
>>> clean out /Library just fine.  If you have a 
>>> /Library/Frameworks/Python.framework, that's probably Python.org python, 
>>> not system python.
>>> 
>>> -glyph
>> 
>> --
>> Jack Jansen, <jack.jan...@cwi.nl>, http://www.cwi.nl/~jack
>> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>> 
>> 
>> 
> 

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Jack Jansen]

You’re absolutely right (both on SIP and on 
/Library/Frameworks/Python.framework probably being a python.org install), 
sorry for the confusion.

This seems to be due to the way Apple has done the “Extras” directory, and 
adding things there to sys.path.

See for example https://github.com/pypa/pip/issues/2468

If you can get rid of 
/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python in 
sys.path you should be all set.

> On  13-Sep-2016, at 22:59 , Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
> 
> 
>> On Sep 13, 2016, at 12:05 PM, Jack Jansen <jack.jan...@cwi.nl> wrote:
>> 
>> I think 
>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>  is a very old location for storing Python packages. Recently things have 
>> been installed in /Library/Python/2.7/site-packages.
>> 
>> Could it be that you’ve installed pyobjc a couple of OSX releases ago?
> 
> This is always worth checking ;).  Particularly if it was a few Setuptools 
> releases ago.  Also worth checking: ~/Library/Python.
> 
>> And could it be that the OSX upgrade that introduced SIP somehow didn’t 
>> clean out user-installed things from /Library/Frameworks before turning off 
>> write permission?
> 
> SIP locks down /System, not /Library.
> 
>> A possible workaround is to turn off SIP (or boot from the recovery 
>> partition), record what is in 
>> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
>>  and then clean it out. Then after a reboot re-install the packages you’re 
>> still using.
> 
> This should be an _absolute_ last resort, though.  You should be able to 
> clean out /Library just fine.  If you have a 
> /Library/Frameworks/Python.framework, that's probably Python.org python, not 
> system python.
> 
> -glyph

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] PyObjC and macOS 10.12 (Sierra)

[Jack Jansen]

_path,
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_set.py",
>  line 736, in install
>requirement.uninstall(auto_confirm=True)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_install.py",
>  line 742, in uninstall
>paths_to_remove.remove(auto_confirm)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/req/req_uninstall.py",
>  line 115, in remove
>renames(path, new_path)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip/utils/__init__.py",
>  line 267, in renames
>shutil.move(old, new)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", 
> line 299, in move
>copytree(src, real_dst, symlinks=True)
>  File 
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", 
> line 208, in copytree
>raise Error, errors
> Error: 
> [('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py',
>  
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py',
>  "[Errno 1] Operation not permitted: 
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.py'"),
>  
> ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc',
>  
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc',
>  "[Errno 1] Operation not permitted: 
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/__init__.pyc'"),
>  
> ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py',
>  
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py',
>  "[Errno 1] Operation not permitted: 
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.py'"),
>  
> ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc',
>  
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc',
>  "[Errno 1] Operation not permitted: 
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message/_metadata.pyc'"),
>  
> ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message',
>  
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message',
>  "[Errno 1] Operation not permitted: 
> '/var/folders/bk/zdhpxqj14y5fzcvlpybb4b64gn/T/pip-Gd3OiE-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/Message'”)]
> 
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

--
Jack Jansen, <jack.jan...@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@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Wanted: list admin for the PythonMac mailing list

[Jack Jansen]

Folks,
as you've probably noticed:-) the amount of time I spend on the pythonmac-sig 
mailing list has considerably diminished over the last couple of years. Not 
that I'm not interested, but I simply don't have the time:-(

However, I was still one of the two list maintainers, together with Skip. 
However, he has called it quits, so I'm now apparently the only list 
maintainer. It's not a lot of work, really nothing more than looking through 
the held emails once every week or so. Usually there's a few of them, usually 
they are all spam, but occasionally there is something that should be let 
through. Think of an investment of half a minute per week. Then you need to 
help epoepl with trouble unsubscribing once every year or so. It may be 
required to take emergency measures once in a very blue moon (I think it 
happened once in the last 15 years, on one of the many mailing lists I've 
maintained) such as temporarily shutting the list down in case of spam storms.

So, I want a volunteer to be list maintainer.

If you already know mailman that's a pre, but learning it doesn't take long 
either (it's in Python, so it's high quality software:-). I'll continue as a 
maintainer (as long as you let me:-), but i don't want to be the sole person 
responsible.
--
Jack Jansen, jack.jan...@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@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] appscript path issue

[Jack Jansen]

I wouldn't be surprised if the root of the problem is with PowerPoint.  
It started its life as an OS9 application, so if it still thinks it  
lives in an OS9 world with FSSpecs and colon-separated pathnames, it  
could be trying to do the conversion to posix paths itself. And such a  
conversion might well fail for hand-mounted NFS shares in non-standard  
locations...

--
Jack Jansen, jack.jan...@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@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] LOLpatents

[Jack Jansen]

On  13-Dec-2008, at 19:32 , has wrote:



On 12 Dec 2008, at 23:41, Conan C. Albrecht wrote:

IANAL, but in my watching of open source projects for many years,  
if you have prior work to the patent, you're fine.  If they decide  
to sue you, you can just show that your project predates the  
patent.  This one was filed in 2007, so I think things like  
appscript are fine.  (does appscript predate June 8, 2007?)  Again,  
I'm not a lawyer.


Don't worry, IANAL either.:) Anyway, appscript first appeared in  
2003. Ditto aeve, which also used SB-style dynamic class creation to  
build its API. Come to think of it, Apple's open-source RubyOSA  
project pretty much copies SB's approach throughout, even down to  
its semi-automatic 'implicit get' mechanism. Given that RubyOSA was  
originally released in summer 2006 I wonder if it also counts as  
invalidating prior art?


Don't forget the original MacPython applescript interfaces. Created by  
Guido and me between 1996 and 2000, if I remember correctly.


I think the various other non-Applescript OSA implementations (what  
was the name of that database-like package again?) don't count as  
prior art for this patent because of the automatically build glue  
classes clause, but the original MacPython OSA interfaces definitely  
did that.


So, we have lots of validating prior art available. Question is: (a)  
is it worth the time/effort to fight this patent, and (b) if it is,  
when is the best time to do so.
I know some people who have been involved in patent fights, I will ask  
around.


Could other people share their insights too, and/or ask around?

Hmm, one of the inventors is our old friend Bill Bumgarner. Bill, are  
you still on the list? Can you say anything about this patent?



--
Jack Jansen, jack.jan...@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@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] lots of Python-Cocoa errors in XCode console window...

[Jack Jansen]

On 3 nov 2008, at 00:02, Bill Janssen wrote:


has [EMAIL PROTECTED] wrote:


You're leaking memory, which isn't a good thing.

Are you using background threads? PyObjC automatically creates an
autorelease pool for the main thread only; you need to provide
autorelease pools for other threads yourself.


Yes, I am using background threads.  I have some functions triggered  
by
actions which make calls on remote services, and so may take  
arbitrarily

long to execute; I fork worker threads to do that fetch.  I'm using
Python's threading.Thread; should my target function look like this?

  def thread_target(*args):
 pool = NSAutoreleasePool.alloc().init()
 try:
 ...
 finally:
 del pool


I don't even think you need the try/finally and the del:
def thread_target(*args):
pool = NSAutoReleasePool.alloc().init()
...

The pool will be discarded when the thread exits, and that's that.

Of course, if you want the pool to be emptied more often you have to  
add code to do that.



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



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

Re: [Pythonmac-SIG] Example of stand-alone NSRunLoop?

[Jack Jansen]

On 15 okt 2008, at 05:34, Joe Strout wrote:

# Now we need a NSRunLoop...
runLoop = NSRunLoop.alloc()  # note: no init() method?
runLoop.run()


I think allocating a runloop is hardly ever what you need: there's one  
already, and you want to get that:


  runLoop = NSRunLoop.mainRunLoop()

This indeed brings up the speech listener window-let (Can't test it,  
no microphone right now).


This is a paradigm you'll come across often in Cocoa: there's a lot of  
objects of which there is one instance per application, and there's a  
class method to get that instance. NSApplication, NSFontManager,  
NSNotificationCentre, too many to mention, really.



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



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

Re: [Pythonmac-SIG] newbie questions about Mac APIs in Python

[Jack Jansen]

On  14-Oct-2008, at 19:36 , Joe Strout wrote:


On Oct 13, 2008, at 10:49 AM, Chris.Barker wrote:

But what if we want to do some of them from a wxPython app (only  
when we detect we're running on a Mac, of course)?


Good question -- can pyObjC play well with wx? Anyone know?


Or more generally: can you invoke some Cocoa functionality from any  
generic Python app, or does it have to be a PyObjC app through and  
through?


For example: suppose we wanted to take the clean but Windows-only  
speech package:


http://pypi.python.org/pypi/speech/0.5.1

...and add Mac OS X support to it.  The speech facilities in Cocoa  
(or Carbon, for that matter) are pretty easy to use; but this is a  
generic module, that ought to work in any Python app, whether it's  
got a wx GUI or even no GUI at all.  Is this possible, and how would  
we go about it?


Some simple things just work, also in command line tools. These are  
usually the CoreFoundation things that are pretty passive objects  
(CFDictionaries and such).


Some things work fine in a command line tool, as long as you make your  
command line tool have a run loop by allocating an NSRunLoop and  
calling one of it's run methods. But this wil require restructuring  
your app a bit. You may get away with running the runloop in a  
separate thread, but I have no experience with this (does anyone  
else?). I wouldn't be surprised if your speech stuff would fall in  
this category.


Some things will contact the window server, and this is not only  
obviously gui-related things like dialogs and such but also more  
subtle ones like some AppleEvents stuff. These will still work from a  
command line app, but they will probably not work from, say, a CGI  
script (as there's no window server). Hmm, maybe the speech stuff  
falls in this category after all, Apple may not want you to access the  
speaker if you're not the owner of the screen (the you here being  
the person running the script).



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



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

Re: [Pythonmac-SIG] Creating Application()

[Jack Jansen]

On  24-Aug-2008, at 21:28 , N3buK4Dn3ZZ4r wrote:



Hi there.
I'm not a complete newbie in python, but in building GUIs. I've worked
around a bit with Tkinter and I think, I can handle this one, but I  
also
tried to work with the FrameWork module, to create Menubars and  
this kind

of stuff. But I did not even get a Application() object createt. Could
anyone please post a simple code example, that creates a Application()
Object and a Menuitem or something like this?


Unless you have a very good reason to use FrameWork (and it appears  
you don't, as you're just starting): stay away from FrameWork. It is  
almost 15 years old (originally written by Guido himself), uses MacOS9  
APIs that are likely to disappear some time soon and hasn't been  
maintained in 7 years or so (I know, I was the last maintainer).


If you want to try something new for GUI development: look at Cocoa/ 
PyObjC. It is completely unlike anything else and the learning curve  
can be pretty steep when you come from another GUI toolkit, but that's  
mainly because you have to un-learn a lot of things. A Cocoa GUI  
almost writes itself. I always have the feeling that I've somehow  
cheated when I'm done: the GUI works, but I don't remember actually  
writing any code:-)



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



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

Re: [Pythonmac-SIG] Problem with Framework

[Jack Jansen]

On 10-Aug-2008, at 12:06 , Georg Seifert wrote:


is there a way to select witch framework to use?


I've never found one. I have two tricks (working together) I use when  
I build software to distribute:
1. After building my distribution, I run a script   
testdependencies (attached to this message) that uses otool -L to  
ensure all dependencies are in Apple-maintained locations (i.e. no / 
Library, no /usr/local, etc).


testdependencies
Description: Binary data



2. If this script returns a warning (about one out of two times:-) I  
do a temporary sudo chmod 0 /usr/local /Library/Frameworks/ 
Python ... and rebuild the whole distribution. If there's anything  
that I really need from /Library or /usr/local I copy it into the  
bundle and mangle the name with install_name_tool. For Python-based  
projects py2app can do this for you, too.




Georg


On  9-Aug-2008, at 17:56 , Georg Seifert wrote:


Dyld Error Message:
 Library not loaded: /Library/Frameworks/Python.framework/Versions/ 
2.4/Python
 Referenced from: /Users/Tim/Desktop/Pantografer.app/Contents/ 
MacOS/Pantografer

 Reason: image not found


Here's the smoking gun: it tries to load a user-installed copy of  
Python 2.4 which doesn't exist.


I assume that on your development machine you have 2.4 installed,  
and /Library (with the user-installed 2.4) takes precedence over / 
System/Library (with the Apple-installed 2.5) when you built the app.



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





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


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

[Pythonmac-SIG] Is there still a good reason for separate macpython and pyobjc mailing lists?

[Jack Jansen]

Now that pyobjc is a first-class citizen of MacPython, is there any  
reason to maintain two mailing lists? Are there any people who are on  
one of the lists and not the other?

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



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

Re: [Pythonmac-SIG] Back-porting Python 2.3 to Mac OS X 10.5?

[Jack Jansen]

Brad,
there's only one potential problem and that's the PPC/Intel issue. If  
you have a PowerPC mac (or you can live with running Python under  
Rosetta on an Intel Mac) I would first try to download a binary 2.3.X.  
My guess is that there's a 90% chance that it works. The issue might  
be finding compatible binary installers for Tcl/Tk and wxPython.

If the binary installer doesn't work just build the source. BUT (large  
but, here): don't try to build for Intel, only for PPC. If you have a  
PPPC mac that's easy. If you don't have one it's going to be a bit of  
a problem. The normal way to build for one platform on another  
platform is through the --host crosscompilation support of configure,  
but Python doesn't like that. Try starting with running the whole  
configure/build with CFLAGS=-arch ppc in the environment.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] Carbon bindings' future (was: Re: eliminating appscript-triggered Dock icon)

[Jack Jansen]

On  9-Apr-2008, at 07:56 , Ronald Oussoren wrote:

Even fixing bgen isn't that much work, once you understand the code.  
The problem is that bgen is a nearly vertical learning curve and  
Jack seems to be the only person that understands enough of bgen to  
be able to hack on it. I'm definitely in favor of ditching bgen and  
moving toward PyObjC-based wrappers.



I would also be in favor of using PyObjC-based wrappers.
But: I'm not sure that completely ditching bgen is what's needed. The  
front-end of bgen, which reads the C header files and produces what's  
basically interface definitions, should be understandable. The  
xxxgen.py files (which are really the interface definitions) could  
then be used to create bridgesupport files, and everything should play  
together well enough.


The only problem would be compatibility: one of the things bgen does  
is convert the procedural Carbon C argument convention (with the main  
object being the first argument, usually) to an OO model on the Python  
side. I don't think bridgesupport can pull off this trick.
And the conversion of arguments to be more Pythonic (two arguments of  
the form char *buf, int bufsiz are represented as a single string on  
the Python side, and lots more) is probably difficult too.

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



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

Re: [Pythonmac-SIG] CoreGraphics, 10.5

[Jack Jansen]

Are you sure your mask is actually greyscale? If I looks as if  
there's a repeating pattern in your result image. Maybe you could  
also use an assert to make sure bitsPerComponent() == bitsPerPixel()  
and #components==1.


On  16-Feb-2008, at 13:45 , Erik van Blokland wrote:



Folks,

I've been wrestling with some CoreGraphics stuff, OSX 10.5.2, stock  
Python 2.5.1. I want to load a RGB  image, then load a grayscale  
image, draw one while using the other as a mask. I can build all  
the required objects. I can draw with masking-like things  
happening to the image. But the masking appears to be according to  
a (random) piece of memory, rather than the pixels from the mask  
image.


The RGB image:
 http://erik.letterror.com/cg/picture.png

The grayscale mask:
 http://erik.letterror.com/cg/mask.tif

The resulting image:
 http://erik.letterror.com/cg/results.png

The script:
 http://erik.letterror.com/cg/cgMaskTestPost.py

The script which draws this file is below. Yellow background, rgb  
image of a neon sign, mask. I get the impression I'm somehow not  
making the right kind of mask. Or perhaps the parameters I'm  
passing to it are wrong. Perhaps the mask image is wrong. I've  
tried black/white bitmaps, tiff, jpeg, png, grayscale 8 bit, 24  
bit. Different formats result in different patterns being used as a  
mask - so there is some correlation between the file and the  
result. Is this anywhere close to how it needs to be done?


Any pointers are most welcome, thanks!

Erik van Blokland




#! /usr/bin/python2.5

from CoreGraphics import *
import os

def test():
testWidth = 1000
testHeight = 500
fileName = 'picture.png'# name of a 8 bit PNG, RGB image
maskName = 'mask.tif'   # name of an 8 bit, grayscale tiff
# the paths
root = os.getcwd()
filePath = os.path.join(root,fileName)
maskPath = os.path.join(root,maskName)
dstPath = os.path.join(root, results.png)

# data providers for the image and the mask
img = CGImageImport(CGDataProviderCreateWithFilename(filePath))
maskProvider = CGDataProviderCreateWithFilename(maskPath)
imgMask = CGImageImport(maskProvider)

# first, let's find out some things about the mask.
width = imgMask.getWidth()
height = imgMask.getHeight()
bitsPerComponent = imgMask.getBitsPerComponent()
bitsPerPixel = imgMask.getBitsPerPixel()
bytesPerRow = imgMask.getBytesPerRow()  
shouldInterpolate = True
decode = [0,255]# not relevant?
# make the mask
maskObject = CGImageMaskCreate(width, height,
bitsPerComponent, bitsPerPixel,
bytesPerRow, maskProvider,
decode, shouldInterpolate)
# now make the image with source image AND mask
imgWithMask = CGImage_createWithMask(img, maskObject)
# make a new image to save it all
	ctx = CGBitmapContextCreateWithColor(testWidth, testHeight,  
CGColorSpaceCreateDeviceRGB(), (0,0,0,0))

# a background color
ctx.setRGBFillColor(.9, .9, 0, .8)
ctx.addRect(CGRectMake(0, 0, testWidth, testHeight))
ctx.fillPath()
# draw the masked image
ctx.drawImage(CGRectMake(50, 50, width, height), imgWithMask)
CGContext_writeToFile(ctx, dstPath, kCGImageFormatPNG)
print done

if __name__ == __main__:
test()


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


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



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

Re: [Pythonmac-SIG] Key Bindings on cross platform apps.

[Jack Jansen]

On  1-Feb-2008, at 23:55 , Christopher Barker wrote:


Hi all

I'm trying help out Rob McMullen get his Peppy editor working  
well on

OS-X. I'm thinking about about key bindings.


There are some apps that have sets of keyboard shortcuts and let you  
switch between them with a preference. This is very handy, because  
now a Mac user of application X can chose whether s/he wants Mac- 
oriented shortcuts (so find will be command-F, for example) and  
another user of X on the Mac who happens to be familiar with the  
Windows version of X can chose Windows-X-compatible shortcuts (so  
find would be F3, probably).


I don't like customizable keyboard shortcuts in general (this is what  
makes it impossible to type anything in someone else's Emacs, for  
example), but in this one case I think it's definitely worth it.

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



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

Re: [Pythonmac-SIG] Pystone numbers for different Macs...

[Jack Jansen]

On 20-Jan-2008, at 19:23 , Daniel Lord wrote:

 I ran the test  on my 1st Gen Quad Core ( 2 x Quad-core 3.0 GHz, 13GB
 RAM) and was a bit surprised to see  little improvement over the Core
 Duo numbers.

 63019.7 pystones/second

 I am assuming the GIL is limiting  threading and therefore I am really
 running on one or two cores--hence the tangible improvement is just
 CPU speed: from 2.33 GHz to 3.0 GHz and a bit of the memory bandwidth
 increase as well.


Interesting...
My first generation quadcore at 2.6 Ghz clocks at 62578.2.

So there's another limiting factor: from my machine to yours is a 15%  
speed bump, but only a 1% increase in pystone numbers.

Somebody told me recently that MacOSX is not very good for fast task  
switching with multiprocessors, because apparently (his words, and  
possibly misrepresented by me) the implementation of semaphores sucks.  
This seems to corroborate that.

Hmm, what is your bus speed? Mine is 1.33 Ghz, is yours that as well  
is it 1.5 Ghz? If the former it could be that semaphores somehow run  
at bus speed and semaphore overhead dwarves any processing done. If  
your bus runs at 1.5Ghz there must be yet another bottleneck...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] Pystone numbers for different Macs...

[Jack Jansen]

On 20-Jan-2008, at 20:53 , [EMAIL PROTECTED] wrote:

Daniel I am assuming the GIL is limiting threading and therefore  
 I am
Daniel really running on one or two cores--hence the tangible
Daniel improvement is just CPU speed: from 2.33 GHz to 3.0 GHz  
 and a
Daniel bit of the memory bandwidth increase as well.

 The GIL doesn't enter into things here.  The pystones benchmark isn't
 multithreaded so even if Python was free-threaded the pystones  
 benchmark
 wouldn't benefit from it.


Hmm, you're right. And there aren't any magic threads either (happens  
far too often nowadays, grmpf), I just checked that with gdb.

So: any other speculations as to why 2.66Ghz-3.0Ghz gives only a 1%  
increase in pystones?
I can't physically reach my Mac Pro for another week, but maybe  
someone else could try disabling three cores? If that increases the  
pystone number (in stead of decreasing it) this could point to a  
processor affinity problem in MacOSX.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

[Jack Jansen]

On 3 jan 2008, at 14:22, Ronald Oussoren wrote:

 Now that there are several people that want to support Apple's build  
 of python: how do we go forward from here?

 I think we should start a small project for MacPython Addons, this  
 project will install:

 * Hotfix for distutils to ensure that distutils builds univeral  
 binaries (32-bit only at first)
 * (possibly) hotfix to ensure that you can install '-fat-' eggs on  
 10.5
 * /Applications/Python-2.5/IDLE.app


I think that for true end users Idle is the only serious omission.  
The first one is really for developers only, and the second one  
doesn't really become important until such fat eggs become widely  
available (which they are not right now, IIRC).

Hmm, idea to keep this manageable: how much work would it be to create  
tiny installers for each of these hotfixes, and then have a umbrella  
installer that encompasses all of these? That way, as new problems  
surface the only work would be to create a hotfix installer for that  
single problem and do a tiny update to the umbrella installer.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

[Jack Jansen]

On 20 dec 2007, at 12:35, Ronald Oussoren wrote:


 That's easily fixable. I'm thinking about reviving Jack's MacPython
 addons idea: a small .mpkg that will install IDLE.app, a 64-bit
 command-line interpreter and some small fixes (such as the distutiles
 one).  That should make Leopard's builtin python a lot more useable
 without requireing people to basicly install the same version of
 python that is already on their system.


I think this would be a very good idea, even if only from a  
political point of view.
Even though I've been an open source developer since long before the  
word existed I find that I'm getting sick and tired of the reinvent- 
the-world attitude that is far too common in the open source community.

If I am new to Python on the Mac and I've played with Apple Python a  
little, but as soon as I want to install one little add-on module I  
have to first replace the whole existing Python with something new  
(and not directly Apple-endorsed) I might just drop out. And at the  
very least it's mightily inconvenient. Also note that the chances that  
the distutils fix or the 64-bit fix are likely to affect me are  
exactly zero (the newcomer me from this paragraph, not the flesh  
and blood Jack me:-).
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

[Jack Jansen]

I've been thinking a bit more about being forced to upgrade package X  
when I'm not interested, and I realised that the times it really  
bothers me are even one more step removed: if I was interested in  
package X and the website/whatever told me don't use the current  
version of X, use the newer one I can probably live with that.

The real problem is when I couldn't care less about package X but I'm  
really interested in Y, which uses X, and then X forcing me to upgrade  
it.

Python is in a pretty good shape right now, with well-packaged  
extension modules being compatible with a fairly wide range of Python  
installations, but please let's try and keep it that way.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] Any hints on building libpng universal?

[Jack Jansen]

On 23-nov-2007, at 4:58, David Warde-Farley wrote:

 Hi again,

 I'm trying to build a universal libpng package at the moment  for use
 with matplotlib from pythonmac.org/packages. There's an older version
 up on undefined.org that's referred to in some mailing list postings
 but there've been some major security holes fixed since then, so I've
 been trying to automate the process of building a

 gcc complains about the '-M' flag being used with multiple -arch
 flags, [...]

I don't remember what I did to build libpng universal, but problems  
with '-M' are usually solved by adding '--disable-dependency- 
tracking' to the configure command.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

[Pythonmac-SIG] Anyone playing with CoreAnimation yet?

[Jack Jansen]

I've just realised how powerful CoreAnimation is, and I want to start  
playing with it, especially with the interaction of CoreAnimation  
CALayer with classic AppKit views and how to treat events, etc.

Is anyone else here using it, and/or interested in sharing experience?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?

[Jack Jansen]

On  27-Oct-2007, at 02:55 , Darran Edmundson wrote:
I've recommended that Douglas join this mailing list and ask  
questions.

  My only concern is that most people coming to this list are probably
python users (like myself) who want to write Mac apps.  Douglas is
coming from the opposite tack - he's a hardcore Cocoa developer who
doesn't know python at all.  With this in mind, do you have any  
pointers

in designing a library that is easily called from python?


There are some things you can do in ObjC that are difficult to expose  
to Python, but as they're so unusual I've never come across them I've  
also conveniently forgotten what they are:-)


Oh yes, I think if you pass a C structure you have to do some  
massaging (excpe tif PyObjC already knows about that structure, such  
as for NSPoint and such, then the work has already been done for you).



I wondered, for example, if he wrote the Objective C library and a
separate Objective C test application to exercise the code, if the  
test

app could then simply be ported to pyObjC?  This way Douglas wouldn't
need to worry about python at all ...


If you do this very early during development, i.e. when the library  
API has only a couple of calls you have the ObjC programmer write a  
minimal test script which you then port to Python, you could give  
this back to the ObjC developer. There's a very good chance this'll  
teach them enough Python to continue the testing directly in Python.

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



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

Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?

[Jack Jansen]

If I understand the architecture correctly I would go with option 1.  
And get the Mac guys to write their code in a reusable way, i.e. have  
them export enough low-level functionality in their API. This should  
be easy enough in ObjC.
It'll allow tweaking from the Python side, and if you're lucky during  
the project they'll see the advantage of Python and all jump on the  
bandwagon:-)

BTW: there's a potential third architecture that I can see: write a  
Cocoa app with a Python module embedded. This is similar to option 1,  
but depending on which technologies you use it may be easier to  
structure things with ObjC in charge in stead of Python. But if you  
also structure your Python code well it shouldn't be much of a  
problem to switch from design 1 to design 3 later in the development  
process.

On 26-okt-2007, at 9:01, Darran Edmundson wrote:


 I have a couple of Cocoa/Quicktime developers working on a small  
 custom
 application.  These guys are very capable at OS X programming but  
 don't
 have any python experience.  I, on the other hand, have a lot of  
 python
 experience but virtually no Mac development experience.  I could  
 really
 do with some advice from someone able to see the big picture.

 A bit of background ... We are working on a museum exhibit where a  
 large
 65 1920x1080 screen attached to a Mac Pro is electronically  
 positioned
 on a 4m industrial slide-track via a physical interface device.  Each
 millimeter of track corresponds to a different image in a 4000 frame
 photo-jpeg-encoded Quicktime.  The user tweaks the interface  
 device, the
 screen moves, the image changes appropriately - that's the basic plan.

 I have a python program on the Mac that determines, among other  
 things,
 the screen location.   The OS X developers are going to write a
 full-screen Cocoa application that handles the display side of things
 (along with some tricks like: change to a new movie; tweak the  
 opacity;
 add a second layer movie; etc.)  The question then: how to join these
 two codes?

 Options (that I can think of, probably more worthy of discussion):

 1) Get the Mac guys to write their application as a library that  
 can be
 wrapped in pyObjC and invoked by my python program.  In this scenario,
 the result is only one process/program with no network issues.

 2) Add networking code to both the python and cocoa apps in order to
 communicate (binary socket, XML over http, Bonjour, etc.).  Easy in
 python via Twisted, no doubt less so in cocoa.

 As always, any advice is much appreciated.

 Cheers,
 Darran.

 -- 
 Darran Edmundson [EMAIL PROTECTED]
 http://www.edmstudio.com
 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig

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


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

Re: [Pythonmac-SIG] Audio_mac.py fails in writeframes

[Jack Jansen]

On  11-Oct-2007, at 18:51 , punch wrote:

I'm running 'OS X' 10.4.10 and python 2.5.1 on a MacBook Pro SR.  
When I

try to run any of the audio demos, specifically Audio_mac.py, I get
errors. The error is in the writeframes method. It appears to try and
pack the constant extSH (set to 0xFF) as a signed byte, which it  
cannot do.


Change the struct.pack format from 'llHhllbbl' to 'llHhllBBl'.

The code predates the distinction between signed and unsigned bytes  
in struct.pack.


But be warned that this also shows how well-maintained the code is:-)
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



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

Re: [Pythonmac-SIG] 64-bit code

[Jack Jansen]

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, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Democracy player

[Jack Jansen]

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, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] findertools.launch reports no eligible process

[Jack Jansen]

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, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] findertools.launch reports no eligible process

[Jack Jansen]

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, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] findertools.launch reports no eligible process

[Jack Jansen]

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, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] StuffIt 10 can corrupt applications packaged with py2app

[Jack Jansen]

On 25-apr-2007, at 7:50, Ronald Oussoren wrote:


 On 24 Apr, 2007, at 5:45, Brian Christensen wrote:


 Following up on this lead we found that there is a problem with
 StuffIt 10. My application was distributed as a zip file so the user
 used StuffIt to unzip the file. It turns out that StuffIt was
 unzipping and deleting the site-packages.zip inside of the  
 application!

 That's very lame behaviour on StufIt's part.

It's a preference. In Stuffit Expander it's called Continue to  
expand if possible, in the full stuffit it's probably something  
similar.
It's on by default, it's what makes stuffit do the full decoding and  
unpacking of, say, a .tar.gz.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] Macintosh modules/Carbon/documentation

[Jack Jansen]

On  31-Mar-2007, at 19:58 , has wrote:


Furthermore, this stumbling block has a stumbling block of its own:
bgen. There's very few folk around who understand it at all, and no
documentation (AFAIK) for anyone else to make sense of it. Until
there's some sort of decision made about bgen's future (maintain and
document it? Replace it completely? Abandon it and maintain existing
code by hand?), I can't see anyone really wanting to step into that
tarpit.


I'm committed to bgen, for at least the next couple of years. I'm  
also using it to generate a bidirectional C++ bridge for Ambulant  
(which is my main project nowadays, and which is one of the things  
that makes me spend so little time with development of Python itself).


But unfortunately getting the *^$ thing in better shape for initial  
use is something that keeps slipping:-(

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



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

Re: [Pythonmac-SIG] Macintosh modules/Carbon/documentation

[Jack Jansen]

On  30-Mar-2007, at 22:55 , Kevin Walzer wrote:

Looking at the Macintosh Library documentation that ships with  
2.5, I

see a lot of outdated stuff: references to the old PythonIDE,
PackageManager, and so on. What is the process for updating these  
docs,

submitting a bug report, etc.?

Also, there appears to be a lot of modules in the Macintosh
Library--Carbon modules, generally--that are undocumented, or are
broken, or (almost as bad) no one know if they work or not. Has anyone
gone through these to sort out what works, what should be deprecated,
etc.? Does it make sense to deprecate the entire Carbon module? What's
the process for this?



I had a chat about this with Ronald a few months ago, where we  
basically went through all the modules. Ronald,

do you have your notes handy?

Carbon itself should be fine. It is indeed undocumented within the  
Python documentation, but the transformation from the official Apple  
C documentation is pretty clear (I think).

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



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

Re: [Pythonmac-SIG] Recording audio on Mac

[Jack Jansen]

On 24-mrt-2007, at 16:46, Lucio Torre wrote:

 Hi,

 I want to record audio on mac. Ive seen that the function SPBRecord
 does what i need.
 (http://developer.apple.com/documentation/QuickTime/INMAC/SOUND/ 
 imsoundinput.19.htm)

 This function is wrapped in the Carbon.Snd python library. My problem
 is that i need to pass a SPBOjb parameter and im unable to create an
 object of that kind.

Carbon.Snd is very old, and it hasn't seen much development in the  
last 8 years. Mainly because the API is baroque, and Apple has been  
steering people away from it for years.

Quicktime is probably your best option for recording from Python, but  
I wouldn't bet on it that all the correct functionality is exported  
to Python. But I'll be going to need some recording facilities too in  
the near future, so if there's something you miss let me know and  
I'll add it.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] How to create a desktop alias to run a python file?

[Jack Jansen]

On 20-mrt-2007, at 17:30, Alfred Morgan wrote:

 From: Stani's Python Editor [EMAIL PROTECTED] 
 This is probably very easy, but I don't find how to do it. I want to
 execute this command if an user clicks on the icon of the alias on the
 desktop:

 /usr/bin/pythonw path/gui.pyw

 Like other people said, you probably don't want to do that, but  
 unlike other people, I'll answer your question.

 mkdir ~/Desktop/MyProg.app
 echo '#!/usr/bin/env pythonw /path/gui.pyw'  ~/Desktop/MyProg.app/ 
 MyProg
 chmod +x ~/Desktop/MyProg.app/MyProg

 double click MyProg on the desktop and it should launch your python  
 program using pythonw

I was very surprised when I saw this, I'd never seen this before.

And, indeed, when I tried it it didn't work:-(
Maybe you skipped an important step in the instructions?

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


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

Re: [Pythonmac-SIG] How to create a desktop alias to run a python file?

[Jack Jansen]

On  23-Mar-2007, at 22:27 , Alfred Morgan wrote:

#!/bin/sh
cat  /tmp/alfred_hw.py  .
from Tkinter import Tk, Label
r=Tk()
Label(r, text=Hello World).pack()
r.mainloop()
.
mkdir ~/Desktop/alfred_hw.app
cat   ~/Desktop/alfred_hw.app/alfred_hw  .
#!/usr/bin/env pythonw /tmp/alfred_hw.py
.
chmod +x ~/Desktop/alfred_hw.app/alfred_hw


Yes, this one works for me just fine!!

I'm very surprised, because it does not follow any Apple guideline  
for application bundles that I've ever seen. (Also, I don't know what  
I did differently yesterday when it didn't work for me, but never  
mind that). BTW: you can make things even simpler by putting the  
Python code into alfred_hw. And moreover you don't need pythonw,  
apparently because you're in an App bundle already:


#!/bin/sh
mkdir ~/Desktop/alfred_hw.app
cat   ~/Desktop/alfred_hw.app/alfred_hw  .
#!/usr/bin/env python
from Tkinter import Tk, Label
r=Tk()
Label(r, text=Hello World).pack()
r.mainloop()
.
chmod +x ~/Desktop/alfred_hw.app/alfred_hw


Is anyone else familiar with such simple .app bundles?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



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

Re: [Pythonmac-SIG] Python and Zeroconf?

[Jack Jansen]

On  26-Dec-2006, at 19:29 , Nehemiah Dacres wrote:

his problem might be how to make fat python byte code, or rather,  
universal binaries with python.


Python byte code is architecture-independent[*], so that shouldn't be  
a problem.


[*] I think there was a problem with portability between machines  
with 32 and 64 bit integers, but I recall that that has been solved  
also. And at least it isn't a problem for ppc/intel mac portability.

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





smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] problem fixing Carbon.AE/CarbonX.AE conflicts

[Jack Jansen]

On  10-Nov-2006, at 12:31 , has wrote:On 9 Nov 2006, at 16:49, Ronald Oussoren wrote: Unfortunately, when I try to do this, all I get is a bunch of  'symbol not found' errors on import: That's because there are hooks in the core interpreter for the  Carbon modules. Yeah, already took a look at mactoolboxglue.c, but it was all  hardwired and didn't really help. I think there must be other stuff  going on as well.Not really: the hooks are only there because at the time I wrote itI thought the export-via-python a bit too much of a hack.But since then everyone is doing it, and with cobject it can actuallybe done in a pretty safe way, so I would use something like thatnowadays.-- Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman  

smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] bugs in _Qtmodule

[Jack Jansen]

On 4-okt-2006, at 3:58, Jeff Senn wrote:



While attempting to use the QuickTime sequence grabber
interfaces from Python I notice that there is some
confusion between Component and ComponentInstance
in _Qtmodule.c.

I believe most of the instances of CmpObj_{Convert,New}
in _Qtmodule should actually be CmpInstObj_{Convert,New}
(There are a few that are correctly CmpObj_...)

I have a (moderately tested) patch...


A patch won't help much, because _Qtmodule is generated (through  
qtscan.py/qtsupport.py). I assume that there's a one-line mistake in  
qtsupport, which leads to one C type being handled as CmpObj in stead  
of CmpInstObj.


Hmm, well at least the patch will contain that information, I guess.  
Could you put it on sourceforge and assign it to me?

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





smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Job postings - allow or not?

[Jack Jansen]

Folks,
I've just let a job posting through to the list, after looking at it  
for a long time and unsure whether or not we want these.

If you have a strong opinion (or a weak opinion, or anything  
resembling an opinion:-) on the matter: please let me know, then I'll  
use the collective feedback as a guidance in the future.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] PyObjC + AEInstallEventHandler crash?

[Jack Jansen]

On 21-dec-2005, at 2:51, Bob Ippolito wrote:

 Trying to figure why the following test app crashes when a 'testtest'
 Apple event is sent to it:

 
 # cocoatest.py

 from PyObjCTools import AppHelper
 from Carbon.AE import AEInstallEventHandler

 AEInstallEventHandler('test', 'test', lambda evt, res:0)

 AppHelper.runEventLoop()

 

 Additional notes: the test app doesn't crash when
 AppKit.NSAppleEventManager is used to install the event handler  
 function,
 nor when CarbonEvt is used instead of PyObjC.

 I'm getting a similar crash in some CarbonX.OSA code within a  
 PyObjC-based
 app and reckon identifying what's causing the test app to crash  
 will help
 me solve the problem there. Any ideas as to the cause, suggestions  
 where
 to look, how to debug it more effectively, etc. would be a big  
 help as
 I've been stuck on this for more than a day now and have only just  
 fitted
 a new laptop case after the last temper tantrum. :p

 My guess is that there's a refcount or GIL bug in
 Carbon.AE.AEInstallEventHandler.

You guessed correctly: AEInstallEventHandler is blissfully unaware of  
refcounts. It simply passes the address of the callback function  
object to the C AEInstallEventHandler, and hopes the object still  
exists when the callback comes.

The workaround is to keep a reference to the object around. Which is  
apparently also the normal case, I think this is the first report  
I've seen of this problem, and I wouldn't be surprised if this code  
even predates my responsibility for the toolbox modules (i.e. Guido  
himself wrote this:-).
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] universal python framework?

[Jack Jansen]

On 9-dec-2005, at 18:56, William Kyngesburye wrote:

 I'm starting to build universal binaries for a bunch of 'nix stuff,
 some of which have python bindings/extensions.  Has anyone looked at
 a universal Python framework?  I'd hate to have to step backwards to
 Apple's included Python framework for that, but I may have to.

There's a fairly recent Apple technote that discusses how to build  
universal binaries for products with a configure/make build  
procedure, such as Python, and I hope to look at that next week. But  
Ronald already discovered that distutils has problems with building  
universal extensions, so that may also turn out to be a problem  
(although he wants to build something more complicated, with the PPC  
binary being 10.3/10.4 compatible).

And the easy way is to simply configure Python twice (Python builds  
nicely in a different directory than the source, I'm doing that all  
the time), once for ppc once for x86, and then using lipo to combine  
everything.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] Selecting in BBEdit Python Indenting style (spaces)

[Jack Jansen]

On 29-nov-2005, at 18:33, Louis Pecora wrote:

 What the heck were they (Guido?) thinking when they used 4 spaces  
 as the one true mode of indentation for Python?

Initially Python was unix-only, and there (at that time) a tab was 8  
spaces and that is that, no problem with mixing tab/spaces. Then the  
Mac (and later dos/windows) joined the scene, which had 4-space tabs.  
Then it was deemed mixing tab/space was bad (because code got ugly or  
even didn't work when ported between 4- and 8-space tabs. Because at  
that time most editors (both on Unix and Windows) still did not have  
the feature to set how many spaces a tabstop was it was decided to go  
with spaces for indenting: going with tabs would have meant unix- 
heads would be stuck with unusable 8-space indents.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

[Pythonmac-SIG] Did anyone play with TransformProcessType yet?

[Jack Jansen]

No, I've not come out of hiding just yet (still far too busy with  
Ambulant to do any Python work), but I came across  
TransformProcessType just tonight, so I did a quick experiment and it  
seems to work.

What it does is turn any process into a full-fledged windowing  
application, with a dock icon, the possibility of a menu bar, etc. So  
this may be the way to get rid of pythonw. I quickly added a method  
MacOS.SetWMAvailable(), and it seems good enough for running the IDE  
with python in stead of pythonw. The icon is ugly (a terminal- 
style script), and the application menu title is python in stead of  
whatever script you're running, but that can all be fixed.

Did anyone else have a look at this call? Is it worth it to invest  
some time into it? If it is I'll check it in and people who build  
Python from CVS can play around with it.

Please reply also to me personally, I still have 847 pythonmac-sig  
mails waiting for me so if you reply only to the list it'll be a long  
time before I see it...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


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

Re: [Pythonmac-SIG] webcam snapshot from Python

[Jack Jansen]

On 12-apr-05, at 20:49, Mathieu Lecarme wrote:
There is a win32 project http://videocapture.sourceforge.net/
But on Mac Quicktime know how to grab picture from a webcam. HackTV 
seams to be a nice example for that.
How can i take a picture (not a movie) from a webcam with macPython?
The Quicktime module should be able to do this, if you're using 2.4.1. 
If you're still using 2.3 you can download and install the new 
Quicktime module through Package Manager or from Bob's package list. 
For the documentation you read Apple's C quicktime docs, and remember 
that a C function like FooBarMovie(Movie *m, int x, int y) will be 
represented in Python as a method of the Movie object, i.e. call 
m.FooBarMovie(x, y).

And the same question as I asked in a similar thread last week: the 
quicktime module should be able to handle capturing, but I've never had 
any feedback that it actually works. So please report back here.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Embedding with CW6

[Jack Jansen]

On 24-mrt-05, at 14:28, Steve Spicklemire wrote:
Hi Folks,
Back in the pretty old days (python 1.5 or so I think) I developed a 
Macromedia Director (MMD) scripting Xtra that allowed Lingo scripts to 
use python as an embedded language. It worked great... but I moved on 
and haven't done anything Carbon in years. Now I find myself in a 
situation where I need to get that Xtra working with the latest MMD. 
The Macromedia XDK seems to only support Codewarrior on the Mac. I 
have only CW6 at this point (I have an email sent off to Metrowerks 
asking how I might get CW7) so I guess I can't build the latest 
sources (as they seem to want CW7). So.. the question is: What's the 
latest set of sources that will likely work on CW6? (in case I can't 
get CW7).
It's difficult to tell (I have to work from the log messages, and 
compare checkins to release tags), but it seems I made the switch from 
CW6 to CW7 in December 2001. The log messages seem to suggest that 2.2 
was released with CW7. So that means 2.1 is the last version that'll 
build with CW6...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] Compiling Python on Tiger

[Jack Jansen]

If anyone has tried to build Python on Tiger: could you please contact 
me?

I've received a bug report that I'd like some more data points on...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Qualcomm Purevoice codec

[Jack Jansen]

On 22 Feb 2005, at 08:24, Roger Binns wrote:
Can anyone give me hints on how to access the Qualcomm Purevoice codec 
that is part of Quicktime from Python?

In BitPim we convert between wav and Purevoice using the convertor
that Qualcomm provides:
http://www.cdmatech.com/solutions/products/purevoice_download.jsp
Note that they don't supply it for MacOS X.  There is however a
codec inside Quicktime.  Ideally I want as close functionality
as possible as their Windows and Linux binaries.
[...]
I couldn't find anything relevant using Google.  There is a
Carbon.QT module but none of the methods appear to do any form of 
conversion.
The quicktime module for Python 2.4 has a lot of new functionality (and 
it's also available as an addon for Python 2.3, through my experimental 
database for Package Manager). Access to codecs is one of the things 
that has been added.

But, of course, I've only tested it very lightly and it's very possible 
I forgot some essential things. Could you please check whether Python 
2.4 (or its Carbon.Qt module used in 2.3) allows you to access the 
codec you need?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] broken web link on Mac Python webpage

[Jack Jansen]

On 18-feb-05, at 22:24, Rick Thomas wrote:
A (hopefully) minor nit:
On the web page http://homepages.cwi.nl/~jack/macpython/beta.html  
there is a link to a fix for Apple Python.  Unfortunately, clicking 
the link tries to go to 
http://homepages.cwi.nl/~jack/macpython/pantherfix , which doesn't 
exist.
The link works for me... So, either (a) I fixed it inadvertantly, (b) 
it only works for me, or (c) we're talking about different links?

Can you check whether it works now, and if it doesn't give some details?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Fink, DarwinPorts vs py2app

[Jack Jansen]

On 10-feb-05, at 20:56, Michael Hudson wrote:
Michael Maibaum [EMAIL PROTECTED] writes:
As for Python. As soon as there is a framework version of Python
that can be installed via a destroot for packaging, I'll add it to
DarwinPorts. Or if someone can figure out how to hack the current
version to do it...
Is there a bug report for this?
It has been fixed, see http://www.python.org/sf/1091468. The fix is 
in 2.3.5 and will be in the forthcoming 2.4.1.

I don't think I've ever done fixes that needed so many things changed 
in so many places, for the benefit of so few users. But then, I myself 
am one of those few:-)
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] How do you find the app that matches a creator type

[Jack Jansen]

On 1-feb-05, at 2:09, Bob Ippolito wrote:
Unfortunately these patches need to be rewritten such that they 
change the gensuitemodule scripts
I think you mean bgen, yes?:)
Yeah I mean bgen...  I'm confusing the evil code generators
Bob, I hope you realise that these evil code generators were written 
by Guido Himself (Our Beloved Leader, He Who Coded What No Man Coded 
Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-)

My main tasks in the MacPython world have been:
a) Keep those two working with new releases of Python
b) Keep those two working with whatever new stuff Steve (Our Beloved 
Leader, He Who Designed What No Man Designed Before, He Who Forever 
Enlightens Our Path, etc etc etc etc etc:-) came up with.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] python.h and veclib.h incompatible?

[Jack Jansen]

Google found one possibly interesting reference,  
http://mail.python.org/pipermail/pythonmac-sig/2003-September/ 
008759.html and the rest of that thread.

The trick seems to be to include math.h before python.h.
On 25 Jan 2005, at 03:31, Brian Clarkson wrote:
Hello.
I was swig'ing an extension that made use of veclib in its internals  
and discovered that if python.h is included before veclib.h that  
compilation will not succeed. It seems they are interacting so that  
parts of fp.h are being left out when they shouldn't be.

I have distilled the problem down to the following simple test case:
begin test.cpp
#include python.h
#includeveclib/veclib.h
#includeiostream
using namespace std;
int main(){
cerr  scalb(3,4)  endl;
return 0;
}
end test.cpp
Which when compiled as follows:
gcc -I/sw/include/python2.3 -c test.cpp
gives the following errors:
In file included from /sw/include/python2.3/python.h:70,
 from test.cpp:1:
/sw/include/python2.3/objimpl.h:255: warning: use of `long double'  
type; its
   size may change in a future release
/sw/include/python2.3/objimpl.h:255: warning: (Long double usage is  
reported
   only once for each file.
/sw/include/python2.3/objimpl.h:255: warning: To disable this warning,  
use
   -Wno-long-double.)
In file included from  
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/CarbonCore.h:165,
 from  
/System/Library/Frameworks/CoreServices.framework/Headers/ 
CoreServices.h:21,
 from  
/System/Library/Frameworks/veclib.framework/Headers/veclib.h:20,
 from test.cpp:2:
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/fp.h: In
   function `long double scalbl(long double, long int)':
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/fp.h:1896: error: `
   scalb' undeclared (first use this function)
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/fp.h:1896: error: (Each
   undeclared identifier is reported only once for each function it  
appears
   in.)

Other than refactoring in order to hide veclib.h from python.h, does  
anyone have any fixes for this?

Thanks in advance!
Brian
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman

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

Re: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity?

[Jack Jansen]

On 26-jan-05, at 21:50, has wrote:
Bob wrote:
It doesn't sound like that's what he wants.
Yeah I know, I was thinking laterally; throwing random ideas into the 
ring 'n that.

iTunes... Mac Mini... media centers... cross-platform... LANs... 
etc... seems a very wide field; perhaps there's opportunities there 
for MacPython to do interesting things.
Definitely, but someone has to do them:-)
When I came across the Mac mini media center stuff a couple of days ago 
I realised that this would be an area where 
Python/MacPython/PyObjC/appscript could really shine. They have very 
few ObjC developers right now, and a rather large agenda.

Think of it: the end user will want to use the remote control to browse 
a selection of songs (or radio stations) on-screen and have the result 
play through itunes. So we're talking a combination of unix 
programming/bit manipulation (reading /dev/ttyXX and getting the IR 
commands), a reasonable user interface in 640x480 (or 575xtheotherone) 
and talking to iTunes. Python is the only language I can think of that 
I would consider doing something like this in.

But, of course, I don't have the time:-( But it would really make me 
happy if people looking for pet projects could have a look at this...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Python+Automator?

[Jack Jansen]

On 23-jan-05, at 15:55, Bob Ippolito wrote:
On Jan 23, 2005, at 9:29, has wrote:
Just reading up on Automator development 
http://developer.apple.com/macosx/tiger/automator.html and 
wondering if the MacPython community (or anyone in it) has any plans 
to 0wnz0r it yet? Like providing a 'Python Automator Action' template 
for Xcode, flogging a nice introductory 'Developing Automator Actions 
with Python' article to online tech sites like O'Reilly, making 
themselves a presence on Automator mailing lists and forums when they 
arrive, etc.

With Tiger arriving soon, seems like a grand opportunity for someone 
with a pre-release build and a hankering for MacPython evangelism to 
get in at the head of the rush and mop the floor with the 
competition. :)
Given the description, it would be trivial to write an Automator 
Action in PyObjC 1.2+ using the py2app plug-in bundle support.  I 
doubt I'll be using Automator often enough to become a PyObjC 
Automator evangelist though.
What's the advantage of PyObjC here? Just because it makes it easier to 
write the plugin, or does it help with writing the Python code too?

Because I wouldn't mind having automator support in a future MacPython 
for Tiger additions...
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] coding preference

[Jack Jansen]

 or not. Whether or 
not it has a positive impact.
Fully agreed. I guess that where I said throwaway app I should have 
said applications that provide a unique service that isn't available 
anywhere else. Whether that unique service is for you yourself only 
(as in a throwaway app) or for a larger community isn't the point.

But if your app is competing with other products (an IDE, an image 
editing program, a database or spreadsheet, whatever) it will really 
have to stand out in functionality to offset the disadvantages of a 
cross-platform toolkit.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] coding preference

[Jack Jansen]

On 19-jan-05, at 18:54, Chris Barker wrote:
I've never used QT, so I can't speak to the advantages. One reason I 
would consider switching, however, is that there are more Scientific 
Widgets for QT (like http://qwt.sourceforge.net/). If you don't have a 
need for those, then wx should be fine.
I've only used it from C++, and only on Linux (the multimedia projects 
I do tend to grow platform-dependent UI solutions), but I was favorably 
impressed. Functionality tends to be in the place where you expect it, 
which is where most GUI packages break down (including Cocoa), and the 
documentation is pretty good. For Linux standards things look 
absolutely great on-screen.

Which brings me to my real point: I don't think a good cross-platform 
GUI toolkit is possible. Period. There are some things that simply 
cannot be matched programmatically, specifically when paradigms are 
different. So while a really good x-platform GUI toolkit may get the 
look right, I don't think it'll ever manage getting the feel right. 
Which means your stuck with the worst of both worlds: something that 
looks like a (say) Mac application but doesn't behave like it.

My solution: for throwaway applications consider a cross-platform 
toolkit, for anything serious use MVC and code the view and controller 
in a platform-native toolkit.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?)

[Jack Jansen]

On 14-jan-05, at 23:57, Bob Ippolito wrote:
I have traced the problem.  It is a two-parter:
(1) There is a module namespace conflict:
WebWare has a package named WebKit
PyObjC has a package named WebKit
As far as I know this is the first time this potential problem with 
python's naming convention is seen in the wild. Maybe it's worth it to 
report it to python-dev?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] Any suggestions for a questionnaire site?

[Jack Jansen]

Folks,
I want to do a questionnaire shortly, on the subject of which 
installers people want most (2.{3,4}.X for 10.{2,3}, mainly).
That'll help me spend my time most efficiently (my MacPython time, that 
is:-)

Does anyone know of a decent site that hosts such questionnaires that 
is both easy to use and cheap (preferably free:-)?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Testers needed again: Fix installer 1.2

[Jack Jansen]

On 11-jan-05, at 11:09, Michael Twomey wrote:
Hi,
I just tried out the installer and it works fine, but it appears to
have littered my disk with CVS directories, was that intentional? (I'm
guessing not)
Good catch!
I've created a new installer that doesn't have this problem.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] [EMAIL PROTECTED]: MindVision Releases VISE X 1.5 for Mac OS X]

[Jack Jansen]

On 11-jan-05, at 2:01, Bob Ippolito wrote:
On Jan 10, 2005, at 19:33, Neal Norwitz wrote:
I thought this might be of interest here.  The PSF owns a license to
VISE.  Jack knows the details.
I think that this is only really relevant to Mac OS9.  I'm not sure if 
Jack plans to make another release for OS9?
I plan to do a final 2.3.5 release. But that does depend on my OS9 
partition still starting up (I've reshuffled things), I'm not going to 
install OS9 and CodeWarrior and all that from scratch.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Python 2.4 Framework build?

[Jack Jansen]

On 7-jan-05, at 21:02, Nick Matsakis wrote:
It appears to me that there is not a python 2.4 framework build in 
fink.
Is this actually the case?  It is my impression that a framework build 
is
necessary to use appscript and other Mac goodies. Is this still the 
case
with 2.4? Finally, what is the easiest way to get a framework build of
2.4?  Is there a binary installer somewhere?
I'm working on a lot of distributions right now, including a 2.4.1 
framework build.
It can't really be finished until 2.4.1 comes out, but if people want 
to give a 2.4.1a0 build a try: let me know and I'll make it available.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Help - MacPython stopped running

[Jack Jansen]

On 7-jan-05, at 18:23, Marshall Labow wrote:
Can anyone help me?
I am running Panther (10.3.7) and installed the upgrade to Python 2.3 
(MacPython IDE) and it worked for a few days. Now when I attempt to 
load the program, the splash screen appears for a few seconds and then 
disappears without the finder ever showing Python IDE as being active. 
I have tried (1) rebooting the computer; (2) re-installing MacPython; 
and (3) deleting the existing MacPython files and re-installing them. 
Nothing so far helps. Anyone have any suggestions?
You've probably run into the Scripts menu problem. See the FAQ for a 
fix (in short: remove your IDE preferences file). If that doesn't help 
please report back,
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] Bob Ippolito's synopsis of Python(s) on OS X

[Jack Jansen]

On 7-jan-05, at 22:55, Brendan Simons wrote:
This is an old thread, (and an old topic) but my
question is about the state of the new tools
described in Bob's presentation at last year's pyCon.
Scanning the archives, I see Jack and Just have talked
about a PyObjC-based python ide since 2002.  I've
really anxious to see how they are coming along.
Aren't we all:-(
The problem is one of time: I've spent all of my working hours the last 
year on a completely un-pythonic project (www.ambulantplayer.org, but I 
do plan to do Python bindings some time this year), and now that I 
finally have some time to do Python work I'm concentrating on the 
important infrastructural problems (mainly the 
multiple-python-problem and getting Package Manager to be more 
maintainable). I assume Just is similarly occupied by other priorities 
(hmm, that doesn't look like english:-).

I haven't even had the time to seriously look at PyOXIDE, let alone the 
other contenders. But I'm still very interested in getting a good 
replacement for the IDE, it's just that I don't have the time to invest 
in it.

Is there some way we could turn this next generation IDE thing into a 
group effort?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

[Jack Jansen]

On 3 Jan 2005, at 23:40, Bob Ippolito wrote:
Most people on Mac OS X have a lot of memory, and Mac OS X generally 
does a good job about swapping in and out without causing much of a 
problem, so I'm personally not very surprised that it could go 
unnoticed this long.
*Except* when you're low on free disk space. 10.2 and before were 
really bad with this, usually hanging the machine, 10.3 is better but 
it's still pretty bad when compared to other unixen. It probably has 
something to do with the way OSX overcommits memory and swapspace, for 
which it apparently uses a different algorithm than FreeBSD or Linux.

I wouldn't be surprised if the bittorrent problem report in this thread 
was due to being low on diskspace. And that could also be true for the 
original error report that sparked this discussion.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] .pydistutils.cfg (was: pychecker)

[Jack Jansen]

Gosh,
I'd never even heard of .pydistutils.cfg. I've added a note to the FAQ 
pointing to it.

Then I looked at the distutils code, and noticed that there's also an 
optional distutils.cfg inside the package. So that made me wonder: we 
could install a symlink in 
/System/yaddayaddayadda/lib/python2.3/distutils/distutils.cfg that 
points to, say, /Library/Python/2.3/distutils.cfg, and put an 
(admin-editable) file there that directs scripts tot the right place 
system wide (/usr/local/bin by default, probably).
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.2, 1.3

[Jack Jansen]

On 2-jan-05, at 22:35, Bob Ippolito wrote:
On 2-jan-05, at 4:40, Bob Ippolito wrote:
+SCRIPT=#!/bin/sh
+export MACOSX_DEPLOYMENT_TARGET=10.3
+exec %s [EMAIL PROTECTED]
This script should check to see if MACOSX_DEPLOYMENT_TARGET is 
already set.  If I have some reason to set 
MACOSX_DEPLOYMENT_TARGET=10.4 for compilation (say I'm compiling an 
extension that requires 10.4 features) then I'm going to have some 
serious problems with this fix.
I was going to do that, but then I thought it didn't make any sense, 
because this script is *only* used in the context of Apple-provided 
Python 2.3. And setting MACOSX_DEPLOYMENT_TARGET to anything other 
than 10.3 (be it lower or higher) while compiling an extension for 
Apple's 2.3 is going to produce disappointing results anyway.

But, if I've missed a use case, please enlighten me.
You're right, of course.  I had realized that I was commenting on the 
fixpython script after I had replied, but my concern is still 
applicable to whatever solution is used for Python 2.4.1.  Anything 
lower than 10.3 is of course an error, in either case.
2.4.1 will install this fix into Apple-installed Python 2.3 (if 
applicable, i.e. if you're installing 2.4.1 on 10.3), but for its own 
use it will have the newer distutils, which understands that it needs 
to pick up MACOSX_DEPLOYMENT_TARGET from the Makefile, so it'll never 
see these scripts.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] Testers needed again: Fix installer 1.2

[Jack Jansen]

There's yet another new version of the Python 2.3 fix installer 
available: http://www.cwi.nl/~jack/macpython/JaguarPythonFix.dmg.

This one should also make C++ extensions build correctly again with 
apple-installed Python 2.3 on 10.3, after installing a later framework 
build.

Please let me know whether it works, especially with real C++ 
extensions (I only tried a toy extension).

And, for the record, I used Ronalds solution of using driver scripts 
for gcc and g++ that set the MACOSX_DEPLOYMENT_TARGET environment 
variable before running the compiler.
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

Re: [Pythonmac-SIG] The PantherPythonFix installer and C++ extensions

[Jack Jansen]

On 30-dec-04, at 21:01, Bob Ippolito wrote:
On Dec 30, 2004, at 2:52 PM, Ronald Oussoren wrote:
On 30-dec-04, at 18:49, Bob Ippolito wrote:
On Dec 30, 2004, at 11:44 AM, Jack Jansen wrote:
On 30-dec-04, at 10:02, Ronald Oussoren wrote:
In the quick-and-dirty-hacks category: you could write two simple 
shell-scripts that start the compiler with the right environment 
variables:

run-cc:
#!/bin/sh
env MACOSX_DEPLOYMENT_TARGET=10.3 gcc [EMAIL PROTECTED]
run-c++:
#!/bin/sh
env MACOSX_DEPLOYMENT_TARGET=10.3 gcc [EMAIL PROTECTED]
Here's an even better idea (I think), please think about whether it 
would fly:
In the Makefile we not only change LDSHARED and BLDSHARED to start 
with  env MACOSX_DEPLOYMENT_TARGET=10.3, but also CXX. That'll 
teach distutils to fiddle with our command lines:-)

Only question is: would this have any adverse side efffects?
Same problem.  If you replace the first word, you'll end up with 
either g++ gcc... or g++ MACOSX_DEPLOYMENT_TARGET=10.3 gcc... 
depending on whether env was used or not.
Wouldn't you end up with 'env MAC.. gcc' when linking c++ extensions? 
distutils changes the first word which is 'env' in either case.
Oh.. right.  But then given a bunch of .o files, it will probably not 
link in libstdc++.  Who knows what SciPy will do with Fortran...
Sigh, you're right. Which leaves two options:
1. Always use g++ to link in LDSHARED (in addition to the env tricks 
above). Would this have any adverse consequences?
2. Use Ronald's idea of wrapper scripts for both gcc and g++. We'd have 
to come up with decent names, though (so that if they're accidentally 
deleted the user may at least have an idea what they were supposed to 
do), maybe something like macpy23-gcc and macpy23-g++? Also, we'd need 
a place to put them. /Library/Python/2.3-PythonPantherFix? 
/System/yaddayaddayadda/python2.3/config/PythonPantherFix? Other ideas?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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

[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2

[Jack Jansen]

On 29-dec-04, at 4:35, Bob Ippolito wrote:
This is the wrong fix.  Distutils is dumber than you think.  This 
patch just breaks C++ compilation in a different way.  The correct 
solution is a patch to distutils of some kind.

from distutils/unixccompiler.py:174
if target_lang == c++ and self.compiler_cxx:
linker[0] = self.compiler_cxx[0]
self.spawn(linker + ld_args)
linker is the variable expanded LDSHARED (or whatever comes out of 
sysconfig.customize_compiler).
Bah!
Any suggestions as to what to do to get c++ compilation fixed?
Also, could you point me to a readily available extension package that 
uses c++?
--
Jack Jansen, [EMAIL PROTECTED], http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

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