My workflow for starting a "boot dev" process within emacs for using it with cider afterwards was something like this:
go to a shell buffer.
enter "boot dev"
wait until the message "Time Elapsed..."
cider-connect (Enter, Enter)
In the case it is a ClojureScript Project, one could start a browser repl with:
(start-repl)
When using cider-jack-in to ease this a bit I get problems with the last step, the ClojureScript repl. Here's the beginning of the error message:
boot.user> (start-repl)
<< started Weasel server on ws://127.0.0.1:45341 >>
<< waiting for client to connect ... java.lang.NullPointerException
at clojure.java.io$make_parents.invokeStatic(io.clj:443)
at clojure.java.io$make_parents.doInvoke(io.clj:438)
at clojure.lang.RestFn.invoke(RestFn.java:410)
(the full message can be found here: http://pastebin.com/chBNByKG)
I did add a ~/.boot/profile.boot according to the cider manual.
Use cider-jack-in-clojurescript (C-c M-J by default) instead of cider-jack-in to get the ClojureScript REPL. (Or connect to an external REPL.) It doesn't work otherwise, at least with the current CIDER (0.14 at the time or writing.)
Related
I try to install slime in emacs. I follow many manuals and got one oucome.
"M-x slime" trow exeption "process inferior-lisp exited abnormally with code 5"
OS Windows 8.1
GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of
2018-05-30
SBCL 1.4.2
SLIME 2.22
My .emacs file text
(setq inferior-lisp-program "C:/SBCL/sbcl.exe")
(add-to-list 'load-path "C:/slime/")
(require 'slime)
Following the comment, I tried to understand where the installation falls
-(load #P"C:/slime/swank-loader")
-T
-(swank-loader::init :reload t)
-WARNING: redefining EMACS-INSPECT (#(SB-PCL:SYSTEM-CLASS COMMON-LISP:T)) in DEFMETHOD
NIL
-(swank:create-server :port 7777)
;;Swank started at port:7777
In Emacs
-M-x slime-connect
Host: localhost
Port: 7777
-Lisp connection closed unexpectedly: connection broken by remote peer
In other topics where i saw that error message, peoples run complex sourcecode with mistakes. The problem was solved by correcting errors. It seems like different situation or i don't understand something.
This is too long for a comment.
You need to find out at which layer the problem occurs. Try for example to run SBCL in a shell with the same command-line (e.g. C:/SBCL/sbcl.exe); if it works, in the REPL:
CL-USER> (load #P"C:/slime/swank-loader")
If that works, you can manually init the swank backend (the Common Lisp part of the Slime/Swank protocol).
CL-USER> (swank-loader::init :reload t)
Then, try to start a server (the port value is arbitrary):
CL-USER> (swank:create-server :port 7777)
If a server starts, you can try to run slime-connect from Emacs, using the localhost port and the same port.
Oleg, try to give ip address 127.0.0.1 instead of localhost when doing slime-connect. I have similar problem on OSX when connecting to a remote SLIME server.
attempting to start cider with M-x cider-jack-in with clojure project file in current buffer on Emacs 24.4.1. I get error in process sentinel: Could not start nREPL server
does nREPL need separate installation...is this an error anyone else is experiencing with 24.4.1?
messages buffer:
Starting nREPL server via /usr/bin/lein update-in :dependencies conj \[org.clojure/tools.nre\
|11:56:07 hello: |pl\ \"0.2.12\"\] -- update-in :plugins conj \[cider/cider-nrepl\ \"0.14.0-SNAPSHOT\"\] -- re\
|11:56:07 hello: |pl :headless...
|11:56:08 hello: |error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: ^[[?25h^[[0G\
Simple matter of having the correct versions of lein and clojure(script) and rtfm on https://github.com/clojure-emacs/cider-nrepl. To solve this I had to upgrade clojure to 1.7+ and lein to 2.5.2. After these upgrades everything worked nicely.
Consider the following scenario:
A minimal boot task starts up a http server:
(boot (serve :handler 'myapp.server/handler
:port 3000))
(This might be launched in several ways, here it's ok to just run it from a nrepl session, e.g. started by boot repl from the terminal)
The handler is represented by the function handler inside the namespace myapp.server. The corresponding file looks like this:
(ns myapp.server (:require ...))
(defonce server-state (atom {:nr 0}))
(defn handler [req]
(prn (swap! server-state update :nr inc))
{:body "Answer.\n"})
This works, every time the address localhost:3000 is visited the the atom is updated and the new version is printed to stdout inside the repl.
How can the atom been inspected at any time?
boot.user=> #myapp.server/server-state
yields an error. (...no such var...)
When trying the same thing from within an emacs cider nrepl connection, this previous attempt always shows up the initial value of the atom: {:n 0}
UPDATE
Here are the exact steps I do when using emacs/cider:
cd projectdir
start emacs
cider-jack-in
(boot (dev))
Ctrl+C+C (in order to get a prompt again.)
Then Testing with curl: getting responses + inside emacs updated atom is logged: {:n 1} .. {:n 2} ..
Then, in the repl: (require 'myapp.server), takes a while: nil.
finally: #myapp.server/state --> however: {:n 0}
Your (...no such var...) error probably happens because you haven't require the myapp.server namespace. Attempts to see updates happening to your atom in CIDER REPL fail probably because your ring app runs in another JVM process than your REPL so the REPL sees only initial value as updates from ring handler happen in another JVM or it is enclosed in a separated classloader as it might be isolated by boot POD.
You have two options:
start your ring app with REPL server enabled and connect to it from another process (for example by using Server Socket REPL and connecting to it using telnet)
start your REPL and then start your ring app from it and you have access to all your loaded namespaces.
With the first approach you probably need to use boot-clj's nrepl option. When you configure it to start nREPL server then you can connect to it using boot repl -c (optionally providing the same coordinates as to boot-http nrepl options) or directly from CIDER using cider-connect.
I recently tried to set up AucTeX SyncTeX with evince under GNU Emacs 24.4. From an ordinary emacs session it work oput of the box after activating TeX-source-correlate-mode, but under my standard Daemon session Dbus refuses to work properly. TeX-Evince-sync-view fails with a DBus 'no conncetion' error, so I tried M-: (dbus-init-bus :system) but that returns ((:signal :system "org.freedesktop.DBus.Local" "Disconnected") (nil "/org/freedesktop/DBus/Local" dbus-handle-bus-disconnect))
and M-: dbus-init-bus :session fails accordingly with 'no connection'.
Does anyone know how to get DBus running properly under Emacs in Daemon mode?
When you connect to D-Bus from Emacs, it must know where the respective dbus-daemon resides. Usually, it knows it via the environment variable $DBUS_SESSION_BUS_ADDRESS. So set this variable in your daemonized Emacs before you call (dbus-init-bus :session) or alike
I am writing an integration test that needs to start up several applications. One of these applications is a Play one as a SBT project called appA.
I am able to start the app on the right port using scala.sys.process as follows:
import scala.sys.process._
import org.scalatest._
class Main extends FeatureSpec with Matchers{
val app = Seq("sbt", "project appA", "run 7777").run
println(app.exitValue)
}
The spawned application however exits immediately with return value 0. No errors are displayed to the console. I just see:
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:3000
(Server started, use Ctrl+D to stop and go back to the console...)
[success] Total time: 1 s, completed Feb 27, 2014 10:26:56 PM
0
The 0 at the end of the output is from calling exitValue on the created process. exitValue blocks until the spawned process exits.
How can I run the Play application without it exiting immediately? Is there a better way to start the application?
SBT has 2 run modes - interactive and batch. If you run without any args it goes to interactive mode and does not exit. When you run it by passing commands it runs in a batch mode and exits when the last command is complete. It does not matter if your application inside SBT runs in a forked JVM or not.
Thus to "fix" it you can apply this hack: add ~ command to the end of the list of sbt commands/args:
val app = Seq("sbt", "project appA", "run 7777", "~").run
~ is used to watch source code for changes and recompile when it happens. Thus SBT will never exit unless stopped by a user or killed.
A cleaner way would be to run Play application in a Jetty container (assuming you have WAR to run) or such by calling a main class that starts up Jetty with a command like java com.example.MyMain but that requires additional setup.