Re: [Freeciv-Dev] (PR#40250) autoconf fails on a recent S2_1 checkout
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40250 2008/5/24 Daniel Markstedt: $subject OSX 10.3.9 ibg3:~/freeciv-2.1 daniel$ ./autogen.sh + checking for autoconf = 2.55 ... found 2.57, ok.+ checking for autoheader = 2.55 ... found 2.57, ok. + checking for automake = 1.6 ... found 1.6.3, ok. + checking for aclocal = 1.6 ... found 1.6.3, ok. I try to setup autoconf 2.57 + automake 1.6.3 environment for myself. This seems to be either problem with those versions or your local problem. Has anybody else reproduced this? + checking for xgettext = 0.10.36 ... found 0.14.5, ok. + checking for msgfmt = 0.10.36 ... found 0.14.5, ok. + running aclocal ... + running autoheader ... + running autoconf ... configure.ac:62: error: possibly undefined macro: AC_MSG_ERROR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:204: error: possibly undefined macro: AC_CHECK_LIB configure.ac:381: error: possibly undefined macro: AC_CHECK_HEADER autoconf failed Are m4_includes produced correctly to the end of aclocal.m4: m4_include([m4/auth.m4]) m4_include([m4/c99.m4]) m4_include([m4/compiler.m4]) m4_include([m4/debug.m4]) m4_include([m4/freetype2.m4]) m4_include([m4/gettimeofday.m4]) m4_include([m4/ggz.m4]) m4_include([m4/glib-gettext.m4]) m4_include([m4/gtk-2.0.m4]) m4_include([m4/gtk2-client.m4]) m4_include([m4/iconv.m4]) m4_include([m4/locale.m4]) m4_include([m4/ngettext.m4]) m4_include([m4/no-client.m4]) m4_include([m4/pkg.m4]) m4_include([m4/readline.m4]) m4_include([m4/sdl-client.m4]) m4_include([m4/sdl.m4]) m4_include([m4/sound.m4]) m4_include([m4/vsnprintf.m4]) m4_include([m4/win32-client.m4]) m4_include([m4/x.m4]) m4_include([m4/xaw-client.m4]) - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40265) [Patch] Goto compiler warning fix
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40265 This fixes compiler warning produced on optimization level O2 (when several functions are inlined to one). - ML diff -Nurd -X.diff_ignore freeciv/client/goto.c freeciv/client/goto.c --- freeciv/client/goto.c 2008-04-25 03:29:36.0 +0300 +++ freeciv/client/goto.c 2008-06-11 13:32:31.0 +0300 @@ -1213,6 +1213,14 @@ struct unit_order order; order.order = goto_last_order; + order.dir = -1; + order.activity = ACTIVITY_LAST; + + /* ORDER_MOVE would require real direction, + * ORDER_ACTIVITY would require real activity */ + assert(goto_last_order != ORDER_MOVE + goto_last_order != ORDER_ACTIVITY); + send_goto_path(punit, path, order); } pf_destroy_path(path); ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40184) [editor] Request to merge new editor gui
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 I only read sources, not yet tested. - Please don't add new empty function headers. New code should have function headers already when committed. - You add function client_player(), but don't always use it in new code instead of client.conn.playing What really happens to these files: --- a/client/gui-gtk-2.0/Makefile.am +++ b/client/gui-gtk-2.0/Makefile.am @@ -42,8 +42,10 @@ libguiclient_a_SOURCES = \ dialogs.h \ diplodlg.c \ diplodlg.h \ - editdlg.c \ - editdlg.h \ + editgui.c \ + editgui.h \ + editprop.c \ + editprop.h \ Are editdlg.[ch] renamed, split or completely replaced? - There's some new direct S_FORTRESS and S_AIRBASE references. That goes against work for generic military bases. See common/base.[ch] to see if better implementation is already possible. - Add FIXME about the fact that following code is not generic enough (gen-movement) + coastal = is_sailing_unittype(punittype); + homecity = find_closest_owned_city(pplayer, ptile, coastal, NULL); - Why city creation now fails without telling reason to client? (modifications to handle_edit_city_create() / handle_edit_create_city() ) This is huge patch. Let's make only agreed fixes against this patch before commit (It's impossible for others to track what other changes appear if you do other development). - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40184) [editor] Request to merge new editor gui
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 About splitting this to smaller commits: - Helper functions from civclient.c should go in immediately. They are simple enough, and they have use outside editor part of the code. - If you have editor.png which has no license issues (fully GPL gfx), that could too should go in soon (there is no previous version of such file, so you cannot break anything by adding it). That makes it much easier to test the actual code changes as text diffs. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40184) [editor] Request to merge new editor gui
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 After some testing: - Only functionality missing from this new model, but present in old version seems to be modifying city internals - packhand.c:2368: handle_tile_info: Assertion `unit_list_size(ptile-units) == 0' failed. I were removing vision from tile with somebody else's unit. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 [EMAIL PROTECTED] - Wed Jun 11 16:51:03 2008]: I only read sources, not yet tested. - Please don't add new empty function headers. New code should have function headers already when committed. What do you mean by empty function header? If you mean the /* ... **/ Then I only fill that in if the function name is not descriptive enough or there are some special conditions or side-effects that programmers need to be aware of (e.g. you must free the return value yourself). Do you think I should describe the functions more in the header? - You add function client_player(), but don't always use it in new code instead of client.conn.playing This I will fix. It is because I added the client_* functions after already writing some code using client.conn.playing and forgot to update the old code. :( What really happens to these files: --- a/client/gui-gtk-2.0/Makefile.am +++ b/client/gui-gtk-2.0/Makefile.am @@ -42,8 +42,10 @@ libguiclient_a_SOURCES = \ dialogs.h \ diplodlg.c \ diplodlg.h \ - editdlg.c \ - editdlg.h \ + editgui.c \ + editgui.h \ + editprop.c \ + editprop.h \ Are editdlg.[ch] renamed, split or completely replaced? They are completely replaced. Similarly for client/include /editgui_g.h. The point was that the code in editgui.[ch] is more that just an edit dialog so the name editdlg did not really apply anymore (cf. function editgui_tileset_changed and editgui_refresh which affect more than one widget). I added editprop.[ch] because editgui.[ch] was getting very long. It will contain the properties dialog (see the wikia editor page for an overview) and its helper functions. - There's some new direct S_FORTRESS and S_AIRBASE references. That goes against work for generic military bases. See common/base.[ch] to see if better implementation is already possible. That I did not know about. I'll look into using that code. Most of the time I had problems trying to get a generic sprite for various objects (like roads or fortresses) so the added code in client/tilespec.c might not be the best possible approach. - Add FIXME about the fact that following code is not generic enough (gen-movement) + coastal = is_sailing_unittype(punittype); + homecity = find_closest_owned_city(pplayer, ptile, coastal, NULL); This is a direct conversion of the old can_unit_exist_at_tile to work on unit_type's (needed for example to check if a unit type can be created at a certain tile). I'll add the FIXME here, but generalizing this code really belongs in another ticket. - Why city creation now fails without telling reason to client? (modifications to handle_edit_city_create() / handle_edit_create_city() ) I thought a long time about how and when to do error messages in server edithand.c. I decided the server should for the most part remain silent for bad input or illegal operations. This is because the user (who is editing) is assumed to know the rules (e.g. where cities may be placed) and becase operations can be batched (which would result in a lot of duplicate messages). Do you think the server should notify the user more in such circumstances? This is huge patch. Let's make only agreed fixes against this patch before commit (It's impossible for others to track what other changes appear if you do other development). It's not hard for me to stash local changes and variously merge between branches, but I will address now the issues you have raised before extending the functionality further. -- 何も欲しくない人がこの世界のどこかにいるか ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 [EMAIL PROTECTED] - Wed Jun 11 19:15:25 2008]: After some testing: - Only functionality missing from this new model, but present in old version seems to be modifying city internals I don't recall there being any GUI for doing that and the packets, handlers, etc., were variously #if 0'd out along with some FIXMEs. Anyway the property editor (in editprop.[ch]) that I would be working on now and will be working on soon will be able to do that (also for tiles, units, and possibly players). - packhand.c:2368: handle_tile_info: Assertion `unit_list_size(ptile-units) == 0' failed. I were removing vision from tile with somebody else's unit. This looks like a bug due to a condition I failed to forsee. It should be easy enough to fix (i.e. don't allow removing vision of a player on a tile with that players' units/city in it). I'll get right on fixing it. -- 皆さん頑張ろうね！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40267) [editor] icons
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40267 First version of editor icons that where suggested to be added to svn in PR#40184 so as remove the need for binary patches. Most images are from tileset images already in the repository. As for the 'X', brush, pointing hand, eye, and wrench+screwdriver they based on various sources which may not be GPL (e.g. some are from tango.freedesktop.org which are CC, wherease others were unattributed in the first place), so I may redo them. -- 綺麗な絵！自分で創ったの？ inline: editor.png___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40250) autoconf fails on a recent S2_1 checkout
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40250 2008/6/11 Marko Lindqvist: 2008/5/24 Daniel Markstedt: $subject OSX 10.3.9 ibg3:~/freeciv-2.1 daniel$ ./autogen.sh + checking for autoconf = 2.55 ... found 2.57, ok.+ checking for autoheader = 2.55 ... found 2.57, ok. + checking for automake = 1.6 ... found 1.6.3, ok. + checking for aclocal = 1.6 ... found 1.6.3, ok. I try to setup autoconf 2.57 + automake 1.6.3 environment for myself. I managed to reproduce with those versions. It seems that pkg.m4 is needed for some reason (I don't know why, but adding it removes the problem and removing it restores the problem) I'll add pkg.m4 immediately. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] 2.1.5
Daniel: Does it compile in your environment now? #40266 should go in before release (there's no risk of breaking anything that currently works; civ1 ruleset is completely broken without this patch anyway) but no other stuff. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 Madeline Book wrote: - Why city creation now fails without telling reason to client? (modifications to handle_edit_city_create() / handle_edit_create_city() ) I thought a long time about how and when to do error messages in server edithand.c. I decided the server should for the most part remain silent for bad input or illegal operations. This is because the user (who is editing) is assumed to know the rules (e.g. where cities may be placed) and becase operations can be batched (which would result in a lot of duplicate messages). Do you think the server should notify the user more in such circumstances? This is an issue for a lot of regular-game city report operations as well. There is no established standard afaik (there should be), but most places seem to have client checking as well as server spamming of error messages IIRC. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 Madeline Book wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 [EMAIL PROTECTED] - Wed Jun 11 16:51:03 2008]: I only read sources, not yet tested. - Please don't add new empty function headers. New code should have function headers already when committed. What do you mean by empty function header? If you mean the /* ... **/ Then I only fill that in if the function name is not descriptive enough or there are some special conditions or side-effects that programmers need to be aware of (e.g. you must free the return value yourself). Do you think I should describe the functions more in the header? Previous discussions have agreed that empty comments are not helpful. It's possible that the function name really says everything about the function; in such a case maybe ... isn't needed. But I really don't see any use to having ... as a comment. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 [EMAIL PROTECTED] - Thu Jun 12 04:43:02 2008]: Madeline Book wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 [EMAIL PROTECTED] - Wed Jun 11 16:51:03 2008]: I only read sources, not yet tested. - Please don't add new empty function headers. New code should have function headers already when committed. What do you mean by empty function header? If you mean the /* ... **/ Then I only fill that in if the function name is not descriptive enough or there are some special conditions or side-effects that programmers need to be aware of (e.g. you must free the return value yourself). Do you think I should describe the functions more in the header? Previous discussions have agreed that empty comments are not helpful. It's possible that the function name really says everything about the function; in such a case maybe ... isn't needed. But I really don't see any use to having ... as a comment. I actually like the whole 3 line ... header as a visual separator between functions (thanks in large part due to the nice color difference in syntax hilighting). Anyway, that is just my preference; are you suggesting that empty headers should just be: / / Or perhaps no header at all? - 勘弁してくれ。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
