aliens

Author Topic: Logging support (for bug reports and stuff)  (Read 12124 times)

Offline Dabb

  • Squaddie
  • *
  • Posts: 5
  • just another old school programmer...
    • View Profile
Logging support (for bug reports and stuff)
« on: December 07, 2011, 05:35:19 pm »
Hi,

I was wondering if there has been any talk about including runtime logging support into openxcom? I mean logging stuff into proper LOG file or console. (or maybe there is already one within code and I just didnt spot it yet).

Of course, as long as most of the testing is done by developers itself and people capable of resolving and producing good bug reports, its not so big deal, but in a longer run... me I personally prefer log files, bigger the better :-)

When crash or bug occurs, its very useful to know what is the host OS is, what video card system has and other information. Sure, user can provide that too, but sometimes, well, lets just say some users do know they use "Windows", or "Linux", but dont get all the details right... (like running WinXP without any service packs ...). And log files can provide developers that information in standard and compact form.

Well, now I'm just waiting for that "openxcom.log" file to appear in my xcom dir - well, actually it already did, but now I'm waiting for the "master" code to get one too, hehe  :D

***** 12/07/11 18:45:57: [info] OpenXcom v0.3
***** 12/07/11 18:45:57: [info] Running on: Windows 7 (build 7601, Service Pack 1) (64bit)
...
There are many portable multithread-safe logging classes to choose from. . One example specifically made for games is Logog https://johnwbyrd.github.com/logog/.

There are lot of alternatives too and many libs have included their own "logging" classes too.

I wish all the best for the project - XCom was my favourite games for a long time. And I want it back too, just as it was, but without bugs!

Well, I also want to use LUA for AI, but thats different story, hehe.

Dabb
« Last Edit: December 07, 2011, 06:52:02 pm by Dabb »

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #1 on: December 07, 2011, 07:52:31 pm »
Well, I also want to use LUA for AI, but thats different story, hehe.

Fork and do it :D

As for console - quake like console would be cool ;)

Offline Yankes

  • Global Moderator
  • Commander
  • *****
  • Posts: 3350
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #2 on: December 08, 2011, 12:50:24 am »
give all;
god;
? :D

Offline Dabb

  • Squaddie
  • *
  • Posts: 5
  • just another old school programmer...
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #3 on: December 08, 2011, 02:46:20 pm »
Fork and do it :D

As for console - quake like console would be cool ;)

Heh, I think I'll wait until UFO: AI people have got their "LUA AI" and other AI stuff propely implemented and then go see if there are useful ideas and pieces to pick...

Quake console, hm, thats intersting idea - with cvars/commands of course. Though using SDL might make it bit more painful, it should be fairly easy to make it as "consolestate", availabe from any game state.

But proper logging, thats something what needs to get done, sooner or later...

Offline michal

  • Commander
  • *****
  • Posts: 629
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #4 on: December 08, 2011, 09:44:10 pm »
Isn't LUA AI for Ufo: ai dead?

Offline Dabb

  • Squaddie
  • *
  • Posts: 5
  • just another old school programmer...
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #5 on: December 09, 2011, 05:56:47 pm »
Isn't LUA AI for Ufo: ai dead?
Hm, I did seem to read something about performance problems with AI and using LUA can make those even worse.

But back to the topic.

I've been playing around with the code and implementing logging support into it without affecting the code itself much. Right now, it adds one file to the project, logging.h but also requires logog library. (goes into deps/logog). I can also implement without using logog, but right now for testing, its fast way to go and less buggy.

Logging level set at COMPILE time decides if logging gets compiled into binary or not.  When logging is set to NONE, there is NO ADDITIONAL CODE compiled with the project. When its set to INFO, only ERROR and WARNING are compiled in (and also logged).

Usage is simple
INFO("This is information level message")
turns into
Quote
***** 12/09/11 17:37:29: [info] : This is information level message

Right now categories are AUDIO, VIDEO, ENGINE, AI, GENERAL (being errors, infos and all the other unclassified ones).

Of course, when it really starts to make "sense", (or not) is when you turn on logging for "AI" category (you can specify categories for logging and filter them).

Quote
***** 12/09/11 17:45:49: [info] [AI] : PatrolBAIState::think started for UnitID #13
***** 12/09/11 17:45:49: [info] [AI] : PatrolBAIState: No destination for UnitID #13: Figuring where to go next
***** 12/09/11 17:45:49: [info] [AI] : PatrolBAIState: (solution 1 assault/recovery) UnitID #13 going to move to #98
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState::think started for UnitID #9
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState: No destination for UnitID #9: Figuring where to go next
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState: (solution 2) UnitID #9 going to move to 79
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState: UnitID #9 is going to walk some

So now I know why that little gray bugger went for a swim instead of shooting me .. well I don't - but I will, soon, heh.

LOGOG_AI_DBUG("AggroBAIState: Gray wants more water");


Offline Daiky

  • Battlescape Programmer
  • Administrator
  • Commander
  • *****
  • Posts: 904
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #6 on: December 09, 2011, 06:11:06 pm »
for debugging AI (real AI is only planned for 0.5), I already had implemented a text field which is shown top left on the screen when in debug mode. But a logfile might be more interesting, because the AI will go so fast, you can only read that info on the screen, if the program would sleep a bit after each message.

I'm only a bit afraid for the extra dependency/library... SupSuper is not very fond of them :)

Offline Dabb

  • Squaddie
  • *
  • Posts: 5
  • just another old school programmer...
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #7 on: December 09, 2011, 06:37:24 pm »
I'm only a bit afraid for the extra dependency/library... SupSuper is not very fond of them :)

Well, I'm not suggesting including "new library", I'm just suggestin putting (some form) of logging in.

Same thing can be accomplished with just logging.cpp and logging.h file - no need for "external" library. Just needs some coding and loving to make simple logging implementation :)

Logog has some nice features though:
- "any" number of targets (console, log file(s)) can be easily added
- different formatter can be set for each target
- different "groups" and filters (video,audio,ai whatever) can go do different targets (for example, you can have additional target, which just logs "AI" messages to console or different file or both).
- multithread safe, portable

And though I've spotted couple of nasty things in it already, i've seen worse, hehe.

Just though it would be useful to have for the project.

Now if I just could stop killing aliens and go back coding...



« Last Edit: December 09, 2011, 06:48:06 pm by Dabb »

Offline Dabb

  • Squaddie
  • *
  • Posts: 5
  • just another old school programmer...
    • View Profile
Re: Logging support (for bug reports and stuff)
« Reply #8 on: December 10, 2011, 11:03:33 am »
Well, if you want to test out Logog library for logging purposes, here is simple patch which just includes Logging.h and simple init for main.cpp. Only tested for MSVC++.

Get and compile Logog library from:
https://johnwbyrd.github.com/logog/

- put Logog include files into openxcom\deps\include\logog
- put logog.lib into openxcom\deps\lib

Patch doesnt screw up your project files, so you have to do it yourself :-)
- add ..deps\include\logog into your project include
- add logog.lib to your project linker input depencies
- add Logging.h to your project files

- also remember to add #include "Engine\Logging.h"  to any file you want to use logging (well, I add it to one central .h file which gets included in every file...)

And then just go test...
INFO("This won't work, no way.");
DBUG_GROUP("AI","Alien AI is going to get you");
DBUG_GROUP("VIDEO","Another video failure, bah!");
...

And when you start loving the fine Log Files you have and all the information you get from them, you can code your own implementation of Logging class, so you dont have to use library. Might do that myself lateron, but not until after Christmas or something, if ever.


Offline alienjon

  • Sergeant
  • **
  • Posts: 12
    • View Profile
    • Cybernetic Pit-Stop
Re: Logging support (for bug reports and stuff)
« Reply #9 on: December 13, 2011, 04:20:24 am »
There's a (I suppose simple) logger that I've written for my own projects with a few options.  No dependencies or anything, just a simple text output to a error.log file.  Here's the implementation, if people think it's interesting enough I can incorporate/push it for people to check out more seriously.  It's all static so a log output can be requested anywhere that Logger.hpp is included:

Code: [Select]
/**
* @brief A domain error.
* @param e The error.
*/
static void error(const std::domain_error& e);

/**
* @brief An invalid argument error.
* @param e The error.
*/
static void error(const std::invalid_argument& e);

/**
* @brief A length error.
* @param e The error.
*/
static void error(const std::length_error& e);

/**
* @brief An out of range error.
* @param e The error.
*/
static void error(const std::out_of_range& e);

/**
* @brief A logic error.
* @param e The error.
*/
static void error(const std::logic_error& e);

/**
* @brief A range error.
* @param e The error.
*/
static void error(const std::range_error e);

/**
* @brief An overflow error.
* @param e The error.
*/
static void error(const std::overflow_error& e);

/**
* @brief An underflow error.
* @param e The error.
*/
static void error(const std::underflow_error& e);

/**
* @brief A runtime error.
* @param e The error.
*/
static void error(const std::runtime_error& e);

/**
* @brief A general std error.
* @param e The error.
*/
static void error(const std::exception& e);

/**
* @brief A non-exception error.
* @param error The error.
*/
static void error(const std::string& error);

/**
* @brief Log an informational message.
* @param message The message.
*/
static void log(const std::string& message);

/**
* @brief Log a warning.
* @param warning The warning.
*/
static void warn(const std::string& warning);