| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| 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 | ||||||
| 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Project | Sandia | ||||||||
| Topic Name | |||||||||
| Type | feature | ||||||||
| Attached Files | |||||||||
| Relationships | |||||||||||
|
|||||||||||
| Relationships |
| Notes | |
|
(0034017) Alan Scott (manager) 2015-01-05 17:21 |
Targeting 4.4, since we see versions of this issue all of the time. |
|
(0034130) Dan Lipsa (developer) 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 (administrator) 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 (manager) 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 (developer) 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 (manager) 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 (manager) 2015-02-18 15:42 |
Very nice. Tested Linux, master, remote server. |
| Notes |
| 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 | |
| 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 |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |