Bob, Sounds terrific. what's your project url again. take a close look at the stackless site. stackless.com it's a 1:1 enhancement that replaces the python core and provides 100% compatiability while providing co-routines. The developers are primarily high-volume MUDD game designers so this is industrial stuff, not a fly-by-night. My understanding is that most of the changes are internal. from a laymen's perspective I understand they've replaced the single C stack with a dynamic set of stacks, such that each co-routines can be suspended at any point and "pickled" to disk. The goal is that a thread (representing a gamers state) can be save/restarted at any time while the entire state machine (game world) continues to run.
They also have an intersting list of other applications where stackless is being applied. Since you're using Python, you should be able to swap to stackless without any changes and then use the co-routines where required. I've studied the authors edition for the overall structure - scanner, parser, dispatcher but couldn't understand how to efficiently manage the yield process without resorting to a inefficient round robin scheme. Do you talk much about the app architecture with your team? Thanks doug Doug Little [EMAIL PROTECTED] Elgin, IL ----- Original Message ---- From: Bob Gailer <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, January 22, 2008 8:41:07 AM Subject: Re: Source woes Doug Little wrote: > Good Morning Everybody. > I read your post further and found your comments regarding Python and stacks and co-routines. IMHO my architecture works just fine in a stack environment. The only concession to a co-routine concept is my attempt to provide an environment in which one could port an existing REXX stage (using threads). The goal is to train Py-plumbers to recode these in Python using the new stage model which does not depend on stacks or coroutines.
