Xref and find declaration of variables

Xref and find declaration of variables

[Thomas Stroesslin]

Hi,

I am a sniff+ user who likes to change to a GPL'ed IDE. There are a lot
of features concerning Xref'ing that I miss in Source Navigator:

myfile.c :

int myglobalvar;
int myfunc(int myarg) {
  int mylocalvar;
  int myvar;

  myvar = 1;
  mylocalvar = 1;
  myarg = 1;
  myglobalvar=1;
}

myotherfile.c :

int myvar; // which is global
...

I am working on myfile.c and try to find out things about my variables:

1) find declaration of myvar on the assignment line -> leads me to myvar
     of myotherfile.c (don't you have scope info in the db?)

2) same as 1) for mylocalvar
   -> doesn't find anything, doesn't report error -> does nothing!

3) same as 1) for myarg
   -> same as 2)

4) myglobalvar referred by -> finds nothing

5) myvar or mylocalvar or myarg referred by in function myfunc()
   -> same as 4


all these features are available in sniff+. IMHO, they are among the top
10 most importand code analysis features (the other 5 are working in
sourcenavigator, good stuff)

do you plan to include such features in future releases of
sourcenavigator? If so, when - roughly - can I expect them to be
implemented?

cheers,
tom

Xref and find declaration of variables

[Thomas Stroesslin]

consider the following "project":

myfile.c :

int myglobalvar;
int myfunc(int myarg) {
  int mylocalvar;
  int myvar;

  myvar = 1;
  mylocalvar = 1;
  myarg = 1;
  myglobalvar=1;
}

myotherfile.c :

int myvar; // which is global
...

I am working on myfile.c and try to find out things about my variables:

1) find declaration of myvar on the assignment line -> leads me to myvar
     of myotherfile.c (don't you have scope info in the db?)

2) same as 1) for mylocalvar
   -> doesn't find anything, doesn't report error -> does nothing!

3) same as 1) for myarg
   -> same as 2)

4) myglobalvar referred by -> finds nothing

5) myvar or mylocalvar or myarg referred by in function myfunc()
   -> same as 4


all these features are available in sniff+. IMHO, they are among the top
10 most importand code analysis features (the other 5 are working in
sourcenavigator, good stuff)

do you plan to include such features in future releases of
sourcenavigator? If so, when - roughly - can I expect them to be
implemented?

cheers,
tom

Re: Xref and find declaration of variables

[Richard F Weber]

Don't know if it's a problem persay with SourceNavigator as compared to 
the C-Parser itself not registering the proper variable & keeping track 
of the scope of the current variable that's being worked with.

However, this could explain some of the hang-ups I've been having with 
the Ada Parser if the database back-end doesn't do associations correctly.

--Rich

Thomas Stroesslin wrote:

>consider the following "project":
>
>myfile.c :
>
>int myglobalvar;
>int myfunc(int myarg) {
>  int mylocalvar;
>  int myvar;
>
>  myvar = 1;
>  mylocalvar = 1;
>  myarg = 1;
>  myglobalvar=1;
>}
>
>myotherfile.c :
>
>int myvar; // which is global
>...
>
>I am working on myfile.c and try to find out things about my variables:
>
>1) find declaration of myvar on the assignment line -> leads me to myvar
>     of myotherfile.c (don't you have scope info in the db?)
>
>2) same as 1) for mylocalvar
>   -> doesn't find anything, doesn't report error -> does nothing!
>
>3) same as 1) for myarg
>   -> same as 2)
>
>4) myglobalvar referred by -> finds nothing
>
>5) myvar or mylocalvar or myarg referred by in function myfunc()
>   -> same as 4
>
>
>all these features are available in sniff+. IMHO, they are among the top
>10 most importand code analysis features (the other 5 are working in
>sourcenavigator, good stuff)
>
>do you plan to include such features in future releases of
>sourcenavigator? If so, when - roughly - can I expect them to be
>implemented?
>
>cheers,
>tom
>
>

Re: Xref and find declaration of variables

[Thomas Stroesslin]

>I think you are asking the wrong question here. Naturally we
>plan on fixing bugs in future releases. But the reality is
>that we have to work on things as time permits. If you

ok, I reformulate the question :-) "do you plan to fix the bug of not
having proper scoping?" don't say it's not a bug, cause at least my
first example must be considered a bug. do you agree on that, Mo? Ok,
the others are feature whishes. But then again, Mo: end-user feedback
is an important part of open source software development, don't you
think?
the order is:
1) release
2) user feedback
3) finetune, enhance, bugfix etc.

where 2) and 3) are looped. I spoke about 2), not 3)

to sourcenav users:
I'd like to know if anybody else also
misses the features I described. Maybe I am spoiled, but IMHO, it
is very hard to analyse someone else's code without those features.
And remember: 3) comes later; so don't let you be scared to silence if
someone tells you immediately to code your whishes yourself if you're
not happy.

to Mo:
If you really _are_ an opensource-man, please be nicer to end-users, as
they help a lot on improving opensource software.

>really need this feature fixes by a specific date, why
>don't you roll up your sleeves and start hacking on the
>source code? If you are uninterested in hacking on the
>source code, you could always contract with Red Hat
>to fix the problem. Heck, you could even hire a third
>party to fix the problem and post a patch for inclusion
>into the next release. You have plenty of options
>when it comes to open source code.
>
>Mo DeJong
>Red Hat Inc

cheers,
tom

> Thomas Stroesslin wrote:
> 
> >consider the following "project":
> >
> >myfile.c :
> >
> >int myglobalvar;
> >int myfunc(int myarg) {
> >  int mylocalvar;
> >  int myvar;
> >
> >  myvar = 1;
> >  mylocalvar = 1;
> >  myarg = 1;
> >  myglobalvar=1;
> >}
> >
> >myotherfile.c :
> >
> >int myvar; // which is global
> >...
> >
> >I am working on myfile.c and try to find out things about my variables:
> >
> >1) find declaration of myvar on the assignment line -> leads me to myvar
> >     of myotherfile.c (don't you have scope info in the db?)
> >
> >2) same as 1) for mylocalvar
> >   -> doesn't find anything, doesn't report error -> does nothing!
> >
> >3) same as 1) for myarg
> >   -> same as 2)
> >
> >4) myglobalvar referred by -> finds nothing
> >
> >5) myvar or mylocalvar or myarg referred by in function myfunc()
> >   -> same as 4
> >
> >
> >all these features are available in sniff+. IMHO, they are among the top
> >10 most importand code analysis features (the other 5 are working in
> >sourcenavigator, good stuff)
> >
> >do you plan to include such features in future releases of
> >sourcenavigator? If so, when - roughly - can I expect them to be
> >implemented?
> >
> >cheers,
> >tom
> >
> >
> 
> 
> 

-- 
---------------------------------------
Thomas Stroesslin
DI-MANTRA (INF 130)
EPFL
CH-1015 Lausanne
phone: +41 (0)21 693 52 64
E-Mail: mailto:thomas.stroesslin@epfl.ch
WWW: http://diwww.epfl.ch/~stroessl/index.html
PGP: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x183AA136

Re: Xref and find declaration of variables

[Ian Roxborough]

Thomas Stroesslin wrote:
> ok, I reformulate the question :-) "do you plan to fix the bug of not
> having proper scoping?" don't say it's not a bug.....

Heheh, I don't see how it could be a bug.

I'll put it another way for you "do you plan to implement a complete
scoping system?"

The answer is "at some point, when we have time".

Note that what you are asking us to do doesn't exist
in SN yet.  Maybe some hack or work around could be used,
but I'd prefer to see a clean safe scope implementation
that would work for nested namespaces, classes, inner-classes,
etc.

Ian.

Re: Xref and find declaration of variables

[Thomas Stroesslin]

> > ok, I reformulate the question :-) "do you plan to fix the bug of not
> > having proper scoping?" don't say it's not a bug.....
> 
> Heheh, I don't see how it could be a bug.

Ok, you're right.
in the example I mentionned, the Xref should at least say: "I don't
know". However, it pretends knowing what it does and gives me the wrong
answer. This is a bug. Saying that it didn't know would be a missing
feature, which I could accept. I see that probably you'd have to remove
the Xref completely to prevent giving false answers.

> I'll put it another way for you "do you plan to implement a complete
> scoping system?"
> 
> The answer is "at some point, when we have time".
> 
> Note that what you are asking us to do doesn't exist
> in SN yet.  Maybe some hack or work around could be used,

I didn't know there was little (or none at all?) scoping support. I only
guessed :-)

Note: I would not dare asking you to implement it. I rather ask
_if_ you planned to implement it, and heck, this is not the same

The essence of my postings:
Having a good xref is the most important thing for me. I don't care much
about other features, I just want a good xref, and I want you to know
that.

thanks,
tom

Re: Xref and find declaration of variables

[Mo DeJong]

On Wed, 2 May 2001, Thomas Stroesslin wrote:

> Mo: end-user feedback is an important part of open
> source software development, don't you think?

Yes, but users actually fixing some problems is an
important part of an open source project too.
Asking "when can I expect this to be done"
multiple times does not seem like feedback to me.

> to Mo:
> If you really _are_ an opensource-man, please be nicer to end-users, as
> they help a lot on improving opensource software.

I really don't follow. I am trying to help you to understand
your options with respect to getting this bug fixed.
I don't see what that has to do with being "nice to end users".
Is the problem that you just don't like any of the options
I have outlined, or do you object to the presentation?

Mo

Re: Xref and find declaration of variables

[Mo DeJong]

On Tue, 1 May 2001, Thomas Stroesslin wrote:

... Details of a bug ...

> do you plan to include such features in future releases of
> sourcenavigator? If so, when - roughly - can I expect them to be
> implemented?
> 
> cheers,
> tom

I think you are asking the wrong question here. Naturally we
plan on fixing bugs in future releases. But the reality is
that we have to work on things as time permits. If you
really need this feature fixes by a specific date, why
don't you roll up your sleeves and start hacking on the
source code? If you are uninterested in hacking on the
source code, you could always contract with Red Hat
to fix the problem. Heck, you could even hire a third
party to fix the problem and post a patch for inclusion
into the next release. You have plenty of options
when it comes to open source code.

Mo DeJong
Red Hat Inc