This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-15
Channels
- # 100-days-of-code (3)
- # announcements (14)
- # beginners (100)
- # calva (20)
- # cider (50)
- # cljdoc (29)
- # cljs-dev (6)
- # clojure (78)
- # clojure-europe (1)
- # clojure-italy (8)
- # clojure-losangeles (1)
- # clojure-nl (11)
- # clojure-uk (108)
- # clojurescript (23)
- # code-reviews (5)
- # cursive (7)
- # datomic (11)
- # devops (1)
- # editors (1)
- # figwheel-main (65)
- # fulcro (114)
- # hoplon (31)
- # hyperfiddle (1)
- # juxt (4)
- # lein-figwheel (2)
- # nrepl (13)
- # off-topic (72)
- # re-frame (35)
- # reagent (9)
- # shadow-cljs (42)
- # spacemacs (2)
- # specter (5)
- # tools-deps (60)
- # yada (2)
@martinklepsch looks like it is possible to retrieve these libs https://dev.clojure.org/jira/browse/TDEPS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50308#comment-50308 unfortunately I'm behind a proxy at the moment so I can't test it reliably
Yeah I saw Alex’s updates and will take another look today. I was surprised though since we both seemed to reproduce this fairly reliably IIRC
Issue is within cljdoc 😓
Hi everyone, I'd like to work on https://github.com/cljdoc/cljdoc/issues/32 . What I learned so far is the server code is using pedestal to build the urls. Is it recommended to get familiar with the library before jumping into the issue?
Hey Daw-Ran, happy to see you'd like to contribute 🙂 For this issue the routing part actually isn't that important I would say but you should have a basic understanding of how interceptors work with pedestal: http://pedestal.io/reference/interceptors
It can also help to take a look at Pedestal's default not-found interceptor: https://github.com/pedestal/pedestal/blob/09dd88c4ce7f89c7fbb7a398077eb970b3785d2d/service/src/io/pedestal/http.clj#L93 and how it is used in Pedestal itself
You might notice that you can also pass a custom not found interceptor to Pedestal's default-interceptors
function (it's in the same namespace).
We use this function in cljdoc so a good start might be to get up and running and make use of the option to supply a custom not found interceptor.
Would be happy to work through it together if you get stuck. Just let me know ✌️
oh and thanks again for the documentation fix 😊
Awesome! Appreciate your guidance. I'll start by understanding the interceptors. 🙂

@martinklepsch hello, I just had an idea, do you think would be feasable to add specs information to cljdoc? for example in Pathom I have a good number of functions that have specs for it (using s/fdef
), I think could be useful to present these spec information with the docs for the fns, not sure how hard to get that in
This would be excellent of course. There are still some issues with the current Clojure.spec implementation that make this nontrivial unfortunately https://github.com/cljdoc/cljdoc/issues/67
I think we could fork clojure.spec and somehow enable this but it’s obviously not a very nice solution
yeah, I actually have done some inspection work in the past, but its not super reliable, I put some in a lib: https://github.com/wilkerlucio/spec-inspec it might be broken at this point
but it did some helpful things, like proper follow back the attribute definition chain (when you make a spec pointing to another one)
The issue is that we need to be able to tell which artifact a spec belongs to in order to store it in a database conflict free
yeah, and I can imagine a few complication cases, for example, spec lets (by design) you add specs to things that you don't own
Yeah that’s useful although I guess we would have to implement those things separately anyways since our data wouldn’t be in a runtime 🙂
so, imagine that I get a lib and add a spec for a fn of a third part library in my library
then the library adds its own spec for it, then how to know which one to keep?
actually, keep from the one that owns it, hehe, if you can easely detect it 😛
Since we only depend on the artifact under analysis you could (optimistically) assume that none of its dependencies modify this kind of Stuff
I need to update this issue though, i feel like it’s not properly describing the issue very well
But yeah, specs would be huge and we could do all kinds of cool stuff with them
yeah, it's exciting to think about the possibilities 🙂
This would be excellent of course. There are still some issues with the current Clojure.spec implementation that make this nontrivial unfortunately https://github.com/cljdoc/cljdoc/issues/67