Thanks for the feedback Ed. I understand your critique with the current blame logic. Unfortunately cutting off / ignoring frames below Display.runAsync or Display.runDeferred can have the opposite effect (missing the project that scheduled the ui runnable). I remember stacktraces that contained the necessary information below these frames. I’ll have to investigate further to find out how often we will be wrong with one or the other approach.
Carsten’s feature request is different from your request. While I’m (ATM) not convinced cutting off frames from a trace wont remove necessary information (some times), I can imaging to produce reasonable results by improving the blame function as you suggested. I created bug 466576 [1] to track your request specifically. I’ll post updates to this bug. Thanks, Marcel [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=466576> > On 06 May 2015, at 14:00, Carsten Reckord <reck...@yatta.de> wrote: > > For cutting off the stack frames at Display.readAndDispatch() there's > already https://bugs.eclipse.org/bugs/show_bug.cgi?id=451359. > > On 06.05.2015 13:54, Ed Merks wrote: >> Marcel, >> >> The error reporting tool is extremely cool and very useful! >> >> One aspect that could likely be improved significantly is the computation of >> the >> "blamed" projects. In particular I'm having to triage many reports such as >> this >> one: >> >> https://dev.eclipse.org/recommenders/committers/confess/#/problems/54f9b544e4b0a38aecd742e2/details >> >> No doubt that's because Oomph is on the stack: >> >> >> >> I would like to suggest that the "blame" logic should consider that >> Display.readAndDispatch processes events of arbitrary origin. As such, >> nothing >> below that point in the stack is likely contributing to any problem above >> that >> point in the stack. >> >> Given that Oomph often starts a "background" dialog to perform tasks on >> startup, >> every possible problem that happens elsewhere in the IDE ends up in Oomph's >> triage bucket, so the list I must triage is large to the point where I'm >> not >> sure it can ever be managed: >> >> https://dev.eclipse.org/recommenders/committers/confess/#/problems/?projects=oomph&kinds=NORMAL&kinds=FREEZE&categories=UNCONFIRMED&page=1&size=100&sort=createdOn,desc >> >> The duplicates are a bit annoying too, but you have some nice support for >> that >> already: >> >> https://dev.eclipse.org/recommenders/committers/confess/#/problems/5522970ce4b026254ee014bf/similar >> >> Kudos for creating this great technology! >> >> Cheers, >> Ed >> >> >> >> >> >> >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-179-131-7721 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
