* Re: Source navigator roadmap, features list, etc.?
@ 2000-09-28 0:23 dave.banham
2000-09-28 13:25 ` Syd Polk
0 siblings, 1 reply; 23+ messages in thread
From: dave.banham @ 2000-09-28 0:23 UTC (permalink / raw)
To: sourcenav
On the subject of bug reporting, I find that SN's inbuilt crash reporting system
doesn't work very well on my Win NT4 workstation - possibly because it has Lotus
Notes e-mail installed which isn't compatible with anything! If you would like
crash reports to be submitted may I suggest that either a cut & paste option is
provided (so that I can e-mail it to you) or an alternative submission method of
say an HTTP post be provided.
On the subject of member functions not being xref'd, I have found that (in C)
function names used as function pointers (i.e. in call-back initialisation) are
not xref'd. In fact the only way I can find them is to Grep the entire project
which takes a number of minutes.
Dave Banham
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-28 0:23 Source navigator roadmap, features list, etc.? dave.banham
@ 2000-09-28 13:25 ` Syd Polk
2000-09-28 17:28 ` Ben Elliston
0 siblings, 1 reply; 23+ messages in thread
From: Syd Polk @ 2000-09-28 13:25 UTC (permalink / raw)
To: sourcenav
At 08:17 AM 9/28/00 +0100, dave.banham@tde.alstom.com wrote:
>On the subject of bug reporting, I find that SN's inbuilt crash reporting
>system
>doesn't work very well on my Win NT4 workstation - possibly because it has
>Lotus
>Notes e-mail installed which isn't compatible with anything! If you would like
>crash reports to be submitted may I suggest that either a cut & paste
>option is
>provided (so that I can e-mail it to you) or an alternative submission
>method of
>say an HTTP post be provided.
>
>On the subject of member functions not being xref'd, I have found that (in C)
>function names used as function pointers (i.e. in call-back
>initialisation) are
>not xref'd. In fact the only way I can find them is to Grep the entire project
>which takes a number of minutes.
This is actually really hard to do.
We could certainly flag assignments of function pointers, but there is no
good static determination of when a function is actually called
dereferencing a function pointer. This requires runtime analysis. And it
could be wrong; the runtime analysis would have to have a reverse table of
addresses to functions. A debugger could do this while the exe is running.
So the only thing we can do is flag assignments of function pointers and
put it in the database.
>Dave Banham
>
Syd Polk spolk@redhat.com
Engineering Manager +1 415 777 9810 x 241
Red Hat, Inc.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-28 13:25 ` Syd Polk
@ 2000-09-28 17:28 ` Ben Elliston
2000-09-29 6:06 ` Bruce Stephens
0 siblings, 1 reply; 23+ messages in thread
From: Ben Elliston @ 2000-09-28 17:28 UTC (permalink / raw)
To: Syd Polk; +Cc: sourcenav
We could certainly flag assignments of function pointers, but there is
no good static determination of when a function is actually called
dereferencing a function pointer. This requires runtime analysis. And
it could be wrong; the runtime analysis would have to have a reverse
table of addresses to functions. A debugger could do this while the
exe is running.
Or worse, the function pointer could be determined by address arithmetic.
As you say, there's only so much that can be done statically.
Ben
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-28 17:28 ` Ben Elliston
@ 2000-09-29 6:06 ` Bruce Stephens
0 siblings, 0 replies; 23+ messages in thread
From: Bruce Stephens @ 2000-09-29 6:06 UTC (permalink / raw)
To: sourcenav
Ben Elliston <bje@redhat.com> writes:
> We could certainly flag assignments of function pointers, but there is
> no good static determination of when a function is actually called
> dereferencing a function pointer. This requires runtime analysis. And
> it could be wrong; the runtime analysis would have to have a reverse
> table of addresses to functions. A debugger could do this while the
> exe is running.
>
> Or worse, the function pointer could be determined by address
> arithmetic. As you say, there's only so much that can be done
> statically.
Of course. There are inevitably limitations.
However, whenever a bit of code does something with something which is
a function pointer, then that's worth noting somewhere.
It's possible that it's never called, but it's surely more than likely
that it will be at some point (even though SN won't be able to tell
where it's called). Not just assignments, either: arguments to
functions ought to be stored somewhere (Tcl_CreateObjCommand and
similar spring to mind).
--
Bruce Stephens Bruce.Stephens@MessagingDirect.com
MessagingDirect(UK) Ltd <URL: http://www.MessagingDirect.com/ >
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Source navigator roadmap, features list, etc.?
@ 2000-10-05 1:16 William Gacquer
0 siblings, 0 replies; 23+ messages in thread
From: William Gacquer @ 2000-10-05 1:16 UTC (permalink / raw)
To: sourcenav
or some kind of "extended real file view":
dir | file | SN | VC |
------------------------------------------|
a | toto.c | yes | yes |
a/b | foo.h | no | yes |
z/zz | albert.txt | no | no |
The SN and VC (version control) columns could be filled with checkboxes.
Of course, this one could be more complete than the one above.
Maybe we could discuss the features that should be included in that kind of
view, if you accept it, of course.
William
-----Original Message-----
From: dave.banham@tde.alstom.com [ mailto:dave.banham@tde.alstom.com ]
Sent: jeudi 5 octobre 2000 09:10
To: sourcenav@sources.redhat.com
Subject: RE: Source navigator roadmap, features list, etc.?
<snip>
>I think that we should have a checkbox on the directory selection dialog
>that says "Live directory". If this is checked, the directory will be
>scanned every time the project is refreshed.
You'd have to implement explicit exclusions too.
Regards
Dave Banham
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Source navigator roadmap, features list, etc.?
@ 2000-10-05 0:52 dave.banham
0 siblings, 0 replies; 23+ messages in thread
From: dave.banham @ 2000-10-05 0:52 UTC (permalink / raw)
To: sourcenav
<snip>
>I think that we should have a checkbox on the directory selection dialog
>that says "Live directory". If this is checked, the directory will be
>scanned every time the project is refreshed.
You'd have to implement explicit exclusions too.
Regards
Dave Banham
^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Source navigator roadmap, features list, etc.?
@ 2000-10-04 0:53 leonp
2000-10-04 2:42 ` Timothy M. Shead
0 siblings, 1 reply; 23+ messages in thread
From: leonp @ 2000-10-04 0:53 UTC (permalink / raw)
To: sourcenav
At 16:02 03/10/2000 -0700, Mo DeJong wrote:
>On Wed, 27 Sep 2000, William Gacquer wrote:
> > 9/ a autoconf/automake project creation as in kdevelop
>
>This one is hard to do in a general way, but we could do
>something like writing a configure.in for the user in the
>same way that we write a Makefile.
As far as I was able to understand the SN was designed for use also
(mainly?) in Embedded Programming, where you need to have a little bit
simpler and closer approach to a lot of build process parameters. Absence
of this simple approach in kdevelop (which is very good IDE!) was the main
reason that I left my attempts to sufficiently and comfortably integrate
the embedded projects into it, while one of the main difficulties was this
autoconf/automake stuff. I shall be very disappointed if this issue will be
introduced also in SN, which is my only IDE today.
Thanks to Cygnus/RH for the good SW.
Leon Pollak
leonp@plris.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-10-04 0:53 leonp
@ 2000-10-04 2:42 ` Timothy M. Shead
0 siblings, 0 replies; 23+ messages in thread
From: Timothy M. Shead @ 2000-10-04 2:42 UTC (permalink / raw)
To: leonp; +Cc: sourcenav
leonp@plris.com wrote:
> At 16:02 03/10/2000 -0700, Mo DeJong wrote:
>
>> On Wed, 27 Sep 2000, William Gacquer wrote:
>> > 9/ a autoconf/automake project creation as in kdevelop
>>
>> This one is hard to do in a general way, but we could do
>> something like writing a configure.in for the user in the
>> same way that we write a Makefile.
>
> As far as I was able to understand the SN was designed for use also
> (mainly?) in Embedded Programming, where you need to have a little bit
> simpler and closer approach to a lot of build process parameters.
> Absence of this simple approach in kdevelop (which is very good IDE!)
> was the main reason that I left my attempts to sufficiently and
> comfortably integrate the embedded projects into it, while one of the
> main difficulties was this autoconf/automake stuff. I shall be very
> disappointed if this issue will be introduced also in SN, which is my
> only IDE today.
Remember that you can always use external commands to build any way you
like - I prefer to use my own makefiles, so my "Build Command" is set to
"make", "Directory" to my top-level project directory, and "Build
Targets" to "<External Makefile>". This shouldn't make anyone nervous :)
Timothy M. Shead
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
@ 2000-09-29 0:26 dave.banham
2000-09-29 11:32 ` Syd Polk
0 siblings, 1 reply; 23+ messages in thread
From: dave.banham @ 2000-09-29 0:26 UTC (permalink / raw)
To: sourcenav
Syd,
You misunderstand my request. All I would like SN to do is "flag assignments of
function pointers" so that Xref will show the assignment as a reference to the
function symbol being xref'd. Currently it does not, so the only way of finding
such references is with grep.
Regards,
Dave Banham
>On the subject of member functions not being xref'd, I have found that (in C)
>function names used as function pointers (i.e. in call-back
>initialisation) are
>not xref'd. In fact the only way I can find them is to Grep the entire project
>which takes a number of minutes.
This is actually really hard to do.
We could certainly flag assignments of function pointers, but there is no
good static determination of when a function is actually called
dereferencing a function pointer. This requires runtime analysis. And it
could be wrong; the runtime analysis would have to have a reverse table of
addresses to functions. A debugger could do this while the exe is running.
So the only thing we can do is flag assignments of function pointers and
put it in the database.
>Dave Banham
>
Syd Polk spolk@redhat.com
Engineering Manager +1 415 777 9810 x 241
Red Hat, Inc.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-29 0:26 dave.banham
@ 2000-09-29 11:32 ` Syd Polk
0 siblings, 0 replies; 23+ messages in thread
From: Syd Polk @ 2000-09-29 11:32 UTC (permalink / raw)
To: dave.banham, sourcenav
At 08:18 AM 9/29/00 +0100, dave.banham@tde.alstom.com wrote:
>Syd,
>You misunderstand my request. All I would like SN to do is "flag
>assignments of
>function pointers" so that Xref will show the assignment as a reference to the
>function symbol being xref'd. Currently it does not, so the only way of
>finding
>such references is with grep.
I agree with you here. Others have asked for what I was talking about.
>Regards,
>Dave Banham
>
>
> >On the subject of member functions not being xref'd, I have found that
> (in C)
> >function names used as function pointers (i.e. in call-back
> >initialisation) are
> >not xref'd. In fact the only way I can find them is to Grep the entire
> project
> >which takes a number of minutes.
>
>This is actually really hard to do.
>
>We could certainly flag assignments of function pointers, but there is no
>good static determination of when a function is actually called
>dereferencing a function pointer. This requires runtime analysis. And it
>could be wrong; the runtime analysis would have to have a reverse table of
>addresses to functions. A debugger could do this while the exe is running.
>
>So the only thing we can do is flag assignments of function pointers and
>put it in the database.
>
> >Dave Banham
> >
>
>Syd Polk spolk@redhat.com
>Engineering Manager +1 415 777 9810 x 241
>Red Hat, Inc.
>
Syd Polk spolk@redhat.com
Engineering Manager +1 415 777 9810 x 241
Red Hat, Inc.
^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <William>]
* Source navigator roadmap, features list, etc.?
@ 2000-09-25 22:04 Timothee Besset
2000-09-26 9:23 ` Syd Polk
2000-09-26 10:30 ` Berek
0 siblings, 2 replies; 23+ messages in thread
From: Timothee Besset @ 2000-09-25 22:04 UTC (permalink / raw)
To: sourcenav
Is this list the only way to send feature suggestions and bug reports?
What are the actual plans of RedHat with source navigator, is it going
to evolve a lot more? Because I would have a truckload of improvement
suggestions and feature requests. It would be nice if there was a public
space somewhere that described who is doing what, maintaining what on
this project.
I had to move from an MSDev environment to development under linux, and
Source Navigator does some things better than MSDev, but it also has
some big drawbacks.
regards
TTimo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-25 22:04 Timothee Besset
@ 2000-09-26 9:23 ` Syd Polk
2000-09-26 10:30 ` Berek
1 sibling, 0 replies; 23+ messages in thread
From: Syd Polk @ 2000-09-26 9:23 UTC (permalink / raw)
To: Timothee Besset; +Cc: sourcenav
Timothee Besset wrote:
>
> Is this list the only way to send feature suggestions and bug reports?
> What are the actual plans of RedHat with source navigator, is it going
> to evolve a lot more? Because I would have a truckload of improvement
> suggestions and feature requests. It would be nice if there was a public
> space somewhere that described who is doing what, maintaining what on
> this project.
>
Right now, we are busy overhauling the GUI code to use incr Tcl 3.0. After we
get done with that, we will start working on new features. So nobody is
officially doing any new features until we get 5.0 released.
> I had to move from an MSDev environment to development under linux, and
> Source Navigator does some things better than MSDev, but it also has
> some big drawbacks.
>
Feel free to post suggestions and requests. Better yet, feel free to work on the
code!
> regards
>
> TTimo
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-25 22:04 Timothee Besset
2000-09-26 9:23 ` Syd Polk
@ 2000-09-26 10:30 ` Berek
2000-09-26 10:37 ` Syd Polk
2000-09-27 21:41 ` Ben Elliston
1 sibling, 2 replies; 23+ messages in thread
From: Berek @ 2000-09-26 10:30 UTC (permalink / raw)
To: sourcenav
I agree completely. I love SN, but it does have a lot of rough edges in the
UI, and it's buggy. I, too, have a lot of suggestions and bug reports and
would like to know what the future of SN is going to be
----- Original Message -----
From: "Timothee Besset" <timo@qeradiant.com>
To: <sourcenav@sources.redhat.com>
Sent: Tuesday, September 26, 2000 01:00
Subject: Source navigator roadmap, features list, etc.?
> Is this list the only way to send feature suggestions and bug reports?
> What are the actual plans of RedHat with source navigator, is it going
> to evolve a lot more? Because I would have a truckload of improvement
> suggestions and feature requests. It would be nice if there was a public
> space somewhere that described who is doing what, maintaining what on
> this project.
>
> I had to move from an MSDev environment to development under linux, and
> Source Navigator does some things better than MSDev, but it also has
> some big drawbacks.
>
> regards
>
> TTimo
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-26 10:30 ` Berek
@ 2000-09-26 10:37 ` Syd Polk
2000-09-27 21:41 ` Ben Elliston
1 sibling, 0 replies; 23+ messages in thread
From: Syd Polk @ 2000-09-26 10:37 UTC (permalink / raw)
To: Berek; +Cc: sourcenav
The future is going to be dictated largely by the community. If a lot of people
in the community want something in, we will make it a priority for development.
Syd Polk
Engineering Manager
Berek wrote:
>
> I agree completely. I love SN, but it does have a lot of rough edges in the
> UI, and it's buggy. I, too, have a lot of suggestions and bug reports and
> would like to know what the future of SN is going to be
>
> ----- Original Message -----
> From: "Timothee Besset" <timo@qeradiant.com>
> To: <sourcenav@sources.redhat.com>
> Sent: Tuesday, September 26, 2000 01:00
> Subject: Source navigator roadmap, features list, etc.?
>
> > Is this list the only way to send feature suggestions and bug reports?
> > What are the actual plans of RedHat with source navigator, is it going
> > to evolve a lot more? Because I would have a truckload of improvement
> > suggestions and feature requests. It would be nice if there was a public
> > space somewhere that described who is doing what, maintaining what on
> > this project.
> >
> > I had to move from an MSDev environment to development under linux, and
> > Source Navigator does some things better than MSDev, but it also has
> > some big drawbacks.
> >
> > regards
> >
> > TTimo
> >
> >
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-26 10:30 ` Berek
2000-09-26 10:37 ` Syd Polk
@ 2000-09-27 21:41 ` Ben Elliston
2000-10-03 9:44 ` Mo DeJong
1 sibling, 1 reply; 23+ messages in thread
From: Ben Elliston @ 2000-09-27 21:41 UTC (permalink / raw)
To: Berek; +Cc: sourcenav
I agree completely. I love SN, but it does have a lot of rough edges
in the UI, and it's buggy. I, too, have a lot of suggestions and bug
reports and would like to know what the future of SN is going to be
IMHO, it should be a relatively high priority to establish a GNATS bug
reporting database for S-N (as other projects on sources.redhat.com do).
This will encourage folks to submit bug reports and for us to track them.
Ben
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Source navigator roadmap, features list, etc.?
2000-09-27 21:41 ` Ben Elliston
@ 2000-10-03 9:44 ` Mo DeJong
0 siblings, 0 replies; 23+ messages in thread
From: Mo DeJong @ 2000-10-03 9:44 UTC (permalink / raw)
To: Ben Elliston; +Cc: Berek, sourcenav
On Thu, 28 Sep 2000, Ben Elliston wrote:
> I agree completely. I love SN, but it does have a lot of rough edges
> in the UI, and it's buggy. I, too, have a lot of suggestions and bug
> reports and would like to know what the future of SN is going to be
>
> IMHO, it should be a relatively high priority to establish a GNATS bug
> reporting database for S-N (as other projects on sources.redhat.com do).
> This will encourage folks to submit bug reports and for us to track them.
>
> Ben
We already have one, but we do not want to "roll it out" until
5.0 is ready.
Mo DeJong
Red Hat Inc
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2000-10-05 1:16 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-28 0:23 Source navigator roadmap, features list, etc.? dave.banham
2000-09-28 13:25 ` Syd Polk
2000-09-28 17:28 ` Ben Elliston
2000-09-29 6:06 ` Bruce Stephens
-- strict thread matches above, loose matches on Subject: below --
2000-10-05 1:16 William Gacquer
2000-10-05 0:52 dave.banham
2000-10-04 0:53 leonp
2000-10-04 2:42 ` Timothy M. Shead
2000-09-29 0:26 dave.banham
2000-09-29 11:32 ` Syd Polk
[not found] <William>
[not found] ` <Gacquer's>
[not found] ` <message>
[not found] ` <of>
[not found] ` <"Wed,>
[not found] ` <27>
[not found] ` <Sep>
[not found] ` <2000>
[not found] ` <10:12:49>
[not found] ` <+0200>
2000-09-27 1:12 ` William Gacquer
2000-09-27 22:16 ` Bruce Stephens
2000-09-28 9:15 ` Berek
2000-09-28 13:26 ` Syd Polk
2000-09-28 13:22 ` Syd Polk
2000-10-03 16:02 ` Mo DeJong
2000-10-04 10:25 ` Syd Polk
2000-09-25 22:04 Timothee Besset
2000-09-26 9:23 ` Syd Polk
2000-09-26 10:30 ` Berek
2000-09-26 10:37 ` Syd Polk
2000-09-27 21:41 ` Ben Elliston
2000-10-03 9:44 ` Mo DeJong
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).