Re: darcs patch: initial, very incomplete tags generator (and 16 more)
Hello nr, Saturday, October 14, 2006, 12:30:54 AM, you wrote:
The ultimate goal is to replace hasktags with a tags generator based on GHC-as-a-library.
is this working at this time? how i can download/use it? hasktags is over-simplified utility, having a really parsing alternative to it will be great -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi,
since you both only mention hasktags as an alternative, I
wonder how ghctags relates to :ctags/:etags in ghci?
http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html
Bulat: don't you find the latter more useful than hasktags?
Norman: adding a standalone-tool will be nice, but I hope
that ghctags and :[ce]tags are using the same codebase,
providing the same functionality with different user-level
frontends?
Cheers,
Claus
----- Original Message -----
From: "Bulat Ziganshin"
Hello nr,
Saturday, October 14, 2006, 12:30:54 AM, you wrote:
The ultimate goal is to replace hasktags with a tags generator based on GHC-as-a-library.
is this working at this time? how i can download/use it?
hasktags is over-simplified utility, having a really parsing alternative to it will be great
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hi,
since you both only mention hasktags as an alternative, I wonder how ghctags relates to :ctags/:etags in ghci?
http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html
Doco suggests that this code is just calling hasktags. How would I know for sure?
Norman: adding a standalone-tool will be nice, but I hope that ghctags and :[ce]tags are using the same codebase, providing the same functionality with different user-level frontends?
Once I can get stuff working, I'll see about coupling it into ghci. But at present performance troubles make it unusable. Norman
http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html
Doco suggests that this code is just calling hasktags.
not at all, it is built in to ghci. though I can see that the docs may be somewhat misleading, due to the reference to Section 10.1, which doesn't mention the built-in functionality.. but that reference is only there because of limitations of the current ghci version (all modules must be interpreted, no direct commandline tool to replace that old hasktags). I was sort of hoping you were working on extending that existing functionality, and moving it out of the ghci code itself - given that ghci and "ghc --make" are ideally just two clients of the ghc API, it would make sense to have the tags code in a separate module, and just call on it from within ghci, ghc, and perhaps ghctags. Instead of fiddling with separate makefiles, I'd prefer options to ghc, so that I could say "ghc --make -ctags", just as I can say, in ghci ":ctags". Of course, there are at least two use cases: code browsing, when one just wants the tags, no building, and code development, when one wants to build and keep the tags up to date.
How would I know for sure?
It's been hiding in the sources for a long time, so perhaps most folks have missed it - the relevant posts were http://www.haskell.org/pipermail/cvs-ghc/2005-June/025415.html http://www.haskell.org/pipermail/cvs-ghc/2005-June/025436.html http://www.haskell.org/pipermail/cvs-ghc/2005-June/025495.html http://www.haskell.org/pipermail/cvs-ghc/2005-June/025638.html I seem to recall that Simon did quite a bit of cleaning up of my initial attempts before committing (and later renamed the command to :ctags/:etags, to avoid abbreviation conflict with :type), but it hasn't seen any further work since (so it is great to have you look into things!-). the current state can be found in ghc/compiler/ghci/InteractiveUI.hs (search for "tags"). http://darcs.haskell.org/ghc/compiler/ghci/InteractiveUI.hs hth, Claus
Norman: adding a standalone-tool will be nice, but I hope that ghctags and :[ce]tags are using the same codebase, providing the same functionality with different user-level frontends?
Once I can get stuff working, I'll see about coupling it into ghci. But at present performance troubles make it unusable.
Norman _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hello Claus, Saturday, October 14, 2006, 2:56:49 PM, you wrote:
since you both only mention hasktags as an alternative, I wonder how ghctags relates to :ctags/:etags in ghci?
http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html
Bulat: don't you find the latter more useful than hasktags?
of course not - i'm don't use ghci and moreover it can't compile some of my modules (with foreign export generators, afair) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hello nr,
Saturday, October 14, 2006, 12:30:54 AM, you wrote:
The ultimate goal is to replace hasktags with a tags generator based on GHC-as-a-library.
is this working at this time? how i can download/use it?
It works, but there are two serious problems: 1. Incorrect emacs tags file when source-line directives are used (ctags might be OK). 2. Performance problems make it unusable on large programs. The performance problems appear to be lurking behind the GHC API, and I'm not competent to correct them, so I've asked S&S for help. Once that's out of the way and I can do some real testing, I'll correct the other problems. If you're currently building a compiler, it's in the utils/ghctags directory. If not, I can put source code on the web, though I'd sort of prefer to have the bugs fixed.
hasktags is over-simplified utility, having a really parsing alternative to it will be great
Indeed. Norman
Hello Norman, Sunday, October 15, 2006, 2:38:57 AM, you wrote:
is this working at this time? how i can download/use it?
my pidgin english frequently forces me to write not that i want to say, but that i _can_ say :) i'm sorry, but for me personally at this moment ghc/ctags is not very required because 1) i have my own hasktags-modified which works pretty ok with my personal programming style, and moreover 2) i still have problems with use of vim :) what i exactly want to say is that i realize importance of utility you wrote and greatly support your work seeing this list of patches, i thought that your work is done and asked for some form of full-fledged announce. i will be interested to look at it, but i can wait about various variants of implementing tags tool: 1) i think that simple standalone tool like hasktags will always has room to use because it works faster and allow to process any incomplete/broken files 2) although in general it's better to make separate tool, in case of tags i think it's better to integrate it with ghc. why? first - you will be able to use --make magic of ghc (although i don't know - may be it's also accessible via GHC API). second - i, as typical user, prefer to always have up-to-date tag files. but how this can be accomplished? by tagging on each compilation. in case of standalone tool this means repeating of syntax analysis phase. it will be great to have instead GHC option which refreshes tag files while recompiling changed modules: ghc --make --generate-ctags main.hs and an option to _only_ refresh tag files: ghc --make --only-ctags main.hs 3) about GHCi command - i think it will be better to have command that updates tag files with info about all loaded (interpreted) modules at this moment. together with auto-tagging on standalone compilation, this should allow one to have full up-to-date tags information one more question - can you deal with broken files (i.e. ones that can't be compiled) ? in particular, is the broken module makes unable tagging of all files that depend on it? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (3)
-
Bulat Ziganshin -
Claus Reinke -
Norman Ramsey