NFORenum v3.4.6 released (NFO renumberer and linter)

[DaleStan]

That release is not compliant with the GPL. You failed to include the license.

[planetmaker]

make clean doesn't delete *.d files which will cause build errors, if things change (e.g. target system). Attached diff fixes it.

The license informations are now attached to the binary. Sorry for my sloppyness. All binaries I'm able to make (for win, mac, lin) can now be found with all documentation and license information at http://dev.openttdcoop.org/projects/home/files

[George]

All binaries I'm able to make (for win, mac, lin) can now be found with all documentation and license information at http://dev.openttdcoop.org/projects/home/files

Got a bit confused. Why do grfcodec is r2116 for linux, but 2101 for win?

[Eddi]

because he has problems building grfcodec on windows and nforenum on mac

[planetmaker]

Indeed. At least for grfcodec on win I hope to sort it out in due time, that's most probably some issue with my MinGW install and the paths there. Concerning nforenum on Mac I'm not very optimistic unless I get a different compiler than gcc 4.0 or gcc 3.3 as it seems partially be a generic problem with extern "C" being more rigerous interpreted[1] than healthy on that platform. So, if anyone can build one it would be great, if s/he could publish nforenum for Mac (Tiger) as it would safe me (and not only me) to run a VM in order to make the grfs.

[1] see http://www.gidforums.com/t-9853.html - not sure where in nforenum's or boost's source the exact problem lies.

[DaleStan]

That gives me an idea, finally.

The only instance of extern "C" is in getopt.h.

If <getopt.h> exists on your system, you might try that instead of "getopt.h". Also, it might be instructive to compile with that #include diked out, and/or relocated to just before it is needed.

[Rubidium]

You can fairly easily compile your own Mac compatible (cross) compiler using gcc 4.2. It also compiles NFORenum r2117 without a problem; I don't own a Mac so I can't test it!

Information on how to make a cross compiler for OSX on Linux can be found on http://devs.openttd.org/~truebrain/compile-farm/ and http://rbijker.net/openttd/osx/

Edit: okay, the binary asserts somewhere when cross compiled. I don't have the tools to properly test it, so I can't fix it either.

[planetmaker]

You can fairly easily compile your own Mac compatible (cross) compiler using gcc 4.2. It also compiles NFORenum r2117 without a problem; I don't own a Mac so I can't test it!

Thanks Rubidium Indeed I already considered to setup such compiler, using yours and TB's instructions, and if I don't find a native solution I might just as well do that. In order to complete the set of files, I added that bz2 file also to the files list at http://dev.openttdcoop.org/projects/home/files - I hope you don't mind

The only instance of extern "C" is in getopt.h.
If <getopt.h> exists on your system, you might try that instead of "getopt.h". Also, it might be instructive to compile with that #include diked out, and/or relocated to just before it is needed.

Oh... I'll see wether that works. I already tried yesterday prior to posting just removing the 'extern "C"' directives from that file without any replacement - but without success. I'll see wether I can find a system header file alike and report back.

EDIT: there's some issue with the above posted mac binary, too:

Code: Select all

NFORENUM processing:
renum -w 141 sprites/firs.nfo
NFORenum v3.4.6 r2117 - Copyright 2004-2009 Dale McCoy.
Error: String 3207996 does not exist.
messages.cpp:143: failed assertion `false'
make: *** [sprites/firs.nfo] Abort trap

It works on windows with r2114 just fine. E.g. check out the firs grf hg clone http://mz.openttdcoop.org/hg/firs in order to reproduce, but other grfs I tried produce the same error.

[DaleStan]

I think the message it's trying to produce there is 'Could not open output file "<foo>" for input "<bar>".' (That's the only place I can find where I made a mistake that would trigger that assert.)

If you feel up to hex editing, it shouldn't be hard to fix the binary that way. The string is {Could not open output file "%t" for input "%s".} Change the '%s' to a '%t'. There's one in Czech too, but I doubt you care about that. Check the diff for r2119 if you do.

[planetmaker]

I tried the actual hex edit as you suggested (in the lack of the ability to compile it for mac). For safety reasons I did it for both, English and Czech string. The result, though, remains the same.

[DaleStan]

Then I'll have to ask that the Mac version be compiled with DEBUG defined, and then I'll need the error message that version emits; it contains some extra information.

With r2119 or earlier, "make remake CFLAGAPP=-DDEBUG". With r2120 or later, that'll still work, but so will "make remake DEBUG=1".

[planetmaker]

Hello,

finally I managed to successfully compile nforenum on mac. Obviously gcc 4.0.1 (i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)) has problems with the boost header files, but the current svn version of gcc compiles it successfully.

It gives me one warning, though:

[CC] getopt.o
getopt.c:51:0: warning: "__alloca" redefined
/usr/include/alloca.h:44:0: note: this is the location of the previous definition

ingo$ /usr/local/bin/g++ --version
g++ (GCC) 4.5.0 20090627 (experimental)

The attached binary works for me on OS-X 10.4.11 on an intel CPU. I cannot guarantee that it works elsewhere or even on every system like that, if dynamically-linked libraries should be missing which I have.

[FooBar]

An industry tile action 02:

Code: Select all

//!!Invalid escape sequence.
//    0 * 0	 02 09 21 00
// \d3981
// \dx80008000
// \b0 \b0
// \b1 \b1 \b2

I wonder why this happens with r2124 of nforenum and not with the latest stable. In the 3.4.6 the above snippet is just fine.


Consequently if I use renum 3.4.6 on that code and run it through grfcodec r2123 it tells me "Could not parse unquoted escape sequence.".

The binaries I used come from http://mz.openttdcoop.org/bundles/grfdev/


If I use the latest stable versions of both tools (3.4.6 and 0.9.10 respectively), everything passes perfectly fine...

[andythenorth]

I wonder why this happens with r2124 of nforenum and not with the latest stable. In the 3.4.6 the above snippet is just fine.

Related issue here: grfcodec r2123 (Mac) is choking on the same sprite numbers in firs.nfo. Haven't got an older version of grfcodec to hand, so can't confirm if that fixes the issue.

[planetmaker]

I'm missing a "make install" option. The attached patch introduces this with the default values being those found on a linux (or mac) systems, but the variables could of course be changed. I'm not sure whether there is anything like a default on windows systems or how to obtain it, so this option might not be sensible there.

Further: it's sensible to to call "make release" prior to this. I didn't make it a dependency of "make install" as it's usually a bad idea to have files owned by root in your local user directory, though, as "make release" creates some files.

[DaleStan]

It gives me one warning, though:

[CC] getopt.o
getopt.c:51:0: warning: "__alloca" redefined
/usr/include/alloca.h:44:0: note: this is the location of the previous definition

What does alloca.h:44 look like? If it's what I expect, the solution is pretty obvious, but I don't want to break anything.

An industry tile action 02:

Code: Select all

//!!Invalid escape sequence.
//    0 * 0	 02 09 21 00
// \d3981
// \dx80008000
// \b0 \b0
// \b1 \b1 \b2

I wonder why this happens with r2124 of nforenum and not with the latest stable.

It appears that the fancy, newly refactored, readable, maintainable parser doesn't like reading hex with bit 31 set. Fixed.

[planetmaker]

It gives me one warning, though:

[CC] getopt.o
getopt.c:51:0: warning: "__alloca" redefined
/usr/include/alloca.h:44:0: note: this is the location of the previous definition

What does alloca.h:44 look like? If it's what I expect, the solution is pretty obvious, but I don't want to break anything.

#define __alloca(size) __builtin_alloca(size)

It appears that the fancy, newly refactored, readable, maintainable parser doesn't like reading hex with bit 31 set. Fixed.

Thanks for the fix. Now it parses nicely

[DaleStan]

Hmmm... That's not quite what I expected.

Fortunately, there's another solution.

[FooBar]

It appears that the fancy, newly refactored, readable, maintainable parser doesn't like reading hex with bit 31 set. Fixed.

Thanks a lot!

[FooBar]

Sorry for the double post, but I have something else I like to be noted

When I have this code (varaction 2 of some kind):

Code: Select all

-1 * 0 02 09 B3 //layout 3 
	85 43 //check relative position (00yx[YYXX])
	00 FF FF //don't shift, don't mask
	\b3 //number of ranges to check (number of tiles)
	//pit
	\wx00  01 02  01 02
	\wx01  00 02  00 02
	\wx02  01 00  01 00
	\wx00 //<default> (first sprite available)

Renum tells me "Warning (100): Default ID appears earlier in sprite". While that is undoubtedly true, I don't think that this is an error from my side so I'm not interested in specifying a different default ID. When coded properly the default ID is never reached, so any tile referenced will suffice in this case.

So much for the introduction.
What I want to do is silence this warning. I tried using renum -w 100,141,144 but that didn't work out as expected. While this silences warnings 141 and 144 just fine, it doesn't silence this warning 100.

My question being: is it me that this doesn't work as I expect? Or what can I do to silence this warning 100?