pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Bob I. <bo...@re...>]

On Friday, Sep 5, 2003, at 12:15 America/New_York, Ronald Oussoren 
wrote:

>
> On 5 sep 2003, at 18:06, Just van Rossum wrote:
>
>> Dinu Gherman wrote:
>>
>>> Yes, that's probably the best thing to do. I sniffed more into
>>> bundlebuilder now. On 2.3 it seems to use a modulefinder, ok... I
>>> wasn't quite aware how cool it is!
>>
>> Actually, it does so with 2.2 as well, provided modulefinder.py is
>> installed. The only thing it can't use with 2.2 is zipimport, so 2.2
>> .app bundles are somewhat larger.
>>
>> Ronald: I think modulefinder.py should be included with PyObjC in
>> MPCompat, next to bundlebuilder.py and plistlib.py. Would you agree?
>
> I do, please check it in. The --standalone option is very usefull.
>
> BTW. I don't think useing 'whatever python the user has installed' 
> would be useful, unless you don't test applications before releasing 
> them :-)

Yeah, other than saving bandwidth there is no good reason to NOT 
include a tested and working version of Python with your executable.

You can say on the distribution page:
	download SMALLER VERSION if you have OS X 10.3 installed, or have 
installed MacPython 2.3 yourself in OS X 10.2.X
	download LARGER VERSION otherwise

Most people have bandwidth to spare these days.  On the distribution 
end, there's always SourceForge (assuming you're an open source 
developer).

It would be interesting if SMALLER VERSION would be able to detect if 
it is running on the proper system (maybe a C bootstrap, or python 2.2) 
before doing anything, and if it's not running on a capable system then 
it would pop up a dialog box with instructions for how to download the 
LARGER version or install MacPython 2.3.

-bob

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Ronald O. <ous...@ci...>]

On 5 sep 2003, at 18:06, Just van Rossum wrote:

> Dinu Gherman wrote:
>
>> Yes, that's probably the best thing to do. I sniffed more into
>> bundlebuilder now. On 2.3 it seems to use a modulefinder, ok... I
>> wasn't quite aware how cool it is!
>
> Actually, it does so with 2.2 as well, provided modulefinder.py is
> installed. The only thing it can't use with 2.2 is zipimport, so 2.2
> .app bundles are somewhat larger.
>
> Ronald: I think modulefinder.py should be included with PyObjC in
> MPCompat, next to bundlebuilder.py and plistlib.py. Would you agree?

I do, please check it in. The --standalone option is very usefull.

BTW. I don't think useing 'whatever python the user has installed' 
would be useful, unless you don't test applications before releasing 
them :-)

Ronald

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> Yes, that's probably the best thing to do. I sniffed more into
> bundlebuilder now. On 2.3 it seems to use a modulefinder, ok... I
> wasn't quite aware how cool it is!

Actually, it does so with 2.2 as well, provided modulefinder.py is
installed. The only thing it can't use with 2.2 is zipimport, so 2.2
.app bundles are somewhat larger.

Ronald: I think modulefinder.py should be included with PyObjC in
MPCompat, next to bundlebuilder.py and plistlib.py. Would you agree?

Just

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Dinu G. <gh...@da...>]

Just van Rossum:

> When he wrote """When I tried to run it on my Mac (10.2.6) by
> double-clickign the application, it started and then closed without any
> screen coming up""" I immediately thought: his /usr/bin/python is 
> broken
> or gone. We'll never know for sure until we see what's in his
> Console.app.

That's (at least partly) entirely my fault, so let's ignore that...

> For end user apps, the best thing to do is INCLUDE the Python you're
> testing and building with with your app bundle. Luckily bundlebuilder
> makes this very easy. Use --standalone, with --strip to reduce the size
> of the bundle. Using Python 2.3 enables zipimport, making your .app
> smaller yet. I built a tiny standalone PyObjC app today, and compressed
> with StuffIt it's a 1 meg download. This includes a (stripped down
> version of) Python.framework. "python2.3 buildapp.py --standalone
> --strip build" was all there was to it.

Yes, that's probably the best thing to do. I sniffed more into
bundlebuilder now. On 2.3 it seems to use a modulefinder, ok...
I wasn't quite aware how cool it is!

But... when creating two vanilla PB projects from the PyCocoaApp
and PyCocoaDocApp templates and adjusting the buildapp.py script
as below (run with python buildapp.py --standalone --strip build)
I get a working app only for the single document version. The multi-
document version launches, but never shows any window. Any idea?
What's the role of the myseterious Main.py files in some of the
sample projects?

Thanks,

Dinu

PS: I think "#! /usr/bin/env python" should be really preferred
     over "#! /usr/local/bin/python"...


#! /usr/bin/env python

import os
from bundlebuilder import buildapp

src = [ fn for fn in os.listdir('.')
         if fn.endswith('.py') and fn not in ('buildapp.py',) ]

buildapp(
	name = "TestTest2",
	mainprogram = "__main__.py",
	resources = ["English.lproj"] + src,
	nibname = "MainMenu",
)

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> The person uses Fink Python 2.3 on 10.2.6, so I think that if he
> never touched his /usr/bin/python

When he wrote """When I tried to run it on my Mac (10.2.6) by
double-clickign the application, it started and then closed without any
screen coming up""" I immediately thought: his /usr/bin/python is broken
or gone. We'll never know for sure until we see what's in his
Console.app.

[ ... ]
> The real question for me is: given multiple options for locations
> and versions of installed Python interpreters on OS X, is there
> any possibility to deploy an application that has the following
> properties:
> 
>    1. it finds and uses the one Python interpreter if there is
>       only one,
> 
>    2. it can be told at launch time or via some kind of config
>       file before launch time which interpreter to use,
> 
>    3. it makes its own "best choice" for 2.
> 
> I think nobody wants to maintain different packages for people be-
> longing to either Fink-, Apple-, Mac-Python and any other camps.
> And for testing with different interpreters (even of the same camp)
> this would also be very useful.

It's moderately safe to make your app dependent on Jag's 2.2 (most
things should work when running under Panther, but you can't know for
sure. It's safe if Jaguar is all you need to support (unless someone
breaks his sistem by messing with /usr/bin/python).

Extension modules are not always compatible between Python versions. Due
to sheer luck it appears that extension modules linked against a flat
unix build also work when used with a framework build, but the other way
round does not work.

If you really want to use an installed version, you should just specify
exactly which one.

For end user apps, the best thing to do is INCLUDE the Python you're
testing and building with with your app bundle. Luckily bundlebuilder
makes this very easy. Use --standalone, with --strip to reduce the size
of the bundle. Using Python 2.3 enables zipimport, making your .app
smaller yet. I built a tiny standalone PyObjC app today, and compressed
with StuffIt it's a 1 meg download. This includes a (stripped down
version of) Python.framework. "python2.3 buildapp.py --standalone
--strip build" was all there was to it.

Just

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Dinu G. <gh...@da...>]

Just van Rossum:

> Zachery Bir wrote:
>
>> No doubt, but I think Dinu's pointing out that his friend prefers
>> using /usr/local/bin/python2.3 (or the like)
>
> If you're shipping an app that is meant to run with the Apple-privided
> 2.2, it should be run with that. Why would an end user have anything to
> say about that? Or do I still miss the point of the question? Quite
> possible, since I have trouble thinking clearly again today...

The person uses Fink Python 2.3 on 10.2.6, so I think that if he
never touched his /usr/bin/python it shouldl still be a more or
less broken Python 2.1, but I'll sort this out... Anyway...

The real question for me is: given multiple options for locations
and versions of installed Python interpreters on OS X, is there
any possibility to deploy an application that has the following
properties:

   1. it finds and uses the one Python interpreter if there is
      only one,

   2. it can be told at launch time or via some kind of config
      file before launch time which interpreter to use,

   3. it makes its own "best choice" for 2.

I think nobody wants to maintain different packages for people be-
longing to either Fink-, Apple-, Mac-Python and any other camps.
And for testing with different interpreters (even of the same camp)
this would also be very useful.

Dinu

--
Dinu C. Gherman
......................................................................
"I am a gentlemen: I live by robbing the poor." (George Bernard Shaw)

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Just v. R. <ju...@le...>]

Zachery Bir wrote:

> No doubt, but I think Dinu's pointing out that his friend prefers
> using /usr/local/bin/python2.3 (or the like)

If you're shipping an app that is meant to run with the Apple-privided
2.2, it should be run with that. Why would an end user have anything to
say about that? Or do I still miss the point of the question? Quite
possible, since I have trouble thinking clearly again today...

Just

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Zachery B. <zb...@ur...>]

On Friday, September 5, 2003, at 09:25 AM, Just van Rossum wrote:

> Apps built with bundlebuilder.py also hard-wire /usr/bin/python, but
> only as the #! line of the bootstrap script. If someone _deletes_
> /usr/bin/python, he/she has a broken system. People should simply not
> touch /usr/bin, period.

No doubt, but I think Dinu's pointing out that his friend prefers using 
/usr/local/bin/python2.3 (or the like)

Zac

Re: [Pyobjc-dev] Detecting Python interpreters on startup

[Just v. R. <ju...@le...>]

Dinu Gherman wrote:

> I got the following request, which makes me wonder how the one Python
> interpreter is located running PyObjC applications?
> 
>  > I was very impressed with the movie of reSTedit. As I use reST all
>  > the time, I down-loaded it, When I tried to run it on my Mac
>  > (10.2.6) by double-clickign the application, it started and then
>  > closed without any screen coming up. I normally run Python 2.3 via
>  > XDarwin (a Fink load) but I do have Python 2.2.1 in my
>  > Applications.
> 
> In my bin-python-main.py (which might not be the newest one) I found
> the following snippet:
> 
>      ## bin-python-main.py
> 
>      // figure out which python interpreter to use
>      NSString *pythonBinPath = [[NSUserDefaults standardUserDefaults] 
> stringForKey: @"PythonBinPath"];
>      pythonBinPath = pythonBinPath ? pythonBinPath :
@"/usr/bin/python";
> 
> Is this hardwiring /usr/bin/python as the one interpreter to use? Or
> has this been determined at "project instantiation time" using the
> Python-Cocoa Application template?
> 
> What is the general policy in chosing between possibly many installed
> Python interpreters and/or can this decission be delayed until the
> launch time of an application and how?

Apps built with bundlebuilder.py also hard-wire /usr/bin/python, but
only as the #! line of the bootstrap script. If someone _deletes_
/usr/bin/python, he/she has a broken system. People should simply not
touch /usr/bin, period.

Just

[Pyobjc-dev] =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoISEjNTIvIzlAaUt8MV8+WjVyTS08fUZ+Ol9CcCVTJTglTSU5JUElYyVzJTkhKiM4IzgbKEI=?=

[<sa...@cr...>]

＜事業者＞国際身元保証受託協会＜特定商取引法に基づく表示です＝
受信拒否す場合は、 http://www12.ocn.ne.jp/~hosyou/deny.htmlでお願いします。他の表示事項（取引条件等）は法律に従いホームページに表示してあります。＞　http://www12.ocn.ne.jp/~hosyou/　　
　　　　　　　　　　　　　　☆☆☆★☆☆☆★☆☆☆★☆☆☆
 
欲しかったのは
　　　　「目的達成」のための「５億９千万円か保証証券」それとも両方
 
【５億９千万円証拠有収入在宅保証証券ビジネス権利】特別優遇発売中
　　　　　　　　　　　　　　☆★--◇--★-◆
　　　　　　【２億円・３億円・５億９千万円等の収入者続出】
　　　貴方様も【証拠有ビック収入ビジネスチャンス】のご検討を！！　　
　　　　　　　　
　　　　　　　　　　　物的証拠を見る確認する迄は
　　　　何事も、騙し騙されの世の中です・信用しないで下さい。
☆☆☆★☆☆☆★☆☆☆★☆☆☆★☆☆☆★☆☆☆★☆☆☆★☆☆
 
　　　『５億９千万円証拠有収入在宅ビジネス事業経営権利』
　　　　＝２０年有効・インターネット・葉書・FAXで出来る＝
◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◆◇◆◇◆◇◆◇◆◇

　　あの時、１億円があったら・あのとき、２億円の保証があったら
　　　　今は、最高なのに！！今からでも遅くありません！！
　　／＿／＿／＿／＿／＿／＿／＿／＿／＿／＿／＿／＿／＿／＿／ 
■日本で初めて当協会から３７年前に【保証証券保証】を先進国を参考に
　開発され、北海道〜沖縄迄全国的に拡大しています。
■裁判と同じ証拠主義を継続して３７年は信用の原点・証拠見て確認する
　までは何事も信用しないは安全・成功の基礎。
■東京高等裁判所の判決書・３億、５億９千万円の銀行印有振込書・
　福祉事務所から保証関連書・他「物的証拠」を見せます・見てください
　確認して下さい」『それまでは信用ないで下さい・こんなウマイ話があ
　るかと疑って下さい』物的証拠は嘘をつけません。
　保証証券通信販売事業を「証拠から開業出来ます」保証の責任はありま
　せん。
■保証証券発行元の全国信用身元保証受託協会が全責任を持ちます。

高裁判決書が物的証拠・判決書見せます・見る迄は信用しないで下さい。
　☆〜〜〜〜〜〜〜☆〜〜〜〜〜〜☆〜〜〜〜〜〜☆〜〜〜〜〜☆

資料請求は　 http://www12.ocn.ne.jp/~hosyou/　から３億円への一歩
　
　　　　［５億９千万円証拠有在宅保証ビジネス］を 裏付ける
物的証拠を見てから、嘘か誠かは証拠次第！
　　　　　　　　　　　　　　証拠確認迄は信用しないが何事も成功の秘訣！
☆〜〜〜〜〜〜〜☆〜〜〜〜〜〜☆〜〜〜〜〜〜☆〜〜〜〜〜☆
　【保証証券】大好評ネトで販売・人助けは不況関係ない好況は当然　　
 　『保証の悲劇の肩代わり・防止の保証証券』は社会福祉証券です。

△福祉関係からの要請（生活保護者の保証ー身内が嫌っている保証を無
　条件で社会の為に保証引き受け）で「保証証券」は大好評発売中!
△論より証拠は当然の格言△悩むより証拠で確信△証拠が無いと疑いは
　解決出来ないのは今の常識です。騙されたく無いなら証拠主義で！！
　

[Pyobjc-dev] Detecting Python interpreters on startup

[Dinu G. <gh...@da...>]

Hi,

I got the following request, which makes me wonder how the one Python
interpreter is located running PyObjC applications?

 > I was very impressed with the movie of reSTedit. As I use reST all
 > the time, I down-loaded it, When I tried to run it on my Mac (10.2.6)
 > by double-clickign the application, it started and then closed without
 > any screen coming up. I normally run Python 2.3 via XDarwin (a Fink
 > load) but I do have Python 2.2.1 in my Applications.

In my bin-python-main.py (which might not be the newest one) I found the
following snippet:

     ## bin-python-main.py

     // figure out which python interpreter to use
     NSString *pythonBinPath = [[NSUserDefaults standardUserDefaults] 
stringForKey: @"PythonBinPath"];
     pythonBinPath = pythonBinPath ? pythonBinPath : @"/usr/bin/python";

Is this hardwiring /usr/bin/python as the one interpreter to use? Or
has this been determined at "project instantiation time" using the
Python-Cocoa Application template?

What is the general policy in chosing between possibly many installed
Python interpreters and/or can this decission be delayed until the
launch time of an application and how?

Thanks,

Dinu

--
Dinu C. Gherman
......................................................................
"Political satire became obsolete when Henry Kissinger was awarded
the Nobel Peace Prize." (Tom Lehrer)

Re: [Pyobjc-dev] unittests for C code

[Ronald O. <ous...@ci...>]

On 3 sep 2003, at 16:36, Ronald Oussoren wrote:

> Hi,
>
> I just ran into a problem w.r.t. converting some structs to/from 
> Objective-C. It turns out that the code in objc_support.m isn't 
> entirely correct, especially for structs that are not carefully layed 
> out by the programmer.
>

[...]

> Is there pre-existing code for this, or should I just write this from 
> scratch. The problem looks easy enough to just write from scratch.

I wrote some crude scaffolding from scratch. Thanks a hackish python 
module the tests get invoked from within the pyunit framework, which 
means they get run with Scripts/allTestsTogether.py.

I won't check this in until I fix the issues that made me start on 
these unittests, and there are some issues with the code that I want to 
fix.

>
> I'd also like opionions regarding delaying the 1.0 release because of 
> this problem.

-1 on delaying the release for this.

Primary reason: NSInvocation also has problems with some of these 
structs (rader bug #3407625). And this is probably a non-issue for most 
users, nobody complained before.

I'll try to get 1.0rc2 out tonight.

Ronald

[Pyobjc-dev] unittests for C code

[Ronald O. <ous...@ci...>]

Hi,

I just ran into a problem w.r.t. converting some structs to/from 
Objective-C. It turns out that the code in objc_support.m isn't 
entirely correct, especially for structs that are not carefully layed 
out by the programmer.

Specifically:

	struct Foo {
		int i;
		double d;
		short  s[5];
	};

The sizeof(struct Foo) is different from 
objc_sizeof_type(@encode(struct Foo)). The best way to test if this 
code is correct would be to write some unittests in C.

I'm thinking of adding a extension module containing those unittests. 
Every test would be in a function, and would raise AssertionError when 
the tests fails, just like the code in unittest.py. A header-file would 
create some usefull definitions that make it easier to write these 
tests.

The tests I'll add:
- Convert Python to struct, and check the struct value (and likewise 
for other ObjC values)
- Convert struct to Python, and check the Python value ( ,,, )
- Check objc_sizeof_type, objc_alignof_type, ...

Adding these as unittests makes debugging slightly easier, I currently 
get core-dumps in test_methods2 (when I add testcases for the struct 
mentioned above).

Is there pre-existing code for this, or should I just write this from 
scratch. The problem looks easy enough to just write from scratch.

I'd also like opionions regarding delaying the 1.0 release because of 
this problem.

Ronald

[Pyobjc-dev] Re: Bundle loading hooks?

[Michael H. <mw...@py...>]

Ronald Oussoren <ous...@ci...> writes:

> However, if you start querying with the NSBundle +bundleForClass:, all
> classes defined in Python seem to be defined in the main bundle even
> if they are actually defined in another (plug-in) bundle. Simularly,
> NSBundle -classNamed: will only find the class if you use the
> mainBundle. This is a problem for us, because this means Interface
> Builder cannot find the classes in a palette that has been defined in
> Python.

Did you ever get any response to this?

> Does anyone know a documented way to get the administration right? I
> got the IB palette working with a dirty hack: when the python plugin
> it loaded it looks for the NSBundle that is associated with its bundle
> and changes the 'isa' pointer of that NSBundle instance to a subclass
> of NSBundle that overrides classNamed. That doesn't look like the
> proper solution to me :-)

I still can't get this to work :-( The palette appears, but you still
get "can't find class" errors in the logs...

Cheers,
mwh

-- 
  ARTHUR:  Why should he want to know where his towel is?
    FORD:  Everybody should know where his towel is.
  ARTHUR:  I think your head's come undone.
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 7

[Pyobjc-dev] Re: My application doesn't dock

[Bob S. <rsw...@tr...>]

Just - Replacing bundlebuilder.py with the version you sent did, indeed fix
the problem.  Thanks!

----- Original Message ----- 
From: "Just van Rossum" <ju...@le...>
To: "Bob Swerdlow" <rsw...@tr...>
Cc: <pyo...@li...>
Sent: Friday, August 29, 2003 12:14 PM
Subject: Re: My application doesn't dock


> Bob Swerdlow wrote:
>
> > Just - I upgraded to PyObjC1.0b1 but this problem does not seem to be
> fixed.
> >
> > In my buildapp.py, I have:
> >
> > infoPlist = Plist(
> >     CFBundleDevelopmentRegion='English',
> >     CFBundleExecutable='python',
> >     CFBundleGetInfoString='Goombah 0.2',
> >     CFBundleHelpBookFolder='Goombah Help',
> >     CFBundleHelpBookName='Goombah Help',
> >     CFBundleIconFile='Goombah.icns',
> >     CFBundleIdentifier='com.transpose.goombah',
> >     CFBundleInfoDictionaryVersion='6.0',
> >     CFBundleName='Goombah',
> >     CFBundlePackageType='APPL',
> >     CFBundleShortVersionString='PreRelease',
> >     CFBundleSignature='????',
> >     CFBundleVersion='0.2',
> >
> >     NSHumanReadableCopyright='Copyright 2003 Transpose, LLC  All
> rights
> > reserved
> > ..',
> >     NSMainNibFile='MainMenu',
> >     NSPrincipalClass='NSApplication'
> > )
> >
> > Is there anything I need to change or do I need a newer version of
> > PyObjC? I know that 1.0 is coming, but I don't know when.
>
> Hm, it seems this was fixed after 1.0b1 was released. Or rather, it may
> have been fixed before in the Python tree, but the one shipping with
> PyObjC 1.0b1 is "old". This all assumes you're using Python 2.2, not
> 2.3, which should contain the right version, and PyObjC's setup.py only
> installs bundlebuiler if it's not already there.
>
> I've attached the latest version of bundlebuilder.py, please let me know
> that I'm not dreaming...
>
> Just

[Pyobjc-dev] Re: My application doesn't dock

[Bob S. <rsw...@tr...>]

Just - I upgraded to PyObjC1.0b1 but this problem does not seem to be fixed.

In my buildapp.py, I have:

infoPlist = Plist(
    CFBundleDevelopmentRegion='English',
    CFBundleExecutable='python',
    CFBundleGetInfoString='Goombah 0.2',
    CFBundleHelpBookFolder='Goombah Help',
    CFBundleHelpBookName='Goombah Help',
    CFBundleIconFile='Goombah.icns',
    CFBundleIdentifier='com.transpose.goombah',
    CFBundleInfoDictionaryVersion='6.0',
    CFBundleName='Goombah',
    CFBundlePackageType='APPL',
    CFBundleShortVersionString='PreRelease',
    CFBundleSignature='????',
    CFBundleVersion='0.2',

    NSHumanReadableCopyright='Copyright 2003 Transpose, LLC  All rights
reserved
.',
    NSMainNibFile='MainMenu',
    NSPrincipalClass='NSApplication'
)

Is there anything I need to change or do I need a newer version of PyObjC?
I know that 1.0 is coming, but I don't know when.

Thanks,
Bob

----- Original Message ----- 
From: "Just van Rossum" <ju...@le...>
To: "Bob Swerdlow" <rsw...@tr...>
Cc: <coc...@li...>
Sent: Thursday, July 10, 2003 10:48 AM
Subject: Re: My application doesn't dock


> Bob Swerdlow wrote:
>
> > I'm building a new Cocoa application using PyObjC.  When running, the
> > icon appears in the dock correctly, but if the user drags the
> > application icon to the dock, it will only go in the "document" area,
> > not the "application" area.
>
> This appears to be a bug in bundlebuilder.py, so is
> Python/PyObjC-specific. I will check in a fix shortly.
>
> Just
> _______________________________________________
> cocoa-dev mailing list | coc...@li...
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>

[Pyobjc-dev] Bundle loading hooks?

[Ronald O. <ous...@ci...>]

Hi,

I'm one of the authors of PyObjC, which is a Python extension module 
that allows you to write Cocoa classes in Objective-C. This works 
pretty well for normal code, but we ran into a problem w.r.t. dynamicly 
loaded bundles (plugins) and the NSBundle methods 'classNamed:' and 
'bundleForClass:'.

When you define a subclass of an Objective-C class in Python, the 
PyObjC module automaticly creates a Objective-C class for you and 
registers that with the runtime. That is, it creates the right C 
datastructures and tells the runtime about these using objc_addClass 
and the like. As mentioned before, this works just fine, these classes 
can be used in NIB files and the classes are found using 
NSClassFromString.

However, if you start querying with the NSBundle +bundleForClass:, all 
classes defined in Python seem to be defined in the main bundle even if 
they are actually defined in another (plug-in) bundle. Simularly, 
NSBundle -classNamed: will only find the class if you use the 
mainBundle. This is a problem for us, because this means Interface 
Builder cannot find the classes in a palette that has been defined in 
Python.

Does anyone know a documented way to get the administration right? I 
got the IB palette working with a dirty hack: when the python plugin it 
loaded it looks for the NSBundle that is associated with its bundle and 
changes the 'isa' pointer of that NSBundle instance to a subclass of 
NSBundle that overrides classNamed. That doesn't look like the proper 
solution to me :-)

Ronald

Re: [Pyobjc-dev] Cocoa/Objective-C equiv to __del__?

[Ronald O. <ous...@ci...>]

On Friday, 29 August 2003, at 15:07, Zachery Bir wrote:

> On Tuesday, August 19, 2003, at 02:02 PM, Zachery Bir wrote:
>
>> Thanks, yeah, looks like the example apps use __del__ (with comments 
>> that say: "dealloc in Obj-C" :)
>
> Hmm... Okay, I've got a __del__ method in my application's delegate 
> class, and I'm trying to clean up after myself. It doesn't seem to get 
> called, though. I've put an 'import pdb;pdb.set_trace()' in the 
> __del__ method, and I never get the prompt - it works just about 
> everywhere else, when I need that kind of run-time introspection.

I don't know if the application's delegate is ever cleaned up unless 
you do so yourself. That might explain why your __del__ method isn't 
called.

>
> Question: Is it problematic (or even bad programming/design) to have 
> the same class as the delegate for the Application, the Window, and an 
> NSTableView? I can imagine that it might be a bit overloaded, but it 
> does seem to do stuff for each of those in its way. I'm not sure how I 
> could share all this information between several delegate classes, but 
> this has been a bit of an accretive project ;)

The real Cocoa guru's probably live somewhere else, but for what it's 
worth: I also do this is simple programs.  Keeping the 
controllers/delegates for a window together keeps things simple.

Ronald

Re: [Pyobjc-dev] Re: interface builder queries

[Ronald O. <ous...@ci...>]

On Friday, 29 August 2003, at 14:10, Ronald Oussoren wrote:
>
> My current idea for a hack to implement this is to dynamicly replace 
> the 'isa' pointer of Python based bundles from that +load method. As 
> longs as IB uses [bundle classNamed:] we would get a working 
> situtation (although using an extremely ugly hack).
>
>
that works al right.

If you use the attached pluginbuilder.py and add the following code to 
init_objc in Modules/objc/module.m you can build a IB.palette that 
actually loads. I haven't checked if you can actually do anything in 
the plugin.

         /* Python based plugin bundles currently use only 
PyObjClass_GetClass,
          * add that seperately to avoid distributing pyobjc-api.h for 
now
          */
         {
                 PyObject* v = 
PyCObject_FromVoidPtr((void*)(PyObjCClass_GetClass), NULL);
                 if (v == NULL) return;

                 PyDict_SetItemString(d, "__C_GETCLASS__", v);
         }


Warning: this is a hack and I don't know yet if I want to see this code 
anywhere near our repository.

Ronald

Re: [Pyobjc-dev] Cocoa/Objective-C equiv to __del__?

[Zachery B. <zb...@ur...>]

On Tuesday, August 19, 2003, at 02:02 PM, Zachery Bir wrote:

> Thanks, yeah, looks like the example apps use __del__ (with comments 
> that say: "dealloc in Obj-C" :)

Hmm... Okay, I've got a __del__ method in my application's delegate 
class, and I'm trying to clean up after myself. It doesn't seem to get 
called, though. I've put an 'import pdb;pdb.set_trace()' in the __del__ 
method, and I never get the prompt - it works just about everywhere 
else, when I need that kind of run-time introspection.

Question: Is it problematic (or even bad programming/design) to have 
the same class as the delegate for the Application, the Window, and an 
NSTableView? I can imagine that it might be a bit overloaded, but it 
does seem to do stuff for each of those in its way. I'm not sure how I 
could share all this information between several delegate classes, but 
this has been a bit of an accretive project ;)

Thanks,

Zac

[Pyobjc-dev] Re: interface builder queries

[Michael H. <mw...@py...>]

Ronald Oussoren <ous...@ci...> writes:

> On Friday, 29 August 2003, at 13:51, Michael Hudson wrote:
>
>>> Thanks for reminding me of this issue. I had noticed this when
>>> building the preference panes, but didn't think this was very
>>> important at the time. I'll see what I can do about this, this may be
>>> a hard problem.
>>
>> It looks it.  There's this intriguingly named function
>> _NSBundleAddClassesAndNotify, but I don't think you're expected to
>> call it...
>
> Hmm, I hadn't looked at global functions yet. The private methods
> didn't look interesting.

I only found that one by accident in gdb :-)

>> Also, the feeling I get is that there's lot of hacking done to get
>> this sort of thing to work from Java, and it would probably take
>> someone from Apple to do the same for Python.  That may be too
>> pessimistic, though.
>
> We probably need support from Apple to get this to work reliably, I
> haven't found a documented API to register our classes.

Right.  Is cocoa-dev the place to ask?  (Although I susbscribed a few
days ago and the list seems to be mainly inhabited by people who can't
read documentation).

>> The nicest answer would be arrange for our bundle to load itself into
>> some subclass of NSBundle, but that doesn't look possible (and Mach-O
>> bundles don't even seem to have init sections, which rules out one
>> scary hack that occurred to me).
>
> They seem to have init sections, and you can use the +load method of
> classes as well. I use the latter to bootstrap Python based bundles,
> because I can get at the current bundle that way, which is handy for
> locating resources such as the python code.

Yeah, I've read & been playing with that code.

> My current idea for a hack to implement this is to dynamicly replace
> the 'isa' pointer of Python based bundles from that +load method. As
> longs as IB uses [bundle classNamed:] we would get a working
> situtation (although using an extremely ugly hack).

I actually tried this this morning :-) (probably not in an optimal
manner, but hey).

The problem is, I think, that IB does this:

bundle = [NSBundle bundleWithPath:...]
cls = [bundle classNamed:...]

NSBundle being the way it is, the loading of executable code (and
hence the executing of +[PyObjC_Bundle_SimpleIBPalette load]) happens
*inside* the call to -[NSBundle classNamed:].  So the 'isa' hacks are
too late.

Certainly, setting a breakpoint in gdb on
+[PyObjC_Bundle_SimpleIBPalette load] shows -[NSBundle classNamed:] in
+the backtrace.

> This seems to be the week for ugly hacks, I'm working on a full-screen
> application (using PyObjC of course) that uses pop-up buttons. Those
> don't work in full-screen mode, the pop-up menu seems to be behind my
> full-screen window. I've already filed a bug after someone else
> noticed he hadn't had any luck getting this to work and just avoids
> pop-up buttons. I haven't found a way to hack around this limitation
> :-(.

I saw your note to cocoa-dev about that...

Cheers,
mwh

-- 
  Not only does the English Language borrow words from other
  languages, it sometimes chases them down dark alleys, hits
  them over the head, and goes through their pockets.   -- Eddy Peters

Re: [Pyobjc-dev] Re: interface builder queries

[Ronald O. <ous...@ci...>]

On Friday, 29 August 2003, at 13:51, Michael Hudson wrote:

>> Thanks for reminding me of this issue. I had noticed this when
>> building the preference panes, but didn't think this was very
>> important at the time. I'll see what I can do about this, this may be
>> a hard problem.
>
> It looks it.  There's this intriguingly named function
> _NSBundleAddClassesAndNotify, but I don't think you're expected to
> call it...

Hmm, I hadn't looked at global functions yet. The private methods 
didn't look interesting.

>
> Also, the feeling I get is that there's lot of hacking done to get
> this sort of thing to work from Java, and it would probably take
> someone from Apple to do the same for Python.  That may be too
> pessimistic, though.

We probably need support from Apple to get this to work reliably, I 
haven't found a documented API to register our classes.

>
> The nicest answer would be arrange for our bundle to load itself into
> some subclass of NSBundle, but that doesn't look possible (and Mach-O
> bundles don't even seem to have init sections, which rules out one
> scary hack that occurred to me).

They seem to have init sections, and you can use the +load method of 
classes as well. I use the latter to bootstrap Python based bundles, 
because I can get at the current bundle that way, which is handy for 
locating resources such as the python code.

My current idea for a hack to implement this is to dynamicly replace 
the 'isa' pointer of Python based bundles from that +load method. As 
longs as IB uses [bundle classNamed:] we would get a working situtation 
(although using an extremely ugly hack).

This seems to be the week for ugly hacks, I'm working on a full-screen 
application (using PyObjC of course) that uses pop-up buttons. Those 
don't work in full-screen mode, the pop-up menu seems to be behind my 
full-screen window. I've already filed a bug after someone else noticed 
he hadn't had any luck getting this to work and just avoids pop-up 
buttons. I haven't found a way to hack around this limitation :-(.

Ronald

[Pyobjc-dev] Re: interface builder queries

[Michael H. <mw...@py...>]

Ronald Oussoren <ous...@ci...> writes:

> On vrijdag, 29 augustus 2003, at 11:51AM, Michael Hudson wrote:
>
>> Michael Hudson <mw...@py...> writes:
>>
>>> Michael Hudson <mw...@py...> writes:
>>>
>>>>> Python should also work, as long as IB is single threaded, see the
>>>>> EnvironmentPrefs example for a python based plugin. That's a plugin
>>>>> for System Preferences, but the mechanics should be simular for IB
>>>>> pallettes.
>>>>
>>>> Right, I'll see if I can blend an IBPalette example with the PyObjC
>>>> screensaver example.  I'll try to package it up for the Examples/
>>>> directory if I come up with anything useful.
>>>
>>> Well, after fixing what I think to be a couple of bugs in PyObjC, I've
>>> run into another problem.  I think.
>>>
>>> It seems interface builder uses [NSBundle classNamed:] to find the
>>> palette class, and my Python classes aren't showing up to this
>>> function (it shows up as the result to [NSBundle principalClass],
>>> though).
>>
>> This would seem to be because the objc runtime thinks that Python
>> classes are not dynamically loaded (fair enough, but it makes the task
>> at hand fairly tricky).
>>
>> It is odd that you have
>>
>>     NSBundle.bundleForClass(aBundle.principalClass()) != aBundle
>>
>> though.
>>
>> Still way over my depth,
>
> Welcome to the club :-)

:-)

> Thanks for reminding me of this issue. I had noticed this when
> building the preference panes, but didn't think this was very
> important at the time. I'll see what I can do about this, this may be
> a hard problem.

It looks it.  There's this intriguingly named function
_NSBundleAddClassesAndNotify, but I don't think you're expected to
call it...

Also, the feeling I get is that there's lot of hacking done to get
this sort of thing to work from Java, and it would probably take
someone from Apple to do the same for Python.  That may be too
pessimistic, though.

The nicest answer would be arrange for our bundle to load itself into
some subclass of NSBundle, but that doesn't look possible (and Mach-O
bundles don't even seem to have init sections, which rules out one
scary hack that occurred to me).

> BTW. I added some code to make it safe to call from Objective-C to
> python from any thread, including those without a Python threadstate,
> using the API defined in PEP311. The bad news is that I did this in a
> tree that contains Panther specific code ;-(.

The threadedness of IB doesn't seem to have caused any problems yet
(unless that turns out to be responsible for the crashes I saw in
PyObjC_GetClassList).

Cheers,
mwh

-- 
  at any rate, I'm satisfied that not only do they know which end of
  the pointy thing to hold, but where to poke it for maximum effect.
                                  -- Eric The Read, asr, on google.com

Re: [Pyobjc-dev] Re: breakage in CVS?

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> > I do not care a jot whether NSMakePoint is defined in Foundation,
> > AppKit or not at all.
> 
> That was quite obvious to me, maybe your mail got garbled on its way
> to the others :-)

Yes, it had indeed absolutely NOTHING to do with the fact that I usually
don't actually read the posts I reply to ;-)

Just

Re: [Pyobjc-dev] Re: breakage in CVS?

[Ronald O. <ous...@ci...>]

On Thursday, 28 August 2003, at 18:45, Michael Hudson wrote:

> I seem to be causing some confusion here.
>
> I do not care a jot whether NSMakePoint is defined in Foundation,
> AppKit or not at all.

That was quite obvious to me, maybe your mail got garbled on its way to 
the others :-)

>
> However, in the version of PyObjC I checked out today, when you import
> AppKit, *AppKit/__init__.py* tries to import NSMakePoint and friends
> from Foundation -- and fails.
>
> I'm not asking for someone to help, I'm asking for someone to fix it!
> Maybe Ronald missed a file in a check in?  That's what it looks like
> to me.

That's not it, the wrappers for those functions are generated when you 
build PyObjC (that's what 's happening after setup.py prints 
'Performing task: Generating wrappers & stubs').

Ronald