GNUstep list announcement

[mcarans]

I announced the release on the GNUstep mailing list and got a nice response from their lead developer:

Thank you for the update. I am excited to see this. I’m definitely going to download and try this.

Thank you, GC
Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron
https://www.openhub.net/languages/objective_c
https://www.gofundme.com/f/cacao-linux- ... ementation

---

Hi all,

I want to thank the developers of GNUstep for their help as I attempted
to modernise Oolite and move it from gcc to clang.

The culmination of that effort is that Oolite has been released on both
the Microsoft Store (https://apps.microsoft.com/detail/9nbhls7xql21) and
FlatHub (https://flathub.org/apps/space.oolite.Oolite).

We welcome new developers to take the game forward as well as
contributors to expansions, graphics, documentation etc.

Cheers,
Mike

[another_commander]

The thread over at the gnustep mailing list seems to have picked up traction, but the last message talks about a very weird crash on Debian. Not sure what's going on there, but I note that in the backtrace provided by the poster there is this strange occurrence:

[...]
#11 0x0000555555addfb5 in +[OOExhaustPlumeEntity exhaustForShip:withDefinition:andScale:] (self=<optimized out>, _cmd=<optimized out>, ship=0x52300003d508,
definition=0x50400138bc58,
scale=<error reading variable: Value cannot be represented as integer of 8 bytes.>) at src/Core/Entities/OOExhaustPlumeEntity.m:63
[...]

The scale variable that "cannot be represented as integer of 8 bytes" is in fact a float variable, so wtf. Possibly a compiler or library issue there?

Reading through the posts I need to also clarify something about Clang's performance. The framerate of the Clang build on Windows is not significantly higher than gcc's, but it is a bit better, there is indeed a small difference when comparing similar build configurations at uncapped framerate and under similar entity loads at the same location between the two builds but it is not that significant. Both hit 400+ fps on my tests but it's not like Clang hitting 600 fps and gcc hitting only 450. Plus, at the end of the day almost everyone plays with v-sync on, which limits framerate to the monitor refresh anyway (60, 70, 120, 144 fps etc.). Where the Clang build shines though, is maintaining a steady frame pace. The Clang build for me offers a gameplay experience that just feels smoother - that's why I recommend it.

[mcarans]

The scale variable that "cannot be represented as integer of 8 bytes" is in fact a float variable, so wtf. Possibly a compiler or library issue there?

Reading through the posts I need to also clarify something about Clang's performance. The framerate of the Clang build on Windows is not significantly higher than gcc's, but it is a bit better, there is indeed a small difference when comparing similar build configurations at uncapped framerate and under similar entity loads at the same location between the two builds but it is not that significant. Both hit 400+ fps on my tests but it's not like Clang hitting 600 fps and gcc hitting only 450. Plus, at the end of the day almost everyone plays with v-sync on, which limits framerate to the monitor refresh anyway (60, 70, 120, 144 fps etc.). Where the Clang build shines though, is maintaining a steady frame pace. The Clang build for me offers a gameplay experience that just feels smoother - that's why I recommend it.

Thanks for letting me know about the followup. I missed it. I replied with a clarification and observed that GNUstep library versions newer than latest stable releases are needed for the clang build. Hopefully using last stable releases is what caused the crash and this will fix it.

[hiran]

The thread over at the gnustep mailing list seems to have picked up traction, but the last message talks about a very weird crash on Debian. Not sure what's going on there, but I note that in the backtrace provided by the poster there is this strange occurrence:

[...]
#11 0x0000555555addfb5 in +[OOExhaustPlumeEntity exhaustForShip:withDefinition:andScale:] (self=<optimized out>, _cmd=<optimized out>, ship=0x52300003d508,
definition=0x50400138bc58,
scale=<error reading variable: Value cannot be represented as integer of 8 bytes.>) at src/Core/Entities/OOExhaustPlumeEntity.m:63
[...]

The scale variable that "cannot be represented as integer of 8 bytes" is in fact a float variable, so wtf. Possibly a compiler or library issue there?

This is interesting, as we are facing two errors.

When I looked at the source code https://github.com/OoliteProject/oolite ... tity.m#L63 my mind was mulling whether it is the execution or the invocation that tries to represent the value as integer. Something has gone wrong in line 63, and I wish I knew what value for scale could not be represented.

With that looking at the quoted text again I see that actually the method parameters are getting printed. I can see the values for ship and definition, both given as hex string of an integer. And then, when the scale should be printed the error is that scale's value cannot be printed as integer.

It is just this backtrace that failed for the integer (something that needs to be fixed upstream), but we still do not know why the backtrace was printed in first place.

[mcarans]

[...]
#11 0x0000555555addfb5 in +[OOExhaustPlumeEntity exhaustForShip:withDefinition:andScale:] (self=<optimized out>, _cmd=<optimized out>, ship=0x52300003d508,
definition=0x50400138bc58,
scale=<error reading variable: Value cannot be represented as integer of 8 bytes.>) at src/Core/Entities/OOExhaustPlumeEntity.m:63
[...]

This is interesting, as we are facing two errors.

When I looked at the source code https://github.com/OoliteProject/oolite ... tity.m#L63 my mind was mulling whether it is the execution or the invocation that tries to represent the value as integer. Something has gone wrong in line 63, and I wish I knew what value for scale could not be represented.

With that looking at the quoted text again I see that actually the method parameters are getting printed. I can see the values for ship and definition, both given as hex string of an integer. And then, when the scale should be printed the error is that scale's value cannot be printed as integer.

It is just this backtrace that failed for the integer (something that needs to be fixed upstream), but we still do not know why the backtrace was printed in first place.

That's a good point. We will have to wait and see if the GNUstep dev (who is the main developer of the GNUstep base library) confirms that the error still occurs when compiling Oolite against newer versions of GNUstep libraries.