1. Contest 2 Announcement:
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 27, 2004
-
Last edited Nov 28, 2004
Preliminary framework complete!
It doesn't run tournaments, and it won't detect whether a match is
over, but it runs, and it doesn't crash!
Get it while it's hot!
http://users.secsme.org.au/~prbarnes/projects/contest/rules.html
Any bug reports are, of course, welcome.
--
MrTrick
2. Re: Contest 2 Announcement:
Uh, perhaps I should elaborate...
The preliminary framework contains a program called engine.exw, that
can be used to run matches.
This means you can actually test your programs with it... so get downloading.
On Sun, 28 Nov 2004 06:32:35 +1100, Patrick Barnes <mrtrick at gmail.com> wrote:
> Preliminary framework complete!
>
> It doesn't run tournaments, and it won't detect whether a match is
> over, but it runs, and it doesn't crash!
> Get it while it's hot!
>
> http://users.secsme.org.au/~prbarnes/projects/contest/rules.html
>
> Any bug reports are, of course, welcome.
> --
> MrTrick
>
>
--
MrTrick
3. Re: Contest 2 Announcement:
Oops, forgot something....
In win32lib, you need to change the lines around 34838 in shellExecuteEx to:
if validId(mainWindow) then
hWnd = getHandle(mainWindow)
else
hWnd = 0
end if
Is there *any* reason why it doesn't like running without a window?
Can I suggest it be changed in the official win32lib code?
On Sun, 28 Nov 2004 12:12:14 +1100, Patrick Barnes <mrtrick at gmail.com> wrote:
>
>
> Uh, perhaps I should elaborate...
>
> The preliminary framework contains a program called engine.exw, that
> can be used to run matches.
> This means you can actually test your programs with it... so get downloading.
>
> On Sun, 28 Nov 2004 06:32:35 +1100, Patrick Barnes <mrtrick at gmail.com>
> wrote:
> > Preliminary framework complete!
> >
> > It doesn't run tournaments, and it won't detect whether a match is
> > over, but it runs, and it doesn't crash!
> > Get it while it's hot!
> >
> > http://users.secsme.org.au/~prbarnes/projects/contest/rules.html
> >
> > Any bug reports are, of course, welcome.
> > --
> > MrTrick
> >
> >
> --
> MrTrick
>
>
--
MrTrick
4. Re: Contest 2 Announcement:
Patrick Barnes wrote:
>
> if validId(mainWindow) then
> hWnd = getHandle(mainWindow)
> else
> hWnd = 0
> end if
That helped. :)\
> > The preliminary framework contains a program called engine.exw, that
> > can be used to run matches.
> > This means you can actually test your programs with it... so get
> > downloading.
Can you make a way to stop a game without leaving those extra processes
running? Or is there already a way? ESCAPE key, perhaps? :)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
5. Re: Contest 2 Announcement:
NEVERMIND! Found the docs. :)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
6. Re: Contest 2 Announcement:
On Sat, 27 Nov 2004 19:38:54 -0800, cklester <guest at rapideuphoria.com> wrote:
>
> posted by: cklester <cklester at yahoo.com>
>
> Patrick Barnes wrote:
> >
> > if validId(mainWindow) then
> > hWnd = getHandle(mainWindow)
> > else
> > hWnd = 0
> > end if
>
> That helped. :)\
>
> > > The preliminary framework contains a program called engine.exw, that
> > > can be used to run matches.
> > > This means you can actually test your programs with it... so get
> > > downloading.
>
> Can you make a way to stop a game without leaving those extra processes
> running? Or is there already a way? ESCAPE key, perhaps? :)
It should work... 'q'...
It's possible that the bot processes remain after the Arena quits, if
they get stuck inside the get_orders procedure and therefore don't
head the MSG_STOP message...
--
MrTrick
7. Re: Contest 2 Announcement:
Why not bind or translate/compile the engine so we don't have to worry about
having the correct win32lib (custom-edited), etc? You can still provide the main
source so we can look for bugs, but it will reduce engine.exw to a single .exe...
Patrick Barnes wrote:
>
> Oops, forgot something....
> In win32lib, you need to change the lines around 34838 in shellExecuteEx to:
>
> if validId(mainWindow) then
> hWnd = getHandle(mainWindow)
> else
> hWnd = 0
> end if
>
> Is there *any* reason why it doesn't like running without a window?
> Can I suggest it be changed in the official win32lib code?
>
>
> On Sun, 28 Nov 2004 12:12:14 +1100, Patrick Barnes <mrtrick at gmail.com>
> wrote:
> >
> >
> > Uh, perhaps I should elaborate...
> >
> > The preliminary framework contains a program called engine.exw, that
> > can be used to run matches.
> > This means you can actually test your programs with it... so get
> > downloading.
> >
> > On Sun, 28 Nov 2004 06:32:35 +1100, Patrick Barnes <mrtrick at gmail.com>
> > wrote:
> > > Preliminary framework complete!
> > >
> > > It doesn't run tournaments, and it won't detect whether a match is
> > > over, but it runs, and it doesn't crash!
> > > Get it while it's hot!
> > >
> > > <a
> > > href="http://users.secsme.org.au/~prbarnes/projects/contest/rules.html">http://users.secsme.org.au/~prbarnes/projects/contest/rules.html</a>
> > >
> > > Any bug reports are, of course, welcome.
> > > --
> > > MrTrick
> > >
> > >
> > --
> > MrTrick
> >
> >
> --
> MrTrick
>
>
8. Re: Contest 2 Announcement:
Patrick Barnes wrote:
>
> On Sat, 27 Nov 2004 19:38:54 -0800, cklester <guest at rapideuphoria.com>
> wrote:
> >
> > posted by: cklester <cklester at yahoo.com>
> >
> > Patrick Barnes wrote:
> > >
> > > if validId(mainWindow) then
> > > hWnd = getHandle(mainWindow)
> > > else
> > > hWnd = 0
> > > end if
> >
> > That helped. :)\
> >
> > > > The preliminary framework contains a program called engine.exw, that
> > > > can be used to run matches.
> > > > This means you can actually test your programs with it... so get
> > > > downloading.
> >
> > Can you make a way to stop a game without leaving those extra processes
> > running? Or is there already a way? ESCAPE key, perhaps? :)
>
> It should work... 'q'...
> It's possible that the bot processes remain after the Arena quits, if
> they get stuck inside the get_orders procedure and therefore don't
> head the MSG_STOP message...
>
> --
Here is an alternative way to execute the bots:
--------------------------------
-- child_process.e
--------------------------------
include w32engin.ew
without warning
object void
global function child_process(sequence cmdline)
atom piProcInfo, siStartInfo, addr, hChildProcess
integer bFuncRetn
addr = allocate_string(cmdline) -- command to run child program ("exw
program.exw")
-- Set up members of the PROCESS_INFORMATION structure.
piProcInfo = struc("PROCESS_INFORMATION")
-- Set up members of the STARTUPINFO structure.
siStartInfo = struc("STARTUPINFO")
put(siStartInfo,"cb",sizeof("STARTUPINFO"))
-- Create the child process.
bFuncRetn = CreateProcessA({
0, -- app name (we use command line instead)
addr, -- command-line
0, -- process security attributes
0, -- primary thread security attributes
0, -- handles are not inherited
0, -- creation flags
0, -- use parent's environment
0, -- use parent's current directory
siStartInfo, -- STARTUPINFO pointer
piProcInfo}) -- receives PROCESS_INFORMATION
free(addr)
if bFuncRetn = 0 then
free_mem(siStartInfo)
free_mem(piProcInfo)
return 0 -- error
else
hChildProcess = grab(piProcInfo,"hProcess")
void = CloseHandle(grab(piProcInfo,"hThread"))
free_mem(siStartInfo)
free_mem(piProcInfo)
return hChildProcess -- return handle to process
end if
end function
-- kill the child process
global procedure child_kill(atom hChildProcess)
if hChildProcess then
void = TerminateProcess({hChildProcess,0})
void = CloseHandle(hChildProcess)
end if
end procedure
-- just closes the handle to the process
-- doesn't kill or affect the child process at all
global procedure child_close(atom hChildProcess)
if hChildProcess then
void = CloseHandle(hChildProcess)
end if
end procedure
-- you can use this if you don't want to keep
-- track of the child and therefore don't
-- need the handle
global procedure child_exec(sequence cmdline)
child_close(child_process(cmdline))
end procedure
----------------------------------------------
It uses the win32engin.ew, so you'd have to resolve conflicts with win32lib
possibly. To start up a process, just use:
h = child_process("exw program.exw")
and it gives you a handle h (or 0 if it doesn't work). Now if the child program
doesn't shut down like it is supposed to when you send it a message, you can
explicitly kill it with child_kill(h)...
9. Re: Contest 2 Announcement:
Rules suggestion:
You must submit your orders within 2*n seconds of the "turn" beginning, correct?
I see a couple of potential problems with this:
A) Your machine is your machine, running at its own speed. The rest of have to
guess if our moves will take too long on your machine.
B) A resource-intensive, number crunching program or something with heavy-disk
access will likely inhibit another program if they are running in parallel, even
though in theory they should get equal slices. On Windows, they simply won't.
There are a number of factors that can affect this, who started up first, is one
program accessing the disk alot, etc.
I would propose two changes to your evaluation routine:
1) Do not run the programs in parallel. Ask for and receive the orders for each
program in turn, and once you've collected all the orders, evaluate them as
normal. In other words, simulate parallel, but don't do actual parallel. This
will not slow things down, but it will guarantee that each program gets 100%
resources. (It would also be easier to code the engine, I would think.) There
also needs to be rule addition: NO "THINKING" outside your allotted time. If I
were to use a chess-program like algorithm, it could just go on calculating
potential orders 100% of the time, taking up resources, etc. It should be
enforced that the program isn't allowed to do anything except sit there between
calls from the main engine for get_orders().
2) Instead of forcing the program to return in an allotted time (which we have
to guess, although we could maintain a local clock in the program I suppose),
allow each program to update a variable that contains a set of "current orders"
and the system will simply take whatever the current value of this variable is at
the end of the alloted time. This will allow for "anytime" algorithms that just
keep updating an answer the longer they have to think about it. If the program
has a "definite" answer, it can submit as soon as its ready, of course.
These changes would likely slow down the evaluation because people might want to
use all of their time each turn, but it would allow for more complex and
interesting strategies. It would also allow the program to do evaluation itself
iteratively by examining possibilities instead of trying to hand-code every
nuance of the strategy. This would also potentially mean that certain bots would
get stronger the faster the machine the tournament is run on. You may or may not
like this implication. You could also ban these sort of endless loop algorithms
altogether, I suppose, but one way or another I think you need to deal with the
possibilities...
10. Re: Contest 2 Announcement:
- Posted by Bernie Ryan <xotron at bluefrog.com>
Nov 28, 2004
-
Last edited Nov 29, 2004
Andy Serpa wrote:
> addr = allocate_string(cmdline) -- command to run child program ("exw
> program.exw")
Andy:
To save typing you didn't need to use allocate_string.
>
> -- Create the child process.
> bFuncRetn = CreateProcessA({
> 0, -- app name (we use command line instead)
> addr, -- command-line
You could have used a temporary ascii string in place of addr, :
sz(cmdline), -- command-line
> free(addr)
szfree() -- free any tempoary strings
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
11. Re: Contest 2 Announcement:
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 28, 2004
-
Last edited Nov 29, 2004
On Sun, 28 Nov 2004 06:32:56 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
I may do that.
Remember that engine.exw is only a temporary solution while I finish
the real arena program (which will incorporate a lot of the code in
engine.exw)
Update version of engine.exw (which doesn't need win32lib to be
changed) will be up soon.
--
MrTrick
12. Re: Contest 2 Announcement:
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 28, 2004
-
Last edited Nov 29, 2004
On Sun, 28 Nov 2004 06:53:52 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> Here is an alternative way to execute the bots:
<SNIP>
Hmmm, looks interesting.
I'll consider using it for the Arena.
There might be issues though, making it compatible with win32lib...
--
MrTrick
13. Re: Contest 2 Announcement:
On Sun, 28 Nov 2004 07:41:51 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> Rules suggestion:
>
> You must submit your orders within 2*n seconds of the "turn" beginning,
> correct? I see a couple of potential problems with this:
>
> A) Your machine is your machine, running at its own speed. The rest of have
> to guess if our moves will take too long on your machine.
True, but I have a fairly fast machine (2.4Ghz, 512mb ram, corporate
machine - nothing cluttering it up )
Can you think of a better metric? My concern is that matches can take
a long time, an entire tournament even longer.
> B) A resource-intensive, number crunching program or something with heavy-disk
> access will likely inhibit another program if they are running in parallel, even
> though in theory they should get equal slices. On Windows, they simply won't.
> There are a number of factors that can affect this, who started up first, is one
> program accessing the disk alot, etc.
That's true... any data file that a program uses is restricted to a
small size though. (Perhaps I should implement file access routines in
eubots.ew to enforce this?)
> I would propose two changes to your evaluation routine:
>
> 1) Do not run the programs in parallel. Ask for and receive the orders for
> each program in turn, and once you've collected all the orders, evaluate them as
> normal. In other words, simulate parallel, but don't do actual parallel. This
> will not slow things down, but it will guarantee that each program gets 100%
> resources. (It would also be easier to code the engine, I would think.)
Actually, it's easier like it is, because the complexity is handled by
the windows API. 
You're right, it would be *fairer* to do things sequentially, I'm just
concerned about the time. Interleaving the processes makes it a lost
quicker, because I can start *all* of the processes, and wait on *all*
of them to finish. (See the waitForMultipleObjects function in
kernel32.dll, it's wonderful). If it was individual, each would need
their own timeout, and turns would take a lot longer to process.
>There also needs to be rule addition: NO "THINKING" outside your
allotted time. If I were to use a chess-program like algorithm, it
could just go on calculating potential orders 100% of the time, taking
up resources, etc. It should be enforced that the program isn't
allowed to do anything except sit there between calls from the main
engine for get_orders().
I may be wrong, but I don't believe that's possible. No top-level
statements are permitted, and the get_orders() function *has* to
return. The only way the MSG_GETMOVE can be received by the bot is if
it's waiting inside eubots.ew.
> 2) Instead of forcing the program to return in an allotted time (which we have
> to guess, although we could maintain a local clock in the program I suppose),
> allow each program to update a variable that contains a set of "current orders"
> and the system will simply take whatever the current value of this variable is at
> the end of the alloted time. This will allow for "anytime" algorithms that just
> keep updating an answer the longer they have to think about it. If the program
> has a "definite" answer, it can submit as soon as its ready, of course.
That is an interesting idea... The way that it works currently is that
if the program is late in returning orders for turn N, its orders are
used in turn N+1, by which time they may not be useful.
> These changes would likely slow down the evaluation because people might want
> to use all of their time each turn, but it would allow for more complex and
> interesting strategies. It would also allow the program to do evaluation itself
> iteratively by examining possibilities instead of trying to hand-code every
> nuance of the strategy. This would also potentially mean that certain bots would
> get stronger the faster the machine the tournament is run on. You may or may not
> like this implication. You could also ban these sort of endless loop algorithms
> altogether, I suppose, but one way or another I think you need to deal with the
> possibilities...
Well, at some stage it has to relinquish control, or it won't be able
to wait on the signal for new orders. I will absolutely not allow a
timeout or non-blocking call to wait for a new orders signal.
Otherwise...
procedure run_match(sequence initial_orders, sequence initial_metrics)
while 1 do
start_time = time()
*figure out orders*
temp = sendOrdersAndWaitForUpdate(orders)
arena = temp[1]
metrics = temp[2]
end while
end procedure
Like this? I don't see how it's any different from the current
functional implementation. The only difference being that the local
variables stay... and that is academic, because you can have global
variables if you want...
What do others think? Would you prefer a setup like this?
(I'm not going to allow both functionl and this, I think that'd be a
large headache.)
--
MrTrick
14. Re: Contest 2 Announcement:
Patrick Barnes wrote:
>
> Update version of engine.exw (which doesn't need win32lib to be
> changed) will be up soon.
I need a version of the arena that can handle end game situations. :)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
15. Re: Contest 2 Announcement:
Alright, I'll add that to the engine. Once there is only a single team
left, it will stop, and display who won, and how many units they have
left.
BTW, if anyone's created some interesting maps, send them to me and
I'll make them available.
They are 16-color bitmaps (hooray for paintbrush). Blank is black,
wall is bright white, and you can use any colors you want other than
those two for the units (the engine normalises them into player 1,
player 2 etc based on what order they are found.)
On Sun, 28 Nov 2004 17:44:35 -0800, cklester <guest at rapideuphoria.com> wrote:
>
> posted by: cklester <cklester at yahoo.com>
>
> Patrick Barnes wrote:
> >
> > Update version of engine.exw (which doesn't need win32lib to be
> > changed) will be up soon.
>
> I need a version of the arena that can handle end game situations. :)
>
>
> -=ck
> "Programming in a state of EUPHORIA."
> http://www.cklester.com/euphoria/
>
>
>
>
--
MrTrick
16. Re: Contest 2 Announcement:
Patrick Barnes wrote:
>
> On Sun, 28 Nov 2004 06:53:52 -0800, Andy Serpa <guest at rapideuphoria.com>
> wrote:
> > Here is an alternative way to execute the bots:
> <SNIP>
>
> Hmmm, looks interesting.
> I'll consider using it for the Arena.
> There might be issues though, making it compatible with win32lib...
>
> --
You may have to namespace some stuff, that's all. I use them together all the
time...
17. Re: Contest 2 Announcement:
Patrick Barnes wrote:
>
> On Sun, 28 Nov 2004 07:41:51 -0800, Andy Serpa <guest at rapideuphoria.com>
> wrote:
> > Rules suggestion:
> >
> > You must submit your orders within 2*n seconds of the "turn" beginning,
> > correct? I see a couple
> of potential problems with this:</font></i>
> >
> > A) Your machine is your machine, running at its own speed. The rest of have
> > to guess if our
> moves will take too long on your machine.</font></i>
>
> True, but I have a fairly fast machine (2.4Ghz, 512mb ram, corporate
> machine - nothing cluttering it up )
> Can you think of a better metric? My concern is that matches can take
> a long time, an entire tournament even longer.
>
The time-limit itself I'm not concerned about, but let's say I have a program
that "thinks" and I want to use my available time, whatever it is. Using a local
clock for 2 seconds * the # opponents I could implement, but not without breaking
the rules (I would need to use .dll functions) because the timer in Euphoria is
at a very low resolution (whole integer seconds) and not very suitable. Or let's
just say I have a slower machine on average my answers take 3 seconds to come up
with. I suspect that on your machine they will be fast enough, but maybe they
won't? How will I know?
>
> > B) A resource-intensive, number crunching program or something with
> > heavy-disk access will likely
> inhibit another program if they are running in parallel, even though in theory
> they should get equal slices. On Windows,
> they simply won't. There are a number of factors that can affect this, who
> started up first, is one program accessing the
> disk alot, etc.</font></i>
>
> That's true... any data file that a program uses is restricted to a
> small size though. (Perhaps I should implement file access routines in
> eubots.ew to enforce this?)
>
>
> > I would propose two changes to your evaluation routine:
> >
> > 1) Do not run the programs in parallel. Ask for and receive the orders for
> > each program in
> turn, and once you've collected all the orders, evaluate them as normal. In
> other words, simulate parallel, but don't do
> actual parallel. This will not slow things down, but it will guarantee that
> each program gets 100% resources. (It would
> also be easier to code the engine, I would think.) </font></i>
>
> Actually, it's easier like it is, because the complexity is handled by
> the windows API.
> You're right, it would be *fairer* to do things sequentially, I'm just
> concerned about the time. Interleaving the processes makes it a lost
> quicker, because I can start *all* of the processes, and wait on *all*
> of them to finish. (See the waitForMultipleObjects function in
> kernel32.dll, it's wonderful). If it was individual, each would need
> their own timeout, and turns would take a lot longer to process.
>
I don't see why it would be faster just because you can start them all at the
same time. The real time is taken up by the bots themselves:
for i = 1 to num_bots do
-- send start msg to bot # i
-- wait up to 2 seconds for response
end for
> >There also needs to be rule addition: NO "THINKING" outside your
> allotted time. If I were to use a chess-program like algorithm, it
> could just go on calculating potential orders 100% of the time, taking
> up resources, etc. It should be enforced that the program isn't
> allowed to do anything except sit there between calls from the main
> engine for get_orders().
>
> I may be wrong, but I don't believe that's possible. No top-level
> statements are permitted, and the get_orders() function *has* to
> return. The only way the MSG_GETMOVE can be received by the bot is if
> it's waiting inside eubots.ew.
>
Ok. I have not studied how you are doing the IPC. With certain kinds of event
loops there would be nothing preventing my program from sending my moves and then
immediately start thinking about new ones while simultaneously checking for new
messages from the main program.
>
> > 2) Instead of forcing the program to return in an allotted time (which we
> > have to guess, although
> we could maintain a local clock in the program I suppose), allow each program
> to update a variable that contains a set of
> "current orders" and the system will simply take whatever the current value of
> this variable is at the end of the alloted
> time. This will allow for "anytime" algorithms that just keep updating an
> answer the longer they have to think about it.
> If the program has a "definite" answer, it can submit as soon as its ready,
> of course.</font></i>
>
> That is an interesting idea... The way that it works currently is that
> if the program is late in returning orders for turn N, its orders are
> used in turn N+1, by which time they may not be useful.
>
Again, depends on your IPC. If you were to use pipes to each program, it could
send an updated answer continously until the time runs out. That's how chess
engines work.
> > These changes would likely slow down the evaluation because people might
> > want to use all of
> their time each turn, but it would allow for more complex and interesting
> strategies. It would also allow the program to
> do evaluation itself iteratively by examining possibilities instead of trying
> to hand-code every nuance of the strategy.
> This would also potentially mean that certain bots would get stronger the
> faster the machine the tournament is run on. You
> may or may not like this implication. You could also ban these sort of
> endless loop algorithms altogether, I suppose, but
> one way or another I think you need to deal with the
> possibilities...</font></i>
>
> Well, at some stage it has to relinquish control, or it won't be able
> to wait on the signal for new orders. I will absolutely not allow a
> timeout or non-blocking call to wait for a new orders signal.
>
> Otherwise...
> procedure run_match(sequence initial_orders, sequence initial_metrics)
> while 1 do
> start_time = time()
> *figure out orders*
> temp = sendOrdersAndWaitForUpdate(orders)
> arena = temp[1]
> metrics = temp[2]
> end while
> end procedure
>
> Like this? I don't see how it's any different from the current
> functional implementation. The only difference being that the local
> variables stay... and that is academic, because you can have global
> variables if you want...
>
> What do others think? Would you prefer a setup like this?
> (I'm not going to allow both functionl and this, I think that'd be a
> large headache.)
>
I'm not I understand the alternatives because I haven't studied your code. Just
some things to think about -- I'm sure we can work within whatever the rules are.
I'm asking about all this because I'll probably make a infinite loop type
program myself and I want to:
A) Make sure I get my moves in on time and recognized.
B) Don't mess up other people's programs because I am hogging the CPU, etc.
18. Re: Contest 2 Announcement:
Andy Serpa wrote:
> ... because the timer in Euphoria is at a very low
> resolution (whole integer seconds) and not very suitable...
That's not true. I have no idea why I said that -- remind me not to post just
after waking up...
19. Re: Contest 2 Announcement:
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 29, 2004
-
Last edited Nov 30, 2004
On Mon, 29 Nov 2004 05:14:31 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> The time-limit itself I'm not concerned about, but let's say I have a program
> that "thinks" and I want to use my available time, whatever it is. Using a local
> clock for 2 seconds * the # opponents I could implement, but not without breaking
> the rules (I would need to use .dll functions) because the timer in Euphoria is
> at a very low resolution (whole integer seconds) and not very suitable. Or let's
> just say I have a slower machine on average my answers take 3 seconds to come up
> with. I suspect that on your machine they will be fast enough, but maybe they
> won't? How will I know?
Hey, I'm open to suggestions for an alternative time-limit metric... A
pity it's not really possible to count number of code lines executed.
> I don't see why it would be faster just because you can start them all at the
> same time. The real time is taken up by the bots themselves:
>
> for i = 1 to num_bots do
> -- send start msg to bot # i
> -- wait up to 2 seconds for response
> end for
Yes, ok. I'll make things sequential.
> > I may be wrong, but I don't believe that's possible. No top-level
> > statements are permitted, and the get_orders() function *has* to
> > return. The only way the MSG_GETMOVE can be received by the bot is if
> > it's waiting inside eubots.ew.
> >
>
> Ok. I have not studied how you are doing the IPC. With certain kinds of
> event loops >there would be nothing preventing my program from sending my moves
> and then >immediately start thinking about new ones while simultaneously checking
> for new >messages from the main program.
Well, the only way to check for new messages blocks. There is no way
to start up another process... (You can only submit one file each
entry, and you can't spawn another instance to do multi-process
collaboration because the command-line is used already.)
> > That is an interesting idea... The way that it works currently is that
> > if the program is late in returning orders for turn N, its orders are
> > used in turn N+1, by which time they may not be useful.
> >
>
> Again, depends on your IPC. If you were to use pipes to each program, it
> could send an updated answer continously until the time runs out. That's how
> chess engines work.
True, except I wasn't able to get pipes working, so I used a different
system. (Look at the sources, I *did* put plenty of comments in)
--
MrTrick
20. Re: Contest 2 Announcement:
- Posted by cklester <cklester at yahoo.com>
Nov 29, 2004
-
Last edited Nov 30, 2004
Patrick Barnes wrote:
>
> > I don't see why it would be faster just because you can start them all at
> > the same time. The
> real time is taken up by the bots themselves:</font></i>
> >
> > for i = 1 to num_bots do
> > -- send start msg to bot # i
> > -- wait up to 2 seconds for response
> > end for
>
> Yes, ok. I'll make things sequential.
Doesn't this slow things down, big time?
If you have 4 bots, that'll be a minimum of 8 seconds, whereas with
the threading, it's not necessarily that long... right?
Well, unless you wait "up to" the 2 seconds... Then it might be tolerable.
But what about with 10,000 bots?!?!?
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
21. Re: Contest 2 Announcement:
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 29, 2004
-
Last edited Nov 30, 2004
On Mon, 29 Nov 2004 14:52:10 -0800, cklester <guest at rapideuphoria.com> wrote:
>
> posted by: cklester <cklester at yahoo.com>
>
> Patrick Barnes wrote:
> >
> > > I don't see why it would be faster just because you can start them all at
> > > the same time. The
> > real time is taken up by the bots themselves:</font></i>
> > >
> > > for i = 1 to num_bots do
> > > -- send start msg to bot # i
> > > -- wait up to 2 seconds for response
> > > end for
> >
> > Yes, ok. I'll make things sequential.
>
> Doesn't this slow things down, big time?
>
> If you have 4 bots, that'll be a minimum of 8 seconds, whereas with
> the threading, it's not necessarily that long... right?
It'll be a maximum of 8 seconds, not a minimum. I'm not sure I like
all this talk about processing for as long as possible, but there you
go...
> Well, unless you wait "up to" the 2 seconds... Then it might be tolerable.
> But what about with 10,000 bots?!?!?
The tournament will be automated. I'm thinking I'll leave it running
overnight. (There goes my folding@home ranking)
--
MrTrick
22. Re: Contest 2 Announcement:
- Posted by Andy Serpa <ac at onehorseshy.com>
Nov 29, 2004
-
Last edited Nov 30, 2004
Patrick Barnes wrote:
>
> On Mon, 29 Nov 2004 14:52:10 -0800, cklester <guest at rapideuphoria.com>
> wrote:
> >
> > posted by: cklester <cklester at yahoo.com>
> >
> > Patrick Barnes wrote:
> > >
> > > > I don't see why it would be faster just because you can start them all
> > > > at the same time.
> The</font></i>
> > > real time is taken up by the bots themselves:</font></i>
> > > >
> > > > for i = 1 to num_bots do
> > > > -- send start msg to bot # i
> > > > -- wait up to 2 seconds for response
> > > > end for
> > >
> > > Yes, ok. I'll make things sequential.
> >
> > Doesn't this slow things down, big time?
> >
> > If you have 4 bots, that'll be a minimum of 8 seconds, whereas with
> > the threading, it's not necessarily that long... right?
>
> It'll be a maximum of 8 seconds, not a minimum. I'm not sure I like
> all this talk about processing for as long as possible, but there you
> go...
>
It may not be feasible to use that kind of algorithm anyway -- it is actually a
very complex problem you've designed.
A note about possible arenas: it occured to me that non-symmetrical arenas could
be unfair (like your TEST map) becaues they may give a structural advantage to
one team or another -- I'm not sure how but I'm sure some "terrains" are more
advantageous than others for attack or defense. For this reason it wouldn't
really be fair to start with random placement of walls or units unless they were
symmetrically random.
BTW, I ran drone2 against itself on map2 (and set the delay to 0 so I could
watch it fast). It often locked up and did nothing at all for several seconds --
the CPU dropped to 0 during those periods as well. It was like it missed a move
or something and was just waiting there...
23. Re: Contest 2 Announcement:
- Posted by Patrick Barnes <mrtrick at gmail.com>
Nov 29, 2004
-
Last edited Nov 30, 2004
On Mon, 29 Nov 2004 15:18:20 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> A note about possible arenas: it occured to me that non-symmetrical arenas
> could be >unfair (like your TEST map) becaues they may give a structural
> advantage to one team or >another -- I'm not sure how but I'm sure some
> "terrains" are more advantageous than >others for attack or defense. For this
> reason it wouldn't really be fair to start with random >placement of walls or
> units unless they were symmetrically random.
Yes, you are right... and although the teams are randomly assigned
identity, I'll make sure the maps used for the tournament and finals
are either rotationally or translationally symetrical for the number
of opponents in the map.
> BTW, I ran drone2 against itself on map2 (and set the delay to 0 so I could
> watch it fast). >It often locked up and did nothing at all for several seconds
> -- the CPU dropped to 0 during >those periods as well. It was like it missed a
> move or something and was just waiting >there...
I believe that's a problem with the timers... if you leave it at 100,
there's no problem.
--
MrTrick
24. Re: Contest 2 Announcement:
- Posted by cklester <cklester at yahoo.com>
Nov 29, 2004
-
Last edited Nov 30, 2004
Patrick Barnes wrote:
>
> On Mon, 29 Nov 2004 14:52:10 -0800, cklester <guest at rapideuphoria.com>
> wrote:
> > posted by: cklester <cklester at yahoo.com>
> >
> > If you have 4 bots, that'll be a minimum of 8 seconds, whereas with
> > the threading, it's not necessarily that long... right?
>
> It'll be a maximum of 8 seconds, not a minimum.
If you give each bot 2 seconds, it will be a minimum of 8 seconds (as well
as a maximum). I was comparing that against if you give each both "up to"
2 seconds, which was what was said and I misread at first. :)
> > Well, unless you wait "up to" the 2 seconds... Then it might be tolerable.
> > But what about with 10,000 bots?!?!?
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
25. Re: Contest 2 Announcement:
On Mon, 29 Nov 2004 15:32:39 -0800, cklester <guest at rapideuphoria.com> wrote:
> > > If you have 4 bots, that'll be a minimum of 8 seconds, whereas with
> > > the threading, it's not necessarily that long... right?
> >
> > It'll be a maximum of 8 seconds, not a minimum.
>
> If you give each bot 2 seconds, it will be a minimum of 8 seconds (as well
> as a maximum). I was comparing that against if you give each both "up to"
> 2 seconds, which was what was said and I misread at first. :)
The inter-process communication used is a combination of semaphores
and shared memory.
The engine sends a start signal to the bot, then waits on the return
semaphore with a certain timeout.
If all bots set their orders and return in only 0.1 seconds, that's
fine! The engine will start the next turn much quicker, because it
didn't have to keep waiting.
If it times out, then it'll only process the orders of those who returned.
--
MrTrick
26. Re: Contest 2 Announcement:
sure:
<http://users.secsme.org.au/~prbarnes/projects/contest/rules.html>
I've made a whole heap of changes, but I can't update them yet cause
the firewall blocks it here. If anyone can provide me with a tool to
tunnel scp over port 80, you'll have my heartfelt appreciation.
They'll be up tonight.
On Tue, 30 Nov 2004 02:28:46 +0000, jxliv7 at hotmail.com
<jxliv7 at hotmail.com> wrote:
>
> Patrick Barnes wrote:
> >
> >
> <snip>
>
> would you mind posting your site where the contest is with every message
> about the contest?
>
> i'm getting tired of trying to go back and find it in the forum...
>
>
>
>
>
--
MrTrick
