I have tried the local hoogle when playing with Reflex, and that's pretty nice. But it would be so much better to have text editor support for jumping to the code. Maybe I want text editor support for hoogle.
I don't know of any haskell tooling that will fetch sources for you. Not like how java has the pretty widely accepted pattern of putting source jars in maven.
Works pretty well. With 4500 dependencies it takes about four seconds on my machine to re-run the derivation for all packages with everything cached. Of course you could generate dependency tags only when they change and do only the local source on save.
The problem is that ctags isn't smart enough to know what definition I actually want to look up. If I look up show, it finds hundreds of instances of show to show me. It doesn't do type inference, figure out exactly what type's show instance I want, then go to that source code. Of course I never expected ctags to be able to do this. Maybe what I want next is the ability to fuzzy-find within a ctags lookup when there are many options.
Yeah, I want fzf within the tag disambiguation interface. I already have fzf for searching through all tags, via fzf.kak, but not for searching through the different options at the other end of the tag.
I miss all of the shininess in spacemacs though. I need to recreate kakoune interactions (theres multicursors and a modal editing lib) in emacs so I can have the best of both worlds. :slight_smile:
Yeah, I want fzf within the tag disambiguation interface. I already have fzf for searching through all tags, via fzf.kak, but not for searching through the different options at the other end of the tag.
:Tags show does give you that functionality, unless I'm misunderstanding something
@Torsten Schmits I now use thax-generated tags hundreds of times a day. Thanks again for making it! I can use the same shortcut to jump to my own source code or to the source code of any Haskell function I use.
Well my only annoyance is that to update the tags from my own project I need to run the whole tag process again, which takes around 30 seconds, so I avoid doing it too often, and so I can't look up my recently written functions.
30 seconds seems steep, for me it takes about 5 seconds. is your dependency tree that huge? I think that the project I've just tested it on is reasonably large. is that an SSD?
I haven't tried to keep the dependency tree small, so it probably is pretty huge, though I don't have Pandoc at least. It does take at least 25 seconds, every time, and yes this is on an SSD. The tags file is 23M.
So I guess I need my projectTags target to not include my own package, so I can run hasktags on my project without needing to compile it. I have it set up in my default.nix like this:
Yeah, it's compiling Haskell, because I gave the list of targets as a list containing only my package. Otherwise I would need to manually specify all of my dependencies.
that's the intended way to use it, but it should not build the package. are you sure there's nothing else that could cause this? the tool only looks at the derivation's attributes to get the sources and dependencies.
It looks like it does build the package even in a simple test with nothing changed after a cabal init except the addition of your default.nix from above:
λ ~/src/test/ time nix-build -A projectTags
these derivations will be built:
/nix/store/q4ci8784lmp9ic4nysf0hyxj0dvngww7-test-0.1.0.0-tags.drv
/nix/store/3k1bqhlk2w2l8jhqzbz9gx1yiqbdaa4y-project-tags.drv
building '/nix/store/q4ci8784lmp9ic4nysf0hyxj0dvngww7-test-0.1.0.0-tags.drv'...
unpacking sources
unpacking source archive /nix/store/3frh2am7mzdk3qgshmlsy26c4hfnnryp-test
source root is test
building
building '/nix/store/3k1bqhlk2w2l8jhqzbz9gx1yiqbdaa4y-project-tags.drv'...
building
/nix/store/hyvqvkaya51kfsbj7cla5vb64jqjfprx-project-tags
nix-build -A projectTags 1.31s user 0.18s system 8% cpu 17.193 total
λ ~/src/test/ nix-build --version
nix-build (Nix) 2.3.3
λ ~/src/test/ cabal --version
cabal-install version 3.0.0.0
compiled using version 3.0.0.0 of the Cabal library
λ ~/src/test/ time nix-build -A projectTags
these derivations will be built:
/nix/store/ny62bvn7b5g35m6j5h821098h7fala3a-test-0.1.0.0-tags.drv
/nix/store/v6dvswnhb0ydpcifv2nskl7balp76wzg-project-tags.drv
building '/nix/store/ny62bvn7b5g35m6j5h821098h7fala3a-test-0.1.0.0-tags.drv'...
unpacking sources
unpacking source archive /nix/store/h44kigiqmvsir82iwb3bv0pmrdji9m2s-test
source root is test
building
building '/nix/store/v6dvswnhb0ydpcifv2nskl7balp76wzg-project-tags.drv'...
building
/nix/store/3jzlz7hnmmjsa7jmgqk9ij4gfrac67vj-project-tags
nix-build -A projectTags 1.38s user 0.18s system 8% cpu 18.188 total
λ ~/src/test/ time nix-build -A projectTags
these derivations will be built:
/nix/store/vyfcwyfia4n3r9f1sgmmlfbpbpzj44h2-test-0.1.0.0-tags.drv
/nix/store/bk2fhhysakxazy809xcflxjzwgpss32c-project-tags.drv
building '/nix/store/vyfcwyfia4n3r9f1sgmmlfbpbpzj44h2-test-0.1.0.0-tags.drv'...
unpacking sources
unpacking source archive /nix/store/9ydv2j4yh0ng79gj7w4qpyf2g9y3m67k-test
source root is test
building
building '/nix/store/bk2fhhysakxazy809xcflxjzwgpss32c-project-tags.drv'...
building
/nix/store/xlg4fr4kf0v0x275z6fkml8q10hyvpni-project-tags
nix-build -A projectTags 1.33s user 0.17s system 8% cpu 16.877 total
λ ~/src/test/ time nix-build -A projectTags
these derivations will be built:
/nix/store/a0xhi7b18wlmwn33njxdbr2sm4dsmakx-test-0.1.0.0-tags.drv
building '/nix/store/a0xhi7b18wlmwn33njxdbr2sm4dsmakx-test-0.1.0.0-tags.drv'...
unpacking sources
unpacking source archive /nix/store/b510xvfch2lygwv72m2skl2cilrkjprz-test
source root is test
building
/nix/store/xwnps3ydyml8g5ycq13b1sn5m3k960fj-test-0.1.0.0-tags
nix-build -A projectTags 1.26s user 0.18s system 13% cpu 10.618 total
λ ~/src/test/ time nix-build -A projectTags
these derivations will be built:
/nix/store/p1lw7lzlh50sbaxgs5dr48748mdqkpsf-test-0.1.0.0-tags.drv
building '/nix/store/p1lw7lzlh50sbaxgs5dr48748mdqkpsf-test-0.1.0.0-tags.drv'...
unpacking sources
unpacking source archive /nix/store/cmhw5hk4c3rvz6i67xbw643il54xifdw-test
source root is test
building
/nix/store/y534ck4pd40bzw3i2k3z111j6ji1c7a5-test-0.1.0.0-tags
nix-build -A projectTags 1.27s user 0.17s system 16% cpu 8.761 total
I'm wondering whether the result symlink to the built package is part of the hashed package, so because it changes every time, the resultant package's hash changes every time...
does anyone have a setup for generating ctags for the entire dependency tree when using nix in some way? like codex does for stack projects
i do this:
hasktags **/*.hs
. not nix specific, but works OKyou mean for the local files in the project?
I just have
hasktags
, but yeah that's only for files in the project. Would be amazing to have ctags for the whole dependency tree.How would hasktags work there since you wont necessarily have the source around? Tried the local hoogle for a nix haskell env?
The project specific hoogle is pretty rad, modulo the shitty broken file links to the nix store.
I have tried the local hoogle when playing with Reflex, and that's pretty nice. But it would be so much better to have text editor support for jumping to the code. Maybe I want text editor support for hoogle.
I would be happy to have the source around... but I guess nix doesn't keep it in the package?
It would only be in the nix store if you built from source. If you got a cached version, your machine would never see the source.
I don't know of any haskell tooling that will fetch sources for you. Not like how java has the pretty widely accepted pattern of putting source jars in maven.
Other than cabal fetch/unpack, ofc, but that's no where near automated for a whole project.
It feels like it should be another flag to the nix haskell package library, like
doBenchmark
anddontCheck
:includeSources
maybe
keepSource
Source derivations are much deeper in the nix space than just the haskell library.
Would still be lovely though if you could get to the source locally from hoogle.
I built something for generating tags:
https://github.com/tek/thax
Works pretty well. With 4500 dependencies it takes about four seconds on my machine to re-run the derivation for all packages with everything cached. Of course you could generate dependency tags only when they change and do only the local source on save.
Suggestions appreciated!
@Torsten Schmits Awesome! Works for me. Thanks :)
That looks like an awesome thing to build into a lorri setup so that it's always there in direnv.
/me adds lorri to his list of things to play with
My problem now is that there are too many ctags. E.g. following a tag for
Parser
gets me 22 results to sort through.rip
Alex Chapman said:
as opposed to what? having no dependency tags or using a different tool like codex?
The problem is that ctags isn't smart enough to know what definition I actually want to look up. If I look up
show
, it finds hundreds of instances ofshow
to show me. It doesn't do type inference, figure out exactly what type'sshow
instance I want, then go to that source code. Of course I never expected ctags to be able to do this. Maybe what I want next is the ability to fuzzy-find within a ctags lookup when there are many options.fzf ftw
Yeah, I want fzf within the tag disambiguation interface. I already have fzf for searching through all tags, via fzf.kak, but not for searching through the different options at the other end of the tag.
Kakoune :heart:
Kakoune is the best thing since sliced vim :)
I miss all of the shininess in spacemacs though. I need to recreate kakoune interactions (theres multicursors and a modal editing lib) in emacs so I can have the best of both worlds. :slight_smile:
Alex Chapman said:
Your problem is that all our language servers are crap :slight_smile:
Alex Chapman said:
:Tags show
does give you that functionality, unless I'm misunderstanding somethingWhich editor is that in?
oh right, it's vim
with the plugin
fzf-vim
I guess I need to do some tinkering with my kakrc
ah, you're using Kakoune as your primary editor
how's the mileage?
did you use vim before?
It's awesome. I did use vim previously. I find that kakoune is to vim as vim is to all other editors, in terms of the editing language.
ugh crap. I don't want to spend the next six months migrating my shit to a new editor :smiley:
how do you write plugins in kakoune? like rplugins in neovim
I haven't written my own, but from what I can tell it's mostly about hooking shell commands into the editor. E.g: https://github.com/andreyorst/fzf.kak/blob/master/rc/fzf.kak
looks like there is no support for plugins running in a subprocess with RPC, right?
I don't know. There's support for connecting to an lsp server, if that helps?
nope! :laughter_tears:
@Torsten Schmits I now use thax-generated tags hundreds of times a day. Thanks again for making it! I can use the same shortcut to jump to my own source code or to the source code of any Haskell function I use.
@Alex Chapman that's wonderful! any suggestions for improvements?
I'm quite unhappy with the store hash in the path, but that's more of a presentation problem, (neo)vim's tag menu is not very configurable
Well my only annoyance is that to update the tags from my own project I need to run the whole tag process again, which takes around 30 seconds, so I avoid doing it too often, and so I can't look up my recently written functions.
30 seconds seems steep, for me it takes about 5 seconds. is your dependency tree that huge? I think that the project I've just tested it on is reasonably large. is that an SSD?
I trigger it whenever I save
I haven't tried to keep the dependency tree small, so it probably is pretty huge, though I don't have Pandoc at least. It does take at least 25 seconds, every time, and yes this is on an SSD. The
tags
file is 23M.hm, my tags file is 32M…what's your cpu?
wonder how we could profile this
https://ark.intel.com/content/www/us/en/ark/products/97496/intel-core-i7-7820hq-processor-8m-cache-up-to-3-90-ghz.html
when you run the derivation, do the 30 seconds pass entirely while nix is evaluating, or does it output what it is tagging?
Oh, it looks like the majority of the time is spent building my project. If I don't change any of my files then it only takes 3.7s.
So I guess I need my projectTags target to not include my own package, so I can run hasktags on my project without needing to compile it. I have it set up in my
default.nix
like this:Is there a way I can turn
pkg
into a list of its dependencies, without including itself?by "building my project", do you mean compiling haskell?
if so, that's wrong, it should only copy the sources and look at the nix deps, not realise the derivation
the optimal case should be that hasktags is run on the current directory and the dep tree is checked for changes by nix
Yeah, it's compiling Haskell, because I gave the list of targets as a list containing only my package. Otherwise I would need to manually specify all of my dependencies.
that's the intended way to use it, but it should not build the package. are you sure there's nothing else that could cause this? the tool only looks at the derivation's attributes to get the sources and dependencies.
so I tested it like this:
and the project isn't compiled when I run
:shrug:
maybe try this
default.nix
with a.cabal
file and one source file and see what happens, so that we can be sure it's not something externalIt looks like it does build the package even in a simple test with nothing changed after a
cabal init
except the addition of yourdefault.nix
from above:I'm not supposed to run it from within
nix-shell
am I?(doing so doesn't seem to help)
how do you figure it is built? there's no output referencing any haskell files
well, that's the tags derivation
Oh, I see. Well then why is it slow? :/
good question!
is it also slow if you use
combined.packages
?Where should I use that? In the targets list?
Why do all the hashes change despite me not changing anything?
projectTags = tags.combined.packages { targets = [xyz]; }
Alex Chapman said:
yeah that is worrying
Faster with
combined.packages
:I see now, this also happens for me, but only in the project where the package is in the root dir
I'm wondering whether the
result
symlink to the built package is part of the hashed package, so because it changes every time, the resultant package's hash changes every time...right, try it with
--no-link
yup, that fixes it for me
Yeah, much faster after the first build.
how do you integrate the generated file? do you not use the command from the readme?
I use
cp $(nix-build --no-link -A projectTags)/tags tags
So now if I change
Main.hs
, it takes longer to build again, ~10s, then back to ~2s on the next run.Which would suggest it's compiling the package.
10s is reasonable
since it's checking all the dependencies again
but you could use
combined.packages
and then manually merge it with the file for the deps that can be generated withcombined.deps
I call it in the background from vim whenever I hit my "save all" mapping, so I don't really notice that there's a delay
but if that's not your workflow, we can come up with something for the tool that's accomodating
Oh ok, I was thinking that yours took ~5s regardless.
Running it in the background would be fine, let me see if I can get kakoune to do that...
well it's not taking 30 seconds, more like 8
the project I've tested this on has its source files split across 14 packages, so not everything is retagged on every save
maybe run hasktags manually to see how long that takes
0.1s
(on just my own source files)
then it's just nix
right, my deps are also split, so the subtree that's examined on a change is smaller, maybe that's a reason
I'll try to think of some way to avoid the deep dependency rechecking