Status: New
Owner: ---- CC: [hidden email], [hidden email], [hidden email] Labels: Type-Defect Priority-Critical Component-VerveineJ New issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 For some reason, some methods are placed in the wrong classes. I did not manage to identify a standalone case, but it looks like if we have a case like below: public class A { ... public void m() { ... x() } } public class B { public void x() { ... } } public class C { ... } we sometimes get x as belonging to class C instead of B. The interesting part is that the invocation will go from A::m() to C::x(). This is a critical issue that stops us from using VerveineJ because the information is too unreliable. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Status: WontFix Comment #1 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 nothing we can do here until we have a concrete case to investigate. Close it until it can be reproduced. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Comment #2 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 In two weeks I will have 13 students using Moose. It would be good to have this issue sorted out. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
I would really love to solve this problem. Like any other one for which you can provide me something to work on. I don't need to explain to you how difficult it is to solve a bug that occur from time to time whitout any concrete example that produce the error ... nicolas ----- Mail original ----- > De: [hidden email] > À: [hidden email] > Envoyé: Mercredi 19 Octobre 2011 14:09:31 > Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the wrong classes > Comment #2 on issue 728 by [hidden email]: VerveineJ places > methods > in the wrong classes > http://code.google.com/p/moose-technology/issues/detail?id=728 > > In two weeks I will have 13 students using Moose. It would be good to > have > this issue sorted out. > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by moose-technology
Comment #3 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 I will certainly not close it :). I reproduced it several times on proprietary case studies. I will try to create a simpler case, but maybe in the meantime others have experienced something similar. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
I did not close it because I think it is irrelevant, but because without more information it is close to useless. As I said I would be more than happy to solve it. As for the example, I don't even ask for a simple one (although the simpler is definitely the better), I just need one example. Anyway, you know how it is ... nicolas ----- Mail original ----- > De: [hidden email] > À: [hidden email] > Envoyé: Mercredi 19 Octobre 2011 14:25:40 > Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the wrong classes > Comment #3 on issue 728 by [hidden email]: VerveineJ places > methods > in the wrong classes > http://code.google.com/p/moose-technology/issues/detail?id=728 > > I will certainly not close it :). I reproduced it several times on > proprietary case studies. I will try to create a simpler case, but > maybe in > the meantime others have experienced something similar. > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by moose-technology
can't you rename all things
C1, C2, C3, ... m1, m2, m3, ... v1, v2, v3, ... and remove everything that appears to be unrelated (arithmetic expressions, I/O, conditions and loops) obfuscate it ... I understand that this can represent some amount of work. But I need something to work on. nicolas ----- Mail original ----- > De: [hidden email] > À: [hidden email] > Envoyé: Mercredi 19 Octobre 2011 14:25:40 > Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the wrong classes > Comment #3 on issue 728 by [hidden email]: VerveineJ places > methods > in the wrong classes > http://code.google.com/p/moose-technology/issues/detail?id=728 > > I will certainly not close it :). I reproduced it several times on > proprietary case studies. I will try to create a simpler case, but > maybe in > the meantime others have experienced something similar. > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
I am looking into it right now. Actually, I think the issue is related to a larger context that I do not see clearly at this moment.
Doru On Wed, Oct 19, 2011 at 2:41 PM, Nicolas Anquetil <[hidden email]> wrote: can't you rename all things -- "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by moose-technology
Updates:
Status: Fixed Cc: -[hidden email] -[hidden email] -[hidden email] Comment #4 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 (No comment was entered for this change.) _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Tudor Girba-2
I am happy to announce that thanks to the very valuable help of Doru, the bug has been clearly identified and subsequently removed. nicolas De: "Tudor Girba" <[hidden email]> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
So what was the nature of the problem?
On Fri, Oct 21, 2011 at 11:39 PM, Nicolas Anquetil <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Nicolas Anquetil
Yeah! U rock guys!
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by moose-technology
Updates:
Status: Started Owner: [hidden email] Comment #5 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 Great job. However, we still have another case of misplaced methods that is still present. It is different than the one I sent you in that it seems to only involve super calls (while the other one was related to calls to a different class). Essentially, something like: public class A extends SomeClass { ... public void x() { super.m() } } leads to m() being placed in an unrelated class B. I suspect it is the same issue as the one you fixed only present in a different place. I am not sure if my description is clear enough. I will try again to reproduce on a smaller case study. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Status: Fixed Comment #6 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 I believe this second case is solved too. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Updates:
Status: Started Comment #7 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 Hmm, I just tried. First, I fixed the shell script (verveinej.sh) to collect the jars automatically from the lib folder. Then I removed the obsolete jars. But, still, if I run the following experiment, I get 575 potentially problematic methods: - download ArgoUML 0.32 from: http://argouml-downloads.tigris.org/argouml-0.32/ - parse, load in Moose, and then execute: (MooseModel root allModels first allMethods select: [:each | each sourceAnchor isNil and: [ each parentType sourceAnchor notNil and: [ '<Initializer>' ~= each name and: [ each name ~= each parentType name ]]]]) openInMoose Am I doing something wrong? _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
what I did: - download ArgoUML-0.32-src.tar.gz (sources of ArgoUML) from the web site you gave - download ArgoUML-0.32-libs.tar.gz (libraries needed by ArgoUML) from the web site you gave - update verveinej to get your new shell script - rm -f output.mse - create MSE file:"verveinej.sh -autocp ArgoUML-0.32-libs ArgoUML-0.32-src" - load MSE in Moose panel - ran your script in workspace When calling verveineJ, "-autocp ArgoUML-0.32-libs" is important. Without it, JDT is not able to resolve a lot of types names, and as a consequence, a lot of source methods that use these types (e.g. as parameter type). And without JDT's name resolution, verveineJ is not able to link a method call to a method declaration. With the autocp, I found 13 methods with problems. Without it, I found 473 (or something like that) methods with problems. Not your 575 ones, but closer to it. No idea how we can get so different results with the same data and program !!! nicolas ----- Mail original ----- > De: [hidden email] > À: [hidden email] > Envoyé: Mardi 1 Novembre 2011 07:40:20 > Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the wrong classes > Updates: > Status: Started > > Comment #7 on issue 728 by [hidden email]: VerveineJ places > methods > in the wrong classes > http://code.google.com/p/moose-technology/issues/detail?id=728 > > Hmm, I just tried. First, I fixed the shell script (verveinej.sh) to > collect the jars automatically from the lib folder. Then I removed the > obsolete jars. > > But, still, if I run the following experiment, I get 575 potentially > problematic methods: > > - download ArgoUML 0.32 from: > http://argouml-downloads.tigris.org/argouml-0.32/ > - parse, load in Moose, and then execute: > (MooseModel root allModels first allMethods select: [:each | > each sourceAnchor isNil and: [ > each parentType sourceAnchor notNil and: [ > '<Initializer>' ~= each name and: [ > each name ~= each parentType name ]]]]) openInMoose > > > Am I doing something wrong? > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Thanks. Indeed, it is strange. Btw, I am on a Mac OS X Lion.
I will try again and get back to you later. But, coming back to the issue, the goal of the script is to provide a set of possible methods that are misplaced (that is methods that should appear in another class than where they are actually defined). The issue is that if we have the source for the class, it means we should have parsed it and have the proper information about its methods. So, how could then methods appear inside without source code? Cheers, Doru On 1 Nov 2011, at 10:35, Nicolas Anquetil wrote: > > what I did: > > - download ArgoUML-0.32-src.tar.gz (sources of ArgoUML) from the web site you gave > - download ArgoUML-0.32-libs.tar.gz (libraries needed by ArgoUML) from the web site you gave > - update verveinej to get your new shell script > - rm -f output.mse > - create MSE file:"verveinej.sh -autocp ArgoUML-0.32-libs ArgoUML-0.32-src" > - load MSE in Moose panel > - ran your script in workspace > > > When calling verveineJ, "-autocp ArgoUML-0.32-libs" is important. > Without it, JDT is not able to resolve a lot of types names, and as a consequence, a lot of source methods that use these types (e.g. as parameter type). > And without JDT's name resolution, verveineJ is not able to link a method call to a method declaration. > > With the autocp, I found 13 methods with problems. > Without it, I found 473 (or something like that) methods with problems. > Not your 575 ones, but closer to it. > > > No idea how we can get so different results with the same data and program !!! > > nicolas > > > > ----- Mail original ----- >> De: [hidden email] >> À: [hidden email] >> Envoyé: Mardi 1 Novembre 2011 07:40:20 >> Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the wrong classes >> Updates: >> Status: Started >> >> Comment #7 on issue 728 by [hidden email]: VerveineJ places >> methods >> in the wrong classes >> http://code.google.com/p/moose-technology/issues/detail?id=728 >> >> Hmm, I just tried. First, I fixed the shell script (verveinej.sh) to >> collect the jars automatically from the lib folder. Then I removed the >> obsolete jars. >> >> But, still, if I run the following experiment, I get 575 potentially >> problematic methods: >> >> - download ArgoUML 0.32 from: >> http://argouml-downloads.tigris.org/argouml-0.32/ >> - parse, load in Moose, and then execute: >> (MooseModel root allModels first allMethods select: [:each | >> each sourceAnchor isNil and: [ >> each parentType sourceAnchor notNil and: [ >> '<Initializer>' ~= each name and: [ >> each name ~= each parentType name ]]]]) openInMoose >> >> >> Am I doing something wrong? >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Yes it does seem strange, and it took me a while to accept it. The point is that, in Java, you can have different methods with the same name and different parameters. So, without a clear handle on the type of all parameters, you cannot decide for sure that a method call is the same as a method declaration. Another point is that JDT is made to work in an IDE, with incomplete code. That's why, even with the source declaration of the method, JDT does not link it to its calls unless it could resolve all the parameters' types. That's why it is also important to have all the needed libraries when parsing with verveineJ nicolas ----- Mail original ----- > De: "Tudor Girba" <[hidden email]> > À: "Moose-related development" <[hidden email]> > Cc: [hidden email] > Envoyé: Mardi 1 Novembre 2011 11:07:26 > Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ places methods in the wrong classes > Thanks. Indeed, it is strange. Btw, I am on a Mac OS X Lion. > > I will try again and get back to you later. > > But, coming back to the issue, the goal of the script is to provide a > set of possible methods that are misplaced (that is methods that > should appear in another class than where they are actually defined). > The issue is that if we have the source for the class, it means we > should have parsed it and have the proper information about its > methods. So, how could then methods appear inside without source code? > > Cheers, > Doru > > > On 1 Nov 2011, at 10:35, Nicolas Anquetil wrote: > > > > > what I did: > > > > - download ArgoUML-0.32-src.tar.gz (sources of ArgoUML) from the web > > site you gave > > - download ArgoUML-0.32-libs.tar.gz (libraries needed by ArgoUML) > > from the web site you gave > > - update verveinej to get your new shell script > > - rm -f output.mse > > - create MSE file:"verveinej.sh -autocp ArgoUML-0.32-libs > > ArgoUML-0.32-src" > > - load MSE in Moose panel > > - ran your script in workspace > > > > > > When calling verveineJ, "-autocp ArgoUML-0.32-libs" is important. > > Without it, JDT is not able to resolve a lot of types names, and as > > a consequence, a lot of source methods that use these types (e.g. as > > parameter type). > > And without JDT's name resolution, verveineJ is not able to link a > > method call to a method declaration. > > > > With the autocp, I found 13 methods with problems. > > Without it, I found 473 (or something like that) methods with > > problems. > > Not your 575 ones, but closer to it. > > > > > > No idea how we can get so different results with the same data and > > program !!! > > > > nicolas > > > > > > > > ----- Mail original ----- > >> De: [hidden email] > >> À: [hidden email] > >> Envoyé: Mardi 1 Novembre 2011 07:40:20 > >> Objet: [Moose-dev] Re: Issue 728 in moose-technology: VerveineJ > >> places methods in the wrong classes > >> Updates: > >> Status: Started > >> > >> Comment #7 on issue 728 by [hidden email]: VerveineJ places > >> methods > >> in the wrong classes > >> http://code.google.com/p/moose-technology/issues/detail?id=728 > >> > >> Hmm, I just tried. First, I fixed the shell script (verveinej.sh) > >> to > >> collect the jars automatically from the lib folder. Then I removed > >> the > >> obsolete jars. > >> > >> But, still, if I run the following experiment, I get 575 > >> potentially > >> problematic methods: > >> > >> - download ArgoUML 0.32 from: > >> http://argouml-downloads.tigris.org/argouml-0.32/ > >> - parse, load in Moose, and then execute: > >> (MooseModel root allModels first allMethods select: [:each | > >> each sourceAnchor isNil and: [ > >> each parentType sourceAnchor notNil and: [ > >> '<Initializer>' ~= each name and: [ > >> each name ~= each parentType name ]]]]) openInMoose > >> > >> > >> Am I doing something wrong? > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by moose-technology
Updates:
Status: Fixed Labels: Milestone-5.0 Comment #8 on issue 728 by [hidden email]: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 (No comment was entered for this change.) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |