pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] PyObjC sources bundled with pbxbuild install

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

Hi,

when I'm building a distribution of some application using the
"pbxbuild install", I see that the included PyObjC folder contains
all .py files in addition to the .pyc files and all test_*.py[c]?
files, too. A little investigation shows the following numbers for
PyObjC 0.9:

Foo.app/Contents/Resources/PyObjC/
   *.pyc : 326713 B
   *.pyo : 152776 B
   *.py  : 229737 B

So the question is: do we really need to include the .py and .pyo
files? If we don't, we'd save about 373 KB in the resulting app,
which is about 14 % of an empty doc-based Python app, installed
from the PB template. I deleted the .py and .pyo files and it
still works.

Another question is if the __main__.py in Contents/Resources
really needs to be a source file or if it could also be a byte-
compiled one? This only for consistency reasons...

Dinu

--
Dinu C. Gherman
......................................................................
"La perfection est atteinte, non pas lorsqu'il n'y a plus rien
=E0 ajouter, mais lorsqu'il n'y a plus rien =E0 retirer."
(Antoine de Saint-Exup=E9ry)=

Re: [Pyobjc-dev] Object not being identified correctly?

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

On Monday, May 26, 2003, at 02:20 Europe/Amsterdam, Sean Gilbertson 
wrote:

> Hello all,
>
> 	I am using an NSOutlineView to display a hierarchy of data, so Cocoa 
> asks for items, and then later gives them back to me, looking for the 
> number of children, and "value" ("label") for the data, which it draws 
> onto the UI.  My problem is that, when Cocoa gives the item back to 
> me, the "in" test fails.  Take a look at the following code "snippet," 
> and its results:
>
>     def outlineView_isItemExpandable_( self, outlineView, item ):
>         NSLog( "isItemExpandable: %s" % ( item ) )
>
>         NSLog( "item in self.profiles: %s" % ( item in self.profiles ) 
> )
>
>         for profile in self.profiles:
>             NSLog( "%s" % ( profile ) )
>
> Results:
>
> 2003-05-25 20:09:04.427 Bluebeard2[5819] isItemExpandable: 
> <ServerInformation.ServerInformation instance at 0x8cfac0>
> 2003-05-25 20:09:04.429 Bluebeard2[5819] item in self.profiles: 0
> 2003-05-25 20:09:04.431 Bluebeard2[5819] 
> <ServerInformation.ServerInformation instance at 0x8cfac0>
>
> 	As you can see, the objects share the same reference address.  
> Performing similar actions in the Python interpreter works fine ("in" 
> tests return True).  I've also tried, in the "for profile in 
> profiles:" loop, "==" and "is" tests, which both return False.  Can 
> anyone shed some light onto why this is happening?

Are the items instances of (a subclass of) NSObject? You must use 
subclasses of NSObject as items for NSOutlineViews, and you must keep 
the items alive as long as the view might reference them. NSOutlineView 
cheats a little and stores the items in an internal datastructure 
without properly increasing there reference count.

I don't really think this is the problem your running into, but you 
never know :-)

Ronald

[Pyobjc-dev] Object not being identified correctly?

[Sean G. <pr...@cf...>]

Hello all,

	I am using an NSOutlineView to display a hierarchy of data, so Cocoa 
asks for items, and then later gives them back to me, looking for the 
number of children, and "value" ("label") for the data, which it draws 
onto the UI.  My problem is that, when Cocoa gives the item back to me, 
the "in" test fails.  Take a look at the following code "snippet," and 
its results:

     def outlineView_isItemExpandable_( self, outlineView, item ):
         NSLog( "isItemExpandable: %s" % ( item ) )

         NSLog( "item in self.profiles: %s" % ( item in self.profiles ) )

         for profile in self.profiles:
             NSLog( "%s" % ( profile ) )

Results:

2003-05-25 20:09:04.427 Bluebeard2[5819] isItemExpandable: 
<ServerInformation.ServerInformation instance at 0x8cfac0>
2003-05-25 20:09:04.429 Bluebeard2[5819] item in self.profiles: 0
2003-05-25 20:09:04.431 Bluebeard2[5819] 
<ServerInformation.ServerInformation instance at 0x8cfac0>

	As you can see, the objects share the same reference address.  
Performing similar actions in the Python interpreter works fine ("in" 
tests return True).  I've also tried, in the "for profile in profiles:" 
loop, "==" and "is" tests, which both return False.  Can anyone shed 
some light onto why this is happening?

Thanks,
	Sean

[Pyobjc-dev] [ pyobjc-Bugs-742862 ] NSApp().endSheet_() raising exception

[SourceForge.net <no...@so...>]

Bugs item #742862, was opened at 2003-05-24 22:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742862&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSApp().endSheet_() raising exception

Initial Comment:
If you close the window the attached app (build with "python 
buildapp.py --link build") a sheet with one button pops up. If you 
click the button, and action is called which is tries to end the sheet by 
doing

        NSApp().endSheet_(self.testSheet)
        self.testSheet.orderOut_(self)

However, NSApp().endSheet_() raises an exception that I can't figure 
out: NSInvalidArgumentException. An equivalent ObjC program 
behaves correctly.

Quitting then additionally causes a GC error:
  Fatal Python error: unexpected exception during garbage collection

I'm at a loss how to investigate this further. Btw. the behavior is 
identical between Python 2.2 + PyObjC 0.9 and Python CVS + PyObjC 
CVS.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742862&group_id=14534

[Pyobjc-dev] Another sheet bug

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

SF is down again, so I'll post here.

If you close the window the attached app (build with "python buildapp.py
--link build") a sheet with one button pops up. If you click the button,
and action is called which is tries to end the sheet by doing

        NSApp().endSheet_(self.testSheet)
        self.testSheet.orderOut_(self)

However, NSApp().endSheet_() raises an exception that I can't figure
out: NSInvalidArgumentException. An equivalent ObjC program behaves
correctly. Quitting then additionally causes a GC error:
  Fatal Python error: unexpected exception during garbage collection

I'm at a loss how to investigate this further. Btw. the behavior is
identical between Python 2.2 + PyObjC 0.9 and Python CVS + PyObjC CVS.

Just

Re: [Pyobjc-dev] GUI testing

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

Jack Jansen:

> I would assume the new System Events by Apple also work for Cocoa 
> programs?
>
> If they do then we simply send ourselves (or whatever other program we 
> try to test) the relevant System Event. System Events are an OSA 
> suite, and support for them is included in Python 2.3.
>
> In case people aren't familiar with System Events: this is the 
> recently released low-level stuff that makes Universal Access tick. 
> It's really good: you can basically interact with any GUI element of 
> any application. And there's an accompanying browser that lets you get 
> at the names you need to use to address the various UI elements in any 
> application.

The Anguish et al. book says on page 863 (Apple Events):

   "... Cocoa applications must use the Carbon Apple Event Manager API
    to send Apple Events. ..."

Unfortunately, it's not quite clear which version that refers to,
since just earlier it mentions problems with 10.1.3...

Dinu

--
Dinu C. Gherman
......................................................................
"It was wonderful to find America, but it would have been more wonder-
ful to miss it." (Mark Twain)

[Pyobjc-dev] [ pyobjc-Bugs-742734 ] NSDistributedNotificationCenter doesn't pass notif.object

[SourceForge.net <no...@so...>]

Bugs item #742734, was opened at 2003-05-24 15:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742734&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSDistributedNotificationCenter doesn't pass notif.object

Initial Comment:
When using NSDistributedNotificationCenter, the notification objects 
are not passed on, but instead a None is received. The same works 
fine NSNotificationCenter. I've attached a test file for both cases from 
the same program (although the distributed version works across 
programs, as well).



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742734&group_id=14534

[Pyobjc-dev] Inter-application communication adventures (was: GUI testing)

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

Ronald Oussoren:

> If the application supports loading plugins you could load a dummy 
> plugin that is only used as a communication vehicle between the test 
> framework and the runloop in the application. Writing plugins that 
> load Python code is not too hard, I have done a proof of concept 
> implementation some time ago (check the mailinglist archives) and I 
> intend to add a supported version of that to the bridge.

That sounds too hackumbersome to me. So I've looked into the class
NSDistributedNotificationCenter which allows notifications across
applications, but only strings can be passed (which is not enough
in this case). And BTW this seems to be buggy in PyObjC; I'll sub-
mit a bug report, shortly.

Thereafter I've tried distributed objects using NSConnection, which
works for me when passing "simple stuff" like a dictionary to an-
other app, but it seems to be copied oneway and I can't seem to
manipulate the original object in the original app...

Distributed objects in ObjC use type modifiers like oneway, bycopy
and byref and it would be interesting to know how much of this (if
anything) already works in PyObjC, or if it ever has a chance of
working on this side of the bridge?

My gut feeling is that one could play dirty and exchange string
representations of Python objects via distributed notifications
in both directions as some kind of a work around, but I can't use
this either, as long as that mechanism also seems to be buggy.

Dinu

--
Dinu C. Gherman
......................................................................
"A whole generation has grown up with the idea that it is normal
for them to have no freedom." (Richard M. Stallman)

Re: [Pyobjc-dev] GUI testing

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

On zaterdag, mei 24, 2003, at 14:19 Europe/Amsterdam, Ronald Oussoren 
wrote:

>
> On Saturday, May 24, 2003, at 14:01 Europe/Amsterdam, Dinu Gherman 
> wrote:
>
>>> I just tried this with simgle widgets and it looks promissing, but
>>> it could also become very challenging for complex widgets like NS-
>>> TableView, -OutlineView and basically anything deeply structured.
>>
>> Of course, the real challenge would be to trigger the tests from
>> *outside* the tested application! Honestly, I have no idea if it
>> is possible to get a handle on a running application from outside,
>> perhaps via notifications posted by NSApplication?

I would assume the new System Events by Apple also work for Cocoa 
programs?

If they do then we simply send ourselves (or whatever other program we 
try to test) the relevant System Event. System Events are an OSA suite, 
and support for them is included in Python 2.3.

In case people aren't familiar with System Events: this is the recently 
released low-level stuff that makes Universal Access tick. It's really 
good: you can basically interact with any GUI element of any 
application. And there's an accompanying browser that lets you get at 
the names you need to use to address the various UI elements in any 
application.
--
- Jack Jansen        <Jac...@or...>        
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] GUI testing

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

On Saturday, May 24, 2003, at 14:01 Europe/Amsterdam, Dinu Gherman 
wrote:

>> I just tried this with simgle widgets and it looks promissing, but
>> it could also become very challenging for complex widgets like NS-
>> TableView, -OutlineView and basically anything deeply structured.
>
> Of course, the real challenge would be to trigger the tests from
> *outside* the tested application! Honestly, I have no idea if it
> is possible to get a handle on a running application from outside,
> perhaps via notifications posted by NSApplication?

If the application supports loading plugins you could load a dummy 
plugin that is only used as a communication vehicle between the test 
framework and the runloop in the application. Writing plugins that load 
Python code is not too hard, I have done a proof of concept 
implementation some time ago (check the mailinglist archives) and I 
intend to add a supported version of that to the bridge.

Gui testing is probably a bit too much for testing PyObjC, although I'd 
love to see such a tool especially if it uses PyObjC.

BTW. Does anyone have ideas on how to execute some code when 'your' 
NSBundle is loaded. I need this to automaticly initialize the Python 
interpreter when someone loads a Python based bundle. My proof of 
concept uses the +initialize method of a dummy class. That works, but 
would mean that the user must install the Developer Tools when she 
wants to write plugins/preference panes/... in pure python (because you 
cannot have the same class in two different bundles, which would mean 
you'd have to generate a .m file based on a template)

Ronald

Re: [Pyobjc-dev] GUI testing

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

I wrote:

> Some stuff can certainly be done using NSControl.performClick_(sender)
> which every interactive widget should understand. So you can fill in
> relevant data into things like textviews, set sliders and so on, and
> then make the final "Go" button be magically pressed. Eventually, you
> need to read out the widgets or whatever else that should have chan-
> ged.
>
> I just tried this with simgle widgets and it looks promissing, but
> it could also become very challenging for complex widgets like NS-
> TableView, -OutlineView and basically anything deeply structured.

Of course, the real challenge would be to trigger the tests from
*outside* the tested application! Honestly, I have no idea if it
is possible to get a handle on a running application from outside,
perhaps via notifications posted by NSApplication?

Dinu

--
Dinu C. Gherman
......................................................................
"Journalism largely consists of saying 'Lord Jones is Dead' to people
who never knew that Lord Jones was alive." (G. K. Chesterton)

[Pyobjc-dev] GUI testing

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

Ronald Oussoren:

> I haven't looked at this yet (SF is down for maintainence, and I'm 
> about to leave anyway), but this does bring up another issue: How can 
> we add tests for GUI features to our test procedures. The best way I 
> can come up with right now would be to build an application that uses 
> a lot of functionality and let the user browse through it. Such an 
> application would also be usefull as a demo on how to use Cocoa 
> widgets from Python.

Some stuff can certainly be done using NSControl.performClick_(sender)
which every interactive widget should understand. So you can fill in
relevant data into things like textviews, set sliders and so on, and
then make the final "Go" button be magically pressed. Eventually, you
need to read out the widgets or whatever else that should have chan-
ged.

I just tried this with simgle widgets and it looks promissing, but
it could also become very challenging for complex widgets like NS-
TableView, -OutlineView and basically anything deeply structured.

But if it works it would be a very furtile road to take, even maybe
for purely ObjC applications which one would test using PyObjC! Oh,
dear, if that ever happens...

Dinu

--
Dinu C. Gherman
......................................................................
"Any sufficiently advanced technology is indistinguishable
from magic." (Arthur C. Clarke)

Re: [Pyobjc-dev] [ pyobjc-Bugs-742629 ] NSBeginAlertSheet crashes

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

On Saturday, May 24, 2003, at 01:15 Europe/Amsterdam, Just van Rossum 
wrote:

> Sf is currently in read-only mode, so here's an old-fashioned email.
>
>> Using NSBeginAlertSheet crashes for me. See the attached demo
>> program (build with "python buildapp.py --link build").
>
> I meant to add that to trigger the crash, simply close the window that
> shows up when the app has launched. This _should_ show a sheet, but
> crashes instead.

I haven't looked at this yet (SF is down for maintainence, and I'm 
about to leave anyway), but this does bring up another issue: How can 
we add tests for GUI features to our test procedures. The best way I 
can come up with right now would be to build an application that uses a 
lot of functionality and let the user browse through it. Such an 
application would also be usefull as a demo on how to use Cocoa widgets 
from Python.

Ronald

Re: [Pyobjc-dev] [ pyobjc-Bugs-742629 ] NSBeginAlertSheet crashes

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

Sf is currently in read-only mode, so here's an old-fashioned email.

> Using NSBeginAlertSheet crashes for me. See the attached demo 
> program (build with "python buildapp.py --link build").

I meant to add that to trigger the crash, simply close the window that
shows up when the app has launched. This _should_ show a sheet, but
crashes instead.

Just

[Pyobjc-dev] [ pyobjc-Bugs-742629 ] NSBeginAlertSheet crashes

[SourceForge.net <no...@so...>]

Bugs item #742629, was opened at 2003-05-24 00:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742629&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSBeginAlertSheet crashes

Initial Comment:
Using NSBeginAlertSheet crashes for me. See the attached demo 
program (build with "python buildapp.py --link build").

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742629&group_id=14534

Re: [Pyobjc-dev] NSNetServiceBrowser misbehaving

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

Bill Noon wrote:

> I just did a cvs checkout and rebuild and the program crashes just
> fine:

Same here.

Just

Re: [Pyobjc-dev] Testsuite adventures

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

Ronald Oussoren:

> Would you mind if I added allTestsCombined.py to PyObjC? This script
> seems to trigger bugs better and my runalltest script, and now that
> I've fixed all issues made some tests step on each others toes it
> also has a nicer user experience (much less output).

Of course not, my pleasure...

Dinu

--
Dinu C. Gherman
......................................................................
"Of course America had often been discovered before Columbus,
but it had always been hushed up." (Oscar Wilde)

Re: [Pyobjc-dev] NSNetServiceBrowser misbehaving

[Bill N. <no...@sn...>]

I just did a cvs checkout and rebuild and the program crashes just fine:

# pythonw resolver.py
setDelegate
search
Browsing for advertised services...
runloop
Bus error

This is with Python 2.3b1 on 10.2.5 (dual G4).

Here is the beginning of the crashlog:
Date/Time:  2003-05-23 15:41:08 -0400
OS Version: 10.2.5 (Build 6L29)
Host:       drift.nrcc.cornell.edu

Command:    python
PID:        9083

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000001

Thread 0 Crashed:
  #0   0x9068ba4c in objc_msgSend
  #1   0x00191238 in pythonify_c_value
  #2   0x001a6148 in init_objc
  #3   0x001a8e28 in ffi_closure_helper_DARWIN
  #4   0x001a9198 in ffi_closure_ASM
  #5   0x908bbbc0 in netServiceBrowserDispatchCallBack
  #6   0x92b36d74 in NetServiceBrowser::BrowserReply(int, char*, char*, 
char*, in
t, NetServiceBrowser*)
....


--Bill Noon
Northeast Regional Climate Center
Cornell University

On Friday, May 23, 2003, at 03:20 PM, Ronald Oussoren wrote:

> I works for me, I'm not sure if this is because I'm running on an 
> almost empty network or because I accidently fixed the bug your 
> running into. Could you try again using the current CVS (I've just 
> checked in my latest changes).
>
> ronald@mithril$ pythonw resolver.py
> setDelegate
> search
> Browsing for advertised services...
> runloop
> didFindService mithril.local.
> Browse complete
> startLookup
> didResolveAddress
> mithril.local.
>     192.168.2.37:80
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] NSNetServiceBrowser misbehaving

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

No luck, the bus error continues.  Any ideas?

-bob

On Friday, May 23, 2003, at 15:20 America/New_York, Ronald Oussoren 
wrote:

> I works for me, I'm not sure if this is because I'm running on an 
> almost empty network or because I accidently fixed the bug your 
> running into. Could you try again using the current CVS (I've just 
> checked in my latest changes).
>
> ronald@mithril$ pythonw resolver.py
> setDelegate
> search
> Browsing for advertised services...
> runloop
> didFindService mithril.local.
> Browse complete
> startLookup
> didResolveAddress
> mithril.local.
>     192.168.2.37:80
>
>

Re: [Pyobjc-dev] NSNetServiceBrowser misbehaving

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

I works for me, I'm not sure if this is because I'm running on an 
almost empty network or because I accidently fixed the bug your running 
into. Could you try again using the current CVS (I've just checked in 
my latest changes).

ronald@mithril$ pythonw resolver.py
setDelegate
search
Browsing for advertised services...
runloop
didFindService mithril.local.
Browse complete
startLookup
didResolveAddress
mithril.local.
     192.168.2.37:80

[Pyobjc-dev] [ pyobjc-Bugs-742543 ] "nil" used in Cocoa-Python doc-based app template

[SourceForge.net <no...@so...>]

Bugs item #742543, was opened at 2003-05-23 19:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742543&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Nobody/Anonymous (nobody)
Summary: "nil" used in Cocoa-Python doc-based app template

Initial Comment:
The default value returned by the method 
MyDocument.dataRepresentationOfType_() is "nil" instead of "None" - 
if this is what is needed there in the template(?). "nil" is definitely not 
defined. This is an excerpt from a new, with PB instantiated, Cocoa-
Python document-based application template: 

class MyDocument(NibClassBuilder.AutoBaseClass):
    ...

    def dataRepresentationOfType_(self, aType):
        # return an NSData containing the document's data represented 
as
        # the type identified by aType.
        return nil

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=742543&group_id=14534

Re: [Pyobjc-dev] Testsuite adventures

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

On Sunday, May 18, 2003, at 14:24 Europe/Amsterdam, Dinu Gherman wrote:
>> You are right w.r.t. end-users running the testsuite. At the very 
>> least we should add a new subcommand to setup.py (is that even 
>> possible with distutils?) and/or document how to do that with the 
>> source release. We should probably also distribute the runalltests 
>> script, or simular functionality, with the binary distribution.
>
> You could also test the distribution installed from a .dmg archive.

Would you mind if I added allTestsCombined.py to PyObjC? This script 
seems to trigger bugs better and my runalltest script, and now that 
I've fixed all issues made some tests step on each others toes it also 
has a nicer user experience (much less output).

Ronald

[Pyobjc-dev] NSNetServiceBrowser misbehaving

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

I was just screwing around with Rendezvous stuff, and it seems to have 
found some kind of PyObjC bug..

When I run the attached program on the LAN for *some* services, I get a 
bus error with this backtrace:

(gdb) bt
#0  0x9068ba4c in objc_msgSend ()
#1  0x00246990 in pythonify_c_value (type=0xfe190 "@", 
datum=0xbfffe2a8) at Modules/objc/objc_support.m:648
#2  0x002580b0 in method_stub (cif=0x1, resp=0xbfffe270, 
args=0xbfffe180, userdata=0xbfffe080) at 
Modules/objc/libffi_support.m:379
#3  0x00258d74 in ffi_closure_helper_DARWIN (closure=0x50fda0, 
rvalue=0xbfffe270, pgr=0x0, pfr=0x1, pst=0x1) at 
/Users/bob/src/Python/pyobjc/libffi-src/src/powerpc/ffi_darwin.c:707
#4  0x002590e8 in ffi_closure_ASM ()
#5  0x908bbbc0 in netServiceBrowserDispatchCallBack ()
#6  0x92b36db4 in NetServiceBrowser::BrowserReply(int, char*, char*, 
char*, int, NetServiceBrowser*) ()
.....

This traceback happens for _http._tcp (there should be a bunch of 
these) but not _daap._tcp (only my laptop is advertising right now).  
When browsing for _http._tcp I see the following output:
setDelegate
search
Browsing for advertised services...
runloop
Bus error

I'm running the latest CVS of PyObjC and an Apr 26 CVS compiler of 
Python 2.1b1.

[Pyobjc-dev] ***15.6 MILLION OPT- IN EMAIL ADDRESSES....$2,000 OF FREE SOFTWARE INCLUDED!

[shiquita <Inc...@ex...>]

DQogSGVsbG8sDQoNClRoaXMgZW1haWwgaXMgdG8gaW5mb3JtIHlvdSB0aGF0IHRoaXMgaXMgeW91
ciBsYXN0IGNoYW5jZSB0byBnZXQgaW4gDQpvbiB0aGlzIG9mZmVyLi4uLi4NCg0KT1ZFUiAxNS42
IE1JTExJT04gT1BULUlOLCBUQVJHRVRFRCBFTUFJTCBBRERSRVNTRVMuLi4NClBMVVMgJDIsMDAw
IFdPUlRIIE9GIEZSRUUgRU1BSUwgTUFSS0VUSU5HIFNPRlRXQVJFIQ0KDQpXT1VMRCBZT1UgTElL
RSBUTyBIQVZFIFlPVVIgTUVTU0FHRSBTRUVOIEJZDQpPVkVSIDE1LjYgTUlMTElPTiBPUFQtSU4s
IFRBUkdFVEVEIFBFT1BMRSBEQUlMWT8NCg0KQkVMT1cgSVMgSlVTVCBBIFNBTVBMRSBPRiBXSEFU
IFdFIEhBVkUgVE8gT0ZGRVIgWU9VLi4uDQoNCj4+PldFIFdJTEwgU1VQUExZIFlPVSBXSVRIIE9W
RVIgMTUuNiBNSUxMSU9OIE9QVC1JTiBFTUFJTA0KQUREUkVTU0VTIFRPIEdFVCBZT1UgU1RBUlRF
RCBSSUdIVCBBV0FZIQ0KDQo+Pj5GUkVFIEVNQUlMIEFERFJFU1MgRE9XTkxPQURTIEZPUiBMSUZF
IQ0KDQo+Pj5ZT1UgV0lMTCBSRUNFSVZFIE9WRVIgJDIsMDAwIFdPUlRIIE9GIA0KRU1BSUwgTUFS
S0VUSU5HIFNPRlRXQVJFIEZSRUUhDQoNCkluY2x1ZGluZy4uLi4uLg0KDQpCUk9BRENBU1QgRU1B
SUwgU0VORElORyBTT0ZUV0FSRS4uLihzZW5kIG1pbGxpb25zIG9mIGVtYWlsDQphZHZlcnRpc2Vt
ZW50cyBkYWlseSB3aXRoIGEgZmV3IGNsaWNrcyBvZiB5b3VyIG1vdXNlLiBOZXcgYnVpbHQgaW4g
DQpzdGVhbHRoIHRlY2hub2xvZ3kpLiBCZSBvbmUgb2YgdGhlIGZpcnN0IHBlb3BsZSB0byB1c2Ug
aXQuIFdlIHVzZWQgdGhlIA0Kc2FtZSBzb2Z0d2FyZSB0byBzZW5kIHlvdSB0aGlzIGVtYWlsIG1l
c3NhZ2UuDQoNCkVNQUlMIEVYVFJBQ1RJT04gU09GVFdBUkUuLi4oUmV0cmVpdmUgbmV3IHRhcmdl
dGVkIGVtYWlsDQphZGRyZXNzZXMgZGFpbHkuIEh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiB0aGVt
KQ0KDQpMSVNUIE1BTkFHRU1FTlQgU09GVFdBUkUuLi4oS2VlcCB5b3VyIGxpc3RzIGNsZWFuLCBv
cHQtaW4NCmFuZCBtYW5hZ2UgYWxsIHlvdXIgcmVtb3ZlIHJlcXVlc3RzLCBsZWFkcywgc2FsZXMg
ZXRjLi4uKQ0KDQpQT1AtVVAgQURWRVJUSVNFUi4uLk5vIG5lZWQgdG8gcGF5IHNvbWVvbmUgZWxz
ZSBmb3IgDQpwb3AtdXAgYWR2ZXJ0aXNpbmcuIFNhdmUgJDEsMDAwcyB3ZWVrbHkuIEl0J3MgeW91
cnMgdG9kYXkgZnJlZSEgDQpQbHVzIHlvdSBjYW4gcmVzZWxsIHRoaXMgc29mdHdhcmUgYW5kIGtl
ZXAgMTAwJSBvZiB0aGUgcHJvZml0IG9yDQpzaW1wbHkgZ2l2ZSBpdCBhcyBhIGZyZWUgZ2lmdCBh
bG9uZyB3aXRoIHlvdXIgY3VycmVudCBzZXJ2aWNlcy4NCg0KYW5kIG11Y2guLi5tdWNoIG1vcmUh
DQoNCkh1cnJ5Li4uVGhpcyBleHRyYW9yZGluYXJ5IG9mZmVyIGVuZHMgc29vbiENCg0KVG8gZmlu
ZCBvdXQgbW9yZSBpbmZvcm1hdGlvbiwgRG8gbm90IHJlc3BvbmQgYnkgZW1haWwuIEluc3RlYWQs
IGNsaWNrDQpvbiB0aGUgbGluayBiZWxvdyBvciBjb3B5IGFuZCBwYXN0ZSB0aGUgY29tcGxldGUg
d2ViIGFkZHJlc3MgaW50byANCnlvdXIgSW50ZXJuZXQgYnJvd3Nlci4NCg0KaHR0cDovL3d3dy5m
b3J0aGViZXN0dC5jb20vNDA5MzI0L2Jyb2FkY2FzdC5odG0NCg0KDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpXYW50IHRvIGJlIFJF
TU9WRUQgZnJvbSBvdXIgZW1haWwgbGlzdD8NCllvdSB3ZXJlIHNlbnQgdGhpcyBlbWFpbCBiZWNh
dXNlIHlvdSB1c2VkIG91ciBPcHQtaW4gc2VydmljZS4NCldlIGhvcGUgeW91IGVuam95IHJlYWRp
bmcgb3VyIG1lc3NhZ2VzLiBIb3dldmVyLCBpZiB5b3UnZCByYXRoZXINCm5vdCByZWNlaXZlIGZ1
dHVyZSBlLW1haWxzIGZyb20gdXMsIENsaWNrIG9uIHRoZSBsaW5rIGJlbG93Lg0KaHR0cDovL3d3
dy5mb3J0aGViZXN0dC5jb20vNDA5MzI0L3JlbW92ZW1lLmh0bQ0KVGhhbmsgeW91IGZvciB5b3Vy
IGNvb3BlcmF0aW9uLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18=

[Pyobjc-dev] ***15.6 MILLION OPT- IN EMAIL ADDRESSES....$2,000 OF FREE SOFTWARE INCLUDED!

[Tina M. A. Daughter<Inc...@ex...>]

DQogSGVsbG8sDQoNClRoaXMgZW1haWwgaXMgdG8gaW5mb3JtIHlvdSB0aGF0IHRoaXMgaXMgeW91
ciBsYXN0IGNoYW5jZSB0byBnZXQgaW4gDQpvbiB0aGlzIG9mZmVyLi4uLi4NCg0KT1ZFUiAxNS42
IE1JTExJT04gT1BULUlOLCBUQVJHRVRFRCBFTUFJTCBBRERSRVNTRVMuLi4NClBMVVMgJDIsMDAw
IFdPUlRIIE9GIEZSRUUgRU1BSUwgTUFSS0VUSU5HIFNPRlRXQVJFIQ0KDQpXT1VMRCBZT1UgTElL
RSBUTyBIQVZFIFlPVVIgTUVTU0FHRSBTRUVOIEJZDQpPVkVSIDE1LjYgTUlMTElPTiBPUFQtSU4s
IFRBUkdFVEVEIFBFT1BMRSBEQUlMWT8NCg0KQkVMT1cgSVMgSlVTVCBBIFNBTVBMRSBPRiBXSEFU
IFdFIEhBVkUgVE8gT0ZGRVIgWU9VLi4uDQoNCj4+PldFIFdJTEwgU1VQUExZIFlPVSBXSVRIIE9W
RVIgMTUuNiBNSUxMSU9OIE9QVC1JTiBFTUFJTA0KQUREUkVTU0VTIFRPIEdFVCBZT1UgU1RBUlRF
RCBSSUdIVCBBV0FZIQ0KDQo+Pj5GUkVFIEVNQUlMIEFERFJFU1MgRE9XTkxPQURTIEZPUiBMSUZF
IQ0KDQo+Pj5ZT1UgV0lMTCBSRUNFSVZFIE9WRVIgJDIsMDAwIFdPUlRIIE9GIA0KRU1BSUwgTUFS
S0VUSU5HIFNPRlRXQVJFIEZSRUUhDQoNCkluY2x1ZGluZy4uLi4uLg0KDQpCUk9BRENBU1QgRU1B
SUwgU0VORElORyBTT0ZUV0FSRS4uLihzZW5kIG1pbGxpb25zIG9mIGVtYWlsDQphZHZlcnRpc2Vt
ZW50cyBkYWlseSB3aXRoIGEgZmV3IGNsaWNrcyBvZiB5b3VyIG1vdXNlLiBOZXcgYnVpbHQgaW4g
DQpzdGVhbHRoIHRlY2hub2xvZ3kpLiBCZSBvbmUgb2YgdGhlIGZpcnN0IHBlb3BsZSB0byB1c2Ug
aXQuIFdlIHVzZWQgdGhlIA0Kc2FtZSBzb2Z0d2FyZSB0byBzZW5kIHlvdSB0aGlzIGVtYWlsIG1l
c3NhZ2UuDQoNCkVNQUlMIEVYVFJBQ1RJT04gU09GVFdBUkUuLi4oUmV0cmVpdmUgbmV3IHRhcmdl
dGVkIGVtYWlsDQphZGRyZXNzZXMgZGFpbHkuIEh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiB0aGVt
KQ0KDQpMSVNUIE1BTkFHRU1FTlQgU09GVFdBUkUuLi4oS2VlcCB5b3VyIGxpc3RzIGNsZWFuLCBv
cHQtaW4NCmFuZCBtYW5hZ2UgYWxsIHlvdXIgcmVtb3ZlIHJlcXVlc3RzLCBsZWFkcywgc2FsZXMg
ZXRjLi4uKQ0KDQpQT1AtVVAgQURWRVJUSVNFUi4uLk5vIG5lZWQgdG8gcGF5IHNvbWVvbmUgZWxz
ZSBmb3IgDQpwb3AtdXAgYWR2ZXJ0aXNpbmcuIFNhdmUgJDEsMDAwcyB3ZWVrbHkuIEl0J3MgeW91
cnMgdG9kYXkgZnJlZSEgDQpQbHVzIHlvdSBjYW4gcmVzZWxsIHRoaXMgc29mdHdhcmUgYW5kIGtl
ZXAgMTAwJSBvZiB0aGUgcHJvZml0IG9yDQpzaW1wbHkgZ2l2ZSBpdCBhcyBhIGZyZWUgZ2lmdCBh
bG9uZyB3aXRoIHlvdXIgY3VycmVudCBzZXJ2aWNlcy4NCg0KYW5kIG11Y2guLi5tdWNoIG1vcmUh
DQoNCkh1cnJ5Li4uVGhpcyBleHRyYW9yZGluYXJ5IG9mZmVyIGVuZHMgc29vbiENCg0KVG8gZmlu
ZCBvdXQgbW9yZSBpbmZvcm1hdGlvbiwgRG8gbm90IHJlc3BvbmQgYnkgZW1haWwuIEluc3RlYWQs
IGNsaWNrDQpvbiB0aGUgbGluayBiZWxvdyBvciBjb3B5IGFuZCBwYXN0ZSB0aGUgY29tcGxldGUg
d2ViIGFkZHJlc3MgaW50byANCnlvdXIgSW50ZXJuZXQgYnJvd3Nlci4NCg0KaHR0cDovL3d3dy5m
b3J0aGViZXN0dC5jb20vNDA5MzI0L2Jyb2FkY2FzdDYuaHRtDQoNCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KV2FudCB0byBiZSBS
RU1PVkVEIGZyb20gb3VyIGVtYWlsIGxpc3Q/DQpZb3Ugd2VyZSBzZW50IHRoaXMgZW1haWwgYmVj
YXVzZSB5b3UgdXNlZCBvdXIgT3B0LWluIHNlcnZpY2UuDQpXZSBob3BlIHlvdSBlbmpveSByZWFk
aW5nIG91ciBtZXNzYWdlcy4gSG93ZXZlciwgaWYgeW91J2QgcmF0aGVyDQpub3QgcmVjZWl2ZSBm
dXR1cmUgZS1tYWlscyBmcm9tIHVzLCBDbGljayBvbiB0aGUgbGluayBiZWxvdy4NCmh0dHA6Ly93
d3cuZm9ydGhlYmVzdHQuY29tLzQwOTMyNC9yZW1vdmVtZS5odG0NClRoYW5rIHlvdSBmb3IgeW91
ciBjb29wZXJhdGlvbi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19f