Waiting for the Travis build to go green but https://github.com/clojure-emacs/cider-nrepl/pull/517 should be ready to go

Turns out there's a JDK 1.7 compatible way to base64 encode some byte[]s

and addressed the typo

gonna take a look at re-doing the CIDER side of the changeset.

merge conflicts hit the original cut pretty hard

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

argh

whatever. just gonna find a way to disable this feature in 1.7

@arrdem I think that’d be best. As I mentioned in the ticket that’s going to be our final release supporting Java 7 anyways. No need to support a JDK which almost no one is using.

As a server == something akin to using https://github.com/facebook/nailgun ? You’re looking to reduce the time it takes to spin the JVM, right?

It looks like technomancy has something for this - https://github.com/technomancy/grenchman which does at least some of what I'm after.

Been thinking about ways to do amortize lein's project loading over many task runs - the midldleware we use at work can make it pretty slow so having an nREPL that can persist a fully evaluated project state for many commands could speed things up a bit.

Yeah I remember using vim-clojure's nailgun whatever when I was first getting started.

I think that alternatively you can defer the loading of your middleware as cider-nrepl does - all middlewares start life as dummies and the real code gets loaded the first time a middleware op gets invoked.

hummm is there prior art in CIDER right now for features with JVM or library requirements?

I know there's some compatability checking for refactor-nrepl and soforth

@bhauman Yeah, tools like rebel-readline are prime candidates to share such functionality. Same goes for REPL-y, and every REPL client that bases its functionality on inspecting running REPL state, instead of some static code analysis (like Cursive does).

@arrdem The clojure.spec support does something similar - it creates a couple of dummy functions in case the real ones don’t exist. I’m guessing in your case you dynamically require problematic class and that should be OK. I’m not very familiar with the refactor-nrepl codebase, so I can’t speak for it.

You can also disable tests on 1.7 using a test selector, which might be acceptable as well and would move the version check to the client.

@bozhidar cool I'll take a peek at the spec stuff

https://github.com/clojure-emacs/orchard/blob/master/src/orchard/spec.clj

lets see if I can get this adapted before my laptop dies and I'm done for the night 😉

@bozhidar how do you feel about adding a dependency on org.apache.commons.codec.binary.Base64 or something else from the Apache commons collection?

I've got an if-class macro all wired up which "solves" the 1.7 compat issue the way you'd expect

I guess I shouldn’t answer the previous question then. 🙂

heh

In general I’m wary of adding a dependency to account for compatibility with barely used JDK - if more people were on 1.7 I’d be fine with this.

But if this library is small I can live with adding it for one release and dropping it afterwards.

(together with the support for Java 7)

Nah it looks like a monster.

Updated the patchset to return an {:error "\java.util.Base64\` is unavailable, \`slurp\` op is disabled"}` response

lol slack

w/e

Alright. New patch is pushed and I'm out of power. Will check in in the morning.

the CIDER side of this is gonna get a little more interesting because it has to do a second nREPL op to get the image content now, but that's doable.

:thumbsup:

Get some well-deserved rest!

I was offline for a few days for the Easter holidays and I now it seems I’ve got a lot of catching up to do. 😄 Spending a few days in a remote Ukrainian village without Internet was definitely refreshing!

nice! I got to spend a couple days down at gramas for the first time in several years which was lovely. Rich may be on to something with all this hammock time talk 😉

He certainly is! I confirm this every time when I spent an entire night not being able to figure something out and they after sleeping on it I come up with a much better approach in like 10 minutes. 😄

I think many OSS projects are pretty messed up mostly because the only time you have for them is after work when your mind is not fresh and creative. And of course then you’re fine with cutting all sorts of corners.

> And of course then you’re fine with cutting all sorts of corners. Ironically, this hurts you the next day at work when you use the OS products! 😆

This is why you spend work hours on OS products and convince your manager that they’re a priority!

sharpen your :knife: