[Freeciv-Dev] Re: Profiling Civserver again

[Mike Kaufman <mkaufman@xxxxxxxxxxxxxx>]

On Wed, Aug 01, 2001 at 09:27:04PM -0400, Ross W. Wetmore wrote:
> If the world was a perfect place, no bug would last long enough to trouble
> anyone, and it would be fixed as you suggest.

hmmph
> 
> The assumptions are safety factors that allow the program to function in spite
> of problems. They are most appreciated by people who are 15 hours into a game
> when the program crashes with a cryptic message, or maybe no message except
> the INSTALL.readme that says report such occurrences to bugs@xxxxxxxxxxx. And
> after much of this such people usually dump Freeciv and go back to Sid's 
> version.

yep I agree, but see below

> 
> Defensive programming like defensive driving is worthwhile if it doesn't 
> cost that much more to implement or follow the right habits.

yes, but this whole discussion started as a result of "hey this function got 
called umpteen million times!" It might be interesting to see what the 
differences are between modulus and while loops and such in the macro, but if a 
little care can avoid the problem, I say we might as well try.

Besides, (not following the list as carefully as he should) has anybody checked 
to see how often (and where) the code goes outside of [-map.xsize,2*map.xsize]?
If it doesn't, why build in a lot of defensive cruft into the code?

> 
> If the code were running a Boeing 747, I don't think you would get a lot
> of support for your suggested development model, and it really shouldn't
> be an apples and oranges comparison.

exactly, it shouldn't, and that is: we're not running a 747 here. what we're 
trying to do (I hope) is to create a nice, slick game with good clean code. I 
thought that part of the idea of the open source model was to at least _try_ to 
do things the RIGHT WAY (as he tries not to look too hard at the civworld code).

I don't know what to do about games crashing at the 15 hour mark (except maybe 
autosave?), but I think that if certain people are that fickle that they would 
switch back to payciv after one or two segfaults, I say, seeya. (might I add 
that these decisions are being made for a "development" tree not the production 
one. If we lost these people because the cvs snapshot they were running 
crashed, we would have lost them anyway -- perhaps adding a more strenuous 
blurb about switching to production code if experiencing problems with dev 
code?).
> 
> Besides having tracked down a number of such things, I can tell you from
> firsthand experience that it isn't the case that a few local peeks into the 
> code will turn up obvious problems. Usually, it is a mistake made next week
> generating garbage data 3 left, two up and 6 down that is the culprit :-).

tracking these things down is what the development process is all about. 
Besides, there can't be all that many ways you _can_ get that far out of bounds 
(or out of bounds period) someone with more knowledge of the code than I could 
list them I imagine. (at least I see only 20 files which call map_adjust_x() 
--of course there could be other places which are a problem, but we'd be 
screwed anyway). After auditing those spots, changing the macro would be much 
less risky.

-mike
> 
> Cheers,
> RossW
> 
> At 06:31 PM 01/08/01 -0500, Mike Kaufman wrote:
> >Perhaps someone could answer this for me: why do we _have_ to assume
> possible X values outside [-map.xsize,2*map.xsize] ? When would this
> (legitimately) happen?
> >
> >If a function is (naughtily) setting X too big or small, let's correct the
> function. Grepping through the code, I don't see a massive number of places
> where map_adjust_x() is called. Ought not be that hard to track down.
> Someone please correct my naivete
> >
> >-mike