public inbox for sourcenav@sourceware.org
 help / color / mirror / Atom feed
From: Thomas Stroesslin <thomas.stroesslin@epfl.ch>
To: sourcenav@sources.redhat.com
Subject: Re: Xref and find declaration of variables
Date: Wed, 02 May 2001 04:33:00 -0000	[thread overview]
Message-ID: <Pine.GSO.4.21.0105020843360.28286-100000@mantrasun3.epfl.ch> (raw)
In-Reply-To: <3AEEF30F.6050805@link.com>

>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

  reply	other threads:[~2001-05-02  4:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01  9:10 Thomas Stroesslin
2001-05-01 10:32 ` Richard F Weber
2001-05-02  4:33   ` Thomas Stroesslin [this message]
2001-05-02 11:28     ` Ian Roxborough
2001-05-03  0:15       ` Thomas Stroesslin
2001-05-02 12:43     ` Mo DeJong
2001-05-01 10:52 ` Mo DeJong
  -- strict thread matches above, loose matches on Subject: below --
2001-03-30  5:45 Thomas Stroesslin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.21.0105020843360.28286-100000@mantrasun3.epfl.ch \
    --to=thomas.stroesslin@epfl.ch \
    --cc=sourcenav@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).