For my game, I'd like the AI to run in the background for X number of seconds. I don't want it to lock up the UI while it's thinking. In other languages, I've done this by firing off the AI as a thread, then creating another clock that sent a "stop" message to the AI after X seconds.
I see implementing the clock as a Delay class.. but need a bit help figuring out the details of forking off the original AI process.
Can someone point me to docs or examples?
On Nov 27, 2004, at 6:33 PM, Ryan Zerby wrote:
For my game, I'd like the AI to run in the background for X number of seconds. I don't want it to lock up the UI while it's thinking. In other languages, I've done this by firing off the AI as a thread, then creating another clock that sent a "stop" message to the AI after X seconds.
I see implementing the clock as a Delay class.. but need a bit help figuring out the details of forking off the original AI process.
Can someone point me to docs or examples?
In Smalltalk, threads are called processes. See the class Process for the messages you can send to one. To fork off a Process, just send #fork to a block containing the code you want to run in the process. As a simple example, assume aiProcess is an instance variable of some object:
startAIProcess aiProcess := [AI new run] fork
stopAIProcess aiProcess terminate
Read up on fork and forkAt:, which are messages that Block objects respond too. Also read up in the system class on ProcessorScheduler and the scheduler priorities.
Here's a trivial piece of code I wrote to play around with forked processes and semaphores:
| ourSemaphore |
ourSemaphore := Semaphore new. [ourSemaphore wait. Transcript show:'I waited'; cr. ourSemaphore signal.]fork.
[Transcript show:'I signaled'; cr. ourSemaphore signal. ourSemaphore wait. Transcript show:'Then I wrote again'; cr]fork.
You'll probably want to put your AI or a call to your AI class in a block, then forkAt:Processor userBackgroundPriority.
For example ... [doSomeAiThinking] forkAt: (Processor userBackgroundPriority). ...
This will fork off your AI work into a background process. You could use some Semaphores to start and stop it as need be.
Hope that helps, Brian Tabone
On Sat, 27 Nov 2004 15:33:00 -0800, Ryan Zerby tahognome@gmail.com wrote:
For my game, I'd like the AI to run in the background for X number of seconds. I don't want it to lock up the UI while it's thinking. In other languages, I've done this by firing off the AI as a thread, then creating another clock that sent a "stop" message to the AI after X seconds.
I see implementing the clock as a Delay class.. but need a bit help figuring out the details of forking off the original AI process.
Can someone point me to docs or examples?
om
this is a serious post with a number of ideas and proposals for the future of Squeak though the style reflects the fact that it was written at 1:30 AM..
I've been reviewing my OS project and it looks like I will be unable to persue it as a primary venture due to financial reasons. (nobody's going to fund an OS in PenguinWorld(TM)).
That being the case I am presented with several very grim problems.
I've been trying to figure out how to restore my DOS Win311 machine one more time and, objectively studying the facts I realize that it would be silly... For one thing I'm currently downloading a single file that's almost as big as DOS' partition limit! (I'm really out of my mind cuz this is over dialup! =P -- I should have my file by christmas.)
Anyway, besides my extremely dated game collection, DOS is great for one thing: Writing. You might not beleive this but I've written around two megabytes worth of stories and I still do much of my school work on a marginally functional 486. =(
What little DOS does, it does brilliantly.
The first thing Squeak needs in order to replace DOS is a good content managment system. For example, the Squeak welcome message is presented in a funky-colored workspace. The first problem is that when you punch the (X), it disappears and is never seen again.
While Squeak's method for handling code is superlative, it seems to lack -- in a perfect sense --, any method for managing _content_.
Since Unix has a heirarchical filesystem (and because Unix does everything at least partially wrong) Squeak should have something better. I havn't looked much into databases in quite a while so I don't have much to actually contribute to such a project. =(
In any case, the next thing DOS has, well IBM PC-DOS 7.0, is E. It's the best text editor I've ever run across. I felt like an expert on the very first day I used it. Ten years later, it continues to amaze me with its attention to the user. At first glance, it proclaims loudly that it cares about it's user. It blatantly defies the "WYSIWYG" paradigm and, instead, chooses a color scheme that actually makes ergonomic sense. (light gray on dark blue.) -- imagine that, someone designing a piece of software with ergonomics in mind! (Squeak is _ALMOST_ like that, that's why I'm sending this message here instead of somewhere else.)
When you start to use it, and really get into what it can do, it will continue to blow your mind for years. -- C macros (type "If" and it writes () {
} else {
}; /*end if */ )
Want to edit multiple files at once? It lets you do that, It also lets you split the screen horizontally or vertically, or into quadrants... (you'd better cover your keyboard cuz I'm only getting started. -- this will make you drool.)
Want to print something? Press F5. -- that's it.
Want to save and exit? Press F4. Want the manual? Press F1. -- It does all this _INSTANTLY_ on twelve year old hardware. =P
Want to draw ascii art? use the "draw" command (Yes, it even has a command line, you could use it as an IDE because you can invoke whatever compiler you are using without leaving the editor! -- CommanShell needs to be rewritten. -- good start though...) I might be up for that...
I could go on but I have so much else to cover. My point is that Squeak needs a full-feature text editor.
On to deeper issues:
The Squeak VM is a good enough platform for the type of experamentation and digital creativity it has supported until now... Unfortunately, if it is going to step into DOS' shoes it needs to be more powerful in a number of areas. The favorite thing I like to make alot of annoying posts about is SMP support. But I think the true path to making the VM better is a re-consideration of its relationship to the system as a whole.
Today Squeak mostly revolves around the VM. The VM sets up basic functions and then loads this thing called the "Squeak Image"... It may just be because it's late at night, but it seems to me that a better way to consider the VM/or Squeak's host dependant software, as a driver for the CPU, to think of the interpreter as something Squeak uses to acess the CPU rather than thinking of the interpreter as something that runs squeak. It may seem like pure semantics but what I'm trying to get at is that The VM should be more like ld.so (the secret program which interprets most Linux software.)
A visable result of this change in thinking will be the discarding of many of the "special objects" such as "display" that tend to detract from the general purpose nature of the interpreter. The Interpreter would need to be enhanced with some mechanism to access OS services or plugin code. Display would just be a regular object, accessable to be extended by the user on a "live" system.
Finally, we get to what prompted me to write this posting.
My main focus from now on will have to be the development of AI. (varrious reasons). I would be very much interested in promoting and developing Squeak as an AI platform and I look forward to colaborating with Ryan and others in the future. =)
This will fork off your AI work into a background process. You could use some Semaphores to start and stop it as need be.
On Sat, 27 Nov 2004 15:33:00 -0800, Ryan Zerby tahognome@gmail.com wrote:
For my game, I'd like the AI to run in the background for X number of seconds. I don't want it to lock up the UI while it's thinking. In other languages, I've done this by firing off the AI as a thread, then creating another clock that sent a "stop" message to the AI after X seconds.
I see implementing the clock as a Delay class.. but need a bit help figuring out the details of forking off the original AI process.
Can someone point me to docs or examples?
On Saturday 27 November 2004 3:33 pm, Ryan Zerby wrote:
For my game, I'd like the AI to run in the background for X number of seconds. I don't want it to lock up the UI while it's thinking. In other languages, I've done this by firing off the AI as a thread, then creating another clock that sent a "stop" message to the AI after X seconds.
I see implementing the clock as a Delay class.. but need a bit help figuring out the details of forking off the original AI process.
Can someone point me to docs or examples?
Threads (Process in Squeak) are created using the
p := [ stuff ] forkAt: priority
idiom.
p := [ stuff ] fork
is a special case that uses the current process priority.
Priorities are defined in ProcessorScheduler; there is a global one of these schedulers called Processor .
So if you want to do stuff in the background you can just go:
myBackgroundProcess := [ stuff ] forkAt: Processor userBackgroundPriority.
Later you can suspend and/or terminate the process forcibly (a bit rude):
myBackgroundProcess suspend. "later..." myBackgroundProcess resume.
myBackgroundProcess terminate. "done with the process!"
or you can set up one or more SharedQueue instances (better) to communicate with it.
queue := SharedQueue new. myBackgroundProcess := [ | done message | done := false. [ done ] whileFalse: [ message := queue next. "... process message ..." "message processing could set done" ]] forkAt: Processor userBackgroundPriority.
You can also signal an exception in another Process; this might be useful for your case (see below).
myBackgroundProcess := [ | done message | done := false. [ done ] whileFalse: [ [ message := queue next. "... process message ..." "message processing could set done" ] on: TimedOutdo: [ :ex | done := true. "stuff to do when my life is over" ]] forkAt: Processor userBackgroundPriority.
"later..." myBackgroundProcess signal: TimedOut
We also have Monitor and Semaphore objects to handle shared access to resources. Monitors are probably better (higher level) things to use.
A read on an empty queue will block a process (that is, suspend it until something is available to read). You can do a wait-with-timeout on a Semaphore or Monitor.
You can also (now) do
[ stuff ] valueWithin: 2000 "msec" onTimeout: [ more stuff ]
which signals a TimedOut exception in the action block, so you can also use the pattern:
[ [ stuff ] on: TimedOut do: [ :ex | ] ] valueWIthin: 2000 onTimeout: [ ].
squeak-dev@lists.squeakfoundation.org