This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # beginners (164)
- # calva (70)
- # cider (26)
- # cljs-dev (6)
- # cljsrn (1)
- # clojars (3)
- # clojure (123)
- # clojure-berlin (1)
- # clojure-dev (5)
- # clojure-ecuador (9)
- # clojure-europe (2)
- # clojure-italy (14)
- # clojure-nl (21)
- # clojure-nlp (5)
- # clojure-portugal (1)
- # clojure-spain (3)
- # clojure-spec (26)
- # clojure-uk (47)
- # clojurescript (17)
- # clr (1)
- # code-reviews (7)
- # core-async (5)
- # cursive (8)
- # data-science (2)
- # datomic (28)
- # emacs (23)
- # events (1)
- # fulcro (43)
- # graalvm (6)
- # graphql (8)
- # immutant (5)
- # jackdaw (17)
- # jobs (1)
- # jobs-discuss (20)
- # joker (3)
- # leiningen (8)
- # luminus (12)
- # off-topic (61)
- # overtone (5)
- # pathom (2)
- # quil (1)
- # re-frame (15)
- # reagent (2)
- # reitit (23)
- # remote-jobs (1)
- # schema (1)
- # shadow-cljs (26)
- # tools-deps (56)
- # vim (4)
Can I pull in new code from a
:local/root dependency without restarting the repl? I’m trying to extract a lib and want to have my test runner on watch mode in the main project.
er, I guess now that I think about it that’s not quite the repl. I guess I mean is there something related to
add-lib that I could run from the repl or a test namespace that can reload a known
@rgm Is that code you already have on the classpath, and it just got updated? Or is this a genuine addition of new code/dependencies?
It’s already on the class path. The plot twist is that there’s a fair bit of cljc and cljs.
Let’s imagine I have editor buffers open for both the main proj, and namespaces in the lib I’m extracting, nrepl’d or prepl’d in on the editor, and if I can avoid restarting the REPL jvm to get new lib code that’d be amazing and happy.
On the JVM, just eval code as you change it. No need for any reloading there. On the browser (cljs) side, that's what Figwheel/Shadow's hot reloading is all about. Or am I missing something @rgm?
Oh, you’re probably not. The idea that it might just work had genuinely not occurred to me.
(I keep a JVM REPL up and running for days, sometimes weeks, and never use a watcher or reloader process)
Hmm, if you're editing code outside the project as well, I don't know how Figwheel et al would cope. I was just reading about some editor/REPL setup tho' where you can have both JVM and browser REPLs running and when you eval clj it goes to the JVM, cljs goes to the browser, and cljc goes to both.
So with that workflow, you'd still follow a good REPL-Driven Development workflow of edit-eval, edit-eval, without even needing to save your files.
I haven't touched cljs for over four years but I've made a public pledge to go back and spend this weekend getting familiar with modern tooling -- including Figwheel and Shadow -- although I don't know what editor I'll use for this learning project. I've moved away from nREPL (to "just" a Socket REPL or in-process REPL/REBL) but I think cljs will force me to use nREPL?
I’m having a pretty fun time with prepl and conjure (I’m a vimmer) … my experience in vim has been than nrepl + piggieback + fireplace.vim is still pretty rough. Colleagues using emacs/cider laugh at me and my struggles.
I've gone through a bunch of setups over the last nine years. I think I started with TextMate and a plain REPL...
...tried a bunch of editor+repl combos, settled on Eclipse/CCW for a while, then moved (back) to Emacs -- I used it a lot 20-30 years ago, then switched to Atom/ProtoREPL and more recently Atom/Chlorine, which means I can get away from nREPL.
And, lately, I've been very enamored with REBL as part of my workflow so my normal work setup is
clj/`deps.edn`, Atom/Chlorine, REBL with a Socket REPL.
But I've always had a soft spot for
vi so I've been keeping an eye on Liquid, which is basically an in-process vi-like editing experience with built-in evaluation (and no REPL needed).
I have Liquid + REBL (started from
clj/`deps.edn`) working now and will try to use that quite a bit going forward (but it does lack some parinfer/paredit/global-find'n'replace niceties).
I don't know how any of that works for cljs stuff tho'. Part of this weekend's exercise will be exploring tooling and figuring all that out.
You should totally be a streamer @seancorfield... I would love to watch you experimenting with that stuff and analyze your workflow.
@anantpaatra Yeah, I was very interesting in the #livestream channel when it started ages ago but the problem is I mostly work on a large (86K+ line) proprietary code base and couldn't stream that.
I am considering doing more screencasts (or even streaming) my OSS work tho'.
@anantpaatra did you see the 9 minute screencast I posted on YouTube of me working with Atom/Chlorine/REBL?
It was definitely interesting to watch that as it is a completely different workflow from everything I've seen so far. But the pace is like trying to appreciate a super-bike when it passes in front of you at 350km/h. You can hear it is loud, you can see it is expensive, it's probably beautiful and you quickly think "damn, I would love to ride that" but its gone before you even realize and you're left with your regular pedestrian day ahead of you. haha
I understand it was made for experienced developers though, but I would really like that clj/deps.edn details being slowly crunched.
OK, good feedback. I didn't realize it came across like that. I thought it was slow and gentle. I'll try harder next time.
For example, watching someone going from zero to a complex project by using
clj/`deps.edn` would be awesome. I truly need something like that.
(I'm from the South of England. I don't have an accent. Everybody else does! 🙂 )
BTW, I'm going to be on DEFN Sunday morning (Pacific) and I believe they're livestreaming that. But it's just chat, not coding.
When I fixed an issue on
core.memoize last week, I realized that it would have been a great opportunity to stream or screencast. I used REBL and
tap> specifically to hone in on the bug and fix it, all live-eval'ing in the editor.
➜ ~ clj -e "(clojure-version)" "1.10.0"
do you show the version of
clj or the default version of clojure? or the requested version of clojure in the current context?
Everything? If it’s reasonably structured it can be greppable for tools to extract more.
I think Elixir’s mix and also npm (to which clj is more alike) show the version of the tool and the version of the language (and also the host runtime version). I’ll verify at a computer tomorrow.
Yeah for me the version of clj is more important - right now in my ansible scripts I’m looking at some some specific file to check a number.
Would prefer to invoke the tool and get an easily comparable version string without starting the JVM
these questions are tbd, imo. I'm not sure that the subtle difference between the clojure version used when building classpaths vs the clojure version being used in your project is obvious to most people. I don't think it's even clear to people that these are independent things.
I just want to share how much I love tools-deps. It's so simple in what it does, you really know what's going on when you use it, and it's so easy to just specify git dep and immediately try something: no need to publish for library authors, no need to setup a project just to try stuff out for library users... I wish we had build tools that are that simple!