Hi Eric,
No problem with the "slow" reply. Thanks for the fix, which gets me back
up and running.
All the best,
Tom
Eric Schulte writes:
> Hi Tom,
>
> Sorry about the slow reply, I've been busy as usual.
>
> I just pushed up a fix for this problem. As you've discovered, the
> slime function r
Hi Tom,
Sorry about the slow reply, I've been busy as usual.
I just pushed up a fix for this problem. As you've discovered, the
slime function returns a two-element list holding any strings written to
STDOUT, and the value of the evaluated code. In two different places
org-babel-execute:lisp wa
Hi Eric,
I understand this a bit better now.
In org-babel-execute:lisp, the local variable result is getting set to
("" "2").
With :results value, the call to read in org-babel-result-cond is being
passed "2" when it expects a list. With :results output, it gets "",
which triggers the same erro
Hi Eric,
An edebug adventure :)
AFAICT, the error is thrown by this call to a macro:
(org-babel-result-cond ("replace") (car result)), where result has been
set to "2" by the long (funcall) in (let).
Specifically, (org-babel-lisp-vector-to-list "2") appears to trigger the
(error)--at least that
Hi Tom,
That example works for me. Perhaps you could edebug (C-u C-M-x) the
`org-babel-execute:lisp' function and then run that code block again to
see at which statement the error is thrown.
I'm not sure what the problem could be.
Best,
t...@tsdye.com (Thomas S. Dye) writes:
> Hi Eric,
>
> #
Hi Eric,
#+begin_src lisp
(+ 1 1)
#+end_src
Debugger entered--Lisp error: (wrong-type-argument listp "2")
byte-code("\211A@)\207" [result x] 2)
org-babel-execute:lisp("(+ 1 1)" ((:comments . "") (:shebang . "") (:cache .
"no") (:padline . "") (:noweb . "yes") (:tangle . "no") (:exports . "c
Hi Tom,
Could you provide a minimal example? I'm unable to debug from the stack
trace alone.
Thanks,
t...@tsdye.com (Thomas S. Dye) writes:
> Aloha all,
>
> With a recent pull, Lisp code blocks that I'm fairly certain were
> working previously started to fail. There is a backtrace below. The L
Aloha all,
With a recent pull, Lisp code blocks that I'm fairly certain were
working previously started to fail. There is a backtrace below. The Lisp
code executes correctly, but Babel doesn't appear to get the results in
the form it expects (if I'm reading the backtrace correctly).
Have I mucked
