Fork me on GitHub

I also didn't realize that the friendly name used in cljdoc.edn also determines the actual URL, so I have a bunch of links that go to blank pages because I was trying to link to the filename instead 😞 I hadn't noticed because some of my filenames do match the friendly name.


I'm getting there, slowly. I know there will be at least one more round of code changes before I actually announce this thing so I hope I'll have the documentation right by then πŸ™‚


Alpha 7 pushed and all the links are now correct! Yay!


Thanks! Please do open an issue if you have some (semi) specific suggestions to make the docs clearer. Doesn’t have to be polished, more about making a note before we all forget about it again :D


I think the main disconnect -- for me -- was that on GitHub, I'd link to /doc/ and I somehow expected that to be magically converted to whatever link cljdoc created for the same file, based on cljdoc.edn... which, after just a little thought, is wildly unrealistic.


@seancorfield but... thats how it works? πŸ˜„ I think I'm misunderstanding something


if you link to any md/adoc file that is also part of your cljdoc.edn those links will automatically be rewritten so that they point to their respective cljdoc counterparts


From what I understood the confusion stemmed from having a different expectation how the URLs are defined (i.e. based on title vs filename) but would be interested to understand if there was something else too


Yeah, I think that's it. I assumed that the cljdoc.edn file would provide a two-way mapping so links to actual doc/ files would be mapped to the URL associated with the "What Ever" name -- what-ever -- but that didn't seem to happen. Should it @martinklepsch?


@seancorfield can you point me to some specific link that you expected to be rewritten? From what I understand this should work but there might be a misunderstanding so it might help to talk about something specific


Hard to say. I took the comment in the docs pretty literally: that rewriting means a link that works on GitHub also works on cljdoc.


So I expected that relative links within the doc/*.md files -- to each other -- would be rewritten to link to the same place in the generated docs on cljdoc itself.


If I had doc/ and it linked to just -- which works on GitHub -- then in the generated docs it would link to /doc/getting-started/result-set-builders per the mapping in cljdoc.edn.


I dug a bit more into this and found a bug that's now fixed in production. Tested it with these changes to the next.jdbc repo:


they're not complete but hopefully helpful enough


In general that "if a link works on github it should work on cljdoc" thing is true and if it isn't, that's a bug πŸ™‚


Nice! Thank you for such a swift fix!


I've done a full regex find'n'replace to fix them all for the next release (rather than take the partial PR). I have more documentation to write (the whole datafy/`nav`/`:schema` thing needs its own page). And, of course, I can only update all the docs when I make a new release πŸ™‚ Alpha 9 contained one tiny bug fix -- and a lot of documentation updates. Alpha 10 will probably be similar, depending on when (if? πŸ™‚ ) I find the next bug!


and (unrelatedly) that you can use [[with-transaction]] to link to other vars in docstrings like this one:


(for other namespaces the sym needs to be fully qualified)


Yeah, I haven't started using WikiLinks in docstrings yet. That's on my list, now that I have cljdoc mostly under my belt πŸ™‚


And good to know re: local building... I will check that out tomorrow!


Being able to run cljdoc locally and importing a project -- wonderful! Thanks for pointing me at that!


have you been using branch names as revisions? I had some weird issue with that yesterday so curious if you tried that and if it worked for you


It looks like (all?) attempts to build cljdoc for yetibot fail during API import due to Too long with no output (exceeded 10m0s).


Hey @UETBU4DT6β€” I've sent @U066S8QGH a message about this: [...] for Yetibot I think the issue might be that some thread pools are started in the background. There seems to be some dirigiste / manifold stuff β€” if you want to look into it I'd suggest you look out for that kind of stuff To test stuff you can clone this repo: make sure you check out the cljs-proper branch and then run clj -Sdeps '{:deps {yetibot {:mvn/version "0.5.18"}}}' -m codox.main clojure yetibot-0.5.18.jar with a version that you've installed into your local maven


Happy to help with this but wanted to wait of Trevor has some ideas where those threads might be coming from