[Tutor] program hangs in while loop using wx.yield

[Alex Hall]

On 11/14/10, Alan Gauld <alan.gauld at btinternet.com> wrote:
> "Alex Hall" <mehgcap at gmail.com> wrote
>
>> The problem is that I want to go until there is a winner. You are
>> right about just letting the mainloop of the gui handle input (I
>> forgot the gui is already looping and waiting for input) but I would
>> like to make the user pause while the computer goes, this way the
>> user
>> cannot just keep hammering out moves as fast as possible
>
> Thats fine so you simple stop accepting input while the computer goes.
> I'm sure your computer can keep up with aeven the fastest typist/mouse
> clicker. If you really want to add a delay simply add a short pause in
> your event handler - 1 second say. Or even better set a semaphore
> which blocks any input and then a timer to reset it after a given
> delay.
>
> This is all fairly satandard GUI practice none of which requires
> complex
> loops. You need to start thinking about a world controlled by the GUI
> firing events( or messages if you like) telling you what is happening
> which you catch and process.
Is there a basic tutorial for this sort of thing? I think part of the
problem is that both players have a Grid object. The human's grid
includes a gui. For example, clicking a square will fire on that
square. The computer has a grid as well, but (of course) with no gui
element; its grid is simply an array holding its ships. All this to
say that when the human fires, something happens to the gui but there
is a lot of other updating going on behind the gui, in the human's
grid object. When the computer "fires", its grid is updated as well,
but not any gui, so message passing by the gui would not seem to
apply.
>
>> be given to the user properly. Therefore, I have gotten rid of the
>> loop I sent originally, but I still have a loop which switches
>> between
>> the two players
>
> Is it two players or is it a player and a computer.
A human and a computer for now. I hope to one day add peer-to-peer
support for two humans to play, but that was not working out at all so
for now I am just trying to give myself some, even if it is digital,
to play against.
> If its the former you need a semaphore to block input from one
> player until the other has gone. In chess terms the values might
> be black and white and the semaphore called player. You then
> either need two input handlers, one for black and one for white
> which call a common utility fuction after checking the semaphor
> or a single function that somehow can identify the player.
>
> If its the latter then the computer should be faster than a hiuman
> so there should be little problem...
Little problem for the computer, since its decision will be made in a
fraction of a second. However, I need to wait for as long as the human
takes to make a turn-ending move. Firing ends a turn, while moving the
mouse or arrows does not. The computer does not have this problem, but
I still need to know when the computer is done.
>
>> the other. If I fire (it is Battleship) and hit your ship,and I am
>> the
>> computer, then this loop will give you the information about where I
>> fired. You will check to see if it was a hit and, since it was, pass
>> back information about what was hit. You will also update the gui to
>> reflect the new status of the damaged ship.
>
> I'm confusing you and I, its safer to use explicit trerms when
> describing
> interactions. But the displaing of information and updating the GUI
> can
> all happen in a blink of an eye if its the computer playing.
You are right, that was confusing. What I am saying is that, each time
a player goes (human or ai) a string gets updated. The opponent can
then examine that string to see what happened, updating the gui (in
the case of the human) accordingly and recording the information for
consideration in future moves (in the case of the ai).
>
>> this, I do not want you firing as fast as possible, and I want you
>> to
>> take in the results before you are allowed to fire.
>
> Why do you care if the human "takes in the results" - if they want
> to trust in randomness surely thats their problem. You as a computer
> can match them blast for blast...
Part of it is that I hope to eventually add sound, and the other part
is that I have always found games that make a move instantly to be a
bit too far from what I am used to. If it is easy to build in a delay,
I would rather have it there.
>
>> while not player1.isWinner or not player2.isWinner:
>>  if player1.grid.turnOver:
>>   print("player2 is going")
>>   player1.grid.speak("player 2 is going.")
>>   player2.enemyMove=player1.grid.cmd #tell p2 what p1 just did
>>   player1.lock() #so p1 cannot interact with the gui
>>   player2.takeTurn() #decides what to do and updates its Grid object
>> accordingly
>>   player1.grid.speak(helpers.interpret(player2.grid.cmd)) #just
>> output what p2 did after takeTurn() is over
>>  elif player2.grid.turnOver:
>>   print("player1 is going")
>>   player1.enemyMove=player2.grid.cmd
>>   player1.unlock() #p1 can now interact with the gui
>>   player1.grid.speak("It is now your turn.")
>>   player1.takeTurn()
>>  #end if
>>  #wx.Yield()
>>  time.sleep(.1)
>> #end while
>
> Still looks way too complicated to me!
Me, too.
>
>> I am honestly not sure how all the control flows, but this loop is
>> gone so hopefully it will not be a problem.
>
> You need to think about the control flow vfery carefully - after all
> you the programmer are supposed to be in charge of your program!
> And if you ever have to debug it you will need to understand
> where the control is going next!
Again: is there a basic tutorial that would explain how control works
when dealing with a gui, especially one that is meant to last a long
time but occasionally block input?
>
> HTH,
>
> --
> Alan Gauld
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
>
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>


-- 
Have a great day,
Alex (msg sent from GMail website)
mehgcap at gmail.com; http://www.facebook.com/mehgcap