@bhauman @thheller In a burst of unexpected productivity (and because of a dumb mistake of mine) - piggieback 0.3 is now out and it uses the updated ns cider.piggieback for consistency with the new artefact coordinates.

I’ll leave it up to you to decide if you want to be doing some ns check for 0.2 and 0.3, but I’ve decided to skip this, as for end users it’s just a matter of updating one dependency. I’ll add some big warning about this in the release notes for CIDER 0.17. Plus this will certainly drive up the adoption of the new piggieback. 😄

0.3 also drops support for rhino, as discussed in the past, so now the codebase is quite simpler.

@bozhidar I think you just broke fireplace... Which uses rhino by default to provide functionally when you haven't done anything yet. And has the namespace hard coded. Does this release have a different co-ordinate? Does CIDER have a default environment it connects to?

Yes - it’s cider/piggieback now.

No, CIDER prompts the user for the environment to use. vim-fireplace should just switch to the much better nashorn I guess. It’s pretty much a drop in replacement.

Tpope can be quite conservative, I wonder how hard it will be to convince him to drop those java versions.

Well, piggieback doesn’t support them anyways, so there’s little point in him supporting them.

He might just say he doesn't support cider piggyback... What are the fixes/improvements?

cider-nrepl will also stop support JDK 7 after the upcoming release, and in general I plan the same for nREPL once I have time to work on the long overdue 0.3 release.

I guess that’s the highlight https://github.com/clojure-emacs/piggieback/pull/80

Everything else is cleanup at this point.

I don't understand the problem/benefit of that change?

Oh, faster. Okay.

Each eval used to spin a new repl which was quite inefficient.

Anyways, if he wants to do some changes - fine, if not - I don’t have time to deal with irrational people.

I've got some time before I start work, I'm going to go take a stab at this.

I’m committing so much of my little free time for those projects, that I can’t deal with upgrade paths and stuff like this all the time.

(I thought of making CIDER work with the old and new version, but I decided I have more important things to do)

It took 6 months for my pprint pr to merge, so I'm not hopeful, but maybe he's looking at this a bit more now.

Also I could have made Rhino just an alias for Nashorn and no one wold have noticed, but again - this seemed like a waste of time.

Wow!

You should join the Dark Side - as you can see the Emacs maintainers are quite responsive. 😉

> cider.piggieback :as pback you're all monsters.... ;)

(not to mention that 10 people are admins on clojure-emacs - we’ve got some very real democracy)

I'm planning on taking on/replacing fireplace eventually. My replant plugin augments it currently, using it to manage sessions and connections. I've got a second person actively contributing, and others seem to be picking up interest. There is the clojure-vim group where there's a few of us, but that's not yet connected to replant.

Might be good for the vim community. Seems tpope has lost interest in the project to some extent. I guess he’s not open to sharing ownership of the project?

No idea. ¯\(ツ)/¯

He's a pretty busy guy, lots of vim plugins, high standards. He has made some commits over the weekend since my PR, some of them tidying up my pprint code.

hi, with latest CIDER from MELPA I get:

Exception Failed to launch Figwheel CLJS REPL: nREPL connection found but unable to load piggieback.
This is commonly caused by
 A) not providing piggieback as a dependency and/or
 B) not adding piggieback middleware into your nrepl middleware chain.

{:dev
   {:dependencies [[binaryage/devtools "0.9.9"]
                   [cider/piggieback "0.3.0"]
                   [day8.re-frame/re-frame-10x "0.2.1-react16"]
                   [figwheel-sidecar "0.5.14"]
                   [org.clojure/tools.nrepl "0.2.10"]]
    :repl-options {:nrepl-middleware [cider.piggieback/wrap-cljs-repl]}
    :plugins [[lein-figwheel "0.5.14"]]}}

Oh wait, could it simply be that latest master is not on MELPA yet and I am to eager to live on the bleeding edge? 😄

@manuel I’m also reasonably certain @bhauman has to cut a new release of figwheel that’s compatible with the new piggieback (basically it has to know of the new namespace).

ok cool

@bozhidar I don't suppose this looks familiar?

javax.script.ScriptException: TypeError: Cannot load script from .cljs_nashorn_repl/goog/undefined in <eval> at line number 1
        at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:470)
        at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:454)
        at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
        at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
        at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
        at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
        at cljs.repl.nashorn$eval_str.invokeStatic(nashorn.clj:46)
        at cljs.repl.nashorn$eval_str.invoke(nashorn.clj:45)
        at cljs.repl.nashorn$load_ns.invokeStatic(nashorn.clj:97)
        at cljs.repl.nashorn$load_ns.invoke(nashorn.clj:96)
        at cljs.repl.nashorn.NashornEnv._load(nashorn.clj:159)
        at user.Delegatingcljs_repl_nashorn_NashornEnv._load(Unknown Source)
        at cljs.repl$load_namespace.invokeStatic(repl.cljc:223)
        at cljs.repl$load_namespace.invoke(repl.cljc:179)
        at cljs.repl$load_dependencies.invokeStatic(repl.cljc:229)
        at cljs.repl$load_dependencies.invoke(repl.cljc:225)
        at cljs.repl$evaluate_form.invokeStatic(repl.cljc:512)
        at cljs.repl$evaluate_form.invoke(repl.cljc:452)
        at cljs.repl$evaluate_form.invokeStatic(repl.cljc:459)
        at cljs.repl$evaluate_form.invoke(repl.cljc:452)
        at cider.piggieback$eval_cljs.invokeStatic(piggieback.clj:214)
        at cider.piggieback$eval_cljs.invoke(piggieback.clj:213)
        at cider.piggieback$do_eval.invokeStatic(piggieback.clj:238)
        at cider.piggieback$do_eval.invoke(piggieback.clj:221)
        at cider.piggieback$evaluate.invokeStatic(piggieback.clj:261)
        at cider.piggieback$evaluate.invoke(piggieback.clj:259)
        at clojure.lang.Var.invoke(Var.java:381)
        at cider.piggieback$wrap_cljs_repl$fn__17019$fn__17021$fn__17022.invoke(piggieback.clj:290)
        at cider.piggieback$enqueue$fn__16999.invoke(piggieback.clj:196)
        at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__4190.invoke(interruptible_eval.clj:190)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: <eval>:1 TypeError: Cannot load script from .cljs_nashorn_repl/goog/undefined
        at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
        at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213)
        at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185)
        at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:172)
        at jdk.nashorn.internal.runtime.Context.load(Context.java:868)
        at jdk.nashorn.internal.objects.Global.load(Global.java:1545)
        at jdk.nashorn.internal.scripts.Script$Recompilation$21$34A$\^eval\_.nashorn_load(<eval>:1)
        at jdk.nashorn.internal.scripts.Script$Recompilation$38$51AA$\^eval\_.CLOSURE_IMPORT_SCRIPT(<eval>:1)
        at jdk.nashorn.internal.scripts.Script$Recompilation$201$189AA$\^eval\_.require(<eval>:19)
        at jdk.nashorn.internal.scripts.Script$493$\^eval\_.:program(<eval>:1)
        at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
        at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
        at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
        at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)

that was longer than I expected...

No, it doesn’t seem familiar.

Perhaps you’re not using the right clojurescript or something?

I'm on 1.9.x

Hmm, I’m puzzle this. In piggieback there’s no nashorn specific code - it just delegates to cljs

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl/nashorn.clj

And that’s the case for all cljs repls.

https://github.com/clojure-emacs/piggieback/blob/master/src/cider/piggieback.clj#L162

I’ve tested it myself and it works just fine.

Ran this code to start a cljs repl

(do (require 'cljs.repl.nashorn)
      (cider.piggieback/cljs-repl
       (cljs.repl.nashorn/repl-env)))

So that bit seems to work fine, but then when I run :Eval (+ 1 1) (which I think sends (ns edge.main) (+ 1 1)) I get 💥

For me the rest works as well, so it must be something with the way vim communicates with nrepl.

Although the message for clj and cljs eval should be exactly the same.

the message is quite suspect, about what it's trying to load... :thinking_face:

I guess you can try on a simpler project? Edge is fancy! Might be something unrelated.

I’ve got just one demo project with only the bare minimum deps and I usually test cider against it, (which is what I did right now)

@bozhidar have you got a link I can use for that?

Everything I have is boot or deps.edn.

boot doesn't support the cider.piggieback yet

You can simply use piggieback as well.

I haven’t committed the other one, but I guess I should do it.

Does boot have to know something about piggieback? Lein certainly doesn’t.

boot-cljs-repl knows about piggieback, yep

https://github.com/adzerk-oss/boot-cljs-repl/blob/master/src/adzerk/boot_cljs_repl.clj#L115-L116

@bozhidar the piggieback project itself wouldn't work because there's no cljs there.

Are you sure about this? 🙂 Try lein with-profile 1.9 repl.

We can’t really run its tests without cljs.

https://github.com/clojure-emacs/piggieback/tree/master/src/cider it's all clj files?

Oh, fireplace works way different to how you're thinking

Yep.

I need to have a .cljs file open, to be in the context of cljs. There's no "REPL Buffer"

Oh, got it. I just started some repl buffer and did some evaluations in it.

You really need to become an Emacs user! Life without a repl is…

😉

hehe. I have something "close enough".

fwiw, I'm getting the same issues with the mies lein template.

d4:code41:(ns cljs.user (:require hello-world.foo))2:id30:fireplace-bianca2-1524041215-92:ns9:cljs.user2:op4:eval7:session36:4fac591c-e5d0-4c02-8b96-9b22c834493ae this is what's blowing up

d4:code49:(ns cljs.user (:require hello-world.foo :reload))2:id31:fireplace-bianca2-1524041215-132:ns9:cljs.user2:op4:eval7:session36:5d429fe2-7588-4383-af14-677724f03ac0e <-- blows up too

@bozhidar I can reproduce without fireplace, if you open a cljs repl, and use REPL-y (basically, use lein repl).

user=> (require 'cljs.repl.nashorn)
nil
user=> (cider.piggieback/cljs-repl (cljs.repl.nashorn))
CompilerException java.lang.ClassNotFoundException: cljs.repl.nashorn, compiling:(/tmp/form-init7664251244487051022.clj:1:29)
user=> (cider.piggieback/cljs-repl (cljs.repl.nashorn/repl-env))
To quit, type: :cljs/quit
nil
cljs.user=> (ns cljs.user (:require hello-world.foo))
<massive exception from above>

lein update-in :dependencies conj '[refactor-nrepl "2.4.0-SNAPSHOT"]' -- update-in :repl-options:nrepl-middleware conj refactor-nrepl.middleware/wrap-refactor -- update-in :dependencies conj '[cider/piggieback "0.3.0"]' -- update-in :repl-options:nrepl-middleware conj cider.piggieback/wrap-cljs-repl -- update-in :plugins conj '[cider/cider-nrepl "0.17.0-SNAPSHOT"]' -- repl <-- my repl start command.

@bozhidar this might be a general nashorn bug, rhino still works with cider.piggieback.

oh, it doesn't beyond the (ns …) form 😂

it works for a single evaluation, 😔 okay

Interesting.

What works for a single evaluation - nashorn?

rhino works for a single evaluation, and subsequent ones fail: java.lang.RuntimeException: No Context associated with current Thread

I deleted a lot of code to support rhino - I’d be really surprised if it worked without it. 😄

I had wondered if it was support for "legacy rhino", I was also just curious

But does something like (+ 1 1) for you in nashorn? It sure works for me.

As for rhino - it hasn’t been updated in many years in the jdk, they just decided to replace it with something else. So the only rhino is the legacy one.

by legacy rhino, I meant the cljs.repl.rhino aspect.

AFAIK the engine itself is the reason why the cljs support for it was so fucked up.

(+ 1 1) works in nashorn, but not the (ns …) thing

cljs.user=> (ns cljs.user (:require hello-world.foo)) ;; :boom:
cljs.user=> (ns cljs.user (:require cljs.core hello-world.foo)) ;; fine

Hmm, so it seems you found some clojurescript bug then. 🙂

Or perhaps the two of us know nothing about cljs - I’m reasonably certain that’s true for me. 😄

@bozhidar I think this is still a piggieback bug, doesn't happen when using nashorn directly

https://github.com/swannodette/mies using mies, modify the scripts/repl.clj to require nashorn :as node, and then run ./scripts/repl, and the above thing which throws using nrepl, is fine.

Interesting.

I wonder if it’s something to do with https://github.com/clojure-emacs/piggieback/pull/80

maybe

Can you try with 0.2.2 before we made this change?

0.2.2 works

user=> (require 'cljs.repl.nashorn)
nil
user=> (cemerick.piggieback/cljs-repl (cljs.repl.nashorn/repl-env))
To quit, type: :cljs/quit
nil
cljs.user=> (ns cljs.user (:require hello-world.foo))
true
cljs.user=>

Damn, now we have our answer then. Can you please file a ticket and ping @bhauman there. I guess he knows how to fix this, as unlike me he actually knows cljs. 🙂

I'm looking at this now.

@dominicm what version of clojurescript are you using?

1.9.946 was what I used in mies

cool

(require
  '[cljs.repl :as repl]
  '[cljs.repl.nashorn :as node])

(repl/repl (node/repl-env))

that shouldn't matter right?

this is about nashorn loading scripts

oh nashorn as node

gotcha

Sorry, I was lazily attempting to give my instructions for updating the mies template

so this works for me (ns hello.there (:require [goog.object :as bobj]))

wrong person, but yeah. I think it's potentially specific to cljs.user

I just did this (ns cljs.user (:require hello-world.foo)) and got the right response

clojure.lang.ExceptionInfo: No such namespace: hello-world.foo, could not locate hello_world/foo.cljs, hello_world/foo.cljc, or JavaScript source providing "hello-world.foo" in file <cljs repl> {:tag :cljs/analysis-error}

oh, I added hello-world/foo.cljs too, just an empty ns

(ns hello-world.foo)

in the repl or in a file?

In the file

uh, that's of course hello_world/foo.cljs

@bhauman is that reproducible now?

yep

its reproduced

also (require 'hello-world.foo :reload)

Great 🙂

I've confirmed that it is my eval commit

Seeing a small oddity with cider-nrepl 0.17.0-SNAPSHOT from emacs. M-x cider-repl-set-ns no longer works for me, although it did yesterday. I get this message, even though I just started the repl by doing C-c M-j:

‘cider-repl-set-ns’ needs a ClojureScript REPL.
If you don’t know what that means, you probably need to jack-in (‘C-c M-j’).

@soulflyer Do you see this for a Clojure or a ClojureScript REPL?

clojurescript repl

Did you update piggieback?

@bozhidar I have a fix for piggieback

@bhauman Great! What turned out to be the problem?

default repl options needed to be calculated when operating outside of the repl

AFAIK requiring is the only place that its a problem and it really only needed an output-dir

@bozhidar when neil took the basic deps out of the project.clj, do you know the thinking there? https://github.com/clojure-emacs/piggieback/commit/7f93cdbad2776233d890a952ee088de54420c8a4

@bozhidar I tried updating piggieback, but was getting problems similar to ones @manuel mentioned earlier so rolled it back out again. I'm now on 0.2.2 from com.cemerick

Well, that’s the problem - cider doesn’t work with it anymore. You’re not getting errors, but it’s just not compatible.

@bhauman No idea. I thought he assumed they were something to be provided and moved them to the testing profiles. @gonewest818 You around?

I noticed the problems with this when I tried to run the tests today and they weren’t working without a profile, so I just left him a comment on GitHub.

I'm a gonna revert to the hard deps for now

actually I'll wait no rush

@soulflyer So, for this to work properly we need a version of figwheel that knows about the changed namespace, which I assume is coming soon. Inf I have some time I might make cider work with both namespaces as well.

hmm. and without updating or pulling CIDER, I'm getting errors starting up figwheel

Exception Failed to launch Figwheel CLJS REPL: nREPL connection found but unable to load piggieback.
This is commonly caused by
 A) not providing piggieback as a dependency and/or
 B) not adding piggieback middleware into your nrepl middleware chain.

example profile.clj code:
-----
:profiles {:dev {:dependencies [[com.cemerick/piggieback <current-version>]
                                [org.clojure/tools.nrepl  <current-version>]]
                 :repl-options {:nrepl-middleware [cemerick.piggieback/wrap-cljs-repl]}}}
-----
Please see the documentation for piggieback here 

Note: Cider will inject this config into your project.clj.
This can cause confusion when your are not using Cider.  figwheel-sidecar.repl/eval38042/fn--38043 (repl.clj:167)

Because your middleware gets updated automatically.

@bozhidar I'm the name change was a bit intense

lein figwheel raw still works

@bozhidar So my best plan is to sit tight and wait a bit?

in terms breaking things

it literally breaks everyone

even if I update figwheel everything is going to be broken

Why so?

SNAPSHOT?

Yes.

thats why

Fair enough. I’ll add some fallback in cider, so no one will have to update for a while.

I overdid it in a hurry and now I’ll suffer the consequences. 🙂

or we could keep cemerick?

I'm thinking this is the best way

folks who rely on it directly shouldn't have to change sources

just deps

It’s confusing to have different coordinates and namespace. That how I ended up doing this. Had changed one instance of cemerick to cider accidentally and was confused by the problem that caused for a while, so in anger I renamed everything to be consistent.

yeah probably a trade off here

We have a much more painful change coming - changing the sources for nREPL itself, so that’s a good exercise in dealing with tough changes.

it doesn't cost that much to keep it the same

though

where as the costs of changing could be god knows what

for folks out there

For nREPL it can’t be done. Once it goes out of clojure-contrib it will have to have a new namespace and a new coordinate.

talking about piggieback only here

Shouldn’t I be able to connect cider to a rhino repl in a cljs node project?

I’m documenting an old project, and I thought I could but I forget how, lol.

I have it running, but jumping around in code isn’t working.

But do end users really care about this? I don’t think anyone uses piggieback directly.

yeah some do

they rely on it directly though

so they can use it at the lein repl

and this is currently in the lein figwheel template

https://github.com/bhauman/figwheel-template/blob/master/src/leiningen/new/figwheel/project.clj#L109

which means its lingering like that in tons of projects

Yeah, but that’s the library itself, not its namespaces. I thought you wanted us to change the coordinate for it. 🙂

the coordinate not the ns 🙂

yes its a tiny bit confusing

hmmm there is no problem having the two piggieback middlewares installed?

cemerick and cider

there shoudn't be

There’ll be a problem only if you decide to activate both of them.

which is hard to do from a cljs.repl

but from a different session

True.

even from a different session it shouldn't be a problem

different vars

Anyway I just cleaned a bunch of junk out of piggieback the delegating repl env is no longer needed

Nice!

Overall I really think that if we just add a bit of conditional code to cider-nrepl and figwheel to know both namespaces (the old and the new) very few users are going to notice anything. Things are going to work for people who don’t upgrade and they are going to work for everyone else as well.

I disagree with you @bhauman. Multiple coordinates with the same namespaces is a recipe for trouble. I think it's better if clients do an or and use resolve.

good enough

I'm in agreement

@dominicm please try the latest piggieback

OK, guess we all have agreement. I’ll update the cider-nrepl code.

I'll try right now @bhauman

Now that piggieback is getting slimmer and slimmer maybe even @thheller is going to like it. 🙂

good with that 🙂

@bozhidar if we get the go ahead from @dominicm I'd say we should cut another release, although I'd like to put the dependencies back in

Go ahead and put those in. We can adjust the build afterwards.

@bhauman Very promising! I just did (js/print "hello")

so much faster

like, this is a zoooom.

(again, you notice this so much more in vim)

yeah its supposed to be freaking quick

fixed figwheel https://github.com/bhauman/lein-figwheel/commit/3df3d098a1130544956ade61c00ed487c3e20374

@juhoteperi needs contacting to fix boot-cljs-repl

@bhauman really fast with figwheel too, this is amazing.

the nice thing about jack in clojurescript is that you get two inspirational quotes. got a good mix of alan kay and madonna 🙂

controversy: Why does cider include inspirational quotes?

so i'm running lein -U figwheel raw and i can get a clojuresript repl up. but cider-jack-in-clojurescript is still not working. Exception Failed to launch Figwheel CLJS REPL: nREPL connection found but unable to load piggieback.

because that's the kind of whimsy you expect in an emacs package

Awesome I am following like the final of the world cup 😃

how would i diagnose what's going on. it feels like a figwheel error. but not figwheel's fault

https://github.com/tpope/vim-fireplace/pull/311 🕓 let's see what happens

I’ve just made cider-nrepl aware of piggieback 0.2

Sorry for all the problems I might have caused by my reckless actions in the morning, but it seems this inspired us all to do a lot of work pretty fast and in the end of the day backwards compatibility was preserved so it’s a win-win, as far as I’m concerned. 🙂

> inspired We're looking for an inspired rockstar developer who can work evenings, mornings, lunches and nights? 😄

Sounds like me! 😄

@dominicm The quotes are a legacy from SLIME - our spiritual predecessor.

I found them to be lost of fun, that’s why I’ve added them to CIDER as well. Everyone should get a bit of fun and inspiration before they start hacking. 🙂

And a sip of cider 😉

@bhauman Should I cut a new release or you want to make more changes and cut it yourself?

hello, I am having a rather odd issue with the find-symbol op

@bozhidar the unixer in me wants an inspirational plugin, that cider calls into

@dpsutton are you understanding what's going on?

@bozhidar yeah cut a release

Went to lunch while things settled. I'll have to try when I get back

I didn't follow the issue because I was at work. But I'll look into it when I get back

@dpsutton cool

its just because cemerick.piggieback was renamed to cider.piggieback and figwheel couldn't find it

Let me see if I got this right: cider-nrepl will now work with cemeric/piggieback, I just have to wait for it to appear on melpa (or pull the source from git). Meanwhile there is a new version of cider/piggieback on the way. Once that is released I can switch over to that and all should be fine. Is that about right?

And a piggie back was released looking for this? I guess that's what I missed

Interestingly, it never broke for vim

@dpsutton what happened was that cider-snapshot was updated

Got you. Thanks

and figwheel doesn't understand the presence of cider.piggie yet

I need to learn these other parts in cljs. I've read your stuff a while back and I'm looking forward to the codebase now that you've worked so much on cleanup

@dpsutton would love to have your eyes on it

Ah ha. Restart everything and I'm picking up the updated cider-nrepl and its working with piggieback 0.2.2. Many thanks, appreciate the efforts @bozhidar

@soulflyer I haven't gotten a successful startup yet. What versions of the relevant libs are you pointing to, and are you using com.cemerick/piggieback or cider/piggieback? And yeah, thanks to everyone for your hard work figuring this out ❤️

I'm using 0.2.2 at com.cemerick

I think emacs was hanging on to the earlier version of cider-nrepl. Killed it off and restarted it and it picked up the version of cider-repl with the fix to allow it to see either 0.2.2 from cemerick or 0.3.0 from cider

I'm seeing this in the cider-nrepl jar

(def cider-piggieback?
  (try (require 'cider.piggieback) true
       (catch Throwable _ false)))

(def cemerick-piggieback?
  (try (require 'cider.piggieback) true
       (catch Throwable _ false)))

both require cider-piggieback

Still no luck for me. I'll worry about something else for the moment until things settle a bit more. @soulflyer I'd love to know what versions of the other libs you're pointing at -- CIDER, cider-nrepl, figwheel... @bozhidar @bhauman etc -- dunno how many folks are likely affected by the problem, but might be worth throwing something up in #announcements once there's a clear path forward for users -- or if it's just a matter of waiting, no need to change version numbers, maybe let folks know they'll have to wait a while.

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/util/cljs.clj#L5

https://github.com/clojure-emacs/cider-nrepl/commit/be2813f69928d5052978161a8db19da407fe5d69

@bozhidar can you update that real quick?

if anyone with merge abilities is around this should fix our stuff now: https://github.com/clojure-emacs/cider-nrepl/pull/523

or at least fixes it for me at work

i've got it lein installed at work and working away now

@dpsutton I can merge that

merged

thanks @gonewest818 any chance you can cut a release as well? i think that will get everyone operational again

If I’m not mistaken the merge should auto-publish a snapshot. or do you mean bump the version, non-snapshot?

I’m sorry to be dense … been away a while and still catching up on what’s been happening.

nah just pushing the snapshot

Ok, then this is the deploy job, currently pending. It runs after everything else passes (and your pull request passed so it’s just a matter of waiting).

https://travis-ci.org/clojure-emacs/cider-nrepl/jobs/368297725

you added that recently, right?

yes, the auto-deploy is relatively new.

nicely done 👍

Thanks! Deploy job ran (https://travis-ci.org/clojure-emacs/cider-nrepl/jobs/368297725#L510-L525) and artifact can be seen in the repo too (https://clojars.org/repo/cider/cider-nrepl/0.17.0-SNAPSHOT/)

Running against git cleaned project, got same error. No distinct cider-nrepl dir in .m2 repository, but deleted cider & trying it again.

delete and use - U option to force the upgrade

although deleting should accomplish this for you

Delete what? & -U with what? Sorry, not sure what you mean.

the -U option to lein forces checks for lein updates i think, even snapshots. but i was saying to delete ~/.m2/repository/cider

Ah, def, already deleted it. If that doesn't work I'll try the -U.

hmm

in emacs go browse into the jar file in ~/.m2/repository/cider/cider-nrepl/cider/nrepl/util/cljs.clj and see if the update is there

look for this patch: https://github.com/clojure-emacs/cider-nrepl/commit/57a813fe1f06b3d031ff983ff7ff654d3205f6af

When running tests for the current file, does cider reload the current file?

me or egg?

@dominicm No.

It's fetching /cider-nrepl-0.17.0-20180418.191838-35.jar, which I think must be the current version.

looks pretty fresh

but go look at the code. there have been a few releases today

emacs should let you navigate into the jar just fine

Bingo, I can confirm I've got a working cljs repl for the 1st time today 🙂

@dpsutton Sorry about the copy/paste snafu. I was in a hurry for a dinner appointment and didn’t read through this carefully.

no worries. that's why there's a bunch of us looking at it 🙂

very easy to fix a typo when you did all the necessary checks

If only I had written the if in the morning… 😉

Anyways, I’m glad this is behind us, although I guess now I should return to cider the option to start rhino, for people on 0.2.x. Or not… 🙂 I wonder if anyone will miss it.

@bozhidar Can't speak for anyone else, but for me this issue is tiny in comparison to the enormous benefits I've gotten from CIDER. I remain extremely grateful for all your work and vision on it 🙂

by the way I've been wanting to make these changes to piggieback for years, everyone should notice faster evals

so

much

its just really complex to evaluate against an existing repl-env, it took me 4 hours this morning to track down a tiny piece of the puzzle

faster

need to get @cfleming in on any potential changes to piggieback as well

@cfleming cemerick.piggieback -> cider.piggieback

Great work, @bhauman! I’m very happy that things are finally moving in the piggieback world again.

@eggsyntax Thanks! You’re welcome! I have this tendency to move fast and break things… I guess I’d be a good fit for facebook. 😄 😄 😄

Btw, I’ve fixed the CI and deployed piggieback 0.3.1, so I guess we can finally put this fun episode behind us and get some rest.

I was supposed to be working on one slide-deck the entire deck, and at 11 pm I guess I should finally start doing this. 😄

What's a slide deck? Presentation for a talk?

Yeah.

you give so many talks!

Guess so. 🙂 I have 4 talks in the next couple of months, but they are all at Ruby conferences. I hope this year I’ll manage to do a few Clojure talks as well - so many interesting updates and ideas to share, so little time…

@bhauman is that just a package change?

Or are there other differences?

so yeah its a coordinate/ns change, and now it works a lot better, minus rhino though

@cfleming ^

Ok, loss of Rhino is no problem. I’m actually not doing anything with piggieback myself at the moment, users have to configure it manually if they want to use it.

good good

We need a council of tooling for changes like this 😛