pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Sockets, Files, Fun

[Tony L. <ton...@lo...>]

Wow, thats cool. I can't get it to work, which I'm guessing is an 
issue with my environment:

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.
>>>  from Foundation import NSFileHandle 
>>>  NSFileHandle
<objective-c class NSFileHandle at 0xa07edbf8>
>>>  NSFileHandle.alloc()
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
objc.error: Class NSObject does not respond to alloc
>>>

I've just re-built pyobjc from CVS; using Apple stock python; Mac OS X 10.2.3

At 11:34 PM +0100 1/21/03, Just van Rossum wrote:
>(Adding a check so it only accepts
>connections from the local machine is left as an exercise for the reader
>;-)

-		sock.bind(("", port))
+		sock.bind(("127.0.0.1", port))


:)

-Tony

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

David Eppstein wrote:

> The table application I have at
> <http://www.ics.uci.edu/~eppstein/tabulizer> does pass Python objects
> to addObserver_... specifically, they are controller objects that
> belong to the document's nib and are subclasses of NSObject. 

Sorry, I must have been unclear: when I say "Python objects" I
specifically mean objects that _don't_ inherit from NSObject. I'm pretty
sure (although I didn't try this time) that if you add a pure Python
object as an observer you will see crashes, as the object will be
wrapped in an autoreleased proxy, which will be gone too soon.

> Having
> to use special wrappers every time I call back and forth between
> Python and objc would make pyobjc lose a lot of its appeal: the
> reason for programming in Python is that it makes it unnecessary to
> deal with that sort of bookkeeping, most of the time.

The question is whether implicitly wrapping (eg.) a Python list so it
can be passed to methods that expect an NSArray is such a good idea.
It's pretty cool, but it only works as long as the receiver keeps a
reference as long as it needs it (or is done with it before the end of
the current event loop cycle).

But then again, it's easily possible to get crashes with NSObjects as
well (eg. if your observer gets deallocated and you haven't removed it
from the notification center yet), so perhaps I worry too much about
safety...

Just

Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

On 1/22/03 12:22 AM +0100 Just van Rossum <ju...@le...> wrote:
> I noticed that the documentation for the NSNotificationCenter
> addObserver:selector:name:object: method says it doesn't retain observer
> objects. This means that you shouldn't pass observer objects that aren't
> unretained NSObject instances, eg. any Python object (just like with
> NSOutlineView).
>
> I wonder now, when _is_ it appropriate to pass Python objects to ObjC,
> and is it really that useful to make it worth it to give up some safety?
> Perhaps it's better to explicitly wrap Python objects in a utility
> class, and/or have to convenience functions that wrap some standard
> Python into matching ObjC objects? Perhaps we could add a method to
> NSArray, say NSArray.fromPythonSequence_(). Stuff like that.
>
> Just-thinking-out-loud

The table application I have at 
<http://www.ics.uci.edu/~eppstein/tabulizer> does pass Python objects to 
addObserver_... specifically, they are controller objects that belong to 
the document's nib and are subclasses of NSObject.  Having to use special 
wrappers every time I call back and forth between Python and objc would 
make pyobjc lose a lot of its appeal: the reason for programming in Python 
is that it makes it unnecessary to deal with that sort of bookkeeping, most 
of the time.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

[Pyobjc-dev] Passing Python objects to ObjC again.

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

I noticed that the documentation for the NSNotificationCenter
addObserver:selector:name:object: method says it doesn't retain observer
objects. This means that you shouldn't pass observer objects that aren't
unretained NSObject instances, eg. any Python object (just like with
NSOutlineView).

I wonder now, when _is_ it appropriate to pass Python objects to ObjC,
and is it really that useful to make it worth it to give up some safety?
Perhaps it's better to explicitly wrap Python objects in a utility
class, and/or have to convenience functions that wrap some standard
Python into matching ObjC objects? Perhaps we could add a method to
NSArray, say NSArray.fromPythonSequence_(). Stuff like that.

Just-thinking-out-loud

[Pyobjc-dev] Sockets, Files, Fun

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

I've played around a bit with NSFileHandle for sockets and came up with
a little demo that might actually be useful. It's called
TelnetInspect.py (see enclosed), and allows you to run a simple telnet
sever in your Cocoa app. Add this to your main program:

  from TelnetInspect import TelnetServer
  server = TelnetServer(port=9090)

Then start the app, and do "telnet localhost 9090" on the command line.
This gives you access to an interactive Python interpreter, ready to
inspect the internals of your application. Pretty nice! Wish I knew how
to add readline support... (Adding a check so it only accepts
connections from the local machine is left as an exercise for the reader
;-)

What I have learned:
- how to use an NSFileHandle to asynchronously accept socket connections 
- how to use an NSFileHandle to asynchronously read data
- how to use the NSNotificationCenter
- how to grab values from a NSNotification
- how to grab data from an NSData instance (hm.)
- how to wrap data in an NSData instance (ugh!)

What I failed at:
- To actually use NSSocketPort, but I forgot what went wrong. Using a
  Python socket and feeding sock.fileno() to the NSFileHandle works
  fine.
- Getting a notification when the connection is closed externally.

Bug report:
- If a notification callback raises an error, the console prints
  something like:

2003-01-21 23:07:46.744 python2.3[14129] Exception raised during
posting of notification.  Ignored.  exception: No attribute retaincount

  The app stays alive until I trigger another (non-notification)
callback (click anything that triggers an action written in Python), it
then dies with a traceback:

Traceback (most recent call last):
  File
"/Users/just/code/pyobjc/Examples/pyDotView/build/PyDotView23.app/
Contents/Resources/__main__.py", line 13, in ?
    sys.exit(AppKit.NSApplicationMain(sys.argv))
AttributeError: 'str' object has no attribute '_pyobjc_info_'


Just

[Pyobjc-dev] mbox file for this list, where?

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

Hi, I can't find any mbox file on SF, is there any?

Dinu

--
Dinu C. Gherman
......................................................................
"Les gens se divisent en deux cat=E9gories=A0: les uns cherchent et
ne trouvent pas, les autres trouvent et ne sont pas contents."
(Mihail Eminescu)=

Re: [Pyobjc-dev] posing

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

On Tuesday, Jan 21, 2003, at 12:19 US/Eastern, Ronald Oussoren wrote:
> Using a global dict might be not that much more expensive than the 
> current situation. We currently use an instance variable, but access 
> it using functions in the runtime which are likely to use a linear 
> search for the right instance variable. It is at the very least a lot 
> more expensive than the way instance variables are normally accessed 
> (as struct members).

Right.

My current thoughts:

Implement -(PyObject*)__pyobjc_pythonImplementation__ to retrieve the 
Python side of the implementation for the instance, if there is one.   
The PyObject* reference will be retrieved from an NSMapTable (fast and 
naturally stores non-object types).   Depending on the implementation 
of NSMapTable, lots of little Maps may be more efficient than one big 
instance map?  If that is the case, per class map tables could be 
managed through per class methods implemented using an FFI closure that 
contains the reference to the map table.

With FFI, it'd be possible to implement the per-class Python 
definitions as a series of methods whose implementations are closures 
that return the appropriate hunk of data.   This would mean the 
elimination of the class-wrapper struct -- not that it is problematic, 
but we are hosed if the size of objc_class changes [and we don't 
recompile].

Its too bad we don't have per-instance methods;  that is, a method 
whose implementation changes per instance.   Really just another way of 
saying "I want instance variables without it being an instance 
variable", I know.

--

Alternative:

Use indexed ivars.

That is, posing will *only* affect instances instantiated after the 
posing happened (this is true of ObjC).   As such, we don't have to 
worry about instances created before posing occurred.

Since that means that we have code that will be invoked for the class 
allocation, we could allocate some indexed ivars to contain the 
per-instance state.

Of course, indexed ivars are generally evil.   If any of Apple's 
classes use 'em, we have a problem with our subclass of that class.

I'm thinking the NSMapTable() route is better in that it is slightly 
slower but more robust.

b.bum

Re: [Pyobjc-dev] Experimenting with libffi

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

Ronald Oussoren wrote:

> I've added a tarball of a recent snapshot of libffi to the files 
> section at sourceforge. This makes it possible to experiment with the 
> libffi-support of PyObjC without downloading the entire GCC 
> distribution.
> 
> Ronald
> 
> PS. This is not an 'official' release/snapshot by the libffi 
> maintainers, bothering them about (build) problems would not be very 
> polite unless you can reproduce it with libffi from the GCC tree ;-)

FWIW I only managed to configure/build it in a subdirectory of libffi.
If you run ./configure in the top level dir it complains about not being
able to find "install-sh".

Just

[Pyobjc-dev] Experimenting with libffi

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

I've added a tarball of a recent snapshot of libffi to the files 
section at sourceforge. This makes it possible to experiment with the 
libffi-support of PyObjC without downloading the entire GCC 
distribution.

Ronald

PS. This is not an 'official' release/snapshot by the libffi 
maintainers, bothering them about (build) problems would not be very 
polite unless you can reproduce it with libffi from the GCC tree ;-)

Re: [Pyobjc-dev] Threading

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

On Tuesday, Jan 21, 2003, at 00:59 Europe/Amsterdam, Bob Ippolito wrote:

> On Monday, Jan 20, 2003, at 18:50 America/New_York, Tony Lownds wrote:
>
>> Hi,
>>
>> I'm trying to make a Cocoa front end for an HTTP based python 
>> application (spambayes). My program spawns a thread to handle the 
>> HTTP requests, but that thread blocks. I've also tried a thread that 
>> does nothing count, and it blocks too. Any advice on writing a pyobjc 
>> program that uses threads?
>>
>> PyObjC .8
>> python 2.2 (from Apple)
>
> My best suggestion is simply don't :)

This the right suggestion for now (without saying whether threading is 
good or not). PyObjC is currently not thread-safe. Most of the code 
should be thread-safe, but we haven't really checked if it is. 
Furthmore you have to add some special code to Python extension module 
to make them cooperate in the Python implementation of multithreading 
and we haven't done that yet.

Ronald

Re: [Pyobjc-dev] posing

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

Using a global dict might be not that much more expensive than the 
current situation. We currently use an instance variable, but access it 
using functions in the runtime which are likely to use a linear search 
for the right instance variable. It is at the very least a lot more 
expensive than the way instance variables are normally accessed (as 
struct members).

Ronald

On Monday, Jan 20, 2003, at 17:13 Europe/Amsterdam, Jack Jansen wrote:

> Can't we have two types of bridging objects, both of which share the 
> __pyobc_pythonImplementation__ method but implemented in a different 
> way? In the cheap bridged object you would have the instance variable 
> and __pyobc_pythonImplementation__ would simply return that. In the 
> All Singing All Dancing bridged object __pyobc_pythonImplementation__ 
> would be implemented using a global dict. (There would need to be 
> auxiliary routines to set and break the link between the objc and 
> python objects too).
>
> I assume the Python programmer will know which of the objects would 
> need to be subclasses of the expensive object...
> --
> 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
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

Bob Ippolito wrote:

> Theoretically, all we need is a running thread that has an array of 
> sockets to select() on that send notifications to the MEL.  I spent a 
> couple hours looking into it, and there's simply no way without at 
> least one extra thread... 

Perhaps we should write a little C extension that spawns a thread and
does the select call from that thread. If this is pure (Obj)C, this
would avoid the whole GIL issue. Perhaps with an interface like this:

import CocoaSelect
CocoaSelect.select(readsocks, writesocks, errorsocks, timeout,
                   target, selector)

This function would call select (the C version) in the worker thread,
and when it returns, it would do
 
    [target performSelectorOnMainThread:selector
     withObject:<results_of_select> waitUntilDone:NO];

Or something. Hm, I just looked at Python's selectmodule.c and it's not
particularly easy to use select from C... Perhaps a native Cocoa
solution is easier.

Just

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

On Tuesday, Jan 21, 2003, at 08:53 America/New_York, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> Did you follow the GIL discussions on python-dev the last few weeks?
>
> Only superficially.
>
>> I filed them away (too busy, but I do want to read them eventually)
>> but there might be interesting stuff in there.
>
> Right. It raises at least one point that may be relevant to us: how to
> find out whether we already have the lock?
>
> But the PyObjC code seems hairy enough to make this hard regardless how
> convenient the PyThread API is :-(
>
> That said, it would be nice to have a recipe that would allow the Cocoa
> run loop to work with (async/non-blocking) sockets, if that's possible
> to begin with. It would be fantastic if we could provide a way to
> integrate asyncore- and Twisted- based code in Cocoa apps without 
> having
> to resort to timers.

Theoretically, all we need is a running thread that has an array of 
sockets to select() on that send notifications to the MEL.  I spent a 
couple hours looking into it, and there's simply no way without at 
least one extra thread...  As far as Twisted goes, it would take me 
minutes to write a reactor (twisted's "runloop") that uses such a 
facility if one existed... I just don't have the time right now to 
develop that framework, I've looked around in the usual places and 
haven't even found a framework that I can do nonblocking socket 
operations given an existing filedescriptor, let alone one that does it 
with a pool.

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

Jack Jansen wrote:

> Did you follow the GIL discussions on python-dev the last few weeks?

Only superficially.

> I filed them away (too busy, but I do want to read them eventually)
> but there might be interesting stuff in there.

Right. It raises at least one point that may be relevant to us: how to
find out whether we already have the lock?

But the PyObjC code seems hairy enough to make this hard regardless how
convenient the PyThread API is :-(

That said, it would be nice to have a recipe that would allow the Cocoa
run loop to work with (async/non-blocking) sockets, if that's possible
to begin with. It would be fantastic if we could provide a way to
integrate asyncore- and Twisted- based code in Cocoa apps without having
to resort to timers.

Just

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

On Tuesday, Jan 21, 2003, at 11:24 Europe/Amsterdam, Just van Rossum 
wrote:

> I've just spent some time on trying to get threads to work but I had to
> give up. There are _many_ places where ObjC calls into Python, but if I
> guard all those places (erm, that is, those places that I found ;-) I
> get deadlocks as some of these call each other and the GIL primitives
> don't support nesting :-(. It will be quite a bit of work to get right.

Did you follow the GIL discussions on python-dev the last few weeks? I 
filed them away (too busy, but I do want to read them eventually) but 
there might be interesting stuff in there.
--
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] select()/poll() on OS X w/PyObjC

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

I've just spent some time on trying to get threads to work but I had to
give up. There are _many_ places where ObjC calls into Python, but if I
guard all those places (erm, that is, those places that I found ;-) I
get deadlocks as some of these call each other and the GIL primitives
don't support nesting :-(. It will be quite a bit of work to get right.

Just

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

Just van Rossum wrote:

> happen, so other Python threads will only run during even callbacks,

That should have been "event callbacks written in Python".

Btw. here is the documentation for the GIL:

  http://www.python.org/doc/current/api/threads.html

Just

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

Tony Lownds wrote:

> >Now -- with all that said -- if you want to do pure pythonic style 
> >accept/port/etc threaded I/O control flow, then you *should* be able 
> >to do everything in a thread in pure python, passing what you need 
> >to the mixed Python/ObjC threads via normal python threading API...
> 
> I haven't had any luck with this, using either accept() or sleep() in 
> a loop. Is the current CVS code better than 0.8 for this?

I don't think so. The problem is the GIL (the Global Interpreter Lock).
When Python calls into NSApplicationMain, it should release the GIL, and
when it calls back into Python it should acquire it again. This doesn't
happen, so other Python threads will only run during even callbacks,
which is effectively never if the app is idle. I saw there is a start at
implementing this (there's some untested stuff in objc_util.[hm]) but
it's not used yet. I would like to help here, but I have no idea where
exactly ObjC enters Python (let's hope it's only in few places!), and
which the critical places are besides NSApplicationMain where the lock
should be released. Python's _tkinter module could be used as an example
of how it's done for the Python-Tcl bridge.

Just

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

On Monday, Jan 20, 2003, at 23:49 America/New_York, Tony Lownds wrote:

> Unless you are writing a pure Foundation based application without=20
> NSRunLoop using PyObjC, using poll()/select() while using the=20
> Foundation/AppKit APIs on OS X will result in an application that is=20=

> considerably less efficient than might be desired.
>
> Even in the context of threading, any thread that will also have=20
> Foundation style interaction will *generally* want to use NSRunLoop to=20=

> control the event loop and event processing, including port events and=20=

> such.=A0=A0 NSRunLoop actually does a very good job of lumping =
everything=20
> together such that passes through the event loop remain efficient.
>
> That is, the last thing you want your code to do is to end up in a=20
> situation where it is busy-waiting on something.=A0 That is, you =
really=20
> want to avoid monitoring stuff via short interval NSTimers -- not only=20=

> does it cause the app to busy wait while monitoring the resource=20
> targeted by the NSTimer but it will also cause the main event loop=20
> [MEL] to keep cycling when it normally wouldn't have to.

I agree that it's Not The Right Way.  I never said it was..  However,=20
IIRC NSSocketPort and whatever else suck for two reasons:  (1) You need=20=

to use them to connect, you can't pass them a file descriptor (2) Each=20=

one gets their own thread.

Ideally what I want is a file descriptor pool, that does select() on an=20=

array of file descriptors and fires events when something happens, that=20=

way I only have two threads (including the MEL) rather than N threads,=20=

which should  certainly be way more efficient than N threads on a 1 or=20=

2 cpu system (which all OS X boxes are).

But, the NSTimer way Just Works with No Significant Changes to either=20
code base.. so it's sufficient for a proof of concept demo, which is=20
what I intended to do.. just to get it over with, because nobody else=20
had demonstrated integrating the twisted event loop with Cocoa.

-bob=

Re: [Pyobjc-dev] select()/poll() on OS X w/PyObjC

[Tony L. <ton...@lo...>]

>Unless you are writing a pure Foundation based application without 
>NSRunLoop using PyObjC, using poll()/select() while using the 
>Foundation/AppKit APIs on OS X will result in an application that is 
>considerably less efficient than might be desired.
>
>Even in the context of threading, any thread that will also have 
>Foundation style interaction will *generally* want to use NSRunLoop 
>to control the event loop and event processing, including port 
>events and such.   NSRunLoop actually does a very good job of 
>lumping everything together such that passes through the event loop 
>remain efficient.
>
>That is, the last thing you want your code to do is to end up in a 
>situation where it is busy-waiting on something.  That is, you 
>really want to avoid monitoring stuff via short interval NSTimers -- 
>not only does it cause the app to busy wait while monitoring the 
>resource targeted by the NSTimer but it will also cause the main 
>event loop [MEL] to keep cycling when it normally wouldn't have to.

Yes, I can see that this might be a problem. But, it works without 
changes to asyncore...

>For accept() type events, check out NSFileHandle's...
>
>- (void)acceptConnectionInBackgroundAndNotifyForModes:(NSArray *)modes;
>- (void)acceptConnectionInBackgroundAndNotify;
>
>... api.

I'm trying this out, although I'm not sure how it will integrate with 
asyncore. Its not working yet, here is my code:


class MyAppDelegate(AutoBaseClass):
     def applicationDidFinishLaunching_(self, aNotification):
         NSLog( "Application did finish launching." )
         port = 50009
        
         import socket
         self.socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
         self.socket.bind(('', port))
         self.socket.listen(1)
         fd = self.socket.fileno()
         self.nsfilehandle = NSFileHandle.alloc().initWithFileDescriptor_(fd)
         NSNotificationCenter.defaultCenter().addObserver_selector_name_object_(
            self,
            'acceptConnection:',
            NSFileHandleDataAvailableNotification,
            self.nsfilehandle)
         self.nsfilehandle.acceptConnectionInBackgroundAndNotify()
         print "waiting for connection on %s" % port

     def acceptConnection_(self, aNotification):
         print "Accepted connection"
         print aNotification.userInfo()

Is that how one uses Notifications? I see the "waiting for 
connection", then telnet to that port, which connects,  but I never 
see the "Accepted connection".

>Now -- with all that said -- if you want to do pure pythonic style 
>accept/port/etc threaded I/O control flow, then you *should* be able 
>to do everything in a thread in pure python, passing what you need 
>to the mixed Python/ObjC threads via normal python threading API...

I haven't had any luck with this, using either accept() or sleep() in 
a loop. Is the current CVS code better than 0.8 for this?

Thanks,
-Tony

Re: [Pyobjc-dev] Threading

[Tony L. <to...@lo...>]

>
>When I say poll, I mean it calls select() with a short timeout 
>interval via NSTimer on a regular basis.

[looks at cocoaDemo..]

Cool, I can do that with asyncore too!

Thanks Bob, I thought I was screwed.

-Tony

[Pyobjc-dev] select()/poll() on OS X w/PyObjC

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

On Monday, Jan 20, 2003, at 20:38 US/Eastern, Bob Ippolito wrote:
>> BTW, python 2.2 from Apple does not appear to have poll() - does 
>> twisted work on  python 2.2 from Apple?
>
> When I say poll, I mean it calls select() with a short timeout 
> interval via NSTimer on a regular basis.

Unless you are writing a pure Foundation based application without 
NSRunLoop using PyObjC, using poll()/select() while using the 
Foundation/AppKit APIs on OS X will result in an application that is 
considerably less efficient than might be desired.

Even in the context of threading, any thread that will also have 
Foundation style interaction will *generally* want to use NSRunLoop to 
control the event loop and event processing, including port events and 
such.   NSRunLoop actually does a very good job of lumping everything 
together such that passes through the event loop remain efficient.

That is, the last thing you want your code to do is to end up in a 
situation where it is busy-waiting on something.  That is, you really 
want to avoid monitoring stuff via short interval NSTimers -- not only 
does it cause the app to busy wait while monitoring the resource 
targeted by the NSTimer but it will also cause the main event loop 
[MEL] to keep cycling when it normally wouldn't have to.

The MEL corresponds to the NSRunLoop for the main thread.   Every 
thread has an NSRunLoop associated with it (whether or not it is used 
is irrelevant).  As long as you use API like...

- (void)addPort:(NSPort *)aPort forMode:(NSString *)mode;
- (void)removePort:(NSPort *)aPort forMode:(NSString *)mode;

... where aPort is likely an instance of NSSocketPort, then the 
Appkit/Foundation will ensure the polling/selecting/waiting will occur 
in a fashion that doesn't cause the app to consume lots of CPU when 
simply waiting for events.

For accept() type events, check out NSFileHandle's...

- (void)acceptConnectionInBackgroundAndNotifyForModes:(NSArray *)modes;
- (void)acceptConnectionInBackgroundAndNotify;

... api.

Now -- with all that said -- if you want to do pure pythonic style 
accept/port/etc threaded I/O control flow, then you *should* be able to 
do everything in a thread in pure python, passing what you need to the 
mixed Python/ObjC threads via normal python threading API...

b.bum

Re: [Pyobjc-dev] Threading

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

On Monday, Jan 20, 2003, at 19:56 America/New_York, Tony Lownds wrote:

> I'm aiming for a thin integration over an existing project. The fewer 
> changes to the server code, the better. It uses asyncore, porting to 
> twisted would probably involve too many changes for my current goals.

It shouldn't be too hard if you approach it the right way.  You'll 
likely end up throwing out more code than you change because twisted 
does so many things for you.

>
> BTW, python 2.2 from Apple does not appear to have poll() - does 
> twisted work on  python 2.2 from Apple?

When I say poll, I mean it calls select() with a short timeout interval 
via NSTimer on a regular basis.

-bob

Re: [Pyobjc-dev] Threading

[Tony L. <ton...@lo...>]

At 6:59 PM -0500 1/20/03, Bob Ippolito wrote:
>On Monday, Jan 20, 2003, at 18:50 America/New_York, Tony Lownds wrote:
>>Any advice on writing a pyobjc program that uses threads?
>
>My best suggestion is simply don't :)

Heh. Its been a good way to force myself up the pyobjc learning curve.

>Check out Twisted ( http://www.twistedmatrix.com/ )..  In CVS HEAD 
>Twisted/doc/examples I have a demo on how you would (in a sort of 
>ghetto polling way) tie a Twisted application into a pyobjc 
>frontend.  It's an asynchronous multi-protocol communications 
>framework that doesn't suck (like medusa).  It never threads unless 
>it really needs to (i.e. RDBMS interaction, and certain things in 
>win32 and jython).

Thanks, I'll check that out.

I'm aiming for a thin integration over an existing project. The fewer 
changes to the server code, the better. It uses asyncore, porting to 
twisted would probably involve too many changes for my current goals.

BTW, python 2.2 from Apple does not appear to have poll() - does 
twisted work on  python 2.2 from Apple?

>If you have any questions post it to the twisted dev list, #twisted 
>in freenode.net, or you could ask me.
>
>I've developed a system for doing Twisted code using Python 2.2's 
>generators that allows you to write Twisted code in a very similar 
>way to how you would write blocking threaded code (with the caveat 
>that you should yield a sleep(0) or cooperate command if you're 
>doing some heavy computation)

Thanks!

-Tony

Re: [Pyobjc-dev] Threading

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

On Monday, Jan 20, 2003, at 18:50 America/New_York, Tony Lownds wrote:

> Hi,
>
> I'm trying to make a Cocoa front end for an HTTP based python 
> application (spambayes). My program spawns a thread to handle the HTTP 
> requests, but that thread blocks. I've also tried a thread that does 
> nothing count, and it blocks too. Any advice on writing a pyobjc 
> program that uses threads?
>
> PyObjC .8
> python 2.2 (from Apple)

My best suggestion is simply don't :)

Check out Twisted ( http://www.twistedmatrix.com/ )..  In CVS HEAD 
Twisted/doc/examples I have a demo on how you would (in a sort of 
ghetto polling way) tie a Twisted application into a pyobjc frontend.  
It's an asynchronous multi-protocol communications framework that 
doesn't suck (like medusa).  It never threads unless it really needs to 
(i.e. RDBMS interaction, and certain things in win32 and jython).

If you have any questions post it to the twisted dev list, #twisted in 
freenode.net, or you could ask me.

I've developed a system for doing Twisted code using Python 2.2's 
generators that allows you to write Twisted code in a very similar way 
to how you would write blocking threaded code (with the caveat that you 
should yield a sleep(0) or cooperate command if you're doing some heavy 
computation)

-bob