explain parsing mechanism, so i dont forget it.

This commit is contained in:
Gabor Körber 2017-05-24 13:15:51 +02:00
parent 39b1f57b50
commit ff0b0bfd19

View File

@ -4,6 +4,37 @@ Logs Submodule
The Logs Submodule is the core parsing mechanism in Scon. The Logs Submodule is the core parsing mechanism in Scon.
It defines classes for opening logfiles from zips, directories, or as a stream, and are intended to be used by higher level apis to adjust to the wanted log retrieval scenario, while keeping the base logic how logs are interpreted unified. It defines classes for opening logfiles from zips, directories, or as a stream, and are intended to be used by higher level apis to adjust to the wanted log retrieval scenario, while keeping the base logic how logs are interpreted unified.
The Parsing Mechanism
---------------------
In this example, parsing complete files:
* Sessions represent a container which hold logfiles from the same directory.
-> 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.
* 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.
from here, all lines contain some instance of a class, already telling us, which kind of log this is
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
e.g.:
for line in game_log.lines:
if isinstance(line, Log):
if line.unpack():
print(line.values.keys())
-> unpack can be called several times, as it only unpacks once.
For the programmer, following submodules are of particular interest For the programmer, following submodules are of particular interest
Game Game