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.scha...@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:jes...@taxboel.dk] > *Gesendet:* Dienstag, 24. Juli 2012 14:55 > *An:* Markus Schaber > > *Cc:* ironpython-users@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.scha...@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....@python.org[mailto: > ironpython-users-bounces+m.schaber=3s-software....@python.org] *Im > Auftrag von *Jesper Taxbøl > *Gesendet:* Dienstag, 24. Juli 2012 00:18 > *An:* Kevin Hazzard > *Cc:* ironpython-users@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 <wkhazz...@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 <jes...@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 <r...@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 | kr...@wintellect.com <r...@wintellect.com>**** > > www.wintellect.com**** > > **** > > *From:* ironpython-users-bounces+rome=wintellect....@python.org [mailto: > ironpython-users-bounces+rome=wintellect....@python.org] *On Behalf Of *Jesper > Taxbøl > *Sent:* Monday, July 23, 2012 11:05 AM > *To:* Kevin Hazzard > *Cc:* ironpython-users@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 <wkhazz...@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 <jes...@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@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> > **** > > **** > > **** > > ** ** >
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
