pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Re: OK, I'm already stymied.

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

Zachery Bir <zb...@ur...> writes:

> On Tuesday, May 6, 2003, at 06:34 AM, Gary Robinson wrote:
>
>> OK, Ronald and bbum, thanks for the quick responses.
>>
>> I was able to successfully
>>
>>     import Foundation
>>
>> so I guess my installation is OK after all.
>>
>> But I suggest updating the Tutorial
>> (Documentation/PyObjC/tutorial/tutorial.html) so that it urges the
>> user to
>> "import Foundation" rather than "import PyObjC" since the latter
>> won't work.
>
> I agree. Caught me at first, as well.

OK, another question: why is it done like this?

Cheers,
M.

-- 
  Ya, ya, ya, except ... if I were built out of KSR chips, I'd
  be running at 25 or 50 MHz, and would be wrong about ALMOST
  EVERYTHING almost ALL THE TIME just due to being a computer!
                                              -- Tim Peters, 30 Apr 97

Re: [Pyobjc-dev] Feedback needed for documentation

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

Ronald Oussoren:

> The most important target for a 1.0 release is providing good 
> documentation. To get things going I'd like to hear about problems 
> with our current documentation, and hopefully also some suggestions on 
> how to improve on it.
>
> Another important point I'd like to get feedback on is what new users 
> of PyObjC find hard when starting to use it, that might give us 
> pointers on how to improve the bridge itself as well as find items 
> that should be mentioned the introduction to PyObjC. Please mention if 
> you are/were new to Python and/or Cocoa.

Before starting giving feedback: isn't (wasn't) there a Wiki
to collect such pieces?

Dinu

--
Dinu C. Gherman
......................................................................
"It's clearly a budget. It's got a lot of numbers in it."
(George W. Bush, 5 May 2000)

Re: [Pyobjc-dev] OK, I'm already stymied.

[tmk <li...@ne...>]

Got bitten too. But some digging and remembering flattening discussion 
put me back to track.
I'm also going through the docs and taking note of what may need to be 
corrected. I'll post back my notes as a whole once I'm finished 
(hopefully sometimes this week).

Btw, I keep forgetting but HUGE kudos to whole the team for bringing us 
0.9 so far it looks incredibly cool.

= tmk =

On Tuesday, May 6, 2003, at 13:01 Europe/Brussels, Zachery Bir wrote:

> On Tuesday, May 6, 2003, at 06:34 AM, Gary Robinson wrote:
>
>> OK, Ronald and bbum, thanks for the quick responses.
>>
>> I was able to successfully
>>
>>     import Foundation
>>
>> so I guess my installation is OK after all.
>>
>> But I suggest updating the Tutorial
>> (Documentation/PyObjC/tutorial/tutorial.html) so that it urges the 
>> user to
>> "import Foundation" rather than "import PyObjC" since the latter 
>> won't work.
>
> I agree. Caught me at first, as well.
>
> Zac
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] OK, I'm already stymied.

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

Things to do for 0.9.1 ;-)

I also noticed the tutorial begins rather complicated with setting an
environment variable. This should not needed for nibclassbuilder, as
it's installed as a command line tool. Perhaps we should also install
bundlebuilder as a command line tool? Hm, and then there's the problem
that /usr/local/bin isn't on the path by default, which is where
nibclassbuilder bets installed, even for a python2.2 install.

Just

Re: [Pyobjc-dev] OK, I'm already stymied.

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

On Tuesday, May 6, 2003, at 06:34 AM, Gary Robinson wrote:

> OK, Ronald and bbum, thanks for the quick responses.
>
> I was able to successfully
>
>     import Foundation
>
> so I guess my installation is OK after all.
>
> But I suggest updating the Tutorial
> (Documentation/PyObjC/tutorial/tutorial.html) so that it urges the 
> user to
> "import Foundation" rather than "import PyObjC" since the latter won't 
> work.

I agree. Caught me at first, as well.

Zac

Re: [Pyobjc-dev] OK, I'm already stymied.

[Gary R. <gro...@tr...>]

OK, Ronald and bbum, thanks for the quick responses.

I was able to successfully

    import Foundation

so I guess my installation is OK after all.

But I suggest updating the Tutorial
(Documentation/PyObjC/tutorial/tutorial.html) so that it urges the user to
"import Foundation" rather than "import PyObjC" since the latter won't work.
I lost over an hour to that, and I'm on a race here to see how much I can
accomplish with PyObjC over the next few days -- that will determine whether
we use it for the project where considering!

But, your quick responses once I asked the question made a big difference.
Thanks again. Onward and upward!

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454


> From: Ronald Oussoren <ous...@ci...>
> Date: Tue, 6 May 2003 06:48:26 +0200
> To: Gary Robinson <gro...@tr...>
> Cc: <pyo...@li...>
> Subject: Re: [Pyobjc-dev] OK, I'm already stymied.
> 
> 
> On Tuesday, May 6, 2003, at 05:05 Europe/Amsterdam, Gary Robinson wrote:
> 
>> In the PyObjC tutorial, it says:
>> 
>>> 1. Create a work directory src. Check which Python you have installed
>>> PyObjC
>>> for, by running python and checking that import PyObjC works. If it
>>> does not
>>> work it could be that you have installed PyObjC for /usr/local/python
>>> but
>>> Apple's /usr/bin/python comes first in your $PATH. Make sure you use
>>> the right
>>> python whereever it says python in this tutorial.
>> 
>> I have run the PyObjC 0.9 installer.
>> 
>> I have both 2.3 and Apple's 2.2 installed.
>> 
>> Whether I am running python 2.2 or 2.3, the statement
>> 
>>     import PyObjC
>> 
>> fails with
>> 
>>     ImportError: No module named PyObjC
> 
> 
> That's right, PyObjC is only the name of the project not of packages we
> install :-). I'd start by browsing some of the example code (for
> example our tuturial). Use 'import Foundation' to access the Foundation
> classes (and functions/constants in that framework).
> 
> BTW. The installer only installs our packages for Apple's Python 2.2.
> To use PyObjC with Python 2.3b1 you have to install using the
> PackageManager (or just from source, the usual 'sudo python setup.py
> install' will do).
> 
> Ronald
> 

Re: [Pyobjc-dev] OK, I'm already stymied.

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

On Tuesday, May 6, 2003, at 05:05 Europe/Amsterdam, Gary Robinson wrote:

> In the PyObjC tutorial, it says:
>
>> 1. Create a work directory src. Check which Python you have installed 
>> PyObjC
>> for, by running python and checking that import PyObjC works. If it 
>> does not
>> work it could be that you have installed PyObjC for /usr/local/python 
>> but
>> Apple's /usr/bin/python comes first in your $PATH. Make sure you use 
>> the right
>> python whereever it says python in this tutorial.
>
> I have run the PyObjC 0.9 installer.
>
> I have both 2.3 and Apple's 2.2 installed.
>
> Whether I am running python 2.2 or 2.3, the statement
>
>     import PyObjC
>
> fails with
>
>     ImportError: No module named PyObjC


That's right, PyObjC is only the name of the project not of packages we 
install :-). I'd start by browsing some of the example code (for 
example our tuturial). Use 'import Foundation' to access the Foundation 
classes (and functions/constants in that framework).

BTW. The installer only installs our packages for Apple's Python 2.2. 
To use PyObjC with Python 2.3b1 you have to install using the 
PackageManager (or just from source, the usual 'sudo python setup.py 
install' will do).

Ronald

Re: [Pyobjc-dev] OK, I'm already stymied.

[<bb...@ma...>]

On Monday, May 5, 2003, at 20:05 US/Pacific, Gary Robinson wrote:
> Whether I am running python 2.2 or 2.3, the statement
>
>     import PyObjC
>
> fails with
>
>     ImportError: No module named PyObjC

There isn't a PyObjC Module -- it is flattened up into the regular 
import space by a magic file in site-packages.

Try:

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% /usr/bin/python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import Foundation
 >>>

[Pyobjc-dev] OK, I'm already stymied.

[Gary R. <gro...@tr...>]

In the PyObjC tutorial, it says:

> 1. Create a work directory src. Check which Python you have installed PyObjC
> for, by running python and checking that import PyObjC works. If it does not
> work it could be that you have installed PyObjC for /usr/local/python but
> Apple's /usr/bin/python comes first in your $PATH. Make sure you use the right
> python whereever it says python in this tutorial.

I have run the PyObjC 0.9 installer.

I have both 2.3 and Apple's 2.2 installed.

Whether I am running python 2.2 or 2.3, the statement

    import PyObjC

fails with 

    ImportError: No module named PyObjC

In python 2.2, I have
>>> sys.path
['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-darwin',
'/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload',
'/usr/lib/python2.2/site-packages',
'/usr/lib/python2.2/site-packages/PyObjC']


And, after installing PyObjC I do have
/usr/lib/python2.2/site-packages/PyObjC
on my disk.


So I'm mystified about why python 2.2 can't import PyObjC.

I want to use PyObjC with Apple's 2.2 python distribution.

Any insights would be most appreciated.




--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

[Pyobjc-dev] Change of plan

[Gary R. <gro...@tr...>]

Dear PyObjC'ers:

I had mentioned NOT using PyObjC for a project we're considering because I
didn't want to exclude OS X 10.1 users. (It's an app that could get a lot of
attention and propagate to a lot of machines quite quickly.) But I did some
research and found that the ratio of 10.2 to 10.1 users is probably in the
range of 9:1.

So, the upshot is that I am going to try to do a rough prototype of some
aspects of the app this week using PyObjC, after which my team will decide
if the project is feasible for us using PyObjC given the very short
timeframe we have available to do it.

At this point, I know virtually nothing about Cocoa programming (I am very
familiar with Python).

So it's going to be an interesting journey.

I may have some questions to ask here as the days go on.

Thanks for the input so far! :)

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] libffi on OSX 10.1

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

On Sunday, May 4, 2003, at 22:40 Europe/Amsterdam, Ronald Oussoren  
wrote:

> I got bored and installed 10.1.5 and the December 2001 developer tools  
> on a spare partition. I then tried to build python and pyobjc. The  
> former mostly succeeded (more on that on the MacPython list), but I  
> ran into some problems with pyobjc.
>
> First of all libffi won't build, seemingly due to a compiler bug:

I was too pessimistic, libffi does build it is just the libffi test  
program that won't build. If I work around that I can build PyObjC with  
libffi support.

Some unittests now pass, but most crash like this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x7081f0d4 in hashStr ()
(gdb) where
#0  0x7081f0d4 in hashStr ()
#1  0x701cee88 in __CFDictionaryFindBuckets1b ()
#2  0x70161d1c in CFDictionaryGetValue ()
#3  0x7081d154 in +[NSMethodSignature signatureWithObjCTypes:] ()
#4  0x00260310 in objcsel_descr_get (meth=0x8dc5e8, obj=0x0,  
class=0xbfffc218) at Modules/objc/selector.m:718
#5  0x10043710 in type_getattro (type=0x92f9e0, name=0x83dda0) at  
Objects/typeobject.c:2006
#6  0x0025d17c in class_getattro (self=0x92f9e0, name=0x83dda0) at  
Modules/objc/objc-class.m:421
#7  0x1003398c in PyObject_GetAttr (v=0x92f9e0, name=0x83dda0) at  
Objects/object.c:1241
...

test_nsnumber fails because of a change in the header of plist files:
Traceback (most recent call last):
   File "Lib/Foundation/test/test_nsnumber.py", line 107, in  
testPropertyList1
     self.assertEquals(data, PLIST)
   File  
"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
unittest.py", line 292, in failUnlessEqual
     raise self.failureException, \
AssertionError: '<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE  
plist SYSTEM  
"file://localhost/System/Library/DTDs/PropertyList.dtd">\n<plist  
version="0.9">\n<dict>\n\t<key>bool</key>\n\t<true/>\n\t<key>plain</ 
key>\n\t<integer>1</integer>\n</dict>\n</plist>\n' != '<?xml  
version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple  
Computer//DTD PLIST 1.0//EN"  
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist  
version="1.0">\n<dict>\n\t<key>bool</key>\n\t<true/>\n\t<key>plain</ 
key>\n\t<integer>1</integer>\n</dict>\n</plist>\n'

Re: [Pyobjc-dev] ANN: PyObjC 0.9

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

On Monday, May 5, 2003, at 15:19 Europe/Amsterdam, tmk wrote:

> Thanks for the correction bbum.
>
> One minor grip though the installer readme text states:
>
> ---
>
> Other than the python modules the installer also installs Project 
> Builder templates, some examples (in /Developer/Examples/PyObjC) and 
> documentation (in /Developer/Documentation/PyObjC).
>

Oops. To be honest, I thought all files were back in /Developer. Maybe 
we should update the installer (with only a fixed readme).

Ronald

Re: [Pyobjc-dev] ANN: PyObjC 0.9

[tmk <li...@ne...>]

Thanks for the correction bbum.

One minor grip though the installer readme text states:

---

Other than the python modules the installer also installs Project 
Builder templates, some examples (in /Developer/Examples/PyObjC) and 
documentation (in /Developer/Documentation/PyObjC).

;-)

= tmk =

On Monday, May 5, 2003, at 04:53 Europe/Brussels, bb...@ma... wrote:

> On Sunday, May 4, 2003, at 17:18 US/Pacific, tmk wrote:
>> After installing the 0.9 release downloaded from sourceforge I was 
>> astonished not to find anything under /Developer/Examples...
>> It seems everything that should go under /Developer/... actually went 
>> under /Library/Developer/... instead!
>
> Ideally, nothing would be installed in /Developer/ directly and 
> everything should be in /Library/Developer/ [according to Apple].   
> Unfortunately, PB is broken and won't find templates and 
> specifications in /Library/Developer.
>
> So -- the packaging now does as much as it can "correctly"....
>
> b.bum
>
>

Re: [Pyobjc-dev] ANN: PyObjC 0.9

[<bb...@ma...>]

On Sunday, May 4, 2003, at 17:18 US/Pacific, tmk wrote:
> After installing the 0.9 release downloaded from sourceforge I was 
> astonished not to find anything under /Developer/Examples...
> It seems everything that should go under /Developer/... actually went 
> under /Library/Developer/... instead!

Ideally, nothing would be installed in /Developer/ directly and 
everything should be in /Library/Developer/ [according to Apple].   
Unfortunately, PB is broken and won't find templates and specifications 
in /Library/Developer.

So -- the packaging now does as much as it can "correctly"....

b.bum

Re: [Pyobjc-dev] ANN: PyObjC 0.9

[tmk <li...@ne...>]

Hi,

After installing the 0.9 release downloaded from sourceforge I was  
astonished not to find anything under /Developer/Examples...
It seems everything that should go under /Developer/... actually went  
under /Library/Developer/... instead!

Seems weird to me even at 2:00 AM %-).

I double-checked on the file listing from the installer and here's an  
excerpt that seems to confirm the above:

./Library/Developer/Documentation/PyObjC/.#coding-style.html.1.2
./Library/Developer/Documentation/PyObjC/.#structure.html.1.1
./Library/Developer/Documentation/PyObjC/.#warts.html.1.1
./Library/Developer/Documentation/PyObjC/ProjectBuilder- 
SyntaxHighlighting.html
./Library/Developer/Documentation/PyObjC/ProjectBuilder- 
SyntaxHighlighting.txt
./Library/Developer/Documentation/PyObjC/TODO
./Library/Developer/Documentation/PyObjC/architecture.html
./Library/Developer/Documentation/PyObjC/architecture.txt
./Library/Developer/Documentation/PyObjC/classes.html
./Library/Developer/Documentation/PyObjC/classes.txt
./Library/Developer/Documentation/PyObjC/coding-style.html
./Library/Developer/Documentation/PyObjC/coding-style.txt
./Library/Developer/Documentation/PyObjC/index.html
./Library/Developer/Documentation/PyObjC/index.txt
./Library/Developer/Documentation/PyObjC/intro.html
./Library/Developer/Documentation/PyObjC/intro.txt
./Library/Developer/Documentation/PyObjC/libffi.html
./Library/Developer/Documentation/PyObjC/libffi.txt
./Library/Developer/Documentation/PyObjC/refcounts.html


Seems like a bug to me or am I mistaken?

= tmk =
On Sunday, May 4, 2003, at 22:24 Europe/Brussels, Ronald Oussoren wrote:

> PyObjC 0.9 is now available for download at  
> http://pyobjc.sourceforge.net/
>
> PyObjC is a bridge between Python and Objective-C.  It allows full
> featured Cocoa applications to be written in pure Python.  It is also
> easy to use other frameworks containing Objective-C class libraries
> from Python and to mix in Objective-C, C and C++ source.
>
> Python is a highly dynamic programming language with a shallow learning
> curve.  It combines remarkable power with very clear syntax.
>
> The installer package includes a number of Project Builder templates  
> for
> easily creating new Cocoa-Python projects.  Version 0.9 also introduces
> support for sytax coloring of Python files in Project Builder.
>
> PyObjC also supports full introspection of Objective-C classes and
> direct invocation of Objective-C APIs from the interactive interpreter.
>
> PyObjC requires MacOS X 10.2 or later.  PyObjC works both with the  
> Apple
> provided Python installation in MacOS X 10.2 (and later) and with
> MacPython 2.3b1.  Users of MacPython 2.3b1 can install PyObjC though  
> the
> PackageManager application.
>
> PyObjC 0.9 includes many inprovements over earlier versions and users  
> are
> strongly advised to upgrade.  The installer package will automatically  
> upgrade
> prior releases.
>
> PyObjC is released with an open source license.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Re: ANN: PyObjC 0.9

[David E. <epp...@ic...>]

In article <75B...@ci...>,
 Ronald Oussoren <ous...@ci...> wrote:

> PyObjC 0.9 includes many inprovements over earlier versions and users 
> are
> strongly advised to upgrade.  The installer package will automatically 
> upgrade
> prior releases.

What about projects built with prior releases?  Is there an easy way of 
automatically upgrading them or would it be better simply to use the 
updated templates?  I haven't been following cvs updates since just 
before everything got moved around in the directory hierarchy.

-- 
David Eppstein                      http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Pyobjc-dev] libffi on OSX 10.1

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

I got bored and installed 10.1.5 and the December 2001 developer tools 
on a spare partition. I then tried to build python and pyobjc. The 
former mostly succeeded (more on that on the MacPython list), but I ran 
into some problems with pyobjc.

First of all libffi won't build, seemingly due to a compiler bug:

/bin/sh ./libtool --mode=compile cc -DHAVE_CONFIG_H -I. 
-I/Users/ronald/pyobjc/libffi-src -I. 
-I/Users/ronald/pyobjc/libffi-src/include -Iinclude 
-I/Users/ronald/pyobjc/libffi-src/src   -fexceptions -g -O2 -c -o 
ffitest.lo /Users/ronald/pyobjc/libffi-src/src/ffitest.c
cc -DHAVE_CONFIG_H -I. -I/Users/ronald/pyobjc/libffi-src -I. 
-I/Users/ronald/pyobjc/libffi-src/include -Iinclude 
-I/Users/ronald/pyobjc/libffi-src/src -fexceptions -g -O2 -c 
/Users/ronald/pyobjc/libffi-src/src/ffitest.c -o ffitest.o
/Users/ronald/pyobjc/libffi-src/src/ffitest.c:82: warning: use of `long 
double' type; its size may change in a future release
/Users/ronald/pyobjc/libffi-src/src/ffitest.c:82: warning: (Long double 
usage is reported only once for each file.
/Users/ronald/pyobjc/libffi-src/src/ffitest.c:82: warning: To disable 
this warning, use -Wno-long-double.)
/Users/ronald/pyobjc/libffi-src/src/ffitest.c: In function `main':
/Users/ronald/pyobjc/libffi-src/src/ffitest.c:1305: Unable to generate 
reloads for:
(call_insn 3679 3677 3682 (parallel[
             (set (reg:SI 3 r3)
                 (call (mem:SI (symbol_ref:SI ("cl.75")) 0)
                     (const_int 80 [0x50])))
             (use (const_int 0 [0x0]))
             (clobber (scratch:SI))
         ] ) 561 {*ret_call_nonlocal_sysv} (insn_list:REG_DEP_ANTI 3637 
(insn_list:REG_DEP_ANTI 3640 (insn_list:REG_DEP_ANTI 3643 
(insn_list:REG_DEP_ANTI 3646 (insn_list:REG_DEP_ANTI 3649 
(insn_list:REG_DEP_ANTI 3652 (insn_list:REG_DEP_ANTI 3655 
(insn_list:REG_DEP_ANTI 3658 (insn_list:REG_DEP_ANTI 3661 (insn_list 
3663 (insn_list 3665 (insn_list 3667 (insn_list 3669 (insn_list 3671 
(insn_list 3673 (insn_list 3675 (insn_list 3677 (nil))))))))))))))))))
     (expr_list:REG_DEAD (reg:SI 4 r4)
         (expr_list:REG_DEAD (reg:SI 5 r5)
             (expr_list:REG_DEAD (reg:DI 6 r6)
                 (expr_list:REG_DEAD (reg:SI 8 r8)
                     (expr_list:REG_DEAD (reg:SI 9 r9)
                         (expr_list:REG_DEAD (reg:SI 10 r10)
                             (expr_list:REG_DEAD (reg:DF 33 f1)
                                 (expr_list:REG_DEAD (reg:SF 34 f2)
                                     (expr_list:REG_UNUSED (scratch:SI)
                                         (nil))))))))))
     (expr_list (use (reg:SF 34 f2))
         (expr_list (use (reg:DF 33 f1))
             (expr_list (use (reg:SI 10 r10))
                 (expr_list (use (reg:SI 9 r9))
                     (expr_list (use (reg:SI 8 r8))
                         (expr_list (use (reg:DI 6 r6))
                             (expr_list (use (reg:SI 5 r5))
                                 (expr_list (use (reg:DI 3 r3))
                                     (nil))))))))))
make[2]: *** [ffitest.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive-am] Error 2	


I've continued building using the still existing non-ffi support, but 
that didn't fly either. I did get it to compile cleanly, but I get an 
segmentation fault when trying to import the objc module. I did not yet 
look into this.

My changes are in CVS.

Ronald

[Pyobjc-dev] ANN: PyObjC 0.9

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

PyObjC 0.9 is now available for download at 
http://pyobjc.sourceforge.net/

PyObjC is a bridge between Python and Objective-C.  It allows full
featured Cocoa applications to be written in pure Python.  It is also
easy to use other frameworks containing Objective-C class libraries
from Python and to mix in Objective-C, C and C++ source.

Python is a highly dynamic programming language with a shallow learning
curve.  It combines remarkable power with very clear syntax.

The installer package includes a number of Project Builder templates for
easily creating new Cocoa-Python projects.  Version 0.9 also introduces
support for sytax coloring of Python files in Project Builder.

PyObjC also supports full introspection of Objective-C classes and
direct invocation of Objective-C APIs from the interactive interpreter.

PyObjC requires MacOS X 10.2 or later.  PyObjC works both with the Apple
provided Python installation in MacOS X 10.2 (and later) and with
MacPython 2.3b1.  Users of MacPython 2.3b1 can install PyObjC though the
PackageManager application.

PyObjC 0.9 includes many inprovements over earlier versions and users 
are
strongly advised to upgrade.  The installer package will automatically 
upgrade
prior releases.

PyObjC is released with an open source license.

Re: [Pyobjc-dev] PyObjC newbie questions

[Gary R. <gro...@tr...>]

> The bad 
> news is that PyObjC currently doesn't work on 10.1, mostly because none
> of the developers have access to a 10.1 system.

Hmm. Too bad it didn't happen to work on 10.1 anyway. But it is hard to keep
extra machines around with obsolete OS's.

If I don't use PyObjC for this app I'll definitely look forward to using it
when more of the user base can access such apps. But for this application I
think I can't afford to lose the 10.1 user base...

Let me ask a quick somewhat off-topic question. Online I saw an example, I
think from Apple, of an AppleScript Studio application that invoked a Perl
daemon to do stuff that Perl was more capable of doing... communication was
via SOAP (using AppleScript's SOAP calls on the AppleScript Studio side). It
seemed quite easy.

That seems like an approach I could take for this, except using a Python app
as the daemon. The AppleScript Studio app would invoke it and tell it to
shut itself down when it isn't needed.

Do you know if I can write a Python app of that nature and bundle it with
the Python interpreter into a single executable under 10.1 and 10.2? Would
other python installations the user may have interfere in any way? Any
problem with making such an app "faceless" in the sense of having no
presence in the dock?

Many thanks for all your help!

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

Re: [Pyobjc-dev] PyObjC newbie questions

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

On Sunday, May 4, 2003, at 03:06 Europe/Amsterdam, Gary Robinson wrote:

> Ronald,
>
> Many thanks for your input!
>
> I think the AppleScript part shouldn't be a problem because I believe 
> Cocoa
> supplies the means to create AppleEvents, so I should be use Cocoa for 
> that
> part...
>
> Another thing, though. What about people who are running 10.1? Is it
> possible to include the Python interpreter itself in the app using
> buildapp.py so that such a user doesn't need to already have Python?

builapp.py uses the bundlebuilder module which supports creating 
standalone applications ('buildapp.py --standalone build'). The bad 
news is that PyObjC currently doesn't work on 10.1, mostly because none 
of the developers have access to a 10.1 system.

Ronald

Re: [Pyobjc-dev] PyObjC newbie questions

[Gary R. <gro...@tr...>]

Ronald,

Many thanks for your input!

I think the AppleScript part shouldn't be a problem because I believe Cocoa
supplies the means to create AppleEvents, so I should be use Cocoa for that
part...

Another thing, though. What about people who are running 10.1? Is it
possible to include the Python interpreter itself in the app using
buildapp.py so that such a user doesn't need to already have Python?

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454


> From: Ronald Oussoren <ous...@ci...>
> Date: Sun, 4 May 2003 01:10:02 +0200
> To: Gary Robinson <gro...@tr...>
> Cc: <pyo...@li...>
> Subject: Re: [Pyobjc-dev] PyObjC newbie questions
> 
> 
> On Saturday, May 3, 2003, at 23:20 Europe/Amsterdam, Gary Robinson
> wrote:
> 
>> Hello everyone,
>> 
>> I'm a PyObjC newbie hoping to get some info.
>> 
>> I have a couple decade's worth of programming experience plus solid
>> experience in Python development on Solaris.
>> 
>> I have no experience with Cocoa or Objective C.
>> 
>> I am interested in using PyObjC to create a small Cocoa application,
>> mostly
>> because  I want to get it done quickly and don't want to have to master
>> Objective C, and in particular, don't want to deal with reference
>> counting
>> etc. Also, I very much like Python's syntax and the libraries that
>> come with
>> it.
>> 
>> It sounds like PyObjC could allow me to do what I want to do, but I
>> have
>> some concerns. I am hoping that someone here can address them for me.
>> 
>> 1) refcounts.html in the PyObjC docs files says "Other than in very
>> special
>> situations you should never have to worry about reference counts. Those
>> special methods mostly seem to involve zombie objects that are no
>> longer
>> reachable from normal code, but will perform some action before really
>> dying
>> at the end of the current pass through the event loop."
>> 
>> OK, but does that mean I can do things in such a way that I KNOW that
>> Python
>> is handling them? That is, is there a programming style I can use such
>> that,
>> if I rigorously follow it, I will know I am not creating the kind of
>> zombie
>> object mentioned above, and am not creating other violations the
>> python-handles-it capability?
>> 
>> In other words, if I don't take the time to develop a deep
>> understanding of
>> Objective C's memory management, can I rely on something other than
>> random
>> chance to keep me out of trouble?  Or is that knowledge actually
>> required?
> 
> You don't have to know about Objective-C's memory management, the
> bridge performs all memory management you need. The sentence you quote
> has to do with some deep Objective-C magic, which is nothing you should
> run in to (it's like metaclasses in Python, they are there but you
> probably shouldn't tell newbies about them).
> 
> 
> 
>> 
>> 2) tutorial.html in the docs file says: "It is even possible to
>> include all
>> of Python (or, if you are using Apple's Python 2.2, all the bits of
>> Python
>> that are non-standard), this gives you an application that is
>> distributable
>> to anyone in the world (as long as they have Mac OS X 10.2)!
>> Unfortunately,
>> the exact details of this procedure are not streamlined enough for
>> inclusion
>> in this tutorial at this point in time."
>> 
>> OK, but is there a way I can find out how to do it? I would be
>> creating an
>> app that I will be hoping a lot of non-developers will download and
>> run.
> 
> Some of the example applications include a script named buildapp.py.
> This will build the application without using Project Builder. If you
> copy the contents of /usr/lib/python2.2/site-packages/PyObjC into the
> Resources directory of the application bundle (such as
> TableModel.app/Contents/Resources for the TableModel example), you'll
> end up with a standalone application.
> 
> The same thing should be possible with the Project Builder templates.
> If I recall correctly those will create standalone applications if you
> build the install target.
> 
>> 
>> 3) While I've done an solid amount of Python programming on Solaris, I
>> have
>> used it only minimally on the Mac. This app would need to control a
>> separate
>> standard OS X app locally via AppleEvents, receive XML-RPC requests
>> from
>> other machines, and send XML-RPC requests to other machines.
>> 
>> Any forseeable problems doing all that with Python's standard
>> libraries and
>> PyObjC?
> 
> XML-RPC should not be a problem, see the example 'WebServicesTool'.
> I've never used AppleEvents before, I can't say anything about that. I
> do know that MacPython contains AppleScript related modules, but to use
> those you probably need to use Python 2.3.
> 
> Ronald
> 

Re: [Pyobjc-dev] PyObjC newbie questions

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

On Saturday, May 3, 2003, at 23:20 Europe/Amsterdam, Gary Robinson 
wrote:

> Hello everyone,
>
> I'm a PyObjC newbie hoping to get some info.
>
> I have a couple decade's worth of programming experience plus solid
> experience in Python development on Solaris.
>
> I have no experience with Cocoa or Objective C.
>
> I am interested in using PyObjC to create a small Cocoa application, 
> mostly
> because  I want to get it done quickly and don't want to have to master
> Objective C, and in particular, don't want to deal with reference 
> counting
> etc. Also, I very much like Python's syntax and the libraries that 
> come with
> it.
>
> It sounds like PyObjC could allow me to do what I want to do, but I 
> have
> some concerns. I am hoping that someone here can address them for me.
>
> 1) refcounts.html in the PyObjC docs files says "Other than in very 
> special
> situations you should never have to worry about reference counts. Those
> special methods mostly seem to involve zombie objects that are no 
> longer
> reachable from normal code, but will perform some action before really 
> dying
> at the end of the current pass through the event loop."
>
> OK, but does that mean I can do things in such a way that I KNOW that 
> Python
> is handling them? That is, is there a programming style I can use such 
> that,
> if I rigorously follow it, I will know I am not creating the kind of 
> zombie
> object mentioned above, and am not creating other violations the
> python-handles-it capability?
>
> In other words, if I don't take the time to develop a deep 
> understanding of
> Objective C's memory management, can I rely on something other than 
> random
> chance to keep me out of trouble?  Or is that knowledge actually 
> required?

You don't have to know about Objective-C's memory management, the 
bridge performs all memory management you need. The sentence you quote 
has to do with some deep Objective-C magic, which is nothing you should 
run in to (it's like metaclasses in Python, they are there but you 
probably shouldn't tell newbies about them).



>
> 2) tutorial.html in the docs file says: "It is even possible to 
> include all
> of Python (or, if you are using Apple's Python 2.2, all the bits of 
> Python
> that are non-standard), this gives you an application that is 
> distributable
> to anyone in the world (as long as they have Mac OS X 10.2)! 
> Unfortunately,
> the exact details of this procedure are not streamlined enough for 
> inclusion
> in this tutorial at this point in time."
>
> OK, but is there a way I can find out how to do it? I would be 
> creating an
> app that I will be hoping a lot of non-developers will download and 
> run.

Some of the example applications include a script named buildapp.py. 
This will build the application without using Project Builder. If you 
copy the contents of /usr/lib/python2.2/site-packages/PyObjC into the 
Resources directory of the application bundle (such as 
TableModel.app/Contents/Resources for the TableModel example), you'll 
end up with a standalone application.

The same thing should be possible with the Project Builder templates. 
If I recall correctly those will create standalone applications if you 
build the install target.

>
> 3) While I've done an solid amount of Python programming on Solaris, I 
> have
> used it only minimally on the Mac. This app would need to control a 
> separate
> standard OS X app locally via AppleEvents, receive XML-RPC requests 
> from
> other machines, and send XML-RPC requests to other machines.
>
> Any forseeable problems doing all that with Python's standard 
> libraries and
> PyObjC?

XML-RPC should not be a problem, see the example 'WebServicesTool'. 
I've never used AppleEvents before, I can't say anything about that. I 
do know that MacPython contains AppleScript related modules, but to use 
those you probably need to use Python 2.3.

Ronald

[Pyobjc-dev] PyObjC newbie questions

[Gary R. <gro...@tr...>]

Hello everyone,

I'm a PyObjC newbie hoping to get some info.

I have a couple decade's worth of programming experience plus solid
experience in Python development on Solaris.

I have no experience with Cocoa or Objective C.

I am interested in using PyObjC to create a small Cocoa application, mostly
because  I want to get it done quickly and don't want to have to master
Objective C, and in particular, don't want to deal with reference counting
etc. Also, I very much like Python's syntax and the libraries that come with
it.

It sounds like PyObjC could allow me to do what I want to do, but I have
some concerns. I am hoping that someone here can address them for me.

1) refcounts.html in the PyObjC docs files says "Other than in very special
situations you should never have to worry about reference counts. Those
special methods mostly seem to involve zombie objects that are no longer
reachable from normal code, but will perform some action before really dying
at the end of the current pass through the event loop."

OK, but does that mean I can do things in such a way that I KNOW that Python
is handling them? That is, is there a programming style I can use such that,
if I rigorously follow it, I will know I am not creating the kind of zombie
object mentioned above, and am not creating other violations the
python-handles-it capability?

In other words, if I don't take the time to develop a deep understanding of
Objective C's memory management, can I rely on something other than random
chance to keep me out of trouble?  Or is that knowledge actually required?

2) tutorial.html in the docs file says: "It is even possible to include all
of Python (or, if you are using Apple's Python 2.2, all the bits of Python
that are non-standard), this gives you an application that is distributable
to anyone in the world (as long as they have Mac OS X 10.2)! Unfortunately,
the exact details of this procedure are not streamlined enough for inclusion
in this tutorial at this point in time."

OK, but is there a way I can find out how to do it? I would be creating an
app that I will be hoping a lot of non-developers will download and run.

3) While I've done an solid amount of Python programming on Solaris, I have
used it only minimally on the Mac. This app would need to control a separate
standard OS X app locally via AppleEvents, receive XML-RPC requests from
other machines, and send XML-RPC requests to other machines.

Any forseeable problems doing all that with Python's standard libraries and
PyObjC?


Thank you in advance for any and all insight...

--Gary

-- 
[http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org]

Gary Robinson
CEO
Transpose, LLC
gro...@tr...
207-942-3463
http://www.transpose.com
http://radio.weblogs.com/0101454

[Pyobjc-dev] Feedback needed for documentation

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

The most important target for a 1.0 release is providing good 
documentation. To get things going I'd like to hear about problems with 
our current documentation, and hopefully also some suggestions on how 
to improve on it.

Another important point I'd like to get feedback on is what new users 
of PyObjC find hard when starting to use it, that might give us 
pointers on how to improve the bridge itself as well as find items that 
should be mentioned the introduction to PyObjC. Please mention if you 
are/were new to Python and/or Cocoa.

Ronald

Re: [Pyobjc-dev] PB templates currently broken

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

On Friday, May 2, 2003, at 23:38 Europe/Amsterdam, Jack Jansen wrote:
>
>
> Ideally I would like to see 0.9 Real Soon Now, as in early next week. 
> If that
> happens I will delay the announcement of MacPython-2.3b1 so that 
> PyObjC 0.9
> can be installed through the package manager. I think we have a really 
> cool
> combo, then, and something we can get some airplay for, to whet 
> people's
> appetite so we'll blow them away when 2.3 and 1.0 come out later.

How about this weekend? The 0.9 packages are available on SF. We just 
have to work on the announcement message(s), and for me at least that 
is harder than any last minute code changes.

> And lets try for a fast track to 1.0. Don't forget 1.0 doesn't have to 
> be perfect,
> after all "it's only a 1.0 release". And we shouldn't forget about 
> "release
> early, release often". We don't want (say) the Ruby people to come up 
> with
> something before us that will eat the publicity and turn us into
> also-runners.

I don't know how the others feel about this, but the only reason I have 
for not calling the current release 1.0 is the quality of the 
documentation. Almost everything else on my private todo-list has to do 
with cleaning up and simplifying the code/design of the bridge.

Ronald