[Freeciv-Dev] [bug #13810] [patch] use unions to save the game settings
Follow-up Comment #11, bug #13810 (project freeciv): This way I can use pset_scategory(i) else I would have pset_scategory(setting_by_number(i)) There is an example of how to create an iteration macro when the array pointer is not available in the header in the patch in bug #13793. Reading your comments I also found that I'm missing some knowledge about how to code (I did learn some basics about C/C++ coding but I do mainly html/php). I think I have to reread the patches #13805 and #13810 (and an unsend patch to add action callback function) carefully with regard to variable and function naming and possible simplifications. And I need to do some planning before coding ... Sorry if something was unclear beforehand. Unfortunately I will not be able to explain so much now as I will be trying to finish the work for 2.2. では失礼します。 ___ Reply to this item at: http://gna.org/bugs/?13810 ___ 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] [bug #13726] Add the flag in start page
On 30/06/2009, Madeline Book no-reply.invalid-addr...@gna.org wrote: Follow-up Comment #8, bug #13726 (project freeciv): (Book, why don't I receive your message on my e-mail account?) I have no idea, maybe it was just late in arriving? Maybe your spam filter got tired of reading through my drivel. Was it just the last one, or all my comments on the gna bugtracker? I'm not doing anything strange, just using the post a comment box... Now I'm not getting any email from gna when I post comments to tickets. O-o もしかして嫌いか。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13848] [Patch] More detailed coding style guidelines
Follow-up Comment #4, bug #13848 (project freeciv): Some rules I was just reminded of: - No more than 2 empty lines between any sections in the code. - #include the header corresponding to the current c source file after all other headers. 思い出してくれてありがとう。 ___ Reply to this item at: http://gna.org/bugs/?13848 ___ 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 #13848] [Patch] More detailed coding style guidelines
Follow-up Comment #3, bug #13848 (project freeciv): Could you add assert() rule that instead of assert(FALSE) assert with more verbose error message should be used when possible: [...] There is the die() function which can be used if the assert condition is not descriptive enough. I'll add a note about it and also to avoid using assert(0) and similar. ちょっと！まだ死なないでくれよ。 ___ Reply to this item at: http://gna.org/bugs/?13848 ___ 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 #13811] [Patch] string vector
Follow-up Comment #1, bug #13811 (project freeciv):
Some general notes:
- The #include shared.h in iterator.h can be
committed separately immediately if desired.
- The string vector header+implementation and
the changes in common/tech.c should be separate
patch submissions.
- Use 8 spaces instead of a tab for 4 indent levels.
- No more than 2 empty lines between code parts.
Some notes about the string vector implementation:
- I suggest a shorter class name, e.g. 'strvec'.
This would also help to distinguish it from
vectors created with the specvec macro.
- Most other data structures in freeciv use
X_free() instead of X_destroy().
- Since a vector generalizes the array concept
(i.e. it supports O(1) random access), there is
already an iteration interface using element
indicies (i.e. a for loop). Hence there is no
need to use the generic iterator interface.
- The insert_{before,after} functions should just
take an element index instead of iterators, if
not removed altogether (there is already an
insert() function).
Some notes about the other changes:
- The need for static variables and consequently the
string vector (in this patch) would be removed if
you just made advance_name_{by,for}_player() take
a buffer and maximum size arguments. Updating all
callers would a bit tedious (by=12 for=57), but it
would be the correct approach.
もっと簡潔であるべきだ。
___
Reply to this item at:
http://gna.org/bugs/?13811
___
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 #13810] [patch] use unions to save the game settings
Follow-up Comment #8, bug #13810 (project freeciv): I meant pset only for the variable names; functions structs, etc. should have setting. The variable name should usually give some hint as to what it stands for. So cmd, when the type is struct setting *, would not be a good variable name (someone would think it was a struct command). Also, do not do this pset_sval_validate(cmd)(arg, caller, reject_message) Just make the wrapper like setting_string_validate(pset, arg, ...) and have it call the validate function if it exists, i.e., if the function pointer is not NULL it returns the return value of the call, otherwise it returns TRUE. 注意して読みなさい。 ___ Reply to this item at: http://gna.org/bugs/?13810 ___ 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 #13810] [patch] use unions to save the game settings
Follow-up Comment #9, bug #13810 (project freeciv):
_(pset_short_help(i))
Why not put the _() in setting_short_help() and write
in the comment header that it returns the translated
version? This goes for all such dupicated expressions.
Why do you use the setting number as first argument
to almost every setting function? The only function
that takes a setting id should be setting_by_number().
for (i = 0; i SETTINGS_NUM; i++) {
Use an iteration macro, either as the for loop or
using the generic iterator interface in utility/
iterator.h. Iterate on 'pset' which is a 'struct
setting *'.
なんだかむかつく。
___
Reply to this item at:
http://gna.org/bugs/?13810
___
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] settings rework
On 01/07/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: Those are the 3 that are being actively developed. My longterm goal is to merge them all into one project. Looking through the patches of longturn and warclient I found the patch 'Setting to control distance of traderoutes.' (longturn 20090623). This is something I also wanted to implement for the standard freeciv ... What are the rules to merge patches from warclient or longturn into the main freeciv? You submit them like other feature/bugfix patches, because they are usually implemented in a not very clean manner and need to be checked. キタナイ！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] settings rework
On 01/07/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: I did rename op_* to pset_* as it matches the purpose of the variable: a pointer to a setting struct Do this for variable names whose type is 'struct setting *' or 'const struct setting *' only, not function names. How many freeciv versions are out there? I knew of freeciv (the original), warclient and longturn. Those are the 3 that are being actively developed. My longterm goal is to merge them all into one project. ... and also a download of the longturn svn ... Do you can say something more about this plan? More details would be here: http://freeciv.wikia.com/wiki/User:Mbook I read that your first priority is the editor for freeciv 2.2. What are the most important points to merge into freeciv? They are listed on the page above, but really only users of those programs would know this... Tips how to do it? Ask people playing on warclient/longturn servers about what warclient/longturn features they absolutely cannot live without, then re-implement those features in 2.1 and trunk, usually by copying and adapting (rewriting) code from their repositories. 書き直す罰ゲーム。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13846] recursion checking for the read command
Follow-up Comment #4, bug #13846 (project freeciv): Please no static variables. Use a context argument and a wrapper/recursive function pair. Ask if you need an example. なんじゃそりゃ。 ___ Reply to this item at: http://gna.org/bugs/?13846 ___ 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] how to use git locally for freeciv
On 01/07/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: You don't need to. As I said the 3 GB size is not a problem. I think I will also get warclient and longturn to compare ... The 3 GB is just silly. The entire history of the trunk and S2_1 branches when cloned from freeciv-svn-mirror are only 269M. どうしてあんまり太っている。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13848] [Patch] More detailed coding style guidelines
URL: http://gna.org/bugs/?13848 Summary: [Patch] More detailed coding style guidelines Project: Freeciv Submitted by: mbook Submitted on: Thursday 07/02/2009 at 02:33 Category: docs Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: As promised I expanded the coding style guidelines with more specific rules, examples, and general suggestions. I also made the guide itself follow its own formatting rules. I would please ask that everyone read the new guide and comment if something is not acceptable or should be added. When this patch is applied to S2_1 and trunk, I will also update the wiki page at: http://freeciv.wikia.com/wiki/Coding_Style 新しい法律が発表されます。 ___ File Attachments: --- Date: Thursday 07/02/2009 at 02:33 Name: more_style.diff Size: 18kB By: mbook http://gna.org/bugs/download.php?file_id=6110 ___ Reply to this item at: http://gna.org/bugs/?13848 ___ 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 #13790] [Patch] Fix diplomat_success_vs_defender() chance
Update of bug #13790 (project freeciv): Status: Confirmed = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13790 ___ 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] settings rework
On 30/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: I would rename settings as options, ... In the client the name option is already used for settings that are client-only (client/options.[ch]), so I don't think renaming to this in the server would be very helpful or useful. Is there some particular reason why you want to rename setting as option in the server? ... move the all the struct as well as all the inline functions into settings.c and define the missing functions. This way the struct is only defined within settings.c (like the struct command in command.c). Good. TODO: 4. possibility of callback functions for options if changed - aifill - aitoggle (I suppose you meant 'autotoggle' instead of 'aitoggle'.) Yes, this is probably a good idea. The other possibility is to change these side-effect settings to commands. 5. add functions to check / set options - option_check(const struct settings_s *op, union setting_value bisval) - option_set(struct settings_s *op, union setting_value bisval) It's not really consistent to prefix the functions with option_ and then operate on settings_s pointers. I would suggest to just use setting_ as the prefix and use setting as the struct name, in keeping with general object oriented conventions. You can also call the union something less verbose, perhaps 'union setval' (since it's not really part of the 'setting' class, but just a little helper data structure). 7. new option - skill string:easy|normal|hard skill level of new AI players Fine, but in its own ticket please (each new feature should have its own patch). 8. new command - default (set default values) A command to do this has already existed a long time in warclient; it is called /reset and I think this is a slightly better name than /default (for example in the future it could take parameters so you could /reset settings, /reset map, /reset teams etc.). 9. special fields within the ruleset - game.default = [0/1] if all options should be set to the default values - game.showchanged = [0/1] if changed values should be listed Is there a reason why you would want to disallow users from using the '/show changed' command? 計画には反対しません。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13814] segfault in assess_danger_player
Follow-up Comment #9, bug #13814 (project freeciv): It would appear to affect only 32-bit systems... シーピーユー差別なんです。 ___ Reply to this item at: http://gna.org/bugs/?13814 ___ 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] settings rework
On 30/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: Am Tuesday 30 June 2009 22:36:11 schrieben Sie: On 30/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: I would rename settings as options, ... In the client the name option is already used for settings that are client-only (client/options.[ch]), so I don't think renaming to this in the server would be very helpful or useful. Is there some particular reason why you want to rename setting as option in the server? for one setting op is used and this is short for op(tion)? It is not needed but I wanted to be consistent. I will leave it as setting(s_s) and settings ... Oh that. Maybe the op is a relic from ancient times when the settings were called options in the server too. It's not too bad as a variable name convention for settings, since it is at least used consistently and there is no other object type whose class name would have op as a short form. The thing is, using just s as the variable name might conflict with string variables, and ss is not much better (but probably as good as op, if some other pointer-to-object variables do not use it already). Another possibility is psetting (like there is pcity, punit, etc.), though it is quite long. We can combine the best of both worlds and get pset, which is short, unique (as far as I know) and reminds the programmer what the variable is (once they have seen it with its full type of 'struct setting *'). Variable naming is not that important, I would just suggest being consistent and using short names to save yourself the typing when the variable is used a lot. TODO: 4. possibility of callback functions for options if changed - aifill - aitoggle Yes, this is probably a good idea. The other possibility is to change these side-effect settings to commands. The problem is, that aifill takes an int value as option and also that this option (is/will be) used in scenarios. I would like to be able to define all settings needed for the game into the ruleset file. This way only rulesetdir ... is needed to start the game and the *serv file would be obsolete. Alright, that sounds like a good plan. 5. add functions to check / set options - option_check(const struct settings_s *op, union setting_value bisval) - option_set(struct settings_s *op, union setting_value bisval) It's not really consistent to prefix the functions with option_ and then operate on settings_s pointers. I would suggest to just use setting_ as the prefix and use setting as the struct name, in keeping with general object oriented conventions. The name comes from the renaming idea (see 3.). I will use a function name of setting_*. You mean rename 'settings_s' to 'setting' like done for 'command'? (done in gna13810) Yes. The convention of appending _s to the struct name is not used in freeciv, so there is no reason to keep it here in this case (there are some bits of code that awkwardly use setting as a variable name which should probably be fixed, altough using setting as both the struct label and a variable name is not a syntax error). 7. new option - skill string:easy|normal|hard skill level of new AI players Fine, but in its own ticket please (each new feature should have its own patch). yes; each list point should be (at least) one ticket; if I get how to plan my work it will be several patches with each resulting in a working freeciv version ... Sorry to keep reminding you about basic things you probably already know well; I do it also for anybody reading these discussions in the future. ;) 8. new command - default (set default values) A command to do this has already existed a long time in warclient; it is called /reset and I think this is a slightly better name than /default (for example in the future it could take parameters so you could /reset settings, /reset map, /reset teams etc.). OK; I will look into warclient. There are instructions on how to download and build it here: http://freeciv.wikia.com/wiki/Warclient How many freeciv versions are out there? I knew of freeciv (the original), warclient and longturn. Those are the 3 that are being actively developed. My longterm goal is to merge them all into one project. 9. special fields within the ruleset - game.default = [0/1] if all options should be set to the default values - game.showchanged = [0/1] if changed values should be listed Is there a reason why you would want to disallow users from using the '/show changed' command? The idea is to (1) reset all settings before loading the values from the ruleset and (2) show the settings changed by the ruleset. This would be in addition to the available commands. The function to load the ruleset file would evaluate this settings and act accordingly. I don't think it makes sense for the ruleset to reset all settings when it is loaded, since there are a lot of settings that really only
[Freeciv-Dev] [bug #13726] Add the flag in start page
Follow-up Comment #7, bug #13726 (project freeciv): Hm, reading the coding style manual, it doesn't say to avoid the usage of tabs. Yes, existing coding style allows use of tabs. However, I agree with book that spaces should be used, so coding style should be changed. Patch welcome. I'll update the wikia page and the docs files, since I have been meaning to do this for a while now. もっと規則が必要だ。 ___ Reply to this item at: http://gna.org/bugs/?13726 ___ 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 #13726] Add the flag in start page
Follow-up Comment #8, bug #13726 (project freeciv): (Book, why don't I receive your message on my e-mail account?) I have no idea, maybe it was just late in arriving? Maybe your spam filter got tired of reading through my drivel. Was it just the last one, or all my comments on the gna bugtracker? I'm not doing anything strange, just using the post a comment box... 捨てたいほどくどくどしい。 ___ Reply to this item at: http://gna.org/bugs/?13726 ___ 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 #13817] [S2_1] done_moving is not reset after the unit orders are cleared
Update of bug #13817 (project freeciv): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: The patch in PR#40563 was not applied to S2_1. Oh sorry, I thought it was included in the S2_1 port. I'll commit it now. 原子爆弾から一個のネジ。 ___ Reply to this item at: http://gna.org/bugs/?13817 ___ 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 #13559] [RT #39700] AI should not ask for help against enemies we have not yet met
Follow-up Comment #2, bug #13559 (project freeciv): I just noticed that I completely omitted Per's name from the Patch by: field in the commit messages for this patch. Sorry Per. :) Patch by: Per Inge Mathisen per.mathi...@gmail.com 誰かが名前を消してしまった。 ___ Reply to this item at: http://gna.org/bugs/?13559 ___ 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 #13814] segfault in assess_danger_player
URL: http://gna.org/bugs/?13814 Summary: segfault in assess_danger_player Project: Freeciv Submitted by: mbook Submitted on: Monday 06/29/2009 at 18:07 Category: general Severity: 4 - Important Priority: 7 - High Status: Confirmed Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: I have confirmed the crash, it occurs fairly regularly after a few turns in trunk if I just set all units to auto-explore at the start of the game. On 26/06/2009, Jordi Negrevernis i Font jnegrever...@jnfprogramari.com wrote: Ejem... happy debugging... #0 0x0806b9db in assess_danger_player (pplayer=0x82c8a74) at advmilitary.c:415 myiter = (struct genlist_link *) 0x2 #1 0x080cc6f6 in ai_do_first_activities (pplayer=0x82c8a74) at aihand.c:430 No locals. #2 0x08052dbf in srv_running () at srv_main.c:642 eot_timer = (struct timer *) 0x89a3290 save_counter = 1 is_new_turn = true __PRETTY_FUNCTION__ = srv_running #3 0x08053984 in srv_main () at srv_main.c:2383 No locals. #4 0x0804b1df in main (argc=1, argv=0xbfdfe3e4) at civserver.c:290 inx = 1 showhelp = 27 showvers = 8 option = value optimized out 探検するのは危険だそうです。 ___ Reply to this item at: http://gna.org/bugs/?13814 ___ 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 #13802] [Patch] Invalid iterator for NULL hash tables
Follow-up Comment #2, bug #13802 (project freeciv): It is really needed? Couldn't it be performed by adding a test in the iterating marco like: if (NULL != hash)? If you mean in the specific iteration macros like hash_keys_iterate, this would need to be repeated each time a new macro like that is defined, and I wanted to avoid the situation where the same code is duplicated in the headers every time. One design goal of the generic_iterate macro is to reduce the definition to only the things that are different. If you mean to put the NULL check in the generic_ iterate macro itself, it would have to be a check on the iterator pointer, since the extra init arguments are passed via macro varargs, and could be completely absent or more than 1 (i.e. there is no way to put them in an if-expression). One reason I did not allow NULL iterator pointers is so that I would not have to put NULL checks in all of the iterator_*() functions and also in any code that would use the init function outside of the generic_ iterate macro. Iterator pointers are somewhat special in that the memory is guaranteed to be on the stack; it is never NULL. If we decide to use NULL iterator pointers in one place, we would have to do away with this nice property and assume that iterators could be NULL almost everywhere. We would not need the iterator.c file, but then we would need a lot more NULL checks everywhere else, so purely from a number of lines of code standpoint I don't think we gain anything. The functions in iterator.c also provide some boiler- plate code which can be copied and adapted for new iterator implementations (albeit the sizeof function is missing). Is that acceptable justification? イエスかノーかはっきり言ってください。 ___ Reply to this item at: http://gna.org/bugs/?13802 ___ 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 #13814] segfault in assess_danger_player
Follow-up Comment #1, bug #13814 (project freeciv): The crash seems to occur when a hut is entered... どうぞ、小屋にお入りください。 ___ Reply to this item at: http://gna.org/bugs/?13814 ___ 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 #13814] segfault in assess_danger_player
Follow-up Comment #3, bug #13814 (project freeciv): It just occurred to me that my recent barbarian.c commit was buggy in case barbarian player is created midturn. It could explain this crash if barbarian player is create from hut. But does it happen already before onsetbarbs turn? Yes. Steps to reproduce: 1. Start a new game with at least one player. 2. Use the editor to place huts all around the starting position. 3. Set units to auto-explore (or just take huts yourself). 4. Server eventually crashes when some hut is taken. お断りします。 ___ Reply to this item at: http://gna.org/bugs/?13814 ___ 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] how to use git locally for freeciv
On 29/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: Am Thursday 18 June 2009 01:50:53 schrieb Madeline Book: On 17/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: [...] My experience (we did it with git-svn here at work) is that it's a bit of an impedance mismatch; svn's limitations impose limitations on how you use git (I don't know if git-svnimport is any better): merges seem to make SVN go WTF? and freak out. Although I've never tried, I guess you could use a separate branch for each patchset, if you take care with how you bring it back into SVN. I have a branch for each patchset. And it is a one-way data exchange svn - git. The changes are submitted to gna as patches. Until now all is fine ... Separate branches is what I use with git-svn, making a new branch whenever I need to build on changes not yet in the main branch (i.e. trunk, S2_1, etc.). As a contributor one has to submit patches for inspection anyway, so when I do go to commit something, I just checkout the destination branch, apply the previously posted patch file, commit to git, then dcommit with git-svn. Unfortunately since the underlying repo is still svn, we cannot use the powerful branch merging features of git. :( A while ago I wrote a mini intro to using git with freeciv svn: https://mail.gna.org/public/freeciv-dev/2008-03/msg00048.html a size of 350MB? I have more than 3GB, most of it in the directory tags. It's not a problem but do I need this directory? I did a 'git svn clone svn://...' matth...@mattsys:/home/matthias/git du -h --max-depth=2 2.5G./freeciv.git/tags 251M./freeciv.git/branches 242M./freeciv.git/trunk 208M./freeciv.git/.git 3.2G./freeciv.git 3.2G. Something is strange, since I have the full repository, with all my local branches and all remote branches and tags in 341 MB as of today (with git-repack -a -d and make distclean with 'trunk' checked out). My directory layout is different, I only have one directory (I call it 'git-svn'), in which there is a '.git' dir of 148M (du -h -s . inside) and the currently checked out source within it (i.e. no separate 'tags', 'branches' and 'trunk' directories, e.g. 'autogen.sh' is just in 'git-svn'). Maybe despite what the documentation says, git-svn clone behaves differently from running git-svn init and git-svn fetch separately. Or maybe you have an old version of git or git-svn that behaves that way. $ git-svn --version git-svn version 1.6.3.1 (svn 1.5.1) Anyway, the commands I used (in the directory you want to be the root of the repository, like 'git-svn' above) are: $ git svn init -t tags -b branches -T trunk --prefix=gna/ svn://svn.gna.org/svn/freeciv $ git svn fetch (It will take a long time to fetch all the revisions, just do the command again if it is interrupted by you or something else. Maybe you will need a while ! git svn fetch; sleep 5; done or similar for your shell. ;)) (I'm also not sure if you should use 'svn+ssh://synt...@svn.gna...' instead of just plain 'svn://svn.gna...', since I do not know if you will have to re-fetch the whole damn thing if you were to get svn write access some day...) $ git-repack -a -d $ git config branch.autosetupmerge true $ git-checkout trunk gna/trunk $ git-svn rebase Now you should be all set. I have no idea why your repository is so huge. It looks like it somehow copied the entire svn repository, and then just added a .git directory at its root. You do not need all of that, the laborious svn fetch should have grabbed all of the necessary information and converted it into git form. I hope I'm not crazy/stupid. ;) 信じられねぇぇ！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13814] segfault in assess_danger_player
Follow-up Comment #5, bug #13814 (project freeciv): I tested many times, I really cannot reproduce any crash. When I put printfs that access the city pointer in assess_danger_player(), the exactly reproducible crashes go away. :( Maybe this is another compiler bug (I will try various compiler flags)... 機械の中に幽霊がある。 ___ Reply to this item at: http://gna.org/bugs/?13814 ___ 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 #13817] [S2_1] done_moving is not reset after the unit orders are cleared
Update of bug #13817 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13817 ___ 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 #13819] Assertion failure in get_invention()
Update of bug #13819 (project freeciv): Status: In Progress = None ___ Reply to this item at: http://gna.org/bugs/?13819 ___ 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] how to use git locally for freeciv
I just made a git repository on gitorious mirroring the trunk branch in gna svn. Try it out: $ git clone git://gitorious.org/freeciv-svn-mirror/freeciv-svn-mirror.git Web page: http://gitorious.org/freeciv-svn-mirror It should be a bit faster than via git-svn. ;) そのおもちゃを見せてくれ。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] how to use git locally for freeciv
On 29/06/2009, Madeline Book madeline.b...@gmail.com wrote: I just made a git repository on gitorious mirroring the trunk branch in gna svn. Try it out: $ git clone git://gitorious.org/freeciv-svn-mirror/freeciv-svn-mirror.git And when that finishes do $ git-checkout -b trunk origin/trunk in the newly created directory (freeciv-svn-mirror). Sorry, I think I had a mistake in the git-checkout example step in my previous mail: I forgot the -b argument to create a new branch. ただの枝だ。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13803] [Patch] Start position cleanup and extension
URL:
http://gna.org/bugs/?13803
Summary: [Patch] Start position cleanup and extension
Project: Freeciv
Submitted by: mbook
Submitted on: Sunday 06/28/2009 at 06:07
Category: editor
Severity: 3 - Normal
Priority: 5 - Normal
Status: Ready For Test
Assigned to: mbook
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release:
Operating System: None
___
Details:
The attached patch implements improved start position
functionality for the editor. Depends on the patches
in #13793, #13800, #13801 and #13802.
The user can now easily place start positions on the
map in edit mode, and efficiently set which nations
may start at any given position, including allowing
all nations or excluding specific ones (via the
property editor).
Two packets are used for communicating start position
information between clients and the server:
PACKET_EDIT_STARTPOS
PACKET_EDIT_STARTPOS_FULL
The first is used to either create or remove a start
position at a tile, and the second to set the nation
information. A bitvector is used to pack a list of
nations into the packet (bits correspond to nation
numbers), with a limit of 1024 maximum nations
(MAX_NUM_STARTPOS_NATIONS in fc_types.h). Hopefully
before more than 1024 nations exist there will be
better network protocol support for dynamic arrays
in packets, removing the need for hard-coded maximum
sizes.
These packets are sent by both the client and the
server, allowing most of the handling code to be
factored out into functions in common/map.c.
Some less noteworthy internal additions:
- Added a 'TILE' packet field (SINT32) used to
send tile indexes, as an alternative to sending
COORD x, y.
- Added a new object type OBJTYPE_STARTPOS to the
property editor, along with 2 read-only and 2
editable properties.
- Added a new value type VALTYPE_STARTPOS_NATIONS
for special handling of a hash_table used to
represent the nations at a start position.
- Added iterators for iterating all nations in a
start position, and all start positions on the
map.
- Updated version.in due to packet changes.
And some partially related fixes:
- PACKET_EDIT_TILE had incorrect but harmless
UNIT id field, which I changed to TILE id.
- editgui_notify_object_{changed,created}() do not
propagate the notifications outside of edit mode.
- Made objtype_get_id_from_object() use -1 to
represent an invalid ID instead of zero, since for
example for tile IDs (i.e. as returned by tile
_index()) zero is a valid value.
- Added some argument checks in property_page_add
_objbind().
As far as start positions go now, what remains to
be done is:
* Make the map generator use the new start position
API (hence remove map.start_positions).
* Send start positions to editing clients when
entering edit mode.
* Implement saving and loading of the new start
position data structures in savegames/scenarios.
* Get a better start position map sprite than
user.attention (also perhaps somehow distinguish
between a start position allowing all, some, or
excluding nations).
ようやくやった。
___
File Attachments:
---
Date: Sunday 06/28/2009 at 06:07 Name: startpos_cleanup_and_extension.patch
Size: 52kB By: mbook
http://gna.org/bugs/download.php?file_id=6068
___
Reply to this item at:
http://gna.org/bugs/?13803
___
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 #13805] [patch] change call by id (int) to call by reference (struct settings_s)
Update of bug #13805 (project freeciv):
Assigned to:None = mbook
___
Follow-up Comment #1:
This patch is good, but you can reduce references to the
global variable 'settings' even more by using helper
functions to get a setting pointer from a setting id:
struct settings_s *setting_by_number(int id)
{
if (!(0 = id id SETTINGS_NUM) {
return NULL;
}
return settings + id;
}
(The expression 'settings + id' is the same as
'settings[id]', since ptr[x] == *(ptr + x)).
To get the id from a setting pointer, you use
pointer arithmetic again:
int setting_number(const struct setting_s *op)
{
if (!op) {
return -1;
}
return op - settings;
}
Some description of pointer arithmetic is here
http://en.wikipedia.org/wiki/Pointer_arithmetic#C_and_C.2B.2B
if you are unfamiliar with the concept.
Ideally we would want to completely remove the extern
reference to 'settings' from settings.h.
Good job using git. :)
算数授業に行きましょうか。
___
Reply to this item at:
http://gna.org/bugs/?13805
___
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 #13805] [patch] change call by id (int) to call by reference (struct settings_s)
Follow-up Comment #2, bug #13805 (project freeciv): In case you want git to use your public name and email address (instead of using information from the local machine), use git config --global user.name Your Name Comes Here git config --global user.email y...@yourdomain.example.com to set your details. That way the correct email will be used for git-format-patch et al. アドレスを知っていませんが。 ___ Reply to this item at: http://gna.org/bugs/?13805 ___ 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 #13807] [patch] define the settings within a function
Update of bug #13807 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13807 ___ 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 #13807] [patch] define the settings within a function
Follow-up Comment #1, bug #13807 (project freeciv):
I'm not sure that we need to get rid of the static
'settings' array and use dynamic memory for settings,
since even with your approach there will still be at
least one variable global to the settings.c file.
If you are worried that you cannot use static initializers
with unions, you need not be, since you can use the
syntax:
union foo {
int i;
const char *s;
bool b;
};
union foo f1 = { .b = TRUE };
union foo f2 = { .s = hi };
This could be a little more tricky though, since the
settings take the address of the int/bool. I think you
can just do
union pfoo {
int *pi;
bool *pb;
char *ps;
};
union pfoo pf1 = { .pi = value };
Of course please use much better variable and field
names than I do in the examples.
時間をかけていい名前を思いつく。
___
Reply to this item at:
http://gna.org/bugs/?13807
___
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 #13807] [patch] define the settings within a function
Follow-up Comment #4, bug #13807 (project freeciv): This will help! The 'static initializers' error message was the reason for me to try it with a function. Is an union portable to win, ...? Struct/union initializers are part of the c language (but not c++ apparently), so it should work with any c compiler. 窓でもいいよ。 ___ Reply to this item at: http://gna.org/bugs/?13807 ___ 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 #13810] [patch] use unions to save the game settings
Update of bug #13810 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13810 ___ 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 #13810] [patch] use unions to save the game settings
Follow-up Comment #3, bug #13810 (project freeciv): It looks really better and understandable to me. More over, it should take the minimal size of the whole structure, and not an addition of all of them. I agree with pepeto, the union of structs would probably make more sense, since what we are basically trying to do is polymorphism on the structs in pepeto's example code. もうちょっとお願いがあるんですが。 ___ Reply to this item at: http://gna.org/bugs/?13810 ___ 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 #13810] [patch] use unions to save the game settings
Follow-up Comment #4, bug #13810 (project freeciv): static inline bool setting_boolval(conct struct setting_s *op) That should be const of course. I'm also not sure about the naming scheme, since with the full setting_ prefix this makes it a little awkward to use in expressions. Perhaps just SBOOLVAL or some similar short macro-like name (beware conflicts though, both literal and conceptual :)). カンック？ ___ Reply to this item at: http://gna.org/bugs/?13810 ___ 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 #13811] [Patch] string vector
Update of bug #13811 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13811 ___ 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 #13559] [RT #39700] AI should not ask for help against enemies we have not yet met
Update of bug #13559 (project freeciv): Priority: 1 - Later = 5 - Normal Status:None = In Progress Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13559 ___ 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 #13799] siplt C_S_PREPARING in trunk
Follow-up Comment #1, bug #13799 (project freeciv): I agree that the client should distinguished between being connected in pregame, and being disconnected. If I recall correctly, right now there are some hacks that check if aconnection is connected to know if the game data should be reset. A client state would probably be a better solution. Ideally we would want to design it so that ruleset data is only sent when the ruleset actually changes on the server, that is, when clients connect initially or when the ruleset is changed in pregame due to the rulesetdir command or a game being loaded. 情報伝達を最小限に下げましょう。 ___ Reply to this item at: http://gna.org/bugs/?13799 ___ 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 #13800] [Patch] Hash table copy constructor and equality test
URL: http://gna.org/bugs/?13800 Summary: [Patch] Hash table copy constructor and equality test Project: Freeciv Submitted by: mbook Submitted on: Sunday 06/28/2009 at 05:06 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Attached patch adds functions: struct hash_table *hash_copy(const struct hash_table *h); bool hash_equal(const struct hash_table *a, const struct hash_table *b); for copying and testing equality of hash tables. The copy is a copy in the deep sense (i.e. new buckets are created), but element key and value pointers are just copied by value (i.e. elements are only shallow copied). Equality is satisfied if the pointer is the same, or both are not NULL, have the same fcmp fval, and free functions, have the same number of elements, and all element key/value pointers are equal in the order traversed by the hash iterator. 平等が写しで保証される。 ___ File Attachments: --- Date: Sunday 06/28/2009 at 05:06 Name: hash_copy_equal.diff Size: 3kB By: mbook http://gna.org/bugs/download.php?file_id=6065 ___ Reply to this item at: http://gna.org/bugs/?13800 ___ 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 #13801] [Patch] Stub invalid iterator implementation
URL: http://gna.org/bugs/?13801 Summary: [Patch] Stub invalid iterator implementation Project: Freeciv Submitted by: mbook Submitted on: Sunday 06/28/2009 at 05:12 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Patch adds a simple stub generic iterator that can be used when an iterator init functions receives invalid arguments. あなたの議論は無効です。 ___ File Attachments: --- Date: Sunday 06/28/2009 at 05:12 Name: invalid_iter_stub.diff Size: 3kB By: mbook http://gna.org/bugs/download.php?file_id=6066 ___ Reply to this item at: http://gna.org/bugs/?13801 ___ 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 #13802] [Patch] Invalid iterator for NULL hash tables
URL: http://gna.org/bugs/?13802 Summary: [Patch] Invalid iterator for NULL hash tables Project: Freeciv Submitted by: mbook Submitted on: Sunday 06/28/2009 at 05:25 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Making use of the 13801, trying to iterate over a NULL hash table will just iterate over nothing, instead of crashing. 私が無にぶつかった。 ___ File Attachments: --- Date: Sunday 06/28/2009 at 05:25 Name: use_invalid_hash_iter.diff Size: 1kB By: mbook http://gna.org/bugs/download.php?file_id=6067 ___ Reply to this item at: http://gna.org/bugs/?13802 ___ 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 #13727] /detach, /observe and /take are incomplete after the game ended
Update of bug #13727 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #5: Here's a quick port for trunk, which appears to work well. Testing would be appreciated. 確認しなければなりません。 (file #6059) ___ Additional Item Attachment: File name: trunk-game_over.patch Size:7 KB ___ Reply to this item at: http://gna.org/bugs/?13727 ___ 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 #13790] [Patch] Fix diplomat_success_vs_defender() chance
URL: http://gna.org/bugs/?13790 Summary: [Patch] Fix diplomat_success_vs_defender() chance Project: Freeciv Submitted by: mbook Submitted on: Thursday 06/25/2009 at 23:12 Category: general Severity: 4 - Important Priority: 7 - High Status: Confirmed Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: As reported by Szunti in the forum: http://forum.freeciv.org/viewtopic.php?p=24231 there is a programming mistake at the end of the function diplomat_success_vs_defender(). The attached patch fixes the inequality and also improves some comments and formatting. 俺はスパイじゃないよ。 ___ File Attachments: --- Date: Thursday 06/25/2009 at 23:12 Name: fix_diplomat_chance.diff Size: 3kB By: mbook http://gna.org/bugs/download.php?file_id=6050 ___ Reply to this item at: http://gna.org/bugs/?13790 ___ 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 #13793] [Patch] Use generic iterator for nation iteration
URL:
http://gna.org/bugs/?13793
Summary: [Patch] Use generic iterator for nation iteration
Project: Freeciv
Submitted by: mbook
Submitted on: Friday 06/26/2009 at 00:13
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
Status: Ready For Test
Assigned to: mbook
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release:
Operating System: None
___
Details:
Attached patch converts the nations_iterate macro
to use the generic iterator interface. Hence the
functions nation_array_{first,last}() are removed.
I make use of the nation iterator in the start
position code I am currently working on.
未来には「国家」という概念は時代遅れである。
___
File Attachments:
---
Date: Friday 06/26/2009 at 00:13 Name: nation_iterator.diff Size: 4kB By:
mbook
http://gna.org/bugs/download.php?file_id=6053
___
Reply to this item at:
http://gna.org/bugs/?13793
___
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 #13763] gtk assertion VALID_ITER failed when detaching
Update of bug #13763 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13763 ___ 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 #13736] [2.1] Air patrol still crashes
Update of bug #13736 (project freeciv): Priority: 5 - Normal = 7 - High Assigned to:None = mbook ___ Follow-up Comment #1: I think we should backport the improved goto code from trunk to S2_1, since it is such a critical part of the client. この要素は重大ですから。 ___ Reply to this item at: http://gna.org/bugs/?13736 ___ 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#40821) Assertion failure
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40821 [ju...@williamsonclan.us - Sun Jun 21 03:09:21 2009]: I am using 2.1.9 Alright, another ticket for the air patrol bug in 2.1.9 has already been started on the gna bug tracker: https://gna.org/bugs/index.php?13736 I will close this ticket marking it as a duplicate and add you as a requestor to the new one. --- なんだ、おじさんか。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13732] Detaching doesn't update the game.player_ptr pointer
Update of bug #13732 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13732 ___ 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 #13733] Endgame report can contain negative tech score
Update of bug #13733 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13733 ___ 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#40821) Assertion failure due to air patrol
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40821 [ju...@williamsonclan.us - Fri Jun 19 19:23:19 2009]: Hello, Whenever I try to send my AWACS on Patrol, I receive the following: File: ../../utility/shared.c Line: 754 Hi, Thanks for the report, but could you provide information about what version you are running? If I recall some air patrol crashing bug was fixed a long time ago. Also, use the gna bug tracker: https://gna.org/bugs/?func=additemgroup=freeciv --- 何ものだ！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13727] /detach, /observe and /take are incomplete after the game ended
Follow-up Comment #3, bug #13727 (project freeciv): There is an other oddity. It seems that the client absolutly needs to receive the C_S_RUNNING state to switch to the game page. So, is it better to send 2 states consecutively (C_S_RUNNING and C_S_OVER) or to allow the client to handle directly the C_S_OVER state ? Directly handling C_S_OVER would be the better approach. If you find some bad dependencies that make this complicated I can have a look at it in more detail. いつも頼ることです。 ___ Reply to this item at: http://gna.org/bugs/?13727 ___ 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#40697) Patch adding Traderoute tab in city dialog
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40697 [jmarda...@ifrance.com - Thu Jan 29 18:53:19 2009]: I have made a patch for the gtk client of freeciv adding a TradeRoute tab in the CityDialog. The patch was made on rev 15454 of trunk 3 files attached : - A svn diff patch for updated files (client/gui-gtk-2.0/Makefile.am, client/gui-gtk-2.0/gui_main.c, client/gui-gtk-2.0/citydlg.c) - A new file client/gui-gtk-2.0/trade.c implementing the trade tab - A new file client/gui-gtk-2.0/trade.h for the header As stated in #40710 you need to follow the patch submission guidelines if you want to have someone examine this patch. It's not that we cannot make it work, it's that it will take too long if we need to do this each time. I will close this ticket, and if you want to try again to have this feature included (I do like the idea) you can post a corrected version to the gna bug tracker: https://gna.org/bugs/?func=additemgroup=freeciv --- 走ろう！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40710) Patch adding traderoutes list in Economic report
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40710 I will close this ticket; if you want to try submitting a corrected patch for this feature, please use the gna bugtracker: https://gna.org/bugs/?func=additemgroup=freeciv --- でもすべての店が閉まっている。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13652] Cannot get explanation of mgr_xxx settings
Update of bug #13652 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13652 ___ 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 #13715] [PATCH] Simplify editor copy and paste handling
Update of bug #13715 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13715 ___ 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 #13498] client abort in 2.1.9+ GTK
Follow-up Comment #14, bug #13498 (project freeciv): Can someone using latest S2_1 from svn confirm if this crash still occurs? There were a number of fixes committed in the meantime, in particular one dealing with some nasty potential memory corruption, so the bug might be absent now. そう思うが。 ___ Reply to this item at: http://gna.org/bugs/?13498 ___ 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 #13719] Compilations warnings
Update of bug #13719 (project freeciv): Status:None = Confirmed Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13719 ___ 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 #13727] /detach, /observe and /take are incomplete after the game ended
Update of bug #13727 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13727 ___ 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 #13621] [patch] load game settings from ruleset
Update of bug #13621 (project freeciv):
Severity: 3 - Normal = 2 - Minor
Priority: 5 - Normal = 3 - Low
Status:None = In Progress
___
Follow-up Comment #9:
Please use the bug tracker to post follow up
comments, so that people looking at the tickets
will see the full converstion.
I will take into account your comments and rework all
the settingconfigurations. As I see it, there should
be the following functions (in settings.c?)
bool settings_check(int cmd, union bisval, ...
bool settings_set(int cmd, union bisval, ...
bool settings_send(int cmd)
I would adopt the convention that the class
is 'setting' (since it is 'struct setting') so
the prefix for all functions is setting_ and
the first argument is 'struct setting *' (or
with leading const if the function does not
change the internal state of the setting).
Also maybe 'setting_update' would be a better
name since in 'setting_set' the set is
repeated and this is kind of ugly. set can
also mean a collection of objects in English
so the name might be a little ambiguous. This
is just my personal opinion though.
- int cmd:
number of the command in the settings struct
It is probably better to use 'struct setting *',
since one day settings might not be in a static
array. It's really not that much of a problem,
though if you use the int id approach you
have to transform 'id' - 'struct setting' in
each setting_*() function, whereas if you pass
the struct pointer you do not have to reference
the global array in each function (or call a
function that does).
- union bisval:
bool/int/string value for the option
Why not 'union setting_value'? This would clearly
indicate what it is used for, and the individual
field names would tell you the underlying types.
I don't think someone seening bisval for the
first time would have any idea what it means.
- char *msgstr:
return message by the function (error/success;
only displayed if length 0)
- int *msglen
length of msgstr
Alright, but check if these are always necessary.
Maybe some of the setting_*() won't need them.
should there also be a function
struct settings *op = settings_get(int cmd)?
If you take the int id approach, though with
the better setting pointer method you would
just change the parsing function to return the
setting pointer.
Maybe if you find that 'int cmd' has an overloaded
meaning as a command id (for 'struct command'),
you can go with the id approach. I do recall some
ugliness in stdinhand where some function returns
an int value that could be either a setting id or
a command id (help_command?); if it is too much
trouble to fix this too then just use ids.
Some questions:
Am Thursday 18 June 2009 03:45:29 schrieb Madeline Book:
- Sometimes you cmd_reply (= notify_conn) in the
set_command_*() function, and sometimes you
notify_conn in its caller; in other words, what
is the point of passing 'pastr' if you just
cmd_reply inside it anyway.
that is the difference between cmd_reply and notify_conn?
From the comments to
cmd_reply I take that it does not duplicates output on the
console? Should
this be used for calls from the command line?
cmd_reply prefixes the message with /commandname:,
and echos to the server console if 'caller' is NULL
(i.e. when the server operator enters the command).
To be consistent, just use cmd_reply in all server
command functions ('*_command()') unless you need
to send some special message to connected users
like Server: Exploding. which the server operator
would already know about in some other way.
Otherwise use freelog() if you just want to print
some information to the console.
Maybe this business of echoing or not echoing to
the console should be examined and cleaned up too,
but that can be in another ticket.
Should this function(s) be called every time something
should be printed or at the end one time to print all
text (especially for the rulesets)?
Ruleset loading should use freelog() to tell the
server operator what is going on, and only send
a message if it succeeds or fails to users (this
is already done by the rulesetdir command I think).
Actually I don't recall that regular freeciv can
gracefully fail loading a ruleset, it just dies.
So any error messages from the setting_*()
functions would be only advisory, and should
probably only be echoed to the console with
freelog(LOG_ERROR, ...).
- You replace the fast pointer checks with slow
string comparisons (strcmp(op-name,...)) for
no reason (yes we can debate which is better
but the fact is that both depend on some hard-
coded name, be it either the string name or
the variable name, so you do not gain anything
by changing it).
So the following line tests, if it points to the same
place in memory? At first I thought
[Freeciv-Dev] [bug #13719] Compilations warnings
Update of bug #13719 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13719 ___ 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 #13587] [patch] add upkeep information to units in city dialog
Update of bug #13587 (project freeciv): Status: In Progress = Postponed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13587 ___ 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 #13727] /detach, /observe and /take are incomplete after the game ended
Follow-up Comment #1, bug #13727 (project freeciv): Do we really need to send_diplomatic_meetings() after the game is over? 終わりの後には外交対話できるか。 ___ Reply to this item at: http://gna.org/bugs/?13727 ___ 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 #13713] [PATCH] Agent calls are never equal if they are to different agents
Update of bug #13713 (project freeciv): Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13713 ___ 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] [PATCH] Fix-type-of-argument-extracted-from-varargs-list
On 17/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: I found my agent crashing on tile-related callbacks. Turns out handle_tile_info() was passing a struct tile *, but enqueue_call() was taking x and y coordinates. This couldn't have helped the core dumps and memory corruption referred to in http://thread.gmane.org/gmane.games.freeciv.cvs/6285, but that's so 2004 I don't know if that's relevant here. Certainly taking two args from a va_list when only one exists there is not a good thing! Thanks for tracking this down, I'll test it and commit it as soon as possible. その機械は一体どうやって動けます。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13714] [PATCH] Fix type of argument extracted from varargs list.
URL: http://gna.org/bugs/?13714 Summary: [PATCH] Fix type of argument extracted from varargs list. Project: Freeciv Submitted by: mbook Submitted on: Wednesday 06/17/2009 at 17:31 Category: agents Severity: 4 - Important Priority: 7 - High Status: Confirmed Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Reposted from freeciv-dev: On 17/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: I found my agent crashing on tile-related callbacks. Turns out handle_tile_info() was passing a struct tile *, but enqueue_call() was taking x and y coordinates. This couldn't have helped the core dumps and memory corruption referred to in http://thread.gmane.org/gmane.games.freeciv.cvs/6285, but that's so 2004 I don't know if that's relevant here. I made a slight adjustement to your patch, namely the trunk version uses the wrapper tile_index(), and the 'const' is written before the typename, in keeping with the general convention in use in the freeciv codebase. システムの中でメモリを破壊します〜 ___ File Attachments: --- Date: Wednesday 06/17/2009 at 17:31 Name: trunk-fix_agent_va_list_corruption.diff Size: 700B By: mbook http://gna.org/bugs/download.php?file_id=5987 --- Date: Wednesday 06/17/2009 at 17:31 Name: S2_1-fix_agent_va_list_corruption.diff Size: 695B By: mbook http://gna.org/bugs/download.php?file_id=5988 ___ Reply to this item at: http://gna.org/bugs/?13714 ___ 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 #13715] [PATCH] Simplify editor copy and paste handling
URL: http://gna.org/bugs/?13715 Summary: [PATCH] Simplify editor copy and paste handling Project: Freeciv Submitted by: mbook Submitted on: Wednesday 06/17/2009 at 18:23 Category: editor Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: mbook Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Attached patch changes the way the copy and paste operation in the editor is handled: instead of having copy and paste modes for each tool, a separate copy and paste tool is added, and this is the only tool that supports copy and paste modes. Although this makes it copy and paste everything on a tile, it should be straight forward to later add the ability to select only a subset of the object types for copying/pasting. 木星から来て液晶を常食としている生命体かもしれない。 ___ File Attachments: --- Date: Wednesday 06/17/2009 at 18:23 Name: simplify_copypaste.patch Size: 15kB By: mbook http://gna.org/bugs/download.php?file_id=5989 ___ Reply to this item at: http://gna.org/bugs/?13715 ___ 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] how to use git locally for freeciv
On 17/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: On Thu, Jun 18, 2009 at 12:54 AM, Matthias Pfafferodtmatthias.pfaffer...@mapfa.de wrote: at the moment I use svn to work with the freeciv code. For each patchset I create a copy of the svn repo using 'cp -lr'. It is not the best way but working ... How would I'm using git (my own local git repo) for the freeciv source code? I found git-svnimport and also more than enough web sides to explain git. But how to handle different patchsets? Create a new branch for each? Up to now I used cvs on my own projects (only one user) but with the freeciv code it is kind of confusing, especially rebasing to the up-to-date svn. My experience (we did it with git-svn here at work) is that it's a bit of an impedance mismatch; svn's limitations impose limitations on how you use git (I don't know if git-svnimport is any better): merges seem to make SVN go WTF? and freak out. Although I've never tried, I guess you could use a separate branch for each patchset, if you take care with how you bring it back into SVN. Separate branches is what I use with git-svn, making a new branch whenever I need to build on changes not yet in the main branch (i.e. trunk, S2_1, etc.). As a contributor one has to submit patches for inspection anyway, so when I do go to commit something, I just checkout the destination branch, apply the previously posted patch file, commit to git, then dcommit with git-svn. Unfortunately since the underlying repo is still svn, we cannot use the powerful branch merging features of git. :( A while ago I wrote a mini intro to using git with freeciv svn: https://mail.gna.org/public/freeciv-dev/2008-03/msg00048.html Though that was over a year ago and I'm sure that some git commands have changed since then (if something fails check the updated docs). As a matter of convenience I have a separate git repository for S2_1, since there are many autoconf/packet related changes which would require a complete ./autogen.sh make whenever switching to trunk. I also like having a bunch of shell aliases for commonly used command sequences: alias gb='git branch' alias gba='git branch -a' alias gci='git commit -v' alias gco='git checkout' alias gd='git diff' alias gdc='git diff --color' alias gdci='git-svn dcommit' alias gl='git log' alias glt='git log --pretty=format:%s%n%n%b' alias gps='git push' alias gpu='git pull' alias gr='git reset' alias greb='git-svn rebase' alias gsh='git show' alias gshc='git show --stat -p --color' alias gst='git status' Using git branches is much more space efficient than copying the svn repo each time, and incomparably faster. This was actually the main reason I learned to use git a long time, though git has many more advantages beyond just that. ;) あなたも同化される。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13652] Cannot get explanation of mgr_xxx settings
Update of bug #13652 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #1: Minimal patchfix. Is there really any current reason to keep the 'explain' command around? 退化器官のようですね。 (file #5992) ___ Additional Item Attachment: File name: fix_explain_underscore_bug.diff Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?13652 ___ 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 #13587] [patch] add upkeep information to units in city dialog
Follow-up Comment #8, bug #13587 (project freeciv): Updated to recent trunk. 逃げ出してるよ！ (file #5993) ___ Additional Item Attachment: File name: version6-13587-gold6.patch.diff Size:9 KB ___ Reply to this item at: http://gna.org/bugs/?13587 ___ 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 #13621] [patch] load game settings from ruleset
Follow-up Comment #8, bug #13621 (project freeciv):
version 5; changes:
Some slight problems with this version:
- A better name would be load_ruleset_game_settings().
- 'astr' should not be static.
- 'astr' should not even be an astring, a stack
allocated char array would suffice (just pass its
maximum size too).
- It's hard to figure out what 'pastr' is used for,
it is neither documented in any function header nor
named according to its use.
- The LOG_VERBOSE messages really should be LOG_DEBUG.
- The critical send_server_setting() ...
send_server_info_to_metaserver() part is duplicated
3 times.
- Names of enum set_cmd_type are vague and belong to
different categories; they need to be at least
documented (e.g. above the enum declaration) so
that programmers know what they are supposed to mean.
- Overuse of SCMD_* makes the codepath of set_command_*()
hard to follow, i.e. parametrizing the behaviour
in that way makes it harded to understand.
- Sometimes you cmd_reply (= notify_conn) in the
set_command_*() function, and sometimes you
notify_conn in its caller; in other words, what
is the point of passing 'pastr' if you just
cmd_reply inside it anyway.
- You replace the fast pointer checks with slow
string comparisons (strcmp(op-name,...)) for
no reason (yes we can debate which is better
but the fact is that both depend on some hard-
coded name, be it either the string name or
the variable name, so you do not gain anything
by changing it).
- You do not have to explicitly convert bool to
int and vice versa in function arguments.
- You (probably) should not be calling send_*()
functions while a ruleset is being loaded.
If any of the above is unclear or you do not know
why it would be a problem, ask and I will try to
elaborate on it.
My suggestion is to factor out into separate
functions [by factor out I mean take the duplicated
code and put it in one place so there is only one
copy, not make 3 copies; cf. 2x + xy + 3xz =
x(2 + y + 3z)]:
- setting value checking with bool return indicating
success and error message buffer for reason:
bool setting_check(const struct setting *op,
int ibval, const char *sval, char *err, int errlen)
with 'ibval' taking the bool or int value, and 'sval'
taking a pointer to the new string, when applicable.
Probably a nicer approach would be to use a union:
union setting_data {
int v_int;
bool v_bool;
const char *v_str;
};
but the one unused argument is good enough, and besides
if you were to use the union you might as well rewrite
the entire setting handling code to make use of it
(it would probably be a lot better as a result).
- setting updating:
bool setting_update(...)
which would be clearly marked as not doing any error
checking (this should be handled by check()). Probably
you should not handle the side-effects here, since this
pollutes a nice low level function with high level
dependencies. Probably a separate ticket should be
made to remove the side-effects completely (e.g. aifill
should be a command, not a setting, but this needs
to be more closely examined).
- maybe reading from a secfile:
bool setting_load_from_secfile(...)
it can take a secfile prefix (i.e. the game.) so as
to be slightly more general, and would probably
make use of check() and update().
Of course if you start to use the above approach
and it turns out to be worse than what you already
have, feel free to ignore my suggestions. :)
Really I would have been happy to commit the last
version, since if you dig much deeper into this
code you will probably end up making a substantial
rewrite. It's up to you if you want to continue
with this less than exciting stuff or just leave
it for later...
もっともっと深く巻き込まれてしまった。
___
Reply to this item at:
http://gna.org/bugs/?13621
___
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 #13713] [PATCH] Agent calls are never equal if they are to different agents
Update of bug #13713 (project freeciv): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13713 ___ 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 #13714] [PATCH] Fix type of argument extracted from varargs list.
Update of bug #13714 (project freeciv): Status: Confirmed = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13714 ___ 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] [PATCH] Agent calls are never equal if they are to different agents
On 15/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: On Tue, Jun 9, 2009 at 3:44 AM, Madeline Bookmadeline.b...@gmail.com wrote: You should know that the agents framework suffers from a number of design problems and has not been actively maintained by anyone in a long time, the original author no longer begin involved in freeciv development and nobody else really interested in learning how it should work or how to fix it and make use of it. Could you elaborate please? I haven't been subscribed in a few years so I'm not up-to-date with current memes. You don't need to do my homework for me; I'm just looking for *what* to look for. Design problems worries me, if I'm going to be depending on agent callbacks. For cma in particular: it is slow (no CPU computation should take longer than a second; the algorithm does not scale), inefficient (too much client-server communication making it unwieldy in online games), does not adapt well to non-default game rules (the ugly cross-dependence of common/ files and untested behavior for other rulesets), and fails to accomodate even basic game situations that occur again and again (no way to prevent greedy tile grabbing, no way to fix tile usage, recomputation right at the very moment when client needs to be responsive, etc., etc.). (I mention in passing that the entire attribute system should be removed, and probably would have been long ago, were it not for the single annoying dependence of the cma on it.) Every potential agent implementation must consider whether it fails in the above mentioned respects at least. In general there is also the question whether client side automation afforded by agents is even desirable for freeciv, as then it may degenerate in to battle of computer programs rather than players. For example in the case of the city worker twiddling problem that cma tries to alleviate (player does not have to micro-manage citizens, in theory), one should also consider fixing the design of the game itself. That is, instead of throwing AI at the game problem, consider finding and proposing better game mechanics that would not suffer the same player annoyances. Then there is the current problem of agent implementations almost always requiring to keep track of some form of state between activations, but the design of freeciv packets makes this quite cumbersome at best (cf. the request id hacks used by cma). In brief, there is poor support for stateful client side programming (other parts of freeciv suffer from this too, and I have a solution in mind, but have not yet had time to make a test implementation). Finally I would just like to mention lua as a much better candidate for work than the agents framework. Extending and implementing all non-resource intensive code in a lua engine would do wonders for AI programming, both on the server and the client side. At least so my dream goes, assuming that the lua integration is done right. ;) All that said, if you are some programming wizard and have already made some significant improvements to the agents system and implemented some useful features, feel free to post your patches for possible inclusion in the development version; at least we would have something more fruitful and concrete to discuss rather than past mistakes and vague generalities. 何かがモニターのピクセルを一つずつ食べてしまう。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13621] [patch] load game settings from ruleset
Follow-up Comment #5, bug #13621 (project freeciv): The attached version has some minor style and formatting improvements and is more or less good enough to commit, I think. There is though the obvious problem that ruleset_set_cmd() does not handle setting side-effects like the set_command() function does. Really what should be done is to factor out the changing of the setting's value into a separate function that is called by both of them. So set_command() would parse its command line and call the function, and ruleset_set_cmd() would parse the [game] section of the section file and call the function. Thus the special side-effects would be handled in just one place by design. But this can be left for another patch (this patch adds the appropriate FIXMEs as future reminders). トイレの上の天井に掛けてある。 (file #5931) ___ Additional Item Attachment: File name: version4-13621-set.patch.diff Size:7 KB ___ Reply to this item at: http://gna.org/bugs/?13621 ___ 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 #13587] [patch] add upkeep information to units in city dialog
Follow-up Comment #7, bug #13587 (project freeciv): I made some minor improvements to your patch, see the attached version. This would be the version that I commit, if nobody sees anything wrong with it. I made unit_description() only append the upkeep information if the unit is owned by the client's player, in keeping with our discussion in other tickets. Other than that, I just improved the comments a bit and fixed the formatting of unit_activity_astr(), since it was already mostly re-written anyway. 批評を恐れないで。 (file #5930) ___ Additional Item Attachment: File name: version5-13587-gold6.patch.diff Size:9 KB ___ Reply to this item at: http://gna.org/bugs/?13587 ___ 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] Bug dans v. 2.1.5-2 ?
On 08/06/2009, Alexis Scheuer alexis.sche...@free.fr wrote: Bonjour. Je tiens à vous indiquer un soucis que j'ai rencontré avec FreeCiv v. 2.1.5-2 sous Ubuntu 8.10, auquel je joue en local avec des IA. Je dois avoir des fichiers de sauvegarde vérolés : tout marche avec une sauvegarde plus ancienne. Par contre, avec les sauvegardes en question, j'ai comme soucis : - des unités et des villes obéissant à des ordres que je n'ai pas donnés (mouvement, production), - un affichage étrange (un ~ jaune près de certaines unités), - un comportement bizarre de l'IHM (perte du passage automatique d'une unité à la suivante lorsqu'on donne un ordre, besoin de taper sur l'espace). Il suffit de faire /away apres chargement de la sauvegarde. Toutes les problemes que vous avez la c'est a cause d'un bug dans les anciennes versions de freeciv ou le jouer est automatiquement permuter entre mode IA lorsqu'une sauvegarde est chargee. Donc vous pouvez aussi reprendre la nouvelle version (2.1.9 dans laquelle le bug est corrige) pour eviter le probleme. 何だか今バゲットを食べたいような気がする。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13652] Cannot get explanation of mgr_xxx settings
Update of bug #13652 (project freeciv): Category:None = general Assigned to:None = mbook ___ Reply to this item at: http://gna.org/bugs/?13652 ___ 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 #13653] [patch] Help for Research Lab implies that University not required
Update of bug #13653 (project freeciv): Status:None = Duplicate Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13653 ___ 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] [PATCH] Agent calls are never equal if they are to different agents
On 08/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: While trying to add an agent, I've found this patch necessary. This is against 2.1.9, as I have nothing closer to HEAD available. Your patch looks alright, as far as I can tell and as far as I know about the intended behaviour of calls_are_equal() (should it care if the agent serving the calls is different?). Well, except for false which should be FALSE. You should know that the agents framework suffers from a number of design problems and has not been actively maintained by anyone in a long time, the original author no longer begin involved in freeciv development and nobody else really interested in learning how it should work or how to fix it and make use of it. BTW, does anyone maintain a (read-only) git mirror? SVN just isn't an option for me. I seem to be the only maintainer using git, and I would second a notion to setup a git mirror. Maybe I will at repo.or.cz, if I feel like it later. In the meantime I just use git-svn and I suggest you do the same (I know it is kind of a pain to setup). By the way, submit your patches to the new bug tracker: https://gna.org/bugs/?func=additemgroup=freeciv 私はガス状惑星で生まれたんだよ。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40809) connexion
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40809 [ugo.degri...@yahoo.fr - Sun Jun 07 18:41:23 2009]: I try to connect to the bugtracker of freeciv but the guest account with the password doens't work. can I have an account or maybe can I submit the bug elsewhere ? Use the gna bugtracker: https://gna.org/bugs/?func=additemgroup=freeciv --- まるで罠のようですね。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13586] [patch] economic report (was PR#40763) - help needed
Update of bug #13586 (project freeciv): Status: In Progress = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13586 ___ 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#40767) Revert resource identifiers and remove update22* fields
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40767 [cazf...@gmail.com - Sat Jun 06 18:41:15 2009]: 2009/4/13 Madeline Book madeline.b...@gmail.com: [guest - Mon Apr 13 18:37:54 2009]: I've created and tested a rollback patch, which removes all update22* references/code and revert back resource identifiers to the 2.1.x default. - Stéphane Messerli Also the terrain.ruleset files in the civ1 and civ2 ruleset directories need to be updated. I'll test it with recent and older savegames once these changes are made. Probably savegames already made in 2.1.99 will become incompatible, but that was to be expected. Hopefully this will be the only drawback. Do you want me to handle this patch, or are you going to do it soon? If you feel like it and have time now you can do it. --- 好きにしてください。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13586] [patch] economic report (was PR#40763) - help needed
Follow-up Comment #6, bug #13586 (project freeciv): The extra 'upkeep_info' field is needed for homeless units because even for the player who owns them they have no upkeep. Would it be so bad just to show zero upkeep for those units? Are there any other circumstances when the extra boolean field would be needed? if the editor is used the changes are visible in the next turn. I'm not sure, how to force an update. Possibly there should be some more city refreshes after editor actions. Could you give more details about what editor actions you used that caused the upkeep values to not show correctly? 援助すればいいだろう。 ___ Reply to this item at: http://gna.org/bugs/?13586 ___ 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 #13643] [RFC] Use lua for customizable database access
URL: http://gna.org/bugs/?13643 Summary: [RFC] Use lua for customizable database access Project: Freeciv Submitted by: mbook Submitted on: Sunday 06/07/2009 at 04:44 Category: general Severity: 3 - Normal Priority: 3 - Low Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: I propose that the current auth code and all future database interfacing code be written in lua scripts. This would have the following advantages: - No need to recompile to change the way the database is used (e.g. table field names, sql statment format, etc.). - Support for databases other than mysql. - Easily extended beyond just auth. For example longturn currently uses postgresql instead of mysql, and warclient servers use password salt. The lua database bindings are provided by LuaSQL (http://www.keplerproject.org/luasql/). It would be added to the 'dependencies' directory, with specific driver libraries only being compiled and linked to the main server executable if the corresponding database is detected by configure. As a first step the lua integration would proceed by combining much of the functionality of the functions authenticate_user process_authentication_status handle_authentication_reply into a single script entry point (i.e. a function that is expected to exist in the database script). A stand-alone lua state is created for this script in auth_init(). The lua function will need to return a status value indicating how the connection should be handled (e.g. 'accept', 'wait', 'reject'). The script would need to be able to manipulate 'user' objects, which correspond to 'struct connection'. Methods should be provided which allow access to at least 'id', 'name' and 'password' information. An alternative would be to pass the required information to the script function each time it is invoked. Possibly all auth string occurences in the code and in filenames should be changed to database, in preparation for future generalization. I'll clarify and revise the details as I test out a tentative implementation (though this will not be very high priority for a while). 誰かが月を一口食いちぎたようだ。 ___ Reply to this item at: http://gna.org/bugs/?13643 ___ 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 #13621] [patch] load game settings from ruleset
Update of bug #13621 (project freeciv):
Assigned to:None = mbook
___
Follow-up Comment #3:
A better and more c compiler friendly style would
be to either declare the variables before the switch
statement, or use braces around the cases:
case SSET_BOOL:
{
bool val_bool;
...
break;
}
Personally I would rather prefer the former:
{
bool bval;
int ival;
const char *sval;
switch (op-stype) {
case SSET_BOOL:
bval = ...
Please use one of these two styles, and not the
strange {} /* no error */ thing.
規則に従わなければなりません。
___
Reply to this item at:
http://gna.org/bugs/?13621
___
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 #13587] [patch] add upkeep information to units in city dialog
Follow-up Comment #4, bug #13587 (project freeciv): Alright, I was not sufficiently clear in my last comments, so I will explain what I meant. I wanted you to change unit_upkeep_text() to take an astring parameter: void unit_upkeep_text(const struct unit *punit, struct astring *astr); and have the function append its text to the end of 'astr', if it should add any text at all (i.e. if the client's player is not the unit owner, it would not add anything). The point is to avoid static variables, because they make the code non re-entrant. This means that it would not be safe to use this code with threads, or even to call this function twice in the same expression (e.g. in the arguments of a printf style function). While freeciv does not use threads, making code re-entrant generally results in a cleaner and more modular design, as well as leaving the possibility of thread use open for the future. Also, do not include headers in other headers (as I have told you in another ticket, sorry if I repeat myself :)). When you have a pointer to some undefined struct, you can just use a forward declaration: struct astring; void unit_upkeep_text(const struct unit *punit, struct astring *astr); then include the real header in the c file where the function is implemented. というわけです。 ___ Reply to this item at: http://gna.org/bugs/?13587 ___ 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 #13586] [patch] economic report (was PR#40763) - help needed
Follow-up Comment #4, bug #13586 (project freeciv): I think we can safely adopt the convention that upkeep information will only be available for the player's own units. So we do not need the extra 'upkeep_info' boolean field; just check that the owner is the same the client's player. if the editor is used the changes are visible in the next turn. I'm not sure, how to force an update. Possibly there should be some more city refreshes after editor actions. もう少しだ。 ___ Reply to this item at: http://gna.org/bugs/?13586 ___ 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 #13621] [patch] load game settings from ruleset
Follow-up Comment #1, bug #13621 (project freeciv):
Some basic things I noticed looking at the
patch:
You can just use the simpler
for (op = settings; op-name; op++)
instead of 'do {} while' to iterate over
settings. (Maybe there should be a settings
_iterate macro.)
You probably do not need to send info to
clients (if that is what you mean by update
in load_ruleset_game_set()) since there will
be a send_game_info() some time after. But
check this please.
You do not need the 'bool check' argument
to ruleset_set_cmd().
You do not need the '{} /* no error */' stuff.
Instead of looking up the value twice in
order to check that it exists, just pass in
the op's current value the first time. So:
val_bool = secfile_lookup_bool_default(pfile, *op-bool_value, game.%s,
op-name);
if (val_bool == *op-bool_value) {
...
and similarly for the other setting types
(of course strcmp for strings).
Do not declare and initialize variables over
case labels in a switch statement. Declare
them all in the enclosing scope of the switch
statement, or right after the starting brace of
the switch (before cases), or make a new scope
in each case where you need new variables.
Do not add header includes to other headers
unless there really is no way to avoid it.
In this case please just include fc_types.h in
the c file, not in ruleset.h.
厳しいだが、不公平ではない。
___
Reply to this item at:
http://gna.org/bugs/?13621
___
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 #13583] [patch] shield2gold_basics (was PR#40761)
Update of bug #13583 (project freeciv): Status: In Progress = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13583 ___ 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 #13585] [patch] shield2gold_units (was PR#40762)
Update of bug #13585 (project freeciv): Status: In Progress = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13585 ___ 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 #13542] [Patch] Game scenario properties in property editor
Update of bug #13542 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13542 ___ 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 #13543] [Patch] Sanitize strings in object list columns
Update of bug #13543 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13543 ___ 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 #13546] [Patch] Always select first object in property editor object list
Update of bug #13546 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13546 ___ 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 #13550] [Patch] Property editor widget overhaul
Update of bug #13550 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13550 ___ 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 #13525] [Patch] Scrollable options window
Update of bug #13525 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13525 ___ 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 #13540] [Patch] Enable/disable GObject signal callbacks
Update of bug #13540 (project freeciv): Status: Ready For Test = Confirmed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13540 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
