Quote -

Certainly, but that does not explain why slashes are OK in Windows, but not in Macintosh.

Native filespecs still work on Windows. Why not on Mac?

Because S+M programmed something wrong in this method? The basic Python libs are very well tested in the meantime and work on Mac (yes, you said allready it must be an error in Poser-Python).

Quote -

I did have some success setting it up as another thread. However, the server-side could not do any Poser scene calls then, because they are not thread safe. When I tried it, Poser crashed.

Threading with Poser-Python < version 7?

Quote -
I've also tried putting up a Tk dialog and using Tk's background callback, but that seems really ugly. I want the server to run forever, not just while some bogus dialog is up.

Even in version 7, threading is broken. Look into the threading module. It's not original (not in Windows, don't know for Macs). The whole implemented Python isn't original. Some libs simply won't work, other may or may not. Mostly those libs where threads are required.

On the other side, any usermade python script is executed in the same "frame". Means also, all variables are left for the next script. The interpreter isn't reset. That's bad for standard things, but fine if you want to do some tricks :)

The good news: Threading isn't required to serve a few calls from the outside world. Use a three-thier model (GUI to Interact with user - server in the middle as consumer - Poser as factory). So Poser needs only a small communication part and a small resolver. The rest can be done inside the server - in any programming language (even on another machine if RPC is implemented on top of IPC).

For the script running in Poser, don't use the higher level Python libs for IPC and keep it small and simple. This script has only 2 things to do: waiting for questions/commands from the server and respond with a result or errormessage.

The trick with the eventloop is: Think the other way around.
The normal way: Poser calls your script (Poser does nothing until your script returns), then your script waits for Poser to get some processing-time again (via TK or an poserevent).

My way: As soon as my script is called the first time, it enters an endless "blocking-loop". Inside this loop the incomming/outgoing ports are scanned, than Poser is called.

while True : if shouldstop: break # incomming data has higher priority if checkIPCinWaiting() : processIncommingData() elif checkIPCoutWaiting() : processOutgoingData() poser.ProcessSomeEvents(10) time.wait(0.001)

This simple loop makes sure Poser runs as usual but the script doesn't loose control. There may be delays, especially if Poser renders. But this is something you can't avoid anyway. The middle part (the server) should handle such issues. Anytime the script has to wait for in- or output (while receiving or sending), Poser should be called via ProcessSomeEvents() to let Poser run as smoothly as possibe.

checkIPCinWaiting and checkIPCoutWaiting must use low-level network calls to avoid the script is blocked until a network-timeout occures (Poser 5 is the biggest problem here).

By the way: time.wait() is used to give other apps more time to run (even the GUI and the serverpart).

It's possible to use UDP insteed of TCP for communication between server and Poser. The needed overhead for the required protocol is small, because the Poser script acts synchron-seriell (first-in, first-out)

---