search

vazexqi / CodingSpectator

Watches and analyzes code edits in the Eclipse IDE non-invasively
http://codingspectator.cs.illinois.edu
Other
20 stars 14 forks source link

Timestamps of the performed refactorings do not match #120

Closed Wanderer777 closed 13 years ago

Wanderer777 commented 13 years ago

CodingSpectator calculates the timestamp of a performed refactoring instead of getting it from the refactoring descriptor. As a result, the timestamp stored by CodingSpectator differs from the timestamp stored by Eclipse logger (and CodingTracker).

vazexqi commented 13 years ago

Yes that is correct. This is because we reuse the way the timestamp is populated when we collect canceled refactorings. RefactoringDescriptors are not created for canceled refactorings by default in Eclipse so we have our own mechanism.

Do you need the timestamps to be the same? And, if so, why? Are you using the timestamps for comparisons?

If this is for data analysis then we need to have some "fuzzy" matching for comparison of the similarity of our performed refactoring and Eclipse's own default captured refactorings.

For future versions, we might be able to make them the same if you require it.

Wanderer777 commented 13 years ago

No, I do not need them to be the same with the timestamps logged by Eclipse. I thought that you might consider reusing the refactoring descriptor's timestamp for the refactorings that were actually performed, if you want to make them the same with the ones stored by Eclipse.

reprogrammer commented 13 years ago

The mismatch is an important point in mind when analyzing the collected. But, there's nothing we could do about it during data collection. So, I close this issue.

reprogrammer commented 13 years ago

CodingSpectator uses the descriptors created by Eclipse to generate descriptors for performed refactorings. But, it sets the timestamp in the constructor of RefactoringDescriptor. So, the timestamps of the descriptors generated by CodingSpectator are different from those generated by Eclipse. I think we've set the timestamp in the constructor because it's a convenient place to do so. We might be able to retain the timestamp of existing descriptors to make matching CodingSpectator and CodingTracker performed refactorings more easily.

reprogrammer commented 13 years ago

It would also be nice if the timestamps of the refactorings in refactoring-problems.log match those recorded in CodingSpectator logs.

reprogrammer commented 13 years ago

@rajkuma1: I added an attribute to the problem-changes node of "refactoring-problems.log" in dc2d90248d6850f2d10fd3546edd6c9f3906dba8. This affects the parser that we writing for this log in issue #194.