From 6fea5815e6b5a12be44a5f036e5dbafc13a0cf2f Mon Sep 17 00:00:00 2001 From: Gabor Guzmics Date: Wed, 24 May 2017 13:20:18 +0200 Subject: [PATCH] rst --- src/scon/logs/readme.rst | 44 ++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/src/scon/logs/readme.rst b/src/scon/logs/readme.rst index 4e2e934..e7a8a79 100644 --- a/src/scon/logs/readme.rst +++ b/src/scon/logs/readme.rst @@ -8,31 +8,31 @@ 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. +* 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