subject:"\[Freeciv\-Dev\] this is a test"

[Freeciv-Dev] [bug #25006] Configure test for thread implementation does not show results when it's tinycthread

2016-08-23 Thread Marko Lindqvist

Update of bug #25006 (project freeciv):

  Status:  Ready For Test => Fixed  
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #25006] Configure test for thread implementation does not show results when it's tinycthread

2016-08-22 Thread Marko Lindqvist

URL:
  

 Summary: Configure test for thread implementation does not
show results when it's tinycthread
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 22 Aug 2016 10:31:49 AM EEST
Category: bootstrap
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 3.0.0
 Contains string changes: None

___

Details:

Fix attached



___

File Attachments:


---
Date: Mon 22 Aug 2016 10:31:49 AM EEST  Name: TinycthreadResult.patch  Size:
428B   By: cazfi



___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #5721] DejaGNU test harness for common client code

2015-03-25 Thread Bernd Jendrissek

Follow-up Comment #2, patch #5721 (project freeciv):

I'll probably get around to porting to 2.5 in the next few weeks. This patch
started on 2.2 and it was fairly easy to update to 2.3 and then 2.4, but I
can't opine on how hard it will be to update to 2.5+.

My current plan is rather to dig up some old bugs with savefile attachments,
to expand the testsuite a little, to train it to be able to find the kind of
bugs that actually happen.

___

Reply to this item at:

  http://gna.org/patch/?5721

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #5721] DejaGNU test harness for common client code

2015-01-21 Thread Marko Lindqvist

Follow-up Comment #1, patch #5721 (project freeciv):

What kind of plan you have about updating this to current freeciv development
version? 2.4 is quite old in that respect (2.5 is about to release, 2.6 is in
stable branch already, feature development is targeting 3.0)
It might be worth taking a new copy of stub client as a base and port your
changes to that rather than trying to update your existing console-client.

___

Reply to this item at:

  http://gna.org/patch/?5721

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #5721] DejaGNU test harness for common client code

2015-01-18 Thread Bernd Jendrissek

URL:
  http://gna.org/patch/?5721

 Summary: DejaGNU test harness for common client code
 Project: Freeciv
Submitted by: berndj
Submitted on: Sun 18 Jan 2015 03:22:40 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 

___

Details:

Includes a test that detects a real bug (an old one) - #20786. Makes 'make
check' run regression tests in the DejaGNU-based testsuite.



___

File Attachments:


---
Date: Sun 18 Jan 2015 03:22:40 PM UTC  Name: freeciv-2.4.diff  Size: 226kB  
By: berndj

http://gna.org/patch/download.php?file_id=23536

___

Reply to this item at:

  http://gna.org/patch/?5721

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #4201] Add test for Casus Belli (reason to cancel) to the DiplRel requirement type.

2013-09-20 Thread Sveinung Kvilhaugsvik

Update of patch #4201 (project freeciv):

  Status:  Ready For Test = Done   
 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://gna.org/patch/?4201

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #4201] Add test for CasusBellig (reason to cancel) to DiplRel requirement type.

2013-09-18 Thread Sveinung Kvilhaugsvik

URL:
  http://gna.org/patch/?4201

 Summary: Add test for CasusBellig (reason to cancel) to
DiplRel requirement type.
 Project: Freeciv
Submitted by: sveinung
Submitted on: Wed 18 Sep 2013 05:56:34 PM GMT
Category: general
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: sveinung
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.6.0

___

Details:





___

File Attachments:


---
Date: Wed 18 Sep 2013 05:56:34 PM GMT  Name: DiplRelCasusBelli.patch  Size:
2kB   By: sveinung

http://gna.org/patch/download.php?file_id=19044

___

Reply to this item at:

  http://gna.org/patch/?4201

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #4201] Add test for Casus Belli (reason to cancel) to the DiplRel requirement type.

2013-09-18 Thread Sveinung Kvilhaugsvik

Update of patch #4201 (project freeciv):

 Summary: Add test for CasusBellig (reason to cancel) to
DiplRel requirement type. = Add test for Casus Belli (reason to cancel) to
the DiplRel requirement type.


___

Reply to this item at:

  http://gna.org/patch/?4201

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20375] fcintl.sh test uses == comparison.

2012-12-21 Thread Marko Lindqvist

Update of bug #20375 (project freeciv):

  Status:  Ready For Test = Fixed  
 Assigned to:None = cazfi  
 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://gna.org/bugs/?20375

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20375] fcintl.sh test uses == comparison.

2012-12-16 Thread Marko Lindqvist

URL:
  http://gna.org/bugs/?20375

 Summary: fcintl.sh test uses == comparison.
 Project: Freeciv
Submitted by: cazfi
Submitted on: Mon 17 Dec 2012 02:57:47 AM EET
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
  Status: Ready For Test
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 2.4.0, 2.5.0

___

Details:

tests/fcintl.sh checks variable equality with == instead of standard
compliant =. Fix attached.



___

File Attachments:


---
Date: Mon 17 Dec 2012 02:57:47 AM EET  Name: FcintlshBashism.patch  Size: 1kB 
 By: cazfi

http://gna.org/bugs/download.php?file_id=16854

___

Reply to this item at:

  http://gna.org/bugs/?20375

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #2987] add test script to check for correct use of fcintl.h

2011-10-30 Thread Matthias Pfafferodt


Update of patch #2987 (project freeciv):

  Status:  Ready For Test = Done   
 Assigned to:None = syntron
 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://gna.org/patch/?2987

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #2988] add test to check for correct usage of __FC_LINE__

2011-10-30 Thread Matthias Pfafferodt


Update of patch #2988 (project freeciv):

  Status:  Ready For Test = Done   
 Assigned to:None = syntron
 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://gna.org/patch/?2988

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #2987] add test script to check for correct use of fcintl.h

2011-10-26 Thread Matthias Pfafferodt


URL:
  http://gna.org/patch/?2987

 Summary: add test script to check for correct use of
fcintl.h
 Project: Freeciv
Submitted by: syntron
Submitted on: Mi 26 Okt 2011 22:24:54 CEST
Category: bootstrap
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:





___

File Attachments:


---
Date: Mi 26 Okt 2011 22:24:54 CEST  Name:
20111026-0035-add-test-script-to-check-for-correct-use-of-fcintl.h.patch 
Size: 2kB   By: syntron

http://gna.org/patch/download.php?file_id=14277

___

Reply to this item at:

  http://gna.org/patch/?2987

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #2988] add test to check for correct usage of __FC_LINE__

2011-10-26 Thread Matthias Pfafferodt


URL:
  http://gna.org/patch/?2988

 Summary: add test to check for correct usage of __FC_LINE__
 Project: Freeciv
Submitted by: syntron
Submitted on: Mi 26 Okt 2011 22:25:59 CEST
Category: bootstrap
Priority: 5 - Normal
  Status: Ready For Test
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Planned Release: 2.4.0

___

Details:

see also gna patch #2972



___

File Attachments:


---
Date: Mi 26 Okt 2011 22:25:59 CEST  Name:
20111026-0036-add-test-to-check-for-correct-usage-of-__FC_LINE__.patch  Size:
822B   By: syntron

http://gna.org/patch/download.php?file_id=14278

___

Reply to this item at:

  http://gna.org/patch/?2988

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1286] Featured test: inputline toolkit

2009-11-28 Thread Daniel Markstedt


Follow-up Comment #7, patch #1286 (project freeciv):

Skin problem raised as bug #14853

___

Reply to this item at:

  http://gna.org/patch/?1286

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1288] Featured test: client side colors

2009-09-25 Thread pepeto


Update of patch #1288 (project freeciv):

 Assigned to:None = pepeto 


___

Reply to this item at:

  http://gna.org/patch/?1288

___
  Message posté via/par Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1288] Featured test: client side colors

2009-09-19 Thread pepeto


Follow-up Comment #5, patch #1288 (project freeciv):

 create_event() is client side mechanism that simulates server
 sent events. It calls handle_event(). See for example
 control.c:do_unit_goto()

Sorry, my mistake, I missed that.  The new patch fix that and:
* create_event() doesn't pass the client.conn.id to handle_event, because
this is used for chat, and this is not a chat line.
* use city_link() instead of city_name() in the create_event() messages.


(file #6764)
___

Additional Item Attachment:

File name: trunk_S2_2_ft_client_colors2.diff.gz Size:10 KB


___

Reply to this item at:

  http://gna.org/patch/?1288

___
  Message posté via/par Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1288] Featured test: client side colors

2009-09-18 Thread Marko Lindqvist


Follow-up Comment #1, patch #1288 (project freeciv):

I noticed that client creates some messages as events with function called
create_event(). Are you aware of that, and are you going to add colors to
those messages also? (If you do, open new ticket)

___

Reply to this item at:

  http://gna.org/patch/?1288

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1286] Featured test: inputline toolkit

2009-09-17 Thread pepeto


Follow-up Comment #4, patch #1286 (project freeciv):

 Is there problem with Freeciv theme on this toolkit? Toolkit
 appears light grey (like default gtk theme) and not like Freeciv
 theme in general.

Checked the theme stuff.  It seems that the toolbar in the default Freeciv
theme is in grey.  I guess it haven't been worked because Freeciv gtk client
didn't contain toolbar until today.  Maybe Daniel could improve this?

 Tooltips could give out shortcut keys performing same actions.

Done.


(file #6738)
___

Additional Item Attachment:

File name: trunk_S2_2_ft_inputline_toolkit3.diff Size:23 KB


___

Reply to this item at:

  http://gna.org/patch/?1286

___
  Message posté via/par Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1286] Featured test: inputline toolkit

2009-09-16 Thread pepeto


Follow-up Comment #1, patch #1286 (project freeciv):

Updated to work against current revisions.


(file #6727)
___

Additional Item Attachment:

File name: trunk_S2_2_ft_inputline_toolkit2.diff Size:22 KB


___

Reply to this item at:

  http://gna.org/patch/?1286

___
  Message posté via/par Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #1286] Featured test: inputline toolkit

2009-09-16 Thread Marko Lindqvist


Follow-up Comment #3, patch #1286 (project freeciv):

Tooltips could give out shortcut keys performing same actions.

___

Reply to this item at:

  http://gna.org/patch/?1286

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40092) 2.2-test: fix update_dumb_city() missing update_vision_site_from_city()

2008-02-10 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=40092 

In PR#40072, the second reported error has Teotitlan shown with the wrong
owner.  This patch does not fix the underlying issue, but is a step toward
making the savegame playable.

The savegame.c:2800 code tries to fix inconsistent games.  This leads to
reality_check_city() and update_dumb_city().  I've straightened the logic in
update_dumb_city(), and added a bit more error checking.  Found a bug in
PR#39895, missing one crucial line: update_vision_site_from_city().

Comparing the current code with 2.1 and 2.0, and walk-through of PR#13718
changes, found a possible improvement through waiting to update the national
borders (a few lines), matching older code in 2.0.

Other minor cleanup.

Index: server/citytools.c
===
--- server/citytools.c  (revision 14391)
+++ server/citytools.c  (working copy)
@@ -186,10 +186,9 @@
 
   terrain_type_iterate(pterrain) {
 /* Now we do the same for every available terrain. */
-goodness
-  = is_terrain_near_tile(ptile, pterrain)
-  ? nc-terrain[terrain_index(pterrain)]
-  : -nc-terrain[terrain_index(pterrain)];
+goodness = is_terrain_near_tile(ptile, pterrain)
+   ? nc-terrain[terrain_index(pterrain)]
+   : -nc-terrain[terrain_index(pterrain)];
 if (goodness  0) {
   priority /= mult_factor;
 } else if (goodness  0) {
@@ -998,12 +997,11 @@
   vision_reveal_tiles(pcity-server.vision, game.info.city_reveal_tiles);
   city_refresh_vision(pcity);
 
-  tile_set_city(ptile, pcity);
+  tile_set_city(ptile, pcity); /* partly redundant to server_set_tile_city() */
   city_list_prepend(pplayer-cities, pcity);
 
   /* Claim the ground we stand on */
   map_claim_ownership(ptile, pplayer, ptile);
-  map_claim_border(ptile, pplayer);
 
   if (terrain_control.may_road) {
 tile_set_special(ptile, S_ROAD);
@@ -1031,7 +1029,7 @@
 }
   }
 
-  /* Place a worker at the city center; this is the free-worked tile.
+  /* Place a worker at the is_city_center() is_free_worked_tile().
* This must be done before the city refresh (below) so that the city
* is in a sane state. */
   /* Ugly detail here is that if another city is currently working
@@ -1042,6 +1040,10 @@
* ptile-worked does not point to it, it will give tile up. */
   server_set_tile_city(pcity, CITY_MAP_SIZE/2, CITY_MAP_SIZE/2, C_TILE_WORKER);
 
+  /* Update the national borders.  This affects the citymap tile status,
+   * so must be done after the above and before arranging workers. */
+  map_claim_border(ptile, pplayer);
+
   /* Refresh the city.  First a city refresh is done (this shouldn't
* send any packets to the client because the city has no supported units)
* then rearrange the workers.  Note that auto_arrange_workers does its
@@ -1172,9 +1174,9 @@
 
   /* idex_unregister_city() is called in game_remove_city() below */
 
-  /* identity_number_release(pcity-id) is *NOT* done!  The cities may still be
- alive in the client, or in the player map.  The number of removed 
- cities is small, so the loss is acceptable.
+  /* identity_number_release(pcity-id) is *NOT* done!  The cities may
+ still be alive in the client, or in the player map.  The number of
+ removed cities is small, so the loss is acceptable.
*/
 
   old_vision = pcity-server.vision;
@@ -1730,10 +1732,11 @@
 bool update_dumb_city(struct player *pplayer, struct city *pcity)
 {
   bv_imprs improvements;
-  struct vision_site *pdcity = map_get_player_city(pcity-tile, pplayer);
+  struct tile *ptile = city_tile(pcity);
+  struct vision_site *pdcity = map_get_player_city(ptile, pplayer);
   /* pcity-occupied isn't used at the server, so we go straight to the
* unit list to check the occupied status. */
-  bool occupied = (unit_list_size(pcity-tile-units)  0);
+  bool occupied = (unit_list_size(ptile-units)  0);
   bool walls = city_got_citywalls(pcity);
   bool happy = city_happy(pcity);
   bool unhappy = city_unhappy(pcity);
@@ -1747,27 +1750,32 @@
   } improvement_iterate_end;
 
   if (NULL == pdcity) {
+map_get_player_tile(ptile, pplayer)-site =
 pdcity = create_vision_site_from_city(pcity);
-map_get_player_tile(pcity-tile, pplayer)-site = pdcity;
-  } else if (pdcity-identity == pcity-id
-  vision_owner(pdcity) == city_owner(pcity)
-  pdcity-size == pcity-size
-  0 == strcmp(pdcity-name, city_name(pcity))
-  pdcity-occupied == occupied
+  } else if (pdcity-location != ptile) {
+freelog(LOG_ERROR, Trying to update bad city (wrong location)
+at %i,%i for player %s,
+   TILE_XY(pcity-tile),
+   player_name(pplayer));
+pdcity-location = ptile;   /* ?? */
+  } else if (pdcity-identity != pcity-id) {
+freelog(LOG_ERROR, Trying to update old city (wrong identity)
+at %i,%i for player %s,
+   TILE_XY(pcity-tile),
+

[Freeciv-Dev] (PR#40088) 2.2-test: wrong city size after attack

2008-02-09 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=40088 

This is implied by the sanitycheck repair in PR#40086, that presumably
happened in the PR#40072 savegame.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#40086) 2.2-test: city center tiles not worked

2008-02-08 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=40086 

Jason Dorje Short wrote:
 The CM code is in common/aicore/cm.c.
 
Well, I've spent a bit of time looking at that, and its pretty difficult.
Whomever wrote that was a genius, or an idiot

Anyway, using the old tried and true pedestrian debugging techniques, I've
found one very nasty place that this happens: IN THE SANITY CHECK!!!

Somebody felt the need to do more than check, without any message or
indication to the user!

In server/sanitycheck.c real_sanity_check_city():

   if (workers + city_specialists(pcity) != pcity-size + 1) {
 int diff = pcity-size + 1 - workers - city_specialists(pcity);

 SANITY_CITY(pcity, workers + city_specialists(pcity) == pcity-size + 1);
...

   if (diff  0) {
city_map_checked_iterate(pcity-tile, city_x, city_y, ptile) {
  if (ptile-worked == pcity  diff  0) {
server_remove_worker_city(pcity, city_x, city_y);
diff++;
  }
} city_map_checked_iterate_end;
   }

The first worker found is the city center!

Now, I still don't know how the dickens the city size is bad, but the
cure is worse than the disease

===

Other server_remove_worker_city() calls elsewhere have a check before them,
for example:

   if (!is_valid || is_free_worked_tile(city_map_x, city_map_y)) {
/* Can't remove a worker here. */
 continue;
   }
   server_remove_worker_city(acity, city_map_x, city_map_y);

===

This is called often -- sanitycheck needs a thorough cleaning.  And all
these error messages need to be sent to the client.  Currently, there's no
easy way for them to be seen during the game.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#40086) 2.2-test: city center tiles not worked

2008-02-07 Thread Jason Dorje Short


URL: http://bugs.freeciv.org/Ticket/Display.html?id=40086 

On Feb 7, 2008 1:12 PM, William Allen Simpson
[EMAIL PROTECTED] wrote:

 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40086 

 In PR#40072, I've found a third error that only showed in the server log.
 Examination of the savegame data confirmed:

 2: Loading rulesets
 1: player1.c1.workers not working city center at Middelburg.
 1: player1.c5.workers not working city center at Tenochtitl?n.
 1: player2.c0.workers not working city center at Chiauhtia.

 After much testing, the savegame load can automatically correct this defect.
 Unfortunately, fixing this immediately results in the following message:

 1: Tile at Tenochtitl?n-49,11 (city center) marked as worked but occupied by 
 an enemy unit!

 This tells me that the reason that some city centers are not worked would be
 invasion.  But that should have been resolved already!?!?

So there's a bug where a city can be invaded but not change hands.
This is an impossible situation to begin with and needs to be tracked
down and fixed; trying to decide what should happen in such a
situation is only going to lead to headache.

 Here's a picture of my current test code display.  Apparently, these cities
 are captured as soon as the game is loaded.  Per's border algorithm doesn't
 update until the next turn, so border islands happen!

Correct; that always bugged me but it's not a cause of bugs (just very ugly).

 Worse, the arrange worker code should *NEVER* remove the worker at the city
 center!  Does anybody remember how/where this is done?  Or who wrote it?

Well there should *NEVER* be an enemy unit at the city center either,
nor should there *EVER* be an enemy-occupied tile that's being worked.
 But once once of these breaks a second one has to go too.

The CM code is in common/aicore/cm.c.

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] (PR#40012) 2.2-test assert in helpdata.c

2008-01-13 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=40012 

Errors from PR#39831, due to my incomplete implementation of buffer
concatenation length checking.

===

Date:   Sat, 12 Jan 2008 17:52:27 +0100
From:   Joan Creus [EMAIL PROTECTED]

...

The message is Assertion `len_destn' failed.

...

And, since we are at it, I think there is a \n missing at the end of
the string in line 1040 (after see Port Facility).

===

As noted for many years in the file itself:

   FIXME:
   All these helptext_* functions have a pretty crappy interface:
   we just write to buf and hope that its long enough.
   But I'm not going to fix it right now --dwp.

Indeed, almost all of the functions pass the buffer size, but fail to
check things during concatenation.

Worse, helptext_unit() doesn't pass the size at all!

Therefore, update helptext_unit() parameters to match helptext_building()
and the others.  Finish the partially complete checks for helptext_tech(),
helptext_terrain(), and helptext_government().

Ensure the buffers are always '\0' terminated, use strlcat().

Fix some missing translation qualifiers for comma lists, both bare
(?blistmore:, ) and c-format (?clistmore:, %s).

Fix a number of TRANS messages that were on the wrong line, and didn't
show up in the *.po files.

Fix several plural translations.

Index: client/gui-gtk-2.0/helpdlg.c
===
--- client/gui-gtk-2.0/helpdlg.c(revision 14228)
+++ client/gui-gtk-2.0/helpdlg.c(working copy)
@@ -818,7 +818,7 @@
 utype_name_translation(utype-obsoleted_by));
 }
 
-helptext_unit(buf, utype, pitem-text);
+helptext_unit(buf, sizeof(buf), utype, pitem-text);
 
 gtk_text_buffer_set_text(help_text, buf, -1);
 gtk_widget_show(help_text_sw);
Index: client/gui-xaw/helpdlg.c
===
--- client/gui-xaw/helpdlg.c(revision 14228)
+++ client/gui-xaw/helpdlg.c(working copy)
@@ -863,7 +863,7 @@
utype_name_translation(punittype-obsoleted_by));
 }
 /* add text for transport_capacity, fuel, and flags: */
-helptext_unit(buf, punittype, pitem-text);
+helptext_unit(buf, sizeof(buf), punittype, pitem-text);
 XtVaSetValues(help_text, XtNstring, buf, NULL);
   }
   else {
Index: client/gui-win32/helpdlg.c
===
--- client/gui-win32/helpdlg.c  (revision 14228)
+++ client/gui-win32/helpdlg.c  (working copy)
@@ -734,7 +734,7 @@
 utype_name_translation(utype-obsoleted_by));
 }
 
-helptext_unit(buf, utype, pitem-text);
+helptext_unit(buf, sizeof(buf), utype, pitem-text);
 set_help_text(buf);
   }
   else {
Index: client/gui-sdl/helpdlg.c
===
--- client/gui-sdl/helpdlg.c(revision 14228)
+++ client/gui-sdl/helpdlg.c(working copy)
@@ -837,7 +837,7 @@
   start_x = (area.x + 1 + scrollbar_width + 
pHelpDlg-pActiveWidgetList-size.w + adj_size(20));
 
   buffer[0] = '\0';
-  helptext_unit(buffer, utype_by_number(type_id), );
+  helptext_unit(buffer, sizeof(buffer), utype_by_number(type_id), );
   if (buffer[0] != '\0') {
 SDL_String16 *pStr = create_str16_from_char(buffer, adj_font(12));
 convert_string_to_const_surface_width(pStr, adj_size(640) - start_x - 
adj_size(20));
Index: client/helpdata.c
===
--- client/helpdata.c   (revision 14228)
+++ client/helpdata.c   (working copy)
@@ -44,6 +44,9 @@
 
 #include helpdata.h
 
+/* helper macro for easy conversion from snprintf and cat_snprintf */
+#define CATLSTR(_b, _s, _t) mystrlcat(_b, _t, _s)
+
 static const char * const help_type_names[] = {
   (Any), (Text), Units, Improvements, Wonders,
   Techs, Terrain, Governments, NULL
@@ -249,10 +252,9 @@
   /* FIXME: show other data like range and survives. */
 #define COREQ_APPEND(s)
\
   (coreq_buf[0] != '\0'
\
-   ? cat_snprintf(coreq_buf, sizeof(coreq_buf),, %s, (s))\
+   ? cat_snprintf(coreq_buf, sizeof(coreq_buf), Q_(?clistmore:, %s), (s))  \
: sz_strlcpy(coreq_buf, (s)))
 
-
   improvement_iterate(pimprove) {
 requirement_vector_iterate(pimprove-reqs, req) {
   if (are_universals_equal(psource, req-source)) {
@@ -628,15 +630,6 @@
 
 /
   FIXME:
-  All these helptext_* functions have a pretty crappy interface:
-  we just write to buf and hope that its long enough.
-  But I'm not going to fix it right now --dwp.
-  
-  Could also reduce amount/length of strlen's by inserting
-  a few 'buf += strlen(buf)'.
-
-  These functions should always ensure final buf is null-terminated.
-  
   Also, in principle these could be auto-generated

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-12-04 Thread Begasus


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 


On 2007-11-29 at 04:06:55 [+], William Allen Simpson 
[EMAIL PROTECTED] wrote:
 
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 
 
 Begasus wrote:
  Sending the diff file now I used to get the source of the 2.2 branch (yeah
  I know .. have these urges! ;) ) to compile in BeOS. Have used svn diff in
  ubuntu (after checking all compiles) to create the diff file. Maybe you
  could have a look at it.
  
 Please don't submit new patches to old resolved tickets.  Start a new 
 ticket,
 with a useful subject and explanations for each change.

My fault .. I didn't realize that mailing the patch as a reply to the emails 
I got from the ticked made it end up in the old resolved ticket.
Will create a new one ... 

Greetings 



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39947) 2.2-test more build errors with gcc 2.95.3

2007-12-04 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39947 

Jason Dorje Short wrote:
 Here's 2 separate patches for the 2 types of fixes.
 
Generally good patches, but partial revert of r14132 and r14133.

The original problem was the bad PR#34336 patch that inserted an if in
the middle of the initializers just before a comment.  Instead, use
conditional assignment.

Index: client/tilespec.c
===
--- client/tilespec.c   (revision 14135)
+++ client/tilespec.c   (working copy)
@@ -4208,28 +4208,24 @@
  const struct unit *punit, const struct city *pcity,
  const struct city *citymode)
 {
-  struct terrain *pterrain = NULL, *tterrain_near[8];
-  bv_special tspecial, tspecial_near[8];
   int tileno, dir;
+  bv_special tspecial;
+  bv_special tspecial_near[8];
+  struct terrain *tterrain_near[8];
+  struct terrain *pterrain = NULL;
   struct drawn_sprite *save_sprs = sprs;
   struct player *owner = NULL;
-  struct base_type *pbase = NULL;
-  bool do_draw_unit, solid_bg;
+  struct base_type *pbase = (ptile ? tile_get_base(ptile) : NULL);
+  /* Unit drawing is disabled when the view options are turned off,
+   * but only where we're drawing on the mapview. */
+  bool do_draw_unit = (punit  (draw_units || !ptile
+|| (draw_focus_unit
+ unit_is_in_focus(punit;
+  bool solid_bg = (solid_color_behind_units
+   (do_draw_unit
+  || (pcity  draw_cities)
+  || (ptile  !draw_terrain)));
 
-  if (ptile != NULL) {
-pbase = tile_get_base(ptile);
-  }
-
-  /* Unit drawing is disabled if the view options is turned off, but only
-   * if we're drawing on the mapview. */
-  do_draw_unit = (punit  (draw_units || !ptile
-   || (draw_focus_unit
-unit_is_in_focus(punit;
-  solid_bg = (solid_color_behind_units
-  (do_draw_unit
- || (pcity  draw_cities)
- || (ptile  !draw_terrain)));
-
   if (citymode) {
 int count = 0, i, cx, cy;
 const struct tile *const *tiles = NULL;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39947) 2.2-test more build errors with gcc 2.95.3

2007-12-04 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39947 

Committed S2_2 revision 14136.
Committed trunk revision 14137.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

William Allen Simpson wrote:
 For portability, we should re-write this section.
 
Damnit, was already re-written in 2.1, but not in 2.2/trunk.  As I've
said before, I really really really wish that folks fixing bugs in 2.1
would also fix them in 2.2/trunk

So, I fixed some reserved words in the macro parameters, too.

Committed S2_2 revision 14094.
Committed trunk revision 14095.

Index: server/settings.c
===
--- server/settings.c   (revision 14094)
+++ server/settings.c   (working copy)
@@ -195,28 +195,49 @@
   return TRUE;
 }
 
+
+//
+#if defined(HAVE_LIBBZ2)
+#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
+#define GAME_MAX_COMPRESS_TYPE FZ_BZIP2
+#define GAME_DEFAULT_COMPRESS_TYPE FZ_BZIP2
+
+#elif defined(HAVE_LIBZ)
+#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
+#define GAME_MAX_COMPRESS_TYPE FZ_ZLIB
+#define GAME_DEFAULT_COMPRESS_TYPE FZ_ZLIB
+
+#else
+#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
+#define GAME_MAX_COMPRESS_TYPE FZ_PLAIN
+#define GAME_DEFAULT_COMPRESS_TYPE FZ_PLAIN
+
+#endif
+
+//
+
 #define GEN_BOOL(name, value, sclass, scateg, slevel, to_client,   \
-short_help, extra_help, func, default) \
+short_help, extra_help, func, _default)\
   {name, sclass, to_client, short_help, extra_help, SSET_BOOL, \
-  scateg, slevel, value, default, func,   \
+  scateg, slevel, value, _default, func,  \
   NULL, 0, NULL, 0, 0, \
   NULL, NULL, NULL, 0},
 
 #define GEN_INT(name, value, sclass, scateg, slevel, to_client,
\
-   short_help, extra_help, func, min, max, default)\
+   short_help, extra_help, func, _min, _max, _default) \
   {name, sclass, to_client, short_help, extra_help, SSET_INT,  \
   scateg, slevel,  \
   NULL, FALSE, NULL,   \
-  value, default, func, min, max, \
+  value, _default, func, _min, _max,  \
   NULL, NULL, NULL, 0},
 
 #define GEN_STRING(name, value, sclass, scateg, slevel, to_client, \
-  short_help, extra_help, func, default)   \
+  short_help, extra_help, func, _default)  \
   {name, sclass, to_client, short_help, extra_help, SSET_STRING,   \
   scateg, slevel,  \
   NULL, FALSE, NULL,   \
   NULL, 0, NULL, 0, 0, \
-  value, default, func, sizeof(value)},
+  value, _default, func, sizeof(value)},
 
 #define GEN_END\
   {NULL, SSET_LAST, SSET_SERVER_ONLY, NULL, NULL, SSET_INT,\
@@ -976,7 +997,6 @@
  N_(If non-zero, saved games will be compressed using zlib 
 (gzip format) or bzip2. Larger values will give better 
 compression but take longer.), NULL,
-
  GAME_MIN_COMPRESS_LEVEL, GAME_MAX_COMPRESS_LEVEL,
  GAME_DEFAULT_COMPRESS_LEVEL)
 
@@ -988,13 +1008,8 @@
   1 - zlib (gzip format)\n
   2 - bzip2\n
  Not all servers support all compression methods.), NULL,
-#if !defined(HAVE_LIBBZ2)  !defined(HAVE_LIBZ)
-  FZ_PLAIN, FZ_PLAIN, FZ_PLAIN)
-#elif !defined(HAVE_LIBBZ2)  defined(HAVE_LIBZ)
-  FZ_PLAIN, FZ_ZLIB, FZ_ZLIB)
-#else
-  FZ_PLAIN, FZ_BZIP2, FZ_BZIP2)
-#endif
+ GAME_MIN_COMPRESS_TYPE, GAME_MAX_COMPRESS_TYPE,
+ GAME_DEFAULT_COMPRESS_TYPE)
 
   GEN_STRING(savename, game.save_name,
 SSET_META, SSET_INTERNAL, SSET_VITAL, SSET_SERVER_ONLY,
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread Jason Dorje Short


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

William Allen Simpson wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 
 
 William Allen Simpson wrote:
 For portability, we should re-write this section.

 Damnit, was already re-written in 2.1, but not in 2.2/trunk.  As I've
 said before, I really really really wish that folks fixing bugs in 2.1
 would also fix them in 2.2/trunk

On that topic, why do we have a 2.2 already?  Obviously bug fixes should 
go to it but it seems you are committing most patches to it and that 
just means it's a mirror of trunk.  It's been 2 years or something since 
the S2_1 branching so no doubt there is enough code to justify a S2_2 
but if we're going to do that we need to actually make it different from 
trunk.

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

Jason Dorje Short wrote:
 On that topic, why do we have a 2.2 already?  

You should, of course, re-read your messages circa Sep 12th.

I'd be happy to stop posting any patches at all to trunk, and use 2.2
as the development branch  It really is a waste of time doing
everything twice or three times.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread Jason Dorje Short


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

William Allen Simpson wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 
 
 Jason Dorje Short wrote:
 On that topic, why do we have a 2.2 already?  
 
 You should, of course, re-read your messages circa Sep 12th.

Negative.  RTFM is not an acceptable answer on this mailing list.  If 
you can give me a search term I'll be happy to peruse a specific thread. 
  But I suspect the 10 seconds it would take you to do that would be 
better spent giving a 10-second summary of the reason.

 I'd be happy to stop posting any patches at all to trunk, and use 2.2
 as the development branch  It really is a waste of time doing
 everything twice or three times.

That was, in fact, entirely my point.  Which is why I wonder why we have 
2.2 yet.

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread Daniel Markstedt


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

On 11/29/07, Jason Dorje Short [EMAIL PROTECTED] wrote:

 URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

 William Allen Simpson wrote:
  URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 
 
  Jason Dorje Short wrote:
  On that topic, why do we have a 2.2 already?
 
  You should, of course, re-read your messages circa Sep 12th.

 Negative.  RTFM is not an acceptable answer on this mailing list.  If
 you can give me a search term I'll be happy to peruse a specific thread.
   But I suspect the 10 seconds it would take you to do that would be
 better spent giving a 10-second summary of the reason.

  I'd be happy to stop posting any patches at all to trunk, and use 2.2
  as the development branch  It really is a waste of time doing
  everything twice or three times.

 That was, in fact, entirely my point.  Which is why I wonder why we have
 2.2 yet.

 -jason


PR#39690
PR#7294

 ~Daniel



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread Jason Dorje Short


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

Daniel Markstedt wrote:

 I'd be happy to stop posting any patches at all to trunk, and use 2.2
 as the development branch  It really is a waste of time doing
 everything twice or three times.
 That was, in fact, entirely my point.  Which is why I wonder why we have
 2.2 yet.

 
 PR#39690
 PR#7294

Interesting.

Just at a glance, then, my judgement would be that branching 2.2 at that 
time was a mistake.  If indeed the difference is as small as it seems 
(taking a look at that now) then I'd suggest merging 2.2 back into trunk 
(and reverting the embassy removal, saving that and other major rules 
changes for after 2.2).

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread Begasus


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

Hi peeps,

Didn't know you guys were paying that much attention (before I knew what 
went on there there was already a fix for the first problem). ;)

Sending the diff file now I used to get the source of the 2.2 branch (yeah 
I know .. have these urges! ;) ) to compile in BeOS. Have used svn diff in 
ubuntu (after checking all compiles) to create the diff file. Maybe you 
could have a look at it.

In regards to the compiler ... there is a 3.4 one but that isn't complete 
and not all links to the correct places ... will take quit some work 
(although it has been done) to get it setup right. The 2.95.3 one is at 
this point still the safest way to go in BeOS.

Greetings and thnx for putting the previous fixes in. 

Luc Schrijvers aka Begasus
[EMAIL PROTECTED]:~/freeciv2.2$ svn diff
Index: server/cityturn.c
===
--- server/cityturn.c   (revision 14099)
+++ server/cityturn.c   (working copy)
@@ -638,7 +638,7 @@
   if (valid_improvement(choice.value.building)) {
 struct universal target = {
   .kind = VUT_IMPROVEMENT,
-  .value.building = choice.value.building
+  .value = {.building = choice.value.building}
 };
 
 change_build_target(pplayer, pcity, target, E_IMP_AUTO);
@@ -651,7 +651,7 @@
 !building_has_effect(pimprove, EFT_CAPITAL_CITY)) {
   struct universal target = {
 .kind = VUT_IMPROVEMENT,
-.value.building = pimprove
+.value = {.building = pimprove}
   };
 
   change_build_target(pplayer, pcity, target, E_IMP_AUTO);
Index: server/savegame.c
===
--- server/savegame.c   (revision 14099)
+++ server/savegame.c   (working copy)
@@ -3001,6 +3001,7 @@
   i = -1;
   unit_list_iterate(plr-units, punit) {
 i++;
+{
 int activity;
 
 secfile_insert_int(file, punit-id, player%d.u%d.id, plrno, i);
@@ -3456,6 +3457,7 @@
 #undef PART_ADJUST
 #undef PART_SIZE
 }
+}
 
 
 /***
Index: common/effects.c
===
--- common/effects.c(revision 14099)
+++ common/effects.c(working copy)
@@ -539,7 +539,7 @@
   struct universal source = {
 .kind = VUT_IMPROVEMENT,
 /* just to bamboozle the annoying compiler warning */
-.value.building = improvement_by_number(improvement_number(pimprove))
+.value = {.building = improvement_by_number(improvement_number(pimprove))}
   };
   struct effect_list *plist = get_req_source_effects(source);
 
@@ -694,7 +694,7 @@
   struct effect_list *plist;
   struct universal source = {
 .kind = VUT_IMPROVEMENT,
-.value.building = pimprove
+.value = {.building = pimprove}
   };
 
   /* A capitalization production is never redundant. */
@@ -1011,7 +1011,7 @@
 struct impr_type *building = pcity-production.value.building;
 struct universal source = {
   .kind = VUT_IMPROVEMENT,
-  .value.building = building
+  .value = {.building = building}
 };
 struct effect_list *plist = get_req_source_effects(source);
 int power = 0;
Index: ai/aicity.c
===
--- ai/aicity.c (revision 14099)
+++ ai/aicity.c (working copy)
@@ -793,7 +793,7 @@
   struct government *gov = government_of_player(pplayer);
   struct universal source = {
 .kind = VUT_IMPROVEMENT,
-.value.building = pimprove
+.value = {.building = pimprove}
   };
   const bool is_coinage = improvement_has_flag(pimprove, IF_GOLD);
 
Index: ai/aidata.c
===
--- ai/aidata.c (revision 14099)
+++ ai/aidata.c (working copy)
@@ -66,7 +66,7 @@
   improvement_iterate(pimprove) {
 struct universal source = {
   .kind = VUT_IMPROVEMENT,
-  .value.building = pimprove
+  .value = {.building = pimprove}
 };
 
 ai-impr_calc[improvement_index(pimprove)] = AI_IMPR_ESTIMATE;
Index: client/helpdata.c
===
--- client/helpdata.c   (revision 14099)
+++ client/helpdata.c   (working copy)
@@ -657,7 +657,7 @@
 {
   struct universal source = {
 .kind = VUT_IMPROVEMENT,
-.value.building = pimprove
+.value = {.building = pimprove}
   };
 
   assert(buf);
@@ -1084,7 +1084,7 @@
   struct advance *vap = valid_advance_by_number(i);
   struct universal source = {
 .kind = VUT_ADVANCE,
-.value.advance = vap
+.value = {.advance = vap}
   };
 
   assert(bufuser_text);
@@ -1173,7 +1173,7 @@
 {
   struct universal source = {
 .kind = VUT_TERRAIN,
-.value.terrain = pterrain
+.value = {.terrain = pterrain}
   };
   buf[0] = '\0';
   
@@ -1229,7 +1229,7 @@
 {
   struct universal source = {
 .kind = VUT_GOVERNMENT,
-.value.govern = gov
+.value = {.govern = gov}
   };
 
   buf[0] = '\0';

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

Begasus wrote:
 Sending the diff file now I used to get the source of the 2.2 branch (yeah 
 I know .. have these urges! ;) ) to compile in BeOS. Have used svn diff in 
 ubuntu (after checking all compiles) to create the diff file. Maybe you 
 could have a look at it.
 
Please don't submit new patches to old resolved tickets.  Start a new ticket,
with a useful subject and explanations for each change.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread William Allen Simpson


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

Jason Dorje Short wrote:
 ...  I'd suggest merging 2.2 back into trunk
 (and reverting the embassy removal, saving that and other major rules 
 changes for after 2.2).
 
For a guy that's been around so long, you don't seem to understand
subversion very well  It's been branched.  Just as 2.1, it's probably
premature.  But there's no going back.

And let's stop using an old resolved and completely irrelevant ticket for
this discussion.



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Re: [Freeciv-Dev] (PR#39926) 2.2-test build error in settings.c with gcc 2.95.3

2007-11-28 Thread Jason Dorje Short


URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 

William Allen Simpson wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=39926 
 
 Jason Dorje Short wrote:
 ...  I'd suggest merging 2.2 back into trunk
 (and reverting the embassy removal, saving that and other major rules 
 changes for after 2.2).

 For a guy that's been around so long, you don't seem to understand
 subversion very well  It's been branched.  Just as 2.1, it's probably
 premature.  But there's no going back.

That was the case with CVS but shouldn't be a problem for SVN.  svn rm 
svn+ssh://[EMAIL PROTECTED]/svn/freeciv/branches/S2_2 should do the 
trick though I believe that is an immediate operation.

 And let's stop using an old resolved and completely irrelevant ticket for
 this discussion.

All the other discussions were in irrelevant tickets too.  But I agree, 
we should have an actual thread for this discussion.

-jason



___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] this is a test

2007-02-08 Thread Per Inge Mathisen


I just want to see what happens if I try to email this list from the
outside. - Per

___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

40 matches

Mail list logo