Opened 16 years ago
Last modified 8 years ago
#312 new defect
wxNVIZ prints debug to terminal
Reported by: | msieczka | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 6.4.6 |
Component: | wxGUI | Version: | svn-releasebranch64 |
Keywords: | digitizer | Cc: | |
CPU: | All | Platform: | All |
Description
E.g. at raster load time it pollutes the terminal with:
Loading raster map <erode.index@PERMANENT>... Loading raster map <erode.index@PERMANENT>... Translating colors from raster map <erode.index@PERMANENT>... 99%
Change History (6)
comment:1 by , 12 years ago
Keywords: | digitizer added |
---|---|
Milestone: | 6.4.0 → 6.4.3 |
Version: | svn-develbranch6 → svn-releasebranch64 |
follow-up: 3 comment:2 by , 9 years ago
Still an issue.
Does anyone know how to intercept GRASS_INFO_MESSAGE() etc to avoid that it gets printed to the terminal?
follow-up: 4 comment:3 by , 9 years ago
Replying to neteler:
Does anyone know how to intercept GRASS_INFO_MESSAGE() etc to avoid that it gets printed to the terminal?
export GRASS_MESSAGE_FORMAT=silent
Alternatively, identify the G_message() calls and change them to G_verbose_message() so that they don't get printed without --verbose.
follow-up: 5 comment:4 by , 9 years ago
Replying to glynn:
Replying to neteler:
Does anyone know how to intercept GRASS_INFO_MESSAGE() etc to avoid that it gets printed to the terminal?
export GRASS_MESSAGE_FORMAT=silent
Alternatively, identify the G_message() calls and change them to G_verbose_message() so that they don't get printed without --verbose.
I don't understand the issue very well. Does this mean that we need to change all G_message()
calls in the library if there is a chance that the part will be used directly by some GUI application (vdigit, nviz, iclass)?
comment:5 by , 9 years ago
Replying to wenzeslaus:
Alternatively, identify the G_message() calls and change them to G_verbose_message() so that they don't get printed without --verbose.
I don't understand the issue very well. Does this mean that we need to change all
G_message()
calls in the library if there is a chance that the part will be used directly by some GUI application (vdigit, nviz, iclass)?
First, should GUI programs be different to non-GUI programs in this regard?
The issue is that library functions are generating messages, meaning that any program which uses those functions will generate messages. It's debatable whether library functions have enough context to decide which messages are appropriate.
Vlib is particularly noisy in this regard. I count 113 calls to G_message() in lib/*/*.c (excluding test suites). 59 of those (more than half) are in Vlib.
The other issue seems to be that GUI-format messages are being written to the terminal, which suggests an issue in the way that the program is started (i.e. something is executing it with GRASS_MESSAGE_FORMAT=gui but not capturing its output; the point of GRASS_MESSAGE_FORMAT=gui is to use a machine-readable format so that a GUI can process the messages).
comment:6 by , 8 years ago
Milestone: | 6.4.3 → 6.4.6 |
---|
This is still an issue for the wxdigitizer (not debug but suer messages):