This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-23
Channels
- # 100-days-of-code (1)
- # adventofcode (13)
- # aleph (1)
- # beginners (48)
- # boot (10)
- # calva (52)
- # cider (18)
- # cljsrn (23)
- # clojure (68)
- # clojure-uk (9)
- # clojurescript (5)
- # cursive (3)
- # datomic (4)
- # figwheel (7)
- # fulcro (14)
- # hoplon (2)
- # leiningen (5)
- # lumo (3)
- # off-topic (87)
- # overtone (5)
- # reitit (5)
- # rum (8)
- # shadow-cljs (7)
- # spacemacs (15)
I now see how the wiki page tricked you, @slipset. What I mean was to Run Build Task… in VS Code and select npm: watch
. So that colon is missing, but even so it is very confusing.
I now configured a default build task instead and changed the instructions to reflect it. Also moved the instructions to the README.md of calva-lib. Also added a LICENSE file to keep @mseddon’s clients happy. 😄
I think I overestimated the age of Calva in the LICENSE file, coming to think about it. Time flies, but not that fast. Calva has yet to celebrate its first birthday.
Has anyone used Github projects? I’m looking at https://github.com/orgs/BetterThanTomorrow/projects and it seems to come with so much ceremony. But maybe we could use just a little of it… I mainly want something where we can keep track of things needed to do and maybe things we would like to do as well. Maintaining a todo-list on one of the repos doesn’t seem right, because I’d like to see a broader picture.
So now we have a basic kanban board, linked to all the repos. However I think only members of BetterThanTomorrow can see it.
there: https://github.com/orgs/BetterThanTomorrow/projects/1, world readable, now
@slipset, I like how you have untangled things in your branch. Are you going to do something more with it or should I try to make things work again from where it is now?
Also, I’d suggest passing the atom
*results
from as high up in the call chain as possible. That way you can have a handle to it and inspect it while running the nrepl-client
Strange… or maybe you are also using Calva Paredit. I really should make it use calva-fmt for its formatting.
ie, is all data that’s relevant for a command contained in the decoded-messages
which are passed to handle-data
or is handle-data
called multiple times for one command?
I think it would be nice to write something about the protocol as comments in this file.
A thing to maybe keep in mind is that for some messages we will want to invoke the callback several times. Like when running tests, for instance (maybe that is the only case, idk).
But I’m looking at it from your code now, so am not sure about it. Maybe it was just a defensive thing to do.
hmm, but then you should probably start out by checking if id
is present in @results*
As you might see, I don’t like overly defensive code. I’d rather it blow up in a spectacular fashion when the invariants don’t hold.
Those id:s is what I added in this change so the when-let around the callback might be a left-over.
I am not fond of defensive code either. Thinking things might have blown up for me so I added a guard, but I do not recall.
If there is an id, there will also be a callback,
(defn send! [write-fn! *results message callback]
(let [id (str (random-uuid))]
(swap! *results assoc id {:id id
:callback callback
:message message
:results []})
`
so you are right about not needing to guard against it. (It indeed is just a left over from when there were no id.)I’ve almost got your refactorings working now, @slipset. There is something tripping up the creation of the CLJS repl, and I just can’t figure out why. The current code is here, if someone wants to check it out: https://github.com/BetterThanTomorrow/calva-lib/blob/1678198fcc5b45493d90e19c8f57a3a8ea755bf8/src/calva/repl/client.cljs#L38