MantisBT - ParaView |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0015239 | ParaView | (No Category) | public | 2015-01-05 16:19 | 2015-09-06 12:18 |
|
| Reporter | Ken Moreland | |
| Assigned To | Dan Lipsa | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | | |
| Target Version | 4.4 | Fixed in Version | 4.4 | |
| Project | Sandia |
| Topic Name | |
| Type | feature |
|
| Summary | 0015239: Output window should suppress duplicate errors and warnings |
| Description | It is not uncommon in ParaView for a filter to give the same warning or error many times for what is essentially the same problem. For example, if an error is given in the middle of a loop over points or cells, it can occur many times unless the programmer is careful about counting errors. Even if a filter behaves exactly as it is supposed to, the ProcessRequest method may be called many times when executing over a composite data set, each likely to give the same error.
All errors and warnings go through a singleton class that manages the output window reporting these errors. This is a good place to identify duplicate messages and combine them to a single output. The preferred behavior would be to first check the warning/error text against previous outputs. If a duplicate is found, that message should be moved to the bottom rather than duplicated on the bottom. A count of how many times each error/warning happened should be displayed. |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | duplicate of | 0015238 | closed | Alan Scott | Output window and other error prints | | related to | 0015240 | closed | Dan Lipsa | Hide some diagnostic information in output window |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2015-01-05 16:19 | Ken Moreland | New Issue | |
| 2015-01-05 16:33 | Alan Scott | Relationship added | duplicate of 0015238 |
| 2015-01-05 16:37 | Ken Moreland | Relationship added | related to 0015240 |
| 2015-01-05 17:21 | Alan Scott | Note Added: 0034017 | |
| 2015-01-05 17:21 | Alan Scott | Target Version | => 4.4 |
| 2015-01-07 14:40 | Dan Lipsa | Assigned To | => Dan Lipsa |
| 2015-01-07 14:40 | Dan Lipsa | Status | backlog => active development |
| 2015-01-29 09:30 | Dan Lipsa | Note Added: 0034130 | |
| 2015-01-29 09:30 | Dan Lipsa | Status | active development => gatekeeper review |
| 2015-02-03 08:20 | Utkarsh Ayachit | Fixed in Version | => git-master |
| 2015-02-03 08:20 | Utkarsh Ayachit | Status | gatekeeper review => customer review |
| 2015-02-03 08:20 | Utkarsh Ayachit | Note Added: 0034140 | |
| 2015-02-03 11:35 | Ken Moreland | Note Added: 0034142 | |
| 2015-02-03 13:00 | Dan Lipsa | Note Added: 0034143 | |
| 2015-02-03 13:03 | Dan Lipsa | Note Edited: 0034143 | bug_revision_view_page.php?bugnote_id=34143#r1018 |
| 2015-02-03 13:24 | Ken Moreland | Note Added: 0034144 | |
| 2015-02-18 15:42 | Alan Scott | Note Added: 0034235 | |
| 2015-02-18 15:42 | Alan Scott | Status | customer review => closed |
| 2015-02-18 15:42 | Alan Scott | Resolution | open => fixed |
| 2015-09-06 12:18 | Utkarsh Ayachit | Fixed in Version | git-master => 4.4 |
|
Notes |
|
|
(0034017)
|
|
Alan Scott
|
|
2015-01-05 17:21
|
|
|
Targeting 4.4, since we see versions of this issue all of the time. |
|
|
|
(0034130)
|
|
Dan Lipsa
|
|
2015-01-29 09:30
|
|
ParaView commits
================
commit b8d9b754cc264510f446a08daed5bfea45226c11
Author: Dan Lipsa <dan.lipsa@kitware.com>
Date: Mon Jan 26 11:23:57 2015 -0500
Fix compilation warnings.
Change-Id: I60ddd54c42ba988d928dd18285128bb24bd04990
commit 06373bf04dcc96e2af6dd55c9cb8a185d0ebd102
Author: Dan Lipsa <dan.lipsa@kitware.com>
Date: Mon Jan 26 10:03:25 2015 -0500
Move VTK: 'Accumulate strings printed to console by Python'
Change-Id: I6747066920bf866b6f2d655d13a0edaf8c3ab303
commit 0305931430d8fe6dbb7f322c01d809ab8d07ba45
Author: Dan Lipsa <dan.lipsa@kitware.com>
Date: Thu Jan 22 15:18:00 2015 -0500
ENH: Parse, colate and filter output messages.
Change-Id: I375ab6860ab8809370d3bc6f533756353eea1531
VTK commits
===========
commit 57c9fa4a78a9431d947c471f812c51f54cee63b1
Author: Dan Lipsa <dan.lipsa@kitware.com>
Date: Mon Jan 26 13:02:57 2015 -0500
Fix style problems.
Change-Id: I0c9d80c1bf1a30ba3814a997f49c29b18485073d
commit cfc422eb1a0b4c3d2079d08fa42699677475b83d
Author: Dan Lipsa <dan.lipsa@kitware.com>
Date: Thu Jan 22 15:22:37 2015 -0500
Accumulate strings printed to console by Python and send them in one piece.
For RunSimpleString output to console is accumulated, for PyMain it is
sent directly
Change-Id: I3345bcc393c3515089c1c56ce1d908ed5b681e53 |
|
|
|
(0034140)
|
|
Utkarsh Ayachit
|
|
2015-02-03 08:20
|
|
SUMMARY
---------------------------------------------
Topics merged into master (v4.3.1-119-g6d9aca5):
(VTK) 15284_refactor_paraview_interactors
15298_fix_exporters_in_python
(VTK) icet-opengl2-fix
minor-fixes
new-baselines-20150202
push_specA_cinema
(VTK) pvweb-support-http-rpc-servers
safer-unified-bindings-arg
vtkmpi-inclusion-fun
fix_pgi_issues |
|
|
|
(0034142)
|
|
Ken Moreland
|
|
2015-02-03 11:35
|
|
This behavior is way better. Two comments though. I'm not sure if they should be part of this issue or new ones should be open:
1. The count on my build (Mac OS) disappears when the count reaches the double digits (10 or more). Apparently the text runs out of room and gets hidden. The count should work at least until the triple digits.
2. The text of the error should be updated to the text of the last error reported. For example, make some source (doesn't matter what), add an array calculator, set the expression as "syntax error" and apply. You'll get a pair of errors, one telling you the position of the syntax error is at position 0 (all great so far). Now change the expression to be "1+syntax error" and apply again. The last error was at position 2, but the text still reports position 0. As errors get repeated, the last one is probably the most relevant, so it would be good to update the text to that of the last error. |
|
|
|
(0034143)
|
|
Dan Lipsa
|
2015-02-03 13:00
(edited on: 2015-02-03 13:03) |
|
Hi Ken,
Thanks for the bug report.
For 2, when looking for similar errors, I can match on the location of the message (this is the behavior in the repository). This means that the user will see only the last message - this might be problematic if there are several Calculator filters and some of them report errors. However, it presents a cleaner view.
The report will be:
E 4 Syntax error: ... see position 3
W 2 An error occurred ...
or
I can match on both the location and the message. This will show every message but might potentially reorder messages.
The report will be:
E 2 Syntax error: ... see position 0
W 2 An error occurred ...
E 2 Syntax error: ... see position 3
Do you have any thoughts on this?
|
|
|
|
(0034144)
|
|
Ken Moreland
|
|
2015-02-03 13:24
|
|
I'm not sure. My inclination is for the first solution.
Another approach would be to change when things are grouped together. In a previous conversation, we had talked about grouping errors that happen in between applies (or perhaps some other event). That way if the user changed the calculator expression and tried to apply again (like someone trying to debug the statement would), a new single error would show up each time updated to the new message. It would also make the order a bit more clear if multiple errors get reported during a ParaView session and the user does not clear out the message log. |
|
|
|
(0034235)
|
|
Alan Scott
|
|
2015-02-18 15:42
|
|
Very nice.
Tested Linux, master, remote server. |
|