Re: [computer-go] Event-driven programming

[Xiaoyong Wu <xiaoyong_wu@xxxxxxxxxxxxx>]

Hi, peter,
If I understand correctly, you are looking at something like this:
In a ladder, at the current state, White wins the ladder. 
If later on, Black makes a move at some positions, Black will win the ladder.
There will be one ladder listener listening on those positions.

For this is correct, a tuplespace like Linda might be a good choice.
http://www.cs.yale.edu/Linda/linda.html

-Xiaoyong
-----Original Message-----
From: Peter Drake <drake@xxxxxxxxxxxxxxxxx>
Sent: Jan 16, 2004 9:29 AM
To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
Subject: Re: [computer-go] Event-driven programming

On Friday, January 16, 2004, at 08:51  AM, Robin Kramer wrote:

>> On Friday, January 16, 2004, at 01:36  AM, Patrick Stiegeler wrote:
>>
>>> dear peter,
>>>
>>> i think, i did something like what you call "event-driven
>>> programming". i use a singleton which i call a NotificationServer and
>>> which handles  all
>>> the message passing:
>>
>> So  you only have a single NotificationServer?  How do you determine
>> which listeners get which events ... or do you just send every event 
>> to
>> all listeners in the entire system?
>
> If there is excellent documentation for the interface, my preference,
> would be for the listeners to be able to register for events and 
> register
> generated events.  Otherwise, providing a list of events might be 
> easier
> for everyone involved.

If it works, there will be excellent documentation.  I'm good at that.  
:-)

My intent is for a listener to attach itself to a particular speaker, 
rather than a particular type of event.  For example, a block is only 
interested in color changes at the points adjacent to it.  (A 
life-and-death estimator might have more widely-ranging interests.)

> One other question, will some modules be able to generate events?  Will
> modules be able to set up their own event servers to incorporate
> information from other machines(i.e. if two modules could use 
> information
> about ladders, maybe a joseki and a tesuji module will they both be 
> able
> to use a module which reads ladders?)

I'm not sure I understand your question.  Yes, objects will be able to 
generate events (generally in response to another event they received). 
  I suppose the ladder reader could generate a "ladder broken" event, to 
which both the joseki and tesuji listeners would react.

As mentioned, I'm working on a single machine here.  This should be 
parallelizable in theory at least.

> Would it be possible to code an event server,client object that could 
> be
> included in each module?

I think it's important to have a master event queue on a single 
machine.  Otherwise there are race condition issues.

> Is there any way to provide for thinking about a move during the 
> opponents
> turn?

It should be possible through multithreading.  Keep a collection of 
analyzer(?) objects around.  If its the opponent's turn, let one of the 
analyzers fire an event which might set up a cascade of other events.  
Once the event queue settles down, check whether it's our turn yet -- 
if not, do more analysis.

Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go