[Ironpython-users] Gradually executing a python script

Jesper Taxbøl jesper at taxboel.dk
Tue Jul 24 15:59:30 CEST 2012


That seems to be a good idea. I actually researched it a bit last night. It
still has some issues, but seems to be easier than finding an abstract
machine.

As I see it. Threads will still affect eachother depending on how much cpu
they consume and it will be non deterministic. But besides that it could
work.

:)))

Tax


Only problem I see here is that scripts will have different number of
"cycle"

2012/7/24 Markus Schaber <m.schaber at 3s-software.com>

>  Hi, Tax,****
>
> ** **
>
> If you run each of those scripts in its own thread, possibly encapsulated
> into its own app domain, then only the player script “hangs”, and not the
> whole application.****
>
> ** **
>
> You could also use rather strong methods like “Thread.Abort()” or
> “AppDomain.Unload()” to clean up player scripts which don’t play nicely.**
> **
>
> ** **
>
> Grüße,****
>
> Markus****
>
> ** **
>
> *Von:* Jesper Taxbøl [mailto:jesper at taxboel.dk]
> *Gesendet:* Dienstag, 24. Juli 2012 14:55
> *An:* Markus Schaber
>
> *Cc:* ironpython-users at python.org
> *Betreff:* Re: [Ironpython-users] Gradually executing a python script****
>
>  ** **
>
> Agreed that could work :), but would still hang if a kid writes an
> infinite loop without actions inside.****
>
> ** **
>
> I am really into making something robust for kids to play with.****
>
> ** **
>
> Tax
>
> ****
>
> 2012/7/24 Markus Schaber <m.schaber at 3s-software.com>****
>
> Hi, Jesper,****
>
>  ****
>
> Let me suggest some different design: Do not use variables, but offer an
> “Action” function / delegate which is provided by the hosting code, and
> called by the player scripts. It gets the possible actions
> (left_wheel_speed, right_wheel_speed and fire) as Parameters. Inside this
> Action, you synchronize to some internal “cycle” mechanism, e. G. 50 ticks
> per second. When a player script wants to perform more than one action per
> tick, the Action() function waits for the next tick to come before it
> proceeds.****
>
>  ****
>
> Also you need to properly synchronize the input variables, one idea is
> that the Action() function takes a snapshot of them after setting the
> output.****
>
>  ****
>
> Another idea is that you could use the “yield return” with yield
> parameters – the script yields the actions, and gets the next snapshot in
> return. Here, you still can synchronize internally.****
>
>  ****
>
> Grüße,****
>
> Markus****
>
>  ****
>
> *Von:* ironpython-users-bounces+m.schaber=3s-software.com at python.org[mailto:
> ironpython-users-bounces+m.schaber=3s-software.com at python.org] *Im
> Auftrag von *Jesper Taxbøl
> *Gesendet:* Dienstag, 24. Juli 2012 00:18
> *An:* Kevin Hazzard
> *Cc:* ironpython-users at python.org
> *Betreff:* Re: [Ironpython-users] Gradually executing a python script****
>
>  ****
>
> First of all, thank you for your time.  I am not that experienced when it
> comes to all the terms used in this area of software, so please be patient
> with me.   ****
>
>  ****
>
> To give you a more clear idea of what I am doing I have posted a video of
> the current progress here
> http://www.youtube.com/watch?v=HER6WSIwSBQ&feature=youtu.be . This is a
> simple gameengine, with a physics based robot. It has simple senes (A
> vector to the nearest bot and the length of a raycast in front of the
> robot) and three actions (left_wheel_speed, right_wheel_speed and
> fire). IronPython is embeeded inside the Unity3D game engine which runs on
> .NET 2.0. I am using the dll version of ironpython in the project. (I could
> not figure out how to integrate the source into my game project.) ****
>
>  ****
>
> The whole prototype was made at  48 hour game jam called "No More Sweden"
> in Malmö the past weekend. ****
>
>  ****
>
> I did not know that the python code is compiled in IronPython before it is
> executed, and therefore will catch syntax errors before execution. That
> will be very usefull. :)****
>
>  ****
>
> I will need to look into the settrace advice, but my gut feeling is that
> it is not the direction I want to be going in. It might be later during
> work on the GUI / programming interface. ****
>
>  ****
>
> I agree that I should have a simple singlethreaded, turn based solution,
> as that can be made deterministic and its far easier to implement. That is
> definitely the way I want to go. The threading was only used in the
> prototype because I could not execute my script gradually. I saw the
> execute command as the only way to have Ironpython run my script, and saw a
> thread as the only way out. (at 3 am in the morning) ****
>
>  ****
>
> The reason I keep mentioning gradually execution requires some
> backstory: The reference project I have been inspired by is an old game
> called GunTactyx (
> http://www.youtube.com/watch?v=vT8PYETav7A&feature=relmfu), where you
> program robots to hunt down other robots. It uses an old version of the
> PAWN Language/abstract machine (http://www.compuphase.com/pawn/pawn.htm).
> As far as I understand each robot there has an isolated abstract machine
> with limited memory and it is ticked gradually, like you control the clock
> on its CPU. If a robot crashes, has an infinite loop or a memory leak it
> does not affect the cpu in the other robots. The reason I am not using PAWN
> is that it is C++ based and my target platform runs .NET 2.0. Besides that
> I prefer Python over the PAWN language.****
>
>  ****
>
> Kevin: When you say statemachine, I imagined Ironpython had something of
> that sort inside its belly? That might be where I am wrong. Is a
> statemachine and an abstract machine the same thing in this context?****
>
>  ****
>
> With regard to the dostuff() functions, I dont mind the robots firing many
> instructions at a time. I just need to be able to let the robots run the
> same number of "ticks" between each game cycle. I imagine assigning a tick
> cost to the dostuff() functions, as they probably will do stuff inside the
> game world. ****
>
>  ****
>
> I have been looking at other solutions to allow me to make a programming
> game. During the 48 hours I briefly used the AluminumLua project which I
> was able to tick, but it lacked debelopment on the language side. (for
> loops was not implemented) I would prefer to stick to Pythoon as I love the
> language and I feel it contains the elements needed to write an
> interristing AI. ****
>
>  ****
>
> I need to read up on the IronPython  system and have therefore just
> ordered "Ironpython in action" book, I hope it will give me a better
> understanding. Other recommendations are welcome.****
>
>  ****
>
> Kind regards and thank you again for your feedback.****
>
>  ****
>
> Tax****
>
>  ****
>
>   ****
>
>  ****
>
> 2012/7/23 Kevin Hazzard <wkhazzard at gmail.com>****
>
> What you're describing is a state machine. There are many ways to build
> such a thing and honestly, I've never thought of single-stepping through
> code as a way to do that. It's actually quite an intriguing idea, if not
> inefficient. But efficiency isn't always measured with elegance (and vice
> versa). Keith's settrace idea is good, too. You should check that out.****
>
>  ****
>
> What it really comes down to is this: do you want the controller to also
> define the code or merely to drive it? For the example you posted, do you
> want the while loops implemented in Python to execute your dostuff() and
> dootherstuff() methods? Or do you want the controller that authorizes a
> "step" to do that? In that context, you could write the controller in
> Python, too, but the design of your code would look very different than
> what you proposed.****
>
>  ****
>
> Kevin****
>
> On Mon, Jul 23, 2012 at 1:48 PM, Jesper Taxbøl <jesper at taxboel.dk> wrote:*
> ***
>
> The reason I want to do it gradually is that I cant be sure that the
> script ever terminates or has syntax errors. Would that not be a problem in
> a turn based setup? ****
>
>  ****
>
> 2012/7/23 Keith Rome <rome at wintellect.com>****
>
> You may want to look into leveraging the sys.settrace() feature of Python
> for controlling line-by-line execution. This API allows you to install a
> profiling function that gets invoked for every frame of script code that is
> executed. In your profiling function, you could compute the amount of
> memory being used by variables within the ScriptScope, and halt execution
> if you need to. Just be careful about what you do in your profiling
> function, as it will be called extremely often by the runtime.****
>
>  ****
>
> http://docs.python.org/library/sys.html#sys.settrace****
>
>  ****
>
>  ****
>
> The reason you are seeing variant results is probably due to how you have
> implemented multithreading. The IronPython runtime is mostly thread-safe
> (as long as you don’t use libraries that make use of mutable objects, and
> as long as you import all libraries used at least once prior to forking
> threads). But your code must also be thread-safe as well. From your
> descriptions of your game engine, it sounds like your game engine is not
> designed to be thread-safe so I would strongly recommend avoiding
> multithreading as a means of providing resource sharing. It is very
> difficult to write 100% thread-safe code, and nothing will stop people from
> writing unsafe scripts in your game.****
>
>  ****
>
> Instead, I would suggest implementing your game engine as a turn-based
> system. For each turn, the script for each character is executed
> completely. This will allow you to cycle through all characters one turn at
> a time, equally, and will also eliminate the problem of having variant
> outcomes since the program will become deterministic.****
>
>  ****
>
>  ****
>
>  ****
>
> *Keith Rome*****
>
> *Senior Consultant and Architect*****
>
> MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS****
>
> Wintellect | 770.617.4016 | krome at wintellect.com <rome at wintellect.com>****
>
> www.wintellect.com****
>
>  ****
>
> *From:* ironpython-users-bounces+rome=wintellect.com at python.org [mailto:
> ironpython-users-bounces+rome=wintellect.com at python.org] *On Behalf Of *Jesper
> Taxbøl
> *Sent:* Monday, July 23, 2012 11:05 AM
> *To:* Kevin Hazzard
> *Cc:* ironpython-users at python.org
> *Subject:* Re: [Ironpython-users] Gradually executing a python script****
>
>  ****
>
> Would that allow me to step gradually through a loop?****
>
>  ****
>
> like:****
>
>  ****
>
> x = 0****
>
> while x < 10:****
>
>    dostuff()****
>
>    x=x+1****
>
> while x > 0:****
>
>    dootherstuff()****
>
>    x=x-1****
>
>  ****
>
>  ****
>
>  ****
>
> 2012/7/23 Kevin Hazzard <wkhazzard at gmail.com>****
>
> Why don't you use a scripting host and inject commands into a ScriptEngine
> reusing a ScriptScope as you need to execute them?****
>
>  ****
>
> Kevin****
>
> On Mon, Jul 23, 2012 at 5:31 AM, Jesper Taxbøl <jesper at taxboel.dk> wrote:*
> ***
>
>  Hi,****
>
>  ****
>
> I am not that familiar with Ironpython yet, but I have a question that I
> hope you can help me answer.****
>
>  ****
>
> I am working on a programming-game where I will allow users to do some
> simple python scripting against a simple API that I will control a game
> character. Instructions like move and shoot etc, alongside some simple
> sense functions that return info on the game world. ****
>
>  ****
>
> My current prototype creates an ironpython engine for each game character
> and executes the script in a thread by itself, which sort of works. But I
> have the problem that the outcome of executing the game gives different
> results every time. Therefore I would like to ask the question:****
>
>  ****
>
> Is it possible to execute a script inside the Ironpython engine gradually?
> ****
>
>  ****
>
> I imagine that I could update a list of engines with a tick(int cycles)
> and get a fair sharing of resources between engines and ensure the same
> result every time.****
>
>  ****
>
> Kind regards ****
>
>  ****
>
> Tax****
>
>  ****
>
>  ****
>
> P.S:****
>
> As this is a programming game I would also like to be able to limit the
> available memory each script is using. Is there a way to limit this, so a
> script like this would be killed.****
>
>  ****
>
> x = 0****
>
> v = {}****
>
> while True:****
>
>    v[x]=x****
>
>    x= x + 1****
>
>  ****
>
>  ****
>
>  ****
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users****
>
>
>
>
> --
> *W. Kevin Hazzard*****
>
> Consultant, Author, Teacher, Microsoft MVP****
>
> (804) 928-3444****
>
> book <http://manning.com/hazzard> | mvp<https://mvp.support.microsoft.com/profile/Kevin.Hazzard>|
> twitter <http://twitter.com/#%21/KevinHazzard> | facebook<http://www.facebook.com/wkhazzard>|
> linkedin <http://www.linkedin.com/in/kevinhazzard> | captech<http://captechconsulting.com>
> ****
>
>  ****
>
>  ****
>
>  ****
>
>
>
>
> --
> *W. Kevin Hazzard*****
>
> Consultant, Author, Teacher, Microsoft MVP****
>
> (804) 928-3444****
>
> book <http://manning.com/hazzard> | mvp<https://mvp.support.microsoft.com/profile/Kevin.Hazzard>|
> twitter <http://twitter.com/#!/KevinHazzard> | facebook<http://www.facebook.com/wkhazzard>|
> linkedin <http://www.linkedin.com/in/kevinhazzard> | captech<http://captechconsulting.com>
> ****
>
>  ****
>
>  ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20120724/1b06e464/attachment.html>


More information about the Ironpython-users mailing list