Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] Stacktrace parser/detector

No problem to wait Johannes' implementation. Johannes if you need any help on that just tell.

I have access to the backlog sheet now, thanks. Should I put the two items that I suggested on the previous mail in?

Ok so, I think the preliminary things are all set! Let's continue to work. ;-)

On Sun, Jun 5, 2011 at 5:00 AM, Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx> wrote:
Hi Paulo,

On 05.06.2011, at 03:00, Paulo Sérgio Medeiros wrote:

Took a look at that, but noticed that I don't have write permission (don't know if that was on purpose).

You just received the invitation to edit the contents of the Backlog. Please add all tasks you think that should be added. However, to make planning a bit easier please change priorities in consultation with those affected by these changes.

And last, just a small correction my name is Paulo, not Paolo. :-)

Sorry for that - I promise to do better :-)

I saw backlog item related to lucene "Simple stacktrace search w/ Lucene". Isn't that part already implemented?

Yes, there is some code. But since we change some parts we will have to adopt the code. We may also redesign some parts. Let's see what happens. 

Also, you said that you are updating the data structure for representing stacktraces, what are the motivations for that?

Stacktraces are just on information of many you could leverage to find helpful resources. For instance, you may also consider class-path information, versions of the libraries used or even code snippets as extended context information for search and reporting.


Can you describe more how are using Lucene and how you use that representation to feed Lucene to create its indexes?

There are several strategies ranging from pure frame matching, to sequence matching with different weights, message similarity etc. Listing all options Johannes worked on fills a master thesis - unfortunately, this one is in German. Johannes, I should have insisted more on writing it in English :) But maybe we should wait for the first implementation to discuss the details? It's not too complex thus I would dare to postpone this discussion for some time.


Maybe you want to send me some papers that you have written or the Johannes' thesis if this is easier.

see above. Yet, there are no further publications on this. 

One last that i'm pretty sure that you are aware (but it is always worth remembering) is that Java has its own stacktrace representation http://download.oracle.com/javase/6/docs/api/java/lang/StackTraceElement.html. It was from there that I took some ideas.

Thanks. As pointed out above, we may consider extra information we can extract from within the IDE. However, this does not necessarily have to be part of the first version.


I would like to provide you more about me too:
[…]
But now with my PhD beginning and with its relation to machine learning and AI techniques in general (not sure what technique I'm going to use yet), I renovated my interest in exploring AI things and so I have stared implementing the stacktrace idea to keep myself sharped and prepare for future implementations in my phd.


Thanks for the introduction! So, stacktraces may become one topic of your PhD thesis then. Let's go :)

Best,
Marcel

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev



Back to the top