cscope-devel

Re: [Cscope-devel] xcscope.el maintainership

[Hans-Bernhard B. <HBB...@t-...>]

On 28.07.2013 09:02, Dima Kogan wrote:

> These are all assigned to Darryl, who I assume is no longer active.

Well, you could always ask Darryl directly.  Haven't heard from him in a 
long time, but he might still be reachable.

> and I'd like to ask: does it make sense for these bindings to continue
> being distributed here? How would yall feel about splitting out that
> part of the repository into a separate project, and I can then take on
> maintainership of that code. I am a regular user of those bindings, so
> this should be a working arrangement.

Or you could do that inside the cscope project.  Our release cycle has 
been very slow these last few year, but it should be possible to 
organize a release of cscope once you have done all those xcscope 
patches you consider necessary.

[Cscope-devel] xcscope.el maintainership

[Dima K. <cs...@di...>]

Hi.

I noticed that the cscope emacs bindings (xcscope.el) appear to be
relatively unmaintained. The last commit was a patch I submitted earlier
this year:

 https://sourceforge.net/p/cscope/patches/79/[1]

The last commit before that happened in 2002. In the meantime there are
plenty of patches and bugs in the tracker that have been open for years.
These are all assigned to Darryl, who I assume is no longer active.

I just fixed another bug, and submitted a patch:

 https://sourceforge.net/p/cscope/bugs/285/[2]

and I'd like to ask: does it make sense for these bindings to continue
being distributed here? How would yall feel about splitting out that
part of the repository into a separate project, and I can then take on
maintainership of that code. I am a regular user of those bindings, so
this should be a working arrangement.

Thanks

dima

Re: [Cscope-devel] cscope bug (sort of)

[Hans-Bernhard B. <HBB...@t-...>]

On 20.06.2013 01:17, Tom...@l-... wrote:
> I’ve been using cscope for many years now, and love it.
>
> I recently ran into a problem with using cscope on a cifs-mounted
> filesystem (a Windows share).  lstat() did not fail, but returned a
> completely false stat structure.
>
> It turns out that on my Ubuntu system I need to compile cscope with the
> following CFLAGS:
>
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> There are no large files involved, but the inode is bigger than 32 bits,
> which causes all sorts of problems.
>
> I’d fix it myself, but have no idea where this information would go…

The canonical approach would be to put AC_SYS_LARGEFILE into 
configure.in.  Full large file support would require some thorough 
rework of the file position handling, though, which might easily break 
more than it fixes.

[Cscope-devel] [ cscope-Bugs-2873621 ] ``make'' fails on OSX Snow Leopard

[SourceForge.net <no...@so...>]

Bugs item #2873621, was opened at 2009-10-06 11:24
Message generated for change (Comment added) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=2873621&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Curses interface
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Justin M. LaPre (laprej)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: ``make'' fails on OSX Snow Leopard

Initial Comment:
The ``make'' command fails on build.c with the following error:

In file included from build.c:50:
/usr/include/ncurses.h:539:40: error: macro "cbreak" passed 1 arguments, but takes just 0
/usr/include/ncurses.h:564:44: error: macro "erasechar" passed 1 arguments, but takes just 0
/usr/include/ncurses.h:600:43: error: macro "killchar" passed 1 arguments, but takes just 0
make[2]: *** [build.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-12-29 05:44

Message:
Applied patch #2912267

----------------------------------------------------------------------

Comment By: Wim Lewis (wiml)
Date: 2010-03-04 00:52

Message:
The #ifdefs in src/constants.h are incorrectly guessing that osx's ncurses
doesn't have cbreak, erasechar, etc., and are trying to #define
replacements. Patches 2912267 and 2963208 are two (different) fixes for
this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=2873621&group_id=4664

[Cscope-devel] [ cscope-Support Requests-3598837 ] Build fail on OSX

[SourceForge.net <no...@so...>]

Support Requests item #3598837, was opened at 2012-12-29 01:11
Message generated for change (Tracker Item Submitted) made by diegostamigni
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=204664&aid=3598837&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Diego Stamigni (diegostamigni)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fail on OSX

Initial Comment:
While compiling on my Max OSX machine (10.8.2) I'm getting this kind of error:

gcc -DHAVE_CONFIG_H -I. -I..     -g -O2 -MT build.o -MD -MP -MF .deps/build.Tpo -c -o build.o build.c
In file included from build.c:50:
/usr/include/ncurses.h:539:40: error: macro "cbreak" passed 1 arguments, but takes just 0
/usr/include/ncurses.h:564:44: error: macro "erasechar" passed 1 arguments, but takes just 0
/usr/include/ncurses.h:600:43: error: macro "killchar" passed 1 arguments, but takes just 0
make[2]: *** [build.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I've resolved and I'm attaching you my patch for the fix.

Regards,
Diego

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=204664&aid=3598837&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3597850 ] cscope should use /var/tmp, instead of /tmp

[SourceForge.net <no...@so...>]

Feature Requests item #3597850, was opened at 2012-12-20 10:51
Message generated for change (Comment added) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3597850&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Daniel Yek (danieyek)
Assigned to: Nobody/Anonymous (nobody)
Summary: cscope should use /var/tmp, instead of /tmp

Initial Comment:
Fedora 18 Beta was mounting tmpfs on /tmp to, hopefully, reduce disk I/O and extend the life of SSD disks.

Since tmpfs was very limited in size, cscope ran out of space while indexing larger source tree.

I had to use:
  TMPDIR=/var/tmp cscope -b -q -k
to enable cscope to complete its indexing.

I think cscope should consider storing temp files in /var/tmp.

Please visit the following URLs for more information:

https://fedoraproject.org/wiki/Features/tmp-on-tmpfs

https://bugzilla.redhat.com/show_bug.cgi?id=826015

http://0pointer.de/blog/projects/tmp.html

https://fedorahosted.org/fesco/ticket/940


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-12-21 09:40

Message:
I have to refuse the notion that this is a bug.  For starters, /tmp has
been the official place for such files since the dawn of time.  If
distributors decide to break that now, that's their fault, not cscope's.

Second, there already is a simple, effective and documented way to get
around this: cscope respects $TMPDIR.  Case closed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3597850&group_id=4664

[Cscope-devel] [ cscope-Bugs-3597850 ] cscope should use /var/tmp, instead of /tmp

[SourceForge.net <no...@so...>]

Bugs item #3597850, was opened at 2012-12-20 10:51
Message generated for change (Tracker Item Submitted) made by danieyek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3597850&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Yek (danieyek)
Assigned to: Nobody/Anonymous (nobody)
Summary: cscope should use /var/tmp, instead of /tmp

Initial Comment:
Fedora 18 Beta was mounting tmpfs on /tmp to, hopefully, reduce disk I/O and extend the life of SSD disks.

Since tmpfs was very limited in size, cscope ran out of space while indexing larger source tree.

I had to use:
  TMPDIR=/var/tmp cscope -b -q -k
to enable cscope to complete its indexing.

I think cscope should consider storing temp files in /var/tmp.

Please visit the following URLs for more information:

https://fedoraproject.org/wiki/Features/tmp-on-tmpfs

https://bugzilla.redhat.com/show_bug.cgi?id=826015

http://0pointer.de/blog/projects/tmp.html

https://fedorahosted.org/fesco/ticket/940


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3597850&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3596998 ] Cscope with persistent history

[SourceForge.net <no...@so...>]

Feature Requests item #3596998, was opened at 2012-12-17 10:59
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3596998&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cscope with persistent history

Initial Comment:
It would be helpful to have a persistent history for all the 
search terms.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3596998&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3594756 ] EDITOR won't start if it contains arguments

[SourceForge.net <no...@so...>]

Feature Requests item #3594756, was opened at 2012-12-11 03:35
Message generated for change (Comment added) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3594756&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Sebastian Freundt (hroptatyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: EDITOR won't start if it contains arguments

Initial Comment:
Steps to reproduce:
- set EDITOR to some command with argument, e.g. "vim -R"
- enter the linebased interface and select a line
=>
Cannot exec vim -R: No such file or directory
Press the RETURN key to continue: 



----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-12-11 14:21

Message:
$EDITOR is supposed to be the name of a program, not an arbitrary piece of
command line.  The latter would be unwise for safety reasons.

Nor is it really necessary to do this, so this is no bug.  You can just as
well put a little shell script onto your path and point $EDITOR to that,
instead.

Oh, and this is actually a duplicate of
http://sourceforge.net/tracker/index.php?func=detail&aid=1007390&group_id=4664&atid=304664

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3594756&group_id=4664

[Cscope-devel] [ cscope-Bugs-3594756 ] EDITOR won't start if it contains arguments

[SourceForge.net <no...@so...>]

Bugs item #3594756, was opened at 2012-12-11 03:35
Message generated for change (Tracker Item Submitted) made by hroptatyr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3594756&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Linebased interface
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sebastian Freundt (hroptatyr)
Assigned to: Nobody/Anonymous (nobody)
Summary: EDITOR won't start if it contains arguments

Initial Comment:
Steps to reproduce:
- set EDITOR to some command with argument, e.g. "vim -R"
- enter the linebased interface and select a line
=>
Cannot exec vim -R: No such file or directory
Press the RETURN key to continue: 



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3594756&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3587158 ] DOS Style line ending brakes display output

[SourceForge.net <no...@so...>]

Feature Requests item #3587158, was opened at 2012-11-14 08:22
Message generated for change (Comment added) made by bcasavan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Neil Horman (nhorman)
Summary: DOS Style line ending brakes display output

Initial Comment:
DOS Style line ending brakes display output. The match is detected but not displayed. See the attached mock-up source tree. egrep for MYMAP_ the search matches '1' and '2' are not visible, but "operational". A better fix should run the characters of 'tempstring' , if there are non-displayable chars it should still display the file name, function, and line number, but replace the matched text with ellipsis.

Proposed change:
Index: display.c
===================================================================
RCS file: /cvsroot/cscope/cscope/src/display.c,v
retrieving revision 1.33
diff -u -r1.33 display.c
--- display.c	20 May 2012 12:24:17 -0000	1.33
+++ display.c	14 Nov 2012 16:16:00 -0000
@@ -229,6 +229,12 @@
 		       linenum, tempstring) < 4) {
 		break;
 	    }
+	    {
+	    	char *cr = strchr( tempstring, '\r' );
+	    	if( cr ) {
+	    		*cr = 0;
+		}
+	    }
 	    ++nextline;
 	    displine[disprefs] = screenline;
 	

----------------------------------------------------------------------

Comment By: Brent Casavant (bcasavan)
Date: 2012-12-04 15:37

Message:
Sorry for the mangled patch -- I'm kind of new to sourceforge and couldn't
find a better way to include it here.  Just look carefully for the change
of "[^\n]" to "[^\r\n]" just after TEMPSTRING_LEN_STR.  This affects only
the display of the output line -- it doesn't affect the actual underlying
cscope database or other internal representation, so it targets just the
issue in question and nothing more.

----------------------------------------------------------------------

Comment By: Brent Casavant (bcasavan)
Date: 2012-12-04 15:31

Message:
I know this subject has been discussed before, however I too would like to
request that this capability be added.

It is a vital capability to have if a person is doing cross-platform
development that spans UNIX-like and DOS-like systems, where no matter
which end-of-line convention you choose to use in your source files the
display in cscope is mangled.

I have a much simpler patch than the original submitter that I hope can be
considered for inclusion:

diff -ruN cscope-15.8a/src/display.c cscope/src/display.c
--- cscope-15.8a/src/display.c	2012-05-20 07:24:17.000000000 -0500
+++ cscope/src/display.c	2012-12-04 17:17:01.500165190 -0600
@@ -225,7 +225,7 @@
 	     disprefs < mdisprefs && screenline <= lastdispline;
 	     ++disprefs, ++screenline) {
 	    /* read the reference line */
-	    if (fscanf(refsfound, "%" PATHLEN_STR "s%" PATHLEN_STR "s%"
NUMLEN_STR "s %" TEMPSTRING_LEN_STR "[^\n]", file, function, 
+	    if (fscanf(refsfound, "%" PATHLEN_STR "s%" PATHLEN_STR "s%"
NUMLEN_STR "s %" TEMPSTRING_LEN_STR "[^\r\n]", file, function, 
 		       linenum, tempstring) < 4) {
 		break;
 	    }


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3587158 ] DOS Style line ending brakes display output

[SourceForge.net <no...@so...>]

Feature Requests item #3587158, was opened at 2012-11-14 08:22
Message generated for change (Comment added) made by bcasavan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Neil Horman (nhorman)
Summary: DOS Style line ending brakes display output

Initial Comment:
DOS Style line ending brakes display output. The match is detected but not displayed. See the attached mock-up source tree. egrep for MYMAP_ the search matches '1' and '2' are not visible, but "operational". A better fix should run the characters of 'tempstring' , if there are non-displayable chars it should still display the file name, function, and line number, but replace the matched text with ellipsis.

Proposed change:
Index: display.c
===================================================================
RCS file: /cvsroot/cscope/cscope/src/display.c,v
retrieving revision 1.33
diff -u -r1.33 display.c
--- display.c	20 May 2012 12:24:17 -0000	1.33
+++ display.c	14 Nov 2012 16:16:00 -0000
@@ -229,6 +229,12 @@
 		       linenum, tempstring) < 4) {
 		break;
 	    }
+	    {
+	    	char *cr = strchr( tempstring, '\r' );
+	    	if( cr ) {
+	    		*cr = 0;
+		}
+	    }
 	    ++nextline;
 	    displine[disprefs] = screenline;
 	

----------------------------------------------------------------------

Comment By: Brent Casavant (bcasavan)
Date: 2012-12-04 15:31

Message:
I know this subject has been discussed before, however I too would like to
request that this capability be added.

It is a vital capability to have if a person is doing cross-platform
development that spans UNIX-like and DOS-like systems, where no matter
which end-of-line convention you choose to use in your source files the
display in cscope is mangled.

I have a much simpler patch than the original submitter that I hope can be
considered for inclusion:

diff -ruN cscope-15.8a/src/display.c cscope/src/display.c
--- cscope-15.8a/src/display.c	2012-05-20 07:24:17.000000000 -0500
+++ cscope/src/display.c	2012-12-04 17:17:01.500165190 -0600
@@ -225,7 +225,7 @@
 	     disprefs < mdisprefs && screenline <= lastdispline;
 	     ++disprefs, ++screenline) {
 	    /* read the reference line */
-	    if (fscanf(refsfound, "%" PATHLEN_STR "s%" PATHLEN_STR "s%"
NUMLEN_STR "s %" TEMPSTRING_LEN_STR "[^\n]", file, function, 
+	    if (fscanf(refsfound, "%" PATHLEN_STR "s%" PATHLEN_STR "s%"
NUMLEN_STR "s %" TEMPSTRING_LEN_STR "[^\r\n]", file, function, 
 		       linenum, tempstring) < 4) {
 		break;
 	    }


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3587157 ] Add -X command line option to remove the syms file

[SourceForge.net <no...@so...>]

Feature Requests item #3587157, was opened at 2012-11-14 08:14
Message generated for change (Settings changed) made by nhorman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587157&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Neil Horman (nhorman)
Summary: Add -X command line option to remove the syms file

Initial Comment:
Add -X command line option to remove the syms file when cscope exits.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587157&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3587158 ] DOS Style line ending brakes display output

[SourceForge.net <no...@so...>]

Feature Requests item #3587158, was opened at 2012-11-14 08:22
Message generated for change (Settings changed) made by nhorman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Neil Horman (nhorman)
Summary: DOS Style line ending brakes display output

Initial Comment:
DOS Style line ending brakes display output. The match is detected but not displayed. See the attached mock-up source tree. egrep for MYMAP_ the search matches '1' and '2' are not visible, but "operational". A better fix should run the characters of 'tempstring' , if there are non-displayable chars it should still display the file name, function, and line number, but replace the matched text with ellipsis.

Proposed change:
Index: display.c
===================================================================
RCS file: /cvsroot/cscope/cscope/src/display.c,v
retrieving revision 1.33
diff -u -r1.33 display.c
--- display.c	20 May 2012 12:24:17 -0000	1.33
+++ display.c	14 Nov 2012 16:16:00 -0000
@@ -229,6 +229,12 @@
 		       linenum, tempstring) < 4) {
 		break;
 	    }
+	    {
+	    	char *cr = strchr( tempstring, '\r' );
+	    	if( cr ) {
+	    		*cr = 0;
+		}
+	    }
 	    ++nextline;
 	    displine[disprefs] = screenline;
 	

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3587158 ] DOS Style line ending brakes display output

[SourceForge.net <no...@so...>]

Feature Requests item #3587158, was opened at 2012-11-14 08:22
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: DOS Style line ending brakes display output

Initial Comment:
DOS Style line ending brakes display output. The match is detected but not displayed. See the attached mock-up source tree. egrep for MYMAP_ the search matches '1' and '2' are not visible, but "operational". A better fix should run the characters of 'tempstring' , if there are non-displayable chars it should still display the file name, function, and line number, but replace the matched text with ellipsis.

Proposed change:
Index: display.c
===================================================================
RCS file: /cvsroot/cscope/cscope/src/display.c,v
retrieving revision 1.33
diff -u -r1.33 display.c
--- display.c	20 May 2012 12:24:17 -0000	1.33
+++ display.c	14 Nov 2012 16:16:00 -0000
@@ -229,6 +229,12 @@
 		       linenum, tempstring) < 4) {
 		break;
 	    }
+	    {
+	    	char *cr = strchr( tempstring, '\r' );
+	    	if( cr ) {
+	    		*cr = 0;
+		}
+	    }
 	    ++nextline;
 	    displine[disprefs] = screenline;
 	

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587158&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3587157 ] Add -X command line option to remove the syms file

[SourceForge.net <no...@so...>]

Feature Requests item #3587157, was opened at 2012-11-14 08:14
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587157&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add -X command line option to remove the syms file

Initial Comment:
Add -X command line option to remove the syms file when cscope exits.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3587157&group_id=4664

[Cscope-devel] [ cscope-Bugs-2984343 ] c++ namespace key word not supported

[SourceForge.net <no...@so...>]

Bugs item #2984343, was opened at 2010-04-09 00:54
Message generated for change (Comment added) made by progmei
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=2984343&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: C lexer/parser
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Hughes (dwv7j5x690)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: c++ namespace key word not supported

Initial Comment:
If a class is declared inside a namespace then cscope cannot find the declarations of those functions.
Also functions declared in anonymous namespace cscope does not index those functions.

Suggested fix:

x@t60>cvs diff src/fscanner.l
Index: src/fscanner.l
===================================================================
RCS file: /cvsroot/cscope/cscope/src/fscanner.l,v
retrieving revision 1.15
diff -r1.15 fscanner.l
479c479
< class{wsnl}+{identifier}({wsnl}|{identifier}|[():])*\{	{	/* class definition */
---
> ("namespace"|"class"){wsnl}+{identifier}({wsnl}|{identifier}|[():])*\{	{	/* class definition */
487a488,497
> namespace{wsnl}+\{	{	/* anonymous namespace */
> 			classdef = YES;
> 			tagdef =  'c';
> 			yyless(9);		/* eat up 'namespace', and re-scan */
> 			yy_set_bol(0);
> 			goto more;
> 			/* NOTREACHED */
> 		}
> 
> 


A similar change would also be required in src/scanner.l for those who use lex. I don't have a server with lex installed available to test.

----------------------------------------------------------------------

Comment By: progmei (progmei)
Date: 2012-11-14 05:28

Message:
As for the C++ is used more widely, but the C language seems no long
popular. Now most project in our product uses C++, and encourge us to use
the C++ and it's features, such as virtual function, namespace,template,
etc...
I don't think cscope not to completely support C++ is a good idea.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-08-02 14:27

Message:
> There are 3 problems with cscope and c++

That's three you're aware of.  Whereas I'm convinced that this is actually
a bottomless pit, which I refuse to jump into.

People are having a hell of a time getting modern full-featured C++ code to
parse with a lexer and generated parser, plus lots of tacked-on extra
gizmos.  Expecting to do it with a lexer and just a little bit of state
machine on top, like cscope does it, is doomed to disappointment.

So, like I said before, we'll always fail at parsing C++ in some way that
somebody out there will find crucially limiting.  And if we managed to
kinda-sorta parse it, we would be getting flack for the result lacking
enough scoping information (namespaces, template hierarchies, ...) as to be
virtually useless. E.g. a standard STL has members whose names a single one
of, "correctly" displayed, would fill our output window all by themselves. 
This is a fight that cannot be won.  So I won't go there.

----------------------------------------------------------------------

Comment By: Paul Hughes (dwv7j5x690)
Date: 2012-08-01 16:07

Message:

It is disappointing that you are so hostile to C++.  Your project could
have many more users if you made some minor changes.

I even gave you exact code to fix the problem! 

There are 3 problems with cscope and c++

namespaces
functions with namespace specifiers eg function(std::string &arg)
functions with template args eg function(vector<myclass> &arg)

All of which can be fixed with minor changes to fscanner.l and scanner.l

After that cscope works well on my very large (1,000,000+ lines)  c and c++
project.



----------------------------------------------------------------------

Comment By: Jud P (judp)
Date: 2012-08-01 12:52

Message:
Bummer. Disappointing as I think this is the only issue holding back use in
my C++ project. Well thanks for the quick response at least!

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-08-01 11:36

Message:
For this to get fixed, it would have to be broken first.  I don't consider
it to be.  This is still cscope, not c++scope.  cscope will _always_ fail
to parse C++ code in some way --- the syntax of that language is just way
too bizarre for that.

----------------------------------------------------------------------

Comment By: Jud P (judp)
Date: 2012-08-01 11:23

Message:
Any chance this will get fixed? I'd love to start using cscope, but I'm
running into this issue and it makes cscope fairly useless for my project.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=2984343&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-2001356 ] "Find assignments to"

[SourceForge.net <no...@so...>]

Feature Requests item #2001356, was opened at 2008-06-23 18:37
Message generated for change (Comment added) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=2001356&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Find assignments to"

Initial Comment:
In the 13.X branch of cscope there was a "Find assignments to" search item. This mysteriously disappeared in the 15.X branch.

It was a very useful search criteria. For example if there were many instances of symbol "counter", and you did a "Find assignments to: counter", you would only get the following

counter = 55;
int counter = 0;

and you would skip all the declarations, etc. Without this option, you had to do a 2 step process: first, do a "find this symbol", then weed out the non-assignments manually.

Please consider adding this option back.


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-11-09 14:06

Message:
Implemented as of version 15.8

----------------------------------------------------------------------

Comment By: Rolland Santimano (r0lland)
Date: 2011-08-16 22:42

Message:
Umm, I would guess that one of the use cases (if there are more than one)
for "find assignment" would be to track changes to a variable's value,
including init statements.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2011-04-07 17:20

Message:
Putting something back is not possible --- it was never in this branch to
begin with.   That feature must have appeared in 13.x development after
this open-source version was branched off.

Oh, and BTW, it's arguablly incorrect to show "int value=0" in a "find
assignment" search --- that's not an assignment, but an initialization.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-12-21 04:15

Message:
This is a very useful feature and I just don't want to use versions later
than 13.x because of this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=2001356&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3585810 ] Request --exclude like ctags

[SourceForge.net <no...@so...>]

Feature Requests item #3585810, was opened at 2012-11-09 12:09
Message generated for change (Comment added) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3585810&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Grant Mills (gmills)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: Request --exclude like ctags

Initial Comment:
I use cscope & ctags with VIM.  I have started working with larger source trees and would like to exclude patterns, just like I can with ctags.

Ideally, I would think it is acceptable to simply port the functionality from ctags but there may be reasons that's not possible.

I'd be willing to volunteer for this if other saw benefit to it.

----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-11-09 13:54

Message:
I don't see the need for a new option.  Whatever you want to achieve using
--exclude can already be achieved using 'find' to create a cscope.files
list.

There is a fundamental principle governing the design of Unix tools: one
job <--> one tool.  Creating lists of files to do something with is one
job.  The tool that does it is 'find'.  cscope's -R is already a violation
of that principle.  No need to exent that given there's already a much more
powerful option available.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3585810&group_id=4664

[Cscope-devel] [ cscope-Feature Requests-3585810 ] Request --exclude like ctags

[SourceForge.net <no...@so...>]

Feature Requests item #3585810, was opened at 2012-11-09 12:09
Message generated for change (Tracker Item Submitted) made by gmills
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3585810&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Grant Mills (gmills)
Assigned to: Nobody/Anonymous (nobody)
Summary: Request --exclude like ctags

Initial Comment:
I use cscope & ctags with VIM.  I have started working with larger source trees and would like to exclude patterns, just like I can with ctags.

Ideally, I would think it is acceptable to simply port the functionality from ctags but there may be reasons that's not possible.

I'd be willing to volunteer for this if other saw benefit to it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354664&aid=3585810&group_id=4664

[Cscope-devel] [ cscope-Bugs-3584836 ] Linux Build Fails

[SourceForge.net <no...@so...>]

Bugs item #3584836, was opened at 2012-11-06 12:31
Message generated for change (Settings changed) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3584836&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Shayan Es (shayanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linux Build Fails

Initial Comment:
Linux  2.6.32-44-generic-pae #98-Ubuntu SMP Mon Sep 24 17:47:51 UTC 2012 i686 GNU/Linux

Even though the ./configure has no errors, the make command fails:

make  all-recursive
make[1]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a'
Making all in doc
make[2]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a/doc'
Making all in src
make[2]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a/src'
/bin/bash ../ylwrap fscanner.l lex.yy.c fscanner.c -- flex  
gcc -DHAVE_CONFIG_H -I. -I..     -g -O2 -MT fscanner.o -MD -MP -MF .deps/fscanner.Tpo -c -o fscanner.o fscanner.c
In file included from /usr/include/bits/errno.h:25,
                 from /usr/include/errno.h:36,
                 from fscanner.c:21:
/usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
fscanner.c: In function ‘yy_get_next_buffer’:
fscanner.c:31230: error: ‘EINTR’ undeclared (first use in this function)
fscanner.c:31230: error: (Each undeclared identifier is reported only once
fscanner.c:31230: error: for each function it appears in.)
make[2]: *** [fscanner.o] Error 1
make[2]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a'
make: *** [all] Error 2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3584836&group_id=4664

[Cscope-devel] [ cscope-Bugs-3584836 ] Linux Build Fails

[SourceForge.net <no...@so...>]

Bugs item #3584836, was opened at 2012-11-06 12:31
Message generated for change (Tracker Item Submitted) made by shayanb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3584836&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shayan Es (shayanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linux Build Fails

Initial Comment:
Linux  2.6.32-44-generic-pae #98-Ubuntu SMP Mon Sep 24 17:47:51 UTC 2012 i686 GNU/Linux

Even though the ./configure has no errors, the make command fails:

make  all-recursive
make[1]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a'
Making all in doc
make[2]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a/doc'
Making all in src
make[2]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a/src'
/bin/bash ../ylwrap fscanner.l lex.yy.c fscanner.c -- flex  
gcc -DHAVE_CONFIG_H -I. -I..     -g -O2 -MT fscanner.o -MD -MP -MF .deps/fscanner.Tpo -c -o fscanner.o fscanner.c
In file included from /usr/include/bits/errno.h:25,
                 from /usr/include/errno.h:36,
                 from fscanner.c:21:
/usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
fscanner.c: In function ‘yy_get_next_buffer’:
fscanner.c:31230: error: ‘EINTR’ undeclared (first use in this function)
fscanner.c:31230: error: (Each undeclared identifier is reported only once
fscanner.c:31230: error: for each function it appears in.)
make[2]: *** [fscanner.o] Error 1
make[2]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a'
make: *** [all] Error 2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3584836&group_id=4664

[Cscope-devel] [ cscope-Bugs-3555640 ] cscope doesn't search in header files

[SourceForge.net <no...@so...>]

Bugs item #3555640, was opened at 2012-08-09 03:47
Message generated for change (Settings changed) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3555640&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Jerome Reybert (klubad)
Assigned to: Nobody/Anonymous (nobody)
Summary: cscope doesn't search in header files

Initial Comment:
When I create a database, I put both .c and .h files in it. When I want to jump to a function declaration, I would like to have the possibility to choose between the definition in the header file or the implementation in the C file.

Let say I have a simple project:
$ more test.*
::::::::::::::
test.c
::::::::::::::
int test_function() {
  return 0;
}
::::::::::::::
test.h
::::::::::::::
int test_function();

If I build a database with all the files
$ cscope -b

and I search for the test_function definition, the only choice I have is in the C file. Symbol show me well both C and header file, but in a huge project, I can't afford to search in the symbol result.

If I limit database to header file, I don't have any result:
$ cat cscope.files
test.h
$ cscope -b

In bigger projects, definitions are sometimes found in header file (if the function is only defined in header, and not in C file), but I can't reproduce this behaviour in this little example. Here, cscope don't find test_function at all.

Is it a bug or a wanted behaviour to not include header definitions (or only in some obscure circumstances) in database?

----------------------------------------------------------------------

Comment By: Darryl (darrylo)
Date: 2012-08-09 11:06

Message:
Ah, sorry.  The behavior is correct.  You're also getting the terminology
confused:

* The "definition" is the actual C/C++ code that implements your function. 
"Definitions" generally do not occur in header files except in the cases of
inline functions or poorly-organized code.

* The "declaration" is the function prototype that specifies the function
return value, name, and (optionally) the function parameter types.  The
declaration generally does not contain any source code that implements the
function (inline functions are a gray zone, here, and definitions can act
as implicit declarations).  Header files generally contain declarations,
but not definitions.

* What you're asking for is certainly reasonable, but currently does not
exist.  You basically want a way to display both declarations and
definitions, but not symbol usages/references.  There is currently no way
to display only declarations, although cscope does sometimes try to display
declarations first (usually unsuccessfully), when showing symbol usage.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3555640&group_id=4664

[Cscope-devel] [ cscope-Bugs-3572729 ] Error in installing cscope

[SourceForge.net <no...@so...>]

Bugs item #3572729, was opened at 2012-09-28 04:26
Message generated for change (Settings changed) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3572729&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Niraj (nniraj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in installing cscope

Initial Comment:
When I try to run Configure script, I get below error:
$ ./configure
./configure: line 16: $'\r': command not found
./configure: line 31: syntax error near unexpected token `newline'
'/configure: line 31: `     ;;

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-09-28 07:24

Message:
\r stands for the ASCII carriage return character.  By far the most typical
reason for that problem would be that your 'configure' script was generated
by tools using DOS line endings, but you're using it in an environment that
doesn't expect DOS line ends (e.g. Cygwin in binary-mount mode).

As such, this is almost guaranteed to be an issue not with the program
itself, but with the way you acquired or unpacked the source code

----------------------------------------------------------------------

Comment By: Niraj (nniraj)
Date: 2012-09-28 04:30

Message:
I am using cygwin xterm.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3572729&group_id=4664

[Cscope-devel] [ cscope-Bugs-3584572 ] Linux Build Fails

[SourceForge.net <no...@so...>]

Bugs item #3584572, was opened at 2012-11-05 16:42
Message generated for change (Comment added) made by broeker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3584572&group_id=4664

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Shayan Es (shayanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linux Build Fails

Initial Comment:
Linux  2.6.32-44-generic-pae #98-Ubuntu SMP Mon Sep 24 17:47:51 UTC 2012 i686 GNU/Linux

Even though the ./configure has no errors, the make command fails:

make  all-recursive
make[1]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a'
Making all in doc
make[2]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a/doc'
Making all in src
make[2]: Entering directory `/home/shayan/Desktop/cscope/cscope-15.8a/src'
/bin/bash ../ylwrap fscanner.l lex.yy.c fscanner.c -- flex  
gcc -DHAVE_CONFIG_H -I. -I..     -g -O2 -MT fscanner.o -MD -MP -MF .deps/fscanner.Tpo -c -o fscanner.o fscanner.c
In file included from /usr/include/bits/errno.h:25,
                 from /usr/include/errno.h:36,
                 from fscanner.c:21:
/usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
fscanner.c: In function ‘yy_get_next_buffer’:
fscanner.c:31230: error: ‘EINTR’ undeclared (first use in this function)
fscanner.c:31230: error: (Each undeclared identifier is reported only once
fscanner.c:31230: error: for each function it appears in.)
make[2]: *** [fscanner.o] Error 1
make[2]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/shayan/Desktop/cscope/cscope-15.8a'
make: *** [all] Error 2


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2012-11-06 11:43

Message:
This is rather clearly not a problem of cscope.  That's one of your own GCC
/ libc headers not finding some another.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104664&aid=3584572&group_id=4664