pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Checking PyObjC-1.0 installed?

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

On Thursday, Oct 16, 2003, at 10:04 America/New_York, Bob Swerdlow 
wrote:

> I used PackageManager to install PyObjC1.0 into my MacPython 2.3.  At 
> least
> I think I did - I opened the database at
> http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist, 
> saw
> the PyObjC-1.0-source and PyObjC-1.0-binary items, selected them and 
> clicked
> "Install."  I got no confirmation, but I eventually saw that the 
> "Packages"
> column had turned to "yes".  Some more concrete feedback would be 
> helpful.

PackageManager needs a lot of work, I don't think anyone disagrees here.

> Is there a way I can confirm that the 1.0 version is really there?  
> Also, is
> there a way to remove the older PyObjC-1.0b1 source and binary
> installations, which are now listed as "old"?

 >>> import objc
 >>> objc.__version__
'1.0'

PackageManager lists packages that the repository offers, not 
necessarily the packages you have on your system.  Which PackageManager 
repository is listing *both* 1.0 and 1.0b1?  There's no need for you to 
try and uninstall 1.0b1 from your computer because 1.0 was installed 
over it.

-bob

[Pyobjc-dev] Checking PyObjC-1.0 installed?

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

I used PackageManager to install PyObjC1.0 into my MacPython 2.3.  At least
I think I did - I opened the database at
http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist, saw
the PyObjC-1.0-source and PyObjC-1.0-binary items, selected them and clicked
"Install."  I got no confirmation, but I eventually saw that the "Packages"
column had turned to "yes".  Some more concrete feedback would be helpful.

Is there a way I can confirm that the 1.0 version is really there?  Also, is
there a way to remove the older PyObjC-1.0b1 source and binary
installations, which are now listed as "old"?

Bob Swerdlow
COO
Transpose
rsw...@tr...
207-781-8284
http://www.transpose.com

----------------------------------
Fight Spam!
Add this link to your signature (as I did): http://wecanstopspam.org
Click through to find out more.
----------------------------------

[Pyobjc-dev] Re: [Pythonmac-SIG] ANN: DrawBot + Renaissance

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

Bob Ippolito:

> I went ahead and packed up my modified DrawBot (the one with widgets).
> More information and a link to download is on the pythonmac.org wiki:

Neat! Some more or less nitpicking thoughts:

1. it is impossible to know which sample has a dynamic interface
    without actually opening it. Maybe those filenames should have
    some consistent label? RegularPolygon.py hasn't...

2. the sliders scales might want to display numeric values, too.

3. slider movements could optionally trigger a rerun continuously
    (interesting results are for sure with randomized drawings ;-)

4. the window drawer might have a button to fold in and out

Otherwise a terrific tool!!

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"I once asked Ivan, 'How is it possible for you to have invented
computer graphics, done the first object oriented software system
and the first real time constraint solver all by yourself in one
year?' And he said 'I didn't know it was hard.'"
(Alan Kay on Ivan Sutherland)

[Pyobjc-dev] ANN: DrawBot + Renaissance

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

I went ahead and packed up my modified DrawBot (the one with widgets).  
More information and a link to download is on the pythonmac.org wiki:
http://pythonmac.org/wiki/DrawBot

Note that tarball includes the self-contained application, an 
unmodified binary build of GNUStep Renaissance, and all of DrawBot's 
source code.

And yes, Just, I did borrow your moinmoin css  ;)  I hope you don't 
mind, I found yours to be much nicer and more readable than the mostly 
default style I was using previously.

-bob

Re: [Pyobjc-dev] buildapp.py and bootstrapping

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

On 15 okt 2003, at 20:52, Bob Ippolito wrote:
> Well, it does.  Remember how the bundlebuilder bootstrap scripts work? 
>  execve to a symlink (if not --standalone) of python that lives in the 
> app bundle.
>
> Of course, you're attaching GDB to Python, which runs a short script 
> that ends up execve'ing (hopefully) the same Python.. but it does 
> work.

That nice. I usually attach gdb when the .app is already running, that 
works fine but only when the app stays up long enough to attach the 
debugger :-)

Ronald

Re: [Pyobjc-dev] buildapp.py and bootstrapping

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

On Wednesday, Oct 15, 2003, at 14:43 America/New_York, Ronald Oussoren  
wrote:

>
> On 15 okt 2003, at 19:45, Bob Ippolito wrote:
>
>> On Wednesday, Oct 15, 2003, at 13:25 America/New_York, b.bum wrote:
>>
>>> Any chance of upgrading buildapp.py with one (or both) of two  
>>> features that would make debugging via gdb a boatload easier?
>>> - add ability to copy in a bootstrap executable that uses an  
>>> embedded Python interpreter in place of the script/link that exist  
>>> today
>>
>> I don't see why this would be hard to do, and I think it makes sense  
>> and it brings back potential OS X 10.1 compatibility as well, right?   
>> Not that I care, but someone might.
>
> A bootstrap executable that uses an embedded Python interpreter might  
> also initialize faster,
> and that definitly is usefull.

Sure, I agree with that.

>> Realistically though, couldn't you just write a script to launch gdb  
>> with the right args, like this (imagine a simple shell script to  
>> automate this):
>> 	gdb --args  
>> /Library/Frameworks/Python.framework/Versions/2.3/Resources/ 
>> Python.app/Contents/MacOS/Python  
>> `pwd`/build/DrawBot.app/Contents/MacOS/DrawBot
>
> That won't work unless this correctly set argv[0] to the full path to  
> the wrapper inside the app bundle.

Well, it does.  Remember how the bundlebuilder bootstrap scripts work?   
execve to a symlink (if not --standalone) of python that lives in the  
app bundle.

Of course, you're attaching GDB to Python, which runs a short script  
that ends up execve'ing (hopefully) the same Python.. but it does work.

-bob

Re: [Pyobjc-dev] buildapp.py and bootstrapping

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

On 15 okt 2003, at 19:45, Bob Ippolito wrote:

> On Wednesday, Oct 15, 2003, at 13:25 America/New_York, b.bum wrote:
>
>> Any chance of upgrading buildapp.py with one (or both) of two  
>> features that would make debugging via gdb a boatload easier?
>> - add ability to copy in a bootstrap executable that uses an embedded  
>> Python interpreter in place of the script/link that exist today
>
> I don't see why this would be hard to do, and I think it makes sense  
> and it brings back potential OS X 10.1 compatibility as well, right?   
> Not that I care, but someone might.

A bootstrap executable that uses an embedded Python interpreter might  
also initialize faster,
and that definitly is usefull.

> Realistically though, couldn't you just write a script to launch gdb  
> with the right args, like this (imagine a simple shell script to  
> automate this):
> 	gdb --args  
> /Library/Frameworks/Python.framework/Versions/2.3/Resources/ 
> Python.app/Contents/MacOS/Python  
> `pwd`/build/DrawBot.app/Contents/MacOS/DrawBot

That won't work unless this correctly set argv[0] to the full path to  
the wrapper inside the app bundle.

Ronald

Re: [Pyobjc-dev] Pure python instance -> ObjC proxy incomplete?

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

On 15 okt 2003, at 19:30, b.bum wrote:

>
> In looking at OC_PythonObject.[hm], it would appear that it doesn't 
> implement all of the NSObject protocol.
>
> In particular, we are missing....
>
> - (BOOL)isEqual:(id)object;
> - (unsigned)hash;
>
> .... which is causing a bit of consternation when using mechanisms 
> that attempt to sort collections of objects contained in ObjC 
> collections.
>
> It would appear that isEqual: could be forwarded to the __eq__() 
> method on the Python side, but only if the object passed in is non-nil 
> and also an instance of OC_PythonObject?

isEqual should use 'PyTypeObject.richcmp'  (e.g. __eq__) if that is 
available and 'PyTypeObject.cmp' (__cmp__) otherwise. hash should use 
PyObject_Hash.

Ronald

Re: [Pyobjc-dev] buildapp.py and bootstrapping

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

On Wednesday, Oct 15, 2003, at 13:25 America/New_York, b.bum wrote:

> Any chance of upgrading buildapp.py with one (or both) of two features  
> that would make debugging via gdb a boatload easier?
> - add ability to copy in a bootstrap executable that uses an embedded  
> Python interpreter in place of the script/link that exist today

I don't see why this would be hard to do, and I think it makes sense  
and it brings back potential OS X 10.1 compatibility as well, right?   
Not that I care, but someone might.
Realistically though, couldn't you just write a script to launch gdb  
with the right args, like this (imagine a simple shell script to  
automate this):
	gdb --args  
/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/ 
Contents/MacOS/Python `pwd`/build/DrawBot.app/Contents/MacOS/DrawBot

This is *nix, remember?  ;)

> - build a bootstrap executable ala distutils that allows the developer  
> to link in other frameworks and/or their own compiled code as a part  
> of the buildapp.py process?   This would both address the gdb issue  
> and allow the developer to trivially interleave ObjC or other compiled  
> code without using one of the project templates/PBX.

I've never had a problem using GDB with dynamically loaded code (via  
ObjC frameworks or Python extension bundles), so why do you need/want  
this?	- It's easier (from the Python side) to just compile the ObjC  
code as frameworks and load it in dynamically, would the ObjC runtime  
even find your compiled code otherwise?
	- "other compiled code" wouldn't be useful from Python without a  
python module to support it.. IIRC, the code is almost the same whether  
you make it a bundle or extend an embedded interpreter, why not just  
make it a module?

[Pyobjc-dev] Pure python instance -> ObjC proxy incomplete?

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

In looking at OC_PythonObject.[hm], it would appear that it doesn't 
implement all of the NSObject protocol.

In particular, we are missing....

- (BOOL)isEqual:(id)object;
- (unsigned)hash;

.... which is causing a bit of consternation when using mechanisms that 
attempt to sort collections of objects contained in ObjC collections.

It would appear that isEqual: could be forwarded to the __eq__() method 
on the Python side, but only if the object passed in is non-nil and 
also an instance of OC_PythonObject?

-hash would be mapped to whatever enables keys within dictionaries with 
the typical rule that two objects that are considered equal have the 
same hash?

Correct?

I'll have a patch shortly, but I can't commit anything until the 24th 
:-).

b.bum

[Pyobjc-dev] buildapp.py and bootstrapping

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

I know we have touched upon this subject in the past, but I wanted to 
raise it again.

Any chance of upgrading buildapp.py with one (or both) of two features 
that would make debugging via gdb a boatload easier?

- add ability to copy in a bootstrap executable that uses an embedded 
Python interpreter in place of the script/link that exist today

- build a bootstrap executable ala distutils that allows the developer 
to link in other frameworks and/or their own compiled code as a part of 
the buildapp.py process?   This would both address the gdb issue and 
allow the developer to trivially interleave ObjC or other compiled code 
without using one of the project templates/PBX.

b.bum

[Pyobjc-dev] Re: [Pythonmac-SIG] Twisted's cfreactor + PyObjC = Asynchronous Networking on OS X

[Brian L. <br...@ma...>]

On Oct 13, 2003, at 3:25 PM, Bob Ippolito wrote:

> For those of you who don't watch Twisted CVS, cfreactor is officially 
> out of the sandbox.  cfreactor is the CoreFoundation integration 
> reactor for Twisted ( http://www.twistedmatrix.com/ ), which means 
> that you can now seamlessly integrate Cocoa and Twisted (without 
> digging around in my sandbox, that is).

This is really nice.  And the demos really are much more responsive.  
Nice work.

[Pyobjc-dev] Twisted's cfreactor + PyObjC = Asynchronous Networking on OS X

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

For those of you who don't watch Twisted CVS, cfreactor is officially 
out of the sandbox.  cfreactor is the CoreFoundation integration 
reactor for Twisted ( http://www.twistedmatrix.com/ ), which means that 
you can now seamlessly integrate Cocoa and Twisted (without digging 
around in my sandbox, that is).

If you're running OS X and you'd like to play with cfreactor, check out 
the latest CVS and do a python setup.py install (so that it can build 
twisted/internet/cfsupport.so -- ignore the warnings, they are expected 
for Pyrex modules).  There are two examples provided in 
doc/examples/Cocoa.  You will need PyObjC 1.0 (though it may work with 
earlier betas, you should upgrade if you haven't yet) and MacPython 2.3 
(not tested with Panther yet, but should work).  The next release 
version of Twisted, which is expected very shortly, will include this 
new reactor and updated documentation.  When it is released, it will 
also be available from my Package Manager repository ( 
http://undefined.org/python/pimp/ ).
	
	SimpleWebClient - Pretty much a straight port of 
doc/examples/qtdemo.py, a very simple app that downloads HTML and puts 
it in a text box.
	WebServicesTool - A Twisted port of b.bum's XML-RPC demo (which is 
included with PyObjC).  For fun, compare how much simpler the Twisted 
version is (since it doesn't need to deal with threads), and how much 
more responsive it feels.

To run either demo, use the buildapp.py script provided in the same 
folder as the application:
	python buildapp.py build

And then:
	open build/ApplicationName.app

Note that when using cfreactor you should *always* call reactor.run() 
while the NSRunLoop is in action (best place to put it is probably in 
your NSApplication delegate's applicationDidFinishLaunching_ method).  
If you're using threads, make sure to only call into Twisted from the 
main runLoop (which is where you have to do your drawing anyways).  And 
of course, you should cfreactor.install() before importing any other 
Twisted modules (see the "Choosing a Reactor and GUI Toolkit 
Integration" HOWTO for more information).

-bob

[Pyobjc-dev] Converting NSCFDictionary etc. to native Python instances

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

Hi,

is there some smarter way to turn output like that from
NSUserDefaults.standardUserDefaults().dictionaryRepresentation()
with lots of NSCF-whatever instances inside into native Python
datatypes than doing it "manually" like this:

   d = NSUserDefaults.standardUserDefaults().dictionaryRepresentation()
   dict = {}
   dict.update(d)

and then working recursively down the nested levels?

Dinu

--
Dinu C. Gherman
......................................................................
"The whole point of brainwashing, is that those being brainwashed
don't know it." (Graham Haley)

Re: [Pyobjc-dev] 1.0 released

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

On Friday, Oct 10, 2003, at 13:55 America/New_York, Just van Rossum 
wrote:

> Bob Ippolito wrote:
>
>> Why isn't bundlebuilder integrated into distutils anyways?
>
> I don't know what the advantages would be, but I'd be interested in
> hearing your opinion. Here's the thread Dinu mentioned:
>
> http://aspn.activestate.com/ASPN/Mail/Message/pythonmac-sig/1812472

You're right in that bundlebuilder and distutils use cases don't really 
overlap at the moment.  After reading that thread and thinking a bit 
more I see that bundlebuilder, in the future, will definitely be using 
distutils for a lot of functionality (building dependencies, searching 
the installed package database, etc), but I don't think distutils will 
really be using bundlebuilder.

It would be kinda convenient to have a "setup.py" equivalent for making 
executables.. where a distutils-like-thing would be in place to do 
platform detection and make py2exe, bundlebuilder, etc. do the right 
thing for the target platform.  It would also be nice if there was a 
way to tell bundlebuilder to go ahead and make a compressed .dmg or 
tarball for you with the application and associated files (examples, 
license (maybe with the special .dmg license-acceptance support), 
readme, whatever).

Dinu mentioned that it would be nice to have PyPI integration with 
sites like versiontracker, macupdate, etc.  I'd also include freshmeat 
on my list.. but anyways, I'm not sure if PyPI really works for 
applications, there should probably be something else for posting 
applications.  PyPI metadata -> freshmeat would be nice though.

-bob

Re: [Pyobjc-dev] 1.0 released

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

Bob Ippolito wrote:

> Why isn't bundlebuilder integrated into distutils anyways?

I don't know what the advantages would be, but I'd be interested in
hearing your opinion. Here's the thread Dinu mentioned:

http://aspn.activestate.com/ASPN/Mail/Message/pythonmac-sig/1812472

Just

Re: [Pyobjc-dev] 1.0 released

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

Bob Ippolito:

> Why isn't bundlebuilder integrated into distutils anyways?  This is 
> for sure something we ought to look into for PackMan's future, since 
> we're changing distutils anyway (integrate py2exe / bundlebuilder / 
> freeze functionality into distutils).

That's what I wondered before on the Pythonmac list... Maybe it's
worth a few more thoughts, after all...

Dinu

--
Dinu C. Gherman
......................................................................
"I tremble for my country when I reflect that God is just, that His
justice will not sleep forever." (Thomas Jefferson)

Re: [Pyobjc-dev] 1.0 released

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

On Friday, Oct 10, 2003, at 11:02 America/New_York, Jack Jansen wrote:

>
> On Wednesday, October 8, 2003, at 07:45 PM, Ronald Oussoren wrote:
>
>> http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist
>
> Either I'm doing something stupid, or there's a problem somewhere.
>
> I installed PyObjC binary and PyObjC-extras from this database. Then
> I tried to run HelloWorld.py and it died:
> Traceback (most recent call last):
>   File  
> "/Applications/MacPython-2.3/Extras/pyobjc-1.0/Examples/ 
> HelloWorld.py", line 78, in ?
>     if __name__ == '__main__' : main()
>   File  
> "/Applications/MacPython-2.3/Extras/pyobjc-1.0/Examples/ 
> HelloWorld.py", line 41, in main
>     NSApp.setDelegate_(delegate)
> AttributeError: 'builtin_function_or_method' object has no attribute  
> 'setDelegate_'

That's looks like a bug.  I'm pretty sure that NSApp is a factory for  
the NSApplication singleton, not an instance of NSApplication.

> And then I ran into some misdesigns in buildapp.py/bundlebuilder.py:
> pretending to be a naive user I opened  
> MacPython-2.3/Extras/pyobjc-1.0/Examples/CurrencyConverter
> in the finder. Double-clicking CurrencyConverter.py crashes (*I* know  
> why, but only when I'm not
> naive:-). Okay, I double-click buildapp.py. Doesn't work either  
> (because it wants a "build"
> argument, sigh). Read the error message, option-double-click buildapp,  
> provide the
> "build" argument in PythonLauncher: still doesn't work (*I* know it's  
> because the
> working directory is incorrect, but not when I'm naive...).

Why isn't bundlebuilder integrated into distutils anyways?  This is for  
sure something we ought to look into for PackMan's future, since we're  
changing distutils anyway (integrate py2exe / bundlebuilder / freeze  
functionality into distutils).

> I think fixing problems like this would be good if we want to lure  
> people to
> switch to PyObjC. If we fix the fact that you can't run PyObjC scripts  
> without
> first creating an app bundle then I think the buildapp problems aren't  
> all
> that important, but if we can't fix PyObjC to load the nib files on  
> the fly
> then we should do something else to make a simple double-click from the
> finder run the examples (even if this means we have to add "runme.py"  
> to all
> examples, that does all the building work and then fires the resulting  
> app).

It's definitely possible to make them load nib files on the fly, but it  
sure is ugly.  At worst case, you can have it build its own bundle  
(with --link) and os.execve or use LaunchServices to open it.

-bob

Re: [Pyobjc-dev] 1.0 released

[Jack J. <Jac...@cw...>]

On Wednesday, October 8, 2003, at 07:45 PM, Ronald Oussoren wrote:

> http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist

Either I'm doing something stupid, or there's a problem somewhere.

I installed PyObjC binary and PyObjC-extras from this database. Then
I tried to run HelloWorld.py and it died:
Traceback (most recent call last):
   File 
"/Applications/MacPython-2.3/Extras/pyobjc-1.0/Examples/HelloWorld.py", 
line 78, in ?
     if __name__ == '__main__' : main()
   File 
"/Applications/MacPython-2.3/Extras/pyobjc-1.0/Examples/HelloWorld.py", 
line 41, in main
     NSApp.setDelegate_(delegate)
AttributeError: 'builtin_function_or_method' object has no attribute 
'setDelegate_'

And then I ran into some misdesigns in buildapp.py/bundlebuilder.py:
pretending to be a naive user I opened 
MacPython-2.3/Extras/pyobjc-1.0/Examples/CurrencyConverter
in the finder. Double-clicking CurrencyConverter.py crashes (*I* know 
why, but only when I'm not
naive:-). Okay, I double-click buildapp.py. Doesn't work either 
(because it wants a "build"
argument, sigh). Read the error message, option-double-click buildapp, 
provide the
"build" argument in PythonLauncher: still doesn't work (*I* know it's 
because the
working directory is incorrect, but not when I'm naive...).

I think fixing problems like this would be good if we want to lure 
people to
switch to PyObjC. If we fix the fact that you can't run PyObjC scripts 
without
first creating an app bundle then I think the buildapp problems aren't 
all
that important, but if we can't fix PyObjC to load the nib files on the 
fly
then we should do something else to make a simple double-click from the
finder run the examples (even if this means we have to add "runme.py" 
to all
examples, that does all the building work and then fires the resulting 
app).
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pyobjc-dev] 1.0 released

[Richard C. <sun...@ma...>]

On Thursday, October 9, 2003, at 06:30  am, Ronald Oussoren wrote:

> Arghh!!! That's a copy-paste error... Is that with the source package, 
> or does the binary installer not work either? I've uploaded new plists 
> that don't mention AppleDevTools.

That was the source package I tried. I've ran it now and all seems fine.

Thanks,

Richard

Re: [Pyobjc-dev] 1.0 released

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

On 8 okt 2003, at 22:43, Martina Oefelein wrote:

> Hello Ronald!
>
>> PyObjC 1.0 is (finally ;-) released!
>
> Congratulations! And Thank You and the other contributors for this  
> terrific work!
>
> But I have a problem:
>
> when I try to download the package using packman, I only get an error  
> message. Apparently the link is broken:
>
> The plist points to:
> http://heanet.dl.sourceforge.net/sourceforge/pyobjc/pyobjc-1.0-darwin 
> -6.6-Power_Macintosh.tar.gz
>
> whereas the file on the server seems to be:
> http://heanet.dl.sourceforge.net/sourceforge/pyobjc/pyobjc-1.0.darwin 
> -6.6-Power_Macintosh.tar.gz
> (Note the period after "1.0"!)

Yet another hole in my pre-release tests :-( I've fixed the 6.6 plist.

>
> Moreover, this file is about a week old! (01-Oct-2003 19:13) Did you  
> accidentally upload the wrong file?

No, I had planned to do the release a week ago, but didn't manage to  
find enough time to actually do the release until yesterday.

Ronald

Re: [Pyobjc-dev] 1.0 released

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

On 8 okt 2003, at 22:42, Richard Chamberlain wrote:

> Hello,
>
> On Wednesday, October 8, 2003, at 06:45  pm, Ronald Oussoren wrote:
>
>> PyObjC 1.0 is (finally ;-) released!
>
> Cool!
>
>> I've tagged the CVS tree: 'release_1_0' is the release, 'branch_1_0' 
>> is a branch for creating a 1.0.x release (should that be necessary). 
>> The files have been uploaded to SF and should be available "soon".
>>
>> MacPython 2.3 users can get instant gratification by pointing PackMan 
>> to 
>> http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist 
>> (and ...-7.0-... for those of you who run MacPython 2.3 on Panther).
>
> Unfortunately that doesn't seem to work for me (10.2.8 / MacPython 
> 2.3) I get a Requires unknown AppleDevTools error message - I do have 
> the apple dev tools installed.

Arghh!!! That's a copy-paste error... Is that with the source package, 
or does the binary installer not work either? I've uploaded new plists 
that don't mention AppleDevTools.

>
>> I'll send the announcement below to other lists some time tomorrow, I 
>> want to be reasonably sure that the SF mirrors have picked up the 
>> archives/installers before telling the world about them.
>
> There is a typo in you're url on the homepage, the available link 
> points to sourceforget instead of sourceforge.
>
Fixed, thanks.

Ronald

Re: [Pyobjc-dev] 1.0 released

[Jack J. <Jac...@cw...>]

>> MacPython 2.3 users can get instant gratification by pointing PackMan 
>> to 
>> http://pyobjc.sf.net/packman/pyobjc-stable-6.6-Power_Macintosh.plist 
>> (and ...-7.0-... for those of you who run MacPython 2.3 on Panther).
>
> Unfortunately that doesn't seem to work for me (10.2.8 / MacPython 
> 2.3) I get a Requires unknown AppleDevTools error message - I do have 
> the apple dev tools installed.

Ronald probablly forgot to add an include directive for the standard 
database.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

Re: [Pyobjc-dev] 1.0 released

[Martina O. <Ma...@Oe...>]

Hi Again!

> There is a typo in you're url on the homepage, the available link 
> points to sourceforget instead of sourceforge.

I don't want to appear like nitpicking, but there is another minor 
mistake on the homepage: On the top right, under "Status" it says:
PyObjC 1.0 was released on 21 September 2003.  See the NEWS for details.

Should be 8 October, of course...
The same date is in the NEWS file, too.

ciao
Martina

Re: [Pyobjc-dev] 1.0 released

[Martina O. <Ma...@Oe...>]

Hello Ronald!

> PyObjC 1.0 is (finally ;-) released!

Congratulations! And Thank You and the other contributors for this  
terrific work!

But I have a problem:

when I try to download the package using packman, I only get an error  
message. Apparently the link is broken:

The plist points to:
http://heanet.dl.sourceforge.net/sourceforge/pyobjc/pyobjc-1.0-darwin- 
6.6-Power_Macintosh.tar.gz

whereas the file on the server seems to be:
http://heanet.dl.sourceforge.net/sourceforge/pyobjc/pyobjc-1.0.darwin- 
6.6-Power_Macintosh.tar.gz
(Note the period after "1.0"!)

Moreover, this file is about a week old! (01-Oct-2003 19:13) Did you  
accidentally upload the wrong file?

ciao
Martina