This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-05
Channels
- # adventofcode (419)
- # aleph (8)
- # aws (6)
- # beginners (148)
- # boot (9)
- # cider (24)
- # cljs-dev (37)
- # cljsjs (8)
- # clojure (134)
- # clojure-android (6)
- # clojure-brasil (15)
- # clojure-dev (8)
- # clojure-dusseldorf (2)
- # clojure-greece (67)
- # clojure-italy (8)
- # clojure-japan (3)
- # clojure-russia (3)
- # clojure-spec (8)
- # clojure-uk (13)
- # clojurescript (54)
- # clojurex (6)
- # cursive (5)
- # data-science (12)
- # datomic (15)
- # defnpodcast (11)
- # emacs (25)
- # fulcro (95)
- # graphql (3)
- # lein-figwheel (1)
- # leiningen (27)
- # luminus (1)
- # lumo (6)
- # mount (2)
- # off-topic (112)
- # om (3)
- # onyx (24)
- # perun (3)
- # re-frame (20)
- # reagent (1)
- # reitit (2)
- # ring-swagger (13)
- # rum (10)
- # shadow-cljs (45)
- # spacemacs (24)
- # sql (2)
- # unrepl (78)
- # yada (1)
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
but the end result is so pretty ๐, and the answer to your question will most likely be: "nope, my repl cannot!"
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
Although maybe that's ok?
lein trampoline run
might be safer
jinx!
what does CIDER do?
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?
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
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
ah you want to make things configurable?
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
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
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?
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)
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]+\\)\\]"
having said that, I do agree it would be nice to have a standalone module for this and be able to constantly test it
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
@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)
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
Clojure's read-string reads the first complete form and then stops - does your edn.el work differently?
good albeit slightly obscure point @U3E46Q1DG ๐
$ 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
switched to your println suggestion @U3E46Q1DG
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