so any pointers would be appreciated (at the moment, I'm just following execution in the debugger).
While not directly related to IronPython (or MSFT for that matter), this seems like a perfect use-case for Vista Smalltalk (non-MS implementation of Smalltalk and Lisp; see: VST Wiki). I've Cc'd the group mailing list [see: Group List; VST Group: Please see the inline message for proper context.] While not a perfect 1-to-1 comparison, [see: Example:1] showcases how one would go about editing the generated Lisp-code from a circle drawn in the visual drawing tool that is part of the VST XBAP application [see: VSB; requires IE7/.NET 3.0 libraries, though WPF/e will be providing a cross-browser/platform capability in the coming months, from what I understand.] It would seem to me that the combination of the message-based approach provided by Smalltalk, and the list-processing approach of Lisp, by breaking any given script into smaller pieces, and building agents to handle the sending/receiving/processing of each message would provide exactly what you would need to accomplish the task of suspending and resuming action as necessary. While I can't say for sure, it would seem to me that adding IronPython to the mix *should* be pretty straight forward: Adding both assemblies to your project, and using a dictionary for ease of storage/access/editing of various Smalltalk and/or Lisp scripts, you could use a pretty straight forward declarative script syntax that would hide any unnecessary complexity from the user. How practical this would be in terms of performance is a definite unknown at this state, but it at least seems to provide a reasonable expectation for performance if care was taken to build in a proper caching mechanism. VST Wiki: http://vistascript.net/ Group List: http://groups.google.ca/group/Vista-Smalltallk Example:1: http://vistasmalltalk.wordpress.com/2007/01/29/modifying-generated-lisp/ VSB: http://vistascript.net/vistascript/vsb/Vsb.xbap Peter Fisk's (VST creator) blog: http://vistasmalltalk.wordpress.com/ On 1/29/07, Erzengel des Lichtes <[EMAIL PROTECTED]> wrote:
Thanks for the responses, I've considered using yield, which is what drew me to Python in the first place, but I operate under the theory that the developer should make it as easy as possible for the user, not themselves. Which means I need to do the yielding automatically on the C# side. What I really want is to use the reflectance available in .net, but I don't need the script itself to be turned into MSIL. The script should be able to be suspended anywhere in the script so that I can save/load (and prevent hanging by interrupting a long script, then let it continue after other scripts have had a chance to run). On the other hand, all .net methods will be atomic. I don't really care much about the performance of the scripts as they're supposed to be very high level; everything performance critical is written in C++, and everything else (except AI and scene choreography) is in C# (the glue is in C++/CLI). Only AI, scene choreography, and user scripts are in python. More often than not, a python script will probably be in its suspended state, waiting for "move" or whatever to return. The script's performance isn't much of a concern when the script isn't actually doing anything most of the time. Up until now I've just been looking into completely replacing PythonEngine, just using Compiler.Parser, but I'll look into Compiler.Generation.CodeGen , as well. I just haven't become very familiar with the internals of IronPython so any pointers would be appreciated (at the moment, I'm just following execution in the debugger). Erzengel des Lichtes Hikari no Daitenshi Archangel of Light -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Monday, January 29, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Presumably someone could also modify IronPython's CodeGen class to turn all methods into generators that yield at regular intervals. This would take a significant performance hit as all the locals would be hoisted into a FunctionEnvironmentDictionary and would still need the scheduler / virtual stack maintenance but be an interesting experiment. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hogg, Jonathan Sent: Monday, January 29, 2007 1:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Stackless Python is definitely the way to go, but if you needed to do this in IronPython/.NET, you can get a poor man's form of micro-threading with generators. Taking your example, you could re-write it like so: def main(self): yield move(5) yield turn(90) if self.direction == Direction.East: yield turn(180) yield move(2) where 'move' and 'turn' are type constructors - or factory functions or whatever - that return an object representing the action to be taken. Now you instantiate the generator to create your micro-thread, and call '.next()' on it to execute it up to the next yield. t1 = mytank.main() action = t1.next() The difference between this and full threading is that it's cooperative and that you have to write your own micro-thread scheduler. Presumably you'll have some kind of game-state/event engine that will keep track of what each of the actors is currently doing and when they become eligible for execution again (it's finished moving/turning), you would poke them to see what they want to do next. Main problem is that if a piece of user-generated logic is badly behaved (doesn't yield), then your game would hang. Jonathan ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: 28 January 2007 17:37 To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? On 1/28/07, Erzengel des Lichtes <[EMAIL PROTECTED]> wrote: Now, the script is going to need to be suspended while it's moving 5 meters (it's not going to teleport) forward, then again while it's turning 90 degrees to the right, possibly again when it turns around, and finally once again while moving forward 2 meters. I can't block the script without suspending the thread/fiber, right? But with a large number of scriptable units, the system will not be able to cope with a thread/fiber per script. This sounds like the sort of thing that Stackless Python[1] was invented for. This is a variation of CPython that -- by removing the dependency of Python code execution on the processor's stack -- allows execution of multiple objects without creating multiple threads. The game "EVE Online" uses Stackless Python for this purpose. I doubt you could accomplish something similar in IronPython simply because of how the CLR works. But the low-level hooks in CLR 2.0 that were created for SQL Server may allow something in that direction. 1: http://www.stackless.com 2: http://www.eve-online.com -- Curt Hagenlocher [EMAIL PROTECTED] -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Alternative Investment Management Limited or its affiliates, or any funds or accounts managed or advised by any of the aforementioned entities (together referred to as "KBC AIM"). This message does not create any obligation, contractual or otherwise, on the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC AIM would enter into a transaction, or prices at which similar transactions may be carried on KBC AIM's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
