From: Aaron Ecay <aaronecay@gmail.com>
To: Brian Beckman <bc.beckman@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Bug? Improper interaction with python variable _ ?
Date: Thu, 29 Oct 2015 14:05:07 +0000 [thread overview]
Message-ID: <87pozxydm4.fsf@gmail.com> (raw)
In-Reply-To: <CAK2VK6uScVfayyRtMA0KgUJdYgwxC8FdowgxLPjJ_U0p4Bi16w@mail.gmail.com>
Hi Brian,
2015ko urriak 5an, Brian Beckman-ek idatzi zuen:
>
> Please see the gist below for a self-explaining example
> copied here for convenience. Emacs 24.5.1 with org-mode
> 8 something (not sure how to get it to report its exact
> version)... a very late version, I am sure. Verified with
> no init.el, that is, with emacs -Q
>
> https://gist.github.com/rebcabin/37f800da658f4b23ceaa
>
> #+TITLE: Org-Babel Bug?
> #+AUTHOR: Brian Beckman
> #+EMAIL: bc.beckman@gmail.com
>
> #+BEGIN_SRC emacs-lisp :exports results :results none
> (setq org-confirm-babel-evaluate nil)
> (org-babel-map-src-blocks nil (org-babel-remove-result))
> #+end_src
>
> * Mystery Number 1
>
> The first line of the first block must be blank, or we must =C-c C-c= the block
> two times. But we want to eval the entire file /via/ =C-c C-v C-b=, and we found
> that the first line must be empty.
>
> If you =C-c C-v C-b= this entire file, the python session buffer, named
> =*bug-org-babel*=, contains an error message that suggests the variable =_= is
> implicated in an error.
>
> We expect the value of this first block to be 999. Make sure that the python
> session is clear by typing =quit()=, then evaluate this entire file by
> =C-c C-v C-b=.
I’m not entirely sure what the error you are seeing is. I tried running
the below src block both with and without the initial blank line. In
both cases the result was 999, as expected, and no errors were reported
in the session buffer.
It would be good if you could use M-x org-version to report the exact
version of org you are using.
>
> #+NAME: probe
> #+BEGIN_SRC python :session bug-org-babel :exports both :results value
>
> 999
> #+END_SRC
>
> #+RESULTS: probe
> : 999
>
> * Mystery Number 2
>
> Now, we set the value of the variable =_= to something arbitray. In a real
> scenario, this variable may be set casually in a loop or some other context. The
> variable =_= is often recommended for /ad-hoc/ use, as in "don't
> care."
In the python repl, _ is set to the result of the last statement.
ob-python uses that fact to extract the value from the python process.
I would expect that creating an overriding binding of _ would cause
strange problems like the one you reported. So you should not assign to
_ in babel code.
--
Aaron Ecay
prev parent reply other threads:[~2015-10-29 14:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 5:12 Bug? Improper interaction with python variable _ ? Brian Beckman
2015-10-05 5:22 ` Brian Beckman
2015-10-29 14:05 ` Aaron Ecay [this message]
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=87pozxydm4.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=bc.beckman@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).