[crossfire] Autoreconf Warnings Bug
Hello everyone, I'm Steven. Hopefully if time permits I can keep helping out with this fun project. I created a bug report and uploaded a patch: https://sourceforge.net/tracker/?func=detail&aid=3428070&group_id=13833&atid=113833 It deals with autoreconf warnings and is very low priority and the fix was just adding two brackets. The warning was: (running from root directory of client trunk on Ubuntu Linux 11.10) $ autoreconf ... macros/libcurl.m4:38: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:416: the top level configure.ac:416: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Autoreconf Warnings Bug
I put the brackets in the wrong spots! Here's the new patch attached and pasted: Index: macros/libcurl.m4 === --- macros/libcurl.m4 (revision 15261) +++ macros/libcurl.m4 (working copy) @@ -142,7 +142,7 @@ _libcurl_save_libs=$LIBS LIBS="$LIBCURL $LIBS" - AC_LINK_IFELSE(AC_LANG_PROGRAM([#include ],[ + AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]],[ /* Try and use a few common options to force a failure if we are missing symbols or can't link. */ int x; @@ -153,7 +153,7 @@ x=CURLOPT_ERRORBUFFER; x=CURLOPT_STDERR; x=CURLOPT_VERBOSE; -]),libcurl_cv_lib_curl_usable=yes,libcurl_cv_lib_curl_usable=no) +])],[libcurl_cv_lib_curl_usable=yes],[libcurl_cv_lib_curl_usable=no]) CPPFLAGS=$_libcurl_save_cppflags LIBS=$_libcurl_save_libs On Tue, Oct 25, 2011 at 1:27 AM, Steven Johnson wrote: > Hello everyone, I'm Steven. Hopefully if time permits I can keep helping > out with this fun project. > > > I created a bug report and uploaded a patch: > > https://sourceforge.net/tracker/?func=detail&aid=3428070&group_id=13833&atid=113833 > > It deals with autoreconf warnings and is very low priority and the fix was > just adding two brackets. > > The warning was: (running from root directory of client trunk on Ubuntu > Linux 11.10) > $ autoreconf > ... > macros/libcurl.m4:38: LIBCURL_CHECK_CONFIG is expanded from... > configure.ac:416: the top level > configure.ac:416: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ... > > Index: macros/libcurl.m4 === --- macros/libcurl.m4 (revision 15261) +++ macros/libcurl.m4 (working copy) @@ -142,7 +142,7 @@ _libcurl_save_libs=$LIBS LIBS="$LIBCURL $LIBS" - AC_LINK_IFELSE(AC_LANG_PROGRAM([#include ],[ + AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]],[ /* Try and use a few common options to force a failure if we are missing symbols or can't link. */ int x; @@ -153,7 +153,7 @@ x=CURLOPT_ERRORBUFFER; x=CURLOPT_STDERR; x=CURLOPT_VERBOSE; -]),libcurl_cv_lib_curl_usable=yes,libcurl_cv_lib_curl_usable=no) +])],[libcurl_cv_lib_curl_usable=yes],[libcurl_cv_lib_curl_usable=no]) CPPFLAGS=$_libcurl_save_cppflags LIBS=$_libcurl_save_libs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7
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@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [RFC] cfpython: raise minimum required version to Python 2.7
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@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire should use Git
I'm not a regular contributor either but I believe mercurial (hg) is the better choice as well. Plus the site Bloody Shade mentioned http://hginit.com/ easily explains the transition from svn to hg. On Jun 13, 2014 9:29 AM, "Bloody Shade" wrote: > I'm not sure I can agree with a move to Git, personally. > > There's plenty of drawbacks that also come with git (not that other > version controls don't). > I personally use mercurial (hg) for my projects and you can find more info > on it and see if you like it at: http://hginit.com/ > > I found this article with some things I also don't like about git, in case > anybody else is wondering (although I'm sure there's more): > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ > > Then again, I'm not a regular contributor, so feel free to ignore this, > but I thought it would be worth throwing my 2 cents. > > On 6/13/2014 10:13 AM, Kevin Zheng wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi all, >> >> Crossfire originally lived in the world of CVS, until a handful of brave >> knights ventured to move it to SVN. Today I believe it is time to move >> again, and this time to Git. >> >> Git is a distributed version control system, which means that checking >> out an old revision or reading the commit log does not require accessing >> the sometimes painfully slow servers on the Internet. Each 'clone' of >> the repository is a fully-functioning repository on its own. This means >> that developers, even those who do not have commit access, can work on >> projects at their own pace and submit them with tools such as `git >> format-patch` and others. >> >> Git makes branching easy. It makes maintaining them manageable. As an >> example, several important fixes were made in 'trunk', which have yet to >> be backported to 1.12.0. In addition, there are no release engineering >> branches, which means that each release is simply cut from the next >> 'trunk' state in line. Even "trivial" fixes could benefit from topic >> branches, but SVN does not make this easy, convenient, or fun. Using Git >> branches would help create a more stable codebase by improving release >> engineering and adopting intermediate "stable" branches that servers can >> track. A recent autotools bug that wiped server configuration files, for >> example, could have been prevented if changes on the bleeding edge were >> evaluated by test servers first. >> >> Git is not terribly difficult to use. Right now I access the SVN >> repository through a local Git clone, but this is inadequate because I >> cannot publish my topic branches (without considerably difficulty). A >> migration that preserves tags, branches, and full revision history can >> be made as fast as the revisions are pulled from SVN. >> >> In summary, a few important benefits of using Git: >> >> - - Contributors can work on the code easier, with revision control. >> - - Distributed, so works without (slow) Internet access. >> - - Encourages branching -> more stable codebase. >> - - Easy to use and migrate to. >> - - Full (all revision history) repository size: 21.7 MiB (server), 13.9 >>MiB (client), 106.1 MiB (maps) >> >> However, there are a few immediate problems: >> >> Most projects using SVN make extensive use of the revision number >> identifiers. Crossfire is no different. Git has revision (commit) >> identifiers, but they are meaningless without the repository, whereas >> SVN increments the number for each commit. I do not believe this is an >> issue, because client compatibility is not determined by this >> specifier, plugin versions are only checked to match, and other uses >> of the identifier can be removed. >> >> Of course, comments, questions, and hate mail are always welcome. >> >> Thanks, >> Kevin Zheng >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJTmvjyAAoJEOrPD3bCLhCQsEIH/2CnCPs/FmKlGmgkMw98zo/b >> vIFMiFiMZsuEteKUajXZb3+OfabyvCTBJZc3nVOlVwxt6xT+9NcspmdPYIofqt2M >> 24fhSY7LqSF5Odc/afQX6JrA21fgF/ryU6jc1Iri2+13Wk6TDEhQqZ/ASdSmaaZm >> IXd9iPb8D7EbSmp0pqvAGKriExVZDSIuukXmOQzbjG8mqFgczBnNdxP62bPh2H03 >> NyMbd+nCFfaaXAca/5wGZgrqmx0OU8DiRx9FTKzwp1/Ku3t09PT9aUbuOY6qUKAU >> kdOQfdp8naAxCbf38B/9k+IU5lk+JFcbs576X3lreU0xyr1byZyparkfNOLk3XE= >> =lsHS >> -END PGP SIGNATURE- >> ___ >> crossfire mailing list >> crossfire@metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire >> >> > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] File format
That sounds like a good idea to me. I suggest YAML since it looks nice and allows comments. XML is pretty verbose but handles anything. JSON looks better than XML but technically doesn't allow comments. I don't think INI files would support what crossfire needs. On Wed, Dec 8, 2021, 1:41 PM Nicolas Weeger wrote: > Hello. > > I'm wondering about replacing (some of) our home-made file formats by some > standard - json, xml, yaml, whatever, ideas welcome. > > My rationale is that it's a pain to change the parsing code each time we > want > to add something to an existing file. > > > Opinions? Flames? Blessings? > > > Best regards > > > Nicolas___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire IRC: http://crossfire.real-time.com/irc/index.html Discord: http://crossfire.real-time.com/discord/index.html Project Site: https://sourceforge.net/projects/crossfire/ Wiki: http://wiki.cross-fire.org/ Website: http://crossfire.real-time.com
Re: [crossfire] File format
I was curious how each format would look when using actual crossfire data. So, I made this webpage to show it! https://shjohnson314.com/cf/format-compare/ I show the following side-by-side: Current, YAML, XML, JSON, TOML using an example of formulae descriptions. I also included pros and cons for each (as objective as possible). If most people don't mind the whitespace dependency, then I most prefer YAML, otherwise XML. When creating the examples, I noticed the following problems with JSON: - Does not allow comments (as I said above, though Nicolas suggested including them as part of our data) In the example I show "data-comments" for the whole file and individual items. I also include regular comments that don't belong to a particular object (except in JSON). - Does not allow multiline strings This is what makes me dislike JSON for this use case. We can't include comments or "data-comments" that are more than one line (easily/nicely). Anything else that is more than one line (messages, books) would look bad too in JSON. Because of these problems with JSON, my next favorite would be XML. I included TOML only because it came up in comparisons between different file formats. It's simple but I couldn't get formula ingredients nicely formatted. TOML does not allow arrays with different types. If I got some pros or cons wrong please let me know. Steven H Johnson On Tue, Dec 21, 2021 at 12:08 PM Nicolas Weeger wrote: > Hello. > > > > Since XML is a subset (superset?) of SGML, I think finding and > > incorporating an XML parser is much easier than a SGML one. > > Probably, yes. > > > I think the biggest tug of war would be between JSON and XML. I would > > likely lean toward JSON, since it's more compact. > > Both are good enough in my eyes, so I guess it'll depend on who actually > writes the first code :) > > > > I think it's important that editing tools are more or less ironclad > > before making a big change. As hard as it is to learn to make and > > submit new/changed content, I'd hate to see it get more intimidating > > through adoption of new formats. > > Well, some people find modifying text files intimidating, I guess... Yes > tools > should be as ironclad as possible, but bugs happen... Besides, a good text > editor nowadays will handle JSON or XML without too much hassle, so > changing > manually would still be possible. > > > > Overall, I'll be sad to see a departure from the current flat files, > > though I acknowledge that the need for something more "standard" is > > legitimate. > > Well, you can always write a parser generator :) > > Given the flat text format definition (in what language?), a generator > that'll > write a parser (and writer) for it. > > Then we can keep the flat files :D > > > Best regards > > > Nicolas___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire IRC: http://crossfire.real-time.com/irc/index.html Discord: http://crossfire.real-time.com/discord/index.html Project Site: https://sourceforge.net/projects/crossfire/ Wiki: http://wiki.cross-fire.org/ Website: http://crossfire.real-time.com
Re: [crossfire] Building in C++?
I think this is a good idea. I was able to build and run crossfire server
with minimal changes on the cpp-buld branch.
Here's my small patch:
- fix building in a 'build' directory
- Add 'build' to .gitignore
- Fix .gitignore to ignore the .cpp version of common/arch_types_valid.c
diff --git a/.gitignore b/.gitignore
index cdb60bf9..bec59837 100644
--- a/.gitignore
+++ b/.gitignore
@@ -517,7 +517,8 @@
/utils/ylwrap
Makefile
Makefile.in
-common/arch_types_valid.c
+build
+common/arch_types_valid.cpp
cov-int/
cscope.*
doc/playbook/handbook.idx
diff --git a/common/Makefile.am b/common/Makefile.am
index 9b08a564..682c0f5c 100644
--- a/common/Makefile.am
+++ b/common/Makefile.am
@@ -74,7 +74,7 @@ libcross_a_SOURCES = \
utils.cpp
loader.cpp:
- $(LEX) -i -o loader.cpp loader.l
+ $(LEX) -i -o loader.cpp $(top_srcdir)/common/loader.l
EXTRA_DIST = README is_valid_types_gen.py
AM_CPPFLAGS = -I$(top_srcdir)/include -DDATADIR=\"$(pkgdatadir)\"
-DCONFDIR=\"$(pkgconfdir)\" \
diff --git a/random_maps/Makefile.am b/random_maps/Makefile.am
index 65e1b3d9..7562133b 100644
--- a/random_maps/Makefile.am
+++ b/random_maps/Makefile.am
@@ -29,7 +29,7 @@ EXTRA_DIST = \
main.cpp
reader.cpp:
- $(LEX) -P rm -o reader.cpp reader.l
+ $(LEX) -P rm -o reader.cpp $(top_srcdir)/random_maps/reader.l
AM_CPPFLAGS = -I$(top_srcdir)/include -I${top_srcdir}/include/random_maps
On Fri, May 27, 2022 at 9:46 AM Nicolas Weeger
wrote:
> Hello.
>
>
> I just pushed branch "cpp-build" which changes all .c files to .cpp files.
> The
> only other changes are what was required for correctly building (adding
> some
> casts, renaming a few variables, things like that).
>
> Functionally, everything is the same.
>
>
> I'd like to merge those changes to master, but well, I'd like to get
> opinions
> before.
>
>
> I don't plan on migrating to a full C++ code base with classes,
> inheritance &
> other things, the current code is fine.
>
> I do plan to use C++ to replace some home-grown things (lists handling
> mostly
> - for new code, I don't want to always have to realloc() and check size, a
> std::vector is enough for that), and to solve issues with object* items
> being
> free'd while still referenced (with our nice check on "count ==
> saved_count"
> here and there urgh).
>
>
>
> Regards
>
>
> Nicolas___
> crossfire mailing list
> crossfire@metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
> IRC: http://crossfire.real-time.com/irc/index.html
> Discord: http://crossfire.real-time.com/discord/index.html
> Project Site: https://sourceforge.net/projects/crossfire/
> Wiki: http://wiki.cross-fire.org/
> Website: http://crossfire.real-time.com
>
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
IRC: http://crossfire.real-time.com/irc/index.html
Discord: http://crossfire.real-time.com/discord/index.html
Project Site: https://sourceforge.net/projects/crossfire/
Wiki: http://wiki.cross-fire.org/
Website: http://crossfire.real-time.com
