It lives!

[JensAyton]

Oolite has grabbed hold of me by the head and pulled me in. I’ll probably be throwing together a test build for OS X soon so we can work out what’s changed and what’s broken. (One thing that is in there, which was inquired about recently, is special indication for large objects on the scanner.) Also, Giles hasn’t responded to my query about another_commander’s Advanced Navigational Array. I think I’ll choose to interpret that as “not no”.

But now I’d like to talk about what I’m working on because, well, attention-whoring is half the fun. It’s… a slightly improved logging system. “Woot”, I hear you cry. (Warning: if you’re not a geek, do not read this lest your eyes glaze over.)

What it does is allow you to turn groups of related log messages on and off using the preferences file. By default, most messages will be on (so logs from newbies will contain everything), but when you’re working on scripts (or the game itself) you can turn off vast swathes of irrelevant noise and concentrate on the messages related to what you’re actually doing. This also means that the developers can ask a user to turn on certain debug messages that are usually off (for instance, sound-related ones) to work on a particular problem, without requiring special builds.

Example: every time Oolite starts, it dumps all the places it looks for files in (generally the first thing in the log). I generally don’t care about this, so I look at the first line of this dump and see:

Code: Select all

[searchPaths.dumpAll]: ---> searching paths:

This means the “message class” of the message is “searchPaths.dumpAll”. I type in the following at the terminal:

Code: Select all

% oolog searchPaths.dumpAll no
> Setting OOLogging flag searchPaths.dumpAll to no

…and run Oolite again, and it’s gone.

Also, that list of OpenGL extensions, and all the stuff about adding various classes of vessels to the Lave system, are also of no interest. They’re also conceptually related. How about disabling them as a group?

Code: Select all

% oolog \$troubleShootingDump no
> Setting OOLogging flag $troubleShootingDump to no

…and they’re all gone. How does this work? Well, the default states for message classes are set in the new configuration file logcontrol.plist, which contains lines like:

Code: Select all

$troubleShootingDump = yes;
rendering.opengl.extensions = $troubleShootingDump;
searchPaths.dumpAll = $troubleShootingDump;
universe.populate = $troubleShootingDump;

Here, $troubleShootingDump is a “metaclass” of log messages, used to control groups of similar message classes. Other predefined metaclasses are $scriptError, $error and $entityState (the latter controls various AI and scripting messages). You can also create and use your own metaclasses:

Code: Select all

% oolog \$myMetaClass yes
> Setting OOLogging flag $myMetaClass to no
% oolog dataCache \$myMetaClass
> Setting OOLogging flag dataCache to $myMetaClass
% oolog script.addShips \$myMetaClass
> Setting OOLogging flag script.addShips to $myMetaClass

The dots in the name suggest that message classes form a hierarchy, which is indeed the case. If a message class is set to “inherit”, or is not defined anywhere, the logging system will delete everything after the last . and try again; for instance, asked to log a message in the class script.addShips.success, given the definitions:

Code: Select all

script.addShips.success = inherit;
script.addShips.failed = $scriptError;
_default = yes;

the logger will look for script.addShips.success, see it’s defined to inherit, look for script.addShips, see it’s undefined, look for script, see it’s undefined, then look for the universal fallback _default. On the other hand, if it looks for script.addShips.failed, it sees $scriptError, looks for $scriptError, finds that undefined, and again goes for _default.

Obviously this is all extremely nerdy, but if you spend any time sifting through the log you’ll probably have a use for it.

Some notes:

• The majority of log calls (there are over a thousand) have not been updated to the new system, and will therefore be of class “unclassified”. However, the ones that spew the most – at least, on my system – will be in the test release.
• Currently, the oolog tool is a trivial shell script – “oolog foo bar” is eqivalent to “defaults write org.aegidian.oolite logging-enable -dict-add foo bar”. I don’t know whether this will work with GNUstep. A slightly more sophisticated tool won’t be hard.
• I’m working on applying the new logging system to the scripting stuff. The debugOn script action will set script.debug (and thus everything that inherits from it) to yes, and debugOff… well, guess.
• The logger very deliberately doesn’t look in OXPs for settings.
• Some other thing I forgot.

[Arexack_Heretic]

Just let me state:

WOOOT!

well done Commander!

[Cmdr. Maegil]

I CAN'T SEE!!! MY EYES GLAZED OVER!!!

AAAAaaaaaarrrrrrgh!!!

[JensAyton]

I’m working on applying the new logging system to the scripting stuff. The debugOn script action will set script.debug (and thus everything that inherits from it) to yes, and debugOff… well, guess.

Actually, I realised that I want to be able to switch that stuff off and ignore OXPs’ scripts. So now, debugOn/debugOff will modify the $scriptDebugOn metaclass, and script.debug will be set to $scriptDebugOn by default. I can then squish them all by setting script.debug to no instead. I knew those metaclasses were good for something. :-p

[Cmdr. Maegil]

My head is swelling! Oh, no, quick, pass me a vise before it ex...

BLAM

[Captain Hesperus]

My head is swelling! Oh, no, quick, pass me a vise before it ex...

BLAM

Ick. Someone get a mop, before this stains the floor.

Captain Hesperus
"That's something you don't see everyday."

[Arexack_Heretic]

Is there a way to specifically tag an oxp for inclusion in debugging?

[Star Gazer]

excellent!!!
I'd like to offer heartfelt thanks on behalf of all the Mac peoples!!

[JensAyton]

Is there a way to specifically tag an oxp for inclusion in debugging?

No. The necessary information isn’t available where most of the log messages are generated.

I may add a verson of debugMessage: which takes a message class parameter, but all the other debug messages are either on or off. The solution, of course, is for people to stop distributing OXPs with debugOn/debugOff (or bugs) in. :-)

[Arexack_Heretic]

people to stop distributing OXPs with debugOn/debugOff (or bugs) in.

That would be ideal yes.

@sig:
...Who watches the watchers eh?

[cade]

I thought the sig was

"who would watch the guards themselves"

By the way, I read the above with only one eye, so at least the other still works.

Now a real use for that eyepatch.

Cmdr Cade

[JensAyton]

Clearly this post broke everyone’s brain, since no-one’s downloaded the update yet. :-)

[Cmdr. Maegil]

A direct translarion of "sed quis custodiet ipsos custodes?" is:

sed = but
quis = whom
custodiet = will/shall guard
ipsos = the refered (reflexive as in themselves)
custodes = guardians

In english this isn't so hard, in most cases the grammar allows to just exchange word for word.

[Cmdr. Maegil]

Clearly this post broke everyone’s brain, since no-one’s downloaded the update yet.

It says it's for Mac OS... I'm a poor Windows user!

[TGHC]

Ditto, I'm straining at the leash here!