This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-06
Channels
- # aws (11)
- # beginners (51)
- # cider (61)
- # cljsrn (37)
- # clojure (51)
- # clojure-spec (5)
- # clojure-uk (6)
- # clojurescript (35)
- # core-async (29)
- # cursive (3)
- # datomic (4)
- # defnpodcast (3)
- # editors (10)
- # emacs (3)
- # fulcro (2)
- # lein-figwheel (9)
- # leiningen (3)
- # mount (3)
- # off-topic (59)
- # parinfer (6)
- # portkey (4)
- # re-frame (6)
- # shadow-cljs (136)
- # spacemacs (1)
- # specter (1)
- # tools-deps (10)
@gonewest818 Quick question - how can we generate the API docs for orchard 0.1? I noticed the CI config has hardcoded master
and I’m not quite certain how to use codox manually.
Let me go back and refresh my memory. I’m using another oss project to provide simpler automation for codox. Initially that wrapper script didn’t handle multiple versions, but I contributed a patch and got it accepted. In theory, with the right version of that script you can enable other branches in CI and they’ll publish to distinct subdirectories of “gh-pages”.
I suspect my next refactor for 0.18 is going to end up being a graphql-like interface for vars 😂 We expose vars differently all over the codebase. Everything should really go centrally through info or metadata, and then have the requested attributes sent back.
It would be useful to have apropos send back line numbers & columns in some cases, to prevent round trips. For tests I have some code which sends an info
for every failed test, so I can build up a vim quickfix buffer, which requires the filename/line/column ahead of time.
tbh, that turned out not to be so slow. But it feels like we should either agree that round-trips are fine, and send back a reference that works with info
in all places OR give the option to grab any of the attributes from info
in results.
I’ve commented a bit on your PR.
> I suspect my next refactor for 0.18 is going to end up being a graphql-like interface for vars 😂 We expose vars differently all over the codebase. Everything should really go centrally through info or metadata, and then have the requested attributes sent back.
Yeah, that’d be nice.
> It would be useful to have apropos send back line numbers & columns in some cases, to prevent round trips. For tests I have some code which sends an info
for every failed test, so I can build up a vim quickfix buffer, which requires the filename/line/column ahead of time.
Perhaps. Roundtrips may or may not be a problem depending on how many of those you need. 🙂
> tbh, that turned out not to be so slow. But it feels like we should either agree that round-trips are fine, and send back a reference that works with info
in all places OR give the option to grab any of the attributes from info
in results.
Yeah, we should decide upon this for sure. I don’t have a strong preference here, but I like the second option a bit more.
Yeah, this definitely needs some checking to see if round-trips are bad or fine. I have used cider over a tenuous double-ssh'd proxy over GSM to another country, so I definitely have sympathy for reducing round trips, and general network chatter.
I'll go over the PR comments soon, just writing backwards compatibility code for cider's apropos, it's rather easy.
I didn’t become so picky about them in a day. You should the code I was writing 15 years ago. 😄 And you won’t see any docs there. 😄 😄 😄
Our project deadlines don't leave much time for documentation, nor do they tend to have much long-term maintenance to warrant it. Docstrings aren't on any mental checklists for me, I actually comb my code before any PR, but docs never get noticed.
Something quite interesting about these changes it that it would allow retest
to be managed by the client.
I'm going to leave the namespace middleware alone for this version, as it touches on clojurescript, which Orchard hasn't made a decision on yet. I would hope that the fact my query is data-based means that it's a piece of cake to port it to cljs.
I was hoping to use that as direct access to running these queries in order to do a test listing buffer which allowed you to run groups of tests together...
That can wait until the next set of snapshots though, I've got some additional functionality to build clients for already.
https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl.clj#L445-L450 took me a moment to notice
> I’m going to leave the namespace middleware alone for this version, as it touches on clojurescript, which Orchard hasn’t made a decision on yet.
Can’t you just update this in cljs-tooling
? Despite the name of the project it’s actually a pure Clojure project that simply inspect the cljs compiler state.
The only reason why I haven’t merged this into orchard yet is that it would add a hard dependency to ClojureScript for orchard
, which might be a bit excessive.
I think I would be replicating the new list functions in cljs-tooling, is that right? I might be wrong.
I can look into that, I will make that a second pass for later, either this weekend or next. I'm starting to run a little short on time, the weather is nice for once in the UK. I do really want this to work for the namespace explorer, as I'm a user of clojurescript, and I have some really neat ideas about things I'd like to try in replant.
I kept pushing this back, because I wanted to add more and more, but eventually I realized how flawed this thinking is. Probably the next 2-3 releases would be much smaller, and ideally just 1-2 months apart.
Makes sense. I think it's easy to fall into the trap of wanting every release to be fireworks, but incremental releases are great too.
Right, so tests all passing on orchard. Only one last thing, the hardest thing in computer science: naming it!
Yeah, that’s true. I’ve been wondering of list-*
should be query/find-*
or something like this. Generally I don’t expect for list
to do any filtering.
I’m writing too much Elisp and I keep forgetting other languages don’t have to prefix everything. 😄
query is sounding good. orchard.query
and vars
feels like a winner, I'm going for namespaces
over nss
though.
@bozhidar how do I manage the required dependency bump between cider-nrepl & orchard, in terms of making the PR?
Commits to orchard
automatically trigger clojar deployments (on successful builds at least). This means you can just add 0.2-SNAPSHOT as a dependency and things should be OK.
@dominicm Btw, maybe you can submit your document for the cider-nrepl
API to cider-nrepl
and we can maintain it there. Thinking about how to best communicate example usages and deprecations I was reminded of it.
I might put it in the wiki for now, having more open push access is useful until it's up to date
toggle-trace-var might be an interesting one to add var-query to. Trace everything private in ns.x.
Trace everything that matches .*!$
in the current namespace (everything that affects state)