Enhance DOI model manipulation

[yiming-tang-cs]

Based on #66, there is no implicit propagation of the file DOI values to the constituent elements like method declarations, so we need to extract enclosing methods changes and bump the DOI values.

┆Issue is synchronized with this Asana task

[yiming-tang-cs]

I think the block context, method context and file context are also related to the log level. Can we get something from context to modify the DOI?

[yiming-tang-cs]

And the static text in the log expression is also related to the logging level. Can we use static text to modify DOI?

[khatchad]

I think we have some ideas for this in #40.

[khatchad]

See #41 (comment) for discussion on this issue. Is it the problem that we are using only the enclosing method? I think that the DOI values trickle down from higher level containers but I don't think there's anything at the statement level.

Raffi thinks that for levels such as INFO, FINE, FINER, and FINEST, there will be more of a correlation than with WARNING and CRITICAL, etc. We need to find out, and maybe #57 will help us correlate DOI to logging levels.

[yiming-tang-cs]

The figure 2 of this paper https://dl.acm.org/citation.cfm?id=3128785.3128834 is a figure logging distribution.

We may build a correlation based on those logging distribution. We could give a higher weight to the logging level which is high in the disctribution figure. However, if we decide to use this, this figure is not enough(some logging level is missing and the number of projects are not enough) and we shoud analyze more projects.

[yiming-tang-cs]

This paper also mentions that

We find that the characteristics of the containing block of a newly-added logging
statement, the existing logging statements in the containing file, and the content
of the newly-added logging statement play important roles in determining the
appropriate log level for that particular logging statement.

I think we need to add DOI for blocks. I am unsure about whether we need the containing file because some of papers does not use this to investigate log, such as http://www.robo-paathshaala.in/ashish/CHAPTER-SAMPLE-PDF.pdf. We may also need to process the content of log. Currently, regular expression may be fine.

[khatchad]

This is like augmenting the Mylyn DOI model with git history.

[khatchad]

I think you want to create a richer history of "events" because more recent events make methods that were edited more recently more interesting in the DOI model and vice-versa.

[khatchad]

Besides #66, a possible starting point would be to read the git history of the project (assuming it is a git project) to read commits using EGit.

[khatchad]

These could be useful:

• https://www.eclipse.org/forums/index.php/t/699154/
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=433030
• https://www.eclipse.org/community/eclipse_newsletter/2013/september/article4.php

[khatchad]

You may need to make a new plug-in (which can be in the same GitHub repo or not) that is a relation provider or something like https://github.com/ponder-lab/fraglight/blob/c7b4dd40112cffdeec5bb54aaba2778bfe29d0be/edu.ohio_state.cse.khatchad.fraglight.ui/plugin.xml#L4-L10.

[khatchad]

➤ Raffi Khatchadourian commented:

Yiming Tang It would seem to me that Discover if any implicit DOI changes occur as a result of file DOI manipulation isn't going to work out. So, you'll need to get more fined grained info out of the commit history.

[khatchad]

➤ Raffi Khatchadourian commented:

In other words, you'll need to find the enclosing methods within the change set yourself. There may be existing work to do this or perhaps a simple regex may do the trick.

[khatchad]

➤ Raffi Khatchadourian commented:

Once you have the enclosing method, you'll need to bump the DOI value of the method similar to what is done with fraglight.

[khatchad]

➤ Raffi Khatchadourian commented:

We should also check that when you are bumping the DOI value of a particular method, the DOI values of elements are decreasing in some way.

[khatchad]

➤ Raffi Khatchadourian commented:

We may also want to think about how much to "bump" the DOI of a particular method. In other words, if there are many changes to a particular method, should that method have a higher DOI (i.e., should we bump it multiple times)?

[yiming-tang-cs]

In other words, you'll need to find the enclosing methods within the change set yourself. There may be existing work to do this or perhaps a simple regex may do the trick.

Yeah, I saw some existing work. I will check them.

[khatchad]

The first step is to extract the enclosing method of the change in the commit. In other words, which methods changed in the commit. Then we need to decide how to bump the DOI of those methods (e.g., should larger changes in a single method yield larger DOI values?).

[khatchad]

This is where the AST differencing happens in fraglight:

https://github.com/ponder-lab/fraglight/blob/c7b4dd40112cffdeec5bb54aaba2778bfe29d0be/edu.ohio_state.cse.khatchad.fraglight.ui/src/edu/ohio_state/cse/khatchad/fraglight/ui/PointcutChangePredictionProvider.java#L625-L642

https://github.com/ponder-lab/fraglight/blob/c7b4dd40112cffdeec5bb54aaba2778bfe29d0be/edu.ohio_state.cse.khatchad.fraglight.core/src/edu/ohio_state/cse/khatchad/fraglight/core/analysis/JoinPointShadowDifferenceAnalyzer.java#L22

[khatchad]

[yiming-tang-cs]

Currently, we are evaluating large projects by mylyngit plugin. While evaluating, we are fixing several bugs we found.

[khatchad]

@saledouble Are we done here?

[yiming-tang-cs]

Are we done here?

Yes.