Environment
OS: OS X Yosemite (10.10.4)
GNU Emacs 24.5.1
CIDER 0.14.0snapshot (package: 20160806.2354)
[org.clojure/tools.nrepl "0.2.12"]
[cider/cider-nrepl "0.14.0-SNAPSHOT"]
If I run this code
(defmacro foo []
(println "column:" (-> &form meta :column)))
(defn bar []
(foo)
(foo))
(foo)
(foo)
print results of inside bar function are
column: 1
column: 2
however, print results of outside bar function are
column: 0
column: 1
I expected both results became same column number but didn't.
Is this correct behavior? If so, please let me know the reason why column index is different inside and outside of a function.
Additional Information
The output results when using lein repl and (require target-file) are same, also the output when using cider-jack-in and cider-load-buffer are same. The problem has occurred when using cider-jack-in and cider-eval-last-sexp.
This behaviour is a bug of cider. I created an issue on cider github.
Related
I am facing a strange behaviour. When using SBCL (Common Lisp) within Emacs via Slime, after ASDF is used, slime-autodoc does not propose arguments list for functions/macros any more.
I am working with SBCL 2.2.6 + ASDF 3.3.6, within Emacs 28.1 with Slime 2.27.
End goal: I would like that, when I write code, I am proposed the arguments of the version/macro.
For instance, when I type "(elt ", the mini-buffer should show: "(elt SEQUENCE INDEX)"
For this purpose, I use slime-autodoc, which works fine... except after ASDF is used.
Exemple...
(1) I open SBCL REPL via M-x slime
(2) I define a simple function (defun foo (x) (+ x x))
Autodoc works: if I type "(foo ", it reminds me "(foo X)"
By the way (swank::autodoc '("foo" swank::%cursor-marker%)) returns ("(foo x)" T) and (swank::arglist #'foo) returns (X) NIL
This is OK.
(3) Then I use ASDF to load a personal basic project, with nothing specific (functions working on integers).
(swank:operate-on-system-for-emacs "toolbox" 'load-op)
(4) Then I define a new simple function (defun bar (y) (+ y y))
Autodoc does not work any more:
when I type "(bar ", it shows "(bar)" in mini-buffer instead of "(bar Y")
With no surprise: (swank::autodoc '("bar" swank::%cursor-marker%)) returns ("(bar)" T) instead of ("(bar Y)" T) and (swank::arglist #'bar) returns () NIL, instead of (Y) NIL
This is not OK.
Important note: autodoc still works for 'foo' function previously defined in (2). It still proposes argument 'X' for it.
I cannot interpret it. It is as if foo and bar were not in the same 'space', as if the use of ASDF has changed the 'space' where things are created. However, we are apparently still in CL-USER package.
I have the following code in a buffer (file ~/firsts.lsp):
(defun firsts (l)
(cond
((null l) ())
(T (cons (car (car l)) (firsts (cdr l))))))
(firsts '((A B) (C D) (E F)))
I would like to "run" this script and see the following output (or a reasonable variant thereof):
(A C E)
My buffer shows this mode:
(Lisp [COMMON-LISP-USER cmucl] adoc)
In trying to run it, I tried C-c C-k, which created a buffer slime-compilation that showed the file was "compiled" without errors, but I do not see a way to get the compiled code to execute or run the entire script through the interpreter.
Slime is installed and running (it's what coordinates the compilation). I know that I can run the forms through the repl, in a form by form manner, but I would like to run the entire script interactively.
Software Environment:
Mac OS X 10.12.3
GNU Emacs 25.1.1
Slime ChangeLog dates 2016-04-19
CMU Common Lisp 21b (21B Unicode) but same result with SBCL 1.3.14
One can imagine various ways how a Lisp source editor and a Listener (a read-eval-print-loop) work together. While SLIME is generally quite good, some of the interaction is slightly clumsy.
In this case there I use three ways to evaluate a buffer with SLIME/Emacs:
select the region, then evaluate the region using SLIME
SLIME eval buffer
save buffer, load buffer or compile-and-load buffer using SLIME
Note that if you evaluate things, results are printed in the mini buffer.
You also want to actually print something, so that you can see what happens.
Compiling things before loading/executing can help find errors. I use that often.
The actual list of key-commands for a buffer is seen on control-h m.
Side notes about interaction when evaluating a buffer
Another interaction style would be to feed each expression to a listener/repl buffer, have the results print there, until an error happens or there are no more expressions. But I don't think SLIME supports that in a direct way.
The LispWorks IDE lets you evaluate a buffer and the output (incl. the evaluation results) is displayed in a corresponding output pane.
The Clozure CL IDE lets you evaluate a buffer and the expressions are evaluated in the top most listener. Printed is the output and the last result.
So I just got Land of Lisp and started to do the first program.
I have a couple questions.
Is there a way to just write some code and run it through a compiler, or interpreter, and not use the REPL thing? I don't like it much. I can't seem to go back if I messed up. It just kinda says "Ha you screwed up, retype that whole function."
I would also like to know what the point of REPL is.
Non-REPL work flow
Edit your file
Compile the file using compile-file; fix errors and warnings; repeat.
Load the file using load; evaluate the form you want; repeat
Example
$ cat > f.lisp <<EOF
(defun f (x) (if (zerop x) 1 (* (f (1- x)) x)))
EOF
$ clisp -q -norc -c f.lisp
;; Compiling file /home/sds/f.lisp ...
;; Wrote file /home/sds/f.fas
0 errors, 0 warnings
$ clisp -q -norc -i f.fas -x '(f 10)'
;; Loading file f.fas ...
;; Loaded file f.fas
3628800
$
The Right Way
Use an IDE, e.g., Emacs with SLIME.
This way, you edit the code in an editor which supports auto-indent and shows you help for each standard symbol.
You compile and test the functions as soon as you write them, giving you a very short development cycle. Under the hood this is accomplished by the IDE interacting with the REPL (this answers your last question).
What is REPL?
Read-Eval-Print loop is a faster, more versatile version of the Edit-Compile-Run loop.
Instead of operating in terms of whole programs (which can be slow to compile and whose execution can be tedious to navigate to the specific location being tested), you operate in terms of a specific function you work on.
E.g., in gdb, you can execute a function with print my_func(123), but if you change my_func, you have to recompile the file and relink the whole executable, and then reload it into gdb, and then restart the process.
With Lisp-style REPL, all you need to do is re-eval the (defun my-func ...) and you can do (my-func 123) at the prompt.
When passing arguments to code block that exports results Org-mode fails to export with the error "Wrong type argument: listp". How can I fix this?
Here is an example. When it is exported it gives the error 'Wrong type argument: listp, "bar"'.
#+TITLE: Example
#+SOURCE: example-one
#+BEGIN_SRC emacs-lisp :exports results
(setq foo "bar")
#+END_SRC
#+SOURCE: example-two
#+BEGIN_SRC emacs-lisp :exports results :var x=example-one
(setq foo (concat x x))
#+END_SRC
I am running Org-mode 7.6 in Emacs 23.3.1.
This issue might simply be with the older copy of Org that you're running. Tested it today with a recent git pull and get the results below. As pmr suggested, you might have better luck asking on the mailing list ( emacs-orgmode#gnu.org ) since there might be someone there who would know what caused this issue and what might have been changed to resolve it in later versions.
The features and examples discussed in the manual are based on the current release version (7.8.03 in this case) so they will not always be compatible with older versions. Does the info-node in your version indicate that it should work?
These 2 commands will show you the associated info-nodes for that section of the Org Manual
; The node itself
(Info-goto-node "(org) var")
; Parent node, in case the first node isn't present
(Info-goto-node "(org) Working With Source Code")
Test Results
Org
* Test variable passing
Headlines are created to split the code blocks apart. When trying to eval on export I'm getting a syntax read error which was reported here: http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00993.html
** Ex 1
#+name: example-one
#+BEGIN_SRC emacs-lisp :exports results
(setq foo "bar")
#+END_SRC
** Ex 2
#+name: example-two
#+BEGIN_SRC emacs-lisp :exports results :var x=example-one
(setq foo (concat x x))
#+END_SRC
Latex
\vspace*{1cm}
Headlines are created to split the code blocks apart. When trying to eval on export I'm getting a syntax read error which was reported here: \href{http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00993.html}{http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00993.html}
\section{Ex 1}
\label{sec-1}
\begin{verbatim}
bar
\end{verbatim}
\section{Ex 2}
\label{sec-2}
\begin{verbatim}
barbar
\end{verbatim}
in your .emacs file - make sure you have the following line:
(setq org-babel-load-languages
(quote ((emacs-lisp . t))))
I have installed LispBox on Windows and it's running great. I do however have some trouble with debugging code : when I try and compile code and it contains an error such as a syntax error, the error message output (printed below) is not very useful.
Serious errors encountered during compilation of
"d:/Jervis/Documents/Programming/LISP/hw1.lisp"
[Condition of type SIMPLE-ERROR]
0: (CCL::%COMPILE-FILE "d:/Jervis/Documents/Programming/LISP/hw1.lisp" "d:/Jervis/Documents/Programming/LISP/hw1.wx64fsl" T NIL T T NIL T :DEFER NIL #<BACKEND WIN64 #x21001C6FCD> :DEFAULT NIL 0)
1: (COMPILE-FILE #P"d:/Jervis/Documents/Programming/LISP/hw1.lisp" :OUTPUT-FILE #P"d:/Jervis/Documents/Programming/LISP/hw1.wx64fsl" :VERBOSE T :PRINT NIL :LOAD NIL :FEATURES NIL :TARGET :WIN64 :SAVE-LOC..
2: (SWANK-BACKEND:CALL-WITH-COMPILATION-HOOKS #<CCL:COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK-BACKEND:SWANK-COMPILE-FILE) #x2100C2730F>)
3: ((:INTERNAL SWANK:COMPILE-FILE-FOR-EMACS))
Does anyone know how to get the line number of the code that is causing the compilation errors?
I have tried to follow the advice here of opening the Compiler Input buffer but that did not work. (The buffer was unavailable, and thus couldn't be opened).
Any Ideas?
A clarification first: the *Compiler Input* buffer you mention has nothing to do with Common Lisp and Slime, it is about errors that Emacs encountered when compiling Emacs Lisp (its internal lisp, quite different from CL).
As for your problem (determining a file name/line number to narrow down the problem): when I enter a broken piece of code in a file (say test.lisp):
(defun fact (n)
(if (= 0 n)
1
!(* n (facto (1- n)))))
, then try to send it to CCL via Slime by pressing C-c C-k in the test.lisp buffer, I get an error and a list of restarts (below the list of restarts there's also a backtrace similar to what you got). Select restart 0 by pressing 0, then 'n' to not load the broken compiled file into CCL. The buffer with the error should be replaced with a buffer named *slime-compilation*, which in my case contains:
cd d:/tmp/lispbox-0.7/
2 compiler notes:
test.lisp:2:5:
warning: Extra arguments in (IF (= 0 N) 1 ! (* N (FACTO (1- N)))) don't match lambda list (CCL::TEST CCL:TRUE &OPTIONAL CCL:FALSE).
style-warning: Unused lexical variable N
Compilation failed.
, which looks like it's what you wanted.
My hand-installed Linux CL setup doesn't need selecting the 0 restart and there's also a slime setting to avoid the 'load fasl file anyway (y/n)' prompt, so the experience can get better with some customization.