Oolite Bulletins

Nyarlatothep wrote:

You've got 2 independent arrays there, and by the look of it, there's no guarantee in the code that rating_names has got as many entries as rating_kills. If you try to get a string or a number from past the end of the array, any array, programs do tend to crash a lot.

cim wrote:

Depends on your language. Obj-C's array and dictionary objects just return nil if you ask for something they don't have, though

git wrote:

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at dfc8e1f... Fix bug in disallowedDockingCollides (SVN:5698)

another_commander wrote:

That's why I had proposed initially when the question was asked in another thread that a dictionary be used instead. As Nyarlatothep has pointed out, different size arrays of rating names and rating kills will result in a GNUstep exception being thrown or just a standard crash. So instead of using descriptions.plist array rating names with the core code's array of rating kills, it would be best if everything got read from a dictionary in descriptions.plist, with a format like:

Code: Select all

{
    "Harmless" = 8;
    "Mostly Harmless" = 24; // or whatever it is
    ...
    "Elite" = 6400;
};

This way you have a) everything in one place, nice and neat and b) much less chance of messing up rating names with corresponding kill ratings, with subsequent crashes.

cim wrote:

Pleb: I'm assuming you did the obvious things like shift-restarting after changing descriptions.plist? The only other thing I can see is that if you have the obvious arrangement of elements in the arrays ("Harmless", "Mostly Harmless", etc) vs (0,8,etc.) the oo_stringAtIndex:i to get the rating out should be an oo_stringAtIndex:i-1

The dictionary approach would still be better (though you'd have to be somewhat more complex with the checking code, since dictionary keys will not be returned in order)

another_commander wrote:

1.77.1 is a tagged revision, i.e. the exact revision of the code that was used for the release of version 1.77.1. You are not meant to do a git pull and submodule update if you are working on it. The instructions in the Oolite-PC subforum are for updating the master branch (trunk) code and do not necessarily apply to development happening on side branches. If you chose to play with side branches, I recommend reading the github online documentation first, because git is not exactly the simplest of version control systems.

At this stage, I would try a git checkout 1.77.1 again, re-apply changes you have made and NOT attempt another git pull or submodule update. Submodules are separate sub-projects in the repository and have their own revision system. By updating them, you basically bring them to their latest revision, which is what trunk uses.

Edit: When I do a git checkout 1.77.1 I get the below message. Maybe it's worth following the instruction contained therein, but I have not tried it myself and cannot guarantee how it will work for you.

git wrote:

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at dfc8e1f... Fix bug in disallowedDockingCollides (SVN:5698)

In any case, the v1.77.1 source code tarball is also available for download from github in both .zip and .tar.gz formats. If all else fails, you can always download that, unzip it to a folder of your choice, then use the development environment to cd into that folder and run make debug=no. That's completely independent of git, though.

JensAyton wrote:

cim wrote:

Depends on your language. Obj-C's array and dictionary objects just return nil if you ask for something they don't have, though

You’d think, but NSArray throws an exception, which is de facto a crash.

another_commander wrote:

it would be best if everything got read from a dictionary in descriptions.plist

Nyarlatothep wrote:

You could hijack the code that prints to the log file as a modern version of ye olde PRINT debugging, and sure enough it will let you know the exact point where the code falls over.

$ gdb oolite.app/oolite.dbg
...gdb loads the program and prepares to run it
(gdb) run
...gdb runs the program
...it crashes
(gdb) bt
#0  0x00007ffff50876c0 in objc_msg_lookup ()
   from /usr/lib/x86_64-linux-gnu/libobjc.so.4
#1  0x00000000005d16b6 in TreeSplay (root=0x7fffd4207060, key=0x3e869d0)
    at src/Core/OOCache.m:704
#2  0x00000000005d0fa9 in CacheRemove (cache=0x7fffd4207060, key=0x3e869d0)
    at src/Core/OOCache.m:481
#3  0x00000000005d110e in CacheRemoveOldest (cache=0x7fffd4207060, 
    logKey=0x7fffdd415990) at src/Core/OOCache.m:512
...and so on

Zireael wrote:

*dun dun*

Thanks for this, Pleb. Can we get this into git source soon? *puppy eyes*