[IronPython] Suspending, saving script execution?

[M. David Peterson]

> 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 <erzengel-von-licht at cox.net> 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: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] 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 <erzengel-von-licht at cox.net> 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
> curt at hagenlocher.org
>
> --
> 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
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070129/52b266a7/attachment.html>