src/fsm/measures/manager.c fsm measures manager #include <stdbool.h>#include <stdio.h>#include <stdlib.h>#include "../../../include/fsm.h"Include dependency graph for manager.c: void fsm_add_measure (char *measure_name) void fsm_list_init_measures () void fsm_rule_trig_measure (int rule_id, int object_id, int measure_id)

fsm measures manager This file is part of Gem-graph. It inits the three lists used for measurements and results management: tools, data and displayables (disp) and provides access. F R O M M E A S U R E M E N T S T O P R E S E N T A T I O N S How should the sequence from measurements to results presentation be organized ? (1) create/edit some mesurement tools and/or activate existing ones (2) apply a mesurement tool to a situation to create a new data list data list = x, f(x), g(x),... these data are collected by the server and send to the client and possibly carry out any operations on these results (3) display (plot) the results and adjust the appearance of the tables As a consequence, three lists at least must be created and maintained : (1) a mesurement tools list (see : fsm/measure/tool_list.c) which should mention if the tool is 'active' or 'inactive NB each rule ou rules-tree edition may change some items of that list (2) a data flows list (see : fsm/measure/flow_list.c) (it could either be named : fsm/measure/data_list.c) on which some operations could be performed : ex : filter, concat, inverse, scale, correlate, etc. NB each data flow should be available in a 'displayable form' (3) a displayed data list (see : fsm/measure/disp_list.c) NB some data may be displayed simultaneously in different pages ex : SYNTH & RESULTS NB these three lists should be stored in the XML model and restored at the beginning of a new session (4) a journal (a pile) stores chronologically the fsm events during a session run (rules exec, mainly) in a journal (.log) one by session When a rule is adequately tagged, it triggers a measure : fsm_rule_trig_measure (rule_id, object_id, measure_id) {...} The measurement is then taken and the result stored.

fsm_add_measuremanager.c manager.cfsm_add_measure void fsm_add_measure (char * measure_name) 2024-09 src/widget/measure/dispatch/widget_measure_event_occurences_nb() src/widget/measure/dispatch/widget_measure_event_occurences_dates() src/widget/measure/dispatch/widget_measure_event_occurences_situations() src/widget/measure/dispatch/widget_measure_time_elapsed_between_two_events() src/widget/measure/dispatch/widget_measure_third_event_occurences_in_between() src/fsm/dispatch/fsm_add_log() *measure_name Here is the call graph for this function: Here is the caller graph for this function:

fsm_list_init_measuresmanager.c manager.cfsm_list_init_measures void fsm_list_init_measures ( ) 2024-09 src/fsm/dispatch/fsm_init() Here is the call graph for this function: Here is the caller graph for this function:

fsm_rule_trig_measuremanager.c manager.cfsm_rule_trig_measure void fsm_rule_trig_measure (int rule_id, int object_id, int measure_id) 2024-09 rule_id object_id measure_id