Fork me on GitHub
#calva
<
2018-12-23
>
pez11:12:41

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.

pez11:12:05

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. 😄

pez11:12:21

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.

pez11:12:34

Reminder to us: We need to also add a LICENSE file to calva-fmt.

pez11:12:22

What’s a good, and EXTREMELY light weight, way to keep a common list of things TODO?

pez11:12:10

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.

mseddon12:12:08

perhaps a trello board or similar?

pez12:12:35

Not lightweight enough, IMO. And people will need to sign up on yet another service.

mseddon13:12:42

yeah always true.

mseddon13:12:53

oh. look, it's simple.

mseddon13:12:03

So now we have a basic kanban board, linked to all the repos. However I think only members of BetterThanTomorrow can see it.

mseddon13:12:03

ah, yeah, I can make that public if you want

pez13:12:47

Awesome.

pez13:12:00

@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?

slipset13:12:09

Can’t promise anything :)

slipset13:12:28

One thing that I thought about last night was

slipset13:12:11

not returning a client from create unless connected? was true.

slipset13:12:41

pushed now

slipset13:12:55

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

pez13:12:24

Pushed where? The git tells me I am up to date with your example-refactorings.

slipset13:12:50

git was hanging 😞

slipset13:12:15

internet seems somewhat unstable…

pez13:12:48

Resilient, but unstable. 😃

pez13:12:59

Our editors seem to be in disagreement about the indentation, are you using Calva?

slipset13:12:25

I’m using calva 🙂

pez14:12:36

Strange… or maybe you are also using Calva Paredit. I really should make it use calva-fmt for its formatting.

slipset14:12:06

I’m using Calva Paredit, yes

slipset14:12:29

I’m not very happy with the handle-data/`do-receive` thingy

slipset14:12:54

Too much stuff happening at the same time, and I also don’t know the protocol there.

slipset14:12:48

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?

slipset14:12:49

I think it would be nice to write something about the protocol as comments in this file.

pez14:12:53

It might take a few decodes to collect all relevant data.

pez14:12:13

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).

slipset14:12:16

callback will always be present right?

slipset14:12:28

So really no need for the when-let?

pez14:12:44

Let me look at it.

pez14:12:40

I think I added that as a guard against any messages that I had not asked for myself.

pez14:12:10

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.

slipset14:12:40

hmm, but then you should probably start out by checking if id is present in @results*

pez14:12:12

Yeah, and we do, right?

slipset14:12:32

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.

pez14:12:04

Those id:s is what I added in this change so the when-let around the callback might be a left-over.

pez14:12:59

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.

pez14:12:20

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.)

slipset14:12:39

Some last commits. Need to attend the family.

mseddon21:12:05

Solid review! Thanks for that.

pez22:12:30

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

pez22:12:05

^ That line is where i lose track of the CLJS repl creation ^