[IronPython] Suspending, saving script execution?
Gutfreund, Yechezkal
ygutfreund at draper.com
Tue Jan 30 15:13:34 CET 2007
Hmm.. Shades of Smalltalk-72 (not 80, which compiled methods, but rather
-72 which parsed and executed method calls as messages on receipt). It
was rejected for performance reasons in Smalltalk-76, which went too far
towards the C# strictly bound, and a compromise was found in -80.
BTW, Ousterout made a strong case for this sort of paradigm in TCL and
distributed TCL.
I like the paradigm for a lot of things that I do, but I realize it's
limitation for other scenarios.
________________________________
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of M. David
Peterson
Sent: Monday, January 29, 2007 8:57 PM
To: Discussion of IronPython
Cc: Vista-Smalltallk at googlegroups.com
Subject: Re: [IronPython] Suspending, saving script execution?
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
<mailto: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
<mailto: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/20070130/56c8beb1/attachment.html>
More information about the Ironpython-users
mailing list