emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rick Moynihan <rick.moynihan@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode@gnu.org, Joel Boehland <joel.boehland@evocomputing.com>
Subject: Re: Org-Babel - Clojure & Lazy Sequences Bug
Date: Thu, 25 Nov 2010 18:31:48 +0000	[thread overview]
Message-ID: <AANLkTi=iVVCy7X3a47WS0=eV68bp3sa7YS8-6fnf7d4T@mail.gmail.com> (raw)
In-Reply-To: <87vd3lz4i0.fsf@gmail.com>

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
>>>
>
>

  reply	other threads:[~2010-11-25 18:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=iVVCy7X3a47WS0=eV68bp3sa7YS8-6fnf7d4T@mail.gmail.com' \
    --to=rick.moynihan@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=joel.boehland@evocomputing.com \
    --cc=schulte.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).