[Freeciv-Dev] Re: Keepig Xconq and Freeciv syncronized.

[Erik Sigra <sigra@xxxxxxx>]

torsdagen den 22 februari 2001 08:29 skrev Stan Shebs:
> For instance, a common random number generator is probably a waste of
> time, because Xconq and Freeciv both have requirements on consistency
> and read/write behavior.  Satisfying those will likely need more code
> than the few lines that actually implement the RNG.

I still don't understad what special random number generation needs 
Freeciv/Xconq don't share with each other.

What Freeciv has seems to have is:
* A random function that returns a random number in the interval 0 .. size - 
1 (0 .. MAX_UINT32 for 0 size).
* The same seed always give the same sequence of random numbers. (Is this
  what you call "consistency"?)
* ability to get and set the state. (Is this what you call "read/write
  behaviour"?)

Xconq differs in the case where size is 0.

So why do you think Freeciv/Xconq coudn't use Xconq's/Freeciv's RNG (not 
counting the small amount of code adjustment needed)?

> But one could imagine a libnamegen.a being installed in /usr/lib.

We don't have to go as far as creating common libraries in /usr/lib if we 
don't want to. It would be a great convenience just to be able to copy code 
between the programs and expect it to work with minimal modification.

The obstacles are for example:
* Random number generation.
* Memory allocation. (I was able to just replace xmalloc with fc_malloc and
  it seems to work. If thoose would have had the same name, I wouldn't even
  have had to do that.)
* The macros DEBUGGING/DEBUG (Can't you agree on one of them?)
* Logging. Both programs should have a function to call with a log level and
  a string. They should have the same name, but do different things,
  depending on the user interface.
* String handling. (I was able to just replace copy_string with mystrdup and
  it seems to work. If thoose would have had the same name, I wouldn't even
  have had to do that.)
* How function headers look, for example:

  /* This is a function that does this and is
     useful in when you need that. */

  /* This is a function that does this and is
   * useful in when you need that.
   */

  /******************************************
   * This is a function that does this and is
   * useful in when you need that.
   *****************************************/

  /* This is a function that does this and is
   * useful in when you need that.
   *****************************************/

  /*****************************************
    This is a function that does this and is
    useful in when you need that.
  *****************************************/
  (This style works really bad with Emacs cc-mode.)

* Possibly other stuff like genlist/speclist and hash.

I don't think that converging on the issues I have mentioned now would cause 
code to swell up because of increased generality.

> Could Xconq and Freeciv actually converge in the future?  I suppose
> it's possible.  Xconq has had 14 years of wandering down the generality
> road, and indeed it serves as a cautionary tale of what kind of morass
> you can end up if you try to generalize everything - it can do all sorts
> of games, but no single game particularly well, and the code scares off
> most would-be contributors.  Freeciv has a more limited goal, is much
> closer to achieving it, and that's a really good thing.

One way to not scare them off is to make them feel familiar with how the code 
looks. If they recognize function names and infrastructure from for example 
Freeciv, they can get started easier. Some may feel reluctant to learn a 
whole new set of infrastructure.