Skip to content

Conversation

@ctmbl
Copy link
Contributor

@ctmbl ctmbl commented Feb 6, 2024

Motivations

A good logging tool/system is very useful to both the programmer and the user

ESTER already had the shape of one but two macros was co-existing ester_* and LOG*
Also in several places of the code base fprintf(stderr, ...) was used, bypassing the logging tools, probably because the programmer didn't know of its existence.

Problems and ambiguous situations

ester_err was used, but often the next line was exit(1) while exit(EXIT_FAILURE) was already included in the macro making it useless and showing the lack of knowledge around the macro.
But more importantly this misusage of the macro raised doubts about the cases where ester_err was used but the function continued afterwards, code that will not be executed because ester_err embed an exit call, I noticed such ambiguous use in these files:

  • atm_onelayer.cpp
  • physics.cpp

These cases were more difficult to dealt with when replacing old calls with new one because even if it was useless we knew that ESTER run well as it is:

  • should I replace them with new ester_err which doesn't exit but risk the appearance of new bugs?
  • or should I ignore this issue and replace them with new ester_critical keeping the same behavior as before

New macros proposal

ester_debug:

  • print to stderr in DEBUG
  • none else

ester_info:

  • prefixed with green "Info"
  • print to stdout in both modes

ester_warn:

  • prefixed with yellow "Warning:"
  • print to stderr
    + indicate line and file in DEBUG

ester_err:

  • same as ester_warn with red "Error:"
    + print stack in DEBUG

ester_critical:

  • same as ester_err with red "CRITICAL:"
    + exit program or throw exception

Examples of how it looks (without the color):

$ ester 1d -i toto
CRITICAL: The input file toto is not HDF5 format.

$ ester 2d -M 10 -i star.h5
Warning: call to matplotlib.pyplot.clf failed
Warning: matplotlib.pyplot.pause failed

Changes to the code

  • No LOGI nor LOGW were used
  • obvious ester_err (the ones that obviously want to exit directly) have been replaced by ester_critical keeping the same behavior
  • a comment has been added, exactly: // Useless because ester_critical already exit on useless exit() calls or return that won't ever be reached
  • in other ambiguous places: solver.cpp, atm_onelayer.cpp, physics.cpp, polytrope.cpp, eos_freeeos.cpp, eos_opal.cpp I chose to replace by ester_critical keeping the same behavior as before but each of these case could be debated to let the function return and above function read an error code and exit themselves
  • in star2d::init the choice has been made to let the function return 1 and let the program exit via ester_critical in star2d.cpp:main --> see Future changes
  • in star1d::init few changes were made contrary to star2d::init hence the need of a future homogenization
  • in some other places a bit of refactoring: solver.cpp, ...

Roadmap

Logging refactor/update:

  • Update logging macros `ester_*
  • Standardize logging format: <log level>: (<optional function/method>) <msg> with color on the log level part
  • Replace old ester_err by ester_err or ester_critical given the case and format each log
  • Replace old LOGE by ester_err and format
  • Test everything
  • Replace fprintf(stderr, ... by ester_err or ester_critical: stat_evol.cpp, mat_math.cpp, matrix_block_diag.cpp, matrix.cpp, RFK_solver.cpp, SDIRK_solver.cpp, solver_full.cpp, solver.cpp, star_map.cpp, star1d_class.cpp
  • Replace other printf/fprintf if possible
  • Test everything
  • Remove the useless returns and exits after ester_critical that I tagged // Useless because ester_critical already exit
  • In some places use ester_err instead of ester_critical and let higher methods/functions exit with ester_critical providing more global information to the user

Future changes

These things were not addressed by this PR but could be by future one in particular #18

  • In star1d::init, star2d::init, read_config.cpp, parser.cpp, star1d.cpp, star2d.cpp:
    • Use new logging macros
    • Homogenize and comment parsing and configuration
    • Improve logic: let appropriate function return and higher level ones, as main, exit with ester_critical
  • All printf("error ...") should be replaced as fprintf(stderr, ..) had been but this could be more difficult (to check each printf call), this could be done smoothly not necessarily in one time
  • MORE IMPORTANTLY: get into the habit of using these macros
  • Future errors, warnings and info should use ester_* macros and not raw printf/fprintf functions

Conclusion

Even if this PR won't go into ESTER code base (even if I think it should in one form or another) it allowed me to dig deeper in the ESTER code base and ready to work on other improvements.

If you agree I'd like you to carefully review this PR, commit by commit, I took care to title them clearly.

Also I'm working on more, and more interesting!, than just that but I'd like to build upon this one if possible.

PS: in my opinion this work will be useless if future development keep the same habit of using custom macros/functions or fprintf instead of using ESTER designed macros ester_* introduced here, it's a change of developing habits which is required.
In general ESTER development should aim more consistency throughout the code base and this PR is trying to go in this direction!

Copy link
Member

@rieutord rieutord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some thing to explain

@ctmbl
Copy link
Contributor Author

ctmbl commented Feb 6, 2024

I'd still want to deal with these two things before merging:

  • Remove the useless returns and exits after ester_critical that I tagged // Useless because ester_critical already exit
  • In some places use ester_err instead of ester_critical and let higher methods/functions exit with ester_critical providing more global information to the user

So don't hesitate to give your opinion on any choice I made or thing I said, we can only profit from different perspectives especially because I don't know ESTER very well

PS: You can quote someone on GitHub with this syntax:

> something I said

it'll look like that:

something I said

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants