Re: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]
[Redirected to cygwin-apps] On Dec 11 14:05, Thrall, Bryan wrote: Alan Thompson wrote on 2012-12-11: Looking at the link on StackOverflow (from 2010) it may be that the xemacs version of ctags is overwriting the default version in /bin. Could this be the culprit? Yes, it looks like xemacs-tags and ctags packages both install /usr/bin/ctags.exe: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=ctags.exe Oh boy, how long do we have this collisions? For years, it seems. FWIW, I'd prefer to keep Exuberant ctags since that's what is part of most Linux installations as well. Volker, would you mind a lot to obsolete the xemacs-tags package in favor of the ctags package? Thanks, Corinna On Tue, Dec 11, 2012 at 11:55 AM, Alan Thompson ... wrote: Hi - Yes, I'm sure: find /bin -name '*tags*' | xargs ls -ldF -rwxr-xr-x 1 alathompson Domain Users 85504 Jan 31 2009 /bin/ctags.exe* -rwxr-xr-x 1 alathompson Domain Users 83968 Jan 31 2009 /bin/etags.exe* -rwxr-xr-x 1 alathompson Domain Users 5411 Dec 21 2011 /bin/ocamltags* -rwxr-xr-x 1 alathompson Domain Users 68608 Jan 31 2009 /bin/ootags.exe* ls -ldF /bin/ls /bin/vim /bin/gcc lrwxrwxrwx 1 alathompson Domain Users 21 Oct 18 12:20 /bin/gcc - /etc/alternatives/gcc* -rwxr-xr-x 1 alathompson Domain Users 101902 Feb 6 2012 /bin/ls* lrwxrwxrwx 1 alathompson Domain Users 21 Oct 18 12:48 /bin/vim - /etc/alternatives/vim* uname -a CYGWIN_NT-6.1-WOW64 ALAN-THO-LAP 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin One can see from the timestamp on the links for gcc and vim that I installed Cygwin on 10/18/2012. However, it seems that both ctags and etags are old versions of the program (circa 2007) and are not the Exuberant Ctags version. However, the GNU documentation here: http://directory.fsf.org/wiki/Exuberant_Ctags clearly lists the Exuberant Ctags, although it has only been updated as of 2004. However, looking here: http://cygwin.com/packages/ctags/ctags-5.8-1-src we see that cygwin has Exuberant Ctags 5.8. Perhaps it is just a packaging issue that caused the old one to be present and Exuberant Ctags 5.8 to be not present? You can see from this thread: http://stackoverflow.com/questions/2634001/any-idea-why-ctags-wont- recurse-on-cygwin/13810472#13810472 that I'm not the only one who stumbled onto this problem. Where should we go from here? Could it just be a packaging problem? Alan Thompson On Tue, Dec 11, 2012 at 11:24 AM, Thrall, Bryan ... wrote: Are you sure you're using the ctags you think you are? $ ctags --help Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert Compiled: Dec 11 2009, 11:42:40 Addresses: dhieb...@users.sourceforge.net, http://ctags.sourceforge.net Optional compiled features: +wildcards, +regex, +internal-sort Usage: ctags [options] [file(s)] snip -R Equivalent to --recurse. snip Hope this helps! -- Bryan Thrall
Re: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]
On 12/12/2012 02:39, Corinna Vinschen wrote: Oh boy, how long do we have this collisions? For years, it seems. There must be a database of package contents behind the packages search engine on sourceware. If someone that has access to that DB extracts a raw list of file names, this command will find the other duplicates: grep -o '/[a-z0-9]+\.exe$' filelist | sort | uniq -d Some will be harmless, like the two ksh.exe versions. But, maybe something interesting will turn up. Volker, would you mind a lot to obsolete the xemacs-tags package in favor of the ctags package? As long as Exuberant Ctags is a complete superset of the functionality in xemacs-tags, this seems like a good idea. Anything that depends on xemacs-tags can depend on the ctags package instead.
Re: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]
On 12/12/2012 10:39, Corinna Vinschen wrote: Oh boy, how long do we have this collisions? For years, it seems. I request a feature to detect package collision, and furthermore suggest which package to install when an user tries to run a program which is not installed but is available from a package. Such feature has been implemented in Ubuntu, for example: https://blueprints.launchpad.net/ubuntu/+spec/command-not-found-magic
RE: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]
Jari Aalto wrote on 2012-12-12: On 2012-12-12 15:48, Aaron Schneider wrote: | On 12/12/2012 10:39, Corinna Vinschen wrote: | Oh boy, how long do we have this collisions? For years, it seems. | | I request a feature to detect package collision, and furthermore | suggest which package to install when an user tries to run a program | which is not installed but is available from a package. This helps: $ cygcheck --help ... -f, --find-package find the package to which FILE belongs $ cygcheck -f /usr/bin/ls coreutils-8.15-1 That only works on files whose package is installed, unfortunately. http://www.cygwin.com/packages is the tool to use for this. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com
Re: [RFU][1.3.9-2] pv
On 10/12/2012 20:15, Corinna Vinschen wrote: Cygwin supports mmap for a long time. However, I'm puzzled why using POSIX message queues should be more work than implementing the message transport from scratch. This sounds much more error prone than using an existing mechanism. I have never used POSIX message queues, and that would only give me -R in any case, since I would still either need shared memory or a new positioning algorithm for -c. Instead, I would open a lock file and use that to co-ordinate which PV is the first one and where the top Y co-ordinate is. I might not even need mmap() at all. So long as I'm using lock files for the terminal anyway, it seems that I might as well also use them for the rest of -c and -R. So this is why I think it would be easier to use lock files and/or mmap than trying to use message queues.
Re: ctags recursion broken? [ATTN: ctags, xemacs-tags maintainers]
Corinna Vinschen writes: Volker, would you mind a lot to obsolete the xemacs-tags package in favor of the ctags package? I will have a look on the weekend, Thanks, Corinna Ciao Volker
