This commits reworks the way that memory is allocated for the logging system.
We basically use a double-linked list, with the oldest and the latest elements
stored in a static variable. Most recent log entries are added at the latest
position in this structure.
A new function to clear and free a log unit has been implemented, and can be used
at many points. We take care that each log unit is freed at closing time.
Also, fsm docs have been a bit clarified.
Tested with valgrind:
==6161== LEAK SUMMARY:
==6161== definitely lost: 5,008 bytes in 54 blocks
==6161== indirectly lost: 16,119 bytes in 672 blocks
We can consider that as a basis for future work, as these leaks are due to external
causes (e.g. libraries).
Signed-off-by: Jean Sirmai <jean@a-lec.org>
Signed-off-by: Adrien Bourmault <neox@a-lec.org>
definitely lost: 5,008 bytes in 54 blocks
indirectly lost: 16,151 bytes in 673 blocks
When g_message() is removed from oper.c fsm_publish_log() no leak seems
caused by the gem-graph code.
We create a window in the app activation and it needs to be closed properly,
freeing all ressources in the meantime. For now, there is only the picture
(E. coli) to free.
From now on, freeing window ressources will be done in
src/widget/manager.c:on_window_close_request().
Signed-off-by: Jean Sirmai <jean@a-lec.org>
The bug was caused by pointers to local variables sended to fsm_add_log().
malloc() are now realized in fsm_add_log_event().
+ cleaning (checking that the sentence "This file is part of Gem-graph."
is systematicaly added to legal mentions.)
To display this minimal window, three files and two functions must be
added simultaneously:
- include/widget/h
- src/manager.c
- src/main_window/design.c
main() now contains: g_signal_connect (on_windows_activation);
on_windows_activation () is in src/manager.c and calls
widget_main_window () which is in src/main_window/design.c
NB The iconic image of E coli drawn by David S. Goodsell in 2009
is reproduced here with permission.
One goal of Gem-graph is to animate such static representations
i.e. use the best anatomy to try to achieve good physiology.
* - in fsm_trigger_log_init(), fsm_trigger_log_close() the word **trigger** is
* replaced by **relay**
* - fsm_log_struct_unit is replaced by: fsm_log_unit_struct
*
* docs/rtfm/intro (previously 'Once upon a time'... 🙃️) is also renamed and
* extended.
*
The same text is presented in two formats: for an external text editor (.txt)
or with lines limited to 80 characters.
The links are prepared but not functionnal.
These two functions (defined in control.c) initiate the log and print it just
before the end of the program.
It is now possible to send messages that reports the events occuring during a
session: the creation of the log, then of the application and their closure in
the reverse order.
As previously,there is no g signal connect (activate) and no window is created.
This triggers the same error message in the console.
What is new, in this commit, is that a first log is printed in the console.
- manager.c,
- oper.c and
- appendix.c
and the functions needed to init, edit and publish the log.
fsm_add_log() is in manager.c There are the filters.
init(), add(), publish() are in oper.c
These are the executive functions.
and functions whose usefulness remains to be demonstrated
are in appendix.
In fsm.h remain the structures (fsm_log_struct, fsm_log_struct_unit)
and the two enums (severity and source)
This commit is the first in a series that will make the fsm apt to build the
log.
The log (or journal) records events chronologically from the start to the end
of the programme.
Its quantitatively most important part is to report on the execution of the
session.
The log will be created from the fsm (finite state machine) which describes
all the possible states of the Gem-graph client and all the transitions between
them.
The fsm header is introduced in this commit.
It lists the structures, functions and tools that the log will need and details
the presentation of events in the log
[date - rank - source file - source function - value].
The src/readme.docs file provides an initial overview of the missions and their
distribution in the code files.
We wanted to have an automated documentation for our project. We choose doxygen
since this is a well-established project, with common standards.
To generate the documentation, simply type `make docs` and open `docs/html/index.html`.
The documentation zone actually contains:
- archives: several files from past of the projects, historical purpose
- GTK-docs: ressources on GTK internals and API
- rtfm: first draft of a user manual
- showcase: some pictures of the UI example, that were communicated on the Gem-graph discussion room (XMPP)
- html: doxygen-generated docs
Jean Sirmai
