MantisBT - ParaView
View Issue Details
0015239ParaView(No Category)public2015-01-05 16:192015-09-06 12:18
Ken Moreland 
Dan Lipsa 
normalminorhave not tried
closedfixed 
 
4.44.4 
Sandia
feature
0015239: Output window should suppress duplicate errors and warnings
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.
No tags attached.
duplicate of 0015238closed Alan Scott Output window and other error prints 
related to 0015240closed Dan Lipsa Hide some diagnostic information in output window 
Issue History
2015-01-05 16:19Ken MorelandNew Issue
2015-01-05 16:33Alan ScottRelationship addedduplicate of 0015238
2015-01-05 16:37Ken MorelandRelationship addedrelated to 0015240
2015-01-05 17:21Alan ScottNote Added: 0034017
2015-01-05 17:21Alan ScottTarget Version => 4.4
2015-01-07 14:40Dan LipsaAssigned To => Dan Lipsa
2015-01-07 14:40Dan LipsaStatusbacklog => active development
2015-01-29 09:30Dan LipsaNote Added: 0034130
2015-01-29 09:30Dan LipsaStatusactive development => gatekeeper review
2015-02-03 08:20Utkarsh AyachitFixed in Version => git-master
2015-02-03 08:20Utkarsh AyachitStatusgatekeeper review => customer review
2015-02-03 08:20Utkarsh AyachitNote Added: 0034140
2015-02-03 11:35Ken MorelandNote Added: 0034142
2015-02-03 13:00Dan LipsaNote Added: 0034143
2015-02-03 13:03Dan LipsaNote Edited: 0034143bug_revision_view_page.php?bugnote_id=34143#r1018
2015-02-03 13:24Ken MorelandNote Added: 0034144
2015-02-18 15:42Alan ScottNote Added: 0034235
2015-02-18 15:42Alan ScottStatuscustomer review => closed
2015-02-18 15:42Alan ScottResolutionopen => fixed
2015-09-06 12:18Utkarsh AyachitFixed in Versiongit-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.