Rick Moynihan writes: > Hi Eric, > > Sorry for the delay in getting back to you. > > I can confirm the fix you quoted below works for me also. > > I've not been using any of the multiple session features, so I haven't > run into the other problems you mention. > > Any idea on what a more permanent solution might be? > > R. > > On 6 November 2010 17:58, Eric Schulte wrote: >> Hi Rick, >> >> I've noticed this as well.  I'm not the original author of ob-clojure.el >> (Joel Boehland is), so I'm not sure how the clojure interaction >> currently works, although I know it makes heavy usage of slime.  There >> must be an existing mechanism used by slime to unroll these lazy >> evaluations, for example in the repl (range 10) *is* expanded >> >> user> (range 10) >> (0 1 2 3 4 5 6 7 8 9) >> >> I'm using clojure extensively in my studies so I have all the more >> reason to try to figure this out.  I'll put this on my stack. >> >> BTW: I've noticed that I am unable to get Clojure code blocks to play >> nicely with existing slime sessions, say for example I have some large >> piece of data in scope in a slime sessions and I'd like to access that >> data from a clojure code block and dump some analysis to an Org-mode >> document.  I have not yet found out how to make this work.  If you have, >> I'd love to hear how, otherwise I'll look into this as well. >> >> Best -- Eric >> >> Having just looked at this quickly, the following function over-defines >> `org-babel-execute:clojure' s.t.  the body of the code block is sent to >> the superior list in the same manner as when calling `slime-eval-defun' >> from within a .clj file.  While this doesn't handle starting up clojure >> instances or differentiate between session and external evaluation it >> should fix the issues mentioned above and could be the beginning of a >> permanent solution. >> >> #+begin_src emacs-lisp >>  (defun org-babel-execute:clojure (body params) >>    (with-temp-buffer >>      (insert body) >>      (read >>       (slime-eval >>        `(swank:interactive-eval-region >>          ,(buffer-substring-no-properties (point-min) (point-max))))))) >> #+end_src >> >> which then results in >> >> #+begin_src clojure >>  (map (fn [el] (list el (* el el))) (range 10)) >> #+end_src >> >> evaluating to >> >> #+results: >> | 0 |  0 | >> | 1 |  1 | >> | 2 |  4 | >> | 3 |  9 | >> | 4 | 16 | >> | 5 | 25 | >> | 6 | 36 | >> | 7 | 49 | >> | 8 | 64 | >> | 9 | 81 | >> >> Rick Moynihan writes: >> >>> I have the following org file: >>> >>> #+BEGIN_SRC clojure >>> (range 10) >>> #+END_SRC >>> >>> #+results: >>> : clojure.lang.LazySeq@f35bf8c6 >>> >>> Where as I would expect to see the sequence.  Evaluating the code >>> inside a doall doesn't seem to do anything either: >>> >>> #+BEGIN_SRC clojure >>> (doall (range 10)) >>> #+END_SRC >>> >>> #+results: >>> : clojure.lang.LazySeq@f35bf8c6 >>> >>> Is there any parameter I can pass to the block to get the code to >>> execute in a doall and return the sequence values rather than the >>> lazy-seq object itself? >>> >>> R. >>> >>> _______________________________________________ >>> Emacs-orgmode mailing list >>> Please use `Reply All' to send replies to the list. >>> Emacs-orgmode@gnu.org >>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode >>