Errors and warnings when building 1.77 trunk

[Eric Walch]

I also don't know the exact differences, but with test builds, the compiler is trying to make a bit more efficient code by doing more compiler passes. In debug builds there is only an efficiency for maximum compiler speed. The exact differences may differ between compilers.
In function there should be no differences other than the test release code might result in an Oolite version running a bit more efficient (=faster).

The deployment (=release) version does result in different code. There all kind of internal checks are skipped. But deployment versions have never been released. Although the next release should be one.

(edit: ninja by cim)

I use XCode 3.x and that currently gives an rel32 error during the compiling process. Reading about it, it means that the addressing exceeds the 32 bit limit. That means the code must grow over the 2 GB border during compiling. That is probably because of the fast but inefficient way of compiling. With test releases the compilation is a bit more efficient and I can avoid that error that is bothering me for the past few weeks.

[Gimi]

I have two environments now, one with debug and one without. Never got as far as updating my debug build with r5168. Why would that matter though? (Explained in layman terms please.)

Also (again in layman terms), when you say a test compile, do you mean with "debug=no". I got no warnings or errors with r5169, either with "debug=no" or "debug=yes".

debug => "debug=yes"
test => "debug=no"
release => "DEPLOYMENT_RELEASE_CONFIGURATION=yes debug=no"

The different build types have some differences in which code is enabled (e.g. test and debug have debug info on the FPS counter, but release doesn't), and what compiler settings are used to build it (e.g. test and release compiles are optimised for execution speed, while debug compiles are optimised for faster compilation and easier debugging). As a result some bugs only affect some but not all build types.

Thanks cim and Eric. I'll start building both debug and test before reporting errors then, hopefully being able to provide some extra information.

[JensAyton]

I also don't know the exact differences, but with test builds, the compiler is trying to make a bit more efficient code by doing more compiler passes. In debug builds there is only an efficiency for maximum compiler speed. The exact differences may differ between compilers.
In function there should be no differences other than the test release code might result in an Oolite version running a bit more efficient (=faster).

There are functional differences too. Search for OO_DEBUG. The biggest is that in a debug build, Oolite will tell you exactly what line of code causes an OpenGL error (which is quite expensive since it needs to synchronise OpenGL state with the graphics card before and after every OpenGL operation). There’s a bunch of extra logging (some of which is supposed to show up on the startup screen on Macs, but this doesn’t work in 10.8) and the potentially dangerous JS callObjC() method is available.

Oh, and the fascinating vector and quaternion statistics tools are available: PS.callObjC("reportJSVectorStatistics") and PS.callObjC("reportJSQuaternionStatistics"). How could you live without those? :-)

[Gimi]

Following errors when building test build r5208:

Code: Select all

 Compiling file src/SDL/MyOpenGLView.m ...
src/SDL/MyOpenGLView.m: In function '-[MyOpenGLView noteMouseInteractionModeChangedFrom:to:]':
src/SDL/MyOpenGLView.m:452: error: 'mode' undeclared (first use in this function)
src/SDL/MyOpenGLView.m:452: error: (Each undeclared identifier is reported only once
src/SDL/MyOpenGLView.m:452: error: for each function it appears in.)
make[3]: *** [obj.win.spk/oolite.obj/MyOpenGLView.m.o] Error 1
make[2]: *** [internal-objc_program-all_] Error 2
make[1]: *** [oolite.all.objc-program.variables] Error 2
make: *** [internal-all] Error 2

Same error when doing a debug build.

[JensAyton]

Well, that was silly. (Fixed in r5209.)

[Gimi]

Well, that was silly. (Fixed in r5209.)

That did the trick, thanks Ahruman.

[Gimi]

Another compile error, this time with r5212.

Code: Select all

 Compiling file src/Core/Universe.m ...
 Linking objc_program oolite ...
./obj.win.spk/oolite.obj/OOJSVisualEffect.m.o:OOJSVisualEffect.m:(.rdata+0x0): multiple definition of `_objc_category_name_OOVisualEffectEntity_OOJavaScriptExtensions'
./obj.win.spk/oolite.obj/EntityOOJavaScriptExtensions.m.o:EntityOOJavaScriptExtensions.m:(.rdata+0x0): first defined here
collect2: ld returned 1 exit status
make[3]: *** [obj.win.spk/oolite.exe] Error 1
make[2]: *** [internal-objc_program-all_] Error 2
make[1]: *** [oolite.all.objc-program.variables] Error 2
make: *** [internal-all] Error 2

[cim]

Hopefully fixed with r5215

[Gimi]

Hopefully fixed with r5215

R5215 compiled fine. Thanks cim.

[Tricky]

Compile warning and error with r5260...

Code: Select all

 Compiling file src/Core/Entities/ShipEntity.m ...
src/Core/Entities/ShipEntity.m: In function '-[ShipEntity firePlasmaShotAtOffset:speed:color:direction:]':
src/Core/Entities/ShipEntity.m:10182: warning: conflicting types for '-(BOOL)firePlasmaShotAtOffset:(double)offset speed:(double)speed color:(OOColor *)color direction:(OOWeaponFacing)direction'
src/Core/Entities/ShipEntity.m:157: warning: previous declaration of '-(BOOL)firePlasmaShotAtOffset:(double)offset speed:(double)speed color:(OOColor *)color direction:(OOViewID)direction'

Code: Select all

 Compiling file src/Core/Scripting/OOJavaScriptEngine.m ...
src/Core/Scripting/OOJavaScriptEngine.m: In function 'JSArrayFromNSArray':
src/Core/Scripting/OOJavaScriptEngine.m:1202: error: expected declaration specifiers or '...' before '...' token
src/Core/Scripting/OOJavaScriptEngine.m:1203: error: '@try' without '@catch' or '@finally'

[JensAyton]

Should be fixed in r5262.

[Tricky]

No more warnings or errors. Thanks.

As an aside, I've noticed a lot of 'integer trucation' fixes. Does this mean that when you check 'PS.fuel' in the debug console it won't return something like '6.6000000000000005' rather than '6.6'.

[JensAyton]

No. Those aren’t integers. :-) The fixes are cases where 64-bit values are being copied to 32-bit variables – mostly not a serious problem, but it can cause obscure bugs in some cases. This stuff should have been fixed up when we started supporting 64-bit builds, but I missed the relevant warning setting. There were something like 280 cases, and I’ve addressed about half of them.

[Tricky]

I've learnt not to make assumptions about types when it comes to data format in *lite coding.

f.i. in old Elite coding, fuel = 53 meant 5.3LY simply because it was easier (and more code/data efficient) to deal with integers rather than floats. (This is for those who aren't old enough to remember the original - not you Ahruman)

So what does cause the strange rounding?

[JensAyton]

So what does cause the strange rounding?

A finite series of digits in base 10 can only represent a fractional value if it is a sum of negative powers of ten. In the same way, a finite series of bits in base 2 can only represent a fractional value if it is a sum of negative powers of 2.

To represent 6.6 as a floating-point number, it is decomposed to 0.825 × 2³. 0.825 cannot be represented as a sum of negative powers of two (you end up with 0.5 + 0.25 + 0.0625 + 0.0078125… = 0.1101001…₂) so it needs to be rounded. (The representation uses 56 bits for the fractional part, with the integer part always being 0.)

That said, you shouldn’t see 6.6000000000000005 in the console (as opposed to the log, possibly) because it’s supposed to be converted with a lower precision to hide all this.