[O] Straight recursive fact prints in floating-point in org-babel but not in REPL
Org-babel seems to print SLIME / SBCL bignums as floating point, at least in this gist (please see https://gist.github.com/rebcabin/f73cecd3c9b7da6218e9). I'd like to be able to control whether bignums are printed out in full. Any advice for me?
Re: [O] Bug? Improper interaction with python variable _ ?
Correction: The first elisp-block should contain another command Here is the corrected org-mode file, top-to-bottom #+TITLE: Org-Babel Bug? #+AUTHOR: Brian Beckman #+EMAIL: bc.beck...@gmail.com #+BEGIN_SRC emacs-lisp :exports results :results none (org-babel-do-load-languages 'org-babel-load-languages '((python . t))) (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=. #+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." #+NAME: second-probe #+BEGIN_SRC python :session bug-org-babel :exports both :results value _ = 42 _ #+END_SRC #+RESULTS: second-probe : 42 But now, all blocks with =:results value= return the value of =_=. We broke org-babel! #+NAME: third-probe #+BEGIN_SRC python :session bug-org-babel :exports both :results value 999 #+END_SRC #+RESULTS: third-probe : 42 On Sun, Oct 4, 2015 at 10:12 PM, Brian Beckman <bc.beck...@gmail.com> wrote: > 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.beck...@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=. > > #+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." > > #+NAME: second-probe > #+BEGIN_SRC python :session bug-org-babel :exports both :results value > _ = 42 > _ > #+END_SRC > > #+RESULTS: second-probe > : 42 > > But now, all blocks with =:results value= return the value of =_=. We broke > org-babel! > > #+NAME: third-probe > #+BEGIN_SRC python :session bug-org-babel :exports both :results value > 999 > #+END_SRC > > #+RESULTS: third-probe > : 42 > > >
[O] Bug? Improper interaction with python variable _ ?
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.beck...@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=. #+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." #+NAME: second-probe #+BEGIN_SRC python :session bug-org-babel :exports both :results value _ = 42 _ #+END_SRC #+RESULTS: second-probe : 42 But now, all blocks with =:results value= return the value of =_=. We broke org-babel! #+NAME: third-probe #+BEGIN_SRC python :session bug-org-babel :exports both :results value 999 #+END_SRC #+RESULTS: third-probe : 42
Re: [O] export: noweb blocks substituted versus verbatim ?
Brian Beckman gmail.com> writes: Found the appropriate docs here: http://orgmode.org/manual/noweb.html#noweb
Re: [O] export: noweb blocks substituted versus verbatim ?
Andreas Leha med.uni-goettingen.de> writes: > > Hi Brian, > [[ omitted: deeper quotes ]] > > As far as I can see, the difference is that some of the code blocks have > the header argument `:noweb yes', while others do not. > > I do not know how to achieve working noweb extension during evaluation > but omitting noweb extension during export, though. > > HTH, > Andreas > Hi Andreas, Thanks for answering. I did some experiments putting `:noweb yes' in various combinations and also putting a dummy line before the references in the first (offending) block, like this: #+NAME: test-block #+BEGIN_SRC python :noweb yes :tangle test_foo.py dummy_for_org_mode = True <> <> def test_smoke (): np.testing.assert_approx_equal (foo_func (), foo_constant) #+END_SRC and separating the code lines with blank lines (as we must do in org-babel `session' mode). None of it made any visible difference. None of it made any difference
[O] export: noweb blocks substituted versus verbatim ?
Hello -- I have a situation where some code blocks with noweb references in them <> are substituted inline when I export the document, and other code blocks with noweb references, are copied verbatim into the exported PDF. I do not know what causes this difference in behavior and I don't know how to control it, but I'd like to control it. I'd like to be able to specify that some blocks have behavior 1 (references substituted inline) and other blocks have behavior 2 (references verbatim). I'm sure this is pilot error, but I'm stumped and would be grateful for advice. My Minimal Viable Example (MVE) follows below, and the PDF file that's exported is here https://drive.google.com/file/d/0B4v0MzmZfdm8TzRLeFlreUFnbEk/view #+BEGIN_COMMENT The emacs lisp block must export results, even though the exports are none, otherwise the block will not be eval'ed on export, and we will get unacceptable confirmation requests for all the subsequent python blocks. #+END_COMMENT #+BEGIN_SRC emacs-lisp :exports results :results none (setq org-confirm-babel-evaluate nil) #+END_SRC ** PyTests Define the test and cases. This code must be tangled out to an external file so =py.test= can see it. When I /export/ this to PDF, the noweb references, namely =<>= and =<>=, are substituted inline, so the typeset version of this block in the PDF shows ALL the code. This is not what I want. #+NAME: test-block #+BEGIN_SRC python :noweb yes :tangle test_foo.py <> <> def test_smoke (): np.testing.assert_approx_equal (foo_func (), foo_constant) #+END_SRC #+RESULTS: test-block : None The following blocks import prerequisites and do a quick smoke test: ** Do Some Imports #+NAME: imports #+BEGIN_SRC python import numpy as np #+END_SRC #+RESULTS: imports : None ** Define Some Variables However, in the typeset PDF, the noweb reference =<>= in the block below is /not/ substituted in-line, but rather appears verbatim. I want /all/ noweb references to appear verbatim in the exported, typeset, PDF document, just like this one. #+NAME: definitions #+BEGIN_SRC python foo_constant = 42.0 <> #+END_SRC #+RESULTS: definitions ** Define Some Functions *** Foo Function is Really Interesting #+NAME: foo-func #+BEGIN_SRC python def foo_func () : return 42.000 #+END_SRC #+RESULTS: foo-func : None We want results from pytest whether it succeeds or fails, hence the /OR/ with =true= in the shell #+BEGIN_SRC sh :results output replace :exports both py.test || true #+END_SRC #+RESULTS: : = test session starts == : platform darwin -- Python 2.7.10, pytest-2.8.0, py-1.4.30, pluggy-0.3.1 : rootdir: /Users/bbeckman/foo, inifile: : collected 1 items : : test_foo.py . : : === 1 passed in 0.06 seconds ===
