* Org-Babel - Clojure & Lazy Sequences Bug @ 2010-11-04 14:11 Rick Moynihan 2010-11-06 17:58 ` Eric Schulte 0 siblings, 1 reply; 12+ messages in thread From: Rick Moynihan @ 2010-11-04 14:11 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-04 14:11 Org-Babel - Clojure & Lazy Sequences Bug Rick Moynihan @ 2010-11-06 17:58 ` Eric Schulte 2010-11-24 1:51 ` Rick Moynihan 0 siblings, 1 reply; 12+ messages in thread From: Eric Schulte @ 2010-11-06 17:58 UTC (permalink / raw) To: Rick Moynihan; +Cc: emacs-orgmode 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.moynihan@gmail.com> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-06 17:58 ` Eric Schulte @ 2010-11-24 1:51 ` Rick Moynihan 2010-11-25 17:40 ` Eric Schulte 0 siblings, 1 reply; 12+ messages in thread From: Rick Moynihan @ 2010-11-24 1:51 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode 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.eric@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.moynihan@gmail.com> 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-24 1:51 ` Rick Moynihan @ 2010-11-25 17:40 ` Eric Schulte 2010-11-25 18:31 ` Rick Moynihan 0 siblings, 1 reply; 12+ messages in thread From: Eric Schulte @ 2010-11-25 17:40 UTC (permalink / raw) To: Rick Moynihan; +Cc: emacs-orgmode, Joel Boehland [-- Attachment #1: Type: text/plain, Size: 985 bytes --] Hi Rick, I'm not quite sure what the best permanent solution would be. I'm tempted to switch to a drastically stripped down version of Clojure interaction which relies very heavily on slime. I'm attaching a first pass at this which allows for slime-based execution, can assign variables, handles lazy evaluation, etc... The downside to this new version is that it doesn't support buffer-based sessions or external evaluation, but the upside is that it is incredibly simple, and by relying so heavily on slime it should be very robust. Once this is enhanced with some code to start slime, and a simple :session setup (namely the ability to grab the slime context from a buffer specified by :session) I may prefer this to the existing ob-clojure. I'd be interested to hear what others think. Personally I'm happy to lose external evaluation and switch to purely slime-based evaluation, but I don't want to trash it if it is an important part of someones work flow. Best -- Eric [-- Attachment #2: ob-clojure.el --] [-- Type: application/emacs-lisp, Size: 2580 bytes --] [-- Attachment #3: Type: text/plain, Size: 3501 bytes --] Rick Moynihan <rick.moynihan@gmail.com> 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 <schulte.eric@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.moynihan@gmail.com> 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 >> [-- Attachment #4: Type: text/plain, Size: 201 bytes --] _______________________________________________ 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-25 17:40 ` Eric Schulte @ 2010-11-25 18:31 ` Rick Moynihan 2010-11-26 20:29 ` Eric Schulte 0 siblings, 1 reply; 12+ messages in thread From: Rick Moynihan @ 2010-11-25 18:31 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode, Joel Boehland Hey Eric, I've just run your ob-clojure, and it seems to work fine, though as you mention it would be nice if it'd start slime (if it isn't already running). I'm not sure what you mean by "external evaluation", but have found that if I do M-x slime-connect (to connect to an existing clojure/swank vm) that I have access to the same vm, via the *slime-repl* buffer, which is nice. Is this what you were referring to, or was it something else? Having access to other sessions seems like a useful feature, but I've not begun to use these more advanced babel features. Anyway, great work; I really appreciate you working on this! R. On 25 November 2010 17:40, Eric Schulte <schulte.eric@gmail.com> wrote: > Hi Rick, > > I'm not quite sure what the best permanent solution would be. I'm > tempted to switch to a drastically stripped down version of Clojure > interaction which relies very heavily on slime. I'm attaching a first > pass at this which allows for slime-based execution, can assign > variables, handles lazy evaluation, etc... > > The downside to this new version is that it doesn't support buffer-based > sessions or external evaluation, but the upside is that it is incredibly > simple, and by relying so heavily on slime it should be very robust. > > Once this is enhanced with some code to start slime, and a simple > :session setup (namely the ability to grab the slime context from a > buffer specified by :session) I may prefer this to the existing > ob-clojure. > > I'd be interested to hear what others think. Personally I'm happy to > lose external evaluation and switch to purely slime-based evaluation, > but I don't want to trash it if it is an important part of someones work > flow. > > Best -- Eric > > > > Rick Moynihan <rick.moynihan@gmail.com> 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 <schulte.eric@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.moynihan@gmail.com> 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 >>> > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-25 18:31 ` Rick Moynihan @ 2010-11-26 20:29 ` Eric Schulte 2010-11-26 20:53 ` Rick Moynihan 0 siblings, 1 reply; 12+ messages in thread From: Eric Schulte @ 2010-11-26 20:29 UTC (permalink / raw) To: Rick Moynihan; +Cc: emacs-orgmode, Joel Boehland Hey Rick, Rick Moynihan <rick.moynihan@gmail.com> writes: > Hey Eric, > > I've just run your ob-clojure, and it seems to work fine, though as > you mention it would be nice if it'd start slime (if it isn't already > running). > Alright, I'm going to fold this into the master branch (we'll still have the entirety of the existing ob-clojure in git for resurrection if need be). > > I'm not sure what you mean by "external evaluation", but have found > that if I do M-x slime-connect (to connect to an existing > clojure/swank vm) that I have access to the same vm, via the > *slime-repl* buffer, which is nice. Is this what you were referring > to, or was it something else? > So what I mean was execution outside of slime, e.g. by writing a code block to a temporary file and then executing that file with clj-env or some such Clojure scripting command. However the more I think about this the more I'm satisfied with slime, as it allows access to both local and remote virtual machines... > > Having access to other sessions seems like a useful feature, but I've > not begun to use these more advanced babel features. > > Anyway, great work; I really appreciate you working on this! > My pleasure, I use Clojure from within Org-mode files on a regular basis (these days I'm probably writing more Clojure than elisp), so this helps me too. Cheers -- Eric > > R. > > On 25 November 2010 17:40, Eric Schulte <schulte.eric@gmail.com> wrote: >> Hi Rick, >> >> I'm not quite sure what the best permanent solution would be. I'm >> tempted to switch to a drastically stripped down version of Clojure >> interaction which relies very heavily on slime. I'm attaching a first >> pass at this which allows for slime-based execution, can assign >> variables, handles lazy evaluation, etc... >> >> The downside to this new version is that it doesn't support buffer-based >> sessions or external evaluation, but the upside is that it is incredibly >> simple, and by relying so heavily on slime it should be very robust. >> >> Once this is enhanced with some code to start slime, and a simple >> :session setup (namely the ability to grab the slime context from a >> buffer specified by :session) I may prefer this to the existing >> ob-clojure. >> >> I'd be interested to hear what others think. Personally I'm happy to >> lose external evaluation and switch to purely slime-based evaluation, >> but I don't want to trash it if it is an important part of someones work >> flow. >> >> Best -- Eric >> >> >> >> Rick Moynihan <rick.moynihan@gmail.com> 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 <schulte.eric@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.moynihan@gmail.com> 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 >>>> >> >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-26 20:29 ` Eric Schulte @ 2010-11-26 20:53 ` Rick Moynihan 2010-11-26 22:49 ` Eric Schulte 0 siblings, 1 reply; 12+ messages in thread From: Rick Moynihan @ 2010-11-26 20:53 UTC (permalink / raw) To: Eric Schulte; +Cc: emacs-orgmode, Joel Boehland On 26 November 2010 20:29, Eric Schulte <schulte.eric@gmail.com> wrote: > > Alright, I'm going to fold this into the master branch (we'll still have > the entirety of the existing ob-clojure in git for resurrection if need > be). That's great news! >> >> I'm not sure what you mean by "external evaluation", but have found >> that if I do M-x slime-connect (to connect to an existing >> clojure/swank vm) that I have access to the same vm, via the >> *slime-repl* buffer, which is nice. Is this what you were referring >> to, or was it something else? >> > > So what I mean was execution outside of slime, e.g. by writing a code > block to a temporary file and then executing that file with clj-env or > some such Clojure scripting command. However the more I think about > this the more I'm satisfied with slime, as it allows access to both > local and remote virtual machines... Yeah, Slime is great in this regard... >> Having access to other sessions seems like a useful feature, but I've >> not begun to use these more advanced babel features. >> >> Anyway, great work; I really appreciate you working on this! > > My pleasure, I use Clojure from within Org-mode files on a regular basis > (these days I'm probably writing more Clojure than elisp), so this helps > me too. Well if it's your pleasure then I have another feature request for you :-) Basically it looks like the different :results types haven't yet been implemented... The one I was missing was 'code' e.g. the following works for elisp: #+begin_src emacs-lisp :results code '(+ 10 1) #+end_src displaying: #+results: #+BEGIN_SRC emacs-lisp (+ 10 1) #+END_SRC But in clojure I get: #+begin_src clojure :results code '(+ 10 1) #+end_src #+results: | + | 10 | 1 | I looked at implementing this myself, ontop of your recent changes, by running it through edebug, which I've only begun to discover, but I couldn't work it out in the hour I spent looking at it. Any suggestions on where I should look to fix this? R. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-26 20:53 ` Rick Moynihan @ 2010-11-26 22:49 ` Eric Schulte 2010-11-27 8:27 ` Achim Gratz 0 siblings, 1 reply; 12+ messages in thread From: Eric Schulte @ 2010-11-26 22:49 UTC (permalink / raw) To: Rick Moynihan; +Cc: emacs-orgmode, Joel Boehland Rick Moynihan <rick.moynihan@gmail.com> writes: > > Basically it looks like the different :results types haven't yet been > implemented... The one I was missing was 'code' e.g. the following > works for elisp: > > #+begin_src emacs-lisp :results code > '(+ 10 1) > #+end_src > > displaying: > > #+results: > #+BEGIN_SRC emacs-lisp > (+ 10 1) > #+END_SRC > > But in clojure I get: > > #+begin_src clojure :results code > '(+ 10 1) > #+end_src > > #+results: > | + | 10 | 1 | > I've just pushed up an implementation of this feature. It uses Clojure's pretty printer which has different settings for printing code and data. This can be controlled through use of the "code" (for code) and "pp" (for data) arguments to :results, here's example output with the new implementation. #+begin_src clojure :results pp '(defn cl-format "An implementation of a Common Lisp compatible format function" [stream format-in & args] (let [compiled-format (if (string? format-in) (compile-format format-in) format-in) navigator (init-navigator args)] (execute-format stream compiled-format navigator))) #+end_src #+results: #+begin_example (defn cl-format "An implementation of a Common Lisp compatible format function" [stream format-in & args] (let [compiled-format (if (string? format-in) (compile-format format-in) format-in) navigator (init-navigator args)] (execute-format stream compiled-format navigator))) #+end_example #+begin_src clojure :results code '(defn cl-format "An implementation of a Common Lisp compatible format function" [stream format-in & args] (let [compiled-format (if (string? format-in) (compile-format format-in) format-in) navigator (init-navigator args)] (execute-format stream compiled-format navigator))) #+end_src #+results: #+BEGIN_SRC clojure (defn cl-format "An implementation of a Common Lisp compatible format function" [stream format-in & args] (let [compiled-format (if (string? format-in) (compile-format format-in) format-in) navigator (init-navigator args)] (execute-format stream compiled-format navigator))) #+END_SRC ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-26 22:49 ` Eric Schulte @ 2010-11-27 8:27 ` Achim Gratz 2010-11-27 15:20 ` Eric Schulte 0 siblings, 1 reply; 12+ messages in thread From: Achim Gratz @ 2010-11-27 8:27 UTC (permalink / raw) To: emacs-orgmode "Eric Schulte" <schulte.eric@gmail.com> writes: > I've just pushed up an implementation of this feature. I'm afraid byte-compile doesn't like it: In org-babel-expand-body:clojure: ob-clojure.el:63:26:Warning: reference to free variable `result-params' :-) Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-27 8:27 ` Achim Gratz @ 2010-11-27 15:20 ` Eric Schulte 2010-11-28 23:23 ` Rick Moynihan 0 siblings, 1 reply; 12+ messages in thread From: Eric Schulte @ 2010-11-27 15:20 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Fixed, Thanks -- Eric Achim Gratz <Stromeko@nexgo.de> writes: > "Eric Schulte" <schulte.eric@gmail.com> writes: >> I've just pushed up an implementation of this feature. > > I'm afraid byte-compile doesn't like it: > > In org-babel-expand-body:clojure: > ob-clojure.el:63:26:Warning: reference to free variable `result-params' > > > :-) > > > Achim. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-27 15:20 ` Eric Schulte @ 2010-11-28 23:23 ` Rick Moynihan 2010-11-29 3:59 ` Eric Schulte 0 siblings, 1 reply; 12+ messages in thread From: Rick Moynihan @ 2010-11-28 23:23 UTC (permalink / raw) To: Eric Schulte; +Cc: Achim Gratz, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 986 bytes --] Hey Eric, thanks for the changes... I tried them locally and they didn't work as some of the pprint functions you were using weren't fully qualified. I've attached a small patch with the fixes. Also it's worth noting for anyone else that clojure 1.2.0(+) is required for this to work. Thanks again for working on this, R. On 27 November 2010 15:20, Eric Schulte <schulte.eric@gmail.com> wrote: > Fixed, Thanks -- Eric > > Achim Gratz <Stromeko@nexgo.de> writes: > >> "Eric Schulte" <schulte.eric@gmail.com> writes: >>> I've just pushed up an implementation of this feature. >> >> I'm afraid byte-compile doesn't like it: >> >> In org-babel-expand-body:clojure: >> ob-clojure.el:63:26:Warning: reference to free variable `result-params' >> >> >> :-) >> >> >> Achim. > > _______________________________________________ > 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 > [-- Attachment #2: ob-clojure.patch --] [-- Type: text/x-patch, Size: 894 bytes --] From 4c05743905a1ab3970d7f5075440e67e1be9d7f3 Mon Sep 17 00:00:00 2001 From: Rick Moynihan <rick@wgrids.com> Date: Sun, 28 Nov 2010 23:21:02 +0000 Subject: [PATCH] Fixed babel pretty printing, by fully qualifying function names --- lisp/ob-clojure.el | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el index e41bf15..a5e8c72 100644 --- a/lisp/ob-clojure.el +++ b/lisp/ob-clojure.el @@ -63,7 +63,7 @@ (if (or (member "code" result-params) (member "pp" result-params)) (format (concat "(let [org-mode-print-catcher (java.io.StringWriter.)]" - "(with-pprint-dispatch %s-dispatch" + "(clojure.pprint/with-pprint-dispatch clojure.pprint/%s-dispatch" "(clojure.pprint/pprint %s org-mode-print-catcher)" "(str org-mode-print-catcher)))") (if (member "code" result-params) "code" "simple") body) -- 1.7.0.4 [-- Attachment #3: Type: text/plain, Size: 201 bytes --] _______________________________________________ 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Re: Org-Babel - Clojure & Lazy Sequences Bug 2010-11-28 23:23 ` Rick Moynihan @ 2010-11-29 3:59 ` Eric Schulte 0 siblings, 0 replies; 12+ messages in thread From: Eric Schulte @ 2010-11-29 3:59 UTC (permalink / raw) To: Rick Moynihan; +Cc: Achim Gratz, emacs-orgmode Hi Rick, Thanks for catching this, I've just pushed up your fix. -- Eric Rick Moynihan <rick.moynihan@gmail.com> writes: > Hey Eric, thanks for the changes... I tried them locally and they > didn't work as some of the pprint functions you were using weren't > fully qualified. I've attached a small patch with the fixes. > > Also it's worth noting for anyone else that clojure 1.2.0(+) is > required for this to work. > > Thanks again for working on this, > > R. > > On 27 November 2010 15:20, Eric Schulte <schulte.eric@gmail.com> wrote: >> Fixed, Thanks -- Eric >> >> Achim Gratz <Stromeko@nexgo.de> writes: >> >>> "Eric Schulte" <schulte.eric@gmail.com> writes: >>>> I've just pushed up an implementation of this feature. >>> >>> I'm afraid byte-compile doesn't like it: >>> >>> In org-babel-expand-body:clojure: >>> ob-clojure.el:63:26:Warning: reference to free variable `result-params' >>> >>> >>> :-) >>> >>> >>> Achim. >> >> _______________________________________________ >> 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 >> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-11-29 3:59 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-04 14:11 Org-Babel - Clojure & Lazy Sequences Bug Rick Moynihan 2010-11-06 17:58 ` Eric Schulte 2010-11-24 1:51 ` Rick Moynihan 2010-11-25 17:40 ` Eric Schulte 2010-11-25 18:31 ` Rick Moynihan 2010-11-26 20:29 ` Eric Schulte 2010-11-26 20:53 ` Rick Moynihan 2010-11-26 22:49 ` Eric Schulte 2010-11-27 8:27 ` Achim Gratz 2010-11-27 15:20 ` Eric Schulte 2010-11-28 23:23 ` Rick Moynihan 2010-11-29 3:59 ` Eric Schulte
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).