[GNE]GNE .4 alpha and Linux

[Gillius <gi...@ma...>]

Elias, I haven't seen you for a very long time in #allegro, so I was 
wondering if you could help me out by creating a Linux version of the 
makefile, if you can do that?  You don't have to test it -- I can do that, 
but I know you will know better what to change, and I feel safe in asking 
because I think very little changes for Linux.

The rest of this message is just informational about what I've been doing 
with GNE (so if you are busy you can skip past/skim it)...

I need to start testing the lib for Linux because I want to make sure it is 
working there before I release .4 alpha.  I've been doing an extreme amount 
of work on GNE lately.  I ran into some big problems with SyncConnection 
now, and I had to sorta restructure the API.  There have been class 
additions and deletions and some major changes that will break all 
Connection-based code.  The new event system is looking more and more like 
Java's Swing everytime I modify it ;).

SyncConnection is going to be more complex than before.  Now instead it 
will be a wrapper for Connection, because I noticed that virtually all of 
SyncConnection's code was the same as Connection, and because of the 
synchronous requirement, the code was inferior and didn't have the flow 
control or caching, since that is very non-trivial for "memory-less" 
syncronous connections.  So instead the class now acts as a wrapper, and 
registers itself with the connection you give it to become the event 
listener (events are now done through listener regististration, rather than 
overloading functions).

This has many advantages.  Firstly, the SyncConnection will actually be 
asyncronous, but appear and act fully syncronous to the user, by "hiding 
and caching writes."  It will also use the flow control.  Plus, with this 
method, there is no "conversions" taking place, and a SyncConnection can 
wrap a Connection at any time (although in practice it is best to only wrap 
it during the connection process, where it is automatically done for the 
user).  Also, the simpler ConnectionListener class where the events go make 
it easier for the user by needing to know much less internals of GNE, allow 
the user to potentally save memory as well.  Multiple Connections can send 
their events to the same listener, rather than having a child class receive 
everything.

The API is now much more robust, easier to use, and all potential flaws, 
memory leaks, and "questionable programming practices" that I could see are 
eliminated.  Since SyncConnections are meant for connecting, and they 
aren't an entity in themselves exhello will be retrofitted to use them.  
Exhello should become much simpler and much of the "bad" code (such as 
objects destructing while their functions are still running etc), will be 
eliminated.  Right now it works only because I wait a few seconds and just 
hope that everything is done by then so I can quit.

Gillius