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
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.
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.)
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 am installing Hunchentoot on a new machine. This time I thought I would try out Lispy, because it appears to be simplest way of managing the dependencies for Hunchentoot in a standard and hopefully automatic way. However, when I install it, it trips on not being able to verify a key. I have seen ASDF-INSTALL try to use a key before, and I have normally found some way to skip verifying the key. I don't really need that kind of security, I trust the people distributing these packages, OK? Anyway, in this case there is no restart to skip the key, so rather than dig into the code and hack my way out of it, I was wondering if there is a more correct way to deal with this. I assume Lispy isn't supposed to be broken and I am using the most standard and supported environment imaginable for Common Lisp: Ubuntu + sbcl. I figure I could make this work, but then again I could just install all the dependencies for Hunchentoot manually using ASDF-INSTALL just as easily, so I figure I'll give Lispy a shot and do it in a more controlled and correct way. Here's the actual log of what I did, cutting out most of the in-between messages:
* (load "asdf-config.lisp")
T
* (asdf:oos 'asdf:load-op :lispy)
; loading system definition from /home/rob/lispy/lispy-0.5/lispy.asd into
...
2010-01-06 23:13:25 "Initializing Lispy system on SBCL 1.0.29.11.debian"
2010-01-06 23:13:25 "Fetching http://common-lisp.net/project/lispy/repository/map.lisp-expr"
2010-01-06 23:13:27 "Fetching http://common-lisp.net/project/lispy/repository/map.lisp-expr.asc"
gpg: Signature made Fri 25 Dec 2009 01:19:20 PM EST using DSA key ID 7CF49723
gpg: Can't check signature: public key not found
debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" RUNNING {AA5E5E9}>:
GPG verification of map /var/cache/common-lisp-controller/1000/sbcl/local/home/rob/lispy/maps/map.lisp-expr with signature /var/cache/common-lisp-controller/1000/sbcl/local/home/rob/lispy/maps/map.lisp-expr.asc failed: "gpg: Signature made Fri 25 Dec 2009 01:19:20 PM EST using DSA key ID 7CF49723
gpg: Can't check signature: public key not found
"
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {AAA7F01}> on
#<ASDF:SYSTEM "lispy" {ABF01E9}>.
1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {AAA7F01}> on
#<ASDF:SYSTEM "lispy" {ABF01E9}> as having been successful.
2: [ABORT ] Exit debugger, returning to top level.
(LISPY::VERIFY-MAP
#P"/var/cache/common-lisp-controller/1000/sbcl/local/home/rob/lispy/maps/map.lisp-expr.asc"
#P"/var/cache/common-lisp-controller/1000/sbcl/local/home/rob/lispy/maps/map.lisp-expr"
#<PURI:URI http://common-lisp.net/project/lispy/repository/map.lisp-expr>)
Install gpg
wget http://common-lisp.net/project/lispy/key.asc
gpg --import key.asc
You should be good to go.
Have you tried quicklisp? It is amazing.
Oh wow, I just discovered a number of lisp packages are in Ubuntu's apt repository, including Hunchentoot. Amazing! How did I not know about this?