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 <schulte.e...@gmail.com> 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 <rick.moyni...@gmail.com> writes: > >> I have the following org file: >> >> #+BEGIN_SRC clojure >> (range 10) >> #+END_SRC >> >> #+results: >> : clojure.lang.lazy...@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.lazy...@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 > _______________________________________________ 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
