[Freeciv-Dev] [bug #18993] Bug in swiss.ruleset?
Follow-up Comment #2, bug #18993 (project freeciv): Huh, I didn't know that. Anyway, I created a list of nations: http://longturn.org/nations/ and it seems every nation except the Swiss have the same name in the ruleset as is the filename of the flag. ___ Reply to this item at: http://gna.org/bugs/?18993 ___ 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 #18653] Upper case first letter of player name
Follow-up Comment #5, bug #18653 (project freeciv): I really feel strongly that the current behaviour is bad, and should be reverted. A new reason is: I dump statistics to a database. The database does not have a user 'Akfaew', but 'akfaew'. I can use nickname, which remains 'akfaew', but won't it change during delegation, to the controling player? ___ Reply to this item at: http://gna.org/bugs/?18653 ___ 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 #19005] calloc can overflow
URL: http://gna.org/bugs/?19005 Summary: calloc can overflow Project: Freeciv Submitted by: akfaew Submitted on: Wed Nov 16 08:54:10 2011 Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_3 Discussion Lock: Any Operating System: None Planned Release: ___ Details: fc_real_calloc states: size_t size = nelem*elsize; /* potential overflow */ A check for potential overflow is the only reason calloc was created in the first place (at least I think that was the case). Here is how OpenBSD does it: /usr/src/lib/libc/stdlib/malloc.c:1383: if ((nmemb = MUL_NO_OVERFLOW || size = MUL_NO_OVERFLOW) /usr/src/lib/libc/stdlib/malloc.c:1384: nmemb 0 SIZE_MAX / nmemb size) { /usr/src/lib/libc/stdlib/malloc.c:1385: _MALLOC_UNLOCK(); /usr/src/lib/libc/stdlib/malloc.c:1386: if (mopts.malloc_xmalloc) /usr/src/lib/libc/stdlib/malloc.c:1387: wrterror(out of memory, NULL); /usr/src/lib/libc/stdlib/malloc.c:1388: errno = ENOMEM; /usr/src/lib/libc/stdlib/malloc.c:1389: return NULL; /usr/src/lib/libc/stdlib/malloc.c:1390: } The attached patch ports this behaviour. It is untested. ___ File Attachments: --- Date: Wed Nov 16 08:54:10 2011 Name: calloc.diff Size: 2kB By: akfaew http://gna.org/bugs/download.php?file_id=14562 ___ Reply to this item at: http://gna.org/bugs/?19005 ___ 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 #18776] /remove perhaps faulty
Follow-up Comment #21, bug #18776 (project freeciv): It does not crash. And i tested it without your previous patches, the ones with vision - while they might have fixed something they were not the cause of my segfaults. Still, could you help me understand: 1u (p - l * 8), which really means 1u (p - p / 4), which is of course 1u (0.75 * p). For 126 players, you cannot shift 1 by 94 bits left! ___ Reply to this item at: http://gna.org/bugs/?18776 ___ 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 #18758] status popup in the way of path
Follow-up Comment #1, bug #18758 (project freeciv): I agree, this sometimes is an annoyance, and I also scroll the map in such ways as to display the popup on the other side of the cursor. A slight transparency would be nice, if GTK supports it. Or perhaps display the info on the left, below the 'Turn done' button? ___ Reply to this item at: http://gna.org/bugs/?18758 ___ 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 #18742] Turn change resets event cache?
Follow-up Comment #2, bug #18742 (project freeciv): Sorry, I forgot to answer to this - I really though I did. Thank you Jacob, indeed my ec_ options were the problem. I set: set ec_turns=9 set ec_max_size=1000 set ec_chat=enabled set ec_info=enabled Why are these values not the default? Event cache does not consume that much memory, when compared to the map, does it? Why are these values limited to 9 and 1000? Sometimes i browse thru the event cache to determine when my enemy is most likely to log in. ___ Reply to this item at: http://gna.org/bugs/?18742 ___ 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] Donate to FreeCiv
Hi there, My name is Peter Ross and I am writing from Flattr, the micro-payments system. I was getting in touch as I noticed that you have a Flattr account but it is registered to a site with an expired URL. Would you be interested in putting a link to your Flattr account on the donate page of your Wikia page? Thanks, Peter. Peter Ross Flattr - social micropayments www.flattr.com @Peterro55 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #18776] /remove perhaps faulty
Follow-up Comment #22, bug #18776 (project freeciv): I removed half the players in LTeX (idlers). The memory usage dropped by about half. I saved the game then restarted the server, and a turn was made - everything is ok. ___ Reply to this item at: http://gna.org/bugs/?18776 ___ 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 #19006] Add a lua_blacklist setting
URL: http://gna.org/bugs/?19006 Summary: Add a lua_blacklist setting Project: Freeciv Submitted by: akfaew Submitted on: Wed Nov 16 18:43:29 2011 Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_3 Discussion Lock: Any Operating System: None Planned Release: ___ Details: I want to be able to dofile! :) This diff is made against S2_3. ___ File Attachments: --- Date: Wed Nov 16 18:43:29 2011 Name: lua_blacklist.diff Size: 2kB By: akfaew http://gna.org/bugs/download.php?file_id=14564 ___ Reply to this item at: http://gna.org/bugs/?19006 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Moving Longturn patches to Lua
On Tue, Nov 15, 2011 at 09:48:07PM +0100, Matthias Pfafferodt wrote: The hardest part is the transmission of the veteran ruleset definitions (IMHO). Speaking of veterans, while looking at freecivs png files i noticed there are four more veteran levels graphics. Did freeciv use to have 8 veteran levels? -- Michal Mazurek ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3056] Requirement vector for roads
Update of patch #3056 (project freeciv): Status:None = Ready For Test ___ Reply to this item at: http://gna.org/patch/?3056 ___ 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 #19005] calloc can overflow
Follow-up Comment #1, bug #19005 (project freeciv): I'm not familiar with the memory management but you should also add the checks in line 1384 1385 to the patch. Else it will not help at all ... ___ Reply to this item at: http://gna.org/bugs/?19005 ___ 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] [bug #19007] fix known map in savegame2
URL: http://gna.org/bugs/?19007 Summary: fix known map in savegame2 Project: Freeciv Submitted by: syntron Submitted on: Mi 16 Nov 2011 21:39:30 CET Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: syntron Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.3.1,2.4.0,2.5.0 ___ Details: do not use the player_count() but the highest used player slot index (see also bug #18776) reported and analysed by Michal Mazurek akfaew patch by me see gna bug #18776 ___ File Attachments: --- Date: Mi 16 Nov 2011 21:39:30 CET Name: 0011-fix-known-map-in-savegame2.patch Size: 3kB By: syntron http://gna.org/bugs/download.php?file_id=14565 ___ Reply to this item at: http://gna.org/bugs/?19007 ___ 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] [bug #18776] /remove perhaps faulty
Follow-up Comment #23, bug #18776 (project freeciv): I removed half the players in LTeX (idlers). The memory usage dropped by about half. I saved the game then restarted the server, and a turn was made - everything is ok. So the last patch fixed it? If this is the case, should both patches be applied to 2.3.1 before it is released on the weekend? I added file #14560 as bug #19007. Memory saving is mostly due to the freed private/known maps ... Still, could you help me understand: 1u (p - l * 8), which really means 1u (p - p / 4), which is of course 1u (0.75 * p). For 126 players, you cannot shift 1 by 94 bits left! I will try - if it is wrong please correct me! lines is (now) calculated as the number of int values needed to save the known information of each tile, i.e (max used player index / 32 + 1). example: max used player index = 60 = 60/32 + 1 = 1 + 1 = 2 Now the player information has to be saved in the int values. It is done such, that in int 1, information for player 0 .. 31 is saved, int 2 takes player 32 to 63 etc. Calculating the bit index within the int is done using the following equation: [bit] = p - l * 8 with p = (player index) and l = p / 32; as l is an int the last equation is equal to l = floor(p/32), i.e. round down. Thus, the equation reads [bit] = p - floor(p/32) * 8 which limits it to values between 0 and 31. l is also used to select the correct int value in the calucaltion of the index for the bitvector known (lines 2836-2837 in savegame2.c of trunk): known[l * MAP_INDEX_SIZE + tile_index(ptile)] |= (1u (p - l * 8)); ___ Reply to this item at: http://gna.org/bugs/?18776 ___ 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] Diplomatic ZOC
With longturns 3x movement it's hard to defend against spies. Would changes to the client be required if spies had diplomatic ZOC, that would only affect other spies? -- Michal Mazurek ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #18742] Turn change resets event cache?
Follow-up Comment #3, bug #18742 (project freeciv): Why are these values limited to 9 and 1000? Sometimes i browse thru the event cache to determine when my enemy is most likely to log in. As this are arbitrary values something had to be defined at the time the corresponding patches were written. At that time, no one had such big games. The values can easily be updated. Perhaps you could create a patch, which updates the default to something like 5 and also updates the max values (20 turns / 1 messages?). All values are defined in game.h. ___ Reply to this item at: http://gna.org/bugs/?18742 ___ 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] [bug #19005] calloc can overflow
Follow-up Comment #2, bug #19005 (project freeciv): fc_real_malloc will handle that, it calls sanity_check_size. Calloc only cares about overflow. The SIZE_MAX part is redundant I think, it is equivalent to SIZE_MAX nmemb * size. It can be important on some strange platforms, but on both Intel and sparc processors max adressable memory is equal to what size_t can contain. OpenBSD supports various strange architectures. I might be mistaken though. #define SIZE_MAXUINTPTR_MAX /usr/include/stdint.h:155: #ifdef __LP64__ /usr/include/stdint.h:156: #define INTPTR_MIN INT64_MIN /usr/include/stdint.h:157: #define INTPTR_MAX INT64_MAX /usr/include/stdint.h:158: #define UINTPTR_MAX UINT64_MAX /usr/include/stdint.h:159: #else /usr/include/stdint.h:160: #define INTPTR_MIN INT32_MIN /usr/include/stdint.h:161: #define INTPTR_MAX INT32_MAX /usr/include/stdint.h:162: #define UINTPTR_MAX UINT32_MAX /usr/include/stdint.h:163: #endif so size_t * size_t will never be greater than SIZE_MAX on a PC. ___ Reply to this item at: http://gna.org/bugs/?19005 ___ 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 #3058] optimise time needed to creating a savegame
URL: http://gna.org/patch/?3058 Summary: optimise time needed to creating a savegame Project: Freeciv Submitted by: syntron Submitted on: Mi 16 Nov 2011 22:28:24 CET Category: general Priority: 3 - Low Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: from a message to the developer list (mail by Michal Mazurek): My sparc64 502mhz is taking 4 minutes now to /save a game. I tried poor mans optimization and inlined a couple of functions. I tested it on a 8x3400mhz intel i7. The test .serv was loading the game, and saving it 10 times. I managed to only go down to 11.76 from 13.56 seconds, that's not very much. Most of the time is spent doing real stuff, so i guess 500mhz is not adequate to run games with max map. About 5 seconds of that time is just starting the server and loading the map. The function tile_index is called 495681563 times, I cant see how this can be cut down. sg_save_player_vision is called 370 times and takes most time, 12%. But it seems to be doing real stuff, also hard to cut down. And even if it is cut down, it's still only 12%. A decent computer saves the game rather fast, so I just guess my computer is just too old to run longturn games. One thing to speed up saving a game would be a better handling of the saving each part of the map. In sg_save_player_vision() the macro SAVE_MAP_CHAR is called several times. Each (!) time it iterates over all tiles (= get tile from x, y coordinates) and saves only one part of the vision map definition (terrain, resources, (owner), specials, bases, update time). If this could be changed to one loop it would help. Similar optimisation could be done for sg_save_map_known(); perhaps even all in one loop? (loop 1: y = lines; inner loop: x values; each part to be saved). However, I think that inlining functions like: int player_slot_count(void) { return (MAX_NUM_PLAYER_SLOTS); } would actually not only be faster, but also take less space. I not sure that the rules are for inlining functions. In coding style only the use of inline functions instead of macros is stated. ___ Reply to this item at: http://gna.org/patch/?3058 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Optimizing /save (I failed)
Am Dienstag, 15. November 2011, 23:55:42 schrieb Michal Mazurek: My sparc64 502mhz is taking 4 minutes now to /save a game. I tried poor mans optimization and inlined a couple of functions. I tested it on a 8x3400mhz intel i7. The test .serv was loading the game, and saving it 10 times. I managed to only go down to 11.76 from 13.56 seconds, that's not very much. Most of the time is spent doing real stuff, so i guess 500mhz is not adequate to run games with max map. About 5 seconds of that time is just starting the server and loading the map. The function tile_index is called 495681563 times, I cant see how this can be cut down. sg_save_player_vision is called 370 times and takes most time, 12%. But it seems to be doing real stuff, also hard to cut down. And even if it is cut down, it's still only 12%. A decent computer saves the game rather fast, so I just guess my computer is just too old to run longturn games. One thing to speed up saving a game would be a better handling of the saving each part of the map. In sg_save_player_vision() the macro SAVE_MAP_CHAR is called several times. Each (!) time it iterates over all tiles (= get tile from x, y coordinates) and saves only one part of the vision map definition (terrain, resources, (owner), specials, bases, update time). If this could be changed to one loop it would help. Similar optimisation could be done for sg_save_map_known(); perhaps even all in one loop? (loop 1: y = lines; inner loop: x values; each part to be saved). However, I think that inlining functions like: int player_slot_count(void) { return (MAX_NUM_PLAYER_SLOTS); } would actually not only be faster, but also take less space. I not sure that the rules are for inlining functions. In coding style only the use of inline functions instead of macros is stated. I posted this as gna patch (request) #3058 (https://gna.org/patch/index.php? 3058). ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Moving Longturn patches to Lua
Am Mittwoch, 16. November 2011, 19:47:45 schrieb Michal Mazurek: On Tue, Nov 15, 2011 at 09:48:07PM +0100, Matthias Pfafferodt wrote: The hardest part is the transmission of the veteran ruleset definitions (IMHO). Speaking of veterans, while looking at freecivs png files i noticed there are four more veteran levels graphics. Did freeciv use to have 8 veteran levels? Freeciv 2.3 supports up to 10 veteran levels but only 4 are used; in 2.4 this will be increased to 20 levels which can be different for different units. See the experimental ruleset for an example (settlers). ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Moving Longturn patches to Lua
Am Dienstag, 15. November 2011, 22:24:29 schrieb Marko Lindqvist: On 15 November 2011 22:48, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: If you plan to continue to support S2_3, I think it would be easier to rebase all longturn patches to S2_4 and do one patch which changes the network protocol to be compatible to S2_3. ... I attached a file with the diff between S2_3 and S2_4 for packets.def. Most of the work to be done is to remove S2_4 features. The hardest part is the transmission of the veteran ruleset definitions (IMHO). Please note that there's more to network compatibility than packets.def changes. While it lists all the packet fields there is in the network protocol, legal ranges of those values can change outside it, and even meaning of any single value (for example when value is removed from the middle of enum) can change. You are right. All the other things also have to be compared / checked. Yesterday evening I did create such a hack. The client 2.3 can connect but there are still some bugs as settlers can't build cities ... From 45f5bc822f9e52c5943eb2ccd67be315dbc21e6b Mon Sep 17 00:00:00 2001 From: Matthias Pfafferodt g...@mapfa.de Date: Tue, 15 Nov 2011 23:30:19 +0100 Subject: [PATCH 1/2] use S2_3 protocol by S2_4 server (longturn) --- common/citizens.c | 10 +++--- common/game.h |3 +- common/map.h |6 +--- common/packets.def| 70 ++-- common/requirements.c | 22 --- common/requirements.h | 22 +++ common/unit.c |7 - fc_version|4 +- server/citizenshand.c |4 +- server/citytools.c| 18 server/cityturn.c |6 ++-- server/edithand.c |5 --- server/gamehand.c |7 +++-- server/maphand.c | 15 -- server/plrhand.c | 13 + server/ruleset.c | 58 +++- server/savegame2.c|8 +++--- server/srv_main.c |6 +--- server/unittools.c|4 +-- 19 files changed, 86 insertions(+), 202 deletions(-) diff --git a/common/citizens.c b/common/citizens.c index f54c50f..5397412 100644 --- a/common/citizens.c +++ b/common/citizens.c @@ -32,7 +32,7 @@ void citizens_init(struct city *pcity) { fc_assert_ret(pcity); - if (game.info.citizen_nationality != TRUE) { + if (TRUE) { return; } @@ -73,7 +73,7 @@ void citizens_free(struct city *pcity) citizens citizens_nation_get(const struct city *pcity, const struct player_slot *pslot) { - if (game.info.citizen_nationality != TRUE) { + if (TRUE) { return 0; } @@ -105,7 +105,7 @@ void citizens_nation_add(struct city *pcity, const struct player_slot *pslot, { citizens nationality = citizens_nation_get(pcity, pslot); - if (game.info.citizen_nationality != TRUE) { + if (TRUE) { return; } @@ -144,7 +144,7 @@ void citizens_nation_move(struct city *pcity, void citizens_nation_set(struct city *pcity, const struct player_slot *pslot, citizens count) { - if (game.info.citizen_nationality != TRUE) { + if (TRUE) { return; } @@ -163,7 +163,7 @@ citizens citizens_count(const struct city *pcity) /* Use int here to check for an possible overflow at the end. */ int count = 0; - if (game.info.citizen_nationality != TRUE) { + if (TRUE) { return city_size_get(pcity); } diff --git a/common/game.h b/common/game.h index 5a30ca9..316ed93 100644 --- a/common/game.h +++ b/common/game.h @@ -158,6 +158,7 @@ struct civ_game { int unitwaittime; /* minimal time between two movements of a unit */ int upgrade_veteran_loss; bool vision_reveal_tiles; + int base_bribe_cost; bool debug[DEBUG_LAST]; int timeoutint; /* increase timeout every N turns... */ @@ -570,7 +571,7 @@ extern struct civ_game game; #define GAME_UNIT_BRIBE_DIST_MAX 32 /* Max number of recursive transports. */ -#define GAME_TRANSPORT_MAX_RECURSIVE 5 +#define GAME_TRANSPORT_MAX_RECURSIVE 1 /* ruleset settings */ diff --git a/common/map.h b/common/map.h index 9e70dee..35fe7a4 100644 --- a/common/map.h +++ b/common/map.h @@ -574,7 +574,7 @@ extern const int DIR_DY[8]; * below. */ #define MAP_DEFAULT_SIZE 4 #define MAP_MIN_SIZE 0 -#define MAP_MAX_SIZE 2048 +#define MAP_MAX_SIZE 128 FC_STATIC_ASSERT(MAP_MAX_SIZE * 1000 = MAX_DBV_LENGTH, map_too_big_for_bitvector); @@ -585,9 +585,7 @@ FC_STATIC_ASSERT(MAP_MAX_SIZE * 1000 = MAX_DBV_LENGTH, /* This defines the maximum linear size in _map_ coordinates. */ #define MAP_DEFAULT_LINEAR_SIZE 64 -/* 32 * 1024 is 2^15; thus, x*y is = 2^15 * 2^15 = 2^30. This can be - * represented by an signed int as required by the network protocol. */ -#define MAP_MAX_LINEAR_SIZE (32 * 1024) +#define MAP_MAX_LINEAR_SIZE 512
[Freeciv-Dev] [bug #18776] /remove perhaps faulty
Follow-up Comment #24, bug #18776 (project freeciv): [bit] = p - floor(p/32) * 8 which limits it to values between 0 and 31. Does it? p - player index in 0..127. let p = 127. p - floor(p/32) * 8 = 127 - 3 * 8 = 103. I run just this part in a test c program. This is really weird. #include stdio.h int main() { int a; for (a = 0; a 128; a++) { int l = a / 32; printf(%xn, 1u (a - l * 8)); } return 0; } I didn't restart a game with 32 players, with a player with an index 32 being not an idler. The Finns didn't respond to me on irc, if they restarted their server or not. But something tells me this code will do strange things if there are more than 32 players (I still dont understand it). Why isn't that 1 just shifted by p % 32? ___ Reply to this item at: http://gna.org/bugs/?18776 ___ 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 #18975] in unit_virtual_destroy() [unit.c::1732]: assertion '!unit_transported(punit)' failed.
Follow-up Comment #2, bug #18975 (project freeciv): Confirm that trunk r20575 with this patch quits quieter than without, thanks. (Didn't try S2_4.) ___ Reply to this item at: http://gna.org/bugs/?18975 ___ 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 #18835] Make many diplomacy dialogs easier to manage (e.g. using vertical tabs)
Follow-up Comment #39, bug #18835 (project freeciv): Can't break it now; thanks. ___ Reply to this item at: http://gna.org/bugs/?18835 ___ 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 #18776] /remove perhaps faulty
Follow-up Comment #25, bug #18776 (project freeciv): Why isn't that 1 just shifted by p % 32? I do not know! I did take the code from the old version, (tried to) understand it and used it in savegame2.c - and it did work! As you say, this seems to be at least strange ... ___ Reply to this item at: http://gna.org/bugs/?18776 ___ 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] [bug #18872] Freeciv gives warnings with clang toolchain
Update of bug #18872 (project freeciv): Category:None = bootstrap Status:None = In Progress ___ Follow-up Comment #9: Somewhat related to this ticket: I just installed clang for myself and have been testing various freeciv compilations with it. So far I've been testing with trunk and S2_4 only, but may look at S2_3 issues at some point. To sum: Freeciv compiles, but with numerous warnings. I will need to make changes both to configure stuff (adjust setting of compiler flags) and code changes (warnings that indicate problems) In general I will not target to warningless clang build in S2_3 as some changes may have potential to break other currently working builds, but any real bugs found by clang diagnostic should be fixed in S2_3 too. ___ Reply to this item at: http://gna.org/bugs/?18872 ___ 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 #18835] Make many diplomacy dialogs easier to manage (e.g. using vertical tabs)
Follow-up Comment #40, bug #18835 (project freeciv): Can't break it now; thanks. OK; this will be commited as soon as 2.3.1 is released ___ Reply to this item at: http://gna.org/bugs/?18835 ___ 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] [bug #18481] lua-5.1, ldebug.c compilation failure
Follow-up Comment #9, bug #18481 (project freeciv): Could you report lua compile problem directly to lua project also? Is that problem somehow solved in system lua of your OS (assuming it ships with one)? Has anybody been in contact with lua folks? This really should be fixed in upstream and not only in our own copy (and over and over again every time we update it) I get similar error with clang on x86_64 Debian Wheezy with clang packet from Sid (as there's not yet one in Wheezy). Full clang error output looks like: CC ldebug.o ../../../../../src.patched/dependencies/lua-5.1/src/ldebug.c:620:21: error: cast from 'char *' to 'TValue *' (aka 'struct lua_TValue *') increases required alignment from 1 to 8 [-Werror,-Wcast-align] StkId errfunc = restorestack(L, L-errfunc); ^~~ In file included from ../../../../../src.patched/dependencies/lua-5.1/src/ldebug.c:21: ../../../../../src.patched/dependencies/lua-5.1/src/ldo.h:25:28: note: instantiated from: #define restorestack(L,n) ((TValue *)((char *)L-stack + (n))) ^~ 1 error generated. make[4]: *** [ldebug.o] Error 1 ___ Reply to this item at: http://gna.org/bugs/?18481 ___ 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 #19008] Compiler flag löegality checking ignores existing flags
URL: http://gna.org/bugs/?19008 Summary: Compiler flag löegality checking ignores existing flags Project: Freeciv Submitted by: cazfi Submitted on: Thu 17 Nov 2011 01:39:39 AM EET 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: 2.2.8, 2.3.1, 2.4.0, 2.5.0 ___ Details: compiler.m4 flag checking macros do not check if proposed flag works together with flags already in target variable. One could argue (as I did until now) that there's no bug in that. Those macros have never been advertised as having such check, and they take optional parameter for extra flags where use can pass existing flags if so wishes. I now decided to make this a bug (instead of patch ticket) since it's hard to imagine a case where check with existing flags is not wanted - since they go to the same variable, user is certainly going to use them together, and passing existing values in extra flags parameter is cumbersome. In fact, existing code never does pass existing flags, though every place should. Attached fix makes those macros to make checks with existing flags in target variable set. It's worth noting that with this we avoid some clang debug build problems. It's partly coincidence since this is not targeted against bug in question as a whole, but this helps to avoid specific problem making clang build to fail (namely compiler flag checking uses -Werror in critical check) ___ File Attachments: --- Date: Thu 17 Nov 2011 01:39:39 AM EET Name: FlagCheckExistingFlags.diff Size: 923B By: cazfi http://gna.org/bugs/download.php?file_id=14566 ___ Reply to this item at: http://gna.org/bugs/?19008 ___ 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 #19008] Compiler flag legality checking ignores existing flags
Update of bug #19008 (project freeciv): Summary: Compiler flag löegality checking ignores existing flags = Compiler flag legality checking ignores existing flags ___ Reply to this item at: http://gna.org/bugs/?19008 ___ 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 #3042] Automatically select gtk3-client as one to build
Update of patch #3042 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3042 ___ 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 #19009] gtk3-client does not show what city is building
URL: http://gna.org/bugs/?19009 Summary: gtk3-client does not show what city is building Project: Freeciv Submitted by: cazfi Submitted on: Thu 17 Nov 2011 03:20:43 AM EET Category: client-gtk-3.0 Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: In city dialog overview-tab current production is not shown in gtk3-client. In gtk2-client it reads in production progress bar. ___ Reply to this item at: http://gna.org/bugs/?19009 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev