Fork me on GitHub
#unrepl
<
2017-12-05
>
cgrand09:12:08

Can your repl do that?

dominicm09:12:42

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

cgrand09:12:05

which part?

dominicm09:12:24

linewise highlighting only in vim printed output.

cgrand09:12:53

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

volrath09:12:27

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

volrath09:12:55

super cool to have semantic highlighting

cgrand09:12:22

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

volrath09:12:15

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

pesterhazy10:12:01

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)}])))"

pesterhazy10:12:32

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

cgrand10:12:42

and profiles

pesterhazy10:12:52

Although maybe that's ok?

cgrand10:12:03

that can be iterated upon

volrath10:12:40

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

pesterhazy10:12:45

lein trampoline run might be safer

volrath10:12:04

haha al-most-

pesterhazy10:12:33

what does CIDER do?

dominicm10:12:53

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

cgrand10:12:11

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

volrath10:12:15

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

pesterhazy10:12:42

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

pesterhazy10:12:30

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

volrath10:12:41

may not be super easy and/or practical to do in terms of elisp... i based some of the logic into elisp built in functions to navigate directories + a clojure-mode function... and customize the :jack-in/ready message a bit since I'm not catching it with an EDN reader

pesterhazy10:12:11

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

volrath10:12:38

I'm not saying it wouldn't be easy

pesterhazy10:12:51

ah you want to make things configurable?

volrath10:12:52

just not as practical

volrath10:12:46

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

pesterhazy10:12:49

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

volrath10:12:07

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

volrath10:12:15

maybe we're talking different things

pesterhazy10:12:07

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

volrath10:12:29

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

volrath10:12:34

plus the configuration thing

volrath10:12:27

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

volrath10:12:46

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

pesterhazy10:12:07

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

pesterhazy10:12:04

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

pesterhazy10:12:45

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

volrath10:12:05

of course they can be implemented as shell scripts

volrath10:12:06

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)

volrath10:12:25

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

volrath10:12:46

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

volrath10:12:19

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]+\\)\\]"

volrath10:12:43

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

volrath10:12:56

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

cgrand11:12:33

gibberish prelude can happen with lein trampoline run too

cgrand11:12:12

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

pesterhazy11:12:42

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

cgrand11:12:06

@U06F82LES (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)

volrath11:12:20

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

pesterhazy11:12:16

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

pesterhazy11:12:34

good albeit slightly obscure point @U3E46Q1DG 🙂

volrath11:12:16

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

cgrand11:12:57

$ 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

cgrand11:12:53

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

volrath11:12:25

that's what I'm doing already

pesterhazy11:12:26

switched to your println suggestion @U3E46Q1DG

cgrand11:12:36

yeah I saw

volrath11:12:39

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

pesterhazy11:12:51

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

pesterhazy11:12:22

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

cgrand11:12:58

luckily most descendants do synchronize (eg BufferedOutputStream)