RJLRef: $PH/06f522/SetGame06f/SetGameLegacy061125.txt

This updates what I had previously told you 
about reuse of GEN and LCP in the SetGame project.

It turns out that this has not previously been done.
However, after two prior iterations trying to 
produce a distributed version spent most of their time
on ad hoc code and networking, it's time to get 
code generation and distributed operations back into the 
system, to pave the way for Distributed BDE.

The question now is (to be discussed Tues eve.)
What can be done about integrating LCP control
with SetGame graphics?  

Here is another legacy project summary.
It ends with the last two sections of Robert Almonte's 
final report, on testing and future work.

---------------------------------------------
Project $CASE/04s522/setGameo4s was extended 
by R Almonte in $CASE/04f522/04f522/ralmonte/cs522
(linked from $PH/COOL-LCP/SetGame04f)
He supplied new code and more complete models 
including .gif and .zargo (ArgoUML) diagrams.

However he ran out of time and could not integrate the network 
and control aspects with schema.sch API and LCP state model flow 
control, any more than Lalo and Herrick did in SetGame04s.

Since he did not include LCP state models, 
I now understand why you were ignoring the 
data model input to GEN and the StateModel setups for LCP -
they did not exist! :-( 

GEN/LCP/project integration problems were actually tackled
(successfully) by the Hominid project in 02s522.
Four teams did parallel projects. Team1 and Team4 did well.

The 02s522 Hominid project was extended in $CASE/04s522/lcp04s.
where Alfredo Lopez resolved various work-arounds that  
02s522 teams used to resolve state action routine pointers.

Lopez generated a funcion ptr array FuncTbl[] indexed by the 
ActFunc field of the STate table, in a preliminary setup phase
which declared State Models.  The former use of ActFunc as a 
function ptr  failed on alpha 64-bit address machines.

My plan is to demonstrate GEN and LCP use on the SetGame project.
$CASE/04f522/ralmonte/cs522/docs/ProjectReport04f522.doc
ends with this test report and TBDs:

------------------------------------
ralmonte:

7.	Testing (ralmonte)

   The DSG application was implemented in two directories: 
dsgame, which contains the server (game manager) and the 
player that contains the interface for the users. 
Both codes were created using Kdevelop IDE in Fedora2.
The project information for both programs is in dsgame and player 
directories. To configure the project to specific platform, just run:

./configure
It will create all the information that the makefile needs 
from the platform. Later CFLAGS will have to be updated manually 
in the ./src/Makefile.in file to include -pthread flag. 
It probably could be automated but I could not find how 
since Kdevelop IDE does it automatic for me.

Run make from the absolute directory of the program, 
and it will generate the executable in the  . /src directory. 
Before it was customized to generate the object files 
and executable in ./debug/src, but this was using Kdevelop IDE.

I created a .sh for each application to run it from the absolute directory.

	./dsgame.sh [PORT]    /* Run in background, for server */

	./player.sh SERVER_HOSTNAME SERVER_PORT

When I ran it in my PC with Fedora2, It ran fine. 
Sometimes it gave me some invalid reading error when I sent a 
VALIDATE_SET message to the server.
I tried in mercury.cs.uml.edu, but it didn't let me add player 
information. It crashes rightly.


8. Future Plan (ralmonte)

The initial goal of this project was to integrate the Setgame project 
from 03f522 using LCP and the DSG project from 04s522 using this new 
communication library. The goal was not meet completely due to the short 
time, the need of a team, and more documentation from the previous projects.

What needs to be done?

-	I implemented a text-based GUI for the player interface 
that will be really nice if it could be implemented using graphic 
interface like Java or X11.

-	The connection between game controller and player interface 
is working in the simplest phase. Connection entity must be added 
in the <netcomm.h> library to be able to control more than one game 
at the same time. NodeController Entity is not implemented if a future 
application requires so synchronization, it will need this entity 
in the netcomm library.

-	I made a code-based game manager to control the game. 
This must be implemented using LCP to represent it as an ActiceInstance 
subclass, which control the SG SetEvaluator and SF FacetEvaluator.
-----------------------------