This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-22
Channels
- # announcements (1)
- # beginners (179)
- # boot (8)
- # calva (3)
- # cider (4)
- # clara (3)
- # cljdoc (31)
- # clojure (9)
- # clojure-austin (1)
- # clojure-chicago (5)
- # clojure-dev (19)
- # clojure-nl (2)
- # clojure-uk (1)
- # clojurescript (13)
- # core-matrix (1)
- # cursive (86)
- # datascript (2)
- # datomic (13)
- # emacs (3)
- # figwheel-main (1)
- # fulcro (66)
- # off-topic (250)
- # pathom (7)
- # re-frame (19)
- # reitit (5)
- # sql (37)
- # uncomplicate (5)
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!
cljdoc is a very nice piece of work @martinklepsch -- thank you! https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-alpha7/doc/readme
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/some-thing.md
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/whatever.md
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/getting-started.md
and it linked to just rs-builders.md
-- 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: https://github.com/seancorfield/next-jdbc/compare/master...martinklepsch:cljdoc-fixes?expand=1
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!
sounds great!
Note that you can also build docs locally for previewing: https://github.com/cljdoc/cljdoc/blob/master/doc/running-cljdoc-locally.md#importing-a-project-from-local-sources
and (unrelatedly) that you can use [[with-transaction]]
to link to other vars in docstrings like this one: https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-alpha7/api/next.jdbc#transact
(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!
Glad it helps
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 https://cljdoc.org/builds/12702 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: https://github.com/cljdoc/codox/tree/cljs-proper/codox 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