135 lines
4.5 KiB
ReStructuredText
135 lines
4.5 KiB
ReStructuredText
Debugger
|
|
========
|
|
|
|
Abstract
|
|
--------
|
|
The purpose of the debugger is to ease to understand why Sheerka does not behave like it should.
|
|
(yes, this could happen). I have have just started so, they are a lot of
|
|
functionalities that we usually found in a debugger that are not yet implemented
|
|
|
|
I guess that the first thing to know is that I want to design a 'smart' debugger,
|
|
which can be configured in a 'declarative' way. It means that, rather that telling
|
|
it what to do, I would prefer tell it what is expected.
|
|
|
|
As of now (2021-01-11), I am far from it, so let's explain how to use the debugger,
|
|
in an 'imperative' way.
|
|
|
|
First, you need to enable the debugger. As it consumes resource, it is deactivated by default ::
|
|
|
|
set_debug()
|
|
|
|
|
|
There are three types of objects that can be debugged :
|
|
|
|
* variables
|
|
* concepts
|
|
* rules
|
|
|
|
Debug Settings
|
|
--------------
|
|
|
|
Path to object
|
|
**************
|
|
Whatever the type of object to be displayed, it lies within a method name, which is itself inside a service.
|
|
|
|
For example, the out_tree (the ast tree that contains what to print once an input is evaluated) is under the service
|
|
'Out' and within the method 'create_out_tree'
|
|
|
|
The information regarding the evaluation of the rule #1 is under the service 'EvaluateRules', and within the method 'evaluate_rule'
|
|
|
|
Context id
|
|
**********
|
|
The same object may be requested several times. To distinguish different execution, the ExecutionContext id is used.
|
|
When using the context id, you can precise if you want to debug a specific context, or a context and its children
|
|
|
|
Debug id
|
|
********
|
|
The debug id is supposed to regroup information of the same unit of processing together. For example, within the same context,
|
|
if a specific piece of processing is called several times (because of a loop for example), they will share the same context id,
|
|
but they will have different debug id.
|
|
|
|
Note that as of now, this does not
|
|
work very well. This information need to be tuned.
|
|
|
|
Debug Variables
|
|
---------------
|
|
|
|
Debugging variables let you see the content of variables, but also the execution flow of a piece of program.
|
|
This execution flow gives a context to the variables
|
|
|
|
To activate variable debugging :
|
|
|
|
debug_var(<path_to_variable>, <context_id>, <debug_id>)
|
|
|
|
|
|
With:
|
|
|
|
* path_to_variable
|
|
* 'service_name' : Activates the debug logs for all methods of the service. The variable won't be shown
|
|
* 'service_name.method_name' : Activates the debug logs for the specific method of the service, the variables won't be shown
|
|
* 'service_name.method_name.variable_name' : Activates the display of a variable, within a specific method, for a specific service
|
|
* 'service_name.*'
|
|
|
|
* context_id
|
|
* context_id
|
|
* 'context_id+' (context_id followed by the sign '+')
|
|
|
|
* debug_id
|
|
* debug_id
|
|
|
|
Debug Rule
|
|
---------------
|
|
|
|
Debugging rules let you see how the rules are evaluated, but also the execution flow of the evaluation.
|
|
|
|
To activate rule debugging :
|
|
|
|
debug_var(<path_to_rule>, <context_id>, <debug_id>)
|
|
|
|
|
|
With:
|
|
|
|
* path_to_rule (when a string is given)
|
|
* 'service_name' : Activates the debug logs for all methods of the service. The variable won't be shown
|
|
* 'service_name.method_name' : Activates the debug logs for the specific method of the service, the variables won't be shown
|
|
* 'service_name.method_name.rule_id' : Activates the debug of a specific rule, within a specific method, for a specific service
|
|
* 'service_name.*'
|
|
|
|
* path_to_rule (when an integer is given)
|
|
* rule_id
|
|
|
|
* context_id
|
|
* context_id
|
|
* 'context_id+' (context_id followed by the sign '+')
|
|
|
|
* debug_id
|
|
* debug_id
|
|
|
|
|
|
Debug Concept
|
|
---------------
|
|
|
|
Debugging concept let you see how the concepts are evaluated, but also the execution flow of the evaluation.
|
|
|
|
To activate concept debugging :
|
|
|
|
debug_var(<path_to_concept>, <context_id>, <debug_id>)
|
|
|
|
|
|
With:
|
|
|
|
* path_to_concept when a string is given
|
|
* 'service_name' : Activates the debug logs for all methods of the service. The variable won't be shown
|
|
* 'service_name.method_name' : Activates the debug logs for the specific method of the service, the variables won't be shown
|
|
* 'service_name.method_name.concept_id' : Activates the debug of a specific concept, within a specific method, for a specific service
|
|
* 'service_name.*'
|
|
|
|
* path_to_concept when an integer is given
|
|
* concept_id
|
|
|
|
* context_id
|
|
* context_id
|
|
* 'context_id+' (context_id followed by the sign '+')
|
|
|
|
* debug_id
|
|
* debug_id |