Clojurians Log v2

Can your repl do that?

I mean, vim can't do that, no matter how hard I try 😄

which part?

linewise highlighting only in vim printed output.

the twist here is that we have two string representations highlighted differently because they represent different things

really cool 🙂 I actually thought on going for something similar on unrepl.el, but at the end I decided to stick with clojure-mode's font-locking, which is basically based on a syntax table

super cool to have semantic highlighting

could have spared me some hair pulling on a couple of occasions

but the end result is so pretty 😄, and the answer to your question will most likely be: "nope, my repl cannot!"

I wanted to join the party 🙂

not sure if this is a safe way to replicate lein repl:

java -cp `lein classpath` clojure.main -e "(do (require 'clojure.core.server) (let [srv (clojure.core.server/start-server {:name :repl :port 0 :accept 'clojure.core.server/repl :server-daemon false})] (prn [:jack-in/ready {:port (.getLocalPort srv)}])))"

For one thing this ignores JVM settings set in project.clj

and profiles

Although maybe that's ok?

that can be iterated upon

may I ask, what's the disadvantage of lein trampoline run -m ...?

lein trampoline run might be safer

jinx!

haha al-most-

what does CIDER do?

lein update-in :plugins conj '[cider-nrepl]' -- repl

lein classpath can be cached (based on a hashes) so starting faster than lein

cider lets you construct a command based on parameters and global options

not sure we want to do caching at this point (will inevitably lead to problems if not handled carefully)

how about encapsulating the jack-in logic in a shell script - then we can share the logic between unrepl.el and unravel?

^ wow

may I ask, why wouldn't it be easy from elisp?

https://github.com/Unrepl/unrepl.el/commit/99ff8b1e3a2a80cbcf351debf1a0ea7a1583e810 this commit has basically all the autodiscover feature

I'm not saying it wouldn't be easy

ah you want to make things configurable?

just not as practical

I made them customizable same as cider, you can customize the way you call either boot or lein, as long as you know that a -i <repl initialization code> is going to happen

another worry is that shell scripts won't work on windows

what exactly did you want to put into a shell script?

maybe we're talking different things

if [[ -e project.clj ]]; then exec lein run ....; elsif [[ -e build.boot ]]; then exec boot socket-server; else clj ...; fi

right. so the thing is I do the "[[ -e project.clj ]] .." as its own function called unrepl-socket--clojure-project-type and I use it some other places, wouldn't want to split the same behavior into two sources

plus the configuration thing

and in my case, it's a bit more than just checking if a certain build tool file exists

I also have to get to the root of the project, because I can be starting the repl from a subdirectory

are these things that could be done in a shell script as well?

reimplementing in elisp is fine of course but I'm thinking it could be nice to have the autosensing code in some kind of module you can test individually

we should at least standardize the :jack-in/ready message, no?

of course they can be implemented as shell scripts

one thing i notice about the jack-in message, when you are starting a boot repl, output can contain a lot more than just the message, it comes with other information and maybe some ansi code gibberish (which i guess could be avoided by cli)

plus, at least for me, the message always comes in to chunks

I get "[" and then ":jack-in/ready ...]"

so I have to buffer the output and check... parseedn gets stuck with the whole output (including gibberish) for some reason I didn't have time to debug, and even if it didn't get stuck the sensible response should be a parse error... so I went with a simple regex "\\[:unrepl\.el/server-ready \\([0-9]+\\)\\]"

(I simplified the message to [:unrepl.el/server-ready <port>])

having said that, I do agree it would be nice to have a standalone module for this and be able to constantly test it

gibberish prelude can happen with lein trampoline run too

to avoid chunking (println (pr-str msg))

first pass at this: https://github.com/Unrepl/unravel/pull/54/files

I'd just regex through the output line by line until I find something like [:jack-in/ready.* and then read from there

@pesterhazy (println (pr-str msg)) is about more than chunking, when you are on a bad day you may have spurious prints interleaved with your message when you do (prn msg)

that was my first approach, but it failed because of the possible extra stuff that could come after the mesage... with @cgrand's println trick this can be solved

Clojure's read-string reads the first complete form and then stops - does your edn.el work differently?

good albeit slightly obscure point @cgrand 🙂

good question, it seems that it does so.. at some point, it gets stucked

$ lein trampoline run -m clojure.main -e ‘(prn :oh-noes)’
objc[9868]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java (0x108d484c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10a4d94e0). One of the two will be used. Which one is undefined.
Initializing NoDisassemble Transformer
:oh-noes

can’t your grep|sed the output of exec right in the shell script?

that's what I'm doing already

switched to your println suggestion @cgrand

yeah I saw

I just take the relevant part of the output... the part after the message was what was messing up with parseedn, but now with the println thing I'm good

maybe a good idea to add a "\n" at the start as well so we're sure we have a line to ourselves?

I think it could still happen theoretically that another thread writes to stdout while we're writing our string but it seems unlikely given that the string length is less than reasonable buffer sizes

openjdk seems fine though: https://github.com/dmlloyd/openjdk/blob/jdk10/master/src/java.base/share/classes/java/io/PrintStream.java#L447

Yeah, that’s sad that https://github.com/dmlloyd/openjdk/blob/jdk10/master/src/java.base/share/classes/java/io/OutputStream.java#L106 is not synchronized

luckily most descendants do synchronize (eg BufferedOutputStream)

Hold my 🍺

Well it will have to wait next week