Skip to content

Follow-up refactoring of logging-related parts #1249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

akosthekiss
Copy link
Member

This patch:

  • Ensures that all calls to jerry_port_log in jerry-core happen
    via macros defined in jrt.h. Also, it unifies the names of those
    macros: as JERRY_ERROR_MSG and JERRY_WARNING_MSG gave a good
    pattern that was well aligned with the naming scheme of the log
    level enum, JERRY_DLOG and JERRY_DDLOG were rewritten to
    JERRY_DEBUG_MSG and JERRY_TRACE_MSG.
  • Ensures that all debug logging code parts of jerry-core (i.e.,
    memory statistics, JS byte-code dumps, and RegExp byte-code
    dumps) are guarded by macros: JMEM_STATS,
    PARSER_DUMP_BYTE_CODE, and REGEXP_DUMP_BYTE_CODE, which in
    turn are controled by cmake build system feature flags
    FEATURE_MEM_STATS, FEATURE_PARSER_DUMP, and
    FEATURE_REGEXP_DUMP.
  • Ensures that all debug logging functionalities can be controled
    during run time (provided that they were enabled during build
    time): the engine has JERRY_INIT_MEM_STATS[_SEPARATE],
    JERRY_INIT_SHOW_OPCODES, JERRY_INIT_SHOW_REGEXP_OPCODES init
    flags, and the default unix/linux command line app has
    corresponding command line switches.`
  • Drops FEATURE_LOG, JERRY_ENABLE_LOG, and
    JERRY_INIT_ENABLE_LOG, as their name was misleadingly general,
    even though they mostly controled the regexp engine only. The
    above-mentioned *REGEXP* things mostly act as their
    replacements.
  • Updates build and test tool scripts and documentation.

JerryScript-DCO-1.0-Signed-off-by: Akos Kiss akiss@inf.u-szeged.hu

@akosthekiss
Copy link
Member Author

follow up as discussed in #1205

@zherczeg
Copy link
Member

zherczeg commented Aug 8, 2016

Pretty big patch. Shall we wait after the release?

@akosthekiss
Copy link
Member Author

We shouldn't. The FEATURE_LOG, JERRY_ENABLE_LOG, JERRY_INIT_ENABLE_LOG things are quite misleading. We shouldn't leave them in 1.0.

flags &= (jerry_init_flag_t) ~JERRY_INIT_SHOW_REGEXP_OPCODES;

JERRY_WARNING_MSG ("Ignoring JERRY_INIT_SHOW_REGEXP_OPCODES flag "
"because of !REGEXP_DUMP_BYTE_CODE configuration.\n");
Copy link
Member

Choose a reason for hiding this comment

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

Why two lines? Only one line above.

Copy link
Member Author

Choose a reason for hiding this comment

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

Written in one line would exceed the 120 chars/line limit.

@zherczeg
Copy link
Member

zherczeg commented Aug 8, 2016

I don't see much risk here. The patch is mostly just renaming. The API change is minor, and happens before the release.

LGTM

@akosthekiss
Copy link
Member Author

updated to master and resolved conflicts

else if (!strcmp ("--show-regexp-opcodes", argv[i]))
{
flags |= JERRY_INIT_SHOW_REGEXP_OPCODES;
jerry_port_default_set_log_level (JERRY_LOG_LEVEL_DEBUG);
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't it be JERRY_LOG_LEVEL_TRACE ?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's true that the regexp engine can log trace level messages but they are mostly "extras" and most of the "important" logs go as debug level. Thus, I wanted to keep the log level implied by "--show-regexp-opcodes" at debug level only as that seamed like a sensible default and aligns with the default implied by other command line switches. Still, should someone want to see the "extras", "--show-regexp-opcodes --log-level 3" is there to use.

@akosthekiss akosthekiss added enhancement An improvement ecma core Related to core ECMA functionality jerry-port Related to the port API or the default port implementation and removed ecma core Related to core ECMA functionality labels Aug 10, 2016
@LaszloLango
Copy link
Contributor

LGTM

This patch:
* Ensures that all calls to `jerry_port_log` in jerry-core happen
  via macros defined in jrt.h. Also, it unifies the names of those
  macros: as `JERRY_ERROR_MSG` and `JERRY_WARNING_MSG` gave a good
  pattern that was well aligned with the naming scheme of the log
  level enum, `JERRY_DLOG` and `JERRY_DDLOG` were rewritten to
  `JERRY_DEBUG_MSG` and `JERRY_TRACE_MSG`.
* Ensures that all debug logging code parts of jerry-core (i.e.,
  memory statistics, JS byte-code dumps, and RegExp byte-code
  dumps) are guarded by macros: `JMEM_STATS`,
  `PARSER_DUMP_BYTE_CODE`, and `REGEXP_DUMP_BYTE_CODE`, which in
  turn are controled by cmake build system feature flags
  `FEATURE_MEM_STATS`, `FEATURE_PARSER_DUMP`, and
  `FEATURE_REGEXP_DUMP`.
* Ensures that all debug logging functionalities can be controled
  during run time (provided that they were enabled during build
  time): the engine has `JERRY_INIT_MEM_STATS[_SEPARATE]`,
  `JERRY_INIT_SHOW_OPCODES`, `JERRY_INIT_SHOW_REGEXP_OPCODES` init
  flags, and the default unix/linux command line app has
  corresponding command line switches.`
* Drops `FEATURE_LOG`, `JERRY_ENABLE_LOG`, and
  `JERRY_INIT_ENABLE_LOG`, as their name was misleadingly general,
  even though they mostly controled the regexp engine only. The
  above-mentioned `*REGEXP*` things mostly act as their
  replacements.
* Updates build, test, and measurement tool scripts, and
  documentation.

JerryScript-DCO-1.0-Signed-off-by: Akos Kiss akiss@inf.u-szeged.hu
@akosthekiss akosthekiss merged commit a2d5acb into jerryscript-project:master Aug 11, 2016
@akosthekiss akosthekiss deleted the logging-followup branch August 11, 2016 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An improvement jerry-port Related to the port API or the default port implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants