RST fun!

This commit is contained in:
Gabor Körber 2017-05-24 13:30:44 +02:00
parent 92ed5e913c
commit ae19a12fd0

View File

@ -7,18 +7,21 @@ It defines classes for opening logfiles from zips, directories, or as a stream,
The Parsing Mechanism
---------------------
In this example, parsing complete files:
* Sessions represent a container which hold logfiles from the same directory.
* ``LogSessionCollector`` is a helper class to build sessions from a directory containing many log-directories, i call sessions.
* ``Session`` represents a container which hold logfiles from the same directory.
- it can open zipped logs aswell as directories
- it has a parse_files method which initiates first pass parsing for the given filenames in the package.
- only 'game.log', 'combat.log' and 'chat.log' are supported for now as session.game_log, session.combat_log and session.chat_log.
- you can only parse one of those files, e.g. first only game log, later combat or chat.
* Logfile class directly has 'lines' property holding all the 'lines from the log'. Each kind of logfile has its own subclass in logfiles.
* this lines list is converted from a string list to dictionaries, containing log, logtype, and timestamp data in the first parsing.
- you are able to parse just a subset of those files, e.g. first only game log, later combat or chat.
* ``Logfile`` class directly has 'lines' property holding all the 'lines from the log'. Each kind of logfile has its own subclass in logfiles.
* this ``lines`` list is converted from a string list to dictionaries, containing 'log', 'logtype', and split timestamp data in the first parsing.
As you might know, this is the same for all logs in SC
* these dicts are scanned by the class factories and replaced with class based representations of the log packet, coming from their submodule.
- the dict is moved into the dict .values of the created class.
* usually at this point, one would discard all dicts, as they represent unknown or unimportant data, what you have left is a list of classes.
- this is the first pass that happens if you call parse_files.
* usually at this point, one would discard all dicts, as they represent unknown or unimportant data, what you have left is a list of classes. this is optional.
from here, all lines contain some instance of a class, already telling us, which kind of log this is
from here, all lines contain some instance of a class, already telling us, which kind of log this is, by its class itself,
however to update the rest of the log information, one has to at least call "unpack" once on the instance.
having this finetuned in multiple steps however allows us to gain speed by ignoring unwanted information (as combat logs e.g. tend to be large)
all other functionality is planend to be in the high level api .game
@ -26,17 +29,16 @@ all other functionality is planend to be in the high level api .game
e.g.::
for line in game_log.lines:
if isinstance(line, Log):
if line.unpack():
print(line.values.keys())
if isinstance(line, Log):
if line.unpack():
print(line.values.keys())
| unpack can be called several times, as it only unpacks once.
| *unpack can be called several times, as it only unpacks once.*
For the programmer, following submodules are of particular interest
Game
----