Fork me on GitHub
#calva
<
2019-06-04
>
hoppy02:06:59

@pez, latest is looking really good.

calva 8
hoppy02:06:53

@pez, I need to switch over to a cljs project (node) and see how that does.

pez05:06:08

The suspense, @hoppy , the suspense! 😎

hoppy10:06:54

ran outta gas - wasn't as easy as I had hoped. Looks like this one was setup such that I start a clj repl, and then manually bootstrap myself into cljs repl. Probably need to rework how to do that. It isn't done with shadow-cljs.

hoppy10:06:05

I was basically doing this by hand at startup, which I can't do in calva (it hangs on the require)

hoppy10:06:15

I will play with some stuff, but won't get to it for a bit.

pez10:06:20

So, you are not using shadow-cljs?

hoppy11:06:51

not for that one. It wouldn't be hard to convert it, and I probably should. It's something I have to debug on raspi sometimes, so tried to keep it light

pez11:06:27

OK. A bit strange that it hangs on require.

hoppy11:06:05

I'd not get to wrapped up in it just now, It probably hasn't been worked in half a year, and I likely have other tooling troubles. Lemme get it stood back up in cider and we'll figure out how to proceed. If shadow-cljs is the correct calva answer, I'm fine with that.

pez11:06:00

With shadow-cljs you just jack-in, and then you get to select if you want to connect to the repl of your app or directly to node. (Here jacking Calva into Calva, a mind bender.)

Wes Hall16:06:15

Hey @pez. So my curiosity got tweeked already and I have been diving into the code 🙂. A few random comments / thoughts... • I definitely feel like I could use some comments. This might be my first contribution when I can find some time. Some of the concepts haven't quite groked in my brain yet. • I feel like I can do some refactoring and maybe write some tests. A few areas jump out as starting points. • I'm a little unclear as to whether the other extensions, calva-fmt and calva-paredit are still used. I am guessing they are, but just bundled using the extension pack thing in the package.json. I wonder whether you have considered splitting all the major functionality up this way, say for example calva-repl and then having the calva extension as just an extension pack containing all the various calva pieces. • People are probably going to hate me for this, but I think personally I would resist the urge to migrate to CLJS. I love clojure too (obviously, since I am here), but if ts/js is the "lingua franca" of VSCode extension development and not swimming against that tide offers advantages (like good debugging support etc), then maybe it is best not to swim against that tide. Please don't hit me! 😉. • I'd quite like to implement a kind of "scratch buffer" thing as an alternative for the REPL. An ethemeral in-memory buffer from which I can evaluate forms in the repl. I imagine (though am not sure), that this would be possible to do in a regular VS code buffer which might allow for a more native feel for REPL interaction. It would or less just be an in-memory clojure buffer. • I even wonder how ambituous (or even possible) it might be to try to do the same kind of thing with the regular "shell style" repl, over the current webview approach. I imagine this would take some rather hardcore controlling of editability in the buffer, making portions readonly etc... no idea if this is possible or sensible in VSCode but it would be interesting to play with it maybe. • It's definitely harder for me to understand calva-fmt.... So. Many. Regexes. Haha. Not your fault obviously but I might need some time with that.

pez16:06:24

@wesley.hall, wow, this is great! > • I definitely feel like I could use some comments. This might be my first contribution when I can find some time. Some of the concepts haven’t quite groked in my brain yet. You mean comments in the code? I’m sorry about the lack of that, I tend to very seldom write those. But lately @mseddon has been growing the code base, and you will find that code much more commented (and much better factored). > • I feel like I can do some refactoring and maybe write some tests. A few areas jump out as starting points. It would be wonderful to see some tests added, and much of the code is screaming for refactoring. As we’ve already covered, I intend to use some time now to try get things on a better foundation. > • I’m a little unclear as to whether the other extensions, calva-fmt and calva-paredit are still used. I am guessing they are, but just bundled using the extension pack thing in the package.json. I wonder whether you have considered splitting all the major functionality up this way, say for example calva-repl and then having the calva extension as just an extension pack containing all the various calva pieces. Yes, I have considered. But it adds confusion for users. The reason they are so separated today, looking like extensions of their own, is that it is what they have been, but I have sourced them in for several reasons. The major one being to make it easier to use common functionality. And some of that functionality is stuff where CLJS has been my choice of weapon and I don’t like the idea of the cljs runtime spread in several extensions. > • People are probably going to hate me for this, but I think personally I would resist the urge to migrate to CLJS. I love clojure too (obviously, since I am here), but if ts/js is the “lingua franca” of VSCode extension development and not swimming against that tide offers advantages (like good debugging support etc), then maybe it is best not to swim against that tide. Please don’t hit me! 😉. I am certainly not going to kill you over this. 😃 I have been threshing a lot on the issue. Currently there are two main reasons to keep CLJS in the mix. 1. It gives access to Clojure tools such as the reader, making it easy to reliably consume Clojure and EDN project files, for instance. 2. I have hoped for it to make the project more attractive to Clojurians to contribute to. (This one is not clear that it has this effect, but it has been a reason.) I, personally think TypeScript is pretty awesome, even if it isn’t as joyful as Clojure. I’m fine with using TS for most of Calva.

pez16:06:27

> • I’d quite like to implement a kind of “scratch buffer” thing as an alternative for the REPL. An ethemeral in-memory buffer from which I can evaluate forms in the repl. I imagine (though am not sure), that this would be possible to do in a regular VS code buffer which might allow for a more native feel for REPL interaction. It would or less just be an in-memory clojure buffer. This has been something I have wanted to do as well, so please go ahead! I’d be happy to discuss the Ux and contribute as much as I can with coding and testing. > • I even wonder how ambituous (or even possible) it might be to try to do the same kind of thing with the regular “shell style” repl, over the current webview approach. I imagine this would take some rather hardcore controlling of editability in the buffer, making portions readonly etc... no idea if this is possible or sensible in VSCode but it would be interesting to play with it maybe. This was my plan for creating a REPL window before @mseddon entered and wrote the repl-interactor and things. There are pros and cons with both approaches. (And I don’t even know how feasible the idea with using something other than a WebView is, it just seems possible.) Let’s keep the option open. > • It’s definitely harder for me to understand calva-fmt.... So. Many. Regexes. Haha. Not your fault obviously but I might need some time with that. I am entirely to blame for calva-fmt. 😃 The good news is that @mseddon wrote a new formatter, in TS, for the REPL Window and there is a settings options to test it for the regular buffers as well. My plan is to fix the new formatter and scrap my calva-fmt hack. They both can be configured with clj-fmt maps, so I don’t see that we would loose anything by going that path.

pez16:06:52

Now must go feed my family. Please keep the discussion going!

👍 4
Wes Hall17:06:22

@pez Understand exactly what you mean by adding confusion re: seperate extensions. As I think about it, I think I am more interested in splitting up the code that the extensions. I assume that VS doesn't have the notion of a "private extension". Something that can only be installed as part of a pack. The alternative I guess would be to just have them split as libraries and not independent extensions, but the problem with that seems to be that you have to declare all the various things in the package.json file, which means some fairly nasty bleed through. It would be really nice if each of these things could be built as entirely independent parts and simply pull together by a parent configuration but perhaps that's not possible. In any case, going the other way and merging them also makes sense, provided they are nicely separated in the structure. Something to look at as things come together.

Wes Hall17:06:40

I'll start having a play around with some basics.

Wes Hall17:06:12

Maybe just removing this test...