From leaf at real-time.com Wed Apr 2 16:14:16 2014 From: leaf at real-time.com (Rick Tanner) Date: Wed, 02 Apr 2014 16:14:16 -0500 Subject: [crossfire] 'svn:externals' pointers to stable/next/latest In-Reply-To: <5339F2D5.7090807@gmail.com> References: <5339F2D5.7090807@gmail.com> Message-ID: <533C7DA8.1080909@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unless someone speaks up on reasons to keep them or other ideas in the next week or so, I say proceed with your suggestions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTPH2KhHyvgBp+vH4RAmYLAJ4mcAd1j6NXjwDgvJ0U8iD2poKemACgqSIt r/EvRsF7FOGxNimVz+iI1do= =haUO -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Sat Apr 5 08:26:14 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 5 Apr 2014 15:26:14 +0200 Subject: [crossfire] 'svn:externals' pointers to stable/next/latest In-Reply-To: <533C7DA8.1080909@real-time.com> References: <5339F2D5.7090807@gmail.com> <533C7DA8.1080909@real-time.com> Message-ID: <201404051526.18943.nicolas.weeger@laposte.net> Agreed, feel free to clean up stuff :) Regards Nicolas Le mercredi 2 avril 2014 23:14:16, Rick Tanner a ?crit : > Unless someone speaks up on reasons to keep them or other ideas in the > next week or so, I say proceed with your suggestions. > > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Tue Apr 8 18:45:29 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Tue, 08 Apr 2014 18:45:29 -0500 Subject: [crossfire] Crossfire 1.71.0 Released Message-ID: <53448A19.6010805@gmail.com> The Crossfire Development Team is pleased to announce the 1.71.0 release. Highlights in this release include: - Per-character keybindings in the GTKv2 client - Fixed sound support in the GTKv2 client - Retirement of the 'crossfire-config' build parameter dumper - New pixmaps for many objects, including jewelry and more - Faster server input parsing - Many, many, many bug fixes For a complete list of new features and bug fixes, please see the online ChangeLog on SourceForge. Availability: Crossfire is available on SourceForge (and its various mirrors). http://sourceforge.net/projects/crossfire/files/ Binary packages are not yet available and will be released when they are ready. 'crossfire-client-1.71.0.tar.bz2' contains the source distribution for the client. If you want to play, this is the only piece you need. 'crossfire-client-images-1.71.0.tar.bz2' contains client images and graphics. This prevents the client from having to request image data from the server. It is optional but recommended if you have a slow Internet connection. 'crossfire-client-sounds-1.71.0.tar.bz2' contains sound effects. This has changed since the 1.70.0 release. Of course, it is optional. 'crossfire-1.71.0.tar.bz2' contains the server source distribution as well as pre-generated archetype and image files. If you are running a server, you need this. 'crossfire-1.71.0.arch.tar.bz2' contains the unpacked archetypes and pixmaps. This is only required if you are planning to make changes to game objects and is not needed to run a server or play the game. 'crossfire-1.71.0.maps.tar.bz2' contains the map distribution. If you are running a server, you need this. Checksums: MD5 (crossfire-1.71.0.arch.tar.bz2) = 284a269840492e45761ea786a86e48ec MD5 (crossfire-1.71.0.maps.tar.bz2) = 71b9d6da7c2d547de0695808e319cfa5 MD5 (crossfire-1.71.0.tar.bz2) = bc58e01b1266785e85c58f6710ccc13f MD5 (crossfire-client-1.71.0.tar.bz2) = a32b9a3cb42f65820c5a9193dcfa56d5 MD5 (crossfire-client-images-1.71.0.tar.bz2) = 91e9ad93276be1565d190fccdcfb810d MD5 (crossfire-client-sounds-1.71.0.tar.bz2) = 3c9b8045231d4f861986b76b1bfde328 Kevin Zheng April 5, 2014 From kevinz5000 at gmail.com Sat Apr 12 23:12:20 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 12 Apr 2014 23:12:20 -0500 Subject: [crossfire] Bug tracker group searches Message-ID: <534A0EA4.5060507@gmail.com> Hi there, Since the bug/feature/patch trackers switched to the new tracker states, the group searches have been left unchanged. To make these states more useful, I would like the following searches: - New (bugs that are "open") - In progress ("feedback", "analyzed", or "patched") - Closed (but NOT "suspended") - Suspended (but NOT "closed") In addition, the milestones should be updated: - 1.11 and 1.12 should be closed - 1.x_next+trunk should be removed - Add milestones for 1.72.0 and 1.71.1? - Maybe re-open the "2.x" milestone for really-distant changes? Somebody with bug tracker modification permissions should make these changes. The current milestones/searches are meaningless/broken anyways. Thanks, Kevin Zheng From leaf at real-time.com Sun Apr 13 00:02:26 2014 From: leaf at real-time.com (Rick Tanner) Date: Sun, 13 Apr 2014 00:02:26 -0500 Subject: [crossfire] Bug tracker group searches In-Reply-To: <534A0EA4.5060507@gmail.com> References: <534A0EA4.5060507@gmail.com> Message-ID: <534A1A62.7050608@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/12/14 11:12 PM, Kevin Zheng wrote: > > Since the bug/feature/patch trackers switched to the new tracker > states, the group searches have been left unchanged. To make these > states more useful, I would like the following searches: > > - New (bugs that are "open") - In progress ("feedback", "analyzed", > or "patched") - Closed (but NOT "suspended") - Suspended (but NOT > "closed") Can be done, the syntax to do so is like this.. Open Tickets: !status:closed-wont-fix && !status:closed-rejected && !status:closed-out-of-date && !status:closed-postponed && !status:closed-accepted && !status:closed-remind && !status:closed-works-for-me && !status:closed && !status:closed-duplicate && !status:closed-invalid && !status:closed-fixed Further info on the syntax: http://www.solrtutorial.com/solr-query-syntax.html I could use some guidance on how to reconfigure the fields though for the new search terms. > In addition, the milestones should be updated: - 1.11 and 1.12 > should be closed - 1.x_next+trunk should be removed - Add > milestones for 1.72.0 and 1.71.1? - Maybe re-open the "2.x" > milestone for really-distant changes? Sounds good and reasonable. Milestones updated, let me know if anything else should be changed in this regard. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTShpZhHyvgBp+vH4RAu1SAKCYPmdddfK7aFHgKtyuhOORop9FZACg7qOq UC/EVu2t3sEev/S2BQWYb6A= =PjLJ -----END PGP SIGNATURE----- From kaol at debian.org Sun Apr 13 05:14:26 2014 From: kaol at debian.org (Kari Pahula) Date: Sun, 13 Apr 2014 13:14:26 +0300 Subject: [crossfire] Building crossfire 1.71.0 server fails without arches Message-ID: <20140413101426.GA15799@sammakko3.piperka.net> Hi. Crossfire 1.71.0 server is unbuildable without the arch directory. Here's what happens in lib/ directory (from make -d's output): Considering target file `smooth'. Considering target file `.collect-stamp'. File `.collect-stamp' does not exist. Finished prerequisites of target file `.collect-stamp'. Must remake target `.collect-stamp'. touch .collect-stamp Putting child 0x01251550 (.collect-stamp) PID 15874 on the chain. Live child 0x01251550 (.collect-stamp) PID 15874 Reaping winning child 0x01251550 PID 15874 Removing child 0x01251550 PID 15874 from chain. Successfully remade target file `.collect-stamp'. Finished prerequisites of target file `smooth'. Prerequisite `.collect-stamp' is newer than target `smooth'. Must remake target `smooth'. touch .collect-stamp Putting child 0x012744c0 (smooth) PID 15875 on the chain. Live child 0x012744c0 (smooth) PID 15875 Reaping winning child 0x012744c0 PID 15875 make collect ... Considering target file `collect'. File `collect' does not exist. Finished prerequisites of target file `collect'. Must remake target `collect'. make[1]: Entering directory `/home/kaol/deb/crossfire/crossfire-1.71.0/lib' /usr/bin/perl -I. collect.pl ./arch Putting child 0x013c6600 (collect) PID 15877 on the chain. Live child 0x013c6600 (collect) PID 15877 collect.pl: looking ... couldn't open ./arch at collect.pl line 500. Reaping losing child 0x013c6600 PID 15877 make[1]: *** [collect] Error 2 Here's the relevant rules from lib/Makefile.am: .collect-stamp: touch .collect-stamp collect: $(PERL) -I$(srcdir) collect.pl $(builddir)/arch $(PERL) $(srcdir)/adm/collect_images.pl -src $(srcdir) -png archetypes faces animations bmaps.paths smooth: .collect-stamp touch .collect-stamp $(MAKE) collect install-data-local: archetypes crossfire.0 faces animations smooth collect.pl util.pl In short, install-data-local requires smooth, which requires .collect-stamp, which gets created with touch. Then smooth's rule decides that smooth needs to be regenerated since .collect-stamp is fresher than smooth, making the build fail since there's no arch directory. This would work if there was a lib/.collect-stamp with a correct timestamp included with the server package, but there isn't. I could suggest that it wouldn't be a dot file since it wouldn't get waylaid so easily then. But this part would, IMHO, work even better without using a stamp file at all. The collect.pl script generates a fairly limited set of files and you had listed them already in the Makefile.am file itself. I'm not sure how make -jn friendly the current code is, either. I ran into this while packaging 1.71.0 for Debian. I worked around it by calling touch -t 197001010101 lib/.collect-stamp before building the server. From kevinz5000 at gmail.com Sun Apr 13 10:36:22 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 13 Apr 2014 10:36:22 -0500 Subject: [crossfire] Building crossfire 1.71.0 server fails without arches In-Reply-To: <20140413101426.GA15799@sammakko3.piperka.net> References: <20140413101426.GA15799@sammakko3.piperka.net> Message-ID: <534AAEF6.4000401@gmail.com> Hi Kari, On 04/13/2014 05:14, Kari Pahula wrote: > Crossfire 1.71.0 server is unbuildable without the arch directory. > Here's what happens in lib/ directory (from make -d's output): > > In short, install-data-local requires smooth, which requires > .collect-stamp, which gets created with touch. Then smooth's rule > decides that smooth needs to be regenerated since .collect-stamp is > fresher than smooth, making the build fail since there's no arch > directory. Thanks for going through all the trouble to figure out what's wrong. It is indeed a missing dependency-tracking file ('lib/.collect-stamp') in the distfile. I must have missed it when creating the tarballs. > This would work if there was a lib/.collect-stamp with a correct > timestamp included with the server package, but there isn't. I could > suggest that it wouldn't be a dot file since it wouldn't get waylaid > so easily then. But this part would, IMHO, work even better without > using a stamp file at all. The collect.pl script generates a fairly > limited set of files and you had listed them already in the > Makefile.am file itself. I'm not sure how make -jn friendly the > current code is, either. The current archetype collection process is hackish and fails when running with multiple build jobs. I was thinking that the collection process should be moved out of the server build process altogether. > I ran into this while packaging 1.71.0 for Debian. I worked around it > by calling touch -t 197001010101 lib/.collect-stamp before building > the server. This workaround also works for packaging on FreeBSD. Do you think I should roll a new tarball with '.collect-stamp' included? Thanks, Kevin Zheng From kevinz5000 at gmail.com Sun Apr 13 11:01:40 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 13 Apr 2014 11:01:40 -0500 Subject: [crossfire] Bug tracker group searches In-Reply-To: <534A1A62.7050608@real-time.com> References: <534A0EA4.5060507@gmail.com> <534A1A62.7050608@real-time.com> Message-ID: <534AB4E4.1040002@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2014 00:02, Rick Tanner wrote: > Open Tickets: > > !status:closed-wont-fix && !status:closed-rejected && > !status:closed-out-of-date && !status:closed-postponed && > !status:closed-accepted && !status:closed-remind && > !status:closed-works-for-me && !status:closed && > !status:closed-duplicate && !status:closed-invalid && > !status:closed-fixed > > Further info on the syntax: > http://www.solrtutorial.com/solr-query-syntax.html > > I could use some guidance on how to reconfigure the fields though > for the new search terms. These would be useful for me: New - status:open Progress - status:analyzed || status:feedback-needed || status:patched Suspended - status:suspended Closed - status:closed Feel free to rename them to whatever makes more sense. Thanks, Kevin Zheng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTSrTkAAoJEOrPD3bCLhCQP88IAISN0+WvCUtRnK5+HqXwUU7R AjzHCQ2OTsRfDkqZyY/2iHQiK9NfUoBC10lX10TaIGz+BpG+k+1p38Al9SUorEVq rcrBoyWvZ3sgeJZ/if7B0Ui5/LMkiZz1OqmweIY3BqKah5V40kIc3x0tWKTRAXLW mr9YaVQysfN0owFuLXxNqkJYAzNz1qHgtDvJ7rhdw+ATlCBxle+21xdW2fMjvGXw bC7G76b8aj2s6SjM/gHVjam+1vMDoGuoXl92q/+mBZ4MKELBkgR83+G0HJ+R7w5K 006pfUa/YOBLjUYFPb/gRlrcxvcBLUIuXShfC8pZReQxUiSDwxWa04hjQ1zT0jo= =GD4q -----END PGP SIGNATURE----- From mwedel at sonic.net Mon Apr 14 02:12:59 2014 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 14 Apr 2014 00:12:59 -0700 Subject: [crossfire] Building crossfire 1.71.0 server fails without arches In-Reply-To: <534AAEF6.4000401@gmail.com> References: <20140413101426.GA15799@sammakko3.piperka.net> <534AAEF6.4000401@gmail.com> Message-ID: <534B8A7B.8020702@sonic.net> On 04/13/14 08:36 AM, Kevin Zheng wrote: > Hi Kari, > > On 04/13/2014 05:14, Kari Pahula wrote: >> Crossfire 1.71.0 server is unbuildable without the arch directory. >> Here's what happens in lib/ directory (from make -d's output): >> >> In short, install-data-local requires smooth, which requires >> .collect-stamp, which gets created with touch. Then smooth's rule >> decides that smooth needs to be regenerated since .collect-stamp is >> fresher than smooth, making the build fail since there's no arch >> directory. > > Thanks for going through all the trouble to figure out what's wrong. It > is indeed a missing dependency-tracking file ('lib/.collect-stamp') in > the distfile. I must have missed it when creating the tarballs. In theory, make dist should collect everything that is necessary (that said, all too often things tend to fall through cracks which are discovered at release time). > >> This would work if there was a lib/.collect-stamp with a correct >> timestamp included with the server package, but there isn't. I could >> suggest that it wouldn't be a dot file since it wouldn't get waylaid >> so easily then. But this part would, IMHO, work even better without >> using a stamp file at all. The collect.pl script generates a fairly >> limited set of files and you had listed them already in the >> Makefile.am file itself. I'm not sure how make -jn friendly the >> current code is, either. > > The current archetype collection process is hackish and fails when > running with multiple build jobs. I was thinking that the collection > process should be moved out of the server build process altogether. It is part of the build process because it is needed for the server to run. However, I'm not quite sure why we never did something like this in the Makefile: if [[ ! -e arch ]]; then echo "No arch directory found - skipping collection" else fi I suspect there is probably some makefile magic that could be done to fix the 'gmake -j4' type issue - something to say that that single command is used to generate this file, so don't run multiple versions at same time. Or perhaps at least for the lib directory, something that just explicitly disables parallelism, since nothing is really built in that directory. All that said, the collect logic isn't great - it doesn't have any way to know if the files in the arch directory have changed, so in that case, the server admin has to know to run an 'make collect' by hand if they know the files have change. There is also some different situation here from SVN vs releases - in SVN, there is no precollected files, so by definition, a collection will be needed - which is not the case for official releases. > >> I ran into this while packaging 1.71.0 for Debian. I worked around it >> by calling touch -t 197001010101 lib/.collect-stamp before building >> the server. > > This workaround also works for packaging on FreeBSD. Do you think I > should roll a new tarball with '.collect-stamp' included? I don't think it is worth the effort - I'd perhaps just put out a notice like 'the lib/.collect-stamp file is missing. Before compiling this release, do a 'touch -t 201401010101 lib/.collect-stamp' and all will be good. That is such a simple workaround that it shouldn't be any problem. For anyone making official binary releases, this won't be a problem in the release - just the packager will have to know this step. From tolga.dalman at googlemail.com Sat Apr 19 03:46:34 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Sat, 19 Apr 2014 10:46:34 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial Message-ID: <535237EA.9010607@project-psi.org> Dear community, first of all: thank you very much for your efforts in the development of crossfire. I'm a keen player of this game since around 2002. Recently, I noticed several cleanup and janitorial work in the trunk. I wonder whether there should be done more. Looking through the code, I have to say that the overall quality of the server sources is really good. However, crossfire is a software that has evolved since at least 1995. Hence, I would like to ask you, the developer community, a number of general questions about the future of the crossfire (server) development: 1. What platforms are still relevant ? Beside Linux and BSD, I found references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, sun, vax, ibm032. 2. What C standard is relevant ? Moving towards C99 or even C11 would allow large portions of cleanups (standard functions, types, language constructs, etc). 3. What about the use of C++ (2011) ? It is clearly possible to smoothly convert existing code to C++ which allows better maintenance of the code. Please understand these questions as a constructive effort to further improve the quality of the current code basis. Best regards Tolga Dalman From nicolas.weeger at laposte.net Sat Apr 19 08:29:29 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 19 Apr 2014 15:29:29 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <535237EA.9010607@project-psi.org> References: <535237EA.9010607@project-psi.org> Message-ID: <201404191529.33267.nicolas.weeger@laposte.net> Hello. Thanks for your interest in Crossfire :) Concerning the first point, I'd say Windows is relevant (though having statistics on clients running Windows would be nice), others I don't know. For point 2), not sure, I think the code is globally ANSI C. See next point though :) And for point 3), that's another can of worm entirely :) My personal reply would be "right now I can more about content and gameplay than code, so let's forget refactorings until we really need it (hitting a wall the current code can't handle, for instance). :) Regards Nicolas Le samedi 19 avril 2014 10:46:34, Tolga Dalman a ?crit : > Dear community, > > first of all: thank you very much for your efforts in the development of > crossfire. I'm a keen player of this game since around 2002. > > Recently, I noticed several cleanup and janitorial work in the trunk. I > wonder whether there should be done more. Looking through the code, I have > to say that the overall quality of the server sources is really good. > However, crossfire is a software that has evolved since at least 1995. > > Hence, I would like to ask you, the developer community, a number of > general questions about the future of the crossfire (server) development: > > 1. What platforms are still relevant ? Beside Linux and BSD, I found > references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, sun, vax, > ibm032. > > 2. What C standard is relevant ? Moving towards C99 or even C11 would allow > large portions of cleanups (standard functions, types, language constructs, > etc). > > 3. What about the use of C++ (2011) ? It is clearly possible to smoothly > convert existing code to C++ which allows better maintenance of the code. > > Please understand these questions as a constructive effort to further > improve the quality of the current code basis. > > Best regards > Tolga Dalman > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Sat Apr 19 10:01:49 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 19 Apr 2014 10:01:49 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <535237EA.9010607@project-psi.org> References: <535237EA.9010607@project-psi.org> Message-ID: <53528FDD.20306@gmail.com> On 04/19/2014 03:46, Tolga Dalman wrote: > 1. What platforms are still relevant ? Beside Linux and BSD, I found > references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, > sun, vax, ibm032. Right now, there are many people using Windows, Linux, BSD, and OSX. Most recent development took place on Linux and BSD. While it's hard to imagine someone running a Crossfire server on VAX or an IBM032, I don't think it's necessary to go in and explicitly pull out support. I highly doubt those platforms still work _with_ current support, because nobody has been able to test. Crossfire tries to be portable, so a good goal would be to remove conditional compilations from most of the source code. In an ideal world every portable project should run on any semi-compliant system with appropriate libraries installed. > 2. What C standard is relevant ? Moving towards C99 or even C11 would > allow large portions of cleanups (standard functions, types, language > constructs, etc). I think moving to C99 is a good idea, but right now the blocking issue seems to be Visual Studio, which is used to build the server on Windows. It'd be interesting to find out how much C99 VS supports. > 3. What about the use of C++ (2011) ? It is clearly possible to > smoothly convert existing code to C++ which allows better maintenance > of the code. That looks like a long-term goal, because I don't see that happening until more stuff is cleaned up. As Nicholas mentioned, there isn't a pressing need for C++. That, and I don't know C++ :D Thanks, Kevin Zheng From tolga.dalman at googlemail.com Sat Apr 19 11:45:26 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Sat, 19 Apr 2014 18:45:26 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <53528FDD.20306@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> Message-ID: <5352A826.40404@project-psi.org> On 04/19/2014 05:01 PM, Kevin Zheng wrote: > On 04/19/2014 03:46, Tolga Dalman wrote: >> 1. What platforms are still relevant ? Beside Linux and BSD, I found >> references to these OSes: win32, hurd, hpux, ultrix, osf1, sgi, >> sun, vax, ibm032. > > Right now, there are many people using Windows, Linux, BSD, and OSX. > Most recent development took place on Linux and BSD. That's what I thought. Do you have any download statistics for, say, Windows binaries ? > While it's hard to imagine someone running a Crossfire server on VAX or > an IBM032, I don't think it's necessary to go in and explicitly pull out > support. I highly doubt those platforms still work _with_ current > support, because nobody has been able to test. > > Crossfire tries to be portable, so a good goal would be to remove > conditional compilations from most of the source code. In an ideal world > every portable project should run on any semi-compliant system with > appropriate libraries installed. My proposal aims at specifying the requirements on platform and programming language for running crossfire. In an ideal world, all supported platforms meeting the requirements are perfectly supported. Everything else needs to be adapted. Right now, I only see the above mentioned OSes as being relevant. So my question: where are the user's of crossfire really ? >> 2. What C standard is relevant ? Moving towards C99 or even C11 would >> allow large portions of cleanups (standard functions, types, language >> constructs, etc). > > I think moving to C99 is a good idea, but right now the blocking issue > seems to be Visual Studio, which is used to build the server on Windows. > It'd be interesting to find out how much C99 VS supports. AFAIK, C99 is not an issue with VS12. >> 3. What about the use of C++ (2011) ? It is clearly possible to >> smoothly convert existing code to C++ which allows better maintenance >> of the code. > > That looks like a long-term goal, because I don't see that happening > until more stuff is cleaned up. As Nicholas mentioned, there isn't a > pressing need for C++. That, and I don't know C++ :D Talking about portability, C++ is really the best choice, especially when it comes to Windows & VS. Since C99 is almost entirely a subset of the C++ language, an approach would be to compile all code with a C++ compiler. With that done, some nice C++ features can be used out of the box. Afterwards, modules can be replaced by real C++ classes. But that, as you said, is a long-term goal. The real question is: what is the future of Crossfire ? I agree to Nicolas that focussing on game content is more important than code. However, the current code architecture restricts the maintenance and addition of new features. I'd like to improve this situation. Best regards Tolga Dalman From nicolas.weeger at laposte.net Sun Apr 20 13:18:52 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 20 Apr 2014 20:18:52 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5352A826.40404@project-psi.org> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> Message-ID: <201404202018.56768.nicolas.weeger@laposte.net> Hello. > The real question is: what is the future of Crossfire ? I agree to Nicolas > that focussing on game content is more important than code. However, the > current code architecture restricts the maintenance and addition of new > features. I'd like to improve this situation. What are you trying to do that you can't with the current code? :) About the future of Crossfire, it's harder to tell, unfortunately. We definitely lack a "roadmap", something towards we all work, a common vision of what the game should be. Too many things are not balanced, and such. For what is worth, I once had a prototype in C++/Qt, not with full classes yet, but the move wasn't too messy, just took some time. So I wouldn't be opposed to moving to C++ (with Qt for the multiplatform aspect :)), but only if most people are ok and if it really is required for some things. And if that doesn't prevent people from first thinking about the content. Therefore I would first like to define what we want, then think about how to achieve those goals - migrating if required. Regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Apr 21 01:23:28 2014 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Apr 2014 23:23:28 -0700 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <201404202018.56768.nicolas.weeger@laposte.net> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> Message-ID: <5354B960.3050405@sonic.net> Going back to to the original thread - certainly win32 is used, and I also do sun/solaris. I'm not sure if there is any conditional code based on platforms in crossfire - if there is, I would think most could be removed through proper configure checks (that code may predate the conversion to autoconf). I suspect in the case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared, no one would care. But without knowing specific areas, support for those might also be part of support for other platforms (something like a #if defined(irix) || defined(sun) ) or the like, so just removing irix doesn't do much. I think some of that might be sound code for the client - though even on linux, it seems that the sound 'standard' changes every 5 years or so. Changing C standard is certainly something worth discussing - C99 would be reasonable (in my mind) - C11 may be a bit too recent - while it may be widely supported, it might also mean that certain users would be forced to upgrade their compilers (and perhaps other parts of their system) faster than they really want. But it also really comes down to features - What C11 (or even C99) features are out there that would be of benefit to crossfire? I'm not familiar enough with the different standards to make any assessment on that. C++ has been touched on some. I'd add that there are going to be more C programmers than C++ programmers, just on the basis that to know C++, you need to know C. So by switching to C++, you may very lose some number of current or future potential developers. I'm also suspect that doing a piecemeal conversion wouldn't be at all useful - while there is lots of crufty code in crossfire, you'd really want to look and figure out how all the classes interact and so forth. Otherwise, you may just end up with a C++ version of crossfire which is fundamentally the same, just written in C++. I'm always a bit concerned about rewriting stuff just for the sake of rewriting - while it may find (and fix) some existing bugs in the code, almost certainly more new bugs will be introduced. So echoing some previous comments, I think gameplay should drive more new features. I also think it would be helpful to express what the benefits of the changes are. In terms of roadmap, I think there were some out on the wiki. But like most volunteer based projects, trying to stick to any such roadmap gets difficult - people tend to work on what they want to work on, and it may or may not match something on the roadmap. From tolga.dalman at googlemail.com Mon Apr 21 04:20:45 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Mon, 21 Apr 2014 11:20:45 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5354B960.3050405@sonic.net> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> Message-ID: <5354E2ED.3040500@project-psi.org> My impression about crossfire right now is that the development in the server and client code is pretty dormant for the last few years. At the same time, however, I notice some increased activity towards cleanup work. I want to take this impetus as a reason to contribute by myself. Two reasons are holding me currently up to contribute, in fact: 1. There is no roadmap or "vision". Admittedly, crossfire runs pretty fine for ages now, nevertheless, I do see some open issues. 2. Parts of the code is crufty and even messy. To be honest, I'm scared off fixing issues I find in the code because of this. I have no intent to start a flame war about anything or breaking functionality. Instead, I'd like you to consider my proposal consisting of these steps: 1. Define clear requirements for the crossfire server code (this might apply to the client as well). From this thread, I found out that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32. What I'm still missing is the versions. Something like this would be nice: - For Linux I would just define the use of GCC 4.6 or higher, binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would require Visual Studio 12 or higher - ... Naturally, these requirements should be testable by the developers. Practically, these items are added in the README file and perhaps published on the crossfire web site. 2. With the platform requirements above given, C99 and/or C++11 can be assumed. Even if we decide not to use any C++ at all, I would suggest compile the code with a C++ compiler for reasons of portability. 3. With defined platform and compilers, cleanup and janitorial work can start. This includes, e.g., the use of standard types (like bool or uint32_t), standard functions (like calloc), removal of various autoconf checks, etc. 4. Modernize architecture and replace existing components. Best regards Tolga Dalman On 04/21/2014 08:23 AM, Mark Wedel wrote: > > Going back to to the original thread - certainly win32 is used, and I also do > sun/solaris. > > I'm not sure if there is any conditional code based on platforms in crossfire > - if there is, I would think most could be removed through proper configure > checks (that code may predate the conversion to autoconf). I suspect in the > case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared, > no one would care. But without knowing specific areas, support for those might > also be part of support for other platforms (something like a #if defined(irix) > || defined(sun) ) or the like, so just removing irix doesn't do much. > > I think some of that might be sound code for the client - though even on > linux, it seems that the sound 'standard' changes every 5 years or so. > > Changing C standard is certainly something worth discussing - C99 would be > reasonable (in my mind) - C11 may be a bit too recent - while it may be widely > supported, it might also mean that certain users would be forced to upgrade > their compilers (and perhaps other parts of their system) faster than they > really want. But it also really comes down to features - What C11 (or even C99) > features are out there that would be of benefit to crossfire? I'm not familiar > enough with the different standards to make any assessment on that. > > C++ has been touched on some. I'd add that there are going to be more C > programmers than C++ programmers, just on the basis that to know C++, you need > to know C. So by switching to C++, you may very lose some number of current or > future potential developers. > > I'm also suspect that doing a piecemeal conversion wouldn't be at all useful - > while there is lots of crufty code in crossfire, you'd really want to look and > figure out how all the classes interact and so forth. Otherwise, you may just > end up with a C++ version of crossfire which is fundamentally the same, just > written in C++. > > I'm always a bit concerned about rewriting stuff just for the sake of > rewriting - while it may find (and fix) some existing bugs in the code, almost > certainly more new bugs will be introduced. > > So echoing some previous comments, I think gameplay should drive more new > features. I also think it would be helpful to express what the benefits of the > changes are. > > In terms of roadmap, I think there were some out on the wiki. But like most > volunteer based projects, trying to stick to any such roadmap gets difficult - > people tend to work on what they want to work on, and it may or may not match > something on the roadmap. > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From leaf at real-time.com Mon Apr 21 13:37:00 2014 From: leaf at real-time.com (Rick Tanner) Date: Mon, 21 Apr 2014 13:37:00 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5352A826.40404@project-psi.org> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> Message-ID: <5355654C.1020701@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/19/14 11:45 AM, Tolga Dalman wrote: > > That's what I thought. Do you have any download statistics for, > say, Windows binaries ? Some stats[1] are available, but they don't show the whole picture as there are other sites[2] that offer file downloads or the download information is not tracked for other (unknown) reasons[3]. The server log files can track number of connections and client versions from players, but at the moment there is no "nice" way to really collect player population data -- like one could gain from using one of the many website traffic analyzers. Meaning, no easy way to tell if a person with Client X has connected 10 times today or if that was 10 different people. [1] = http://sourceforge.net/projects/crossfire/files/crossfire-server-windows/stats/timeline [2] = http://www.meflin.net/crossfire/ [3] = http://sourceforge.net/projects/crossfire/files/crossfire-client/snapshot/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTVWVEhHyvgBp+vH4RAnHNAJ40cKeFNY7fMba9YbsVhSSUPznqbgCgndfI oLEmw2o3UaY/E53nlk7vyYU= =KzjE -----END PGP SIGNATURE----- From kevinz5000 at gmail.com Mon Apr 21 17:56:18 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 21 Apr 2014 17:56:18 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5354B960.3050405@sonic.net> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> Message-ID: <5355A212.3060308@gmail.com> On 04/21/2014 01:23, Mark Wedel wrote: > Going back to to the original thread - certainly win32 is used, and I > also do sun/solaris. Solaris support seems like a good idea to keep. > I think some of that might be sound code for the client - though even > on linux, it seems that the sound 'standard' changes every 5 years or so. Sound support is now handled by SDL_Mixer, which works well with OSS, ALSA, PulseAudio, and the myriad of sound systems there are. Most, if not all of the platform-dependent code there has been removed. > Changing C standard is certainly something worth discussing - C99 would > be reasonable (in my mind) - C11 may be a bit too recent - while it may > be widely supported, it might also mean that certain users would be > forced to upgrade their compilers (and perhaps other parts of their > system) faster than they really want. But it also really comes down to > features - What C11 (or even C99) features are out there that would be > of benefit to crossfire? I'm not familiar enough with the different > standards to make any assessment on that. C99 has many new shiny features that I would really like to use. - Intermingled declarations with better locality of reference - Exact-width integer types (we try to hack around this right now) - New boolean data type (hacked around with our TRUE/FALSE macros) - Variable length arrays (may be useful in future) - Inline functions, to replace some macros in use - New style comments (trivial, but useful) - New library functions like 'snprintf' (used for quite some time) Of course, right now the blocking issue is compiler support, specifically from Microsoft. Both GCC and Clang support C99, except for a few floating point operations, and so do a number of popular compilers (Intel, maybe more). > C++ has been touched on some. I'd add that there are going to be more C > programmers than C++ programmers, just on the basis that to know C++, > you need to know C. So by switching to C++, you may very lose some > number of current or future potential developers. Personally, I prefer C simply because I don't know C++ (yet). Aside from greedy selfishness, I don't think a (partial) rewrite in C++ will be useful. C++ has nice features, but our aging code has done fine without so far. > So echoing some previous comments, I think gameplay should drive more > new features. I also think it would be helpful to express what the > benefits of the changes are. Right now there's no pressing feature that requires C++ in order to implement. As far as I can see (which isn't very far) C is fine for the job. Of course, I don't know what job this is, which means... > In terms of roadmap, I think there were some out on the wiki. But like > most volunteer based projects, trying to stick to any such roadmap gets > difficult - people tend to work on what they want to work on, and it may > or may not match something on the roadmap. It would be nice to sit down and come up with a roadmap. I've been doing so much 'cleanup' work lately because I didn't have anything specific in mind to work on. Thanks, Kevin Zheng From kevinz5000 at gmail.com Mon Apr 21 18:18:55 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 21 Apr 2014 18:18:55 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5354E2ED.3040500@project-psi.org> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> Message-ID: <5355A75F.1060109@gmail.com> On 04/21/2014 04:20, Tolga Dalman wrote: > My impression about crossfire right now is that the development in > the server and client code is pretty dormant for the last few years. > At the same time, however, I notice some increased activity towards > cleanup work. I want to take this impetus as a reason to contribute > by myself. More help with Crossfire is always welcome. > Two reasons are holding me currently up to contribute, in fact: 1. > There is no roadmap or "vision". Admittedly, crossfire runs pretty > fine for ages now, nevertheless, I do see some open issues. 2. Parts > of the code is crufty and even messy. To be honest, I'm scared off > fixing issues I find in the code because of this. Having a roadmap or vision is a good idea. Right now mine is to make sure the game works on my operating system and keep it that way. My other vision is to make Crossfire more fun, but without any crystallization that's not very productive. I have many, many open issues with Crossfire, but I haven't considered them important enough to dedicate substantial work to them yet. I'd love to hear your issues so we can start discussing and working on those right now. > 1. Define clear requirements for the crossfire server code (this > might apply to the client as well). From this thread, I found out > that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32. > What I'm still missing is the versions. Something like this would be > nice: - For Linux I would just define the use of GCC 4.6 or higher, > binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would > require Visual Studio 12 or higher - ... Naturally, these > requirements should be testable by the developers. Practically, these > items are added in the README file and perhaps published on the > crossfire web site. The problem with drawing a bright line is that somebody is inevitably left on the other side. Many working groups have drawn a standard called C99; we do not have to rigidly adhere to it, but instead of requiring specific versions of a specific toolchain, we should write portable code reasonably within a particular standard. > 2. With the platform requirements above given, C99 and/or C++11 can > be assumed. Even if we decide not to use any C++ at all, I would > suggest compile the code with a C++ compiler for reasons of > portability. I've seen recommendations to compile C using a C++ compiler. However, if you refer to Bjarne Stroustrup's authoritative book he admits that certain incompatibilities exist. C++ is no more standard than C, and C is just as (maybe even more) portable as C++. > 3. With defined platform and compilers, cleanup and janitorial work > can start. This includes, e.g., the use of standard types (like bool > or uint32_t), standard functions (like calloc), removal of various > autoconf checks, etc. I'm in favor of doing this in the mid-term. We already have a nice collection of compatability macros that can serve as a crutch for compilers we do not obey C99. > 4. Modernize architecture and replace existing components. I'm not exactly sure what this means. I also see no point in replacing components that have been in service and aren't breaking. I see no harm in rewriting code, but it'd be a lot more productive to focus on making the game more fun than fixing what isn't broken. Thanks, Kevin Zheng From mwedel at sonic.net Tue Apr 22 01:06:36 2014 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Apr 2014 23:06:36 -0700 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5355A75F.1060109@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> Message-ID: <535606EC.7070901@sonic.net> On 04/21/14 04:18 PM, Kevin Zheng wrote: > On 04/21/2014 04:20, Tolga Dalman wrote: >> 1. Define clear requirements for the crossfire server code (this >> might apply to the client as well). From this thread, I found out >> that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32. >> What I'm still missing is the versions. Something like this would be >> nice: - For Linux I would just define the use of GCC 4.6 or higher, >> binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would >> require Visual Studio 12 or higher - ... Naturally, these >> requirements should be testable by the developers. Practically, these >> items are added in the README file and perhaps published on the >> crossfire web site. > > The problem with drawing a bright line is that somebody is inevitably > left on the other side. Many working groups have drawn a standard called > C99; we do not have to rigidly adhere to it, but instead of requiring > specific versions of a specific toolchain, we should write portable code > reasonably within a particular standard. And to follow that, if there are features of a specific version of the language that would be useful, say the requirement is 'the compile you use must support foo. foo is known to be supported in gcc x, visual studio y, .. If your compiler is not listed, see if that option is supported if additional compiler flags are needed' That in many ways works better - oftentimes, compilers will lack full support for certain options, but support the ones we care about. > >> 2. With the platform requirements above given, C99 and/or C++11 can >> be assumed. Even if we decide not to use any C++ at all, I would >> suggest compile the code with a C++ compiler for reasons of >> portability. > > I've seen recommendations to compile C using a C++ compiler. However, if > you refer to Bjarne Stroustrup's authoritative book he admits that > certain incompatibilities exist. C++ is no more standard than C, and C > is just as (maybe even more) portable as C++. The other problem I think that can lead to is this - suppose some change is made that works fine when compiled in C mode but fails in C++ mode for whatever reason - you now get the problem of whether the developer making the change will actually care about that, and depending on where that incompatibility is, whether they can actually figure it out if they are a pure C programmer. If anything, for full compatibility, compiling with different compilers with full warnings/strict mode may be better. > >> 3. With defined platform and compilers, cleanup and janitorial work >> can start. This includes, e.g., the use of standard types (like bool >> or uint32_t), standard functions (like calloc), removal of various >> autoconf checks, etc. > > I'm in favor of doing this in the mid-term. We already have a nice > collection of compatability macros that can serve as a crutch for > compilers we do not obey C99. And that can certainly be extended. The addition of functions like snprintf are worth supporting (as are strlcat and strlcpy if those are part of some standard), but those can also be easily checked for in autoconf, and if they fail to exist, some simple conditionals can check for that and private functions added. Same for fixed sized types - the native types used by the compiler can be used instead of the typedefs currently in place, but if those native types are not available (due to old version), a simple enough ifdef to use the typdef instead. Other parts are harder - changes in actual syntax can't really be handled in that way, but I think there are few of those. > >> 4. Modernize architecture and replace existing components. > > I'm not exactly sure what this means. I also see no point in replacing > components that have been in service and aren't breaking. I see no harm > in rewriting code, but it'd be a lot more productive to focus on making > the game more fun than fixing what isn't broken. I'd note that a lot of the goofy, ugly, or odd code exists because maps expect it that way. Which is to say, some functions could potentially be made cleaner and simpler, but to do so would require examining every map and making changes to some number (and depending on exactly what construct is being used, being able to detect those automatically might be hard). I'm all for fixing some of that, but it falls into the category of a lot of work with no direct/end user effect. For programmers, there is cleaner code, but for players, things worked (or should work) exactly the same as before. So those types of changes tend to be somewhat low priority just for that reason. From tolga.dalman at googlemail.com Tue Apr 22 03:20:10 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Tue, 22 Apr 2014 10:20:10 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <535606EC.7070901@sonic.net> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> Message-ID: <5356263A.3090609@project-psi.org> >> The problem with drawing a bright line is that somebody is inevitably >> left on the other side. Many working groups have drawn a standard called >> C99; we do not have to rigidly adhere to it, but instead of requiring >> specific versions of a specific toolchain, we should write portable code >> reasonably within a particular standard. > > And to follow that, if there are features of a specific version of the > language that would be useful, say the requirement is 'the compile you use must > support foo. foo is known to be supported in gcc x, visual studio y, .. If > your compiler is not listed, see if that option is supported if additional > compiler flags are needed' Exactly. My point is that the code MUST be compilable by a set of specific toolchains by following a specific standard (e.g., C99). Some C99 features will probably not work on all specified toolchains, thus, those must be omitted in the code. I see no need for checking for a specific compiler. Instead, I'd just assume it. > That in many ways works better - oftentimes, compilers will lack full support > for certain options, but support the ones we care about. I agree. >>> 2. With the platform requirements above given, C99 and/or C++11 can >>> be assumed. Even if we decide not to use any C++ at all, I would >>> suggest compile the code with a C++ compiler for reasons of >>> portability. >> >> I've seen recommendations to compile C using a C++ compiler. However, if >> you refer to Bjarne Stroustrup's authoritative book he admits that >> certain incompatibilities exist. C++ is no more standard than C, and C >> is just as (maybe even more) portable as C++. No. I'm thinking of the GCC project -- they are doing it this way. The incompatibilities are really restricted to struct initialization and using C++ keywords as variables or functions (like new or class). BTW: that book is neither a good reference, nor a good C++ tutorial, IMHO. > The other problem I think that can lead to is this - suppose some change is > made that works fine when compiled in C mode but fails in C++ mode for whatever > reason - you now get the problem of whether the developer making the change will > actually care about that, and depending on where that incompatibility is, > whether they can actually figure it out if they are a pure C programmer. I had already compiled the crossfire 1.70 code with C++ using GCC last year. I can't rembember any serious issues. > If anything, for full compatibility, compiling with different compilers with > full warnings/strict mode may be better. I tend to agree, though, I have had some bad experience in another project with a lot of false-positives using VS 2008. Using GCC, I would always recommend compiling with -W -Wall. >>> 3. With defined platform and compilers, cleanup and janitorial work >>> can start. This includes, e.g., the use of standard types (like bool >>> or uint32_t), standard functions (like calloc), removal of various >>> autoconf checks, etc. >> >> I'm in favor of doing this in the mid-term. We already have a nice >> collection of compatability macros that can serve as a crutch for >> compilers we do not obey C99. > > And that can certainly be extended. The addition of functions like snprintf > are worth supporting (as are strlcat and strlcpy if those are part of some TBH I have some problems with strlcat and strlcpy: they are neither supported by ISO C, nor by POSIX. The glibc project repeatedly refused to add those functions to the standard library. They offer no more functionality than strncpy and strncat. Conversely, they are a known source of potential bugs (a quick Google search for strlcpy and glibc will reveal the details). > standard), but those can also be easily checked for in autoconf, and if they > fail to exist, some simple conditionals can check for that and private functions > added. Same for fixed sized types - the native types used by the compiler can > be used instead of the typedefs currently in place, but if those native types > are not available (due to old version), a simple enough ifdef to use the typdef > instead. I guess, we're here in disagreement. If I understood you correctly, you want to support old compilers, while my approach is to remove old cruft to make crossfire maintainable. What old toolchains are being used and which of them do you want to support and test ? >>> 4. Modernize architecture and replace existing components. >> >> I'm not exactly sure what this means. I also see no point in replacing >> components that have been in service and aren't breaking. I see no harm >> in rewriting code, but it'd be a lot more productive to focus on making >> the game more fun than fixing what isn't broken. > > I'd note that a lot of the goofy, ugly, or odd code exists because maps expect > it that way. Which is to say, some functions could potentially be made cleaner > and simpler, but to do so would require examining every map and making changes > to some number (and depending on exactly what construct is being used, being > able to detect those automatically might be hard). I had in mind the networking, event processing/server loop, and plugin codes. > I'm all for fixing some of that, but it falls into the category of a lot of > work with no direct/end user effect. For programmers, there is cleaner code, > but for players, things worked (or should work) exactly the same as before. So > those types of changes tend to be somewhat low priority just for that reason. I agree, though, my contribution will certainly be in the coding area. I leave the game play and game content creation to the experts :) From juhaj at iki.fi Tue Apr 22 11:19:10 2014 From: juhaj at iki.fi (Juha =?ISO-8859-1?Q?J=E4ykk=E4?=) Date: Tue, 22 Apr 2014 17:19:10 +0100 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5355A212.3060308@gmail.com> References: <535237EA.9010607@project-psi.org> <5354B960.3050405@sonic.net> <5355A212.3060308@gmail.com> Message-ID: <6545433.3jcrU2LFAM@rigel> > - Variable length arrays (may be useful in future) Which the C11 standard kindly removed. The stupidest decision by any standards committee ever: to remove perhaps the most important improvement in the previous standard just because some fool compiler manufacturer had not been able to implement it in ten years. > It would be nice to sit down and come up with a roadmap. I've been doing > so much 'cleanup' work lately because I didn't have anything specific in > mind to work on. What happened to that rebalancing-related roadmap from a few years ago? Did it ever get finished? I must admit I have not even logged on to a Crossfire server for years, which is pretty sad. I will go back to my cave now. ;) -- ----------------------------------------------- | Juha J?ykk?, juhaj at iki.fi | | http://koti.kapsi.fi/~juhaj/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Tue Apr 22 18:19:48 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Tue, 22 Apr 2014 18:19:48 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5356263A.3090609@project-psi.org> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> Message-ID: <5356F914.4090302@gmail.com> On 04/22/2014 03:20, Tolga Dalman wrote: >> And to follow that, if there are features of a specific version of >> the language that would be useful, say the requirement is 'the >> compile you use must support foo. foo is known to be supported in >> gcc x, visual studio y, .. If your compiler is not listed, see if >> that option is supported if additional compiler flags are needed' > > Exactly. My point is that the code MUST be compilable by a set of > specific toolchains by following a specific standard (e.g., C99). > Some C99 features will probably not work on all specified toolchains, > thus, those must be omitted in the code. I see no need for checking > for a specific compiler. Instead, I'd just assume it. The problem is that now we have to explicitly define a list of features that are allowed in the code. Technically, neither GCC nor Clang are C99 compliant because they lack certain floating type macros. This does not concern us because we don't really care about floating point operations. Likewise, I think it's a good idea to change the language standard to C99, but only use features where it makes sense. If we do decide to change language standard, there is no immediate need to jump in and use every single new feature, either. >>> I've seen recommendations to compile C using a C++ compiler. >>> However, if you refer to Bjarne Stroustrup's authoritative book >>> he admits that certain incompatibilities exist. C++ is no more >>> standard than C, and C is just as (maybe even more) portable as >>> C++. > > No. I'm thinking of the GCC project -- they are doing it this way. > The incompatibilities are really restricted to struct initialization > and using C++ keywords as variables or functions (like new or > class). BTW: that book is neither a good reference, nor a good C++ > tutorial, IMHO. I'm still not sure why this would make the project more portable, though. The major compiler toolchains support C just as well as C++, with the notable exception of Visual Studio. >> The other problem I think that can lead to is this - suppose some >> change is made that works fine when compiled in C mode but fails in >> C++ mode for whatever reason - you now get the problem of whether >> the developer making the change will actually care about that, and >> depending on where that incompatibility is, whether they can >> actually figure it out if they are a pure C programmer. > > I had already compiled the crossfire 1.70 code with C++ using GCC > last year. I can't rembember any serious issues. The choice of compiler should be left to the user. Since this is a project written in C, the 'official' way to compile it should be a C compiler. Note that 'official' only means that someone will get yelled at if a change breaks the compilation. Quite frankly, I still have the (possibly wrong) notion that the most logical choice to compile a C program is a C compiler. >> If anything, for full compatibility, compiling with different >> compilers with full warnings/strict mode may be better. > > I tend to agree, though, I have had some bad experience in another > project with a lot of false-positives using VS 2008. Using GCC, I > would always recommend compiling with -W -Wall. Right now the code seems to compile fairly cleanly. >>> I'm in favor of doing this in the mid-term. We already have a >>> nice collection of compatability macros that can serve as a >>> crutch for compilers we do not obey C99. >> >> And that can certainly be extended. The addition of functions >> like snprintf are worth supporting (as are strlcat and strlcpy if >> those are part of some > > TBH I have some problems with strlcat and strlcpy: they are neither > supported by ISO C, nor by POSIX. The glibc project repeatedly > refused to add those functions to the standard library. They offer no > more functionality than strncpy and strncat. Conversely, they are a > known source of potential bugs (a quick Google search for strlcpy and > glibc will reveal the details). While strlcat and strlcpy are not defined by any standards body, I believe that they are superior to the normal functions and should be used whenever possible. If you haven't noticed, I recently committed a small chunk of platform-dependent code that uses these two functions when available instead of our hacks around it. >> standard), but those can also be easily checked for in autoconf, >> and if they fail to exist, some simple conditionals can check for >> that and private functions added. Same for fixed sized types - the >> native types used by the compiler can be used instead of the >> typedefs currently in place, but if those native types are not >> available (due to old version), a simple enough ifdef to use the >> typdef instead. > > I guess, we're here in disagreement. If I understood you correctly, > you want to support old compilers, while my approach is to remove old > cruft to make crossfire maintainable. What old toolchains are being > used and which of them do you want to support and test ? Right now Crossfire seems maintainable. Recently, several important bug fixes were made, and few new features were introduced. I am in favor of switching to the "standard" fixed-sized integer types. It is trivial to make the appropriate definitions in a separate header file for systems that do not already have these types. >> I'd note that a lot of the goofy, ugly, or odd code exists because >> maps expect it that way. Which is to say, some functions could >> potentially be made cleaner and simpler, but to do so would require >> examining every map and making changes to some number (and >> depending on exactly what construct is being used, being able to >> detect those automatically might be hard). > > I had in mind the networking, event processing/server loop, and > plugin codes. Even then, some specifics would be useful. What are you suggesting for networking or the server loops? Personally I'd like to go back in time and get rid of plugins, but that is an entirely different discussion. It will involve a *lot* of work for not a ton of appreciable player benefit. >> I'm all for fixing some of that, but it falls into the category of >> a lot of work with no direct/end user effect. For programmers, >> there is cleaner code, but for players, things worked (or should >> work) exactly the same as before. So those types of changes tend >> to be somewhat low priority just for that reason. > > I agree, though, my contribution will certainly be in the coding > area. I leave the game play and game content creation to the experts > :) At the end of the day, if you believe that certain changes are worth your time making, please send a patch. The recent cleanups were made because I wanted them and nobody objected to them. Thanks, Kevin Zheng From kevinz5000 at gmail.com Tue Apr 22 18:27:09 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Tue, 22 Apr 2014 18:27:09 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <6545433.3jcrU2LFAM@rigel> References: <535237EA.9010607@project-psi.org> <5354B960.3050405@sonic.net> <5355A212.3060308@gmail.com> <6545433.3jcrU2LFAM@rigel> Message-ID: <5356FACD.4010901@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/22/2014 11:19, Juha J?ykk? wrote: >> It would be nice to sit down and come up with a roadmap. I've >> been doing so much 'cleanup' work lately because I didn't have >> anything specific in mind to work on. > > What happened to that rebalancing-related roadmap from a few years > ago? Did it ever get finished? I must admit I have not even logged > on to a Crossfire server for years, which is pretty sad. Probably not, although I wasn't around back then to be able to tell. A lot of things, including experience tables, spell levels, player stats, artifact properties, item prices, weights, and more still need a lot of balancing and tweaking. Unfortunately, the only balancing that I am capable of performing is for object weights. Simply copy real-world values in :D Thanks, Kevin Zheng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTVvrNAAoJEOrPD3bCLhCQxgMIALz3IR7llW0arn/QUfOdoxsA 5j5UxoUzuUMuY/txtcxhDcibr9CIXDYswEOcL5YqYoLZo2lJ5cGnXVnB8BYZYniC 41NBlvFyKBsOm/S0Frpk0fRSHZ1ajVCJ7f2xsmsZOnjjDrPuqrERbzl9xDTbGbw+ gUWY+gtv9qvVw1hviosXFZ7DF/IOh8V9Su7+6JPAkb0WbS+cMq87T4IWcCfvYt+t 6M8zJwNduVefKc+iA/mRPTahrUkd/6iCmXhsAamq1zFPr+Wl/gQ1GGVnrdQkGvTE hJZTAC6QmK8Y3mN4rb4Elm61RqvNqisjIbuXW33+N8dw7UwRWBZub4lguBbEst4= =ZKV5 -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Apr 23 01:43:54 2014 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Apr 2014 23:43:54 -0700 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5356F914.4090302@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> Message-ID: <5357612A.4020506@sonic.net> Few general notes on this: My idea if using new functions provided by libraries (if they exist) and include local copies if they don't is that often times vendor provided functions may be much better optimized that locally included ones. Also, for some functions (like strlcpy), it may be a trivial exercise to include a local copy of equivalent functionality. But for others, like snprintf, it might be hard, but a simple replacement of non equivalent functionality is easy, like: sprintf(buf, ...) if strlen(buf) > buflen { oops, we have a buffer overrun } which isn't great, but could still be better than an alternative of just using an unprotected sprintf. I do tend to agree with the comment that given crossfire is C code, using a C compiler would seem to be the best tool to use to compile it. That said, if it happens to compile with a C++ compiler, or changes are trivial to let it do so, great. But I'd just put the responsibility of making sure it compile with C++ belongs to those who want to compile with C++, not all developers. I will also note that crossfire actually does a fair amount of floating point - all the speed and speed_left is floating point, the just simple addition/subtraction. The plugin logic has pluses and minuses - the ability to right plugins that register themselves is good, but the entire dynamic loading adds a bit of code complexity and another place for errors. But also, at one time, the python plugin was optional, so you could run the server without necessarily having python & its development libraries installed. But IIRC, at some point, it was decided that enough scripts and other stuff require python it should become standard - since it is known it will always exist, whether having it be a dynamically library that is loaded makes sense is debatable. From tolga.dalman at googlemail.com Wed Apr 23 02:17:08 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Wed, 23 Apr 2014 09:17:08 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5356F914.4090302@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> Message-ID: <535768F4.7070904@project-psi.org> On 04/23/2014 01:19 AM, Kevin Zheng wrote: > I'm still not sure why this would make the project more portable, > though. The major compiler toolchains support C just as well as C++, > with the notable exception of Visual Studio. It is not only the language and the employed toolchain. In my experience, problems begin as soon as you start implementing containers and data structures in C (which, btw, has been done in crossfire). It is then a good idea to use standardized library functions, like, strings, lists, or hash tables. All this is provided by C++ for free in a highly portable way. >> I tend to agree, though, I have had some bad experience in another >> project with a lot of false-positives using VS 2008. Using GCC, I >> would always recommend compiling with -W -Wall. > > Right now the code seems to compile fairly cleanly. Try compiling with gcc 4.8. While almost all issues are minor (unused variables and signed compares), there is some work left with at least GCC. I haven't tried other compilers though. > While strlcat and strlcpy are not defined by any standards body, I > believe that they are superior to the normal functions and should be > used whenever possible. If you haven't noticed, I recently committed a > small chunk of platform-dependent code that uses these two functions > when available instead of our hacks around it. Yes, and that's a good progress! However, I still fail to understand why strlcat/strlcpy would be superior to strncat/strncpy. > Right now Crossfire seems maintainable. Recently, several important bug > fixes were made, and few new features were introduced. As I said before, these developments have inspired me to start this (quite long) thread. And to repeat: I believe that the overall quality of the source code is really good. Still there is some way to go. Thanks for your work! > Even then, some specifics would be useful. What are you suggesting for > networking or the server loops? I haven't had thought about it well enough, but I can think of two possibilities: a) refactor/rewrite the code. b) use third-party libraries. My preference is of course b), however, such a step must be thoroughly investigated beforehand. > At the end of the day, if you believe that certain changes are worth > your time making, please send a patch. The recent cleanups were made > because I wanted them and nobody objected to them. While I really appreciate the positive discussion we have had up until now, my impression is that I should now be showing you what I have in mind rather than doing mouth-work only :) On github, I have created a crossfire server repository to track my patches (based on SVN trunk rev. 19362). https://github.com/tdalman/crossfire I won't be able to test any other platform than Linux and I won't be attempting to do so either. If you think some of the changes are worthwhile to adopt, I'd be happy of course. Likewise, please don't hesitate to comment on my patches. I will try to keep the code in sync, but at some point that will no longer be possible. Best regards Tolga Dalman From nicolas.weeger at laposte.net Wed Apr 23 13:37:28 2014 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 23 Apr 2014 20:37:28 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5357612A.4020506@sonic.net> References: <535237EA.9010607@project-psi.org> <5356F914.4090302@gmail.com> <5357612A.4020506@sonic.net> Message-ID: <201404232037.36160.nicolas.weeger@laposte.net> Hello. > The plugin logic has pluses and minuses - the ability to right plugins > that register themselves is good, but the entire dynamic loading adds a > bit of code complexity and another place for errors. But also, at one > time, the python plugin was optional, so you could run the server without > necessarily having python & its development libraries installed. But > IIRC, at some point, it was decided that enough scripts and other stuff > require python it should become standard - since it is known it will > always exist, whether having it be a dynamically library that is loaded > makes sense is debatable. What about simply having compile-time modules? When you compile, if you have Python then the module is compiled, it not then it isn't, end of story :) Regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Wed Apr 23 14:05:33 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Wed, 23 Apr 2014 14:05:33 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <535768F4.7070904@project-psi.org> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <535768F4.7070904@project-psi.org> Message-ID: <53580EFD.3090204@gmail.com> On 04/23/2014 02:17, Tolga Dalman wrote: > It is not only the language and the employed toolchain. In my > experience, problems begin as soon as you start implementing > containers and data structures in C (which, btw, has been done in > crossfire). It is then a good idea to use standardized library > functions, like, strings, lists, or hash tables. All this is provided > by C++ for free in a highly portable way. While using C++ means that we can reinvent less wheels, the current implementation is no less portable. >> Right now the code seems to compile fairly cleanly. > > Try compiling with gcc 4.8. While almost all issues are minor (unused > variables and signed compares), there is some work left with at least > GCC. I haven't tried other compilers though. I'm using Clang and I haven't seen warnings about unused variables. I'll poke around my compiler flags and see if I can get them. >> While strlcat and strlcpy are not defined by any standards body, I >> believe that they are superior to the normal functions and should >> be used whenever possible. If you haven't noticed, I recently >> committed a small chunk of platform-dependent code that uses these >> two functions when available instead of our hacks around it. > > Yes, and that's a good progress! However, I still fail to understand > why strlcat/strlcpy would be superior to strncat/strncpy. The standard "strncat" and "strncpy" functions do not guarantee that the destination buffer will be null-terminated. This means that your changes are vulnerable to many buffer overflow attacks. Using the sstring construct in Crossfire or moving to C++ will mitigate this possibility, but probably not completely remove it. >> Even then, some specifics would be useful. What are you suggesting >> for networking or the server loops? > > I haven't had thought about it well enough, but I can think of two > possibilities: a) refactor/rewrite the code. b) use third-party > libraries. My preference is of course b), however, such a step must > be thoroughly investigated beforehand. Some of the code in the network loop should be cleaned up. Once I was also considering using something similar to SDL_Net, but decided that it wasn't worth the effort. > I won't be able to test any other platform than Linux and I won't be > attempting to do so either. If you think some of the changes are > worthwhile to adopt, I'd be happy of course. Likewise, please don't > hesitate to comment on my patches. I will try to keep the code in > sync, but at some point that will no longer be possible. I noticed many changes to silence compiler warnings. I haven't taken a closer look, but perhaps it may be a good idea to change the function definitions themselves instead of prefixing "(void)"? I also noticed a lot of changes that simply rip out compatibility in 'porting.c', which is intended to keep that kind of stuff. Ideally, there would be no conditional compilations except there. Extend the above mentioned issue with ripping out the safe_* functions. I'll be working on cherry-picking specific changes, I hope your rebases with master aren't too painful :) Consider using `git svn` which lets you keep track of the SVN repository. You can also rebase your work off my pre-cloned repository and track SVN from there. Thanks, Kevin Zheng From kevinz5000 at gmail.com Wed Apr 23 14:12:10 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Wed, 23 Apr 2014 14:12:10 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5357612A.4020506@sonic.net> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <5357612A.4020506@sonic.net> Message-ID: <5358108A.9070109@gmail.com> On 04/23/2014 01:43, Mark Wedel wrote: > My idea if using new functions provided by libraries (if they exist) > and include local copies if they don't is that often times vendor > provided functions may be much better optimized that locally > included ones. Agreed, even if the speed improvement is negligible. > Also, for some functions (like strlcpy), it may be a trivial exercise > to include a local copy of equivalent functionality. But for others, > like snprintf, it might be hard, but a simple replacement of non > equivalent functionality is easy, like: > > sprintf(buf, ...) if strlen(buf) > buflen { oops, we have a buffer > overrun } > > which isn't great, but could still be better than an alternative of > just using an unprotected sprintf. It's probably a good idea to maintain local copies of non-standard functions, but I think things like "snprintf" are safe to use anywhere (even in Visual Studio). > I will also note that crossfire actually does a fair amount of > floating point - all the speed and speed_left is floating point, the > just simple addition/subtraction. Yes, but C99 brought additional functions and macros to control the precision of floating point operations. Neither GCC nor Clang support that part of the standard, but we don't care much since the existing operations are good enough. Floating point operations in C89 are still here, don't worry :p > The plugin logic has pluses and minuses - the ability to right > plugins that register themselves is good, but the entire dynamic > loading adds a bit of code complexity and another place for errors. > But also, at one time, the python plugin was optional, so you could > run the server without necessarily having python & its development > libraries installed. But IIRC, at some point, it was decided that > enough scripts and other stuff require python it should become > standard - since it is known it will always exist, whether having it > be a dynamically library that is loaded makes sense is debatable. I like the idea of conditionally compiling required "modules". We don't seem to have a lot of third parties who want to make plugins, and it adds a layer of abstraction that recently caused subtle problems. I am *not* volunteering to swoop in and rip them all out, though :D Thanks, Kevin Zheng From mwedel at sonic.net Thu Apr 24 01:35:34 2014 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 23 Apr 2014 23:35:34 -0700 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5358108A.9070109@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <5357612A.4020506@sonic.net> <5358108A.9070109@gmail.com> Message-ID: <5358B0B6.2060901@sonic.net> Compile time modules for the plugins would probably be simpler (avoids dynamic linking) I think the one notable change would be each plugin would need its own init function (init_python, init_logger, etc), and some part of the server code would have to have the #ifdefs to call those or not. The one advantage of the dynamic linking module is there is a standard/common init that is called during the loading. The idea of third party modules is hard to imagine - unlike say plugins for firefox which tend to be fairly abstract, the plugins for crossfire are really tied to the server they are compiled with. That is/was one source of many problems - a new field is added to some object, the server is recompiled, and maybe even the plugins, but the plugins are not installed so access to the structure gets random values. So I can't ever see anyone distributing a binary only .so file and have it work, unless it was very trivial. So they will always be source, and even if due to license reasons it can't be distributed as part of crossfire, it still wouldn't be hard to just make the appropriate directory in the plugins directory and add the logic for it to get compiled. From mwedel at sonic.net Thu Apr 24 01:48:21 2014 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 23 Apr 2014 23:48:21 -0700 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <53580EFD.3090204@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <535768F4.7070904@project-psi.org> <53580EFD.3090204@gmail.com> Message-ID: <5358B3B5.9030707@sonic.net> Just a quick note: While using external libraries for certain common things can be handy, one also has to be careful about how common these libraries are (eg, if it doesn't exist on certain platforms, its convenience factor goes down a whole bunch) Beyond that, there was a separate ticket/discussion about the need to have perl for the server on windows to collect the archetypes. To me, that isn't a big issue, but so some it is, and if that is an issue, I'd then think requiring additional libraries would fall into that extra pain. It could also make binary distributions harder certainly, using standard functions that are available on all systems and simplify life should be done. The socket code got a bit messy with all the WIN32 #ifdefs - a simpler solution there would probably be add a 'read_from_socket' type function which makes the appropriate call and checks the appropriate error types and returns appropriate error code, so all that logic only has to be in one function and not duplicated many times. Same could be done for the write calls. From tolga.dalman at googlemail.com Thu Apr 24 05:23:23 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Thu, 24 Apr 2014 12:23:23 +0200 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <53580EFD.3090204@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <535768F4.7070904@project-psi.org> <53580EFD.3090204@gmail.com> Message-ID: <5358E61B.9050603@project-psi.org> > The standard "strncat" and "strncpy" functions do not guarantee that the > destination buffer will be null-terminated. This means that your changes > are vulnerable to many buffer overflow attacks. Yes, but then those functions are used incorrectly. If the buffer is too short, the cpy/cat operation will misbehave (i.e., the string will be truncated). > Using the sstring construct in Crossfire or moving to C++ will mitigate > this possibility, but probably not completely remove it. I agree. > Some of the code in the network loop should be cleaned up. Once I was also > considering using something similar to SDL_Net, but decided that it wasn't > worth the effort. SDL Net is a fine portable socket abstraction and might solve some immediate ugliness of the current networking code. Another possibility is to go a step further and use frameworks like MessagePack or Protobuf for serializing/deserializing byte streams and ZeroMQ as communication framework. However, two problems come with that as well: as Mark noted these libraries must be supported by all platforms, and such a change would mean a considerable amount of work with little visible effects for the user. > I noticed many changes to silence compiler warnings. I haven't taken a > closer look, but perhaps it may be a good idea to change the function > definitions themselves instead of prefixing "(void)"? That's what I did where possible. Elsewhere (esp. in types/) I couldn't easily change the API. > I also noticed a lot of changes that simply rip out compatibility in > 'porting.c', which is intended to keep that kind of stuff. Ideally, there > would be no conditional compilations except there. Assuming C99, these functions are not really needed, right ? > Extend the above mentioned issue with ripping out the safe_* functions. I haven't yet touched those, though I guess there could be done some simplification as well (i.e., use tmpfile or mkstemp instead of tempnam*). > I'll be working on cherry-picking specific changes, I hope your rebases > with master aren't too painful :) Thank you very much! I really appreciate it. > Consider using `git svn` which lets you keep track of the SVN repository. > You can also rebase your work off my pre-cloned repository and track SVN > from there. Great hint, I didn't know about that before. I'll investigate. Best regards Tolga Dalman From kevinz5000 at gmail.com Fri Apr 25 17:53:51 2014 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 25 Apr 2014 17:53:51 -0500 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <5358B3B5.9030707@sonic.net> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <535768F4.7070904@project-psi.org> <53580EFD.3090204@gmail.com> <5358B3B5.9030707@sonic.net> Message-ID: <535AE77F.50008@gmail.com> On 04/24/2014 01:48, Mark Wedel wrote: > Beyond that, there was a separate ticket/discussion about the need to > have perl for the server on windows to collect the archetypes. To me, > that isn't a big issue, but so some it is, and if that is an issue, I'd > then think requiring additional libraries would fall into that extra > pain. It could also make binary distributions harder I was working on that ticket but kind of dropped the ball on it. I don't see the Perl dependency as a problem, either, but I understand that it _may_ be troublesome on Windows. I am also considering moving the archetype collection scripts to the arch directory, any thoughts on this? Thanks, Kevin Zheng From mwedel at sonic.net Sat Apr 26 00:05:37 2014 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 25 Apr 2014 22:05:37 -0700 Subject: [crossfire] Crossfire server code cleanup/janitorial In-Reply-To: <535AE77F.50008@gmail.com> References: <535237EA.9010607@project-psi.org> <53528FDD.20306@gmail.com> <5352A826.40404@project-psi.org> <201404202018.56768.nicolas.weeger@laposte.net> <5354B960.3050405@sonic.net> <5354E2ED.3040500@project-psi.org> <5355A75F.1060109@gmail.com> <535606EC.7070901@sonic.net> <5356263A.3090609@project-psi.org> <5356F914.4090302@gmail.com> <535768F4.7070904@project-psi.org> <53580EFD.3090204@gmail.com> <5358B3B5.9030707@sonic.net> <535AE77F.50008@gmail.com> Message-ID: <535B3EA1.7020703@sonic.net> On 04/25/14 03:53 PM, Kevin Zheng wrote: > On 04/24/2014 01:48, Mark Wedel wrote: >> Beyond that, there was a separate ticket/discussion about the need to >> have perl for the server on windows to collect the archetypes. To me, >> that isn't a big issue, but so some it is, and if that is an issue, I'd >> then think requiring additional libraries would fall into that extra >> pain. It could also make binary distributions harder > > I was working on that ticket but kind of dropped the ball on it. I don't > see the Perl dependency as a problem, either, but I understand that it > _may_ be troublesome on Windows. > > I am also considering moving the archetype collection scripts to the > arch directory, any thoughts on this? This is sort of a messy one. It sort of seems obvious that the arch collection (and related bits) should be in the arch tree. However, it is the server that is the actual consumer of those files. So if they are collected in the arch tree, they somehow have to get into the right directory for the server to use them. Now there are certainly different ways to handle this - you could have the server call arch/scripts/collect.pl - I'm not exactly sure how that improves anything. Likewise, one could run the script in the arch directory, and if it deposit the files in arch/build or something, and then have the server install process know to look there. That actually seems more complicated. Plus, it is nice to just be able to do a 'make collect' in the lib directory and have it do the right thing. I'm not opposed to relocation of those scripts - I'd just like to see more how it will all works out. From tolga.dalman at googlemail.com Sat Apr 26 01:50:01 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Sat, 26 Apr 2014 08:50:01 +0200 Subject: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7 Message-ID: <535B5719.4030005@project-psi.org> Hi, currently, Python 2.4 is required for the map scripts to work properly. I propose to require version 2.7 as minimum Python version, which was released in 2010 and is still widely used. With Python 2.7, we have the opportunity to cleanup some very old Python conditional stuff. This way we should be able to replace cjson by the Python standard library JSON implementation. What do you think ? Best regards Tolga Dalman From shjohnson.pi at gmail.com Sat Apr 26 07:40:19 2014 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Sat, 26 Apr 2014 08:40:19 -0400 Subject: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7 In-Reply-To: <535B5719.4030005@project-psi.org> References: <535B5719.4030005@project-psi.org> Message-ID: If we're raising the version can we just go to python 3? That way it wouldn't need to be raised again for awhile. I wouldn't mind porting python 2 scripts to 3 either. Python 3.4 was just released March 16, 2014. On Apr 26, 2014 2:50 AM, "Tolga Dalman" wrote: > Hi, > > currently, Python 2.4 is required for the map scripts to work properly. I > propose to require version 2.7 as minimum Python version, which was > released > in 2010 and is still widely used. > > With Python 2.7, we have the opportunity to cleanup some very old Python > conditional stuff. This way we should be able to replace cjson by the > Python standard library JSON implementation. What do you think ? > > Best regards > Tolga Dalman > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tolga.dalman at googlemail.com Sat Apr 26 08:20:24 2014 From: tolga.dalman at googlemail.com (Tolga Dalman) Date: Sat, 26 Apr 2014 15:20:24 +0200 Subject: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7 In-Reply-To: References: <535B5719.4030005@project-psi.org> Message-ID: <535BB298.6010305@project-psi.org> On 04/26/2014 02:40 PM, Steven Johnson wrote: > If we're raising the version can we just go to python 3? That way it > wouldn't need to be raised again for awhile. I wouldn't mind porting python > 2 scripts to 3 either. Python 3.4 was just released March 16, 2014. Python 3 is already supported in crossfire for some time. My query regards the *minimum* supported version of Python. Since Python 2 is being used actively alongside Python 3, I see no point in removing the support. From shjohnson.pi at gmail.com Sat Apr 26 09:43:41 2014 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Sat, 26 Apr 2014 10:43:41 -0400 Subject: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7 In-Reply-To: <535BB298.6010305@project-psi.org> References: <535B5719.4030005@project-psi.org> <535BB298.6010305@project-psi.org> Message-ID: Ok, I suppose it is too early to remove python 2 support. Still I'd be happy to help out with any python related coding. Just let me know. On Apr 26, 2014 9:20 AM, "Tolga Dalman" wrote: > On 04/26/2014 02:40 PM, Steven Johnson wrote: > > If we're raising the version can we just go to python 3? That way it > > wouldn't need to be raised again for awhile. I wouldn't mind porting > python > > 2 scripts to 3 either. Python 3.4 was just released March 16, 2014. > > Python 3 is already supported in crossfire for some time. My query regards > the > *minimum* supported version of Python. Since Python 2 is being used > actively > alongside Python 3, I see no point in removing the support. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -------------- next part -------------- An HTML attachment was scrubbed... URL: