emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Lennart C. Karssen" <lennart@karssen.org>
To: emacs-orgmode@gnu.org
Subject: Re: Global variables in Org mode document with source blocks
Date: Tue, 25 May 2021 16:22:25 +0200	[thread overview]
Message-ID: <9b777904-f849-83b1-a9b2-87ab5d8bcc3c@karssen.org> (raw)
In-Reply-To: <CAJ51EToKGNUSw-TnDYivpCqNwHAMgrOUPJ5ZzgxgQpw9JuN=og@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 5746 bytes --]

Dear John,

Thanks a lot for your quick reply. My apologies for not replying
earlier. Some urgent things came up that took my time.

I tried your suggestions and settled on a small adaptation of your first
suggestion. Because the output of my source blocks is raw Org code (i.e.
the report text that explains the failure), I can't directly print
=failure-DIGITS= or something similar. My solution to that is to append
=# failure-BLOCK= to the output text (which is ignored during export)
and use your =count-matches= suggestion to count those. The text =BLOCK=
is different for each code block and should allow me to specify which
blocks fail in the Conclusion section.


Thanks a lot!

Best regards,

Lennart.

On 18-05-2021 17:03, John Kitchin wrote:
> Given all the different languages involved, I don't think there is a way
> to use a common variable. 
> 
> One way might be to have each block output some kind of string if it
> fails, and then in the last block you could search for the buffer for
> that string. Something like this:
> 
> 
> * Section 1
> 
> #+BEGIN_SRC sh
> false || echo "failed"-`date +'%s'`
> #+END_SRC
> 
> #+RESULTS:
> : failed-1621348872
> 
> 
> #+BEGIN_SRC python
> import time
> 
> if not False:
>     print(f'failed-{time.time()}')
> #+END_SRC
> 
> #+RESULTS:
> : failed-1621348926.125608
> 
> 
> * Final section
> 
> #+BEGIN_SRC emacs-lisp
> (format "There were %s failed blocks" (count-matches "failed-[0-9]"
> (point-min) (point-max)))
> #+END_SRC
> 
> #+RESULTS:
> : There were 2 failed blocks
> 
> Some alternatives include writing/appending to a file on error, and then
> counting the number of lines.
> 
> Another route is to use a :post header and search for the string there.
> 
> #+BEGIN_SRC emacs-lisp
> (setq n-failures 0)
> #+END_SRC
> 
> #+RESULTS:
> : 0
> 
> #+name: fail-capture
> #+BEGIN_SRC emacs-lisp :var data=""
> (when (string-match "failed-[0-9]" data)
>   (incf n-failures)
>   (message "captured a failure in %s. n-failures=%s" data n-failures))
> #+END_SRC
> 
> #+BEGIN_SRC sh :post fail-capture(*this*)
> false || echo "failed"-`date +'%s'`
> #+END_SRC
> 
> #+RESULTS:
> : captured a failure in failed-1621349398. n-failures=1
> 
> 
> #+BEGIN_SRC python :post fail-capture(*this*)
> print('This did not fail')
> #+END_SRC
> 
> #+RESULTS:
> : nil
> 
> #+BEGIN_SRC python :post fail-capture(*this*)
> print('This failed-9')
> #+END_SRC
> 
> #+RESULTS:
> : captured a failure in This failed-9
> : . n-failures=2
> 
> All these approaches need you to handle and catch the errors. I think
> other kinds of errors would stop the export process. e.g. if a block
> errors out from division by zero or something.
> 
> I don't know how easy it would be to check if a src block succeeded or
> not. If it was easy, you might use the org-babel-after-execute-hook
> variable to update something when a failure is detected. Some blocks
> create an *Org-Babel Error Output buffer somewhere, but i don't know if
> this is 100% reliable across all blocks.
> 
> John
> 
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu <http://kitchingroup.cheme.cmu.edu>
> 
> 
> 
> On Tue, May 18, 2021 at 9:58 AM Lennart C. Karssen <lennart@karssen.org
> <mailto:lennart@karssen.org>> wrote:
> 
>     Dear list,
> 
>     I am working on a dynamic report in Org mode, where I use source blocks
>     in various languages to process data. Several blocks produce text or
>     tables that become part of the PDF on export.
> 
>     The final chapter should state whether all checks passed, or whether one
>     or more failed (it is not necessary to know which step failed).
> 
>     In a single language environment, I would use a variable (called e.g.
>     nrChecksFailed) that would be incremented for each failing check. In a
>     single language Org document this could probably be done with a
>     :session, but given that I mix Awk, Bash, Emacs lisp and R that doesn't
>     look like the way to go. Do Org documents/source blocks have some
>     concept of a (global) variable that I can pass to my SRC blocks and
>     increment inside them?
> 
>     E.g. after somehow initialising nrChecksFailed = 0, I would like to do:
> 
>     #+header :var nFailed=nrChecksFailed :var someData=someData
>     #+begin_src R :results raw
>     do_some_check_here_on_someData
> 
>     if (check_results_OK) {
>       cat("check A passed\n")
>     } else {
>       cat("check A *failed*\n")
>       nFailed <- nFailed + 1
>     }
>     #+end_src
> 
>     So that in my conclusion chapter I can do for example:
> 
>     #+header: :var nFailed=nrChecksFailed
>     #+begin_src bash  :results raw
>     if [[ nFailed -eq 0 ]]; then
>       echo "All checks passed
>     else
>      echo "One or more checks *failed!*"
>     fi
>     #+end_src
> 
> 
>     Best regards,
> 
>     Lennart.
> 
>     -- 
>     *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>     L.C. Karssen
>     The Netherlands
> 
>     lennart@karssen.org <mailto:lennart@karssen.org>
>     http://blog.karssen.org <http://blog.karssen.org>
>     GPG key ID: A88F554A
>     -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands

lennart@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  reply	other threads:[~2021-05-25 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 13:57 Lennart C. Karssen
2021-05-18 15:03 ` John Kitchin
2021-05-25 14:22   ` Lennart C. Karssen [this message]
2021-05-18 17:25 ` Greg Minshall
2021-05-25 14:27   ` Lennart C. Karssen

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=9b777904-f849-83b1-a9b2-87ab5d8bcc3c@karssen.org \
    --to=lennart@karssen.org \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: Global variables in Org mode document with source blocks' \
    /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

Code repositories for project(s) associated with this 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).