bug report

bug report

[Paul F. Kunz]

   I'm using Source Navigator (SN) on my home machine on a CVS revison
control project.  I have a PPP connection, thus I must type my
password for all CVS transactions.  When I have a file in the SN
editor and I do Tools -> Revison Control -> Compare Revisons, SN just
hangs.  Perhaps, it doesn't know how to repsond to the password
prompt.  Or perhaps it is not respecting my CVS_RSH = ssh environment
variable setting. 

Re: bug report

[Albert Wong]

>    I'm using Source Navigator (SN) on my home machine on a CVS revison
> control project.  I have a PPP connection, thus I must type my
> password for all CVS transactions.  When I have a file in the SN
> editor and I do Tools -> Revison Control -> Compare Revisons, SN just
> hangs.  Perhaps, it doesn't know how to repsond to the password
> prompt.  Or perhaps it is not respecting my CVS_RSH = ssh environment
> variable setting. 
>

A quick fix for now would be to use ssh-agent and RSA authentication.

-Albert

Re: bug report

[Paul F. Kunz]

>>>>> On Tue, 25 Jul 2000 19:44:09 -0700 (PDT), Albert Wong <awong@cs.washington.edu> said:

> A quick fix for now would be to use ssh-agent and RSA
> authentication.

   Wow! what a fast answer!   

Unfortunately, my home site has all home directories in AFS.   So if I
login in there to read my mail, I don't get a AFS token via ssh.   I
guess I have to choose between  SN working or my email working.

Re: bug report

[Ben Elliston]

      I'm using Source Navigator (SN) on my home machine on a CVS revison
   control project.  I have a PPP connection, thus I must type my
   password for all CVS transactions.  When I have a file in the SN
   editor and I do Tools -> Revison Control -> Compare Revisons, SN just
   hangs.  Perhaps, it doesn't know how to repsond to the password
   prompt.  Or perhaps it is not respecting my CVS_RSH = ssh environment
   variable setting.

Source-Navigator doesn't expect the revision control tool to want any input.  
It just runs the command and groks the output.

If you're using ssh, why not use ssh-agent/ssh-add to prevent having to type
your password on every CVS transaction?  S-N will start working, too.

Ben

Re: bug report

[Paul F. Kunz]

>>>>> On Wed, 26 Jul 2000 12:45:39 +1000 (EST), Ben Elliston <bje@redhat.com> said:

   Wow! what a fast reponse!

> Source-Navigator doesn't expect the revision control tool to want
> any input.  It just runs the command and groks the output.

   Well ediff-revision under emacs understands to prompt for
password, so why isn't S-N at least as smart.

> If you're using ssh, why not use ssh-agent/ssh-add to prevent having
> to type your password on every CVS transaction?  S-N will start
> working, too.

   There are other problems with that, but I'm beginning to think they
are less of a problem.

Re: bug report

[Mo DeJong]

On Tue, 25 Jul 2000, Paul F. Kunz wrote:

> >>>>> On Wed, 26 Jul 2000 12:45:39 +1000 (EST), Ben Elliston <bje@redhat.com> said:
> 
>    Wow! what a fast reponse!
> 
> > Source-Navigator doesn't expect the revision control tool to want
> > any input.  It just runs the command and groks the output.
> 
>    Well ediff-revision under emacs understands to prompt for
> password, so why isn't S-N at least as smart.


Well, why don't you make it smarter? Poke around in
version.tcl for the sn_rcs_exec command. You
are going to have to do something like
sn_exec_x_events from utilities.tcl, the
catch is you will need to read some output
like event_exec_x_events_proc and figure
out if the output is a password prompt.
Then you would need to bring up a password
dialog and have the user type a password.
Post a patch to the list when you have
it working.

Have Fun
Mo DeJong
Red Hat Inc

Re: bug report

[Ben Elliston]

   > > Source-Navigator doesn't expect the revision control tool to want
   > > any input.  It just runs the command and groks the output.

   >    Well ediff-revision under emacs understands to prompt for
   > password, so why isn't S-N at least as smart.

It was this way by design.  S-N treats all version control systems the same;
they support a common set of operations.

Ben

Bug report

[Paul F. Kunz]

   Still can't find the proper place for bug reports, so please
forward.

   I've tried Source Navigator on a project that has source code in C,
C++, Java, and even some Fortran.   The only problem is that there is
a Java class called `Display' and also a C++ class called `Display'.
This unusual situation confuses Source Navigator.  For example, the
class heiarchy display shows some C++ classes inheriting from a Java
class and visa versa.

   I must admit that my situation is very unusal and something that
one can easily not be prepared for.  Or maybe not.  If one has a mixed
Java/C++ application, it might be very natural to have a C++ class
counterpart that does the real work for a Java class. 

   Anyway, It reminds me of the time that I ran Doxygen on a large C++
project and managed to make it crash.  The problem was that there was
a nested class with the same name as a top level class.  Dimitri was
able to fix Doxygen quickly for my unusal case, so maybe SN can also
be fixed.  But I'm ready to change the name of either the Java class
or the C++ class in the mean time.

Bug report

[Paul F. Kunz]

   I couldn't find on the Web a better address to submit a bug
report.   Please forward to a more proper address.

   This in an installation bug.  I did the following and snavigator
failed to run...

- download source, unzip, untar.

- configure  (no options, system is Red Hat Linux 6.1 on Intel platform)

- make

- su'ed to root and did `make install'.

- quit root session, did `rehash' and typed `snavigator' which failed
  on `sn_tcl_tk_init' (or something like that).


   Grep'ing as myself in /usr/local/share I found...

cd /usr/local/share/
find . -type f -print0 | xargs -0 -e grep -n -e sn_tcl_tk_init
grep: ./sdk/include/db.h: Permission denied
grep: ./sdk/include/cdefs.h: Permission denied
grep: ./gui/tclIndex: Permission denied
./gui/sninit.tcl:772:proc sn_tcl_tk_init {} {

After su'ing to root and fixing these permissions, then snavigator
launched and operated fine under my user account.

P.S.

   I've considered many times buying a 5-10 user license for Source
Navigator.   But I could never quite justify it because someone else
on my site has already bought a 25 user license for SNiFF+ which is
more or less an equivalent product.   Source Navigator is considerablely
easier to use on a new project than SNiFF+, thus with it becoming
GPL'd, the choice is obvious.

Re: Bug report

[Mo DeJong]

On Mon, 24 Jul 2000, Paul F. Kunz wrote:

>    I couldn't find on the Web a better address to submit a bug
> report.   Please forward to a more proper address.
> 
>    This in an installation bug.  I did the following and snavigator
> failed to run...
..
> - quit root session, did `rehash' and typed `snavigator' which failed
>   on `sn_tcl_tk_init' (or something like that).

It is a known problem, we are going to have a directory where you
can grab patches soon.

> P.S.
> 
>    I've considered many times buying a 5-10 user license for Source
> Navigator.   But I could never quite justify it because someone else
> on my site has already bought a 25 user license for SNiFF+ which is
> more or less an equivalent product.   Source Navigator is considerablely
> easier to use on a new project than SNiFF+, thus with it becoming
> GPL'd, the choice is obvious.

Just because it is GPLed does not mean you can not spend money
on Source-Navigator. If there is a feature you are just dying
to have or some bug that you really need fixed, you can always
hire us to implement it.

Mo DeJong
Red Hat Inc

Re: Bug report

[Paul F. Kunz]

>>>>> On Mon, 24 Jul 2000 20:11:28 -0700 (PDT), Mo DeJong <mdejong@cygnus.com> said:

> It is a known problem, we are going to have a directory where you
> can grab patches soon.

In hindsight, I should have known that someone has already seen this
problem. 

> Just because it is GPLed does not mean you can not spend money on
> Source-Navigator. If there is a feature you are just dying to have
> or some bug that you really need fixed, you can always hire us to
> implement it.

   I'll keep that in mind.   But first, I'll install it for public use
and see if anybody uses it.